do not draw cell when border Side content is empty#76
do not draw cell when border Side content is empty#76jaypipes wants to merge 1 commit intocharmbracelet:mainfrom
Conversation
Updates the drawing of Borders to simply skip over border cells when the Content of the Side is empty. This allows layout of a component to proceed as expected. The difference between an empty Content and a space Content (as is the case for the HiddenBorder) is that the HiddenBorder's border cells can be styled, for instance with a background color, whereas empty border cells will not overwrite any existing cell content in the bounding box supplied to the Draw method. Signed-off-by: Jay Pipes <jaypipes@gmail.com>
|
ping @aymanbagabas any thoughts on this? |
Thank you @jaypipes for working on this. As of the Border component, it is set to be removed in favor for other components. With that being said, if you have any thoughts on how new components should look like, let's start a discussion and talk about it 🙂 |
@aymanbagabas where shall I start the discussion? In an issue? Do you have an issue somewhere with your thoughts on how you are evolving this library? I've been building tooling on top of the primitives in this library and am not aware of how you want to change the library's design. It would be helpful to understand what your thoughts are on that. I've been building out a library of what I've called "elements", which are simpler Drawables that understand how to plot themselves on a screen and their location relative to a tree of other elements (similar to the document object model in HTML/CSS). Elements have a border, a padding, various min, scroll, fixed and relative widths (just like an HTML element). Elements have a display mode (identical to CSS display property), an alignment mode (identical to CSS text-align and vertical-align property), whitespace mode (similar to CSS whitespace and wrap properties). Elements also have hooks for various events like focus, mouse click, etc. Examples of elements are Div, Span, HR, Pre, TextArea, etc that match the defaults and behaviour of same-named HTML elements. The library I've been building has a concept of a "component", which is a higher-level structure that builds a set of related elements. Examples of components are things like TabGroup, which manages the display and construction of a set of tabbed pages, Modal, which manages a dialog-box kind of thing, etc. I've kept my library private because, well, I've been using a private branch of ultraviolet because things have been changing so much in ultraviolet I needed to do a I was hoping that ultraviolet really would be focusing on the lowest level of terminal UI primitives: the terminal handling itself and the screen and input device I/O and event loop. I envisioned other libraries (such as the one I've been writing) building on top of ultraviolet to create more developer-friendly ways of producing TUI apps in Go. |
I just enabled GitHub discussions so we can talk about design patterns and everything Ultraviolet in details. With regard to the border API, I was planning to replace it with a broader concept and basic Box type that handles borders, margins, and computing the inner area. But again, if Ultraviolet is focusing on the primitives, maybe there is no need for such types.
Dude, I've been playing with something very similar! Although, I didn't like the first take on it, so I moved it to the side for now. Would love to see what you've built 🙂
Yes, to be honest, we still haven't released a version of Ultraviolet because the API keeps changing. The low-level stuff like the renderer and the input handler are almost stable, but the other screen related drawing API might change.
That's the goal of Ultraviolet, focus on the low-level terminal primitives, allowing building more friendlier libraries and frameworks on top. |
LOL :) Here you go.. just made it public... |
LOL :) That's what I had made. Even called it Box. I created a separate interface called |
|
@aymanbagabas I'm very much interested in collaborating with you and having a deeper discussion about the evolution of ultraviolet and this library I've been building -- maybe combining them? I've kep my library private and tried to keep up with the changes going on in ultraviolet because I didn't want to interfere with anything here. But I'm also quite happy and willing to contribute things to this library if you feel this is the right place for certain contributions. |
Let's chat about this on Discord or Slack. This is definitely the right place for low-level terminal primitives. For now, I would keep the two libraries separate, but maybe in the future we port some basic form of markup language of some sort to |
rock on. which Slack community? |
|
Updates the drawing of Borders to simply skip over border cells when the Content of the Side is empty. This allows layout of a component to proceed as expected. The difference between an empty Content and a space Content (as is the case for the HiddenBorder) is that the HiddenBorder's border cells can be styled, for instance with a background color, whereas empty border cells will not overwrite any existing cell content in the bounding box supplied to the Draw method.