freemint-discuss Mailing List for FreeMiNT (Page 3)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

On Donnerstag, 4. September 2025 16:20:44 CEST Jo Even Skarstein via Freemint-
discuss wrote:
> Never mind.

Sorry if my comments sounded a bit harsh, but i just don't get the idea behind 
it.

Never mind.

On Thu, 04 Sep 2025 15:50:32 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:

>> > It will work, because if XaAES does *not* open the pipe there is only one
>> > process reading from it.
>>
>> But that does not make sense. If the user configured AES to not display
>> anything, it should be like that, whether the pipe exists or not.
>>
>> > To provide a better solution than XaAES.
>>
>> Imho that is functionality that should not be outsourced. If that external
>> program crashes, the pipe will disappear. What exactly do you have in mind for
>> a "better solution"? >> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

> It will work, because if XaAES does *not* open the pipe there is only one
> process reading from it.

But that does not make sense. If the user configured AES to not display 
anything, it should be like that, whether the pipe exists or not.

> To provide a better solution than XaAES.

Imho that is functionality that should not be outsourced. If that external 
program crashes, the pipe will disappear. What exactly do you have in mind for 
a "better solution"?

On Thu, 04 Sep 2025 13:16:25 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:

>> On Donnerstag, 4. September 2025 13:08:42 CEST Jo Even Skarstein via Freemint-
>> discuss wrote:
>> > It would be nice if it was possible for other applications to monitor the
>> > alert-pipe and not just XaAES itself.
>>
>> That won't work, then you would have 2 processes trying to read data from the

It will work, because if XaAES does *not* open the pipe there is only one process reading from it.

>> pipe. And why do you want to do that?

To provide a better solution than XaAES.

Jo Even

On Donnerstag, 4. September 2025 13:08:42 CEST Jo Even Skarstein via Freemint-
discuss wrote:
> It would be nice if it was possible for other applications to monitor the
> alert-pipe and not just XaAES itself.

That won't work, then you would have 2 processes trying to read data from the 
pipe. And why do you want to do that?

It would be nice if it was possible for other applications to monitor the alert-pipe and not just XaAES itself. Just showing an alertbox is not very userfriendly or elegant, I'd like a more "modern" approach to both the presentation and usability.

Since no alerts are shown by XaAES if all types are supressed, maybe XaAES shouldn't create the pipe in that case?

Btw I find it very strange that the kernel has to format the alert-string itself, this should be left to the presentation layer. What if you're not using an AES? But I guess it's too late to do anything about that.

Jo Even

On Thu, 04 Sep 2025 10:08:23 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:

>> On Donnerstag, 4. September 2025 09:22:43 CEST Jo Even Skarstein via Freemint-
>> discuss wrote:
>> > Is it possible to instruct XaAES to not open the alert pipe?
>>
>> No, currently not. It is opened unconditionally in https://github.com/
>> freemint/freemint/blob/b09c517a8d33320c8da8ca12d34f63cf03c89a5f/xaaes/src.km/
>> k_main.c#L1780
>>
>> Is there a problem with that? I think the AES is required to do so, otherwise
>> that pipe will not be created at all, and Salert() won't display a dialog. >> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Hi,

Forwarding this from Debian m68k list in case you missed it, and there 
are people who use DEB packages with MiNT.

	- Eero

-------- Forwarded Message --------
Subject: Re: Removing dpkg arch definition for tos-mint?
Resent-Date: Wed,  3 Sep 2025 02:49:44 +0000 (UTC)
Resent-From: deb...@li...
Date: Wed, 3 Sep 2025 04:49:26 +0200 (CEST)
From: Thorsten Glaser <tg...@de...>
Reply-To: deb...@li..., deb...@li...
To: deb...@li...
CC: deb...@li...

Hi porters, here’s a question:

On Wed, 3 Sep 2025, Guillem Jover wrote:

