@A__P

Quote:
That’s a well-documented behaviour in the animal world, known as "territorial pissing".

@terminills

Quote:
For starters, we have absolutely no idea what the kernel contract between Hyperion and Trevor says.

@walkero

Quote:
I was several times on the brink of initiating an OS4-only print magazine, but always got second thoughts. The cost of printing has gone up since Covid, but it's the cost of postal services that is really killing the plan. This, combined with our tiny user base, which would require low print runs (and higher per-copy prices), turns the idea into a pipe dream

Still, I would be all for centralizing our writing efforts as you're suggesting. At the moment, things appear in so many places that they're hard to follow or even find.

An AmigaGuide-based magazine like WhatIFF is certainly possible, quite easy to produce (if there are articles to publish), but I'm not sure how good the format is for graphic content, which I don't think I would like to give up.

A PDF magazine would offer all that most people expect, but requires some DTP effort to lay out the content, and perhaps some format compatibility voodoo so that AmiPDF can display it.

A "diskmag" (of course not on a diskette) would be very much in the Amiga spirit, but requires an engine.

And the easiest of course: a magazine website, although that would have ideally be displayable in an OS4 browser.

Those are four options I can see at the moment.

I'd also like to add that if we manage to find a solution, I'm ready to give up my own blogging and contribute to the common effort instead.

@walkero

People have a wonderful quality that they may prefer something, rather irrationally, over something else that is way more practical, accessible, or cheaper. Take our PPC Amigas, for example: they are awkwardly under-featured, hard to get, and obscenely expensive, yet we stick to them despite having loads of alternatives. They give us some experience or feelings we wouldn't trade off.

Printed magazines are similar in a way. Almost anything they contain could be published on the web more quickly, more cheaply, and made instantly available to a much larger audience. Yet there is still something about picking up an actual magazine, leafing through its pages, looking at the layout and illustrations as they were meant to appear, and perhaps putting it on a shelf afterwards. It turns reading into a small physical ritual rather than just another piece of content passing through a screen. The web is unquestionably more practical, but practicality isn't always what makes something enjoyable.

So I guess when people are asking for a print magazine, they're pursuing the kind of enjoyment we've always had with mags. It's not that they don't know you can read stuff elsewhere.

@Valiant

Thanks - any support will be greatly appreciated! I also hope to update Rave over the summer with some interesting new features.

@kas1e

I tried to implement recording some time ago but I didn't get to a working state, so I put it aside to focus on other things. It's still a priority, though.

At the moment, I can recommend Thomas Wenzel's Advanced AHI Recorder.

@Valiant

Most probably, the error comes from something that toolbar.gadget needs to open. Please check is you also have installed the Enhancer Core requirements: select.gadget or shared.image is probably missing.

@OldFart

Technically possible, but believe it or not - it would be much easier to implement it as a new gadget than overload the existing one. The main reason is input handling; if you can stand me getting technical, here's the explanation.

Currently, the gadget displays the buttons (which are instances of glyph.image) and the text (which is drawn directly into the rastport). Neither the button images nor the text are gadgets, so if you click on them, the mouse input requires "manual" handling, for which radiobutton.gadget naturally has some code.

Now, if it were possible to replace the round radio buttons and the labels with regular button.gadgets containing text (as you're suggesting), the input-handling part would boil down to passing the GM_HANDLEINPUT message to the individual buttons. The heavy lifting for input would be done by the button.gadget class.

The result would be a radiobutton.gadget with two different layers for input processing. Which is exactly the kind of complexity I'm trying to reduce in BOOPSI. I prefer dedicated gadgets that do one particular job and do it well, rather than complex do-it-all ones, which are also harder to debug should anything go wrong.

@all

As AmigaOS 4.2 development continues, it is time to share another story from behind the scenes. Enjoy reading!

@all

Rave 1.10 has been released on OS4depot. I'd like to thank users who reported problems with the previous version - above all, Mike Steed, Niels Bache, and Javier de las Rivas - and helped with the testing.

As usual, there is an article on my Ko-fi blog that tells the story behind the current release. If you like what I've done and want to support my efforts, I won't say no to a coffee

Thank you, and enjoy!

@jabirulo

Quote:
This should now be fixed too for Rave 1.10.

@FlynnTheAvatar

Quote:
Open the information window on the Shell icon in SYS:System, remove "TABBED" from the WINDOW argument, and save.

@joerg

Quote:
That, or possibly some other specialist.

@FlynnTheAvatar

Quote:
Try disabling the tabbed mode before my console fix hits the public.

@icbrkr

Quote:
Absolutely not! The OS4 installation on my X5000 is very stable. But then again, I run more or less pure Update 3 - the only "foreign" component is the Radeon RX driver from the Enhancer Pack.

You seem to be having a hardware problem. I'd check your PSU or RAM modules first.

@nbache @jabirulo

I'll send a test build to both of you before releasing Rave 1.10.

@jabirulo

I can't reproduce this either. However, I reviewed the waveform gadget's selection hook, and I found a situation similar to the one that caused the race condition in the Settings, so I applied the same kind of fix just to be on the safe side.

@msteed

Quote:
It was a race condition. More details in my next blog post

@all

With the help of Niels Bache, the X1000-only crash has been fixed for Rave 1.10.

@Elwood

It has always been this way: a BOOPSI gadget that becomes activated receives all input until it is deactivated. So an active string gadget (for example) will swallow the ESC, instead of the application receiving it. It would require some redesign in the framework to do something about it. I have no idea (yet) what the needed scope of the redesign would be.