-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    LinuxDaily.com    Linux42.org    OpenSkillz.com   
 
Apps
News
Groups
Knowledge
Events
Forum
People
Jobs
Register
Login

-
- Poll . 

Your expectations for KDE4?


Posted by Yaba on May 15 2006
A revolution. It will set new standards.35%35%35% 35%
It will become the best DE ever!14%14%14% 14%
Better than Vista, not as cool as Mac OS X9%9%9% 9%
Much better than KDE 3.510%10%10% 10%
Somewhat better than KDE 3.5 but will need time to mature9%9%9% 9%
Don't know.5%5%5% 5%
First release might be pretty buggy.4%4%4% 4%
Waiting for KDE 4.23%3%3% 3%
I am afraid that people might overrate it.3%3%3% 3%
People might be dissappointed.2%2%2% 2%
Current expectations are too high.7%7%7% 7%
Votes: 1507
goto page:  1  2 

-
.

 A revolution

 
 by ATAHUALPA on: May 15 2006
 
Score 50%

For the Human effort employed, It SHOULD set new standards :)


"no quiero demostrar nada,solo quiero mostrar"
Federico Fellini
http://es.arcoiris.tv/

Reply to this

-
.

 pros and cons

 
 by soulrebel on: May 15 2006
 
Score 50%

many things look promising, but others frightening.
i really like the small new stuff, like yakuake and katapult (which really boost usability), also the eyacandy here and there (the bubble-tooltips etc), but other things i really hope are not going to be default.
all this new hardware and filesystem abstraction happening in the user interface is horrible. the media:/ kioslave for example is ok, as long as double-clicking a drive, mounts the filesystem and then opens its mounted directory, but using these system:/media/cdrom0 things is absolutely horrible! no application whatsoever understands this, ever try to open a cd from the desktopicon and then a file from within with any application? not even most kde apps understand these addresses, openoffice, gimp or vlc will probably never.
why are these things done?
whats wrong with just showing the 'real' directory?
why is home:/documents easier then /home/username/documents ?
whats the point of hiding the unix filesystem hierarchy?

also whats the point of PHONON? i really think its going to be an artsdv2, with all its flaws, because the concept itself is flawed. why can i not just set the media-engine per-application? it works well now doesnt it? so if kaffeine and amarok and juk and so on use gstreamer now, why would i want to squeeze another programming layer inbetween? its no benefit, just another source of bugs!
then if something goes wrong with it, the media-system will be completely screwed. right now at least i can choose between the backends in the apps, and if something breaks there is always an alternative to move to. if phonon breaks, tough luck.

please dont understand this as dissing or sth. like that; i really like kde and have used for years(...), but i just see development going the wrong directions in some places.
please do not try to immitate vista or macosx, but try to become an independant good-looking and feature rich DE; most importantly do not try to hide the underlying os with makeup, it might seem easy for the newbie, but instead makes understanding unix much harder in the long run (and is a pain interaoperability wise).

sorry for the long post.
greetings
soul_rebel


# cd /usa/whitehouse
# rm -rf *

Reply to this

-
.

 Re: pros and cons

 
 by illuminatus23 on: May 15 2006
 
Score 50%

I conclude w/t you. Esspecially when it comes to the part "Oh, the user might be too stupid for that, let's hide it..." This sounds like GNOME-developing, doesn't it?

Another thing i hate ist the "System Settings" Replacement of kcontrol (dunno if it comes with others distros than kubuntu too). It's just a unneccesary reducing of abilitites. kcontrol might be complicated for noobs, right. But why don't allow noobs to learn?


Reply to this

-

 Re: pros and cons

 
 by sirtalon on: May 15 2006
 
Score 50%

"also whats the point of PHONON? i really think its going to be an artsdv2, with all its flaws, because the concept itself is flawed. why can i not just set the media-engine per-application? it works well now doesnt it? so if kaffeine and amarok and juk and so on use gstreamer now, why would i want to squeeze another programming layer inbetween? its no benefit, just another source of bugs!"

