[New Component] ExtTabCtrl - A custom, feature-rich tab control (LGPL)

[Antek]

Regarding the licensing issue on the first page of this thread:

Code: Pascal  [Select][+][-]

1. As far as I understand, it does, but I am not sure. In any case, it is my intention to allow it (maybe I will have to add also this exception).

quote from github repo (and ALLIGATOR):
Note for application developers:

Code: Pascal  [Select][+][-]

1. The LGPL explicitly allows this component to be linked into commercial,
2. proprietary, and closed-source applications without requiring
3. the source code of your overall application to be disclosed,
4. provided that modifications to the ExtTabCtrl library itself
5. remain open source under the LGPL.

LGPL 2.1 says 5.

Code: Pascal  [Select][+][-]

1. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

Seems you're right....BUT in LPGL 3.1 there I can't find something like the statement above...

So (LPGL 3.1) 4. Combined Works. applies and this means
you have to


...

d) Do one of the following:

Code: Pascal  [Select][+][-]

1.     0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

--> provide Source
OR

Code: Pascal  [Select][+][-]

1.     1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

--> provide a way that a user can change the LGPL library with another lib (providing same api/interface) that's why dll/so are used in most cases of lgpl libs

I think using the "lgpl with static linking exception" like lazarus does (most components?) would be "safer" (in terms of 'am I allowd to use this?')

[ovidio]

I have been busy with the code, and forgotten to update the note about the License. Now it reads:

ExtTabCtrl is licensed under the LGPL with the same linking exception as Free Pascal and Lazarus. This allows the component to be linked into commercial and closed-source applications without disclosing your overall application's source code. Only modifications made directly to the ExtTabCtrl library itself must remain open source under the LGPL.

I hope this will clarify the issue.

[d7_2_laz]

I have tried to make the color more subtle. It is hard to get a good balance, because the color is different on macOS and on Windows. What do you think of this color?

Yes, i find it more pleasing now! - but maybe just because it's very subtle now. Matter of taste.
Basically i'd agree to the points mentioned by wp. At least in long term range it would be better an app could access the property. Not urgent.

[jianwt]

Thank you for your excellent control. However, I found that on UOS Linux 64-bit system, when the tab name is as long as shown in the image below, it overlaps with the close icon (X). You should consider the issue of the spacing between the character length of the tab name and the close icon.

[d7_2_laz]

maybe a bit difficult to see, at least on my monitor. Maybe blending factor 0.2 or 0.25

Agree. There's even a noticeable difference when applying style 'tsBbutton' vs. style 'tsChrome' -> in the latter it might easily appear that passive tabs actually flow into one another (no distinction between).
So, why not tsChrome: blending factor 3, the others: 0.2 or 0.25 as a short term solution?

[ovidio]

- That tabs may appear truncated is by nature. If they should appear if that doesn't make sense (because one cannot identiy anything on the tab), or if there maybe measures against, might be a question. I would it let as it is, but only to mention this little aspect.

I have implemented this, but it is a little weird to me. I find strange that there is an empty space (which suggests that there are no more tabs) and then a scroll button (suggesting that there are indeed more tabs). What do you think?

[ovidio]

Thank you for your excellent control. However, I found that on UOS Linux 64-bit system, when the tab name is as long as shown in the image below, it overlaps with the close icon (X). You should consider the issue of the spacing between the character length of the tab name and the close icon.

Thank you for testing. I have checked the code, and everything seems to be OK. Are you using GTK3? There is a known bug (see previous messages) in GTK3 returning the wrong text width.

[ovidio]

Agree. There's even a noticeable difference when applying style 'tsBbutton' vs. style 'tsChrome' -> in the latter it might easily appear that passive tabs actually flow into one another (no distinction between).
So, why not tsChrome: blending factor 3, the others: 0.2 or 0.25 as a short term solution?

Ok, I think that the easier thing is to just let the user define the border color. I will do it Tomorrow.

[d7_2_laz]

Agree. There's even a noticeable difference when applying style 'tsBbutton' vs. style 'tsChrome' -> in the latter it might easily appear that passive tabs actually flow into one another (no distinction between).
So, why not tsChrome: blending factor 3, the others: 0.2 or 0.25 as a short term solution?

Ok, I think that the easier thing is to just let the user define the border color. I will do it Tomorrow.

That's the best solution imo - e.g. imagine one uses OnTabDraw - and cannot select a wished tab color only because it might not contrast enough from a predefined border color.

- That tabs may appear truncated is by nature. If they should appear if that doesn't make sense (because one cannot identiy anything on the tab), or if there maybe measures against, might be a question. I would it let as it is, but only to mention this little aspect.

I have implemented this, but it is a little weird to me. I find strange that there is an empty space (which suggests that there are no more tabs) and then a scroll button (suggesting that there are indeed more tabs). What do you think?

