Hey everybody,
in Dublin we (unsuccessfully) tried to set up a meeting to coordinate
different forces and directions that work/used to work on areas related to
Konqueror, e.g.:
Alexander: Profiles
Beineri: Views, Tabs, easy konqui (?)
Carsten + Benjamin: File Dialog
Benjamin: easy konqui
David: Base
Dirk: Document Viewer
Also, Holger Freyther volunteers to work on Konqueror. Holger, Florian and me
just met and figured out some issues that need to be fixed - no fundamental
changes but things that will make life with Konqueror easier. First thing
Holger is going to address is the sidebar: see
cheers,
holger + florian + el

Friday 27 2006 16:16, Ellen Reitmayr wrote:
Also, Holger Freyther volunteers to work on Konqueror. Holger, Florian and
me just met and figured out some issues that need to be fixed - no
fundamental changes but things that will make life with Konqueror easier.
First thing Holger is going to address is the sidebar: see

interesting. ettrich, dfaure, ben meyer and myself met briefly on irc the
other day to discuss the file manager in kde4.

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

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.

something that came up in the conversation was the dolphin file manager[1]. we
invited the primary author, peter penz, to join us in the conversation at
some point. it's an interesting starting point for experimentation, if
nothing else, since it has a small code base that is fairly cruft free.
konqi's code base is considerably more daunting and less rewarding to
experiment on.

i've put together a handful of patches for dolphin over the last 2 days
(they're in svn[2] now) and peter is both responsive and aware of relevant
issues. he's an interface designer by day, and that probably helps.

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

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 ;)
- 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. 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)
- navigation (breadcrumbing, drop zones, integrated search)
- 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)

thoughts?

[1] http://enzosworld.gmxhome.de/
[2]

Am Samstag, 28. 2006 01:20 schrieb Aaron J. Seigo:

Hi Aaron,

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

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, I think it is most useful. Why do you think that a fully editable
location bar is useless for filemanaging tasks?

so the big question is: one browser+manager or one browser and one manager?

I guess we need some more indepth reasearch from HCI people.

I regularily experience that Windows users are actually confused that explorer
and Internet explorer are two different programs and they don't understand
why they cant use c&p or d&d between IE/ftp and the local filesystem /
explorer. What makes things even more confusing is that the Windows explorer
has _some_ networking capailities too.

Yours,
-- martin

Le samedi 28 octobre 2006 01:20, Aaron J. Seigo a :
interesting. ettrich, dfaure, ben meyer and myself met briefly on irc the
other day to discuss the file manager in kde4.

Yup, I also remember discussing with ben meyer about this during aKademy, and
recently with dfaure on IRC.

Nice to see so much interest in improving file management in kde4.

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.

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.

[]
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 IMH 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. :-)
- 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 IM it's still no an outright
candidate as default file manager (might become the case though).

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 IM one of the critical parts we
want to get right. 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).
- 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?

Regards.

Saturday 28 2006 13:50, Kevin 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 IMH 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 IM 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 IM one of the critical parts
we want to get right.
agreed.

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, IM >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

Saturday 28 2006 15:10, Ellen Reitmayr wrote:
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.

It probably is, but on the average corporate network you're not going to
bookmark all the places that you need to be somewhen, that would become messy
really soon. Typing the URL (with the assistance of autocompletion) is often
by far the fastest way to get somewhere.

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)

I know at least one: pasting URLs that get sent around by mail or that are in
documentation. At my work this is one of the most common ways of navigating
somewhere, the rest being split mostly between typing less-common URLs or
bookmarks. Actual browsing is by far the least common use case.

Ironically, at home it's exactly the opposite: I use no bookmarks, hardly
copy/paste, and most of the time I simply browse around.

course I'm not an average user, but the above shows that I use pretty much
all the possible ways of navigation that Konq offers.

Le samedi 28 octobre 2006 15:10, Ellen Reitmayr a :
Saturday 28 2006 13:50, Kevin 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.

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, IM >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 KI (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. :-) , 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.