What Phonon will do is pretty much move that abstraction code out of those applications and put it in a common kde-wide library. This will REMOVE duplicated effort, and make it much easier to do common audio related things (look at the sample of juk's aRts implementation vs Phonon implementation, the Phonon one is MUCH simpler). Also it will most likely be possible to override which engine to use on a per-application basis (though whether or not that application exposing the choice to the end user depends on the app devs).

Phonon also means that when GStreamer breaks ABI compatibility (which they did with 0.10, and are talking about doing again), KDE doesn't have to fork GStreamer and end up with another aRts. Also for the people like me that have NEVER had gstreamer work for them (IMHO gstreamer is worse than aRts, at least aRts will play sounds on my laptop, and works perfectly fine on my desktop) they can chose Xine.

In short Phonon means less duplicated effort, the ability to manage audio of many applications at once (i.e. sound categories will allow a volume manager program to adjust the volume of system notifications when you're talking on a VoIP program, or combined with Solid will switch the VoIP program to use a headset you just plugged in depending on your settings). I like Phonon because I will be able to pretty much replace aRts with Xine on my laptop and desktop.


Reply to this

-

 Re: Re: pros and cons

 
 by soulrebel on: May 16 2006
 
Score 50%

i am not trying to be pessimist here but i think that what phonon is designed to do, is a really(!) difficult thing. afterall its supposed to channel all sorts of media (also video) through a rather large number of backends. this means that on both sides (input + output) it has to be 100% flexible.
-> a lot of code -> lots of possible bugs -> instability.
as soon as it stops working on some computers application developers will start making there own implementations for music-engines again ...
also making phonon compatible with so many backends will reduce their individual features. will i be able to use phonon to transcode video? will phonon be slim enough to not slow this down additionally?
or will i then have to resort to a direct gstremaer/xine/whatever implementation?
talking about backends, why not pick one and trough focussing developement on that one provide an easier-to-maintain, slimmer and more stable interface for media-apps?
what about vlc(videolan)?
1) i havent seen any formats or codecs that it doesnt support, matter-of-fact i have seen no application or media-engine that supports an equal number of input and output file/codec-combinations.
2) it is portable, afaik it works on all currently supported kde platforms and also possible future platforms (win and osx)
3) it is smaller than gstreamer and only a little bigger than xine.
4) its very stable (at least from my experience)
5) its 100% about streaming,
-> it can be used to transcode from anything to anything. think about adding menus to all mediafiles...
-> also it has superb network functionality built it. just imagine being able to stream and recieve through your lan or internet by pressing a single button in you media-app....

now with the abstraction required to support 10 different backends in phonon, do you think stuff like that will be possible?

if yes and the phonon-devs prove me wrong, iwould be more than happy :)


# cd /usa/whitehouse
# rm -rf *

Reply to this

-

 Re: Re: Re: pros and cons

 
 by sirtalon on: May 16 2006
 
Score 50%

"i am not trying to be pessimist here but i think that what phonon is designed to do, is a really(!) difficult thing. afterall its supposed to channel all sorts of media (also video) through a rather large number of backends. this means that on both sides (input + output) it has to be 100% flexible.
-> a lot of code -> lots of possible bugs -> instability."

Kaffeine already does this and it works very well (despite originally being written just to use Xine), Amarok and Juk already does this (though for audio only) and they work pretty well.

"also making phonon compatible with so many backends will reduce their individual features."

Phonon isn't meant to expose all the features of every single backend, its supposed to provide the features 'most' people would need (i.e. simple playback mostly, look at the API documentation on EBN to see all that its currently planned to do), not to do very special case stuff like pro audio apps would need (those the Phonon devs recommend developing directly against a multimedia framework).

"will phonon be slim enough to not slow this down additionally?"

Phonon is a simple library, not a sound server, it wouldn't slow it down anymore than Kaffeine and Amarok and Juk are already slown down.

"talking about backends, why not pick one and trough focussing developement on that one provide an easier-to-maintain, slimmer and more stable interface for media-apps?"

There were GStreamer .6 bindings in KDE SVN, though when the next version of GStreamer came out they were broken horrible and it was taking so much effort to port the bindings they had to pretty much make all new bindings from scratch, with GStreamer .10 ABI compatibility with previous versions of GStreamer was broken (which would of broken kdelibs binary compatibility, and GStreamer would of had to of been forked to prevent that break if it had happened in the middle of the KDE 4 life cycle), and the GStreamer devs are talking about breaking compatibility again. To preserve ABI compatibility in KDELibs you would either need a project which will not break ABI compatibility (which GStreamer is not), or to abstract the interface away which you would the end up with a very Phonon like abstraction layer. Arts didn't have the ABI problem because its been unmaintained for a long time now.

