emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]


From: tomas
Subject: Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]
Date: Tue, 23 Aug 2022 14:02:21 +0200

On Tue, Aug 23, 2022 at 02:45:24PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 23 Aug 2022 06:44:50 +0200
> > From: <tomas@tuxteam.de>
> > 
> > One strong evidence is application-side decorations. Yes, the toolkit
> > is supposed to take care of that. But the temptation for application
> > developers is enormous to "know better" here and there.
> 
> I indeed question the optimistic belief that system-wide conventions
> are always better.  They might be in some basic stuff, like the outer
> decorations of the GUI windows, but other than that...

Yes, but the "outer decorations" now belong to the application (the
browser, at least, is like that).

> > Currently I have the "pleasure" of working with Windows [...]
    [first click active]

> Jist FYI: that's configurable, if you want to change it (I don't).

Hm. On an application-by-application basis? But... good to know.

> > Other
> > applications do something on the first click right away (the browser
> > selects the URL if you happen to click on the right place; some browser
> > "apps" do even much more -- one chat app I "have to use" puts you in
> > some answer mode).
> 
> The solution, of course, is to always click only on the window
> decorations, not inside the client area.  Then all the applications
> will behave the same, because it isn't the app, it's the window
> manager's behavior.

But the problem is... the decoration area /is/ client area for those
more "modern" windows (e.g. the browser). And the javascript running
in the browser (the "app") has a say in how those things react.

I find myself searching for spots "between" the menus and the close
widget to land the click without creating havoc. And don't get me
started with scroll events, which can (and do) go to unfocused
windows. But that's not the topic here.

> Alternatively, configure Windows to auto-focus a window when the mouse
> pointer is over it for some predefined minimum time.  That's what I
> do, and I never needed to look back.  (You can also auto-raise the
> window at that time, but I don't: the whole point is to be able to
> type into a window that is not on top.)

Oh, point-to-focus, thanks for this :-)

I'm going to install Linux on the box (I've my boss's OK), but otherwise
I'd give it a try, so thanks for the hint!

Cheers
-- 
t

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]