[PATCH] Tiny patch for spring-loaded folders in Dolphin

[Peter Penz]

[...]
> > I don't have an answer for this yet and also must have a look first...
>
> I have some plans, but they are rather hackish.  The basic idea is to
> delegate the final call to <view>->deleteLater() in
> DolphinColumnView::deleteColumn() and DolphinView::deleteView() to a static
> method
> FolderExpander::deleteWhenNotDragSource (or a better name ;)) which hide()s
> and disconnect()s <view> (which seems not to cancel the drag) but does not
> delete it until it thinks <view> is not a drag source.  It will err on the
> side of caution by deleteLater()-ing <view> if it can't rule it out for
> sure. I'll provide an actual patch for review when I get a chance, but will
> quite understand it if it sounds too hairy to commit ;)

Postponing the deletion of the view until the dropping has been done sounds OK 
to me. But using a static method in FolderExpander sounds dangerous: Assuming 
we have the following directory structure:
A
  B
    C

A uses the icons view, B the details view and C the column view. Now the user 
drags an item into A, drags it into B and drags it into C. When is the view A 
deleted internally? Do we have a queue?

Just a quick thought: The DolphinView is responsible for creating the views, 
so it also should take care deleting them and we should not forward this to 
the FolderExpander. I think the folder expander should emit a signal when the 
dragging has been finished. By this e. g. the DolphinView can queue the 
pending views that must be deleted and deletes them as soon as it gets the 
signal from the Expander. What do you think?

[...]
> Not offended at all - this is just the kind of very thorough critique and
> improvements I was hoping for! I agree with all but a few (all related to
> the same thing) and will prepare an updated patch within the next 24 hours.

Please just take all the time you need, there is no need to do something 
within 24 hours (except if your name is Jack Bauer :-) 

> The areas I'm not sure on all pertain to these:
> > +        <entry name="AutoExpandAnyView" type="Bool">
> > +            <label context="@label">Use auto-expanding folders for all
> > view types</label>
> > +            <default>false</default>
> > +        </entry>
> >
> > What do you think about: AutoExpandFolders?
>
> ...
>
> > However I don't like the naming of 'alwaysExpandThisView'. What about
> > having just methods like:
> >
> > void AutoExpander::setEnabled(bool enable);
> > bool AutoExpander::isEnabled() const;
> >
> > instead? The 'alwaysExpandThisView' is unclear from my point of view
> > ('always' vs. 'sometimes', 'this view' vs. 'other view'...).
>
> The concept that the "alwaysExpandThisView" and "AutoExpandAnyView" are
> trying to capture is that if this is true, then whether or not a folder in
> this view is expanded does not depend on the current setting of
> DolphinSettings::instance().generalSettings()->autoExpandAnyView() [or the
> renamed version of this ;)].  setEnabled(...) sounds like it will always
> expand the view or always not expand the view, when it actually depends on
> a setting that can change after the FolderExpander is created.

I understand, but exactly this difference should be kept out of the expander 
class itself from my point view. The client of the expander decides whether it 
should do an expanding or not. If this is based on reading the general setting 
from Dolphin or because the client says "all tree views should be expanded" 
should not be decided inside the expander class.

> It's a rather tricky concept to explain in a few characters :/ I'm happy to
> leave the final call up to you, though.
>
> And while I've got your attention ;) - this bug:
>
> https://bugs.kde.org/show_bug.cgi?id=168254
>
> will need some additional things exposed in the DolphinPart, I think: the
> patch (with "HACK HACK HACK" where I'm doing some rather dubious
> workarounds!) is here:
>
> http://lists.kde.org/?l=kfm-devel&m=121821503218290&w=2
>
> and advice would be appreciated :)

Honestly speaking I don't know the difference of Konquerors dirfilter plugin 
and Dolphins general filter functionality (Tools -> Show Filter Bar). If the 
functionality from Dolphins filter bar is sufficient, then we'd just have to 
offer this interface to the Dolphin part and filtering would also work with 
the column view. Are there behavioral differences between the filters from 
Dolphin and the dirfilter plugin?

> Also, I'm wondering what the plans are re:
> https://bugs.kde.org/show_bug.cgi?id=161848 ? I had a quick look today, and
> couldn't really think of a way of doing it without making KToolTipItem a
> QObject and adding a couple of signals and slots to it, which might not be
> the desired course.  No rush on this, though - I have a whole bunch of
> other stuff to be getting on with in the meantime!

I had no time for this issue yet. Also the whole code for the tooltips has not 
been done by me, so it's difficult to give any advice (but yes: I also think 
KToolTipItem should get an QObject in this case). Maybe you could get in 
direct contact with Fredrik Höglund, that would be great :-)

Thanks!
Peter

>
> Cheers,S
> Si.