Hi,

I'm using the docked IDE. I'd like to have the following: packages open in a second, dedicated window.

At the moment, this cannot be achieved - or at least, I do not see how.

Currently it is possible is to dock all package windows in a separate window, and then save the desktop.

But that is not what I want, because then every time I open the IDE, these same packages are opened every time. I don't want that. I' like that whenever I open a package, it goes to a dedicated window.

Am I missing something, or is this something that is currently impossible ?

Michael.

Hello Michael,

you are right, a "package manager" window (or "package editor", call it what you want) that would host all open packages in a tabbed control is due a long time...

Ondrej

Either that or: A default target dock for window classes. I.e. all Package-Windows would share a class. And there would be a default dock site for that class.

Then all the "collection editors" that can open from the object inspector, they also could have a class, and a target dockside.

"Collection editors" - you mean e.g. the "Menu Editor"? The difference is that there is always 1 Menu Editor. So you have always 1 editor per collection. And they are all different. That also means that may need different dock site sizes.

With packages, you have an unlimited number of package windows and all are the same.

IMO packages should be handled like unit files - manage them in a "package editor" (with the difference that we don't need multiple package editors like we have source editors - that would be an overkill).

Ondrej

Ondrej Pokorny wrote

[...] >> you are right, a "package manager" window (or "package editor", call >> it what you want) that would host all open packages in a tabbed >> control is due a long time...

Indeed. Since the beginning of the anchor docked IDE.

He meant the TCollection editors, like column editor of grids or fields of a datasource.

But those editors do not share a common ancestor. So they must opt-in to a collections-window.

Also possible.
Keep in mind that a package can be open and modified (undo, disk changes).

Mattias

Yes.

But those editors do not share a common ancestor. So they must opt-in to a collections-window.

Ah, did not know that.

Because opt in will be very limited. As those can come from any 3rd party component/package

Could the OI recognise them, and add them to a list (not ideal, then the list needs to be searched each time a window opens...)

I do have (and want) quite often several package windows open, and next to each other.
- I have the screen space
- That way I don't need to switch tabs/windows/... But can straight go to click on whatever unit I need.

Though I don't use the docked IDE, so as long as that affects only the docked IDE it wont bother me (but of course there may be users that have that need and use the docked IDE)

Even in the undocked IDE, I have often well over 20 packages open - and that is just the project-specific packages.

There is no way I can arrange this on my screen, docked or not.

So a solution for this would really be higly appreciated.

No need to over-engineer or over-generalize it, a simple package manager window will do.

Packages are a corner stone of the IDE, they deserve this special treatment ;-)

Michael.

If that is on an "opt in/out base" ....

I was objecting to the "we don't need multiple package editors like we have source editors" part. (depending on interpretation)

* Ok to have just one package-mgr, ? IF
- Individual packages can opt out, and show in there own window as they do today
- If the remember they were opted out (either IDE global or per project / I don't care).
=> Thus, I can opt out the packages that I want to have individually, and once I have done that I never need to do it again.

Though if they do remember per project, then lets fix that re-open packages does sometimes fail, when the IDE restarts with an empty project. And it is not later done when the project needing the packages is opened.

It makes no sense to have this on a per project basis. Packages are meant to be shared between projects almost by definition.

I use project groups and switch often between projects, it would be very annoying to see a package popping in and out of the package manager window just because I got annoyed at having to configure it for every project.

Besides that, packages should be 'first class citizens' in the IDE, and not depend on projects.

=> Thus, I can opt out the packages that I want to have individually, and once I have done that I never need to do it again.

Fine by me. If it is a 'per package' setting, then it should be easy, it can be stored in the .lpk

Though if they do remember per project, then lets fix that re-open packages does sometimes fail, when the IDE restarts with an empty project. And it is not later done when the project needing the packages is opened.

As said, I don't think that would make any think 2 settings to control the behaviour are sufficient:
- Use package manager window or not. Stored globally.
- Individual packages can opt out. Stored on a per package basis.

if later on it turns out more options are needed, it can be debated. But IMO we'll get already a long way with the above 2.

The "KISS" principle is a useful guideline in software development :-)

Michael.

The opt-in was for the collection editors.

Package editors are all the same and independent of the project. E.g. a package editor stays open when switching to another project.

