<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Again, thanks for the prompt
reply! With regards to file navigation through the disjointed
children directories of the parent, the only solution I can think
of is some improved breadcrumb directory tree at the toolbar of
the view. I was thinking of adding files only via drag and drop,
context menu, toolbar button, or Ctrl+C/V into the panel area
rather than just clicking to add a file (as this would limit drilling
into the directory). I don't think that accidentally clicking a
file/folder directly into the stashing area should be a
particularly big problem as this can be easily addressed by a
clear button or by simpling closing the panel.<br>
<br>
The events which would cause the panel to close is a good
question. I am of the opinion that the user should manually close
the panel as they need to. An auto closing panel might be
confusing for some users. Perhaps the split view should be
disabled while this panel is open? After all, this panel is <i>also</i>
serving the purpose of the split view. As for searching, my idea
is to have an option in this panel's toolbar to add the results of
a search into the panel, so the search area can co-exist <i>with</i>
the panel and add to its functionality : ) This can still operate
in the default 50-50 split.<br>
<br>
Finally, my current plan calls for only one such session of the
panel at a time to reduce complexity. However, I am considering to
have tabs for this staging area and if this does improve user
productivity, I will certainly look into it.<br>
<br>
As such, I have made a feature list for this project - a list of
minimum deliverables in the GSoC timeline and some features which
I might incorporate later on if I can't finish it by the end of
the GSoC period. I am happy to discuss this at any time on IRC
(nick: stheory on #kde, #kde-devel).<br>
</font><br>
<div class="moz-cite-prefix">On Sunday 27 December 2015 05:12 AM,
Johan Ouwerkerk wrote:<br>
</div>
<blockquote
cite="mid:CAAcD2ipq1RGyAF==F_tYa6joQ3Som8JDvKoQebg=zST_x18EdQ@mail.gmail.com"
type="cite">
<pre wrap="">On Sat, Dec 26, 2015 at 7:24 PM, Arnav Dhamija <a class="moz-txt-link-rfc2396E" href="mailto:arnav.dhamija@gmail.com"><arnav.dhamija@gmail.com></a> wrote:
In my opinion and personal experience, ctrl+click has always been a pretty
unintuitive and unfriendly way of selecting non-contiguous subsets of files.
It's stressful to keep one finger always on the ctrl key and the
functionality is very limited as it only works for the current level of the
directory. This idea does exactly that, it works on disjoint folder trees at
the same time. Plus, there is no stress about accidentally lifting the
finger from the ctrl key and losing the entire selection : )
</pre>
<pre wrap="">
Oh I agree. I just wanted to know if this was going to be more than
just a 'visual' UI to copy existing shortcut mechanisms.
It seems that it will be, and particularly the capability to work with
disjoint folder trees will make it rather more powerful/useful.
Plus it's a really nice concept because you do not need to know about
shortcuts, need less 'dexterity' or fine motor control and so on and
in theory it would even translate fairly well to a touch interface I
think.
So props for the idea, it sounds like a winner if you get it to work!
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Does this mode have special provisions for navigating in the one panel
so you can easily select file (sub)sets from disjoint directory trees
without setting up the file view as an expanded tree view first?
</pre>
</blockquote>
<pre wrap="">
I am not entirely sure if I have understood the question, but operations can
be performed on the File Tray view as well across multiple disjoint
directory trees. I'm not quite clear on the part of "setting up the file
view as an expanded tree view first" however.
</pre>
</blockquote>
<pre wrap="">
Depending on the File View mode you may or may not be able to navigate
between disjoint trees easily.
For example if I have a directory tree like this:
/A/B/C
/A/B/D/E
/A/B/D/F
/A/G/H/I
/A/J/K
Suppose I am located in /A/B
I decide I wish to archive contents of /A/B/C, /A/B/D/F and /A/J/K
Furthermore, suppose I use a default of "small icons", so I only get
to see a grid of icons and cannot expand folder trees to drill down to
sub-hierarchies from within the file view itself.
Then if I invoke the stashing mechanism for the selection from /A/B, I
now have a problem: how to select /A/B/D/F without selecting /A/B/D/E
?
How to select /A/J/K at all? Remember, from the file view I can
neither drill down (because clicking a folder selects it, and I don't
get the expanders from a tree view because I use the icon view mode)
nor back up to /A.
I can refine my selection from within the staging panel itself, of
course, but if the file hierarchies are complex and/or happen to
contain lots of files it can get visually "noisy", making it tedious
to prune the selection down to what I'd actually want to include.
Being able to limit the initial "rough cut" of the selection
beforehand would help tremendously but requires a relative freedom to
navigate around folders in Dolphin while setting up the staging area
at the same time. Especially if you want to keep viewing the items
that have been explicitly pruned from selection in the staging area so
the user can undo/redo the pruning itself easily.
Now, with normal shortcut behaviour (Ctrl + Click), if you were to
navigate elsewhere, you'd lose your selection. You could avoid this
for the stashing mechanism quite easily: simply do not behave like
those shortcuts and keep the state around, but then you must address
the problem of cancellation.
Whatever the choice, I think the user must be able to explicitly
cancel out of/close the stashing widget in case they entered it by
mistake. With Ctrl+Click it basically amounts to, release Ctrl, click
anywhere and your selection is reset to empty.
Also, how do you want cancellation/closing to work generally: does the
widget auto close itself and release the selection immediately when a
context menu action is "completed"? Or is the widget and selection
retained so the user may re-use the selection for other actions
afterwards, and must therefore close the widget manually? What actions
in Dolphin would cause the staging area and any selection within it to
be dismissed?
E.g. searching for files? Splitting the file view (to view multiple
directories side by side)?
Which reminds me: if split view is used or file search results are
currently being displayed, should it be possible to summon the staging
area then or not? In particular with split view: how does the staging
area behave? Does it 'attach' to a particular 'side' of the view, and
if so, is it possible to have multiple staging areas open at the same
time, one for each visible directory tree in a split view?
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font face="arial">arnav dhamija</font></div>
</body>
</html>