Forum > GTK

Problem with gtk3 when compile empty app

<< < (7/8) > >>

dbannon:
Juha, running my tomboy-ng under trunk lazarus GTK3, I am surprised, very surprised how close it is to working. I get a crash as my main form is show, a focus issue. There is nothing fancy about the main form itself but I do fiddle around with its visibility so possibly my problem. Seems some alignment problems and some updates are slow, probably because of the amount of debugging info being written.

My test app, which is supposed to be a small subset of tomboy-ng is much more unstable, thats what I have been looking at and perhaps, unfairly.

My app to manage the Lazarus Examples, https://gitlab.com/dbannon/laz_examples/-/tree/main/Utility/ExScanner appears just about userable as a GTK3 app !  Again a few sizing issues really, not bad. Sometimes a crash at exit, but I am wondering if thats debugger related.

Now, this is all with trunk, sorry, Main, from a few weeks ago. I should try the same thing on my CT install.

And yes, demanding to be installed as root is enough for me to say No Thanks !

Davo

dbannon:
OK, I have done a few test between a week old Lazarus, a day old Lazarus and Lazarus 2.2.0 and, of course CT.

First of all, you are not going to be pleased to hear this, some things work better in Lazarus 2.2.0 that all the rest, specifically the bitmaps that appear in Speedbuttons, its correct in 2.2.0, rubbish is all the rest.

I do not see any improvements delivered by your merge (but I am testing on Linux so getting rid of the writeln's is obviously a good thing for Windows).

In all cases, Radio Buttons do not work in RadioGroupbox (but do work as expected in a plain GroupBox ??).

In all cases, I cannot alter the height of a Panel programmatically, this code is ignored, works fine in all other widgetsets -


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure TForm1.Button1Click(Sender: TObject);begin    if Panel1.Height > 10 then        Panel1.Height := 1    else Panel1.Height := 50;end;

I had to rewrite the very basic test app used to determine the above, I could not import lazarus project into CT - now, thats rude !

I also had to discard my existing GTK3 test apps, they were based around forms from my real app but have been fiddled endlessly and have problems that do not show up when I run the real app under GTK3. Corruption somewhere. That I am afraid explains my impression that Lazarus GTK3 was a lot worse that it really is.

And the writeln statements would explain Akira1364 better experience with CT on Windows.

Davo

JuhaManninen:
Sorry for the delay in my reply.


--- Quote from: dbannon on January 22, 2022, 01:27:18 am ---OK, I have done a few test between a week old Lazarus, a day old Lazarus and Lazarus 2.2.0 and, of course CT.
First of all, you are not going to be pleased to hear this, some things work better in Lazarus 2.2.0 that all the rest, specifically the bitmaps that appear in Speedbuttons, its correct in 2.2.0, rubbish is all the rest.

--- End quote ---
Oh, if LCL-GTK3 is worse in the development branch "main", then we must find which revision caused it.
2.2 was branched some time ago, I am not sure how many commits affect LCL-GTK3.
If you can bisect the guilty revision with your tests, it would be helpful.


--- Quote ---I do not see any improvements delivered by your merge (but I am testing on Linux so getting rid of the writeln's is obviously a good thing for Windows).

--- End quote ---
Yes, the commit was 02115d373b794b3, "LCL-GTK3: Turn WriteLn into DebugLn. Make sure they compile. Cleanup."
Most changes seem irrelevant. CT also did change Writeln to Debugln which is a good choice.
I included only a subset of their changes. Many of them did not compile which is weird. Like Integer - Boolean comparison and such. How can they compile their code?

dbannon:
OK, will do. As time permits....

Davo

dbannon:
Juha, the problem does appear to be in  02115d373b794b3, "LCL-GTK3: Turn WriteLn into DebugLn. Make sure they compile. Cleanup.", specifically in gtk3lclintf.inc

Around line 306 the function TGtk3WidgetSet.RawImage_DescriptionFromBitmap() pops some values into an array that is defined in gtk3bindings/lazcairo1.pas.  However, in the version committed in 02115d3 they appear to be in the wrong order compared to the bindings file. Looks like CT uncommented a few extra formats but they where in the wrong place ? It needs to be -


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---function TGtk3WidgetSet.RawImage_DescriptionFromBitmap(ABitmap: HBITMAP; out ADesc: TRawImageDescription): boolean;// var//  GDIObject: PGDIObject absolute ABitmap;const  CairoImageFormatToDepth: array[cairo_format_t] of integer =  (    {CAIRO_FORMAT_INVALID}   -1,    {CAIRO_FORMAT_ARGB32}    32,    {CAIRO_FORMAT_RGB24}     24,    {CAIRO_FORMAT_A8}         8,    {CAIRO_FORMAT_A1}         1,    {CAIRO_FORMAT_RGB16_565} 16,    {CAIRO_FORMAT_RGB30}     15  );                           

Now, doing that on my system certainly fixes the problem. The test is easy, blank form, add a speed button, assign it a bit map and test. On GTK3 without the fix, image is unrecognizable.

Do you want patch, pull request, bug report ?  Its an easy fix ....

Davo

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version