Mattias

IMO this is exactly the over-engineering we (ok maybe I :) ) don't need/want...

Just one package manager with all open packages in it and the thing is done. Everything else brings just a headache...

... OK if absolutely necessary then one "package manager class" with multiple window instances and the user can decide in what package manager window the package is opened. So basically the same what the "source editor" does. But IMO it brings just an unnecessary complexity... I have never used multiple editors either... I can't imagine that I need to see two or more different

The lpk is stored in git. That setting sounds user specific and should go to the desktop settings.

> Though if they do remember per project, then lets fix that re-open > packages does sometimes fail, when the IDE restarts with an empty > project.

What do you mean with re-open package sometimes fail? Is there some bug?

[...] I think 2 settings to control the behaviour are sufficient: - Use package manager window or not. Stored globally. - Individual packages can opt out. Stored on a per package basis.

Sounds reasonable.
For a docked IDE, the "opt-out" option is basically undocking.

[...]

Mattias

As I said, either is fine by me. I only mention it, because the IDE (every once in a while), when I restart it, and as far as I can tell based on the project that gets opened, simply does not reopen the packages that were open.

So either there is some bug that aborts the loader, or there is some dependency on the project. Whatever it is is, I wouldn't want it to get worse (I.e. any "opt out of docking to mgr" to be forgotten when some projects are opened).

Otherwise, I do agree. IDE global makes a lot more sense.

That would already be helping me.

If the package window manager was an IDE add on package, then we could extend the mechanism used by docked-form and anchor-dock => where a package can be installed but entirely, ignored.
Then it would
- always be installed.
- might be enabled by default.

I can switch it off.
I don't wont to uninstall it, because that will be less tested, and I will have a potentially less stable IDE (over time)

- Individual packages can opt out. Stored on a per package basis.

IMHO a real valuable option.

I would most likely use that.
Usually I have 3 to 5 packages that are part of my workload. They should be undocked for easy and quick access.
Any other package that I open (well they rarely stay open, so very rare for more than one such additional package to be open)? can be in the pkg-mgr.

It all depends, on first view, the pkg mgr sounds just like a dedicate docking for package windows (like we once had the "message window docking".

So unless the pck-mgr also refines the interface, then it really is just a pre-determined dockside for package windows (i.e. when they were never docked anywhere, then they will be docked there).

Of course the pkg-mgr would also work if you use an IDE without anchor docking. So that be fine. Bit of re-inventing the wheel, but wouldn't need the drag and drop docking.
=> though I can almost guarantee, users will want to be able to sort the tabs (like you can in the source edit, but just use the extended notebook and that is solved)

Or just one pkg mgr, and free floating package windows. I.e. keep the existing functionality.

And just set a parent on the package editor windows if they are in the mgr. => or move the design of the package-windows into a frame, that then can either be instantiated in the window or the manager.

I have never used multiple editors either... I can't imagine that I need to see two or more different usually have 3 source windows open.? (the fit nice, side by side on my

main screen / and all other IDE windows are on my other screens) In extreme case more. I think I had up to 7 or 8 at some time.

The extra ones then are mostly very small and just show a single proc or declaration (maybe 10 to 15 lines max).
The editors have a "lock" feature, which means codetools and search-results will not scroll those editors, so they don't accidentally get scrolled.

If it is possible to hook-in into the package window creation and set the parent to the new PackageManager (or not if the package should be stand-alone), then it would be definitely possible and probably not that difficult either. Maybe even the simplest solution if it doesn't clash with desktops and AnchorDocking and if it plays well with all the Widgetsets.

Ondrej

Also fine, as long as it is global.

If nothing else, I always try to be reasonable... ;-)

Michael.

That probably is the wrong question...

The "smart answer" is: Yes of course.

