FLTK logo

Re: [fltk/fltk] possible incoherence in Fl_Tree_Item drawing (Issue #298)

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.issues  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: [fltk/fltk] possible incoherence in Fl_Tree_Item drawing (Issue #298) AshfordN Nov 28, 2021  
 

Pretty sure the example can be done without deriving from Fl_Tree_Item.. it'd just be not as clean from an OO point of view.

Yeah, there are ways of independently managing the icon state, but like you said, none are really clean (or efficient) at the moment.

Not sure about rust, but you could use Fl_Tree_Item's userdata as a pointer to your own structure of data per item to keep track of your widget/icon state info, and the my_handle() method I added to Fl_Tree_Item could just as easily be a static function that takes a pointer to the Fl_Tree_Item as a parameter. The callback can then get the item and pass it to the static global function my_handle() which can do the work it does.

userdata pointers are not widely used by the Rust binding, probably because there is no idiomatic way of managing them. This means that no interface currently exists to cleanly bind the icon state to the Fl_Tree_Item...at least none that I can think of. I apologise for the multiple references I'm making to a project that has nothing to do with this repo; but at this point, I'm satisfied that we have mostly resolved the issue here. Any further challenges I'm having, is due to the specific limitations of the Rust binding.

I just have one more suggestion, as it relates to @erco77 previous comment:

Meanwhile, I can open a separate RFE issue requesting a new flag that forces any child widget() to resize to the full width of the item.

Instead of creating a new flag, I think it might be easier/cleaner to simply repurpose the output of draw_item_content() to determine the position of any assigned widget, and xmax could still be computed as wid.x() + wid.w().


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.