[Freemint-list] 20 year anniversary...

[Helmut Karlowski]

Am 05.11.2016, 20:21 Uhr, schrieb Jo Even Skarstein:

>> 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

Ah, you mean something like SDMASTER? Yes, that would be nice ;)

>> > 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

Computers do crash less often ;)

> 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.

I prefer having the most basic stuff (fileselector, etc.) built in. When I  
run N.AES for example, I cannot do much without installing/running  
additional tools that I don't have or don't know how to use.

Also the external way would cause more files to care about (versioning,  
etc.) for the installation-process. People already seem to struggle with  
the files in MiNT.

>> Why can't they be replaced?
>
> Of course they can, by altering kernel code. But if would be much easier

You can chose any file-selector you want that replaces the one in XaAES.  
You can run any task-manager if you want.

> if they were user applications, not integrated into the kernel module.
> That would also open up new possibilities for scripting and macros.

I can't see a problem here.

> 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

An end up with less speed, less free memory and probably more trouble.

> kernel space and moved into user space is a step towards better
> stability.

What is not stable right now?

> 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.

Anyway - from my side there won't come anything fundamental before the  
great big branch-merge is done. That doesn't seem to happen so soon.

-Helmut