| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 4 | |
Hi all, I am currently porting Qt3 code to Qt4, and I don't want to use any compatibility trick. Everything went OK (well I've already done some such porting), till I stumbled on a place where QButtonGroup's are used in a sequencer tracks display (QGridLayout). In Qt3, every set of buttons (e.g. the colon of 'mute' checkboxes) had their own QButtonGroup. I had full control on the id of every button in the set and so it was easy to let the user add / remove tracks wherever he wants. Also I could easily connect each of these QButtonGroup to a slot of the parent widget using a single: connect(bg_muted, SIGNAL(clicked(int)), this, SLOT(flipMuted(int))); Now in Qt4, I have no control on the button's id. I can't anymore insert a button with the id of my choice. I dare not use the position in "QList<QAbstractButton *> buttons ()" because its management is not documented. Clearly the ids are not considered useful any more: even the QButtonGroup signal: void QButtonGroup::clicked ( int id ) has changed to: void QButtonGroup::buttonClicked ( QAbstractButton * button ) My problem is that I need to know which row a button belongs to, in order to act upon the proper track. While identifiers inside QButtonGroup were quite convenient for that use, I currently only see very convoluted solutions. Any idea welcome, AO ######################################################################## -- [ signature omitted ]
I'm not sure I completely understand your problem, but is a QSignalMapper what you're looking for? It would take a buttonClicked(QAbstractButton*) as an input and emit a signal with the ID that you assigned to that button. Tom On Mon, Mar 24, 2008 at 8:37 AM, Alexandre Oberlin <alxobr@xxxxxxxxx> wrote: > Hi all, > > I am currently porting Qt3 code to Qt4, and I don't want to use any > compatibility trick. > Everything went OK (well I've already done some such porting), till I > stumbled on a place where QButtonGroup's are used in a sequencer tracks > display (QGridLayout). > > In Qt3, every set of buttons (e.g. the colon of 'mute' checkboxes) had > their own QButtonGroup. I had full control on the id of every button in > the set and so it was easy to let the user add / remove tracks wherever > he wants. Also I could easily connect each of these QButtonGroup to a > slot of the parent widget using a single: > connect(bg_muted, SIGNAL(clicked(int)), this, SLOT(flipMuted(int))); > > Now in Qt4, I have no control on the button's id. I can't anymore > insert a button with the id of my choice. I dare not use the position > in "QList<QAbstractButton *> buttons ()" because its management is > not documented. > > Clearly the ids are not considered useful any more: even the > QButtonGroup signal: > void QButtonGroup::clicked ( int id ) > has changed to: > void QButtonGroup::buttonClicked ( QAbstractButton * button ) > > My problem is that I need to know which row a button belongs to, in > order to act upon the proper track. > > While identifiers inside QButtonGroup were quite convenient for that > use, I currently only see very convoluted solutions. > > Any idea welcome, > > > AO > > ######################################################################## > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > >
Tom Panning écrivit: > I'm not sure I completely understand your problem, but is a > QSignalMapper what you're looking for? It would take a > buttonClicked(QAbstractButton*) as an input and emit a signal with the > ID that you assigned to that button. This looks good. I never used a QSignalMapper and did not even know it existed! I just quickly read through the doc and it seems to be an elegant solution. The example given answers much of my problem. Still I need to call "void QSignalMapper::setMapping ( QObject * sender, int id )" on the fly, not only in the container's constructor. This is because e.g. when the user inserts a new track between track2 and track3, then track3 will become track4, and subsequently I want its widgets to signal track4. I guess this is possible if I take care not to have 2 buttons mapping to the same ID at any moment. So I will just drop the QButtonGroups. Thank you very much, AO > > Tom > > On Mon, Mar 24, 2008 at 8:37 AM, Alexandre Oberlin <alxobr@xxxxxxxxx > <mailto:alxobr@xxxxxxxxx>> wrote: > > Hi all, > > I am currently porting Qt3 code to Qt4, and I don't want to use any > compatibility trick. > Everything went OK (well I've already done some such porting), till I > stumbled on a place where QButtonGroup's are used in a sequencer tracks > display (QGridLayout). > > In Qt3, every set of buttons (e.g. the colon of 'mute' checkboxes) had > their own QButtonGroup. I had full control on the id of every button in > the set and so it was easy to let the user add / remove tracks wherever > he wants. Also I could easily connect each of these QButtonGroup to a > slot of the parent widget using a single: > connect(bg_muted, SIGNAL(clicked(int)), this, SLOT(flipMuted(int))); > > Now in Qt4, I have no control on the button's id. I can't anymore > insert a button with the id of my choice. I dare not use the position > in "QList<QAbstractButton *> buttons ()" because its management is > not documented. > > Clearly the ids are not considered useful any more: even the > QButtonGroup signal: > void QButtonGroup::clicked ( int id ) > has changed to: > void QButtonGroup::buttonClicked ( QAbstractButton * button ) > > My problem is that I need to know which row a button belongs to, in > order to act upon the proper track. > > While identifiers inside QButtonGroup were quite convenient for that > use, I currently only see very convoluted solutions. > > Any idea welcome, > > > AO > > ######################################################################## > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx > <mailto:qt-interest-request@xxxxxxxxxxxxx> with "unsubscribe" in the > subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > > -- [ signature omitted ]
On Monday 24 March 2008, Alexandre Oberlin wrote: > Now in Qt4, I have no control on the button's id. I can't anymore > insert a button with the id of my choice. Heh? Up to now I thought that's what void QButtonGroup::addButton(QAbstractButton *button, int id) was supposed to do. > Clearly the ids are not considered useful any more: even the > QButtonGroup signal: > void QButtonGroup::clicked ( int id ) > has changed to: > void QButtonGroup::buttonClicked ( QAbstractButton * button ) There's also a signal void QButtonGroup::buttonClicked(int id) Regards, Bernd -- [ signature omitted ]
Bernd Brandstetter écrivit: > On Monday 24 March 2008, Alexandre Oberlin wrote: >> Now in Qt4, I have no control on the button's id. I can't anymore >> insert a button with the id of my choice. > > Heh? Up to now I thought that's what > void QButtonGroup::addButton(QAbstractButton *button, int id) > was supposed to do. I don't have it mentioned in my 4.0.1 doc. > There's also a signal > void QButtonGroup::buttonClicked(int id) I don't have it in my 4.0.1 doc either. If the issue has been resolved in releases subsequent to 4.0.1, I still want to be sure that a user with 4.0 can compile and run my program. Thank you for you interest, AO -- [ signature omitted ]
On 24.03.08 21:11:14, Alexandre Oberlin wrote: > Bernd Brandstetter écrivit: >> On Monday 24 March 2008, Alexandre Oberlin wrote: >>> Now in Qt4, I have no control on the button's id. I can't anymore >>> insert a button with the id of my choice. >> >> Heh? Up to now I thought that's what >> void QButtonGroup::addButton(QAbstractButton *button, int id) >> was supposed to do. > I don't have it mentioned in my 4.0.1 doc. Yeah, seems there's a doc bug as the "since 4.x" is missing there. >> There's also a signal >> void QButtonGroup::buttonClicked(int id) > I don't have it in my 4.0.1 doc either. > > If the issue has been resolved in releases subsequent to 4.0.1, I still want to be sure that a user with 4.0 can compile and run my program. Wow, I hope you're aware that you're limiting yourself quite a lot with that restriction and IMHO for no good reason, I doubt there are that many people out there that use 4.0.x as those releases had quite a lot of bugs in them. Andreas -- [ signature omitted ]
On mandag den 24. Marts 2008, Andreas Pakulat wrote: > On 24.03.08 21:11:14, Alexandre Oberlin wrote: > > Bernd Brandstetter écrivit: > >> On Monday 24 March 2008, Alexandre Oberlin wrote: > >>> Now in Qt4, I have no control on the button's id. I can't anymore > >>> insert a button with the id of my choice. > >> > >> Heh? Up to now I thought that's what > >> void QButtonGroup::addButton(QAbstractButton *button, int id) > >> was supposed to do. > > > > I don't have it mentioned in my 4.0.1 doc. > > Yeah, seems there's a doc bug as the "since 4.x" is missing there. > > >> There's also a signal > >> void QButtonGroup::buttonClicked(int id) > > > > I don't have it in my 4.0.1 doc either. > > > > If the issue has been resolved in releases subsequent to 4.0.1, I still > > want to be sure that a user with 4.0 can compile and run my program. > > Wow, I hope you're aware that you're limiting yourself quite a lot with > that restriction and IMHO for no good reason, I doubt there are that > many people out there that use 4.0.x as those releases had quite a lot > of bugs in them. I would even escalate this a bit: Qt 4.0.x was not production quality, and you should not use it at all. I would even avoid 4.1.x if possible. Bo. -- [ signature omitted ]
Bo Thorsen wrote: >I would even escalate this a bit: Qt 4.0.x was not production quality, > and you should not use it at all. I would even avoid 4.1.x if possible. LSB 3.1 includes Qt 4.1.x. LSB 3.2 includes Qt 4.2.x Any distribution shipping KDE 4.0 has Qt 4.3.x On top of that, Qt 4.0.x and 4.1.x have reched end-of-life cycle. Targetting any of those two is just... a waste of time. Your time. There are many bugs that have been fixed on those and you'd have to work around them yourself. Workarounds that may break when used against the correct code. in newer versions. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira écrivit: >> I would even escalate this a bit: Qt 4.0.x was not production quality, >> and you should not use it at all. I would even avoid 4.1.x if possible. Not every user knows this. > LSB 3.1 includes Qt 4.1.x. > LSB 3.2 includes Qt 4.2.x Does this means Qt 4.0.x is not "LINUX Standard Base" ? > Any distribution shipping KDE 4.0 has Qt 4.3.x > On top of that, Qt 4.0.x and 4.1.x have reched end-of-life cycle. > Targetting any of those two is just... a waste of time. Your time. There > are many bugs that have been fixed on those and you'd have to work around > them yourself. > > Workarounds that may break when used against the correct code. in newer > versions. I'm not going to use undocumented workarounds. Thanks for your advice, AO -- [ signature omitted ]
Alexandre Oberlin wrote: >> LSB 3.1 includes Qt 4.1.x. >> LSB 3.2 includes Qt 4.2.x > >Does this means Qt 4.0.x is not "LINUX Standard Base" ? All Qt 4.x applications run on Qt 4.y where y >= x. So a Qt 4.0 application will run on any Linux distribution conforming to LSB 3.1 (with the Qt4 optional package) or 3.2. The question is the other way around: why use Qt 4.0 if the minimum requirement is 4.1? >> Any distribution shipping KDE 4.0 has Qt 4.3.x >> >> On top of that, Qt 4.0.x and 4.1.x have reched end-of-life cycle. >> Targetting any of those two is just... a waste of time. Your time. >> There are many bugs that have been fixed on those and you'd have to >> work around them yourself. >> >> Workarounds that may break when used against the correct code. in >> newer versions. > >I'm not going to use undocumented workarounds. Great, because there are no documented workarounds. Your only solution is to upgrade. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira écrivit: > All Qt 4.x applications run on Qt 4.y where y >= x. So a Qt 4.0 > application will run on any Linux distribution conforming to LSB 3.1 > (with the Qt4 optional package) or 3.2. Nice. Thanks for the info. > The question is the other way around: why use Qt 4.0 if the minimum > requirement is 4.1? Not all users are aware of this. Some have old PCs with old distros or home made configs on them. >>> Workarounds that may break when used against the correct code. in >>> newer versions. >> I'm not going to use undocumented workarounds. > > Great, because there are no documented workarounds. > It all depends on the meaning we take for the words. Personally I would be tempted to say that I was given here lately a *documented* workaround to avoid using "void QButtonGroup::addButton(QAbstractButton *button, int id) " > Your only solution is to upgrade. Something great with Qt (at least on Linux) is that you can keep the previous release and switch to it as necessary without a single problem. I hope you stick to this policy in the future. To continue the story, my app now compiles on Qt 4.0.1, but I have strange exits 0X377, possibly related to QList's. Shall I give up 4.0.1 ? ;-) Your advice was very much appreciated, thanks a lot. AO -- [ signature omitted ]
Alexandre Oberlin wrote: >> The question is the other way around: why use Qt 4.0 if the minimum >> requirement is 4.1? > >Not all users are aware of this. Some have old PCs with old distros or > home made configs on them. I suggest you try to find out which distributions have Qt 4.0 in them. You won't find many. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira écrivit: > Alexandre Oberlin wrote: >>> The question is the other way around: why use Qt 4.0 if the minimum >>> requirement is 4.1? >> Not all users are aware of this. Some have old PCs with old distros or >> home made configs on them. > > I suggest you try to find out which distributions have Qt 4.0 in them. You > won't find many. Sorry, no time for that ;-) Am I so original to upgrade components individually and only when I have no way out ? Now I am so far off my original Fedora distro that I must compile almost everything. The single idea of upgrading the whole distro makes me terribly nervous. AO -- [ signature omitted ]
Alexandre Oberlin wrote: >Thiago Macieira écrivit: >> Alexandre Oberlin wrote: >>>> The question is the other way around: why use Qt 4.0 if the minimum >>>> requirement is 4.1? >>> >>> Not all users are aware of this. Some have old PCs with old distros >>> or home made configs on them. >> >> I suggest you try to find out which distributions have Qt 4.0 in them. >> You won't find many. > >Sorry, no time for that ;-) >Am I so original to upgrade components individually and only when I > have no way out ? Yes. Most people follow standard upgrades for their distribution. And then they upgrade wholesale to a newer version every now and then. When dealing with servers, those may remain unchanged except for critical updates for years. On those, I can tell you this: you will not find Qt 4.0. At the very least, you'll find 4.1, which was the first one added to LSB 3.1. > Now I am so far off my original Fedora distro that I > must compile almost everything. The single idea of upgrading the whole > distro makes me terribly nervous. You should have been doing gradual updates like everyone else... -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Andreas Pakulat écrivait: > On 24.03.08 21:11:14, Alexandre Oberlin wrote: >> Bernd Brandstetter écrivit: >>> On Monday 24 March 2008, Alexandre Oberlin wrote: >>>> Now in Qt4, I have no control on the button's id. I can't anymore >>>> insert a button with the id of my choice. >>> Heh? Up to now I thought that's what >>> void QButtonGroup::addButton(QAbstractButton *button, int id) >>> was supposed to do. >> I don't have it mentioned in my 4.0.1 doc. > > Yeah, seems there's a doc bug as the "since 4.x" is missing there. > What do you mean ? x>0 ? The function is not only missing in the doc. Compilation under 4.0.1: playdialog.cpp: In member function `void PlayDialog::buildScoring()': playdialog.cpp:439: error: no matching function for call to `QButtonGroup:: addButton(QCheckBox*&, int&)' /usr/local/Qt-4.0.1/include/QtGui/qbuttongroup.h:49: error: candidates are: void QButtonGroup::addButton(QAbstractButton*) > Wow, I hope you're aware that you're limiting yourself quite a lot with > that restriction and IMHO for no good reason, I doubt there are that > many people out there that use 4.0.x as those releases had quite a lot > of bugs in them. Well actually the porting is going on quite well. My prog compiles and runs on qt3, so I don't like the idea of it not working for early qt4 versions. Thanks for your interest, AO -- [ signature omitted ]