Hi,

The previous message thread on this topic some weeks ago had lots of noise and no clear answer. Though I think it did raise some awareness to the problem.

Recently I have seen many Mantis reports regarding GTK1 marked as resolved (about 3-5 of mine in the last 7 days) without actually fixing those bugs. Many of them were closed with comments goes something like this: GTK1 cannot compile anymore and has been marked deprecated. Well, if it cannot compile, then why not simply remove the GTK1 option from the IDE wigetset list - it is clearly not being maintained any more and is broken more often than not.

For those die-hard developers that must continue to use GTK1 - continue using 0.9.28.3 until you can upgrade to GTK2. Life evolves, so should your project. But it's rather pointless having a widgetset marked "deprecated" (already a good starting point) in the widgetset list, when it fact it cannot even be compiled any more.

I vote to simply remove it completely from the widgetset list. No point in having something marked "deprecated" in Beta software either. I think the Lazarus project is the first to ever do this (at least from all project I have ever seen). :-)

We try to fix compilation bugs as soon as possible.

It has been suspended, meaning patches are welcome, but the current Lazarus developers won't spend time on fixing gtk1 bugs.

Well, if it cannot compile, then why not simply remove the GTK1 option from the IDE wigetset list - it is clearly not being maintained any more and is broken more often than not.

Some people still want to use it and we accept patches for it.

Why deprive those people of using 0.9.29? We don't break it intentionally, like we don't break win98 support intentionally.

Against.

Vincent

Personally I have nothing againts. But first someone needs to remove the gtk1 code from the gtk2 interface.

Best regards,
Paul Ishenin.

The suggestion is impossible because AFAIK Gtk2 is still merged with Gtk1.

I've been ignoring all gtk discussions.

About splitting gtk2 from gtk. How about the following:

- copy all gtk1 widgetset units used by gtk2 to gtk2 dir
- remove gtk1 dir usage, for gtk2 widgetset
- remove all {$ifdef GTK1} and gtk1 specific code from the copied units

imho, simple enough. Are there some caveats?

thanks,
dmitry

Well, sure something like that could be made but a real cleanup would be much prefered.

And since already Vincent is against removing Gtk1, there is little use to do a quick and dirty split. We need a real cleanup moving the code to it's adequate places. The gtk1 units should not exist in the gtk2 directory after a real clean up.

02.06.2010 21:51, Vincent Snijders wrote:
..

We try to fix compilation bugs as soon as possible. It has been suspended, meaning patches are welcome, but the current Lazarus developers won't spend time on fixing gtk1 bugs.

...

Some people still want to use it and we accept patches for it.

...

Why deprive those people of using 0.9.29? We don't break it intentionally, like we don't break win98 support intentionally.

Ok. There is a small reason to support that gtk1. The lets do the following things:
1. split gtk1 and gtk2 code so any change in gtk1 code can make no harm to gtk2 interface
2. give commit rights to those ppl who want the gtk1 interface support. so other developers should now warry about the problems it has.

Best regards,
Paul Ishenin.

Felipe Monteiro de Carvalho wrote

The suggestion is impossible because AFAIK Gtk2 is still merged with Gtk1.

I know that. I'm not suggesting the underlying code simply gets deleted. I'm suggesting as a start, to remove the GTK1 option from the Widgetset Lists in places like "Project > Project Options > Compiler Options" and "Tools > Configure Build Lazarus" etc..

That way it doesn't reflect badly on the Lazarus project - showing something as "usable", but doesn't even compile any more.

Graeme Geldenhuys wrote

That way it doesn't reflect badly on the Lazarus project - showing something as "usable", but doesn't even compile any more.

It does compile.

Vincent

Paul Ishenin wrote

Personally I have nothing againts. But first someone needs to remove the gtk1 code from the gtk2 interface.

Nope, I see it as follows:

* First remove GTK1 from all widgetset lists in the IDE.
* Remove GTK1 unit/include paths information from CodeTools
* Then remove all IFDEF GTK1 etc code from GTK2 widgetset units.
* Then copy all gtk1 units used for GTK2 into GTK2 directory.
* Then remove all GTK1 only units and directory.
* Then clean-up GTK2 units further or restructure the code completely.

