trouble with tree: vanishing cursor and focus problems

[lifeatt...@gmail.com]

FLTK 1.4, not too old; Linux MATE 20.1; gcc 9.3.0.

A small program derived from the tree-as-container example. Instead of using Fl_Tree_Item widgets, I'm drawing them dynamically. A Fl_Tree_Item consists of a checkbox and a label, except if the item is in "edit mode", when it is a checkbox and a Fl_Input. To enter "edit mode", the tree item must be RE-selected.

The problem: when I try to edit an existing tree item, the mouse cursor disappears over the window. After that, only keyboard navigation works in the tree, and I can't seem to RE-select an item any longer [assuming that hitting space twice on an item should RE-select it].

I've been thrashing on this for a bit, and would appreciate some ideas on what I've done wrong.

I'm attaching my stripped down program. To reproduce the issue, do the following:

1. run the program

2. Make sure the item "Outline" is selected. [shows in green]

3. Press enter. A new item is created: a Fl_Input appears, enter some text. Press enter.

4. The new item should be highlighted in green at this point. Repeat step 3 a couple of times. You should have three tree child items with text.

5. With the mouse, click on the 2d item to select it, then click again to RE-select it.

6. The Fl_input appears: start typing some text.

As soon as I start typing text at step 6, the mouse disappears. Pressing enter to finish editing doesn't restore the mouse; up and down arrow work to move the selection focus among the tree items but pressing space twice on a focused item doesn't RE-select it.

My thanks for any advice!

Kevin

[Ian MacArthur]

On 21 May 2021, at 17:24, lifeattickville wrote:
>
> I'm attaching my stripped down program. To reproduce the issue, do the following:
> 1. run the program
> 2. Make sure the item "Outline" is selected. [shows in green]
> 3. Press enter. A new item is created: a Fl_Input appears, enter some text. Press enter.
> 4. The new item should be highlighted in green at this point. Repeat step 3 a couple of times. You should have three tree child items with text.
> 5. With the mouse, click on the 2d item to select it, then click again to RE-select it.
> 6. The Fl_input appears: start typing some text.
>
> As soon as I start typing text at step 6, the mouse disappears. Pressing enter to finish editing doesn't restore the mouse; up and down arrow work to move the selection focus among the tree items but pressing space twice on a focused item doesn't RE-select it.

Though I note that if I click out of the edit box at step 6, the mouse re-appears and works normally.
I speculate that the code still thinks the Fl_Input widget has the focus in some way, and hence that the cursor is suppressed.
The mouse does not disappear until the edit box is dismissed, it is still visible whilst he edit is in progress.

[Ian MacArthur]

Yes, the input is hiding the cursor, and then if the input is dismissed whilst the cursor is inside it, it remains hidden.
If you move the mouse so the cursor is *out* of the edit box whilst the edit box still has keyboard focus, type sone more text, then when you dismiss the edit box the cursor is restored normally.

Or you can restore the cursor yourself - here’s a hack that seems to work (attached)

[Greg Ercolano]

On 5/21/21 9:24 AM, lifeatt...@gmail.com wrote:

FLTK 1.4, not too old; Linux MATE 20.1; gcc 9.3.0.

    I think what's missing is you need to tell Fl_Tree_Item about the widget by calling
    Fl_Tree_Item::widget(_text).

    The test/tree.cxx example shows how this works.

    begin(); // For some reason this magic is required when adding new items

    The reason for begin() is Fl_Tree is derived from Fl_Group, so when you add FLTK widgets
    to the items, you have to call begin() before creating the FLTK widget so it gets added to Fl_Tree's group.

    The reason for the Fl_Tree_Item::widget() is the item needs to know which FLTK widget
    is associated with it, so it can manage it during drawing.

    You may need to change your code a bit, as I think you had to jump through some hoops
    to get your MyText widget to work around the missing widget() call..

[lifeatt...@gmail.com]

Ian, Greg - Thank you very much! I'll try some tweaks when I have a chance and provide an update.

Kevin

[lifeatt...@gmail.com]

My thanks, again! I ended up with Ian's approach, partly because it felt simpler. I expect if I used the widget() approach with a group of the checkbox and fl_input, I could get that working too.

[imm]

On Sun, 23 May 2021, 15:47 lifeattickville wrote:

My thanks, again! I ended up with Ian's approach, partly because it felt simpler. I expect if I used the widget() approach with a group of the checkbox and fl_input, I could get that working too.

OK.

I'd caution that, whilst my workarounds frequently work, that doesn't mean they are necessarily the correct fix...

--
Ian
From my Fairphone FP3
  

[lifeatt...@gmail.com]

I'd caution that, whilst my workarounds frequently work, that doesn't mean they are necessarily the correct fix...

Understood! This got me past a blockage, improved my code, and I'll revisit again in the future.

[Greg Ercolano]

    I would not recommend adding FLTK widgets to Fl_Tree without assigning them with widget().

    I wrote Fl_Tree, and I'd say any behavior you get without doing that would be "undefined",
    as the tree doesn't know which item to associate the widget with, and therefore where or when
    to draw it.

[lifeatt...@gmail.com]

> I would not recommend adding FLTK widgets to Fl_Tree without assigning them with widget().

Thanks again for the feedback! I am convinced that some of the strange behaviors I've seen may very well be explained by failing to use widget().

>  as the tree doesn't know which item to associate the widget with, and therefore where or when to draw it.

Maybe I'm missing something I should know ... I thought the custom item drawing I'm doing was taking care of those concerns?

Kevin

[Greg Ercolano]

    Drawing is one thing, but the xywh() position of the actual widget is important for event
    delivery (mouse entering/exiting the widget's xywh perimeter) and Fl_Tree has to manage that
    when the parent widget is resized/scrolled, or things like margins and such are moved around.

    Your custom drawing code should all be based around the widget's own x()/y()/w()/h() which
    Fl_Tree/Fl_Tree_Item will manage for you as long as the association is made with widget().

    Your widget draw code should NOT be based on external widget's positions, such as the item's
    label_x() / label_y() / etc. if you're implementing an actual Fl_Widget derived widget.

    Instead of using label_xywh() for your starting XYWH, you should be using use x() / y() / w() / h(),
    as drawing outside the widget's own xywh area is generally bad. (An exception might be labels
    intentionally drawn around the outside of the widget's perimeter)

    And you shouldn't have to be concerned with moving the widget's position in the tree; as the parent,
    Fl_Tree and Fl_Tree_Item should manage all that, provided it's been told which item to associate
    the widget with, which is done with Fl_Tree_Item::widget().

    Arguably there should be an Fl_Tree_Item::begin() and Fl_Tree_Item::end() to let you parent your
    widget, just like other FLTK widgets, but for efficiency Fl_Tree_Item is not derived from Fl_Widget.