Apache OpenOffice (AOO) Bugzilla – Issue 17937
bloated / strange menus ...
Last modified: 2005-04-14 07:55:56 UTC
I forgot to submit this - essentially, this reduces pixel wastage in the menus, and makes the look more like almost any other system. It adds the ability to re-enable check-boxes & toggles for the special case of the toolbar configuration right click menu (the only place they really make sense). It works rather well - but for the fact, that many toggle menu items are not correctly tagged, and thus can get an icon when they are un-checked. This is what we ship in Ximian OO.o 1.0.3, forward-ported to 1.1 HTH.
Created attachment 8280 [details] de-bloat the menus
pl->cj: i'm told you had something to say on this ?
(see last comment)
I will take a look at this.
*** Issue 19677 has been marked as a duplicate of this issue. ***
So; I guess Amit is spending some time going over the .src files to ensure that all check menu items are correctly marked up - since I understand this was a problem for up-streaming this. Patch should arrive here in the next few days / weeks. Thanks.
Created attachment 11264 [details] Correctly tag the check items.
Christian - I've attached Amit's patch (for him) to fix the menu items so there will be no icon vs. check-mark conflicts. Can you comment on when this can get in ? [ it'd be nice to see it in 1.1.1 ]
Hi Michael, Thanks for the patch. Currently we are working on reordering and redesigning menus and toolbars for OO.o 2.0. Regarding the check-marks this problem is well known and will be also addressed in 2.0. We'll merge the icon and check-mark column and we'll also going to remove the waste of space in the 'File' menu. So, I would like to address all of this in OO.o 2.0 -Christian
This patch seems to fix only one half of the problem. It is good that the shortcut now be positioned more to the left. What I don't like is the behavior that now an entry with an icon in front of it might toggles the visibility of the icon. Switching the feature makes a check mark visible, switching it off, the icon appears again. It is much easier for users to have icon and check marks beneath to each other, because this makes it very easy to identify what is switched on or off. Thus i propose to change only the shortcut stuff.
Ok; so cj's problems are a simple artefact of the menu items not being correctly marked up as being checkable. I attach a patch that fixes a good number of these issues;
Created attachment 15678 [details] fixups
CJ->SSA: Stephan, could you please check patch. Thanks.
Stephan wrote: > The problem why we didn't want to incorporate your fix was its inability > to display checked images. You either have a checkmark or an icon but > never both. Has this changed meanwhile - sorry I haven't actually > compiled the patch yet. What is the reason for the checkable flags in > the resources ? Is this now mandatory for (checkable) entries ? Does > your new code rely on this ? > So - the resource files have the capability to annotate that an item is a check-item; ie. then you can always omit the icon & just render a check-mark instead - and never get an 'icon' vs. 'check' ugliness. However - in many cases (as you have noticed) they are not correctly annotated. The 2nd attachment ('fixups') nails these so they behave as expected; hence the request for more comment. If it helps I can create a CWS with those modules & changes in [ if you're happy with the code ] & let you QA it ?
I see two problems: - you can never have icons and checkmarks simultaneously - you must set the corect flag in the resource file to avoid toggling between checkmarks and the icon, which is something nobody will remember to do for future entries What I would like to see are toolbox like checkmarks. Icons of checked menu entries will then be painted with a selection like checked toolbox buttons. Checked entries that have no icon will get a checkmark as icon but will be painted using the same toolbox style. If they are unchecked, the checkmark icon would vanish. This would allow for checked menu entries with icons while saving screen space and keeping the old resource files.
> I see two problems: > - you can never have icons and checkmarks simultaneously Why is that a problem ? all gtk+ apps work that way, and I don't recall ever seeing a professional application that had icons & toggles. > - you must set the corect flag in the resource file to avoid toggling between > checkmarks and the icon, which is something nobody will remember to do for > future entries That's pretty trivial to fix; we can add an assertion in the code such that we'll only allow toggles to be set that are marked check boxes - with a friendly message saying 'fix your RSC'. These patches bring OO.o back into line with the rest of the civilised world wrt. UI cleanliness & normality of operation. It's concerning to me that you would happily junk the accepted norm of a check-mark next to a toggle [ and preferably best-case some alpha faded check, indicating 'check-ability' (or radio-status) ] in favour of some new notion of toolbar-button whatevers - which will be extremely unfamiliar to users. Furthermore - a 'toolbar button' type pressed/unpressed state will be hard to convincingly render for a small icon; and - worse - it's still inconsistent & confusing, since only a few checkable items have icons - so in this proposed scheme - there would be a mix of check marks & unusual toolbar button icon things next to adjacent menu items [ not at all ideal ]. Please re-consider :-) please.
I just don't like the idea to sacrifice icons in order to have check marks. But may be CJ can comment on this when he will be back. BTW: A professional application that displays icons in menus either checked or non-checked is MS Office.
Ah - you're right; I just looked at Office XP and it does this - but it looks terrible: inconsistent & awful; image attached, compare vs. clear.png - how gimp/gtk does it.
Created attachment 18206 [details] ugh
Created attachment 18207 [details] more ugh
Created attachment 18208 [details] crispness ...
michael: so you're advertising OfficeXP now ? I mean, really, look at the screen shots you provided. In XP it's clear what is done, totally consistent with a checked toolbar item; also you have checked/unchecked and an image living in harmony. In the gtk snapshot we just see a menu that is overloaded to hell; and still one cannot see a solution for the image vs. checkmark problem.
> michael: so you're advertising OfficeXP now ? I mean, really, look at the screen > shots you provided. In XP it's clear what is done, totally consistent with a > checked toolbar item; also you have checked/unchecked and an image living in > harmony Not at all; there is a dearth of semantic information to the user. eg. in 'duff.png' is the 'Zoom' item a checkable item or not ? is the 'Normal' item checkable or not ? - there is no way of knowing short of clicking it, coming back to the menu and looking again. Similarly - there is no way of knowing that 'Document1' 'Document2' 'Document3' are all members of a radio-group, without again trying them and seeing [ indeed, you can't even tell they are checkable ]. > In the gtk snapshot we just see a menu that is overloaded to hell; and > still one cannot see a solution for the image vs. checkmark problem. Contrast this with the (admittedly large but) clear gimp menu. It is obvious that 'Shrink Wrap' is not checkable, whereas 'Snap to Grid' is. Similarly it is clear that the ratios & 'Other' are in a radio-group, where any one of these is selectable. ie. the behavior of the button is completely clear at a single glance, requiring no advanced expert knowledge or thought. Yes - there are no icons next to them - but - so what :-) Clearly - toolbar buttons by themselves are less intuitive - but, there's no excuse not to improve on that.
Created attachment 18510 [details] patch vs. HEAD for extra up-stream ease
The patch is now partially applied in CWS vcl34. The amount of whitespace between text and accelerator string is reduced. However, the checkmark vs. bitmap changes were not incorporated.
reopen for verify
please verify in CWS vcl34 that menus are now more compact you could check that menu strings are still fully visible and do not overlap with their accelerators
.
Checked and verified in cws vcl34 -> OK !
ok on Linux and Solaris
OK on Windows -> closed !