Zeljko,

http://lists.freepascal.org/lists/fpc-devel/2009-September/017544.html http://bugs.freepascal.org/view.php?id=14621

With respect to this I moved from {$mode delphi} to {$mode objfpc}{$H+} This allows me in fpc to have better type safe signal hooking or method overriding.

The point is to convert this
====================================================================================
var
  Method          : TMethod;
...
  NetworkAccessManagerHook:=
QNetworkAccessManager_hook_create(QNetworkAccessManager);
  QNetworkAccessManager_authenticationRequired_Event(Method):=Authenticate;
  QNetworkAccessManager_hook_hook_authenticationRequired(NetworkAccessManagerHook,Method);
====================================================================================
to this
====================================================================================
  NetworkAccessManagerHook:=
QNetworkAccessManager_hook_create(QNetworkAccessManager);
  QNetworkAccessManager_hook_hook_authenticationRequired(NetworkAccessManagerHook, at Authenticate);
====================================================================================

Release Candidate V1.72RC does this:
http://users.telenet.be/Jan.Van.hijfte/qtforfpc/qt4pas-V1.72RC_Qt4.5.2.tar.gz http://users.telenet.be/Jan.Van.hijfte/qtforfpc/demos-V1.72RC_Qt4.5.2.tar.gz

As I understand that LCL/Qt will need a lot of changes due to this, I therefore created an automatic converter to do this: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/patch_lcl_V1.72.py Usage:
cd /svn/lazarustrunk/lcl/interfaces/qt
./patch_lcl_V1.72.py
(and then copy over V1.72RC qt4.pas)

the program will convert most needed changes.
* remove declaration of variable method
* remove keyword var if not needed anymore
* remove assignment to variable method
* rewrite hook_hook_something or override_something call

The changed files are back-upped into *.bak

The programs checks that it is run in lcl/interfaces/qt, remove this check if you want to convert other code

Only one manual change is needed in LCL/Qt qtwidgets.pas (then lazarus
compiles):
====================================================================================
procedure TQtCustomControl.viewportDelete;
var
  NilMethod: TMethod;
begin
  if Assigned(FViewPortWidget) then
  begin
    FillChar(NilMethod, SizeOf(NilMethod), 0);
    QLCLAbstractScrollArea_override_viewportEvent(QLCLAbstractScrollAreaH(Widget),
NilMethod);
    FreeAndNil(FViewPortWidget);
  end;
end;
====================================================================================
into
====================================================================================
procedure TQtCustomControl.viewportDelete;
begin
  if Assigned(FViewPortWidget) then
  begin
    QLCLAbstractScrollArea_override_viewportEvent(QLCLAbstractScrollAreaH(Widget),
QLCLAbstractScrollArea_viewportEvent_Override(NilMethod));
    FreeAndNil(FViewPortWidget);
  end;
end;
====================================================================================

There was already a nullhook for that usage defined, I renamed it to nilmethod in V1.72RC

If you accept this new method of working for hooking, I will release V1.72 for all platforms.
(probably monday evening)

kind regards,

Den Jean

Den Jean wrote

If you accept this new method of working for hooking, I will release V1.72 for all platforms. (probably monday evening)

IF it's better than old hooking then I accept , but there are more problems (as I can see) with this code change.
1.Qt45 becomes default
2.No more Qt44 use ? Qt44 bindings (qt44.pas) does not use such hooking. No problem with me, but will anybody else arguing about it ?

Another question is : Can I use in $mode delphi
QClass_hook_hook_someEvent(FQClassHook, MySlot); ? or I MUST use mode $objfpc and
QClass_hook_hook_someEvent(FQClassHook, @MySlot); ?

What others think ?

zeljko wrote

2.No more Qt44 use ? Qt44 bindings (qt44.pas) does not use such hooking. No problem with me, but will anybody else arguing about it ?

If anyone asks, I could create a Qt 4.4 V1.72
(lots of work so please only ask if really necessary)

Qt 4.5 is much better than Qt 4.4.
Installing and using a Qt 4.5 (using LD_LIBRARY_PATH) on a Qt 4.4 based distribution should not be that
difficult for a professional programmer.

If I only need to create the sources and not
the binaries (no need to boot a Mac/Windows/64bit linux, install Qt 4.4, compile, copy binary .... )
it is much less work (linux 32 bit binary is not a problem, it is my usual habitat)

Both are possible. But in some rare case where the procedure variable gets mixed with a procedure call w/o parameters (default values for all parameters), mode delphi does not work. But using the intermediate method var ofcourse still works (other casting ofcourse)

the bug report shows a general example. Just removing the default value in the declaration of the hooked method is already enough to fix it. So not a big problem either.

does not work:
procedure TButton.Clicked(checked: Boolean = False);cdecl;
...
QAbstractButton_hook_hook_clicked(hook, Clicked);
works:
procedure TButton.Clicked(checked: Boolean);cdecl;
...
QAbstractButton_hook_hook_clicked(hook, Clicked);

kind regards,

Den Jean

I know that, but I'm afraid that there always will be somebody :) I would like to fix USE_QT_XX forever, and use such flag JUST for developers NOT for users.

