Opened 16 years ago
Closed 11 years ago
#306 closed enhancement (fixed)
hidden tabs are hard to spot in wxGUI module windows
Reported by: | msieczka | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 7.0.0 |
Component: | wxGUI | Version: | svn-develbranch6 |
Keywords: | tabs, forms, usability, module dialogs | Cc: | martinl |
CPU: | All | Platform: | All |
Description
You can't use --o and --v in v.in.ogr GUI cause they are missing.
Attachments (3)
Change History (29)
comment:1 by , 16 years ago
Cc: | added |
---|
comment:2 by , 16 years ago
I'm still missing the "Optional" tab in r33388. Translation issue? (Wild guess.)
follow-up: 6 comment:5 by , 16 years ago
Replying to martinl:
Use arrows to see other tabs or resize window.
ahh,
maybe there could be a right-most greyed out "..." tab in the case there are other hidden tabs. otherwise they are easy to miss.
possible?
Hamish
follow-up: 7 comment:6 by , 16 years ago
Replying to hamish:
ahh,
maybe there could be a right-most greyed out "..." tab in the case there are other hidden tabs. otherwise they are easy to miss.
possible?
if there are hidden tabs, the arrow is filled (right, left, or both).
comment:7 by , 16 years ago
comment:8 by , 16 years ago
Priority: | major → minor |
---|---|
Type: | defect → enhancement |
follow-up: 10 comment:9 by , 16 years ago
Priority: | minor → major |
---|---|
Type: | enhancement → defect |
OK, so resizinng the window magically reveals the missing tab. But how is the user supposed to guess he should resize the window? This is a defect.
comment:10 by , 16 years ago
Type: | defect → enhancement |
---|
Replying to msieczka:
OK, so resizinng the window magically reveals the missing tab. But how is the user supposed to guess he should resize the window? This is a defect.
Sorry, I don't see that as a defact -- some tabs are hidden because of window size, see screenshot, arrows indicates if there are hidden tabs.
follow-up: 13 comment:12 by , 16 years ago
Replying to martinl:
Use arrows to see other tabs or resize window.
I got traped byt this also a few times and overlooked the horizontal scroll arrows on the right. Any ideas to make that more outstanding? Eg. a half-shown/grey tab on the right (one of those which don't fit) would make it obvious I guess. Would that be possible? If you only see complete tabs and then space on the right then you don't get there idea that there could be more tabs hidden.
Markus
comment:13 by , 16 years ago
Replying to neteler:
I got traped byt this also a few times and overlooked the horizontal scroll arrows on the right. Any ideas to make that more outstanding? Eg. a half-shown/grey tab on the right (one of those which don't fit) would make it obvious I guess. Would that be possible?
The behaviour is dictated by the underlying widget provided by the toolkit, e.g. GtkNotebook for wxGTK. It may be possible to modify the appearance using the mechanisms provided by the toolkit, e.g. themes or gtkrc.
You could use e.g. wxChoiceBook (which uses an option menu instead of tabs) instead. The only other alternative is to construct the equivalent of wxNotebook from the base widget classes (e.g. wxPanel, wxButton).
follow-ups: 15 16 comment:14 by , 16 years ago
Glynn:
The behaviour is dictated by the underlying widget provided by the toolkit
right, but we can make tabs at will, and we can call one "...".
Questions for working within the current toolkit:
- can we control the order of the tabs on the fly?
- can we make and destroy tabs on the fly?
- can we grey out a tab?
if those things are possible maybe we can hack in a work-around. if not, we will have to take care to talk about the little arrows in the getting started tutorials, and perhaps file a wish upstream.
I think tabs are preferable to an options menu in this case, and we should try and avoid getting into the widget business if possible.
Hamish
comment:15 by , 16 years ago
Replying to hamish:
The behaviour is dictated by the underlying widget provided by the toolkit
right, but we can make tabs at will, and we can call one "...".
Questions for working within the current toolkit:
- can we control the order of the tabs on the fly?
AFAICT, no.
- can we make and destroy tabs on the fly?
Yes.
- can we grey out a tab?
AFAICT, no.
if those things are possible maybe we can hack in a work-around.
Also, I don't know how easy it is to determine the position of tabs relative to the parent.
if not, we will have to take care to talk about the little arrows in the getting started tutorials, and perhaps file a wish upstream.
Presumably other programs which use GtkNotebook has the same issue.
Hmm; a lot of programs use it for the Preferences dialog, but they usually have a fixed number of pages. Programs with a lot of preferences (e.g. GIMP, VLC) tend to use a list or tree control instead of tabs.
follow-up: 17 comment:16 by , 16 years ago
Replying to hamish:
Glynn:
The behaviour is dictated by the underlying widget provided by the toolkit
right, but we can make tabs at will, and we can call one "...".
To have a pseudo tab containing a title "..." would be perfect. If that's possible, the problem will be psychologically solved.
Markus
comment:17 by , 16 years ago
Replying to neteler:
Replying to hamish:
Glynn:
The behaviour is dictated by the underlying widget provided by the toolkit
right, but we can make tabs at will, and we can call one "...".
To have a pseudo tab containing a title "..." would be perfect. If that's possible, the problem will be psychologically solved.
Just to add my own 2 cents. I think the major problem is what you stated earlier:
"If you only see complete tabs and then space on the right then you don't get there idea that there could be more tabs hidden."
IMHO, it is this _space_ which is the major cause of confusion. Can this space be controlled ?
Moritz
Markus
follow-up: 21 comment:18 by , 16 years ago
I've followed this but haven't had the chance to relook at the options dialog tabs closely to see what the commotion is about until today.
The flatnotebook control, probably for nice aesthetic reasons, does not show partial tabs but only complete ones if a window is too small to show all tabs.
To recap, this behavior has misled some folks into thinking that there are not more tabs to the right.
However, there is a visual clue--one that people need to get used to, of course, but a consistent one--to additional tabs beyond the right OR left side of the window. The little arrows on the right will be darkened in any direction that there are hidden tabs.
There are some customizations possible for flatnotebook tabs, but I don't see anywhere that we can change the behavior that you either see all of a tab or you see none of the tab. The arrow buttons are a nice indicator of hidden tabs. This is a bit of a learning curve, especially for new users. But it's not too bad.
There are some other kinds of notebook controls, of course. Most lack arrow buttons to move to tabs outside the window.
After we get this version well-stablized and bugs fixed, we can look into other kinds of notebooks for the layer control area (e.g., AuiNotebook) to see what advantages and disadvantages there might be. IMHO, the tabs we are using now look quite nice aesthetically.
Michael
comment:19 by , 16 years ago
Keywords: | tabs added |
---|
AFAICT the correct way to address this is with an upstream wish to the flatnotebook people. If this is the only shortcoming of the current widget set, it would be a shame to change it all for the want of one improvement.
filed with wx as trac ticket #9962
Hamish
comment:20 by , 16 years ago
Summary: | v.in.ogr GUI is missing --o and --v → hidden tabs are hard to spot in wxGUI module windows |
---|
comment:21 by , 16 years ago
Replying to cmbarton:
I've followed this but haven't had the chance to relook at the options dialog tabs closely to see what the commotion is about until today.
The flatnotebook control, probably for nice aesthetic reasons, does not show partial tabs but only complete ones if a window is too small to show all tabs.
Ah; I assumed it used the normal wx.Notebook widget.
Is there some reason why it must be a FlatNotebook rather than a wx.Notebook widget? The latter is a bit more clear about indicating hidden tabs: the arrows are larger, and there isn't any space (the tabs are enlarged to fill any additional space).
Also, a wx.Notebook will provide a more native look, as it uses the platform's native notebook widget. It should also honour the user's theme setting.
comment:22 by , 16 years ago
Sarching wx.Notebook as image in the Internet revealed
http://xoomer.alice.it/infinity77/main/NotebookCtrl.html
which contains the promising screenshot http://xoomer.alice.it/infinity77/Softwares/notebook2.jpg
There no tab obscurity exists, it is immediately clear that the user has to expect further tabs on the right.
Markus
comment:23 by , 12 years ago
Milestone: | 6.4.0 → 6.4.4 |
---|
comment:24 by , 11 years ago
Milestone: | 6.4.4 → 7.0.0 |
---|
There is a new option in settings (Appearance tab) to change the style of notebook (tabs) for generated module dialogs (r52927, see an old announcement on ML). Some of the styles are using native notebook (tabs). Usually, the problem with too many tabs is solved in better way than the fancy green notebook solves it.
Maybe, we need to change the default settings now to the most standard system style.
Minor issue is what to do with icons in the tabs. It seems that is it good only for vertical style. Moreover, it is not clear if there are some symbols to describe the tabs.
For GRASS 6 it is wontfix, it is not possible to backport it easily, changing milestone to 7.
comment:25 by , 11 years ago
The default module dialog style is now 'basic top' (r57212).
For GRASS 7, this should be fixed for all platforms.
comment:26 by , 11 years ago
Keywords: | forms usability module dialogs added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Closing this fixed. If somebody from original reporters or anybody else wants to comment on it, you are welcome to do so.
We still have the fancy green FlatNotebook
(as only choice) in main GUI in Layer Manager.
Missing? See the attached screenshot.