[Clam-devel] Re: faust status

[Natanael Olaiz]

Commited in two steps, and changed some names on MainWindow and 
NetworkCanvas. Now those names are a little bit large, but I think now 
them refers better to its uses.

Commit 11582:
 * RunTimeLibraryLoader: Load() changed to virtual, added some commented 
debug messages, and minor changes on CompletePathFor()
 * RunTimeFaustLibraryLoader:
    - implemented virtual Load() to search first for the examples faust dir
    - added std::map GetCompilePluginCommands(std::string 
pluginSourceFullName) to get required faust compilation commands with 
the propers paths
    - if plugin exists in factory, use ReplaceCreator instead 
AddCreatorWarningRepetitions
    - added helpers: faustBinCommand() and faustLibIncludeFile()

Commit 11583:

 * ClamNetworkCanvas:
    - added signal: openFileWithExternalApplicationRequest
    - added QString _fileNameToOpen (used when catching the previous 
signal on MainWindow), onOpenFileWithExternalApplication to set it and 
getFileNameToOpenWithExternalApplication() to get it
    - added slot onOpenFileWithExternalApplication
    - added "Open diagram with browser" item on processings context menu 
which have svg_diagram attribute
    - added "Open source with editor" item on processings context menu 
which have dsp_source attribute
 * NewtorkEditor MainWindow:
    - added slot on_action_Launch_Browser_triggered
    - on_action_Online_tutorial_triggered() calls 
on_action_Launch_Browser_triggered
    - added slot 
on_action_Processing_Open_File_With_External_Application_triggered, 
connected to ClamNetworkCanvas::openFileWithExternalApplicationRequest 
signal
    - added messages on slot on_action_Compile_Faust_triggered, and 
changed to search the .dsp files on faust examples directory and compile 
them one by one directly (doesn't need to have Faust installed or makefiles)


El 07/08/2008 03:10 PM, Natanael Olaiz escribió:
> El 07/08/2008 02:38 PM, Pau Arumí escribió:
>> I've looked at the patch. Go ahead and commit. And maybe I'll propose
>> some refactoring afterward. Great work!
>>   
> OK.
>
>> On dl, 2008-07-07 at 19:25 -0300, Natanael Olaiz wrote:
>>  
>>> El 07/07/2008 02:12 PM, Pau Arumí Albó escribió:    
>>>> Hi Natanael,
>>>> could you please remind me the status of your Faust work?       
>>> Here is the last path about that I made. It doesn't need to have 
>>> Faust installed, just to have the .dsp source
>>> files on '$FAUST_PATH/examples' (or ~/.faust/examples), the 'faust'
>>> compiler on  '$FAUST_PATH/compiler' (or ~/.faust/compiler) and the
>>> 'ladspa.cpp' on '$FAUST_PATH/architecture' (or ~/.faust/architecture).
>>> It allows to recompile all found .dsp from the NE main menu as your
>>> original code, but without using 'make' (to avoid needing faust
>>> installed). Also it allows to browse the .svg and edit the ,dsp code
>>> from the processing context menu (and for now there is a dummy
>>> "recompile" option too):
>>>     
>>
>> I'm not sure whether t we want NE to know how to compile faust scripts
>> (maybe yes, but want to think more about it). If faust Makefile would
>> provide an option to use the local faust binary it would be easier,
>> right? We could propose a Makefile patch to faust devels.
>>   
>
> The major problem is that Faust doesn't support by now (at least I 
> didn't found) defining the libraries path when you call it, just 
> search by default at /usr and the active path (that's because I change 
> to the 'architecture' path when calling the compiler)
>
> Another option could be making an external script which do the actual 
> compilation tasks (i.e. doing also the searches for the compiler and 
> libraries)..
>
>>> I think there is a pending patch and some questions, right?    
>>>>         
>>> Yes:
>>>       * What do you think about the factory changes? I created
>>>         CLAM::Factory::ReplaceCreator (and Registry/FactoryRegistrator
>>>         related methods) to use instead of AddCreatorWarning in case
>>>         that plugin already exists on reloading. It erase the original
>>>         creator and create a new one. Is that good? I didn't found any
>>>         other way to erase just a single creator for the dynamic
>>>         plugin's loading...
>>>       * I created
>>>         'RunTimeFaustLibraryLoader::GetCompilePluginCommands' which
>>>         uses the previously created
>>>         'RunTimeLibraryLoader::CompletePathFor' to return the
>>>         compilation commands. I putted there because I though is more
>>>         related to the specific Faust library loader, but I'm using it
>>>         from MainWindow as a kind of static method. Anyway, I can't
>>>         define as static because CompletePathFor uses
>>>         'RunTimeLibraryLoader::GetPaths' which is not static (also I'm
>>>         using CompletePathFor from MainWindow to search for the .dsp
>>>         directory). What do you think about that? Put the methods on
>>>         MainWindow instead? Duplicate the GetPaths code and make them
>>>         static? Make another code file to manage the faust compilation
>>>         and related tasks?
>>>       * I don't like the method that I used to deal with calls to
>>>         MainWindow from the canvas (the NetworkCanvas emit signals
>>>         catched from MainWindow, which calls back to
>>>         NetworkCanvas::getFileNameToBrowse). Plus, I'm getting some
>>>         messages when I run the NE:
>>>                 QMetaObject::connectSlotsByName: No matching signal
>>>                 for
>>>                 
>>> on_action_Reload_Faust_Plugins_triggered(RunTimeFaustLibraryLoader&)
>>>                 QMetaObject::connectSlotsByName: No matching signal
>>>                 for on_action_Processing_Launch_Editor_triggered()
>>>                 QMetaObject::connectSlotsByName: No matching signal
>>>                 for on_action_Launch_Editor_triggered(QString&)
>>>                 QMetaObject::connectSlotsByName: No matching signal
>>>                 for on_action_Processing_Launch_Browser_triggered()
>>>                 QMetaObject::connectSlotsByName: No matching signal
>>>                 for on_action_Launch_Browser_triggered(QString&)
>>>         How do you suggest to manage that? I think using the context
>>>         menues on the canvas is the comfortablest way to put those
>>>         commands, but the needed code has not much to do in NE...
>>> Well... for now I think these are my main doubts. :)
>>>     
>>
>> I'll look at these issues later (anyway they are not important enough to
>> keep you back from commiting)
>>
>>   
> OK, now I'll commit it. Thanks!
>
>
>> P
>>
>>
>>
>>
>>   
>
>