Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes ha scritto:
Basically, the main stated plan for the 1.6 branch is switching our
file format to some correctly formed xml. There is already some
proof-of-concept code to do that in a branch. This will force us to
have a more unified way to access the parameters, and I was arguing
that we could _maybe_ leverage this for dialog/kernel interaction.
Many thanx for the explanations to everybody.
From what I understood, it seems
there is no actual reason for having inside LyX xml-based
or string-based interactions among MVC components,
if it is possible to have (model's typed) object-based interactions.
For example, when view event handlers activate controllers,
these may perform direct invokations of the model functionality
through using direct parameters passing. Actually, in order to
preserve the possibility of catching the functionality dispatch
request in multiple points of the code, it is useful to have a
base FuncRequest class encapsulating any type of request.
IMHO, such class (or a related one e.g. FuncParams) could be
subclassed by various functionality in order to add to the
structure as many params as needed by the single functionality.
Somewhere else, the dispatching code will retrieve those params
from such structure and activate the functionality through the
model-API specifically created for it.
Example:
[in the model]
find(docstring string_to_find, bool casesensitive, bool whatever);
[in the dispatching framework]
class FuncRequestFind : public FuncRequest {
public:
FuncRequestFind(..., string_to_find, bool casesensitive, bool whatever);
docstring string_to_find;
bool casesensitive;
bool whatever;
virtual void dispatch() {
find(this->string_to_find, this->casesensitive, this->whatever);
}
}
[in the controller]
SearchController::onFindNext() {
docstring string_to_find;
bool casesensitive;
bool whatever;
request_dispatch_of(new FuncRequestFind(..., string_to_find,
casesensitive, whatever);
}
This would avoid the unnecessary overhead of serializing/deserializing
these parameters all the time. Despite the simple find example, if the
number of params grows or if they are numeric, or just if the parser
wants to be very sure about syntax for robustness purposes (e.g.
parsing from the command-buffer or from the command-line, we don't
want segfault if the user types a wrong syntax), parsing
them may become heavy. I can't even imagine having an xml-writer and
an xml-parser and validator being activated for each and every key press
or button press while using LyX.
In addition, the possibility of having string-based or xml-based
serialization/deserialization of these parameters and the existence
of a FuncRequest dispatching mechanism adds the possibility
to invoke such functionalities *also* by other means, for example:
- from the command buffer
- from an external script
- from a remote client
All you need, in this case, is to add a standard
serialization/deserialization
mechanism to the base FuncRequest class, and override the serialization
methods in the subclasses, e.g.
FuncRequestFind::serialize(iostream & s) { // maybe XMLIOStream &
parent::serialize(s);
s.serialize(string_to_find);
s.serialize(casesensitive);
s.serialize(whatever);
}
This is just to stress that I hope the model will not start exporting
only functions that take a serialized form of params. That would be
too bad (imho) -- unless I'm missing smth.
T.
Re: FuncRequest/dispatch goals
Bo Peng ha scritto: It would be discussed after 1.5.0 but ODF may be steered too much to WYSIWYG (single character and paragraph styles etc) to be used by Isn't LyX already moving towards supporting custom paragraph styles ? I saw a Paragraph Settings dialog (and actually I'm a little bit concerned about the meaning of its existence: shouldn't customization of a single paragraph be forbidden, in favour of customization of a style ?). Anyway, xml2xml translation will just be a matter of writing a (guess complex) transformation stylesheet. T. -- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://feanor.sssup.it/~tommaso
Re: FuncRequest/dispatch goals
On Wed, Jul 11, 2007 at 11:36:52AM +0200, Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: > >>"Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: > > > >Tommaso> What about the OO OpenDocument xml format ? Would it be too > >Tommaso> complex for LyX ? > > > >The lyx document format is supposed to reflect what LyX is able to > >handle. I am not sure ODF is usable, since we have no plan to > >implement openoffice on top of LyX :) > > This does not mean we should not reuse the same tags as ODF. But as Lars > said once, we can modify the tags later. > > > > >Tommaso> Plus, what about maths ? Would they be represented as smth. > >Tommaso> like MathML instead of plain LaTeX that you have now ? > > > >I think there are problems related to that (latex (and lyx) LyX is > >more on the presentational side). > > The main problem is that mathml is bloody verbose. I think you can now > embed TeX math in ODF too. Having math in 'tex' and text in 'lyx' is the only reason why text-in-math does not properly work. If 'lyx' is replaced by 'xml', math should go the same route. Andre'
Re: FuncRequest/dispatch goals
What about the OO OpenDocument xml format ? Would it be too complex for LyX ? It would be discussed after 1.5.0 but ODF may be steered too much to WYSIWYG (single character and paragraph styles etc) to be used by lyx/latex. However, being able to embed figures, and having an internal exporter to ODF would be extremely helpful to lyx.. More after 1.5.0. Bo
Re: FuncRequest/dispatch goals
On Wednesday 11 July 2007 10:30:47 Jean-Marc Lasgouttes wrote: > Tommaso> Plus, what about maths ? Would they be represented as smth. > Tommaso> like MathML instead of plain LaTeX that you have now ? > > I think there are problems related to that (latex (and lyx) LyX is > more on the presentational side). MathML supports both methods (presentational and content) although I think you can't mix them (reasonable IMHO). > JMarc -- José Abílio
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes wrote: "Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: Tommaso> What about the OO OpenDocument xml format ? Would it be too Tommaso> complex for LyX ? The lyx document format is supposed to reflect what LyX is able to handle. I am not sure ODF is usable, since we have no plan to implement openoffice on top of LyX :) This does not mean we should not reuse the same tags as ODF. But as Lars said once, we can modify the tags later. Tommaso> Plus, what about maths ? Would they be represented as smth. Tommaso> like MathML instead of plain LaTeX that you have now ? I think there are problems related to that (latex (and lyx) LyX is more on the presentational side). The main problem is that mathml is bloody verbose. I think you can now embed TeX math in ODF too. Abdel.
Re: FuncRequest/dispatch goals
> "Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: Tommaso> What about the OO OpenDocument xml format ? Would it be too Tommaso> complex for LyX ? The lyx document format is supposed to reflect what LyX is able to handle. I am not sure ODF is usable, since we have no plan to implement openoffice on top of LyX :) Tommaso> Also, reading about these ideas to have an all-in-one Tommaso> container file format, I'm wondering if, at the end, you Tommaso> won't end up into an xml spec that is someway similar to Tommaso> that. Maybe. Tommaso> Plus, what about maths ? Would they be represented as smth. Tommaso> like MathML instead of plain LaTeX that you have now ? I think there are problems related to that (latex (and lyx) LyX is more on the presentational side). JMarc
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes ha scritto: Basically, the main stated plan for the 1.6 branch is switching our file format to some correctly formed xml. There is already some proof-of-concept code to do that in a branch. This will force us to What about the OO OpenDocument xml format ? Would it be too complex for LyX ? Also, reading about these ideas to have an all-in-one container file format, I'm wondering if, at the end, you won't end up into an xml spec that is someway similar to that. Plus, what about maths ? Would they be represented as smth. like MathML instead of plain LaTeX that you have now ? T. -- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://feanor.sssup.it/~tommaso
Re: FuncRequest/dispatch goals
> "Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: Tommaso> Jean-Marc Lasgouttes ha scritto: >> Except if this serialization can be merged with the writing of the >> xml parameters once we switch to that. In this case, the thing >> would make more sense (and allow to define bindings to tune >> individual parameters). >> Tommaso> Is it possible to have brief description of what is this Tommaso> "writing of XML params" (or just a pointer to archived mail Tommaso> or wiki page, if any) ? Basically, the main stated plan for the 1.6 branch is switching our file format to some correctly formed xml. There is already some proof-of-concept code to do that in a branch. This will force us to have a more unified way to access the parameters, and I was arguing that we could _maybe_ leverage this for dialog/kernel interaction. Since we are not very organised people, there is no wiki to see. You can try to search for XML in the archives or look at this branch: http://www.lyx.org/trac/browser/lyx-devel/branches/personal/larsbj/xml However, I relaize now that this will probably not be very useful for dialogs like search/replace which are not related to the file format. JMarc
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes ha scritto: Except if this serialization can be merged with the writing of the xml parameters once we switch to that. In this case, the thing would make more sense (and allow to define bindings to tune individual parameters). Is it possible to have brief description of what is this "writing of XML params" (or just a pointer to archived mail or wiki page, if any) ? Thanks, bye, T.
Re: FuncRequest/dispatch goals
On Tue, Jul 10, 2007 at 06:39:30PM +0200, Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: > >>"Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: > > > >Tommaso> While this could be useful to allow activation of the > >Tommaso> functionality from the action buffer or a script, why don't > >Tommaso> just call the method, instead, from the GUI classes ? > > > >This was part of the Model/View/Controller separation of the code. The > >idea was that the controllers should only use lfuns instead of direct > >code. I am not very sure myself that this is useful. > > I personally think the use of LFUN to request a change is fine and > useful; useful because it forces us to think about how to design the > LFUN in a GUI independent way (when it applies). It could be a plain library interface nevertheless. The string based interface is useful for the LyX server, but that's not in active widesprecd use. > What I personally dislike (I should probably say "hate" ;-)) and what I > intent to change in 1.6 is the serialization used in order to retrieve > information from the core (the initParam() and such). That's plain stupid indeed. Andre'
Re: FuncRequest/dispatch goals
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> We don't need XML to sanitize a the format of the passed Abdelrazak> string, we could do that now using Abdelrazak> requests. I mean that we will do XML in any case, and this could be merged with the serialization stuff. Abdelrazak> But I object that this is needed at all, we have a fine Abdelrazak> in-memory Buffer structure and we should use that. This Abdelrazak> serialization is the number one reason why the LyX dialogs Abdelrazak> are so hard to modify for beginners. I agree with that. JMarc
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> What I personally dislike (I should probably say "hate" Abdelrazak> ;-)) and what I intent to change in 1.6 is the Abdelrazak> serialization used in order to retrieve information from Abdelrazak> the core (the initParam() and such). For retrieving Abdelrazak> information we should use direct calls like what is done Abdelrazak> in the Outline dialog, the Tabular dialog etc. Except if this serialization can be merged with the writing of the xml parameters once we switch to that. In this case, the thing would make more sense (and allow to define bindings to tune individual parameters). We don't need XML to sanitize a the format of the passed string, we could do that now using requests. But I object that this is needed at all, we have a fine in-memory Buffer structure and we should use that. This serialization is the number one reason why the LyX dialogs are so hard to modify for beginners. I've programmed a lot in property based languages (MATLAB GUIDE) and I much prefer the Qt C++ way. Abdel.
Re: FuncRequest/dispatch goals
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> What I personally dislike (I should probably say "hate" Abdelrazak> ;-)) and what I intent to change in 1.6 is the Abdelrazak> serialization used in order to retrieve information from Abdelrazak> the core (the initParam() and such). For retrieving Abdelrazak> information we should use direct calls like what is done Abdelrazak> in the Outline dialog, the Tabular dialog etc. Except if this serialization can be merged with the writing of the xml parameters once we switch to that. In this case, the thing would make more sense (and allow to define bindings to tune individual parameters). JMarc
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes wrote: "Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: Tommaso> While this could be useful to allow activation of the Tommaso> functionality from the action buffer or a script, why don't Tommaso> just call the method, instead, from the GUI classes ? This was part of the Model/View/Controller separation of the code. The idea was that the controllers should only use lfuns instead of direct code. I am not very sure myself that this is useful. I personally think the use of LFUN to request a change is fine and useful; useful because it forces us to think about how to design the LFUN in a GUI independent way (when it applies). What I personally dislike (I should probably say "hate" ;-)) and what I intent to change in 1.6 is the serialization used in order to retrieve information from the core (the initParam() and such). For retrieving information we should use direct calls like what is done in the Outline dialog, the Tabular dialog etc. Abdel.
Re: FuncRequest/dispatch goals
> "Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: Tommaso> While this could be useful to allow activation of the Tommaso> functionality from the action buffer or a script, why don't Tommaso> just call the method, instead, from the GUI classes ? This was part of the Model/View/Controller separation of the code. The idea was that the controllers should only use lfuns instead of direct code. I am not very sure myself that this is useful. JMarc
Re: FuncRequest/dispatch goals
On 7/10/07, Tommaso Cucinotta <[EMAIL PROTECTED]> wrote: Hi, as a newbie of the LyX code, I'm just curious about the purpose of the FuncRequest/dispatch mechanism. Specifically, it is not clear to me why from the GUI some functions produce a formatted text string that is dispatched through a FuncRequest object, for being parsed later somewhere else in the code, and finally result into a method call (e.g. LFUN_WORD_FIND, in files ControlSearch.cpp, LyxAction.cpp, LyXFunc.cpp, lyxfind.cpp). While this could be useful to allow activation of the functionality from the action buffer or a script, why don't just call the method, instead, from the GUI classes ? insets, text, gui may handle the same LFUN in different ways under different situations. If you trace a LFUN, you can sometimes see 'get a message, if a condition is met, process and mark this lfun as dispatched, otherwise, pass this lfun untouched to someone else'. Cheers, Bo
