Re: [seul-edu] Fwd: [Kde-edu]Welcome to the new kde-edu
#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
Reply to: