I see I misread what fnj wrote in my haste and excitement. Yes, it seems fnj is just describing sloppy focus behavior in E17. I misread "as soon as the mouse goes over it" as "as soon as the mouse button goes down over it".

Still, you're providing an excellent example of not getting it.

This is really easy: go find a computer with Windows or Mac OS and try it out, then try to do the same thing on anything built on X. Seriously, if you haven't once seen a properly functioning click-to-focus-unless-the-ButtonPress-could-begin-a-drag system, there's no point in replying.

There is no version of PointerRoot or sloppy focus or any such thing that exhibits the correct (as in, "expected by most of the world") behavior. Windows and Mac users—i.e. the vast majority of computer users—do not expect a window to get focus and stay below other windows as PointerRoot and sloppy focus allow. It has to be at least click-to-focus and raise-on-focus, or you're talking about a system that does not work as most people expect it to. All the systems have windows that are exceptions like docks, menu bars, palettes, the desktop; those are not the issue. Neither are pedantic points about scroll wheels being implemented as buttons 4 and 5.

The problem is that on X click-to-focus is click-to-focus-always. It needs to be click-to-focus-unless-some-conditions-are-met. One of those conditions is that the ButtonPress not possibly be the beginning of a drag; there may be other conditions I'm forgetting at the moment.

At least most of the people I've known to have worked on window managers acknowledge that they cannot do what Windows and Mac do without baroque schemes. I don't know who you are calling "bullshit" on behavior that has long been standard on Windows and Mac OS.

I've already wasted too much time on this. Until you've realized that there is a deficit in existing X-based systems, or found one that lacks the deficit, I'm not replying again.

I can't tell if you don't know what you're talking about or are being a pedant, but I'll assume the latter.

If "focus" bothers you so much, then pretend I said this instead:

"Can I drag a file from a lower, inactive folder to anywhere without either raising or activating that folder? You know, like Windows and Mac users have been able to do almost as long as those have existed?"

I'm not talking about the focus change that happens whenever there's a grab or anything like that. Most people aren't when they talk about this.

I'm really very surprised that anything on X is doing this correctly. I know of one way to get it right, but I haven't found any code (but my own) doing it that way. Some baroque schemes were being discussed a long time ago and, except maybe in some rare instances, nobody went forward with any of them. It's just not important enough to most of the people using X for anyone to have bothered. Most don't see any value to it because they are using pointer-root-, sloppy-, or something other than click-to-focus, and various schemes for controlling raising and lowering of windows.

Thanks for the tip. I'll have to check it out.

You've used neither and have access to neither?

Fascinating.

Can I drag a file from a lower, unfocused folder to anywhere without either raising or focusing that folder? You know, like Windows and Mac users have been able to do almost as long as those have existed?

In the mid 1980's as part of some gifted program in Baton Rouge, I learned Logo. I think that was part of a Summer enrichment program. I don't remember what kind of computers we used.

I taught myself TI-99/4a BASIC.

In the late 1980's, there was a computer in my middle school algebra classroom which was really just an excuse to goof off.

In the early 1990's, in high school at LSMSA, I learned Pascal on a VMS terminal.

Given where I was and when I was there, I fell into this gap between "everyone should know how to use a typewriter" and "everyone should know how to use a keyboard", so I never had to take a typing class. I think most of my classmates and I would have been insulted to have had to take one of these "How to use MS Office" courses I hear about.

Window managers are supposed to claim a selection for each screen they manage named WM_Sn, where n is the number of the screen. All this is really used for right now is to let one window manager take over from another one. The selection is one of a special kind of selection known as manager selections. Basically it makes sure that some shared resource is only controlled by one program at a time.

The freedesktop.org System Tray Protocol uses a manager selection so applications can find the "system tray" to put icons in it. I don't know if that spec is still used.

The principle idea that hasn't seen much use is side effect targets. Normally selections are used for moving data around, but the ICCCM specifies more than that. Requesting a ConvertSelection on a side effect target is basically a remote procedure call.

Suppose you have something that allows operations on groups of windows, like a task bar. One thing I do on Window that I can't recall doing on X is asking for a group of windows to be tiled or cascaded. The EWMH spec, so far as I can recall, doesn't provide a way to do this or even an obvious path for extension to do so. The request to cascade a list of windows would have to somehow include all of those windows, and can't be broken up into a series of ClientMessages without using something to specify that a sequence of ClientMessages has begun and ended. A side effect target is ideal for this. The task bar calls ConvertSelection on WM_Sn with a target of CASCADE and a property which contains the list of windows to be cascaded. The window manager then cascades the windows listed and lets the task bar client know if the operation succeeded or failed.

I didn't blame X for anything. I actually like Gtk+ and have longed wished this problem would be solved. (You see my name. You can dig up a bug report.) But I haven't been able to convince the right people to see focus handling (and other things) the way I see them. Unfortunately, "the right people" means not only Gtk+ developers, but also Qt developers and at least a few window manager developers. I'm working on what I hope is a more convincing argument, but this is really not my day job.

I also have this nagging feeling that compositing window managers may have changed the scene so much that my understanding no longer applies. But if that were so, I would trade a compositing window manager for a properly working non-compositing window manager in a cycle.

Oh, but gimp itself is probably part of the problem. The gimp way of handling windows was snafu last I checked.

It's not that ridiculous. There's more than one aspect of X to understand. I know next to nothing about drivers or anything else internal to X, but I have, I believe, a decent grasp of the things above those layers which are documented. Unless the documentation is lying, there are things on X that have, especially for the sake of modern UIs, been done incorrectly for years. Focus handling is the main thing I keep harping on. Just about everything should be using the globally active focus model by default, but most things don't. Motif and other Intrinsics-based toolkits allow it. Gtk+ does not. I don't know if Qt allows it, but it didn't do it by default last I checked. Too many people "just know" that's not the way you do things, so they keep doing them the way they've been doing them and then can't get things like drag-and-drop to work properly without a bunch of ugly hacks. There's too much knowledge of what is, getting in the way of learning what could be. My fear for an X12 would be that, like Wayland (or maybe just Weston, can't tell yet) developers almost did, they would lock-out getting things done the right way.

The X selection mechanism, for another example, is something that could be used to greater effect. But most people think of it as just the PRIMARY selection, the clipboard, and part of drag-and-drop, if that much. Fewer people recognize it's part of window management and the message tray protocol (or whatever it was called). It has more potential, but again you get people who know very well what X is, but don't recognize what it could be.

Yeah, yeah, RTFA. Sorry for existing before coffee.

Potential protocol changes were noted in the documents of version 11, such as the ICCCM which notes that the FocusIn event should have a timestamp and a previous-focus field. Has anyone out there considered just taking X11, making changes known to be needed, and dropping the protocol support for what's rarely or not needed anymore?

Mod parent up!

How many people miss this obvious combination is amazing. If you live in your office, I recommend getting a nice comfy chair too, maybe with an ottoman and a side table. And task lighting. And a quiet circulating fan.

And an espresso machine.

I don't remember the move in. I used OS/2 until version 3.something. Then my priorities shifted and I used whatever was available as needed. When I came back to computers, I was quickly drawn to Linux. I still want my pre-Warp 4 WPS, but my next computer will probably be a Mac.

I think there's a niche for a WPS, with some UI fixes like a single menu bar, running on Linux. Given spare time and energy, of which I have less every day, I work on the design, documentation, and maybe some code for such a system. Maybe if I win the lottery . . . well, I guess I should play it first.

This is like watching a train wreck. I really should just go do something else.

Sometime last year I went through every DE available from Ubuntu repositories. KDE and Kubuntu shared the feature of making me nauseated when I had to use the mouse. It seemed like everything on the screen responded to pointer crossing. For all I know they track the pointer, treat it as a light source and adjust colors, shadows, and highlights all over the desktop as it moves around. I doubt they do that, but it felt as bad as I imagine that would feel.

I had hope for XFCE, but the menu bar was broken and there were so many icons and colors that it looked like the DE had been through gangland and tagged by everyone.

GNOME3 might have been OK if they both put the menu bar in the right place (just one, top of the screen) and didn't waste so much screen space with huge title bars.

The rest weren't worth more description.

Maybe I'll get bored enough sometime to try the new offshoots like MATE or whatever, but for now Unity puts the menu bar where it belongs and mostly stays out of my way. Too bad there isn't a decent spatial file manager anymore; I suppose I could settle for Miller columns, but we don't have those either.

Oh, GNUstep might do the trick, but putting it together correctly (no WIndowMaker) is too much trouble for now.