Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

 "Marko" == Marko Vendelin [EMAIL PROTECTED] writes:

Marko Another possibility is to use exactly the same interface for
Marko toolbar and menubar. Then the set of toolbars will be presented
Marko by first level submenus, buttons in the toolbars --- by
Marko commands in submenus, and comboboxen by sub-submenus. Easy and
Marko as configurable as menubars are. Kernel will just call
Marko toolbar-update() and menubar-update() and there will be only
Marko one toolbar object to call by the kernel.

Using the submenu interface for combox is certainly a very good idea!

Marko do you really want to see flashing toolbars depending on where
Marko you are in the document? I think that usually people fix the
Marko toolbars and these toolbars don't change much. I might be wrong
Marko --- there are no toolbars in my gnu emacs at all.

It's not me who wanted toolbars to appear depending on cursor position
:) Note that the frontend would be free to ignore that, or condition
it on some config switch. It is just that the hook would be there.

 - combox: currently, there is only one possible combox, the layout
 combox. Will we need more of them, and which ones?

Marko You might want to have any command in the combox (emphasize,
Marko \Large, TOC, style). This is easy to implement using menu
Marko structure.

Yes.

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 9 Feb 2001, Jean-Marc Lasgouttes wrote:

 It's not me who wanted toolbars to appear depending on cursor position
 :) 

hey, it's not me either ! I just wanted the possibility of context-sensitive stuff.

 Note that the frontend would be free to ignore that, or condition
 it on some config switch. It is just that the hook would be there.
 

I'm becoming increasingly unsure on exactly where we disagree :))

john

-- 
"Brodie, he's a reasonable man, but he's *insane* !"
- Kramer

Re: Can we remove the code for references in menus?

[Allan Rae]

On Fri, 9 Feb 2001, John Levon wrote:

 On 9 Feb 2001, Jean-Marc Lasgouttes wrote:

  It's not me who wanted toolbars to appear depending on cursor position
  :)

 hey, it's not me either ! I just wanted the possibility of
 context-sensitive stuff.

It would seem none of you have ever used Lotus Ami Pro 3.1 (the only
"word-processor" I've ever considered worth using, circa 1992).  It has
multiple, context-sensitive, user-configurable toolbars, that can be
manually "rotated" like a James Bond number plate (or a Blender toolbar
but not as confusing).  And Ami Pro had a similar philosophy for style
sheets (although it provided WYSIWYG and did it's own typesetting)

  Note that the frontend would be free to ignore that, or condition
  it on some config switch. It is just that the hook would be there.

 I'm becoming increasingly unsure on exactly where we disagree :))

Note that even if it was configured to be always visible the toolbar could
still use the feedback provided by the signal to de/activate buttons or
change current entries in comboxes etc. as appropriate.

Allan. (ARRae)

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:

Marko> Another possibility is to use exactly the same interface for
Marko> toolbar and menubar. Then the set of toolbars will be presented
Marko> by first level submenus, buttons in the toolbars --- by
Marko> commands in submenus, and comboboxen by sub-submenus. Easy and
Marko> as configurable as menubars are. Kernel will just call
Marko> toolbar->update() and menubar->update() and there will be only
Marko> one toolbar object to call by the kernel.

Using the submenu interface for combox is certainly a very good idea!

Marko> do you really want to see flashing toolbars depending on where
Marko> you are in the document? I think that usually people fix the
Marko> toolbars and these toolbars don't change much. I might be wrong
Marko> --- there are no toolbars in my gnu emacs at all.

It's not me who wanted toolbars to appear depending on cursor position
:) Note that the frontend would be free to ignore that, or condition
it on some config switch. It is just that the hook would be there.

>> - combox: currently, there is only one possible combox, the layout
>> combox. Will we need more of them, and which ones?

Marko> You might want to have any command in the combox (emphasize,
Marko> \Large, TOC, style). This is easy to implement using menu
Marko> structure.

Yes.

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 9 Feb 2001, Jean-Marc Lasgouttes wrote:

> It's not me who wanted toolbars to appear depending on cursor position
> :) 

hey, it's not me either ! I just wanted the possibility of context-sensitive stuff.

> Note that the frontend would be free to ignore that, or condition
> it on some config switch. It is just that the hook would be there.
> 

I'm becoming increasingly unsure on exactly where we disagree :))

john

-- 
"Brodie, he's a reasonable man, but he's *insane* !"
- Kramer

Re: Can we remove the code for references in menus?

[Allan Rae]

On Fri, 9 Feb 2001, John Levon wrote:

> On 9 Feb 2001, Jean-Marc Lasgouttes wrote:
>
> > It's not me who wanted toolbars to appear depending on cursor position
> > :)
>
> hey, it's not me either ! I just wanted the possibility of
> context-sensitive stuff.

It would seem none of you have ever used Lotus Ami Pro 3.1 (the only
"word-processor" I've ever considered worth using, circa 1992).  It has
multiple, context-sensitive, user-configurable toolbars, that can be
manually "rotated" like a James Bond number plate (or a Blender toolbar
but not as confusing).  And Ami Pro had a similar philosophy for style
sheets (although it provided WYSIWYG and did it's own typesetting)

> > Note that the frontend would be free to ignore that, or condition
> > it on some config switch. It is just that the hook would be there.
>
> I'm becoming increasingly unsure on exactly where we disagree :))

Note that even if it was configured to be always visible the toolbar could
still use the feedback provided by the signal to de/activate buttons or
change current entries in comboxes etc. as appropriate.

Allan. (ARRae)

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

 "Marko" == Marko Vendelin [EMAIL PROTECTED] writes:

Marko There is another silly example when this signal is needed ---
Marko one might have TOC in the toolbar with chapters showing up as a
Marko buttons. I am not sure who would like to have this feature, but
Marko the point is that kernel has no idea how the lists are
Marko presented to the user (dialog, menu, toolbar, or just written
Marko to the serial port). 

An example which may be a bit less silly is to have chapters shown as
tabs, or as a tree on the left of the document.

JMarc

Re: Can we remove the code for references in menus?

[Allan Rae]

On 8 Feb 2001, Jean-Marc Lasgouttes wrote:

  "Marko" == Marko Vendelin [EMAIL PROTECTED] writes:

 Marko There is another silly example when this signal is needed ---
 Marko one might have TOC in the toolbar with chapters showing up as a
 Marko buttons. I am not sure who would like to have this feature, but
 Marko the point is that kernel has no idea how the lists are
 Marko presented to the user (dialog, menu, toolbar, or just written
 Marko to the serial port).

 An example which may be a bit less silly is to have chapters shown as
 tabs, or as a tree on the left of the document.

Implementation details.  Anyway you look at it there are a myriad of
possibilities.

Allan. (ARRae)

Re: Can we remove the code for references in menus?

[John Levon]

On Thu, 8 Feb 2001, Allan Rae wrote:

  Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?
 
 Why all lists?  If a figure inset is changed then an LOF-signal could be
 sent and so on.

As far as I can tell this kind of "document mutated" medium-grained signal is what
I've been arguing for ...

john

-- 
"The HP-UX CC compiler cannot handle two consecutive semicolons. It is a silly 
compiler."
- kdeveloper.org

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:

Marko> There is another silly example when this signal is needed ---
Marko> one might have TOC in the toolbar with chapters showing up as a
Marko> buttons. I am not sure who would like to have this feature, but
Marko> the point is that kernel has no idea how the lists are
Marko> presented to the user (dialog, menu, toolbar, or just written
Marko> to the serial port). 

An example which may be a bit less silly is to have chapters shown as
tabs, or as a tree on the left of the document.

JMarc

Re: Can we remove the code for references in menus?

[Allan Rae]

On 8 Feb 2001, Jean-Marc Lasgouttes wrote:

> > "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:
>
> Marko> There is another silly example when this signal is needed ---
> Marko> one might have TOC in the toolbar with chapters showing up as a
> Marko> buttons. I am not sure who would like to have this feature, but
> Marko> the point is that kernel has no idea how the lists are
> Marko> presented to the user (dialog, menu, toolbar, or just written
> Marko> to the serial port).
>
> An example which may be a bit less silly is to have chapters shown as
> tabs, or as a tree on the left of the document.

Implementation details.  Anyway you look at it there are a myriad of
possibilities.

Allan. (ARRae)

Re: Can we remove the code for references in menus?

[John Levon]

On Thu, 8 Feb 2001, Allan Rae wrote:

> > Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?
> 
> Why all lists?  If a figure inset is changed then an LOF-signal could be
> sent and so on.

As far as I can tell this kind of "document mutated" medium-grained signal is what
I've been arguing for ...

john

-- 
"The HP-UX CC compiler cannot handle two consecutive semicolons. It is a silly 
compiler."
- kdeveloper.org

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

 "John" == John Levon [EMAIL PROTECTED] writes:
John So I must update every dynamic menu/toolbar item on every
John update(). OK, I suppose that's not too bad. But what is it
John you're actually informing the frontend of ? It seems that the
John current examples are just about buffer switches/opens/closes.
John Why not call them bufferOpened(), etc. ? Why the vague
John "update()" ?

It might be: "the cursor moved, maybe you should update the checkboxes
for font settings" or anything. In fact it is called when LyX waits
for input, so maybe nothing intresting happened, but I believe the
computational cost is small. Now, I do not think that we should add
checks and signals all over the kernel code to cover all possibilities.

John How would your method cope with a number of different toolbars
John for different things ? Do you call update() on each one ? Why
John not just let the frontend decide what needs updating - why not
John just tell it what changed ?

What I envision is enhancing the toolbar code to have several named
toolbars, like current menus. Then add methods show/hide for named
toolbars. The toolbars would have generic names like "math",
"tabular", etc. A dumb implementation like xforms could chose to
ignore these calls. Better ones would do the right thing.

John it still makes for ugly parsing code whilst reading the menus
John in. maybe it would still be ugly, perhaps you're right here ...

What parsing code? Where?

John But the frontend doesn't deal in functions. It deals in GUI
John objects, which may have the ability to Dispatch() when operated.
John How can the kernel code possibility cater for the differences
John between the xforms and the KDE frontend, when say, a maths area
John is entered by the cursor ?

What action do you have in mind besides poping a toolbar?

John if need be we can have different default.ui files if you still
John think the kernel code should be the master of the frontends in
John the manner you describe

I thin kthe menu/toolbar frontends should be as dumb as possible and
should not have too much LyX-related trickery. If you have a nice idea
about what your frontend could do which is not covered by the
interface, then it seems reasonable to implement this feature in GUI-I
fashion so that other implemtations can do it too. I believe that
menu/toolbar stuff is simple enough for that to be possible.

John Of course, and that's the killer problem in your scheme - you
John can't know about the differences between the frontends in the
John kernel code ! You may be able to alter Edit-Table, but you
John forgot the Table dialog, and the table toolbar - hold on,
John they're not in this GUI - etc.

The kernel calls methods to enable/disable them, and the frontend is
free to ignore them.

John I don't see how you could do this in a nice way, without
John essentially implementing my suggested scheme :

John   Signal0void enteredTableArea;

toolbar-show("tabular");

 _except_ for the TOC case, which deserves a special treatment with
 some signals. This is another reason why I want to remove the refs
 stuff, which is the other special case.

John but they are not the only special cases: essentially everything
John is a special case.

Could you elaborate? I agree that the xforms code is ugly. But this is
mostly because there is no reasonable menubar/toolbar objects in
xforms. I believe that writing a frontend for KDE equivalent to the
xforms one will be trivial. The real problem is probably in the extra
functionality you want. Could list the kind of nice things you want to do?

I understand that, as a frontend writer, you feel that you will be
restrained in what you can do because there is a common architecture
you are bound to. However, I really think that it is possible to build
such an architecture which will be good enough to allow all this
customization to be done by the _user_. And to me, allowing the user
to decide what his interface will do is much better than allowing the
implementor to play nice tricks (as long as we can provide enough
customisability in GUI-I fashion).

Actually, there are things that I do not really know how to handle in
toolbars:

- combox: currently, there is only one possible combox, the layout
  combox. Will we need more of them, and which ones?

- math toolbar: the math panel provides bmtables. How is that
  implemented in KLyX? I do not know how to descibe this in a
  reasonable way.

Also, in menus, there is the problem of updating intelligently the
TOC (because it could cost time to do it too often). However this
problem would also arise if you had complete control on the menus. A
solution has to be devised, maybe with signals.

Finally, my main problem is that I do not have time to work on this
right now, so if I cannot convince you to work from the current
scheme, I'll have to give up :( 

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 7 Feb 2001, Jean-Marc Lasgouttes wrote:

 Finally, my main problem is that I do not have time to work on this
 right now, so if I cannot convince you to work from the current
 scheme, I'll have to give up :( 

I only happened to mention it in passing really. I really need to sit down and
think hard about this. I was a little rash yesterday; I think we agree on
more than it seems.

The solution for now is to postpone this discussion until I have really hammered
on the problem (and Kalle et al !). Currently the work of moving and implementing
dialogs is priority.

Given infinite time, I would like to do these fairly major works :

1) "finish" the GUI-I work. Dialogs, Menus, Toolbars, and then - the really hard bit 
...
2) Lars' logical character styles. IMHO this is a very important interface issue
3) Spreadsheet-style table handles
4) lyxfunc reworking [1]

