Fw: [Re: [seul-edu] Fwd: [Kde-edu]Welcome to the new]

[Douglas Loss <dloss@suscom.net>]

On Sun, 26 Nov 2000, owner-seul-edu@seul.org wrote:

> From: Corrin Lakeland <lakeland@cs.otago.ac.nz>
> X-Sender:  <lakeland@freki.otago.ac.nz>
> To: Manuel Gutierrez Algaba <algaba@gmx.net>
> cc: <seul-edu@seul.org>, <debian-jr@lists.debian.org>
> Subject: Re: [seul-edu] Fwd: [Kde-edu]Welcome to the new
> 
> #include <my_own_opinions_disclaimer.h>
> 
> There are two replies I'd like to make to your email.  One is
> as a
> subscriber to debian-jr and the other is as a programmer.
> 
> -- Debian Jr --
> 
> I would _REALLY_ like to see an open-source computer
> environment that is
> good for children to use.  There is a large demand here from
> schools to
> have a cheaper, easier to maintain, better setup for kids from
> 5-17.
> Quite a task!  Then there are all the parents who would like
> the computer
> to be useful for their children.
> 
> The easiest way of achieving this _now_ is to find a set of
> programs that
> provide such an environment, tie them together nicely and
> encourage people
> to fill in the gaps.  I'm sure we'll end up having to plug a
> few gaps
> ourselves but I think we've already got a large enough task
> and don't need
> to add a fully fledged metalib compatibility layer.
> 
> I guess the point I'm making is that I'm trying to meet a need
> I see, not
> to enter an argument about the relative merits of kde/gnome. 
> I would
> certainly be happier if kde applications looked better in a
> gnome
> environment and the other way around, but I'll stick to being
> happy that
> people are writing the applications under any environment at
> the moment.
> 
> -- Programming perspective
> 
> I too am disappointed at the tight coupling between interface
> and engine
> that is standard nowadays.  I can understand it, it makes
> programming the
> engine a fair bit easier if you don't have to develop a parser
> for working
> between the interface and the engine.
> 
> Hopefully with kparts/corba/etc. we will see this decoupling
> work better.
> If people use these their programs will be easier to integrate
> into the
> other environment.
> 
> Personally I don't care very much if the engine internally is
> linked
> against kde or gnome for things like qstring, I expect most
> people to have
> the basic support/lib packages installed nowadays so what does
> it matter if
> they are using gnome if their app _looks_ the same as other
> apps running.
> 
> I am aware that kde's interface/implementation coupling is
> incompatible
> with gnome's, but I don't see this as a reason for not using
> coupling.
> I'm sure that some time in the future a good shared IPC method
> will be
> worked out and programs that use kde's and gnome's methods
> (probably
> gnome's) will be the easiest to port.
> 
> I also don't want to see either kde or gnome win the desktop
> war, I think
> competition is good for both of them.  Because of this belief
> I think we
> need a good long term strategy for keeping gnome and kde users
> happy and I
> think coupling provides it.
> 
> Incidentally, if you want to see coupling working in practice,
> have a
> look at pybliographer sometime.  It is distributed as two
> separate
> applications with the interface controlling the implementation
> via python.
> 
> -- Conclusion
> 
> I don't think debian-jr should get involved in this debate
> even though it
> affects us, mostly because we're not going to be able to find
> a solution.
> I think we should use the best applications no matter which
> libraries
> they're linked against and hope that at some time in the
> future they'll
> all look a little more consistent.  Consistency is important
> but it is
> hard to achieve at the packaging end and it isn't so important
> we should
> reject all gnome/kde/wmaker/whatever applications.
> 
> In terms of solving this problem I think the best thing to do
> is encourage
> the use of corba/whatever to split interface and
> implementation.  This
> makes it easier to port the interface to another environment.
> 
> > simple, combinable, it does a specific and unique task and
> it
> 
> Doing a unique task was never UNIX's soul.  I have ed, ex, vi,
> emacs,
> xemacs, pico, axe, kwrite, kedit, gedit, gxedit and probably
> more
> installed on my machine, and that is just the text editors...
> awk and sed
> can be simulated with perl, yet I still use them both
> occasionally.
> 
> Have a look at the main gnome developer discussing how unix
> needs to move
> from sharing via pipes to sharing via a corba like setup. 
> Roughly
> speaking we need to move from the concept of small
> applications being
> coupled to the concept of functions being coupled.
> 
> Don't try to discourage people writing good gnome/kde/whatever
> apps just
> because they won't look right under kde/whatever/gnome.  Do
> try to
> encourage them to separate interface from implementation, that
> way bad
> interface writers will get new interfaces written for their
> engines and
> bad engine writers will get new engines tied into their
> interfaces.
> 
> > What happened to Java ?
> 
> I don't like it much so I hardly use it, I don't know about
> everyone else.
> Java was designed to blend in with the environment it is run
> on, much as
> themes are intended to do with kde/gnome.  Maybe kde/gnome
> theme support
> will be improved in the future so a gnome application looks ok
> in kde.
> 
> > Educative program requirements have been always independent
> > of the O.S. . A good educative programm is good if it's
> helpful,
> > having a "cheese" or "metal" theme of the buttonry doesn't
> make
> > it more helpful.
> 
> Not much more helpful anyway.  Debian is a distribution; our
> job is to
> combine existing programs in such a way as to make the best jr
> distribution currently available.  We can also send a few
> encouraging
> words to developers going in the right direction but we're
> trying to make
> a distribution, not a killer app.
> 
> You're welcome to write a few good educational programs, I'm
> happy to help
> you with splitting interface from implementation and with
> packaging.  But
> lets all stick to tasks we can solve.
> 
> Corrin Lakeland
> 
> 
-- 
Doug Loss           The art of medicine consists of amusing the
dloss@suscom.net    patient while nature cures the disease.
(570) 326-3987             Voltaire