FLTK logo

Re: [fltk.coredev] Insomnia, Fl_Flex, and resizable

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.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Insomnia, Fl_Flex, and resizable "'melcher.... Oct 27, 2022  
 
tl;dr : sorry for the long text. Withdrawing my first idea, I suggest we move child related data to the children and not allocate it as part of the parent, and create a standardised interface for that.

Ok, I see the points.

So changing Fl_Pack is not realistic. And since Fl_Flex is in fltk_rs, it's probably wise to keep the method names as is. Fl_Groups seems to avoid successfully to have pointers dangle, or we would know about it.

I am just very much in favour to point at something else only once, because otherwise there are just too many locations to keep track of. For example, if I delete and Widget, it may have a parent that links back to it, but it also may be resizable, so my parent may have a second pointer. Now with Fl_Flex, there may be just another pointer that tells me that my widget has a fixed size. 

This is by no means a drama, but if it is possible to avoid it easily, I would. So here are my ideas:

  1. Storing relative width and height was a bad idea by me, because different Groups may want to store very different things per child. 
  2. Making the Group handle an array of widget data (Fl_Group::init_size()) or widget pointers (Fl_Group::resizable()) is inherently unsafe, even if we got away with it for 30 years. But that's also part of what kept us from implementing new Groups with better resizing options like Flex and Grid.
  3. Making Fl_Group::insert(), remove(), and clear() virtual would make implementing Flex and Grid easier and safe.
So I withdraw my original idea and suggest that we add a group_data pointer to every widget. This pointer is reserved for use by the current parent exclusively, and the parent can store whatever it wants. It should delete that data when removing a widget, but if it doesn't, the widget removes the data when being deleted (no leak). If it is added to a new Group, the new Group will simply replace the group_data with its own data. 

Yes, it adds a pointer to Fl_Widget, but OTOH it removes pointers and code in Fl_Group.

To have a little code, I suggest:

  class _Fl_Group_Data {
  public:
    virtual ~Fl_Group_Data();
  };

  class Fl_Widget {
    ~Fl_Widget() {
      ...
      group_data(NULL);
    }
    void group_data(_Fl_Group_Data*); // replace current group data with new group data
    _Fl_Group_Data *group_data();
  };

class Fl_Fancy_Group {
  class _Fl_Fancy_Group_Data : public _Fl_Group_Data {
    double width_factor;
    int initial_width;
    ...
  };
  void insert(FL_Widget *w) {
    w->group_data(new _Fl_Fancy_Group_Data(50.0, w->w()));
    ...
  }
  void remove(Fl_Widget *w) {
    ...
    w->group_data(NULL); // will call 'delete' for us
  }
};





--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/3cecd8cd-b50c-491a-bc21-cca4e36e539fn%40googlegroups.com.
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'.