That's what I really care about ...

thanks
john

[1] Lars, there would only be one file auto-generated now after our tete-a-tete, and
that's the initialiser for the lyxfuncs ... does that change your opinion on the 
auto-gen
at all :))

-- 
"Beware of bugs in the above code; I have only proved it correct, not tried it."
- Donald Knuth

Re: Can we remove the code for references in menus?

[Lars Gullik Bjønnes]

John Levon [EMAIL PROTECTED] writes:



| [1] Lars, there would only be one file auto-generated now after our
| tete-a-tete, and 
| that's the initialiser for the lyxfuncs ... does that change your
| opinion on the auto-gen 
| at all :))

Slightly :-)

Lgb

Re: Can we remove the code for references in menus?

[Marko Vendelin]

Hi!

On 7 Feb 2001, Jean-Marc Lasgouttes wrote:

  "John" == John Levon [EMAIL PROTECTED] writes:
 John So I must update every dynamic menu/toolbar item on every
 John update(). OK, I suppose that's not too bad. But what is it
 John you're actually informing the frontend of ? It seems that the
 John current examples are just about buffer switches/opens/closes.
 John Why not call them bufferOpened(), etc. ? Why the vague
 John "update()" ?
 
 It might be: "the cursor moved, maybe you should update the checkboxes
 for font settings" or anything. In fact it is called when LyX waits
 for input, so maybe nothing intresting happened, but I believe the
 computational cost is small. Now, I do not think that we should add
 checks and signals all over the kernel code to cover all possibilities.

This is the way it is implemented in Gnome frontend. As far as I can
see the overhead is indeed minimal. However, I haven't profiled it...


 John How would your method cope with a number of different toolbars
 John for different things ? Do you call update() on each one ? Why
 John not just let the frontend decide what needs updating - why not
 John just tell it what changed ?
 
 What I envision is enhancing the toolbar code to have several named
 toolbars, like current menus. Then add methods show/hide for named
 toolbars. The toolbars would have generic names like "math",
 "tabular", etc. A dumb implementation like xforms could chose to
 ignore these calls. Better ones would do the right thing.

Another possibility is to use exactly the same interface for toolbar and
menubar. Then the set of toolbars will be presented by first level
submenus, buttons in the toolbars --- by commands in submenus, and
comboboxen by sub-submenus. Easy and as configurable as menubars
are. Kernel will just call toolbar-update() and menubar-update() and
there will be only one toolbar object to call by the kernel.


[...]
 John I don't see how you could do this in a nice way, without
 John essentially implementing my suggested scheme :
 
 John Signal0void enteredTableArea;
 
 toolbar-show("tabular");

do you really want to see flashing toolbars depending on where you are in
the document? I think that usually people fix the toolbars and these
toolbars don't change much. I might be wrong --- there are no toolbars in
my gnu emacs at all.


  _except_ for the TOC case, which deserves a special treatment with
  some signals. This is another reason why I want to remove the refs
  stuff, which is the other special case.

Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?


[...]

 Actually, there are things that I do not really know how to handle in
 toolbars:
 
 - combox: currently, there is only one possible combox, the layout
   combox. Will we need more of them, and which ones?

You might want to have any command in the combox (emphasize, \Large, TOC,
style). This is easy to implement using menu structure.


 Also, in menus, there is the problem of updating intelligently the
 TOC (because it could cost time to do it too often). However this
 problem would also arise if you had complete control on the menus. A
 solution has to be devised, maybe with signals.

Signal would be nice.

Marko

Re: Can we remove the code for references in menus?

[Allan Rae]

Still to read the full thread but skimming a couple I can add these
comments:

On Wed, 7 Feb 2001, Marko Vendelin wrote:
[...]
  John How would your method cope with a number of different toolbars
  John for different things ? Do you call update() on each one ? Why
  John not just let the frontend decide what needs updating - why not
  John just tell it what changed ?
 
  What I envision is enhancing the toolbar code to have several named
  toolbars, like current menus. Then add methods show/hide for named
  toolbars. The toolbars would have generic names like "math",
  "tabular", etc. A dumb implementation like xforms could chose to
  ignore these calls. Better ones would do the right thing.

 Another possibility is to use exactly the same interface for toolbar and
 menubar.

Or toolbar and dialogs as I keep saying...

 Then the set of toolbars will be presented by first level
 submenus, buttons in the toolbars --- by commands in submenus, and
 comboboxen by sub-submenus. Easy and as configurable as menubars
 are. Kernel will just call toolbar-update() and menubar-update() and
 there will be only one toolbar object to call by the kernel.

and only emit the appropriate signal which can be shared between different
implementations of the same thing...

 [...]
  John I don't see how you could do this in a nice way, without
  John essentially implementing my suggested scheme :
 
  John   Signal0void enteredTableArea;
 
  toolbar-show("tabular");

 do you really want to see flashing toolbars depending on where you are in
 the document? I think that usually people fix the toolbars and these
 toolbars don't change much. I might be wrong --- there are no toolbars in
 my gnu emacs at all.

You all seem to have missed the fact that tables already have an update
signal for the dialog and that triggers changes in the dialog when the
cursor moves around the cells.  A table toolbar is just a different form
of this dialog and so there is no point in adding a toolbar specific
signal when the table dialog one already exists.  That's part of the
reason why I keep trying to get you blokes to see that toolbars are just
the same as dialogs.  They are built differently [initialisation] but they
look the same to the kernel and can share the same signals.

   _except_ for the TOC case, which deserves a special treatment with
   some signals. This is another reason why I want to remove the refs
   stuff, which is the other special case.

 Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?

Why all lists?  If a figure inset is changed then an LOF-signal could be
sent and so on.

  Also, in menus, there is the problem of updating intelligently the
  TOC (because it could cost time to do it too often). However this
  problem would also arise if you had complete control on the menus. A
  solution has to be devised, maybe with signals.

 Signal would be nice.

I still think this should be triggered by the frontend -- sure I know the
tear-off menu arguement and there is probably a need for a specific signal
for that but you should only need to update the TOC when it's accessed.
A torn-off menu however would want to be updated by a signal (since it
would look like the existing TOC dialog).

Allan. (ARRae)

Re: Can we remove the code for references in menus?

[Marko Vendelin]

On Thu, 8 Feb 2001, Allan Rae wrote:

 On Wed, 7 Feb 2001, Marko Vendelin wrote:
 [...]
   John How would your method cope with a number of different toolbars
   John for different things ? Do you call update() on each one ? Why
   John not just let the frontend decide what needs updating - why not
   John just tell it what changed ?
  
   What I envision is enhancing the toolbar code to have several named
   toolbars, like current menus. Then add methods show/hide for named
   toolbars. The toolbars would have generic names like "math",
   "tabular", etc. A dumb implementation like xforms could chose to
   ignore these calls. Better ones would do the right thing.
 
  Another possibility is to use exactly the same interface for toolbar and
  menubar.
 
 Or toolbar and dialogs as I keep saying...

We can also use dialogs interface for menubar too. The only difference
which I see in current implementation of dialogs VS menubar is that
menubar is user-configurable and dialogs are hard-coded. I guess, we would
like to keep the user settings for toolbars too. If we treat toolbars
and menubars as dialogs then the only parameter which is required to build
these objects is menubar or toolbar name defined in .lyxrc files. This
name can be passed by InsetCommand, if I am not missing something.


[...]

  do you really want to see flashing toolbars depending on where you are in
  the document? I think that usually people fix the toolbars and these
  toolbars don't change much. I might be wrong --- there are no toolbars in
  my gnu emacs at all.
 
 You all seem to have missed the fact that tables already have an update
 signal for the dialog and that triggers changes in the dialog when the
 cursor moves around the cells.  A table toolbar is just a different form
 of this dialog and so there is no point in adding a toolbar specific
 signal when the table dialog one already exists.  That's part of the
 reason why I keep trying to get you blokes to see that toolbars are just
 the same as dialogs.  They are built differently [initialisation] but they
 look the same to the kernel and can share the same signals.
 
_except_ for the TOC case, which deserves a special treatment with
some signals. This is another reason why I want to remove the refs
stuff, which is the other special case.
 
  Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?
 
 Why all lists?  If a figure inset is changed then an LOF-signal could be
 sent and so on.

Even better.


   Also, in menus, there is the problem of updating intelligently the
   TOC (because it could cost time to do it too often). However this
   problem would also arise if you had complete control on the menus. A
   solution has to be devised, maybe with signals.
 
  Signal would be nice.
 
 I still think this should be triggered by the frontend -- sure I know the
 tear-off menu arguement and there is probably a need for a specific signal
 for that but you should only need to update the TOC when it's accessed.
 A torn-off menu however would want to be updated by a signal (since it
 would look like the existing TOC dialog).

There is another silly example when this signal is needed --- one might
have TOC in the toolbar with chapters showing up as a buttons. I am not
sure who would like to have this feature, but the point is that kernel
has no idea how the lists are presented to the user (dialog, menu,
toolbar, or just written to the serial port). In the case of TOC written
to the serial port we even don't have any "Refresh" button to press or the
frontend will have to take care for processing input from serial console
too.

Marko

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> So I must update every dynamic menu/toolbar item on every
John> update(). OK, I suppose that's not too bad. But what is it
John> you're actually informing the frontend of ? It seems that the
John> current examples are just about buffer switches/opens/closes.
John> Why not call them bufferOpened(), etc. ? Why the vague
John> "update()" ?

It might be: "the cursor moved, maybe you should update the checkboxes
for font settings" or anything. In fact it is called when LyX waits
for input, so maybe nothing intresting happened, but I believe the
computational cost is small. Now, I do not think that we should add
checks and signals all over the kernel code to cover all possibilities.

John> How would your method cope with a number of different toolbars
John> for different things ? Do you call update() on each one ? Why
John> not just let the frontend decide what needs updating - why not
John> just tell it what changed ?

What I envision is enhancing the toolbar code to have several named
toolbars, like current menus. Then add methods show/hide for named
toolbars. The toolbars would have generic names like "math",
"tabular", etc. A dumb implementation like xforms could chose to
ignore these calls. Better ones would do the right thing.

John> it still makes for ugly parsing code whilst reading the menus
John> in. maybe it would still be ugly, perhaps you're right here ...

What parsing code? Where?

John> But the frontend doesn't deal in functions. It deals in GUI
John> objects, which may have the ability to Dispatch() when operated.
John> How can the kernel code possibility cater for the differences
John> between the xforms and the KDE frontend, when say, a maths area
John> is entered by the cursor ?

What action do you have in mind besides poping a toolbar?

John> if need be we can have different default.ui files if you still
John> think the kernel code should be the master of the frontends in
John> the manner you describe

I thin kthe menu/toolbar frontends should be as dumb as possible and
should not have too much LyX-related trickery. If you have a nice idea
about what your frontend could do which is not covered by the
interface, then it seems reasonable to implement this feature in GUI-I
fashion so that other implemtations can do it too. I believe that
menu/toolbar stuff is simple enough for that to be possible.

