Hello,
I gave a look to the sources of GTK3 port and I noticed one thing about the widget for listing the baud rates.
If you look into vice\src\arch\gtk3\widgets\superpetwidget.c, you will see there is an array called baud_rates[]
that lists the available numeric baud rates. This array is used when calling acia_widget_create()
, inside superpet_widget_create()
.
Then, if you look inside vice\src\arch\gtk3\widgets\aciawidget.c, you will see that there is a mechanism for translating the integer array with the baud rates into an array of vice_gtk3_combo_entry_int_t
structures.
It is not clear to me the reason because an array of vice_gtk3_combo_entry_int_t
is not declared directly inside superpetwidget.c: by doing that, the code inside aciawidget.c will be simplified a lot, because functions generate_baud_rate_list()
, free_baud_rate_list()
and the on_destroy()
handler could be deleted.
To simplify the code maintenance, you may also declare such array in this way:
#define DECLARE_BAUD(_bps) { #_bps, _bps }, static const vice_gtk3_combo_entry_int_t baud_rates[] = { DECLARE_BAUD(300) DECLARE_BAUD(1200) DECLARE_BAUD(2400) DECLARE_BAUD(9600) DECLARE_BAUD(19200) { NULL, -1 }, };
Before providing a patch, I was wondering if there is a particular reason because this has been made, like fetching the baud rates at runtime from an external file... but I have not seen that and acia_widget_create()
seems to be called only in this point.
What do you think?
If you will find this idea interesting, this is how I made it.
There's a bug about the PET ACIA settings here: #1605, which mentions moving the PET-specific ACIA settings to 'Settings -> Peripheral devices -> RS232' which is where the other emulators have their ACIA settings.
The idea, IIRC, was to reuse the PET ACIA widget code for other emulators as well, which may or may not have a different set of baud rates.
Should the baud rates be a fixed list then indeed your macro-based approach would be preferred.
closing this one, outdated