The serious answer is: It has to be. Because even if it was non-opt-out => you must redirect all package windows into the manager. So you need to stop and change their creation in any case.
If you know where to do that (and sorry, I don't) then adding the option is probably the least issue.

Btw, that code has base classes in the IDE interface. So that means once you know where to place your hooks, you can probably add them to the IDEintf without to much extra work. And, then that answers what your question should have been:
?? If it is possible to hook them from outside the IDE code itself.

Also some of the base classes have shared stuff for package windows and project inspector. => So it may be possible to have an opt in for the project inspector to go into the manager.
Doesn't have to be done, but might be an idea to keep the idea in mind, as to not block any road that could be kept open with minimal effort.

----------------

But anyway, another consideration (though not for me / but for anchordock users)

There is a difference in having a "default dock site" and having the manager.

- If there are other windows in that default dock side, then you can have tabs for e.g. "code explorer" and 4 packages => all on the same level.
- With the manager, you have 2 tabs:? "code explorer" and "manager" (which then has nested tabs).

Both has pro and con...
And yes, with the mgr, the user can still undock, and dock manually to the anchor side.

Just thought to mention it before anything gets set in stone (or whatever material we use nowadays in an SSD).

Just want to clarify the terminology before it's too late.

"Package Manager" is easily confused with "Online Package Manager" and the "Install/Uninstall Packages" dialogs. It needs to be somehow emphasized in future code and GUI that this is about "Package EDITOR" and not managing the list of installed packages in the IDE. ?
Perhaps a "Notebook" or something else, or at least "Package Editor Manager"... -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20250806/883746ce/attachment.htm>

Well, first I thought the simplest way would be to rewrite the package editor window so that only one instance is allowed, add a PageControl in it and open all packages within it => that means hardcode it in the IDE.

I have to admit that it does not allow the user to modify the behavior and open packages in different windows (unless you allow multiple window instances and move packages between them). And I see that you don't like it.

Just to mention: Delphi got rid of the package window completely. Packages are managed/edited like projects in the "Projects" tree view. I have never missed the package window in Delphi.

The AnchorDocking already has to hook into the window creation/placement. So the mechanism is already there. You just have to make sure that the "DockedPackageManager" takes the window before AnchorDocking.

Ondrej

This seems like a much better goal than messing around with a new package editor window. Just treat packages like projects.

Doug C.

---- On Thu, 07 Aug 2025 03:15:50 -0400 Ondrej Pokorny via lazarus wrote ---

Just to mention: Delphi got rid of the package window completely. Packages are managed/edited like projects in the "Projects" tree view. I have never missed the package window in Delphi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20250807/96574def/attachment-0001.htm>

DougC wrote

This seems like a much better goal than messing around with a new package editor window. Just treat packages like projects.

The "Project group" window can host packages as well. It allows simple tasks (e.g. compile the package). Another approach would be to extend its functionality.

On the other hand I still don't like the current approach of unlimited package windows...

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20250807/2d8f884b/attachment.htm>

Ondrej Pokorny wrote

On 07.08.2025 09:22, DougC via lazarus wrote: > This seems like a much better goal than messing around with a new package > editor window. Just treat packages like projects.

I have been advocating this since years.

(probably to the great annoyance of some lazarus devs :/ )

The "Project group" window can host packages as well. It allows simple tasks (e.g. compile the package). Another approach would be to extend its functionality.

I think this would not solve the problem of opening the package in a separate window. The 'Project group' window just makes various packages/projects/files accessible in one grouped window. They will still open in separate windows.

On the other hand I still don't like the current approach of unlimited package windows...

That is my main problem and the reason why I started this thread. 20+ packages cluttered all over the desktop...

Your solution of putting them all in a tabbed window seems the correct and simplest solution to me.

You can simply open a new such window in case a package has opted out or the global setting for 'opting' out is set...

Michael.

Yeah, it's hard. Everything has to be backwards-compatible (except the LCLTaskDialog), everybody needs their option to keep the IDE how he has used it for the last 20 years. Everybody wants to open their projects and forms in every stable version from 20 years ago...

I am quite happy that I don't do any LCL projects anymore and switched to web with pure FPC and Pas2JS :)

Ondrej

I know, I use that as launch pad for the packages windows (for selected packages). Depending on what project I am on, I can quickly launch the required packages. and then have them open.

Ondrej Pokorny wrote

Just to mention: Delphi got rid of the package window completely. Packages are managed/edited like projects in the "Projects" tree view. I have never missed the package window in Delphi.

But, do they still offer a floating IDE? Or are they generally docked?

Docking an unlimited amount of windows becomes tedious, which in part is what started this.

But, for multi-screen users docking isn't always the best. => well you can have several dock sides. But I don't like the extra space for docksite-handles, and if I hide them I can no longer change layounts when I need to (and I do need to).

Well, having several "package dock sites" would work for me too, as long as
- I can have 4 or 5 of them, that each contain a single package
- behave more or less like the current package editor
- ideally allow to hide the unnecessary single tab (but I could live with it visible, if needs must)

I would just guess that having several such window, aka several groups, is the most complex solution.

I.e. having 2 states
- package is in manager
- package is not in manager
is just a boolean simple flag.

having several managers means
- each package must know its manager (ok instead of boolean, store a number)
- each manager must remember its position
=>? loading may open manager in a different order that their numeric sequence, but each package must be must be mapped into the correct manager (not by number, but by where it was positioned on the screen).

That makes it some extra work. (At least I think it will).

Ondrej Pokorny wrote

The AnchorDocking already has to hook into the window creation/placement. So the mechanism is already there. You just have to make sure that the "DockedPackageManager" takes the window before AnchorDocking.

Then the real question is => do we need to support this without anchordocking.

Because if this needs to only work with anchordcok, then just put a hook there, and any package that does not have config from a previous open get caught by that hook, and opened in a designated default anchordock-site.

All you need is to allow the user to select that designated site.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20250807/db96a528/attachment-0001.htm>

And the irony is (if my info is correct), Michaels request is exactly because of "old projects" and/or "old workflows". Just not workflows established in Lazarus, workflows established in other IDE/Editors, that now need to be available in Lazarus too.
And that is ok.? On the positive site, he added quite a few fine extras to the IDE.

And other users from coming from other tools, have in the past ask for this and that, and some of it was useful and added.

But, if we nicely support those coming from other software, it would be a real strange deal to withdraw support for those coming from older Lazarus versions, wouldn't it be?

As I experience it, the request to treat packages on the same footing as projects is not due to old workflows, but because I work really a lot on packages ?

I simply do not see the need to have a project in order to compile a package. In my view, a package is a compile target like any other.

I experience the IDE really as "project centric" . My proposal is to make it 'compile target centric'.

Meaning that 'Ctrl-F9' builds whatever the current compile target is, whether that is a package or project (or even a single file...)

Sure, I'm the first to say that backward compatibility is important.

It's worth to repeat:

I think lazarus is the best pascal editor available. It beats VSCode and Delphi hands down. This does not exclude that I think there is still room for improvement...

Michael.

Yeah, but that means to include the "Project groups" into the IDE (not as a standalone package) and get rid of the "Project inspector" and all the package windows.

Then we would have basically what Delphi has.

Yes, I do like it :)

