[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: File Tree Plugin
From:       Thomas Fjellstrom <thomas () fjellstrom ! ca>
Date:       2010-08-30 18:08:01
Message-ID: 201008301208.01771.thomas () fjellstrom ! ca
[Download RAW message or body]

On August 30, 2010, Dominik Haumann wrote:
> Hi Thomas,
> 
> this is kind of a wishlist for the file tree plugin. It would be great if
> you (or other developers) would implement it :)
> 
> 
> wishes:
> - context menu on document: "Close Document"
> - context menu on folder: "Close Document Group" or similar
> - as Christoph already mentioned, implement the file shading
> - "Show Active" toolbar button. Imo, the usefulnes to this button is
>   limited, especially since it does not raise the tool view if the
>   tool view is hidden and you click this button. There is also a quick
>   document switch plugin that could be integrated here. Or maybe even
>   better: KDevelop also has a quick switch plugin. Maybe consider getting
>   the best out of all those plugins? This certainly would be awesome!

Well there is a close option on files.. Is it not working?

> 
> bugs
> - the mapping is not always right. e.g. if you create a new session, then
>   1. open part/buffer/katetextblock.cpp
>   2. open part/README
>   3. close part/README
>   --> now the "part" folder is still there
> - more severe issues exist, but I did not find a way to reliabily reproduce
>   (e.g. the entire file list vanishes, or the mapping is even wrong)

Yeah, theres issues with the mapping. But I've never seen it (recently) not 
remove a folder it should remove.

But the entire list vanishes? Hmm. I guess I need to do some more testing. 
That should /not/ happen. It should only remove a dir node once its empty, and 
not before.

Though in your example, it should auto merge buffer under part when opening 
part/README, so part would stick around. Thats "normal". So youd have part -> 
buffer -> README  instead of buffer -> README.

I don't consider it worth the added complexity to auto un merge trees. Just 
how far would you go? say you open a bunch of files under several dirs deep for 
a project, and everything is neatly under a single "projectname" node. when 
you start closing files, it might end up un-merging to the point of ending up 
with the root item being "src" or something silly.

> 
> To be honest, if we get the bugs above fixed, I really consider removing
> the other Document list. The old Document list has some bugs, also
> included in the color shading which even lead to crashes for some users.
> Given that this file tree plugin automatically structures the files in a
> nice way, I think the manual sorting is not that important and probably
> can be dropped. This is just an idea, though ;)

Well there is a slight problem with the entire idea behind the tree, its hard 
to do intelligently. I tried to make the implementation as simple as I could, 
mostly because I have problems with complex algorithms ;) but also because the 
more complex it gets the harder it is to work with.

Right now if you open /home/user/foo/bar/baz/frob and then 
/home/user/foo/frob, its going to show two root folders in the list, one for 
baz, and the other for foo (respectively). That may not be what people want or 
expect. But if you try and recursively re-parent every dir on a new opened 
file, you may end up with a single root item for everything you open, and that 
item may be /home/user or even / in some cases. Which I'm pretty sure is not 
what anyone wants or expects. So my code only searches down one dir, with the 
thinking that you may open /home/user/project/foo/bar/frob and then 
/home/user/project/foo/frob, and want them to show up under a common root. 
Maybe not, but I think it is more common.

> 
> @Thomas: Finally, I'd like to ask you whether you can blog about it on our
> kate homepage (www.kate-editor.org). I'd immediately create an account for
> you!

Heh. I'm really not much for writing. I suppose I could write about it. But I 
guarantee it won't be a very active account.

> Greetings,
> Dominik
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel


-- 
Thomas Fjellstrom
thomas@fjellstrom.ca
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]