Highlight Parent Directory in Treemap Upon Mouse Hover (Was: Improving of the treemap mouse actions)

[sakkamade]

Good day. Here I am with a zoom issue again.

What I would like to see is the hover effects to be more noticeable. Here is what I have on my mind:

1. Simply hovering over the content of directory will outline it (on the current level)
   Because presently it is rather difficult to understand where one directory ends and another begins
2. Clicking, or double-clicking it (the highlighted directory) will move to it in the tree and zoom that directory on the treemap
3. Loop (look #1)

In short, I would love to have experience similar to what I had with GdMap in this regard, but with QDirStat.

[shundhammer]

One option is to enable the mouse hover instant details feedback (Menu Edit -> Configure QDirStat -> Rightmost tab General).

This is pretty much what you want, except that it shows you that information in the bottom status line, not in the tree view above.

Personally, I don't like that at all because (a) it's too nervously flickering at the edge of vision all the time and (b) if there is anything really important in that status line, it goes unnoticed because the stuff there is changing all the time anyway.

But if that's what you prefer, go for it.

[sakkamade]

Hmm. Yes, I saw that, and I don't really like it too, but it is not too much related, is it?

Please try to read the steps, I'll reword them if needed.

[shundhammer]

Doing the same amount of flickering in the tree view upon mouse hover is not an option.

The tree view and the treemap are only very loosely coupled - on purpose. They are two distinct views operating on the same in-memory set of data (the directory tree read from disk). They communicate over Qt slots and signals with a SelectionModel as the mediator: Both are connected to the SelectionModel and react to certain events; like selection changed or current item changed. This is the abstraction level they work with, and this is completely on purpose.

An event like current item changed originating from the treemap will make the tree view seek that item in the tree, open all its ancestors (parent, grandparent etc. up to the root item) and scroll the tree view so that new current item is guaranteed to be visible. It will also notify the Details Panel on the right side to update its information with that new current item.

This kind of abstraction level is what makes all that interoperability between the different views (tree view, treemap, details panel) possible in the first place.

What this not includes, as you may have noticed, is something like a selection light, something like "if you happen to be in the neighborhood, be so kind and highlight that item in the other view, too; if not, don't bother". Because that would be much too vague, and it would raise all kinds of questions and pathological situations.

[shundhammer]

Directory boundaries in the treemap are much easier to understand when you zoom the treemap to the level of that directory: Click it in the tree view and zoom in (easiest with the mouse wheel) as far as it will go. Then you are moving only inside that directory tree until you select something outside of it in the tree view.

The treemap is not really optimized for directory / subtree grouping. It does show that to some extent, but it's very limited; it's that very subtle shading that tries to group a directory or a subtree, but it's not much of a grouping hint.

This is also not what the treemap is really meant for; it is meant for showing the relation of files in a (literally) flattened hierarchy so they are easier to compare against each other. Of course, even that has limits since the shape is not always very square; the more elongated any tile of the treemap is, the harder it is to compare against another one. But that's also not what it's meant for; it's for a very rough comparison, not for details.

[shundhammer]

So, what exactly is your use case? What do you intend to do?

[sakkamade]

Hmm. Ah, I see. My bad. And if this is what I meant?

Simply hovering over the content of directory will outline it (the whole directory) (on the current level)

[shundhammer]

You mean highlight the current direct parent (in the tree view) of the treemap tile you are hovering over?

[sakkamade]

This is also not what the tree map is really meant for; it is meant for showing the relation of files

Yes, but would not it be easier to navigate through the them on treemap if the directories also were, somehow, shown (marked) too? This is what directories for, right?

[shundhammer]

This would basically mean introducing yet another kind of highlighting in the tree view - and without selecting that highlighted item or making it the current item; both would trigger changing the selected and/or the current item in the other attached views as well, including the treemap.

[shundhammer]

Let me think about this; but don't get your hopes too high. Right now I don't have any idea how to do that visually so it doesn't interfere with the other selections, how it would work well with the normal light and also a dark widget theme, how to not confuse users.

[sakkamade]

This would basically mean introducing yet another kind of highlighting in the tree view

The tree view has nothing to do with it until the "step 2", before that everything should happen on the treemap alone.

But I understand that the highlight on treemap is currenlty hardcoded with selected item in tree?

[sakkamade]

but don't get your hopes too high

Worry not, I never do. I am a mere user.

[shundhammer]

Also consider that the tree view may need scrolling if the parent directory of the currently selected tile is not currently visible; that would involve a lot of flickering and motion in the other half of the window which would probably be very distracting. If you move the mouse cursor wildly around the treemap, the tree view will go berserk.

[sakkamade]

Also consider that the tree view may need scrolling if the parent directory of the currently selected tile is not currently visible

Once again. I'd like for this highlight not to concern the tree at all. Not until I click on the directory in treemap.
And when I do click, what should appear in tree view is the directory itself, not the file of it (how it is presently). It can be divided with single and double clicks, i.e. single click will show (in tree) the directory, double click the file.

[sakkamade]

I understand that that is not how it works right now, not at all, however such is my suggestion.

[shundhammer]

Fundamentally changing the interaction with the treemap is out of the question; this would throw off all other users (negatively "surprising" them which is a user experience no-go), and it would be inconsistent in many ways. Any new interaction has to integrate nicely with the existing interactions, so it can only be an add-on, not a replacement.

A tile in the treemap basically (almost) always corresponds to a file. Only when there is "empty space", i.e. lots of very small files that are too small to be rendered, there are tiny bits of the underlying directory that are even accessible for a mouse click in the treemap. In that case, the directory is already selected in the tree view if you manage to click into that kind of empty space. But in most cases, there is no such empty space, so a directory is mostly unclickable in the treemap.

What you can already do, however, is click on the "Up" button (toolbar or menu Go -> Up one Level; key Alt Up) to select the parent directory.

[sakkamade]

Fundamentally changing the interaction with the treemap is out of the question; this would throw off all other users (negatively "surprising" them which is a user experience no-go), and it would be inconsistent in many ways.

However breaking these changes may appear to you now, as far as I see they should not affect the user who has no need in them too much, even if they would be enabled by default.

But let us begin with the point #1.

Outlining hovered directory in treemap:

1. This will provide user with better understanding on where the file is located
2. Will separate the rest of the files from the files encompassed by it, while ability to see them both still remains
3. I fail to see any downsides in some additional greenish, dotted, thin, etc. (different) outline, nor how can it seem to be inconsistent/inconvenient from user's point (how to implement it is another question)

I can easily see it as a part of "Use hover effect" option.

[shundhammer]

It goes far beyond that, but that will only become apparent when actually using this and seeing unexpected reactions in the other view, depending on the actual implementation. And of course this would be a completely separate hover option because users of the existing one might not welcome this change.

[sakkamade]

seeing unexpected reactions in the other view

Yes, but I talk only for myself here:

I can easily see it as a part of "Use hover effect" option.

---

And of course this would be a completely separate hover option

Yes, of course. Making it a separate option is better, and it always is.

But I would rather hear your very own opinion on this.

[sakkamade]

Now that I have some time I'll try to reply to the rest of your commentaries.

Directory boundaries in the tree map are much easier to understand when you zoom the tree map to the level of that directory: Click it in the tree view and zoom in (easiest with the mouse wheel) as far as it will go

But even in this case I must click/move to some directory/file before that.
And this cannot really be applied to what I would like to see. That is, the mouse actions on treemap.

Right now I don't have any idea how to do that visually so it doesn't interfere with the other selections

I will attempt to describe it visually, then, taking the GdMap as an example:
(Graphical glitches are likely caused by dev. version of picom, don't mind them.)

dir-showcast.mp4

(The directories—or their absence—are marked with cyan, files are always marked with yellow.)

As you see above:

1. The double click here allows to zoom in the directory (just like qdirstat now); it has no tree, however, so the rest of my account on that part cannot be displayed here
2. The directories and files are highlighted by simple hover over them, whilst I would rather see it being only for directories

Only when there is "empty space", i.e. lots of very small files that are too small to be rendered, there are tiny bits of the underlying directory that are even accessible for a mouse click in the tree map

And even in this case, if the directory has subfolders, the parent may not be highlighted entirely.

---

To summarise, the features which needs to be implemented are following:

1. Hovering the treemap should display boundaries of directories on current level, and produce no changes in tree whatsoever
2. Single click on the treemap should zoom in the directory and highlight the parent directory in tree (the right mouse click should also apply to parent directory, not to the file within)
   2.1. Double click should be left as is

[shundhammer]

I watched your video (thank you for that), and I see what you mean.

But I find that highly disruptive because something is always flickering, and it's flickering all over that window: The currently selected tile (corresponding to a file) and its parent directory (sometimes? Always? Not sure if I picked up the pattern how that works).

And, worst of all IMHO, the status bar at the bottom - at the edge of vision. That is the most distracting part since the way human vision works is that peripheral vision is so sensitive to motion (going back to times when humans always had to be watchful for predators hunting them down) and little else; in particular, peripheral vision does not detect many details. That leads to your brain constantly shifting your focus from where you were actually looking (the mouse position) to the periphery (the status bar) where the motion was detected; only to have the conscious part of the brain move it back to the intellectual center of attention, the mouse position.

This is grossly irritating, and that's the reason why I don't like the old "mouse hover" behaviour in QDirStat (which some user begged for, and it was simple to implement).

Yet, without that kind of additional information, that parent directory highlighting loses most of its usefulness. In that implementation, I already find it borderline useful since it only tells you the directory base name, not the full path, so you have to guess what that upper line is at all, and where it fits into the directory hierarchy.

All in all, I find this really counterproductive; it's nervous, flickering, disruptive, and I don't see any benefit.

If you really want to know more information about any treemap tile, why not simply click it and get all the information in the Details panel, in the tree view, and in the Breadcrumbs widget (the path above the tree view where you can click on every path element to navigate)?

Do you really keep watching the treemap where your mouse cursor is, the position of the mouse cursor, and the status bar at the bottom with two lines of information at the same time? All that while you keep the mouse cursor moving across the treemap; with all the fine motor skills in your hand and the eye-hand coordination that this involves?

[shundhammer]

I can understand why they did it that way in GdMap: There is no connected other view where you could get more information from, neither details nor information about the hierarchy; so they didn't have many other options how to do that.

Other treemap -based disk analyzer tools like SequoiaView on Windows (that gave the inspiration to add a treemap to KDirStat, the QDirStat predecessor) behaved in similar ways; yet that was always their downfall since it's very limited what you can do with a treemap.

The success and popularity of KDirStat (and WinDirStat on Windows which is derived from it) and later QDirStat came from the combination of both types of view: A traditional tree view and a treemap. That was the breakthrough; this leverages the power of both types of view (and now QDirStat even has a third one, the Details panel which removes a lot of clutter from the tree view). Use each one to exploit their respective strengths.

This is what QDirstat is all about, what makes it powerful; yet doing without that kind of hectic and nervous flickering with every mouse movement.

[shundhammer]

So, all in all, thank you for this really interesting discussion and for your insights; but I don't want to go down this route with QDirStat for all the reasons I mentioned above.

This does not mean that any more discussion about this from your side is not welcome; feel free to add more thoughts and opinions here. But for the time being, the decision is made.

[sakkamade]

Yet, without that kind of additional information, that parent directory highlighting loses most of its usefulness.

No, I don't think so. No, actually yes, that is right. 😄
But this feature already exists in qdirstat, so I don't understand what you are trying to say here.

Do you really keep watching the treemap where your mouse cursor is, the position of the mouse cursor, and the status bar

Yes; and I would like not to see it here, not with files, only with directories.

If you really want to know more information about any treemap tile

I do not, and this is the reason exactly. What I want to know is where that tile is, I want to undestand which of other tiles are in the same directory―in the same place.

All in all, I find this really counterproductive; it's nervous, flickering, disruptive, and I don't see any benefit.

I don't understand why you are so fixated on status bar. I guess the problem is that we have too different number of directories and files within them.

---

I guess I may agree with you on most of the points.
But you have closed it rather prematurely, you should have simply told me that hover is no-go from the beginning, so not to waste our time dwelling on it.
And the title was as vague as possible, so as to find a middle ground, in case if developer would have been open to discussion, and I see you are.

feel free to add more thoughts and opionions here.

I certainly will.

[sakkamade]

For now, the only alternative I can suggest is the same behaviour as I described above (except for zoom in), which, however, would be triggered by middle click (or perhaps by single click of left mouse button).

How about it?

Directory boundaries in the tree map are much easier to understand when you zoom the tree map to the level of that directory: Click it in the tree view and zoom in (easiest with the mouse wheel) as far as it will go

But even in this case I must click/move to some directory/file before that.
And this cannot really be applied to what I would like to see. That is, the mouse actions on treemap.

And here, yes, you were absolutely right. But again, since it is so difficult to find where another directory beings, I did not click in the right place before.

[shundhammer]

Middle click... you mean like this? ;-)

https://github.com/shundhammer/qdirstat/blob/master/src/TreemapTile.cpp#L700-L703

Double-click left zooms in, double-click middle zooms out. That has always been there. ;-)

