Dnd of Tag Elements

Post by **SSC** » Tue Dec 06, 2011 4:53 pm

Hi,

is it possible to add a custom draglistener to tags in the xml editor?
When I turn on the feature with Full Tags in the Author View of the XML Editor and drag a XML Tag on a DropTarget I only receive the text between the tag elements as event.data.

My goal is to get the tag as a DOM node or something like that.
I need to know where the tag is in the documents xml hierarchy, it´s attributes and all those information a DOM node would give me.

How can I handle this issue? I guess that I am not able add my own draglistener to the XML tag elements in the document, am I?
Is there maybe a workaround to receive the information I want to know?

Post by **Radu** » Tue Dec 06, 2011 5:42 pm

Hi,

For external drop locations the Author indeed only provides the text content.

Maybe you can avoid using DnD.
Let's say that you have a custom view added to the Eclipse Workbench.
Instead of dropping nodes to it you can place a button in the view called "Analyze current node".
We have API which allows you to get the current node (the node in which the caret is placed) from the current opened Author page in the workbench.

Our Eclipse integration API and a small sample project can be found here:
http://www.oxygenxml.com/oxygen_sdk.htm ... pse_plugin

Our internal Author structure is DOM like but not DOM:
http://www.oxygenxml.com/InstData/Edito ... rNode.html

Code: Select all

IWorkbenchPart currentPart =  .....;

if (currentPart instanceof ro.sync.exml.workspace.api.editor.WSEditor) {

  WSEditor oxygenEditor = (WSEditor) currentPart;

  WSEditorPage currentPage = oxygenEditor.getCurrentPage();

  if(currentPage instanceof WSAuthorEditorPage) {

    WSAuthorEditorPage oxygenAuthorPage = (WSAuthorEditorPage) currentPage;

    try {

      AuthorNode currentNode = oxygenAuthorPage.getDocumentController().getNodeAtOffset(oxygenAuthorPage.getCaretOffset());

      if(currentNode.getType() == AuthorNode.NODE_TYPE_ELEMENT) {

        AuthorElement currentElement = (AuthorElement) currentNode;

        //You can then go to the parent element or access attributes, etc

      }

    } catch (BadLocationException e) {

      e.printStackTrace();

    }

  }

}

Regards,
Radu

Post by **SSC** » Tue Dec 06, 2011 6:19 pm

Thanks for your answer.
The response time is great.

Also thanks for the hint with the eclipse SDK, but I am already using it and also found the AuthorNode, but I am missing a getter for the Attributes of the selected node.
As I can see your "Attributes" view is able to view the attributes and you can even modify the attributes in this view.
Unfortunately our CMS already has a generic view, which is responsible for showing information of Objects in the CMS.
We want to avoid having different views for the same job, so I´d like to know how the "Attributes" View works.

Back to the Topic :
DnD of an Author Node would be fine and I think it would be a better approach to allow passing an AuthorNode as eventData, because that AuthorNode object also contains the information of the contained text.
Surely I can image cases where your approach can fit better and it is much easier to pass raw text as eventData. But I guess I am not the first person, who wants to drag tag elements from the XML Editor.

Post by **Radu** » Wed Dec 07, 2011 1:33 pm

Hi,

If the selected AuthorNode is an instance of AuthorElement, the AuthorElement has method to get access to the attributes which are set on it.
If you want access to the attributes which are not set on the node but which are allowed by the schema to be set on that node, the API would be something like this:

Code: Select all

      WSAuthorEditorPage authPage = ...;

      AuthorElement element = ...;

      authPage.getDocumentController().getAuthorSchemaManager().createWhatAttributesCanGoHereContext(element);

Our Attributes View is made up of attributes which are set on the element + attributes which may be set on an element but it took a lot of coding and it would probably take a couple of weeks to replicate 80% of its functionality.

One very important fact, if you want to change an attribute value for an AuthorElement, you have to change it by going through the AuthorDocumentController API like:

Code: Select all

      WSAuthorEditorPage authPage = ...;

      AuthorElement element = ...;

      authPage.getDocumentController().setAttribute("attrName", new AttrValue("attrValue"), element);

So do not directly call methods in the AuthorElement to modify attribute values, this will not give you undo/redo support in the editor for your action.

About the DnD:

What we set in the "event.data" for our internal Author DnD-ing is a complex structure, the dragged selection may contain more than one nodes or may contain only a part of a node. This structure is self contained, the AuthorNodes in it are clones, they do not longer belong to the original document in order to be able to serialize and un-serialize the entire structure if needed (the drop might be in an Author page from another Eclipse application).
So we cannot easily offer API access to this structure.
So we have API for custom processing different drops in the Author page (from different sources) but not for exposing our internal dnd object to an external target.
We also have what I consider to be a small bug, after dropping the content from Author to another view, the selected source content gets deleted although it should not.

Regards,
Radu

Post by **SSC** » Wed Dec 07, 2011 2:19 pm

Thanks a lot.

It is a pity that there is just one piece of sample code for the eclipse plugin. So unfortunately I am forced to ask a lot of questions here in the support forum. For instance I wonder if I ever would have figured out that I am supposed to use the setAttribute method of the DocumentController instead of the using the method of the AuthorElement directly.

Concerning the DnD issue I already expected such an answer.
I thought there eventually could be a way to make a DragSource out of a tag element und then attach an own draglistener to it.

Post by **Radu** » Wed Dec 07, 2011 3:18 pm

Hi,

It is a pity that there is just one piece of sample code for the eclipse plugin. So unfortunately I am forced to ask a lot of questions here in the support forum. For instance I wonder if I ever would have figured out that I am supposed to use the setAttribute method of the DocumentController instead of the using the method of the AuthorElement directly.

Yes, we should have richer sample projects and documentation for our Eclipse API, so we'll try to make some future improvements for this.

Having these discussions on the forum is also a good thing for future developers who might search similar subjects.

Tha Javadoc for the "setAttribute" method on an AuthorElement contains a warning:

Code: Select all

<b>Warning:</b> Use this only when the element is not from a the existing 

   {@link AuthorDocument} content, for example a cloned element.

   All operations on nodes from the document model must be done using the 

   {@link AuthorDocumentController} methods.

By the way, if you want Java sources from our entire API interfaces, they can be found in the AuthorSDK:

http://www.oxygenxml.com/InstData/Edito ... horSDK.zip

in the lib/apiSrc.zip ZIP archive.

They are useful to attach when working in Eclipse with the API from our "oxygen.jar" library.

I thought there eventually could be a way to make a DragSource out of a tag element und then attach an own draglistener to it.

This method:

Code: Select all

ro.sync.exml.workspace.api.editor.page.author.WSAuthorEditorPageBase.getAuthorComponent()

should give you access to the org.eclipse.swt.widgets.Canvas on which the entire Author editor is rendered.
You could experiment either:

Creating another DragSource over it, but most probably you have to dispose ours first (which can be found as a property in the Control control.getData(DND.DRAG_SOURCE_KEY)) because you cannot have 2 drag sources created over the same control.

or:

Add another drag listener to the existing drag source, maybe this would call your listener first.

Regards,
Radu

Post by **SSC** » Wed Dec 07, 2011 4:25 pm

Thanks for the hint with the "apiSrc".
This makes it much easier to understand your api.

I´ll try my best using your canvas, because I think we will want to draw additional information on your editor in the future. (Like some CMS specific meta data and so on...)

Post by **Radu** » Wed Dec 07, 2011 4:39 pm

Hi,

If you want to present additional information you should try to either modify the CSS associated to the XML document to add some :before or :after elements (but the content would be quite static), or we have a ro.sync.ecss.extensions.api.StylesFilter API which would allow you to provide some display content for certain elements.
The styles filter implementation can be added in the Extensions list by editing the document type associated to the XML file.

I do not see how you would be able to draw significant content by calling directly the canvas, you would need to know a lot of information about the layout and heights of the text rows in the page, information which you lack.

Regards,
Radu

Post by **SSC** » Thu Dec 08, 2011 11:36 am

Hello,

yesterday I ran the following code, but it seems that I only get those attributes, which are already declared...

Code: Select all

							AuthorDocumentController documentController = ((WSAuthorEditorPage) currentPage).getDocumentController();

							WhatAttributesCanGoHereContext availableAttrs = documentController.getAuthorSchemaManager().createWhatAttributesCanGoHereContext(nodeElement);



List<Attribute> attributesList = availableAttrs.getPreviousAttributesList();

for (Attribute attribute : attributesList) {

String localName = attribute.getLocalName();

String value = attribute.getValue();

								sb.append(localName);

								sb.append(" : ");

								sb.append(value);

								sb.append(System.getProperty("line.separator"));

}

Can you please tell me what I am doing wrong?
I also wanted to get those attributes, which are available in the schema.

Post by **Radu** » Thu Dec 08, 2011 1:34 pm

