I made a stylesheet for HTML form elements that looks similar to Apple's Platinum theme. An exact duplicate is not my goal.
I have a page where I'm planning a new desktop environment for free systems. It's a work in progress.
When I started messing around with this, I'd been out of touch with the free software community for a while. I was under the impression that Wayland was still this new thing that might replace X but then again might not. It looked to me like there was still active development on X, but I've since learned that I was mistaken. So, now I see that Wayland is the way to go and maybe some other things I didn't like have become the de facto standards.
I had wanted to just get the various X11-based desktop environments to fix a little problem. It required a simple change to window management and toolkit design. The WM change was just to stop sending WM_TAKE_FOCUS for button presses in the client areas of globally active windows. Most toolkits don't use globally active windows. As far as I know, only Java UIs do, by default, and it's not even an option for most toolkits. Only people using Java-based UIs would even notice the window management change, which brings us to the change needed in toolkits. That change is just for the toolkit to call XSetInputFocus when it wants the keyboard focus after a button press in the client area of its globally active windows, like it's supposed to do according to the ICCCM. Since only Java UIs use globally active windows, they would be the only ones that have to change.
Now, a nice change would have been for toolkits like Gtk and Qt to start using globally active windows too. All of this would enable desktop Linux users to do something that only Mac users can do right now: drag a selection from a background window without raising the background window.
OK, it's a little more complicated than that. For one thing, the window manager should not only not send the WM_TAKE_FOCUS message for button presses in the client area of globally active windows, they should also not raise those windows in that case. If they're already waiting for FocusIn events to raise windows, this should not be a problem. Another thing is that toolkits would have to not call XSetInputFocus when the button press might be the start of a drag, but they probably would want to call it otherwise. This actually makes another trick possible. Client windows could choose to stay in the background for other actions too. Already, using a scroll wheel doesn't change input focus; clients could allow their scroll bars to be dragged without changing focus too. There are other things, found only on Macs, that could happen for Linux desktops too. One other thing, which I think toolkits already do, is that they'd have to always take focus when they get the WM_TAKE_FOCUS message. (Basically, that message is the WM saying, "There's no way you could know that you should be focused, but you should be.)
My goal in all this was to make drag and drop work better so that it could be used for more things and maybe some other UI improvements might follow from that. I believe that this rethinking of how window focus works would have also improved the situation with things like focus stealing. Alas, I've since learned that some people believe click-to-focus itself to be an example of focus stealing. Not everyone can be pleased.
I get the impression that drag-and-drop is still broken in many ways, even on Wayland. Whatever the case, I know it's not working as well as it does on Macs, because today's assumptions about focus handling on Linux desktops don't allow it on either X or Wayland. I think there are other problems simply because most Linux developers are not aware of what Mac users can do, and they're used to working a certain way anyway.
I think it's OK for a desktop environment to do something awesome even if almost no one knows about it. Lots of Mac users are suprised to learn about background dragging, and they've probably done it without noticing.
Right now, it's impossible for drag and drop to work really well on Linux desktops. Even when it is possible, there's still the matter of making it actually do things. I think that between the toolkits and the file managers, most uses are covered.
So, what now? Well, Wayland has actually complicated things in some ways and made them easier in other ways. The existing click-to-focus compositors have duplicated the status quo of X desktops. Except for Java, all toolkits used the locally active input model, and now that's the only option. It doesn't have to be this way, but cleanly implementing something like the globally active input model on Wayland requires agreement from all parties involved. Otherwise, there has to be some sort of opt in; we need the Wayland equivalent of indicating a focus model. Either socially or technically, that's complicated. What's really easy it making it work right from the start. Desktop compositors, in the click-to-focus mode, would simply not focus windows on clicks in their client areas. They would expect clients to request focus, through the xdg-activation protocol, if they want it. Just as they'd have to do on X, toolkits would have to determine if a button press is meant to focus or do something else, like begin the drag of an item.
I tried, some years ago, to bring this to the attention of Wayland developers and toolkit developers. I think only one person understood, but I know that neither of us yet understood exactly how this would work on Wayland. We needed the XDG activation protocol, but it didn't exist yet. I may try again, but I get the feeling nobody wants to hear it unless I've got code for everyone.
The problem with me trying to write code for this is that it requires at least a little API change for toolkits; just enough for deciding whether a button press should cause activation. I think that in Gtk, that would mean an addition to the GtkWidget API, like adding a boolean property or maybe a callback that returns a boolean. I really don't know. I haven't been familiar with Gtk since some version 2 release. I think the compositor code might be easier. Assuming the XDG activation protocol is already implemented, it should be just a matter of removing the code that activates a window on a button press.
Now that I have the time to work on some code, the code I wanted to work on is irrelevant. I don't know what to do about that.
Update! The code I wanted to work on may be irrelevant, but making Wayland work for my purposes is a bit too hard for me right now. I can make things work on X, so that's what I'm going to do for now. Maybe once I've mostly worked thing out it will be easier to switch to Wayland. Part of my trouble is that the existing Wayland protocols don't do enough. For example, I need a way to tell the compositor to animate the appearance of a surface as if it emerged from an icon on the screen, and I need to be able to tell the compositor what the final position of the surface should be. Except perhaps for a KDE-specific protocol, there's no way to specify where on screen a surface should be; there are only relative positioners for pop-ups.
(I.e., stuff I wrote maybe a year ago before I knew what was up.)
Probably the most complete code I've uploaded is a page demonstrating the use of a double crystal monochromator for X-ray absorption spectroscopy. It was written before HTML5 was a thing and uses an old doctype that was created for combining HTML, SVG, and MathML.
The Shuffle window manager is a recent hasty creation. I made it to address a longstanding problem with X11 desktop environments: they don't handle click-to-focus very well. There's more explanation on there. Since it's not enough to have a window manager, I've been working on making a widget toolkit. This has been a slow process, especially since my holiday ended.
All of the X11 widget toolkits I've checked fail to exploit a key focus mode for a click-to-focus environment. Picking one and forking it is a complicated process and I'd rather not maintain a fork. I offered some patches many years ago, but they were rejected either because the problem was not understood or it wasn't time for the API or ABI change they required. I got busy with work, so I wasn't able to keep up with toolkit development.
I've barely started writing a toolkit in Common Lisp. This is difficult because I have not been a Lisper for a long time. I was barely one almost 20 years ago, and that was with the lisp used by the Sawfish (then Sawmill) window manager. I've been using LabVIEW almost exclusively for more than 10 years now, so I'm barely familiar with Emacs anymore. Another problem is that most of the code in CLX dates back to the creation of version 11 of the X protocol and it's poorly documented I only recently found goodmediocre documentation. So, why use Common Lisp? I like the language, despite the barriers to using it. I'm also not expecting people to use my toolkit because it handles focus a little better; my hope is that Gtk and Qt developers will adopt the focus model I'm promoting.
In case no one wants Linux users to be able to drag and drop like Mac users have for decades, I've got my own desktop environment project: INDEX. It's the INcompatible Desktop Environment for X. If no one likes my ideas, it may indeed remain incompatible, but that's OK. It's a hobby.
My mantra for the INDEX project is "OS/2 with the polish of Apple Platinum." I used OS/2 versions 2 and 3 long ago and really enjoyed them. (Screenshots of version 4 tell me I wouldn't have liked it with its multicolored tabs.) I think it had some rough edges, so that's where Apple Platinum comes in. I don't like how Mac OS (or macOS) is centered on applications, but they got so many other things right. So the idea of INDEX is to provide an object-oriented user interface, like OS/2, with many of the usability details that Macs are known for.
Why not Wayland? I'm not very familiar with it, and I think remote display is cool. Where I work, some of the essential computers are running some version of X on some version of Linux. They aren't computers I use, so I don't know the details. I do know that the lead programmer can check on the computers in the control room from his office by using X. I don't have any idea how many people actually use X remotely, but I know there are some and I don't think they should be abandoned. Moreover, I know my colleagues who use Linux now are disappointed with the interfaces that are on offer. I'd like to give the scientific community a better option than macOS.
Over the years, I've used many different kinds of interfaces: computational notebooks, 2D and 3D CAD, scientific spreadsheets, SCADA software, specialized analysis software, drawing programs, IDEs, and, of course, "office" software. I want a desktop environment that supports all these things and interactions between them. All of these kinds of programs are available, more or less, as web applications. Whether local, web, or remote X based, I want them all to work together.
I don't yet know what the complete INDEX system will look like, but I expect it to be very data oriented.
20 years ago, I thought the desktop should look something like this:
At the time, that took up most of my 800x600 screen. I think the low-contrast style of OS/2 was my goal, except for those bumpy window frames. The OS/2-style settings panel is there, but the alert and dialog look more like something from a Mac.
About 10 years ago, my thinking was more like this:
My screen have gotten much bigger, but you can see some things changed and some remained the same. I was trying out the smooth gradients look that has dominated system UI for a while now. There's one menu at the top of the screen, but there's something in the corner and creeping down the side of the screen. Now there are tabs everywhere! You can't tell from a static image, but the idea is that tabs are provided by the system; you can group web page tabs with spreadsheet tabs if you want.
I have another image from long ago. It's a bunch of controls, but it's a little weird.
All those red boxes are where the text or icons go. If you can see the pink above and below the red, that's room for font ascenders and descenders. The little bits of cyan are selected text. From the size of the image, I can tell you it's about 20 years old; it had to fit on my tiny laptop screen. You can see the Apple Platinum influence there.
Despite the time I've spent on pictures, my real interest is interaction. That might seem unlikely, because I've got another page of pictures. I confess: drawing the pictures is a comfort while I think about how to make it all happen. I haven't written much code outside of LabVIEW recently. The Shuffle window manager is pretty basic C code. I realized I should probably put the menu bar in the window manager, so I need menu making code. I need both widgets and interpretation.
I need widgets, so objects seem like a good idea. Do I use GObject, which I already know? How about C++? Vala? Rust? Go? JavaScript? CLOS? I've written so little code so far that I'm not really committed to any of these, but I think I'm going with CLOS, or Common Lisp.
I also need some way for apps to tell the window manager what menus to display and how to update them. I need both a format and an interpreter of that format. If it's going to work over remote X11 connections, I should probably use X window properties, at least to start; they're easy, if clunky. Common Lisp is nice and dense, but maybe JSON is good enough. The latter has the advantage of being more widely used.
For a few reasons, keyboard input focus needs to be well controlled.
A global menu bar isn't very useful if it doesn't track the window you're using. This is one reason the environment should be click-to-focus. Another is that that's what the vast majority of users expect.
If there are to be utility, palette, or insepector windows, they should also track the active window without taking focus from it.
You should be able to drag any draggable thing you see on the screen without changing the screen. That means that if there's something selected, or an icon, in a background window, dragging the selection or icon away should leave the window in the background. There may be a gesture to make background windows pop up so something can be dropped on them, but that should be different from the drag starting gesture.
Popped up windows, like dialogs and alerts, should get keyboard focus if they come from a place with keyboard focus. Focus should not change from one app to another just because the other popped up an alert.
The first reason usually given for a global menu bar is Fitts's Law. What's more important is that the menu bar should be the last interface you have to use for anything. As the interface of last resort, it shouldn't take up a lot of space. Menu bars in every window make it seem like menus are the first way to do something.
tbd: basically making a consistent OOUI
One thing that needs to go away is the idea of saving files. Lot of web apps have effectively done this. A user's work should always be preserved. Still, many people are in the habit of periodically pressing Ctrl+S to save their work, and that should do something. "Save" will therefore be interpreted as "Stamp" and a timestamped copy of the user's work will be set aside.
Working in a lab or with multiple remote workstations, it's very easy to lose track of where you are. Samples have to be changed, people interrupt, machines go wrong. It should be easy to get back on track when you look at a screen, and to know the screen is the right one. Microsoft's Metro design language, with its emphasis on typography, is really good for this.
tbd: mostly about DnD
An OOUI isn't necessarily a great fit for a POSIX system with its many file and directories. INDEX will have two characters: one for the user's home folder, and another for everything else. The home folder, containing the user's own files, is an easy fit for an OOUI.
The INDEX window manager will provide the global menu bar.
The INDEX file manager will be an X selection manager which apps can rely on for file location services.
To facilitate the presentation and manipulation of files and information about files from both the local system and remote systems, the X File Manager Protocol allows applications and a singular (or host-specific?) file manager to exchange information.
A file manager is an X client which owns the manager selection FILE_MANAGER or FILE_MANAGER_hostname, where hostname is replaced by the hostname for the filesystem managed. The usual conventions for manager selections apply.
FILE_MANAGER
FILE_MANAGER_hostname
OPEN
CLOSE
ICON_GEOMETRY
Something for apps to say they've opened files?
A way to notify that the icon for a file has moved?
Notebook interfaces are cool.
Note-taking software is cool.
An outliner seems like a good thing to have.
Some way to have a slide show with transitions.
If only everything could be LaTeX.
?
Won't somebody make a feed reader that aggregates different feeds into a single timeline? I haven't looked at this in a while. Maybe there's more than one now.
I use Zotero.