Qt Developer Blogs Launched
Thursday, 4 August 2005 | Jriddell
QDevBlog has launched featuring the thoughts of all your favourite Trolltech engineers. Currently "the ramblings of engineers" has a lead entry from KDE founder and Qt lead developer Matthias Ettrich on some basic thoughts about KDE 4. QDevBlog is also on the increasingly large Planet KDE.
Comments:
blog renders incorrectly in ie, firefox and opera - Steve - 2005-08-04
The background to the main column stops half way accross the right column...
Konqueror criticism - David - 2005-08-04
Matthias is realizing the problems with featureitis in konqueror. It looks like he's realizing some of the benefits of the Gnome philosophy for a while (even though Gnome takes it too far) e.g. xchat vs gnome-xchat.
Re: Konqueror criticism - Anonymous - 2005-08-04
Gnome's approach is easy: they just remove the funcionality, or hide it under the hood. What is hard is keeping funcionality and configurability while making sane defaults with a clutterless and usable interface. I find few merits in Gnome philosophy, really... I need the features!
Re: Konqueror criticism - brockers - 2005-08-04
I agree. For a long time in the development community their has been a non-existant dichotomy placed on software which states that more features means less usability... and visa-versa. While it is true that additional features mean more work to maintain (or improve) usability; having features is not the enemy of usability. Heck, a basic typewriter has only one feature, but its lack of features actually make it less usable. For those that believe Gnome philosophy is helping them... take a look at their desktop percentage as a whole. Their share of the Linux/BSD desktop market is actually SHRINKING. XFCE is taking market share from them because its easy to out-simplify the simply desktop. Functionality and flexability are hallmarks of KDE, and one of the primary reasons I (and 2/3 of all Linux users) use it. Yes, we need to improve usability but not at the expense functionality or flexability. Bobby
Re: Konqueror criticism - Matthias Ettrich - 2005-08-04
Look, KDE is more than Konqueror. If Konqueror gains focus then KDE as a whole gains features, simply because more users will use the dedicated applications. KControl even in its current state is more powerful than the settings io slaves. Or the help center. Or digikam. Or KGet. You guys seem to believe that providing a focused document manager by default will mean a Konqueror in its current form has no longer a place in KDE. I'm not sure where this fear comes from. If you believe in a generic browser for a broad group of users, then you should have faith. Emacs didn't go away when we introduced KEdit. If enough people are willing to develop and maintain a swiss army knife, it will continue to exist. Heck, if you really love it the way it is, why don't you join its development team? Maybe it will have to get launched from some application menu, but that shouldn't be a problem for a power user, should it? I have yet to see a single KDE developer who uses Konqueror and not Konsole for simple file management tasks like copying files. I know I don't. And the reason for that is not lack of features, or the fact that I simply prefer the console. Trust me, I don't, that's why I develop graphical user interfaces. I would love to use a modern file manager if there was one. KDE is a fine and powerful environment with loads of great applications and features. It hurts to see one single flagship application giving it a bad reputation for being overly complicated. And it doesn't do justice to the rest of KDE, with its hundreds of contributors. KDE is bigger than Konqueror, a lot bigger.
Re: Konqueror criticism - Nicolas Goutte - 2005-08-04
Then how are you supposed to use the KIO slaves with Konsole? If you use the KIO slaves (especially floppy:, zip:, tar:), then you cannot use Konsole. As for the fear, well, exactly such an answer is fuel for fears. If really no KDE developer would use Konqueror (which is a wrong assert), then why it should stay for the users. Have a nice day!
Re: Konqueror criticism - Matthias Ettrich - 2005-08-04
Well, for the console there is tar, gzip and the mtools. A less-integrated file manager would simply call ark for zip and tar files. This has as nice benefit of consistency. Ever tried to drop a file into a view shown with tar://? The view claims to accept the drop, but nothing happens. If you hit Control, you'll get a message box in the middle of the screen (sic!) that says "Information, writing to tar is not supported [Cancel]. All fixable, the protocols could be extended to prevent drops from the beginning, the slaves could know about the target window to put the message box in the right position, and and and. Still it's inconsistent: the window looks the same but doesn't behave the same. Most certainly floppies and other removable devices such as usb sticks and cameras must and will be supported in any document manager to come. But this is more about mounting than it is about io slaves.
Re: Konqueror criticism - Nicolas Goutte - 2005-08-04
Then I do not understand why KDE would need a third file manager instead of fixing all these problems. Ark is perhaps nice but it does not view every format either. So, as on console, you would have to unpack to a temporary file and then makes something out of it. (That is what I meant by menaing that you cannot use KIO slave in the console.) That is barely what I would call progress. And if KDE would fall back to separate applications, then what good KIO slaves would be for? I really feel that such a way is very dangerous for KDE, as it drops a major part of what KDE is currently. As for dialogs in the middle of the screen, I do not know where this behaviour comes from. But is this really a reason to re-implement everything? Can this not be changed in Konqueror without disrupting any feature? (And perhaps with an option to keep it in the middle of the screen nevertheless.) (As for mounting, please keep in mind that one cannot mound VFAT on BSD. So simply telling that floppy: is unneeded/redundant/whatever will not be enough.) Have a nice day!
Re: Konqueror criticism - Aaron J. Seigo - 2005-08-04
first, i'd just like to note that i use konq for probably 50% or more of my file management. the rest is konsole. and to be honest, no matter how good a file manager is, i'd still use the command line for certain tasks. less than i do now though. ok.. enough about me: > And if KDE would fall back to separate applications, > then what good KIO slaves would be for network transparent access to files? not only are these used behind the scenes by all sorts of kde apps (think of kio_smtp) but are useful in file dialogs and what not. they would still be useful, and accessable, in a simpler file manager. i think matthias is talking about the ui (e.g. use of kparts) and not the access mechanisms (kio). ark is just a special example of a kio-specific app. i mean, you don't use konqi to browse your email (kio_pop3 or kio_imap) do you? probably not ;) and so the perhaps same with archives. what would be killer would be to have a streamlined but well featured file manager and a single document viewer that is augmented by a few special purpose apps (archiver, web browser (also konq =), etc). right now konqueror-the-file-manager tries to do both of those things and that results in various annoyances.
Re: Konqueror criticism - Vlad C. - 2005-08-04
KIO slaves are not a sustainable solution for accessing network locations because supporting KIO slaves requires a huge amount of work on the part of individual applications. In fact, not even Mozilla Firefox and OpenOffice, which are two of the most widely used applications and which have a strong developer base, have been able to seamlessly access network locations using KIO slaves. Solution: Use Linux-FUSE to access network locations. Enable the Add a Network Folder Wizard to mount network locations using all of the following: 1) SSHFS-FUSE (http://fuse.sourceforge.net/sshfs.html) 2) SMB for FUSE (http://hannibal.lr-s.tudelft.nl/~vincent/fusesmb/) 3) Fusedav (http://0pointer.de/lennart/projects/fusedav/) KDE should automatically detect the presence of SSHFS-FUSE, SMB for FUSE, and Fusedav and use them instead of KIO slaves. Why? Because once mounted onto the filesystem, all apps (even the shell) can access the network files through OS-level system calls. For SMB, the user should be able to browse SMB locations using a minimal implementation of SMB4K (http://smb4k.berlios.de/) that is well-integrated into the Add a Network Folder Wizard. The wizard should allow the user to mount a subfolder of an SMB share. The user should be able to select the mountpoint through a tree-view GUI of the root filesystem, and this GUI should allow the user to create new folders, delete existing folders, and rename folders. The default location for mounted network partitions should be /home/username/network/, and the user should have the option to make the mounting take place at boot-time or only when the particular network item is accessed. The user should be able to unmount and disconnect from a network location by right clicking its folder in Konqueror.
Re: Konqueror criticism - Aaron J. Seigo - 2005-08-04
> because supporting KIO slaves requires a huge amount of work on the part of > individual applications having actually used KIO, i can say that this isn't true. > have been able to seamlessly access network locations using KIO slaves have they even tried? granted, neither uses KDE libraries natively, but the OOo integration project seems likely to result in the use of KDE's file dialog in OOo when run on KDE. > KDE should automatically detect the presence of SSHFS-FUSE, SMB for FUSE, and > Fusedav and use them instead of KIO slaves there's also kio_fuse so this is somewhat nonsensicle. fuse just isn't very widely deployed, and ioslaves are already pretty darn easy to use. > he user should be able to browse SMB locations using a minimal implementation > of SMB4K (http://smb4k.berlios.de/) that is well-integrated into the "Add a > Network Folder Wizard" yes, a browser for knetattach would be very nice.
Re: Konqueror criticism - Vlad C. - 2005-08-05
>having actually used KIO, i can say that this isn't true. The Firefox team seems to find it pretty difficult: https://bugzilla.mozilla.org/show_bug.cgi?id=298848 Please correct me if I'm wrong, but it looks like non-KDE apps have to embed a miniature network client for every protocol they want to support. I've elaborated more in a letter to LKML, and I was referred to the Linux-FUSE project, which perfectly fits what I had envisioned: http://lkml.org/lkml/2005/7/12/209 >OOo integration project seems likely to result in the use of KDE's file dialog in OOo when run on KDE. True, but whenever I open a network file from OO, I get this message: "Protocol 'fish' is supported only partially. Local copy of the file will be created." >there's also kio_fuse so this is somewhat nonsensicle. fuse just isn't very widely deployed, and ioslaves are already pretty darn easy to use. KIO_fuse seems to overcomplicate things rather than simplify them. For example, why do this with KIO_fuse: gimp $FUSE_KIO_GATEWAY_MOUNTPOINT/fish:__you@wherever/tmp/tux.png when you can do this with SSHFS: gimp $SSHFS_MOUNTPOINT/tmp/tux.png The syntax for SSHFS is simpler and its implementation faster, since it doesn't have to go through the fish layer. That's why I think network transactions should be handled by FUSE.
Re: Konqueror criticism - manyoso - 2005-08-05
Quote Vlad C.: "The Firefox team seems to find it pretty difficult: https://bugzilla.mozilla.org/show_bug.cgi?id=298848" That's because you are asking them to include KDE filepicker in gtk firefox. And it isn't because they find the task to _hard_ it is because they simply don't want to do what you ask. Your dog isn't barking.
Re: Konqueror criticism - Vlad C. - 2005-08-05
Quote manyoso And it isn't because they find the task to _hard_ it is because they simply don't want to do what you ask. You may be right. But then this shows that KDE can't _expect_ other apps to use its filepicker, network ioslaves, etc because many will be unable or unwilling to do so. The easiest solution is for KDE to manage the mounting/unmounting of network locations that have been transparently integrated into the filesystem by the OS. Linux-FUSE, SSHFS, Fusedav, and SMB-fuse do just that. If network locations are mounted onto the filesystem (as opposed to floating around in a DE abstraction like fish:/), all apps (even GTK ones) will be able to open/save to network locations, and users wouldn't have to ask maintainers to modify their apps.
Re: Konqueror criticism - manyoso - 2005-08-05
<i>"But then this shows that KDE can't _expect_ other apps to use its filepicker, network ioslaves, etc because many will be unable or unwilling to do so."</i> Sure. But so what. This is true for any library or any project in existence. There is no law mandating that anyone use another projects library/technology that I am aware of. Why this is not obvious and obviously irrelevant to you I do not know. <i>The easiest solution is for KDE to manage the mounting/unmounting of network locations that have been transparently integrated into the filesystem by the OS</i> FUSE isn't the OS. It isn't adopted by OO or Firefox or Mozilla or any of these apps you keep harping about. It isn't particularly well known or anything. Why? Look above. No one has yet mandated a law requiring these apps to use it. I really don't understand why KDE using FUSE instead of KIO in our file picker/saver would motivate Firefox to use KDE's file picker/saver. They aren't using it because they don't want to. Not because KDE's file picker/saver has any technological shortcomings. You really have no dog that will even _whine_, much less bark.
Re: Konqueror criticism - Vlad C. - 2005-08-05
FUSE isn't the OS. FUSE was added to Andrew Morton's kernel tree in January 2005, and hopefully it will make it to mainline Linux soon. It isn't adopted by OO or Firefox or Mozilla or any of these apps you keep harping about. FUSE doesn't have to be adopted by any application to be functional. Firefox, OO, Vim, Bash, etc don't have to make any changes to accommodate FUSE -- they don't even have to know FUSE exists! As far as they're concerned, they're accessing a local file. FUSE completely hides the fact that the file is on a network, and that's what makes its network transparency superb. I really don't understand why KDE using FUSE instead of KIO in our file picker/saver would motivate Firefox to use KDE's file picker/saver. You're right, FUSE won't do anything to encourage non-KDE projects to use the KDE filepicker. But FUSE will let users access network files no matter what filepicker/shell they choose.
Re: Konqueror criticism - manyoso - 2005-08-05
<i>"FUSE was added to Andrew Morton's kernel tree in January 2005, and hopefully it will make it to mainline Linux soon."</i> Well, woo hoo. Still isn't in official Linux kernel though. Furthermore, KDE supports many Unix OS, not just Linux. <i>"You're right, FUSE won't do anything to encourage non-KDE projects to use the KDE filepicker. But FUSE will let users access network files no matter what filepicker/shell they choose."</i> So, you are a FUSE cheerleader. Good for you. How this has any relevance to KDE and Matthias blog I don't get. Enough.
Re: Konqueror criticism - Kevin Krammer - 2005-08-05
> FUSE completely hides the fact that the file is on a network, and that's what makes its network transparency superb Actually this makes it unbearable. Local files are assumed to be fast, they are usually read in one go. Try working with an application that blocks event processing for hours because it accesses a perceived local file through a slow network connection.
Re: Konqueror criticism - Segedunum - 2005-08-05
"Actually this makes it unbearable. Local files are assumed to be fast, they are usually read in one go." Come again? That's what IO slaves are meant to provide! If you'd ever worked in a real work environment you'd know that people work with file over a network all the time, especially over a Windows network, as if they are local. That's expected, standard behaviour. No networking system should ever copy a file locally to your machine, which is how things work at the moment. It becomes even more clear if your try to play a music or video file or anything fairly large. "Try working with an application that blocks event processing for hours because it accesses a perceived local file through a slow network connection." Well, duh. It's irrelevent in the vast majority of environments though. Remember that the application has to access the file though, even if that means downloading it and uploading it back. If your file(s) is even remotely large (a big problem today) you can forget it.
Re: Konqueror criticism - Kevin Krammer - 2005-08-06
> Come again? That's what IO slaves are meant to provide! Exactly! IO slaves provide an asynchronous API because data transfer might take a long time. Making remote files look like local files through FUSE mounting looses that.
Re: Konqueror criticism - Nicolas Goutte - 2005-08-06
The problem exists already today in KDE. If the file systems offers transparentmoving of an old file to a off-disk tape, KDE does not know it. So it starts indirectly a restore from tape to get file info and thumbnail of a file that the users has not used for long otherwise and that indeed was right to move from disk to tape. Sure that it is not the common use for common users but that is a KDE bug. (Sorry I do not remember the number.) Have a nice day!
Re: Konqueror criticism - Vlad C. - 2005-08-05
Quote Try working with an application that blocks event processing for hours because it accesses a perceived local file through a slow network connection. This is only a problem for old-style kernel implementations of network mounting (such as NFS and SMBFS, where you need root access to mount). Indeed, with those you run the risk of hanging your whole system if the network connection fails. However, FUSE is a userland filesystem, which means that the worst you can do is hang the application that is using the network file. I tried this just now: I started streaming an mp3 file over FUSE/SSHFS with Kmplayer, Kaffeine, and RealPlayer. In the middle of the song, I unplugged the network cable. The only application that hanged was the player; everything else ran perfectly. After a minute, I re-plugged the network cable and the music continued playing as if nothing happened! This is a lot better than the fish:/ KIO slave, because with it I couldn't even stream an mp3 in the first place! (Kaffeine said Remote files not accepted. You can only select local files. when I tried opening the same mp3 using fish:/)
Re: Konqueror criticism - Morty - 2005-08-05
From your example I'd say fish:/ KIO salve are a lot better than FUSE/SSHFS. Having the application give a clear feedback to the user, rather than hang for no apparent reason, are always the correct solution. It's basic usability.
Re: Konqueror criticism - Vlad C. - 2005-08-05
"From your example I'd say fish:/ KIO salve are a lot better than FUSE/SSHFS. Having the application give a clear feedback to the user, rather than hang for no apparent reason, are always the correct solution. It's basic usability." This is what should have happed: Kernel detects that network cable is unplugged. Kernel queries FUSE to see if anything was mounted on the network. Kernel finds out what applications were using network files and which network files were opened. Kernel notifies KDE (via D-Bus?) KDE displays this message: Your network cable was unplugged. You will not have access to files previously mounted under ~/network/music. Kmplayer (PID 6955) was reading file ~/network/music/song.mp3 and will remain frozen until the network connection resumes. Do you want to close Kmplayer? That's how integration between Linux and KDE should work. Telling users they can't stream network files (when in fact they can under normal circumstances) is not a solution. I realize that the Linux kernel needs to be improved for this scenario to take place, so it would be nice to see users of kernel functionality (ie. KDE developers) subscribe to the Linux Kernel Mailing List: http://vger.kernel.org/vger-lists.html#linux-kernel and explain what they need from the kernel in order to provide a well-integrated desktop environment.
Re: Konqueror criticism - Kevin Krammer - 2005-08-06
> which means that the worst you can do is hang the application that is using the network file. That's what I wrote. The application assumes that the file has local file characteristics and works with it through the blocking standard file API. Which means it will not process visual updates or user input. I personally like my applications to stay responsive during network operations.
Re: Konqueror criticism - Aaron J. Seigo - 2005-08-05
>but it looks like non-KDE apps have to embed a miniature network client for > every protocol they want to support sucks to be them, then. i'd suggest that they ought to start using the technology available to them via the kde libraries and things become much easier. as for fuse, it is neither widespread nor portable, nor does it have the breadth of kio for protocol coverage. not to mention kio is used for more than plain ol' file system access. a proper system-level vfs would be great. seems kde is one of very few projects that has cared enough to do anything serious about it though.
Re: Konqueror criticism - cl - 2005-08-05
> I was referred to the Linux-FUSE project a) KDE isn't a Linux only project b) FUSE only works on Linux c) AFAIK FUSE isn't even official part of the Linux kernel
Re: Konqueror criticism - Vlad C. - 2005-08-05
a) KDE isn't a Linux only project My proposal was for KDE to detect whether it is running under a system that supports FUSE and only then use the FUSE capabilities. If the OS doesn't support it, then KDE should fall back to KIO slaves for network access. b) FUSE only works on Linux True, but the vast majority of KDE installations are on Linux. Linux has also received backing from corporations, which has led to countless kernel-level usability improvements (such as the ability of non-root users to mount through FUSE). It would be a shame if KDE didn't take advantage of these capabilities. KDE on Linux can (and to some extent already does) make a killer combination on the desktop, but there has to be tight integration and minimal duplication of tools at various levels. c) AFAIK FUSE isn't even official part of the Linux kernel FUSE was added to Andrew Morton's kernel tree in January 2005, and hopefully it will be included in mainline Linux soon. A common disillusionment among kernel developers is: It will take years before userland catches up and starts using new kernel functionality. Well, this is KDE's chance to give them a pleasant surprise by providing a slick GUI for managing network mounts ;)
Re: Konqueror criticism - Nicolas Goutte - 2005-08-04
Using KIO in an application is easy. There is even a few interfaces depending on what control you need. The simpliest ones are KIO::NetAccess, especially the download and upload methods. Have a nice day!
Re: Konqueror criticism - Dawit A. - 2005-08-06
What everyone who seems to advocate FUSE does not seem to understand or consider is the fact that KDE is supports platforms other than Linux!!! Should we simply ignore this fact and make KDE Linux specific ???? Please think about what you are asking before you make a blind suggestion!
Re: Konqueror criticism - Vlad C. - 2005-08-17
Non-Linux users can still use network KIO slaves all I was suggesting is that when FUSE is detected on the system, KNetAttach should give the user the option of mounting network shares with FUSE. The vast majority of KDE users run Linux the kde-linux mailinglist has 300 times more traffic than the kde-nonlinux mailinglist. Why should Linux desktop users be dragged down by the ineptitude of other Unixes that lack desktop-oriented usability improvements at the kernel level? The desire to work *perfectly* on all Unixes is bogging KDE down and causing it to be suboptimal and less usable. I think KDE should integrate tightly with Linux to achieve the best desktop experience Free software can provide :-)
Re: Konqueror criticism - Nicolas Goutte - 2005-08-05
Well, if you want to use Ark instead of Konqueror, then you do not need tar: ar: and zip: and you do not need to implement gzip: and bz2: to be usable from Konqueror (which is a KDE bug/wish that I would like to see implemented in KDE4). When I continue my reasoning, it means that the tar and zip libs are of little use in kdelibs in that case too. They can go back to KOffice and Ark can spare the effort of modifying the code to use them in KDE4. Sure perhaps it would still be good to use KIO slaves for example in Kate or in other applications, but when the main use is "disbanded", then the maintenance of the code will quickly decrease. There is much orphaned code in KDE like this, already today. You can see it at the floppy handling for example. The KFloppy application had reached a state in KDE 3.2 where it became unusable and it is again unmaintained now, after I have tried to fix the minimum. The KIO slave floppy: and mac: have not much changed since months or even years. Other orphaned KIO slaves seems to be ftp: fish: and sftp: where nobody seems to have the knowledge, time and resources to fix them correctly. So hit again the KIO slaves at an important point and there is not much left of a key KDE technology. Sure, the discussion has started in the UI. I am just stressing that such a radical change of the UI, against KDE's history, has repercussions in the heart of KDE, perhaps because Konqueror is also part of the heart of KDE. Have a nice day!
Re: Konqueror criticism - Aaron J. Seigo - 2005-08-05
> The KFloppy application > KIO slave floppy: and mac: yes, i agree that rarely used technology does not get great testing coverage. i don't think this applies to the general subject matter here, however. > Other orphaned KIO slaves seems to be ftp: fish: and sftp: where nobody seems > to have the knowledge, time and resources to fix them correctly. and yet many, many people use them every single day with success, including myself. in the case of fish david committed a few fixes this year, and waldo fixed 12 different issues in the 4th quarter of last year > So hit again the KIO slaves at an important point and there is not much left > of a key KDE technology. whatever; go around and see how many apps use kioslaves and how many ioslaves there are that work well. you're painting a bleak picture where it doesn't exist. i would like to see more maintenance hacking on the ioslaves we have, but it's not exactly like the wheels are falling off them either. > I am just stressing that such a radical change of the UI, against KDE's > history, has repercussions in the heart of KDE, i don't see where Matthias said, "let's not allow the use of ioslaves in file management." i also am aware of a good number of apps that use ioslaves behind the scenes. not to mention the file open/save dialogs ... etc... i think you're missing Matthias' point and striking out at shadows. > perhaps because Konqueror is also part of the heart of KDE. i think it's a huge part of kde. which is why we ought to improve it. there are issues with it right now and we can either close our eyes to that or improve it. improvement does mean "making it suck" either. or "abandoning ioslaves". so leave those straw men at home.
Re: Konqueror criticism - Dawit A. - 2005-08-05
> Other orphaned KIO slaves seems to be ftp: fish: and sftp: where nobody > seems to have the knowledge, time and resources to fix them correctly. Come again ? All of these io-slaves are maintained to my knowledge. At least I maintain the sftp io-slave. If you have a specific problem you want to mention to me I will be glad to look at it...
Re: Konqueror criticism - Nicolas Goutte - 2005-08-06
Well, sorry, I have the feeling that the bugs are stacking up. If you want details, for example, ftp: still does not use NLST to get a simple list if everything else fails. The idea is at least in bug #88575 since September 2004. (There could also be the solution to ask what FTP server is being used and react on this. However not even the check for Windows NT uses that command.) Similar a simple bug/wish like #92589 is not even commented, even if the code seems to have nearly everything that is wished. (The bug is from November 2004.) That is more than 6 months back, so I have to assume that the code is orphaned. Similar all bugs for fish: seems to go more or less to /dev/null. At least I am happy that you claim the maintainership of sftp, so that at least this one will not degrade. Sure it might work for most of people but if the code remain at its stage it will not improve. (As for problems with sftp, yes I had some when I was the KOffice maintainer. After the first try, I have not used it anymore (as I finally used rsync directly), so I unfortunately cannot tell you if there are still problems. Sorry!) Have a nice day!
Re: Konqueror criticism - ltmon - 2005-08-05
Hi, Well I'm not sure I understood all of your post, so forgive me if I misrepresent what your wrote. I don't think anybody is really talking about getting rid of kio slaves. Kio in itself is very useful even if not used from within Konqueror. For example, kio-ipod can be used from Konq to transfer files to and from an ipod ... but due to ipods being tag-based with an index file, rather than simply file based, it turns out to be a usability nightmare. BUT kio-ipod is useful behind the scenes, as Amarok can now use it to transfer files to and from an ipod. Amorok does this with a sane gui, and with kio-ipod available in the background Amarok simply focuses on the gui side of things rather than the ipod protocol. By the same token, Ark provides a better interface for dealing with archives than Konqueror does. But just because Ark is not Konqueror doesn't mean that it can't use kio behind the scenes to give protocol information. A more extreme example: kio-pop exists, but no-one in their right mind is using Konqueror as an email client. Looking forward to your comments :) Cheers, Luke.
Re: Konqueror criticism - Illissius - 2005-08-05
If you're looking for a "streamlined but well featured file manager", perhaps check out Krusader. Coming from Windows and Total Commander (maybe you've heard of it?), I couldn't imagine I would ever find another file manager to replace it; but then I did ;).
Re: Konqueror criticism - renox - 2005-08-06
I fail to see your point, for me it just means that instead of preventing drag and drop to archives, it should be possible to add files in the archive. As long as the window show distinctly that you're browsing/modifying an archive instead of a directory, I don't see the problem (that may be the most difficult part: finding a way to warn the user that he is browsing/modifying an archive instead of a 'normal' directory without being too obstrusive).. A directory and an archive are for me both file containers, they should be handled similarly.
Re: Konqueror criticism - Datschge - 2005-08-05
(Posting here since the blog seems to have choked on this comment's lenght...) I'm concerned about your kind of input you publically give KDE these days. Especially your latest blog entry gives me the impression of a populist (as in 'popular to those who have no idea about what you talk') superficial rant by someone who seems to have lost touch with the pace of KDE community's development. This is particularly sad considering this is not coming from a newbie who doesn't know better but by the project's founder who supposedly should know better and still apparently thinks it's for the better to do a embarassingly improper sweeping blow to the project's community. And that at a time which due to the on-going code porting appears to be one where deep changes can be pushed through by a vocal minority. In your blog you basically devalued the current meritocratic rule "those who write the code, decide" after all. Quotes from the blog: "I dont want to read a manual before using a mobile phone, or operating a DVD player, and I dont have to. Sending an email, receiving some files, translating them and sending them back is in the same league of complexity, and it shouldnt require extensive training, or the need to understand how the system works under the hood." You start trying please. You just can't consider it feasible to dumb down one of the most complex technical tool available to people today to be as easy to use as a phone. And I mean a classic dial phone, for mobile phones you should actually do the crosscheck with someone who isn't familiar with mobile phone what of the phone he is able to use right away. Big fat chances are that he will barely figure out that he'll need to press a button with a green telephone receiver symbol to actually start the call after dialing. Everything else will most likely throw him completely off if he doesn't bother consulting the manual beforehand. In the first part of the 'Window management' topic you raise the issue that nobody likes to do (manual) window managing, and the suggested solution is that "the ideal window manager is the one that you dont use at all. This needs support from the applications." I would never have thought of that... How about supporting the fit-the-window-size-to-the content-shown 'maximized' window mode of the pre-Mac OS X days natively within Qt and suggesting to let the window manager enforce that particular mode by default when showing new windows? Coupled with already existing KDE's smart placing of new windows this basically resolves your issues, no? You go on with secondary windows aka dialogs, failing to mention that within KDE those are avoided whenever possible, and are normally never modal, so I fail to see your actual issue with KDE here unless you just want to badmouth it. Then you go on (rightfully so) praising Apples sheets and drawers as a solution and I have to wonder if you offer such in Qt and should suggest KDE to use that (after all they ought to be supported in Qt/Mac I would think, so why not offer that on other Qt platforms as well?). Then you go to everyone's favorite configuration topic, right away starting with a ridiculous simplification of human preferences: "Sometimes people like to customize something, but thats different. Customization means giving the computer a personal touch, with colors, images, or sounds. Changing the computers behaviour is entirely different." Yea right. Make me a slave of my computer's unchangeable behavior but give me plenty of sweetmeat by pleasing we with my favorite colors, pictures and sounds in return. Way to go! It does not matter that even non-coding people could easily turn KDE into highly customized installations, perfectly adapted to the particularly needed workflow thanks to XMLGUI and Kiosk. No, instead encouraging wider use of these (which would invalidate your "even a community that diverse and large as KDEs cannot ensure basic functionality working in all modes") you instead suggest "KDE 4 is our chance to get rid of all that clutter". And then it goes against the very core what makes KDE a rather special, unique project: "'Those who write the code, decide' is a good rule, but it only works if there is a strong maintainer or group of maintainers with a clear and aligned vision. Many parts of the KDE had this, others didnt. And thats where we see the issues today." And let someone lead us to remove the features people with a vision once implemented, and newspeakingly call that 'vision' as well. Great vision for KDE indeed. Then you go on with the file manager topic. As apparently everyone does, I will also agree with you here that the different use cases for Konqueror need to be more clear cut and be reflected in the GUI. And you know what? Konqueror exactly empowers you to do exactly that, with profiles and the ability to link independent XMLGUI files to those profile. Nobody hinders anyone to create highly dedicated profiles limiting Konqueror to just what is needed in a dedicated web browser, just what is needed in a dedicated file manager, just what is needed in a dedicated FTP client, just what is needed in a dedicated Commader clone, just like what is needed in whatever use case one can come up. But no, like with the above configuration topic we rather shall split everything up, say the issue is with the code while the actual issue is that everyone even including of the project itself (by the way of defaults) fail to make good use of the configuration possibilities. Regarding those I consider the call for "hot coding sessions" to be misled and just resulting in unnecessarily redundant coding which could be better used within KDE where the actual shortcommings are. I call for better documentation, for better user, sysadmin and distro creator documentation as well as better dox within KDE code. Thanks for reading till here.
Re: Konqueror criticism - manyoso - 2005-08-05
Hold on there Datschge! No reason to get personal. I mean if the technical head of TT and founder of KDE can not air a few opinions for the sake of not hurting your feelings, then I don't think it is Matthias that is "sad". Matthias has his opinions. As do I, and as do you, and as do most KDE'ers. I agree with many of them and disagree with a few. You can do so to, but leave the "superficial rant's", "lost touch", "particularly sad" out of it, please.
Re: Konqueror criticism - Datschge - 2005-08-05
Of course I hope he doesn't take it personal, and I actually think that he's doing all that on purpose to trigger more activity (and my fingers are very itchy, need to try to get more time and money finally), but after all rather positive sounding reactions to his overal vague rant I really concerned that this will effect KDE in a bad way. Too many KDE great features are underpublicized, and if those will be removed due to lack of popularity as well as different visions of some brash leaders he calls for it will break my heart.
Re: Konqueror criticism - manyoso - 2005-08-05
Then I suggest you calm down a little bit and try to understand what is actually being said. No one is suggesting jettisoning Konqueror. Just that for those people who would like their applications more modular we should accommodate. Taking Konqui's code and creating three new apps will not reduce functionality. It will just be three new apps. And I sincerely believe that if functionality is lost, people won't use it and will use Konqui. Just because an experiment has a chance of failing doesn't mean we shouldn't try. The upside could be very large.
Re: Konqueror criticism - Datschge - 2005-08-05
And you don't see an issue that this suggestion would lead to three additional more or less independently developed apps from scratch while improving Konqueror to more user transparently offer the same functionality in different profiles could gain the same with the bonus of having a flexible shell framework? Maybe you just didn't get my point. Will calm down now and got to bed, later.
Re: Konqueror criticism - manyoso - 2005-08-05
"while improving Konqueror to more user transparently offer the same functionality in different profiles could gain the same" We already have different profiles and there is a limit to this. If we make profiles __so__ flexible that it effectively creates three different apps at runtime then I fail to see any advantage. The idea of making a profile system __so__ flexible as to allow three different apps in one codebase all switching on/off at runtime is so complex as to be ridiculous overkill. And for what?
Re: Konqueror criticism - Datschge - 2005-08-05
Sorry, but the flexibility basically already exists. It's just that the only default profile even touching it a little bit is the Simple Browser profile, and even that doesn't go far enough imo. Polishing is what is missing. Unless you want completely new features which would both justify creating completely separated applications and would not be an improvement to Konqueror behavior asking for additional independent applications to fix that issue is overkill.
Re: Konqueror criticism - Segedunum - 2005-08-05
"Polishing is what is missing." And what the hell does that mean? "It's just that the only default profile even touching it a little bit is the Simple Browser profile, and even that doesn't go far enough imo." Profiles are not going to work simply because you will always get serious overlap. And if you have profiles and different applications that use exactly the same Konqueror technology, what's the difference? "Unless you want completely new features which would both justify creating completely separated applications and would not be an improvement to Konqueror" They are not completely separate applications. They are applications that use the same common technology that do their respective tasks and do them focused and well.
Re: Konqueror criticism - ac - 2005-08-06
"And what the hell does that mean?" Polishing means adaption of KDE features to specific use cases as well as streamlining existing features. Only the latter needs actual coding. "Profiles are not going to work simply because you will always get serious overlap." Where? Care to elaborate? "And if you have profiles and different applications that use exactly the same Konqueror technology, what's the difference?" The discussion was about the impression that additional new applications are needed. Applications sounds for me like it will be independent from Konqueror, if it's Konqueror based I'd assume it's a fork of Konqueror. Please be aware in these cases I'm talking about the technologies Konqueror offers (in a framework like fashion toward which also eg. KDevelop is moving to), not the technologies which form the base of KDE but are also put to use in Konqueror (KParts, XMLGUI etc.). If everyone is thinking Konqueror should be splitted up even further and its technologies be offered to all KDE apps based on which new applications for dedicated use cases will be formed I'm all for it, but that's something nobody wrote this way so far. The call instead was to get rid of them in KDE 4, by a developer on a developer blog, so I have to assume he's also talking about the under the hood stuff. "They are not completely separate applications. They are applications that use the same common technology that do their respective tasks and do them focused and well." That's also very vague.
Re: Konqueror criticism - Segedunum - 2005-08-07
"Applications sounds for me like it will be independent from Konqueror, if it's Konqueror based I'd assume it's a fork of Konqueror." You've totally misunderstood. You'd have three applications, dedicated for their particular purposes, but would reuse all the common components and code of Konqueror as a whole. Essentially, all three applications would be Konqueror because you'd have serious reuse - with KParts etc. is absolutely first-rate at. Let's face it, Gnome can't hold a candle to the resusable components and architecture KDE has. Those applications would simply cater to different use cases. "The call instead was to get rid of them in KDE 4, by a developer on a developer blog" Well no, I didn't read it that way at all. He was talking about getting rid of file management stuff in a web browser and vice versa, but not removing any of it. Just putting it in sensible places.
Re: Konqueror criticism - ac - 2005-08-07
The part where Ettrich talked about getting rid of whatever stuff was under the configurability topic, not the file manager one. Anyway let's look forward to whatever Ettrich is talking about there: > Ive been discussing design ideas with Zack and Simon, and hopefully we are able to present a prototype of how a modern file manager for KDE 4 could look like.
Re: Konqueror criticism - Aaron J. Seigo - 2005-08-05
there's a reason they are unerpublicized: we hide them too well. imagine if we could expose them more effectively in the GUI so that they were more obvious. one way to do this is to provide a clearer separation between web, file system and document viewers. now, as to how that's done technically .... who knows. i don't think it means abandoning kparts, kioslaves, toolbar configurations, yadda yadda yadda. in fact i think means taking greater advantage of these things to present a more refined presentation of them. i also think a number of people are leaping from a description of a user interface to some sort of automatically negative perception of what it must mean technically under the hood
Re: Konqueror criticism - Nicolas Goutte - 2005-08-06
Yes, indeed, the technology should not be dropped just because somebody does not like the look&feel. (I would probably have been better if I would have written something like this, instead of fearing that KIO slaves would become useless.) Have a nice day!
Re: Konqueror criticism - KDE User - 2005-08-05
+1 from me.
Re: Konqueror criticism - Segedunum - 2005-08-05
Ughh. Right. "Especially your latest blog entry gives me the impression of a populist (as in 'popular to those who have no idea about what you talk') superficial rant by someone who seems to have lost touch with the pace of KDE community's development." He's made it abundantly clear in the past why he doesn't like the way Konqueror does things, the way KControl is organised and he's made it abundantly clear why users in a live environment have found these things difficult and he's explained it. If KDE to move into business, organisations and increase it's userbase these are things that need to be addressed. Which part of that was not clear? I'm afraid you've lost touch with the KDE community, because the KDE community isn't going to attract organisations to using it and isn't going to attract new users and developers otherwise. Matthias works in a *real* work environment - listen. "You start trying please. You just can't consider it feasible to dumb down one of the most complex technical tool available to people today to be as easy to use as a phone." No one's saying it is, but it's quite clear that we can do alot better than Konqueror and some of the things in KDE. "Make me a slave of my computer's unchangeable behavior" What makes you think that you would be a slave and things would be unchangeable? You got one word right in that sentence - me. That's what *you* think. "It does not matter that even non-coding people could easily turn KDE into highly customized installations, perfectly adapted to the particularly needed workflow thanks to XMLGUI and Kiosk." Since you replied to me in one comment about usability studies, have you done one or at least observed users in a live work environment? "Then you go on with the file manager topic. As apparently everyone does" There's a reason that *everyone* does, as he's explained. "And you know what? Konqueror exactly empowers you to do exactly that, with profiles and the ability to link independent XMLGUI files to those profile." Your arguments really are shown to be crap right there. There's a massive, massive, huge difference between empowering people to do something and actually doing it. Profiles simply do not cut it, because there is too much functionality that is different between file managing, web browsing etc. Empowering people in an application like a file manager or a web browser is a total cop-out, because you know it's wishy-washy crap. Either it's a file manager or it's not or it's a web browser or it's not. That doesn't mean that you don't have common components between each (what Konqueror is really good at), but you focus on one main thing and do it well. That is a central Unix/open source philosophy. "Nobody hinders anyone to create highly dedicated profiles limiting Konqueror" But those profiles have to be created, and even then there is functionality that is simply not common between different use cases. Do you need cookie and security settings in a file manager or vice versa? No, of course you bloody dont. "Nobody hinders anyone to create highly dedicated profiles limiting Konqueror to just what is needed in a dedicated web browser, just what is needed in a dedicated file manager, just what is needed in a dedicated FTP client, just what is needed in a dedicated Commader clone, just like what is needed in whatever use case one can come up." But all that is simply not being come up with because you simply cannot separate and add what you need from and to Konqueror. It's too much of an overarching application. "say the issue is with the code while the actual issue is that everyone even including of the project itself (by the way of defaults) fail to make good use of the configuration possibilities." Funny, funny, funny. It's all the users' fault! They're not using KDE properly! Please do get your head out of your arse. If people are <quote>failing to make good use of the configuration possibilities</quote> continuously, then that should at least tell you something is wrong. And just how much *configuring* should an average person do exactly? If you have to configure something too much then it simply isn't usable. "Regarding those I consider the call for "hot coding sessions" to be misled and just resulting in unnecessarily redundant coding which could be better used within KDE where the actual shortcommings are." Errr, those are shortcomings. "I call for better documentation, for better user, sysadmin and distro creator documentation as well as better dox within KDE code." Document what exactly? From what you've written you don't document anything other than "Configure it to do what you want.", "You can configure x from here, and also from here as well, oh and also from here.", "You need to go through several levels of dross to configure this, but if you don't want the dross you can configure it" or "You can edit this file here...." "I call for better documentation, for better user, sysadmin and distro creator documentation as well as better dox within KDE code." Yer. Absolutely wonderful documentation that would make for a sys admin. You do realise that a sys admin needs pretty clear documentation, don't you? And you don't cop-out with the 'distro creator' stuff because KDE cannot lump things on to the shoulders of distributors. That tac has clearly failed because you end up getting something that isn't integrated, doesn't work well together and ends up not being KDE at all. What Matthias has described is KDE's fault in its own back yard, and no one can solve it apart from KDE.
Re: Konqueror criticism - Vlad C. - 2005-08-05
>If Konqueror gains focus then KDE as a whole gains features, simply because more users will use the dedicated applications. Totally agree. I think there should be more focus on perfecting the bread&butter functions of Konqueror File Manager (ie. managing files ;). For example, you can't cut, copy, paste, trash and delete in the tree view using the keyboard and you can't rename folders using the mouse: http://bugs.kde.org/show_bug.cgi?id=80584 You also can't paste anything into the Home Folder by right-clicking on its icon because apparently the Home Folder is not a folder, but a link. Here's a solution: Konqueror should be modified to show the Root Folder sidebar by default. When the user first opens Konqueror, their home folder should be selected and expanded. The only folders visible should be /, /home, and /home/username. Everything else should be hidden and expandable if the user clicks on the Show system folders tick. Conversely, there should also be a Hide system folders tick when the system folders are expanded. The appearance of the ticks should be configurable by right clicking and from Konqueror's main configuration. All the actions that can be performed on a folder in the right-side panel should also be performable on a folder in the sidebar tree-view.
Re: Konqueror criticism - Hasso Tepper - 2005-08-05
> Heck, if you really love it the way it is, why don't you join its > development team? Because I have enough projects to take care of? I can't join teams of every software pieace I use and like ;). > I have yet to see a single KDE developer who uses Konqueror and not Konsole > for simple file management tasks like copying files. I do. Although I have to have normal mouse for that - touchpads etc. don't count. If I have to work with laptop without external mouse, I prefer keyboard as much as possible and therefore use Konsole mostly.
Re: Konqueror criticism - Derek Kite - 2005-08-05
I have yet to find a graphical file manager that works as well as the console. Although there are some things in Konq that I find compelling and useful. I dare someone to match the simplicity of this command in any graphical environment: rm *~ or ls *.bin, or *.jpg, or *.pl or even tar -zxf (first couple of letters) [tab][enter] These are a few of the things I do regularly and quickly. On the other hand being able to click on a *tar.gz file to browse it's contents is seriously slick, or previews of images, text files, etc. The most frustrating thing is the time it takes to get to the file I want. There is a vast potential for improving KDE. Getting rid of a few toolbars or tidying up some dialogs ain't gonna cut it though. These are difficult problems, and the audience is tough. Derek
Re: Konqueror criticism - Dawit A. - 2005-08-05
I will bite... :) > rm *~ In Konqueror: Type *~ in location bar Select all temp files and delete OR Filter your view using the dirfilter plugin Select all temp files and delete Granted it does not beat rm *~ which is a single command, but I want to see someone come up with an easier way to do this in any graphical environment!!! > ls *.bin, or *.jpg, or *.pl Same thing here!! Type *.bin in the said directory under Konqueror or use the directory filter plugin. I definitely need to write some blurb about how to use the directory filter plugin as people seem not to use this useful plugin at all. Of course that is a shameless plugin on my part... > tar -zxf (first couple of letters) [tab][enter] Split the current view in Konqueror. Browse into the archive and Drag and drop the folder into the other view... I know some of these require multiple steps in GUI, but it is just as simple to do in the GUI as they are on the command line. Now if you had given an example of piping results of one command to another, then... Just today I had to do find . -name "*.ui" | grep -v -e Base which is not easy to do in GUI, but then again every tool has its own purpose...
Re: Konqueror criticism - pingu - 2005-08-06
Hmm, interesting Idea though, WHY NOT USE THE KONQUEROR ADDRESS AREA TO TYPE IN COMMANDS EXACTLY LIKE KONSOLE. LIKE LS *.JPG, TAR ZXVF, ZIP, UNZIP ETC ? that way onsole is embedded in the address bar, and you can do everything in konqueror. those commands can also be configured to open the output in another tab of konqueror instead of present tab for tar etc. or when one does tar zxvf files.tar.gz * another pane of konqueror shows caption as 'adding files to files.tar.gz' if we keep the commands common to konsole and konqueror then what ever can be done in konsole can be done in konqueror too. this should be th type of konqueror in kde 4 :)
Re: Konqueror criticism - Salsa King - 2005-08-06
<I>For those that believe Gnome philosophy is helping them... take a look at their desktop percentage as a whole. Their share of the Linux/BSD desktop market is actually SHRINKING. XFCE is taking market share from them because its easy to out-simplify the simply desktop</I> have you any stats to back that statment up?
Re: Konqueror criticism - James Richard Tyrer - 2005-08-05
Yes, power users want the features and newbies want something as simple as Firefox. This should be easy to do with multiple configurations of Konqueror. Note that to do this, a design error needs to be fixed. The View Profiles: "filemanagement" & "webbrowsing" are part of the code -- you can NOT change the default Profile for "File" or "Web" even by hand editing a configuration file. This is a bug and it needs to be fixed.
Re: Konqueror criticism - mhn - 2005-08-04
If I understood this correct, the main point has to do not with the 'gnome approach', but with the technical maintainability of all the miriads of possible setups. It's impossible to test them all. Of course, perfect software is flexible as a matter of nature, so it doesn't need testing anyway. But nobody has written perfect software yet.
Re: Konqueror criticism - Ian Monroe - 2005-08-04
No, it has to do with usability.
Re: Konqueror criticism - Aaron J. Seigo - 2005-08-04
you're both right.
Re: Konqueror criticism [Source for hp's comments] - coulamac - 2005-08-05
I think David is pointing to Havoc Pennington's eerily similar comments located under the "The Question of Preferences" section of this article: http://ometer.com/free-software-ui.html So, I suppose there are a few questions: 1) Are Pennington and Ettrich saying the same thing? 2a) if so, do people agree with the software philosophy espoused by Pennington and Ettrich? 2b) if not, how do they differ? 2) if the Answer to number 1) and 2a) are "yes", what about the implementation of the philosophy by GNOME do people find undesirable, and how can KDE do it better? Cheers!
Re: Konqueror criticism [Source for hp's comments] - Datschge - 2005-08-05
I don't remember Pennington ever dissing KMail's non-focus MDI as bad usability so they sure are not the same.
Re: Konqueror criticism [Source for hp's comments] - coulamac - 2005-08-05
Hmmm... it seems that Pennington, a GTK+/GNOME developer, (mostly) used GNOME examples of (allegedly) bad usability to make his point. Here it seems that Ettrich, a Qt/KDE developer, is using mostly KDE examples of (allegedly) bad usability to make his point. So, each developer targeted his own desktop to make his point. That seems similar to me. :-) Criticism of a project by one of its own members should be respected if the criticisms are meant to be constructive and lead to improvements. I understand Ettrich's blog comments to be constructive and to attempt to make KDE better for 4.0. Whether or not you agree with his criticisms is a completely different matter, of course. That is where the debate over the content of the criticisms is important. Just my thoughts on the matter.
Re: Konqueror criticism [Source for hp's comments] - Datschge - 2005-08-05
I consider his criticisms as uninformed sounding thus misleading, too vague and counter-productive rather than constructive, but I guess that's abundantly clear from my lenghty post further above.
Re: Konqueror criticism [Source for hp's comments] - Segedunum - 2005-08-05
"I consider his criticisms as uninformed sounding thus misleading, too vague and counter-productive rather than constructive" Vague? Oh yer, that wasn't vague at all.
Thanks Matthias - David - 2005-08-04
Decent down-to-Earth guy that Matthias Ettrich. He's said some things that needed saying there, and it's nice that he's 'actually seen' users using KDE in an environment to get work. Trust me, once you've done that things take on a different perspective.
Re: Thanks Matthias - Waldo Bastian - 2005-08-05
Sure, I have seen the videos [http://primates.ximian.com/~pete/GUADEC/wms-guadec-2005.sxi], however the solution to that problem is a data-driven development process were design decisions can be taken based on feedback from actual usability testing. There are people doing that [http://www.openusability.org] and they actually help KDE to become better. That's hard work. Blog entries like this are entertaining but do little to fix any problem. KDE has had a mailinglist list for a long time were usability was supposed to be discussed and that was filled with armchair usability experts just like Matthias, it has done very little to make KDE better.
Re: Thanks Matthias - Segedunum - 2005-08-05
I totally sympathise Waldo, but it just seems to be very difficult to convince some developers of the need to see users out in a live environment or to convince them to listen a bit to users who have. They may seem like armchair usability people, and some are, but a lot aren't. You might say that the people who write the code decide, and you'd be right. But to write code to make usability better in KDE you need to have existing developers on your side, and a lot just don't seem to be. Konqueror is a classic example. Many developers seem to be very, very confused about the difference between a kitchen-sink, swiss army knife Konqueror and the code re-use that Konqueror has between itself and different applications. That's what's needed - reuse of different components, not an all-in-one everything application. It's nothing very difficult. They are things he's described there that you can solve within about a week, including talking time, if everyone pulls in the right direction.
Re: Thanks Matthias - Datschge - 2005-08-05
You are dodging Waldo's point that it's usability studies what matter. Listening to a couple of users is not the same.
Re: Thanks Matthias - Bryan Feeney - 2005-08-05
What are usability studies <i>except</i> listening to (and observing) users?
Re: Thanks Matthias - Derek Kite - 2005-08-06
Have you ever watched an inexperienced user working with something moderately complex like a spreadsheet? The user would be totally lost. Many never again touch spreadsheets. But the spreadsheet was the application that established desktop computers in business. Just to illustrate that usability is very complex. Specialized applications require special knowledge to make usable. User experience helps, but what user doing what? Derek
Re: Thanks Matthias - anonymous coward - 2005-08-06
Doing so on a grander scale. It is important to be aware that there are different kind of users, different kind of use cases for computers, and different user behavior and expectations in different regions and countries. KDE has always been listening to a couple kinds of users which are techno savy and/or motivated enough to report their issues directly to developers, to mailinglists or to bugzilla. Those users however doesn't give you the whole picture, nor does listening to users in your particular environment do so. This is the differentiation I do between (good) usability studies and (armchair usability observatios through) watching a small amount of users. Please note the talk about the study Waldo linked in his post, it takes most of this all into consideration.
Re: Thanks Matthias - KDE User - 2005-08-06
It's suicide to listen to those mythical dumb users who aren't motivated enough to even know what KDE is or how to provide feedback, when you have REAL users and a REAL community right here and right now giving you feedback. Alienating REAL users in the hopes of capturing a larger market share from the sheeples is just plain foolish for a project like KDE.
Re: Thanks Matthias - ac - 2005-08-07
Well said.
Re: Thanks Matthias - mhn - 2005-08-05
I think datschge meant to underline _a_couple_, not _users_
Re: Thanks Matthias - Segedunum - 2005-08-05
"You are dodging Waldo's point that it's usability studies what matter." Err, that's what I said. You're totally dodging the issues in that post. "Listening to a couple of users is not the same." Did you read what I wrote? I didn't say listen, I said watch, and preferably listen as well. I doubt very much whether you've even listened to a couple of users with all the crap you've posted, and that's the point. I think you're secretly hoping to ask for massive usability studies that will be difficult to undertake for most so they'll get bogged down, and then it can all go away. It won't. You can't just pluck usability studies out of the air.
Re: Thanks Matthias - will - 2005-08-07
Certainly, usability studies is the way to go, but there are a lot of things that can just be just implemented because it is common sense from a usability perspective. The first elementary step is just to remove, remove and remove. I think much of this falls in under that category. The usability discussions in KDE goes nowhere, but the problem with them not primarily that there are "armchair" usability experts. That would have corrected itself if the discussions had any consequences for development. I think that you fail to realize that the real problem is of a political nature - it is the fact that the decisions are made by engineers with a different agenda than ordinary users. For just this reason comments like this probably what is needed the most - an opinion from someone that really has the power to influence. In a discussion that calls for change, it is common that the defender of status quo attempts to dissmiss the discussion, rather that face up to the problem posed. That is what you have chosen to do now, even if it rather implausibly means questioning Matthias' professional crediblity in usability issues.
Damn you Matthias ;-) - Bryan Feeney - 2005-08-05
You stole my idea! http://dot.kde.org/1120343862/1120354997/1120381902/1120465909/ As you can see, I whole-heartedly agree. The compromises made to Konqueror in trying to be a generic file-viewer (an acceptable extension of the web-browser idea in my opinion) and a file-manager have made it more awkward to use. I also like the way you referred to Microsoft, I think they really hit on something with their "task-driven" interface (yes, even evil Micro$oft gets it right once in a while). I remember going over some stuff with my Dad. I asked him did he know how to copy a file (expecting him to reply Edit->Copy) and he pointed to the obvious "Copy File" item in the "File and Folder Actions" section of the side-pane. KDE really has all the infrastructure to make this work. You could have an side-pane, with [File/Folder] Actions =================== Open Open with program (pops up a dialog with all appropriate programs) Rename [finsh off with Actions taken from the actions submenu in the context menu] Common Places ================ *My Home *My Group (home://) *My Devices (system:// or drives://) *Audio CD Files (audiocd://) (be intelligent, and don't show if no audio CD?) Details ================== [The meta data from the tooltips/propertys window] Of course, this all relies on being able to select a file. Personally, I think single click select, double-click open is the only way to go there, although there is an argument, in the file-manager only, to let the middle-click button open items (even folders) in their application / a new window. In the file-viewer (konqueror) it would make more sense to have it open items in a new tab of course. One other thing I saw that looked good, and taken from the ideas for the NeXT file-manager via Thunar (http://thunar.xfce.org/wiki/ui:suggestion-20050320) is a series of bread-crumbs to work your way back. However instead of buttons have what appears to be a text-edit (though really a HTML pane) with each folder a hyperlink and a > icon between each item. For people who like to type in paths retain the clear button by the text-edit: the use-case then is a user hits the clear button, the bread-crumbs disappear, they type in a path, hit enter, and the path is changed to the bread-crumb hyperlinks as the location appears. With regard to copy and paste, I think big copy and paste buttons on the toolbar should do the job.
Somewhat disagree - LuckySandal - 2005-08-06
I am a power user who happens to _like_ the integration of a web browser and file manager. The one thing I cannot stand about Windows/GNOME is that you can type a URL into the file manager, which at least on Windows is supposed to be one with the browser, and the application acts totally different than if you had started it in web browser mode. I was also thoroughly pissed when I installed the new version of KDE and found that Konqueror was configured to used that obnoxious listbox-like Ark part for viewing archives, instead of a standard/modern icon view. I want to have a consistent interface when moving files around, whether inside or outside an archive. The thing I like about Konqueror is the KParts. I like, for instance, that I can view a PDF file in the *same window* as a regular web page. That solves some of the window management issues discussed, for less windows to manage means less inefficiency & frustration, no? I think Matthias is missing the trees for the forest. He sees the big picture of Konqueror being unusuable, but he forgets the simple ways in which it could be made more usable. On the topic of displaying sizes and permissions for pseudo-filesystems, so what? This could be solved with a simple patch that causes that information not to be displayed unless the ioslave provides it. This is how it should have worked to begin with. Or how about a sidepane that one can say is interactive and still maintain a straight face? And yet we are talking of forking Konqueror into two separate applications for such trivial causes? It seems the real problem is that Konqueror has not yet become a mature file manager, not that it is one with the web browser. I understand that the new users see browsing and file management as two separate applications. This has not been solved with view profiles, however, simply because the current view profile implementation is highly defective. For instance, click on Settings->Load View Profile->Simple Browser. How much "simpler" is the simple browser? Not at all. Nothing happened, did it? The simpler XMLGUI file that is supposed to load, doesn't. How was this overlooked in the last two KDE releases? I am not trying to beat up on Konqueror, but we need to at least have features working before we can draw conclusions about their usability - no need to attack a straw man. The swiss army knife analogy was apt for this precise reason. If profiles for one worked the way they were supposed to, then it would be more like a single-blade knife that suddenly morphed into a screwdriver as needed.
Re: Somewhat disagree - KDE User - 2005-08-06
>I was also thoroughly pissed when I installed the new version of KDE and found that Konqueror was configured to used that obnoxious listbox-like Ark part for viewing archives, instead of a standard/modern icon view. I want to have a consistent interface when moving files around, whether inside or outside an archive.< Couldn't agree with you more! Another pet peeve is when Konqueror opens up images or text files in EXTERNAL viewers. Totally lame and not integrated. It can't be rocket science to open text and images directly in the browser.
Re: Somewhat disagree - LuckySandal - 2005-08-06
> Another pet peeve is when Konqueror opens up images or text files in EXTERNAL viewers. Totally lame and not integrated. It can't be rocket science to open text and images directly in the browser. < Yes, I also alluded to this in my first post. I think the best way to handle this is to have a _global_ option of whether to open files in an embedded viewer or an external application, not for each individual mimetype. What we need is real work on Konqueror as opposed to just KHTML. There are five-year-old Konqueror reports on bugzilla that still have not been addressed. For instance, http://bugs.kde.org/show_bug.cgi?id=3212 . I posted a patch that fixed this one, but it was completely ignored as are most.
Re: Somewhat disagree - Morty - 2005-08-06
There is a global setting for text type files for this, I don't have a recent KDE available at the moment. If you open open the properties for a text type file, and open the edit mimetype dialog. Under embedding tab in the left click action, you can set it to follow a acction for generic text files. I think this is set as default for most text filetypes, making it more or less default and you can at least set it "globally" for those. Not exactly what you want tho. Personally I don't think a global setting for this are a good solution, as it a one-size-fits-all approach which does not really fit with the differences in workpattern concerning various filetypes. Having an easier way to rapidly set this would be a better solution. A simple list of all the different mimetypes where you could choose to embed or not embed, making it possible to customize this feature in a minute or two. Since you can never get defaults to satisfy most power users, it's better to make it easier for them. But not excluding having good default, and perhaps the defaults for embedding need a review. What really bugs me with embedded previews are the lack of automatic zooming of pictures, the default for preview of a picture like a jpeg are 1:1 scaled. Rather useless when clicking on large pictures. The default should be fit to window, making the whole picture visible. I guess you can configure it, but it's about sane dafaults as I think most users will expect this.
Re: Somewhat disagree - Dawit A. - 2005-08-06
Perhaps you should first ask whether there was a way to display this files embedded or not, no ??? 1.) ALT+F2 and "filetypes" 2.) See the attached picture for details Anyways, everyone and their mother seem to want to pick on Konqueror... I guess it is the in thing to do these days...