2011/10/4 Peter Soetens <peter [..] ...>

> I've run this service again for our euRobotics 'simulation' deployment (see
> attachment)
>
> - Maybe instead of the connection name, we could indicate the connection
> type instead. With the words 'buffer[size]' or 'data' for example. The long
> names impair readability and don't give any extra information.
> - Readability might improve if the arrows leaving an output port or
> entering an input port would originate from the same point. I have no idea
> to do this.. drawing another 'icon' which represents a port would not
> guarantee that the port icon stays close to the component in the drawing.
> - We might need another service to display peer connections. I don't think
> its readable to show both.
> - Ports of services are not done yet..? We could show services which have
> ports as ovals as well, but again, these could be relocated far away by the
> drawing algorithm.
>
> Anyway, very usable as it is... and independent of ROS :-)
>
> Peter
>

FYI, here is a screen for a more connected scheme. Sorry for the size of the
screen I can't do better for having the hole scheme.

>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

On Monday 17 October 2011 02:11:21 Willy Lambert wrote:
> 2011/10/4 Peter Soetens <peter [..] ...>
>
> > I've run this service again for our euRobotics 'simulation' deployment
> > (see attachment)
> >
> > - Maybe instead of the connection name, we could indicate the connection
> > type instead. With the words 'buffer[size]' or 'data' for example. The
> > long names impair readability and don't give any extra information.
> > - Readability might improve if the arrows leaving an output port or
> > entering an input port would originate from the same point. I have no
> > idea to do this.. drawing another 'icon' which represents a port would
> > not guarantee that the port icon stays close to the component in the
> > drawing. - We might need another service to display peer connections. I
> > don't think its readable to show both.
> > - Ports of services are not done yet..? We could show services which have
> > ports as ovals as well, but again, these could be relocated far away by
> > the drawing algorithm.
> >
> > Anyway, very usable as it is... and independent of ROS :-)
> >
> > Peter
>
> FYI, here is a screen for a more connected scheme. Sorry for the size of
> the screen I can't do better for having the hole scheme.

This shows again what composition of components is useful for as well...
providing clear overview of the system from the top level.

Peter

2011/10/5 Willy Lambert <lambert [dot] willy [..] ...>

>
>
> 2011/10/5 Steven Bellens <steven [dot] bellens [..] ...>
>
>> 2011/10/5 Willy Lambert <lambert [dot] willy [..] ...>:
>> >
>> >
>> > 2011/10/5 Peter Soetens <peter [..] ...>
>> >>
>> >> On Tue, Oct 4, 2011 at 11:35 PM, Steven Bellens
>> >> <steven [dot] bellens [..] ...> wrote:
>> >>>
>> >>> 2011/10/4 Peter Soetens <peter [..] ...>:
>> >>> > I've run this service again for our euRobotics 'simulation'
>> deployment
>> >>> > (see
>> >>> > attachment)
>> >>> > - Maybe instead of the connection name, we could indicate the
>> >>> > connection
>> >>> > type instead. With the words 'buffer[size]' or 'data' for example.
>> The
>> >>> > long
>> >>> > names impair readability and don't give any extra information.
>> >>>
>> >>> Agree, tried to implement it but didn't test is extensively though.
>> >>
>> >> Bugfix for this in attachment :-)
>> >>
>> >>>
>> >>> > - Readability might improve if the arrows leaving an output port or
>> >>> > entering
>> >>> > an input port would originate from the same point. I have no idea to
>> do
>> >>> > this.. drawing another 'icon' which represents a port would not
>> >>> > guarantee
>> >>> > that the port icon stays close to the component in the drawing.
>> >>>
>> >>> Pretty easy, edges accept a tailport and headport argument, which you
>> >>> can set to any direction (n,e,s,w,ne, etc..). Done.
>> >>
>> >> It doesn't group them by port.
>> >>
>> >>>
>> >>> > - We might need another service to display peer connections. I don't
>> >>> > think
>> >>> > its readable to show both.
>> >>>
>> >>> We might be able to display peers with the same contour colors maybe?
>> >>
>> >> I don't see how this could work.
>> >>
>> >>>
>> >>> > - Ports of services are not done yet..? We could show services which
>> >>> > have
>> >>> > ports as ovals as well, but again, these could be relocated far away
>> by
>> >>> > the
>> >>> > drawing algorithm.
>> >>>
>> >>> DOT has subgraphs, but I never worked with those either. Might offer a
>> >>> solution for this problem.
>> >>>
>> >>> > Anyway, very usable as it is... and independent of ROS :-)
>> >>>
>> >>> Now start using it :)
>> >>
>> >> :-)
>> >> Peter
>> >>
>> >
>> > I tried this on a little example, it works fine here. I love it. I'll
>> try
>> > this on a hudge example as soon as my app is working under xenomai ;)
>> > It is a must have for the default Orocos installation, and more, I would
>> put
>> > it by default in the deployer.
>> > The only suggestion for now would be to enlarge the size of "Component"
>> > drawing if it is possible. Cause in a heavily connected application
>> you'll
>> > need some space to connect ports and it would be more readable if you
>> can
>> > find components easily
>>
>> I've put the dot syntax arguments as properties for drawing
>> components, connections and channels - so you can play with it
>> yourself to get the graph you like most.
>> If anyone wants to implement service ports as well, feel free to send
>> patches - I don't have any more time for it in the near future myself.
>>
>>
> Great I have big bubles now ;)
>
>
Is it possible to modify those properties from Lua ?
I tried this :
Deployer:provides("dot"):getProperty("comp_args"):set("style=filled,width=5,height=3.5")

and this
print(Deployer:provides("dot"))

which prints :
Service: dot
Subservices:
Operations: generate, getOwnerName
Ports:

so I wonder if Lua know how to get a property in a servcie ?

>
>
>> Steven
>>
>> >
>> >>
>> >>
>> >> --
>> >> Orocos-Dev mailing list
>> >> Orocos-Dev [..] ...
>> >> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>> >>
>> >
>> >
>>
>
>