Issue 17937

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 !