[Clam-devel] Re: faust status

[Natanael Olaiz]

Just the same patch without some trash on the .ui (still are some 
changes that I'm not sure why are there, but I'll change from the 
original when I could restore it from the SVN).
Also I changed processingOpenFileWithExternalApplicationFrom to 
openFileWithExternalApplicationFromProcessing.

El 07/12/2008 06:35 AM, Natanael Olaiz escribió:
> I can't connect to iua.upf.edu, so here I send a patch of the changes.
>
> A question: now I'm saving/restoring the option as a setting, but the 
> variable is still in the canvas... how can I get it from 
> ClamNetworkCanvas if I put it on MainWindow?
>
> 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
>>>>>>           
>>
>>
>>
>>   
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NE_faust.patch
Type: text/x-diff
Size: 12697 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080712/154a9d83/attachment-0004.patch>