Tpanel became ugly in trunk?

[Josh]

i need to check over the weekend what has happened. Its odd commenting when i cant test i myself

I do not undersand using a groupbox as panel container, is the recommendation then if your going to target mac, not to use tpanel at all, and then have issues and additional overhead with other widget set implementation of a groupbox?

the idea is write once compile many using the underlaying nativewidgetset or custom qt, gtk etc. I would not expect an emulation of another widget set.

what was the issue with tpanel in the first place?

its worth noting that windows 11 you can now turn on/off rounded corners.

i would suggest a modeswitch, with it on by default
{$MODESWITCH macOSRoundedCorners+} 
{$MODESWITCH macOSRoundedCorners-}

that way it will operate as i would like it, but if i wanted emulation i could turn it off.

[Hansaplast]

I'll pretend to be patient so you can take a look in the weekend 😁
If I only knew how to get back to the working version with FPCUpDeluxe (I do not know what trunk version I should use) then I'd grab that one.


Well, I can see how one gets to "group" - "box". Just not how I am used to use it.
And yes, I'd assume not one Mac dev would want to use TPanel anymore.
Not sure what the issue was and like you said: AFAIK nobody complained about the old way with the proper look (rounded corners and such).

[Josh]

hi

i have on win system.
Lazarus 3.99 (rev c96908793d)
from 11sept 2023

not sure if that helps

[Hansaplast]

I'll give it a shot 😊  -- Thanks!

[Hansaplast]

Unfortunately that did not work - but that could also be because of my lack of experience with the weird Gitlab versioning.


Big thanks to Rich2014 for bringing back the old (rounded, flat, macOS look) TPanel!

[Hansaplast]

For those who are interested:
Rich2014 (thanks Rich!) took the effort to implement both views for Cocoa (he modified how borders appear/behave).
So in the Cocoa Widgetset you can have TPanel look like the old Windows 3.x panels and you can have them look the modern, more Mac appropriate, TPanels as seen in macOS.


See his post here in Bugtracker.


Basically, he made support for both 3d style and box style available (in Cocoa).
- Old window style (transparent background) when ParentBackground=true and color=clDefault
- New macOS NSBox style (opaque background): when ParentBackground=false


Just an idea: would it be desirable to have ParentBackground set to false by default for macOS?
I carefully assume that Mac developers want to see the Mac style, and it would not affect Windows or Linux users when code is compiled there.
Feed back is appreciated.

[rich2014]

@Josh,

hi,

In fact:

1. only TCocoaWidgetSet.Frame3d() chaned to be consistent with Win32

2. on MacOS, there is no corresponding control for TPanel.
the implementation of TPanel on Cocoa over the years is a transparent area with no appearance and is only responsible for Group management.
the so-called appearance is just a side effect of calling Frame3d() when processing the BevelInner and BevelOuter properties. the original implementation of Frame3d() calls NSBox to draw the border, but NSBox will force the background to be filled, which happens to give the user the feeling of a GroupBox without Caption.

IMPO:

1. the original intention of TPanel is to logically manage components in groups, while the meaning of TGroupBox includes both group management (Group) and appearance (Box).

2. the biggest problem with the original TPanel Style is that it forces the background color to be set, which mixes the two concepts of group management and appearance. Especially it is not friendly to nested TPanel.

3. if we want to manage by group and need visual effect, TGroupBox should be more appropriate. it's not a purely theoretical judgment, for Lazarus IDE and Double Commander, two GUI-heavy apps, they follow this rule, always use TGroupBox instead of TPanel when it needs visual grouping.

4. why we rely TPanel to produce the rounded corner effect on MacOS? it just because NSBox was used in Frame3d() to draw the border before. after using it for a long time, the side effect becomes a habit. we should actually use TGroupBox in this case.

However:
both styles supported on Cocoa now.

reading bugtracker, i do not understand why any MacOS Developer would want the tpanel to mimick a Win32 Panel.

adding an extra style would be poblematic, ie if you add a style bsNative for Cocoa, what happens when you x compile to Windows that Style is not defined.

I do not recall any user complaining that the old tpanel appearance was bad/faulty or ugly.

The change however seems to disprove the saying 'If it aint broke, don't fix it'.

As i cant chck anyhing yet, what does an nswindow look like, does it have rounded corners?

[Hansaplast]

For Cocoa only: would it be desirable to have ParentBackground set to false so the more modern rounded TPanel is used by default?
I carefully assume that Mac developers want to see the Mac style, and it would not affect Windows or Linux users when code is compiled there.
This should have no impact on Windows/Linux when re-compiling code on those platforms.



