tab widget

[Xeverous]

I would like to implement tab (and some other widgets) but I need some guidance regarding library's code - everything is so composable that I have a feeling I will write duplicated code most of time time.

I have read the post and checked how button is implemented (array composite of 2 elements) but I still don't get many things:

• What is the purpose of _base types? That is, proxy vs proxy_base, composite vs composite_base etc
• Why do various elements are class templates and inherit from typename Base? What's the benefit of doing this over just inheriting from element?
  • Are there any restrictions on the inheritance (eg Base must be element or a type derived from it)?
• I figured out that the support directory is a collection of helpers (implementation details etc) but what is the reliation of element/* to element/gallery/*? Both directory trees contain button header and source - their reliation/dependency is unclear to me.
• What are some very good widget example implementations that I should look at when implementing other widgets (eg if I would like to implement radio box, I should surely check check box)?

[djowel]

On one hand, I was thinking there's a lot I need to answer here and for the sake of expediency, I thought about doing a video chat on this, and your other post on radio-boxes. On the other hand, it might also be good to write down my answer that can become basis for documentation. I'm a bit torn on how to proceed, given that I am also in the middle of something else. Allow me some time to think about how best to approach this, OK? A day or two perhaps...

[Xeverous]

Ok, I'm fine with realtime conversation. From my previous experience from work and other collaborations (mostly university stuff) the most productive way to solve such problems was to actually do all of these things together, that is:

• realtime voice chat (with screen sharing if some code/schemas/diagrams was needed to be presented)
• writing documentation basis during the conversation
• writing down any agreements/decisions (usually things to do for everyone up to the next meeting)

Looking forward to your decision.

[djowel]

Sounds good to me. Actually, I'm thinking the same... Let's do it. Email me at djowel-at-gmail-dot-com and let's schedule a video chat.

[Xeverous]

So the design has been quite well-defined during our latest talk, but I have some implementation-related questions:

For now, lets assume the widget is named notebook as it is the best name for me currently and you haven't commended on this.

• base class notebook_element_base
• classes vnotebook_element, hnotebook_element
• factory functions vnotebook, hnotebook (each with 2 overloads) that take 2 arguments (bar of tabs + the screened deck element) - This will cover all 4 layouts where the bar of tabs has different placement (top, bottom, left, right). Then such factory functions call vtile/htile to create a single widget that automatically implements functions such as limits, events etc.

Example use would be:

// +------+------+------+------+-----+
// | tab0 | tab1 | tab2 | tab3 | ... |
// +------+------+------+------+-----+
// |                                 |
// |            screen               |
// |         (deck element)          |
// |                                 |
// |                                 |
// +---------------------------------+

auto w = vnotebook(
    htile(tab0, tab1, tab2, ...), // bar of tabs
    deck(screen0, screen1, screen2, ...) // deck element which switches depending on tab
);

My questions:

• What the argument types for the notebook factory functions should be? Currently (from what vtile/htile and deck factory function returns) notebook factory functions should accept array_composite<N, v/htile_element> and array_composite<M, deck_element> and static_assert(N == M).
• Deck element (what I call the notebook screen) switching depending on the selected tab is very trivial to implement but in order to make tabs clickable, each of them should be wrapped in a button - am I right? I don't see a clean way to perform this if the factory function would accept a composite which already has an array of v/htiles. Do we want a key_intercept there? What's your view on this problem?
• I'm concerned how the bar of tabs would be rendered - so far it consists of few elements that do not change appearance. Should we move this burden to the user (and expect the user to pass a proper "bar of tabs") or should the notebook factory (apart from making tabs clickable) wrap the bar of tabs in some shadows to signal which one is selected?

Unrelated question:

• Why does each htile/vtile element have a vector? Why each element in a composite needs this vector?

[djowel]

This will be a little bit terse, but I'll see if I can reply with more substance tomorrow.

For now, I suggest working on the tab (very similar to radio_button) and refactoring the similarities. You'll have to do some simple canvas drawings for the tab image (un-selected and selected --typically the selected is lighter than the unselected), using this as the basis:

https://github.com/cycfi/elements/blob/develop/lib/src/element/gallery/radio_button.cpp#L10

where:

1. state: selected or unselected
2. hilite: mouse overs over the button (showing some feedback that it is clickable)

Then you can make an example using it, again following the radio_button example in the buttons example.

Let's continue when you have a working tab group example (htile of tabs).

[Xeverous]

radio_button::select has some logic duplication (state is checked twice):

   void basic_radio_button::select(bool state)
   {
      if (state != is_selected())
         value(state);
   }

   bool basic_radio_button::is_selected() const
   {
      return value();
   }

   bool layered_button::value() const
   {
      return _state;
   }

   void layered_button::value(bool new_state)
   {
      if (_state != new_state)
         state(new_state);
   }

It could be just:

   void basic_radio_button::select(bool state)
   {
      value(state);
   }

[Xeverous]

Trying to grasp and move upwards the similarities between check_box and radio_button - I don't like the situation that both widgets create copies of the string and actually store 2x (string + state representation widget) instead of 2x state representation widget + 1x string.

[Xeverous]

I think that radio buttons and checkboxes should be using label factory. Then someone could easily htile them to decide whether they want text on the left or right side of the check/radio.

[djowel]

It could be just:

   void basic_radio_button::select(bool state)
   {
      value(state);

I think you assuming that is_selected() and value() are final (which is probably a good assumption).

[djowel]

Trying to grasp and move upwards the similarities between check_box and radio_button - I don't like the situation that both widgets create copies of the string and actually store 2x (string + state representation widget) instead of 2x state representation widget + 1x string.

Yes, I thought so too. That is also why I started the text_reader thing: https://github.com/cycfi/elements/blob/develop/lib/include/elements/element/text.hpp#L23

[Xeverous]

Possible, that migth simply be an "overassumption" considering there are many virtual calls.

[Xeverous]

So, got any rought plans how a checkbox/radio button would store text? How would you compose them using label and text_reader interface?

[djowel]

So, got any rought plans how a checkbox/radio button would store text? How would you compose them using label and text_reader interface?

The basic idea is that one should be able to make a label that uses a string_view, (-- even an entirely generated string, but that is not relevant here). I'm not sure about the API yet (see below). Let's cross that bridge later :-)

For example, I would like to detect or have the user hint on literal strings. In such cases, you don't even need a std::string. And there are many cases where you just want to pass string_view. The string is already stored somewhere else (e.g. some resources for internationalization e.g. a std::map)... Basically a lifetime management issue.

[Xeverous]

You can make multiple constructors:

• const char(&)[N] - this must be a C-string, guuaranteed infinite lifetime
• std::string_view - user manages lifetime
• std::string - widget manages lifetime
• const char* = delete because it is unknown, require the user to wrap the call into string or string_view.

[djowel]

So, got any rought plans how a checkbox/radio button would store text? How would you compose them using label and text_reader interface?

The basic idea is that one should be able to make a label that uses a string_view, (-- even an entirely generated string, but that is not relevant here). I'm not sure about the API yet (see below). Let's cross that bridge later :-)

For example, I would like to detect or have the user hint on literal strings. In such cases, you don't even need a std::string. And there are many cases where you just want to pass string_view. The string is already stored somewhere else (e.g. some resources for internationalization e.g. a std::map)... Basically a lifetime management issue.

In other words, the source of the text/string should not matter for things like labels. And we need to give the client ways to hint at the source of the string which determines if it will be stored or not.