[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    RE: ktalk-config
From:       David Faure <David.Faure () cramersystems ! com>
Date:       1999-11-02 11:37:52
[Download RAW message or body]

> David Faure wrote:
> 
> > > On the other hand such questions could be handled somehow.
> > > Possibly the
> > > best solution here would search the system for talk-clients and list
> > > them. But I have no idea how this could be easily achieved...
> > > (or is the
> > > coming 2.0 release capable to make such "miracles" happen?
> > > P-) -There is
> > > no base that describes the programs functionalities, by now...)
> > 
> > Why such a complex solution ?
> > If we have ktalk part of kdenetwork, then we change the default talk
client
> > to ktalk, and the dummy user doesn't have to care about this anymore
> > ... until he becomes a knowledgeable user that installs blatalk or
whatever
> > and then can change ktalkd's configuration.
> 
> Well, you`re right by stating that this is a complex solution. And
> you`re absolutely right to say it would be easier to integrate ktalk
> directly.

> [DE-philosophy on P-)]
> But on the other hand I wonder if the architecture of KDE2.x will allow
> to lookup programs with their MIME-types. 
Yes it does.
That's part of what libkio does.
And here it would even be 'service type' (like "talk program"), not
mimetype.

BUT: you can't expect other talk programs to come up with a
mimetype/servicetype file. So it doesn't solve the problem here.

> Then such things could be done by the system, not by the "dummy user".
> BTW I assume that not every user will, or even wants to become a
> knowledgeable one. So the enviroment will have to take care 
> of that. And I believe that this kind of "feedback" or "information" is 
> what makes a DE attractive.
> Users like to see what's possible without reading a book, or searching
> huge piles of directories and man pages - and you cannot 
> blame them for that, do you?
> 
> So I believe that in the long run the system will have to display all
> necessary information and not more (everything as options, with
> explanations and active hints aside). Forcing the user to 
> lookup whether
> there are alternative clients (like in the ktalk example), where there
> are found and what commandline options have to be taken, is totally
> contraproductive. (But easy to implement, as you correctly stated)
> At this point we also do not have to forget that the most 
> active user is the developer - and s/he will benifit most.
> So UNIX could really become ready for the dektop!
> [DE-philosophy off]
Well as this nice talk is right but it doesn't go anywhere, does it ? :)

If you suggest that at some point, a KDE program does a "find /"
to look for which programs are installed, it's obviously out of question.
Yes, modern distributions have a lot of nicer ways to find out
what's installed, but that's distribution specific.
Distributions should take care of this : when installing whatevertalk and
ktalkd,
ktalkd configuration has to be updated to call whatevertalk.
But anyway : do you know many good talk clients besides ktalk ? :-)

> Back to the subject: I agree - ktalk should get in! P-)
Yup.

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems

[prev in list] [next in list] [prev in thread] [next in thread]