"what about vlc(videolan)?"

What about Xine? What about GStreamer? What about Jack? What about NMM? What about QuickTime? What about DirectShow? What about aRts? What about ESD? What about /dev/null? What about future framework Y that comes out 1 week after KDE4 is released that blows all of those out of the water and nothing can even come close to comparing to and is universally agreed to be the best by every single person on earth? Phonon will allow for a multimedia framework to be chosen as the standard (gstreamer isn't the standard just because they want to be one), and when (if) that happens KDE can switch to using that as the default back end, and could even deprecate all the others if no one wants them. Phonon for one will prevent another aRts from happening to KDE.


Reply to this

-

 Re: pros and cons

 
 by rgfree on: May 15 2006
 
Score 50%

I agree with you in terms of these strange media URLs. I dont like these either. They dont work in all apps and just cause lots of new problems and dont really solve many.

The reduced KControl is only in Kubuntu right now. It would be ok if all icons are shown. But some are missing (like KDE Components) and can only be found in the original KControl. This is quite confusing. The absolutely worst thing Kubuntu (which is otherwise a REALLY great distro!!) is the reduced Konqueror. I cannot even search for files because the menu item has been removed. Ugh.

Phonon seems fine for me, though. Amarok has an option to use several backends right now. Works great for me. I understand Phonon (I'm not a developer though) as the sharing of this concept/part of Amarok by many apps which is perfectly okay IMHO.


Reply to this

-

 Re: Re: pros and cons

 
 by soulrebel on: May 16 2006
 
Score 50%

i am fine with the kubuntu system settings; as long as no dialogs are lost they might aswell make it kde-default.

i really want to stress that i am not against making things simpler. i am just against it if it is done by reducing functionality or making things harder for experienced users (this kio-slave url overlay stuff definitely make it harder for me).


# cd /usa/whitehouse
# rm -rf *

Reply to this

-

 Hard choice

 
 by Ekardnam on: May 15 2006
 
Score 50%

A revolution. It will set new standards.
But on the other hand, I think I'll proably be dissapointed (missing many features I want).


Reply to this

-

 going wrong way

 
 by caminoix on: May 15 2006
 
Score 50%

imho, kde's going wrong way and i'm afraid it's even deeper than soulrebel said.
there's a weird trend among kde developers to rewrite just about everything. koffice is the most striking example, i should think. i mean, what's wrong with openoffice, inkscape, gimp and a couple of other programs? they seem to be losing a lot of time doing sth which is completely unnecessary, and the result is that they have lots of programs but none of them is as good as the alternatives developed independently in the centre of their makers' attention.
while functionality is a great idea, i can't see why it should mean embracing the microsoftish "all users are hopeless morons and can't ever learn a thing" policy. it might be working for windows users, though ;)

kde *is* the best de i've ever seen, and i don't think i'll soon see a better one. it makes me even more sorry to watch it become windows running on linux.

sorry for the long post.


nemerle - the best language for mono | kate os | source mage
Reply to this

-

 Re: going wrong way

 
 by rgfree on: May 16 2006
 
Score 50%

Dont agree at all.
Rewriting apps is absolutely necessary if you want tight integration. If you have gnome apps, java apps, kde apps all mixed you lose valuable memory, startup times go up because each app must load the same things (printing, file dialogs) over and over again and many things just work differently which is a bad thing. You never get a coherent user interface this way where you can i.e find the settings of an application always under the same menu item, looking exactly the same. You will never get drag & drop working everywhere you use it. You will never get document embedding working flawlessly across all apps etc. This is very important to get a professional desktop environment which mean much more than just a bundle of various applications.


Reply to this

-

 Re: Re: going wrong way

 
 by caminoix on: May 16 2006
 
Score 50%

what you're saying is very true. however, following your (and probably kde's) way of thinking would really mean rewriting everything! whenever anyone writes a good program in java, gtk or whatever else, the kde people will have to rewrite it from scratch to assure maximal integration. unless you have tens of thousands of people to do that, it's quite impossible, and anyway, there will always be programs which stand out but everyone uses them simply because they're better.
imho, all this is leading to is slowing the development of kde down, buggy releases and lots of programs which may integrate very well but i won't use them anyway because their non-integrating alternatives really are better.


nemerle - the best language for mono | kate os | source mage
Reply to this

-

 There's a solution

 
 by bufalo73 on: May 16 2006
 
Score 50%

If every program was split in a server part and a client part it won't be neccesary to "reinvent the wheel". Think about OO.o. If there was a Writer-engine, an Impress-engine, ... the KDE developers could take this backend and make another (KDE) frontend. And the same goes with most of the "big" programs. It's the same problem I see with Photoshop filters. They can only work with PS. So if GIMP developers want some filter like the ones PS has they have to rewrite it.


Reply to this

-

 Re: Re: Re: going wrong way

 
 by sirtalon on: May 16 2006
 
Score 50%

A lot of times the 'rewrites' come out better than the 'original' (even though almost everything today can be considered a 'rewrite' of some older program). Should every one just stuck with XMMS, and never write Juk or Amarok? Many people love XMMS, though it can't do the things Amarok can, which a lot of people want (XMMS can't handle having music libraries which a lot of people need in order to handle having large amounts of music, I know my music can't be managed at all easily through just playlists).


Reply to this

-

 Re: going wrong way

 
 by sirtalon on: May 16 2006
 
Score 50%

Rewriting? You do realize that KOffice is older than OpenOffice? OOo is the new comer, not KOffice! Gimp and Krita aren't the same at all, Gimp is an image manipulation program (modify preexisting images/photos) and Krita is a paint program (ideal for image creation). Also Karbon14 may be older than Inkscape as well (at the very least it was started before inkscape was considered 'good enough'). Should KDE abandon KOffice just because some company releases another office suite as open source? KOffice is also MUCH ligher than OOo is, and the OOo people are having trouble doing pretty much any real work on it because the code base is such a horrible mess. Also if you say KDE should abandon KHTML for Gecko and Firefox and not 'rewrite' it, again I'll say that KHTML is older than Firefox, and gtkhtml is actually a port of an old version of khtml to GTK, Apple also considered KHTML to be a better choice than Gecko. Also Phonon isn't rewriting anything, nor is Solid. Both Phonon and Solid are abstraction layers, that way every KDE app doesn't have to have its own code to do hardware & audio for linux, bsd, OS-X, Windows, and others.

"i can't see why it should mean embracing the microsoftish "all users are hopeless morons and can't ever learn a thing" policy"

Isn't that the Gnome policy (at least the reducing functionality in the name of usability part)? Where has KDE reduced the functionality of anything that would warrant a statement like that?


Reply to this

-

 Re: going wrong way

 
 by caminoix on: May 16 2006
 
Score 50%

oh dear, quite a few answers at one time, i'll try to keep readable though.

1. koffice vs oo:
i'm sorry, i didn't know koffice is older than oo. but imho it's even worse for it. because it had more time to get perfected, and it didn't while oo had less, and it did. anyway, the result is that i'm using oo because it can do things i want it to while koffice can't.
if the same goes to gimp and inkscape, i should consider it a serious reason to abandon a project which had a lot of time, and only got as far as to be overtaken a good deal by newcomers with less experience, probably manpower etc.

2. khtml
i don't think i've ever said anything bad about khtml. i'm really not trying to say everything beginning with k- should be abandoned!
all i said was that those programs which have better alternatives should either be worked on harder or, better, abandoned, and the manpower moved to bug hunting because this is the biggest problem i see in kde.
the same goes to phonon and solid.

3. better rewrites
sure they do. personally, i only use kaffeine. still, i'd rather the work to be done by someone else, and the kde developers to concentrate more on eliminating bugs in the first place.

4. moron users
oh, it definitely is the gnome policy. but judging on what i see is planned or under developement at kde, i begin to think it's about to become kde's policy, too.
it doesn't have to mean reducing functionality. it just means adding extra gadgets telling you that you put a cd into the drive like you didn't known it yourself, or that you'd plugged in a printer etc,

5. to sum it all up:
i love kde. i really do. and this is why i'm concerned about its future, and not because i'm its greatest enemy.
i might be wrong, so please don't flame me (if you ever wanted to), but i might also be right sometimes.

again, sorry for the long post.


nemerle - the best language for mono | kate os | source mage
Reply to this

-

 Re: Re: going wrong way

 
 by sirtalon on: May 16 2006
 
Score 50%

1. KOffice is older than OpenOffice, but originally OpenOffice was StarOffice (made by some company then bought by Sun) and because it wasn't selling enough they released the open source version known as OpenOffice. So OpenOffice was developed for a long time as a closed source project and released as OSS much later so its had a lot of commercial support, while KOffice hasn't had much manpower till recently (it is catching up pretty fast to OOo, 2.0 should put them very close with MS document support being the last real big difference).

2. I was just using KHTML as an example (because its a similar situation to KOffice/OOo that comes up a lot). Also you can't really tell the developers what to do because most of them are volunteers and often are only interested in specific things (though the ones paid to work on KDE can be told what to do while being paid). Phonon and Solid should both lower the amount of bugs, and make things easier to debug, instead of having to debug N implementations of an media-engine with multiple backends you would only have to do it once, and instead of having to maintain how to manage hardware or find the state of the system in several different apps all of that would go into the Solid framework. Phonon and Solid shouldn't really be looked at as completely new projects, as much as optimizing already existing technologies making them MUCH easier to debug and maintain (both of which will also lower the barrier to making applications that take advantage of audio/video playback as well as find out/use information about the system like so Kopete doesn't keep trying to auto reconnect again and again to a remote server while you're not even connected to the Internet).

3. A lot of the 'rewrites' aren't done by actually KDE developers (and a lot of them become KDE developers BECAUSE of the rewrites).

4. The new Media Manager thing is pretty useful in some cases (and very easy to disable) and VERY helpful to newbies (if I put a Video-DVD into the computer I generally DO want it to be played in Kaffine), and if a passive popup tells me that the hardware I just plugged in was setup properly that doesn't bother me (long as its a PASSIVE popup), though just a Ding sound on success and a passive/active popup on failure would be better (though this isn't done yet at all, at least on Gentoo and SuSE).

5. I love KDE as well, and maybe I'm just more confident about KDE's future because I read pretty much every blog entry on PlanetKDE and every article on the Dot (a lot of the ones about Plasma are VERY interesting)


Reply to this

-

 Re: going wrong way

 
 by gollum on: May 16 2006
 
Score 50%

Just to say I prefer Koffice to OOo.
Don't know why, but it is like that, and I am happy that there has bee an office suit developed for KDE.

On the other and, as you can use non-KDE apps whith KDE, I don't understand where's the mater.

One freedom in free software is for the developer to choose what they whant to develop.

regards.


Reply to this

-

 Re: Re: going wrong way

 
 by caminoix on: May 16 2006
 
Score 50%

you're of course right about the choice.

my only problem is that i can't get rid of the idea that if it hadn't been for koffice and the like, the development of kde itself would go faster and the releases would be better tested.
that's it, and i seem to have caused much more commotion than i actually meant to...


nemerle - the best language for mono | kate os | source mage
Reply to this

-

 Re: Re: Re: going wrong way

 
 by Dhraakellian on: May 18 2006
 
Score 50%
DhraakellianDhraakellian
-
Nick T. 1

Earth, 3 Sol System, Western Spiral Arm, Milky Way
Last visit Oct 19 2013
0 Friends
0 Groups

