Hi all,

Attachment contains:

+ TCalendar implemented
+ Reimplemented TCustomCheckGroup and TCustomRadioGroup
* Fixed problem with "Hidden radio button"
+ Added more events to QAbstractButton

cheers,
zeljko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qtupdate-r11352.patch
Type: text/x-diff
Size: 30363 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/qt/attachments/20070621/6ddb70bd/attachment.bin>

Hi,

Did you update your sources recently? applying the patch showed some conflicts

Also, I don't like comments with questions (no-one will answer them in the code, they should be instead discussed on the mailling lists)

+ {we have a bug in LCL when parent is TCustomCheckGroup, it doesn't set sizes for items ?!? Width = 0 , Height = 0}

IMHO comments should be simple, stick to the point of why the code was put there and inpersonal (so no need for signatures, svn will reveal who wrote it if that matters).

And the HiddenButton issue seams to become an ugly hack on our widgetset code .... maybe a solution in LCL should be made instead

Also, please note that we are now going to support Qt 4.2 too

So, when adding qt4 unit to new units see what I did on the other units to add selectively qt4 or qt42 units

Further, there are some ifdefs for the mdi things. Is this unstable or something like that? IMHO if they don't cause bugs we can just remove the ifdefs and change to IFNDEF USE_QT_4_2

Also, please add IFDEFs around functions not available on Qt 4.2

thanks,

Ah, by the way, I just decided to inverse the ifdefs

The default will be support for Qt 4.2 so we get maximum compatibility as the default state

And a USE_QT_4_3 will be available to select 4.3 support

If someone wishes to suggest a new name for the ifdefs now is a good time =)

Felipe Monteiro de Carvalho wrote

Hi, Did you update your sources recently? applying the patch showed some conflicts

not on my site. What are rejected files - code ?
my patch:

At revision 11353.
[linda at houston lazarus]$ patch --dry-run -p0 < qtupdate-r11352.patch patching file lcl/interfaces/qt/qtobjects.pas
patching file lcl/interfaces/qt/qtwidgets.pas
patching file lcl/interfaces/qt/qtwsstdctrls.pp
patching file lcl/interfaces/qt/qtwsextctrls.pp
patching file lcl/interfaces/qt/qtwscalendar.pp
patching file lcl/interfaces/qt/qtint.pp

my real patch:
[linda at houston lazarus]$ patch -p0 < qtupdate-r11352.patch patching file lcl/interfaces/qt/qtobjects.pas
patching file lcl/interfaces/qt/qtwidgets.pas
patching file lcl/interfaces/qt/qtwsstdctrls.pp
patching file lcl/interfaces/qt/qtwsextctrls.pp
patching file lcl/interfaces/qt/qtwscalendar.pp
patching file lcl/interfaces/qt/qtint.pp

Also, I don't like comments with questions (no-one will answer them in the code, they should be instead discussed on the mailling lists)

I don't like many things, but have to live with it ;)

+ {we have a bug in LCL when parent is TCustomCheckGroup, it doesn't set sizes for items ?!? Width = 0 , Height = 0}

question is there until resolved , if you don't like just delete it.

IMHO comments should be simple, stick to the point of why the code was put there and inpersonal (so no need for signatures, svn will reveal who wrote it if that matters).

no it doesn't matter ...

And the HiddenButton issue seams to become an ugly hack on our widgetset code .... maybe a solution in LCL should be made instead

nope, if there's no radio button named "HiddenRadioButton" (inside TRadioGroup only) nothing happens, as soon as somebody fix LCL (think someone said that's because of gtk), workaround will be removed.

Also, please note that we are now going to support Qt 4.2 too

I saw that

So, when adding qt4 unit to new units see what I did on the other units to add selectively qt4 or qt42 units

yep, I've already sent patch when I saw that there's missing Qt42 ifdef in QtWSCalendar.

Further, there are some ifdefs for the mdi things. Is this unstable or something like that? IMHO if they don't cause bugs we can just remove the ifdefs and change to IFNDEF USE_QT_4_2

