> It would generalize the > principle, but it's a bit like multiple inheritance in C++ vs. single > inheritance plus multiple interfaces in Java. Multiple is nice, but it > really is a can of worms, which Java tries to sidestep. Mostly, people > are just going to say that you can get what you want with Remote Desktops > and/or X-though-ssh-type things. Which is why this rambling wreck of a > tangential digression is mostly just crazy talk.
For inheritance, the problem is not at the first level, but when there are more: diamond inheritance means that resources could be duplicated, creating strange behavior if the programmer did not made the inheritance virtual. On the other hand, this can often be avoided, and when you speak about Java, just remember that this language does not even have unsigned types :) I am not sure it was designed to be simple to use, sometimes I think it was designed to be easier to design (not sure you understand what I mean). Then, it have added more and more powerful mechanisms, but some of them are still pretty basic against implementations of other languages (I am thinking about generics). Anyway, if you are careful, there are no reason to make things buggy because of multiple inheritance. On the other hand, it can often be avoided, and I still had no occasion to use those techniques (but I still consider I lack experience in OO conception). So, a language used for common needs have no real interest in implementing that. For DEs, the problem is quite different, I think: you will have multiple DEs using same files. And, nowadays, DEs want to detect everything instantly, so they need frequent, if not constant, access to their files. It is more near multi-threading that multi-inheritance, and nowadays people do multi-threaded quite often. Maybe problem is that DEs are often older than the arrival of multi-threading on public computers, and so were not designed with those possibilities in mind? But, well, that OT, for sure, and could start undesired war (especially the part on languages...) so I'll stop it now :) > Something ought to be possible and done, but really, why bother? There no real demand for it. Commercial guys often create the need for something which no-one needs, and then people become so used to that new need that it become vital. Think about television, it is a great example. >> While the gnome session seemed to run OK, the actual *application* >> I wanted to run didn't. >> > > Drats. Well, having worked through all this may have taught us > something, at least. Back in thread \o/ I do not want to troll, but, maybe it is because those applications are deficient? I mean, they should be able to take their input configuration from a file given by the user, in my humble opinion. Thinking about that... since that need is close to unix philosophy, you could try to use tools which claims to respect it. But it is not really fashion nowadays to follow a philosophy which makes you in needs to know which tool to use for which task, so there are not so many applications following that scheme. (It is also harder to create, because programmers have to restrain themselves to add "cool features" ;) ) For graphical browsers, I only know uzbl, maybe it could fit your needs? Of course, you can not compare it to chrome, firefox or IE, and it is still a little experimental, but I often use it happily, and except on some crappy websites like hotmail, it just works. For other applications... I do not know, my preferred softwares are text editors, compilers and lightweight browsers (with opera as fallback ,because I still does not master uzbl :/ ) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/807aef0c28d5f5a3026eae0898c48e8e.squir...@www.sud-ouest.org