Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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 design+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.