A new IDE component for managing opened units in the source editor.
Has the following features:
1) Switch to desired editors by clicking on the unit lists. 2) Filter the list of opened units in the list and click to switch. 3) Click and drag the items in the unit list for arranging the order. 4) Close units by selecting, right-click and clicking "Close Selected Unit" context menu.
Hope it can be added to &LtPos;lazarus>/components
Mantis conversion info:
Mantis ID: 13930
Version: 0.9.27 (SVN)
Fixed in version: 0.9.29 (SVN)
Target version: 0.9.30
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
This is an IDE tool to help navigate between pages of source files in the
source editor. Since both IDE tools (editortoolbar and filebrowser) were in
lazarus/components, I thought maybe it should be there. But anywhere is fine
for me anyway.
I think the features are nice, but I don't know if an external package is required. I think those features should be built-in.
For example: In GTK1 and GTK2 you can right click on the editor Tabs and see a listing of all opened files. Simply selecting one in that popup menu will switch to that file. If this is not automatically supported in other widget sets, then I think it should be added to the LCL, as it is very handy. I often work with many files open and find the right click on tabs very useful.
As for reordering - this can also be done via right click on editor part, but I think a much more intuitive way will be to allow dragging the tabs left and right. I have seen this done in other applications (Firefox being one of them and it works on all platforms), so this must be possible in all Lazarus widget sets.
As for filtering, I can't really see the need for that. If you can find the opened files with a right click on the tabs and see a listing, then what's the point of filtering.
The other nice idea you have is a vertical display of files. Maybe the Lazarus editor can be improved to allow the tabs to be on any position (top, bottom, left or right). Currently Top is the only position. I sometimes think Left or Right is better, because you can see more tabs at once without requiring scrolling.
All the above would mean there is one less window being display at all times. In my setup I already have such a lot of windows open at once - adding yet another would not be feasible. Just my 0.02c worth. :-)
This tool was built during one of those period where the right-click list on the
tabs went missing in svn version.
Plus I always wanted some way to filter and reordered the opened files
(I almost always easily have more than 50 files opened,
you know.....Ctrl+Click, Alt+Up is so handy...until the list needs arrows to scroll slowly).
The missing tab-list was the final switch to make me dig in and just do it,
else I would have just reverted svn and continue bearing with it. ;-)
I know the feeling of building a package to solve a problem. I've done that myself.
I believe the missing tab-list was by accident. I quickly reverted to an older version when I noticed it was missing. I'm back on Trunk (yesterdays update) and the tab-list is working again. :-)
The think is, the features you added with your packages is things that should be standard. Like dragging tabs to re-order them. Or positioning tabs left or right of the editor instead of always Top.
PS:
If the external package has to stay (and not me merged with the IDE itself), then one additional feature. Register with the IDE, so the position of that window will be remembered. Every time I restart Lazarus, the new window is back at it's designed location and not where I left it last.
Its not as obvious as you think, I've tried it. The tab-control and the editor
list are 2 separate entities. The editor list is linked heavily to code tools,
and the tab-control is sort of like a remote-control.
Initially, I tried just reordering the page-indexes on the tab-control
(because its easier). Later I found out that my code-navigations are all
screwed as the underlying editor list order did not change accordingly,
and codetools follows the underlying editor list.
So even if the tabs are dragable, lots of work needs to be done beneath it.
I would have to spend a lot of time to comprehend how the whole source
editor and codetools work together. So, I did the next easiest thing,
by activating the menu-command by calculated number of times, to move
the editors.
As for positioning, I'll see what I can do. But I'll be mega-delighted
if you would merge it with the IDE. ;-))
About "easily have more than 50 files opened, you know.....Ctrl+Click, Alt+Up is so handy.":
Here is another handy short cut: Ctrl-F4
;)
An automatic close file feature would be nice. Some kind of garbage collection. Something like: if more files are open than fits into the tabs and there are files that were not used for x time, then close the least used.
About window position:
see for example ide/addtoprojectdlg.pas search for IDEDialogLayoutList.
About list as standard feature:
IMO the list is useful for any TPageControl that has no multi line tabs. It would be cool to have this as component in the lcl. Just drop the component on a form, connect it to a TPageControl and it adds itself to the popup menu.
OTOH windows supports multi line tabs. Maybe we should add an option to activate this for the source editor.
And yes, a d&d for tabs would be handy.
&LtPos;quote>
An automatic close file feature would be nice. Some kind of garbage collection. Something like: if more files are open than fits into the tabs and there are files that were not used for x time, then close the least used.
&LtPos;/quote>
Why not a feature to open codetool jumps in the same Editor (under certain conditions)
- Of course not it the file is edited
- probably not, if the file is in the current project
- certainly if the file is from a package (maybe an editor per package...)
- history would have to keep entries for no longer open files
But all those a considerations off topic to this bug
I would vote too, to integrate this feature, or an alike feature:
- "tabs on the left" + "drag and drop tabs" would help.
- Not sure about a filter, but it can be applied to tabs, if needed (maybe put in toolbar?)
I do not have write access to the Lazarus repository, so it's up to others if this package will be merged. But like I mentioned before, I think the features you implemented should be built-in, by extending the PageControl used by the editor etc...
Thanks for update 3. Positioning now works nicely. :-)
I know, I post this tool here just to share. It doesn't matter where it ends up.
And my perception of your "(and not me merged with the IDE itself)" is you
making it become a part of the source editor like your editor toolbar ;-)
About the built in part, I have a different opinion.
I believe most helper tools should come as packages.
The IDEIntf should expose as many parts of the IDE as possible, so that innovation can come in packages.
Reason: So that users have a choice to have an IDE that is as light or bloated as it fits their needs. A tool that helps someone may also be an annoyance to someone else. Hence packages helps respect those choices.
If I follow the mailing list correctly, Lazarus is going to have an online
repository of tools coming in fpPkg packages in future. And I'm excited about
this direction as the FPC/Lazarus ecosystem will be some sort like the linux
package systems that provides a choice to users to have a pascal toolchain that
can be as big or as small as they need it to be.
First about your tool, Funky:
I just tried it a few seconds and I think, it is quite a good idea. In big projects it happens often that you have a lot of open units and navigating might be quite difficult.
At my machine this window has a strange green color... I do not think it is supposed to be like this, isn't it?
And an idea for improvement: What do you think of placing the switch event in the MouseUp part? It is quite irritating that it switches the editor before dragging... Or is this neccessary because of the implementation of the movement of the editor tab in the tab bar?
Now about what has been discussed in this comments:
The garbage collection for editor tabs is a very good idea. It happens often to me that I trace functions or functionallities very deep in the lcl, resulting in a large amount of tabs. However, I think that the idea of one tab per package might not be a good solution, since this tracing sometimes even goes over package boundaries. And you should consider that packages which are currently open may be in editing, so that you should "allow" more tabs for this package than only one.
Sorry for this OT again... Maybe somebody want to post a new "bug" report for this?
Nevertheless, I think that the dragging in the editor tab bar is a neccessary and evident feature for an IDE with tab support. I only once implemented drag'n'drop in tabs, and that was with my own tab control under delphi..
As an addition I would place the opened file list posted here. Although it would be much handier if it would be dockable to the other IDE windows around... But that seems "to be implemented".
Well, I hope this was not too off topic in general. Just my thoughts.
Most of features are already implemented in the IDE. The remaining will not work with the current code. In any case please close this issue and open another one if requires with the remaining feature implementation if needed.