More info
Send a message
Add as friend
Other contents
--

The problem with that argument is the assumption that, were it not for koffice, those hackers would be working elsewhere in KDE. They might; they might not. KOffice is their (or their employers') itch. They might not necessarilly have wanted to scratch the kicker, kdesktop, kwin, etc itches.

And, besides, what's to to say that KOffice can't help expose Qt/KDE bugs and bring them to the light to be fixed (or redesigned in later versions)?


Reply to this

-

 Re: Re: going wrong way

 
 by smileaf on: May 19 2006
 
Score 50%

Your not alone. I prefer Koffice to openoffice.
Why?
Quicker start-up times
smaller install size.
fits in very nicely with kde instead of looking ugly and windows'ish like.
It runs faster.

Most of the time I use kwrite because I don't do word processing very much. in fact.
I've never felt limited in any koffice application. its always been able to do what I need it to do.


this comment has been leafed...
Reply to this

-

 well

 
 by dec0ding on: May 16 2006
 
Score 50%

KDE has conventions and standards. None of them should be broken when releasing the next major version of it. If that condition is positive, then there'll be no problems. That'd mean that I don't like to see new standards and conventions for the look or design of KDE. But on the other hand I really like to see good ideas realised which will replace the existing but not functional parts of KDE (yes, arts is one of them).

And the most important thing is colaboration with other communities. Things like "GNOME sux, KDE is better", "KDE is overhyped and not that simple like KDE"... are useless even dangerous for the future of these two environments.


My blog, projects, discussions, comments and wishes: http://gemidjy.blogspot.com
Reply to this

-

 Re: well

 
 by gollum on: May 16 2006
 
Score 50%

Ok, but Gnome sucs, KDE is better :-D


Reply to this

-

 remove some things

 
 by nardew on: May 16 2006
 
Score 50%

i completly agree with idea of removing those URLs like media:/ system:/ etc. It's useless to try to replace classical unix hierarchy and cover it for beginners...


Reply to this

-

 Re: remove some things

 
 by soulrebel on: May 16 2006
 
Score 50%

i see that at least on this point most people here agree.
i will make a feature request (or is it a feature removal request?) and hope i get some support.
also it would be great, if we had the possibility to vote on the matter on one of the communitysites.
what do you think?


# cd /usa/whitehouse
# rm -rf *

Reply to this

-

 Re: Re: remove some

 
 by Yaba on: May 17 2006
 
Score 50%

Post a bug report, make the link public here and people can vote for the report.


I blog, therefore I am.
Reply to this

-

 Re: remove some things

 
 by smileaf on: May 19 2006
 
Score 50%

I personally *like* the system:/ and media:/

Makes it very convent to access removable drives.

Lets look at it this way.
A user wants to be able to see all their removable drives in 1 location.

solution 1: The user MUST have all their mount points in 1 directory and KDE has to know that when entering a directory found in the fstab it is to check if it's mounted and if not mount it.

solution 2: media:/

What's the drawback to solution 1?
Lets say a user has mount points in both /mnt and /media.
lets say that media:/ has an icon for cdrom and that link redirects the user to /media/cdrom
now the user wants to return to that first screen (the media:/) so the user clicks the up button. What happens?
the user gets directed to /media is that what the user was intending on happening?

So why is media:/ a *good* thing? makes it easy for the user to find devices quickly in 1 location and easily navingate them all.

What is the draw back? NON-KDE applications can't use this.
I'd rather have the ease of use over limiting what we can do just because other programs can't/refuse to support this.


this comment has been leafed...
Reply to this

-

 Re: Re: remove some

 
 by Hintzy on: May 21 2006
 
Score 50%

On my system, everything *is* in /mnt, I don't even have a /media folder.

I'd rather not screw over all of my non-kde apps. Isn't the whole point of open-souce to work together? Designing your product so that someone else's won't work anymore sounds very MS to me...


There are 10 types of people in this world: those who understand binary and those who don't.
Reply to this

goto page:  1  2 

Add commentAdd commentall pollsSuggest new pollBack



-
-
How do you like Plasma 5?
 The best KDE Desktop ever.
 Definitely a nice improvement.
 Not decided yet. Haven't tried it yet.
 I do not like some of the changes.
 KDE is taking the wrong way.
 I am still sticking with KDE 3.5.
 I have no opinion, but wanted to vote anyway.

resultmore
 
 
 Who we are
Contact
More about us
Frequently Asked Questions
Register
Twitter
Blog
Explore
Apps
Jobs
Knowledge
Events
People
Updates on identi.ca
Updates on Twitter
Facebook App
Content RSS   
Events RSS   

Participate
Groups
Forum
Add App
Public API
About KDE-Apps.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Advertising
Sponsor us
Report Abuse
 

Copyright 2003-2014 KDE-Apps.org Team  
All rights reserved. KDE-Apps.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.
KDE and K Desktop Environment are trademarks of KDE e.V.