RFC: Features (and Widgets) to Implement Next

[abonander]

• Specialized Dialogs
  • Progressbar dialog
  • File chooser dialog
  • Color chooser dialog
  • Font chooser dialog
  • Synchronous variants (IupGet[Color|File|Text], IupMessage)

Addendum 1:

• Toggle/Radio Buttons/Checkboxes (all seem to be the same control class in IUP)
• Menus (menubars and popup menus)
• Tabbed containers
• Spinners (textbox with decimal value and up/down buttons)
• Sliders (linear control with sliding handle)
• Dropdowns/multi-selects
• Frame

Features that can be relegated to separate crates:

• Canvas drawing (CD backend and OpenGL)
  • CD-drawn controls
  • OpenGL-drawn controls
• Other IUP extended controls (matrix, plotter, browser control)
• Tree, just because it's so complex it should have its own crate

[lxn]

Has anyone started work on the toggle stuff? If not, I would like to try my hand on it.

[abonander]

Be my guest! Although perhaps some API design brainstorming is in order first.

It looks like checkboxes and radio buttons are both created with one function, IupToggle, and are only differentiated by what container they're added to. If added to any regular container, they come out as checkboxes, but when added to (a child of) IupRadio, they become radio buttons.

But IupRadio is a unitary container like IupDialog, and so needs a sub-container to hold multiple elements. It also supports having toggles within nested containers. This makes encapsulating it in a simple builder API problematic, because it would limit the user's options in laying out the toggles and adding things like frames and labels.

Then there's the actual value of the toggles themselves. Like everything with IUP, it's done with strings instead of integers so it's a bit of a pain to match against. There's "OFF", "ON", and a setter-only "TOGGLE" value. If we decide to support 3-state toggles then there's also "UNDEF". If we exclude 3-state toggles (kind of a niche feature to begin with), then we can encapsulate this with a bool getter+setter and then a toggle() method.

And we also have to consider callbacks. The ACTION callback takes an Ihandle* and an int (1 for ON and 0 for OFF), whereas the VALUECHANGED_CB just passes the Ihandle*, so we can simply implement the OnValueChanged trait for this type and let the user check it themselves in the callback.

The Radio container itself needs methods to set and get which toggle is selected as well. The IUP API allows for both setting/getting by name and by Ihandle*, we should support this in as simple an API as possible. I'd like it to have a callback that is fired when any toggle is selected so the user can match on it themselves, but I was unable to find precedent in the one other UI toolkit I know (Swing) and it'd be kinda complicated anyways.

I'm going to be away for the weekend but I should have Internet access. I'll be working on this stuff when I have time to kill. Feel free to start working on it and let me know if you have any questions or anything.

[lxn]

Thanks for your detailed writeup.

I had considered to use this library for a project, but just today it was decided to do it in Go. So I probably won't have much time to contribute, sorry :(

[abonander]

Ah, well. The tool you'd rather use isn't always the right tool for the job. Thanks for your interest! Check back sometime, huh?