Hi,

Since Lazarus switched to using GTK2 by default under Linux, the GTK1 support and stability has been free falling. Maybe it's time to simply remove GTK1 support because it definitely is NOT a stable platform any more - unlike the "Configure Build Lazarus" dialog suggests, saying GTK1 is stable (like Win32) and GTK2 is beta.

This bug report suggests the same thing. GTK1 cannot even be compiled any more. :-/

http://bugs.freepascal.org/view.php?id=16414

It seems like this is caused by the latest Bidi patches. Should Bidi code be moved to Gtk2 sources only?

Imho, it's better to split Gtk1 and Gtk2 sources completely. IIRC, gtk2 widgetset is still using some gtk1 units.

thanks,
dmitry

On Thu, May 6, 2010 at 12:59 AM, dmitry boyarintsev <

It is reasonable to assume nobody is using GTK1 with Lazarus anymore since nobody complains about the bugs.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100506/e63b09ea/attachment.html>

2010/5/6 Razvan Adrian Bogdan :

It is reasonable to assume nobody is using GTK1 with Lazarus anymore since nobody complains about the bugs.

Then a clear-cut decision should be made to remove GTK1 - instead of giving the false illusion that it is one of two "stable" widgetsets. This might present a good opportunity for the GTK2 code to be cleaned up as well.

dmitry boyarintsev wrote

Imho, it's better to split Gtk1 and Gtk2 sources completely. IIRC, gtk2 widgetset is still using some gtk1 units.

If anybody gets into updating the GTK2 Widget Type sources, pleaaaaaaase do split the GUI related code from the event queue related code (e.g. in the forms* source file). Best move it into it's own not directly Widget Type dedicated directory (same of course needs to be different for Linux and for Windows, as with the Linux Widget Types the event queue is done in LCL code while with the Windows Widget Types it's provided by OS APIs, No idea about Mac....)

I suppose the stand alone event queue related code can be used both by the GTK(2) and by the QT Widget types (and maybe Mac). Moreover this would make creating a __functional__ (supporting TTimer and Thread communication) GUI-less Widget Type (e.g. for (fast) CGI Applications and embedded stuff much more straight-forward.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100506/4e9a895d/attachment.html>

What eventqueue related code are you talking about and which forms* files ?

Marc

It is planned, but not now.

Marc

Marc Weustink wrote

What eventqueue related code are you talking about and which forms* files ?

Maybe in fact the form* files need not to be targeted directly.

Here some locations in the code used by "gtk" that lead to code-sequences that I think could be cleaned up to separate the message queue code from the gui code.

gtkmsgque.pp 47:
TGtkMessageQueue=class(TLinkList)

defines the event queue object

gtkwinapi.inc 7402:
   function TGtkWidgetSet.PostMessage(Handle: HWND; Msg: Cardinal;
wParam: WParam;

here events are inserted into the queue

gtkwidgetset.inc 1204:
   procedure TGtkWidgetSet.AppProcessMessages;

here we wait for events and events are taken out of the queue

gtkwidgetset.inc 1224:
   gtk_main_iteration_do(False);

My suggestion includes that e.g.

- the "MessageQueue" class is defined independently of the Widget Type ("Interface") as a simple ubiquitously usable object.using inheritance/functions/properties/callbacks to interface whatever Widget type specific code uses it.

- AppProcessMessages is defined in a file independent of the Widget type and done way that is independent of the Widget type, interfacing the Widget type actually used by inheritance/functions/properties/callbacks

-Michael

BTW.: line numbers taken from svn version 25236
-Michael

Well, I *do* use gtk1 in my big comercial application suite. I stopped reporting gtk1 bugs because it was announced here on mailing list, that gtk1 bugs will be resolved/suspended unless they are reported with proper patch.
Since this announcement, I stopped updating lazarus, because I *need* gtk1 .. it is IMHO still the only stable/usable lcl-ws on linux.

best regards
Burkhard

Have you been reporting these stability bugs, so they may be fixed and you can one day switch to gtk2?

Henry

We are using qt for our big commercial application suite and have not stability problem. Maybe you should try that.

I'm still tending to use v1 because I've found Lazarus (and a number of other apps) to be extremely slow on v2 when run to a remote X server. This was specifically an X problem which didn't show up on VNC, I think it's now been fixed since when I checked a couple of days ago performance appeared to be adequate on the limited number of systems I tested.

Might I suggest that just as some widget sets are marked as "pre alpha" it might be appropriate to mark gtk v1 as "post omega" and move it to the bottom of the list rather than junking it completely? That way it could degrade gracefully but would still be visible to anybody who wanted it, and the onus would be on him to report or fix any removed or unimplemented functionality.

Mark Morgan Lloyd wrote

I'm still tending to use v1 because I've found Lazarus (and a number of other apps) to be extremely slow on v2 when run to a remote X server. This was specifically an X problem which didn't show up on VNC,

Last time (some months ago) when I tried to run Lazarus IDE via a remote X11 session, the IDE was totally unusable (extremely slow), yet other GTK2 applications ran fine. So I don't think it was a GTK2 issue, but rather a LCL-GTK2 issue.

bottom of the list rather than junking it completely? That way it could degrade gracefully but would still be visible to anybody who wanted it, and

I though it is already doing this? :)

Some Mozilla software behaved the same, specifically Debian's rebadged FireFox. I need to check more but I think it's fixed, which suggests that it was either something inherent in v2 or that there was some plausible-but-wrong way of using it which had caught out multiple projects.

I'm running Ubuntu 8.04.2 on both systems. I actually used Firefox, gnome-control-center and gEdit to test. They all worked perfectly except for Lazarus IDE or LCL based apps.

Does anybody know whether double-buffering affects this? Graeme, if you think it's worth testing the theory, I attached a simple patch to disable it globally for the sake of it.

Best regards,
Fl?vio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtk_disable_doublebuffer
Type: application/octet-stream
Size: 602 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100513/00126a25/attachment.obj>

2010/5/13 Fl?vio Etrusco :

Does anybody know whether double-buffering affects this? Graeme, if you think it's worth testing the theory, I attached a simple patch to disable it globally for the sake of it.

As I said in my previous email, I haven't tried running Lazarus remotely in months. I just tried now with the latest svn Lazarus compiled with GTK2. It now works fine and runs at normal speed like all other Gnome/GTK2 apps.

There are still some issues. Last year Paul made some improvements regarding mouse handling and from that moment I started to use lazarus-gtk2 for development. Resizing/dragging controls still takes ages, (but I seldom design forms for lazarus )

Marc

Some performance problems can be caused by mouse movement events getting queued up. Look at this:

http://bugs.freepascal.org/view.php?id=14936

Henry

:)