John> Of course, and that's the killer problem in your scheme - you
John> can't know about the differences between the frontends in the
John> kernel code ! You may be able to alter Edit->Table, but you
John> forgot the Table dialog, and the table toolbar - hold on,
John> they're not in this GUI - etc.

The kernel calls methods to enable/disable them, and the frontend is
free to ignore them.

John> I don't see how you could do this in a nice way, without
John> essentially implementing my suggested scheme :

John>   Signal0 enteredTableArea;

toolbar->show("tabular");

>> _except_ for the TOC case, which deserves a special treatment with
>> some signals. This is another reason why I want to remove the refs
>> stuff, which is the other special case.

John> but they are not the only special cases: essentially everything
John> is a special case.

Could you elaborate? I agree that the xforms code is ugly. But this is
mostly because there is no reasonable menubar/toolbar objects in
xforms. I believe that writing a frontend for KDE equivalent to the
xforms one will be trivial. The real problem is probably in the extra
functionality you want. Could list the kind of nice things you want to do?

I understand that, as a frontend writer, you feel that you will be
restrained in what you can do because there is a common architecture
you are bound to. However, I really think that it is possible to build
such an architecture which will be good enough to allow all this
customization to be done by the _user_. And to me, allowing the user
to decide what his interface will do is much better than allowing the
implementor to play nice tricks (as long as we can provide enough
customisability in GUI-I fashion).

Actually, there are things that I do not really know how to handle in
toolbars:

- combox: currently, there is only one possible combox, the layout
  combox. Will we need more of them, and which ones?

- math toolbar: the math panel provides bmtables. How is that
  implemented in KLyX? I do not know how to descibe this in a
  reasonable way.

Also, in menus, there is the problem of updating intelligently the
TOC (because it could cost time to do it too often). However this
problem would also arise if you had complete control on the menus. A
solution has to be devised, maybe with signals.

Finally, my main problem is that I do not have time to work on this
right now, so if I cannot convince you to work from the current
scheme, I'll have to give up :( 

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 7 Feb 2001, Jean-Marc Lasgouttes wrote:

> Finally, my main problem is that I do not have time to work on this
> right now, so if I cannot convince you to work from the current
> scheme, I'll have to give up :( 

I only happened to mention it in passing really. I really need to sit down and
think hard about this. I was a little rash yesterday; I think we agree on
more than it seems.

The solution for now is to postpone this discussion until I have really hammered
on the problem (and Kalle et al !). Currently the work of moving and implementing
dialogs is priority.

Given infinite time, I would like to do these fairly major works :

1) "finish" the GUI-I work. Dialogs, Menus, Toolbars, and then - the really hard bit 
...
2) Lars' logical character styles. IMHO this is a very important interface issue
3) Spreadsheet-style table handles
4) lyxfunc reworking [1]

That's what I really care about ...

thanks
john

[1] Lars, there would only be one file auto-generated now after our tete-a-tete, and
that's the initialiser for the lyxfuncs ... does that change your opinion on the 
auto-gen
at all :))

-- 
"Beware of bugs in the above code; I have only proved it correct, not tried it."
- Donald Knuth

Re: Can we remove the code for references in menus?

[Lars Gullik Bjønnes]

John Levon <[EMAIL PROTECTED]> writes:



| [1] Lars, there would only be one file auto-generated now after our
| tete-a-tete, and 
| that's the initialiser for the lyxfuncs ... does that change your
| opinion on the auto-gen 
| at all :))

Slightly :-)

Lgb

Re: Can we remove the code for references in menus?

[Marko Vendelin]

Hi!

On 7 Feb 2001, Jean-Marc Lasgouttes wrote:

> > "John" == John Levon <[EMAIL PROTECTED]> writes:
> John> So I must update every dynamic menu/toolbar item on every
> John> update(). OK, I suppose that's not too bad. But what is it
> John> you're actually informing the frontend of ? It seems that the
> John> current examples are just about buffer switches/opens/closes.
> John> Why not call them bufferOpened(), etc. ? Why the vague
> John> "update()" ?
> 
> It might be: "the cursor moved, maybe you should update the checkboxes
> for font settings" or anything. In fact it is called when LyX waits
> for input, so maybe nothing intresting happened, but I believe the
> computational cost is small. Now, I do not think that we should add
> checks and signals all over the kernel code to cover all possibilities.

This is the way it is implemented in Gnome frontend. As far as I can
see the overhead is indeed minimal. However, I haven't profiled it...


> John> How would your method cope with a number of different toolbars
> John> for different things ? Do you call update() on each one ? Why
> John> not just let the frontend decide what needs updating - why not
> John> just tell it what changed ?
> 
> What I envision is enhancing the toolbar code to have several named
> toolbars, like current menus. Then add methods show/hide for named
> toolbars. The toolbars would have generic names like "math",
> "tabular", etc. A dumb implementation like xforms could chose to
> ignore these calls. Better ones would do the right thing.

Another possibility is to use exactly the same interface for toolbar and
menubar. Then the set of toolbars will be presented by first level
submenus, buttons in the toolbars --- by commands in submenus, and
comboboxen by sub-submenus. Easy and as configurable as menubars
are. Kernel will just call toolbar->update() and menubar->update() and
there will be only one toolbar object to call by the kernel.


[...]
> John> I don't see how you could do this in a nice way, without
> John> essentially implementing my suggested scheme :
> 
> John> Signal0 enteredTableArea;
> 
> toolbar->show("tabular");

do you really want to see flashing toolbars depending on where you are in
the document? I think that usually people fix the toolbars and these
toolbars don't change much. I might be wrong --- there are no toolbars in
my gnu emacs at all.


> >> _except_ for the TOC case, which deserves a special treatment with
> >> some signals. This is another reason why I want to remove the refs
> >> stuff, which is the other special case.

Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?


[...]

> Actually, there are things that I do not really know how to handle in
> toolbars:
> 
> - combox: currently, there is only one possible combox, the layout
>   combox. Will we need more of them, and which ones?

You might want to have any command in the combox (emphasize, \Large, TOC,
style). This is easy to implement using menu structure.


> Also, in menus, there is the problem of updating intelligently the
> TOC (because it could cost time to do it too often). However this
> problem would also arise if you had complete control on the menus. A
> solution has to be devised, maybe with signals.

