To me a top bar only makes sense when it contains the active window menu like on Mac. Keeping a bunch of disk-browsing shortcuts and a huge empty space always on top seems a waste.
For me even the top bar on macOS doesn't make that much sense, since the menu might be far away from the related window. This UI concept is not a good fit for large screens (and was never intended to be used with such screens, since the design is from stone age).
Whilst your point is fair, I do think the fitt's law benefits are pretty huge (ie the infinitely extending target because it's across the screen edge).
It really depends on usage patterns I guess. If you have lots of _really_ small windows then your point is entirely correct, but if people are using large windows then it becomes less clear - there's a fair chance they're moving almost as far to reach the edge of the window for the in-window menu bar, but not benefiting from the screen edge infinite target, at which point the macos model becomes superior.
The thing is I suspect the cut-off applies even for half-screen windows these days, I think the benefits of screen edge scale better than the benefits of window edge (since you can always move faster if you don't have to aim well). On the other hand, I guess there's an upper limit to practical window size, regardless of how large screens get.
I think fitts law is precisely why it’s a bad design. I don’t use the menu bar very often, so I’d much rather have something else on the screen edge. Like browsers tabs for example, which I use all the time and sit on screen edge on windows/linux.
Do they? It doesn't look at all like that when I google screenshots. It looks like there's some chrome in between the top of the screen edge and the start of the tab. At least in Chrome.
It's crazy to me that Chrome still doesn't support any real equivalent to this; it's 2022 and Chrome (AFAICT) still insists on shoving every single tab end-to-end at the top, squishing them into tiny unclickable slivers, like some absolute fucking maniac. Even Edge gets this right by supporting vertical tabs (albeit with far less sophistication than TST), and it was supposed to be a cold day in Hell before I ever gave a Microsoft-developed web browser any sort of praise.
It's not that Fitts' Law forgot it, but that the designer of "infinite height" menu bars (Bruce "Tog" Tognazzini) didn't foresee today's gigantic and multiple screens, and was designing for the original Mac, whose screen was tiny and singular in comparison!
Linking to an archive.org cache since Tog's web site's https certificate expired.
The Fitts' Law benefits of pie menus are significantly more profound than the Fitts' Law benefits of the "infinite height" menu bar that Tog describes in his classic article, especially on large screens. And they don't result in you moving the cursor far away from where you want to be next.
Fitts' Law says the target acquisition time (and error rate) is related to the target size (larger target = better, so pie menus make all the targets quite large, extending in all directions to all four edges of the screen; menu bars also do, but only in one direction, wasting three out of four screen edges), and the target distance (nearer target = better, so pie menus make all the targets uniformly quite nearby, exploiting all directions; menu bars don't minimize the distance, only exploit one possible direction (up), and you also have to move back too, so it's worse on a big screen).
Also, multiple displays that you can move between throws a monkey wrench into the "infinite screen edge". Which may be one reason why nobody (except for the beautiful weirdo in the thread above ;) ) ever puts a screen above or below another screen, or a menu bar on the left or right edge, even though Windows has always let you do that, but the Mac doesn't.
There is another predictive model similar to Fitts' Law called "Steering Law" that applies to the narrow twisting "tunnel" from your current position, to the menu bar, through the menu and submenus, and back to where you need to be next, that you have to "steer" the cursor through in order to accomplish a task:
>The steering law in human–computer interaction and ergonomics is a predictive model of human movement that describes the time required to navigate, or steer, through a 2-dimensional tunnel. The tunnel can be thought of as a path or trajectory on a plane that has an associated thickness or width, where the width can vary along the tunnel. The goal of a steering task is to navigate from one end of the tunnel to the other as quickly as possible, without touching the boundaries of the tunnel. A real-world example that approximates this task is driving a car down a road that may have twists and turns, where the car must navigate the road as quickly as possible without touching the sides of the road. The steering law predicts both the instantaneous speed at which we may navigate the tunnel, and the total time required to navigate the entire tunnel.
>The steering law has been independently discovered and studied three times (Rashevsky, 1959; Drury, 1971; Accot and Zhai, 1997). Its most recent discovery has been within the human–computer interaction community, which has resulted in the most general mathematical formulation of the law.
Fitts' Law and Steering Law also apply to the forgiving pull-right submenu design that the original Apple Human Interface Guidelines described, which Tog invented, Apple forgot about (but finally rediscovered), and Amazon reinvented, which I was just writing about recently here:
I love pie menus and wish they were used more. What I really like about them is that if they're well implemented, they can be the discoverable version of a gesture system.
You're right, that's a great thing about them pie menus: they are "self revealing", since they show you how to use them.
There are three phases of using pie menus, and they support "rehearsal" to move you smoothly and seamlessly and unconsciously from novice to expert:
1) Novice: Click to pop the menu up. Look at the screen. Read the menu items. Browse the items (by pointing at them, possibly revealing more information or hiding unselected item labels, see the Unity3D pie menus for an example). Each time you use the menu this way, you're rehearsing the faster mouse gesture to make the same selection.
2) Intermediate: Remember which direction the item you want is in. Press and move in that direction, then look at the screen and wait for the menu to pop up confirming that you have selected the right item. When you know you got the right item, release the mouse button to select the desired item. This increases your confidence that you can (unconsciously) move onto the next stage.
3) Expert: Remember which direction you want, and swipe (mouse ahead) in the appropriate direction, even making multiple selections through nested menus. It's not even necessary to look at the menu (you can keep looking at whatever the menu selection affects, like the object you clicked on to pop it up, and the pie menu gesture tracking can provide real-time feedback of previewing the changes during the gesture, before even showing the menu. At any time you can stop moving the mouse and the menu will pop up and reveal the possible and currently selected items and their directions.
Color selection, font style, or size selection menus are great examples of previewing menu selection effects without needing to show the menu, where it's more obvious to just see the effect on the object directly instead of reading about it in the menu, popped up over and blocking your view of the object itself.
Also, the distance as well as the direction can be used as a parameter, like a 2-dimensional font "pull-out" style (direction) size (distance) pie menu.
Linear menus with keyboard shortcuts suffer from the fact that the keyboard shortcuts are totally different actions than using the menus the slow way with the mouse, so slowly using linear menus with the mouse is NOT rehearsal for quickly using linear menus with the keyboard, and all your time using linear menus the slow way is wasted, instead of rehearsing to use them the fast way every time you use them the slow way, like pie menus.
Pie menus also support "browsing" and "re-selection", as opposed to marking menus or gesture recognition. All possible pie menu gestures are valid easily understandable selections, while with marking menus and gesture recognitions, most possible gestures are syntax errors.
So you can move the mouse into and around the pie menu (even before it's popped up) to browse different items (seeing their effect on the object you clicked on, instead of the menu popping up and blocking your view of it). This enables you to correct mistakes, as well as simply browse and see all the available options by pointing at them (possibly revealing more detailed descriptions, like the Unity3D menus).
The space of all possible gestures, between touching the screen / pressing the button, moving along an arbitrary path (or not, in the case of a tap), and lifting your finger / releasing the button. It gets a lot more complex with multi touch gestures, but it’s the same basic idea, just multiple gestures in parallel.
Excerpt About Gesture Space
I think it’s important to trigger pie menus on a mouse click (and control them by the instantaneous direction between clicks, but NOT the path taken, in order to allow re-selection and browsing), and to center them on the exact position of the mouse click. The user should have a crisp consistent mental model of how pie menus work (which is NOT the case for gesture recognition). Pie menus should completely cover all possible “gesture space” with well defined behavior (by basing the selection on the angle between clicks, and not the path taken). In contrast, gesture recognition does NOT cover all gesture space (because most gestures are syntax errors, and gestures should be far apart and distinct in gesture space to prevent errors), and they do not allow in-flight re-selection, and they are not “self revealing” like pie menus.
Pie menus are more predictable, reliable, forgiving, simpler and easier to learn than gesture recognition, because it’s impossible to make a syntax error, always possible to recover from a mistaken direction before releasing the button, they “self reveal” their directions by popping up a window with labels, and they “train” you to mouse ahead by “rehearsal”.
More comments from the HN discussion of "Visualizing Fitts' Law":
>Pie menus benefit from Fitts' Law by minimizing the target distance to a small constant (the radius of the inactive region in the menu center where the cursor starts) and maximizing the target area of each item (a wedge shaped slice that extends to the edge of the screen).
>They also have the advantage that you don't need to focus your visual attention on hitting the target (which linear menus require), because you can move in any direction into a big slice without looking at the screen (while parking the cursor in a little rectangle requires visual feedback), and you can learn to use them with muscle memory, with quick "mouse ahead" gestures.
[...]
Updated links from that old message:
An Empirical Comparison of Pie vs. Linear Menus (Published at AMC CHI '88):
The Design and Implementation of Pie Menus: They’re Fast, Easy, and Self-Revealing.
(Originally published in Dr. Dobb’s Journal, Dec. 1991, User Interface Issue, cover article.)
Of course not all pie menu implementations support all the useful features, and some "ersatz pie menus" are really horrible because they are not designed to respect Fitts' Law, and only copy the surface features (like being round) without any of the essential properties or advanced features:
- popping up centered on the cursor, which starts out in the inactive center
- large pie slice shaped target regions extending to the screen edge, instead of only selecting items by clicking on their small labels
- delimiting item and submenu selection with mouse clicks, not distance of motion or pausing motion
- never introducing mandatory pauses and waits, or requiring you to always engage in a visual feedback loop, looking at the screen and moving the mouse and waiting until you see something before continuing (but that should always be possible if you don't mouse ahead)
- click-move-click as well as down-swipe-up gestures
- reliable, dependable mouse-ahead, even when the computer is lagging behind and freezing
- submenu navigation, back to parent menu, cancel all menus
- re-selection and browsing
- pop-up display pre-emption (don't pop up the menu window until the user stops moving the mouse, or releases the button to click up the menu even without pausing)
- real time live feedback hooks so the application can preview the effects of the direction/distance selection that you would get if you released the button
- live feedback before popping up the menu, so the popup menu doesn't overlap the thing you're editing with the menu
- live tooltip or overlay label and description feedback during gestures, and hiding or dimming labels on unselected items
- overflow linear target based items (to support greater than 8 items), laid out below like a drop-down menu, or in any other direction: up, left, right, diagonal, or custom layouts.
- instead of pies directly containing some number of items (which makes it hard to visualize the changing directions when adding and removing items), pies contain a fixed number of slices as independent containers of items, which define the directional layout before adding any items, and support empty slices (like a dummy no-op, to fill out a shameful 7 item menu to glorious 8), and slices with multiple items (with a linear layout showing all items in the slice, or a "pull-out" combobox showing one at a time as you move further out, like font size, etc)
- user defined and dynamically editable pie menus, submenus, items, and other user interface widgets, like the Blender pie menu editor does so well. Blender Add-on Review: Pie Menu Editor: https://www.youtube.com/watch?v=cQWwbBFQPrY
Usually people who design and implement "ersatz pie menus" make mistakes or omissions because they don't know better, don't have enough time or resources, haven't used pie menus themselves, or haven't studied Fitts' Law.
But unfortunately enough, there are actually people who purposefully implement crippled straw-man pie menus, even though they know better, just to acquire illegitimate software patents and spread FUD about pie menus.
Here is an example of a purposefully crippled design of pie menus that Gordon Kurtenbach implemented and published and claimed to be "typical", presumably in order to support false claims in an illegitimate patent on marking menus that he and Bill Buxton were granted, which has inhibited their adoption by making many companies and people afraid of using either marking menus or pie menus.
This video incorrectly labels them "Typical Radial Menus", but they are definitely not -- it's like they're designed to be as obnoxious and unusable as possible, aggressively triggering unsolicited submenus after you've only moved a small distance and before you've even clicked.
Demo of Marking Menus: A demonstration of the differences between marking menus, linear menus, and pie menus is shown. Shows the "marking" property of marking menus and the property of scale independence. By Gordon Kurtenbach.
>Don Hopkins, 10 years ago:
These "typical pie menus" are not at all typical -- they're just "straw man pie menus". Typical pie menus (like the pie menus in The Sims) don't behave the way this straw man implementation demonstrates, and don't suffer from the disadvantages demonstrated here. Typical pie menus support "mouse ahead" gestures and scale independence, and it's disappointing that the authors of this video weren't aware of that, and attempt to define marking menus in terms of a straw man definition of pie menus.
Unfortunately in another 10 year old discussion I recently ran across about "Crowd funding project: Marking menus for Photoshop and other software," someone watched and cited that deceptive video, and was mistakenly convinced that "Pie menus are infinitely less powerful than Marking Menus, and absolutely not the same thing."
That's why I believe the whole point of that video with terribly designed fake "Typical Radial Menus" was to deceptively promote patented marking menus instead, and that all the FUD they spread has prevented companies like Adobe from using them in their products.
There is some difference, but it's not anything like that video misrepresents. The Wikipedia page on pie menus gets it right: "A marking menu is a variant of this technique that makes the menu less sensitive to variance in gesture size." And "a mouse click could be used to trigger an item or submenu". Nowhere does it mention triggering submenus without mouse clicks.
Parroted FUD> Pie menus are infinitely less powerful than Marking Menus, and absolutely not the same thing. Where Marking Menus shine is in submenus, which I find to be cumbersome in regular pie menus (which is why my favourite implementations of pie menus eg. in Modo is without submenus).
I wrote a detailed reply to that parroted FUD, including copies the email between Gordon and I from December 1990, proving that I meticulously explained to Gordon how pie menus, submenus, mouse ahead, and tracking all worked together, more than a decade before he made that video, so he certainly did known better, and his video was purposefully deceptive, and his patent and FUD has held back progress and hurt users.
(You can see the comment and read my full reply and all the email from 1990 explaining pie menus to Gordon at the end of the link above.)
The Fitt's Law benefits decrease with the distance you have to travel to reach the bar, though. It always takes me several gestures on mouse or trackpad to reach the top bar on modern display resolutions. Better to just have good accelerator keys (not that any of the major desktops seem to do that in a discoverable way).
> It always takes me several gestures on mouse or trackpad to reach the top bar on modern display resolutions
First, resolution should have nothing to do with this. Second, even on the largest 4K display that I have, and assuming that you have a mouse curve with acceleration, I only have to thrust the mouse for about 1-2cm of physical distance in order to reach the opposite edge of the screen.
If you are moving the mouse ultra slowly to the edge, then yes, it may take a while to reach it. But the entire point of Fitt's law is that you just thrust the mouse towards that edge as fast as you can since you're not going to overtake it.
Some people do not use acceleration (but one can argue that they are in a minority). I was pro acceleration until I bought a steelseries pad with an aluminum legs mouse. A home tech that never migrated to my workplace so quickly.
Fitt's Law says ease of use is a function of size and travel distance. Items on the edge of the screen have "infinite" size, so they're "infinitely" usable (according to fitts law)
Some might say that swiping across a screen edge would be an application of Fitt's Law.
These gestures are used extensively on Windows on tablets, and has been on WebOS and Blackberry 10. (Not that Windows' laggy implementation isn't more infuriating than useful IMHO ...)
It's about target size and distance, not screen edge limits on motion, or relative motion -vs- absolute position input devices.
The "infinite height menu bar" design uses screen edges to make the target size effectively "infinite", but it doesn't minimize the distance, and doesn't exploit any direction but "up".
FWIW, Windows does let you place the task bar on any edge of the screen though, but you still can't have four task bars, one on each screen edge!
The screen edge limits of mouse movement only apply to input devices like mice and track pads (motion sensitive), but not touch screens (position sensitive), because touch screens are position sensitive input devices, and your finger position is directly tied to the cursor position, so you can't move the cursor without moving your finger or vice-verse.
This is related to the "nulling problem" that Bill Buxton wrote about in his taxonomy of input devices, "Lexical and Pragmatic Considerations of Input Structures":
>One consequence of the second philosophy is that the same transducer must be made to control different functions, or parameters, at different times. This context switching introduces something known as the nulling problem. The point which we are going to make is that this problem can be completely avoided if the transducer in question is motion rather than position sensitive. Let us see why.
>Imagine that you have a sliding potentiometer which controls parameter A. Both the potentiometer and the parameter are at their minimum values. You then raise A to its maximum value by pushing up the position of the potentiometer's handle. You now want to change the value of parameter B. Before you can do so using the same potentiometer, the handle of the potentiometer must be repositioned to a position corresponding to the current value of parameter B. The necessity of having to perform this normalizing function is the nulling problem.
>Contrast the difficulty of performing the above interaction using a position-sensitive device with the ease of doing so using one which senses motion. If a thumb-wheel or a treadmill-like device was used, the moment that the transducer is connected to the parameter it can be used to "push" the value up or "pull" it down. Furthermore, the same transducer can be used to simultaneously change the value of a group of parameters, all of whose instantaneous values are different.
>Relative vs Absolute Controllers:
One of the most important characteristics of input devices is whether they sense absolute or
relative values. This has a very strong effect on the nature of the dialogues that the system can
support with any degree of fluency. As we have seen, a mouse cannot be used to digitize map
coordinates, or trace a drawing because it does not sense absolute position. Another example
taken from process control is discussed in the reading by Buxton (1986a). This is the case of
what is known as the nulling problem which is introduced when absolute transducers are used in
designs where one controller is used for different tasks at different times.
Most people around world use small laptop screens, where having a top bar bad from fitt's law. Having infinite large window buttons (that are used often) on the top right corner is great and window menu/start button at bottom left corner.
Indeed, although I use macs daily for over a decade now, the whole "consistent" placement of the app menu at the top of the screen has struck me as idiotic from day 1. On a 27 inch iMac it was already a nuisance, on a 43 inch wide monitor it is downright silly. My preference would be to make it a setting, as I can see there are cases where it does make sense, e.g. multi windowed application with palette windows and such, if one so prefers.
It was ok in 1984 on the very first Mac with a sub 7" screen. It felt out of place on later models with normal sized monitors (normal for those times.) I never liked the Mac UI because of that menu thing and I configured my way out of it in the Ubuntu GUIs in the 10s.
...and when that menu bar was a primary interaction element of almost every application you'd use. These days, that seems to be more exception than the norm.
It feels weird while you are not accustomed to it but after some times it feelw the only reasonable way. I felt this when switching from XFCE to Unity.
I felt the same about hard disks naming when switching from Windows to Linux - lack of drive letters felt weird but now it feels great.
It was never even intended to be used in a scenario where you have multiple application windows. When that UI was first introduced, you could have multiple windows per application, but only one application could run at a time. The behavior of having the menu bar scoped to the screen and the application not quitting when all windows were closed makes a lot of sense in that context.
No. Searching in the current app menus. Because they are centralized and don’t have their own comportement. In MacOS you can activate the search in menus keyboard shortcut in any app, giving you a Sublime/VSCode-like command palette in any app.
>Fly-Pie is an attractive marking menu for GNOME Shell. Fly-Pie 10 brings improved touch support, a new clipboard menu and a bunch of other new features!
I highly prefer the Mac's Menu Bar at the top of the screen when using a mouse, and I agree with the Fitt's Law arguments.
However, I am also highly keyboard centric.
So in the case of the top menu, I recommend Menuwhere by ManyTricks. It allows you to assign a mouse click to popup a copy of the current applications menu under your mouse. And you can assign a keyboard shortcut to activate this menu and then navigate the menus by key
While we can make lots of arguments around about Fitt's Law and what is the ultimate computer UI, much of it comes down to individual preference. I personally find the Mac's GUI to be an ideal environment because Apple provides both a good basic set of global keyboard shortcuts. MORE IMPORTANTLY macOs has great API's to allow other tools to be built to bend macOS to my personal style developed over 40 years of computing. Naturally, you will have other preferences.
(On macOS I also use LaunchBar and Keyboard Maestro among other apps to make my Mac as keyboard focused. On Windows I am a heavy AutoHotKeys user. And on Linux, well it is mostly CLI)
The point of border menus is that they are virtually infinitely high, meaning they’re easy to hit because you only need to aim at the horizontal position.
With a pointer maybe, it's great with a keyboard though, ^F2 and or Cmd-? and you have every menu item to hand. Best past is even apps like Excel Mac have proper menus, which are missing from the Windows version. And with the Mac style menus aren't constrained by app window size or duplicated across them.
The top menu bar is a waste of screen real estate, even on a Mac - an outdated 1980s concept that was cool back in the day, but no longer (alongside the single button mouse).
If you auto hide it, it becomes troublesome to click on browser tabs as a slight error on pointing to the new tab will make the bar appear and push everything down. I understand that many people like the macOS UI concept, but I find standard Windows far superior, allowing more screen real estate especially on small screens. Same comment applies to the icons on the bottom bar further wasting my screen's limited height (although that can be customized).
My main work computer is a M1 Macbook Pro and I'd LOVE to be able to simply use Windows/Linux for better productivity.
I always liked the RISC OS way of doing it where there was a mouse button dedicated to bring up the menu for the current app. There's no need to show the menu unless someone is trying to interact with it.
It's useful because it is showing important stuff like clock, battery and keyboard layout. And if you are already using this space, you can also fit the program menu there and save some space.
I agree about the app icons. Moving them to the left is the first thing I do on any Mac I'm using.
Huh, thats why I always autohide menu bar and move it to the left side of screen. This way I will not open it accidentally while scrolling or by clicking on title bar/tabs of windows.
Or you do it the Gnome way and have a thin top bar all the time but hide the dock and use the keyboard most of the time for opening and switching apps.
Auto-hide/reveal is worse. It's a dead zone where you can't have interactive elements, because it's too hard to get the pointer on top without triggering the bar.
This brings back some fond memories of experimenting with many alternative shells including LiteStep. I remember being able to run Windows XP + LiteStep + Chromium + PuTTy as my daily driver on a refurbished laptop with 256MB of RAM during my student days. Truly the glory days.
I've never been happier with an OS than I was with Windows 7, a very minimal LiteStep setup, Launchy, VistaSwitcher and Everything. Small system tray and task icons down the left of the screen, leaving all the rest of the space for applications.
Last time I looked at Gnome I could kind of almost set it up like that, but there was still too much stuff on screen.
The only major problem I have with Gnome are the memory usage and the sheer size of the default adwaita title windows. I understand that in a context that gnome also works very well with a touch screen/tablet but in a desktop context so much space is wasted by those titles.
Using stardock software like windowblinds was a lot of fun as a child. Thinking back at their software today as a software developer it was pretty incredible how much customizable it was.
It would be fun to do a deep dive into their software today. There must be something to learn when it comes to creating customizable gui themes.
They are a games company as well. I often feel non-game software made by game developers have some sort of quality and personality that you often can't find elsewhere.
It really depends on when. If we're talking Win9x-XP, shells could do everything, and Explorer wasn't really special. From Vista onwards, things started to get "more special", and Win8+ especially killed many old extensibility points.
Curious why you feel that way, when they were all generally cloned linux shells [sic] anyway? eg: blackbox <> openbox (now xoblite), or litestep <> afterstep/nextstep?
I guess it was a bit more punk to break windows, from some perspectives.
Nostalgic to visit the LiteStep website, looks largely unchanged from when I stumbled across it probably circa 2003. I always enjoyed the crispness of the menu chrome and icons from what I always associated with a "BeOS style".
I think I might be a bit of a strange user. I have all of my icons hidden, a solid black background and the task bar in the right side of the most right display. I lunch my programs with Launchy, a long dead program, but somehow still works the fastest out of any alternative and I really appreciate the calculator function of it. Must used stuff is pinned to the taskbar, that includes VS Code, Explorer, GnuCash, browser links set to open as individual windows for Gmail, Google Calendar, Discord, Facebook messenger and same configuration but linked to MS Edge for another instance of Discord but with a different account.
On my main monitor I don't have any bars or anything, if there nothing open it's just a black screen, if it's sunny, sometimes I can't even tell if the display us turned on and that's how I like it.
Microsoft PowerToys also contain a new neat launcher called "PowerToys Run" which is similar to Launchy. It supports various plugins including Calculator.
I like the feature that it shows up on the display where the mouse pointer is currently located so you don't have to jump between displays.
Love powertoys. I started using it for being able to define screen areas to snap windows to "FancyZones" but once I started using PowerToys Run, I was hooked. I almost never use the start bar (or calculator) anymore. In addition to starting your apps, it also can do calculations, execute shell commans, web searches, find open windows, etc.
It also include a mouse / click highlighter that's helpful when you're recording a training / onscreen presentation.
> I have all of my icons hidden, a solid black background and the task bar in the right side of the most right display.
I do the same and I rarely click on the Start menu or the task bar, I use Super + [1-4] to launch the pinned programs or switch focus to their windows if they are already running. For other programs I press Super on my keyboard and type the name of the program I want to launch.
My pinned programs are Browser, Text Editor, File Explorer, Collaboration app at work and Browser, Discord, File Explorer, Steam at home.
I'm on Linux but I have a similar setup, with no permanent UI elements at all - I have a script to show a notification with the time and remaining battery (on laptop) and so on that I run when I need to see that info. I use a tiling window manager, three monitors and heavy usage of workspaces.
An other macOS-like custom theme for Microsoft Windows?
As both macOS and Windows user, I would like to minimize the task bar, menu bar height as small as possible, to maximize the display area of current using app. I prefer access to the apps, windows by keyboard as much as possible, because I feel it's quicker than click to icon or access through mouse.
One habit which I've dropped is changing wallpaper. I hadn't seen and didn't care about my wallpaper for a long time ago. There is always one window display on my computer. If I leave my desk, just lock it and unlock when I back.
I even hide the menu bar on my Mac so every window always is as fullscreen as a window can be and I have never looked back. When I want someting from the menubar I need to move the mouse there anyways.
The only nitpick is, when having an external monitor set to be above the MacBook's one, simply jamming your mouse up to the top won't reveal the menubar as easy and you need to move it exactly to the screen top. Also I don't know how that approach would work with the new MacBooks with a notch.
When I used windows I always stuck the taskbar to the side since you can generally give up a bit of horizontal estate on widescreen monitors.
That was a time when I only had one monitor though, so perhaps that would be more annoying than not with two depending on the side you wanted to put it on.
One of the last few projects which still support modern windows releases. I hope we'll get a revival of alternative shells for both windows and macos one day.
I remember trying out many alternatives on win2k and that one needed much fewer fixes...
These customization efforts will likely continue to break and frustrate devs into giving up in future updates because proprietary OS vendors like Microsoft and Apple are simply not motivated to allow people to get in the way of their regular overhauls of their preferred brand experience.
If you want wide customization of an OS, an open source OS is likely a more maintainable choice.
So every modern graphical linux distro has it's own GUI implementation of it for FVWM? Or without sarcasm, it's a Window Manager problem in X, and my google-fu says FVWM doesn't support this feature.
I was an author for a couple of alternative desktop shells for Windows 9x.
I think Windows 95 was the first time I encountered support changing the desktop shell (then via the ‘shell’ property in one of Windows’ ini files). I remember some of the main uses cases were:
1. Restoring the Windows 3.x progman (Program Manager) shell
2. Bespoke UIs for educational systems in schools and colleges
3. Bespoke UIs for locked down graphical terminals, like kiosks.
The shells I wrote were purely aimed at families though. Designed to make the single user OS a little more like a multi user platform. Windows 95 was pretty terrible when it came to different family members using the same computer.
It was fun times but I honestly don’t miss Windows 9x one but.
Being able to replace the shell is actually possible since 3.x, also using the method you described. It was fun using Calmira to make win 3.x look like 9x.
Cool, that still exists. Some years ago I was into all that desktop customization and tried this, LiteStep [0] and Blackbox/bb4win [1] but ended up with BlackBox.
Nowadays, all the customization I need is a tool to fix the taskbar position that someone who probably uses a portrait mode monitor moved to the wrong spot [2] and a launcher [3]
MS PowerToys also feature a launcher and a couple of nice features like mouse cursor highlight on shake and window zones which make 4k portrait mode monitors somewhat usable.
Used bb4win (bbmean afair) till 2012 I guess, but then it was not developed and not coupled well with Win 7/8 probably, so I came back to Explorer. Nowadays on Win11 I'd probably won't need bb4win anymore.
I don't think so, the Aero look and feel was out (in Longhorn betas) way before KDE4 came to be... But perhaps the Windows 7 look was influenced by it.
However, the current look of KDE - which is much more like Aero - is very recent, at least post Windows 8. KDE4 as it was at the beginning didn't look like Aero that much IMHO.
I've been using Flow Launcher on Windows and it's good but doesn't pick up some programs im looking for, I'll check out key-pirranah - maybe it can have better results. I like the idea of "Associate a Keyword to an Item"
You cannot change that UI toolkit an existing application uses. Only change the theming if that toolkit supports theming, and change the desktop shell.
I think they’re referring to the fact that, within the system apps that Microsoft controls, there are multiple generations of UI design. Like, last I checked I think Device Manager still has a Windows 98-ish look (there are many others).
These also correspond to different UI frameworks. You can change between themed and unthemed Win32 apps (although doing so can break layout, since themed widgets may have different sizes). But you can't easily change from Win32 to "modern", which is where the main disconnect is.
(Device Manager is a themed Win32 app. I actually can't think of any piece of Win10+ that isn't themed.)
It hasn't been supported in a sense that there's no checkbox in OS settings to enable it for all apps. But any Win32 app that doesn't declare itself as compatible with theming (either via the manifest or via an API call) will still get the old slate grey 3D widgets, and even the old UI font.
(It has to work that way for backwards compatibility reasons, since some very old apps make assumptions about how exactly the widgets are rendered in their static UI layouts.)
Similar but not identical. The different Windows UI toolkits have slight nuances that are sometimes only noticeable if you’re looking but sometimes stand out.
I got that. But the reason it looks different is because it’s literally different APIs drawing the widgets. You cannot “fix” those programs to use the same APIs without access to the source code. And clearly 3rd party desktop shells are not going to have access to the source of Microsoft Windows.
That’s not a KDE thing, it’s a Qt and GTK thing. Those toolkits support themes and all you’re doing in KDE is specifying a two different themes (albeit named the same) that is visually similar. However if you look closer at the widgets you’ll notice how theming on Qt and GTK differ, so even the “same” theme across those two toolkits will look and behave subtly different.
It can do that because Gtk allows for custom themes, so it's possible to make one that looks like Qt. The opposite - making Qt look like a Gtk theme - is also possible.
But Windows deprecated support for user-configurable themes ages ago, and none of the new frameworks have it.
If it continues to work on new versions of Windows as they are released, it would be liberating to keep the same desktop interface even after an upgrade of Windows, instead of being subjected to whatever whim of the day they cook up (half-made) in Redmond.
That's not even possible in theory. If my app uses half system controls and half custom-drawn controls that I have painstakingly made to look like (I expected) the system controls to look, then if you swap out the system controls now you made the app inconsistent internally, which is just worse.
Windows has some consistency flaws, e.g. how they can't make their own settings have a consistent UI, but releasing more toolkits with different looks can't change how past ones look, it's just not possible.
Having apps being consistent internally is the best you can hope for, and that obviously is the same for Linux/MacOS as well.
More than likely, the majority of your eye's focus is spent in the top half of your screen, for me having the start bar at the top is very natural. If you haven't, I'd give it a try. Having said that, user choice is sacrosanct.
I've personally put my monitor on a thick book (about CS foundation, fittingly enough) so that most of the time, I'm naturally looking at the middle of the screen where, incredibly, most of the useful stuff actually is. In any case, for me the start bar is mostly useless.
I think I do mostly look at the top half of the screen, but I somehow reach a different conclusion from you :)
There's nothing interesting on the taskbar, so it makes sense to keep it down there. The most commonly used programs like Firefox, IDE, Slack are pinned to the taskbar, so I can invoke them with Win+[1-3]. When multitasking in full screen, there's Alt+Tab. Overall, I feel like the taskbar doesn't have that much use most of the time, but it's nice to have it on the screen just so I can use it as "shortcut cheatsheet".
I have a UW monitor. The correct position of the taskbar for me is vertical on the right side of the screen. And to occupy as little space as possible, here is how it actually looks
Kind of, yes. But I don't remember the project being open source when it started. Then there was a long time without any progress and since a few years it seems slightly active again ...
These kind of things, litestep, Cygwin...they are embarrassing things that most of us had they in the past.
The road is difficult, now I am a normal user of GNU/Linux, but when I started this road, this kind of embarrasing things was my crutch or walking stick. The last step is the laptop/computer has only a partition with GNU/Linux, when it happens, you walked the more diffult part of road.
Well, I mean that yes this projects are embarrasing, but they are good and they help a lot people (include me). Thanks embarrasing projects.
Thank you for sharing! I've been in love with LiteStep but it's not had any development on it in years - seems to have died. Hoping this will be a good-enough replacement for me.
What is the RAM usage like? I don't know how themes work for windows, or is this directly modifying the GUI? Is this an application which needs to be running to display this theme?
At one point I experimented with using this to turn the Hyper-V Server version of Windows (i.e. the free one with no desktop to speak of, intended purely to run as a hypervisor) into a desktop OS. It did indeed work as a desktop... but unfortunately there was so much else gutted out of that version of Windows that I gave up and went with Windows 10 LTSC.
Yep Talisman! I received a shareware copy of it on a magazine CD. Totally blown away by the true color UI and pre-arranged widget bits here and there. The thing's born in the 9X era but rocks a definite XP vibe.
I like the top bar and the neat bottom one. But I prefer having more space on the screen. I have an AutoHotkey script to show task bar only on key press so it's not toggle by accident. Then it's always fullscreen-like experience.
Yeesh I’m getting some Rainmeter/Stardock PTSD. If you're into this interior decorating and don't need Windows, Linux will blow your mind.
In high school, if you had one of these tacked on Windows UI things, you were likely the kid who took the Apple sticker that came with your iPod nano and slapped it on your Windows laptop.
Sorry for asking, but am I right that this project has no relation whatsoever with the well-established Cairo library, which has been around for almost 20 years?
If so, it would be a pretty terrible choice of name for a project with a focus on something that's visual (an alternative Windows desktop), given that cairolib is a graphics lib. I, for one, have been rather confused.
How about not choosing a project name in relation to a well-established city in egypt? /s
Like the space for project names is pretty much overloaded multiple times already. Unless we start to use funny words of the dictionary like 'carbuncle'.
