Hi Petr, hi Rainer and all the others! Before I start, please let me clarify something - maybe I wasn't that clear in my previous mail ...
The current LibO behavior is buggy, for sure. But the strange behavior isn't based on the missing "we know how it should work" (the specification). LibreOffice just misses to correctly implement the behavior - and as I said yesterday, OOo does behave fine in this case. Am Freitag, den 04.03.2011, 14:02 +0100 schrieb Petr Mladek: > Christoph Noack píše v Čt 03. 03. 2011 v 21:58 +0100: > > Am Donnerstag, den 03.03.2011, 21:28 +0100 schrieb Petr Mladek: > > > https://bugs.freedesktop.org/show_bug.cgi?id=31471 . The menu icon for > > > grid enabled/disabled is confusing. We would like to use a normal check > > > box instead. I hope that it does not break any design rules ;-) > > > > Well, it does :-) Here is the (very short) OOo spec how Menus are > > styled, along with the description of checkmarks vs. images: > > http://specs.openoffice.org/ui_in_general/menus/Menus.odt > > Well, I see there that both item images and checkmarks are allowed. I do > not see any rule when to use image and when checkmark. It is derived on a case-by-case basis. The usual case: If a features is often used and thus available in the toolbars, then the menu re-uses the same icon. This should ease the learning for the user, because toolbars miss text (in OOo) - but the menu items can help to explain the icons. But, it would be the wrong assumption that more icons in the menus do help more - they serve as visual anchors for the user. So the usual recommendation is to only use a few icons within the menus to keep this "characteristic". > Hmm, I do not like the checkmark specification. IMHO, it is more clear > to show empty box when the menu item is disabled. I see this (mine > preference) behavior in View/Toolbars/ menu. Here, I have to assume that you refer to the picture in the specification. The specification text states: "Unchecked menu items without an item image will be drawn without any special markings, leaving an empty place in the first column of the menu." So no issue - at least to me :-) > > Concerning the issue, I can confirm some weird behavior in LibO 3.3.1 - > > but, everything is fine in OOo 3.2.0 (quickly checked). I don't know why > > "we" cause this issue ... > > What is the correct behavior? > > I have attached screenshots that shows the current behavior on Linux > GNOME x86_64. It shows the grid icon when the grid is disabled. It shows > nothing when the grid is enabled. I think that it does not follow the > specification. It should always show the grid and visualize > (border/background) whether it is selected or not. Correct, it should always show the icon. Thanks for the screenshots - I also created some and added it to the bug report. Direct link: https://bugs.freedesktop.org/attachment.cgi?id=44142 By the way, thanks for already referring there to this mail thread. > Note that the same problem is with the "Snap to Grid" menu item. The > icon nicely visualize the purpose but it not shown when the feature is > enabled. > > Note that "Grid to front" menu item uses the checkmark, so it looks > weird. True, but I also would omit a picture for that feature - so at least here, it behaves according the defined behavior. > > Furthermore, there might be an additional issue when using one of the > > newer Linux distributions, since Gnome decided to deactivate the images > > in the menus. Thus, the images have to be replaced by real checkboxes, > > although the specification above is different in this case. > > I use GNOME and I see icons on many menu locations. It is based on a gconf configuration item; the Gnome default is "off". Maybe the distribution turned it on ... Here is what the Gnome Design Team wrote about it: http://www.andreasn.se/blog/?p=103 (By the way, I don't agree to all statements in his blog posting, it is just to explain the Gnome behavior). > > So, how to continue? Could anyone please check with a more recent OOo > > 3.3 - maybe on different platforms? > > > > Petr, might it make more sense to continue this discussion in the issue > > tracker? > > I would prefer to continue the discussion in bugzilla. It will be easier > to get input from users that are interested into that particular bug. > > On the other hand, if you expect a flamewar inside the design team, it > might be enough to discuss it here and just mention a link to the > mailing list archive in the bug. Hehe ;-) I don't think this has to be a flamewar ... I'll post the important information to the bug tracker, but the more talkative explanations may make more sense on this list. > > PS: I had to moderate this mail, so - if anybody joins to answer, please > > CC all guys. > > Thanks. I would prefer to do not subscribe. I am already in too many > lists that I do not read actively ;-) Of course - so we'll CC you in such cases. Thanks for the hint! > Thanks for help. Shouldn't it be the other way round? Thanks for your help! :-) Cheers, Christoph -- Unsubscribe instructions: E-mail to [email protected] List archive: http://listarchives.libreoffice.org/www/design/ *** All posts to this list are publicly archived for eternity ***
