On 4 Apr 2001, Jean-Marc Lasgouttes wrote:
> >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
> Allan> You are free to combine things like: Help-> Version Copyright Credits
>
> That would make an awfully large dialog, wouldn't it?
Think laterally!
Or even folded or scrolling or outside the box or tabbed.
All the info doesn't have to be displayed at once. The dialog could be as
big as the copyright notice already is or much smaller depending on how
you present the info.
Automatically scroll throught the credits for example -- starting at a
random point if you like so everyone gets a chance to have their name in
lights or whatever. It doesn't have to look like what we've already got.
> Allan> into a single Help->About if want. You just need to connect
> Allan> such a dialog to the signals that everyone else also uses.
> Allan> Choose one or preferably all three but it doesn't really matter
> Allan> since you also control the menu to large extent and can ensure
> Allan> that there's only a Help->About option in the menu.
>
> We would then have to think about the scheme we use to allow different
> menus for different implementations. The two possiblities I see are
>
> 1/ provide a way in menu definition to condition o the current
> frontend (like a #ifdef in C++)
ooh yucky
> 2/ have completely different ui files like xforms.ui, gnome.ui... Then
> we have the risk of make maintenance difficult.
The last time I looked KDE and Gnome had different requirements for the
naming of some standard menu entries and even where they should be placed.
Stuff like File->Quit versus File->Exit for example. Other OSes have
different desktop standards. In the long run I think we'll end using
something like:
common.ui.inc, gnome.ui, windows.ui, kde.ui, default.ui, ...
to get around these differences. The two top-level menues that'll cause
the most grief seems to be File and Help. But Windows or at least MS
products seem to have a habit of providing Format where we currently use
Layout (although that's not a 100% match in features provided). Likewise,
Tools is used to cover some of what we do in Edit (like Preferences).
So while some of these things might be seen as good ideas to use in the
common menus I certainly wouldn't advocate another major menu
reorganization. Particularly in light of some of the other stupid UI
stuff that MS products do.
> 3/ maybe a better one: turn these menu entries to OptItem, and have
> LyXfunc::getStatus() return Disabled on the relevant functions if
> nobody is connected to the signals (I guess sigc++ allows us to query
> this condition).
SignalName.empty()
Hmmm... That's why I suggested we just use those existing/common signals.
You shouldn't need to check since you can associate one of those functions
with the combined menu entry. If anyone uses the minibuffer to run
help-copyright they'd get the combined dialog. Likewise for help-version
since the associated signals would all be connected to by combined dialog.
> Allan> Hmmm... in fact I'd probably be inclinded to do this for the
> Allan> xforms implementation as well but it's only a cosmetic thing.
>
> I think that, when a particular frontend maintainer identifies a
> change that would make the interface better, we should wonder whether
> this change should be propagated to other arch. This means: let
> frontends have liberty of implementation, but avoid gratuitous differences.
Sure, and that's already been happening a lot which is why Matthias was
complaining about the frontends all looking the same. It's certainly
helped LyX along to have all these people focussing on the UI.
Allan. (ARRae)