Or simply use the mouse wheel which is much easier.

[sakkamade]

double-click middle zooms out

Thankfully, I have never used the double middle click in my whole life.

By "the same behaviour as I described above", I meant following:

Hovering the treemap should display boundaries of directories on current level...

Though, in this case I would rather see this directory being highlighted in tree as well.

[shundhammer]

Maybe all is not lost yet; I have an idea.

To avoid that hectic flickering, such a "highlight the parent directory in the treemap" feature could use a slight delay; very much like tooltips do it. If the user moves the mouse cursor across the treemap, nothing would happen immediately; only after the delay the parent directory would be highlighted.

For highlighting, two versions come to my mind:

• Draw a narrow simple white (not colored!) frame around it. If that turns out to be indistinguishable from the border of uncategorized (i.e. grey) treemap tiles, that frame could use a dotted line which would make the distinction clearer.

• Use a dark overlay with an alpha channel, just like I did manually with Gimp for the screenshot in my first answer here. To avoid disruption, this would need to use an animation, so it would fade in gradually; which fortunately is very much possible with the QGraphicsView widget that the treemap view already uses. The general idea is to do that in a subtle way, not dragging the user's attention off the original focus.

• If the dark overlay works well, this could also outline the next few levels of directories on top of that, this time also with a thin frame around them.