Yes, backward compatibility is a no-brainer. But some Lazarus developers demand forward compatibility as well (=open and compile a Lazarus 4.0 project in Lazarus 2.0).

Ondrej

Michael Van Canneyt wrote

I simply do not see the need to have a project in order to compile a package. In my view, a package is a compile target like any other.

I do agree. (though a bit off topic here)

Given that one of the bigger reasons for packages is that they can be used (shared) in many projects, they should be possible to be developed on their own.

In my opinion (and not as part of the answer to your above statement), they should have a testcase. Always. And then that could be used. But, it is not the "job" of the IDE to enforce that (by cutting short other options).

But then, if you work on a package like that (with or without an other project open) then you still have dependent packages and the same amount of packages open (only one project that is then not open).

However even if you can open a package as a project, and even if we drop "only one project", and allow several projects to be open at the same time => there needs to be one active project. (even if that could dynamically change)
Codetool may need that for looking up dependencies and defines Run needs to know which project
....

And even if we do BOTH
- treat packages as projects
- allow several open projects
=> They can still all have separate windows.

So all that is a different topic

That really is a matter of having rules how to dynamically change that. E.g. a unit can be in many projects. Even in several packages.

But even if a unit is in only one packages, you still have to targets: the package and the unit itself.

Also IMHO compile targets can be part of projects.

Its just about sorting out all the different concepts and having them nicely co exist.
This may need to introduce the term "active project" as what the IDE currently uses to determine what to do. "Active project" does not need to be a "LPI Project". It just needs to provide for
- what to compile
- where to find units for codetools
- what settings/defines/etc to assume (again codetool needs that / maybe other IDE parts too)

