[oXygen-user] Outline view again

Wed Jan 25 16:46:49 CST 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Excellent! You guys do work fast.

Please do point me to the nightly builds. I'd like to give it a try.

Thanks,
David

On 01/25/2012 01:19 AM, George Cristian Bina wrote:
> Hi David,
> 
> We already changed the implementation for the filtering support in
> the Outliner to remove the children/descendants of a matched node.
> This will go in the next oXygen release but if you want to test it
> using a nightly build just let me know :).
> 
> Best Regards, George -- George Cristian Bina <oXygen/> XML Editor,
> Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
> 
> On 1/20/12 5:39 PM, David Cramer wrote: Hi George, So, I understand
> that it has to show unmatched ancestors if I deselect "Flat
> presentation mode of the filtered results". For example, if I 
> filter on section you would show:
> 
> book chapter section
> 
> I can even live with situations where you have to show something
> like:
> 
> book xinclude chapter section chapter section
> 
> It's inconvenient that the xinclude element adds a level of
> hierarchy to the tree, but I could live with it.
> 
> What does not make sense to me, however, is showing unmatched
> nodes that aren't ancestors of matched nodes. To my mind that's not
> filter, but search/highlight all (btw., for me it highlights even
> unmatched nodes if they are descendants of matched nodes).
> 
> It could be that in fact we need a new view that is based on 
> css+extensions as Wendell suggested, though it seems like adding a 
> switch to hide unmatched leaves in filtered results in the outline 
> view would be a smaller, easier to implement feature.
> 
> Please do continue to explore the issue and consider the
> perspective of writers working on a long document or topic where
> they want to see a nav-pane like table of contents/tree-view of the
> headings without being distracted by other content. I have to say
> it's a limitation I've noticed and more than one writer has
> mentioned it to me.
> 
> Thanks, David
> 
> On 01/20/2012 08:46 AM, George Cristian Bina wrote:
>>>> Hi David,
>>>> 
>>>> We will look into this (early next week) to see what such a
>>>> change means exactly. My previous explanation was not
>>>> complete - also the ancestors of the matched nodes are
>>>> present in the tree. So, right now the tree structure of the
>>>> document is actually preserved, the filtered tree contains
>>>> all the nodes from the document that belong to a path from
>>>> root to a leaf containing a matched node (and the matched
>>>> nodes are rendered with bold). If we show only the matched 
>>>> nodes then the parent/child hierarchy will be not match the
>>>> actual document hierarchy, for example if you match on
>>>> "section" and "para" and you have para elements directly
>>>> inside a section and para elements inside an
>>>> itemizedlist/listitem then these later will be promoted as
>>>> siblings of the former - that may cause some confusion I
>>>> believe...
>>>> 
>>>> Best Regards, George -- George Cristian Bina<oXygen/>  XML
>>>> Editor, Schema Editor and XSLT Editor/Debugger
>>>> http://www.oxygenxml.com
>>>> 
>>>> On 1/20/12 3:11 PM, David Cramer wrote: Ah, I see. It shows
>>>> all descendants if the element has any children that are also
>>>> matched instead of only the children that are matched.
>>>> 
>>>> Is that a change you would consider for a future release?
>>>> 
>>>> Thanks, David
>>>> 
>>>> On 01/20/2012 12:36 AM, George Cristian Bina wrote:
>>>>>>> Hi David,
>>>>>>> 
>>>>>>> What happens in fact it is not that oXygen shows
>>>>>>> siblings of the matched nodes, it shows the children
>>>>>>> and descendants of a node that matches. It seems that
>>>>>>> if we will show the matches without the elements
>>>>>>> children/descendants that will give exactly what you
>>>>>>> want.
>>>>>>> 
>>>>>>> Best Regards, George -- George Cristian Bina<oXygen/>
>>>>>>> XML Editor, Schema Editor and XSLT Editor/Debugger 
>>>>>>> http://www.oxygenxml.com
>>>>>>> 
>>>>>>> On 1/19/12 5:43 PM, David Cramer wrote: Hi there, I
>>>>>>> think I've asked about the Outline view before and it
>>>>>>> seems to be getting more useful, but feedback from
>>>>>>> writers is that it's still exactly what they want.
>>>>>>> 
>>>>>>> When editing a document, it is useful to have a "table
>>>>>>> of contents" view of the document next to the main
>>>>>>> authoring view that provides a synoptic view of the
>>>>>>> document's organization. In oXygen, the Outline view
>>>>>>> comes very close to providing this:
>>>>>>> 
>>>>>>> Given a DocBook document if I filter on "chapter,
>>>>>>> section" then for the typical document, I see just the
>>>>>>> chapters and sections, but the results are a flat list.
>>>>>>> If I  deselect "Flat presentation mode of the filtered
>>>>>>> results" then I have the indented tree view I expect
>>>>>>> BUT I also see elements, PIs, etc that are preceding
>>>>>>> siblings of the sections. For example:
>>>>>>> 
>>>>>>> * chapter Overview of the Foo Server * section
>>>>>>> Understanding the Foo Server Deployment * title Some
>>>>>>> section title * para Why am I seeing this para? * para
>>>>>>> This is noise and clutter ipsum lorem * section Foo
>>>>>>> Server Concepts
>>>>>>> 
>>>>>>> Is there a configuration change I could make to
>>>>>>> eliminate the preceding siblings of the section from
>>>>>>> the Outline view? If there's not, could the behaviors
>>>>>>> of the outline view be adjusted to allow for this use
>>>>>>> case?
>>>>>>> 
>>>>>>> Thanks, David
>>>>>>>> _______________________________________________ 
>>>>>>>> oXygen-user mailing list oXygen-user at oxygenxml.com 
>>>>>>>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
>>>>>>>>
>>>>
>>>>>
>
>>>>>>>> 
>> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPIIZZAAoJEMHeSXG7afUh7woH/jck9nYnoPef3yw2KCPS3STj
jQHA/mkAtBAs0zLL9bACH5mDs76ZQ6pwkH415Jk7JPpKPmzwZXXKYtmyQytIvriZ
sbUt2TF1biF1OqSlSJ888BKGSYkoRVksAtzC/RR0AP8C3fXaj45jW66Mk3prFqNr
dCsGkZqYQyh5CdQzFhnDICJcEjfyPUCLEPk3hxUswzYtIzX+WjgzIuvJ7DZT7Nm/
GHmWXFR6szoQDiJve/Cja72zguwVkeXWnmu7zquaNVOj1gseJa/6VjjmWozpyh56
2sTYLMSqYpRcKsx/WfBmK6MGxITCIj8U1dzVHZUD8yXXsTTLtos/WCuJTM69UiM=
=k/Li
-----END PGP SIGNATURE-----