Signal would be nice.

Marko

Re: Can we remove the code for references in menus?

[Allan Rae]

Still to read the full thread but skimming a couple I can add these
comments:

On Wed, 7 Feb 2001, Marko Vendelin wrote:
[...]
> > John> How would your method cope with a number of different toolbars
> > John> for different things ? Do you call update() on each one ? Why
> > John> not just let the frontend decide what needs updating - why not
> > John> just tell it what changed ?
> >
> > What I envision is enhancing the toolbar code to have several named
> > toolbars, like current menus. Then add methods show/hide for named
> > toolbars. The toolbars would have generic names like "math",
> > "tabular", etc. A dumb implementation like xforms could chose to
> > ignore these calls. Better ones would do the right thing.
>
> Another possibility is to use exactly the same interface for toolbar and
> menubar.

Or toolbar and dialogs as I keep saying...

> Then the set of toolbars will be presented by first level
> submenus, buttons in the toolbars --- by commands in submenus, and
> comboboxen by sub-submenus. Easy and as configurable as menubars
> are. Kernel will just call toolbar->update() and menubar->update() and
> there will be only one toolbar object to call by the kernel.

and only emit the appropriate signal which can be shared between different
implementations of the same thing...

> [...]
> > John> I don't see how you could do this in a nice way, without
> > John> essentially implementing my suggested scheme :
> >
> > John>   Signal0 enteredTableArea;
> >
> > toolbar->show("tabular");
>
> do you really want to see flashing toolbars depending on where you are in
> the document? I think that usually people fix the toolbars and these
> toolbars don't change much. I might be wrong --- there are no toolbars in
> my gnu emacs at all.

You all seem to have missed the fact that tables already have an update
signal for the dialog and that triggers changes in the dialog when the
cursor moves around the cells.  A table toolbar is just a different form
of this dialog and so there is no point in adding a toolbar specific
signal when the table dialog one already exists.  That's part of the
reason why I keep trying to get you blokes to see that toolbars are just
the same as dialogs.  They are built differently [initialisation] but they
look the same to the kernel and can share the same signals.

> > >> _except_ for the TOC case, which deserves a special treatment with
> > >> some signals. This is another reason why I want to remove the refs
> > >> stuff, which is the other special case.
>
> Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?

Why all lists?  If a figure inset is changed then an LOF-signal could be
sent and so on.

> > Also, in menus, there is the problem of updating intelligently the
> > TOC (because it could cost time to do it too often). However this
> > problem would also arise if you had complete control on the menus. A
> > solution has to be devised, maybe with signals.
>
> Signal would be nice.

I still think this should be triggered by the frontend -- sure I know the
tear-off menu arguement and there is probably a need for a specific signal
for that but you should only need to update the TOC when it's accessed.
A torn-off menu however would want to be updated by a signal (since it
would look like the existing TOC dialog).

Allan. (ARRae)

Re: Can we remove the code for references in menus?

[Marko Vendelin]

On Thu, 8 Feb 2001, Allan Rae wrote:

> On Wed, 7 Feb 2001, Marko Vendelin wrote:
> [...]
> > > John> How would your method cope with a number of different toolbars
> > > John> for different things ? Do you call update() on each one ? Why
> > > John> not just let the frontend decide what needs updating - why not
> > > John> just tell it what changed ?
> > >
> > > What I envision is enhancing the toolbar code to have several named
> > > toolbars, like current menus. Then add methods show/hide for named
> > > toolbars. The toolbars would have generic names like "math",
> > > "tabular", etc. A dumb implementation like xforms could chose to
> > > ignore these calls. Better ones would do the right thing.
> >
> > Another possibility is to use exactly the same interface for toolbar and
> > menubar.
> 
> Or toolbar and dialogs as I keep saying...

We can also use dialogs interface for menubar too. The only difference
which I see in current implementation of dialogs VS menubar is that
menubar is user-configurable and dialogs are hard-coded. I guess, we would
like to keep the user settings for toolbars too. If we treat toolbars
and menubars as dialogs then the only parameter which is required to build
these objects is menubar or toolbar name defined in .lyxrc files. This
name can be passed by InsetCommand, if I am not missing something.


[...]

> > do you really want to see flashing toolbars depending on where you are in
> > the document? I think that usually people fix the toolbars and these
> > toolbars don't change much. I might be wrong --- there are no toolbars in
> > my gnu emacs at all.
> 
> You all seem to have missed the fact that tables already have an update
> signal for the dialog and that triggers changes in the dialog when the
> cursor moves around the cells.  A table toolbar is just a different form
> of this dialog and so there is no point in adding a toolbar specific
> signal when the table dialog one already exists.  That's part of the
> reason why I keep trying to get you blokes to see that toolbars are just
> the same as dialogs.  They are built differently [initialisation] but they
> look the same to the kernel and can share the same signals.
> 
> > > >> _except_ for the TOC case, which deserves a special treatment with
> > > >> some signals. This is another reason why I want to remove the refs
> > > >> stuff, which is the other special case.
> >
> > Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?
> 
> Why all lists?  If a figure inset is changed then an LOF-signal could be
> sent and so on.

Even better.


> > > Also, in menus, there is the problem of updating intelligently the
> > > TOC (because it could cost time to do it too often). However this
> > > problem would also arise if you had complete control on the menus. A
> > > solution has to be devised, maybe with signals.
> >
> > Signal would be nice.
> 
> I still think this should be triggered by the frontend -- sure I know the
> tear-off menu arguement and there is probably a need for a specific signal
> for that but you should only need to update the TOC when it's accessed.
> A torn-off menu however would want to be updated by a signal (since it
> would look like the existing TOC dialog).

There is another silly example when this signal is needed --- one might
have TOC in the toolbar with chapters showing up as a buttons. I am not
sure who would like to have this feature, but the point is that kernel
has no idea how the lists are presented to the user (dialog, menu,
toolbar, or just written to the serial port). In the case of TOC written
to the serial port we even don't have any "Refresh" button to press or the
frontend will have to take care for processing input from serial console
too.

Marko

Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

The subject says it all. Removing this code would simplify things,
really.

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 6 Feb 2001, Jean-Marc Lasgouttes wrote:

 
 The subject says it all. Removing this code would simplify things,
 really.
 
 JMarc

