Introduce command to share with menu and toolbar

[qPCR4vir]

Hi, The goal of this PR is to:

Introduce command to share with menu, toolbar, button and checkbox

• [x] Plan minimum: just use one command to initialize items in:
  • [x] menu,
  • [x] toolbar,
  • [x] button and
  • [ ] checkbox
• [ ] plan maximum: share state: selected, pushed, checked, etc. with (drawer read from here?):
  • [ ] menu,
  • [ ] toolbar,
  • [ ] button and
  • [ ] checkbox

please, compare: widget_show2 manual item creation with: widget_show2 created with command

This is my first version, and you will need to review and redesign a few thing in it, but I hope this is the first draft of what we wanted. Maybe the correct way is to create a command "interface" to add to any of the supported classes?

First just I will try to compare/document the possible affected parts:

• menu vs. toolbar: toolbar is a widget, menu - not.

  • menu: hold a plain ptr to an implement which use structures in a drawerbase::menu namespace. The later includes a menu_type, menu_item_type, and the enum checks,

        enum class checks
        {
            none,
            option,
            highlight
        };

    menu_item_type hold a plain pointer to a menu_type and all the state-data of the item which can be acceded with an item_proxy which hold a pointer to the menuand the position order of the item. A new item can be added with menu::append or menu::insert.

        enum class tools
        {
            separator,
            button,
            toggle,
            dropdown
        };

  • toolbar: the drawerhold a plain pointer to a drawer_impl_type that hold an item_container of toolbar_items. The later hold the state-data. A new item can be added with toolbar::append or with item_proxy::dropdown_append.
  • button: is a widget_object class, which hold a DrawerTrigger, a shared Events and an scheme_type scheme_. The state-data is hold deeper in the windows structure (like the caption), and in these members. The DrawerTrigger holds a unique_ptr<impl> that have attributes where the state-data image, focused, pushed, etc are.
  • checkbox: is a widget_object class, which hold a DrawerTrigger, a shared Events and an scheme_type scheme_. The state-data is hold deeper in the windows structure (like the caption), and in these members. The DrawerTrigger holds a unique_ptr<implement> that have element::crook_interface::data data_; where the state-data check_state { unchecked, checked, partial }, radio, etc are.

• [ ] Implement/use checks/tools

• [x] create command: a no-widget class, wich state-data useful to set and to share menu, toolbar, buttonand checkbox

  • [x] title/text, tooltip/status
  • [x] event handler
  • [x] image (a shared type),
  • [ ] set/get image
  • [ ] checks style
  • [ ] flags: enabled, checked

• [ ] Make menu and toolbar API similar:

  • [ ] prefer item_proxy

• In menu:

  • [x] menu::append(shared_command)
  • [x] menu::insert(shared_command) .
  • [ ] in menu_type
  • [ ] in menu_item_type <---- real data here (generalize?)
    • [x] hold a shared_command
    • [x] add constructor that take a shared_command
    • [ ] set/get shared_command (to be used by other constructors)
    • [ ] really need 'linked'?
  • [ ] add to item_proxy
  • [ ] set/get shared_command (to be used by other constructors)
  • [ ] set/get image
  • [ ] answerer()
  • [ ] reuse renderer_interface?

• In toolbar:

  • [ ] in toolbar_item <---- real data here

    • [x] hold a shared_command
    • in constructor that take a type, text, image and event
      • [ ] create a shared_command
    • [x] add constructor that take a shared_command
    • [ ] set/get shared_command (to be used by other constructors)

  • [ ] in dropdown_item <---- real data here

    • [x] hold a shared_command
    • in constructor that take a type, text, image and event
      • [ ] create a shared_command

  • [x] add constructor that take a shared_command

    • [ ] set/get shared_command (to be used by other constructors)

  • [x] add item_proxy& dropdown_append(shared_command command);

  • [x] add item_proxy append(tools t, shared_command command);

  • [x] add void insert(size_type pos, tools type, shared_command command)

    • [ ] return item_proxy

  • [x] add void push_back(tools type, shared_command command)

    • [ ] return item_proxy

  • [ ] dropdown_item construct take a menu and vice ferse?

  • In button:

  • [x] hold a shared_command

  • [x] add constructor that take a type, text, image and event

  • [x] create a shared_command

  • [x] add constructor that take a shared_command

  • [ ] set/get shared_command (to be used by other constructors)

  • In checkbox:

  • [ ] hold a shared_command

  • [ ] add constructor that take a shared_command

  • [ ] set/get shared_command (to be used by other constructors)

[cnjinhao]

First of all, thanks for your efforet, very good idea!

no struct arg_menu ?

Because menu::item_proxy is like a handle/proxy of a menu item, not an event_arg.

really need 'linked'?

What does linked mean? Does it mean that dropdown_item directly refers to the shared command? I think it would be better to make dropdown_item directly refers to the shared command, in default, and make it Copy-on-Write. Then the redundant data members can be eliminated.

reuse renderer_interface?

Yes, the renderer is cloneable. We can make tiny changes based on the current renderer just with a small piece of code.

dropdown_item construct take a menu and vice ferse?

Sorry, I don't understand, would you please explain it.

[qPCR4vir]

really need 'linked'?

What does linked mean?

oh, sorry, I just wanted to know how menu_item_type::linked member works.

Does it mean that dropdown_item directly refers to the shared command? I think it would be better to make dropdown_item directly refers to the shared command, in default, and make it Copy-on-Write. Then the redundant data members can be eliminated.

yes, something like that is a good solution! It is not trivial to have a really good solution. I only implemented the simplest possibility, and then, maybe, you will have some day time to make it better! I will try to implement a few more details, but for a robust design one need more experience.

dropdown_item construct take a menu and vice verse?

Sorry, I don't understand, would you please explain it.

My bad. I mean that a sub-menu and a toolbar dropdown are both a kind of containers of "command-items" and it could be great if we could just pass a menu to toolbar::append or item_proxy::dropdown_append to add all the items in one instruction.