gdk_event_request_motions is a gtk 2.12 feature. I need to read up on this. IT also means that we need to think if we should bump the minimal gtk2 requirement.

When my todo list for the next release is gone I plan to look into gtk2 (+ graphics) again.

Marc

It was slightly buggy, as you can see by the comments, but there's been some more developments in the discussion on the gtk bugzilla. This patch increases performance in the designer on my slow computer by quite a lot (I don't even know if it still applies cleanly, though).

When my todo list for the next release is gone I plan to look into gtk2 (+ graphics) again.

Good to hear :)

Henry

Maybe it can check for the version?

Mattias

2.12 is already ancient, though, I'm on 2.20 (Debian testing). Either way, the gtk_event_request_motions bug isn't malicious, but it requires testing. Chances are that you won't hit it on a moderately fast computer.

Henry

When the time it there i'll decide.

Marc

Users expect to work on gtk2 2.8. Recently that was a bug report to support that version: http://bugs.freepascal.org/view.php?id=0015949

Luiz

Luiz Americo Pereira Camara wrote

Users expect to work on gtk2 2.8. Recently that was a bug report to support that version: http://bugs.freepascal.org/view.php?id=0015949

Fine. You obviously need to decide which versions you support.

I propose to release 0.9.30 supporting 2.8 as is today and than go to 2.12

Luiz

Luiz Americo Pereira Camara wrote

I propose to release 0.9.30 supporting 2.8 as is today and than go to 2.12

As I know our gtk2 widgetset already uses some 2.8 functions. So I see nothing bad to use other required. Although they are not availble in fpc packages.

Best regards,
Paul Ishenin.

+1

Another solution could be to make some sort of installable package from the GTK1 support. I have to admit that I don't know if that is technically possible.

A third option would be to have a special release of lazarus and fpc that can be used for compiling using lcl-gtk1 that is downloadable and installable seperately. This "GTK+ Edition" of lazarus/fpc could be used to keep up care and necessary bug fixing for those programs in the future.

Solution two and three would take more effort to be realized than only marking gtk1 as deprecated but still usable (on ones own risk ;).

I am still using gtk1 and will continue to do so for some applications that are running on older and thus slower hardware.

Hello,
In connection with GTK I would like to ask dev team two questions:
1. Can Lazarus work without ?GTK1, GTK2, Qt and other packages that are not written in Pascal? Require only the FPC. Where can I download?

2. Dev team will support in the future Lazarus without GTK1, GTK2, Qt, and others packages which are not written in Pascal? I am looking only version of Lazarus with FPC.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100514/01422e1d/attachment.html>

lazbuild and some packages in the lazarus sources only need FPC.

The IDE needs a graphic back end. The fpgui widgetset only needs X11/xorg, but is not yet capable of running the IDE.

You can download the sources in a zip file from the download page.

Mattias

In connection with GTK I would like to ask dev team two questions: 1. Can Lazarus work without ?GTK1, GTK2, Qt and other packages that are not written in Pascal? Require only the FPC. Where can I download?

I know somebody is currently working on the LCL-fpGUI widgetset. fpGUI is completely written in Object Pascal - so no large library dependencies are needed. But last time I checked, LCL-fpGUI was still very experimental and Lazarus itself couldn't be compiled with LCL-fpGUI yet.

Well, there do are some new developments in LCL-FPGui. See:

http://bugs.freepascal.org/view.php?id=16473

Thanks, I'll wait till a stable version.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100514/a0108230/attachment.html>

Felipe Monteiro de Carvalho wrote

Well, there do are some new developments in LCL-FPGui. See: http://bugs.freepascal.org/view.php?id=16473

Thanks Felipe. I knew Jos? was working on LCL-fpGUI, but I didn't know anything was committed yet. I'll give it a try soon.

Marc Weustink wrote

IT also means that we need to think if we should bump the minimal gtk2 requirement.

Oh please, pretty please, don't.
I have gtk2-2.8.3-4 on a 10 year old machine running Suse 10.0 and I prefer GTK2 above GTK1 nowadays.

Bart

Shall we all wait for you to catch up, then ;)

Henry

Bart wrote

Oh please, pretty please, don't. I have gtk2-2.8.3-4 on a 10 year old machine ?running Suse 10.0 and I prefer GTK2 above GTK1 nowadays.

I agree with Henry. Linux is free, simply upgrade - there is no good reason not to stay up-to-date. Or keep using the released 0.9.28.2 for your old machine and stay away from Trunk or later versions.

Henry Vermaak wrote

On 14 May 2010 13:28, Bart wrote: > On Thu, May 13, 2010 at 5:23 PM, Marc Weustink

This is one and probably the most important reason, I still prefer gtk1. It doesn't change anymore, so my apps work pretty fine on suse 9.0-11.2 (beside some minor issue (bug #14496) which I could get around with a dirty hack ..)
Switching to gtk2 means, either stick to an old lazarus version (with those many gtk2 bugs) or update linux on my dev machine + force my customers to also update their linux installations... sorry, no way.

regards
Burkhard

Ow there is still a good reason why I keep my 2 (real) linux machines at fc8 (i've VMs running upto the latest)

Marc

Marc Weustink wrote

Ow there is still a good reason why I keep my 2 (real) linux machines at fc8 (i've VMs running upto the latest)

:-) I do the reverse. My real system is up to date (mostly with LTS versions of Ubuntu) and VM's with older distros, exotic OSes or Windows.

Hi

Switching to gtk2 means, either stick to an old lazarus version (with those many gtk2 bugs) or update linux on my dev machine + force my customers to also update their linux installations... sorry, no way.

No, actually sticking with GTK1 means sticking with old Lazarus version. It may not be a bad idea. GTK1 will work forever as it works now if you never update anything, and if your customers never update anything.

At some point it will happen that you or one of your customers wants more advanced features and then you must update. If it takes few years then Lazarus will be much better and GTK2 is already replaced with something better, so you can skip it. :-)

Regards,
Juha

Juha Manninen wrote

advanced features and then you must update. If it takes few years then Lazarus will be much better and GTK2 is already replaced with something better, so you can skip it. :-)

Hopefully Lazarus would have reached v1.0 by then. :-)

What I find strange though is that GTK2 is (I think), yet Lazarus developers (and users) are still talking about *not* bumping the lowest supported GTK2 from 2.6 (I think) to something newer.

2.6 -> 2.30 is a lifetime apart! Surely it's time Lazarus starts taking advantage of GTK2 features that have appear in the last 5+ years of GTK2 development? LCL-Qt was very quickly bumped from Qt v3 to Qt v4, so why not GTK2?

[um, maybe I should restrain myself from posting to the Lazarus mailing list again - I'm asking way to many questions. <wink>]

seems some kind of favouritism for low version numbers:
- keeping lazarus below 1.0
- keeping gtk way down

And I agree with you, there is a need to review (and *revert*) the QT decision

:) ;> :) ;> :) ;> :) ;>
SCNR

If Lazarus abandon support for GTK could lose many members. Be absolutely sure of that. I see to many people in Brazil who only use GTK in Lazaus and other softwares. (several people use GTK with PHP)

[um, maybe I should restrain myself from posting to the Lazarus mailing list again - I'm asking way to many questions. <wink>]

I agree with you. I always think about Qt more beautiful, but it is heavy to many PCs (this is a reality).

Graeme, excuse me, but, do not give up when something goes wrong. If this keeps up there will come a day that you may want to leave the land, because most people are imperfect (is not a criticism, it is a friendly advice). :/

Graeme Geldenhuys wrote

LCL-Qt was very quickly bumped from Qt v3 to Qt v4, so why not GTK2?

Qt v2, was the only available option for years in a state pre-alpha, unmaintained, much like fpgui (SCNR).

Qt v3 was never supported.

Because GTK 2.6 is already LGPL. The license is a compelling feature of Qt 4.5. I think you will see support for Qt 4.5 in Lazarus for the coming years.

Vincent

Martin wrote

And I agree with you, there is a need to review (and *revert*) the QT decision

Yes, and while they are at it, move back to FPC 0.xx too. We can't be having a v2.4 in the Lazarus project - that's way to high a number. ;-) Thank goodness fpGUI is still below v1.0 so it still works with Lazarus IDE. :)

silvioprog wrote

If Lazarus abandon support for GTK could lose many members.

You totally misread my post. I wasn't talking about abandoning GTK (v1 & v2), only GTK1 because it's often broken and nobody reports issues - probably because nobody really uses it any more. And as for LCL-GTK2, Lazarus really should try and keep up with the GTK2 development. GTK2 is and LCL-GTK2 still says we only support from GTK 2.4/2.6 yet all modern distros ship with GTK that same design idea was applied to LCL-QT, then LCL-QT would currently only support Qt v2 features.

I really don't seem to understand the Lazarus team's thinking. We will continue support GTK1 even though no modern Linux distro comes standard with GTK1 anymore. LCL-Qt is immediately bumped up to the latest Qt v4 version. But no, LCL-GTK2 is in some limbo land. Not stable, and not keeping current with the latest GTK2. Yet this is all ok to the Lazarus team. Maybe I'm just used to working in a development team that is a lot more organized and has a clear direction. Enough said on this topic already so I'll stop here.

Graeme, excuse me, but, do not give up when something goes wrong.

I don't, that's the point. If I see something wrong, I report it (I already reported 200+ bugs in Lazarus alone and supply patches where I can). The Lazarus team keeps saying that if something is not reported, they will not know it's broken. If it's not a code issue, I try and contribute by give alternative advice. Either way, this always seems to land me in hot water for some reason. There seems to be no win-win situation here.

Vincent Snijders wrote

... for years in a state pre-alpha, unmaintained, much like fpgui (SCNR).

Simply because LCL is a lot more buggy that fpGUI, and because LCL-fpGUI will limit the abilities in fpGUI. So I prefer to use the real thing and get all the features the toolkit offers, that means using fpGUI directly.

Because GTK 2.6 is already LGPL.

I don't understand your comment. The latest GTK 2.30 is also LGPL. Most distro also ship with GTK 2.16+ versions, so why hold LCL-GTK2 back with GTK 2.6 version as minimum.

"GTK+ is licensed under the GNU LGPL 2.1 allowing development of both free and proprietary software with GTK+ without any license fees or royalties."
-- quoted from http://www.gtk.org the first paragraph on the home page.

The license is a compelling feature of Qt 4.5. ?I think you will see support for Qt 4.5 in Lazarus for the coming years.

OK, Qt was a licensing issue - I understand that now. Thanks for pointing that out. Still doesn't explain why LCL-GTK2 doesn't jump to supporting a lot new version of GTK2 as minimum.

We rather not support version that are not LGPL, like Qt 4.4. And no, it is not holding back, but making sure it still works. 2.18 or 2.20 works but 2.6 too, or rather 2.8, because that is the currently oldest supported version, afaik, (but IANAGD= I am not a gtk2 developer).

Vincent

The reason Qt jumped, was the license, and that is the reason it won't jump in the future, like gtk and winapi doesn't.

Vincent

And don't forget: FPC still uses only i386 instructions in the default setup while using Pentium4+ stuff would allow often much better code. All modern CPUs support it for years ;)

Vincent Snijders wrote

not holding back, but making sure it still works. 2.18 or 2.20 works but 2.6 too, or rather 2.8, because that is the currently oldest supported version,

OK, so you guys are only 12 versions behind. :-)

PS:
I see I kept typing GTK 2.30 when I meant GTK 2.20 being the latest version.

No, we our software supports a wide range of versions: all release between 2.8 and 2.20.

Vincent

Florian Klaempfl wrote

> is and LCL-GTK2 still says we only support from GTK > 2.4/2.6 yet all modern distros ship with GTK 2.16+ at least. Debian Lenny is afaik.

I did say "modern distros" didn't I? :-)

And don't forget: FPC still uses only i386 instructions in the default setup while using Pentium4+ stuff would allow often much better code.

Point taken. Maybe this could be changed for FPC too - seeing that the resulting executables will have for much better code (as you said)?

Slackware, SuSE etc all ship i686 executables as standard - they don't seem to cause any problems. God help the person still running a 486 or P2/P3 system - even my PDA and mobile phone has more processing power than that!

And what features exactly misses the LCL by taking care of 2.8?

Florian Klaempfl wrote

And what features exactly misses the LCL by taking care of 2.8?

Read the GTK+ changelogs: htpp://www.gtk.org.
Bug fixes, new features etc...there are just too many to list here.

And? When running on a GTK2 2.20 system the LCL benefits from a lot of these changes as well. Only new API functions cannot be used or only with a version check.

there are just too many to list here.

I doubt that there are a lot which are really needed.

Debian Lenny is the latest stable Debian release and probably used by a lot of people. I know also a lot of ubuntu machines running 6.06 simply because upgrading is too expensive.

http://ik.homelinux.org/

On lenny GTK 2.12 is used afaik. I do not know about Ubuntu 6.06, I stopped using it a long time a go and moved to Arch Linux :)

Ido
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100515/e2e549c2/attachment.html>

BTW, I still know people that are using Win98 and WinNT 3.54, however we can not stay freeze because of such choices imho.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100515/60fdd1f1/attachment.html>

It would be good to provide a second gtk2 binding which supports dynamic linking for newer functions. Then the lcl gtk2 interface could use newer functions.

2.6 -> 2.30 is a lifetime apart! Surely it's time Lazarus starts taking advantage of GTK2 features that have appear in the last 5+ years of GTK2 development? LCL-Qt was very quickly bumped from Qt v3 to Qt v4, so why not GTK2?

Speaking for myself: I got problems running qt-lcl on all computers. LCL should at least run on two year old systems. Better some more years.

[um, maybe I should restrain myself from posting to the Lazarus mailing list again - I'm asking way to many questions. <wink>]

Mattias

Florian Klaempfl wrote

And what features exactly misses the LCL by taking care of 2.8?

As far as I remember there is a good amount of features of 2.8 compared with 2.6 which are useful, you can see the ifdefs in LCL-Gtk2

And recently developers found some routines which require 2.12 that are needed to improve using LCL-Gtk2 in a remote X server.

Usually each new Gtk version has a couple of new routines which are useful.

If I was the gtk2 maintainer, I would increase the minimum to 2.12, which is reasonable, but of course there are other solutions like checking the version dinamicaly or make the ifdefs default to 2.12 but allow others to define GTK_2_6 if they use an older Gtk.

Ok, imagine company which uses lazarus for commercial apps (like mine and yours) and that apps relies on gtk2.
1.We bump to 2.20 , so some new functions comes in, structures changed etc... 2.You compile your app with such 2.20 and wire update to customer. 3.Customer uses Fedora 4 which is based on 2.12
What will happen in this case ?
a) Your application won't work
b) It'll work out of the box

if a), you have to: update customer OS (or gtk2 if you can, but I doubt about it in case of Fedora 4 as example).

In one word - you get mess and we get gazillion of complains on mailing list.

IMO, 2.6 is too low maybe, but maybe gtk2 should be updated to max 2.10, or release 0.9.28.3 with all regressions and bugs fixed in 0.9.28.2 and note that's last version which supports 2.6 and bump laz 1.0 to at least 2.12.

zeljko

Mattias Gaertner wrote

Speaking for myself: I got problems running qt-lcl on all computers.

What exact problems ?

zeljko

zeljko wrote

Ok, imagine company which uses lazarus for commercial apps (like mine and yours) and that apps relies on gtk2. 1.We bump to 2.20 , so some new functions comes in, structures changed etc...

I don't mean that LCL-GTK2 should be bumped immediately to GTK 2.20 - that version of GTK+ is too new (only release a month ago). But something like Felipe mentioned 2.12 will already be a good start, and that allows for some code clean-up (which what I heard from other developers here is really needed in LCL-GTKx backend). Mattias suggestion of a totally new implementation of LCL-GTK2 is maybe even a better idea - use what was learned from the last 10 years and design a better maintainable LCL-GTK2.

What will happen in this case ? a) Your application won't work b) It'll work out of the box

I don't have this problem. fpGUI runs on distros as old as 10 years (from my last tests) without limiting any fpGUI features. :-)

IMO, 2.6 is too low maybe, but maybe gtk2 should be updated to max 2.10, or release 0.9.28.3 with all regressions and bugs fixed in 0.9.28.2 and note

I think Felipe had a very good idea. Bump LCL-GTK2 to 2.12 and make that the default minimum in code. Then have IFDEF's for developers that need to support older versions - they need to explicitly tell LCL at compile time that they want to support an older version of GTK+.

I didn't had the right qt version.
It was not a problem of the quality of the qt interface and I know there were good reasons to increase the minimum version of the qt intf so rapidly. I hope, that this process stopped and in two years the qt intf still can run on qt 4.5 systems.

Mattias

qt intf minimum requirement will be 4.5 at least under 1.1 LazDevel version (if we release 1.0 in next 1-3 yrs).
Next 4.7 is fully binary compatibile and (tested beta) works ok. IMHO 4.8 could be last in 4.XX series which can come in Q3/Q4 of 2011, so 5.0 (possible binary incompatibile) can be probably released in 2012-2013 and will be stable/useable in 2014 probably.

zeljko

Ah, you just want to make your fpGUI more advantageous by crippling the deployability of the LCL gtk2. For a moment I really thought you at least wanted to help LCL with your good ideas ...

Vincent

The trouble is that many stable and enterprise distributions are simply old. These versions are still being deployed.

Vincent Snijders wrote

Ah, you just want to make your fpGUI more advantageous by crippling the deployability of the LCL gtk2. For a moment I really thought you at least wanted to help LCL with your good ideas ...

No, fpGUI simply doesn't have the limitations of LCL because everything is implemented by fpGUI itself - no large framework dependencies. Easy deployment was one of the main reasons fpGUI was started. If you want a missing feature in fpGUI, implement it. Now compile that version of fpGUI on a 8-10 year old distro or simply run the latest executable on a old distro, and you still have that new feature available. No external framework dependencies means lesser limitations!

And yes, I would like to see LCL improve in stability - more so than new LCL features. Why? Because better stability will directly improve the stability of the IDE. Not to forget that competition is healthy for software growth and I have no intention in crippling LCL in any ways - direct or indirect.

Some parts of LCL is simply a mess - hence the many, many bugs reports and regression bugs. Simple proof. To help LCL improve in stability, it needs to rely on the stability of the underlying frameworks it depends on (just one part of a big problem). That means newer versions of GTK2 or Qt. And for LCL to grow in features (though again limited due to what is available on all other libraries LCL depends on), it again needs to use the newer versions of the frameworks.

It's a rather simple concept - and no hidden agenda or malicious intend implied.

Marco van de Voort wrote

The trouble is that many stable and enterprise distributions are simply old. These versions are still being deployed.

We standardized on Ubuntu LTS releases. This greatly reduces the problem you mention. Alternative, you can switch to something like RedHat. Both are distros that are actively being developed and kept up to date, yet have stable (long term support) release.

First some facts:
I've checked some popular distros about supported gtk+ version. Moving to 2.12 means supporting
Debian: back to 5.0 Lenny released 2009/02/15 - 15 months ago (see http://distrowatch.com/table.php?distribution=debian) Ubuntu: back to 7.10 Gutsy released 2007/10/18 - 31 months ago (see ...=ubuntu)
Fedora: back to 8 (werewolf) released 2007/11/08 - 30 months ago (see ...=fedora)
openSUSE: back to 10.3 released 2007/10/04 - 31 months ago (see ...=suse) Mandriva: back to 2008 released 2007/10/09 - 31 months ago (see ...=mandriva)

While the current state (supporting 2.6) means supporting Debian: 2005/06/06
Ubuntu: 2005/04/08
Fedora: 2005/06/13
openSUSE: 2005/04/15
Mandriva: 2005/04/14

To summarize, now Lazarus supports systems being up to 5 years old, while changing to 2.12 would mean supporting < 2.5 years old systems, except for debian, which in fact is a widely used distro (AFAIK) but it's 2007 release only supports gtk+ 2.8.20.
So much for the facts.

For my opinion, I think such decision requires sufficient knowledge regarding the users of lazarus, how many users do we have running different systems, and what are their opinion or requests.
I know in open source users are also developers and that this list is also open for users (as in fact I am also a user and not developer) but are there any information available based on which we could make such decision? If not shouldn't we gather it? (by making a platform for it, for example having a "start page" showing up first time you run lazarus with links urging users to share their thoughts and information (register) (and other useful links) like many other IDE has, or creating polls or anything (just ideas).

Sorry if I said something irrelevant or stupid, I'm relatively new to this list. Just trying to share my ideas.

cheers
Kriszti?n

2010/5/15 Marco van de Voort

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100515/3d4963fa/attachment.html>

Wow. Nice list.

Yes, this is welcome.

Let's summarize:
Some features require a higher gtk version. Solutions: a) do not use the new feature
b) enclose the new feature in IFDEFs and enable it by default c) enclose the new feature in IFDEFs and disable it by default d) use feature without IFDEF
e) use dynamic linking and check for the version. Maybe add an IFDEF to support static linking.

Obviously a is not wanted.
Apparently b, c and d does not work for all. The decision between b, c and d depends on your gathered facts.
And there is e.

First look at the feature, check if e is not possible, then we can discuss b,c,d.

Mattias

Mattias Gaertner wrote

e) use dynamic linking and check for the version. Maybe add an IFDEF to support static linking.

I used e) few times for our gtk2 interface.

Best regards,
Paul Ishenin.

While the current state (supporting 2.6) means supporting Debian: 2005/06/06 Ubuntu: 2005/04/08

The oldest Ubuntu (Desktop) that is still supported is Ubuntu 8.04 LTS with a release date of April 24 2008. By the way the server edition does not count as it's X less.

See https://wiki.ubuntu.com/Releases

I meant "support" as: Lazarus supporting that distro, only based on gtk+ version shipped with the specific release.
Ubuntu 5.04 comes with gtk+ 2.6.4 thus is supported by lazarus which requires gtk+ 2.6 (not counting any other possible limitations), while Ubuntu 4.10 only has gtk+ 2.4.9.
This has nothing to do with the official support of the release. That's what I meant, sorry if it was not clear.

2010/5/15 Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100515/d2864f29/attachment.html>

I meant "support" as: Lazarus supporting that distro, only based on gtk+ version shipped with the specific release.

Yes I had worked that out but it's a bit pointless supporting a version of a Linux distribution that the maker of that Linux distribution no longer supports.

Does anyone use a Linux distribution that is no longer supported by it's maker? If so why?

Here is a list based on GTK version and if it's still supported by it's maker.

Debian
stable 5.0 (lenny) 2.12.11
testing (squeeze) 2.20.1
unstable (sid) 2.20.1
http://wiki.debian.org/DebianEtch

Ubuntu
8.04 LTS (hardy) 2.12.9
9.04 (Jaunty Jackalope) 2.16.1
9.10 (Karmic Koala) 2.18.3
10.04 (Lucid Lynx) 2.20.0
https://wiki.ubuntu.com/Releases

Fedora
11 (Leonidas) 2.16.1
12 (Constantine) 2.18.3
will be 13 (rawhide) 2.21.0
http://fedoraproject.org/wiki/Releases

openSUSE
11.0 2.12.9
11.1 2.14.4
11.2 2.18.1
factory 2.20.0
http://en.opensuse.org/SUSE_Linux_Lifetime

Mandriva
2008.1 2.12.9
2009.1 2.16.1
2010 2.18.3
http://www2.mandriva.com/support/lifecycle/

Gentoo
stable 2.18.6
unstable 2.18.9
Gentoo has a rolling update. (Release version is meaningless)

