GUI design - must-have's and CPU hogs

[srg]

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...

I never noticed any difference between windows and AmigaOS. It's been a long time, is the only way to activate a Window in AmigaOS to click on the toolbar? BTW I liked the Workbench 3.0 windows, they were nice and did the job, I may implements something like that for mine when I get to that position.

srg

[mystran]

Indeed, my favourite CPU hog would likewise be window manager trying to keep content when resizing. Moving is ok, since with a proper backing store it's not THAT slow, but resize is a hell, since almost every app needs to do layout recalculation, bitmap scaling and the like when one resizes a window.

My favourite usability killer is window manager which does not allow one to move/resize a window from anywhere, but instead requires one to move mouse to some stupid and small position instead. See evilwm on how to do this properly.

My favourite brain-damage is any API which requires one to move around variable-length amounts of data, but either silently truncates too long data, or does not provide a clean way to retry with bigger buffers.

My favourite kill-me-slowly are API's which require one to use several threads for things like doing async-IO or GUI or whatever. Yes, it's nice if the API is thread-safe, but I think it's less bad to require the application to take care of synchronization if it wants to, than it is to require every application using the API to be completely thread-safe.

My favourite I-have-enough-to-do-thank-you is any API which requires me to write tons and tons of stupid stock-code to do the single (and simple) thing that one would imagine people to use the API for. For examples of this, look at X Input Methods (XIM) or libpng.

And finally, my favourite so-long-and-thank-you-for-the-fish is any system which can lead to undefined behaviour in course of perfectly normal operation.

[Solar]

I never noticed any difference between windows and AmigaOS.

:O

It's been a long time, is the only way to activate a Window in AmigaOS to click on the toolbar?

Obviously it's been a long time... as there is no toolbar in AmigaOS. You activate windows by clicking on them somewhere. (And they aren't raised to top even when active, which allows typing in a half-covered text editor while looking at a PDF for reference, for example.)

Focus-follows-mouse and raise-on-doubleclick were available as options ("commodities"), though.

[chris]

My favourite brain-damage is any API which requires one to move around variable-length amounts of data, but either silently truncates too long data, or does not provide a clean way to retry with bigger buffers.

First thing that comes to mind: ioctl(sockfd, SIOCGIFCONF, &ifc)

[srg]

Oops I meant titlebar :-[

I don't remember the windows not comming up to the top when you click on them. (I do have WinUAE with legal ROMS and WB3 but I've lost my license key to install it all).

So please remind me, what did you do to activate and then raise a window to the top.

sorry

srg

[Solar]

So please remind me, what did you do to activate and then raise a window to the top.

Activation by click, as I said.

Each window had a "depth gadget" which allowed raising or dropping it one "level". I.e., raising the bottommost window to the second bottommost window. As I mentioned, tools were available to configure top-on-doubleclick, back-on-click-with.
-shift etc. etc.

As for WinUAE... did I understand correct that you own Amiga Forever but lost the serial number?

[bkilgore]

One thing that I have always wished that Windows would support is moving around things in the start bar. Basically, the same functionality they have in the QuickLaunch toolbar, but for the main application buttons as well as the system tray icons. I never understood why I would have to open program A before program B (or even worse, if B was already open, close it, then open A, then B again) just to get the toolbar icon for program A to come before B. Lots of times, if i have more programs open than will fit, i will find myself dreaming of a better world where I can move the programs i'm currently using onto the same "page" of buttons, especially if i keep switching between a few programs a lot that are on different pages. M$ supports drag-and-drop everywhere else, I dont see why the toolbar and system tray should be any different.

[srg]

So please remind me, what did you do to activate and then raise a window to the top.

As for WinUAE... did I understand correct that you own Amiga Forever but lost the serial number?

Spot on...

UPDATE I've just found out how to get it back.

ahh I see what you mean now. I think I shall have to do some major refamiliarising . The last time I had it running, I managed to get Final Writer 5 from ebay and using a special DOS program, make disk images. It installed perfectly (shame the CatWeasle only works on linux, although I have a linux machine). I did also get Deluxe Paint 4 AGA but it doesn't seem to like WinUAE.

BTW I remember getting Final Writer 5 for my birthday for my real amiga but having to wait another 2 months will christmas to get the expansion card to run it (FW5 requires 6MB RAM).

I got my PC the birday after that and got rid of the Amiga. Shame really, but we needed to get some money back for the PC.

Anyway, I see the little widget about the levels. I must admit I didn't use AmigaOS 3.0 anywhere near to it's full potential in my Amiga Days (I was still young then).

srg

P.S One last think before this thread is dragged back to topic, did you know that Commodore Owned the patent on the 2-button mouse AND that patend was why Gateway bought it??

[mystran]

Oh, one "feature" I hate possibly more than anything (after having to move my mouse to stupid spots to move/resize a window) is not being able to resize an obviously too small dialog.

It's ok not to allow resizing if and only if there isn't a single scrollable component on the dialog. If there's anything that requires scrolling (including but not limited to file/directory selection, text/hypertext views, lists, trees, tables, ...) PLEASE allow me to resize the dialog if I want to. It's NOT that hard to code properly resizable layouts for such dialogs, and it makes life a LOT less painful.

[Schol-R-LEA]

P.S One last think before this thread is dragged back to topic, did you know that Commodore Owned the patent on the 2-button mouse AND that patend was why Gateway bought it??

Are you sure about that? IIRC, Engelbart did a lot of research on multi-button mice even in the early days, and I know that the mouse on the Alto had three buttons. Even if Commodore had bought the rights, which they didn't, the latest that the patent would have been valid until was 1987 (the original Engelbart patent, based on the original 1964 design, was filed in 1967 and granted in 1970; if you look closely, you can see that the mouse depicted has more than one button).

Commodore might have had a patent on a particular design for a two-button mouse, but not for the idea itself.

[zloba]

i don't think there is any one "best feature" - it's the completeness that counts. so here's the list

as a user, i want:
-installable (absolutely no building of a dozen prerequisite packages (or any building for that matter), and no googling to find out exactly what packages are needed and where the hell to find them, much less having to edit source code just to get them to compile)
-configurable (absolutely no editing of cryptic configuration files and no goodling for clues. everything should be either obvious, or well-documented and published on the original website or in built-in help)
-customizable: focus, stacking policies, titlebar, taskbar etc.
-efficiency of navigating between tasks. preferrably, a taskbar which would let me group and rearrange task buttons to my liking (by dragging)
-multiple desktops are welcome, but not essential
-mutlilanguage support: keyboard maps, fonts, unicode.; this is essential.

as a programmer:
-a good API (preferrably OO-style), well-defined and documented
-a design that allows runtime efficiency (with good implementation)
-multithreading-friendly
-a "window manager" mechanism, like in X, so some of the above features would be provided by or controlled via an external window manager.

p.s.

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...
....
Or do you think this a really valuable feature?

no, but i don't think it's THAT bad, either. there are only so many mouse events per second and per distance travelled; besides, windows gui is actually quite efficient. a mouse pointer is just a tiny bitmap, compiled into a resource handle, and windows handles them quite efficiently. even if you do nothing but move the mouse all over the place.

[Dreamsmith]

Solar: I agree with the inactive window thing. I'd even take it a step further: I don't need to SEE any window other than the active one. The biggest CPU hog in most modern GUIs is support for overlapping windows. The biggest pain the world is trying to fish out a window hidden behind several others. The biggest waste of time in my day before someone's computer is spending a little time after I open anything to move and resize the bloody window.

Bah, we don't need any of that! If you're using Linux, check to see if your distribution has the Ion window manager available. Try it out. I've been using it for about a year now. But it's addicting -- before long, you'll find yourself cursing anything else as you deal wth the silly window placement issues that have plagued everything since Macintosh System 6 (before System 6 and Multifinder, one app owned the screen at a time, and everything was much easier to use...)

[srg]

P.S One last think before this thread is dragged back to topic, did you know that Commodore Owned the patent on the 2-button mouse AND that patend was why Gateway bought it??

Are you sure about that? IIRC, Engelbart did a lot of research on multi-button mice even in the early days, and I know that the mouse on the Alto had three buttons. Even if Commodore had bought the rights, which they didn't, the latest that the patent would have been valid until was 1987 (the original Engelbart patent, based on the original 1964 design, was filed in 1967 and granted in 1970; if you look closely, you can see that the mouse depicted has more than one button).

Commodore might have had a patent on a particular design for a two-button mouse, but not for the idea itself.

Well this is where I got it from:

http://amiga.emugaming.com/gatepate.html

srg

[Solar]

I don't need to SEE any window other than the active one.

I disagree. Far too often, I am in my editor and need a web page for reference. Or I am in my shell and type some command depending on what I just read in a PDF.

If you're using Linux...

Nope, too much hassles around the edges.

Besides, I don't think the window manager / toolkit idea is a too smart one. Yes, it allows you to configure your every whim; but it makes for inconsistent look & feel (making it a headache every time you have to work on some other system but your very own), seriously adds complexity to the GUI subsystem, and - from our perspective perhaps most importantly - scatters development effort among dozens of teams effectively doing the same.

I'd prefer the "one WM to rule them all" approach, where criticism is translated into a better next version instead of YAPF (yet another project fork).

I am perfectly aware that this is premium flame bait for the "choice is beneficial" camp.

...before long, you'll find yourself cursing anything else as you deal wth the silly window placement issues...

Well, when my system starts up, the mailer pops up bottom left, the shell bottom right (sized and aligned so they don't overlap), and the text editor sits full-width in the top half of the screen. I have three seperate things in view, and I tend to keep all three of them busy. Window placement done right isn't a bad thing in my book. (Not that Windows is that good at it...)

[crc]

Well, I'm not a big fan of GUI's, but they are useful for some things (AutoCAD comes to mind)...

Best feature: full, consistent keyboard-based control. Don't scrap the mouse, but allow all operations, menus, etc to be accessed easily from a keyboard. I have CTS, and the mouse is a major culprit there

Unnecessary CPU hog: Eye candy. Yes, transparent windoes, shadows, etc look nice, but they slow things down a lot. (I don't consider things like subpixel rendering to be eye candy though since they make it much easier to work with a computer. Indeed, I no longer use GUI's [except for BeOS] that don't offer subpixel rendering on my LCD display for that reason).

Most annoying: Overlapping windows. I HATE overlapping windows. Don't waste my valueable vertical screen space with "title bars" and "per-window" menu bars. I'd rather have a nice list of open windows/per-window controls on one side of the screen. If I need multiple windows, I'll tile them.