Simplify what exactly ? The core code ? If it's just the menu code, well
that needs totally reworking anyway...

john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

 "John" == John Levon [EMAIL PROTECTED] writes:

John Simplify what exactly ? The core code ? If it's just the menu
John code, well that needs totally reworking anyway...

It would give us (at least me) a better view of the code. Removing it
is as simple as doing a big cut in the xforms code and afew small cuts
in the rest. I agree a rework would be necessary. We have to know
however what "special types" the menus should have.

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 6 Feb 2001, Jean-Marc Lasgouttes wrote:

  "John" == John Levon [EMAIL PROTECTED] writes:
 
 John Simplify what exactly ? The core code ? If it's just the menu
 John code, well that needs totally reworking anyway...
 
 It would give us (at least me) a better view of the code. 

OK

 in the rest. I agree a rework would be necessary. We have to know
 however what "special types" the menus should have.

I've spent some time thinking about the menu stuff a couple of months
ago. It is an icky problem really; I'm definitely leaning towards having
all item-creation / default.ui parsing in each frontend, and only having
meaningful signals like :

Signal1void, const string fileOpened;

or similar.

john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

 "John" == John Levon [EMAIL PROTECTED] writes:

John I've spent some time thinking about the menu stuff a couple of
John months ago. It is an icky problem really; I'm definitely leaning
John towards having all item-creation / default.ui parsing in each
John frontend, and only having meaningful signals like :

John   Signal1void, const string fileOpened;

John or similar.

What will you be able to do in KDE that you cannot do right now? 

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 6 Feb 2001, Jean-Marc Lasgouttes wrote:

  "John" == John Levon [EMAIL PROTECTED] writes:
 
 John I've spent some time thinking about the menu stuff a couple of
 John months ago. It is an icky problem really; I'm definitely leaning
 John towards having all item-creation / default.ui parsing in each
 John frontend, and only having meaningful signals like :
 
 John Signal1void, const string fileOpened;
 
 John or similar.
 
 What will you be able to do in KDE that you cannot do right now? 

Not generate a dynamic menu every time it's called (theoretically, the
hookes needed in kernel are simple in some cases, more complicated in
others)

Not have to mess around with the two menubar thing which is awkward to
interpret

Have specific toolbars that change depending on the mutating document and
transient properties (e.g. position). It shouldn't be the kernel's
responsibility to manage these sets, simply because they can differ
between frontends. IMHO these changes should be told to the frontends, and
then it is their responsibility to act

Organisation of menus according to relevant standards (possibly)

Simpler code

As simple as possible handling of the special cases :

  | Dynamic | Static
---
BufferDependent   | References, TOC | N/A
---
BufferIndependent | Lastfiles, Documents| *Formats


But Kalle is the one to ask really, he's the GUI whizz and he had a go at
the Qt2 menubar before

thanks
john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Re: Can we remove the code for references in menus?

[John Levon]

On 6 Feb 2001, Jean-Marc Lasgouttes wrote:

  "John" == John Levon [EMAIL PROTECTED] writes:
 
 John Not generate a dynamic menu every time it's called
 John (theoretically, the hookes needed in kernel are simple in some
 John cases, more complicated in others)
 
 You can generate the menus at Menubar::set or Menubar::update time (it
 is just not convenient with xforms). The kernel does not care about
 what you do when the different methods are called.

So I must update every dynamic menu/toolbar item on every update(). OK, I
suppose that's not too bad. But what is it you're actually informing
the frontend of ? It seems that the current examples are just about
buffer switches/opens/closes. Why not call them bufferOpened(), etc. ?
Why the vague "update()" ?

How would your method cope with a number of different toolbars for
different things ? Do you call update() on each one ? Why not just let
the frontend decide what needs updating - why not just tell it what
changed ?

 The two menubar thing is a choice of the interface. You could also
 choose to ignore them :) We build the menubars explicitely in xforms
 because everything should be done by hand. You do not need to do that.

it still makes for ugly parsing code whilst reading the menus in. maybe
it would still be ugly, perhaps you're right here ...

 It is the kernel responsability to tell what functions are available
 at a given moment. Concerning a change of toolbars, I agree that one
 or two signals would be useful.

But the frontend doesn't deal in functions. It deals in GUI objects, which
may have the ability to Dispatch() when operated. How can the kernel code
possibility cater for the differences between the xforms and the KDE
frontend, when say, a maths area is entered by the cursor ?

 That is indeed a problem. We should see what the conflicts are before
 deciding what we need.

if need be we can have different default.ui files if you still think the
kernel code should be the master of the frontends in the manner you
describe

 John Simpler code
 
 I'm not sure about that.

me neither :)

 John As simple as possible handling of the special cases :
 
 John   | Dynamic | Static
 John ---
 John BufferDependent | References, TOC | N/A
 John ---
 John BufferIndependent | Lastfiles, Documents| *Formats
 
 The dynamis vs. static distinction is not as simple:
 
 - there can be some things which appear/disappear depending on
   document type and cursor position (with OptItem). This can be useful
   when you want to replace EditTable with EditFigure depending on
   where the cursor stands.

Of course, and that's the killer problem in your scheme - you can't know
about the differences between the frontends in the kernel code ! You may
be able to alter Edit-Table, but you forgot the Table dialog, and the
table toolbar - hold on, they're not in this GUI - etc.

I don't see how you could do this in a nice way, without essentially
implementing my suggested scheme :

Signal0void enteredTableArea;

 - I think that basically, even if you rebuild the menus at each
   update, or before showing it (which is the most pessimistic case),
   you have mostly no performance penalty, 

I'm not bothered about performance, it is avoiding ugly code where at all
possible

   _except_ for the TOC case,
   which deserves a special treatment with some signals. This is
   another reason why I want to remove the refs stuff, which is the
   other special case.

but they are not the only special cases: essentially everything is a
special case.


All IMHO of course :)

thanks
john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

The subject says it all. Removing this code would simplify things,
really.

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 6 Feb 2001, Jean-Marc Lasgouttes wrote:

> 
> The subject says it all. Removing this code would simplify things,
> really.
> 
> JMarc