• If that also works, there is the chance of even adding the full path of those higher-level directories in the treemap; probably with a very small font in the bottom right corner of that directory.

• Of course, all of that could be disabled by a single global setting in the config dialog.

• Maybe there should also be a toggle in the toolbar to switch it on and off on demand; we'll see.

So far, those are only crazy ideas; it might or might not work. But I'll give it a try to experiment with it as soon as time permits.

[shundhammer]

First experiments: Highlight the parents of the clicked-on tile upon middle mouse click.

This starts from the tile that you middle-clicked on upward (i.e. outward in the treemap). The direct parent is highlighted with a thicker (2 pixels) white outline, the grandparent, grand-grandparent etc. are outlined with a thin (1 pixel) white outline.

I tried first with a dotted line for the grandparent, grand-grandparent etc., but that is pretty drowned out by all the treemap colors.

This is currently in branch huha-ovl.

Right now there is nothing yet to clear the highlight; so far, this is just to demonstrate the outlining. Of course, it clears the previous white outlines when you middle-click on a tile that belongs to another directory.

More to come.

[shundhammer]

Please notice that since that is the nature of a treemap, the hierarchy level is always from innermost to outermost. Since the white highlights are by definition all in the same hierarchy from bottom to top, there are no ambiguities; even though it looks weird at first glance that the innermost white rectangles are all nicely nested within each other, the outermost one does not seem to be, but it actually is; only that it extends to the left instead all the others which extent to the right. But that is pure coincidence in this example.

[sakkamade]

This is nice!

Some commentaries:

1. Yes, I guess the white outline should be removed when I left click the file outside, but
   Wouldn't it work just as nice together with left mouse button, too? To show both white and red highlights?
2. When I middle click the item I would like to see the path of clicked directory in statusbar

A middle click is not at all discoverable;

So you are fine with it now?

[shundhammer]

Now it's beginning to take shape: The parents highlight is now removed when you click the left mouse button (selection) or the right one (context menu) on any tile outside of the highlighted directory.

It feels quite intuitive now; but it needs more testing.

[sakkamade]

Now when I click the file *within* the highlighted directory the white outline is also being removed, which is not so nice.

EDIT: What about this then?

Wouldn't it work just as nice together with left mouse button, too? To show both white and red highlights?

[shundhammer]

This is still work in progress; a lot might still change. Update and rebuild; clearing the highlight is now less drastic.

Time to go to bed for now; it's 1:30 a.m. around here (CEST / Germany).

[sakkamade]

EDIT: What about this then? [...]

This is still work in progress; a lot might still change.

I didn't expect you to implement that right away... I only asked your opinion.

[shundhammer]

I had attempted to give the middle mouse button the same selection capability as the left one, including Ctrl+click to add a tile to the selection instead of just replacing it. But so far, that didn't work at all; it clashed with implicit behavior of those mouse actions that is done somewhere deep inside Qt.

