[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KColorButton class in kdelibs/kdeui
From:       Mosfet <mosfet () jorsm ! com>
Date:       1999-07-22 22:56:17
[Download RAW message or body]

Hrm. Well the slot is obselete and I just removed the connect. The dialog
should be popping up in mouseReleaseEvent() if the mouse did not move more than
6 pixels, otherwise it is considered a drag. I needed to do things this way
because otherwise moving the cursor just one pixel while the mouse is down was
considered a D'nD event and overriding the QPushButton methods was acting very
odd (read the CVS log about the pushbutton staying down).

This works for me, if you got time I would look at the dragged flag and see if
that is being messed up...

On Thu, 22 Jul 1999, Cristian Tibirna wrote:
> On Thu, 22 Jul 1999, Mosfet wrote:
> 
> > This is of course assuming you are trying to make is use QColorDialog instead
> > of KColorDialog ;-) After reading your mail again I can't tell if that is what
> > you want or if you are not getting a dialog at all...
> 
> OK. Here's that *bug* again:
> 
> KColorButton has in the constructor a connect to a slot called
> slotClicked(). Of course nor KColorButton neither the parent class
> QPushButton (or QWidget, the grandparent class) don't have a slot called
> like this. Also, of course, clicking on a KColorButton doesn't do
> anything. Unfortunately, this is the first time in life so I can't use my
> (rather satisfactory :-) memory to say what the code looked like in the
> past.
> 
> Now I want to know if somebody knows why the slotClicked is connected but
> doesn't exist.
> 
> I'd also want to know if somebody protest to me adding a slotClicked slot
> which would do the obvious: pop up a QColorDialog, get the color from it
> and then repaint the KColorButton.
> 
> Thanks
> 
> Cristian
-- 
Daniel M. Duley - Unix developer & sys admin.
mosfet@kde.org
mosfet@jorsm.com

[prev in list] [next in list] [prev in thread] [next in thread]