OSDev.org

A thought occurring in the Microkernel design info thread made me curious about one thing: What do you consider a "best feature" in a GUI, what a "most annoying", and what qualifies as an "unnecessary CPU hog" in your book? Just give one example for each; I'm curious about opinions.

My vote for "unnecessary CPU hog": In Windows today, a "mouse over" is sent to an application window even if it's not active. If you drag your mouse pointer over the Outlook window, it changes to no less than nine different pointer graphics depending on what gadget it hovers over... even while the window doesn't have the focus at all! I don't want to picture how much messaging is involved there. In my book, if a window isn't active, it isn't active, except for redraws, and it certainly shouldn't receive messages.

Or do you think this a really valuable feature?

My vote for "best feature": In AmigaOS of golden times, an application was shipped with "catalogs": files containing all strings displayed by the application. The application binary contained placeholders, and relied on the locale.library to replace the placeholders with strings from the catalog matching the user's locale settings. (A default, usually English, was hard-coded into the app.) All you needed to localize an application to a different language was taking an existing catalog (the default one could be extracted from the app), and translate it. There were catalogs to be found on the internet localizing popular applications to more languages than the app designers even knew existed. That was a neat feature... and no binary patches "for US version only" etc...

Or do you think there's a better way to do it?

My vote for "most annoying": Anything stealing the focus from the window I'm working in. Anything. I don't care if I got new mail if it messes with my freehand drawing. So what if Word finally starts up when I'm busy mine-sweeping. I can't think of a single reason why focus should be taken away from where I had put it. If there are important messages, give a beep, or display them in a separate area of the desktop, but don't take away my focus.

Or can you think of a good reason?

My vote for Cpu-Hog: in so many 'modern' window manager, the manager tries very very hard to keep a window displayed while moving/resizing the window. Old managers simply draw borders or things alike. As a result, the hidden windows behind what you redraw get tons of message asking to redraw small horizontal/vertical bars at each mouse movement. That's not simply eating CPU without reasons, that's also awful to watch.

My vote for killer feature: A scriptable engine to collect those 'progress/notification/whatever' dialog windows so that i can check a small and quiet location of my desktop and see all the download in progress there rather than having 20 iconified "...% compl..." buttons in a task bar ...

Good feature: (yes, to my unfortunate mind, this has been thought up in windows) being able to kick applications you dont want to see to a system-tray like position, where it is very small but always noticed. Of course windows doesn't apply this properly.

The idea is that when I tell the computer to do X I should be able to ignore the entire result of X until the time I want to look at it. I don't want it to clutter up my task bar either, so let it begone to a corner of the screen. Example of a program that understands this is Winamp, when my music is playing I don't give a **** what the program does. Just get lost & keep playing it. Nero should have something similar when burning cd's, just dunk it away.

Good feature: Tooltips. Not those that explain what the text that is there is for, those that give more info on the subject. Examples are abbreviations with a tooltip of the full name, taskbar icons with a tooltip of the opened document plus possibly info about that, tooltip over winamp telling me what it's playing, tooltip over time box that tells me the date, tooltip on my virus scanner that reports how it's doing, etc etc etc.

Focus-stealing popups I don't like any application coming along with popups just announcing that something's been done, where a simple and decent notification like an icon showing up in the toolbar suffices.

redrawing the whole screen when the active window is moved around or resized. The active window has to be drawn and kept separately, so nothing shall be clipped against it. So, you only deal with it and redrawing of other windows happens only either in case of content change or in case of activating another window.

and Solar, you are right: only the active window shall be notified of mouse events like mouse over, mouse out and so forth.

Window moving, WIndow resizing althou' Pype is right, it simply looks cool, if the whole window moves around. But thi shall not affect the underlying area, only the window itself. That's why the gui handling in my own os is split in two. One high priority "driver" which does the mouse and window moving/resizing stuff, and the gui service, which is responsible for all the other things.

tons of events do not only lag the system but the application too, because - imagine - all the times fetching the next event just to find it is junk slows down. Well, actually, it keeps the gui-eventhandling thread busy.

multithreaded UI library This one is simply a must have. NO sense in having the application itself spinning around polling for events, if the UI thread can simply fetch events and trigger the required actions - even waking up the main thread and telling it what to do ere fetching the next event. Short call paths in the event handling subsystem are always a good thing (tm).

less is more No one needs that kind of cpu cycles eating eye candy like fading in menues or animated minimizing of windows.

Pype.Clicker wrote: As a result, the hidden windows behind what you redraw get tons of message asking to redraw small horizontal/vertical bars at each mouse movement.

You could take a different approach:

1) Buffer window bitmaps in memory. If windows move, the window manager assembles a new picture from the memory buffers.

