Design of widgets

[certik]

The discussion started in #239 (comment). We can continue here.

[certik]

#239 (comment):

I like Turbo Vision visual style, imitating a graphical GUI. From the programming perspective, having a Widget base class which can contain children and following a Qt like approach is the most familiar one to me. I did some half-baked approach on my program so far, but it would need to be more sophisticated. Should we create a new thread to talk about how to engage this development?

@iganinja, I like the Turbo Vision style as well. Married with unicode it can look really nice.

I am also familiar with the imperative Qt style. So why don't we start with that? We can always build a "react" functional style on top of this imperative style as another optional layer.

[certik]

@flagarde we'll probably don't want to commit the font into this git repository, so I assume we provide the tooling for end applications (that use cpp-terminal) to easily download & ship it with the application. And then they can figure out the licensing situation and we don't have to worry about it.

[flagarde]

@certik Yes exactly, I was thinking to add a CMake option to download the font and put it in the right folder. So it would'nt be on the cpp-terminal repo and so it would be the programmer responsbility to install it or not. I think this way we are safe and we stay away from GPL-2.0+ right ?

[flagarde]

But I want to offer this opportunity especially for debugging. To use same font in Unix/Windows would be beneficial for tests I think

[certik]

@flagarde I think that should work. My understanding of GPL2 is that as long as your dependency on it is optional, that is cpp-terminal builds and works just fine without it, then we don't have any obligations: they only apply if the end user turns the optional dependency on. Yes, having some kind of a "canonical" font that we test that works on all platforms is good, we should do it.

[flagarde]

@certik Perfect so we just add an option with a #Please check licensing and that's it 👍🏻

[flagarde]

@certik With Hebrew

[certik]

The font looks good! But we have a bug in the renderer --- the word is flipped horizontally, compare it with the text I sent above. Otherwise it looks good.

I can't read Arabic, but it might be similar, and also it might not be connected correctly, just comparing it against the source code visually.

[flagarde]

@certik bidi is maybe not done in terminal by default, We maybe have to do this by hand. Ligatures etc can't be performed in the standard console cmd.exe I think (Windows negelect consoles until very recently). Maybe with the new one is better ?

[iganinja]

By the way, do we have FTXUI on our list? It's another C++ terminal library, although in some fast tests I was not able to make it run properly in Windows.

[certik]

Yes, we had it in the README, but it got removed. Let's put it back in: #272

[iganinja]

So, I come up with this Widget class, very heavily inspired in Qt's one:

class Widget
{
public:
  Widget(Widget* parent = nullptr);
  virtual ~Widget() = default;

  virtual Widget* add_child(std::unique_ptr<Widget>&& child);
  virtual std::unique_ptr<Widget> remove_child(Widget* child);

  virtual Position position() const;
  virtual void set_position(Position position);

  virtual Size size() const;
  virtual void resize(Size available_size);

  virtual void draw(Window& target);

  virtual bool is_visible() const;
  virtual void set_visible(bool visible);
  virtual void show();
  virtual void hide();
  
  enum class InputProcessing
  {
    Processed,
    Skipped
  };
  
  virtual InputProcessing proces_input(Key key);
  
  bool has_focus() const;
  void set_focus(bool focus);

private:
  Widget* m_parent{nullptr};
  bool m_is_visible{true};
  std::vector<std::unique_ptr<Widget>> m_children;
  bool m_has_focus{false};
};

Each Widget owns N children. You can add or remove them at any time. We have position and size getters and setters. resize() is somewhat a hit. For example, if we have a Menu, you can call its resize() with (10, 20) size, but Menu after that call with return (10, 1) size, as Menu will always have height of 1.

draw() of course draws the widget. I'm thinking we will need to rework Window in order to allow not visible characters, currently it throws an exception if you try to draw outside its bounds. This way widget handling will be much easier, developing my editor I saw it's very easy to draw where I should not. Anyway I'm also thinking we need to clip somehow the widgets, as if we want to implement a ScrollView we would need it. Perhaps passing a Rect to draw()? There is also the option to pass a class like ClippingWindow instead of Window, and this ClippingWindow be configured with a rect which indicates where drawing operations are allowed.

Finally, I'm not really sure how to implement the focus thing. If, for example, we have a form with several line inputs (name, surname, etc), we would want to put the blinking caret in the first one, then press tab and set the focus to the next one. How can we implement that? What would be the correct way to unfocus one widget and focus another one?

Well, let me know what do you think about it, please. Thanks!

[iganinja]

Hi guys.

I'm doing a little bit of work on that. Can we create a branch, something like widgets_poc so I can upload my stuff to there?

[flagarde]

You can't create one?

[flagarde]

@iganinja I have created a branch for your work