[Interest] Qt 5 and filesystem

[Jason H]

Well, Windows has always done that, but it is more obvious as of Vista. It used to display the path, but since Vista, they bread crumbs it and made the parts of the path drop downs. 

But still I love my left pane treeview. It has a different use case. It's fine to have a list and bread crumbs when you are only selecting a file. But you cannot drag-n-drop that way. With a left treeview you can expose the source or destination, and use t he main view to select the destination or source, respectively. The only other way would be to h have two parallel bread crumbs and list views (which isn't terrible - it's better than not being able to dnd at all)





________________________________
 From: Rick Stockton <rickstockton at reno-computerhelp.com>
To: "interest at qt-project.org" <interest at qt-project.org> 
Sent: Tuesday, January 8, 2013 1:26 PM
Subject: Re: [Interest] Qt 5 and filesystem
 
On 01/07/2013 11:58 PM, Mark wrote:
> On Mon, Jan 7, 2013 at 10:12 PM, Charley Bay <charleyb123 at gmail.com> wrote:
>> Mark sayeth:
>>> <snip>, KDE has a "little" (pun intended) thingy called
>>>
>>> "KIO". It's a very massive IO framework that has support for a lot of
>>> different filesystems. It's all working under Qt and is right now in
>>> the progress of being ported to a Qt only library (as in no other
>>> dependencies needed to run other then KIO + Qt). Lately i've been
>>> doing a lot of experimenting with KIO + QML. <snip>,
>>
>>> One big thing that you will also encounter when using QML + filesystem
>>> related stuff is the complete lack of trees! Right now there is no way
>>> to display a treeview in QML. And i don't mean through proxy stuff.
>>> Just using QML + imports. I am experimenting in that area as well to
>>> get a treeview working properly but that's kinda tricky. Qt should
>>> really try to improve a bit here and offer some default components
>>> that can display a tree like structure.
>>
>> On the "tree-view" ... after MUCH thinking (and experimentation), I'm pretty
>> close to concluding, "We don't need tree-views".
>>
>> At first I *wanted* them, but after much experimentation where a
>> "(List-)Model" may be a "property" of a higher-level thing (like an
>> item-within-a-model), I've decided that I don't need them (yet).  Further,
>> the specific domain of experimentation happens to be for
>> "file-system-type-things".
>>
>> As an example, here's a link to discussion about a number of
>> "file-system-viewer-things" (visualizing hard drive usage in this example),
>> where IMHO the "best-ones" don't use a "tree-view":
>>
>> <http://superuser.com/questions/8248/how-can-i-visualize-the-file-system-usage-on-windows>
>>
>> QML is so "visual" and "dynamic", that IMHO there are *much* better ways to
>> visualize stuff (like files) than through a tree-view.  Fundamentally, IMHO
>> tree-views are so incredibly "wasteful" regarding visual-real-estate.
>>
>> I concede "tree-views" may be necessary in some domains, but generally, I
>> think users hate them, and there are likely better ways to represent
>> information.  I assume the best reason in favor of tree-views is that they
>> are "familiar", although they seem to impose a "widget-like" historical
>> perspective that may be incompatible with new UI paradigms.
>>
>> --charley
>>
> Certainly a interesting point of view!
> I both agree and disagree with it.
>
> Agree: in terms of creating completely new gui's with the power of
> QML. Using that you can certainly come up with very interesting
> alternatives.
>
> Disagree: in todays desktop world a treeview - or lets put it
> differently, representing data in a tree - is not something you can
> "just" discard. Another reason is that having a tree like gui element
> is a lot more convenient than making the same using a bunch of
> listviews.
>
Within KDE, there is frequent use of "breadcrumb" lines in the UI. These
show the direct line of parents on a single line of text, rather than
wasting "big areas" by stuffing the view with unwanted "peers" of the
Parents. I think that it does a pretty good job of avoiding your
problem: For example, use the application launcher, in "Application
Launcher Style", and drill down into Applications->Games->Arcade Games.
Each item in that collection of games (which is somewhat "like" a
filename item) gets the entire width. To move back to parent branches
and the ultimate "root", you can click on parent or grandparent items in
the "breadcrumb", skipping over any lvels of branches which you don't
want to see.

Without some kind of treeview organization, you can end up with a
gigantic list. Think of the GNOME "All Applications" Screen, which is
sorted alphabetically: If you don't know exactly how to spell the name,
it is really hard to find what you want. And copy/paste, without SOME
indication of the tree structure, becomes difficult to manage.
_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130108/39eafc2d/attachment.html>