GUI design - must-have's and CPU hogs

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:GUI design - must-have's and CPU hogs

Post by Candy »

Solar wrote: 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.
I'd prefer a 3-monitor setup for my main work computer if I could afford it. One for references, one for coding, one for displaying results / compile stuff / execution results / debug logs. This most importantly disproves the idea of one-at-a-time. That might work for Joe Average (my mom, sis, fairy etc) but not for a power user trying to use the computer to get something done. Even my sis has a paper stand next to her computer for most stuff, because you need a reference when working. I oppose the paper office, and like to have it all onscreen.

PS: computer at work runs at 1600*1200 or 2048*1536 for the same reason, when comparing results I want to see all the results. Couldn't get a second monitor so...
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...)
Very true. Here IM pops up at the total right side (not wide, lists complete list of people I know on screen), mailer in systray, winamp in systray, nothing default started, and most things can run concurrently.
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:GUI design - must-have's and CPU hogs

Post by Pype.Clicker »

oh, among other dreams ...

We were talking about writing code while checking a document, right ... I guess when you're reading a reference, you don't worry about those 'print, exit, search, etc' buttons and other fancy things, right ? All you need is the text, and possibly only the *selected text* ...

Let's say it would work that way: When active, the 'text viewer' app would be full-featured with its status, navigation, menu, scroll bars.

Then you select blocks of text, go further, select other blocks and then "okay, now let's implement what's said" ...

