[Clam-devel] patch: added submenues in context menu to connect with compatible ports in canvas

[David García Garzón]

Nice! How fast!

I liked the separator between the monitors and the sink/sources.
Also, instead 'Connect to used processing' a 'Conect to' could be enough.
What about joining the processing and the port levels? Anyway the patch should 
be committed just to keep changes atomic.

BTW, the same screenshots you are sending as attachment, should be inserted 
into the development screenshots wiki instead.

http://iua-share.upf.edu/wikis/clam/index.php/Development_screenshots



El Wednesday 28 May 2008 18:55:06 Natanael Olaiz va escriure:
> El 05/28/2008 01:22 PM, Pau Arumí escribió:
> > On dc, 2008-05-28 at 12:05 +0200, David García Garzón wrote:
> >> I liked the idea at first instance. But looking at that screenshot i
> >> find it very messing for the user. What's the difference between the
> >> first and the second oscilloscope? The first one is creating a linked
> >> processing while the second one is about connecting to an existing one.
> >> I don't have a solution on that but let's mature an idea.
> >>
> >> One solution could add multilevel menu 'connect to' or 'create linked',
> >> or just one of them while keeping the other in the first level.
> >
> > I like this option, because we can have MANY processings in the canvas,
> > while the available sinks remain small
>
> I was replying the same. :)
> Do you like now? (Plus, I commented the separator between monitors and
> sinks/sources)
>
> >>  Or providing a
> >> dialog interface for choosing the connected ports. Or showing
> >> the 'processing.port' in a single level. I am not that convinced on any
> >> of the solutions. Any ideas?
> >>
> >> BTW, 'f' is typeid(CLAM::TData).name() for gcc (non portable), so i
> >> think that should be expressed in that way. It is more self explanatory
> >> and also strong to changes on the way of representing typeid's names
> >> which are not standard.
> >
> > Sure! (Natanael you can patch this)
>
> Done.
>
> A question: I implemented within the patch a way to check for an
> attribute ("icon", in this case) in a secure way. What do you think to
> put it on Factory like an "AttributeExist" method?
>
> > P
> >
> >> David.
> >>
> >> On Dimecres 28 Maig 2008, Natanael Olaiz wrote:
> >>> This idea took me more time that I expected, so I didn't improve a few
> >>> ugly copy&paste testings yet. :-/
> >>> Here is the patch and a screenshot. It works, but probably the code
> >>> could be improved and I need to check the names...