Hi,

My bad, my previous code sample was incomplete, it should have been like:

Code: Select all

WSAuthorEditorPage authPage = ...;

AuthorElement element = ...;

WhatAttributesCanGoHereContext  context = authPage.getDocumentController().getAuthorSchemaManager().createWhatAttributesCanGoHereContext(element);

List<CIAttribute>  attrs = authPage.getDocumentController().getAuthorSchemaManager().whatAttributesCanGoHere(context);

Regards,
Radu

Post by **SSC** » Thu Dec 08, 2011 6:07 pm

Thanks for the code example.

And back to DnD

Code: Select all


com.oxygenxml.editor.editors.gb



com.oxygenxml.editor.editors.xml.cb

Those two classes are subclasses of

Code: Select all

org.eclipse.swt.dnd.Transfer

Isn´t there a possibility work with your TransferData and get an AuthorNode or something similar out of it?

Post by **Radu** » Thu Dec 08, 2011 6:37 pm

Hi,

No, sorry, this will not help.

Regards,
Radu

Post by **SSC** » Wed Dec 14, 2011 3:54 pm

And how about using the outline view for DnD?
I mean in the default outline in eclipse you can also drag and drop items which are in the outline view.
But in connection with the oxygen xml editor it seems to be that you cannot DnD the items of the outline view. Even to drop those outline items onto the oxygen xml editor is not possible.
Is there maybe a way for us to use those outline items for DnD and then read the information of the chosen AuthorNode?
In the the end the items of the outline are also an representation of the tags in the current xml document.

Post by **Radu** » Wed Dec 14, 2011 4:53 pm

Hi,

I think you're in luck with the Outline view, we use a local selection transfer so you can access the nodes from it.
More than one nodes can be dropped at the same time.
I tested with the following drop target:

Code: Select all

Composite testComposite = SWTUtils.createGridComposite(this, 1, SWT.NONE);

    testComposite.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true));

    

    DropTarget dt = new DropTarget(testComposite, DND.DROP_COPY | DND.DROP_MOVE);

    dt.setTransfer(new Transfer[] {LocalSelectionTransfer.getTransfer()});

    dt.addDropListener(new DropTargetAdapter() {

      

      @Override

      public void dropAccept(DropTargetEvent event) {

        System.err.println("DROP ACCEPT");

      }

      

      @Override

      public void drop(DropTargetEvent event) {

        System.err.println("DROP");

        StructuredSelection sel = (StructuredSelection) LocalSelectionTransfer.getTransfer().getSelection();

        if(! sel.isEmpty()) {

          if(sel.getFirstElement() instanceof AuthorNode) {

            System.err.println(sel.getFirstElement());

          }

        }

      }

      

      @Override

      public void dragOver(DropTargetEvent event) {

        System.err.println("DRAG OVER");

      }

      

      @Override

      public void dragOperationChanged(DropTargetEvent event) {

        System.err.println("OP CHANGED");        

      }

      

      @Override

      public void dragLeave(DropTargetEvent event) {

        System.err.println("DRAG LEAVE");        

      }

      

      @Override

      public void dragEnter(DropTargetEvent event) {

        System.err.println("DRAG ENTER");

      }

    });

Regards,
Radu

Post by **Radu** » Wed Dec 14, 2011 5:00 pm

Hi,

The same drop target code should also accept drops from the Author page, but it will receive a "ro.sync.ecss.component.AuthorTransferredObject" instead of simple nodes, because the selection in the Author page is more complex (can span multiple elements, can have only text, etc).

I do not know how much of the ro.sync.ecss.component.AuthorTransferredObject object is left unobfuscated in a final distribution but when you receive such an object maybe you could at least look at the current selected WSAuthorEditorPage and get the selected node from there.

You should also probably force the COPY detail on the drag event to avoid deleting the dragged node from the Author page.

Code: Select all

      @Override

      public void dragEnter(DropTargetEvent event) {

        event.detail = DND.DROP_COPY;

      }

Regards,
Radu

Post by **SSC** » Thu Dec 15, 2011 1:33 pm

Thank you for your reply.
This really helped a lot and we are almost happy with the oxygen solution for a XML editor.

There are currentlythree things left we would really appreciate in the next oxygen releases :