Saturday 28 2006 21:39, Mark Rose wrote:
I do all my non-CLI file management via the location bar. To access
anything, I simply type where I want to go. Granted, this is definitely not
novice friendly, but I find the sidebar a waste of screen realestate for
how I go about things (though in cases it's obviously more convenient).

Same here, but I have a strong feeling that this is a usability/layout problem
in fact. When I still used Windows XP at work I *always* had the sidebar
enabled, while in Konq I consistently _disable_ the sidebar instead because
it feels big, clunky, and inconvenient.

So far I would like to give the KDE 4 sidebar a second chance, it must be
possible to get it 'right'.

(And the oneliner below is random. Really. :) )

Saturday 28 2006 2:31, Martin Konold wrote:
Am Samstag, 28. 2006 01:20 schrieb Aaron J. Seigo:
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, I think it is most useful. Why do you think that a fully editable
location bar is useless for filemanaging tasks?

i didn't say it was useless. i asked if it was the most ergonomic thing.

try the implementation in dolphin; you'll notice it's quite easy to jump
between breadcrumb and editable location bar. there's a button, a keyboard
shortcut and a config option.

so the big question is: one browser+manager or one browser and one
manager?

I guess we need some more indepth reasearch from HCI people.

I regularily experience that Windows users are actually confused that
explorer and Internet explorer are two different programs and they don't
understand why they cant use c&p or d&d between IE/ftp and the local
filesystem / explorer. What makes things even more confusing is that the
Windows explorer has _some_ networking capailities too.

this has -nothing- to do with what each can access. let's think about this for
a second: the preferred and recommended means for a kde application to access
files is via kio which is "network transparent". we view apps that can't do
this as odd and even buggy. so why exactly would i suggest to neuter konqi
this way? that would be, in my own estimation, *stupid*.

the difference between a "browser" and a "manager" are interface differences.
that's why in my email i talked about interface differences rather than file
access methods. in a "browser" one is navigating a large information space
that is arranged in a way for perusing; the web is a perfect example; a
collection of ebooks might be another; one may want to "browse" their files.
in a "manager" one is more likely to be sorting, labelling, searching,
grouping and working with the set of data.

so in a browser it may well make sense to type "http://kde.org/areas/sysadmin"
and deal with that as the first class navigation system but
typing "/" in a text edit and having only
that text edit as a way to deal with my location, while obviously possible to
live with, is probably not the fastest mechanism since it's a common and
perfectly correct use case to jump back to /home/aseigo/manuals (as one
example) which isn't the case with websites (where the list of entries in the
url may not represent an actual hierarchy). moreover, such a breadcrumb may
go a long ways to eliminating the need for most users needing an actual tree
widget to display the hierarchy given the use case of a file manager.

p.s. let's please not derail this conversation (and sink yet another attempt
at improving on the already pretty nice tools we have in kde3) by discussing
irrelevant things like "will it be transport neutral?"

Saturday 28 2006 5:50, Kevin 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 IMH 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 IM 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 $HME 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".

Hi all,

I think I have come to a point where I'd like us to try and make a separate filemanager application,
which we could even name dolphin if Peter agrees, as long as we share as much code as possible
with konqueror the browser, and with the file dialog.

In particular, how about we make a standalone library (well, or set of classes in libkonq)
for the view framework? That is: support for any level of view splitting and for tabs, and
the related kactions.
This assumes that we actually need nested view splitting in the file manager though,
as opposed to just one splitter i.e. one level of splitting like in dolphin. I'm not sure
this is actually used; I often split, but never more than once.
This also assumes that we need tabs in the filemanager but I read in the openusability
study about filemanagers that users liked the tabs in konqueror and were missing
them in Windows. A bit surprising to me given that tabs make DnD of files between
directory views impossible

In terms of sharing with the file dialog, I mean that kdirmodel and kfileitem can provide
most of those standard features related to file items: tooltips, dnd, previews, delayed
mimetype determination, etc. (This is my next line of action).
Another level of sharing with the file dialog might be sharing views and delegates,
but we'll have to see how that goes (for instance I like the idea of a delegate that
shows some details in the text under the icons in the icon view, but that's not
something for the file dialog I guess).
TH the file management operations (copy/move/delete/move-to-trash with
confirmation and undo/redo support etc.) as implemented by K and KonqUndo
in kdebase/libkonq are probably useful for kfiledialog too.

I really don't have strong opinions on how the GUI should be like
(that's what we have the usability group and our users for), my main goal is to
design all this from a sound technical point of view, which means as much modularity
and code reuse as possible.

I think the best approach at this point would be to
1) continue the work on the "building blocks" for file management (model, views,
common filemanagement operations etc.)
2) create a kde4-based dolphin based on those building blocks -- which doesn't really
mean a straight kde4 port of the current dolphin codebase, but rather porting the
core of dolphin (and using kde4 stuff for the rest of it (for instance I think that bookmarks
should use kio/bookmarks, with a different xml file than the one used by konqueror,
and that undomanager should use KCommandHistory from kdeui and/or konq_undo, etc.).
By working on dolphin in kdebase we can make it use more of kdelibs4 to avoid some
of that duplication of code and efforts.

I'm happy to contribue to both parts of the work, of course.
What do you think about this approach?

Peter (I see you're subscribed), how do you like the idea of "porting/restarting" dolphin
in kdebase svn? See to get a svn account.

Mon 30 2006, Luciano Montanaro wrote:
Monday 30 2006 11:53, David Faure wrote:

This also assumes that we need tabs in the filemanager but I read in the
openusability study about filemanagers that users liked the tabs in
konqueror and were missing them in Windows. A bit surprising to me given
that tabs make DnD of files between directory views impossible

This is not true. You can drag your icons to the tab and wait a few seconds
to move files to the associated view. I use the feature often enough. I'm
using splitted views less often since I discovered this feature.

K, I stand corrected. It takes a bit of time (I hate losing time ;), but it works indeed.

Mon 30 2006, Mark Rose wrote:
As just a KDE user, I don't see the paradigms as so fundamentally different. I
see Konqueror as a visual file accessing program. What's so neat about is
that the transport mechanism is irrelevant. I really stop noticing whether
I'm seeing something over http, ftp, fish, etc. Some file types Konqueror can
display natively and others it opens in external viewers. A page of
information and links known as a website is really not fundamentally
different than a page of links known as a directory listing or folder view.
For me, this seamless integration between local and remote, regardless of
transfer mechanism, known as Konqueror, is the "killer app" for KDE and
Linux. Konqueror is an absolute joy to use.

That was the kde3 konqueror idea indeed. But it turns out that by having everything
into the same application we end up with a large mess, where file-management and
web-browsing things are all mixed up: in the sidebar, in the configuration dialog,
in the behavior of the "Home" button (and in the bookmarks).

Not everything can be "seamlessly integrated" between file-management and web-browsing.
Configuration is one good example of that: file management (local and remote, of course,
i.e. "directory views") is unrelated cookies and javascript and java and useragent etc.
Web bookmarks and the advanced history features (sidebar and "most often visited" menu)
are mostly used in the webbrowsing and not so useful for filemanagement.
We need filemanagement bookmarks, but those should be made separate, which even
makes it possible to share them with the file dialog - much more important than mixing
them with the web bookmarks. Basically the distinction isn't the protocol (transport),
but the (mime) type: directory bookmarks are for directory views and for the file dialog.

The part where I'm not sure is the document viewer embedding functionality.
That one seems to be useful for both filemanagement and webbrowsing,
(which is why I'm calling them that way; "document viewer/browser" is part of both).
I guess we can keep kparts embedding in both, but mostly on by default in the
webbrowser and mostly off by default in the filemanager - like it is already, except
for images. Which reminds me of another good reason for separating filemanagement
from webbrowsing: my wife wants images embedded into konqueror when
webbrowsing but not when clicking on local files. Two reasons: local images tend
to have much higher resolution (like scanned images or digital camera images),
and well, currently the embedded image viewer (khtmlimage I guess) doesn't zoom out,
so you only see a little topleft corner of the image. Could be fixed, but still it shows
the need for configurability and separation. The other reason: file manager windows
tend to be smaller than webbrowsing windows (if only because of the sidebar, but also
because if you want to dnd between file manager windows they need to be smaller
than the screen anyway), so there's not enough room for embedding (large) images into them.
But during webbrowsing, embedding makes sense (there's room) and is useful (less windows).

The main problem I had when Waldo first talked about separating filemanagement and webbrowsing
was: what should happen if you type a http url in a filemanager window. Currently you get
the webpage next to your directory-tree sidebar, which kind of sucks ;). With separate programs
we could simply open a webbrowsing window when typing Enter. My own usability study
(i.e. discussing my wife ;) ) shows that this is a good solution, even better than we do now:
for people who want an actual webbrowser window, without directory sidebar, this new
solution is even faster than "click on konqueror-webbrowser icon in panel, then type
url in new window". And vice-versa, we can open a filemanager window when typing
a directory-like url (local or remote) in a web window.

Am Sonntag, 29. 2006 18:47 schrieb Aaron J. Seigo:

Hi,

try the implementation in dolphin; you'll notice it's quite easy to jump
between breadcrumb and editable location bar. there's a button, a keyboard
shortcut and a config option.

I gave dolphin a try and I am not convinced. E.g. when I navigate to / I can't
do this via a button or by clicking on icons. I am forced to use the menubar.
As we all know being forced to use the menubar has usability issues.

The next thing is that dolphin tries to be smart and hides most directories.
E.g in / I can on my kubuntu system only see
- debootstrap/
- home/
- media/
- usplash_fifo

This selection is a very bad idea. E.g. me navigating to /tmp should be easily
doable.

After enabling the access to the hidden files (only available via menu not
icons) I get presented all hidden files and directories including those
starting with a dot. Then when navigating to /tmp and back to / it forgot
about my selection again. In practice this meand that navigating from $HME
to / and then to /tmp is not a reversable action. (The users needs to
explicitly enable the access to the "hidden" entries again and again.

IMH this is a typical but lame attempt to make the UI simpler.

Rule of thumb: Make it as simple as possible but not simpler.

In the real world this means don't make sane assumptions like "when I enter a
direcotry and navigate back to the upper directory I can easily go back to
the original directory. (Action of Navigation must always allow to be
revertable without changing any view/contents by the mere act of navigating)

Regards,
-- martin

Le lundi 30 octobre 2006 15:15, Martin Konold a *:
I gave dolphin a try and I am not convinced. E.g. when I navigate to / I
can't do this via a button or by clicking on icons. I am forced to use the
menubar. As we all know being forced to use the menubar has usability
issues.

Well, it's part of the "dolphin is young" cons. Not a big deal IMH it could
easily be improved.

The next thing is that dolphin tries to be smart and hides most
directories. E.g in / I can on my kubuntu system only see

- debootstrap/
- home/
- media/
- usplash_fifo

This selection is a very bad idea. E.g. me navigating to /tmp should be
easily doable.

After enabling the access to the hidden files (only available via menu not
icons) I get presented all hidden files and directories including those
starting with a dot. Then when navigating to /tmp and back to / it forgot
about my selection again. In practice this meand that navigating from $HME
to / and then to /tmp is not a reversable action. (The users needs to
explicitly enable the access to the "hidden" entries again and again.

IMH this is a typical but lame attempt to make the UI simpler.

Rule of thumb: Make it as simple as possible but not simpler.

If you're using kubuntu edgy, it has nothing to do with Dolphin. Kubuntu
devels chose to patch kio file to obtain this behavior

Regards.

Am Montag, 30. 2006 15:27 schrieb Kevin :

Hi Kevin,

Rule of thumb: Make it as simple as possible but not simpler.

If you're using kubuntu edgy, it has nothing to do with Dolphin. Kubuntu
devels chose to patch kio file to obtain this behavior

Thanks for enlighting me.

IMH Kubuntu is then to blame.

Regards,
-- martin

Monday 30 2006 12:36, Leo Savernik wrote:
Hmm, this could be streamlined. Why not immediately moving/copying when
directly dropped onto the tab?

this is what the dolphin breadcrumb widget does. i'll be doing some usability
testing of it this week and i'll add this particular feature to the test
coverage.

Monday 30 2006 3:53, David Faure wrote:
In particular, how about we make a standalone library (well, or set of
classes in libkonq) for the view framework?

i think this makes complete sense.

That is: support for any level
of view splitting and for tabs, and the related kactions.
This assumes that we actually need nested view splitting in the file
manager though, as opposed to just one splitter i.e. one level of splitting
like in dolphin. I'm not sure this is actually used; I often split, but
never more than once.

i've seen screenshots with more than one split, but i'm not sure that was
anything more than showing that you -can-. it certainly does make the control
interface for splitting much more complicated. i lean towards your instincts
here as well and think that going with a single split is likely enough; we
can always gather user feedback along the way.

This also assumes that we need tabs in the filemanager but I read in the
openusability study about filemanagers that users liked the tabs in
konqueror and were missing them in Windows.

i see no reason not to provide tabs; they are increasingly popular in
applications and will decrease the learning difference between the browser
and manager applications.

I really don't have strong opinions on how the GUI should be like

on the other side of this fence, i do have some expectations and hopes for the
GUI. perhaps this results in a natural and complimentary division of interest
and duties here =)

2) create a kde4-based dolphin based on those building blocks -- which
doesn't really mean a straight kde4 port of the current dolphin codebase,
but rather porting the core of dolphin (and using kde4 stuff for the rest
of it (for instance I think that bookmarks should use kio/bookmarks, with a
different xml file than the one used by konqueror, and that undomanager
should use KCommandHistory from kdeui and/or konq_undo, etc.). By working
on dolphin in kdebase we can make it use more of kdelibs4 to avoid some of
that duplication of code and efforts.

i've been talking to peter via private email quite a bit about this already
and he's completely onside with this approach, including moving dolphin into
kde's svn to make it easier for us to collaborate on the porting work. but he
can speak for himself here and provide all the details.

I'm happy to contribue to both parts of the work, of course.
What do you think about this approach?

i'm in.

Hi all,

Le Lundi 30 2006 11:53, David Faure a :
I think I have come to a point where I'd like us to try and make a separate
filemanager application, which we could even name dolphin if Peter agrees,
as long as we share as much code as possible with konqueror the browser,
and with the file dialog.

At least we would already have a name a cuter one than kfm. :-)

In particular, how about we make a standalone library (well, or set of
classes in libkonq) for the view framework? That is: support for any level
of view splitting and for tabs, and the related kactions.
This assumes that we actually need nested view splitting in the file
manager though, as opposed to just one splitter i.e. one level of splitting
like in dolphin. I'm not sure this is actually used; I often split, but
never more than once.

Well, I somehow doubt this needs to be shared. As you already pointed I doubt
people use more than one level of splitting. It becomes quickly unmanageable
to a user IMH

This also assumes that we need tabs in the filemanager but I read in the
openusability study about filemanagers that users liked the tabs in
konqueror and were missing them in Windows. A bit surprising to me given
that tabs make DnD of files between directory views impossible

In terms of sharing with the file dialog, I mean that kdirmodel and
kfileitem can provide most of those standard features related to file
items: tooltips, dnd, previews, delayed mimetype determination, etc. (This
is my next line of action).

Hmm, I'm not exactly sure what you mean here. At least dnd and previews
support in model classes like KDirModel and KFileItem looks strange to me (I
could probably live with the preview there though). Could you elaborate a
bit?

Another level of sharing with the file dialog might be sharing views and
delegates, but we'll have to see how that goes (for instance I like the
idea of a delegate that shows some details in the text under the icons in
the icon view, but that's not something for the file dialog I guess).
TH the file management operations (copy/move/delete/move-to-trash with
confirmation and undo/redo support etc.) as implemented by K
and KonqUndo in kdebase/libkonq are probably useful for kfiledialog too.

I really don't have strong opinions on how the GUI should be like
(that's what we have the usability group and our users for), my main goal
is to design all this from a sound technical point of view, which means as
much modularity and code reuse as possible.

I think the best approach at this point would be to
1) continue the work on the "building blocks" for file management (model,
views, common filemanagement operations etc.)
2) create a kde4-based dolphin based on those building blocks -- which
doesn't really mean a straight kde4 port of the current dolphin codebase,
but rather porting the core of dolphin (and using kde4 stuff for the rest
of it (for instance I think that bookmarks should use kio/bookmarks, with a
different xml file than the one used by konqueror, and that undomanager
should use KCommandHistory from kdeui and/or konq_undo, etc.). By working
on dolphin in kdebase we can make it use more of kdelibs4 to avoid some of
that duplication of code and efforts.

I'm happy to contribue to both parts of the work, of course.
What do you think about this approach?

As your evil clone, I agree with this approach. :-)

More seriously, it looks like the best way to go. Having building blocks
shared (through libkonq I guess) and applications using them. Such a "file
management toolkit" is interesting by itself.

Now that I think of it, it might even be of interest for the people working on
krusader No idea if we have some of them subscribed here.

Regards.

Monday 30 2006 4:23, David Faure wrote:
Mon 30 2006, Mark Rose wrote:
As just a KDE user, I don't see the paradigms as so fundamentally
different. I see Konqueror as a visual file accessing program. What's so

That was the kde3 konqueror idea indeed. But it turns out that by having
everything into the same application we end up with a large mess, where

and just so it isn't mistaken for all being a waste exercise: i think we -did-
learn that eliminating the "local vs remote" issue by simply not caring so
much does work. that many of the tools that evolved (e.g. servicemenus,
various file views, etc) were very, very useful. that tabs in filemanagers
actually do make sense (would we have tried that if we hadn't also used it
for a web browser?) etc so we learned lots of "Do"s along with
the "Don't"s IMH

Not everything can be "seamlessly integrated" between file-management and
web-browsing. Configuration is one good example of that: file management

filemanagement bookmarks, but those should be made separate, which even

The part where I'm not sure is the document viewer embedding functionality.

yes, yes and yes =)

