Fl_Input_Choice dropdown bellow text

[danielc...@gmail.com]

Hi,

The Fl_Input_Choice shows the dropdown on the right, is it possible to show it at the left with the right side aligned with the right of the dropdown button?

Thanks

[Matthias Melcher]

Not that I know of, but IMHO what you describe should be the default behaviour.

[Greg Ercolano]

On 1/7/22 6:22 AM, 'Matthias Melcher' via fltk.general wrote:

Not that I know of, but IMHO what you describe should be the default behaviour.

    I believe to support the user fully redefining positioning of the internal input/pulldown widgets, the currently private methods inp_{xywh}() and menu_{xywh}() would need to be virtual and protected so that a subclass could redefine them, and thus redefine the
    positioning during e.g. resizing.

    Also, it'd probably be good if the align() method for the Fl_Group could be changed for LEFT or RIGHT aligned for the input field, with the current orientation being the default.

    I'll try making a patch and if it works as expected, and if so, add it.

[Albrecht Schlosser]

On 1/7/22 5:14 PM Greg Ercolano wrote:

On 1/7/22 6:22 AM, 'Matthias Melcher' via fltk.general wrote:

Not that I know of, but IMHO what you describe should be the default behaviour.

Actually the default behavior is to display the menu in a place where it fits on the screen. This can be below or above the widget and it can move to the left as far as necessary. That's from testing by moving the window around until the Fl_Input_Choice widget is near one of the borders of the screen (monitor).

    I believe to support the user fully redefining positioning of the internal input/pulldown widgets, the currently private methods inp_{xywh}() and menu_{xywh}() would need to be virtual and protected so that a subclass could redefine them, and thus redefine the
    positioning during e.g. resizing.

    Also, it'd probably be good if the align() method for the Fl_Group could be changed for LEFT or RIGHT aligned for the input field, with the current orientation being the default.

I'm not sure if changing the meaning of the align() member is such a good idea. However, this is a specialized widget and we could add another flag member if necessary. It's now a good time to change the ABI before FLTK 1.4.0 will be released.

    I'll try making a patch and if it works as expected, and if so, add it.

See above, take care not to prevent the default positioning mechanism. I think, if whatever you do only changes the *default position* it should be okay.

[Greg Ercolano]

On 1/7/22 8:28 AM, Albrecht Schlosser wrote:

I'm not sure if changing the meaning of the align() member is such a good idea.

    Right, realized that as I was implementing.

    I was thinking the extra bits in align() could be used, but yeah, perhaps that's a bad idea,
    as the reserved FL_ALIGN_XXX bits might be used for something else in the future, and there
    isn't a FL_FREE_ALIGN (like we have for label types) to identify where reserved bits start.

    So I can think of a few ways to do it:

    1. Add a new Fl_Align _input_align; member value, and add an accessor pair to manage it:

        void input_align(FL_ALIGN_LEFT|RIGHT);
      Fl_Align input_align() const;

    2. Use the accessor names in #1, but use the internal Fl_Input widget's align() value to hold
        the LEFT/RIGHT state (avoids creating a new member value), since Fl_Input's label() is never shown.

    Perhaps there's better ideas -- defining API's was never a personal strong point.

However, this is a specialized widget and we could add another flag member if necessary. It's now a good time to change the ABI before FLTK 1.4.0 will be released.

    Right, that's what I was thinking.

[Greg Ercolano]

Opened issue #361 for this as a request for enhancement (RFE):
https://github.com/fltk/fltk/issues/361

I'll follow up there with patch suggestions and test program(s).

[Greg Ercolano]

    I've actually moved the OP's request to issue #362 instead:
    https://github.com/fltk/fltk/issues/362

    Issue #361 is for a slightly different issue, one I misinterpreted
    the OP's request to be, but will nevertheless be implemented separately.