1. You should offer an API for the ro.sync.ecss.component.AuthorTransferredObject object which we can use. Yesterday I debuged through all those unobfuscated classes and unfortunately realized that all valuable information is private and that there is no interface/API for it.
2. It would be nice, if you put those programmatically generated menu items and toolbar items in your plugin.xml with the org.eclipse.ui.menues extension. We do like to remove a couple of them, because most of our customers do not need those special toolbar and menu items.
3. A possibility to color the tags in your Author View programmatically.(I know you already mentioned that the implemention of this feature is in progress)

Shall I also post those issues in the feature request forum or is it adequate to leave those issues here and you could pass those feature requests to your developers.
IMHO I think those features would be very useful and not that difficult to realize.
I hope you welcome this feedback.

Post by **Radu** » Thu Dec 15, 2011 4:22 pm

Hi,

So:

1. You should offer an API for the ro.sync.ecss.component.AuthorTransferredObject object which we can use. Yesterday I debuged through all those unobfuscated classes and unfortunately realized that all valuable information is private and that there is no interface/API for it.

I added this as an improvement request. This is easy to do but even if it gets done, the nodes in the transferred object will no longer be connected in the XML document (but there is in the transferred object data about the ancestors of those elements), so you can also try my suggestion to use the API and look at the selected nodes in the Author page when the object is dropped in your custom view.

2. It would be nice, if you put those programmatically generated menu items and toolbar items in your plugin.xml with the org.eclipse.ui.menues extension. We do like to remove a couple of them, because most of our customers do not need those special toolbar and menu items.

Specifying toolbar extensions directly in the Java code gives us flexibility for handling different types of documents (XML, XSL, CSS, PHP, Javascript, etc). This means that when opening a "CSS" the toolbar has fewer buttons for example.
Specifying extensions in the "plugin.xml" means hardcoding specific actions to specific places.
Can you give us an example of what specific actions you would like to remove for the end users?

3. A possibility to color the tags in your Author View programmatically.(I know you already mentioned that the implemention of this feature is in progress)

For now this is scheduled for Oxygen 14 (for next year), but I cannot guarantee a certain release, I'll update this forum post when it gets done.

Regards,
Radu

Post by **SSC** » Thu Dec 15, 2011 5:24 pm

Radu wrote: Specifying toolbar extensions directly in the Java code gives us flexibility for handling different types of documents (XML, XSL, CSS, PHP, Javascript, etc). This means that when opening a "CSS" the toolbar has fewer buttons for example.
Specifying extensions in the "plugin.xml" means hardcoding specific actions to specific places.

I am sorry but in this case you are wrong and I have to disagree.
With the org.eclipse.ui.menus extension you can use the "visibleWhen" feature for every single menu or toolbar item.

Here is an example used within the default eclipse view template application:

Code: Select all


<extension

         point="org.eclipse.ui.menus">

      <menuContribution

            locationURI="menu:org.eclipse.ui.main.menu">

         <menu

               label="File">

            <command

                  commandId="org.eclipse.ui.file.exit"

                  label="Exit">

