Rob Oakes wrote: >1) the existing Outline/TOC widget (which I'll call the Document Map to >differentiate from the Outliner below), 2) > Corkboard, 3) Outliner.
not good idea to rename it this way - it will cause many confusion in the future discussion. lets have 'outliner' meaning fixed to what it means in the current lyx. devise some other name please. > The outliner incorporates synopsis and perhaps other meta-data (keywords?) > offering a similar metaphor to the corkboard, but for the entire > hierarchical document structure. I foresee the outliner being of use when > first starting a new draft. It would be brilliant to sit down and create a > brain dump of ideas, flesh them out by adding a brief summary of what the > section should say, and have LyX create a document skeleton to which the > text can be added. what i was feared was duplication of the code for our outliner and your new widget for outlining. but as i understand now this is actually intended only as the first design of the document, which only creates the structure. once generated .lyx file it won't do any changes in document structure - ie to let it for 'our' outliner? this would save us for duplicating the code and no need of document <-> 'new' outliner comunication, which i foresee is a quite _lot_ of work. > ** LFUN_OUTLINE_DRAGMOVE ** " i dont see any code related to the actual > moving of the document parts and i'm bit wondering how you want to implement > it through LFUN_OUTLINE_DRAGMOVE, ie how to code the actual movements > through the parameters... " ... > When trying to determine how a drag move should work, there are really two > pieces of relevant information. The first is section which is to be moved, > but the second is where it should be moved to. its maybe more complicated by changing of the depth eg. subsection->section. >I had thought that this > might be passed using the QModelIndex from the TocModel, but was not able to > devise a working solution. I also wasn't sure how a QModelIndex might be > passed as an argument through the existing dispatch system. i dont see any easy solution, thats why i asked ;) > Is there a better way that this might be implemented? the problem is that lfuns were designed to separate gui from the actual work on the document, which goes somewhat against the advanced usage of drag and drop of the document structure. using lfun would probably need invetion of some protocol how to describe the movements and then one magic function which do this structural change inside document (this would be needed anyway one day, we have already in our bug tracker task to drag and drop inside outliner). the second possibility that one touch diretly the document from the ui is not philosophically right and i think that we should aim for kernel/ui separation. >I had hoped to spend > some quality time this evening parsing through the TocModel class to see how > it stores and passes references to the underlying document. In extension, > is there a way to access the document in structure using a system other than > the cursor? lot of work on outliner has been done by Abdel, i hope he would offer some hints or ideas. > ** More on Index Cards ** " those index cards are supposed to be viewable > only inside of the corkboard or they are intended to be normal insets inside > editing window? " > > The index cards represent a way of viewing existing meta-data. At present, > there are two bits that are important to me: 1) the section "title" or > label, 2) the section summary. While I would prefer that the section > summary not be included in the final print document, it might be nice to > have an collapsible inset (similar to the current inset used for notes) > included in the editing window. based on Richard gloss it occured to me that notes could be actually used for your intentions? we already have three types of notes - we could just add the fourth one "Corkboard" or so, which could be switched to from context menu. the advantage would be not so much coding, natural integration with the current insets. the problem is probably that you can have anything inside insets eg math or picture (editation problems inside corkboard) and that there can be many 'cork' notes inside one section. > The patch I sent the other day was the first in that series. But I am > finding the work on the drag/drop and backend to be rather tough going. (In > fairness, the corkboard took nearly two months of spare time to get working > as well.) Any ideas on how to split the overall work load? side note: i dont fully understand the scrivener concept, so take my notes below with some distancei... anyway i would: 1. work on one thing only and don't let be distracted by other ideas/modules until finished to some reasonable state. also note that writing the code is only half of the time - the second half is bugs fixing which would be revealed by the users... 2. start with corkboard for which you already have some code. 3. when you have corkboard ui and its basic backend try to squeeze it into trunk. 4. when doing work on corkboard, make the backend prepared for other enhacements for the other modules, but dont spend time on coding those enhancements. just to have in mind how to enhance it without need to complete rewrite. 5. _conceptual_ things of the new outliner ideas are still bit unclear to me. to debug the current one was lot of work so i'm rather sceptical if you intend to implement new widget which do the same plus something more... it would be good to sort this out before working on backend. iirc Steve Litt was another outliner fan, maybe you can convince him to cooperate on this feature... > guidelines. Any thoughts you might have on the drag-drop or insights into > LyX's dispatch mechanism would also be greatly appreciated. there was some attempt to document dispatch mechanism in our wiki by JMarc, but iirc he didn't finished it. good luck :) pavel
