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

David García Garzón dgarcia at iua.upf.edu
Fri May 23 10:11:55 PDT 2008


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.



-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080523/64d6c0ef/attachment.sig>


More information about the clam-devel mailing list