url in a filemanager window. Currently you get the webpage next to your
directory-tree sidebar, which kind of sucks ;). With separate programs we
could simply open a webbrowsing window when typing Enter.

And vice-versa, we can open a filemanager window when typing a
directory-like url (local or remote) in a web window.

i'm not sure we need to open a file manager for local urls. perhaps the
browser can be allowed to be more "free form" for the user (which "browsing",
at least in english, implies anyways) while the manager is more purposeful
and therefore focused (which is also implied by the english word used:
manager)

i suppose the defining difference should be "protocols which can allow for
modification" (even if the actual permissions on the given item don't). which
means media, locally mounted file systems, remote protocols that support
writing (smb, fish, nfs, webdav) can all be shown directly in the file
manager.

whereas view-only, or browsing, protocols would open in the browser. this
means http (even though you can send data using it, but that's a different
concept than altering what you are viewing being supported by the protocol),
applications:/, settings:/ those would all open in the browser.

does that make sense?

let me see what i can whip up for testing purposes while working on better
non-local support in the dolphin urlnavigator.

Monday 30 2006 7:15, Martin Konold wrote:
I gave dolphin a try and I am not convinced.

=)

E.g. when I navigate to / I can't do this via a button or by clicking on
icons.

perhaps you're using an old (stable?) version? the version i have from svn
allows me to either:

- click on the bookmark button in the url nav bar and select Root
R
- click in the Root entry in the bookmarks sidebar

(note: sidebars in dolphin's svn are very new and waaay up in the air right
now. mostly it's tossing about ideas right now and experimenting with things)

The next thing is that dolphin tries to be smart and hides most
directories. E.g in / I can on my kubuntu system only see

yeah, this is a kubuntu issue as others have pointed out =/

This selection is a very bad idea. E.g. me navigating to /tmp should be
easily doable.

agreed.

After enabling the access to the hidden files (only available via menu not
icons)

which isn't unreasonable IMH why do people need quicker access to hidden
files?

I get presented all hidden files and directories including those
starting with a dot. Then when navigating to /tmp and back to / it forgot
about my selection again.

agreed i'll whip up a patch to make "show hidden files" sticky.

In practice this meand that navigating from $HME
to / and then to /tmp is not a reversable action. (The users needs to
explicitly enable the access to the "hidden" entries again and again.

IMH this is a typical but lame attempt to make the UI simpler.

yes, it's an abortive (if understandable) attempt to make the UI simpler by
kubuntu + an implementation issue that is easily improved in dolphin. not a
show stopper in either way.

Monday 30 2006 7:26, Allan Sandfeld Jensen wrote:
Saturday 28 2006 01:20, Aaron J. Seigo wrote:
- navigation (breadcrumbing, drop zones, integrated search)

Nice idea, but I don't see any reason to replace the locationbar.
Typing in a location is the fastest way to get to place

this is not true in all use cases. it's only guarantee-ably true when:

- the user is descending (upwards and sideways navigation is often slower)
- the user knows where they are going

there have been usability studies done on these things, though primarily
(exclusively?) in the web sphere. i have yet to read one that actually found
them flawed; all i've come across online note they are beneficial, though
that benefit is impacted by positioning.

there was also some usability testing done on such a widget at dublin. the
weaknesses found there are currently avoided by the dolphin implementation,
as i understand it.

currently i'm lining up guinea pigs for usability tests this week of the
dolphin breadcrumb. i'll let you all know how that goes and then we can move
even further from conjecture on the matter.

and we for this very simple reason it would be folly to throw it away.

brilliant, another person who comments without trying it out. i'll toss this
one to yoda.

"throwing it away we are not!" says yoda. "letting the user switch between
breadcrumb and editable are we, as well do we let them choose their default.
the force may be strong with you so you use an editable bar, mmmh? but most
weak are with the force. trees and URIs ergonomic they are not. them we give
the breadcrumb."

So instead of this HELL*-inspired breadcrumb bar,
* read GNME

this kind of reactionary crap really ought to add to the SPAM rating of an
email so it can be automatically filed where it belongs. that said, you can
add Vista and most websites of the world to that list, among others.

we should have
locationbar with active parts so you can click on any part of the path, and
drag to any parts of it.

then you end up dealing with appropriate click-drag distances for editing.
there lie dragons. and for the minor difference this presents from a dual
mode bar i don't see the point, though i do see the pitfalls.

Monday 30 2006 17:05, Allan Sandfeld Jensen wrote:
Tuesday 31 2006 00:28, Aaron J. Seigo wrote:
this is not true in all use cases. it's only guarantee-ably true when:

- the user is descending (upwards and sideways navigation is often
slower) - the user knows where they are going

No, descending is faster by typing,

if the user knows where they are going, yes. isn't that what i said?

sideways navigation is faster.

going from /home/aseigo/pix/venezuela to /home/aseigo/music:

editable:
click mouse in edit area or press F6+end
press delete key or highlight pix/venezuela with keyboard or mouse
type "music"

breadcrumb:
click aseigo, hold momentarily
select music
or
click aseigo button
move mouse into view
click music folder

and that's assuming the user has perfect knowledge of their system. this does
not measure user confidence and awareness in any way.

"throwing it away we are not!" says yoda. "letting the user switch
between breadcrumb and editable are we, as well do we let them choose
their default. the force may be strong with you so you use an editable
bar, mmmh? but most weak are with the force. trees and URIs ergonomic
they are not. them we give the breadcrumb."

That's a problem, not a solution. As you state above there are different
cases where one is usefull. This makes it a poor replacement, and makes no
improvements to the current users skilled in the current interface.

if you don't like it: don't use it. simple. flip to the editable text edit and
be happy. but let others have something that works for them, too.

that said, you assume that most of our users are skilled in the current
interface. similar to this statement:

Sorry if I am reactionary, but I value real users higher than potential
users.

the implicit assumption in this statement is that current kde users are served
well by the editable bar. it is true that you and i may be skilled with it;
other power users may be skilled with it; but you may have (or not?) noticed
that most of our users today are not like you and i. we became the minority
by a long shot some years ago. we need to continue serving us and those like
us well because we're exceedingly valuable and important to the project, and
as loyal users deserve nothing less. this needs to be balanced with the needs
of our general user base.

having been using this widget now for the last several days it strikes quite a
nice balance here; not to mention i haven't missed the editable-only
alternative one bit because, as a power users, i've discovered the keyboard
shortcut (there's also a button you can click if you'd like) that, much like
F6 does today, gives me an editable bar with keyboard focus. and unlike in
GNME's file dialog these modes of usage are well revealed in the interface.

now, how about support for the statement opposite to the one you note: that
current kde users are not served well by the editable bar? evidence relating
to the poor performance of raw URIs (leading to media:/, system:/ and others
which caused other problems), evidence of breadcrumbs actually working very
well for a broad class of users seems there's a good set of arguments
here. not to mention dolphin's user base, which is rather larger than i
expected to be honest.

of course we -could- find out by trying this that the breadcrumb completely
sucks ass for most people. in which case we just switch to the editable thing
by default. but we'll only know by trying. dare to try and we'll all learn a
hell of a lot more than we do when we jerk our knees about and refuse to
imagine and create new things where problems have arisen.

we should have
locationbar with active parts so you can click on any part of the path,
and drag to any parts of it.

then you end up dealing with appropriate click-drag distances for
editing. there lie dragons. and for the minor difference this presents
from a dual mode bar i don't see the point, though i do see the pitfalls.

Yes pitfalls that's UI design, but as long as you cannot drag the path onto
itself you should be pretty safe. So you can drag away from the path, or
you can drag onto it.

i meant that if you want an editable bar with clickable bits you need to
differentiate between and
click-to-go-to-this-element. and yes, this does mean no dragging of path
elements (though that's probably not much of a loss).