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

[Pau Arumí Albó]

El dj 29 de 05 de 2008 a les 05:49 -0300, en/na Natanael Olaiz va
escriure:
> Here I resend the patch of the "Connect to" function, with a little 
> cleaner code, and a patch for a very cheating Copy&Paste processing(s) 
> functionality. It uses QClipboard, but I send only the processings names 
> of actual/selected processings on plain text :-) To do it seriously, I 
> could define a new MIME format and use it in a similar way... or take 
> the David advice to use his XML implementations on the Network (I 
> unsuccessfully tried, I need to study further about all that stuff).
> 

1-ProcesingContextConnectTo.cleanup.patch --> commit 11426
Very nice feature. Thanks!

For the second patch CheatCanvasCopyAndPasteProcessign.patch I got some
errors (rejected chunks) when applying it. So I'll wait for a new
version.

Please, notice me if there are pending patches.

Pau



> Regards,
> Natanael.
> 
> El 05/28/2008 02:41 PM, Natanael Olaiz escribió:
> > Sorry, I forgot to send a separate patch for the audio check issue.
> >
> > 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
> >>
> >>  
> >>>  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)
> >>
> >> 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...
> >>>>       
> >>>
> >>> _______________________________________________
> >>> Clam-devel mailing list
> >>> Clam-devel at llistes.projectes.lafarga.org
> >>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel 
> >>>
> >>>     
> >>
> >>
> >> _______________________________________________
> >> Clam-devel mailing list
> >> Clam-devel at llistes.projectes.lafarga.org
> >> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel 
> >>
> >>
> >>   
> >
> 
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel