Angus Leeming wrote:
Abdelrazak Younes wrote:
Hang on. My understanding is that all actions from the dialogs must go through
the LFUN dispatch mechanism and that uses strings.
More exactly, an action from a View (a dialog) use a controller method.
The Controller method might (best) or might not use the dispatch
machinery depending on the operation.
Laughs. You've just made that rule up. That's not the law that I operated under.
No, I am just stating a fact. I am hardly the author of all controllers.
As I said: It is _better_ to use an LFUN at controller level and I might
end-up doing this in that case too because we want to reuse the same
LFUN for potential toolbar actions (for alignement, etc). But right now,
I want something that works and I don't want to touch the core (i.e. the
LFUN machinery) now that we are closer to 1.5.0. In 1.5.1 I might
convert the needed controller actions to LFUNs.
When it's absolutely necessary yes. In the case of the Paragraph dialog,
it should be update at each new cursor location. The serialisation is
only good for one-shot dialog showing not for real-time update.
Shrug. Why not. It used to work fine.
Because I don't want the core to _drive the frontend. I want the other
way around: if some dialog needs some information, it _asks_ the core
via the controller. I don't want a dialog that behaves differently
depending on the way you launch it, period.
Besides, this serialisation is really unnecessarily complex and
complicated i.e. hard to understand, i.e. hard to maintain. The simple
fact that nobody dared to fix this bug is a good indicator that
something's wrong with it IMO.
This is not the point in this case. I don't need this data on
initialisation, I need it on _update_
So? Again, this used to work once upon a merry time.
No. See above.
So what exactly are you proposing to change with direct calls?
See patch (not finished),
Well, I'm not in a position to dictate; you're the one writing the code not me.
Right.
However, this turns the philosophy that drove the whole frontend/backend
separation on its head.
Come on, most of my work up to now was about making the separation
happen as opposed to a nice theoretical goal. I believe I have done a
good deal toward this goal already.
The frontends should not touch the core directly at all.
Sure but don't include the controllers in that lot. A controller is
_the_ interface between a dialog and the kernel. If we were to separe
the frontend from the core, the only solution would be to have a Qt4
executable that would use a core dll that includes everything that is in
frontend/ and in frontend/controllers/
That's what the LFUN dispatch mechanism is for.
As I said, I agree with the use of LFUN wherever available. I just don't
agree that there should not be any direct call for _requesting_
information from the core. The Controller _knows_ about the core
structures and classes so we should just use the data in there instead
of converting the data into a string, passing it through some methods
and reconstruct the data in the controller. If we were to do that for
all dialogs, there would be a very strong performance penalty, I am
quite sure of that.
Abdel.