Simplify what exactly ? The core code ? If it's just the menu code, well
that needs totally reworking anyway...

john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

> "John" == John Levon <[EMAIL PROTECTED]> writes:

John> Simplify what exactly ? The core code ? If it's just the menu
John> code, well that needs totally reworking anyway...

It would give us (at least me) a better view of the code. Removing it
is as simple as doing a big cut in the xforms code and afew small cuts
in the rest. I agree a rework would be necessary. We have to know
however what "special types" the menus should have.

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 6 Feb 2001, Jean-Marc Lasgouttes wrote:

> > "John" == John Levon <[EMAIL PROTECTED]> writes:
> 
> John> Simplify what exactly ? The core code ? If it's just the menu
> John> code, well that needs totally reworking anyway...
> 
> It would give us (at least me) a better view of the code. 

OK

> in the rest. I agree a rework would be necessary. We have to know
> however what "special types" the menus should have.

I've spent some time thinking about the menu stuff a couple of months
ago. It is an icky problem really; I'm definitely leaning towards having
all item-creation / default.ui parsing in each frontend, and only having
meaningful signals like :

Signal1 fileOpened;

or similar.

john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Re: Can we remove the code for references in menus?

[Jean-Marc Lasgouttes]

> "John" == John Levon <[EMAIL PROTECTED]> writes:

John> I've spent some time thinking about the menu stuff a couple of
John> months ago. It is an icky problem really; I'm definitely leaning
John> towards having all item-creation / default.ui parsing in each
John> frontend, and only having meaningful signals like :

John>   Signal1 fileOpened;

John> or similar.

What will you be able to do in KDE that you cannot do right now? 

JMarc

Re: Can we remove the code for references in menus?

[John Levon]

On 6 Feb 2001, Jean-Marc Lasgouttes wrote:

> > "John" == John Levon <[EMAIL PROTECTED]> writes:
> 
> John> I've spent some time thinking about the menu stuff a couple of
> John> months ago. It is an icky problem really; I'm definitely leaning
> John> towards having all item-creation / default.ui parsing in each
> John> frontend, and only having meaningful signals like :
> 
> John> Signal1 fileOpened;
> 
> John> or similar.
> 
> What will you be able to do in KDE that you cannot do right now? 

Not generate a dynamic menu every time it's called (theoretically, the
hookes needed in kernel are simple in some cases, more complicated in
others)

Not have to mess around with the two menubar thing which is awkward to
interpret

Have specific toolbars that change depending on the mutating document and
transient properties (e.g. position). It shouldn't be the kernel's
responsibility to manage these sets, simply because they can differ
between frontends. IMHO these changes should be told to the frontends, and
then it is their responsibility to act

Organisation of menus according to relevant standards (possibly)

Simpler code

As simple as possible handling of the special cases :

  | Dynamic | Static
---
BufferDependent   | References, TOC | N/A
---
BufferIndependent | Lastfiles, Documents| *Formats


But Kalle is the one to ask really, he's the GUI whizz and he had a go at
the Qt2 menubar before

thanks
john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Re: Can we remove the code for references in menus?

[John Levon]

On 6 Feb 2001, Jean-Marc Lasgouttes wrote:

> > "John" == John Levon <[EMAIL PROTECTED]> writes:
> 
> John> Not generate a dynamic menu every time it's called
> John> (theoretically, the hookes needed in kernel are simple in some
> John> cases, more complicated in others)
> 
> You can generate the menus at Menubar::set or Menubar::update time (it
> is just not convenient with xforms). The kernel does not care about
> what you do when the different methods are called.

So I must update every dynamic menu/toolbar item on every update(). OK, I
suppose that's not too bad. But what is it you're actually informing
the frontend of ? It seems that the current examples are just about
buffer switches/opens/closes. Why not call them bufferOpened(), etc. ?
Why the vague "update()" ?

How would your method cope with a number of different toolbars for
different things ? Do you call update() on each one ? Why not just let
the frontend decide what needs updating - why not just tell it what
changed ?

> The two menubar thing is a choice of the interface. You could also
> choose to ignore them :) We build the menubars explicitely in xforms
> because everything should be done by hand. You do not need to do that.

it still makes for ugly parsing code whilst reading the menus in. maybe
it would still be ugly, perhaps you're right here ...

> It is the kernel responsability to tell what functions are available
> at a given moment. Concerning a change of toolbars, I agree that one
> or two signals would be useful.

But the frontend doesn't deal in functions. It deals in GUI objects, which
may have the ability to Dispatch() when operated. How can the kernel code
possibility cater for the differences between the xforms and the KDE
frontend, when say, a maths area is entered by the cursor ?

> That is indeed a problem. We should see what the conflicts are before
> deciding what we need.

if need be we can have different default.ui files if you still think the
kernel code should be the master of the frontends in the manner you
describe

> John> Simpler code
> 
> I'm not sure about that.

me neither :)

> John> As simple as possible handling of the special cases :
> 
> John>   | Dynamic | Static
> John> ---
> John> BufferDependent | References, TOC | N/A
> John> ---
> John> BufferIndependent | Lastfiles, Documents| *Formats
> 
> The dynamis vs. static distinction is not as simple:
> 
> - there can be some things which appear/disappear depending on
>   document type and cursor position (with OptItem). This can be useful
>   when you want to replace Edit>Table with Edit>Figure depending on
>   where the cursor stands.

Of course, and that's the killer problem in your scheme - you can't know
about the differences between the frontends in the kernel code ! You may
be able to alter Edit->Table, but you forgot the Table dialog, and the
table toolbar - hold on, they're not in this GUI - etc.

I don't see how you could do this in a nice way, without essentially
implementing my suggested scheme :

Signal0 enteredTableArea;

> - I think that basically, even if you rebuild the menus at each
>   update, or before showing it (which is the most pessimistic case),
>   you have mostly no performance penalty, 

I'm not bothered about performance, it is avoiding ugly code where at all
possible

>   _except_ for the TOC case,
>   which deserves a special treatment with some signals. This is
>   another reason why I want to remove the refs stuff, which is the
>   other special case.

but they are not the only special cases: essentially everything is a
special case.


All IMHO of course :)

thanks
john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester