[Clam-devel] Patch with questions: tooltip on ProcessingTree

[Natanael Olaiz]

El 05/26/2008 12:13 AM, David García Garzón escribió:
> Notice that last commits on NetEditor are moving CLAM dependant features out 
> of the ProcessingBox and even out of NetworkCanvas because we want to reuse 
> the NetworkCanvas for other kind of networks: currently Jack networks in the 
> new NetEditor tab, but also enabling it for reuse in other projects. 
>
> So any of the CLAM dependant code (ie, looking up in the factory metadata) 
> should be delegated to a virtual function in the canvas (which name should 
> have a 'generic' meaning) and implement it on the concrete method of 
> ClamNetworkCanvas.
>
> Also, be aware that you are using the name as key for the factory. This works 
> because name and type match when you drop one processing into the canvas, but 
> the second one will be named Oscillator_2 instead just Oscillator.
>
>   
Thanks for your corrections.
Previously I putted on ProcessingBox to avoid regenerate the tooltips 
every time. Do you think it could be useful to do something similar on 
ClamNetworkCanvas, or it's fine as is in this new patch?


> On Divendres 23 Maig 2008, Natanael Olaiz wrote:
>   
>> Here is the idea of the tooltips methods on ProcessingBox. I don't know
>> if all could be really necessary, or just the setDefaultToolTipText...
>>
>>
>> Best regards,
>> Natanael.
>>
>> El 05/23/2008 02:11 PM, David García Garzón escribió:
>>     
>>> Is it the mouse tracking still needed? It adds a lot of load to the
>>> application that every mouse movement goes into the event queue, instead
>>> just enter and leave mouse events.
>>>
>>> On Divendres 23 Maig 2008, Natanael Olaiz wrote:
>>>       
>>>> El 05/23/2008 06:49 AM, David García Garzón escribió:
>>>>         
>>>>> Is the mouse tracking and paintEvent catching and the like needed at
>>>>> all? I think that a simple call to item's setToolTip that your are
>>>>> indeed calling should suffice:
>>>>>
>>>>> http://doc.trolltech.com/4.4/qtreewidgetitem.html#setToolTip
>>>>>
>>>>> I think that the problem is that you are using column 1 instead of 0
>>>>> that is the visible one. Note that column 1 is hidden and is used to
>>>>> store the actual key of the processing.
>>>>>           
>>>> Ups!...
>>>>
>>>> Here is the changed patch. Very much simpler. :-)
>>>> Thanks, David.
>>>>
>>>>
>>>> Best regards,
>>>> Natanael.
>>>>
>>>>         
>>>>> On Divendres 23 Maig 2008, Natanael Olaiz wrote:
>>>>>           
>>>>>> El 04/29/2008 02:13 PM, Pau Arumí Albó escribió:
>>>>>>             
>>>>>>>>>    - Added a tooltip when moving over the name of processing box
>>>>>>>>> (is a little bit annoying)
>>>>>>>>>                   
>>>>>>> I like it (i don't know if i'm missing the annoying part). I find it
>>>>>>> very useful.
>>>>>>>
>>>>>>> Another related feature i'd like to see is this tooltip when moving
>>>>>>> over the processing-tree (the left pane).
>>>>>>>               
>>>>>> I made it in some way, but I don't like it...
>>>>>>
>>>>>> I tried to put it on a paintEvent (the alternative code is commented
>>>>>> in the patch), but I had two problems (I'm so newbie on Qt... could
>>>>>> anyone help me with this?):
>>>>>>     - When i create a QPainter object sometimes I got (I need to
>>>>>> filter certain QPaintEvent (s)?):
>>>>>>
>>>>>>     QPainter::begin: Widget painting can only begin as a result of a
>>>>>> paintEvent
>>>>>>
>>>>>>     - I didn't know how to update the widget from the OverProcessing
>>>>>> slot, to make it call to paintEvent...
>>>>>>
>>>>>> So, I putted a simple QToolTip::showText direct from the slot.
>>>>>>
>>>>>> (The last days I was finishing some readings about C++... I'll need to
>>>>>> use this next days to read about Qt!...)
>>>>>>
>>>>>>             
>>>>>>> [...]
>>>>>>> With the minor fixes, this is commitable. But i'd like a next step
>>>>>>> that removes the hardcoded attributes "category", "description" and
>>>>>>> gets all metadata instead -- using Factory::GetPairsFromKey(...)
>>>>>>>               
>>>>>> I did it. But anyway, I putted some "hardcoded" checks to take away
>>>>>> "icon" attributes, empty values and values equals to the main key name
>>>>>> -i.e. empty descriptions-. Do you think is better now?
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Natanael.
>>>>>>             
>
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProcessToolTipsOnNetworkCanvas.patch
Type: text/x-patch
Size: 2307 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080526/32ebda2d/attachment-0005.bin>