[Clam-devel] Improving Faust usability

[Natanael Olaiz]

El 07/19/2008 05:59 PM, Pau Arumí escribió:
> On ds, 2008-07-19 at 17:23 -0300, Natanael Olaiz wrote:
>   
>> El 07/19/2008 08:05 AM, Pau Arumí escribió:
>>     
>>> On ds, 2008-07-19 at 06:33 -0300, Natanael Olaiz wrote:
>>>
>>>   
>>>       
>>>> I commited it (r11640):
>>>>
>>>>      * TaskRunner: created a widget with a cancel/close buttons. Cancel
>>>>     terminate the actual processs, clear the queue list and returns an
>>>>     error.
>>>>     
>>>>         
>>> That was fast! I like the buttons layout.
>>>
>>> I've tested rev 11644 and it still have (two) pop-up windows, one asking
>>> if you want to proceed, and the second informing about the success or
>>> failure.
>>> The point is avoiding any pop-up window, the console output (and the
>>> cancel button) will suffice.
>>>   
>>>       
>> r11656:
>>
>>      * TaskRunner: the destructor terminate the current process and
>>     emits a widgetDestructor signal
>>      * MainWindow:
>>             - removed the popups on Faust compilation
>>             - the TaskRunner::widgetDestructor signal enable
>>     ui.action_Compile_Faust_Modules (to avoid keep it disabled when
>>     closing the QDockWidget)
>>     
>
> I've compiled this revision and the first pop-up still pops up. Only the
> first.
>   
Ups, I forgot that. Commited.

>> A question: now after the compilation (done or canceled) the 
>> action_Compile_Faust_Modules is re-enabled. If you call it without close 
>> the QDockWidget it will open another instance. Should I simply enable 
>> the action when the widget is closed, or make the local runner as  
>> _runner to reuse it if not closed?
>>     
>
> The first option seems bad to me. I imagine a user saying "why now I
> can't compile when a minute ago I could!" The second better.
> But the current behavior (adding widgets) even better. First, it splits
> horizontally without taking extra space, and Qt handles well the widgets
> overload. And second, I see it useful to compare the log of two
> compilations, for example before doing a .dsp modification and after.
>   
OK, let's keep it as is.

> P
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>