The first point is rather important for now - simply because GTK1 is always in a "cannot compile" state. The other options (except for the last one) doesn't seem that difficult - as Dmitry suggested as well.

Vincent Snijders wrote

It does compile.

A month ago it didn't. A week ago it didn't, and probably tomorrow it wouldn't either. :)

Graeme Geldenhuys wrote

The first point is rather important for now - simply because GTK1 is always in a "cannot compile" state.

False. I just compiled it.

Vincent

Vincent Snijders wrote

False. I just compiled it.

13:30 (GMT+2) it did not. I just tried again with new updated Lazarus SVN, and now LCL-GTK1 does indeed compile. I can also compile a simple 1 Form, 1 Button with 1 Editbox project and it ran. Trying to compile the Lazarus IDE also worked, but trying to run the Lazarus IDE compiled with GTK1 gives the following error.

I suppose, even if Lazarus IDE itself cannot be compiled with GTK1, at least projects using GTK1 can - though I would still be very wary about this.

----------------------------------------------------------
$ ./lazarus --pcp=/temp/lazarus-gtk1

Gtk-WARNING **: Failed to load module "libcanberra-gtk-module.so": `gtk_module_init': /usr/lib/libcanberra-gtk-module.so: undefined symbol: gtk_module_init
[WARNING] Out of OEM specific VK codes, changing to unassigned [WARNING] Out of unassigned VK codes, assigning $FF SetPrimaryConfigPath NewValue="/temp/lazarus-gtk1" -> "/temp/lazarus-gtk1" TMainIDE.ParseCmdLineOptions:
PrimaryConfigPath="/temp/lazarus-gtk1"
SecondaryConfigPath="/etc/lazarus"
ERROR in LCL:
Creating gdb catchable error:
$00000000006CACD1 line 1513 of lclproc.pas
$00000000008D635B line 679 of gtkdef.pp
$00000000008D62E7 line 658 of gtkdef.pp
$00000000008B739B line 5017 of gtkwidgetset.inc
$00000000008BD28D line 1436 of gtkwinapi.inc
$00000000008BBFE6 line 1607 of gtkwinapi.inc
$00000000007A6066 line 126 of include/winapi.inc
$00000000007BB8C4 line 1125 of include/font.inc
$00000000007BC0A1 line 1246 of include/font.inc
ERROR in LCL:
Creating gdb catchable error:
$00000000006CACD1 line 1513 of lclproc.pas
$00000000008B73AC line 5020 of gtkwidgetset.inc
$00000000008BCA20 line 1844 of gtkwinapi.inc
$00000000007A6066 line 126 of include/winapi.inc
$00000000007BB8C4 line 1125 of include/font.inc
$00000000007BC0A1 line 1246 of include/font.inc
$00000000007BCD97 line 260 of include/canvas.inc
$000000000084A725 line 41 of include/controlcanvas.inc $00000000007BFBBF line 1574 of include/canvas.inc
TApplication.HandleException Division by zero
Stack trace:
$00000000006CAD02 line 1514 of lclproc.pas
$00000000008B73AC line 5020 of gtkwidgetset.inc
$00000000008BCA20 line 1844 of gtkwinapi.inc
$00000000007A6066 line 126 of include/winapi.inc
$00000000007BB8C4 line 1125 of include/font.inc
$00000000007BC0A1 line 1246 of include/font.inc
$00000000007BCD97 line 260 of include/canvas.inc
$000000000084A725 line 41 of include/controlcanvas.inc $00000000007BFBBF line 1574 of include/canvas.inc
$00000000007BF128 line 1251 of include/canvas.inc
$00000000007BEC81 line 1154 of include/canvas.inc
$00000000006D9353 line 118 of splash.pp
$000000000086CEA9 line 96 of include/graphiccontrol.inc $000000000090A75B line 213 of include/customimage.inc $000000000086CD84 line 64 of include/graphiccontrol.inc $000000000069E685
$0000000000862DB5 line 1011 of include/control.inc ERROR in LCL:
Creating gdb catchable error:
$00000000006CACD1 line 1513 of lclproc.pas
$00000000008D635B line 679 of gtkdef.pp
$00000000008D62E7 line 658 of gtkdef.pp
$00000000008B739B line 5017 of gtkwidgetset.inc
$00000000008BD28D line 1436 of gtkwinapi.inc
$00000000008BBFE6 line 1607 of gtkwinapi.inc
$00000000007A6066 line 126 of include/winapi.inc
$00000000007BB8C4 line 1125 of include/font.inc
$00000000007BC0A1 line 1246 of include/font.inc
ERROR in LCL:
Creating gdb catchable error:
$00000000006CACD1 line 1513 of lclproc.pas
$00000000008B73AC line 5020 of gtkwidgetset.inc
$00000000008BCA20 line 1844 of gtkwinapi.inc
$00000000007A6066 line 126 of include/winapi.inc
$00000000007BB8C4 line 1125 of include/font.inc
$00000000007BC0A1 line 1246 of include/font.inc
$00000000008A435F line 290 of include/promptdialog.inc $00000000008A4191 line 241 of include/promptdialog.inc $00000000008A4DF3 line 536 of include/promptdialog.inc [FORMS.PP] ExceptionOccurred
Sender=EDivByZero
Exception=Division by zero
Stack trace:
$00000000006CAD02 line 1514 of lclproc.pas
$00000000008B73AC line 5020 of gtkwidgetset.inc
$00000000008BCA20 line 1844 of gtkwinapi.inc
$00000000007A6066 line 126 of include/winapi.inc
$00000000007BB8C4 line 1125 of include/font.inc
$00000000007BC0A1 line 1246 of include/font.inc
$00000000008A435F line 290 of include/promptdialog.inc $00000000008A4191 line 241 of include/promptdialog.inc $00000000008A4DF3 line 536 of include/promptdialog.inc $00000000007591D3 line 591 of include/intfbaselcl.inc $00000000007AAD3A line 337 of include/lclintf.inc
$00000000008A30B1 line 192 of include/messagedialogs.inc $000000000089E4F0 line 651 of dialogs.pp
$00000000006C0EEA line 198 of include/application.inc $00000000006C479C line 1507 of include/application.inc $00000000006C381C line 1196 of include/application.inc $0000000000950621 line 114 of lclmessageglue.pas
TApplication.HandleException: there was another exception during showing the first exception
Stack trace:
$00000000006CAD02 line 1514 of lclproc.pas
$00000000008B73AC line 5020 of gtkwidgetset.inc
$00000000008BCA20 line 1844 of gtkwinapi.inc
$00000000007A6066 line 126 of include/winapi.inc
$00000000007BB8C4 line 1125 of include/font.inc
$00000000007BC0A1 line 1246 of include/font.inc
$00000000008A435F line 290 of include/promptdialog.inc $00000000008A4191 line 241 of include/promptdialog.inc $00000000008A4DF3 line 536 of include/promptdialog.inc $00000000007591D3 line 591 of include/intfbaselcl.inc $00000000007AAD3A line 337 of include/lclintf.inc
$00000000008A30B1 line 192 of include/messagedialogs.inc $000000000089E4F0 line 651 of dialogs.pp
$00000000006C0EEA line 198 of include/application.inc $00000000006C479C line 1507 of include/application.inc $00000000006C381C line 1196 of include/application.inc $0000000000950621 line 114 of lclmessageglue.pas
[TGtkWidgetSet.Destroy] WARNING: There are 3 unreleased DCs, a detailed dump follows:
[TGtkWidgetSet.Destroy] DCs: 00007FD434241440 00007FD434241240 00007FD434241040
[TGtkWidgetSet.Destroy] WARNING: There are 9 unreleased GDIObjects, a detailed dump follows:
[TGtkWidgetSet.Destroy] GDIOs: 00007FD434253340 00007FD4342532C0 00007FD434253140 00007FD4342530C0 00007FD4342531C0 00007FD434253240 00007FD434253040
[TGtkWidgetSet.Destroy] gdiBitmap: 2
[TGtkWidgetSet.Destroy] gdiBrush: 2
[TGtkWidgetSet.Destroy] gdiFont: 2
[TGtkWidgetSet.Destroy] gdiPen: 2
[TGtkWidgetSet.Destroy] gdiRegion: 1

----------------------------------------------------------

You can ignore the "libcanberra-gtk-module.so" warning, that is only GTK1 sound support and not needed for even small test applications which do run.

Paul Ishenin wrote

1. split gtk1 and gtk2 code so any change in gtk1 code can make no harm to gtk2 interface

There seems to be a lot of code used/usable by both interfaces. Maintenance should be a lot easier if the common stuff is not duplicated, so is might even be sensible to extract common parts that already exist twice into commonly used files via functions, procedures, inheritance or include files. So there should be one ore more directory for the common stuff. There will be common stuff that really is dedicated to both GTK1 and GTK2, so this should be in a directory with "gtk" in the name, There also will be some stuff that is not really specific to gtk1/2, but used /usable for other existing (removing some duplicated code there might be sensible) or future interfaces. Such code should go into a directory without gtk in the name.

-Michael

+1
-Michael

It's enough to add an TLabel to your app and you'll get same crash. Something went wrong when changed gtkwinapi (about GDIObjects deletion or something like that).

zeljko

Michael Schnell wrote

There seems to be a lot of code used/usable by both interfaces. Maintenance should be a lot easier if the common stuff is not duplicated,

This idea was proven wrong in the history of LCL-Gtk2. And not just wrong, it has costed us hundreds of hours of development.

Because of that we don't have common code between LCL-Win32 and LCL-WinCE and it was a great idea. I am pretty sure that huges amounts of LCL-Win32 changes would break LCL-WinCE and just fill my bug tracker with regressions. While if people want fixes from Win32 I can just copy them and test.

This whole discussion, a waste of time and effort would haven't, if not used GTK! I propose to remove GTK1 & 2 of the basic code and have it as an additive or widget.

?>----------------

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

Hi!

Rigel Rig wrote

This whole discussion, a waste of time and effort would haven't, if not used GTK! I propose to remove GTK1 & 2 of the basic code and have it as an additive or widget.

GTK2 is THE widgetset currently in use on Linux. Removing it from the "core" of the IDE would mean to lose or really, really upset many of the Linux users (including me).

Also there is no real possibility to make a widgetset "additive" or as an "extension" (as became clear in the NoGUI discussion some weeks ago).

So there is no real possibility to remove GTK2. But as Paul suggested, the two GTKs - which are sharing a lot of code - should be split up and the GTK2 one should be refactored/reworked/improved, so that maintainence is made easier.

Regards,
Sven

2010/6/3 Rigel Rig :

This whole discussion, a waste of time and effort would haven't, if not used GTK! I propose to remove GTK1 & 2 of the basic code and have it as an additive or widget.

What do you mean with additive or widget? It is a widgetset, and you don't have to use it. You can always use Qt on linux.

Henry

In fairness, 0.9.29 + GTK1 didn't a couple of days ago but I was too wrapped up in my own problems to query it.

That seems reasonable to me. But I don't think that simply expunging all GTK1 code would be doing the project a favour: degrade gracefully, but do no evil.

[...]

No it isn't pointless. You forget about embedded computers, they are not growing over time and are running on small amounts of ressoruces, e.g. a 233 MHz Geode CPU having 64 MB of RAM. I wouldn't even dare to try GTK2 on that little things.

I vote to simply remove it completely from the widgetset list. No point in having something marked "deprecated" in Beta software either. I think the Lazarus project is the first to ever do this (at least from all project I have ever seen). :-)

Can you please explain one point for me:

The process of removing GTK1 is a bunch of work for the developers of lazarus as it is for the users of GTK1 beeing bound to use it, because they will have to care for getting and using the right versions of lazarus and fpc. Additionally someone has to document all this in the wiki.

But what exactly is the benefit of doing all this work?

While implementing graphics I was not so sure the dual code base of win32-winCE was such good idea. I had to code it twice, with a result that my code slightly differs on both. Since while I was testing on one, I fixed some bugs, which also had to be applied to the other. In this process I forgot a few in both codebases.

I do agree that sharing has its issues, but I hope you will understand that splitting similar code also has issues. Both are not ideal.

Marc

Let me be clear:

GTK1 wont get removed.

Marc

Marc Santhoff wrote

No it isn't pointless. You forget about embedded computers, they are not growing over time and are running on small amounts of resources, e.g. a 233 MHz Geode CPU having 64 MB of RAM. I wouldn't even dare to try GTK2 on that little things.

Then switch to fpGUI for embedded systems. It works perfectly and is low on resources and small size executables. Plus fpGUI is a lot more modern in looks than GTK1 - and fpGUI is still actively being developed. :)

But yes, I kind of see your point. But do you also know that LCL-GTK1 is *not* being maintained at all any more. You might complain, but clearly nobody is actually using LCL-GTK1 any more because so far it is only I that noticed that LCL-GTK1 is currently broken. Most of the times it can't compile, and when it does you can't even us it in applications, because the simplest program will make it crash at runtime (as my previous posts highlight and error log showed).

So if I was still maintaining an application that must use GTK1, I'll definitely stay with whatever Lazarus LCL-GTK1 version was the most stable. So far, that seems to be v0.9.26.2

But what exactly is the benefit of doing all this work?

1) It will be the start of cleaning up the spaghetti code required for GTK2
2) The cleanup will probably allow LCL-GTK2 to be easier to maintain. Most here complain that it's a mess.
3) Ending up with clearer code, it might even make LCL-GTK2 less buggy (like it's counterpart LCL-Qt - which is much younger code by the way).
4) Why advertise a feature that is constantly broken. Lazarus is already well know for being buggy - so why add fuel to the flames.
5) Code evolves. Out with the old, in with the new.

Marc Weustink wrote

GTK1 wont get removed.

And it won't be maintained and it won't work anymore. I don't see your logic, sorry.

Hm, maybe next time. When I started to write the programs in question I didn't even know there is fpGUI. I think there wasn't at all. ;)

But if I really would have to change the code base used for those programs or their future descendants at all they will definitively not be dependent on only one widget set alone.

Sure, at the cost of having to care for one more installation of IDE and compiler, remembering aka documenting the differences and so on.

?Looks like mostly viewn with the maintainers hat on. My point of view is more like the "api users" view as a programmer not changing the underlying widget set itself. Besides that, "maybe" and "might" do not count. ;)

4) Why advertise a feature that is constantly broken. Lazarus is already well know for being buggy - so why add fuel to the flames.

Never heard that. Do you sell lazarus? ;)

5) Code evolves. Out with the old, in with the new.

Really good code doesn't need to evolve. ;)
But you're right, every season brings a new fashion and style.

2010/6/3 Graeme Geldenhuys :

But I don't like the fpGUI's developer. he is very rude, and has a strange behavior: he always says, in the Lazarus mailing list, how wonderfull is his tool and how buggy is Lazarus. I don't understand that.

Gustavo

Speaking about rude: If you reply to a person saying something about the person you are replying to, you should usually address that person as "you".
Replying to a person, referring to the person you are replying to, in third person ("the fpGUI's developer") could very easily be considered as very rude too.

"Graeme Geldenhuys" to whom you replied is that "fpGUI's developer"

Regards
Martin

04.06.2010 9:48, Martin ?????:

"Graeme Geldenhuys" to whom you replied is that "fpGUI's developer"

I think that was a kind of joke. At least I feel it so. Maybe in GB humor is a bit different?

Best regards,
Paul Ishenin.

Malvinas belong to Argentina ;)

Gustavo

Yes, but Paul meant me being in GB, maybe having a diff humour.

Well I can see how it could have been meant in a humorous way. I wasn't seeing emotions, so I took it literally. I offer my apologies.

Martin

Exactly.

And, I am also told he, the fpGUI's developer, prefers decaf with plenty of milk, as opposed to the rough-ground dark strong Colombian variety the real men among us go for.

2010/6/3 Adem :

Seriously, I love Free Pascal/Lazarus. The few crashes are due to my own mistakes on my own code. Maybe I'm not a very good programmer, but I have wrote a lot of apps with Freepascal/Lazarus. Data acquisition, mostly. Unit, form, button, xml file, tchart... Ctrl+F9, BANG, a brand new app reading data from a 16f877 through serial port. Web, Linux, windows, what do you want. Give me a Mac, I can do that, too.

Great quality, free as in speech, multiplatform. Lazarus is great. Free Pascal/Freepascal is great.

Everything else is just smoke. Period.

Gus

Good to know, thanks.

(You could have told earlier, couldn't you? The discussion is totally of track with this knowledge ... ;)

i, too, got a chuckle out of gustavo's comment and just automatically assumed he was playing the devil's advocate... next message in my reader is from gustavo so i guess i'll find out in a minute :)

I mean Lazarus to be modular. Something like Linux and KDE, Gnome. You may use only Linux or Linux and KDE or Linux and Gnome or Linux and something else. I do not mean to not use GTK or QT.

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

That's the reason why we split gtk/gtk2. We'll probably grant svn write access to gtk1 dir for few ppl who wants to maintain gtk1.

zeljko

Who knows?

Luckily it's open source, so anyone can jump in and patch, or even offer to be the new maintainer. There just isn't the manpower to maintain an obsolete widgetset. I wish all the people who have been on gtk1 all this time would jump in and work on the fpgui interface, since that will really help for light-weight systems.

Henry

Yes, if nobody tells, it will go unnoticed.

Vincent

Gustavo Enrique Jimenez wrote

But I don't like the fpGUI's developer. he is very rude, and has a

There is nothing in the fpGUI license agreement that says you must communicate with the fpGUI maintainer simply because you want to use fpGUI. :)

Henry Vermaak wrote

Luckily it's open source, so anyone can jump in and patch, or even offer to be the new maintainer. ?There just isn't the manpower to

My point I probably didn't make very clear is as follows. Currently changes to GTK2 keep breaking GTK1. So even if GTK1 isn't removed totally, splitting it completely from GTK2 will at least be better. Then GTK2 changes will not affect GTK1.

Adem wrote

And, I am also told he, the fpGUI's developer, prefers decaf with plenty of milk, as opposed to the rough-ground dark strong Colombian variety the real

I really don't know how to respond to this - I lost you somewhere.

PS:
Just so you know... I do prefer fresh filter coffee to lattes. :)

zeljko wrote

That's the reason why we split gtk/gtk2. We'll probably grant svn write access to gtk1 dir for few ppl who wants to maintain gtk1.

A good idea. That would probably solve most of the current GTK1 issues. Plus GTK2 changes will not be able to break GTK1. At least this way GTK1 can still live in Lazarus for a bit longer.

I'm glad that you understood why we want to split gtk1/gtk2.

zeljko

Vincent Snijders wrote

Yes, if nobody tells, it will go unnoticed.

Sorry Vincent. Mea maxima culpa.

But at the same time I don't want to introduce noise into the ML or bug system until I'm confident of my facts.

Graeme Geldenhuys wrote

Then switch to fpGUI for embedded systems. It works perfectly and is low on resources and small size executables. Plus fpGUI is a lot more modern in looks than GTK1 - and fpGUI is still actively being developed. :)

Yes, it's still being developed- and from elsewhere in the thread it appears that it's nowhere near a drop-in replacement for GTK1: if it were I'm sure that nobody at all would have any problems switching existing projects to use it.

Look, another way of tackling this would be to stop work on fpGUI and for everybody to have an all-out push to get both GTK1 and GTK2 reliable and with similar levels of functionality for some arbitrary release. Then put both GTK1 and 2 onto maintenance-only and get fpGUI up to the same level of functionality so that it is a drop-in replacement for GTK1. Then start moving forwards again with fpGUI and GTK2.

Paul Ishenin wrote

I think that was a kind of joke. At least I feel it so. Maybe in GB humor is a bit different?

Yes, it's spelled "humour" :-)

I have to take some responsibility for any ill-feeling since I intentionally adopted a slightly hostile tone at the start of a couple of other threads. But Graeme has brought a lot of it on his own head in my opinion since resurrecting the "drop GTK1" thread when it was clear that most people weren't very keen on the idea was bound to ruffle feathers.

I prefer to compromise: during the week I drink Columbian decaf. Unmilky ;-)

Luckily, my native language is German, where it is spelled "Humor".

I prefer to compromise: during the week I drink Columbian decaf. Unmilky ;-)

For me , that's:
regular sized cappuccino, with an extra shot, extra dry, no syrups, with chocolate on top, takeaway (to go, if you are American).

Martin wrote

For me , that's: regular sized cappuccino, with an extra shot, extra dry, no syrups, with chocolate on top, takeaway (to go, if you are American).

Double espresso for me, and no shop stuff, please, I roast my own coffee :)

Henry

Due to the amount of replies some mails produce here, I stopped reading all threads. Sometimes I scan through them to see if a comment is needed. Unlike some others I try to focus on coding and not writing the same mail over and over again ;)
There was a time that a reaction within a day or two was fast.

Marc

absolutely! it isn't like some/all of the developers and/or maintainers have one of each type of machine/OS available or the time to test them all if they did ;)

the problem is that graeme does and has written about it several times but others don't grok it for some reason :?

standing here on the sidelines, i see no reason why a duplicate of the existing code cannot be copied to a GTK2 unit and then each stripped of the other's code... yeah, sure... that would result in some duplication but it would be better in the long run since they could then easily divert in their own directions without effecting the other... this would allow the GTK1 code to stay operational as long as there was a maintainer for it and also allow the GTK2 code to grow and evolve and neither would adversely effect the other... no need to try to create a share common code unit/lib... those working with GTK1 would ensure that it works what whatever version of FPC/Laz and those working with GTK2 would ensure that it works what whatever version of FPC/Laz...

seems like a win:win situation to me... even they diverge quite a bit...

IIUC: this is only because the LCL_fpGUI interface is not complete but someone has been working on that if i recall what i've read and understood it correctly...

unless i misunderstand something, once the LCL_fpGUI interface stuff is done, fpGUI will be a "drop-in" replacement for any of the existing interfaces... GTK1, GTK2, QT, WIN-whatever, etc...

do i misunderstand that?

waldo kitty wrote

unless i misunderstand something, once the LCL_fpGUI interface stuff is done, fpGUI will be a "drop-in" replacement for any of the existing interfaces... GTK1, GTK2, QT, WIN-whatever, etc...

That is correct. LCL-fpGUI will be like any of the other LCL-xxx widgetsets.

Note:
Just to be clear as well. The Roadmap wiki page only indicates the LCL-xxx features implemented for LCL. It doesn't indicate the feature of the underlying toolkit itself. Many have emailed be, and they seem to see "not implemented" status on the RoadMap wiki pages, and think that fpGUI doesn't have those features yet. This is not the case. It's only the LCL-fpGUI widgetset interface that doesn't have those features implemented.

I'd hope that you don't. But right now it seems to me that Graeme is kvetching about the fact that Lazarus's GTK1 support is going downhill without making it clear whether he really wants to use it or whether he's advertising fpGUI as an alternative.

The Linux distreax have in general moved to GTK2 and deprecate GTK1, at which point I think it's reasonable for Lazarus to prefer GTK2 (plus Carbon, Qt and so on). At the same time there seems to be a consensus that something slimmer is desirable, but- speaking as an outsider- I think it would be an enormous waste of effort trying to work on both fpGUI and GTK1 simultaneously.

Mark Morgan Lloyd wrote

kvetching about the fact that Lazarus's GTK1 support is going downhill without making it clear whether he really wants to use it or whether he's

I don't use GTK1 any more, but others want to. So I try and compile LCL and Lazarus IDE with it every now and then - I do the same think with Qt (but haven't in a long time).

I understand there is a need for a "light weight" backend for LCL (old systems, embedded devices etc), and LCL-GTK1 used to be it. But GTK1 is not being developer any more, packages for newer distros don't exist, and LCL-GTK1 is broken more often that it is fixed, so it's really a dead horse. This is why I originally wanted to introduce LCL-fpGUI, but quickly found that I simply don't have the time or LCL internals knowledge to develop fpGUI and develop LCL-fpGUI. Recently Joshyfun started working on LCL-fpGUI and managed to complete all the components on the Standard components palette tab. Hopefully he will find the energy and time to continue his good work, and maybe others could chip in and help when they see it progress. I offered to share my knowledge of fpGUI to help anybody working on LCL-fpGUI.

Are you insuniating that I am a complete failure when it comes to dark humor?

And, are you always this insensitive to people people making unfounded allegations about you?

PS: Just so you know... I do prefer fresh filter coffee to lattes. :)

You would say that, wouldn't you?

Graeme Geldenhuys wrote

I don't use GTK1 any more, but others want to. So I try and compile LCL and Lazarus IDE with it every now and then - I do the same think with Qt (but haven't in a long time).

[Etc.] Seems reasonable to me.

the way i'm reading his posts is that he wants to see GTK1 working if it is going to be included in the feature/widget set lists... if it isn't, then remove it... make sense, really...

that he mentions fpGUI as an alternative is simply, to me, providing an alternative for those that need something that works and is light weight to replace GTK1 with if it is going to sit and be dead meat...

true to a point... that point being the existing codebase running on small dedicated devices that currently use GTK1... those cannot switch to GTK2 or other widget sets because of memory and space constraints... at least that's my understanding of the conversations...

Exactly right. And I would hardly call Graeme's post kvetching. He just wants to improve Lazarus by pointing out an problem. I for one am glad he is doing so.

Felipe Monteiro de Carvalho wrote

This idea was proven wrong in the history of LCL-Gtk2.

I can't imagine how deliberately maintaining duplicated code sequencers would reduce the overall maintenance effort rather than increasing it. This contradicts any software design rules "!out of the book". But happily it's not me do decide ;).

-Michael

Marc Weustink wrote

Both are not ideal.

Right. Common code needs for a lot better documentation (or rather a documentation at all) for the commonly used
functions/procedures/objects/files. And as Documentation always is a major issue with community based projects, you are right that a big problem arises with commonly used code.

-Michael

It isn't really proven either. It's more comparing apples and oranges.

The problem is that the gtk interface was the first one implemented and got partly rewritten once. With the experience we got there, the Carbon and QT interface have a much cleaner internal design. Something the gtk interface should heve too. Were that the case, then having the same code base would be less of a problem. But.... that isn't the case.

So for the given fact of the internal state of the gtk1/gtk2 interface, it is better to split them and improve gtk2 internally.

Marc

Michael Schnell wrote

I can't imagine how deliberately maintaining duplicated code sequencers would reduce the overall maintenance effort rather than increasing it. This contradicts any software design rules "!out of the book". But happily it's not me do decide ;).

The point is that the code only looks duplicated, but really it is not. The gtk_create_button or whatever which is being called for gtk1 is not the same gtk_create_button (invented routine) which is being called for gtk2.

And they *do not* behave exactly the same. Or worse then that, then most often behave, but 10% of the time don't and then you get very hard to fix bugs. Fixing a gtk1 bug when may break gtk2, and vice-versa.

The same APIs under Windows desktop and Windows CE often has a significantly different result for each of those 2 types of Windows. So the code which was tested as perfectly working under Win32 doesn't produce the same results under WinCE because the API being used isn't the same, so it isn't the same code.

If you could remove all calls to the underlying widgetset library, then yes, totally, you are 100% right that those functions should probably be in a common unit, but trying to unify code which calls functions which just happen to have the same names, but actually come from different libraries is a recipe for a maintenance nightmare.