[Interest] Qt 5 and filesystem

[Rick Stockton]

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.