[Clam-devel] Re: faust status

Natanael Olaiz nolaiz at gmail.com
Fri Jul 11 13:00:38 PDT 2008


Thank you very much for your comments, there are very informative!

I readed this now, since I was without internet access... and now I have 
to go. This night I'll change that and commit the results.


Regards,
Natanael.

El 07/11/2008 08:01 AM, David García Garzón escribió:
> I think is ok to put it in MainWindow so that you can save it in QSettings.
>
> About the menus options i will handle them all in the .ui file instead of in 
> code, just enabling them if USE_LADSPA.
>
> Try to avoid macros to remove parts of code unless you are debugging. For 
> example the SVG_WIDGET macro has no sense at all now it is stable and that we 
> have an option.
>
> Restrict the on_... method names to the ones that are implicitly connected 
> slots which follow qt naming conventions to implicitly connect slots. For 
> example onLaunchBrowser would be launchBrowser.
>
> In general the conventions for slots and signals
> Signals: somethingHappened()   (using past)
> Slots: doThatThink   (imperative, just like a regular method)
> so that when you connect you can read:
> When emmiter somethingHappened receiver doThatThing
>
> Then the explicitly connected slots are named
> on_uiObjectName_signalName()
> I use them mostly with actions defined on the ui to avoid having to do:
> connect(_ui->uiActionName, SIGNAL(triggered()), this, SLOT(doThat()))
>
> Also I saw you are emiting slots or regular methods. Don't emit methods not 
> being signals, just call them. If you call an slot within the class just call 
> it like a regular function. Just emit signals, not slots neither regular 
> methods.
>
> In this case, I don't know if you did so, but anyway is a good advice to 
> anyone new (or not that new) to qt: avoid using the signal slot mechanism 
> when the signal is not directly an user event but code you write, and you 
> know who is the receiver object and the receiver method. New people to Qt get 
> entusiastic with sigslot mechanism which is powerful but has less compile 
> time checks, is hard to trace and adds signal resolution overhead. 
> Annotator's vmqt is a good example on over use and it is a hell to understand 
> it ;-)
>
>
>
> On Divendres 11 Juliol 2008, Natanael Olaiz wrote:
>   
>> The same on a submenu:
>>
>> screenshot: NetworkEditor Faust menu actions
>>
>> El 07/11/2008 04:15 AM, Natanael Olaiz escribió:
>>     
>>> The same, but now the two Faust related menu actions are created from
>>> MainWindow.hxx, and appears only "ifdef USE_LADSPA".
>>>
>>> BTW, I just realize that the embedded svg option is not exclusive to
>>> Faust plugins. Anyway, by default it starts without it, so if you like
>>> it, I'll commit it.
>>>
>>> And a question. What is the best place for the slot
>>> onOptionEmbedSvgDiagramsChanged()? MainWindow, as in the patch (where
>>> the signal come), or directly on ClamNetworkCanvas (in _canvas)?
>>>
>>> El 07/11/2008 01:48 AM, Natanael Olaiz escribió:
>>>       
>>>> El 07/09/2008 06:00 PM, Pau Arumí Albó escribió:
>>>>         
>>>>> El dc 09 de 07 de 2008 a les 22:16 +0200, en/na David García Garzón va
>>>>>
>>>>> escriure:
>>>>>           
>>>>>>> - Hey, your screenshots have Sinks and Sources with svg diagrams. But
>>>>>>> mines no. I want them! :-)
>>>>>>>               
>>>>>> I don't like them too much but maybe another icon could look better.
>>>>>>
>>>>>> I think the faust svg feature although cool and awesome, is not
>>>>>> convenient for usability because they add too much elements on the
>>>>>> screen, which is something we want to solve with the subnetworks
>>>>>> feature. Making the diagram appear on user query, maybe in a side
>>>>>> view could be better. We can now use QWebKit to have linked svg's!
>>>>>>             
>>>>> I tend to find those diagrams useful to understand the network --which
>>>>> tells me this decision might depend on the user's taste.
>>>>> I'd like to avoid doing too much work now (like having a side view),
>>>>> and
>>>>> first gain experience using faust and specially have feedback of faust
>>>>> users.
>>>>> Anyway, I agree that we that faust-svg diagrams could be somehow
>>>>> optional: a NE bool setting "show faust svg diagrams" could
>>>>> enable/disable the svg embedding *when inserting a new processing*,
>>>>> which I think it's straightforward to do. David, Natanael: do you buy
>>>>> it?
>>>>>           
>>>> In this patch I added the bool option to ClamNetworkCanvas, and is
>>>> managed from the menu of main window. Not the best option, because it
>>>> will be showed on non-linux environments, but I don't know where to
>>>> ask the user for the option inserting the .svg...
>>>>
>>>> Plus I renamed some action names on MainWindow (r11583), with
>>>> unmatched ui signals.
>>>>
>>>>         
>>>>> P
>>>>>           
>
>
>
>   





More information about the clam-devel mailing list