I think just the same, absolutely (would look misleading)!  So i mentioned the topic somehow cautious. Similar is valid for other approaches, e.g. shifting an extremely truncated tab fully into view (only for eventually to see that now the same happens on the opposite side). Therefore i wouldn't change it but simply keep it a bit in mind for the case that a good idea sometime may come up.

More important here imo would be: to give the scroll-right button a bit more space/indentation for to avoid occasionally wrong clicks.

[wp]

I found that on UOS Linux 64-bit system, when the tab name is as long as shown in the image below, it overlaps with the close icon (X).

Is this because you use a bold title for the selected tab? What happens when you keep normal font? Bold text is wider than normal text - ovidio, maybe we simply should update the tab layout whenever a new tab is selected?

[jianwt]

I found that on UOS Linux 64-bit system, when the tab name is as long as shown in the image below, it overlaps with the close icon (X).

Is this because you use a bold title for the selected tab? What happens when you keep normal font? Bold text is wider than normal text - ovidio, maybe we simply should update the tab layout whenever a new tab is selected?

I am using FPC 3.2.2 with GTK2. I just ran the demo "demo_simple" without doing anything — just opened it. Note: do not maximize the window; the overlapping issue will not appear when maximized. Add two more tabs, then look back at the "Standalone" tab – you will see that the tab's label and the close icon partially overlap.

[ovidio]

I am using FPC 3.2.2 with GTK2. I just ran the demo "demo_simple" without doing anything — just opened it. Note: do not maximize the window; the overlapping issue will not appear when maximized. Add two more tabs, then look back at the "Standalone" tab – you will see that the tab's label and the close icon partially overlap.

Ok, thanks. I was able to reproduce the bug on Raspberry Pi OS. I believe that it is fixed now. Please, can you check it?

[ovidio]

That's the best solution imo - e.g. imagine one uses OnTabDraw - and cannot select a wished tab color only because it might not contrast enough from a predefined border color.

I have already implemented border color. Please, can you check that it works for you (it does for me)?

I think just the same, absolutely (would look misleading)!  So i mentioned the topic somehow cautious. Similar is valid for other approaches, e.g. shifting an extremely truncated tab fully into view (only for eventually to see that now the same happens on the opposite side). Therefore i wouldn't change it but simply keep it a bit in mind for the case that a good idea sometime may come up.

More important here imo would be: to give the scroll-right button a bit more space/indentation for to avoid occasionally wrong clicks.

I reverted this, and tried to make the scroll "smarter" (try to avoid cutting tabs unless there is no other choice). What do you think?

[d7_2_laz]

I have already implemented border color. Please, can you check that it works for you (it does for me)?

Great!  This gives much more place now for to apply individual design preferences
resp. to avoid possible design conflicts ... <story closed>

I reverted this, and tried to make the scroll "smarter" (try to avoid cutting tabs unless there is no other choice). What do you think?

Yes, it appears somehow more intuitive now i think. Certain noticeable truncations are unavoidable imo.
And the area for the "scroll-next" button is not so cramped that it invites accidental clicks!
I'd propose you leave it as it is now.

[d7_2_laz]

For interest i played again with the component (scrolling did improve well!) and during that i realized - again about the topic 'close-button keep color when changing modes' -, probably a bit late, that, in dark mode, for some (potentially good looking) tab colors a red cross  might not be the best choice (regarding contrast).
Ok, one now might created images for a custom imagelist; but only for a clRed color of the x-symbol that is manually drawn in the code?
Alternatively a color option for the manually drawn cross might be thinkable. Or a small user exit / event 'OnDrawCloseButton' within 'DrawCloseButton' (for someone who might want to draw his own shape). Is this thought felt rather to be exaggerated?

ButtonHints: don't know why, but i don't get them to work (OS: Windows). I did:

Code: Pascal  [Select][+][-]

1.       with ExtTabCtrl1 do begin
2.            ShowHint := True;
3.            ButtonHints.AddHint := 'Add a tab';
4.        // etc.

and when i hover the Add-Button, i see within exttabctrl.pas, TExtTabCtrl.MouseMove:

Code: Pascal  [Select][+][-]

1. // This line will only be reached when e.g. the mouse is a bit left of the Add button,
2. // but never when being directly above the Add button:
3.         if FBtnAdd.BoundsRect.Contains(Point(X, Y)) then
4. // A breakpoint here will never be reached:
5.            NewHint := FButtonHints.AddHint

A second little thing. There are 'hint text' properties for buttons, but, in a very general sense, the cross-'button' is also a kind of button.
When bringing the cursor in the hint-position abve the cross, it actually tells the tab name. Alternatively it could tell 'Close this tab' or similar as default text.