KComboBox in designer WAS Re: kartesio
Orestes Mas
orestes at tsc.upc.edu
Wed May 8 19:15:54 UTC 2013
El Dimecres, 8 de maig de 2013, en/na Albert Astals Cid va escriure:
> El Dimecres, 8 de maig de 2013, a les 14:18:43, Orestes Mas va escriure:
> > To fix it it's enough to use a KComboBox in designer, but the point is I
> > cannot do that because I want this combo act as an own-derived class
> > (myaudiocombo) and to do that I've to *promote* the standard combo in
> > designer to my combo class, but designer only allows me to promote Qt
> > classes, not KDE ones.
> >
> > Do you know which is the proper way to handle this (pretty common, I
> > presume) situation?
>
> My suggestion, don't inherit from Q/KComboBox, don't think you really need
> it.
>
> I've looked at your class the only think i can see is you hijacking the
> polish event, but you can totally do that with an eventFilter if you need
> to. The rest just seems like would totally work with "have a KComboBox"
> instead of "is a KComboBox".
>
My reasoning was: I've a ComboBox letting user choose between ALSA or
PulseAudio sound systems. If user changes current combo selection, I want a
second combo (the one we are speaking of) to ask gstreamer for a list of audio
devices in the new selected sound system, and to fill itself with these values.
As this operation requires a bit more intelligence than a standard combo, my
idea was to derive a class implementing the suitable functionality.
So, if I understand you correctly, your advice is to transfer all this
behaviour from my custom combo to the class containing it, am I right? For
instance, let the widget containing the combo (in my cas is a customized
settings dialog) detect changes in the first combo and updating the second one
accordingly.
Would you reccomend this? This will certainly solve the problem, but on that I
should object that having some more widgets with similar needs on the same
dialog would lead to long source file for the dialog class. I'd like to keep
source files manageable, but if there's no other solution...
--
Orestes Mas.
More information about the kde-edu
mailing list