>The definition for tos-mint was requested in 2012, but it's not clear
>to me whether this has ever been used. So while going over things to
>potentially remove, last year I stumbled over this.

IIRC this was used:

- as cross compiler to build the bootloaders and other native
   utilities (though probably only for TOS, not MiNT?)
   ⇒ using the dpkg arch to fit into the usual cross-toolchain
     creation system
- as dpkg natively on FreeMiNT

Not sure whether the latter has received any attention. When
I last used it, about a decade ago, it could use some, but it
generally was usable.

Perhaps someone here or on the wider m68k-linux channels has
any input?

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

On Donnerstag, 4. September 2025 09:22:43 CEST Jo Even Skarstein via Freemint-
discuss wrote:
> Is it possible to instruct XaAES to not open the alert pipe?

No, currently not. It is opened unconditionally in https://github.com/
freemint/freemint/blob/b09c517a8d33320c8da8ca12d34f63cf03c89a5f/xaaes/src.km/
k_main.c#L1780

Is there a problem with that? I think the AES is required to do so, otherwise 
that pipe will not be created at all, and Salert() won't display a dialog.

Is it possible to instruct XaAES to not open the alert pipe? I see there's a setting to ignore certain alerts, but it looks like the pipe is opened and monitored even when all alerts are supressed.

Jo Even

Le 2025-08-28 23:42, Peter Slegg via Freemint-discuss a écrit :
> The same argument could be used about any aspect of the AES.
> 
> Windows and menus could be farmed out to user space so people can
> choose how they look and feel.
> 
WindoWs in user space is probably possible for a part ( all widgets) but 
not fully, toolbar don't think so and menu too they need to be redraw by 
application itself. Fileselector can be put in userspace this is the 
most simple as not need to be very fast, I think it is more challenging 
for window, now if it is for change look and feel it's not need to be in 
user space.

On 8/29/25 2:48 AM, Jo Even Skarstein via Freemint-discuss wrote:
>>> Windows and menus could be farmed out to user space so people can choose how they look and feel.
> Absolutely, and I'm pretty sure I've suggested this many years ago. That's quite a bit of work though. But there are other things that would be easier to remove from the kernel module and put in userspace applications, like the fileselector and process manager.
>
> Jo Even
>

One of the things I always loved about MagiC is the ctrl-alt-esc process 
manager.  I'd agree that the AES one can be farmed out to userspace but 
it'd be nice if there was better "rescue" functionality built right in.

This is also something that occurred to me about the kernel itself.  
There is boot up functionality that as far as I can tell stays resident 
like reading config file, ini menu, etc.  Same with emutos too really 
(boot menu, etc).  It'd be clever to put all of this one time use 
functionality into an unloadable module so the memory could be recovered 
once it was used.  Probably not worth the effort but it sounds 
interesting to me.

Thanks,

Mark

On Fri, 29 Aug 2025 10:21:30 +0100, Peter Slegg <ps...@sc...> wrote:

>> Question.
>> How does memory use and performance differ between bubbles as an app and built-in ?

That depends entirely on the implementation.

Jo Even

I very seldom see any bubbles in apps. In fact I can't remember when I last saw one. 

I don't remember turning it off. 

Question. 
How does memory use and performance differ between bubbles as an app and built-in ?

⁣Peter

On 27 Aug 2025, 09:37, at 09:37, Jo Even Skarstein via Freemint-discuss <fre...@li...> wrote:
>How is this supposed to work? While debugging some AV-stuff I noticed
>that my application was sent BUBBLEGEM_REQUEST messages even though
>BubbleGEM was not installed. Turned out that I had enabled the XaAES
>built-in BubbleGEM replacement by mistake ages ago. But then it struck
>me - I haven't seen any bubbles in any applications. So I looked into
>it a bit closer.
>
>- Like BubbleGEM, XaAES sends BUBBLEGEM_REQUEST messages to the owner
>of the window the mouse currently hovers above.
>- BubbleGEM put's it's own (the BubbleGEM "server") in msg[1], XaAES
>puts the apid of the owner of the window here.
>- appl_find("BUBBLE  ") returns apid 4 if no actual "BUBBLE  "
>application is running. However, sending BUBBLEGEM_SHOW messages to
>this apid does not do anything.
>
>In short, I could not figure out how to get XaAES to actually show a
>bubble.
>
>Jo Even
>
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

