[Freemint-list] 20 year anniversary...

Jo Even Skarstein joska at online.no
Sat Nov 5 22:21:02 MSK 2016


On lø., 2016-11-05 at 11:41 +0100, Helmut Karlowski wrote:

> > Yes, I think there are several things in XaAES that could be removed and
> > replaced with an API and userspace programs. Like the hardcoded hotkeys,
> > which leaves no room for user configuration.
> 
> They are not hardcoded - you can change any hotkey by editing xa_help.xx.

Sorry, I was not clear. I meant that the hotkeys' functionality is
hardcoded. There is no way to trigger application events from user
configurable hotkeys. E.g. if I wanted to add a hotkey to Taskbar to
open the start menu I would have to hack it. Instead I could register
the desired hotkey with a "hotkey manager application" which is passed
all keypresses from the kernel, and forwards them to it's clients using
pipes or messages.

> > BubbleGEM replacement should not be in the kernel.
> 
> Explain why.

That is the wrong question :) The question should be "why should it be
in the kernel?". What value does that add? I see no value in running
pure GUI code like this inside the kernel binary itself. One example -
why isn't there a desktop in the kernel module? We know why - because
it's not necessary. Why doesn't the same philosophy apply to the file
selector, the system monitor, task manager?

A bug in a user application is annoying, but does usually not cause
problems outside the application. A bug inside the kernel can be
critical. Moving functionality from the kernel to userspace reduces the
changes for the kernel to f*ck itself up. It also reduces kernel memory
usage.

> Why can't they be replaced?

Of course they can, by altering kernel code. But if would be much easier
if they were user applications, not integrated into the kernel module.
That would also open up new possibilities for scripting and macros.

> I think having them external would increase overhead and code-size.

That is one way to look at it. Another way to look at it is that you
reduce the amount of kernel code, at the cost of adding code in form of
separate applications. Every bit of functionality that is removed from
kernel space and moved into user space is a step towards better
stability.

> Of course there's much room for improvements.

There always is :) But my opinion is that we're now at a point where
improvements means removing features from the kernel and improving the
kernel quality, not adding features.

Jo Even



More information about the Freemint-list mailing list