So you shift the focus to your editor and the viewer magically turn into "naked" mode, hiding whatever menubars, etc. Simply leaving you a clear text view. While still in the editor, key combos may have been define to forward commands to other application, without shifting focus (e.g. not ALT+TAB or window movement required: just do something like WIN+PG_down and you're sending 'page down' to the 'alternate window': your text viewer...

The 'naked mode' could also collect 'selected blocks' and display them altogether or let you switch from one selected block to another at will (still from the editor with WIN+1 .. WIN+9)

(can't wait for it to be implemented)
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:GUI design - must-have's and CPU hogs

Post by Candy »

Pype.Clicker wrote: We were talking about writing code while checking a document, right ... I guess when you're reading a reference, you don't worry about those 'print, exit, search, etc' buttons and other fancy things, right ? All you need is the text, and possibly only the *selected text* ...
Well... yes, in most cases I'd just use a bunch of selected blocks of text. Usually dump my editor over the lower half of the acrobat (usually pdfs), bochs over the top half
Let's say it would work that way: When active, the 'text viewer' app would be full-featured with its status, navigation, menu, scroll bars.

Then you select blocks of text, go further, select other blocks and then "okay, now let's implement what's said" ...
My reading/marking and my implementation moments usually lie up to 1.5 year apart... not that usable, but I reread them so it might work
So you shift the focus to your editor and the viewer magically turn into "naked" mode, hiding whatever menubars, etc. Simply leaving you a clear text view. While still in the editor, key combos may have been define to forward commands to other application, without shifting focus (e.g. not ALT+TAB or window movement required: just do something like WIN+PG_down and you're sending 'page down' to the 'alternate window': your text viewer...
Alternate doesn't work nice. I'd vote for making them F1-F12 with clear labeling on the taskbar which app uses which button.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re:GUI design - must-have's and CPU hogs

Post by Solar »

Pype.Clicker wrote: So you shift the focus to your editor and the viewer magically turn into "naked" mode, hiding whatever menubars, etc. Simply leaving you a clear text view.
That's one reason why I always preferred the top-of-screen-menubar-for-the-currently-active-window (Amiga / Mac style) instead of the per-window-menubar (Windows style).

It's not exactly the thing, but a step in the right direction. Just have a look at how much screen real estate is claimed by "File, Edit, View, Tools, Help"...
Every good solution is obvious once you've found it.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:GUI design - must-have's and CPU hogs

Post by Candy »

Solar wrote: It's not exactly the thing, but a step in the right direction. Just have a look at how much screen real estate is claimed by "File, Edit, View, Tools, Help"...
If you place them next to the title of the app, on the right hand side of the window, it doesn't take much at higher resolutions.

Best Ideas: Jobs instead of programs as things you start, open and end. See also http://clicker.sourceforge.net/pixs/c32desktop.png (Pype was first with the idea) for an example.
Soap_

Re:GUI design - must-have's and CPU hogs

Post by Soap_ »

crc wrote: 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.
Most of the time I'd agree with this. I hate doing fiddly manual window rearrangement in order to make effective use of my screen estate. The window manager should be doing that, not dumping it's responsibilities on to the user.

However, when I'm doing graphical work the ability to resize/move/overlap windows actually comes in useful because it allows me to quickly experiment with different spatial arrangements of images.
Dreamsmith

Re:GUI design - must-have's and CPU hogs

Post by Dreamsmith »

Solar wrote: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),
Heh. I've been complaining about that problem for years, ever since I was first forced to start working with Windows sytems -- coming from the Macintosh beforehand, I must say I laugh my head off every time someone suggests Windows has any consistency in its user-interface. And it is a headache, going from system to system, where Microsoft has changed how things are done, what control panels control what, where certain settings are found, etc. Simply knowing what you'll get when you click on Network Neighborhood (or whatever it's called under your version of Windows, if you can even find it on your desktop, or under the Start menu, or wherever they move it next) is a vain hope.

Thankfully, under Linux, I can choose which interface I want to use, and have it be comprehensive rather than a bit of eye candy. The same things have been in the same place and worked the same way on my desktop for years. If you actually value consistency, I don't know how you can stand Windows...
Solar wrote:seriously adds complexity to the GUI subsystem,
Or simplicity. Having written GUI applications under Window API, MSW, GNOME, Qt, wxWidgets, and MacOS, among others, I can say without a question, hands down, the easiest and least complex is Qt. Which is most complex is harder to say, but Windows is certainly in the running. Under Linux, one is not required to be that complex. There are simpler interfaces for Windows, (such as Qt under Windows), but in that case they simply hide the complexity rather than eliminate it. It can't be eliminated under Windows becase you can't simply yank out that part of the OS and replace it with something simpler.
Solar wrote:and - from our perspective perhaps most importantly - scatters development effort among dozens of teams effectively doing the same.
Or not. If they were effectively doing the same thing, your argument about a lack of consistency would be specious.

Actually, it's a specious argument in any case. There is no scattering of development unless it was previously gathered, or if you want to stretch the metaphor a bit, if it would otherwise be gathered in one place. But that seems wildly unlikely. It's about as logical to suggest that millions of Americans taking a few hours a week to watch football is the reason Duke Nukem Forever is still in development rather than released. "If only they weren't watching football, they would have been working on Duke Nukem and gotten it finished by now!" Yeah, right. Insert your own favorite coding project and some other coding project in the previous sentence for an equally ridiculous statement. "If only everyone working on KDE and GNOME had been working together on the same project instead..."

(...both projects would be substantially behind where they are now.)
Dreamsmith

Re:GUI design - must-have's and CPU hogs

Post by Dreamsmith »

Solar wrote: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. ;)
Well, it's worse than that, it's nonsensical. What does "better next version" mean? Better at what? When you say something is better than something else at this or that, you're making a sensible statement. When you just say something is better than something else, without defining "at what", you're spouting pure nonsense -- there's simply no meaning to the statement at all.

But that "at what" is critical, because all serious software is written to a specification, some set of objectives that it must achieve. Since not all software has the same objectives (not to mention all users), it'd be silly to assert some particular interface would be "better in general". "Better in general" is pure fantasy...

You can't make a "better next version" without simultaneously making a "worse next version" -- what's good for some will be bad for others. The only possible way for the next version of some particular piece of code to be better for everyone is if it forks to satisfy the different directions it would need to be taken for each of the different ways it could be better. Every time a project forks, it brings about a better version of that software for some users. Projects that don't fork can't really have a "better next version" that isn't also a "worse next version", depending on your particular "at whats"...
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re:GUI design - must-have's and CPU hogs

Post by Solar »

Dreamsmith, I see I was misunderstood.

Of course, I was not referring to Windows as an example of how the "one true WM" is done. I still believe the "one true WM" is the way to go.

Of course a "better next version" does not refer to any structural changes to the look & feel (at least not after v1.0), but to the fixing of bugs and obvious shortcomings.

Of course that means this hypothetical "one true WM" won't behave *exactly* like everybody would like, since you can't please everybody. But I consider having one look & feel is a strong feature in itself.

Note that, while we're talking about the "one true WM", my OS design did include a mechanism to plug-in "UI modules", to abstract the actual representation from implementation. However, the idea here was not to have a dozen 2D WM's, but to allow expansion of the system by 3D interfaces, acoustic interfaces for the blind, cranial VR interfaces...
Every good solution is obvious once you've found it.
Legend

Re:GUI design - must-have's and CPU hogs

Post by Legend »

Most times, forking and the "choice" result in let's say 10 solutions for the same thing, each pleasing around 1% from the amount of people in comparision to what one good solution would have done ...

(Note that these are not exact values, but should show what I mean ;) )
mystran

Re:GUI design - must-have's and CPU hogs

Post by mystran »

One killer usability feature is being able to have one window on top of window stack, and ANOTHER have keyboard focus. It's often very nice to have something like your IRC window only display a few lines, and not having to pop it on top to write a line like "ok".

Another killer feature is being able to easily throw a window to the bottom of the window stack. One you get used to this, you can keep a lot of windows open, and "dig" the one you want by throwing others on top of it to the bottom. It's much more useful than it sounds.
Post Reply