On Fri, 29 Aug 2025 09:08:24 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:

>> PS: the taskmanager would be a good candidate to be "farmed out". However it
>> currently uses internal knowledge that is not available to user space

I can't see that it presents any information that's not available through the existing API's. But I would assume that it retrieves this information directly from internal structures instead.

Jo Even

On Donnerstag, 28. August 2025 23:42:40 CEST Peter Slegg via Freemint-discuss 
wrote:
> Windows and menus could be farmed out to user space so people can choose how
> they look and feel.

Theoretically, yes. But those are part of the "core" AES functions, so you 
would need an internal implementation anyway that does not depend on external 
programs/modules, or you end up with an unusable AES if that module is not 
found.

In MagiC, replacing those is actually possible. The winframe.slb demonstrates 
this by replacing the window look&feel.

Imho it is a matter of what is always required, and what is optional, with the 
goal to farm out optional functionality to make the AES even smaller if you 
don't need it. Windows & menus are certainly always required.

PS: the taskmanager would be a good candidate to be "farmed out". However it 
currently uses internal knowledge that is not available to user space 
programs.

On Thu, 28 Aug 2025 22:42:40 +0100, Peter Slegg via Freemint-discuss <fre...@li...> wrote:

>> The same argument could be used about any aspect of the AES.

Not "any", but "many".

>> Windows and menus could be farmed out to user space so people can choose how they look and feel.

Absolutely, and I'm pretty sure I've suggested this many years ago. That's quite a bit of work though. But there are other things that would be easier to remove from the kernel module and put in userspace applications, like the fileselector and process manager.

Jo Even

On Thu, 28 Aug 2025 at 23:43, Peter Slegg via Freemint-discuss <
fre...@li...> wrote:

> The same argument could be used about any aspect of the AES.
>
Technically speaking, yes. For instance having XaAES as a kernel module
also breaks this principle -- it favours one AES over others and sometimes
even introduces regressions (like the infamous keyboard bug in N.AES which
nobody noticed for years).

I'd say what matters in this debate is ... the actual implementation.
Helmut was a clever Atari developer but he wasn't exactly prototype of a
person who produces clean and maintainable code (not to speak about the
quality of his commits...). So while Frank's / Ozk's work on XaAES is
defendable even now, 20 years later, Helmut's code is usually Thorsten's or
my friend every other month when we discover something broken / horribly
designed / nonsensical.

-- 
http://mikro.atari.org

The same argument could be used about any aspect of the AES.

Windows and menus could be farmed out to user space so people can choose how they look and feel. 

I don't have a hard view on this, I just like consistency.

Could they be made AES plugins ? 

⁣Peter

On 27 Aug 2025, 21:00, at 21:00, Jo Even Skarstein via Freemint-discuss <fre...@li...> wrote:
>
>On Wed, 27 Aug 2025 18:07:45 +0200, Thorsten Otto via Freemint-discuss
><fre...@li...> wrote:
>
>>> - if you have to change something, either because of fixed bugs or
>added
>>> features, it is much easier to just update that single bubble.app
>rather than
>>> have to reinstall all of freemint/xaaes.
>
>Another advantage of farming functionality out to userspace
>applications with a well defined API is freedom of choice. If I don't
>like the way the help-bubbles looks or behaves I can write my own,
>without it affecting other users with other preferences.
>
>>> I personally find such tooltips quite useful, but it is very
>annoying that
>>> they get in the way all the time while editing a field, and you have
>to click
>>> everytime to make them disappear. That is maybe a shortcoming due to
>the way
>>> AES works, but nevertheless makes such a feature almost unusable.
>
>It is not a limitation of the AES, but of BubbleGEM. Because the author
>originally wanted them to look like their Mac counterpart, they're
>actually bitmaps that's drawn outside of any window. If you have
>something like lines.app running when a BubbleGEM help bubble appears,
>you'll see that the screen is locked the whole time the bubble is being
>displayed.
>
>It doesn't have to be like this at all. If a normal, widget-less window
>is used the bubble doesn't have to interfere with user interaction.
>
>Jo Even
>
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Thanks, that explains it.

