Hi Simon,

Am Tuesday, 26. August 2008 21:18:11 schrieb Simon St James:
> Hi all,
>
> One of these days I'm going to submit a patch that just works, with no
> known side-effects or drawbacks.
>
> Today is not that day :)
>
> Please find attached what I hope will be the beginning of a fix for:
>
> https://bugs.kde.org/show_bug.cgi?id=155636

Thanks for your work, but please contact David Faure or me _before_ 
investigating so much work into a (quite large) patch, otherwise I fear it 
gets very frustrating for you if David or I don't agree with the approach in 
general.

I think this patch goes into the wrong direction: Dolphin and Konqueror have 
different philosophies of the status bar and I see no sense putting the status 
bar logic from Dolphin into the Dolphin Part. E. g. a lot of Dolphins 
statusbar logic is related to showing error messages and information messages 
into the status bar. Konqueror does not do this... I also have plans for 
refactoring some parts of the statusbar in Dolphin to be able offering an 
optional zooming slider.

I have not checked how Konqueror handles the status bar information, but if 
there are signals or whatever missing from the Dolphin part so that Konqueror 
can show the status, then for sure we should add those signals into the 
Dolphin part. But there is no need for exporting the whole statusbar including 
space information to Konqueror.

It is important for me to keep the code in Dolphin straight forward. 
Introducing a DolphinStatusBarController just for updating the statusbar 
information is "too much" from my point of view...

The Dolphin KPart should only export the views (icon view, details view, 
column view). The URL navigator, the filterbar, the context menu, the panels, 
split of views ...  - all the other things are handled by Konqueror and 
Dolphin separately For sure this does not mean that Dolphin and Konqueror 
don't use similar libs for implementing similar functionality (in fact: they 
share a lot of similar libraries already), but the sharing for such things is 
not done with the KPart.

https://bugs.kde.org/show_bug.cgi?id=155636 only wants that the directory info 
and hover info is shown. I think it should be possible solving this in a more 
straight forward manner :-)

So honestly speaking I object against the attached approach and really hope 
that this does not frustrate you. Please let me know if I can support you for 
https://bugs.kde.org/show_bug.cgi?id=155636 and please just contact me 
directly before investigating so much time again.

Thanks for your understanding,
Peter

> The bulk of the patch is factoring the status bar logic out of
> DolphinViewContainer and into a class called, for the time being,
> StatusBarHandler (something like DolphinStatusBarController might be
> better, if rather verbose).  I'm going with this approach as I'm guessing
> exporting DolphinViewContainer in the Part might be rather awkward, but do
> correct me if I'm wrong :)
>
> The actual bit that pokes the status bar into Konqueror is in DolphinPart
> and is currently #if 0'd out, for two reasons:
>
> 1) Cosmetic - the capacity bar is a little taller than the standard status
> bar area:
>
> http://etotheipiplusone.com/konq-statusbar.png
>
> 2) Functional, and a blocker - Konqueror relies on its built-in status bar
> text label for the "right-click brings up the Split/ Lock/ Close View"
> menu, and the Dolphin bar currently replaces this, removing the ability to
> summon this menu.
>
> I suppose there are two main choices here:
>
> A) we can either attempt to re-instate this right-click menu behaviour, but
> I cannot really think of a clean and foolproof way of doing this without
> making some ugly changes to Konqueror and/ or some ugly Konqueror-specific
> changes to Dolphin; or
>
> B) we can follow KHTMLParts' lead and, in "KPart"-mode (i.e. when embedded
> in Konqueror), not use our own text label to show the message, and instead
> use the KPart system's own status bar text message stuff (the KPart system
> also provides a progress widget which we can use in place of
> m_progressBar).
>
> The disadvantage is that, in KPart mode, we'll lose those cute little Info,
> Error etc icons next to the status message, and we'll have to either modify
> DolphinStatusBar so that it can operate in two different modes (one using a
> label & progress bar for the messages/ progress; the other emitting the
> relevant signals for use by the KParts system).  This might involve
> creating an AbstractStatusBar class with DolphinStatusBar and, say,
> DolphinPartStatusBar as implementations.
>
> As always, comments, plans, re-namings and nitpicks appreciated :)
>
> I've not documented this heavily but will do so if the general approach is
> approved.
>
> Best Wishes,
> Simon