Allan's Rant Summary:
We can use JMarc's and Asger's single toolbar class (or hierarchy) just
like I said in my last email. The interface that the LyX core sees via
the LyXView is a couple of signals in a manner similar to that currently
used by the Popups class. The two ideas are not incompatible its just a
matter of how much the rest of LyX has to know about toolbars in order to
use them.
The gui-independent support code (mostly from the ToolBarItem class) is
not included in my view of "the rest of LyX" and is not a "LyX core"
functionality. Thus it also is also being hidden by the signals.
Now for the rant...
On Wed, 28 Oct 1998, Jean-Marc Lasgouttes wrote:
> >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> If a toolbar is visible it should be attached to the
> Allan> Popups::updateBufferDependent signal if that's appropriate.
> Allan> Then when this signal is activated (on buffer switch or
> Allan> readonly-toggle) the toolbars update() method would call the
> Allan> various query functions (advocated in a different email) to
> Allan> decide whether a given toolbar button should be greyed out or
> Allan> not. The toolbar implementation doesn't know what's affected
> Allan> until it makes the query.
>
> What I mean is that we could have *one* generic toolbar class which is
> filled by the kernel and is able to handle whatever is put inside
> it. We could suppose that the user has the possibility to define its
> own math toolbar, which contains its favourite symbols. None of the
> toolbar needs to be harcoded. This is a situation which is really
> different from the popups, which cannot really be defined in a
> GUI-independant way.
>
> I really think that every part of the GUI that can be tk-independent
> should be so.
I agree. This is where that paper and pencil and five minutes together
would really help.
We define customisable toolbars supported by all toolkits with a generic
toolbar definition but it isn't necessary for LyX to know anything other
than a signal interface. The backend (which handles the GUI-indep side of
the toolbars and I consider separate from the rest of LyX) handles the
toolbar class you and Asger have been developing. The frontend implements
the drawing of these toolbars.
If the user wants to have a bunch of different toolbars is it really
necessary to display them all at once? As I suggested yesterday one at a
time should be sufficient and then flip through them to get to a different
toolbar. If we have a few standard names like MATH or TABLE for example we
could provide context sensitive toolbars via a very simple signal
interface (the same style of interface used in Popups and also described
yesterday).
Sure, maybe the signals don't belong in Popups they probably belong in
the LyXView gui-implementation (which I'll refer to as Frame for now).
Each Frame would have a similar format to the Popups class: a bunch of
simple signals that allow us full independence from the gui
implementations. This also masks the gui-backend stuff from the rest of
LyX.
> Allan> The Communicator could have a method to retrieve the
> Allan> custom-toolbar settings (or you could go directly to the
> Allan> toolbar backend) and then the frontend builds up the toolbar/s
> Allan> from this.
>
> Yes, indeed such a thing is necessary. I do not know about the signal
> stuff by itself. In a first step, I'll try to devise a simple class
> hierarchy based on what we have, and later we will improve upon that.
>
> Allan> I still don't see a need for special case handling of toolbars
> Allan> within LyX (sure a custom toolbar will be a bit fancier in the
> Allan> frontend than a popup but it doesn't require special treatment
> Allan> by LyX)
>
> If you want to write 3 toolbar classes for 4 different GUIs and
> maintain that, it's fine with me. Howerver, I really think that one
> toolbar class for each tk is really enough.
I've said all along we should be using the one toolbar class hierarchy
that you and Asger have discussed and developed! I'm only arguing about
how the rest of LyX sees the toolbars! toolbars should be seen the same
way popups are: they're aren't! they're invisible to the rest of LyX.
The only bits that need to know about what toolbars look like is the
frontend gui-specific implementation and the gui-independent backend that
provides the support functions for the gui-specific implementations!
The signals I've been talking about hide all the trickery from LyX and
provide a simple signal-based interface to the toolbars.
> Similarly, we do not want
> to hardcode the menus separately for each GUI. We have the possibility
> to avoid it, so why do the same as popups?
Because we are actually getting gui-independence via the signals
interface. We don't have to hardcode the table or maths toolbars and I
didn't say we should (although I may have been a little confusing on that
issue). I said we can use the toolbar system you and Asger have developed
that includes the LyXFunc::Query() to decide if a button should be shown
or not.
I haven't said we shouldn't use one toolbar class ever. All I've argued
is that the interface the rest of LyX sees should be the same or similar
to what LyX currently sees of popups implementation. Which is a couple of
signals in one Popups class.
The idea is you build the ToolBar and ToolBarItem or whatever class
hierarchy that you and Asger have decided upon and it will form the
basis for the gui-backend handling of the gui-frontend. All this code IMO
should be in the frontends/ with the generic ToolBar class/es in the
support/ subdirectory since its common to all gui implementations and
*not* needed as a core LyX functionality. (It's only used by frontends so
it should be in the frontends/)
The interface the rest of LyX should see is a couple of signals to request
viewing of whatever current toolbar the user wants.
If you want to get fancier and allow a user to have multiple toolbars
visible at once then we could modify the signal interface. The most I can
see being necessary is one fixed toolbar the user can select from a list,
and a second toolbar that changes automatically in a context-sensitive
manner. The second toolbar should of course check what type the first
toolbar is so that we don't have two identical toolbars. This of course
means that the default toolbar definitions have names and that for a user
to get correct context-sensitive behaviour they have to use those names
also (or we provide a mechanism to map user toolbar names to contexts).
So each LyXView would then have:
a Frame
with at most two visible customisable ToolBars
(one context sensitive the other chosen by the user)
and two BufferViews (with their own scrollbars) (and status bar?)
and one menu
and one set of popups in the Popups class
*all* of which utilise signals in a manner similar to that already in use
in the Popups class. The toolbar, menu and bufferview signals being
accessed via the Frame class.
Allan. (ARRae)
