[Freemint-list] 20 year anniversary...

[Jo Even Skarstein]

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

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

No, not that. I mean that all applications should be able to "subscribe"
to hotkeys. I.e. an application should be able to tell the AES that it
wants to receive certain keypress combinations even it does not have
keyboard focus.

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

That is not a result of running inside the kernel...

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

That is a completely different problem, that will be solved by a better
packaged distribution. The current archive is just a random collection
of files and needs a lot of work and knowledge to install. But there is
no problem in building a complete archive that only needs to be unpacked
to work - no initial configuration should be necessary.

> You can chose any file-selector you want that replaces the one in XaAES.

Sort of, but they all hack into the AES trap which is not a good
solution. OTOH it adds yet another source of problems - what happens
when the user program (which an add-on fileselector is) f*cks up it's
own trap-handler? The entire AES goes down...
  
> You can run any task-manager if you want.

You can, but you can't get rid of the built-in one. Just like the
built-in fileselector, even with a replacement installed the original
one sits here doing nothing (well, not the fileselector since XaAES
itself seems to call it directly and not via the trap so the built-in
file selector is used whenever you invoke it from an XaAES menu) except
using RAM.

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

Why? I'd say you end up with the same speed, more free memory and less
trouble. And MORE flexibility.

> > kernel space and moved into user space is a step towards better
> > stability.
> 
> What is not stable right now?

Generally speaking XaAES is not very good at handling
crashing/malfunctioning user applications. While N.AES keeps chugging on
and let you recover from an application crash, XaAES often crashes or
continues "working" but with subtle problems that eventually leads to a
system crash.

Jo Even