Daniel Dekany wrote: > > 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. >
I guess that it is because you do not explicitly select an element in the Document Structure view (I suggest to click on the "chapter", "section", etc, gray, generated content). The position of the caret is highly volatile. If you resize the view containing the caret, this may move it elsewhere in order to always keep it visible. The consequence of this is that the other views are scrolled accordingly. Double-clicking selects a word and, unlike the caret position, text selection and node selection are not volatile. (No, this behavior is not a bug, but I know that some people hate it.) >>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. :) I can easily imagine that. > Can't active the automatic spell checker > though. ;) Yes, I've searched my email folders and found that you have requested this feature a long time ago. > (BTW, excuse me to poke my noise into your business, Not a problem. All ideas are welcome. > 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.) We don't know how to make money with Open Source. I've read many articles about this and never been convinced that the approaches which are suggested would be adapted to XXE. Moreover, we don't know how to write software collaboratively, to use CVS repositories, to merge changes, etc. > > 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), Not on my quad-core QX6700, 4Gb memory, dual 500Gb hard drives configured as RAID 0, NVidia 8800 GTX graphics card. ;-) > 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. > OK, I got it. Thank you.
