Hi,

I recently created report http://bugs.freepascal.org/view.php?id=19658

This was about panels that behave a little differently to panels in Lazarus Windows and Delphi. There were no comments or feedback request there so I decided to take a look

After some investigation it appeared that the problem was because GtkFrame was used. The problem with this widget is that one can't control the postion and painting in a small area two pixels around it. So every nested TPanel in GTK2 Lazarus smaller by 4 pixels that the parent no matter what (the consequences can be seen in the screenshots from Panel.zip). Looking at the code I also noticed that no special features of GtkFrame were used, all panel drawings take place inside paltform-independent part of LCL.

Trying to solve the problem, I ended up with the following replacement in the TGtk2WSCustomPanel.CreateHandle

{ -------- Before }

  Frame := gtk_frame_new(nil);
  gtk_frame_set_shadow_type(PGtkFrame(Frame),
    BorderStyleShadowMap[TCustomControl(AWinControl).BorderStyle]);

{ -------- After }

  Frame:=gtk_scrolled_window_new(nil, nil);
  gtk_scrolled_window_set_shadow_type(PGtkScrolledWindow(Frame),
    BorderStyleShadowMap[TCustomControl(AWinControl).BorderStyle]);
  gtk_scrolled_window_set_policy(PGtkScrolledWindow(Frame),
GTK_POLICY_NEVER, GTK_POLICY_NEVER);

After this change the problem project that looked identically (good) in Delphi and Win32 Lazarus and differently in GTK2 Lazarus (labels and panels at wrong positions) began to look consistent in linux.

So there are questions:
- Can this patch be applied? Apart from obvious testing and checking, there is also a compatibility problem. After this change, the forms people designed in linux can start to look a little different (or even greatly if the nesting level of panels is deep). But as I noted in the report, without this change it's difficult to synchronize forms "visually".
- Does using GtkFrame in LCL make sense at all? I did not look deeper, but at least quick search showed it was used several times.

Thanks,

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110701/c5f42081/attachment.html>

1.It's changed to GtkFrame with r31280
LCL GTK2: Make Panel.OnPaint work. Patch from August Klein, issue #19488

I don't like to use GtkScrolledWin in place of simple widget. Can it be changed to something else (like pure GtkWindow and then draw border if needed) ?

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110701/fb2ee1ad/attachment-0001.html>

2011/7/1 zeljko

Good news it was just half month ago, I see the post by August Klein (reporter)

| 2011-06-14 03:36
| I upload my proposed patch for this bug. It consists in rewriting of GTK2 Panel
| component. Now it
| uses a Frame (as Qt) instead of ScrolledWindow.
| It also fixes 0017662 and 0017775.

So at least not so many forms will be affected if the positioning is changing. The bad news is that three problems were fixed by moving from ScrollingWindow to Frame, now I suggest to fix another one by returning, not so much on my side :)
By the way, I tried to catch OnPaint for current (frame) control and failed, it did not fire.

I don't like to use GtkScrolledWin in place of simple widget. Can it be changed to something else (like pure GtkWindow and then draw border if needed) ?

I tried, but even access violation appeared, seems like GtkWindow is not intended to be used as a child

Hmm, the situation is still very complex...

Max

gtk_container_set_border_width(PGtkContainer(Frame), 0) here seems to make it better.

Henry

Actually, it doesn't make a difference. The thing that fooled me is that my panels on debian are bigger than yours on ubuntu.

Henry

That said, changing the frame to gtk_alignment_new(0, 0, 1, 1) seems to work for me. What does it look like on Ubuntu?

Henry

Henry, works correctly in Ubuntu, looks like a good candidate. At least it hasn't bad history of the scrolling control so maybe also fixes the same problems. But I still can not catch OnPaint from all 3 variants (Frame, Scrolling, Alignment) bevel-less or not. So I don't understand what was that fix (#19488) about.

Max

Thanks Henry, I haven't time to search if border can be setted up under gtk, but this can help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110701/58d8527b/attachment.html>

Max Vlasov wrote

On Fri, Jul 1, 2011 at 6:17 PM, Henry Vermaak

don't know ... maybe ask reporter of that issue and August.

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

The only problem here is that GtkAlignment has no "shadow" function so can't respond correctly to the BorderStyle property (both Frame and ScrollingWindow have). But I suppose in this case it can be just done with additional custom drawing.

Max