⁣Peter

On 28 Aug 2025, 15:10, at 15:10, "Vincent Rivière" <vin...@fr...> wrote:
>On 27/08/2025 at 18:10, Thorsten Otto via Freemint-discuss wrote:
>> is it only me, or is someone on your way removing some headers from
>your 
>> mails? Normally i can "reply to the ML", but not with your mails,
>which 
>> seems to have all the mailing list headers removed.
>
>This happens when someone answers with "Reply All". In this case, both 
>the mailing list address and original poster address are specified as 
>email recipients.
>
>The mailing list systems notices this, and avoid sending a duplicate 
>copy of the message. Consequently, you just get the answer as private 
>mail. But other people get it from the mailing list as usual.
>
>On the other hand, if someone answers with "Reply to the list", only
>the 
>mailing list is specified as recipient.
>
>Best practices:
>
>- Use "Reply to the list", if available in your email software.
>
>- Alternatively, on some lists (including Freemint-discuss) you can
>just 
>press Reply. It will reply to the list only.
>Note that this is dangerous, as some mailing lists (i.e. emutos-devel) 
>only reply to the original poster in that case.
>
>- Alternatively, use "Reply All", and remove any address from 
>recipients, except the mailing list.
>
>As a rule of thumb, don't CC named people when replying. That's
>annoying.
>
>-- 
>Vincent Rivière
>
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

On 27/08/2025 at 18:10, Thorsten Otto via Freemint-discuss wrote:
> is it only me, or is someone on your way removing some headers from your 
> mails? Normally i can "reply to the ML", but not with your mails, which 
> seems to have all the mailing list headers removed.

This happens when someone answers with "Reply All". In this case, both 
the mailing list address and original poster address are specified as 
email recipients.

The mailing list systems notices this, and avoid sending a duplicate 
copy of the message. Consequently, you just get the answer as private 
mail. But other people get it from the mailing list as usual.

On the other hand, if someone answers with "Reply to the list", only the 
mailing list is specified as recipient.

Best practices:

- Use "Reply to the list", if available in your email software.

- Alternatively, on some lists (including Freemint-discuss) you can just 
press Reply. It will reply to the list only.
Note that this is dangerous, as some mailing lists (i.e. emutos-devel) 
only reply to the original poster in that case.

- Alternatively, use "Reply All", and remove any address from 
recipients, except the mailing list.

As a rule of thumb, don't CC named people when replying. That's annoying.

-- 
Vincent Rivière

On Wed, 27 Aug 2025 18:07:45 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:

>> - if you have to change something, either because of fixed bugs or added
>> features, it is much easier to just update that single bubble.app rather than
>> have to reinstall all of freemint/xaaes.

Another advantage of farming functionality out to userspace applications with a well defined API is freedom of choice. If I don't like the way the help-bubbles looks or behaves I can write my own, without it affecting other users with other preferences.

>> I personally find such tooltips quite useful, but it is very annoying that
>> they get in the way all the time while editing a field, and you have to click
>> everytime to make them disappear. That is maybe a shortcoming due to the way
>> AES works, but nevertheless makes such a feature almost unusable.

It is not a limitation of the AES, but of BubbleGEM. Because the author originally wanted them to look like their Mac counterpart, they're actually bitmaps that's drawn outside of any window. If you have something like lines.app running when a BubbleGEM help bubble appears, you'll see that the screen is locked the whole time the bubble is being displayed.

