GlobalMenuBar - Revision history

GigaClon: Categorization

2006-06-20T18:06:08Z

Categorization

← Older revision		Revision as of 18:06, 20 June 2006
Line 13:		Line 13:
	:::I'm not against per-window menus, if someone else will do it and if they will be easy to switch off :) And if this setting will be preserved across sessions, of course. Actually this should not be too difficult as we already have a docked toolbox. --bb		:::I'm not against per-window menus, if someone else will do it and if they will be easy to switch off :) And if this setting will be preserved across sessions, of course. Actually this should not be too difficult as we already have a docked toolbox. --bb

	::::I think we should pick one and stick with it -- 90% of users will use the defaults anyway. Per-window menus have the advantage of behaving in an expected and standard fashion, as well as requiring less mouse motion (compared to non-'maximized' shared menus). I wouldn't object to it being configurable, if it were configurable globally across apps, as I believe KDE does. As it is (not being a KDE[[/Qt]] app), I don't think it's wise to assume the rest of the environment will play along. Nearly all GNOME configurations and I think some fairly common KDE configurations will have problems with a 'maximized' shared menu. -- [[MenTaLguY]]		::::I think we should pick one and stick with it -- 90% of users will use the defaults anyway. Per-window menus have the advantage of behaving in an expected and standard fashion, as well as requiring less mouse motion (compared to non-'maximized' shared menus). I wouldn't object to it being configurable, if it were configurable globally across apps, as I believe KDE does. As it is (not being a KDE/Qt app), I don't think it's wise to assume the rest of the environment will play along. Nearly all GNOME configurations and I think some fairly common KDE configurations will have problems with a 'maximized' shared menu. -- [[MenTaLguY]]

	::::Thinking about it, it might be nice to have an extension module that hid the per-window menus and used a Qt global menu if that's currently turned on for Qt[[/KDE]] (IIRC that does have a global menu option?). Whatever we can do to fit in with the user's environment (without requiring them to manually set an option) would be great. At least enabling a global GTK menu would certainly help build infrastructure for that. -- [[MenTaLguY]]		::::Thinking about it, it might be nice to have an extension module that hid the per-window menus and used a Qt global menu if that's currently turned on for Qt/KDE (IIRC that does have a global menu option?). Whatever we can do to fit in with the user's environment (without requiring them to manually set an option) would be great. At least enabling a global GTK menu would certainly help build infrastructure for that. -- [[MenTaLguY]]

	::I'm also rather fond of an OS X-style application menu, actually, though clearly some things don't belong on it. -- [[MenTaLguY]]		::I'm also rather fond of an OS X-style application menu, actually, though clearly some things don't belong on it. -- [[MenTaLguY]]
Line 31:		Line 31:

	Furthermore, you could mount this panel at the top of each document window if you were so inclined, however I feel we're moving away from this idea.		Furthermore, you could mount this panel at the top of each document window if you were so inclined, however I feel we're moving away from this idea.

			[[Category:Wiki Attic]]

Conversion script: link fix

2006-01-22T02:33:06Z

link fix

New page

A single global menu bar would solve two problems.

# Where do we put those meta-tools

:What do you mean by meta-tools? What's wrong with the right-click menu? --bb

:I think the right-click menu is cumbersome (perhaps its because of the extra level of menu items to sort through). I'd love to see a more traditional menubar somewhere. On the subject, I also dont care much for the 'Inkscape' menu. It's unclear as to what it actually does. Something more traditional here would work well too I think, such as a 'File' menu and a 'About|Help' menu. --tvon

::"Inkscape" menu was done simply becaue two menus didn't fit into the toolbox. But if we create a separate floating menu dialog (perhaps with the possibility to maximize it horizontally in one click at the top of the screen, so it looks almost like the Mac menu) we can remove it from the toolbox. --bb

::I honestly think we're better off with every document window having its own menu bar for now -- doing a floating menubar in a way that isn't painful is tricky. Since we don't really have the option of attaching to the (real) top of the screen (due to e.g. GNOME Panel), Fitts' Law works against us in the case of a shared menu. -- [[MenTaLguY]]

:::I'm not against per-window menus, if someone else will do it and if they will be easy to switch off :) And if this setting will be preserved across sessions, of course. Actually this should not be too difficult as we already have a docked toolbox. --bb

::::I think we should pick one and stick with it -- 90% of users will use the defaults anyway. Per-window menus have the advantage of behaving in an expected and standard fashion, as well as requiring less mouse motion (compared to non-'maximized' shared menus). I wouldn't object to it being configurable, if it were configurable globally across apps, as I believe KDE does. As it is (not being a KDE[[/Qt]] app), I don't think it's wise to assume the rest of the environment will play along. Nearly all GNOME configurations and I think some fairly common KDE configurations will have problems with a 'maximized' shared menu. -- [[MenTaLguY]]

