Introducing the Rear Window blog

@samo79

+1

@jabirulo

Quote:
I tried to reproduce it, but couldn't. But I'm not sure I understand exactly where you click/drag. Can you show it in a screen grab or something?

Also, that is on a Sam460, IIRC?


Best regards,

Niels

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

@neils & @trixie

See pic attached


http://jabirulo.byethost13.com/temp/rave01.png

when click on green zone and dragging to select a "part" of (previewed) sample here it freezes.

SAM460ex

@jabirulo

Yeah, that's what I thought you meant. So no, I couldn't reproduce that either.

So maybe it is/was specific for Sam460? Since we are in the murky waters of timing issues, that wouldn't be completely impossible, as it has yet another speed than the X1000 and X5000 which we tested on so far.

Best regards,

Niels

@nbache @jabirulo

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

@trixie

ok thx

@jabirulo

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

@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!

@trixie

Thanks for the update.

---
redfox

@trixie
Thanks for another update!

@all

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

@trixie

As per usual, peeking through the Rear Window is always a great pleasure and I'm glad some insight was provided about the actual state of some component's code.
Now that the code is still fresh in your memory, maybe you could give the following a thought:
Remove the 'button'-image from the gadget altogether (tag controlled?) and turn the gadget in a series of pushbuttons, where the labels themselves form the buttons. And that in both vertical and horizontal layouts. The vertical layout becomes then more of a sticky chooser gadget.

Keep on going!

OldFart

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

@trixie

Thanks for sharing your stories and taking the time to explain a few things. Nice looking windows and radio buttons.

---
redfox