docked IDE and form caption

[Paolo]

@zeljko, do you open a ticket in the bugtracker ?

[Paolo]

added to bugtracker

https://gitlab.com/freepascal.org/lazarus/lazarus/-/work_items/42376

[dsiders]

Ok, then only title bar paint is missing, it can be painted with themes, also it's size must be taken into calculation.

It's not like there haven't been previous reports about the same thing... including the form not reporting the correct width and height. Right now it uses ClientWidth and ClientHeight. The non-client areas are not accounted for in the values at all.

[Martin_fr]

When the main form is shown its Title bar is not visible, is it normal beahviour ?

Well, short answer: Yes it is.

But, to trying to understand, what would be the benefit of showing it?
- Just seeing the name, as given in the Object inspector?
- Seeing the border buttons? (which need to be prevented from being clicked)
- Something else?

I feel the caption alone is of relatively low value? But if it is => would a "fake form header" be enough? Just have a bar on top, that prints the name?

As for the buttons, they may (or may not / depends on OS and possible even theme settings on the OS) look different from what they would in the running app. The reason being that the form in the docked designer is an embedded form (MDI style). That form must have the designer as parent, no way to avoid that. (btw, depending on your app's and IDE's manifest settings they may look different with the undocked designer too / afaik).

IIRC (big big IIRC) the form being parented also affects the main menu in the designer. => In 4.x you may have noted you cannot open entries from the main menu to select any of the items inside. (as you could with the undocked designer). In 4.99/5.0 that is "fixed". It doesn't show main menu that the system draws => it paints a fake that offers you all the functionality.
That only works at the very top of the designer. => if the window moves down to show its title bar, then that fix must be removed. (However a custom drawn title bar, can be done above that drawn menu). Of course each OS/Desktop may have a diff style, thaw would not be replicated...

Overall, it will either
- adjusting the offset to show the real form header, but remove the main menu fix and need to deal with the minimize buttons   
- require implementing a fake header (solves the button issue)
- other ideas?

I believe the main menu fix is more valuable, so option 1 is out.

[LeP]

- Something else?

Forms Icon ?

Maybe you don't give any impartance to this, but in my applications this is my "sign".

[Paolo]

LeP just anticipated my answer. The title bar if visibile gives a better view of final aspect.

@Martin, consider this just as a joke  , why show a button caption when it is in the Object Inspector ?

Anyway I'll try on delphi if it still works on my PC and see what it does.

PS: some windows version should show rounded corners.

At the end it is better, for me, disabile it, so no real issue.

[Martin_fr]

Well, yes, I have to out myself as one who does way more code, than GUI design. I have done a few forms, but usually the caption is either constant (then I don't need to care), more likely at least i18n, and sometimes set at runtime. In the last case a preview would not gain any info.

I do see for the floating designer, that the caption helps finding the correct design form (if working on more than one). But in the docked version that issue does not exist, since the source edit tab identifies the unit, and the IDE only supports one per unit.

So, I did paint the above (my) picture to get some feedback.

But, in that case, a "fake form title bar" would be enough? It could show the icon, the caption, and even dummy buttons for min/max-imize, close.
It wouldn't be identical to the final result, as each OS/Desktop differs for that. (but I don't know how close an embedded form actually get to that, if the embedded form title-bar was shown).

You can hack your docked designer, by finding were it gets the border measurements, and adjusts the outer (holding) window's size and scroll offset.... (but mind that this will break the menu bar)


Btw, strange then that no one minds the window decorations shown around a TFrame in the floating designer. => they don't exist in the final product.

But, joke aside, should the docked designer be kept as it for TFrames? I.e. For TFrames no window decoration's should be visible?


I don't know who will eventually work on the issue. So I don't know what will be done.

[Martin_fr]

Also, I just did a test on the undocked/floating designer.

Changing BorderStyle has no effect on the design form => So it could be said that the decorations shown are not the decoration of the form you are designing, but the decoration of the designer holding that form...
Well, implementation wise, I think that is not the case, but....

Also, yes, it does react to changes in BorderIcons (except the help icon), and the window icon.

[LeP]

I want to add somthing to this thread, like I think the things should works: although I don't use this tool very often, since Delphi's presentation during development is almost identical to the application's runtime; it's useful when you can't or don't want to run the application in the final device.

In Delphi you can use Live App (FIREUI APP) which allows you to project your FORM in development directly onto a device as if it were running (but it isn't).
I often use it for Android and Mac applications (sometimes even on Windows 10) because it allows you to view the screen exactly as if it were running on the device, but without installing or running anything.

It's supported on Windows and Mac, and (even though it's no longer available in the store) I also use it for Android.

In practice, while you're developing in your IDE, the form appears on the remote device as if it were running.

With Android, it's excellent because it allows you to see all the graphical nuances (text, size, usability) during construction.

[Martin_fr]

In Delphi you can use Live App (FIREUI APP) which allows you to project your FORM in development directly onto a device as if it were running (but it isn't).

From the description that isn't a designer feature (as in strictly part of the designer).

I take it it needs to run some "preview" app on the target (that preview app is however not re-crompiled, its a fixed binary, that gets loaded once, and then receives the form as lfm).

So basically an LFM viewer. (internally its similar to a stripped down designer, that then runs on the target and gets synced).

How does it work if you have your own custom components? E.g. if you have a component that draws itself directly on the canvas? Then that viewer must know about it? (I guess Delphi can solve that by compiling a load-able plugin of that component for the target, since Delphi can have shared binary plugins)

[LeP]

From the description that isn't a designer feature (as in strictly part of the designer).

Yes, you are right. Nothing to do with designer, it only an "view helper".

I take it it needs to run some "preview" app on the target (that preview app is however not re-crompiled, its a fixed binary, that gets loaded once, and then receives the form as lfm).

Yes, of course there is an app (with sources). You can recompile it for every platform supported: sure for Windows, Mac, Android, IOS but I don't know for Linux.

So basically an LFM viewer. (internally its similar to a stripped down designer, that then runs on the target and gets synced).

Yes

How does it work if you have your own custom components? E.g. if you have a component that draws itself directly on the canvas? Then that viewer must know about it? (I guess Delphi can solve that by compiling a load-able plugin of that component for the target, since Delphi can have shared binary plugins)

I'm not sure but I think that if you recompile the app with your actual environment ... all should be working.

The app only make drawing things and gesture, not elaboration. It cannot show something that at runtime will be inserted.

For sure is not perfect but is simple to use if you want to see in preview what you are doing. Like I told, the preview (during design) of Delphi is already wonderfull and very very near to real effects, that is something more to be certain that one is on the right path.

P.S.: I have added an Delphi design preview (for Android 5")

[n7800]

I'm a regular user of DockedFormEditor and find hiding the form caption very justified. It's a designer, not a preview, and displaying only the client area of the window is logical.

The discussion shows that the implementation really does create a lot of questions with little benefit. I'll even add another one: what if the "BorderStyle" property is set to "bsNone"? ))

If this is implemented, it should still be an option so users can choose. For example, I often work on a small monitor.

The IDE window title, IDE menu, component palette, Source Editor toolbar, Source Editor tabs, code/form tabs, form menu, status bar, Messages window - all of these steal vertical space. Subtract the taskbar height, and you're left with very little space on a laptop...

[Paolo]

I'm a regular user of DockedFormEditor and find hiding the form caption very justified. It's a designer, not a preview, and displaying only the client area of the window is logical.

For me see the icon, caption, bar color, form edges etc.. is useful, but in any case, I just disabled DockedFormEitor and I'am happy with floating forms, so no real issue.

[LeP]

If this is implemented, it should still be an option so users can choose. For example, I often work on a small monitor.
The IDE window title, IDE menu, component palette, Source Editor toolbar, Source Editor tabs, code/form tabs, form menu, status bar, Messages window - all of these steal vertical space. Subtract the taskbar height, and you're left with very little space on a laptop...

Of course, you are pretty right.

I used to works always with two monitors and when I works "outside" I always have a laptop with minimun a 17" screen since decades. Since last years I use 18" laptop.

I need to have maximum visibility for projects when I am on site, so more options are visbile better it is.