::::Thinking about it, it might be nice to have an extension module that hid the per-window menus and used a Qt global menu if that's currently turned on for Qt[[/KDE]] (IIRC that does have a global menu option?). Whatever we can do to fit in with the user's environment (without requiring them to manually set an option) would be great. At least enabling a global GTK menu would certainly help build infrastructure for that. -- [[MenTaLguY]]

::I'm also rather fond of an OS X-style application menu, actually, though clearly some things don't belong on it. -- [[MenTaLguY]]

:I agree that the context menu deserves some HEAVY pruning to become a real "context menu", anyway. -- [[MenTaLguY]]

# How can we provide a multi-document structure while maintaining a single document view?

:I think my latest changes more or less take care of that. There's no single "main" window, but whatever document is on top gets all attention from dialogs. All dialogs are unsinkable. It's different from GIMP (although the difference is only in behavior, while visibly it's almost the same) and from windows programs (no empty window as parent of all documents) - but I like it and so far I see no problems with this approach. --bb

This menu would take the shape of having all Major menu items enumerated horizontally ( ala windows and the mac ).
Below those menu items would rest a horizontal toolbar with buttons for file operations, clipboard maintainence and dialog / palette visibility controls.

:If you need it, we can create a new dialog (for lack of a better word) that will have such a menu and toolbar. It will be floating and unsinkable like all other dialogs. --bb

Furthermore, you could mount this panel at the top of each document window if you were so inclined, however I feel we're moving away from this idea.

Buliabyak: *

2003-11-14T06:06:30Z

New page

A single global menu bar would solve two problems.

# Where do we put those meta-tools

:What do you mean by meta-tools? What's wrong with the right-click menu? --bb

:I think the right-click menu is cumbersome (perhaps its because of the extra level of menu items to sort through). I'd love to see a more traditional menubar somewhere. On the subject, I also dont care much for the 'Inkscape' menu. It's unclear as to what it actually does. Something more traditional here would work well too I think, such as a 'File' menu and a 'About|Help' menu. --tvon

::"Inkscape" menu was done simply becaue two menus didn't fit into the toolbox. But if we create a separate floating menu dialog (perhaps with the possibility to maximize it horizontally in one click at the top of the screen, so it looks almost like the Mac menu) we can remove it from the toolbox. --bb

::I honestly think we're better off with every document window having its own menu bar for now -- doing a floating menubar in a way that isn't painful is tricky. Since we don't really have the option of attaching to the (real) top of the screen (due to e.g. GNOME Panel), Fitts' Law works against us in the case of a shared menu. -- MenTaLguY

:::I'm not against per-window menus, if someone else will do it and if they will be easy to switch off :) And if this setting will be preserved across sessions, of course. Actually this should not be too difficult as we already have a docked toolbox. --bb

::I'm also rather fond of an OS X-style application menu, actually, though clearly some things don't belong on it. -- MenTaLguY

:I agree that the context menu deserves some HEAVY pruning to become a real "context menu", anyway. -- MenTaLguY

# How can we provide a multi-document structure while maintaining a single document view?

:I think my latest changes more or less take care of that. There's no single "main" window, but whatever document is on top gets all attention from dialogs. All dialogs are unsinkable. It's different from GIMP (although the difference is only in behavior, while visibly it's almost the same) and from windows programs (no empty window as parent of all documents) - but I like it and so far I see no problems with this approach. --bb

This menu would take the shape of having all Major menu items enumerated horizontally ( ala windows and the mac ).
Below those menu items would rest a horizontal toolbar with buttons for file operations, clipboard maintainence and dialog / palette visibility controls.

:If you need it, we can create a new dialog (for lack of a better word) that will have such a menu and toolbar. It will be floating and unsinkable like all other dialogs. --bb

Furthermore, you could mount this panel at the top of each document window if you were so inclined, however I feel we're moving away from this idea.

Buliabyak: *

2003-11-14T02:51:31Z

New page

Buliabyak: *

2003-11-13T22:12:20Z

New page

A single global menu bar would solve two problems.

# Where do we put those meta-tools

:What do you mean by meta-tools? What's wrong with the right-click menu? --bb

# How can we provide a multi-document structure while maintaining a single document view?

:I think my latest changes more or less take care of that. There's no single "main" window, but whatever document is on top gets all attention from dialogs. All dialogs are unsinkable. It's different from GIMP (although the difference is only in behavior, while visibly it's almost the same) and from windows programs (no empty window as parent of all documents) - but I like it and so far I see no problems with this approach. --bb

This menu would take the shape of having all Major menu items enumerated horizontally ( ala windows and the mac ).
Below those menu items would rest a horizontal toolbar with buttons for file operations, clipboard maintainence and dialog / palette visibility controls.

:If you need it, we can create a new dialog (for lack of a better word) that will have such a menu and toolbar. It will be floating and unsinkable like all other dialogs. --bb

Furthermore, you could mount this panel at the top of each document window if you were so inclined, however I feel we're moving away from this idea.