[Semi-patch] Dolphin statusbar in Konqueror
Peter Penz
peter.penz at gmx.at
Tue Aug 26 20:51:38 BST 2008
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
More information about the kfm-devel
mailing list