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.
Dot Categories:
Comments
The background to the main column stops half way accross the right column...
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.
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!
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
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.
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!
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.
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!
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.
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.
> 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.
>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.
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.
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.
"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."
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.
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
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.
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.
"FUSE was added to Andrew Morton's kernel tree in January 2005, and hopefully it will make it to mainline Linux soon."
Well, woo hoo. Still isn't in official Linux kernel though. Furthermore, KDE supports many Unix OS, not just Linux.
"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."
So, you are a FUSE cheerleader. Good for you. How this has any relevance to KDE and Matthias blog I don't get.
Enough.
> 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.
"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.
> 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.
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!
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:/)
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.
"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.
> 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.
>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.
> 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
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 ;)
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!
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!
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 :-)
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!
> 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.
> 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...
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!
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.
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 ;).
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.
(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.
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.
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.
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.
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.
"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?
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.
"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.
"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.
"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.
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.
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