MDI is far away from unstable, I'm using it almost every day, it's not yet finished but it doesn't make any bugs.I don't like too much ifdef's too but if U remove {$ifdef mdidevel} mainform will be always created with QWorkspace inside (we cannot change formstyle to mdiform yet - LCL problem not widgetset), my opinion would be: let it be {$IFDEF MDIDEVEL} for some time until better solution comes to our minds.

Also, please add IFDEFs around functions not available on Qt 4.2

Which functions are not available under Qt42 except MDI things ? I don't have Qt42 anymore so no chance to test against it.

zeljko

Felipe Monteiro de Carvalho wrote

Ah, by the way, I just decided to inverse the ifdefs The default will be support for Qt 4.2 so we get maximum compatibility as the default state

compatibility with what ? or what ? I know that Qt4 is not production lib in mainstream distros, but definitely when KDE 4.0 comes into , there will be Qt 4.3 , not 4.2 one.

zeljko wrote

compatibility with what ? or what ? I know that Qt4 is not production lib in mainstream distros, but definitely when KDE 4.0 comes into , there will be Qt 4.3 , not 4.2 one.

My almost 1 year old Mandriva has Qt 4.2 installed by default, but no distributions currently come with 4.3, so we get about 1 year more of distributions support by using 4.2

zeljko wrote

Which functions are not available under Qt42 except MDI things ? I don't have Qt42 anymore so no chance to test against it.

http://doc.trolltech.com/4.3/qt4-3-intro.html

There should be a change-log file too, but it seams to be empty. Maybe they didn't add it to the website yet.

Also, when looking at docs, just changing the version number to 4.2 shows the 4.2 docs.

I am very found of binary compatibility, where you develop an application and it just runs on the greatest number of boxes possible without headaches =) And this is why I decided for this.

thanks,

Felipe Monteiro de Carvalho wrote

My almost 1 year old Mandriva has Qt 4.2 installed by default, but no distributions currently come with 4.3, so we get about 1 year more of distributions support by using 4.2

I'm still using Fedora 3, and maded qt-4.3 rpms without single problem (after Den decided to switch to Qt-4.3).

zeljko wrote

I'm still using Fedora 3, and maded qt-4.3 rpms without single problem (after Den decided to switch to Qt-4.3).

But then everyone using a lazarus-qt application would need to compile their own Qt.

zeljko wrote

not on my site. What are rejected files - code ?

You are right ... I had some uncommited local changes. Sorry.

AFAIK there are QWorkspace->QMdiArea changes, QMainWindow styles (not used in bindings), QtScript-ing ,and some new routines in QPainterPath & QWidget (which are not in qt bindings).

So , what's up with my latest patch. It will be applied or not ?

tnx.

just "everyone" which uses distros wich deployed qt-4.2 inside. What about everyone which have Fedora 3, Fedora 4, Suse 9.2 ? Yes, if they want to develop an application with lazarus-qt they need to compile their own qt-4.2 or qt-4.3 doesn't matter ... they have to do it.
why ? It works with Fedora 7 out of the box (FC7 have qt-4.3), next Mandriva will have Qt-4.3 as default.
I have nothing against {$ifdef USE_QT42} or {$ifdef USE_QT43}, just do whatever, it works for me anyway ;)

zeljko wrote

So , what's up with my latest patch. It will be applied or not ?

Yes, it will, with changes.

thanks, committed with changes.

Note1: I commited the hidden button workaround with a new IFDEF: QT_HIDDEN_BUTTON_WORKAROUND so it will be easy to find this when lcl is fixed

Note2: I removed the ifdefs for MDI and made ifdefs for QT 4.3 instead

Note3: Please work more on the identation. Lazarus follows the borland style identation.

Note4: Do you also get the items of a RadioGroupBox in the wrong positions?

I attached a screenshots with both USE_QT_4_3 and
QT_HIDDEN_BUTTON_WORKAROUND set

Also there are some strange colors. I am using Qt 4.3 on Mac. Setting to Qt 4.2 mode makes the strange colors go away, but doesn't fix the misalignment.

As far as I remember, the radio group should use a vertical box layout, so I have no idea why it the controls would loose the alignment

bye,

I've prepared new patch which fixes all kind of alignments, don't know anything about colors, it looks good here (Linux).