Redhat Enterprise
3.9 2.2.4
4.8 2.4.13
5.5 2.10.4
6-BETA 2.18.6
http://www.redhat.com/security/updates/eol/

GTK versions nicked from http://distrowatch.com/.

I have not addressed version of GTK, I quoted the GTK. ;) For me the gtk1 was no longer more alive, he's ugly and reminds me of Win95. :P

I could not translate that part, and I think you not understand well my message (or I do not translate well). :/

I agree.

Bart

"Does anyone use a Linux distribution that is no longer supported by it's maker?
If so why?"

There was a discussion in the thread about the usage of old releases, see it there.
I personally know people who use for example old ubuntu because their hardware is not supported (I know this normally does not happen but it still does in some cases) or too slow with the newer releases. I gues there can be more reasons.
The point I was trying to make was that we should know who and on which system uses lazarus so such decisions could be made. I do not have that information. If there is some source from where you know that no one uses lazarus on releases with old gtk just show it and that should solve this issue. :)
However, I agree that in general it is a viable policy to align the required version to the officially supported main distros (and of course take advantage of all of it's features). But I think at this point we do not know if the general case applies to lazarus or our user base is different and we should follow a different path (like being compatible with old systems). I hope it is clear now.

Kriszti?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100515/351c1b2d/attachment.html>

+1

http://ik.homelinux.org/

+1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100515/6950a961/attachment.html>

Hi

Does anyone use a Linux distribution that is no longer supported by it's maker? If so why?

Some people might do it, for different reasons, and then they usually use an old version of every program and library.
Some of those old programs / libraries are still supported so that bugs get fixed but all new features go to latest versions.

Lazarus could follow the same idea. Old libraries are supported in a "fixes- branch" of old Lazarus version while the latest version supports only the recent library versions.

Juha

Indeed, and coming from someone who has to support distributions using GTK2.08 and earlier your method of dynamic linking has worked flawlessly. Much appreciated!

While I'm commenting in this thread. The LCL may be buggy (it certainly has its moments), but at least it natively supports the Mac.

Regards,
Brad

setup a VM with the latest version out of the box is easy and takes almost no time. The real machines are configured for their task. Upgrading those means work and time. And the latter I want to spend on more fun things.

Marc

2010/5/15 Kriszti?n Nagy :

For .deb packages, Debian Stable must be used as a reference distro.

Gustavo

Graeme Geldenhuys wrote

I agree with Henry. Linux is free, simply upgrade - there is no goodreason not to stay up-to-date.

There can be plenty of good reasons, particularly when a distro drops a package that users are used to (e.g. Debian dropping SeaMonkey AKA IceApe). At that point a site can continue to have a fairly robust set of systems by simply upgrading kernels, but upgrading libraries and "middleware" can be vastly more difficult.

As you go on to note, at that point it's possible to stick at an older version of FPC and/or Lazarus, although it sometimes takes quite a lot of work finding out exactly what versions will run. However that means that any problems the user has cannot be addressed by telling him to get the latest version from SVN or to use the latest snapshot.

Frankly, it's a dilemma. It's unreasonable to expect the developers to limit themselves to older library (gtk etc.) versions, and it's undesirable to lose users by telling them that they have to upgrade when they can't.

I think that one thing that would be useful would be a table somewhere- possibly in a wiki- of the latest FPC/Lazarus versions that users have found to work on a particular platform.

Mark Morgan Lloyd wrote

As you go on to note, at that point it's possible to stick at an older version of FPC and/or Lazarus, although it sometimes takes quite a lot of work finding out exactly what versions will run.

You can combine the info here:

http://wiki.lazarus.freepascal.org/LCL_Internals#Minimum_Toolkit_versions

And check on Distro Watch which distribution version have which Toolkit versions.

Frankly, it's a dilemma. It's unreasonable to expect the developers to limit themselves to older library (gtk etc.) versions, and it's undesirable to lose users by telling them that they have to upgrade when they can't.

That's why usually we make a compromise. If possible the libraries are dynamically loaded. Sometimes the cost of keeping support for older versions becomes too high and moving up is inevitable.

Florian Klaempfl wrote

Debian Lenny is afaik.

Is there a portable way that an app can query the widget set version for an "About" box or error report? I'm routinely displaying FPC and Lazarus versions as determined at compilation but knowing what's been found at runtime would be useful.

And don't forget: FPC still uses only i386 instructions in the default setup while using Pentium4+ stuff would allow often much better code. All modern CPUs support it for years ;)

I raised a bit of interest elsewhere by comparing Delphi and FPC code generation. Delphi is still stuck on i386 and doesn't know about SSE etc., so it's arguable whether FPC by default needs to do better.

Looking at Debian "Lenny" as an example, I think it's worth noting that the kernel and libc appear to be -i686 but everything else is -i386. Obviously there might be Pentium-aware optimisation in the binaries but I'm not sure that can be checked by inspection.

I think I'd vote for i686 AKA P-II, but with minimal capabilities check during installation. Again, I think this suggests that an easily-found compatibility matrix would be a great help.

Hi

Mark Morgan Lloyd wrote

I raised a bit of interest elsewhere by comparing Delphi and FPC code generation. Delphi is still stuck on i386 and doesn't know about SSE etc., so it's arguable whether FPC by default needs to do better.

Of course it needs!
Delphi is not the ultimate maximum perfection out there. I think GCC is a better target when competing about code generation features.

Juha

But gcc users aren't the target audience of FPC...

-Fl?vio

Yes, they are.
When talking about produced code, FPC is in the same league. Delphi is nothing in HPC.

Mattias

I was trying to keep my phrasing neutral, but I think there are a couple of significant points. The first is that gcc is generally bundled with an OS distribution, if the OS can't run on <686 then it's obviously safe to make the compiler assume >=686 as well. Hence FPC bundled with a distro might also be different from the generic binary snapshot.

The second is that user expectations of FPC and Lazarus might differ: somebody using a command-line compiler on an older system might tolerate being told that he has to go back to 2.0.0 and run make a couple of times, but somebody who simply wants a competent RAD IDE might not.

Graeme Geldenhuys wrote

Last time (some months ago) when I tried to run Lazarus IDE via a remote X11 session, the IDE was totally unusable (extremely slow), yet other GTK2 applications ran fine. So I don't think it was a GTK2 issue, but rather a LCL-GTK2 issue.

GTK v1 and v2 both looking OK now over X, although I usually use VNC for other reasons. I've checked x86, SPARC and PowerPC (Mac), in all cases running Linux.

There are peculiarities in control spacing between VNC and X (notebook tab height, spacing between items in a RadioGroup etc.) which I don't think are Lazarus's problem but instead are caused by VNC not reporting dpi accurately. If I can characterise this better I'll raise it in a separate thread, or a bug report if I'm really confident of my facts.

> bottom of the list rather than junking it completely? That way it could > degrade gracefully but would still be visible to anybody who wanted it, and I though it is already doing this? :)

