Konqueror 4

[Kevin Ottens]

Le samedi 28 octobre 2006 15:10, Ellen Reitmayr a écrit :
> 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.

Sorry for being unclear. My comment was only from the technical point of view. 
I think that we agree, from the user point of view it should be completely 
separated. That's more on the technical side that I'm pondering. :-)

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

Well, I think dolphin does this pretty well. You can basically have both modes 
and it tries to switch mode when it makes sense. Currently it's only based on 
the protocol IIRC, but maybe that could be used to overcome problems with 
deep hierarchies? (I'm guessing roughly here).

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

Well, they're for sure a good way to display bookmarks and metadata about the 
current selection to the user.

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

Well partly, but it still misses something: users expect a folder view of 
those bookmarks, and then they expect "up" to work accordyingly. That said it 
might be because those users are former windows users where you have the "My 
computer" "folder".

That's how it all started with the way system:/ and media:/ are done right 
now. Formerly we had devices:/ and most of my users were confused because 
when you clicked on a device you simply jumped in file:/mnt/bar, obviously 
breaking the up action for them. In the same way if you open a file manager 
directly at the root of a cdrom (for instance), those same users expected to 
be in devices:/. Instead they were in file:/mnt which was confusing for them.

That's exactly why if you use system:/ you have one consistent hierarchy that 
acts correctly with the up action. Infortunately the major mistake I made 
here is about interoperability. So now I solved the issue I wanted to solve 
for the aforementioned users but it introduced interoperability issues with 
applications having no clue about KIO (amarok, kaffeine, openoffice, etc.).

I hope it explains why I think it should be solved in the navigation model (be 
it url bar or breadcrumb) and why I suspect that addressing it with bookmarks 
only wouldn't be enough for some users.

That said, maybe we don't want to care about users who got "bad habits" on 
other desktops. :-) Or, I'm simply overestimating the importance of this 
issue. I basically encountered it with five users (which was 100% or my users 
at that time) prior to the creation of media:/ which might not be really 
relevant after all...

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

My bad for this one, actually I implemented this behavior in the icon views 
only...

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20061028/1de677f0/attachment.sig>