On Monday 20 September 2004 18:26, Christoph Wiesen wrote:
> Am Sonntag, 19. September 2004 22:55 schrieb Kevin Krammer:
> > Any example of fd.o specifications that are implemented in GNOME but not
> > in KDE?
> > Well, maybe the shared mime-type spec, but it is agreed on, David Faure
> > and other core-devs actively worked on the drafts, so I would be
> > surprised if it isn't implemented soon.
>
> I guess it's more of a simple pharse to state that there are some areas KDE
> could still improve upon - and most of those areas seem to be actively
> worked on anyway.
Well, seems to be, as noone came up with a spec that is neither implemented
nor worked on.
But it sounded a lot like an accusation that KDE developers are not
incorporating standards, which is not very clever if you want to have
developers look at the rest of the posting.
Very likely a developer will consider the poster to be a troll and skip the
rest of the text and possible the rest of the whole thread.
> One of those areas is that you sometimes hear that a feature can't or
> should not be implemented because it would either be only-for-linux (i.e.
> the other unices supported by KDE could not really take advantage of it) or
> because it's the "responsibility of the distribution". The last one is
> something I actually heard from time to time.
"Can't" or "Won't" in this cases usually means that it isn't going to be a
dependency for the core libs and core apps.
It is seldom final, most of the time someone comes up with a fallback
mechanism that can always be implemented. For example KDE can use dnotify on
Linux >= 2.4 to watch for file changes, use FAM on Linux and a variety of
UNIX flavors, but can always fall back to contuinually compare modification
times with stat().
It also matters if the feature is something other apps will rely on. For
example it isn't a problem to offer an applet for switching screen
resolutions even when this is only available for X servers which have the
xrandr extensions enabled.
> An example for this - that GNOME has just now - is "Volume Management" as
> done via the GNOME Volume Manager. Basically I would have called it in a
> different way if it hadn't been called that by the GNOME people.
> Wouldn't it be the responsibility of the distributions to make sure (or
> don't) that cdroms and usb sticks and whatever are automagically detected
> and mounted and so on? Maybe many people think so - though I'd disagree
> anytime. But that doesn't matter.
Volume management is more than just automounting. Automounting is more a
workaround until some proper "removable device" managment is available.
For example automount does not work for devices without filesystem, e.g. audio
CDs.
As far as I understand the plans of the volume manager developers (on any
desktop) is to also notify other applications about attaching or deattaching
of devices. Latter is necessary to release resources on a device that was
requested to be removed.
> Actually all that matters to a user is that GNOME handles their external
> media nicely and KDE does not - or you could say "the kde-based
> distribution" does not... the user doesn't care.
I don't have the just release GNOME 2.8 installed, but I assume that gvm also
works when running in KDE.
I also don't know what the KDE based entrance level distributions like
Linspire or Xandros offer.
Additionally I am quite confident that kvm is going to be released with the
next KDE release.
Actually I expect that both are only technology demonstrators and some
properly shared implementation will be available in the future.
> And that's the point some seem to be making - GNOME doesn't seem to care
> anymore what they should do and what is better left for another project: if
> there _is_ something that can be done to improve the end users experience
> they just started doing it, no matter what.
> That's where GNOME leads right now.
In some areas they certainly do, in some areas they certainly don't.
And I don't buy the "no matter what" part, I am sure that most of the GNOME
core developers also prefer quality and maintainable solutions.
Especially not after the quickly available CORBA based component solution
Bonobo turned out to be less popular with developers than the KDE developed
KParts framework, which required some work at first but is far easier to use.
Cheers,
Kevin
--
Kevin Krammer <kevin.krammer@xxxxxx>
Qt/KDE Developer, Debian User
www.mrunix.de - Unix/Linux programming forum
www.qtforum.org - Qt programming forum
___________________________________________________
.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
