Menu
▾
▴
freemint-discuss — The official FreeMiNT Mailing List
You can subscribe to this list here.
| 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
(15) |
Oct
|
Nov
|
Dec
|
|
From: Jo E. S. <jo...@on...> - 2025-09-05 13:13:56
|
Around 1997 I worked on an ambitious FreeMiNT distro-project that ended up being much too complex for me. It included some shell-scripts for setting up the system and adding software packages, and as a part of this I wrote some tools that allowed me to access the fileselector and alertbox from the shell. It also included a tool that I never really got working properly - and looking at the code today tells me why! - it allowed you to describe a GEM form (text-fields, radiobuttons, checkboxes and dropdown-lists) with plain text and upon completion is printed the values to stdout. The form-tool can not be resqued, but the fileselector and alert tools were OK so I tidied up the source and uploaded it here: https://atari.joska.no/shellGEM/ Don't know if it's useful today, but who knows. Jo Even |
|
From: Jo E. S. <jo...@on...> - 2025-09-05 12:13:39
|
On Fri, 05 Sep 2025 12:44:02 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote: >> If there is a sequence of '#$#[0-2]' in the input, it calls specific >> functions: >> - 0: load gradient >> - 1: display a bubble >> - 2: load config file So it looks like "someone" has misused the alert pipe to "remote control" XaAES. The idea is not bad, as this allows you to e.g. force XaAES to reload the config file and/or gradient from a shellscript. But there should be a separate pipe for this. >> PS.: a fix has been pushed. I only did some basic checks, and verified that >> the pipe is not created when you set alert_winds = 0 in the config file. >> Thanks :) I'll be away this weekend, but will do some tests on Sunday evening. Jo Even |
|
From: Thorsten O. <ad...@th...> - 2025-09-05 12:02:13
|
On Freitag, 5. September 2025 13:28:40 CEST Miro Kropáček wrote: > I don't but unfortunately the usual suspect is the same: Yes, i expected that. But i could not find such a character sequence in any file. So another thing that should reverted? |
|
From: Miro K. <mir...@gm...> - 2025-09-05 11:29:04
|
On Fri, 5 Sept 2025 at 12:44, Thorsten Otto via Freemint-discuss < fre...@li...> wrote: > BTW, the code that reads the alert pipe does some other strange things: > > > > https://github.com/freemint/freemint/blob/b09c517a8d33320c8da8ca12d34f63cf03c89a5f/xaaes/src.km/k_main.c#L1016-L1019 > > If there is a sequence of '#$#[0-2]' in the input, it calls specific > functions: > > - 0: load gradient > > - 1: display a bubble > > - 2: load config file > > Do you have any idea where that might be used? > I don't but unfortunately the usual suspect is the same: https://github.com/freemint/freemint/commit/c9ae3dd5f4d420711e8a5bafb18c3192408a2897 . -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2025-09-05 10:44:21
|
On Freitag, 5. September 2025 10:51:31 CEST Jo Even Skarstein via Freemint- discuss wrote: > - XaAES is the only AES that does this. Hm, ok. I thought that this is always done also by other AES. > XaAES can suppress *all* alerts coming from the alert pipe. >Why should XaAES hog the pipe in this case? Yes, i see. I never used that feature, since it looked dubious to me (supppressing alerts just because based on the icon type) But since that mask is configurable, i think your request is doable. If something should go wrong with it, user can always set the mask back to the default value. BTW, the code that reads the alert pipe does some other strange things: https://github.com/freemint/freemint/blob/ b09c517a8d33320c8da8ca12d34f63cf03c89a5f/xaaes/src.km/k_main.c#L1016-L1019 If there is a sequence of '#$#[0-2]' in the input, it calls specific functions: - 0: load gradient - 1: display a bubble - 2: load config file Do you have any idea where that might be used? >just generally look nicer than the crude alert presented by XaAES. I think that's not XaAES fault. It mostly depends on how the alert string written by the app is formatted, just like when doing a normal form_alert() call. PS.: a fix has been pushed. I only did some basic checks, and verified that the pipe is not created when you set alert_winds = 0 in the config file. |
|
From: Jo E. S. <jo...@on...> - 2025-09-05 08:51:52
|
I'm sorry too, was a bit stressed and frustrated yesterday. I'll try to be more clear: - XaAES is the only AES that does this. MultiTOS AES and N.AES has separate applications to monitor the alert-pipe. - XaAES can suppress *all* alerts coming from the alert pipe. Why should XaAES hog the pipe in this case? - I want to write a program that displays the alerts in a more userfriendly manner. E.g. by timing out automatically, not grabbing focus, logging them, and just generally look nicer than the crude alert presented by XaAES. I only suggest a change where XaAES does not hog the pipe when all alerts are supressed. This has abolutely no side-effects for XaAES, since the alerts are not shown anyway. Jo Even On Fri, 05 Sep 2025 08:04:10 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote: >> 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. >> _______________________________________________ >> Freemint-discuss mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Thorsten O. <ad...@th...> - 2025-09-05 06:04:36
|
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. |
|
From: Jo E. S. <jo...@on...> - 2025-09-04 14:21:05
|
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 |
|
From: Thorsten O. <ad...@th...> - 2025-09-04 13:50:45
|
> 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"? |
|
From: Jo E. S. <jo...@on...> - 2025-09-04 12:30:28
|
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 |
|
From: Thorsten O. <ad...@th...> - 2025-09-04 11:16:44
|
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? |
|
From: Jo E. S. <jo...@on...> - 2025-09-04 11:09:03
|
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 |
|
From: Eero T. <oa...@he...> - 2025-09-04 09:00:48
|
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
|
|
From: Thorsten O. <ad...@th...> - 2025-09-04 08:08:45
|
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. |
|
From: Jo E. S. <jo...@on...> - 2025-09-04 07:22:53
|
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 |
|
From: <o....@lu...> - 2025-08-29 21:51:41
|
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. |
|
From: Mark D. <mdu...@at...> - 2025-08-29 13:42:52
|
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 |
|
From: Jo E. S. <jo...@on...> - 2025-08-29 11:41:11
|
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 |
|
From: Peter S. <ps...@sc...> - 2025-08-29 09:21:46
|
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
|
|
From: Jo E. S. <jo...@on...> - 2025-08-29 08:52:11
|
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 |
|
From: Thorsten O. <ad...@th...> - 2025-08-29 07:08:49
|
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. |
|
From: Jo E. S. <jo...@on...> - 2025-08-29 06:48:29
|
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 |
|
From: Miro K. <mir...@gm...> - 2025-08-28 22:09:48
|
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 |
|
From: Peter S. <ps...@sc...> - 2025-08-28 21:42:56
|
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 |
|
From: Peter S. <ps...@sc...> - 2025-08-28 18:23:57
|
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 |
5 messages has been excluded from this view by a project administrator.