2) If window contents change, the applications (which are scheduled anyway or their window contents wouldn't change) update their window bitmap.

That way, you don't have to pass messages or schedule apps.

(Just from the top of my head, and remembering AmigaOS "SuperBitmap" window mode...)

Best features yet to be seen in a mainstream OS: Live text and fade-through warnings. Both of these get mentioned (though not under those names) in Raskin's Humane Interface; live text is also one of the key design features of Oberon. Live text is the ability to select an arbitrary section of text - any text, anywhere - and run it as a program call. The entire user interface in Oberon is nothing more than text windows; menus are literally just windows with a list of function names. An elegant solution to the console/GUI dichotomy.

Fade-through alerts are a part of Raskin's solution to the focus loss problem, and particularly to the problem of issuing warnings without forcing the user to acknowledge it when there are no choices to be selected from. A fade-through warning is one which is itself translucent, and slowly fades away; focus is not altered, and the current window is not completely obscured, so the user's current action is not directly interfered with, but the warning is visible enough that the user is unlikely to miss it. This technique can be seen in game design (especially cockpit simulators), where it's been used it for years to considerable effect.

Schol-R-LEA wrote: Fade-through alerts...

...sound like a really nice idea, until you realize they're basically an alpha-blending animation...

My idea of unobstrusive alerts is some configurable combination of "ping", screen flashing (screen shortly changing color), and a permanent "message window" (which could also hold Pype's progress bars). Same effect (make alerts visible but non-blocking), less CPU cycles to spend. (And what do your fade-through alerts do if there're lots of them? )

And what about small noification buttons/widgets appearing in some corner of the screen (of course always on top) and behaving according to the severity of the notification?

slowly blinking for alert, stay calm for notification and so forth? and if the user clicks on such a widget, some explanation pops up and then the widget disappears?

And if there are more of them, why not hide the list of them behind the first one and expand them upon clicked event?

beyond infinity wrote: And what about small noification buttons/widgets appearing in some corner of the screen (of course always on top) and behaving according to the severity of the notification?

slowly blinking for alert, stay calm for notification and so forth? and if the user clicks on such a widget, some explanation pops up and then the widget disappears?

And if there are more of them, why not hide the list of them behind the first one and expand them upon clicked event?

I saw the notification thing in my mind as a split-screen Linux computer, where 90% of the screen was used (the top) for normal stuff, and important and less important messages flowed across the bottom terminal-style. Of course, with scrolling & history. Nowadays I'd kick the idea of a terminal out, but having a permanent section of the screen reserved (say, a nice pad on the lower hand side above the default clock location) for notifications seems a good idea. Make it a nice light background color, avoid overlap with applications (always-on-top style, or shrink the available screen space). Then, allow people to set the importance and treatment of warnings/errors/criticals.

I detest applications such as MSes MSN messenger. They steal your keyboard focus at any time without warning to a network-connected box that sends upon enter. I've had at least two occasions where I sent out half my password to some **** that happened to time it right.

@candy: isn't it possible to teach such applications not to do this evil thing? Some registry entry?

beyond infinity wrote: @candy: isn't it possible to teach such applications not to do this evil thing? Some registry entry?

nope... They just do something similar to a VB's SetFocus which just steals the focus from whatever had it. My current solution is to use a different client (miranda) which doesn't auto-open windows.

Solar wrote: You could take a different approach:

1) Buffer window bitmaps in memory. If windows move, the window manager assembles a new picture from the memory buffers.

2) If window contents change, the applications (which are scheduled anyway or their window contents wouldn't change) update their window bitmap.

That way, you don't have to pass messages or schedule apps.

(Just from the top of my head, and remembering AmigaOS "SuperBitmap" window mode...)

Because the most likely bitmap that's going to change is the currently active one, and since you don't display those on the background that are covered, make two bitmaps, one of the current window and one of the background. If a window wishes to draw to a place that isn't on either, don't do the draw at all. If it's on one of them, draw it.

Upon movement of window, plot the top bitmap on a different location on the bottom one, and replace with pieces from the bottom one.

Upon changing the top window (by closing the top one, or clicking on a different one), request that window to be drawn on top, place the current top one on the background (just draw at the current place) and then request updates for the areas covered by the old one, but not by the new one. This sends very few messages to get the same result. Nice idea?

My vote for "unnecessary CPU hog": In Windows today, a "mouse over" is sent to an application window even if it's not active. If you drag your mouse pointer over the Outlook window, it changes to no less than nine different pointer graphics depending on what gadget it hovers over... even while the window doesn't have the focus at all! I don't want to picture how much messaging is involved there. In my book, if a window isn't active, it isn't active, except for redraws, and it certainly shouldn't receive messages.

I disagree with this one based on problems I've seen with n00bs like my Mom. Sometimes it helps to highlight menu items or toolbar buttons on mouse-over, whether the window is active or not, because the user wants to click on that window but might not see clearly what they'd be clicking on (important consideration for older users with less-than-perfect eyesight).

Then again, maybe this is an argument for switching focus on mouse-over (?).

I personally hate the focus changing when i move the mouse over another window but having the cursor change can be very helpful. not only for less computer literate people but in other areas as well. when i want to resize a window that doesn't have focus, i like to see my cursor change to reflect the resize handles being hovered over. or when i move my cursor over an unfocused web browser it is nice to see a hand when there is a link to follow or an "I" when there is a text field, etc...

The idea here is that a window that is not the active one is inactive: You can't resize it, you can't click on a link - and you can't activate any of its features by accident when you click on it to activate it.

I know that sounds alien. I suggest using Amiga Workbench for a while to get the feeling...