Discrepancy between Fl_Choice and Fl_Input_Choice

[pvr...@btinternet.com]

I noticed a discrepancy between the drawing of Fl_Choice and Fl_Input_Choice in the size of the menu button. It is particularly noticeable having one above the other.

I see the code in Fl_Choice is:

// Arrow area

int H = h() - 2 * dy;

int W = Fl::is_scheme("gtk+") ? 20 : // gtk+ -- fixed size

Fl::is_scheme("gleam") ? 20 // gleam -- fixed size

: ((H > 20) ? 20 : H); // else: shrink if H<20

int X = x() + w() - W - dx;

int Y = y() + dy;

Whereas in Fl_Input_Choice is:

virtual int menu_x() const { return(x() + w() - 20 - Fl::box_dx(box())); }

/** See menu_x() for info. */

virtual int menu_y() const { return(y() + Fl::box_dy(box())); }

/** See menu_x() for info. */

virtual int menu_w() const { return(20); }

/** See menu_x() for info. */

virtual int menu_h() const { return(h() - Fl::box_dh(box())); }

In my case I set h() to 20 in both cases and using default scheme so the menu button for Fl_Choice looks square and the Fl_Input_Choice oblong.

I can probably sort this out by overriding the Fl_Input_Choice inp_w(), menu_x() and menu_w() functions.

Regards Phil.

[Philip Rose]

Adding the screen shot of the discrepancy.

Phil.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/3f1a648d-299c-4279-b95d-bf6254b9e93fn%40googlegroups.com.

[Philip Rose]

On 19/05/2024 16:37, 'Philip Rose' via fltk.general wrote:

Adding the screen shot of the discrepancy.

Adding this code to my extension of Fl_Input_Choice makes them the same size, but the arrow heads are different - see attached

// Change drawing methods to make menu arrow similar to Fl_Choice

virtual int menu_w () const {

if (menu_h() < 20) return menu_h();

else return 20;

}

virtual int menu_x() const { return(x() + w() - menu_w() - Fl::box_dx(box())); }

virtual int inp_w() const { return(w() - Fl::box_dw(box()) -menu_w()); }

Phil.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/b95f6542-2604-4bba-be7b-bf26d6fb89ca%40btinternet.com.

[Philip Rose]

On 19/05/2024 16:54, 'Philip Rose' via fltk.general wrote:

On 19/05/2024 16:37, 'Philip Rose' via fltk.general wrote:

Adding the screen shot of the discrepancy.

Adding this code to my extension of Fl_Input_Choice makes them the same size, but the arrow heads are different - see attached

// Change drawing methods to make menu arrow similar to Fl_Choice

virtual int menu_w () const {

if (menu_h() < 20) return menu_h();

else return 20;

}

virtual int menu_x() const { return(x() + w() - menu_w() - Fl::box_dx(box())); }

virtual int inp_w() const { return(w() - Fl::box_dw(box()) -menu_w()); }

Phil.

I can see the difference:

In Fl_Input_Choice::Input_Menu_Button::draw() - the rectangle is "inset" by 1. in Fl_Choice::draw() it is "inset" according to FL_UP_BOX . This is not readily hackable, without changing the FLTK code.

Phil.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/23fd0851-75b6-4984-b3b5-01507a5900fd%40btinternet.com.

[Bill Spitzak]

I agree these should match and FL_Choice is doing the correct thing.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/0fb1e5c4-d257-44aa-8134-c144ae5f1ac5%40btinternet.com.

[Greg Ercolano]

Mmm, seems like this should be reported as a bug.
OP, if you create a github issue, I'll either assign myself (apparently git blame shows me for the lines of code in question), or if another dev feels better situated to handle it, they can take it:

```

47cd9a11a0 (Greg Ercolano      2022-01-13 07:28:00 -0800  84)   virtual int menu_x() const { return(x() + w() - 20 - Fl::box_dx(box())); }
47cd9a11a0 (Greg Ercolano      2022-01-13 07:28:00 -0800  85)   /** See menu_x() for info. */
47cd9a11a0 (Greg Ercolano      2022-01-13 07:28:00 -0800  86)   virtual int menu_y() const { return(y() + Fl::box_dy(box())); }
47cd9a11a0 (Greg Ercolano      2022-01-13 07:28:00 -0800  87)   /** See menu_x() for info. */
47cd9a11a0 (Greg Ercolano      2022-01-13 07:28:00 -0800  88)   virtual int menu_w() const { return(20); }
47cd9a11a0 (Greg Ercolano      2022-01-13 07:28:00 -0800  89)   /** See menu_x() for info. */
47cd9a11a0 (Greg Ercolano      2022-01-13 07:28:00 -0800  90)   virtual int menu_h() const { return(h() - Fl::box_dh(box())); }

```
..this way when I solve it, you can signoff on the solution.
I already have another recent issue waiting to be solved, so I'll try to handle both.

[Greg Ercolano]

Here's a suggested patch that might be a good start, solving for the default scheme case.

However, to solve for the larger case of different schemes, Fl_Choice and Fl_Input_Choice have decidedly taken different evolutionary paths, the latter offering an internal "InputMenuButton" class to handle drawing the arrow box with virtuals for letting the app overload the input and menu xywh methods to control sizing, whereas Fl_Choice has the logic hardcoded in draw(). So keeping the two in sync means either keeping the code separate, or perhaps better, implementing a common class to handle drawing the arrow box, so that the two widgets share common code for this, as it seems like the larger goal is to have the widgets look completely alike in different schemes, just one with an input widget and the other without.

[Greg Ercolano]

While working on the alternate schemes case to try to match the drawing behavior, I noticed Fl_Choice has some odd drawing behavior in the non-default schemes that surely needs to be fixed; it has some hard coded numbers for its "vertical divider" that just don't seem right; from Fl_Choice::draw(), we have (emphasis in bold red):

    if (Fl::is_scheme("gtk+") ||
        Fl::is_scheme("gleam") ||
        Fl::is_scheme("oxy")) {
      // draw the divider
      int x1 = x() + w() - 20 - dx;
      int y1 = y() + h() / 2;

      fl_color(fl_darker(color()));
      fl_yxline(x1, y1 - 8, y1 + 8);
 
      fl_color(fl_lighter(color()));
      fl_yxline(x1 + 1, y1 - 8, y1 + 8);

That just can't be right; when the widget is resized, that results in fixed height lines that just can't be intentional:

Will see if I can fix that too in Fl_Choice while my head is in this code, as I assume that should be resolved.

[pvr...@btinternet.com]

Mmm, seems like this should be reported as a bug.
OP, if you create a github issue, I'll either assign myself (apparently git blame shows me for the lines of code in question), or if another dev feels better situated to handle it, they can take it:

Ticket raised.

Phil..

[Greg Ercolano]

On 5/19/24 14:15, 'pvr...@btinternet.com' via fltk.general wrote:

Mmm, seems like this should be reported as a bug.
OP, if you create a github issue, I'll either assign myself (apparently git blame shows me for the lines of code in question), or if another dev feels better situated to handle it, they can take it:

Ticket raised.

    Great -- thanks; issue #978 for those following.
    Continuing development conversation there.

    Devs, I have questions raised in that issue that probably needs some discussion to solve the non-default scheme cases.