Changing my mind: reverting my menubar, toolbars and statusbar changes
Hi, I have been quite busy trying to convince everyone actions to toggle UI items such as menubar, toolbars, sidebars or statusbar should be labeled "Show/hide Foo" depending on the visibility of Foo rather than implemented as a checkable "[ ] Show Foo" item. Having started to work on converting applications, I came to the conclusion that: 1. It is a lot of work to fix this in all KDE SC (not even taking into account applications outside the SC) for little gain. 2. The gain is actually not that obvious: I find myself having a harder time to read some menus after the port. The fact that the "Show" and "Hide" words have different widths makes it more difficult to parse a menu which contains a series of "Show " elements because the "" part of the labels are not aligned on the same column anymore. With this in mind, I believe it is better to revert my changes. I am sorry for wasting other people valuable time, but now that I realize it is not so much of a good idea, I think it is better to acknowledge it and fix it before we freeze kdelibs API. # The "Fix my mess" plan I would like to revert r1186566, r1186567 and r1192393: http://websvn.kde.org/?view=revision&revision=1186566 http://websvn.kde.org/?view=revision&revision=1186567 http://websvn.kde.org/?view=revision&revision=1192393 The last one can be reverted without any consequences as it's only internal. The first two introduce two methods: KStandardAction::showHideMenubar() and showHideStatusbar(), and deprecate two others: KStandardAction::showMenubar() and showStatusbar(). A quick look at lxr.kde.org tells me at least three applications (Dolphin, Konqueror and Konsole) have already switched to these new methods. I think the best way to deal with those changes is to: 1. Next Monday (11/8): Swap the deprecated flags: Remove them from the show*() methods and add them to the showHide*() methods. 2. Revert the use of the showHide*() methods in Dolphin, Konqueror and Konsole. 3. Monday after (11/15): Remove the showHide*() methods. This should reduce the risk of build failures since any application I missed which switched to showHide*() methods will continue to build but get warnings for one week. Does this make sense? # Future plan In order to get something positive out of this story, I am going to go through main KDE SC applications and fix a quite common mistake related to these actions: Applications which have "[ ] Show " menu items should not change them to "[x] Hide " when it is toggled. This is clearly wrong. Aurélien
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
Hi Aurélien, On Saturday 06 November 2010 15:31:45 Aurélien Gâteau wrote: > I have been quite busy trying to convince everyone actions to toggle UI > items such as menubar, toolbars, sidebars or statusbar should be labeled > "Show/hide Foo" depending on the visibility of Foo rather than > implemented as a checkable "[ ] Show Foo" item. > [...] > The gain is actually not that obvious: I find myself having a harder > time to read some menus after the port. Might be transitional, but I was seeing the same. The check box is also faster to "parse" than the word. > # The "Fix my mess" plan > [... long plan involving reverting ...] > This should reduce the risk of build failures since any application I > missed which switched to showHide*() methods will continue to build but > get warnings for one week. Does this make sense? It would be simpler to just revert the kdebase/apps commits, too, instead of API juggling. I compile trunk daily, so if there is commit missed, I can spot it and revert :) > Applications which have "[ ] Show " menu > items should not change them to "[x] Hide " when it is > toggled. This is clearly wrong. Exactly. Left-over from the days where KToggleAction did not force a check box. David Faure is the maintainer of XMLGUI stuff and actually was in favor of those API changes, so wait for his decision. Christoph Feck (kdepepo)
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On 06/11/2010 16:47, Christoph Feck wrote: >> # The "Fix my mess" plan >> [... long plan involving reverting ...] >> This should reduce the risk of build failures since any application I >> missed which switched to showHide*() methods will continue to build but >> get warnings for one week. Does this make sense? > > It would be simpler to just revert the kdebase/apps commits, too, instead of > API juggling. I compile trunk daily, so if there is commit missed, I can spot > it and revert :) Actually what I meant was to revert both changes in kdelibs and kdebase but keep the deprecated flag on the methods which would be removed for a week, to avoid breaking other applications. Might not be worth it indeed. >> Applications which have "[ ] Show " menu >> items should not change them to "[x] Hide " when it is >> toggled. This is clearly wrong. > > Exactly. Left-over from the days where KToggleAction did not force a check > box. > > David Faure is the maintainer of XMLGUI stuff and actually was in favor of > those API changes, so wait for his decision. OK, makes sense. Aurélien
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On Saturday 06 November 2010, Ingomar Wesp wrote: > Aurélien Gâteau wrote: > > I have been quite busy trying to convince everyone actions to > > toggle UI items such as menubar, toolbars, sidebars or statusbar > > should be labeled "Show/hide Foo" depending on the visibility of > > Foo rather than implemented as a checkable "[ ] Show Foo" item. > > Having followed the discussion and how you fought to get this change > in, I'm a bit saddened that it turned out to not work so well in > practice. > > Maybe we can tackle the underlying issue in another way. If I > understood the problem correctly, it basically boils down to > > [X] Show Foo > > textually implying the opposite of the action that the user is going > to trigger if (s)he clicks it. If we keep the checkboxes, maybe we > are able to change the text, so that it is obvious that it describes > the current state rather than an action by changing the verb into an > adjective: > > [X] Foo shown > [X] Foo visible > [X] Foo enabled > > Just an idea... IMHO that does not really fix the problem. I think the real problem is that we think that an additional qualifier like "Show" or "shown" is necessary. As if our users would not understand what the state of the checkbox preceding the menu entry signifies. I just had a look at Firefox (maybe others can check applications from other "vendors" like Apple, Microsoft, etc.) Firefox has the options to show/hide certain UI components in the View menu (while we have them in the Settings menu). In this menu Firefox simply lists the UI components names without any verbs, adjectives, etc., i.e. View Toolbars [x] Navigation Toolbar [x] Bookmarks Toolbar [x] Status Bar Sidebar [ ] Bookmarks [ ] History Does it really matter that Firefox has those options in the View menu while we have them in the Settings menu? I don't think so. So, why don't we simply get rid of "Show" (and the "Shown" in Settings- >Toolbars Shown). IMHO those qualifiers are totally superfluous in combination with checkboxes. Our convention to add the "Show" does stem from a time where we could (and did) hide the checkboxes of checkable menu entries. Apparently, with Qt 4 the checkboxes of checkable menu entries cannot be hidden. Since we are already at Qt 4.7 it seems very unlikely that QtDF will ever change this. So why insist on a convention that does not make any sense anymore? Just my 2 cents. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On 07/11/2010 14:16, David Jarvie wrote: > On Sunday 07 November 2010 09:31:44 Ingo Klöcker wrote: >> On Saturday 06 November 2010, Ingomar Wesp wrote: >>> Aurélien Gâteau wrote: I have been quite busy trying to convince everyone actions to toggle UI items such as menubar, toolbars, sidebars or statusbar should be labeled "Show/hide Foo" depending on the visibility of Foo rather than implemented as a checkable "[ ] Show Foo" item. >>> >>> Having followed the discussion and how you fought to get this change >>> in, I'm a bit saddened that it turned out to not work so well in >>> practice. >>> >>> Maybe we can tackle the underlying issue in another way. If I >>> understood the problem correctly, it basically boils down to >>> >>> [X] Show Foo >>> >>> textually implying the opposite of the action that the user is going >>> to trigger if (s)he clicks it. If we keep the checkboxes, maybe we >>> are able to change the text, so that it is obvious that it describes >>> the current state rather than an action by changing the verb into an >>> adjective: >>> >>> [X] Foo shown >>> [X] Foo visible >>> [X] Foo enabled >>> >>> Just an idea... >> >> IMHO that does not really fix the problem. I think the real problem is >> that we think that an additional qualifier like "Show" or "shown" is >> necessary. As if our users would not understand what the state of the >> checkbox preceding the menu entry signifies. >> >> I just had a look at Firefox (maybe others can check applications from >> other "vendors" like Apple, Microsoft, etc.) >> >> Firefox has the options to show/hide certain UI components in the View >> menu (while we have them in the Settings menu). In this menu Firefox >> simply lists the UI components names without any verbs, adjectives, >> etc., i.e. >> >> View >> Toolbars >> [x] Navigation Toolbar >> [x] Bookmarks Toolbar >> [x] Status Bar >> Sidebar >> [ ] Bookmarks >> [ ] History >> >> Does it really matter that Firefox has those options in the View menu >> while we have them in the Settings menu? I don't think so. >> >> So, why don't we simply get rid of "Show" (and the "Shown" in Settings- >>> Toolbars Shown). IMHO those qualifiers are totally superfluous in >> combination with checkboxes. Our convention to add the "Show" does stem >> from a time where we could (and did) hide the checkboxes of checkable >> menu entries. Apparently, with Qt 4 the checkboxes of checkable menu >> entries cannot be hidden. Since we are already at Qt 4.7 it seems very >> unlikely that QtDF will ever change this. So why insist on a convention >> that does not make any sense anymore? > > I agree about removing "Show" etc. But if this is done, the menu items should > be moved to the View menu. In the Firefox example you give, the menu name > (View) puts the meaning of the menu items in context and acts as the verb, > giving the necessary hint to the user that the checkboxes determine the view > state of the respective items. Removing the verb and leaving them in the > Settings menu would IMO make their meaning a bit unclear. I agree it looks better without the "Show" but there should be enough context to ensure the item text is not ambiguous. We already do this correctly when there are multiple toolbars: in this case the "Settings" menu contains a "Toolbars" submenu which contains one checkable item per toolbar and the item text is simply the name of the toolbar. One way to give enough context would indeed be to move these items to the "View" menu. These settings are in the "View" menu in Mozilla applications (checked Firefox and Thunderbird) and in the GNOME applications I tried (Gedit, EOG, Gnome-terminal and GIMP (although the last two use "Show " instead of just "")). Aurélien
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On 06/11/2010 22:26, Ingomar Wesp wrote: > Aurélien Gâteau wrote: >> I have been quite busy trying to convince everyone actions to toggle UI >> items such as menubar, toolbars, sidebars or statusbar should be labeled >> "Show/hide Foo" depending on the visibility of Foo rather than >> implemented as a checkable "[ ] Show Foo" item. > > Having followed the discussion and how you fought to get this change in, I'm > a > bit saddened that it turned out to not work so well in practice. Yes, I fought hard, but I think it's better to acknowledge I am wrong as soon as I realize it. Especially since the patches contains API changes in kdelibs. Aurélien
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On Sunday 07 November 2010, David Jarvie wrote: > On Sunday 07 November 2010 09:31:44 Ingo Klöcker wrote: > > On Saturday 06 November 2010, Ingomar Wesp wrote: > > > Aurélien Gâteau wrote: > > > > I have been quite busy trying to convince everyone actions to > > > > toggle UI items such as menubar, toolbars, sidebars or > > > > statusbar should be labeled "Show/hide Foo" depending on the > > > > visibility of Foo rather than implemented as a checkable "[ ] > > > > Show Foo" item. > > > > > > Having followed the discussion and how you fought to get this > > > change in, I'm a bit saddened that it turned out to not work so > > > well in practice. > > > > > > Maybe we can tackle the underlying issue in another way. If I > > > understood the problem correctly, it basically boils down to > > > > > > [X] Show Foo > > > > > > textually implying the opposite of the action that the user is > > > going to trigger if (s)he clicks it. If we keep the checkboxes, > > > maybe we are able to change the text, so that it is obvious that > > > it describes the current state rather than an action by changing > > > the verb into an adjective: > > > > > > [X] Foo shown > > > [X] Foo visible > > > [X] Foo enabled > > > > > > Just an idea... > > > > IMHO that does not really fix the problem. I think the real problem > > is that we think that an additional qualifier like "Show" or > > "shown" is necessary. As if our users would not understand what > > the state of the checkbox preceding the menu entry signifies. > > > > I just had a look at Firefox (maybe others can check applications > > from other "vendors" like Apple, Microsoft, etc.) > > > > Firefox has the options to show/hide certain UI components in the > > View menu (while we have them in the Settings menu). In this menu > > Firefox simply lists the UI components names without any verbs, > > adjectives, etc., i.e. > > > > View > > > > Toolbars > > > > [x] Navigation Toolbar > > [x] Bookmarks Toolbar > > > > [x] Status Bar > > > > Sidebar > > > > [ ] Bookmarks > > [ ] History > > > > Does it really matter that Firefox has those options in the View > > menu while we have them in the Settings menu? I don't think so. > > > > So, why don't we simply get rid of "Show" (and the "Shown" in > > Settings- > > > > >Toolbars Shown). IMHO those qualifiers are totally superfluous in > > > > combination with checkboxes. Our convention to add the "Show" does > > stem from a time where we could (and did) hide the checkboxes of > > checkable menu entries. Apparently, with Qt 4 the checkboxes of > > checkable menu entries cannot be hidden. Since we are already at > > Qt 4.7 it seems very unlikely that QtDF will ever change this. So > > why insist on a convention that does not make any sense anymore? > > I agree about removing "Show" etc. But if this is done, the menu > items should be moved to the View menu. In the Firefox example you > give, the menu name (View) puts the meaning of the menu items in > context and acts as the verb, giving the necessary hint to the user > that the checkboxes determine the view state of the respective > items. Removing the verb and leaving them in the Settings menu would > IMO make their meaning a bit unclear. Do you really think this would be a bit unclear? What else would an unchecked UI element in any menu mean? Quite frankly, I cannot image the number of users which grasp "[ ] Show Toolbar" but not "[ ] Toolbar" to be significant. Surely, there are a lot of not that computer literate people (like my parents) who understand neither one nor the other. But people who understand the former, but not the latter? I claim that such people do not exist. Prove me wrong! ;-) Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On Sunday 07 November 2010, David Jarvie wrote: > On Sunday 07 November 2010 19:12:46 Ingo Klöcker wrote: > > On Sunday 07 November 2010, David Jarvie wrote: > > > On Sunday 07 November 2010 09:31:44 Ingo Klöcker wrote: > > > > On Saturday 06 November 2010, Ingomar Wesp wrote: > > > > > Aurélien Gâteau wrote: > > > > > > I have been quite busy trying to convince everyone actions > > > > > > to toggle UI items such as menubar, toolbars, sidebars or > > > > > > statusbar should be labeled "Show/hide Foo" depending on > > > > > > the visibility of Foo rather than implemented as a > > > > > > checkable "[ ] Show Foo" item. > > > > > > > > > > Having followed the discussion and how you fought to get this > > > > > change in, I'm a bit saddened that it turned out to not work > > > > > so well in practice. > > > > > > > > > > Maybe we can tackle the underlying issue in another way. If I > > > > > understood the problem correctly, it basically boils down to > > > > > > > > > > [X] Show Foo > > > > > > > > > > textually implying the opposite of the action that the user > > > > > is going to trigger if (s)he clicks it. If we keep the > > > > > checkboxes, maybe we are able to change the text, so that it > > > > > is obvious that it describes the current state rather than > > > > > an action by changing the verb into an adjective: > > > > > > > > > > [X] Foo shown > > > > > [X] Foo visible > > > > > [X] Foo enabled > > > > > > > > > > Just an idea... > > > > > > > > IMHO that does not really fix the problem. I think the real > > > > problem is that we think that an additional qualifier like > > > > "Show" or "shown" is necessary. As if our users would not > > > > understand what the state of the checkbox preceding the menu > > > > entry signifies. > > > > > > > > I just had a look at Firefox (maybe others can check > > > > applications from other "vendors" like Apple, Microsoft, etc.) > > > > > > > > Firefox has the options to show/hide certain UI components in > > > > the View menu (while we have them in the Settings menu). In > > > > this menu Firefox simply lists the UI components names without > > > > any verbs, adjectives, etc., i.e. > > > > > > > > View > > > > > > > > Toolbars > > > > > > > > [x] Navigation Toolbar > > > > [x] Bookmarks Toolbar > > > > > > > > [x] Status Bar > > > > > > > > Sidebar > > > > > > > > [ ] Bookmarks > > > > [ ] History > > > > > > > > Does it really matter that Firefox has those options in the > > > > View menu while we have them in the Settings menu? I don't > > > > think so. > > > > > > > > So, why don't we simply get rid of "Show" (and the "Shown" in > > > > Settings- > > > > > > > > >Toolbars Shown). IMHO those qualifiers are totally superfluous > > > > >in > > > > > > > > combination with checkboxes. Our convention to add the "Show" > > > > does stem from a time where we could (and did) hide the > > > > checkboxes of checkable menu entries. Apparently, with Qt 4 > > > > the checkboxes of checkable menu entries cannot be hidden. > > > > Since we are already at Qt 4.7 it seems very unlikely that > > > > QtDF will ever change this. So why insist on a convention that > > > > does not make any sense anymore? > > > > > > I agree about removing "Show" etc. But if this is done, the menu > > > items should be moved to the View menu. In the Firefox example > > > you give, the menu name (View) puts the meaning of the menu > > > items in context and acts as the verb, giving the necessary hint > > > to the user that the checkboxes determine the view state of the > > > respective items. Removing the verb and leaving them in the > > > Settings menu would IMO make their meaning a bit unclear. > > > > Do you really think this would be a bit unclear? What else would an > > unchecked UI element in any menu mean? > > > > Quite frankly, I cannot image the number of users which grasp "[ ] > > Show Toolbar" but not "[ ] Toolbar" to be significant. Surely, > > there are a lot of not that computer literate people (like my > > parents) who understand neither one nor the other. But people who > > understand the former, but not the latter? I claim that such > > people do not exist. Prove me wrong! ;-) > > I can't prove you wrong. :-( What I'm saying is that putting the > items in the View menu would make it a bit clearer because the menu > items would be unambiguously related to viewing, so there would be > less opportunity to misunderstand them. I quite agree with you that > there are people who probably wouldn't understand either, but that > shouldn't stop us trying to make things as clear as possible for > those who might be capable of understanding. One problem with the View menu is that it's not a standard menu while the Settings menu is a standard menu. For example, KAddressBook 4.4 does not have a View menu. Other than that I'm not totally opposed to putting those options into a View menu. Regards, Ingo signature.asc De
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
Am 11/7/2010 20:12, schrieb Ingo Klöcker: > Quite frankly, I cannot image the number of users which grasp "[ ] Show > Toolbar" but not "[ ] Toolbar" to be significant. Surely, there are a > lot of not that computer literate people (like my parents) who > understand neither one nor the other. But people who understand the > former, but not the latter? I claim that such people do not exist. Prove > me wrong! ;-) Sorry to say: *you* are suggesting a change; it is on *you* to prove that the change is good ;-) How is a checkable menu entry that is not checked different from a menu entry that is not checkable, hm? There is *no* difference. Having a menu entry that does not show a checkbox and whose name is merely "Toolbar" in a menu named "Settings" does absolutely *not* suggest that choosing that entry will switch on the toolbar. It rather suggests that this will allow toobar related settings. Therefore, I strongly suggest to keep the word "Show" as long as the entry is in a menu named "Settings". -- Hannes
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On Monday 08 November 2010 08:06:58 Johannes Sixt wrote: > How is a checkable menu entry that is not checked different from a menu > entry that is not checkable, hm? There is *no* difference. That depends on the used style. With Skulpture, for example, any checkable entry shows a check box, either checked or unchecked. If the difference isn't clear enough using Oxygen style, I am sure Hugo can improve it. Christoph Feck (kdepepo)
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On Monday 08 November 2010 14:35:16 Christoph Feck wrote: > On Monday 08 November 2010 08:06:58 Johannes Sixt wrote: > > How is a checkable menu entry that is not checked different from a menu > > entry that is not checkable, hm? There is *no* difference. > > That depends on the used style. With Skulpture, for example, any checkable > entry shows a check box, either checked or unchecked. If the difference > isn't clear enough using Oxygen style, I am sure Hugo can improve it. > > Christoph Feck (kdepepo) Sorry, there _is_ a difference. Maybe it lacks contrast (in which case I'll improve it), but an empty box _is_ drawn for unchecked menu options.
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
Am Monday 08 November 2010 schrieb Johannes Sixt:
> How is a checkable menu entry that is not checked different from a menu
> entry that is not checkable, hm? There is *no* difference.
Broken UI style? There "*can be*" a difference ;-P
Unchecked Box:
Bespin, Skulpture, Oxygen, QtCurve, Motif/CDE,Plastique
NO Unchecked Box:
Phase, Windows, GTK+, Cleanlooks
I'm willing to move Phase up (if anyone is interested...), Windows can diaf
and the other two can be considered "non standard" broken then >-)
Leaving that aside and a bit more working solution oriented, i'd anyway
suggest to have a headered "Visible UI elements" (or so) group ("trailing
seperator") and move the items in question in there
Cheers,
Thomas
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On 08/11/2010 14:18, Thomas Lübking wrote: > Am Monday 08 November 2010 schrieb Johannes Sixt: >> How is a checkable menu entry that is not checked different from a menu >> entry that is not checkable, hm? There is *no* difference. > Broken UI style? There "*can be*" a difference ;-P > > Unchecked Box: > Bespin, Skulpture, Oxygen, QtCurve, Motif/CDE,Plastique > > NO Unchecked Box: > Phase, Windows, GTK+, Cleanlooks You can add Mac OS X here. So this basically means all major desktop environments (but Plasma) on which KDE applications can run. Aurélien
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On 06/11/2010 15:31, Aurélien Gâteau wrote: > # The "Fix my mess" plan > > I would like to revert r1186566, r1186567 and r1192393: > > http://websvn.kde.org/?view=revision&revision=1186566 > http://websvn.kde.org/?view=revision&revision=1186567 > http://websvn.kde.org/?view=revision&revision=1192393 > > The last one can be reverted without any consequences as it's only internal. > > The first two introduce two methods: KStandardAction::showHideMenubar() > and showHideStatusbar(), and deprecate two others: > KStandardAction::showMenubar() and showStatusbar(). Quick update on this: I reverted r1192393, removed the deprecated warnings from KStandardAction::showMenubar() and KStandardAction::showStatusbar() and reverted the code using the showHide*() method in kdebase/apps. Unless something goes wrong I'll remove the KStandardAction::showHide*() methods before soft API freeze. Aurélien
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On Tuesday 09 November 2010 15:52:01 Hans Meine wrote: > Hi Aurélien, > > I just want to express how much I appreciate your judiciousness to say you > dislike your own proposal now. I was quite sceptical about it, but did not > want to go bikeshedding, so I am happy you changed your mind *and* actually > made this whole public experiment. It's certainly an advancement to know > what's not an advancement. :-) > > Have a nice day, > Hans Agreed. I wish a few more developers would be that honest with their "mistakes" instead of being stubborn. Myself included, probably ;) Christoph Feck (kdepepo)
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
Hi Aurélien, I just want to express how much I appreciate your judiciousness to say you dislike your own proposal now. I was quite sceptical about it, but did not want to go bikeshedding, so I am happy you changed your mind *and* actually made this whole public experiment. It's certainly an advancement to know what's not an advancement. :-) Have a nice day, Hans
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On 09/11/2010 15:52, Hans Meine wrote: > Hi Aurélien, > > I just want to express how much I appreciate your judiciousness to say you > dislike your own proposal now. I was quite sceptical about it, but did not > want to go bikeshedding, so I am happy you changed your mind *and* actually > made this whole public experiment. It's certainly an advancement to know > what's not an advancement. :-) I agree, I definitely want to congratulate with Aurélien as well for his decision: what he did should be a demonstration of what all of us should do sometimes. Thank you! > Have a nice day, > Hans signature.asc Description: OpenPGP digital signature
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On Monday 08 November 2010, Aurélien Gâteau wrote: > On 08/11/2010 14:18, Thomas Lübking wrote: > > Am Monday 08 November 2010 schrieb Johannes Sixt: > >> How is a checkable menu entry that is not checked different from a > >> menu entry that is not checkable, hm? There is *no* difference. > > > > Broken UI style? There "*can be*" a difference ;-P > > > > Unchecked Box: > > Bespin, Skulpture, Oxygen, QtCurve, Motif/CDE,Plastique > > > > NO Unchecked Box: > > Phase, Windows, GTK+, Cleanlooks > > You can add Mac OS X here. So this basically means all major desktop > environments (but Plasma) on which KDE applications can run. So what is Apple's solution for the problem of checkable menu entries? What is Microsoft's solution? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Changing my mind: reverting my menubar, toolbars and statusbar changes
On Tuesday 09 November 2010 23:40:06 Ingo Klöcker wrote: > So what is Apple's solution for the problem of checkable menu entries? > What is Microsoft's solution? GNOME uses "X Toolbar" [1] MacOS X uses "Show/Hide Toolbar" [2] [1] http://library.gnome.org/devel/hig-book/stable/menus-types.html.en [2] http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGMenus/XHIGMenus.html Christoph Feck (kdepepo)
