Konqueror 4

[Aaron J. Seigo]

On Saturday 28 October 2006 5:50, Kevin Ottens wrote:
> Le samedi 28 octobre 2006 01:20, Aaron J. Seigo a écrit :
> > the more i look at konqueror the more i wonder if we'll be able to truly
> > pull off a "browser and a manager" application. the paradigms are so
> > fundamentally different .......
>
> I admit I'm still pondering about the right approach regarding this.
> There's pros and cons in both.

i think we can offer both to our users. a browser with a UI streamlined for 
browsing and a manager with a UI streamlined for managing. one then has a 
choice of either concept without a strange melange of the two in the 
interface nor with one pulling down the other's efficiency through 
least-common-denominator interface elements.

> That said, I'm convinced that even if we go with two separate applications
> libkonq has probably to be shared between them.

yes, there will be tons of shared code regardless.

> > one example is the location bar. it makes all the sense in the world to
> > have a fully editable url bar as we do now for a browser (e.g. a web
> > browser). but is it the most ergonomic thing in a file manager? hm.
>
> Well, you probably have to keep it at least for file management on network
> shares.

i'm not overly sure, actually. thinking about this exact issue the other day i 
started pondering if it would be possible to pull out the protocol and 
hostname, with the former selectable/editable via a drop down listing 
possible options (hopefully in plain language as well as bare protocol names) 
and the latter editable with a history combobox; following that could be a 
breadcrumb of the directories.

that said, dolphin supports both breadcrumb and editable already and can 
switch between them on the fly.

> > [...]
> > the negatives of working with dolphin include:
> >
> > - it's kde3; peter's expressed desire to port to kde4 sooner than later
> > and it shouldn't be -too- hard. the interview stuff is probably the
> > biggest bit.
>
> Well, we already have some candidates for this floating around. Ben Meyer's
> view and recent efforts on KDirModel coming to my mind. That's not exactly
> as if we're starting from scratch.

yes, dfaure's kdirmodel work helps a lot; it just means switching over to them 
when porting to kde4.

> > - there's a certain amount of features and polish missing that can be
> > seen in konqueror. this is to be expected given the time put into konqi
>
> And that's the biggest problem with starting a separate application, that

yep. it's also a bit of a blessing, but certainly something of a curse.

> said it can be easier by using libkonq which has already quite some
> interesting logic IMHO. In return it would probably improve libkonq.

yes, dolphin already uses quite a bit of stuff from konqi. things like the 
servicemenu action items are whoelsale duplicated (copy 'n paste, mostly). 
helps highlight what could be done a lot better =)

> > the benefits include:
> >  - we have to ask ourselves about each inclusion
> >  - we don't have to be tempted with reworking rather than ripping out
> > cruft like the sidebars as they don't exist in dolphin ;)
>
> Well, that assumes the sidebars has to be removed. :-)

well, the ones we have right now really shouldn't be kept in kde4. they are 
less than good. and i'm speaking from both a technical as well as a usability 
perspective there.

will we need sidebars? of course. what should they look like? pretty different 
than what we have right now. IME when there's the temptation to continue 
using something that is there already, that's usually what happens.

> >  - it's a much nimbler code base at this point
> >
> > so the big question is: one browser+manager or one browser and one
> > manager? if the latter it may make sense to adopt dolphin at least as a
> > test bed if not as an outright candidate for the role as manager.
>
> Dolphin is definitely a good test bed. But IMO it's still no an outright
> candidate as default file manager (might become the case though).

it certainly needs work, but then so does konqi. the question that's been on 
my mind is this:

is it quicker and easier to produce a quality product by working on konqueror 
directly and making it the multi-faced application that is well tuned for the 
use cases, or is it quicker and easier to produce a quality product by 
building from another code base for one of the primary use cases?

right now i'm thinking that we have a much better shot at making konqueror a 
kick-ass browser interface (note: not "web browser" but "* browser") replete 
with power features like history, "radial views" and "svn integration" that 
we already have while dropping some of the more "manager-esque" features 
(like "create an image gallery") if we focus on making it a browser.

a file manager doesn't need that level of complexity or that set of features 
(e.g. a history listing). in fact, it's degraded by them. it also could 
benefit from its own set of special features that really don't make a whole 
lot of sense in a "browser" like a drop pool area.

> >  - feedback (metadata, previews)
>
> Hmm, which kind of improvement are you looking for? I consider ourselves
> quite strong in this department.

we are able to access the information, yes, which is where we kick ass. but we 
present it very clumsily. the mouse overs are less than great: they popup 
only after a moment's pause and obscure other items. they also seem tied to 
other settings like tooltip preferences. since they are put into a tooltip-y 
type box they are also pretty ugly. they tend not to emphasize more important 
information over less important information. etc..

having a dock area that shows meta data in a much prettier way, that 
prioritizes information and that doesn't obscure other entries would be a 
very big win.

> >  - navigation (breadcrumbing, drop zones, integrated search)
>
> Note that we probably want more information about breadcrumbing to be sure
> it's a real improvement or if we should find something else. 

it's become a pervasive metaphore on both the web and in other file managers. 
the usability of it is fairly proven for navigating hierarchies in a 
simplistic way (which is what the majority of people do =) and i plan on 
doing some usability testing of my own as well with the breadcrumb widget 
itself.

ellen and co already did some testing at dublin, and it highlighted a number 
of problems with the one they tested.

> system:/ current behavior. I think the problem system:/ and friends tried
> to solve should be solved there instead (hopefully with no side-effect this
> time).

interestingly, the breadcrumb in dolphin does this to a large extent already. 
for instance, when you are in your $HOME the first button says "Home". 
similar for other special places. really nice.

of course, switch to the editable line and you get the whole darn thing =)

> >  - covering fundamental use cases (near?) perfectly (d'n'd in konqi is
> > quite poor righ tnow; this past week i painfully watched people try and
> > deal with it. renaming needs to be dealt with smarter. etc...)
>
> Hmmm, could you elaborate a bit regarding d'n'd problems in konqi?

ellen mentioned a few. some of the issues i've observed while watching users 
include:

 - allowable drop areas are very limited and not obvious at all. this is 
particularly true when viewing files with previews turned on: you can't drop 
on an icon and the actual extent (from konqi's perspective) is not marked 
visibly in view even though it is bigger than the preview image itself
 - allowable click-n-drag areas suffer from the same problem in point 1
 - shift-click selection is non-intuitive in its current implementation
 - the single click selection issue really gets frustrating for users when 
moving files about (i'm a big proponent of single click, but we must fix this 
issue in kde4)
 - when dragging multiple items, the drag icon only reflects the currently 
dragging one resulting in a loss of contextual information

there are some nice features that could be added to D'n'D, but we really 
should get these basics right first. it's one of the (few) things 
that -really- gets people annoyed with konqi.

and it seems people are happier with "basics that work" than with "basics that 
sort of work but lots of snazzy features" ;) konqi is the latter, in kde4 we 
can deliver "basics work with lots of snazzy features".

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20061029/49699734/attachment.sig>