Issues related to docking packages are quite common. I plan to add separate?"Category::DockedFormEditor" and "Category::AnchorDockingDsgn" labels for the bug tracker. Any suggestions/objections? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260926/2bf64221/attachment.htm>

+1

What about:
- AnchorDocking as component in user apps
- The "AnchorDockingDsgn" may not convey to everyone that this is IDE only. Maybe Category::IdeAnchorDocking
- the LCL: There is also very basic docking in the LCL => included somewhere?
? (that only comes into focus if anchordocking is component (user apps) too)

And what about general bugs affecting the above?? E.g.
- a bug in AnchorSides might well affect AnchorDocking
- a bug in the LCL docking code might affect AnchorDocking

26.09.2026 10:47, Martin Frb via lazarus ?????:

Why not simply "Docking"? Not sure that it is worth to have multiple tags for this purpose.

I don't want to overcomplicate things, and too much differentiation won't be helpful for searching the bug tracker, and it will also complicate the assignment of labels.

If there are separate labels for "AnchorDocking" and "AnchorDockingDsgn", then before assigning a label, you will have to localize the error, which means creating a test project, and this is more difficult than testing in the IDE itself.?Moreover, the fix will likely be the ?same?. It's unnecessary work.

Therefore, I'd suggest simply using a single "AnchorDocking" label for both packages, since "Dsgn" is essentially just a small extension for integrating this same package into the IDE. It's logical that they are even located in the same shared folder. Details can be specified in the label description, indicating that it applies to both.

- The "AnchorDockingDsgn" may not convey to everyone that this is IDEonly. Maybe Category::IdeAnchorDocking

It is better to use the package name to maintain recognizability for users and avoid confusion. In any case, it is precisely this package that users have installed.?A label?description will help eliminate ambiguity with "Dsgn".

Theoretically, there could be an unlimited number of custom docking packages that utilize this LCL functionality ))

And what about general bugs affecting the above?? E.g. - a bug in AnchorSides might well affect AnchorDocking - a bug in the LCL docking code might affect AnchorDocking

If the correction requires an LCL, an LCL label must be assigned.

Of course, initially the label can be assigned based on the location of detection (docking package), and during the process of debugging and searching for causes it can be changed to another (LCL).

Why not simply "Docking"? Not sure that it is worth to have multiple tags for this purpose.

I think the difference between the "AnchorDocking[Dsgn]" and "DockedFormEditor" packages is significant enough to warrant separate labels. They have separate functionality and a separate code base. Consequently, developers might be experts in one but not the other, and they would need a specific label?for searching. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260927/59548187/attachment.htm>

I agree with "docked form" being separate => it does not actually provide dock/undock functions. It is more of an "embedded" editor.

On the AnchoreDockDsgn (IDE affecting issues): Does that then mean that the following issue would not be labeled with it?
https://gitlab.com/freepascal.org/lazarus/lazarus/-/work_items/39923

This does not happen in the IDE, only in user code. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260927/0249246e/attachment.htm>

I agree with "docked form" being separate => it does not actually provide dock/undock functions. It is more of an "embedded" editor.

OK, I?ve created the label and already assigned it to some issues.

To clarify: in my initial message, I proposed introducing two labels ??"AnchorDocking" and "AnchorDocking". However, after receiving feedback, I decided it would be better to stick with just one label: "AnchorDocking". It will apply to all cases (user applications and the IDE extension).

As I mentioned earlier, there isn't much point in separating them, and using a single label will make the assignment process simpler.?An explanation will be provided in the label's description. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260930/04971c1b/attachment.htm>

Ok, too: One AnchorDocking label to bind them all. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260930/3dbf2334/attachment.htm>