It doesn't have to be like this at all. If a normal, widget-less window is used the bubble doesn't have to interfere with user interaction.

Jo Even

I'm using Android bluemail app.

⁣Peter

On 27 Aug 2025, 17:10, at 17:10, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:
>PS.:
>
>is it only me, or is someone on your way removing some headers from
>your 
>mails? Normally i can "reply to the ML", but not with your mails, which
>seems 
>to have all the mailing list headers removed.
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

PS.:

is it only me, or is someone on your way removing some headers from your 
mails? Normally i can "reply to the ML", but not with your mails, which seems 
to have all the mailing list headers removed.

On Mittwoch, 27. August 2025 17:08:21 CEST Peter Slegg wrote:
> If drawing a window is an AES function, isn't drawing a bubble help also an
> AES function

Drawing a window isn't an AES function. It only tells the app that a redraw is 
needed.

What i find personally annoying about integrating that into AES:

- if you have to change something, either because of fixed bugs or added 
features, it is much easier to just update that single bubble.app rather than 
have to reinstall all of freemint/xaaes.
- if the functionality is integrated, and apps that make use of it don't have 
an option itself to disable it, then the user has no way to disable it either. 
I personally find such tooltips quite useful, but it is very annoying that  
they get in the way all the time while editing a field, and you have to click 
everytime to make them disappear. That is maybe a shortcoming due to the way 
AES works, but nevertheless makes such a feature almost unusable.

Just my 2cents. I definitely vote for removing that again, especially if it 
does not work as designed.

I'm puzzled though. 

If drawing a window is an AES function, isn't drawing a bubble help also an AES function ?

⁣Peter

On 27 Aug 2025, 15:14, at 15:14, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:
>On Mittwoch, 27. August 2025 15:52:48 CEST Peter Slegg wrote:
>> BubbleGem app never worked reliably for me.
>
>Then it would be better to fix that. Sources of it are available at
>https://
>github.com/thmuch/bubblegem
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (3)	Nov (30)	Dec (10)
2018	Jan (44)	Feb (44)	Mar (32)	Apr (49)	May (45)	Jun (7)	Jul (15)	Aug (84)	Sep (95)	Oct (36)	Nov (88)	Dec (41)
2019	Jan (21)	Feb (27)	Mar (67)	Apr (25)	May (69)	Jun (45)	Jul (65)	Aug (15)	Sep (20)	Oct (42)	Nov (109)	Dec (62)
2020	Jan (58)	Feb (36)	Mar (84)	Apr (169)	May (325)	Jun (267)	Jul (43)	Aug (3)	Sep (27)	Oct (25)	Nov (25)	Dec (7)
2021	Jan (11)	Feb (66)	Mar (1)	Apr (55)	May (24)	Jun (36)	Jul (10)	Aug	Sep (1)	Oct (21)	Nov (2)	Dec (22)
2022	Jan (3)	Feb (98)	Mar (15)	Apr (31)	May (4)	Jun (23)	Jul (45)	Aug (15)	Sep (75)	Oct (8)	Nov (10)	Dec (12)
2023	Jan (5)	Feb (49)	Mar (31)	Apr (3)	May (7)	Jun (5)	Jul (7)	Aug (161)	Sep (8)	Oct (7)	Nov (27)	Dec (26)
2024	Jan (24)	Feb (35)	Mar (11)	Apr (38)	May (13)	Jun (39)	Jul (2)	Aug (24)	Sep (7)	Oct (5)	Nov	Dec (18)
2025	Jan (82)	Feb (11)	Mar (9)	Apr (13)	May (2)	Jun (7)	Jul (2)	Aug (38)	Sep (46)	Oct (13)	Nov	Dec

freemint-discuss Mailing List for FreeMiNT (Page 3)

FreeMiNT is a free alternative OS kernel for Atari systems & clones

freemint-discuss — The official FreeMiNT Mailing List