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<void> 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
