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
(46) |
Oct
(13) |
Nov
|
Dec
|
|
From: Thorsten O. <ad...@th...> - 2025-09-23 07:01:45
|
On Montag, 22. September 2025 21:53:30 CEST Jo Even Skarstein via Freemint- discuss wrote: > And yes, I am aware that the memory of the > crashed process may have been allocated and overwritten by another > process since the crash Thats not the only problem here, but even if you know the address of the crashed program, its memory does not belong to any process anymore, and is not managed by mint currently. I also don't know what you want to examine in the basepage, there is nothing that changes there during the runtime of the process? |
|
From: ROBERT M. <rj...@ya...> - 2025-09-22 23:21:48
|
<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I downloaded freemint-1-19-23dc029a-000-st_str.zip and installed it on my stock Mega ST/4 having TOS 1.0. <div><br></div><div>Regards,</div><div>Bob</div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On Sep 20, 2025, at 1:34 AM, Miro Kropáček <mir...@gm...> wrote:<br><br></div><div dir="ltr"><div dir="auto"><div>Hi Bob,</div><div dir="auto"><br></div><div dir="auto">maybe first tell us which archive you downloaded.</div><div><br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div><a href="http://mikro.atari.org" target="_blank">http://mikro.atari.org</a></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Dňa so 20. 9. 2025, 1:05 Bob Myers <<a href="mailto:rj...@ya...">rj...@ya...</a>> napísal(a):<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u> <div> <p>Hi Miro;</p> <p>I did this on my TOS 1.0 Mega ST/4 and booted the machine. It did not switch desktops or presented me with a bash shell. What am I supposed to see? I'm going to check you link now.</p> <p><br> </p> <p>Regards, </p> <p>Bob</p> <p><br> </p> <div>On 9/18/2025 10:29 PM, Miro Kropáček wrote:<br> </div> <blockquote type="cite"> <div dir="auto"> <div dir="auto"><br> </div> <div dir="auto">just unzip the archive on C:.</div> <div><br> </div> <div data-smartmail="gmail_signature"> <div dir="ltr"> <div><a href="http://mikro.atari.org" target="_blank" rel="noreferrer">http://mikro.atari.org</a></div> </div> </div> </div> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss <<a href="mailto:fre...@li..." target="_blank" rel="noreferrer">fre...@li...</a>> napísal(a):</div> </div> </blockquote> </div> </blockquote></div> </div></div></body></html> |
|
From: Jo E. S. <jo...@on...> - 2025-09-22 19:53:47
|
Hi, I want to examine the basepage and TEXT segment of a *crashed* process. mint-prg.hyp ( https://tho-otto.de/hypview/hypview.cgi?url=%2Fhyp%2Fmint-prg.hyp&charset=UTF-8&index=14 ): > If you Fopen() process zero (MiNT itself) then you can > Fseek() to any address that is managed by MiNT and read or > write there. This is for debuggers and similarly dangerous > tools. Not quite sure how this is supposed to work. - I open u:\\proc\\*.000, with Fopen, it returns a valid filepointer. - I Fseek to the desired address (address of basepage of the crashed process), Fseek returns the address I Fseek'ed to. - I try to read the basepage with Fread(f, sizeof(BASEPAGE), &buffer). Fread returns error -36, EACCESS. What am I doing wrong here? And yes, I am aware that the memory of the crashed process may have been allocated and overwritten by another process since the crash, but that should not cause the access issue if I understand the quote from mint-prg.hyp correctly. Jo Even |
|
From: Miro K. <mir...@gm...> - 2025-09-20 06:34:56
|
Hi Bob, maybe first tell us which archive you downloaded. http://mikro.atari.org Dňa so 20. 9. 2025, 1:05 Bob Myers <rj...@ya...> napísal(a): > Hi Miro; > > I did this on my TOS 1.0 Mega ST/4 and booted the machine. It did not > switch desktops or presented me with a bash shell. What am I supposed to > see? I'm going to check you link now. > > > Regards, > > Bob > > > On 9/18/2025 10:29 PM, Miro Kropáček wrote: > > > just unzip the archive on C:. > > http://mikro.atari.org > > Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss < > fre...@li...> napísal(a): > > |
|
From: Bob M. <rj...@ya...> - 2025-09-19 23:05:57
|
Hi Miro; I did this on my TOS 1.0 Mega ST/4 and booted the machine. It did not switch desktops or presented me with a bash shell. What am I supposed to see? I'm going to check you link now. Regards, Bob On 9/18/2025 10:29 PM, Miro Kropáček wrote: > > just unzip the archive on C:. > > http://mikro.atari.org > > Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss > <fre...@li...> napísal(a): |
|
From: Miro K. <mir...@gm...> - 2025-09-19 03:30:01
|
Hi Bob, just unzip the archive on C:. http://mikro.atari.org Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss < fre...@li...> napísal(a): > Hi; > > Can someone point me to discussions describing how to install this version > onto a mega st4? I’m unsure how to do this since I don’t see an > install.pkg file in the mint folder. > > Thanks, > Bob > Sent from my iPhone > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: ROBERT M. <rj...@ya...> - 2025-09-18 21:06:19
|
Hi; Can someone point me to discussions describing how to install this version onto a mega st4? I’m unsure how to do this since I don’t see an install.pkg file in the mint folder. Thanks, Bob Sent from my iPhone |
|
From: Miro K. <mir...@gm...> - 2025-09-12 22:32:04
|
On Sat, 13 Sept 2025 at 00:00, Vincent Barrilliot via Freemint-discuss < fre...@li...> wrote: > A while back, I rewrote the keyboard/midi handling stuff in C in my fork > of EmuTOS and it works great ( > https://github.com/vinz6751/genxtos/blob/main/bios/aciavecs_c.c). I event > rewrote the VBL handler in C there :D It's possible to write interrupt > handlers with GCC (tried it, it works) so it's to be considered when the > sole reason is "need to save scratch registers and terminate with RTE" > I couldn't find an example of that in your source tree (but I didn't look too hard). I presume you are talking about using gcc's interrupt attribute <https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/m68k-Function-Attributes.html> ? Could be an interesting thing to do, indeed. But one has to be *extremely* careful when rewriting those handlers into C because one typo can have a catastrophic outcome. So no huge PRs there please, make them as simple as possible. > As part of doing that, I also have as a secondary objective to be able to > "#define-out" code that is irrelevant for a ST, so to hopefully save a bit > of space/overhead and make MiNT more vanilla-ST-friendly (every kilobyte of > memory counts there :D) > As you are perhaps aware, "KERNELDEFS_000 = -DM68000 -DNO_RAMFS -DNO_FAKE_SUPER -DNO_DEV_RANDOM" has more or less the same objective, so maybe you can just extend the scope of "M68000" if you find something unrelated to ST to be still included. In general your ideas seem right, just be cautious and progress in small steps: the last thing we need is a huge PR messing with hundreds of asm lines while introducing hundreds of C lines. :) -- http://mikro.atari.org |
|
From: Vincent B. <vin...@la...> - 2025-09-12 22:00:26
|
Hi Miro, 1 Thank for the advice. I cleaned up and created another PR as a result, I hope it's now in a decent state though it's still a single PR (there is just one commit there that moves a method). I'll pay attention to create different PRs going forward. 2 Next I'll check if it makes sense to improve the install_vector() function so it automatically detects if the handler to install supports XBRA (if handler-12 is 'XBRA' and handler-8 is 'MiNT'), and if so, save the old handler. And likewise for restoring. Factoring that would allow to eliminate some code. 3 Next I would like to see if I can split init_intr because it says "init" but it actually has the code for different handlers dealing with different things (timers, TOS disk vectors etc.) so it's a "God" module. I'll probably split that so to have the timer stuff separated in its own files (e.g. timer_5ms, timer_20ms), the TOS disk handlers on another, etc. 4 Also I'm wondering why the TOS disk vectors handlers (new_rawbs etc.) really need assembly code. There is code duplication there that could be eliminated between the 3 vectors. In general, I would also like to rewrite some things in C unless there is a clear performance reason to keep it in asm. This is also because: * the Coldfire support makes the asm source quite unreadable because of all the "#if __coldfire__". * it gives no chance to the compiler to use 68020+ instructions (indirections, scale factors) that could give a positive performance improvements * Some things don't need to be ultra fast. For example, the keyboard stuff doesn't need to be ultra fast (just need to check it can keep up with the mouse events). A while back, I rewrote the keyboard/midi handling stuff in C in my fork of EmuTOS and it works great (https://github.com/vinz6751/genxtos/blob/main/bios/aciavecs_c.c). I event rewrote the VBL handler in C there :D It's possible to write interrupt handlers with GCC (tried it, it works) so it's to be considered when the sole reason is "need to save scratch registers and terminate with RTE" I would like to isolate or make more apparent the hardware dependency of FreeMiNT (e.g. it assumes the Atari user vector addresses for ACIAs, interruption levels etc.), so I could consider adapting it for my Foenix Retro Systems GenX to harness the power of the 060 installed there. (That's why i started looking at the init_intr.) As part of doing that, I also have as a secondary objective to be able to "#define-out" code that is irrelevant for a ST, so to hopefully save a bit of space/overhead and make MiNT more vanilla-ST-friendly (every kilobyte of memory counts there :D) Vincent B. (Vinz) Le 12/09/2025 à 13:11, Miro Kropáček a écrit : > Hi Vincent, > > welcome to the mailing list. First I'd like to ask you to actually > subscribe (register) to the list otherwise I need to accept every > single email from you in the admin panel. > > Your initiative is certainly welcome, me and the few remaining > freemint developers usually spend time on "hotter" issues, leaving > this kind of work neglected. I have briefly browsed through your > commits, I find majority of the changes very useful and definitely > improving the current state of things. > > If you want to see your changes merged, I'd ask for for the following: > > - create PR for each group of your changes: e.g. renaming > variables/magic constants is fine to have as one PR (much appreciated > the work you did there, splitting everything nicely in separate > commits, please keep that), then I saw some vector restoration fixes - > another PR, moving functions into other files - another PR etc > > - if you have some commits fixing your own bugs (I saw a commit like > that there), please merge those commits together so there's only one > final good commit > > - it's fine to say "this PR depends on that PR, so merge the latter first" > > If you need some help with git(hub), just ask. It's somewhat dull work > to rebase/reorder/cherry-pick for the PRs but it makes the reviewer's > work much easier. > > On Fri, 12 Sept 2025 at 12:57, Vincent Barrilliot via Freemint-discuss > <fre...@li...> wrote: > > Hello, > > I have started looking at the FreeMiNT code and I am not finding > it very > "easy" or modern. I would like to refactor things a bit to make > the code > base easier to grasp for new comers like me, so maybe to help people > figure things out and contribute more easily. For example: > > Renaming variables, moving where it belongs (so modules should have > single responsibility), avoiding magic numbers, adding comments or > updating/writing notes on how things work. This should be rather > rather > safe. > > An example of what I'm doing is here > https://github.com/vinz6751/freemint/pull/2/files > > (the individual commits tell the story). > > I'd like to know how I can get these changes in, if that is possible. > > Thank you! > > Vincent Barrilliot > > > > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > > > > -- > http://mikro.atari.org > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Miro K. <mir...@gm...> - 2025-09-12 11:11:39
|
Hi Vincent, welcome to the mailing list. First I'd like to ask you to actually subscribe (register) to the list otherwise I need to accept every single email from you in the admin panel. Your initiative is certainly welcome, me and the few remaining freemint developers usually spend time on "hotter" issues, leaving this kind of work neglected. I have briefly browsed through your commits, I find majority of the changes very useful and definitely improving the current state of things. If you want to see your changes merged, I'd ask for for the following: - create PR for each group of your changes: e.g. renaming variables/magic constants is fine to have as one PR (much appreciated the work you did there, splitting everything nicely in separate commits, please keep that), then I saw some vector restoration fixes - another PR, moving functions into other files - another PR etc - if you have some commits fixing your own bugs (I saw a commit like that there), please merge those commits together so there's only one final good commit - it's fine to say "this PR depends on that PR, so merge the latter first" If you need some help with git(hub), just ask. It's somewhat dull work to rebase/reorder/cherry-pick for the PRs but it makes the reviewer's work much easier. On Fri, 12 Sept 2025 at 12:57, Vincent Barrilliot via Freemint-discuss < fre...@li...> wrote: > Hello, > > I have started looking at the FreeMiNT code and I am not finding it very > "easy" or modern. I would like to refactor things a bit to make the code > base easier to grasp for new comers like me, so maybe to help people > figure things out and contribute more easily. For example: > > Renaming variables, moving where it belongs (so modules should have > single responsibility), avoiding magic numbers, adding comments or > updating/writing notes on how things work. This should be rather rather > safe. > > An example of what I'm doing is here > https://github.com/vinz6751/freemint/pull/2/files > > (the individual commits tell the story). > > I'd like to know how I can get these changes in, if that is possible. > > Thank you! > > Vincent Barrilliot > > > > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > -- http://mikro.atari.org |
|
From: Vincent B. <vin...@la...> - 2025-09-12 10:37:29
|
Hello, I have started looking at the FreeMiNT code and I am not finding it very "easy" or modern. I would like to refactor things a bit to make the code base easier to grasp for new comers like me, so maybe to help people figure things out and contribute more easily. For example: Renaming variables, moving where it belongs (so modules should have single responsibility), avoiding magic numbers, adding comments or updating/writing notes on how things work. This should be rather rather safe. An example of what I'm doing is here https://github.com/vinz6751/freemint/pull/2/files (the individual commits tell the story). I'd like to know how I can get these changes in, if that is possible. Thank you! Vincent Barrilliot |
|
From: Jo E. S. <jo...@on...> - 2025-09-11 16:49:19
|
On Wed, 2025-09-10 at 16:04 +0200, Thorsten Otto via Freemint-discuss wrote: > It would still interfere i think, since only one application will > receive mouse events. Also, even a widget-less window would have a When evnt_multi times out it should return also the current mouse position and button status, regardless of which application has input focus. XaAES doesn't, I have created an issue for this: https://github.com/freemint/freemint/issues/424 > border frame, unless you explitcly disable that in xaaes.cnf. But i'm > not sure whether other AES like MyAES or N.AES support that (not to > speek about SingleTOS, where you would not have widget-less windows > at all). You confuse widget-less with frame-less :) You can have a window without any widgets in any AES. If you for some reason wants a frame- less window only XaAES supports that I think, and unfortunately only via appsettings in xaaes.cnf. But that's not a problem, you don't have to draw "bubbles" but can simply put the help-text in a normal, rectangular window like e.g. Windows does. > Anyway, attached is my first attempt to port the Pascal code to Pure- > C. Maybe someone will give this a try. Note that when you Thanks, but I already have a pretty feature-complete implementation using windows instead of locking the screen like BubbleGEM does. The mouse button bug mentioned above prevents this from working correctly when the help-text is displayed by right-clicking on an item though. In this case the text should be closed as soon as the right mousebutton is released, but as I can't reliably detect the button status upon receiving the BUBBLEGEM_SHOW message this does not work under XaAES. Works fine in N.AES. Jo Even |
|
From: Jo E. S. <jo...@on...> - 2025-09-11 15:20:50
|
This reminds me of this thread: https://sourceforge.net/p/freemint/mailman/freemint-discuss/thread/1744916577.qyhcl82rwok8oswk%40epost.online.no/#msg59174408 On Tue, 2025-09-09 at 23:36 +0200, Miro Kropáček wrote: > Hi, > > am I missing something or "route add default <IF>" should work and it > doesn't? I'm trying to create a simple point to point TCP/IP setup > and Atari side just says "Network is unreachable". > > I don't see anything suspicious in route.c, it seems it should work? > > http://mikro.atari.org > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Miro K. <mir...@gm...> - 2025-09-11 08:01:07
|
On Thu, 11 Sept 2025 at 04:00, Mark Duckworth via Freemint-discuss < fre...@li...> wrote: > A default route necessarily has to involve an IP. Traffic that has no > other destination has to route through somewhere. > > What you are looking for is a subnet route. That would look something > more like route add 192.168.1.0 eth0 Which would say that all traffic to > 192.168.1.0 goes out eth0. I'm not sure you could set it up so that you > directly route to the whole internet but if you could it would look like > route add 0.0.0.0 eth0 > Isn't "route add 0.0.0.0 eth0" basically the same as "route add default eth0" from my example? Because that's exactly what I'm trying to achieve. A quick google search found e.g. this one: https://superuser.com/questions/279543/connecting-two-linux-pcs-via-cross-cable where the guy does basically exactly the same thing and he is encouraged to drop the "gw" part because it's not necessary. -- http://mikro.atari.org |
|
From: Mark D. <mdu...@at...> - 2025-09-11 02:00:21
|
On 9/10/25 3:29 AM, Miro Kropáček wrote: > On Wed, 10 Sept 2025 at 08:44, Thorsten Otto via Freemint-discuss > <fre...@li...> wrote: > > I think you also need to specify a gateway ip. In my scripts, i use > > > exec /bin/route add default eth0 gw 192.168.1.1 > > > where 192.168.1.1 is the router. > > The thing is that I didn't want the router to be involved. As a > workaround, yes, I did use the other computer's IP address as gateway > but that shouldn't be necesarry -- route's help clearly states that > "gw" is optional. > > On route's side everything seems to be OK, it just calls FreeMiNT's > ioctl with the prefilled structure so I'm wondering whether there > isn't some bug or unexpected behaviour on FreeMiNT's side. > A default route necessarily has to involve an IP. Traffic that has no other destination has to route through somewhere. What you are looking for is a subnet route. That would look something more like route add 192.168.1.0 eth0 Which would say that all traffic to 192.168.1.0 goes out eth0. I'm not sure you could set it up so that you directly route to the whole internet but if you could it would look like route add 0.0.0.0 eth0 |
|
From: Thorsten O. <ad...@th...> - 2025-09-10 14:04:54
|
On Mittwoch, 27. August 2025 22:00:43 CEST Jo Even Skarstein via Freemint- discuss wrote: > If a normal, widget-less window is used the bubble doesn't have to interfere > with user interaction. It would still interfere i think, since only one application will receive mouse events. Also, even a widget-less window would have a border frame, unless you explitcly disable that in xaaes.cnf. But i'm not sure whether other AES like MyAES or N.AES support that (not to speek about SingleTOS, where you would not have widget-less windows at all). Anyway, attached is my first attempt to port the Pascal code to Pure-C. Maybe someone will give this a try. Note that when you recompile it using the original pcgemlib, there may be missing functions like vqt_extentn() and v_gtextn(), but it should not be too hard to reimplement them. |
|
From: Miro K. <mir...@gm...> - 2025-09-10 07:29:57
|
On Wed, 10 Sept 2025 at 08:44, Thorsten Otto via Freemint-discuss < fre...@li...> wrote: > I think you also need to specify a gateway ip. In my scripts, i use > > exec /bin/route add default eth0 gw 192.168.1.1 > > where 192.168.1.1 is the router. > The thing is that I didn't want the router to be involved. As a workaround, yes, I did use the other computer's IP address as gateway but that shouldn't be necesarry -- route's help clearly states that "gw" is optional. On route's side everything seems to be OK, it just calls FreeMiNT's ioctl with the prefilled structure so I'm wondering whether there isn't some bug or unexpected behaviour on FreeMiNT's side. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2025-09-10 06:44:06
|
> am I missing something or "route add default <IF>" should work I think you also need to specify a gateway ip. In my scripts, i use exec /bin/route add default eth0 gw 192.168.1.1 where 192.168.1.1 is the router. But note that when you specify the other point of your interface as gateway, DNS requests will also be send there. |
|
From: Miro K. <mir...@gm...> - 2025-09-09 21:37:18
|
Hi, am I missing something or "route add default <IF>" should work and it doesn't? I'm trying to create a simple point to point TCP/IP setup and Atari side just says "Network is unreachable". I don't see anything suspicious in route.c, it seems it should work? http://mikro.atari.org |
|
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 |
5 messages has been excluded from this view by a project administrator.
