This is something I would like to put in, but it can get really messy when you consider you can have 4 CMDHDs. There is also the SDL build which has a far more restrictive space on the status bar. In the future, we plan to break apart the emulator from the GUI front end so anyone can make their own. Maybe someone will come up with a better way to do it. I always thought of having a widget type system where you could move the individual components around, or turn them off entirely. But that is a long way off and not my general area. I work on the underlying emulation and integrating more "real" devices into the system.
I will set the GUI maintainer to this feature request.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Having different LEDs and LED layouts depending on drive type would be nice to have indeed. In the Gtk UI we already have a minor drive type-dependent customization of the LEDs: they can have different colors (the 1541 flashes red on activity, the 1541-II flashes red).
For this to work we'd have to extend the API used to inform the UI so the UI can react to drive type changes and thus LED layout (number of LEDs, colors, labels/tooltips). But as Roberto mentioned, there's not a lot of space to work with on the status bar, so we might then have to consider making the individual widgets of the status bar (re)movable.
I know Gtk allows some drag and drop style manipulation of certain container widgets, toolbars and a list/tree widgets come to mind, so it can be most likely be done. And if Gtk doesn't allow this anymore (they tend to deprecate certain features they don't deem necessary or fitting their design philosophy) I could always add a little context menu for the status bar where the user can enable or disable widgets of the status bar.
As for the SDL UI, it has even less space and the "status bar" currently consists of 40 characters of plain text. We could of course just render our own custom "widgets" on the canvas, but that'll involve quite a bit of code, and thus time.
So I'll definitely keep this mind, it would a nice feature to have, at least for Gtk and any other future UIs (should they spawn when the planned GUI-as-a-client API is implemented). But right now I'm a bit occupied with implementing customizable joystick mappings and generalizing certain UI code, so adding this won't happen soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is something I would like to put in, but it can get really messy when you consider you can have 4 CMDHDs. There is also the SDL build which has a far more restrictive space on the status bar. In the future, we plan to break apart the emulator from the GUI front end so anyone can make their own. Maybe someone will come up with a better way to do it. I always thought of having a widget type system where you could move the individual components around, or turn them off entirely. But that is a long way off and not my general area. I work on the underlying emulation and integrating more "real" devices into the system.
I will set the GUI maintainer to this feature request.
Having different LEDs and LED layouts depending on drive type would be nice to have indeed. In the Gtk UI we already have a minor drive type-dependent customization of the LEDs: they can have different colors (the 1541 flashes red on activity, the 1541-II flashes red).
For this to work we'd have to extend the API used to inform the UI so the UI can react to drive type changes and thus LED layout (number of LEDs, colors, labels/tooltips). But as Roberto mentioned, there's not a lot of space to work with on the status bar, so we might then have to consider making the individual widgets of the status bar (re)movable.
I know Gtk allows some drag and drop style manipulation of certain container widgets, toolbars and a list/tree widgets come to mind, so it can be most likely be done. And if Gtk doesn't allow this anymore (they tend to deprecate certain features they don't deem necessary or fitting their design philosophy) I could always add a little context menu for the status bar where the user can enable or disable widgets of the status bar.
As for the SDL UI, it has even less space and the "status bar" currently consists of 40 characters of plain text. We could of course just render our own custom "widgets" on the canvas, but that'll involve quite a bit of code, and thus time.
So I'll definitely keep this mind, it would a nice feature to have, at least for Gtk and any other future UIs (should they spawn when the planned GUI-as-a-client API is implemented). But right now I'm a bit occupied with implementing customizable joystick mappings and generalizing certain UI code, so adding this won't happen soon.