From sysrpl at gmail.com Sat Jul 2 06:26:00 2022 From: sysrpl at gmail.com (Anthony Walter) Date: Sat, 2 Jul 2022 00:26:00 -0400 Subject: [Lazarus] Codebot Cross Landing Page and Update Message-ID: Hello everyone. I wanted to let you all know I created a landing page for my recently updated Codebot Cross library. I've been working on the library as my base set of units for some time now, but have only been pushing updates to my private git server. With a FOSS application I published recently, I pushed a big update to my public facing repository on Github. Some people were asking me for documentation or pictures, so I cobles together this landing page: https://www.getlazarus.org/cross/ It contains installation, documentation, and organization information about the library along with links to some demonstration projects and articles. Now that I have my private and public code synched, I plan to push more regularly to Github. I also have been going through an old external hard drive I picked out of my closet and found a few projects I'd like to dust off, bring up to standards, and publish. Thank you for your attention. Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossh at rosshemail.com Wed Jul 6 14:17:06 2022 From: rossh at rosshemail.com (Ross Hemingway) Date: Wed, 6 Jul 2022 08:17:06 -0400 Subject: [Lazarus] Compiling IDE to QT5 fails on Ubuntu Message-ID: Per my forum post https://forum.lazarus.freepascal.org/index.php/topic,59843.0.html Ubuntu 20, using the 2.2.2 deb files to install. The IDE rebuild fails to complete with QT5 selected.? The error looks to be that a makefile script (idepkg) is checking for existence of /usr/share/lazarus////units/x86_64-linux/qt5 and has fatal error due not allowed to create directory.? An empty qt and gtk2 directory exists here, and was created as part of the deb file install, but not a qt5 directory.?? None of the IDE rebuild files get stored here, but the makefile is still checking and has fatal error if directory qt5 is not found.??? Issue seems to be some aspects of the old IDE rebuild process still exist, where it would place the revised units directly into the /usr/.. directories. Solution: (easy)? have the deb install script create the missing empty /usr/share/laz...../qt5 dir per above, or (harder) fix the idepkg makefile to stop checking for locations it no longer uses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sysrpl at gmail.com Fri Jul 15 11:44:15 2022 From: sysrpl at gmail.com (Anthony Walter) Date: Fri, 15 Jul 2022 05:44:15 -0400 Subject: [Lazarus] More Gtk3 Status Message-ID: Last year in September 2021 I wrote this list asking about the status of the Gtk3 widgetset implementation for Lazarus. The consensus at the time seemed to indicate that the package was still incomplete and had no maintainer. Over the past few days, I have been attempting to add Gtk3 widgetset support to a few upcoming library projects I will soon release. As someone with a lot of experience in the areas of general programming, object pascal programming, code library design, and importantly the inner workings of the Lazarus WS (widgetset) abstraction layers for a few different backends, I have this to say. The design of the Gtk3 widgetset backend for Lazarus is fundamentally a bad design and unnecessarily difficult to work with. I can provide specifics about all the problems I see with it in a follow up message if anyone cares to know more, but I am more interested and motivated to get an answer to a burning question that I hope someone can answer. My question is: After 11 years of the Gtk3 release by the Gnome Foundation, and the unmaintained status of Gtk2 by the same foundation, when are we within the Lazarus community going to be comfortable going seeing something someone has started, recognize it as a fundamentally bad design, and officially delete it, thereby allowing someone else to start fresh perhaps steering clear of the problems inherited in a prior bad design attempt? I know I will hear people responding to my question with the statement that I could do this if it's something I care about. That is, I could start writing what might consider a proper design of the Gtk3 widgetset for Lazarus. To those people, I would say I have a lot of other projects and problems IRL I am working on at the the moment and don't have the time to start yet another endeavor as big as redesigning and rewriting the Gtk3 widgetset for Lazarus. Sure I can provide a lot of valuable insight as to what is wrong with the current attempt, but don't have the time (my actual health is failing IRL), but it would be foolish for me to try to take over the Gtk3 widgetset at this point. In brief, if anyone out there cares about helping Lazarus and bringing its support for the Linux desktop more up to date with its current underlying toolkit options, I would offer them both encouragement and some guidance as to both what to avoid and what to do that is good. I have a whole bunch of web browser related source code for Lazarus Gtk3 that I have been sitting on, waiting to publish when Gtk3 support in Lazarus was a bit more mature. I also have a new OpenGL toolkit (an example of the source code interface is here ) I want to release with Gtk3 support on Lazarus. I'd like to be able to release this stuff and a lot more before I die. -------------- next part -------------- An HTML attachment was scrubbed... URL: From denisgolovan at yandex.ru Fri Jul 15 12:00:54 2022 From: denisgolovan at yandex.ru (denisgolovan) Date: Fri, 15 Jul 2022 13:00:54 +0300 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: Message-ID: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> Hi Antony & all Personally I am interested in complete Gtk3 widgetset in Lazarus. Unfortunately, I can only donate some funds to make it happen. Of course, financial help is not the complete solution, but it might help. Perhaps it's possible to make a separate project at https://foundation.freepascal.org/ to collect funds for volunteer(s) for that specific purpose. -- Regards, Denis Golovan From michael at freepascal.org Fri Jul 15 12:26:41 2022 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 15 Jul 2022 12:26:41 +0200 (CEST) Subject: [Lazarus] More Gtk3 Status In-Reply-To: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> Message-ID: On Fri, 15 Jul 2022, denisgolovan via lazarus wrote: > Hi Antony & all > > Personally I am interested in complete Gtk3 widgetset in Lazarus. > Unfortunately, I can only donate some funds to make it happen. Of course, financial help is not the complete solution, but it might help. > > Perhaps it's possible to make a separate project at https://foundation.freepascal.org/ to collect funds for volunteer(s) for that specific purpose. There already is an ongoing project since 2020 to complete the Gtk3 widgetset ? Mattias Gaertner looked into this, if my memory serves me well he made an inventory of the work it would take to bring the Gtk 3 widgetset up-to-date. I see I forgot to set the page's visibility in the CMS :/ I did so now. Michael. From denisgolovan at yandex.ru Fri Jul 15 12:40:32 2022 From: denisgolovan at yandex.ru (denisgolovan) Date: Fri, 15 Jul 2022 13:40:32 +0300 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> Message-ID: <3888001657881632@myt5-76cfa60c365b.qloud-c.yandex.net> > I see I forgot to set the page's visibility in the CMS :/ > > I did so now. > > Michael. Thanks, Michael. Now, next step - how can I donate to this specific project? The only thing I about specific project donation is following: ============= At a later stage, we'll set up per-project funding, so you can donate directly for the implementation of a particular project you would like to see realized. ============= ... I think I saw that note couple years ago, but somehow I managed to donate something to specific project. Unfortunately, I cannot remember how. Could you direct me? Or perhaps state this information at site itself? -- Regards, Denis Golovan From sysrpl at gmail.com Fri Jul 15 12:43:09 2022 From: sysrpl at gmail.com (Anthony Walter) Date: Fri, 15 Jul 2022 06:43:09 -0400 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> Message-ID: Respectfully, I believe the current underlying implementation of Gtk3 is fundamentally a bad design making it unnecessarily difficult to work with. I do not see it being completed and see its poor design as a large part of the reason it has been languishing for so long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From denisgolovan at yandex.ru Fri Jul 15 12:45:50 2022 From: denisgolovan at yandex.ru (denisgolovan) Date: Fri, 15 Jul 2022 13:45:50 +0300 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> Message-ID: <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> > Respectfully, I believe the current underlying implementation of Gtk3 is fundamentally a bad design making it unnecessarily difficult to work with. I do not see it being completed and see its poor design as a large part of the reason it has been languishing for so long. Could you be more specific about "current underlying implementation of Gtk3"? Do you mean current in-master or the one Michael just publish at foundation site? -- Regards, Denis Golovan From sysrpl at gmail.com Fri Jul 15 13:47:11 2022 From: sysrpl at gmail.com (Anthony Walter) Date: Fri, 15 Jul 2022 07:47:11 -0400 Subject: [Lazarus] More Gtk3 Status In-Reply-To: <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> Message-ID: Denis, I will attempt the big design flaws I have found so far while wrangling with the current Gtk3 widget implementation. There are three main layers underpinning cross platform LCL widgetset. 1) We obviously have the LCL itself that mimics the VCL and creates a cross platform component and control library with the same classes and hierarchy across multiple platforms. This piece works well enough. 2) We have underlying native toolkits written in C or C++, or some other language, whose functionality is exposed to Free Pascal by a flat C style API of imported functions, enumerations, constants, and records. This piece works well enough also. 3) We have a series of pascal WS (widgetset) classes used in conjunction with the "RegisterWSComponent(TSomeControl, TWSSomeControl);" that is responsible for binding the 1 and 2 layers. The WS classes are responsible for creating the actual underlying native toolkit widget or control from layers 2 and bridging access to specific properties and methods to layer 1. Okay, this works. I would have designed a set of interfaces to bridge this piece instead, but we have these WS classes. I'll deal with it. Now here is the first big problem with the Gtk3 widgetset as implemented. Somehow someone decided it would be a neat idea to add a 4th piece just for Gtk3. This piece attempts to wedge itself between 2 and 3 by recreating the already existing flat C style API from piece 3 as a big series of pascal objects that redeclare the Gtk3 API as a series of objects (see TGtk3Widget in the file gtk3widgets.pas). Now we have a 4th layer just for Gtk3 that not only adds more complexity, but also introduces peculiar behaviors altering what someone writing a Gtk3 native widget port needs to know while following through with creating a control or component. For an example of the problem this additional with Gtk3 4th layer introduces, consider my attempts to take some Gtk2 widgets I have written and also support them in Gtk3 with its extra layer. I recently updated my gtk vte (virtual terminal emulator control, code here and video here ) that currently works under Gtk2. While writing the Gtk2 version I referenced the flat C API from here and had little to no problems getting it working. With the Gtk2 widgetset implementation in Lazarus I was able to just use the Gtk2 documents online to see what functions existed related to working with Gtk2 widgets and it worked. This is what I expect when working with a native widgetset, that is I read the documentation provided by the actual widget to toolkit maker (reading documentation at gnome.og). Now with the current Gtk3 widget implementation tries to introduce a whole other extra layer that works differently than the actual Gtk3 documentation provides. Not only are the Gtk/Gdk functions I need hidden elsewhere, but they work differently in most cases, as decided by whomever is maintaining the base Gtk3 widgetset for Lazarus. I DO NOT want to spend my time trying to figure out where someone has hidden a Gtk3 widget API inside some class from which I am supposed to figure out to inherit in the hopes that the Gtk3 widgetset maker got right. This whole declaration of the flat Gtk3 C style API and putting them into another set of pascal classes that are then references by WS classes and then referenced by LCL controls and components is just BAD BAD BAD. It should be KISS. Just make the control handle an actual reference to the underlying system toolkit handle, and please DO NOT attempt to recreate another object hierarchy (in addition to the WS classes) of each possible widget or object type present on a platform or toolkit combination. Stay with a straight flat C style API and let me read the actual developers documentation instead of forcing me to figure and find errors you created in wiring a whole new API re-duplicating their APIs above and beyond and behind the LCL. For reference, in addition the vte example I posted above, I have also been wrangling with webkitgtk for Gtk3 also OpenGL under Gtk3 with the same problems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From denisgolovan at yandex.ru Fri Jul 15 14:37:46 2022 From: denisgolovan at yandex.ru (denisgolovan) Date: Fri, 15 Jul 2022 15:37:46 +0300 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> Message-ID: <6262461657888666@sas1-ac0cb6954dcf.qloud-c.yandex.net> > Denis, > > I will attempt the big design flaws I have found so far while wrangling with the current Gtk3 widget implementation. > There are three main layers underpinning cross platform LCL widgetset. > > 1) We obviously have the LCL itself that mimics the VCL and creates a cross platform component and control library with the same classes and hierarchy across multiple platforms. This piece works well enough. > > 2) We have underlying native toolkits written in C or C++, or some other language, whose functionality is exposed to Free Pascal by a flat C style API of imported functions, enumerations, constants, and records. This piece works well enough also. > > 3) We have a series of pascal WS (widgetset) classes used in conjunction with the "RegisterWSComponent(TSomeControl, TWSSomeControl);" that is responsible for binding the 1 and 2 layers. The WS classes are responsible for creating the actual underlying native toolkit widget or control from layers 2 and bridging access to specific properties and methods to layer 1. Okay, this works. I would have designed a set of interfaces to bridge this piece instead, but we have these WS classes. I'll deal with it. > > Now here is the first big problem with the Gtk3 widgetset as implemented. Somehow someone decided it would be a neat idea to add a 4th piece just for Gtk3. This piece attempts to wedge itself between 2 and 3 by recreating the already existing flat C style API from piece 3 as a big series of pascal objects that redeclare the Gtk3 API as a series of objects (see TGtk3Widget in the file gtk3widgets.pas). Now we have a 4th layer just for Gtk3 that not only adds more complexity, but also introduces peculiar behaviors altering what someone writing a Gtk3 native widget port needs to know while following through with creating a control or component. > > For an example of the problem this additional with Gtk3 4th layer introduces, consider my attempts to take some Gtk2 widgets I have written and also support them in Gtk3 with its extra layer. I recently updated my gtk vte (virtual terminal emulator control, code here and video here) that currently works under Gtk2. While writing the Gtk2 version I referenced the flat C API from here and had little to no problems getting it working. With the Gtk2 widgetset implementation in Lazarus I was able to just use the Gtk2 documents online to see what functions existed related to working with Gtk2 widgets and it worked. This is what I expect when working with a native widgetset, that is I read the documentation provided by the actual widget to toolkit maker (reading documentation at gnome.og). > > Now with the current Gtk3 widget implementation tries to introduce a whole other extra layer that works differently than the actual Gtk3 documentation provides. Not only are the Gtk/Gdk functions I need hidden elsewhere, but they work differently in most cases, as decided by whomever is maintaining the base Gtk3 widgetset for Lazarus. I DO NOT want to spend my time trying to figure out where someone has hidden a Gtk3 widget API inside some class from which I am supposed to figure out to inherit in the hopes that the Gtk3 widgetset maker got right. This whole declaration of the flat Gtk3 C style API and putting them into another set of pascal classes that are then references by WS classes and then referenced by LCL controls and components is just BAD BAD BAD. > > It should be KISS. Just make the control handle an actual reference to the underlying system toolkit handle, and please DO NOT attempt to recreate another object hierarchy (in addition to the WS classes) of each possible widget or object type present on a platform or toolkit combination. Stay with a straight flat C style API and let me read the actual developers documentation instead of forcing me to figure and find errors you created in wiring a whole new API re-duplicating their APIs above and beyond and behind the LCL. > > For reference, in addition the vte example I posted above, I have also been wrangling with webkitgtk for Gtk3 also OpenGL under Gtk3 with the same problems. Hi Anthony While I understand your concerns and they seem clear & perfectly valid, but I cannot help or influence Lazarus/FPC devs in any way. If they accept this layer as ok, it's they who support Lazarus & they decide at the very end which way GTK3 would go. I guess it's Mattias Gaertner whom you should talk to. It's the one who volunteered to develop & support GTK3 stuff right now. It would be nice to have Mattias join this discussion. -- Regards, Denis Golovan From badsector at runtimeterror.com Fri Jul 15 18:45:02 2022 From: badsector at runtimeterror.com (Kostas Michalopoulos) Date: Fri, 15 Jul 2022 19:45:02 +0300 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> Message-ID: On 7/15/22 14:47, Anthony Walter via lazarus wrote: > Denis, > > I will attempt the big design flaws [...] > Now here is the first big problem with the Gtk3 widgetset > as?implemented. Somehow someone decided it would be a neat idea to add a > 4th piece just for Gtk3. [...] This isn't a flaw, the approach the Gtk3 backend has makes sense if you consider that it is trying to avoid all the special case functionality for what essentially mimicing the Win32 API in an increasingly (in every major version) weird and "non-Win32-like" API. In a way the Gtk1 and Gtk2 widgetsets do it too but if anything they do it in a messier way because for anything non-trivial they allocate a separate TWidgetInfo object (a record) that they map between the Gtk1/Gtk base widget and the LCL functionality/data that needs to emulate the Win32 behavior all the time when that data is needed with the source code being littered with calls like "GetOrCreateWidgetInfo(handle)". The Gtk3 widgetset instead of doing that uses the OOP functionality that Free Pascal had for decades now :-P to avoid doing that runtime mapping and put widget-specific functionality in its own class. Otherwise that functionality would need to be spread all over the place - especially for calls that assume that a call with HWND would apply to all widgets the same way. Also about that "just for Gtk3", in fact it isn't just the Gtk3 backend that takes the OOP approach with a custom class per control - from a quick look, the Qt, Qt5, FPGUI, Carbon and MUI widgetsets take that approach too. > Just make the control handle an actual reference to > the underlying system toolkit handle, and please DO NOT attempt to > recreate another object hierarchy While it can be a minor surprise, in practice you are already dealing with widgetset-specific functionality anyway and you should always keep the widgetset itself "in the loop" - meaning that even if you try to bypass it, you still need to know what the widgetset does. And again, if anything, the Gtk3 approach still seems better because control has its own class for the underlying widgets which makes it easier to find what is going on. Kostas From sysrpl at gmail.com Fri Jul 15 20:38:01 2022 From: sysrpl at gmail.com (Anthony Walter) Date: Fri, 15 Jul 2022 14:38:01 -0400 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> Message-ID: Kostas, We already have an object oriented layer to interact with controls. That layer is the LCL. What you are saying is it makes sense for each widgetset to create their own separate and independent class hierarchy, or to use TWidgetInfo, or have something akin to: LCL-> WSClasses -> TSomePlatformWidgets (ie TGtk3Widget class and derivitatives) -> Flat C API What would make more sense to me would be: LCL Object -> IWidget -> Flat C API Where any control would need to fill implement the requirements of IWidget to be complete. In this way we could have a contract between the LCL and what is expected of a control (IWidget), a button (IButton), a listbox (IListBox), a page control (IPageControl), and so on. You might ask how does this fix anything? Well first it nails down three layers instead of four of five. Second, it creates a contact between the LCL and someone writing the part to go between the LCL and flat C APIs. Third, it provides a consistent model for ANYONE wanting to implement a widgetset, thus making it MUCH easier for people to understand what is going on. Forth, implementors can look at other widgetsets to understand how to create a new or fix a malfunctioning part of the widgetset they are working on. Again, I would support the idea of using Handles on platform specific objects, like a Canvas (DC on Windows, CairoRed of gtk3), a WinControl (HWND on Windows, PGtkObject on gtk2/Gtk3) IN ADDITION TO A well described non reference counted interface model for platform specific objects (IWidget, ICanvas, IButton, IListBox) which the LCL would depend on to automatically take care of the platform and widget specific glue. uses { This unit would defines the contract between the LCL and all Widgetset be defining all relevant interfaces that must be implemented to make a LCL widgetset } Widgets, ... ; type TWinControl = class(TControl, IWidget) private FWidget: IWidget; protected property Widget: IWidget read FWidget implements IWidget; .... end; ... TCustomListBox = class(TWinControl, IListBox) private function GetListBox: IListBox; protected property ListBox: IListBox read GetListBox implements IListBox; .... end; ... function TCustomListBox.GetListBox: IListBox; begin Result := Widget as IListBox; end; -------------- next part -------------- An HTML attachment was scrubbed... URL: From fpc at pascalprogramming.org Sat Jul 16 15:42:05 2022 From: fpc at pascalprogramming.org (Marco van de Voort) Date: Sat, 16 Jul 2022 15:42:05 +0200 Subject: [Lazarus] gtk3, glib2 headers, gir2pascal Message-ID: <629cac09-be91-08cf-b83a-44c301f30ce6@pascalprogramming.org> Who maintains the gtk3 headers and gir2pascal? Last week I tried to port a glib based library (Aravis), and I noticed that the interface/gtk3/gtk3defs headers were out of date, and didn't support Windows. So I sought to regenerate them, with a modified gir2pascal and also saw that some more recent patches (https://github.com/n1tehawk/gir2pascal) were not incorporated in lazarus-ccr yet. (I base myself on that version). Since local changes and github<>gitlab is complicated, it is probably the best to work with patches. Anybody interestd? From ganmax at narod.ru Sat Jul 16 21:27:50 2022 From: ganmax at narod.ru (Maxim Ganetsky) Date: Sat, 16 Jul 2022 22:27:50 +0300 Subject: [Lazarus] gtk3, glib2 headers, gir2pascal In-Reply-To: <629cac09-be91-08cf-b83a-44c301f30ce6@pascalprogramming.org> References: <629cac09-be91-08cf-b83a-44c301f30ce6@pascalprogramming.org> Message-ID: <6fad844c-19f8-e07b-7811-6045406df007@narod.ru> 16.07.2022 16:42, Marco van de Voort via lazarus ?????: > > Who maintains the gtk3 headers and gir2pascal? > > Last week I tried to port a glib based library (Aravis), and I noticed > that the interface/gtk3/gtk3defs headers were out of date, and didn't > support Windows. > > So I sought to regenerate them, with a modified gir2pascal and also saw > that some more recent patches (https://github.com/n1tehawk/gir2pascal) > were not incorporated in lazarus-ccr yet. (I base myself on that version). > > Since local changes and github<>gitlab is complicated, it is probably > the best to work with patches. Anybody interestd? It is actually worse, it's Git->SVN. Although the patch set is not very big (and looks fine BTW), so it's doable. But IMO, this tool should just be incorporated into Lazarus sources. What do you (and others) think about this? -- Best regards, Maxim Ganetsky mailto:ganmax at narod.ru From fpc at pascalprogramming.org Sun Jul 17 14:09:00 2022 From: fpc at pascalprogramming.org (Marco van de Voort) Date: Sun, 17 Jul 2022 14:09:00 +0200 Subject: [Lazarus] gtk3, glib2 headers, gir2pascal In-Reply-To: <6fad844c-19f8-e07b-7811-6045406df007@narod.ru> References: <629cac09-be91-08cf-b83a-44c301f30ce6@pascalprogramming.org> <6fad844c-19f8-e07b-7811-6045406df007@narod.ru> Message-ID: On 16-7-2022 21:27, Maxim Ganetsky via lazarus wrote: > > It is actually worse, it's Git->SVN. Although the patch set is not > very big (and looks fine BTW), so it's doable. > > But IMO, this tool should just be incorporated into Lazarus sources. > What do you (and others) think about this? > Agree. Due to the usage for the interface headers it is kind of like a dependency of lazarus, so it shouldn't be in a repo for 3rd party components. From zeljko at holobit.hr Mon Jul 18 11:59:02 2022 From: zeljko at holobit.hr (zeljko) Date: Mon, 18 Jul 2022 11:59:02 +0200 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> Message-ID: <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> On 15. 07. 2022. 13:47, Anthony Walter via lazarus wrote: > Denis, > > I will attempt the big design flaws I have found so far while wrangling > with the current Gtk3 widget?implementation. > There are three main layers?underpinning cross platform LCL widgetset. > > 1) We obviously have the LCL itself that mimics the VCL and creates a > cross platform component?and control library with the same classes?and > hierarchy?across multiple platforms. This piece?works well enough. > > 2) We?have underlying?native toolkits written in C or C++, or some other > language, whose functionality is exposed to Free Pascal by a flat C > style API of imported functions, enumerations, constants, and > records.?This piece works well enough also. > > 3)?We have a series of pascal WS (widgetset) classes used in conjunction > with the "RegisterWSComponent(TSomeControl, TWSSomeControl);" that is > responsible for binding the 1 and 2 layers. The WS classes are > responsible for creating the actual underlying native toolkit?widget or > control from layers?2 and bridging access to specific properties and > methods to layer?1. Okay, this works.? I would have designed a set of > interfaces to bridge this piece instead, but we have these WS classes. > I'll deal with it. > > Now here is the first big problem with the Gtk3 widgetset > as?implemented. Somehow someone decided it would be a neat idea to add a > 4th piece just for Gtk3. This piece attempts to wedge itself between 2 > and 3 by recreating the already existing flat C style API from piece 3 > as a big series of pascal objects that redeclare the Gtk3 API as a > series of objects (see TGtk3Widget in the file gtk3widgets.pas). Now we > have a 4th layer just for Gtk3 that not only adds more complexity, but > also introduces peculiar behaviors altering what someone writing a Gtk3 > native widget?port needs to know while following through with creating a > control or component. I've commited gtk3 skeleton and basic controls + some winapi functions (AFAIR it was 2012 or even 2013). Everything is based on qt/qt5/carbon/cocoa philosophy already inside LCL. At that time I've maintained gtk2 and it's not so pleasant for maintainer (maybe for you as programmer of your apps, but not lazarus lcl-ws maintainer) so my decision was to encapsulate gtk3 to pascal objects, and if someone ask me to introduce gtk4 I'll do it in same way. Why ? Easy maintaining. Also, after I commited gtk3 there were none or just few commiters to the gtk3 ws (I could not continue with gtk3 ws because of lacking spare time). > > For an example of the problem this additional with Gtk3 4th layer > introduces, consider my attempts to take some Gtk2 widgets I have > written and also support them in Gtk3 with its extra layer. I recently > updated my gtk vte (virtual terminal emulator control, code here > and video here > ) that currently > works under Gtk2. While writing the Gtk2 version I referenced the flat C > API from here > and had > little to no problems getting it working. With the Gtk2 widgetset > implementation in Lazarus I was able to just use the Gtk2 documents > online to see what functions existed related to working with Gtk2 > widgets and it worked. This is what I expect when working with a native > widgetset, that is I read the documentation provided by the actual > widget to toolkit maker (reading documentation at gnome.og). You're mixing apples & oranges (LCL vs your application). They're different in many ways. Just simple example is event filters and event triggering at the right time - eg TListView.OnSelectItem ... mousedown->onselectitem->mouseup (order isn't important here, but point is that such order should be same on all platforms, and ppl are filling bugs about it, so maintainer should fix that if possible). > > Now with the current Gtk3 widget implementation tries to introduce a > whole other extra layer that works differently than the actual Gtk3 > documentation provides. Not only are the Gtk/Gdk functions I need hidden > elsewhere, but they work differently in most cases, as decided by > whomever is maintaining the base Gtk3 widgetset for Lazarus. I DO NOT > want to spend my time trying to figure out where someone has hidden a > Gtk3 widget API inside some class from which I am supposed to figure out > to inherit in the hopes that the Gtk3 widgetset?maker got right. This > whole declaration of the flat Gtk3 C style API and putting them into > another set of pascal classes that are then references by WS classes and > then referenced by LCL controls and components is just BAD BAD BAD. > > It should be KISS. Just make the control handle an actual reference to > the underlying system toolkit handle, and please DO NOT attempt to > recreate another object hierarchy (in addition to the WS classes) of > each possible widget or object type present on a platform or toolkit > combination. Stay with a straight flat C style API and let me read the > actual developers documentation?instead of forcing me to figure and find > errors you created in wiring a whole new API re-duplicating their APIs > above and beyond and behind the LCL. Seen a lot of ppl who give smart advices to lazarus/fpc developers in last 15 yrs that I'm commited to lazarus, but rare or none provided any code for lazarus. zeljko From petr at petrhlozek.cz Mon Jul 18 12:03:14 2022 From: petr at petrhlozek.cz (=?UTF-8?B?UGV0ciBIbG/FvmVr?=) Date: Mon, 18 Jul 2022 12:03:14 +0200 Subject: [Lazarus] More Gtk3 Status In-Reply-To: <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> Message-ID: Hi, I'm sorry, maybe a stupid question. Why trying to implement Gtk3 when we have Gtk4? Gtk3 will be outdated very soon and the problem will be the same like with Gtk2. Petr po 18. 7. 2022 v 11:59 odes?latel zeljko via lazarus napsal: > > > > On 15. 07. 2022. 13:47, Anthony Walter via lazarus wrote: > > Denis, > > > > I will attempt the big design flaws I have found so far while wrangling > > with the current Gtk3 widget implementation. > > There are three main layers underpinning cross platform LCL widgetset. > > > > 1) We obviously have the LCL itself that mimics the VCL and creates a > > cross platform component and control library with the same classes and > > hierarchy across multiple platforms. This piece works well enough. > > > > 2) We have underlying native toolkits written in C or C++, or some other > > language, whose functionality is exposed to Free Pascal by a flat C > > style API of imported functions, enumerations, constants, and > > records. This piece works well enough also. > > > > 3) We have a series of pascal WS (widgetset) classes used in conjunction > > with the "RegisterWSComponent(TSomeControl, TWSSomeControl);" that is > > responsible for binding the 1 and 2 layers. The WS classes are > > responsible for creating the actual underlying native toolkit widget or > > control from layers 2 and bridging access to specific properties and > > methods to layer 1. Okay, this works. I would have designed a set of > > interfaces to bridge this piece instead, but we have these WS classes. > > I'll deal with it. > > > > Now here is the first big problem with the Gtk3 widgetset > > as implemented. Somehow someone decided it would be a neat idea to add a > > 4th piece just for Gtk3. This piece attempts to wedge itself between 2 > > and 3 by recreating the already existing flat C style API from piece 3 > > as a big series of pascal objects that redeclare the Gtk3 API as a > > series of objects (see TGtk3Widget in the file gtk3widgets.pas). Now we > > have a 4th layer just for Gtk3 that not only adds more complexity, but > > also introduces peculiar behaviors altering what someone writing a Gtk3 > > native widget port needs to know while following through with creating a > > control or component. > > > I've commited gtk3 skeleton and basic controls + some winapi functions > (AFAIR it was 2012 or even 2013). Everything is based on > qt/qt5/carbon/cocoa philosophy already inside LCL. At that time I've > maintained gtk2 and it's not so pleasant for maintainer (maybe for you > as programmer of your apps, but not lazarus lcl-ws maintainer) so my > decision was to encapsulate gtk3 to pascal objects, and if someone ask > me to introduce gtk4 I'll do it in same way. Why ? Easy maintaining. > Also, after I commited gtk3 there were none or just few commiters to the > gtk3 ws (I could not continue with gtk3 ws because of lacking spare time). > > > > > For an example of the problem this additional with Gtk3 4th layer > > introduces, consider my attempts to take some Gtk2 widgets I have > > written and also support them in Gtk3 with its extra layer. I recently > > updated my gtk vte (virtual terminal emulator control, code here > > and video here > > ) that currently > > works under Gtk2. While writing the Gtk2 version I referenced the flat C > > API from here > > and had > > little to no problems getting it working. With the Gtk2 widgetset > > implementation in Lazarus I was able to just use the Gtk2 documents > > online to see what functions existed related to working with Gtk2 > > widgets and it worked. This is what I expect when working with a native > > widgetset, that is I read the documentation provided by the actual > > widget to toolkit maker (reading documentation at gnome.og). > > > You're mixing apples & oranges (LCL vs your application). They're > different in many ways. Just simple example is event filters and event > triggering at the right time - eg TListView.OnSelectItem ... > mousedown->onselectitem->mouseup (order isn't important here, but point > is that such order should be same on all platforms, and ppl are filling > bugs about it, so maintainer should fix that if possible). > > > > > > Now with the current Gtk3 widget implementation tries to introduce a > > whole other extra layer that works differently than the actual Gtk3 > > documentation provides. Not only are the Gtk/Gdk functions I need hidden > > elsewhere, but they work differently in most cases, as decided by > > whomever is maintaining the base Gtk3 widgetset for Lazarus. I DO NOT > > want to spend my time trying to figure out where someone has hidden a > > Gtk3 widget API inside some class from which I am supposed to figure out > > to inherit in the hopes that the Gtk3 widgetset maker got right. This > > whole declaration of the flat Gtk3 C style API and putting them into > > another set of pascal classes that are then references by WS classes and > > then referenced by LCL controls and components is just BAD BAD BAD. > > > > It should be KISS. Just make the control handle an actual reference to > > the underlying system toolkit handle, and please DO NOT attempt to > > recreate another object hierarchy (in addition to the WS classes) of > > each possible widget or object type present on a platform or toolkit > > combination. Stay with a straight flat C style API and let me read the > > actual developers documentation instead of forcing me to figure and find > > errors you created in wiring a whole new API re-duplicating their APIs > > above and beyond and behind the LCL. > > Seen a lot of ppl who give smart advices to lazarus/fpc developers in > last 15 yrs that I'm commited to lazarus, but rare or none provided any > code for lazarus. > > zeljko > -- > _______________________________________________ > lazarus mailing list > lazarus at lists.lazarus-ide.org > https://lists.lazarus-ide.org/listinfo/lazarus -- web: https://petrhlozek.cz email: petr at petrhlozek.cz hobby: https://www.ok2cqr.com/ From fpc at pascalprogramming.org Mon Jul 18 17:39:41 2022 From: fpc at pascalprogramming.org (Marco van de Voort) Date: Mon, 18 Jul 2022 17:39:41 +0200 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> Message-ID: <09cf24db-f7dd-0cb1-7836-5219ae1c2c5a@pascalprogramming.org> On 18-7-2022 12:03, Petr Hlo?ek via lazarus wrote: > I'm sorry, maybe a stupid question. Why trying to implement Gtk3 when > we have Gtk4? Gtk3 will be outdated very soon and the problem will be > the same like with Gtk2. It is not known how much it even matters for the subset that LCL uses. Interested people could simply try to get the GTK3 port working with GTK4, and evaluate the differences. From support at uvviewsoft.com Mon Jul 18 17:53:38 2022 From: support at uvviewsoft.com (Alexey Torgashin) Date: Mon, 18 Jul 2022 18:53:38 +0300 Subject: [Lazarus] More Gtk3 Status In-Reply-To: <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> Message-ID: <5f3787451062ba0dd2d97d9fdb4e570c@uvviewsoft.com> Zeljko, currently gtk3 WS is not able to run my text editor app. Various visual bugs in the main form. I will be happy to pay you (initial author) 200$ if you fix the gtk3 for my editor (others will benefit too in theory). Alexey From ganmax at narod.ru Tue Jul 19 01:22:02 2022 From: ganmax at narod.ru (Maxim Ganetsky) Date: Tue, 19 Jul 2022 02:22:02 +0300 Subject: [Lazarus] gtk3, glib2 headers, gir2pascal In-Reply-To: References: <629cac09-be91-08cf-b83a-44c301f30ce6@pascalprogramming.org> <6fad844c-19f8-e07b-7811-6045406df007@narod.ru> Message-ID: <60ec0b75-7099-4419-5b16-ca6ac1aaebb6@narod.ru> 17.07.2022 15:09, Marco van de Voort via lazarus ?????: > > On 16-7-2022 21:27, Maxim Ganetsky via lazarus wrote: >> >> It is actually worse, it's Git->SVN. Although the patch set is not >> very big (and looks fine BTW), so it's doable. >> >> But IMO, this tool should just be incorporated into Lazarus sources. >> What do you (and others) think about this? >> > Agree. Due to the usage for the interface headers it is kind of like a > dependency of lazarus, so it shouldn't be in a repo for 3rd party > components. This tool is now part of Lazarus source code tree in main branch and located in /tools/gir2pascal. -- Best regards, Maxim Ganetsky mailto:ganmax at narod.ru From zeljko at holobit.hr Tue Jul 19 09:50:41 2022 From: zeljko at holobit.hr (zeljko) Date: Tue, 19 Jul 2022 09:50:41 +0200 Subject: [Lazarus] More Gtk3 Status In-Reply-To: <5f3787451062ba0dd2d97d9fdb4e570c@uvviewsoft.com> References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> <5f3787451062ba0dd2d97d9fdb4e570c@uvviewsoft.com> Message-ID: <4156c1d9-9fbb-8d4a-0471-0d8154d53f0e@holobit.hr> On 18. 07. 2022. 17:53, Alexey Torgashin via lazarus wrote: > > Zeljko, currently gtk3 WS is not able to run my text editor app. Various > visual bugs in the main form. I will be happy to pay you (initial > author) 200$ if you fix the gtk3 for my editor (others will benefit too > in theory). Sorry, but I don't have enough spare time to play with gtk3, but even if I fix it I don't need money for that work, better give it to lazarus project. Can you point to specific issues ? zeljko From fpc at pascalprogramming.org Tue Jul 19 15:10:49 2022 From: fpc at pascalprogramming.org (Marco van de Voort) Date: Tue, 19 Jul 2022 15:10:49 +0200 Subject: [Lazarus] gtk3, glib2 headers, gir2pascal In-Reply-To: <60ec0b75-7099-4419-5b16-ca6ac1aaebb6@narod.ru> References: <629cac09-be91-08cf-b83a-44c301f30ce6@pascalprogramming.org> <6fad844c-19f8-e07b-7811-6045406df007@narod.ru> <60ec0b75-7099-4419-5b16-ca6ac1aaebb6@narod.ru> Message-ID: <3b7faaf3-2122-392a-4655-cdd30016e759@pascalprogramming.org> On 19-7-2022 01:22, Maxim Ganetsky via lazarus wrote: > > This tool is now part of Lazarus source code tree in main branch and > located in /tools/gir2pascal. > Great, thanks. I'll try to add my mods (windows-only) in the coming days. From ganmax at narod.ru Wed Jul 20 01:46:48 2022 From: ganmax at narod.ru (Maxim Ganetsky) Date: Wed, 20 Jul 2022 02:46:48 +0300 Subject: [Lazarus] More Gtk3 Status In-Reply-To: <4156c1d9-9fbb-8d4a-0471-0d8154d53f0e@holobit.hr> References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> <5f3787451062ba0dd2d97d9fdb4e570c@uvviewsoft.com> <4156c1d9-9fbb-8d4a-0471-0d8154d53f0e@holobit.hr> Message-ID: 19.07.2022 10:50, zeljko via lazarus ?????: > > > On 18. 07. 2022. 17:53, Alexey Torgashin via lazarus wrote: >> >> Zeljko, currently gtk3 WS is not able to run my text editor app. >> Various visual bugs in the main form. I will be happy to pay you >> (initial author) 200$ if you fix the gtk3 for my editor (others will >> benefit too in theory). > > Sorry, but I don't have enough spare time to play with gtk3, but even if > I fix it I don't need money for that work, better give it to lazarus > project. Can you point to specific issues ? E. g. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39335 It even has a patch attached, which needs a review. -- Best regards, Maxim Ganetsky mailto:ganmax at narod.ru From zeljko at holobit.hr Wed Jul 20 09:32:23 2022 From: zeljko at holobit.hr (zeljko) Date: Wed, 20 Jul 2022 09:32:23 +0200 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> <5f3787451062ba0dd2d97d9fdb4e570c@uvviewsoft.com> <4156c1d9-9fbb-8d4a-0471-0d8154d53f0e@holobit.hr> Message-ID: On 20. 07. 2022. 01:46, Maxim Ganetsky via lazarus wrote: > 19.07.2022 10:50, zeljko via lazarus ?????: >> >> >> On 18. 07. 2022. 17:53, Alexey Torgashin via lazarus wrote: >>> >>> Zeljko, currently gtk3 WS is not able to run my text editor app. >>> Various visual bugs in the main form. I will be happy to pay you >>> (initial author) 200$ if you fix the gtk3 for my editor (others will >>> benefit too in theory). >> >> Sorry, but I don't have enough spare time to play with gtk3, but even >> if I fix it I don't need money for that work, better give it to >> lazarus project. Can you point to specific issues ? > > E. g. > > https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39335 > > It even has a patch attached, which needs a review. > That patch isn't ok. Just drop simple TStringGrid with ScrollBars = sbAutoBoth and increase row count so it needs scrollbar: it is not visible even if you have thousands of rows, but scrolling looks ok, better than it's now. zeljko From marc at dommelstein.nl Wed Jul 20 22:48:18 2022 From: marc at dommelstein.nl (Marc Weustink) Date: Wed, 20 Jul 2022 22:48:18 +0200 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> Message-ID: I don't know if it is the same for GTK 4 buut for GTK 1,2 ,3 the problem was that the API isn't stable. It is work in progress. So for every dot version you get new functionality. Until they decide it is time for a major release and gtkX+1 is born, where gtkX becomes obsolete soon. The moment we (Lazarus) has a full WS implementation, the version of GTK is obsolete. Another problem is/was the way we implemented gtk1, it was our first interface. We bolted GTK2 on that code. In the meantime other WS were implemented with a better class hierarchy. Which is lucky done for gtk3 too. Marc On July 18, 2022 12:03:14 PM GMT+02:00, "Petr Hlo?ek via lazarus" wrote: >Hi, > >I'm sorry, maybe a stupid question. Why trying to implement Gtk3 when >we have Gtk4? Gtk3 will be outdated very soon and the problem will be >the same like with Gtk2. > >Petr > >po 18. 7. 2022 v 11:59 odes?latel zeljko via lazarus > napsal: >> >> >> >> On 15. 07. 2022. 13:47, Anthony Walter via lazarus wrote: >> > Denis, >> > >> > I will attempt the big design flaws I have found so far while wrangling >> > with the current Gtk3 widget implementation. >> > There are three main layers underpinning cross platform LCL widgetset. >> > >> > 1) We obviously have the LCL itself that mimics the VCL and creates a >> > cross platform component and control library with the same classes and >> > hierarchy across multiple platforms. This piece works well enough. >> > >> > 2) We have underlying native toolkits written in C or C++, or some other >> > language, whose functionality is exposed to Free Pascal by a flat C >> > style API of imported functions, enumerations, constants, and >> > records. This piece works well enough also. >> > >> > 3) We have a series of pascal WS (widgetset) classes used in conjunction >> > with the "RegisterWSComponent(TSomeControl, TWSSomeControl);" that is >> > responsible for binding the 1 and 2 layers. The WS classes are >> > responsible for creating the actual underlying native toolkit widget or >> > control from layers 2 and bridging access to specific properties and >> > methods to layer 1. Okay, this works. I would have designed a set of >> > interfaces to bridge this piece instead, but we have these WS classes. >> > I'll deal with it. >> > >> > Now here is the first big problem with the Gtk3 widgetset >> > as implemented. Somehow someone decided it would be a neat idea to add a >> > 4th piece just for Gtk3. This piece attempts to wedge itself between 2 >> > and 3 by recreating the already existing flat C style API from piece 3 >> > as a big series of pascal objects that redeclare the Gtk3 API as a >> > series of objects (see TGtk3Widget in the file gtk3widgets.pas). Now we >> > have a 4th layer just for Gtk3 that not only adds more complexity, but >> > also introduces peculiar behaviors altering what someone writing a Gtk3 >> > native widget port needs to know while following through with creating a >> > control or component. >> >> >> I've commited gtk3 skeleton and basic controls + some winapi functions >> (AFAIR it was 2012 or even 2013). Everything is based on >> qt/qt5/carbon/cocoa philosophy already inside LCL. At that time I've >> maintained gtk2 and it's not so pleasant for maintainer (maybe for you >> as programmer of your apps, but not lazarus lcl-ws maintainer) so my >> decision was to encapsulate gtk3 to pascal objects, and if someone ask >> me to introduce gtk4 I'll do it in same way. Why ? Easy maintaining. >> Also, after I commited gtk3 there were none or just few commiters to the >> gtk3 ws (I could not continue with gtk3 ws because of lacking spare time). >> >> > >> > For an example of the problem this additional with Gtk3 4th layer >> > introduces, consider my attempts to take some Gtk2 widgets I have >> > written and also support them in Gtk3 with its extra layer. I recently >> > updated my gtk vte (virtual terminal emulator control, code here >> > and video here >> > ) that currently >> > works under Gtk2. While writing the Gtk2 version I referenced the flat C >> > API from here >> > and had >> > little to no problems getting it working. With the Gtk2 widgetset >> > implementation in Lazarus I was able to just use the Gtk2 documents >> > online to see what functions existed related to working with Gtk2 >> > widgets and it worked. This is what I expect when working with a native >> > widgetset, that is I read the documentation provided by the actual >> > widget to toolkit maker (reading documentation at gnome.og). >> >> >> You're mixing apples & oranges (LCL vs your application). They're >> different in many ways. Just simple example is event filters and event >> triggering at the right time - eg TListView.OnSelectItem ... >> mousedown->onselectitem->mouseup (order isn't important here, but point >> is that such order should be same on all platforms, and ppl are filling >> bugs about it, so maintainer should fix that if possible). >> >> >> > >> > Now with the current Gtk3 widget implementation tries to introduce a >> > whole other extra layer that works differently than the actual Gtk3 >> > documentation provides. Not only are the Gtk/Gdk functions I need hidden >> > elsewhere, but they work differently in most cases, as decided by >> > whomever is maintaining the base Gtk3 widgetset for Lazarus. I DO NOT >> > want to spend my time trying to figure out where someone has hidden a >> > Gtk3 widget API inside some class from which I am supposed to figure out >> > to inherit in the hopes that the Gtk3 widgetset maker got right. This >> > whole declaration of the flat Gtk3 C style API and putting them into >> > another set of pascal classes that are then references by WS classes and >> > then referenced by LCL controls and components is just BAD BAD BAD. >> > >> > It should be KISS. Just make the control handle an actual reference to >> > the underlying system toolkit handle, and please DO NOT attempt to >> > recreate another object hierarchy (in addition to the WS classes) of >> > each possible widget or object type present on a platform or toolkit >> > combination. Stay with a straight flat C style API and let me read the >> > actual developers documentation instead of forcing me to figure and find >> > errors you created in wiring a whole new API re-duplicating their APIs >> > above and beyond and behind the LCL. >> >> Seen a lot of ppl who give smart advices to lazarus/fpc developers in >> last 15 yrs that I'm commited to lazarus, but rare or none provided any >> code for lazarus. >> >> zeljko >> -- >> _______________________________________________ >> lazarus mailing list >> lazarus at lists.lazarus-ide.org >> https://lists.lazarus-ide.org/listinfo/lazarus > > > >-- >web: https://petrhlozek.cz >email: petr at petrhlozek.cz >hobby: https://www.ok2cqr.com/ >-- >_______________________________________________ >lazarus mailing list >lazarus at lists.lazarus-ide.org >https://lists.lazarus-ide.org/listinfo/lazarus From sysrpl at gmail.com Thu Jul 21 07:55:07 2022 From: sysrpl at gmail.com (Anthony Walter) Date: Thu, 21 Jul 2022 01:55:07 -0400 Subject: [Lazarus] More Gtk3 Status In-Reply-To: References: <5813311657879254@sas8-edeffd71deff.qloud-c.yandex.net> <5517121657881950@vla1-3991b5027d7d.qloud-c.yandex.net> <71a9f2ef-ed71-d2f6-72ec-16942d55e06f@holobit.hr> Message-ID: After some research, I found a few more serious issues with Gtk3. I will not bother filing bugs as the issues seem too ingrained to the implementation. Here are some problems: 1) TGtkWidget makes custom drawing an inaccessible private field value that cannot be set. What this means is that only certain predefined widgets (with enumerated contents) in Gtk3Widgets.pas are allowed to receive paint handling events. 2) The CreateWidget virtual method of TGtkWidget is designed to create an underlying Gtk3 widget instance. But the design makes brings inheritance problems, as you cannot make use of the inherited CreateWidget implementation if you want a different widget type. For example, a TCustomControl backed by a Gtk.DrawingArea. 3) TGtkWidget is defined as having a "property Widget: PGtkWidget". PGtkWidget is ^TGtkWidget. TGtkWidget is not a TGtkWidget. Ridiculous. 4) There are a reduplication of header file translations, and they are each incomplete in their own different ways. There is LazGtk3.pas and Gtk3.pas, LazGdk3.pas and Gdk3, Pango and LazPango1. The latter names in the list are duplicates to the lclgtk3 widgetset and are incomplete and different from the former named units. 5) Colors are not being handled correctly with the Gtk3 implementation. I don't know how many I have found where clWindowText is not being correctly translated to a valid RGB (ColorToRGB). For example on my system theme clWindowText is near white, but with lots of code parts of this Gtk3 implementation it's translated to near black because no RGB translations are being made. 6) All drawing is being handled by cairo on Gtk3 and drawing on a parent control (a Form for example) can change the drawing state in a child control (TPaintBox for example). If I invalidate a form and draw using a transform, the paintbox drawing is automatically transformed. There are cairo functions to preserve the state, but they are not being used correclty in the Gtk3 widgetset implementation. 7) There are lots of other problems. I completed a couple of tasks related -------------- next part -------------- An HTML attachment was scrubbed... URL: