Outline view again
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPGDoQAAoJEMHeSXG7afUhRIQH/0y03DCeYsc6SuWM2kt3q2/c B7VgNeVdEGZY5alT21nXcexJR1w7aJQp4q7LHUp/bdcH/p6hkRLa0Pb0pRRMa9x9 GlKHvdRC8OcmYc/iSoml45b2zZ0zsIa9fqaaKFpoyJtrhPO9gsrLX1nEe/J18vyD wUSyzWGbjuv1C6pSedwLtePNGPsu7CJUFu4kh+elmjbDCfLGUP6ZUWRCAxWAF2uO EGg1O22sOZj85jvDVmjGnv19ZhZr4QKnY5jwF4QNU+OmwpILY9f0c4B0vMiZ5uUe /N1o3L661jyoaXAE6NDq+xBQvC9LCz7sQsH4a09yrDs9fcomQ9KvmoOdxydCDKQ= =YAD0 -----END PGP SIGNATURE-----
Dear David, It's not the same as being able to configure the outline view (which is an intriguing idea), but one thing I have done is make a distinct CSS stylesheet just for a ToC rendition of the document. Of course this gives you all the flexibility of CSS including hiding things, and can be done right away. Switching between two or more CSS renditions is a feature oXygen has had for a while. Additionally, in its CSS support, oXygen includes several extensions including a 'foldable' property that allows a user to expand and collapse arbitrary blocks of the document, while keeping certain element children visible. So you can collapse/expand sections while keeping their titles in view, for example. Tailoring a user interface for the needs of users (each of whom is an individual with personal quirks and preferences) is certainly an art. At least one competitor to oXygen (which I haven't used in a while) allows the outline view to be styled with its own CSS. While this is good as far as it goes, it has a down side, in that it hides the straight unenhanced outline view, which is also nice to have. Maybe what we need is not more configuration of the outline view, but a way to view the same document with two (or more) different CSS stylesheets in different windows (along with, probably, the ability to harness their cursor positions together, or not). Cheers, Wendell On 1/19/2012 10:43 AM, 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?
-- ====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Wendell, Thanks for the suggestion. In fact, I've done that before to address this complaint and will probably do it again as a stop-gap measure, but as you point out, it doesn't quite meet the need. The user wants to be able to scan the nav pane, click on an item, and have the content pane sync up. I also have experience customizing the competitor of oXygen you mention. In that case, I had several css files for the structure view and used a macro/menu button to let the user toggle between them. It's one of the few areas where that tool has something on oXygen. You suggestion to add the ability to split the Author-view of the content window would be a nice thing to have for other reasons (e.g. to compare to sections of a document). In fact, you can already split the content pane in text view. However, I think that the current Outline view is already very close to doing everything it needs to do. In fact, it's more flexible than the competitor's structure view in that oXygen lets the user filter the list. That's not something you can do with SV. Thanks, David On 01/19/2012 01:35 PM, Wendell Piez wrote:
Dear David,
It's not the same as being able to configure the outline view (which is an intriguing idea), but one thing I have done is make a distinct CSS stylesheet just for a ToC rendition of the document. Of course this gives you all the flexibility of CSS including hiding things, and can be done right away. Switching between two or more CSS renditions is a feature oXygen has had for a while.
Additionally, in its CSS support, oXygen includes several extensions including a 'foldable' property that allows a user to expand and collapse arbitrary blocks of the document, while keeping certain element children visible. So you can collapse/expand sections while keeping their titles in view, for example.
Tailoring a user interface for the needs of users (each of whom is an individual with personal quirks and preferences) is certainly an art. At least one competitor to oXygen (which I haven't used in a while) allows the outline view to be styled with its own CSS. While this is good as far as it goes, it has a down side, in that it hides the straight unenhanced outline view, which is also nice to have. Maybe what we need is not more configuration of the outline view, but a way to view the same document with two (or more) different CSS stylesheets in different windows (along with, probably, the ability to harness their cursor positions together, or not).
Cheers, Wendell
On 1/19/2012 10:43 AM, 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?
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPGIOiAAoJEMHeSXG7afUh5A4H/3ADMto0ja9kpqhkHk9Q/DEy iKqL/zeAs1wqaBjfoRF93JTKmD5wFaSsOYrmLdmprEM6wcrRG6Px9IxNSRO1Wmeg 7fOkk4YfUKWsxn/jaEfHRAyJbE1JVuK8xDfZelxbRUOWksdfqNkZsxAfPHjJXldW c4W9LXTe4cheP7avHSY/rGtRjHGF99jY1SEfxmgqzT4bHSPHD1RfR262eDMzK8Oh LIE/x+j1OmMtcvia2NjvnfilUrX/nAOT1svD8i0TRu9FoR8CsmFaWCiS2nNhvwiJ qNFgJ7wbLFp3w0WytEq/fTtxzXjLKRUOXsJIZ2xN+U47flx88npIjaBQdup22Ng= =1uSI -----END PGP SIGNATURE-----
Wendell et al. I have seen RDF and presumably RDFa tables of contents (ToCs). There are two extremes in the types of ToCs. 1) a manifest which just lists the component files and their locations 2) A collection of hyperlinks, roles, and relationships. I have been working on the latter and can send out a preprint of a paper that I am completing. Most of the information and schemas can be found at www.cytometryml.org. My own work is on measurements of cells. A major problem-weakness in what I have done is that although, I have written XML schemas, I cannot interface them with neither html5 nor xhtml5. html5 does not appear to be simple to extend. Can your ToC include hyperlinks? Not the formatting of the text but providing the capacity with a browser to move to a new web page? Bob Leif -----Original Message----- From: oxygen-user-bounces@oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Wendell Piez Sent: Thursday, January 19, 2012 11:35 AM To: oxygen-user@oxygenxml.com Subject: Re: [oXygen-user] Outline view again Dear David, It's not the same as being able to configure the outline view (which is an intriguing idea), but one thing I have done is make a distinct CSS stylesheet just for a ToC rendition of the document. Of course this gives you all the flexibility of CSS including hiding things, and can be done right away. Switching between two or more CSS renditions is a feature oXygen has had for a while. Additionally, in its CSS support, oXygen includes several extensions including a 'foldable' property that allows a user to expand and collapse arbitrary blocks of the document, while keeping certain element children visible. So you can collapse/expand sections while keeping their titles in view, for example. Tailoring a user interface for the needs of users (each of whom is an individual with personal quirks and preferences) is certainly an art. At least one competitor to oXygen (which I haven't used in a while) allows the outline view to be styled with its own CSS. While this is good as far as it goes, it has a down side, in that it hides the straight unenhanced outline view, which is also nice to have. Maybe what we need is not more configuration of the outline view, but a way to view the same document with two (or more) different CSS stylesheets in different windows (along with, probably, the ability to harness their cursor positions together, or not). Cheers, Wendell On 1/19/2012 10:43 AM, 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?
-- ====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bob, Yes, the nodes in Oxygen's Outline view are indeed links to the corresponding node in the content pane. David On 01/20/2012 10:22 PM, Robert Leif wrote:
Wendell et al. I have seen RDF and presumably RDFa tables of contents (ToCs). There are two extremes in the types of ToCs. 1) a manifest which just lists the component files and their locations 2) A collection of hyperlinks, roles, and relationships. I have been working on the latter and can send out a preprint of a paper that I am completing. Most of the information and schemas can be found at www.cytometryml.org. My own work is on measurements of cells. A major problem-weakness in what I have done is that although, I have written XML schemas, I cannot interface them with neither html5 nor xhtml5. html5 does not appear to be simple to extend. Can your ToC include hyperlinks? Not the formatting of the text but providing the capacity with a browser to move to a new web page? Bob Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEbBAEBAgAGBQJPGsgSAAoJEMHeSXG7afUhXbkH+O/NfN0AeMmcNZrIMGyEKmod mfrFMlBKvJTkrLLhgd/wI6ei0TRfJEVnV/zbJ+4S0z6JDTVZYyjv4khC2xvGnCIK Fx0PYklBOyFY6JjwmQRsgnVUWxHoLHZzUk49fZMjm1uWssayaVsQBLKq+KJv74Fq 8fHU72CRJCmdFm01t1unAhGqoiYGVljXl1KBKyqIIrr0lWinl8qcy9J8rBi675fd 4uy0ebTiyBBNOxBjGWNYorOUWv6cjPnuAK36yP1tVPpFmp5MVaf0CeoyPmcZb3JX UexMPfSuqKai+CSa3ocdDKVqVsvMQvU2y8vFx57BUUj3gJ1T9kLpnfX6Omj8WQ== =wxW5 -----END PGP SIGNATURE-----
Dear Bob, On 1/20/2012 11:22 PM, Robert Leif wrote:
Wendell et al. I have seen RDF and presumably RDFa tables of contents (ToCs). There are two extremes in the types of ToCs. 1) a manifest which just lists the component files and their locations 2) A collection of hyperlinks, roles, and relationships. I have been working on the latter and can send out a preprint of a paper that I am completing. Most of the information and schemas can be found at www.cytometryml.org. My own work is on measurements of cells. A major problem-weakness in what I have done is that although, I have written XML schemas, I cannot interface them with neither html5 nor xhtml5. html5 does not appear to be simple to extend. Can your ToC include hyperlinks? Not the formatting of the text but providing the capacity with a browser to move to a new web page?
If you're meaning within oXygen's Author mode specifically and you want linking semantics in the display (as formatted with CSS), you should look at oXygen 13's CSS extensions in this area. But by saying "in the browser", you seem to be speaking more broadly; about that I'm not sure what I'd say other than while CSS by itself doesn't provide linking semantics, generating ToCs such as you describe is a very normal thing to do with XSLT. This approach (which indeed I'd describe as a classical approach to online publishing) would have you not integrating your XML-based application format into HTML or XHTML, but rather converting it into HTML or XHTML for display. Current mainstream browsers do support XSLT 1.0 transformations for this purpose. (But this isn't directly on topic for this list is it? Maybe you want XSL-List at mulberrytech.com.) Regards, Wendell ====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
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:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPGDoQAAoJEMHeSXG7afUhRIQH/0y03DCeYsc6SuWM2kt3q2/c B7VgNeVdEGZY5alT21nXcexJR1w7aJQp4q7LHUp/bdcH/p6hkRLa0Pb0pRRMa9x9 GlKHvdRC8OcmYc/iSoml45b2zZ0zsIa9fqaaKFpoyJtrhPO9gsrLX1nEe/J18vyD wUSyzWGbjuv1C6pSedwLtePNGPsu7CJUFu4kh+elmjbDCfLGUP6ZUWRCAxWAF2uO EGg1O22sOZj85jvDVmjGnv19ZhZr4QKnY5jwF4QNU+OmwpILY9f0c4B0vMiZ5uUe /N1o3L661jyoaXAE6NDq+xBQvC9LCz7sQsH4a09yrDs9fcomQ9KvmoOdxydCDKQ= =YAD0 -----END PGP SIGNATURE----- _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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@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/ iQEcBAEBAgAGBQJPGWgFAAoJEMHeSXG7afUhjU0H/AzBhrXcDeuzFyTcV2ShawXg 5aQPObO19vqwvA37W75YekWKexeZsKWygu+bX2203wIfKhN87HfabT/BHHYC12sw 4crebZNCEageNz8NibfiZaSeQuKoO+vPiKwn16IgO86Bn8kenYkdeK8+qD0gqdfQ EuoqY/N/akizNhXmDBnafLobIWdgBTGzSkQlMgR5b0NHj3PO9bD+DrVKYUTuoWbP uPzxEB6qhQlywpjUARf1BXM7LvHVGMMRTLg7MfCNWYAkO2Fvm6aXY0n2XjaL9TWM WRnwVDrVDIcgKxH+ivtN/sAtrujiuxsm7wF0wEd74jLWoH6RSMwuWYUScfda4/c= =IbwK -----END PGP SIGNATURE-----
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:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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@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/
iQEcBAEBAgAGBQJPGWgFAAoJEMHeSXG7afUhjU0H/AzBhrXcDeuzFyTcV2ShawXg 5aQPObO19vqwvA37W75YekWKexeZsKWygu+bX2203wIfKhN87HfabT/BHHYC12sw 4crebZNCEageNz8NibfiZaSeQuKoO+vPiKwn16IgO86Bn8kenYkdeK8+qD0gqdfQ EuoqY/N/akizNhXmDBnafLobIWdgBTGzSkQlMgR5b0NHj3PO9bD+DrVKYUTuoWbP uPzxEB6qhQlywpjUARf1BXM7LvHVGMMRTLg7MfCNWYAkO2Fvm6aXY0n2XjaL9TWM WRnwVDrVDIcgKxH+ivtN/sAtrujiuxsm7wF0wEd74jLWoH6RSMwuWYUScfda4/c= =IbwK -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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@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/ iQEcBAEBAgAGBQJPGYrKAAoJEMHeSXG7afUhLO8H/1FspGyfSIr8Ow9QxLbMuiee nMnC/sIMRZRWLYmhih+NqpTINadjXhkJyzoHM0bAYTICdSvf9OGuOziVOArxEB7x b7TvMJFUwkjaRjBoOVZr9oKNABza04JIab394Kp+hWymsE1auHzOx6YCZMdZ+c0G u+QC+xqbNV67DQyBZZ9TDwKJ/xHdVHCtnGXpvS4WwYfhuZarbqTzwJtsVQ3zguFw epbiz8BB0wa+zj0yTu1Th+dwEps3cdFCcg/wUcDp7HVfbqajlixsaQuQt/IZ/gKt X3AI1uHl4ChtQHrf3TF5nA/Q4kGll6OFGLEBzs8UpXmYTDDXlgmAmNZjGjAXBwg= =1v2r -----END PGP SIGNATURE-----
Hi again, On 1/20/2012 10:39 AM, David Cramer wrote:
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.
A new view, or an ability to vertically split a document in Author mode and align the two (or more) panes so they scroll together -- which, of course, may amount to the same thing. While I can't speak to what's easier or harder to implement, it does seem that oXygen is nearly there. In fact, as it happens, an associate of mine was just telling me of his joy at discovering the CSS switching feature (and how he stayed up half the night writing CSS to take advantage of it). This feature would build on that.
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.
+1 Cheers, Wendell -- ====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Hi all, These are interesting ideas to explore... What I am thinking, for the document outliner is to generalize the DITA Maps Manager view that we currently provide for DITA to handle also the new DocBook assemblies and maybe other type of "maps". Such a side view may support loading also normal DocBook documents and present a high level outline, possibly handling external entities or XInclude elements that may be used for modularization. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 1/20/12 10:41 PM, Wendell Piez wrote:
Hi again,
On 1/20/2012 10:39 AM, David Cramer wrote:
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.
A new view, or an ability to vertically split a document in Author mode and align the two (or more) panes so they scroll together -- which, of course, may amount to the same thing.
While I can't speak to what's easier or harder to implement, it does seem that oXygen is nearly there. In fact, as it happens, an associate of mine was just telling me of his joy at discovering the CSS switching feature (and how he stayed up half the night writing CSS to take advantage of it). This feature would build on that.
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.
+1
Cheers, Wendell
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:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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@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/
iQEcBAEBAgAGBQJPGYrKAAoJEMHeSXG7afUhLO8H/1FspGyfSIr8Ow9QxLbMuiee nMnC/sIMRZRWLYmhih+NqpTINadjXhkJyzoHM0bAYTICdSvf9OGuOziVOArxEB7x b7TvMJFUwkjaRjBoOVZr9oKNABza04JIab394Kp+hWymsE1auHzOx6YCZMdZ+c0G u+QC+xqbNV67DQyBZZ9TDwKJ/xHdVHCtnGXpvS4WwYfhuZarbqTzwJtsVQ3zguFw epbiz8BB0wa+zj0yTu1Th+dwEps3cdFCcg/wUcDp7HVfbqajlixsaQuQt/IZ/gKt X3AI1uHl4ChtQHrf3TF5nA/Q4kGll6OFGLEBzs8UpXmYTDDXlgmAmNZjGjAXBwg= =1v2r -----END PGP SIGNATURE-----
-----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@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-----
Hi David, I just sent you an email with details on how you can access that. Please let us know your test results. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 1/26/12 12:46 AM, David Cramer wrote:
-----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@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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks George. I just gave it a try and the improved Outline view works beautifully. My only additional suggestions would be: 1. Add a "Show element name" checkbox to the Outline view settings menu along with "Show text" etc. That way you can select only "Show text", hiding the element names, attributes, comments, and processing instructions to have a clean table of contents view of the document by filtering on the lowest level element you're interested in (e.g. section in DocBook). 2. Show more information (e.g. element name, title, attributes) in the tooltip when you mouse over a node. Currently, the tooltip shows only the title even if the title is already showing. The tooltip should show you stuff that you are NOT already seeing in the tree, otherwise it's just noise. I have to say it's really nice to be able to filter the outline by an arbitrary list of elements. This will be very useful and it's nice that it will work equally well with all schemas without special customization. Thanks, David On 01/26/2012 07:25 AM, George Cristian Bina wrote:
Hi David,
I just sent you an email with details on how you can access that. Please let us know your test results.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 1/26/12 12:46 AM, David Cramer wrote: 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@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/ iQEcBAEBAgAGBQJPI3PgAAoJEMHeSXG7afUhAm0H/AtIXxQB3DBMziA+HkALZLQF VP4R2C3rFOszTNGvz87lwMdPJpcmCQk5Wx94+fSqqRqxNp8RCS7YWysiT1c/gO2P I/S+fnOjnTpPOdcWpb3m/7VNDWrMLNoGTUVIACvJLXrCvHB663cqe6YlUmmNy07g aMDEa1CLNADHNuqqmgW/57MLbD2Ffu4MyvCm5gH7lfZiMXo+r7VvpOFDdnx6UZHA 68ILaS3xhcH6EExu+e52SkGdLh/09X7KMcYe8tlYJi9dHawFqcUnLPK5AmaPh3fh zFugJBa+kCkyJYDdcKbM0ExEW7u0/lH+gFo1sJtOt6zzhzeiXub5rZ3uyAz41gw= =F0wY -----END PGP SIGNATURE-----
Hi David, We will look into these additional suggestions and probably they will also get in the next version. We will keep you up to date as things get implemented. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 1/28/12 6:04 AM, David Cramer wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thanks George. I just gave it a try and the improved Outline view works beautifully.
My only additional suggestions would be:
1. Add a "Show element name" checkbox to the Outline view settings menu along with "Show text" etc. That way you can select only "Show text", hiding the element names, attributes, comments, and processing instructions to have a clean table of contents view of the document by filtering on the lowest level element you're interested in (e.g. section in DocBook).
2. Show more information (e.g. element name, title, attributes) in the tooltip when you mouse over a node. Currently, the tooltip shows only the title even if the title is already showing. The tooltip should show you stuff that you are NOT already seeing in the tree, otherwise it's just noise.
I have to say it's really nice to be able to filter the outline by an arbitrary list of elements. This will be very useful and it's nice that it will work equally well with all schemas without special customization.
Thanks, David
On 01/26/2012 07:25 AM, George Cristian Bina wrote:
Hi David,
I just sent you an email with details on how you can access that. Please let us know your test results.
Best Regards, George -- George Cristian Bina<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 1/26/12 12:46 AM, David Cramer wrote: 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@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/
iQEcBAEBAgAGBQJPI3PgAAoJEMHeSXG7afUhAm0H/AtIXxQB3DBMziA+HkALZLQF VP4R2C3rFOszTNGvz87lwMdPJpcmCQk5Wx94+fSqqRqxNp8RCS7YWysiT1c/gO2P I/S+fnOjnTpPOdcWpb3m/7VNDWrMLNoGTUVIACvJLXrCvHB663cqe6YlUmmNy07g aMDEa1CLNADHNuqqmgW/57MLbD2Ffu4MyvCm5gH7lfZiMXo+r7VvpOFDdnx6UZHA 68ILaS3xhcH6EExu+e52SkGdLh/09X7KMcYe8tlYJi9dHawFqcUnLPK5AmaPh3fh zFugJBa+kCkyJYDdcKbM0ExEW7u0/lH+gFo1sJtOt6zzhzeiXub5rZ3uyAz41gw= =F0wY -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I love how fast you guys move! Please do keep me posted. I'd enjoy doing another test drive. Thanks, David On 01/31/2012 02:27 AM, George Cristian Bina wrote:
Hi David,
We will look into these additional suggestions and probably they will also get in the next version. We will keep you up to date as things get implemented.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPKBN+AAoJEMHeSXG7afUhKIIIAIACFxjhqQmtBBG1FnWgOXO1 FdFkE4tQPYID/2ovrpDWNJ2sKw/nR5rDT0u2ic/OOLURvpY4jT8ABKPpNc1doQ/c Vr47IlQ8EXYld7Bkc9cETdgHPFEn4JnrRWBX99A4SP4ziVgjZ3mbjmv9tj3wz50Q 4vI7v5yNIS5ecBv7kR8AgC9czseGJsH0OPIVg9RukL5FTOv/8eDcz2PcdibrxxIw wquoTxOw4DlCcfyNzjyXp/hFi7otr0lZJxwa/9G7qCuzC+Q02maFIYhWp1dZM0N+ +q2o7oEcrkomchYyltmz2PX3KFG4fHDog82NFOUBGWcX30TaVHEDmgPl7EX9ucc= =IT3H -----END PGP SIGNATURE-----
participants (4)
-
David Cramer -
George Cristian Bina -
Robert Leif -
Wendell Piez