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

[Simon St James]

Hi Peter,

Call me Jack ;) Updated patch with your feedback included attached! No 
additional bugs fixed, alas.

On Monday 11 August 2008 09:34:04 you wrote:
> Hi Simon,
>
> (just a short reply as I'm in the office...)
>
> [...]
>
> > > 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?
> >
> > This was my first thought and would be absolutely ideal, but
> > unfortunately it is thwarted by the fact that, while a startDrag event
> > can be reliably detected by FolderExpander, cancellation of the drag
> > cannot (a successful QDragDrop can be, though, IIRC), as far as I can
> > tell, which is a major pain the a** ;)
>
> Ah, I see ;-)
>
> > A view can itself tell if it is a drag source (I think) by way of the
> > protected state() method - there might be some way of leveraging this.
> >   I don't think it's possible to detect state() changes without
> > polling, though.  Definitely a lot more thought required, here.
>
> Maybe it would be worth checking how Konqueror did this in KDE 3. Konqueror
> also could exchange views per directory level.

Based on a quick experiment, it simply keeps using the same view mode when 
using auto-entry.  This would be a possible strategy to adopt, except that it 
wouldn't help with ColumnView :/
>
> > I've also found another bug: if we have a split pane with icon view,
> > then auto-entering a folder in the left pane also causes the right
> > pane to be auto-entered.  Amazing how tricky something so
> > simple-sounding can turn out to be! :) My initial thought was maybe to
> > be able to provide an option originatingView in the triggerItem signal
> > (NULL by default) as a "hint" as to which view to expand.  Can you
> > think of a better solution for this?
>
> I'm wondering why this happens: When having a split view there are 2
> instances of DolphinView each having it's own folder expander. And each
> folder expander is aware about the view it is working on. Am I missing
> something? Sorry, I don't have time currently to check the code in detail
> :-(

No problem.  Important detail I didn't mention: this is if I drag from one 
pane over a folder in the other pane.  If I just restrict myself to one pane, 
it's OK.

> [...]
>
> > > 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.
> >
> > Hmmm ... Ok, but I'm a bit confused as to how this would solve the
> > following problem:
> >
> > - Column view should not auto expand by default; thus, when the user
> > opens column view, dragging a file over one of directories in the view
> > will not auto-open it (fine so far).  setEnabled(false) at the time of
> > creation of the column view will take care of this.
> >
> > - The user then changes this setting (I'm assuming it will ultimately
> > be settable from the UI ... ?), so now directories in the column view
> > need to auto-open on drag hover.  The column view still has
> > setEnabled(false) from when it was created, though, so this will not
> > occur.
>
> This would be no problem: When changing the general settings during runtime
> all view instances (icon view, details view and column view) get recreated
> so that they can rely on that initializing themselves in the constructor is
> enough.

Aha! I didn't realise this, and this is a game-changer: I'm completely in 
agreement, now!  It even solves a corner case that had just occurred to me 
(my approach wouldn't take into account whether the "Expandable Folders" 
setting in the Details Mode settings dialog changed).

> And even if this would not be the case (meaning: the views don't get
> recreated), I'd go that far that the view should tell the folder expander
> to change the setting and not the folder expander itself. But this is just
> my personal point of view and I understand your point of view too.
>
> PS: there is a bug in the column view when recreating it after applying
> settings - just in case you want to try out my statement ;-)
>
> [...]
>
> > > the column view. Are there behavioral differences between the filters
> > > from Dolphin and the dirfilter plugin?
> >
> > Good point - will investigate.
> >
> :-)
>
> [...]
>
> > > KToolTipItem should get an QObject in this case). Maybe you could get
> > > in direct contact with Fredrik Höglund, that would be great :-)
> >
> > Sounds like a good idea :) I was initially a little worried about
> > making changes as everything seems very flexible (more than Dolphin
> > seems to require) and kdelibs-ish, as if it might be moved there
> > eventually.  I'll ask Fredrik whether it's destined for kdelibs or to
> > be kept Dolphin-only and in either case, whether he had any plans in
> > mind for implementing the preview.
>
> Yes, it was intended that this goes into kdelibs. But Fredrik can for sure
> explain in more details what points must be solved first.

Cool; thanks for the info.  I'll contact him soon.

Best Wishes,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dolphin-springloaded3.patch
Type: text/x-diff
Size: 11888 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20080811/3ccc9f5e/attachment.patch>