[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [PATCH] Dolphin - Save/ Restore File View Position in Konqueror
From:       Peter Penz <peter.penz () gmx ! at>
Date:       2008-07-21 7:04:07
Message-ID: 200807210904.07343.peter.penz () gmx ! at
[Download RAW message or body]

Hi Simon,

On Sunday, 20. July 2008 16:39:32 Simon St James wrote:
> Hi all,
>
> Firstly - can someone with the power whitelist my e-mail address for this
> list? I'm subscribed, but with a different mail addy.  Thanks!

Thanks for the patch! One important note (as this is already your second patch 
for Dolphin/Konqueror): Please use kfm-devel@kde.org for the patches, 
kfm-devel is the official mailing list for Konqueror and Dolphin. Although I 
regulary have a look at kde-devel, I might miss some patches because of the 
high traffic in this list... ;-)

> Secondly, please find attached a patch that makes Konqueror's embedded
> (DolphinPart) file views remember their scrollbar position as you go back
> and forth in Konqueror's history - currently, if I scroll halfway down a
> list of files in a directory, then navigate to a different directory, then
> press the "Back" button, I end up in the original directory but scrolled
> all the way up to the top.  With this patch, I end up at my original scroll
> position, halfway down.

I did not have the time yet to try your patch and hopefully David Faure can 
comment on whether this is the correct way to do it (Dolphin itself uses the 
URL navigator, which remembers the position for each history state).

> It's a little glitchy due to a problem I'm continually running into:
>
> - A URL is opened.
> - The current cached directory contents are emptied.
> - The View item associated with the directory model updates itself, either
> immediately as soon as the model is altered, or through a delayed layout
> timer - it seems to be dependent on whether we are using a QListView or a
> QTreeView.
> - Since the model is empty at the time of the view's update, the content of
> the view is assumed to be empty, and the scrollbars are reset to (0,0) with
> their minimum and maximum both equal to 0.
> - Even when the directory has completed loading and the model has been
> re-filled, the view may not have updated yet and will still think it is
> empty, so attempting to set the scrollbar positions to their "correct"
> locations is denied.
> - Thus, we eventually end up with the view re-populated, but scrolled up to
> (0,0), which we don't want.
> - So we have to fire a timer with a delay to do the actual updating of the
> scrollbars, and hope that the view has noticed that it is in fact full of
> items that we can scroll through.  This results in very visible "jumping"
> of the scrollbars from (0,0) to their proper, final places.
>
> I've added a "TODO" in the patch that looks like it may provide a means of
> working around the problem, but it would be nice to be able to tell Qt not
> to do any re-layouting until we say so.  scheduleDelayedItemsLayout()
> looked promising, but of course flushing and loading of a directory is
> asynchronous, so there's plenty of time for the event queue to start
> processing again and triggering unwanted relayouts.  Does anyone have any
> suggestions for how to tackle this?

I had similar problems in Dolphin too - we might compare the approaches, maybe 
the DolphinView can provide a hint for the kpart so that we don't need to 
duplicate the approach.

I've to go to the office now, I should have some time on Wednesday evening for 
investigating into this...

>
> Best Wishes,
> Simon


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]