KDE Commit Digest for July 1, 2005
Saturday, 2 July 2005 | Dkite
Some highlights from this week's KDE Commit-Digest (all in one page):
Kopete supports MSN http protocol. amaroK adds support for media:/ urls. Speedups in Krita and aKregator. Work continues on Quanta plugin for KDevelop.
Comments:
kdereview? - Ryan - 2005-07-02
Still no listings about kdereview. I see kdenonbeta and playground, but no kdereview. I'm pretty sure it was listed in the CVS Digest before things moved over to Commit Digest.
Re: kdereview? - Maeztro - 2005-07-05
Well, about kdereview I can tell you that KNetworkConf improved it's Wifi support, now you can configure the WEP key and essid of a wireless interface and we're finishing network profiles support.
system:/ - James Richard Tyrer - 2005-07-02
Regarding "home:/" JRT commented: One thing which the user doesn't need is: "Home". It should be replaced with: "Documents" although I think that it could use a better name (I call mine "USR Home"). There is nothing in the $HOME directory that a user needs to access except when doing administration tasks.
Re: system:/ - Stephen Leaf - 2005-07-02
Home is the user's directory for _everything_ not just files which are for system administration. nor is "Documents" a good name. I for one house very little documents in my home directory, and quite frankly that name would give it the idea that documents is the only thing it can hold.
Re: system:/ - panzi - 2005-07-02
I think he maybe means there should be a "Documents" subdirectorey in $HOME and this should be linked in system:/
Re: system:/ - mmebane - 2005-07-02
"Home is the user's directory for _everything_ not just files which are for system administration" Right. The problem is, home is generally treated like My Documents on Windows, when it is more like Documents and Settings\User\ on Windows. I think sticking a home icon on the desktop is a bad idea for most users. As other people have mentioned, this should be different.
Re: system:/ - mikeyd - 2005-07-02
Why? Where would you suggest should be treated like My Documents instead? Home is the place for everything belonging to the user.
Re: system:/ - Brandybuck - 2005-07-02
Why do we need something like that? We are NOT Windows! We don't have to emulate them!
Re: system:/ - mikeyd - 2005-07-02
Well unless you have some kind of magic users need somewhere to actually, you know, save their documents.
Re: system:/ - mmebane - 2005-07-02
Maybe have a ~/data/ or something?
Re: system:/ - Kevin Krammer - 2005-07-02
Actually that's exactly the path I point my KDE "document" path to. So it is the one showing up in file dialogs.
Re: system:/ - mikeyd - 2005-07-02
Possible, but why? Preferences are all in dot files, so there isn't (to me) any obvious need for a separate directory for "proper files", it's just another five keys to type.
Re: system:/ - Morty - 2005-07-03
The whole thing sounds to me more like someone are trying to solve a made up problem. Lots of work and discussion of something that's not a real problem, based on some strange idea of it being a "usability problem". The Unix way with users home directory and hidden files/folders already makes this a non issue. If the home directory contains visible files and folders not explicit put there by the user, the it's install or distribution is broken. Creating a workaround for this in KDE are rather pointless. Since KDE and Konqueror by defalt don't show hidden files or directories the only thing visible for a new user in $HOME, in a sane installation, are Desktop and tmp. Even newbies does not get confused by that. Anything else are creations of the users, as it should be. It is rather pointless to dream up a usability problem for this to solve.
Re: system:/ - James Richard Tyrer - 2005-07-03
Unfortunately, preferences are not always in dot files and dot folders and there are other files and folders in my $HOME including some that I found it useful to add. But, if you don't have an obvious need to set your: "Documents path" to something other than $HOME, why does that mean that you should say that the same MUST apply to everyone else?
Re: system:/ - Morty - 2005-07-03
Those programs that stores their settings in your $HOME and not using dot files or folders are broken, file a bugreport and get it fixed. It's a bug afterall. If you add files yourself which does not belong in $HOME, why not add them somewhere else? If the files annoy or confuse you, put them somewhere else then. The thing you are after are to hide files from users, and the way to do this already exist. All KDE programs does this by default, until you explicit tells them to show the hidden files.
Re: system:/ - James Richard Tyrer - 2005-07-03
Exactly what is you point? Are you suggesting that we no longer have the option of setting the: "Documents path" to a directory other than $HOME? If that is your point, or implicit in your argument, you certainly have not made a convincing argument. I find it more convenient to have the directories holding my documents, graphics, music, photos, etc. in a directory separate from $HOME. The reason is that there are already over a hundred files or folders in $HOME. Having made this decision, I also find it convenient to have other administration stuff in $HOME. You suggest that I should be forced to have the documents in $HOME and put my additional administration files somewhere else. Why is this better than making a subdirectory for my user files? But, be sure that you understand that what I suggest is permissive. If users still want to set their "Documents path" to $HOME, they can do so. With the "home:/" I/O slave, this is effectively REQUIRED since it is quite inconvenient to do so. What I am suggesting is that we have, instead, a "documents:/" I/O slave that points to the directory specified in the "Documents path" which can be $HOME or a subdirectory of it (wherever the user wants).
Re: system:/ - Morty - 2005-07-03
What my point is, for normal users the current setup with $HOME are already working and the right way to do it. It also have the big advantage it also works with non KDE applications. That some advanced users, like you MAY want to have a different solution for some reason, are not the main point. By making Konqueror and filechoosers correctly follow what you call "Documents path", or the users defined homedirectory setting. And I think it's much smarter to fix this to work as it was supposed to work, than creating a complex I/O slave to do the same job. What I am against is creating some new piece of infrastructure, who really don't bring anything new or usefull for the waste majority of users. Rather than using and fixing the simple and elegant solution already in place, for those few with a different need. All in all, for the waste majority of users it neither usefull, or solves some kind of usability problem.
Re: system:/ - James Richard Tyrer - 2005-07-03
> By making Konqueror and filechoosers correctly follow what you call > "Documents path", or the users defined homedirectory setting. HELLO! 'what *I* call the documents path'?? Do you use KDE?? In the Control Center go to: "System Administration -> Paths". See that third line: "Documents path". This is what *KDE* calls the default working directory: "Documents". Yes, the _current_ default for this setting is $HOME. But, as I said somewhere, it is a design error to design something based on the (incorrect) assumption that the default will allways be used. Doing it wrong might be simple but it is certainly not elegant. Just because the default for "Documents" is $HOME does not mean that it is the same as $HOME. Presuming that it is breaks the current design of KDE. The way it is supposed to work is that the default working path is determined by this "Documents path" setting. When you set this, it is set in: "kdeglobals". So, for it to work correctly, this directory needs to be referred to as "Documents"; it should not be referred to as Home just because the current default is that both reffer to the same location. I do not consider the way I have my system set up to be for advanced users. I think that it is easier to use and therefore suitable for all users. I have a directory that is a subdirectory of $HOME and have the "Documents path" set to the path to that directory. All of my user files are stored in subdirectories of this directory. I have a link on the DeskTop to this directory which replaces the "Home" link. So, when I want to open a file, I don't have to worry about all of the junk in $HOME, I just go directly to the files directory. Isn't this why we have the tree directory structure -- or should we just throw everything in the same directory?
Re: system:/ - Morty - 2005-07-03
Since this works flawlessly for me with $HOME, I haven't bothered to verify the exact wording :-) For all that I care it could have been called "My Stuff", which actually are a much more precise name than "Documents". But i digress, the name is not the important part. And if you actually read what I wrote, you see we agree on the concept of going directly to the files directory. Be it $HOME or $HOME/USR-Home, since the path setting are there it should work correctly for all KDE apps. Even for those with special/advanced needs not using $HOME. But I see no reason to force a new layer of semantics on top of the filesystem(IO-slave). Or forcing a default move away from $HOME, because of some broken applications storing junk there. Anyway, I can't remember last time I saw one doing it. But such an application should have the bug fixed. And by moving away from $HOME by default you create a new set of usability problems, for users not running purely KDE applications. A user with knowledge to change the default directory, will most likely have knowledge to handle the effect of this on non KDE programs. A less skilled user will not, and should not have to face the issue.
Re: system:/ - James Richard Tyrer - 2005-07-03
You still don't get it. If you have your "Documents" directory set to $HOME and you are using "home:/" to reference them you have no problem (except for the label). But, if you change "Documents" to something else (e.g. $HOME/Files), then "home:/" still points to $HOME and you have a problem. OTOH, if you reference the "Documents" directory with "documents:/" which points to whatever you set the "Documents path" to, then it will still work fine if you use the default of $HOME. And (most important), if you change "Documents" to something else (e.g. $Home/Files) then it still works -- it still points to the default working directory specified with "Documents path". Using "home:/" to reference documents is a design error. Yes, currently, the working path only gets set to "Documents" for KDE applications. For non-KDE applications it is still $HOME. This is a bug in KLauncher that needs to be fixed. It is perhaps another example of a design error caused by assuming that everyone would use the default.
Re: system:/ - Morty - 2005-07-04
Ok, now I see what you are really getting at, and where you missed the point. The "Documents" setting should act as default directory when opening anything, like Konqueror as filemanager, any file chooser or the home button when in filemanger mode. Nothing more. The location bar should follow the actual path, like it is today. The creation of another abstraction layer for the filesystem, are the design error. Using a IO-slave like home:/, referring to a arbitrary location is where the mistake is. You already have one abstraction in the form of ~, making another specific to KDE will only cause usability problems with regards to non KDE applications. Will KLauncher change it in the filechooser of a GTK application too? As long as we still live with hierarchical filesystem, it will only cause real usability problems. The users not finding their files in $HOME when using non KDE applications. Since KDE does not follow the standard and define $HOME as something else, like $HOME/Files or something.
Re: system:/ - James Richard Tyrer - 2005-07-04
> Will KLauncher change it in the filechooser of a GTK application too? It already can do this -- change the current directory of a non-KDE application. To do this, you must set the: "path=" paramater in the 'desktop' file. You can do this with the GUI, with the "Work Path" setting either in the Menu Editor or the Application tab of the Properties dialog. Perhaps the user should have a choice of whether or not to apply the KDE default Work Path to non-KDE applications but I don't see how it is going to cause a usability problem if what users are doing is using non-KDE apps with the KDE desktop. I would suggest that it be turned on as the default if it is configurable. I expect to find my GIMP files in: "$HOME/USR-Home/Graphics" and that is where The GIMP stores them as a default. $HOME will not be changed. We could define an additional environment variable USR_HOME (or whatever we want to call it) if we need to. But what will be changed is the addition of a "documents:/" I/O slave that will be a subset of: "system:/" that will point to the base directory for storing the user's files.
Re: system:/ - mikeyd - 2005-07-03
I don't say it must apply to everyone else. However, it's a perfectly good default documents path, and as such there's nothing wrong and a lot right with having an icon for it on the desktop by default.
Re: system:/ - James Richard Tyrer - 2005-07-03
I am talking about the: "system:/" I/O slave NOT the file system. The "home" entry which references $HOME directories should be removed and replaced with an entry which references the directories pointed to by the "Documents path" settings. The "kfm_home" icon is OK (something else would be better [that icon isn't always a house in other themes]) but it should be called something other than "Home Folder". Since the default for the "Documents path" is currently $HOME, this does NOT _require_ that any change be made in how the user's home directory is set up. What it does is _permit_ it to be set up differently. I have my "Documents path" set to something else so I immediately noticed that I couldn't go directly there using: "System". We should never assume that the default will always be what is used. It is a design error to do so. This is not the only place where this applies and this is not the only place that the mistake of assuming that the default will always be used is being made.
Re: system:/ - Bill Kendrick - 2005-07-07
Since it sounds like there's an option for KDE to set a "Documents path" (I'm sadly in front of WinXP at work right now, and can't look at this), this totally makes sense. For example, if I do 99% of my work on some shared drive that's mounted somewhere outside of my $HOME directory, having a quick link via "system:/" to that directory is much easier than navigating there every single time, especially if KDE apps default to load/save files in that location.
Re: system:/ - Kevin Krammer - 2005-07-02
As KDE already has a configurable path for documents (kde-config --userpath document), maybe home:/ should point to that directory. The default is $HOME if I remember correctly, but a distributor or admin could change that if they felt $HOME would confuse their users. In either case it could be necessary for the KDE launcher to change the working directory to whatever home:/ points to prior to launching a non-KDE application. Cheers, _
Re: system:/ - Brandybuck - 2005-07-02
<em>There is nothing in the $HOME directory that a user needs to access except when doing administration tasks.</em> Huh? Not everything in my home directory is a document, unless you count "file" as synonymous with "document". I'll have scripts in there and other executables. I have source code and other stuff. "Document" tells the user that it contains only documents, which is incorrect. On the other hand, "Home" implies that it contains everything the user owns, which is correct. "Home" isn't more difficult to understand. The concept is simple. There is no usability issue here.
Re: system:/ - James Richard Tyrer - 2005-07-03
> Huh? Not everything in my home directory is a document, unless you count > "file" as synonymous with "document". I'll have scripts in there and other > executables. I have source code and other stuff. I don't keep any documents in my $HOME directory. That is, I don't keep any user data files in $HOME, I keep them all in subdirectories of $HOME/USR-Home. The reason for this is that there is a lot of other junk in my $HOME directory. Since you appear to agree with my argument, perhaps you misunderstood. > "Document" tells the user that it contains only documents, which is > incorrect. On the other hand, "Home" implies that it contains everything the > user owns, which is correct. "Home" isn't more difficult to understand. This isn't about a different name for a directory, it is about a different directory -- a directory that might be called "Documents". Since we already call the path to the default Working Directory: "Documents" the I/O slave should probably be called "documents:/"
Re: system:/ - LuckySandal - 2005-07-03
Au contraire, there is nothing in the home directory under most default installations, except dot files, which (take note JRT) ARE INVISIBLE TO THE USER. I create my own directory hierarchy under /home/luke ... i have `/home/luke/documents,' `/home/luke/music'... notice how `music' is not a subcategory of `documents,' at least not in my mind and in the minds of most users, but Bill Gate's mind it is, and that is why nobody actually uses the Windows filesystem hierarchy. I believe this has already been discussed and rejected on kde-usability. I think that "home" is a better metaphore for personal files anyway. I also disagree with home:/ being a list of other users' home dirs. I think it should be a redirection to your home directory. `home:/music'; would better than `/home/luke/music' (supposedly), but `home:/luke/music' is worse. If you want to share files with other users in your group (very few systems are multiuser these days, and even fewer share files between users), why not have it be `user:/john' or something?
Re: system:/ - James Richard Tyrer - 2005-07-03
> notice how `music' is not a subcategory of `documents,' Yes, I noticed. I noticed it long before you posted. IMO, that is why the "Documents" directory needs to be called something else. In the Control Center, it should be called what it is "Working Path"; users can name it whatever they want (perhaps "Files" is a good default). I have: "/home/jrt/USR-Home/Documents", "/home/jrt/USR-Home/Music" and my Documents Path is: /home/jrt/USR-Home. Now the question is: why is your system better than what I suggested? Even if all of the files in $HOME were dot-files, would your system be better? Wouldn't it still be better to have a separate folder for your default working directory. I have over a HUNDRED configuration files and folders in my $HOME directory and, unfortunately, they are not all dot files and dot folders. And these dot files and folders are only invisible to the user when: "View -> Show Hidden Files" is off.
Re: system:/ - LuckySandal - 2005-07-03
> IMO, that is why the "Documents" directory needs to be called something else. So you are basically arguing that because "Documents" is basically a save location for any type of user files (not necessarily "documents" in the proper sense) then it should be renamed. In that case I might actually agree, and I would just set mine to my home directory. However, I currently have my "Documents" path set to (gasp) /home/luke/documents because normally anything that I would not consider a "document" already has a path which its corresponding program is configured to use. But I'm not sure what the creators of the "Documents" path really intended. As for these programs that place non-hidden configuration files in you home directory, I would like to know what they are and if they are configurable. If they are things like legacy console programs that average users are not going to run anyway, I don't see why it is an issue (for instance, you, being an advanced user, were able to solve this problem in your own way).
Re: system:/ - James Richard Tyrer - 2005-07-03
> But I'm not sure what the creators of the "Documents" path really intended. The "Documents path" is the default "Working Path" for KDE applications -- that is what it is so that must be what was intended. Why it is called "Documents path" in the Control Center: "System Administration -> Paths" something I don't understand. Why isn't it called: "Default Working path" since that is what it is? Also note that just because most of the configuration stuff is hidden doesn't mean that it doesn't get in the way. Not everything hides the so-called hidden files.
Re: system:/ - LuckySandal - 2005-07-03
> Also note that just because most of the configuration stuff is hidden > doesn't mean that it doesn't get in the way. Not everything hides the > so-called hidden files. Yeah until recently the KDE folder selection dialog didn't hide them....
amaroK & streams - charles - 2005-07-02
> amaroK adds support for media:/ urls. Does this mean that amaroK will now be able to play streaming media? The las time I checked, I was being asked to do some kind of upgrade (I've forgotten which)! When will the play/pause button be "fixed?"
Re: amaroK & streams - Anonymous Coward - 2005-07-02
Amarok always has played streaming media for me? I can perfectly listen to MP3-streams on the Internet. To see what media:/ does, just type it in your Konqueror URI bar, it will show you a list of all devices on your system (hard drive partitions, usb mass storage devices,...). It is comparable to My Computer on Windows, but it just works for unmounted partitions too.
Re: amaroK & streams - Seb Ruiz - 2005-07-02
THE PLAY/PAUSE BUTTON EXISTS!!!!! All you have to do is change your toolbar settings.
Re: amaroK & streams - Veton - 2005-07-02
Yes ... but it does work with the system tray icon!
Re: amaroK & streams - Ian Monroe - 2005-07-03
Just middle click on the tray icon.
Re: amaroK & streams - Ian Monroe - 2005-07-03
But the play/pause button wants to have little buttonettes with the stop button. Please don't fix it. :(
media:/ kioslave? - anonymous - 2005-07-02
Isn't media:/ a kioslave ? Shouldn't Amarok support this through KDE libs?
Re: media:/ kioslave? - Sergio - 2005-07-02
But engines aren't kde applications, and xine doesn't support kioslaves, so it's necessary convert media:/ urls to file:/ urls
Re: media:/ kioslave? - anonymous - 2005-07-04
ah offcourse :) Thanks for the answer
The Evil Plan!!! - Fast_Rizwaan - 2005-07-02
I with you... :)
fd.o to the rescue - bangert - 2005-07-02
hhm, guess it'd be easy enough to talk to the gnome folks and come up with a solution which works for both desktops...
New KDE 4 Applications... and their naming! - Fast_Rizwaan - 2005-07-02
Chinchilla - a linear movie editor :) shouldn't it be name "KMovieEdit" or "kme" or "KVideoEdit"? My Wishlist: 1. KRichEdit - A Richtext editor. 2. KSoundEdit - A sound editor. 3. KSoundRecord - A sound recorder. 4. KVideoRecord - A video recorder. 5. KVideoEdit - A linear movie editor. (chinchilla :() 6. KUserSettings - A KDE settings (bookmark, app. settings, fonts, etc.) save/restore application. 7. KScreenKeyboard - A Screen Keyboard for users to type unicode text. I really confused by "weird" names for applications. I would better appreciate symbolic names which makes sense. KVideoEdit more describes about the application than chinchilla. ln -sf chinchilla kvideoedit. ln -sf noatun kdemediaplayer ln -sf gwenview kviewimage ln -sf kopete kmessenger ln -sf guarddog kfirewall ln -sf kdehelpcenter khelp ln -sf kolourpaint kpaint ln -sf k3b knero ln -sf k3b kcdburn ln -sf k3b kdvdburn ln -sf amarok ksongs ln -sf apollon kp2p just my thoughts for KDesktopUsers ;)...
Re: New KDE 4 Applications... and their naming! - Mark Kretschmann - 2005-07-02
As a first measure, I suggest: ln -sf Fast_Rizwaan KDEBlogUser
Re: New KDE 4 Applications... and their naming! - Sam Weber - 2005-07-02
If you enable descriptions in the K-menu, you get those nice (imo bland) descriptions. If you all of a sudden start changing names, then people would get more confused.
Re: New KDE 4 Applications... and their naming! - KDEBlogUser - 2005-07-02
>Mark Kretschmann >ln -sf Fast_Rizwaan KDEBlogUser happy? ;)
Re: New KDE 4 Applications... and their naming! - Anonymous - 2005-07-02
The dot is not your personal blog site?
Re: New KDE 4 Applications... and their naming! - Nicolas Goutte - 2005-07-02
The problem of trivial names is that there is a huge probability that they are already trademarks. KDE's trademark problems were all on trivial names. (That is why Krita is named Krita and not anything with "paint".) Have a nice day!
Re: New KDE 4 Applications... and their naming! - Martin Stubenschrott - 2005-07-02
Never do this please, you can have descriptive names in the menus, but why should there only be one kdemediapalyer? And if another program becomes the best kde solution and is included in KDE by default, should we change its name to kdemediaplayer?
Re: New KDE 4 Applications... and their naming! - Anonymous - 2005-07-03
KDE, as you should well realize, is not the first time non descriptive names have been used for objects in every day life. Even your suggestion of Nero would only be descriptive to perhaps learned individuals who know that Nero actually did burn Rome (Rome in Italy) and see the pun. That is hardly helpful to the (possibly less than) average user. This naming scheme also isn't limited to KDE in the computing world, you have Firefox, Konqueror, Opera to name some web browsers. You have Excel, Outlook, Quicktime etc... Despite this I will agree that some applications may follow your desires already, Openoffice Writer, Math, Draw, Calc etc... and you already have many k* applications such as KGet, Konversation, KView, KPDF, KColorChooser, but as has been mentioned what do you name another colour chooser which is maybe better, KColorChooser2 ? How confusing would that be ? In any case do you drive your F*RedneckTransportingTruck or Ford F150 ? I think calling it an F150 is in everyone's best interest. Even the extremely good marketing people at a Japanese company such as... Toyota... have the Avalon/Aventis. Although Avalon was an Island visited by King Arthur it hardly describes a 4 wheeled moving vehicle. And as far as I know Aventis doesn't mean anything although it may resemble some words such as the verb advento(to approach), Aventinus(hills near Rome) or even ventus(wind). So really the naming scheme we have had for quite some time, naming things with numbers, after people, animals, plants, objects, invented words, etc... has worked well and will continue to. After all from the position of a developer, if you are too lazy to read a description, you don't belong using my software. Natural selection may retake its course.
Re: New KDE 4 Applications... and their naming! - Davide Ferrari - 2005-07-04
You're trolling, arent' you?
Re: New KDE 4 Applications... and their naming! - Stefan Heimers - 2005-07-04
Now just strip the 'k's from the names and you end up with something reasonable ;-)
Desktop Users!!! - fast_rizwaan - 2005-07-02
and newbies they just know these words: "song(s)", "video", "mail", "letter", "picture", "cartoon", "document", "internet", and more human names. Yesterday, I saw my one of my friends wishing to hear a song on My KDE 3.4.1 desktop. I had my konsole opened. just went out for a min. And here's what he typed: 1. songs - he wants to listen to songs 2. video - he wants to view some videos 3. picture - to see some family photos 4. internet - to browse internet. But unfortunately, KDE is not HUMAN Desktop Environment. KDE/Unix can't understand humans. I thought why not have a script+kommander application which will show a Wizard/Dialog with options like when he typed "songs" and pressed enter: ------------------------------------------------- Hi there, it seems that you want to listen songs What would you like to do (click on it or press respective number) 1. Play a song... // again a dialog / application (amarok?)appears 2. Search for a song... 3. Record a Song... (from radio, tv, microphone, etc.) 4. Edit a song... 5. Good Bye --------------------------------------------------- Here Amarok is a good application which can find, filter a song. If such a dialog appears, even a computer illiterate HUMAN could use KDE. a bash script + kommander script will work wonder for newbies. just my 2 cents for Human users.
Re: Desktop Users!!! - sv - 2005-07-02
that sounds like waht the developers are trying to do with plasma and ALI you should check it out it sounds like they know that problem and are trying to solve it.
Re: Desktop Users!!! - gerd - 2005-07-02
url?
Re: Desktop Users!!! - Kevin Krammer - 2005-07-02
Plasma is more a concept to integrate the three permant planes (desktop, panel, on-screen display layer) into one unified solution. http://plasma.bddf.ca/
Re: Desktop Users!!! - Anonymous - 2005-07-02
What is bddf.ca? The company behind Plasma?
Re: Desktop Users!!! - superstoned - 2005-07-02
simply the hosting company, i guess. plasma is (check the website) fully developed by the KDE community.
Re: Desktop Users!!! - Kevin Krammer - 2005-07-02
Normal non-Unix endusers don't type commands into shells. They use GUI lauch methods, for example application menus or clicking on files in the file manager. If you think shells should understand those concepts as well, go complain to the shell developers.
Re: Desktop Users!!! - KDEBlogUser - 2005-07-02
that's right, normal desktop users don't use konsole much. A desktop shortcut or Plasma links would be good.
Re: Desktop Users!!! - mikeyd - 2005-07-02
Konsole is just a way of running a shell which is certainly not part of kde. Why didn't he just click the menu button in the bottom left, look through and figure out he wanted multimedia, and then click (again after some looking through) Music Player (JuK), ignoring the part in brackets? That's what people I've introduced to kde seem to do. KDE is human-friendly, it's just the unix shell that isn't. Newbies won't be using the shell. I have a suspicion you're a troll.
Re: Desktop Users!!! - KDEBlogUser - 2005-07-02
>Why didn't he just click the menu button in the bottom left, look through and figure out he wanted multimedia, and then click (again after some looking through) Music Player (JuK), ignoring the part in brackets? cool down dude, my friend never saw KDE at the first place. And he is not a nerd. did you read, "I had my konsole opened. just went out for a min."? btw the 'K' blue icon does not mean anything to a new person. Only you and me know that it is the "Menu" button. Do you think that is human friendly? Try getting someone who've never used KDE+GNU/Linux (and non windows user) and see his reaction in front of your KDE. Perhaps an animated 'K' button with *sparkle* animation every few seconds could attract a newbie's attention leading to kmenu and then to other tasks.
Re: Desktop Users!!! - mikeyd - 2005-07-02
I read it, but I wouldn't go typing in a random program to try and do something, and I can't imagine anyone else would either. If it had been kword rather than konsole would you be making the same complaint? The K icon is in exactly the same place as the start menu on windows, and there's a tooltip that says "click here to start applications". Perhaps some text on the button would be a bit friendlier, but it would take up a lot more space. The bottom left is a fairly obvious first place to start, it's the first of the row of buttons, and the buttons there are clearly part of the DE rather than one application. I think it's a pretty obvious first button to click.
Re: Desktop Users!!! - rinse - 2005-07-03
1. songs - he wants to listen to songs -> he could also have typed this: music (wants to listen to music) track (wants to play a track) mp3 (wants to play mp3-files) 2. video - he wants to view some videos -> he could also have typed this: film (wants to see a film) cartoon (wants to see a cartoon) bambi (wants to see Disney's Bambi) 3. picture - to see some family photos -> he could also have typed this: photo image photos images etc. etc.. 4. internet - to browse internet. -> he could also have typed this: ie website www.kde.org google surfing Anyway, it is crazy to just type random commands if you want to do something Better is to add icons to your desktop with the text [picture] [internet] [songs] [films] A simple way to do that is using a file hierarchie: my documents -> - my movies - my music - my photo's etc. That's how my mom's pc works, if she wants to listen to some music, she clicks on the button 'music', and amaroK starts :)
Re: Desktop Users!!! - James Richard Tyrer - 2005-07-05
This isn't going to work in Konsole without a major AI application. However, I point out that on my system if you click that house in the upper left corner of the screen, that a browser window opens that has icons for: Music Video Photos And you already have a browser window open. IMHO, this is the way to do it. -- JRT
can anybody see full page at - KDEBlogUser - 2005-07-02
kommander documentation: http://kommander.kdewebdev.org/docs/kmdr-basics.html