Angus, Maybe you'd have some other idea about how to deal with this issue. It's got me very puzzled.
Here's the problem: Suppose the paragraph dialog is open, and the user clicks in a new paragraph. One would expect the dialog to update its settings to reflect the settings in the new paragraph. As things are, however, it doesn't. This is a problem, in part, because the dialog serves not just to allow you to set things but also as a source of information: You want to know what the line spacing is, you look at the dialog. But it gets worse: If you start out in a regular paragraph and click into a list, the "Label width string" field will still be disabled. So the dialog needs to reset itself when the user moves the cursor into a new paragraph (or be made modal, which is what has been done as we look for a better solution). So far as I can tell---I'm hardly an expert on that part of the code, but I've spent a lot of time looking---there's no provision in the extant code for anything like this. I mean, you could certainly have a signal (say, cursorMoved) to which dialogs could attach, but the signal itself can't send the data needed for the update (serialized or otherwise), since it doesn't know what dialogs are attached to it and so doesn't know what data they require. So even if such a signal existed---and such a signal may need to exist for the dialog to behave as it should---the question will still arise: Where does the dialog get the new data? There are some dialogs that do update properly, for example, the table dialog. The reason it works seems to be that it's closely tied to tables, and the tables receive mouse press signals and then update the table dialog. But we do have the same problem elsewhere. The ERT dialog, for example, doesn't update if you click from one ERT into another. That can probably be solved, though, since again the dialog is closely tied to an inset, and the inset knows what data the dialog needs. Best, Richard 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. > > >> 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. > > >> 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. > > >>> 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. However, this turns the philosophy that drove the whole frontend/backend > separation on its head. The frontends should not touch the core directly at > all. That's what the LFUN dispatch mechanism is for. > > Angus > -- ================================================================== Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ ================================================================== Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
