Konqueror 4

[Ellen Reitmayr]

On Saturday 28 October 2006 13:50, Kevin Ottens wrote:
> > 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 can't judge it from a technical point of view. i guess there should be a 
clear separation of the two for users. that means if konqueror remains one 
application, file and view profile need to be much better separated 
(including settings, complete menus, possibly url bar, views, ...). not sure 
if shortcuts might become an issue, though.

> That said, I'm convinced that even if we go with two separate applications
> libkonq has probably to be shared between them.
>
> > 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.

we did some basic user tests with benjamin's vista-like url bar, the gnome and 
mac style at akademy. really just very basic test, but it indicated that 
gnome's breadcrumb in combination with file bookmarks is extremely fast for 
navigation. still, it has issues for deep hierarchies. 

but i agree with kevin that you shouldn't remove the editable url bar 
completely, but maybe hidden as gnome does it (one or two users needed to 
type at a point, can't remember the use case though...)

> > [...]
> > 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.
>
> > - 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
> said it can be easier by using libkonq which has already quite some
> interesting logic IMHO. In return it would probably improve libkonq.
>
> > 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 - sidebars are useful for navigation, information, etc. maybe the 
sidebars we currently have in konqui are a bit outdated, but having 
information beside the main view is sure required.

> >  - 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).

I can't guess how much implementation effort the one of the other means, or if 
more than one developer will get involved with dolphin later. 

however, getting to a state where dolphin can do what konqueror can do for 
file browsing right now will sure require some man power. if that can be 
assured, or if dolphin will use existing code (konqlibs?), then i think it's 
cool to start with a minimal application rather than the fullblown konqui ;-) 

> > this would free us to
> > work konqi into the best -browser- possible. (this is more about usage
> > paradigms than what sort of content is viewed/managed; e.g. this isn't
> > about turning konqi into web browser only or recreating the entire
> > "embedded viewer" managerie as seen in konqi today in a separate
> > application we call a "file manager")
> >
> > for me, the biggest improvement targets for file management in kde4
> > include:
> >
> >  - feedback (metadata, previews)
>
> Hmm, which kind of improvement are you looking for? I consider ourselves
> quite strong in this department.
>
> >  - 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 looks
> tempting to me but replacing the URL bar is IMO one of the critical parts
> we want to get right. 
agreed.

> Of course I'm biased regarding the criticality of 
> this thing, and it comes from the fact that I'm not that happy with
> 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).
not in a url bar and not in a breadcrumb, IMO.... >> bookmarks.

> >  - 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...)
(seamless integration of open/edit with previews, of network folders, ..)

> Hmmm, could you elaborate a bit regarding d'n'd problems in konqi?

hah!
+ there is insufficient destination feedback when you move an item over other 
items or blank space (where exactly will it be dropped?)
+ In some views (icon view), folders open when holding another item over them, 
in other views they don't.
+ In icon view, dragging items and releasing them in the same folder changes 
their position, in others it simply disappears (it should slowly move back).
+ ...


/el

-- 
Ellen Reitmayr
KDE Usability Project
usability.kde.org
-------------- 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/20061028/9bb2da97/attachment.sig>