File Tree plugin and Kate in KDE SC 4.6

Hi! It’s me again. Got some exciting news.

The file tree is now the default (and only) document list/view widget. It actually took me by surprise. After I got the list mode and other features implemented, the old document list was unceremoniously ripped out, and extensions were added to allow kate to always load a given plugin, and give its settings tab a little more prominence.

Since then however I’ve fixed a few issues regarding the settings in the plugin. The file tree settings tab now sets the plugins global settings, and will clear out the setting overrides for the current session so they will get pulled from the global settings. And I just finished up adding back the “Go” menu, and the “next” and “prev” document shortcuts.

Just to be clear, you are NOT forced to use a tree view from now on. That is just the current default. You can switch to list mode using either the settings dialog (which will apply to kate globally, minus any sessions you have used the document view context menu to change the mode for), or using the context menu on the document view (file tree) widget.

Thank you to everyone who has used my plugin in the past, and to everyone who will be using it in the future :)

15 thoughts on “File Tree plugin and Kate in KDE SC 4.6”

  1. with the premise that File Tree is great, I’m unable to switch opened files with the Alt+{Left,Right} arrow, in old kate they are hooked to “Back” & “Forward” actions.
    This require to use the mouse way too often. There are workarounds? If there are not could be expected to have the function back in the future? Please please please.
    P.S. I’m using git at commit titled “fix port to CCCM3″ Oct 18 21:40:49
    cheers

    1. I commited the Go menu and alt-left/right actions to svn right before I posted this blog entry. You’re going to need to update ;) All of kate as well, I had to change a core kate ui file to get the go menu to show up where it used to be. Might need to wait for someone to merge these changes to the git repo as well.

  2. Actually the file tree browser needs some love (I’m still using 4.4 however): Make an option which not changes the tree root if you accidently click on a folder but instead just opens the subtree. In turn a right-click action on a folder should offer “make root”. This would make it much more comfortable (similar to the NERDTree plugin in vim).

    1. This doesn’t have anything to do with the File System Browser plugin, but a new plugin I developed a couple months ago. I don’t really have anything to do with the File System Browser. I think the new file tree might just be what you want.

  3. yay! I love the file tree :)
    only one issue: I preferred it when it showed just the folder name, instead of “/home/chani…asdf”
    it’s really hard to find stuff when every single top-level folder starts with “/home/chani…” and ends with only the last few characters of the folder name. It’s redundant too, because I’m never editing any file that’s *not* in /home/chani :P

    it might be a little less redundant if it started at wherever the folders diverge… but just showing the folder name would be cool too. :)

    1. Yeah, I’m not really happy with that either. Not sure what I’m going to change that to yet. Theres some code you can uncomment in the plugin that changes it to replace $HOME in any top level item with ~. It’s better at least.

  4. I love the new view! And I second Chani’s request :) All my code paths are /home/leo/kde/src/kdefoo/src/foobar.cpp which doesnt often get shown in the folder name :)

      1. Then revert it to what you had before: just show the folder name and not the entire path. We can fine-tune it still in the coming releases, so if it’s not perfect right from the start, it’s perfectly ok.

        1. I can still do that. Though it turns out it was relatively easy to support both, and obviously at least one person wanted it bad enough to hack it in. If you’d rather it not be available as an option in the settings dialog, it can be removed at any time. Default is “off”.

  5. Is it possible to re-add the option to sort the open documents in a “custom” order ? What would also be truly awesome would be to define custom “groups” that would contain arbitrary documents that you would organize by drag & drop for example, a sort of “virtual folders”.

    1. Technically it is possible to support something like that, but it would complicate the code quite a bit. The custom sort order was known to cause a lot of crashes in the old code. It would take some doing to get the grouping you suggest to work properly too.

  6. I like the document list. Thank you. But, can you please add the custom sort order? I really need it. Especially when I have 50 or so open files from many different folders and I need to group them based on some criteria.

Leave a Reply