[color=#FF0040]               <visibleWhen

                     checkEnabled="false">

                  <with

                        variable="activePartId">

                     <equals

                           value="GUI_Test.view1">

                     </equals>

                  </with>

               </visibleWhen>[/color]

            </command>

         </menu>

      </menuContribution>

 </extension>

In this example the ID of the active part is compared with my view1 ID.
On the following wiki page you can find more expressions which can be used to support the "visibleWhen" feature in org.eclipse.ui.menus .

http://wiki.eclipse.org/Command_Core_Expressions

In the table below the "Variables and the Command Framework" heading is also an "activeEditorId" which you could use like I did with my test view1 and the "activePartId".

So you could use something similar like this :

Code: Select all


<extension

         point="org.eclipse.ui.menus">

      <menuContribution

            locationURI="menu:org.eclipse.ui.main.menu">

         <menu

               label="Dita">

            <command

                  commandId="oxygen.dita.command1"

                  label="Some Dita command">

[color=#FF0040]               <visibleWhen

                     checkEnabled="false">

                  <with

                        variable="activeEditorId">

                     <equals

                           value="your.certain.oxygen.editorID">

                     </equals>

                  </with>

               </visibleWhen>[/color]

            </command>

         </menu>

      </menuContribution>

 </extension>

Radu wrote: Can you give us an example of what specific actions you would like to remove for the end users?

We would like to leave out nearly all of your additional toolbar items, because our end users mainly only edit the xml content and do not transform anything or work with the underlying schema.

Post by **SSC** » Thu Dec 15, 2011 7:51 pm

Now I use this code while knowing that the unobfuscated classnames may change in future releases...

Code: Select all


Object data = event.data;

if (data instanceof StructuredSelection) {

   StructuredSelection selection = (StructuredSelection) data;

   Object firstElement = selection.getFirstElement();



   if (firstElement instanceof ro.sync.ecss.component.lb) {

      kb[] fragments = ((ro.sync.ecss.component.lb) firstElement).getFragments();

      for (kb kb : fragments){

           AuthorDocumentFragment b = kb.b();

	   List<AuthorNode> contentNodes = b.getContentNodes();

	   for (AuthorNode authorNode : contentNodes) {

		adjustDataToAuthornNode(authorNode);

	   }

       }

    }



  if (firstElement instanceof AuthorNode) {

    AuthorNode node = (AuthorNode)firstElement;			  adjustDataToAuthornNode(node);

   }

}

In the adjustDataToAuthornNode method I compare the passed authorNode with the

Code: Select all

editorPage.getFullySelectedNode();

to be sure that editorPage.getFullySelectedNode(); is the node which I actually dropped.
Then I add a processing instruction to that node :

Code: Select all

documentController.insertXMLFragment("<? Test PI ?>", fullySelectedNode,			AuthorConstants.POSITION_BEFORE);

This solution works quite well, but except of this cast because of the missing interfaces/API we talked about.

Code: Select all

   if (firstElement instanceof ro.sync.ecss.component.lb) {

      kb[] fragments = ((ro.sync.ecss.component.lb) firstElement).getFragments();

This is really worse, but at least it works

My actual question is how can I check if an PI is already existend for that AuthorNode?

When I searched the forum I found this code snipped :

Code: Select all


AuthorDocument ownerDocument = authorNode.getOwnerDocument();

      AuthorElement rootElement = ownerDocument.getRootElement();

      List<AuthorNode> allDocumentNodes = ownerDocument.getContentNodes();

      int rootIndex = allDocumentNodes.indexOf(rootElement);

      if(rootIndex > 0) {

        AuthorNode nodeBeforeRoot = allDocumentNodes.get(rootIndex - 1);

        if(nodeBeforeRoot.getType() == AuthorNode.NODE_TYPE_PI) {

          try {

            String piContent = nodeBeforeRoot.getTextContent();

          } catch (BadLocationException e) {

            e.printStackTrace();

          }

        }

      }

I changed it so that I am asking for the index of the passed authorNode.

Code: Select all

allDocumentNodes.indexOf(authorNode);

But this only returns -1 which means it does not find the node and so I am not able to check if a PI is already existend or not.
Is there maybe another way to get a previous sibling of an authorNode? Although I am not really sure if a PI can be a real sibling of a XML tag.

Or is it possible to define in the schema that only one PI is allowed and insert this PI schema aware?

Post by **Radu** » Fri Dec 16, 2011 11:35 am

Hi,

In Oxygen 13.2 (probably in January next year) you will have these objects not obfuscated (which will break your existing code

)

In my opinion, you should only look in the "selection.getFirstElement()" to see if it is an object coming from an Oxygen Author page (you can check on the object by reflection to see if it has a "getFragments()" method for example) and then look directly at the selection in the "editorPage.getFullySelectedNode()". I think that it's close to impossible that that selected node was not the one which was dropped in your custom view.

You added the custom PI using correct API.

Now for the question:

My actual question is how can I check if an PI is already existend for that AuthorNode?

So the Author page is a tree of AuthorNodes (similar to DOM nodes) which point in a single content string which contains all text nodes, an image for this can be found here:

http://www.oxygenxml.com/InstData/Edito ... gment.html

The code which you found iterates only in the children of the document (the comments, processing instructions + root element which are on the top level in the XML file).

I think your code should look more like this:

Code: Select all

    AuthorNode fullySelectedNode = edPage.getFullySelectedNode();

    if(fullySelectedNode != null) {

      //Maybe we have a processing instruction before it

      AuthorParentNode parent = (AuthorParentNode) fullySelectedNode.getParent();

      int indexOfFullySelectedNode = parent.getContentNodes().indexOf(fullySelectedNode);

      if(indexOfFullySelectedNode > 0) {

        AuthorNode previousNode = parent.getContentNodes().get(indexOfFullySelectedNode - 1);

        if(previousNode.getType() == AuthorNode.NODE_TYPE_PI) {

          //This should have both target and data

          String textContent = previousNode.getTextContent();

        }

      }

    }

About this question:

Or is it possible to define in the schema that only one PI is allowed and insert this PI schema aware?

Schema aware insertion is only concerned with inserting XML elements which adhere to the schema used to edit the XML file.
So you will have to make sure that your custom PI is not repeated.

Regards,
Radu

Post by **SSC** » Fri Dec 16, 2011 1:23 pm

Thanks for your reply.

If in Version 13.2 those classes are not obfuscated any more or you offer an interface for those classes I would resign to use the solution with reflection and just wait until January. Using reflection and check whether it contains a certain method is IMHO not satisfactory, I then prefer to wait.

Your Code with the AuthorParentNode works really well.

Have you also seen my previous post about the org.eclipse.ui.menus extension?
http://www.oxygenxml.com/forum/topic6502-15.html#p20146

If you have futher questions about this extension I would offer my help for you. I think to choose the build in extensions of the powerful eclipse framework is better then using an own solution, which is not customizable for your customers (and after I finished evaluating your XML Editor we may also become your customer

).

Post by **Radu** » Fri Dec 16, 2011 5:48 pm

Hi,

Have you also seen my previous post about the org.eclipse.ui.menus extension?

Sorry for the delay, we had a longer talk internally about this.
This approach seems possible so I added an improvement request to try and move the creation of most of our toolbars/menus to the plugin.xml.
This will not include the internal Author toolbar and menu which are contributed by the document type associated with the XML document.

Regards,
Radu

Post by **SSC** » Fri Dec 16, 2011 7:07 pm

Sorry for the delay, we had a longer talk internally about this.

We also just had an internal meeting about the Oxygen XML Editor and I was nearly able to persuade the management to choose Oxygen as a solution. My job is now to do some final tests concering the integration of Oxygen into our eclipse CMS client.
To come back to the "delay" you mentioned... One of the most important argument for using oxygen is the great support and fast response time by you in this forum. I am really impressed by that. Keep at it

This will not include the internal Author toolbar and menu which are contributed by the document type associated with the XML document.

I expected that beforehand and this leads directly to one of the questions of our management: "Is it possible to extend or modify the internal Author toolbar?"

At least the management will be happy, if you realize my recommendation with the menu items and the even more important fact that you and your company are responsive to wishes of the customers.

I wish you a nice weekend then.
See you on monday

Post by **Radu** » Mon Dec 19, 2011 11:52 am

Hi Simon,

About this question:

Is it possible to extend or modify the internal Author toolbar?

Yes and no. The Author internal toolbar has two lines. The first line (Refresh buttons, change tracking actions, etc) is fixed and cannot be configured.
From what I remember we've had a previous user who actually dynamically navigated our MultiPageEditorPart hierarchy, found the coolbar and disposed a couple of toolbars from it.

The second line is dynamically contributed by the Document Type which corresponds to the edited XML file, document type which has been defined in the Document Type Association Oxygen preferences page:

http://www.oxygenxml.com/doc/ug-editorE ... orial.html

Regards,
Radu

Post by **Radu** » Thu Jan 12, 2012 2:43 pm

Hi,

Oxygen 13.2 was just released, so the clipboard and drag and drop objects should now be exposed in the Java classes.

Regards,
Radu

Post by **SSC** » Thu Jan 12, 2012 5:17 pm

Thanks for your hint

It´s really great to see how fast you have realized the requests of your customers. Thumbs up for that.

Post by **SSC** » Fri Jun 29, 2012 10:19 pm

Hello Radu,

Some time ago we talked about the org.eclipse.ui.menus extension:

Radu wrote:
SSC wrote:Have you also seen my previous post about the org.eclipse.ui.menus extension?
[...]
This approach seems possible so I added an improvement request to try and move the creation of most of our toolbars/menus to the plugin.xml.
[...]

The first thing I searched for, after downloading Oxygen version 14, was the org.eclipse.ui.menus extension in your com.oxygenxml.author plugin.xml file, but I was not able to find any org.eclipse.ui.menus extension.

Is it maybe possible for uns, as customers, to see the state of certain improvement requests, like the one concerning the org.eclipse.ui.menus extension improvement?

Best regards,

Simon

Post by **Radu** » Tue Jul 03, 2012 10:44 am

Hi Simon,

This was not implemented in 14.0. I cannot tell you a precise timeline for this because it implies a lot of modifications and architecture changes on our side.

Is it maybe possible for us, as customers, to see the state of certain improvement requests, like the one concerning the org.eclipse.ui.menus extension improvement?

No, sorry, our issues list is internal.

Regards,
Radu

Dnd of Tag Elements

Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements

Re: Dnd of Tag Elements