Abdelrazak Younes wrote:
I am also in the opinion that the kernel should be _completely_
ignorant of the dialogs. So all dialog updates called from the insets
etc should disappear. All opened dialogs will updated themselves by
asking proper questions to the kernel.
Hm.
How would the dialogs know when to ask, then? How would the table dialog
know that the cursor moved to a different table column, a different table,
or completely out of any table?
The kernel need to tell somehow. We can't have every dialog polling for
changes, a horrible overhead. A simple signal that cause every open
dialog to check for changes also has overhead - usually only a few
dialogs/toolbars change if any.
Telling the dialog(s) in question (via a function call) seems reasonable
enough.
If you want to make it very generic, consider having the dialogs registering
callbacks with the kernel. Efficient, but lots of work achieving little
more
than simple function calls. :-/
Helge Hafting
Isn't this M-V-C thingy about making maintanance easier? If so, how come
that a simple dialog needs 3(!) extra classes (spilled on 6 files in 2
directories, no less...)?
Something went awfully wrong here as far as I can tell...
I am glad that someone joins me there :-)
I propose that we discuss this when 1.6 time comes.
Abdel.
