I'm glad someone else noticed it.

You don't have to sterilize anyone or otherwise restrict anyone's rights in order to limit reproduction. What you have to do is respect the rights of women, and the women themselves. Make sure that women are free to get an education, own property, vote, control their own bodies, and all those other things men are often free to do. Just look at the birth rates in the countries that already do this, and look at the quality of life in those countries. For anyone bothered by abortion, the rates of that actually go down too, but why don't you go work on early detection and artificial wombs instead of treating women like cattle?

This was pretty much my point. Whether a researcher uses Windows or Mac OS seems to be determined by either the likelihood that they program or use TeX; in either case they use Mac OS.

As far as I can tell, they are. I mean, you just have to accept that. Would they be more productive on Linux? If so, I can't imagine why they would have switched. And I'm not saying everyone has jumped ship, just most. I've seen no compelling reason for anyone to switch to Linux from Mac OS or Windows. All that said, Linux still runs the computing clusters, but you can run an X server on either Mac OS or Windows for those remote apps.

The poor use of Home, End, etc. on Macs is one reason I haven't switched. I don't think they are even normal keys anymore; you have to press Fn or something, I think. I think somehow Up is almost the same as Home, and Down as End, but I'm not sure and . . . ugh. As for copy and paste, two options: keyboard shortcuts, and select then drag. Yeah, I think you have to give up middle-click insertion of PRIMARY, but I'm pretty sure you gain a clipboard that works for more than text. (Granted, this may have improved on X11 desktops—X certainly allows selection of anything—but I don't use that lately.)

You also get drag and drop that works correctly.

But aren't Windows, GNOME, KDE, Unity, and whatever pretty much doing the same thing? I dislike it too, but shy of going for otherwise even more broken desktop environments, I don't see a way out of that. I think I'm soon due for another round of trying everything out, but last I checked, Unity was the best without having to tweak anything.

Call me back when drag and drop works correctly on any X11-based desktop.

. . . called Mac OS.

That's where many desktop Linux users I've known are now. Many hated going there, because they believe in software freedoms, but they had work to do.

As stated above, I misread fnj's description.

X11 remains the windowing system on which nobody implemented click-to-focus and focus-to-raise with exceptions for things like drag and drop.

Not that it's not possible. It's just that nobody has released code that does it.

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.