Any feedback/input is appreciated.

[wp]

For Cocoa only: would it be desirable to have ParentBackground set to false so the more modern rounded TPanel is used by default?

Cocoa only or not does not play a role if there is any chance that a project developed on a different platform would be ported to Mac.

A changed TPanel.ParentBackground property would break 90% of my applications in which panels are just used without any visual feedback (border turned off, no color change) in order to auto-arrange controls. Suppose the image viewer of the attached project: the form contains a client-aligned TShellListView and a left-aligned sidebar containing a TShellTreeview at the top and a TImage at the bottom. The treeview and the image fill the sidebar and adjust their size when the size of the from changes. The easiest way to achieve this is to add a left-aligned panel to the form; the treeview is added to the panel as client-aligned and the image is added as bottom-aligned. The Listview is added to the form directly as client-aligned.

If the sidebar would have a different color the application would appear to me as being damaged visually. The panel should not be distinguishable from the background. This is the default for Windows, and I am happy with it. If the default would change for Mac I would have problems porting this application to Mac.

[zeljko]

That's why I proposed TPanel property named something like ThemedPaint true/false, if true then it does not look ugly and it's painted by theme (so disables BevelInner & BevelOuter), if false it looks like it's desired when following delphi guidelines.

[Hansaplast]

Cocoa only or not does not play a role if there is any chance that a project developed on a different platform would be ported to Mac.

A changed TPanel.ParentBackground property would break 90% of my applications in which panels are just used without any visual feedback (border turned off, no color change) in order to auto-arrange controls. ...

If the sidebar would have a different color the application would appear to me as being damaged visually. The panel should not be distinguishable from the background. This is the default for Windows, and I am happy with it. If the default would change for Mac I would have problems porting this application to Mac.

I'm not sure what to look for - I compiled your example on my Mac and I do not see a difference when ParentBackground is false or true. Both look identical.
(I use TPanel for the same purpose at times as well)

[rich2014]

this is just because BevelInner/BevelOuter happens to be not set in this sample.

it does not mean that the ParentBackground should be changed arbitrarily.

I'm not sure what to look for - I compiled your example on my Mac and I do not see a difference when ParentBackground is false or true. Both look identical.
(I use TPanel for the same purpose at times as well)

[rich2014]

i completely agree with @wp, this was also the original intention of modifying Frame3d() at that time.

at the same time, in order to encourage TPanel to return to the original intention of managing components in groups, the current implementation is appropriate (TPanel should have no visual effects).

Cocoa only or not does not play a role if there is any chance that a project developed on a different platform would be ported to Mac.

A changed TPanel.ParentBackground property would break 90% of my applications in which panels are just used without any visual feedback (border turned off, no color change) in order to auto-arrange controls. Suppose the image viewer of the attached project: the form contains a client-aligned TShellListView and a left-aligned sidebar containing a TShellTreeview at the top and a TImage at the bottom. The treeview and the image fill the sidebar and adjust their size when the size of the from changes. The easiest way to achieve this is to add a left-aligned panel to the form; the treeview is added to the panel as client-aligned and the image is added as bottom-aligned. The Listview is added to the form directly as client-aligned.

If the sidebar would have a different color the application would appear to me as being damaged visually. The panel should not be distinguishable from the background. This is the default for Windows, and I am happy with it. If the default would change for Mac I would have problems porting this application to Mac.

[msintle]

at the same time, in order to encourage TPanel to return to the original intention of managing components in groups, the current implementation is appropriate (TPanel should have no visual effects).

This is a very noble view, but I'm afraid it does far more harm than good in production use.

You have to be very careful when making breaking changes that will affect all existing code out there.

No matter how noble your reasons may be, you don't want to create extra work for people; just for nobility's sake.

A breaking change means people have to go and edit hundreds of forms they've created previously, for absolutely no benefit at all.

Then imagine having to do this on a regular basis...for all good reasons on the surface, but ultimately, the road to hell is paved with good intentions.

This would become a maintenance nightmare for everyone involved. People would be spending all their time fixing code just to keep up with changes.

You can imagine this would start a revolt of sorts pretty soon. Nobody wants to have to keep dealing with stuff that's breaking constantly.

[MISV]

What is the state of this? What properties do I need to switch designtime/runtime to get old behavior?

I already have some code adjusting my Windows/Delphi forms to Mac/Lazarus at runtime, so it is okay if I need switch some properties.