Once again, I reply to many posts, and with a long message, but it seems that
people are interested in the discussion, so I wont deceive them.
Martin Nordholts a écrit :
> Comparing a kernel "user interface" with an image editor user interface
> is just plain silly.
I don't think so, but maybe some people have difficulties seeing the parallel,
so read ahead please.
Sven Neumann a écrit :
> On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote:
>> Still that narrow minded? You obviously didn't read the drizzt's post
>> at all! Drizzt was comparing the linux kernel _user_ interface with the
>> gimp's _user_ interface.
> As far as I know the kernel doesn't have a user interface in the sense
> the term is used for a graphical user application such as GIMP.
So for you a user interface is a GUI ?
> It does
> provide a lot of interfaces to device drivers and to the higher levels
> of the operating system though. And these interfaces are changing quite
I feel like there's a need for some technical information in here.
Have you ever heard of kernel space and user space ?
The linux kernel code, and all module code, is running in "kernel space", while
all the remaining parts are in "user space".
On a linux system, you can take any 2.6 kernel, and still have your system up
and running. Even using a 2.4 kernel will be possible, with only a few changes
to some administrative tools (modutils and the like).
Because the USER interface is stable. So much that when there is a need for a
change, kernel programmers don't do it, they find another way, whatever it
The kernel internals are moving, and a lot, but this the user don't care about.
you can rewrite gimp every day if you want, nobody (or no user at least) will
care, if the user interface is stable.
> Perhaps this was a misunderstanding. I don't really understand the
> purpose of the Linux kernel example.
It is an example I used on IRC when someone told me to use the old GIMP version
if I did not like the new one.
And chosed because everybody is using new kernels because of the improvements
and the new drivers, which are added but still using the same user interface.
If you cannot see the parallel, sorry.
Then from your previous email:
> Obviously you have no idea of what you are talking about here.
From what you say, I would say I have much more idea than you have.
> The Linux
> kernel APIs are changing faster than anything else in the software
> world. If you had ever maintained a device driver outside the main
> kernel tree, you wouldn't have chosen the Linux kernel as an example of
> something that doesn't change its interface between releases.
I would say only one thing: Why bother !!!
Commit your driver to the kernel, and you'll have no more to do out of the tree
Keeping drivers out of the tree is nonsense.
> GIMP is
> very conservative compared to the Linux kernel. Our plug-in API has not
> seen an incompatible change for five years now.
So the few developpers have nothing to do, but users have to learn the tool once
again after every release ?
Am I the only one feeling that there's a problem in this point of view ?
> You also probably do not realize how much work an optional change is.
> Every option that is added doubles the complexity of the code. It is
> already impossible for us to test all possible configurations that GIMP
> offers. If we tried to make major interface changes optional, the code
> would become completely unmaintainable very soon.
Not at all.
As I said, being a free software, The GIMP project may have some of the best
programmers at hand.
Once again, there are more options in the kernel than you can think about, and
the code is maintained, maintainable, and often tested.
If it's done correctly and early, everything can be tested using test tools.
Once again you are saying implicitly that GIMP developers are newbies. Please
And making major changes is not required if you spent more time thinking. For
example, for the menu, making it dockable with it's docking position being a
saved configuration setting, would prevent an option. And it's already done for
dialogs, so it's not more work, it should even be less work.
Gimp-developer mailing list