New functionalities for the AuthorPersistentHighlighter

Are you missing a feature? Request it's implementation here.
SSC
Posts: 206
Joined: Thu Dec 01, 2011 4:22 pm
Location: Hamburg, Germany

New functionalities for the AuthorPersistentHighlighter

Post by SSC » Thu Aug 16, 2012 11:32 am

Hi,

In our Eclipse RCP client we currently use your ro.sync.ecss.extensions.api.highlights.AuthorPersistentHighlighter to highlight certain XML tags.

For the rendering a ro.sync.ecss.extensions.api.highlights.ColorHighlightPainter in the ro.sync.ecss.extensions.api.highlights.PersistentHighlightRenderer is used.

Would it be possible to add some functionalities?
We´d like to have a possibility to draw a border around the XML tags, which should be highlighted and add some text before and after the hightlighted XML tag.

It would be nice, if the ColorHighlightPainter would have setBorder(BorderInformation borderInfo) method in order to draw a border around the Highlighted XML tag.

The PersistentHighlightRenderer has a getTooltip method.
Maybe you could add a getTextBefore(AuthorPersistentHighlight highlight); and a getTextAfter(AuthorPersistentHighlight highlight);

An even better approach would be the possibility to customise the the highlight via CSS, so that it is up to the user how to style a Highlight.

I imagine something like this :

Code: Select all


oxy|highlights[kgu-custom='validblock']:before
{
color : #CD2626 ;
content : "Start - valid for ["attr(valid)"]";
display : block;
margin-bottom : 5px;
}
oxy|highlights[kgu-custom='validblock']
{
padding : 5px;
border: dashed 0.5px #CD2626;
}
oxy|highlights[kgu-custom='validblock']:after {
color : #CD2626 ;
margin-top : 5px;
content : "End - valid for ["attr(valid)"]";
display : block;
}
In this forum post Radu mentions something similar for PIs : http://www.oxygenxml.com/forum/topic6949.html#p21688
Maybe oxy|highlights could be implemented in a similar way...

Looking forward for your feedback according to this feature request.

Best regards,

Simon
Simon Scholz
vogella GmbH
http://www.vogella.com

SSC
Posts: 206
Joined: Thu Dec 01, 2011 4:22 pm
Location: Hamburg, Germany

Re: New functionalities for the AuthorPersistentHighlighter

Post by SSC » Thu Aug 16, 2012 2:53 pm

Hi,

some time ago you told me about the http://oxygenxml.com/doc/ug-editor/topi ... ctors.html

On that page(http://oxygenxml.com/doc/ug-authorEclip ... ctors.html) I saw that you also support the Adjacent Sibling Selector.

Is it somehow possible to combine those two features?

So that I can use selectors like this:

Code: Select all


oxy|processing-instruction[my-custom-PI] + *:before {
color : #CD2626 ;
content : "Start";
display : block;
margin-bottom : 5px;
}

oxy|processing-instruction[my-custom-PI] + * {
padding : 5px;
border: dashed 0.5px #CD2626;
}

oxy|processing-instruction[my-custom-PI] + *:after {
color : #CD2626 ;
content : "End";
display : block;
margin-top : 5px;
}
This would make it possible to style the node, which is a sibling to the PI.
And could be a workaround for our features request.

Best regards,

Simon
Simon Scholz
vogella GmbH
http://www.vogella.com

mihaela
Posts: 211
Joined: Wed May 20, 2009 2:40 pm

Re: New functionalities for the AuthorPersistentHighlighter

Post by mihaela » Thu Aug 16, 2012 3:09 pm

Hi Simon,
We´d like to have a possibility to draw a border around the XML tags, which should be highlighted and add some text before and after the hightlighted XML tag.
For the next version of oXygen (14.1) we have worked on some CSS customizations that allows you to change the background and foreground color of the Author tags.

We have added the following CSS properties:

Code: Select all


-oxy-tags-color
-oxy-tags-background-color
I think that you should use this properties to mark specific tags in Author and not the custom highlights.
Is this solution suitable for your needs?


The custom highlights do not contribute to the Author content layout, they where added in oXygen to add the possibility to mark (highlight) some Author content.

From your CSS sample I understand that you want to use the before and after pseudo-elements to attach some information to your highlights, based on your highlights attributes values.

What is exactly that you want to obtain? Do you want to add information to every tag or do you want to just mark some type of elements?

Best regards,
Mihaela
Mihaela Calotescu
http://www.oxygenxml.com

SSC
Posts: 206
Joined: Thu Dec 01, 2011 4:22 pm
Location: Hamburg, Germany

Re: New functionalities for the AuthorPersistentHighlighter

Post by SSC » Thu Aug 16, 2012 3:56 pm

Hi,

What we want to achieve is to mark some type of elements, like it is done with the ro.sync.ecss.extensions.api.highlights.AuthorPersistentHighlighter

Currently we use the AuthorPersistentHighlighter to change the background color of a certain XML tag and add a tooltip.

But instead of changing the backgroundcolor, we´d like to have a border around the highlighted XML tag.
And in addition to that, we´d also like to add textual information for the user, which can be directly seen. So I came up with the idea to use before and after statements for that.

The...
-oxy-tags-color
-oxy-tags-background-color
... CSS selectors actually do the same what already can be done in the ro.sync.ecss.extensions.api.highlights.ColorHighlightPainter.

Best regards,

Simon
Simon Scholz
vogella GmbH
http://www.vogella.com

mihaela
Posts: 211
Joined: Wed May 20, 2009 2:40 pm

Re: New functionalities for the AuthorPersistentHighlighter

Post by mihaela » Thu Aug 16, 2012 5:25 pm

Hi Simon,

To add a border to your custom highlights you can extend the ro.sync.ecss.extensions.api.highlights.ColorHighlightPainter and add the paint border functionality. Here is a small sample (you can improve this painter to use a specific stroke width or type):

Code: Select all


public class CustomHighlightPainter 
extends ColorHighlightPainter {

/**
* Border color.
*/
private Color borderColor;

/**
* Constructor.
*
* @param borderColor Border color.
*/
public ColorAndBorderHighlightPainter(Color borderColor) {
this.borderColor = borderColor;
}

@Override
public void paint(HighlightPainterInfo pi) {
super.paint(pi);

if (borderColor != null) {
// Set draw color
pi.getGraphics().setDrawColor(borderColor);
// Draw border
pi.getGraphics().drawRect(
pi.getOrigin().x + pi.getRelativeX(),
pi.getOrigin().y,
pi.getLength(),
pi.getCurrentBoxHeight());
}
}
}
Regarding your second request (to add before or after content to the custom highlights): unfortunately there is no possible to do this. As I already said, the custom highlights were not built to contribute to the Author content layout.

However, we are thinking that maybe another CSS property that you could use it to change the tags content would be helpful. Do you think that this could help you? Do you need to set different content for start and end tag of the same element?

We have another question for you: what type of information do you set on the tags tooltip (can you give as an example)?

Regards,
Mihaela
Mihaela Calotescu
http://www.oxygenxml.com

SSC
Posts: 206
Joined: Thu Dec 01, 2011 4:22 pm
Location: Hamburg, Germany

Re: New functionalities for the AuthorPersistentHighlighter

Post by SSC » Thu Aug 16, 2012 6:18 pm

Hi Mihaela,

I just tried your CustomHighlightPainter, but it seems that the HighlightPainter is invoked several times, so that the existing CSS before elements and the actual xml elements have its own border.
Actually we want one single border around the whole xml element including the before and after selectors content.
mihaela wrote: However, we are thinking that maybe another CSS property that you could use it to change the tags content would be helpful. Do you think that this could help you?
About what kind of CSS property are you thinking?
mihaela wrote: Do you need to set different content for start and end tag of the same element?
Not now, but maybe in the future.
mihaela wrote: We have another question for you: what type of information do you set on the tags tooltip (can you give as an example)?
The information is quite generic, because the oxy-custom-PI itself just contains ids of certain Objects in our system.
With those ids we programmatically generate a localized text according to the language the user selects.

At the moment I am trying to modify the everything by an ro.sync.ecss.extensions.api.StylesFilter, where I search for an AuthorNode, which has the PI as previous sibling and draw a border around it.
Then I added...

Code: Select all


* :before{
content: "";
}
...to the CSS, so that the StyleFilter gains access to the before elements. When I get the parent of the before element I also get access to the PI and then I got the text from our API with the id, which is stored in the PI, so that I can set content to the before statement.

But this approach has many drawbacks:
- It is quite complicated
- Existing before elements are overriden, when a PI is added

When I try to call getTextContent() on the before node an Error thrown, because it´s textcontent is not present in the xml but only in the CSS I guess?
Is there a way to check, if there already is content in the before node?

Do you want the code I am using in my custom StylesFilter, to better follow my aims?

Best regards,

Simon
Simon Scholz
vogella GmbH
http://www.vogella.com

SSC
Posts: 206
Joined: Thu Dec 01, 2011 4:22 pm
Location: Hamburg, Germany

Re: New functionalities for the AuthorPersistentHighlighter

Post by SSC » Thu Aug 16, 2012 6:38 pm

Here is a picture of the custom Highlighter:
Image

Here you can see 3 borders, but we´d like to have one border, which surrounds every item of those 3.

Best regards,

Simon
Simon Scholz
vogella GmbH
http://www.vogella.com

SSC
Posts: 206
Joined: Thu Dec 01, 2011 4:22 pm
Location: Hamburg, Germany

Re: New functionalities for the AuthorPersistentHighlighter

Post by SSC » Fri Aug 17, 2012 9:40 am

Hi,

in general it seems that the :before node, the actual node and the :after node are not handled as a unity.
In my opinion this is wrong, because other XML Editors and even common browsers handle :before,:after and the actual node as unity.

I got 3 examples for that:
[1.]
When I use CSS like I already mentioned in a former forum post:

Code: Select all


    oxy|highlights[kgu-custom='validblock']:before
{
color : #CD2626 ;
content : "Start - valid for ["attr(valid)"]";
display : block;
margin-bottom : 5px;
}
oxy|highlights[kgu-custom='validblock']
{
padding : 5px;
border: dashed 0.5px #CD2626;
}
oxy|highlights[kgu-custom='validblock']:after {
color : #CD2626 ;
margin-top : 5px;
content : "End - valid for ["attr(valid)"]";
display : block;
}


The CSS display:block; makes in the Oxygen XML Editor put the :before and :after "nodes" outside the border, which is defined for the actual node.
Other XML Editors do it diffrently.

[2.]
Also the picture I have added is an evidence for that, because there are 3 Borders, when I use the CustomHighlightPainter.

[3.]
When I turn on "Full Tags" in the Author view of the XML Editor, the :before content is outside the Tag.
Image
Only if I use display:inline the :before node is shown inside die note tag.

Best regards,

Simon
Simon Scholz
vogella GmbH
http://www.vogella.com

mihaela
Posts: 211
Joined: Wed May 20, 2009 2:40 pm

Re: New functionalities for the AuthorPersistentHighlighter

Post by mihaela » Fri Aug 17, 2012 3:44 pm

Hi Simon,

First some short answers to your points:
[1.]
The CSS display:block; makes in the Oxygen XML Editor put the :before and :after "nodes" outside the border, which is defined for the actual node.
Other XML Editors do it diffrently.
Yes, you are right. We'll investigate if we can change the current behavior.
[2.]
Also the picture I have added is an evidence for that, because there are 3 Borders, when I use the CustomHighlightPainter.
Highlight Painters are mostly intended to highlight parts of text (for example to underline or to strike-out the highlighted text).
So a painter is applied to each small text fragment instead of having a single painter applied to the entire node.
The current behavior will remain unchanged.
[3.]
When I turn on "Full Tags" in the Author view of the XML Editor, the :before content is outside the Tag.
We'll also discuss and investigate if this behavior can be modified.


We looked over the entire thread again and here are some other observations:
In our Eclipse RCP client we currently use your ro.sync.ecss.extensions.api.highlights.AuthorPersistentHighlighter to highlight certain XML tags.
As you know a persistent highlight is serialized in the XML content with processing instructions like oxy_custom_start and oxy_custom_end. But when loaded in the Author page there are no processing instructions in the content, the highlights are just flexible positions which when saving get serialized as processing instructions. So you cannot match in the CSS these custom persistent highlights.
The PersistentHighlightRenderer has a getTooltip method.
Maybe you could add a getTextBefore(AuthorPersistentHighlight highlight); and a getTextAfter(AuthorPersistentHighlight highlight);
Also, highlights persistent or not persistent cannot contribute to the displayed content, they are like a layer which is drawn over the Author content. So they cannot provide static text to the Author page.

Have you abandoned this approach in favor of custom-named processing instructions or are you trying these approaches in parallel?
If you use custom processing instructions in the XML you can indeed try to match the node which is after such a processing instruction in the StylesFilter and try to set a static text to its before content.
When I try to call getTextContent() on the before node an Error thrown, because it´s textcontent is not present in the xml but only in the CSS I guess?
Is there a way to check, if there already is content in the before node?
Yes, you should look at the mixed content already set on the:

ro.sync.ecss.css.Styles.getMixedContent()

and use the old content + the new one to set a new mixed content to it.

Regards,
Mihaela
Mihaela Calotescu
http://www.oxygenxml.com

SSC
Posts: 206
Joined: Thu Dec 01, 2011 4:22 pm
Location: Hamburg, Germany

Re: New functionalities for the AuthorPersistentHighlighter

Post by SSC » Tue Aug 21, 2012 3:22 pm

Hello,

I´d like to offer you another picture concerning the "wrong" behavior of the Full Tags mode´s XML elements.

Image
- http://i46.tinypic.com/97nurd.png -

In the second part of the picture the :before content is outside the |note> tag and also outside the red border of the |note> tag.

Because of that I changed the CSS of the :before element to display: inline;(see third part of the picture)
But then also the |body> tag moves inside the border, which is really bad.

The last part shows what is actually desired and expected.

Best regards,

Simon
Simon Scholz
vogella GmbH
http://www.vogella.com

mihaela
Posts: 211
Joined: Wed May 20, 2009 2:40 pm

Re: New functionalities for the AuthorPersistentHighlighter

Post by mihaela » Wed Aug 22, 2012 12:24 pm

Hi Simon,

There is an option in Preferences, Editor / Edit modes / Author page, called "Compact tag layout". This option is used for the "full-tags" display mode of the Author mode, to obtain a layout that is much more ergonomic, placing multiple XML tags on the same line.
By default, this option is enabled.
Try to disable it to see if you obtain the layout you need (the body element tag placed outside the border).

Best regards,
Mihaela
Mihaela Calotescu
http://www.oxygenxml.com

SSC
Posts: 206
Joined: Thu Dec 01, 2011 4:22 pm
Location: Hamburg, Germany

Re: New functionalities for the AuthorPersistentHighlighter

Post by SSC » Thu Aug 23, 2012 11:07 am

Hello mihaela,

indeed this is a solution, but not the best, because we liked the "much more ergonomic" layout, too.
Maybe you could try to just draw the border around the desired |xmlnode> to which the border belongs, even though the "Compact tag layout" feature is turned off.

Also the Problem of the :before content being outside the Full Tag |xmlnode> is not solved by turning the "Compact tag layout" feature off.

Would it be possibile to fix this "bug" of the "Full Tags" mode?
Or do you have an other opinion about the described Full Tags behavior?
But changing the display CSS from block to inline is not what I want to do in order to have the :before node inside the "Full Tags", because it modifies to actual correct CSS style rules.

Best regards,

Simon
Simon Scholz
vogella GmbH
http://www.vogella.com

mihaela
Posts: 211
Joined: Wed May 20, 2009 2:40 pm

Re: New functionalities for the AuthorPersistentHighlighter

Post by mihaela » Thu Aug 23, 2012 5:45 pm

Hi Simon,
Maybe you could try to just draw the border around the desired |xmlnode> to which the border belongs
Indeed, the border should include only the tags of the element on which the border is set. We will take your request into consideration and we will try in the future to change this behavior.
Also the Problem of the :before content being outside the Full Tag |xmlnode> is not solved by turning the "Compact tag layout" feature off.
Would it be possibile to fix this "bug" of the "Full Tags" mode?
I already added your request in our internal bug tracking tool about including the :before content inside the element tags.

We will let you know when this changes will be implemented.

Best regards,
Mihaela
Mihaela Calotescu
http://www.oxygenxml.com

Post Reply