SO, FOR EVERYBODY READING THIS LIST:

QT45 BECOMES DEFAULT, NO MORE QT43, QT44 support.

Anyone ? :)

zeljko

Ok, this one is interesting :)
But there's still one small thing I always forget to tell you. There is lclextensions package which is used by VirtualTrees, and I have problem with qt compilation under win32 because we have HDC type declared in qt4.pas.Is it possible to rename that HDC to QHDC or something else so there's no mismatch between HDC types ?

btw: I've recompiled 1.72RC and it looks ok under linux ... works ok...no problems, so I think it's time that you create 1.72, so I can commit it to svn (with Qt45 as default patches). Have you tested/tried 1.72RC under win & mac ?

zeljko

zeljko schreef:
Zeljan, can you wait committing changes in the lazarus SVN (especially in the binary branch until after I tagged 0.9.28? Otherwise I have to create a fixes branch for the binaries too, and I rather want to prevent that.

Vincent

np (I'm planning this in coord with Den .... (probably friday/saturday) )

I can count on this (your post at lazdevel) ?
" I propose to tag on Wednesday 23-9. If you disagree, please write an email before Wednesday 08:00 AM CET."
If anything changes , please post to lazdevel.

zeljko

Done ( plus all related types, added Q in front of them in pascal interface only, not in c/c++)

btw: I've recompiled 1.72RC and it looks ok under linux ... works ok...no problems, so I think it's time that you create 1.72, so I can commit it to svn (with Qt45 as default patches).

Done see:
http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html Also updated LCL/Webkit demo for V1.72.

Have you tested/tried 1.72RC under win & mac ?

Compiled library and one demo at least for release.

regards,

Den Jean

)

Will the changes be included to the final Lazarus 0.9.28b release?

Matthias

No.

Vincent

Matthias Klumpp wrote

Will the changes be included to the final Lazarus 0.9.28b release?

No, it's a "big" change, and qt45 becomes default. with 0.9.28 you can still use qt43,qt44 (-dUSE_QT_44) and qt45 (-dUSE_QT_45). After changes there will be no more USE_QT_XX defines, there will be one and only qt :)

zeljko

TNX (a big thanks :) )

zeljko

zeljko wrote

:)I would like to fix USE_QT_XX forever, and use such flag JUST for : developers NOT for users.

and Qt 4.6 is almost out. Prepare for USE_QT_46 :-)

Den Jean wrote

and Qt 4.6 is almost out. Prepare for USE_QT_46 :-)

Maybe it would be interresting to discuss our future policy for Qt version support. While it's a very good idea to go for Qt 4.5 and drop the previous ones to have a uniform license, I am in favor of stopping at Qt 4.5 for the years to come, because otherwise the Qt interface is useless in Linux. If the necessary Qt version isn't install will users need to build their own Qt to run LCL-Qt software? Is this really expected?

In my experience they won't do it and if LCL-Gtk2 also expected everyone to have Gtk 2.18 or whatever high version it would also be useless in Linux and I think that LCL-Qt could have a shot at being the standard in some years if LCL-Qt programs can run in a large part of the installed Linux base, which will *never* happen if we keep upgrading without stop.

So what do you think? Should we station Qt 4.5 or go upgrading with every new version?

I'm already using it on another machine but it's full of bugs :)

That was my intention. I hope that Qt 4.6 will not broke something like Qt 4.4 broken QFileDialog filters (changed function names).So you can use qt 4.6 (yes it works with bindings 1.70) installed on your system with current qt-4.5 bindings and no changes inside lclqt code.
I agree with you.

Den, there's one more small thing I've been talking about long time ago. Is it possible to get QMetaObject into bindings ? I don't remember exactly but I think that you said that it isn't possible.
We already have QObject_metaObject() and it returns QMetaObjectH. So it would be nice to have QMetaObject_className() etc.

zeljko

Felipe Monteiro de Carvalho wrote

On Wed, Sep 23, 2009 at 5:54 PM, Den Jean wrote: > and Qt 4.6 is almost out. Prepare for USE_QT_46 :-)

I just hinted that the USE_QT will remain necessary, see below

I think we need to support the current distributions and prepare for the next ones. So that when the next ones become available, lazarus/Qt can be installed.
Therefore, support Qt 4.5 and slowly prepare for Qt 4.6.

If you need an older distro (older than the current), you can install a newer Qt alongside the distro wide one and use LD_LIBRARY_PATH.

But it might be nice if the makefile could detect the qt version an define the correct USE_QT, so that
the users do not have to do anything.

eg.
current = Mandriva 2009.1 = Qt 4.5
old = Mandriva 2009.0 (released in 2008) = Qt 4.4
new = Mandriva 2010 (expected in Nov 2009) = Qt 4.5

This is comparable with Qt release dates:
Qt 4.0 June 28, 2005
Qt 4.1 December 19, 2005
Qt 4.2 October 4, 2006
Qt 4.3 May 30, 2007
Qt 4.4 May 6, 2008
Qt 4.5 March 3, 2009

