Hussein Shafie escribi?:
> Philippe Nobili wrote:
>> When editing DocBook documents, we usually use the raw XML view on the
>> left in combination with the styled (central) view; it is especially
>> useful for beginners who are lost with the DocBook very rich set of
>> elements and sometimes complex hierarchical structure.
>
> I'm sorry but we fundamentally don't agree on this. Having the tree view
> very rarely helps. The node path bar is sufficient to understand to
> structure of the document, whatever the complexity of the structure.
Please let's me desagree. There are cases (other that mentioned at the end
of this post) where the tree view really helps. In particular when
correcting (slightly) invalid documents imported from foreing sources.
IMHO, this is a weak side of XEE.
>
>>
>> Currently (up to version 4.0.0), it is not easy to locate the caret or
>> a selected element simultaneously in both views. We think that with
>> little modifications the synchronization between these views could be
>> made more efficient and help our editors a lot:
>>
>> 1) When scrolling one of the two view, keep the top element in sync in
>> both views; this would be clearer than the current behavior.
>> 2) When position the caret in one the views, or selecting an element,
>> made both selections or carets appear at the same horizontal position
>> in both views
>>
>
> I'm sorry but XMLmind XML Editor has not been designed to be used with
> both the tree view and the styled view side by side. It is unlikely that
> we ever improve the synchronizations of the views.
>
> If we really wanted to do that, the best solution would be to get rid of
> the tree view (which is just a ``normal view'' having no CSS style
> sheet) and replace it with a specialized, highly optimized for the task,
> pane similar to those found in all the other structured document editors.
Perhaps a perfect synchronization of styled and nonstyled views is neither
neccesary nor easy to achieve. But a better automatic scrolling policy
would certainly help:
- When just navigating by moving the caret, keep always the caret visible.
Most time both views will sychronize at the top or the bottom of the viewport.
- When extending the text or element selection, keep the whole selection
visible if it fits inside the viewport. Again, most time both views will be
in adequate synchronism.
- If the selected region doesn't fit inside the vieport, at least keep the
caret visible in both views, like in the first point.
The current behaviour it to keep the caret visible in most cases, but do
not force the whole selection to be visible, event if there is enough room
for it.
>
> ---
> PS:
>
> --> We have implemented the possibility of having several views of the
> same document in a single window just to show off ("pour la frime", en
> Fran?ais).
>
> In practice, we don't think this feature is really useful...Except from
> time to time:
>
> * the tree view: show me the code of the <svg> element currently
> displayed as a graphic, show me the structure of the XHTML <select>
> element currently displayed as a list control, etc.
>
> * DocBook's document structure view: demote/promote chapters and sections.
>
> --> The tree view alone is useful when a CSS style sheet has not been
> developed for a document type and/or when it does not make sense to
> develop one. For example: one of my colleagues routinely uses the tree
> view of XXE to view and edit XSL-FO elements.
In any case. I find XXE really useful. And we will never thanks you enough
for allowing it to be used for free for personal work. So thanks!
--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado
