UI quirks / Legacy leftovers in interface

[GoogleCodeExporter]

I start this issue in order to keep and share a list of observations about 
grafx2 - Trying to watch grafx2 from an outside eye, as if I didn't know the 
explanation for them, and what led to current UI.
Don't expect any quick changes about the things I list here : the goal is to 
see emerge new ideas for improvement that clash with the DOS version, and to 
spot some bad habits that we shouldn't continue for continuity's sake.

Original issue reported on code.google.com by yrizoud on 6 Aug 2010 at 9:31

[GoogleCodeExporter]

1) Secondary palette button opens a page of settings - why is it separate from 
the screen you get when clicking Settings.

Resolution button:
2) Most users never use anything but windowed mode, so it doesn't merit its own 
button on the tool bar - it's just a setting as well.
3) The image size is not related to the screen resolution, so there's no reason 
for them to be in the same screen.
4) The pixel scaler mostly affects the size of the unzoomed view : It is more 
related to the Magnifier.

5) The status bar is well used when drawing (showing coords, sometimes color) 
and hovering the palette (showing RGB). Aren't there some other screen areas / 
buttons that could display additional info when hovered ? ie. "Get transp 
color" could display which color# is transparent, Grad rect could display a 
preview of the gradient, FX could display the active effects, Undo/Redo could 
display which step number we're watching, brush FX could show brush dimensions, 
Page could show the filename of the spare... Basically, showing any significant 
data that helps the user know if he needs clicking the hovered area or not.

6) Double-click almost never exploited.

7) Drag-and-drop never exploited (what about layer ordering, palette arranging?)

8) Very few graphic buttons, in general.

9) Some complicated screens would be better if they had a status bar to display 
tool tips for the hovered button. F1 is less helpful for big screens with lots 
of buttons, because it doesn't jump to a specific button's explanation.

10) On standard applications for Windows, there's sometimes a "?" button, when 
you click it your cursor changes to a question mark, and then when you click 
any control it opens the related help. Grafx2's F1-on-hovered button is much 
more unusual, and you need to know on which are the two screens where it works.

11) A button to open a screen's help would normally be needed, arguably it's 
not necessary if ALL screens have F1, and the splash screens refer to it.

12) Could have more contextual mouse cursors, if the needs arises.

13) A few Help texts should benefit from hyperlinks.

14) In the Help screen, "About", "Credits", and "Help" look like classic 
buttons, but actually act as tab or radio buttons. 

Original comment by yrizoud on 6 Aug 2010 at 9:34

[GoogleCodeExporter]

This is going to grow into a big "drop-everything-in" issue.
I think we should try to report smaller issues and make more use of the 
"components" and other stuff the issue tracker provides us, possibly with a wik 
ipage replacing the issue tab and providing links to predefined views (such as 
"see all UI improvements", "see all features planned for next release".

As for the issues itself anyway :
1) Ok, but then we should have a global settings screen + a picture-specific 
screen (with palette, picture size, ...)
2,3,4) Ok, all of them can be moved to the global or picture-specific settings. 
But then I'm not so fond of the new settings dialog. It feels industrial 
beetwen all these carefully hand-crafted dialogs.

5) Some great ideas in there.
6) Not many apps use it. Any cases where it would be useful ?
7) No code for it. But yes, would be useful.
8) Draw them :) Note in the effects screen, there are graphical buttons, but a 
text label besides to help find out what they do.
9) One of the UI rules I use is if you need that, your screen is too 
complicated. Make it simpler. The only exception would be keyboard shortcuts
10) Seriously, who uses that ? ;)
11) I feel it would waste space. See 15.
12) which ones ? we don't use the existing ones much already. Drag&drop would 
best be made with moving the object you're dragging (layer button, ...)
13) Yes. VGAPaint does it and it's cool.
14) Move them above the textarea and just hide the bottom part of the selected 
one. Voilà, you have tabs :)
15) More widgets : menubar (for 11: an help menu), checkbox, tabs, radio 
buttons. the menubar could be made as a stackbar at bottom of screen, or inside 
windows. Or at top of screen if we show it only when a window is open (as the 
drawing area MUST start at top of screen for now)

Original comment by pulkoma...@gmail.com on 6 Aug 2010 at 9:55

[GoogleCodeExporter]

Yeah, I know it's not one, solvable Issue.. But don't worry, It's not meant for 
recurring growth. Maybe one or two adds, and then, whether we have made use of 
the ideas or not (in specific issues, or directly while implementing 
something), it can be archived away. I'll simply search for it in the archives 
if I ever need some out-of-the-box ideas.
The interest is not in the answers, but in the questioning :)

6) Double-click is an option when the single click is implied for the item, and 
had a minimum of side-effects. One case is when the single click selects an 
item out of many, without performing further action. For example : any listbox, 
any place where clicking something puts a selection cursor on it.

Original comment by yrizoud on 6 Aug 2010 at 11:47

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 20 Jan 2011 at 8:54

• Changed title: UI quirks / Legacy leftovers in interface

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 10 Apr 2011 at 8:43

• Added labels: Milestone-2.4

[GoogleCodeExporter]

Original comment by yrizoud on 8 Mar 2012 at 7:15

• Changed state: WontFix