Everybody makes the point that it's degrading and deprecated, but (as of 0.28.3) it still appears at the top of the list without a health warning, while v2 is marked beta. I get the impression that's not the message that the developers are trying to send to the user community :-)

Mark Morgan Lloyd wrote

Everybody makes the point that it's degrading and deprecated, but (as of 0.28.3) it still appears at the top of the list without a health warning, while v2 is marked beta. I get the impression that's not the message that the developers are trying to send to the user community :-)

Thanks for the bug report. I fixed it in rev25577

Mark Morgan Lloyd wrote

I usually use VNC for other reasons. I've checked x86, SPARC and PowerPC (Mac), in all cases running Linux.

Did anybody try using VNC to remote-control a Lazarus (GTK2) application running on Arm-Linux ?

Thanks,
-Michael

Not recently I'm afraid. I got badly bogged down trying to use my one development ARM system for both webcams- which meant I had to push it onto Debian "unstable"- and FPC/Lazarus... I had the usual problems with EABI etc. and ground to a halt.

If it would be of any general help I could revert to a stable distro i.e. comparable with what's on the PowerPC, and try again.

Hmm, which webcam do you use?

Mark Morgan Lloyd wrote

If it would be of any general help I could revert to a stable distro i.e. comparable with what's on the PowerPC, and try again.

Many thanks for the offer. I'm just evaluating ARM for a new project, but it's not up to speed right now. I'm going to try VNC on the ARM system one day soon and let you know what I find, and maybe ask for more help ...

Thanks again,
-Michael

FPC ran and compiled itself. FPC compiled Lazarus which ran, although on the ARM system I was using it needed a lot of swap to compensate for limited RAM- I gave it 512Mb. I was able to move projects off other machines and compile and run them, although without going through my notes I can't say what mixes of VNC, (remote) X and widget sets I used.

Noting that we're talking Linux here: a number of not-very-recent (i.e. cheap :-) USB ones which in principle are supported by SPCA. To be frank I've only had acceptable results with a PCI BTTV card (badged Grandtec), everything else tends to work over an extremely limited brightness range- couple of optical instruments are rather better (a gooseneck endoscope and a Bresser microsocope) but I suspect in part because the illumination level etc. is much more constrained.

I tried to post some more detailed notes the last time somebody was asking about this, it was only later that I realised I was still trying to send to the old server :-) In brief I think there are two sets of problems:

i) Some drivers support v4l v1, and some v2: apps have to know which. There's a shim .so which works round some of the issues but I don't think the situation's been helped by code maintenance related to moving SPCA into the kernel.

ii) Drivers almost always rely on register settings captured when the camera is running under Windows. I suspect that in many cases Windows drivers are aware of multiple submodels, so while Linux recognises a USB camera by vid:pid it has no way of knowing that there are different ways it can be tweaked.

I'd be happy to dig through my notes and code (C, I admit) but I think a new thread would be in order.

Sounds good :)

In fact in the end I would like to cross-compile the ARM-projects on a PC and remote-debug them via Ethernet.

Did you try this, as well ?

Thanks !

-Michael

Michael Schnell wrote

In fact in the end I would like to cross-compile the ARM-projects on a PC and remote-debug them via Ethernet. Did you try this, as well ?

Bit like the old Logitech debuggers :-) No, because I was looking at things from the point of view of trying to have multiple architectures- x86, SPARC, PowerPC and ARM- set up like "real" computers rather than embedded targets.