If that works, users who prefer to always get the parents outline could simply use the middle mouse button instead; but so far, it just does crazy things.

So far, this is all still in the experimental stage; I want to use it and play with it for some time so I can form an informed opinion what feels intuitive and what does not.

Simply always adding the white rectangles on a left click in addition to the red marker rectangle will probably feel intimidating to novice or casual users; the parents markers involve some learning curve or at least some explanations, and I am more and more convinced that very few users bother to read documentation anymore these days.

To get them to read anything, it would probably require to feed them one tidbit of information at a time (no longer than a tweet, i.e. no more than 160 characters); like some built-in "tips" that appear at appropriate times in some text bubble (Mickey Mouse style).

[shundhammer]

Latest version:

• Now using middle-click like left-click, i.e. with selection (including Ctrl-selection to add or remove individual items to or from the selection)

• Now also overlaying a semi-transparent mask subtly half-obscuring everything outside of that directory branch (upon middle-click), leaving only the subtree of the current item unobscured.

  Right now that means the toplevel parent that is not the root of the current treemap remains unobscured, i.e. everything with a white frame.

  Of course, a left-click outside of the innermost white frame removes the mask.

[shundhammer]

Unresolved problems so far:

• Showing the directories, i.e. which white rectangle is what.

  Since the innermost white frame is the direct parent of the current treemap tile (the red frame), this is now always the path displayed at the top in the breadcrumbs widget, the path with the clickable individual path components above the tree view.

  If that is possible at all (which I don't know yet), a tool tip when hovering over the white frame lines might be an option.

• Making the whole feature discoverable; a middle-click is something for real hard-core insiders (and for users who RTFM, i.e. all seven (or so) of them).

  I have not yet given up the idea of doing it upon hover with a timeout. The middle-click will remain as the quicker option; since very likely almost nobody uses it, it won't get in anybody's way.

  If there is a timeout (with a cool fading-in effect to make it less disruptive), it needs to be configurable so users who don't like it can disable it.

  I am still very much undecided about this.

[shundhammer]

Try it and play with it. It becomes even more useful when used in combination with zooming the treemap in and out; you get a real sense of proportion of subdirectories even independently of the tree view above (which already displays the percentage bars to visualize the same).

[shundhammer]

Now we have a tooltip with the directory path on each of the white rectangles, but only on the outline, not inside (which would be confusing and annoying).

I gave it some leeway with not only the real outline (that's only 1 or 2 pixels wide) but 10 pixels to its inside. It's only on the inside because otherwise QGraphicsView might get undefined results with all kinds of its internal algorithms.

[sakkamade]

Now using middle-click like left-click, i.e. with selection (including Ctrl-selection to add or remove individual items to or from the selection)

This one is not much desirable for me, as I have already mentioned above.

I wanted to see the *parent directory* of clicked file being selected in the tree, rather than the file. That was the whole point of it.
I would like not to see the red highlight in this case at all.

Now we have a tooltip with the directory path on each of the white rectangles,

It is not really convenient to hover one-pixel-width outline. And the tooltip is not much useful, as it has a timeout.

I gave it some leeway with not only the real outline (that's only 1 or 2 pixels wide) but 10 pixels to its inside

I wonder if user will be able to understand that there is actually a 10px-width area. I wasn't.

[sakkamade]

[...] and I am more and more convinced that very few users bother to read documentation anymore these days. [...]

I am not sure what users you target, but most of them are likely to remain with Filelight or Baobab, and never to even think of moving from them.
And most would likely get scared away at first sight of these *ugly* rectangles.

[shundhammer]

So you don't like it. Okay; that's your opinion.

[sakkamade]

No, sorry I guess I was unclear.

What I was trying to say is that I think users who likes QDirStat won't mind reading extensive documentation, while those who mind will simply remain with default Filelight or Baobab.

But yes,

I wanted to see the *parent directory* of clicked file being selected in the tree, rather than the file.

And yes,

That was the whole point of it.

Well, maybe half of it.

[shundhammer]

I played a bit with GdMap to get a feel for the user experience:

I loaded my home directory and clicked around a bit; it appears that the last directory that I clicked into was ~/doc/photo. That's what you can read at the top in the clickable path. Yet here it shows my whole home directory again, so that path is unrelated to the current treemap content. That ~/doc/photo is in the blue part on the left side.

Then I moved the mouse cursor around, and I found myself somewhere inside one of those deeply nested Opera extension directory trees (which uses the same general directory layout as Chrome or Firefox extensions).

According to your description, I had expected to see the direct parent directory of the file under the mouse cursor highlighted; but lo and behold, it was not that one (~/.config/opera/Extensions/bbke...bg/8.5.7_0/_locales/pt_BR), it was its topmost ancestor within the treemap, ~/.config).

This is exactly what my new scene mask would highlight; both follow the exact same strategy. Zooming GdMap into the treemap confirms that: It's always the highest parent level.

What you never get highlighted in any way in GdMap, though, is the direct parent directory; only if it happens to be the only hierarchy level that is visible in the treemap.

IMHO that is pretty much useless; what would a user do with only that information? How is that helpful?

Worse, the clickable path above the treemap appears to be very detached from the highlighting in the treemap; I don't know if that is a bug or intentional, but after clicking "Go up one level" or "Goto toplevel folder" that ~/doc/photo path was stuck there, even though it had no more significance to what was going on in the rest of the program.

And the status bar always displays only the first path component of the file under the mouse cursor; at least in the case when the path above the treemap is not completely wrong like in my example.

The bottom part of the status line contains the rest of the path; the mental acrobatics to figure out the resulting path are quite mind-boggling for the average user.

All in all, I don't like that user experience at all (nevermind the possible bug with that leftover old path); it stretches the limits of what a treemap can do way beyond its true capabilities. It clearly shows that other views to complement those shortcomings are sorely missing.

[shundhammer]

So, what I wanted to achieve with those white frames was to indicate the borders of the current tile's (file's) directories all the way up the hierarchy. That is interesting because it gives the user more context; only showing the toplevel is useful only in very rare cases.

On the other hand, only showing the direct parent directory is (in most cases) just as useless as only showing the highest ancestor; just look at any of the screenshots here. Would I care of the direct siblings of messages.json in that pt_BR locale directory? Are there even any? It's much more interesting to see the part of that whole subtree that is taken by all the localization files; or, depending on the use case, of that entire browser extension, or of all extensions for that browser.

You can't know beforehand. It's very situation-specific. So the only useful aid the program can give to the user is to show all the directory borders.

That of course immediately raises the question which border belongs to which directory; and this is where the tooltips come in. When I experimented with the first versions of this, I always wondered what directory I was looking at; what that border really is.

Zooming the treemap in is one way of drilling down; but it has the downside of throwing the user completely off track since the layout invariably changes because the proportions of the previous vs. the new rectangle are different, so the treemap layout starts again, rearranging each tile and each subdirectory.

On the way back up (zooming out again) it's the same; you have to find your bearings again after each zoom step.

[sakkamade]

According to your description, I had expected to see the direct parent directory of the file under the mouse cursor highlighted

You have forgotten how much we deviated from the feature I wanted at first.

On the way back up (zooming out again) it's the same; you have to find your bearings again after each zoom step.

Right, that is the downside.

---

I will try to test it some more tomorrow to see whether your approach of highlighting a *file* is really the way.

[shundhammer]

Well, you never answered my question about a use case.

You replied with how GdMap does it and with implementation suggestions. But I still don't know what you want to achieve.

[shundhammer]

In parallel, I discovered how useful marking the directory borders can be; it gives visual insights how directories, all their subdirectories and the files use disk space.

This is why I keep asking for use cases; most users have only their specific scenario in mind, while their use case is very often just a small piece of a much larger jigsaw puzzle. Assembling the puzzle is the goal, not just finding the right spot for that one piece.

So a new feature needs to solve a general problem, not just answer one specific question (which becomes irrelevant once it's answered). A one-trick pony is useless.

[shundhammer]

BTW in case you missed that: If all you want is to see details of the parent directory, there is the "Go up one level" action in the tool bar, in the "Go" menu and in the context menu, and it has the Alt+Cursor Up keyboard shortcut.

[sakkamade]

I reply only to this now.

Well, you never answered my question about a use case. You replied with how GdMap does it and with implementation suggestions.

I didn't reply to the question of use case there #176 (comment), and your question of use case was before I succeed to convey what I wanted.

Now, the use case. There is no use case, as am I simply getting lost when I click two squares located side by side. (Though it is better now that there are white directory borders.)
You said it is confusing how gdmap zooms its way in, I say I have no idea what is going on in the tree when I click the rectangles on map.

[shundhammer]

Now, the use case. There is no use case

There must be a use case. You must have an idea of what you are trying to do. That's what a use case is.

as am I simply getting lost when I click two squares located side by side

Well, why do you do that? What are you trying to achieve?

You must have an idea what you are trying to do with that treemap. So, what is it? Why are you clicking into the treemap in the first place?

---

The usefulness of a treemap in general and the treemap of QDirStat in particular is:

• You can instantly see the relative size of items in a complete directory tree, even if nested deeply inside the hierarchy.

• A large blob hiding deep inside a deeply nested directory tree (e.g. an installation ISO) sticks out like a sore thumb; you will instantly spot it. One click on it will give you all the details on it (in the other views!), and you can decide if you really want that thing there, or if you prefer to delete it.

• The color coding gives some rough category of the type of file that you are looking at: An image, a video, an audio file, a text document; or "something else" (i.e. grey).

• The amount of the same colors give you some indication by what file types your disk space is used, in particular if any (non-grey) color dominates.

That's very much it. The humps that the shading indicates give some very slight hint about the grouping, i.e. what files belong together in the same directory or subtree; but it's only a very subtle hint, and it doesn't go very far.

For everything else, the other views are much more useful: The tree view displaying the exact hierarchy, the details panel displaying further information (exact size, allocated size, exact type, what software package it belongs to (if any)); the breadcrumbs widget above displaying the exact path and enabling direct access to higher hierarchy levels.

I am very much convinced that you are trying to use the treemap for things that it was never meant for; and that it is unsuitable for. Why anybody would want to use a treemap-only application like GdMap etc. is beyond me; they don't provide nearly enough information to let the user make an informed decision, e.g. if a file taking up so much disk space could be deleted or moved to archive media, or if it's something that should rather be kept.

That is why QDirStat gives access to all that information in various ways, and even provides the cleanup actions for so you can take immediate action if desired.

Just blindly moving and clicking around in the treemap with disregard to the other views will get you nowhere; no amount of pimping up the treemap will change that.

[shundhammer]

Merged branch huha-ovl to master and created new issue #181 to summarize the new behavior.

[sakkamade]

I am very much convinced that you are trying to use the treemap for things that it was never meant for;

"Never before" must not imply "and never will."
Personally, I am quite comfortable with navigation in gdmap.

I do apologise, but I see no further point in trying to convince you in something, as you doing everything the way you believe is right (which may be for better).

Myself, I'll just stick to this #176 (comment), as currently qdirstat shows itself in its best light if user forget about clicking the treemap.

[sakkamade]

you doing everything the way you believe is right

Still, I rather see this than the position of some other projects' teams who in trying to consider everyone's opinion, in the end, does no changes at all, for everyone never comes to an agreement.