On 04/20/2013 05:08 PM, Liviu Andronic wrote:
Helge, Pavel, Do you think you could take a look at this student's proposal and give some feedback?
This looks pretty sensible to me. A few comments below.
I think I have a rough idea as to how can we implement the layout editor, in Lyx I have made a Qt prototype http://postimg.org/image/j9g22xphx/ described as below! **********GUI*********** Available Additions : A QComboBox used to choose from a list of available options "ClassOptions" , "Paragraph styles", "Floats", "Flex insets and InsetLayout", "Counters", "Font description", and their possible suboptions like a "Paragraph style" can have "Font Description" as its subtype Layout elements: A QListWidget containing the new Class elements "ClassOptions" , "Paragraph styles", "Floats", "Flex insets and InsetLayout", "Counters", "Font description". The user will select any one of them and he will be shown the available options in the element specifics section. for e.g if the user chooses "Paragraph styles" then he would be shown with options like "Align", "BottomSep", "Copy Style" etc. as much as possible without any coding stuff, this would be shown in layout specifics section. Layout specifics: It will contain yet another QListWidget which would display the suboptions which are possible to add into it, and it will have Values section as each option will have to take values like number, color, option etc. some type of values might be common while others might be unique to the option, which would be shown to the user appropriately.
One other question here is: In what form do we want to represent this information within LyX? I.e., what the options are, etc? How much of that is already in the code? Most of it, presumably, though not in a usable form. I.e., Layout::parskip is declared as a double. But I don't know if that helps us in any way.
Layout Preview: It is a QGraphicsWidget which will try to display in as much capacity as possible the combined look showing the usage of every layout element created, added or edited. For eg if I created two paragraph styles, style1 and style2 then it will show two sentences instantiating the styles.
This is useful, but I'd definitely leave it myself for the very end. Just being able to edit stuff is the first issue.
Layout file: section would be meant for advanced users to directly modify the code, or add some Latex stuff to their liking.
There are two cases here: (i) a layout file is loaded that is in a system directory. In that case, the modified file will have to be written to the user directory; (ii) the file is loaded from the user dir, in which case it gets written back there.
Probably it should also be possible to load the "local layout", and modify that will the layout editor.
There is a complication here somewhere in the fact that our layout files "cascade" the way CSS does. I.e., you can load a Chapter style from one file, then modify it in another, etc. I'm not sure why this might cause problems, but I am guessing it will pop up somewhere.
******BACKEND****** The backend structure which would be supporting the GUI would have the simple task of parsing the .layout file based on the layout elements created by the user listed in the Layout Elements List. Implementation of this can be done in the following way: ->We create a class LayoutElements and then introduce methods in it which would parse it into lines of code readable to a .layout file.
Note that we already have systems of reading and, more recently, or writing TextClass, Layout, InsetLayout, etc, objects. Probably the backend can just use these. I.e., the layout editor, when it wants to read a layout file, module, whatever, just creates a new TextClass object and calls its read() method. Then the editor can operate with this object, and its various Layout, InsetLayout, etc, bits. It may even be useful to add methods to these objects for use by the editor. Writing the new info may then be as easy as calling the some sort of write() method, which I can't now find. But there are some issues there, I expect.
Richard
