View Issue Details

IDProjectCategoryView StatusLast Update
0036220LazarusLCLpublic2020-02-14 10:01
ReporterDavid Assigned ToJuha Manninen  
Status resolvedResolutionfixed 
PlatformLinuxOSFedora Gnome 
Product Version2.1 (SVN) 
Summary0036220: GTK3 gui apps fail
DescriptionOn Fedora (using default Gnome 3) but not Ubuntu, GTK3 apps fail because, I suspect ScreenInfo.PixelsPerInch is set to zero during Application.Initialization. The zero value is then used while the main form is being first displayed. TCustomForm.AfterConstruction() has -
if Application.Scaled and Scaled and (Monitor.PixelsPerInch <>PixelsPerInch) then
    AutoAdjustLayout(lapAutoAdjustForDPI, PixelsPerInch, Monitor.PixelsPerInch .......

... and Monitor.PixelsPerInch is zero. This causes a "gtk_window_resize: assertion 'width > 0' failed" and goes on to trigger a series of pixman_region32 warning from GTK.
Steps To ReproduceA blank form, select GTK3 widget set, run it. Problem is run time, does not matter if the binary is made on Fedora or not, all that matters is its run there.

I tested for this bug on a Virtual Machines running Fedora 30, on a high DPI screen. So, I think its possible that it may not happen if the screen is not high DPI or even, perhaps its sensitive to being run in the VM ? If you have problems duplicating the issue, let me know and I'll run some more tests to see just what is really necessary to see it.

ScreenInfo is set to zero in, in function TGTK3WidgetSet.GetDeviceCaps() when passed LOGPIXELSX, it calls the GTK3 api gdk_screen_width_mm - beyond there, its too deep for me !

TagsNo tags attached.
Fixed in Revisionr62211, r62212
WidgetsetGTK 3
Attached Files


Anton Kavalenka

2019-10-27 17:52

reporter   ~0118878

AFAIK Fedora has Wayland by default.
What is written in console when you run your application?


2019-10-27 23:23

reporter   ~0118884

Last edited: 2019-10-27 23:24

View 2 revisions

When we hit line 271 in GTK3WSForms, "PGtkWindow(AWidget)^.move(ALeft, ATop);" it triggers the GTK assertion I mentioned above (not exact as I have not setup copy and paste out of VM) -

(project1:6049): Gtk-[1:35mCRITICAL[0m **[34m09:00:12.730[0m:gtk_window_resize: assertion 'width >0' failed

Further on, we see a series of messages like this -

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

This is repeated seven or eight times. Both relate to having a window width of zero.

I put a couple of lines into, gtk3widgetSet.GetDeviceCaps(..) that tested for Result being zero in calls using LOGPIXELSX and LOGPIXELSY, if zero, set them to eg 96. That solved the display problems, the form shows up fine but seg v on exit. Sigh ...

And yes, Fedora uses Wayland, an endless source of problems .....

Anton Kavalenka

2019-10-28 07:24

reporter   ~0118886

Last edited: 2019-10-28 07:40

View 3 revisions

GTK warning caused by LCL trying to realize Widget before geometry (bounds) are set.

Either as LCL-QT (fixed week ago) - the GTK3 application may somewhere use function from xlib. Although this has to be caught and removed.

Try to run your application in a way:
DISPLAY=:0 ./project1

This makes Wayland use its xwayland layer.

I'm periodically playing with GTK3 widgetset, but never run in situation when application just not starts.
But all my systems are XWindow (where GTK3 works) except of one (where Wayland works, but never tested GTK3 App).
Nvidia gives the choice -
* brand-new video card+ driver ver > 450 + KMS+ Wayland
* older card + driver ver < 450 + XWindow
+ wide range of cards + OSS nouveau + KMS +Wayland


2019-10-28 11:11

reporter   ~0118894

Thanks Anton, I am pretty certain the problem relates to the Screen object initialised right at begining of startup. Before any widgets are built. Screen.PixelsPerInch is set to zero. That number is later used in calculating a scaling factor for high DPI screens. If I detect and over ride that zero, it starts up fine (but crashes at close).

Anyway, tried your suggestion of setting DISPLAY, useful, I did not know about that. But it did not make any difference. But you are still in the game ! Redhat are so confident about Wayland that they give you a bootup option to also start with xorg - and, you guessed it, the problem goes away under xorg !

Both problems - looks like the crash at close is also an wayland problem. Hmm....


Anton Kavalenka

2019-10-28 13:50

reporter   ~0118896

Last edited: 2019-10-28 13:51

View 2 revisions

Got my fault under wayland with test program from 0035667

Thread 1 "project1" received signal SIGSEGV, Segmentation fault.
0x00007ffff77d9d58 in gdk_pixbuf_get_from_surface () from /usr/lib/x86_64-linux-gnu/
(gdb) bt
#0 0x00007ffff77d9d58 in gdk_pixbuf_get_from_surface () from /usr/lib/x86_64-linux-gnu/
0000001 0x0000000000707a8c in CREATE (this=0x7ffff42789c0, vmt=0x1, AWIDGET=0x0, APAINTEVENT=false) at gtk3/gtk3objects.pas:1130
0000002 0x0000000000704a63 in GTK3DEFAULTCONTEXT () at gtk3/gtk3objects.pas:308
0000003 0x000000000066be69 in GETDC (this=0x7ffff4ce2040, HWND=140737300688016) at gtk3/
0000004 0x00000000005f4a10 in GETDC (HWND=140737300688016) at include/
0000005 0x00000000006955b5 in GETDEVICECONTEXT (this=0x7ffff4cfc0f0, WINDOWHANDLE=0) at include/
0000006 0x00000000006a3e5b in GETDEVICECONTEXT (this=0x7ffff4cfdaf0, WINDOWHANDLE=0) at include/
0000007 0x0000000000680bd7 in CREATEHANDLE (this=0x7ffff4cea720) at include/
0000008 0x00000000005e8616 in REQUIREDSTATE (this=0x7ffff4cea720, REQSTATE=...) at include/
0000009 0x00000000005e88d3 in TEXTEXTENT (this=0x7ffff4cea720, TEXT=0x7ffff4038558 'ToolButton1') at include/
0000010 0x000000000079e188 in GETTEXTSIZE (this=0x7ffff4cfdaf0) at include/
0000011 0x000000000079ee29 in CALCULATEPREFERREDSIZE (this=0x7ffff4cfdaf0, PREFERREDWIDTH=0, PREFERREDHEIGHT=0, WITHTHEMESPACE=true) at include/
0000012 0x00000000006a4e3e in GETPREFERREDSIZE (this=0x7ffff4cfdaf0, PREFERREDWIDTH=0, PREFERREDHEIGHT=0, RAW=false, WITHTHEMESPACE=true) at include/
0000013 0x000000000079e204 in GETPREFERREDSIZE (this=0x7ffff4cfdaf0, PREFERREDWIDTH=0, PREFERREDHEIGHT=0, RAW=false, WITHTHEMESPACE=true) at include/
0000014 0x00000000007a1891 in CALCULATEPOSITION (parentfp=0x7fffffffdae0) at include/
0000015 0x00000000007a1361 in WRAPBUTTONS (this=0x7ffff4cfc0f0, USESIZE=1, NEWWIDTH=0, NEWHEIGHT=0, SIMULATE=false) at include/
0000016 0x000000000079fb6e in ALIGNCONTROLS (this=0x7ffff4cfc0f0, ACONTROL=0x0, REMAININGCLIENTRECT=...) at include/
0000017 0x000000000069112f in ALIGNCONTROL (this=0x7ffff4cfc0f0, ACONTROL=0x0) at include/
0000018 0x000000000069dc28 in AUTOSIZECONTROL (parentfp=0x7fffffffdd20, ACONTROL=0x7ffff4cfc0f0) at include/
0000019 0x000000000069dc68 in AUTOSIZECONTROL (parentfp=0x7fffffffdd20, ACONTROL=0x7ffff4cfaf30) at include/
0000020 0x000000000069d9ac in DOALLAUTOSIZE (this=0x7ffff4cfaf30) at include/
0000021 0x000000000068ac21 in DOALLAUTOSIZE (this=0x7ffff4cfaf30) at include/
0000022 0x00000000006a5709 in ENABLEAUTOSIZING (this=0x7ffff4cfaf30) at include/
0000023 0x00000000006a1fc8 in SETVISIBLE (this=0x7ffff4cfaf30, VALUE=true) at include/
0000024 0x00000000004d12f8 in SETVISIBLE (this=0x7ffff4cfaf30, VALUE=true) at include/
0000025 0x00000000004d6406 in SHOW (this=0x7ffff4cfaf30) at include/
0000026 0x00000000004dffc7 in RUN (this=0x7ffff4cfa8f0) at include/
0000027 0x00000000004a319d in main () at project1.lpr:20

Anton Kavalenka

2019-10-28 14:06

reporter   ~0118897

My guess - wayland has rootwindow of size 0x0
Patch resolves the problem and makes the application appear
gtk3objects.diff (483 bytes)   
Index: gtk3objects.pas
--- gtk3objects.pas	(revision 62111)
+++ gtk3objects.pas	(working copy)
@@ -1122,6 +1122,7 @@
     AWindow := gdk_get_default_root_window;
     AWindow^.get_geometry(@x, @y, @w, @h);
+    w:=1; h:=1;
     // ParentPixmap := gdk_pixbuf_get_from_window(AWindow, x, y, w, h);
     // Widget := gdk_cairo_create(AWindow);
     // gdk_cairo_set_source_pixbuf(Widget, ParentPixmap, 0, 0);
gtk3objects.diff (483 bytes)   


2019-10-29 01:13

reporter   ~0118901

Last edited: 2019-10-29 01:56

View 2 revisions

Nope, that patch did not help. In TGtk3WidgetSet.GetDeviceCaps(), gdk_screen_width_mm still returns 0 and that is used later to scale a window and that makes bad things happen.

I note your patch sets w and h to 1. Thats a strange figure, cannot be close to right number, why 1 ?

EDIT: Another observation, the crash I see at the close depends on what I have forced Screen.PixesPerInch to be. If its less that 85 no crash, window is a little smaller than it should be but OK. If I set it to 90, window displays OK but crashes with an access violation on close. I image that number is system dependent, thats my number !

So, if Screen.PixeslsPerInch was set properly, instead of my force hack, I expect the crash would not happen. I expect ....



2019-10-29 04:47

reporter   ~0118904

Last edited: 2019-10-29 04:52

View 2 revisions

"gdk_screen_width_mm has been deprecated since version 3.22 and should not be used in newly-written code.
Use per-monitor information"

Fedora 30 uses 3.32. Gee, the Gnome Devs really look after their users, don't they ?

Sigh .....

Anton Kavalenka

2019-10-29 06:32

reporter   ~0118905

Last edited: 2019-10-29 06:48

View 3 revisions

As a workaround you can specify DPI directly (I do this for enforced scaling) before main form creation.

      ScreenInfo.PixelsPerInchX:=StrToIntDef(ParamStr(1),96); // specified in commandline

1 pixel cairo surface is used inside TGtk3DeviceContext to represent Canvas without widget (typically used for text size calculation)

As I can see Gtk3 widgetset has proper monitor enumerations routines. Calling gdk_screen_width_mm in GetDeviceCaps is a remnats of GTK2 (coped in time of GTK3 creation).

Now GTK2 does this

 LOGPIXELSX : { Logical pixels per inch in X }
    Result := ScreenInfo.PixelsPerInchX;

  LOGPIXELSY : { Logical pixels per inch in Y }
    Result := ScreenInfo.PixelsPerInchY;


2019-10-29 07:07

reporter   ~0118906

OK, I have identified a number (12-15 ?) of deprecated gdk_screen_* calls in LazGdk3, including all the ones that would help in this situation. And tested, they fail on Fedora Gnome 3.32 under wayland. My guess is they are leaving them there when they can but not bothering to, for example, hook them up to Wayland.

What we are expected to use is the Monitor set, and we don't have bindings.

In particular - gdk-monitor-get-width-mm() but maybe gdk_window_get_scale_factor() or gdk_monitor_get_scale_factor() might be interesting.

I have no experience or even an understanding of how to create those bindings, I would be willing to have a play if someone was willing to coach (but that might end up harder than doing it yourself ;-) )



2019-10-29 07:17

reporter   ~0118907

Sorry Anton, our posts crossed. Those now deprecated calls were alive quite recently so maybe a bit unfair to call them hangovers from GTK2, Gnome 3.22 was 2016 from what I can see. But deprecated they are.

Poking the scaling factors in via command line is a touch dangerous in that the app crashes (at close time) if the magic number is outside a particular range. I reckon it varies between hardware but in my case, telling it we have 80 pixels per inch is OK, 90 will cause a messy crash. My Laptop is actually 166 pixes per inch but I have no idea what VirtualBox does to that.

Maybe better to disable scaling altogether until we have a better solution ? Thats nasty too I know !


Anton Kavalenka

2019-10-29 12:38

reporter   ~0118912

I tested my application on Wayland with desktop scaling factors 1 1.2 1.5
No crash

So - general Bugtracker mantra:
Please provide simple compilable example.


2019-10-29 22:52

reporter   ~0118918

Last edited: 2019-10-29 23:07

View 2 revisions

The compilable example is easy, a blank form. The platform to test on is the issue I suspect. I am testing on Fedora 30 Gnome Wayland running in a VM on a very High DPI laptop.

I have found Ubuntu 19.10 does the same thing, if you select Wayland, Ubuntu defaults to Xorg.

The laptops 'native OS' is 18:04 Mate and I note that even on that the deprecated calls return the wrong value, get_screen_width_mm returns 508, whereas gdk_screen_get_monitor_width_mm(gdk_screen_get_default(), 0) returns the more correct 293. However, it too is deprecated and it also returns zero on the infamous Fedora running wayland.

To trigger the crash, I do this in at, for width, line 1985, TGtk3WidgetSet.GetDeviceCaps(), 4 extra lines to detect we are returning zero, set it to 80 is OK (for me) but 96 crashes.

    LOGPIXELSX : { Logical pixels per inch in X }
      Result := RoundToInt(gdk_screen_width / (gdk_screen_width_mm / 25.4));
      if Result = 0 then begin
        debugln('Warning - gdk set PixesPerInch to 0, using 80 instead');
        Result := 80;

My laptop is about 160 ppi. They are becoming quite common. Maybe we need appeal on the forum to others using high ppi screens ? If we can establish its only high a PPI problem, at least we can document that. But the real solution is to get the necessary data from Gnome's monitor rather than screen API.


2019-10-30 06:06

reporter   ~0118921

No, wrong, I think the crashes I am seeing are random, much more likely on the Fedora VM but still possible (1 in 20) on my native Mate desktop. The only thing that seems to influence them is reading from the monitor/screen width, one way or another. I tried the following code and found that it did report, accurately, my monitor width on the native Mate desktop but returns zero on Fedora in a VM , even though all calls are marked as current on the Gnome Devs website. And it greatly increases the likelyhood of a crash. in "unit1.pas" -

  type PMonitor = pointer;
  type PDisplay = pointer;
  function gdk_monitor_get_width_mm (Monitor: PMonitor) : integer; cdecl; external;
  function gdk_display_get_monitor(Display:PDisplay; MonNumb : integer): PMonitor; cdecl; external;


procedure TForm1.FormShow(Sender: TObject);
  Display : PDisplay;
  MyMonitor : PMonitor;
  Display := gdk_display_get_default(); // is in Lazgdk3
  MyMonitor := gdk_display_get_monitor(Display, 0);
  Memo1.append('Monitor width = ' + inttostr(gdk_monitor_get_width_mm (MyMonitor)));

Beam me up Scotty, I'm out of here ...


2019-11-02 12:37

reporter   ~0118975

Right, while it needs more investigation, this issue is apparently not an LCL problem at all. With a small cpp programme I can replicate the symptoms exactly, not a single line of Pascal involved !

Its either a Wayland bug, a Virtual Box bug or a small crack in the reality/unreality boundaries that is allowing some unreality to seep into our universe. Further research is indicated ....



2019-11-05 12:18

reporter   ~0119068

OK, I am suggesting we close this issue, its actually three issues. If someone can close it for me (I cannot apparently) I will log the three issues as three separate reports, two of which I have a solution for.
For the record, the three issues are -
One - Its not possible to determine physical monitor sizes with Wayland. But thats OK, Wayland wants to look after scaling itself. We just need to stop the GTK Errors that trigger a crash and memory leaks. An easy patch ....
Two - Function TGtk3WidgetSet.GetDeviceCaps() in uses deprecated GTK calls. I can fix it but does not really make things work better ?
Three - even the simplest form occasionally crashes on exit, I cannot find why.....


Juha Manninen

2019-11-05 13:09

developer   ~0119072

> I will log the three issues as three separate reports, two of which I have a solution for.

If you have patches for those 2 issues, please upload them here. The remaining open issue can have its own report if needed.

Anton Kavalenka

2019-11-05 17:39

reporter   ~0119077

Last edited: 2019-11-05 17:40

View 3 revisions

@Juha Manninen
The only patch (gtk3objects.diff) attached to this issue resolves problem with running LCL-GTK3 application on Wayland machine.

Get Linux machine with Wayland - and try to run any Lazarus-built GTK3 application.

Juha Manninen

2019-11-05 19:25

developer   ~0119081

@Anton Kavalenka, I thought the patch was no good because David replied: "Nope, that patch did not help."
How is it?
Yes, I must install Fedora into a virtual machine and test stuff myself.

Anton Kavalenka

2019-11-05 19:55

reporter   ~0119082

Last edited: 2019-11-05 20:02

View 3 revisions

I have real Debian 11 "bullseye" on Intel graphics with Wayland. The patch makes applications run instead of crash.

Topicaster blames Screen.PixelsPerinch is equal to zero. Real hardware works properly, but crashes on allocating 0-sized surface.


2019-11-05 23:16

reporter   ~0119083

Sorry, I glossed over Aton's patch, it did not relate to the issue I was chasing. It too is needed. So, "four issues".

I will post my patch latter today. I got caught posting a sloppy patch once before, thats not going to happen again !



2019-11-06 06:07

reporter   ~0119089

OK, now there are two patches associated with this report, Antons and mine (36220.patch), both are needed, a table of my tests -

* Out of the Box - Access Violation, GTK Assertion, width > 0, no form visible, memory leak.

* Anton - form shows but stupidly small, GTK Assertion, width > 0, lots of pixbuf invalid rectangles.

* Myfix - An exception caught in Forms.pp ExceptionOccurred(), no form visible, memory leak

* Both fixes - form shows correct size, no complaints on stdout.

Under Wayland, the Gnome approved functions returns zero when asked about the physical width and height of the screen. Apparently, Wayland reserves the right to scale windows in high DPI screens ! That zero gets used in some code attempting to scale a windows after creation time and causes a crash. My proposed solution is to let Wayland have its way, don't attempt to scale window sizes, let Wayland do it. If Wayland is not in use, existing code will still work.

See . I have built a bit of code in cpp to prove this is not a FPC / Lazarus issue, it also fails to get screen width in mm on Wayland using gnome functions marked as OK on their website. So, looks like we will have to go along. My cpp test code available on request.

The change in my patch is to, obviously not a GTK3 only unit ! But my change just checks for Monitor.PixelsPerInch not being zero - if its zero, its always going to be a bad thing to proceed so lets not try to scale with a zero width. That extra test could be in a {$IFDEF LCLGTK3} but unnecessary IMHO.

I am unsure of what Anton's patch does but my tests indicate that it too is necessary, operates in a different part of the code to where I have been playing.

36220.patch (1,634 bytes)   
Index: include/
--- include/	(revision 62145)
+++ include/	(working copy)
@@ -78,7 +78,8 @@
   EndFormUpdate; // the BeginFormUpdate is in CreateNew
   inherited AfterConstruction;
-  if Application.Scaled and Scaled and (Monitor.PixelsPerInch<>PixelsPerInch) then
+  if (Monitor.PixelsPerInch > 0) and Application.Scaled
+         and Scaled and (Monitor.PixelsPerInch<>PixelsPerInch) then   // DRB
     AutoAdjustLayout(lapAutoAdjustForDPI, PixelsPerInch, Monitor.PixelsPerInch,
       Width, MulDiv(Width, Monitor.PixelsPerInch, PixelsPerInch));
@@ -430,7 +431,8 @@
-  if Application.Scaled and (PixelsPerInch<>Monitor.PixelsPerInch) then
+  if (Monitor.PixelsPerInch > 0) and Application.Scaled
+         and (PixelsPerInch<>Monitor.PixelsPerInch) then   // DRB
     AutoAdjustLayout(lapAutoAdjustForDPI, PixelsPerInch, Monitor.PixelsPerInch,
       MulDiv(Width, Monitor.PixelsPerInch, PixelsPerInch),
       MulDiv(Height, Monitor.PixelsPerInch, PixelsPerInch));
@@ -2277,7 +2279,8 @@
 procedure TCustomForm.Show;
-  if Application.Scaled and Scaled and (Monitor.PixelsPerInch<>PixelsPerInch) then
+  if (Monitor.PixelsPerInch > 0) and Application.Scaled                    // DRB
+         and Scaled and (Monitor.PixelsPerInch<>PixelsPerInch) then
     AutoAdjustLayout(lapAutoAdjustForDPI, PixelsPerInch, Monitor.PixelsPerInch,
       Width, MulDiv(Width, Monitor.PixelsPerInch, PixelsPerInch));
36220.patch (1,634 bytes)   


2019-11-06 06:23

reporter   ~0119090

Next question is a technical, "best practice" one, maybe better suited to the forum ?
Function TGtk3WidgetSet.GetDeviceCaps() in uses deprecated functions gdk_screen_width() and gdk_screen_width_mm(). Similarly for the height functions.

These functions, while deprecated, do work in non Wayland systems at present. They could be replaced with somewhat more complicated code that I have tested that uses functions approved by Gnome. But neither approach returns valid data under Wayland. Do we want to replace the deprecated functions just because they are deprecated ?

If so, I will need to add new binding, sensible place would be in lcl/interfaces/gtk3/gtk3bindings/lazgtk3.pas however, it says in its header "This is an autogenerated unit using gobject introspection (gir2pascal). Do not Edit.". What ???

A number of other functions prototyped in lazgtk3.pas are also deprecated, they should be marked as such IMHO.

Third issue !
(sick of me yet ?) I have seen crashes on close in my simple form, maybe one in five times. But I cannot reproduce it now, Fedora just pushed out some updates, I wonder .....

Anton Kavalenka

2019-11-06 07:32

reporter   ~0119091

Spontaneous crash on exit should be considered not a bug but feature until proper order of ref() and unref() would be restored.
Looks like Widget deleted once by LCL then by GTK.

Juha Manninen

2019-11-06 22:45

developer   ~0119114

I applied both patches, thanks. I also decided to optimise David's code a little. Now Monitor.PixelsPerInch is read from widgetset only once / method.
David, please ask questions about GTK3 binding code from Zeljko using Lazarus mailing list. Include "Attention Zeljko" or something in the title. Mailing list is better than private mail because other people may also be interested.

A minor convenience issue: guys please create patches from the top level directory of Lazarus sources. Then I don't need to "cd path/to/modified/file" before applying it. As an extra bonus you can then include files from different directories in one patch.


2019-12-17 01:18

reporter   ~0119892

Are we going to see these merged into 2.0.8 ?

Juha Manninen

2019-12-17 19:36

developer   ~0119895

Ok, I added r62211 and r62212 to be merged.


2020-02-12 12:11

reporter   ~0121044

Last edited: 2020-02-14 10:01

View 2 revisions

on the Lazarus_2.0_fixes_Branch wiki page -
Merge conflicts
    r62212 LCL: Prevent an error when Monitor.PixelsPerInch=0 which may happen with GTK3 + Wayland. Issue 0036220. If this revision won't be merged, check if r62211 needs to be unmerged too.

meaning ?

As a by-note, my testing seems to indicate that its no longer needed, so, maybe thats the explanation. But trunk still has this code, does it happen sometimes that code goes directly to fixes, not via trunk ? Just curious .....

Issue History

Date Modified Username Field Change
2019-10-27 13:05 David New Issue
2019-10-27 17:52 Anton Kavalenka Note Added: 0118878
2019-10-27 23:23 David Note Added: 0118884
2019-10-27 23:24 David Note Edited: 0118884 View Revisions
2019-10-28 07:24 Anton Kavalenka Note Added: 0118886
2019-10-28 07:39 Anton Kavalenka Note Edited: 0118886 View Revisions
2019-10-28 07:40 Anton Kavalenka Note Edited: 0118886 View Revisions
2019-10-28 11:11 David Note Added: 0118894
2019-10-28 13:50 Anton Kavalenka Note Added: 0118896
2019-10-28 13:51 Anton Kavalenka Note Edited: 0118896 View Revisions
2019-10-28 14:06 Anton Kavalenka File Added: gtk3objects.diff
2019-10-28 14:06 Anton Kavalenka Note Added: 0118897
2019-10-29 01:13 David Note Added: 0118901
2019-10-29 01:56 David Note Edited: 0118901 View Revisions
2019-10-29 04:47 David Note Added: 0118904
2019-10-29 04:52 David Note Edited: 0118904 View Revisions
2019-10-29 06:32 Anton Kavalenka Note Added: 0118905
2019-10-29 06:33 Anton Kavalenka Note Edited: 0118905 View Revisions
2019-10-29 06:48 Anton Kavalenka Note Edited: 0118905 View Revisions
2019-10-29 07:07 David Note Added: 0118906
2019-10-29 07:17 David Note Added: 0118907
2019-10-29 12:38 Anton Kavalenka Note Added: 0118912
2019-10-29 22:52 David Note Added: 0118918
2019-10-29 23:07 David Note Edited: 0118918 View Revisions
2019-10-30 06:06 David Note Added: 0118921
2019-11-02 12:37 David Note Added: 0118975
2019-11-05 12:18 David Note Added: 0119068
2019-11-05 13:07 Juha Manninen Assigned To => Juha Manninen
2019-11-05 13:07 Juha Manninen Status new => assigned
2019-11-05 13:09 Juha Manninen Note Added: 0119072
2019-11-05 17:39 Anton Kavalenka Note Added: 0119077
2019-11-05 17:39 Anton Kavalenka Note Edited: 0119077 View Revisions
2019-11-05 17:40 Anton Kavalenka Note Edited: 0119077 View Revisions
2019-11-05 19:25 Juha Manninen Note Added: 0119081
2019-11-05 19:55 Anton Kavalenka Note Added: 0119082
2019-11-05 19:59 Anton Kavalenka Note Edited: 0119082 View Revisions
2019-11-05 20:02 Anton Kavalenka Note Edited: 0119082 View Revisions
2019-11-05 23:16 David Note Added: 0119083
2019-11-06 06:07 David File Added: 36220.patch
2019-11-06 06:07 David Note Added: 0119089
2019-11-06 06:23 David Note Added: 0119090
2019-11-06 07:32 Anton Kavalenka Note Added: 0119091
2019-11-06 22:45 Juha Manninen Status assigned => resolved
2019-11-06 22:45 Juha Manninen Resolution open => fixed
2019-11-06 22:45 Juha Manninen Fixed in Revision => r62211, r62212
2019-11-06 22:45 Juha Manninen LazTarget => -
2019-11-06 22:45 Juha Manninen Widgetset GTK 3 => GTK 3
2019-11-06 22:45 Juha Manninen Note Added: 0119114
2019-12-17 01:18 David Note Added: 0119892
2019-12-17 19:36 Juha Manninen Note Added: 0119895
2020-02-12 12:11 David Note Added: 0121044
2020-02-14 10:01 David Note Edited: 0121044 View Revisions