How can we add a new icon in the ONOS GUI ?

106 views
Skip to first unread message

程凡

unread,
Aug 9, 2015, 6:27:32 AM8/9/15
to ONOS Developers
Hi team.
I'm working on a PoC about Microwave Equipment, we want to present a microwave NESs icons in the ONOS GUI, and I have read a tutorial on how to add a icons on ONOS GUI(the tutorial is https://wiki.onosproject.org/display/ONOS/UI+View+-+Defining+a+Custom+Glyph). But the tutorial do not teach us how to add a new kind of equipment icon to ONOS system.

In glyph.js, I find a set of equipment definitions, such as switch,roadm,flowTable and so on, if I add a new definitions of microwave, what else should I do to show the microwave icon when this type of device connected to ONOS?

Simon Hunt

unread,
Aug 10, 2015, 12:56:01 PM8/10/15
to 程凡, ONOS Developers, Thomas Vachuska
Hello 程凡, 

The current behavior is for the icon ("glyph") to be selected based on the Type of the Device (see lines 28-30 of Device.java). 
The Topology view uses the device type (converted to lowercase) as a lookup key in the Glyph Service to obtain the glyph to use 
when rendering that device.

As you noted, we have a mechanism to inject new glyphs at runtime (as outlined by the tutorial you cited). However, what is
missing is the ability to introduce arbitrary new device types into the data model on the server side.

I have created a new Jira ticket ONOS-2564 to express our desire to accommodate your request. It includes the implementation
note that an annotation on a device with the key 'glyphId' would be used to tell the Topology View which glyph to use when
rendering the device's icon. (The annotation would override the use of the device "type" to select the key). 

In this way, you would be able to:
  • set the device type to be Device.Type.OTHER  
  • add an annotation to the device instance of "glyphId" --> "microwave"
  • inject a microwave glyph into the Glyph Service (with JavaScript)
The topology view would do the rest.

I'm not sure what the process is for requesting new types added to the Device interface is, and will defer to others on the list
for comments in that regard.

Cheers, 
~Simon





--
You received this message because you are subscribed to the Google Groups "ONOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to onos-dev+u...@onosproject.org.
To post to this group, send email to onos...@onosproject.org.
Visit this group at http://groups.google.com/a/onosproject.org/group/onos-dev/.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/onos-dev/3cc338fd-40de-4f22-bb82-1c96f9d5beda%40onosproject.org.

Thomas Vachuska

unread,
Aug 10, 2015, 1:18:19 PM8/10/15
to Simon Hunt, 程凡, ONOS Developers
Hi,

As Simon pointed out, the icons today are derived from the Device.Type. This is intended to be a course-grained classification of the various flavors that networking equipment can be. We definitely want to represent MW equipment, just as we did with optical equipment so we should of course add the basic MW type(s). Given that this is an enum value - and we want it to stay that way - we won’t be able to provide for dynamic extensibility of the Type.

However, we are planning to allow device glyphs to be defined via network configuration (network admin-based control) and also via device drivers (vendor-based control). These two mechanisms will allow specifying which glyph to use for a device; the mechanism for adding new/custom glyphs to the GUI would remain as Simon described it.

Thomas

程凡

unread,
Aug 11, 2015, 9:35:36 AM8/11/15
to ONOS Developers
Hi
thanks for the replies.

I think I should do the following things if i want to show a MW icon:

1. add the basic MW type(s) to the Device Type enum
2. add a new (MW)driver to discover MW equipments (so that the device type is MW)
3. add a new definition of mw in the glyphDataSet of glyph.js

am I right?

if so, I will push codes about that to gerrit later this week.

Cheers,
Cheng Fan

Thomas Vachuska

unread,
Aug 11, 2015, 12:24:13 PM8/11/15
to 程凡, ONOS Developers
Hi Cheng,

I would suggest you do all these in stages and separate reviews as you listed them out. The primary reason is that the MW device provider may end-up larger chunk.

Step #1 and #3 should be straightforward. For the step #2, are you planning to extend the existing OpenFlowDeviceProvider or were you going to add some other means of discovery for the MW devices?

Thomas

--
You received this message because you are subscribed to the Google Groups "ONOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to onos-dev+u...@onosproject.org.
To post to this group, send email to onos...@onosproject.org.
Visit this group at http://groups.google.com/a/onosproject.org/group/onos-dev/.

程凡

unread,
Aug 12, 2015, 11:15:49 AM8/12/15
to Thomas Vachuska, ONOS Developers
Hi Thomas,
Thanks for your suggestions, I totally agree with you.
I think it's enough to extend the existing OpenFlowDeviceProvider for the MW devices, maybe we need to add some new port types(just like the OchPort,OmsPort in optical devices).
You can see the details in the code reviews later.

cheers,
Cheng Fan.

Thomas Vachuska <t...@onlab.us>于2015年8月12日周三 上午12:24写道:
Reply all
Reply to author
Forward
0 new messages