Then there are
- projects (potentially multiple open / one active) ?? potentially different project types
- package as active project
- build modes
- compile targets

The problem with compile targets though is, that they need to be provided by the "active project" => as the container telling the IDE how to find them or what they are.
Even if the "active project" just says: look at all open entities and find everything that could be compiled.
And we totally ignore the need to resolve ambiguity of the "current compile target"
You still need to have that project open, so other people can have projects open that have more specific targets. Otherwise you take the option of having any project away.

But well, if you add the concept of new project classes, then those can provide any "project less" feeling you like. You just keep the dummy "no project" open forever, and work with any other concept provided within that project.
Alternative you could add "work modes" to the IDE, and select them like currently you can select anchor docking.

Actually, no it does not require that.

It requires to make the IDE more modular, so you can hook more of its frontend (e.g I started moving the debugger GUI, and one day there maybe an INTF that allows to register a completely different set of debugger windows). The same could be done for the project and build control.e

You can already create a new "run" menu entry in an installable package. But it would be additional instead of a replacement. But allowing such replacements would be possible.

I am strongly against pulling more into the IDE. The fact that it is a big "all in one" pool already causes issues, because lazbuild needs to be nogui, and we had a hard time getting rid of some workaround IFDEF.

The IDE really should become more and more packages in ide/packages. => added bonus, those then can also have testcase, which really should exist.

Well, if Lazarus gets rid of the project inspector and all the package windows then it is exactly the opposite - making the IDE lighter.

Ondrej

Ondrej Pokorny wrote

Well, if Lazarus gets rid of the project inspector and all the package windows then it is exactly the opposite - making the IDE lighter.

Missing the sarcasm smiley?

No, dead serious. As I wrote before - Delphi doesn't have these windows either. If you get rid of something, then is is lighter, isn't it?

What we have now currently and what we are discussing is taking Lazarus as it is now for granted and add more and more features on top of it (new docked PackageManager / new docked sites for AnchorDocking / extend the add-on package Project Groups / ...).

With the Delphi approach you make everything simpler.

Ondrej

It was an open question, so I fully accept that there is a "yes".

Then, IMHO, any solution, as long as their is an option for the current behaviour.

Martin Frb wrote

Then, IMHO, any solution, as long as their is an option for the current behaviour.

Exactly this philosophy makes the IDE bulky and "pulling more into the IDE" and making it a big "all in one" pool. Because the IDE has to serve us all...

Ondrej

Ondrej Pokorny via lazarus schrieb am Do.,
7. Aug. 2025, 12:35:

As long as the use case that a package might only have been opened temporarily is kept in mind and it doesn't become a persistently stored part of the project group unless desired (no matter if it's some kind of implicit package group or an explicitly opened one).

Cause that's how I mainly encounter packages, especially when making a new package known to the IDE (which involves opening it). Or if I need to fix something in a package of mine that my project uses, but that I don't really consider a *part* of my project (like the LCL).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20250808/3858f670/attachment.htm>

Currently IDE never automatically adds projects or packages to the project group. Although there is a button to "Add current project". I think that behaviour should be kept.

Since lazarus can open any known package at a click, the situation is different from delphi, there you cannot open dependency packages unless you navigate to it on the filesystem, unless the dependency is already in the project group...

I'm not sure what delphi does if you open a package file explicitly.

I seem to recall it replaces the project group with a new one with just the package you opened. If so, I don't think this behaviour should be copied in Lazarus.

That does imply that it will always be possible to have a 'floating' package.

Cause that's how I mainly encounter packages, especially when making a new package known to the IDE (which involves opening it). Or if I need to fix something in a package of mine that my project uses, but that I don't really consider a *part* of my project (like the LCL).

I agree totally that this would be counter-productive.

Michael.

Michael Van Canneyt via lazarus schrieb am
Fr., 8. Aug. 2025, 10:18:

I just wanted to make sure that people are aware of this considering the *idea* to get rid of the package manager windows completely and instead integrating them into the package groups.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20250808/3fbeadb3/attachment.htm>

It depends how you open it. It either adds the package to the project group and opens it or closes the PG and opens it in a new PG.

Yes, that is true.

Ondrej

An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20250808/2c2e973e/attachment.htm>