Though the Trolls/Nokia generally do a good effort on not breaking compatibility, the problem with the fpc binding is that a Qt 4.6 binding contains symbols that are not resolved against a Qt 4.5 dll. Vice-versa a Qt 4.5 binding can usually be used with a Qt 4.6. (Qt 4.4/4.5 was a bad exception with the QFileDialog filter)

prepare for Qt4.6 so that Qt 4.5 can be used with a Qt4.6. See which classes will be deprecated/absent:
http://doc.trolltech.com/4.6-snapshot/obsoleteclasses.html

Since the Qt lib is versioned this should be very easy to implement.

Den Jean wrote

If you need an older distro (older than the current), you can install a newer Qt alongside the distro wide one and use LD_LIBRARY_PATH.

That isn't what I am talking about. I am not concerned about software developers using LCL-Qt to write software, but about the users of the end software developed with Lazarus and LCL-Qt.

And I also don't think it's a good idea, if we set a minimum Qt version we should stick to it regardless of which Qt version is installed in the developer machine. Why stablish a relation between the minimum requirements of the software and the developer computer? Is there a relation between the developer computer and the end user computer?

Of the few places I know using Linux most of them use old distributions, because there is simply no reason to waste time in continuous updates even if they are free. How would software developed with LCL-Qt run in these computers? Do you know any company updating their Linux computers every year like we are updating Qt versions?

current = Mandriva 2009.1 = Qt 4.5 old = Mandriva 2009.0 (released in 2008) = Qt 4.4 new = Mandriva 2010 (expected in Nov 2009) = Qt 4.5

How many people are using the latest Mandriva 2009 compared to all other older versions? I suspect a minority.

I don't have Linux data, but the W3school statistics for Windows may help a bit:

http://www.w3schools.com/browsers/browsers_os.asp

Windows XP was launched in 2001 but only had more then 50% of users in
2004. Windows Vista still has only 18% of users.

Will we be surporting Qt 4.5 in 2012? If not, I suspect we will never be targeting the majority of the installed Linux base.

Compare with the Gtk2 interface. I think it requires Gtk 2.8 (could be 2.6, don't remember), which is supported in Madriva 2006 and superior.

What is more important: Producing software which runs on more computers or using the latest Qt version?

Felipe Monteiro de Carvalho wrote

Windows XP was launched in 2001 but only had more then 50% of users in 2004. Windows Vista still has only 18% of users.

It is not a fair comparision since windows costs money :)

For newer versions if some functionality is needed we are using dynamic linking (look at gtkext package).

What is more important: Producing software which runs on more computers or using the latest Qt version?

I am agree with you that we should stay on qt 4.5. Although if there will be something nice to have from the versions > 4.5 we will need to redecide. Maybe also using dynamic linking.

Best regards,
Paul Ishenin.

Felipe Monteiro de Carvalho wrote

Of the few places I know using Linux most of them use old distributions, because there is simply no reason to waste time in

My machine is installed in 2004 (think fedora 3), and reading your text I can develop only with qt-3.3. There's no support for qt4 in fedora 3, but I've maded packages by myself :) It's linux , and that's the way how it works. If you want to develop on linux, then you must know something about it. What about users which have 2 yrs old distro with qt-4.1 inside ? Nothing. If they want to develop with lazarus they must upgrade qt, if they want to use some shiny new lclqt application - they must upgrade qt and bindings.

continuous updates even if they are free. How would software developed with LCL-Qt run in these computers? Do you know any company updating their Linux computers every year like we are updating Qt versions?

Minimum version will be 4.5 for next 2-5 yrs (definitelly) since it's stable enough and have all things we need for lclqt at the moment. 4.6 have some deprecated classes (as Den mentioned), but such classes are still inside Qt so bindings will not scream about it, and if someone have 4.6 installed and qt-4.5 bindings (eg. 1.72) it'll work. As I said before QT_USE_XXX will be (if) only for development purposes and nothing else.

We cannot take WinXP/Vista/7 into account since it costs some money.

Will we be surporting Qt 4.5 in 2012? If not, I suspect we will never be targeting the majority of the installed Linux base.

yes, time to stabilize qt interface has come, and I'm planning to remove beta status of qt for 0.9.30.
It was hard before qt-4.5 since there was many bugs and instability (especially in qt-4.3).

Compare with the Gtk2 interface. I think it requires Gtk 2.8 (could be 2.6, don't remember), which is supported in Madriva 2006 and superior.

Cannot compare gtk2 and qt.
1.Gtk2 is much longer in lazarus source that qt is. 2.Gtk2 is default for linux development, qt not.

What is more important: Producing software which runs on more computers or using the latest Qt version?

Producing software which runs on more computers :)

zeljko wrote

My machine is installed in 2004 (think fedora 3), and reading your text I can develop only with qt-3.3. There's no support for qt4 in fedora 3, but I've maded packages by myself :)

Yes, but I am worried about Linux users, not developers. People that don't work with software development and have no idea what the word "source code" means. How many of them would build a new Qt version just to use, let's say PeaZip made with Lazarus?

I am happy we agree =)