Monday, May 21, 2007, 12:39:23 PM, Hussein Shafie wrote:
> Daniel Dekany wrote: >> There is a need for a clickable ToC for navigating in bigger DocBook >> documents. The "Document structure" CSS seems to be fine for this >> purpose, but it is rather problematic to use for this because of >> GUI-related problems. Basically, you have to go trough this hassle for >> a simple ToC-based jumping: >> >> 1. View -> Add...-> bottom (or top) set to "Document structure". >> This must be repeated once per opening the document. >> >> 2. Enlarge the height of the bottom view by dragging its border. >> >> 3. Double-click on the desired ToC line. > > No need to double click. A single click is sufficient. If I only single-click, then when I resize the window layout frames (by dragging that separator bar between them with mouse), then the center frame has often jumped back to the very beginning of the document. I don't know why... maybe just a bug. >> 4. Decrease the height of the bottom view by dragging its border >> (you don't want the ToC to take any vertical space from the main >> view when you don't "navigate"). >> >> Regarding some tricks involved in this process: >> >> - In 3. if you just click instead of double click, XXE may jumps back >> to the document start when the view is later resized in 4, hence >> spoiling what the whole thing was about. >> >> - The view has to be in top or the bottom slot, and must be enlarged >> vertically before the dobule-clicking, because the selected title >> will be at the bottom of the normal view, while you want it to be at >> the top of it. Now if the normal view is vertically small, and then >> after the double-clicking it is enlarged (4.) then the earlier >> bottom line will become the top line (try it to see why). >> >> So it is nor trivial nor convenient to do. >> >> Further notes: >> >> - Simply choosing the "Document structure" under View and then later >> restore it to "DocBook" is not good, as it is *very* slow for larger >> documents. Especially the switching back to "DocBook". >> >> - Putting the "Document structure" view at left or right and just >> always leaving it there is not good, because that CSS wastes >> horizontal space awfully (quite needlessly BTW -- this may could be >> improved), and thus its frame had to be so wide that no horizontal >> space is left for frame of the norma view on a 1280x1024 monitor. >> Not to mention that the selected title will be at the bottom of the >> normal view, and now the earlier explained vertical resizing trick >> can't be applied. >> >> - I know XXE can be customized and maybe this problem can be solved >> with that (I don't know), but a good *out-of-the-box* DocBook >> editing experience would be important. I'm sure most users just want >> to edit their DocBook (or DITA or XHTML) documents, not learn how to >> customize XXE. > > We have implemented > "Options|Customize Configuration|Save Views As Default" > in XXE Professional Edition v3.6. See > http://www.xmlmind.com/xmleditor/_distrib/doc/help/optionsMenu.html#customizeConfigurationMenu No thanks, I'm a "local guru" as per the XXE documentation... can edit config files by hand. :) Can't active the automatic spell checker though. ;) (BTW, excuse me to poke my noise into your business, but did you guys considered the goal of becoming The de-facto standard documentation editor in Open Source world? I know, it doesn't generate income directly, as most OS projects simply won't use non-free software as their standard tools, but, well, if it will be the standard there (like Eclipse in another field), then it will certainly mean a big increase in the number of XXE adoptions in the commercial world as well. Now allowing automatic spell checking in the free non-commercial-use-only edition would be a *big* push towards becoming the standard OS editor (because again, they usually don't/can't use non-free stuff as "standard" tool). You see, many programmer-types has bad prejudices to WYSIWYG and to the initially unusual approach of XXE, not to mention its perceived slowness, but if they see those wavy red lines, I think a big percentage of them will not able to resist.) > If you prefer to always work with both the styled view and the document > structure view, you need to do (1) and (2) and then "Save Views as > Default" *once* *for* *all*. And, of course, the average user can do > that. > > No need to edit XXE configuration files. > > This being said, the above facility does not solve *all* the usability > problems you have described. I'm sorry but, for now, I have no clue > about how these usability problems you can be solved. In principle what I do with the mouse could be automated and associated to a button on the toolbar. However that's an awkward solution and has performance implication as you have to maintain two views in parallel, despite that you see only one at once. But I guess that this navigation-in-big-XMLs issue is important enough to warrant a generic feature for this purpose. There should be a "navigate" button on the toolbar (in general, not only for DocBook), that would pop up a special minimalist read-only ToC-like view in a big (almost full-screen) popup window where you can click and then the popup window immediately closes and causes the main view(s) to jump to the place where the clicked element is (but that element has to be at the top of the main view(s), not at the bottom of it). Now this navigation view shouldn't be an ordinary XXE view, nothing like a real ToC that require CSS or anything fancy like that, because that's unfortunately too slow with big documents (with XXE 3.6.0 at least), and the point is exactly to quickly navigate in big documents. Instead, optionally one could be able to specify in the xxe file what element types are relevant as far as the navigation view is concerned, and how the text that is shown in the navigation view associated to that element should be extracted (this can be specified with XPath expressions maybe). Then when the navigation view is requested, a Java routine written superficially for navigation view building could easily be able to build the navigation view very quickly, which should simply show the earlier specified elements, one line each, indented as these filtered elements nest into each other, starting with the element name as small gray text followed by the corresponding extracted text in normal size black (just as plain text), and that's it. And there should be vertical indentation level indicator lines like in SciTE. Something like that. Simple, and since it's just about navigation in a big XML node tree, and nothing like WYSIWYG is about, it's certainly good enough for most schemas. -- Best regards, Daniel Dekany
