Skip to content

do not draw cell when border Side content is empty#76

Open
jaypipes wants to merge 1 commit intocharmbracelet:mainfrom
jaypipes:jaypipes/empty-border
Open

do not draw cell when border Side content is empty#76
jaypipes wants to merge 1 commit intocharmbracelet:mainfrom
jaypipes:jaypipes/empty-border

Conversation

@jaypipes
Copy link

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.

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>
@jaypipes
Copy link
Author

jaypipes commented Feb 4, 2026

ping @aymanbagabas any thoughts on this?

@aymanbagabas
Copy link
Member

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 🙂

@jaypipes
Copy link
Author

jaypipes commented Feb 5, 2026

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 replace directive in my go.mod file and that wouldn't be good for a public repo on github...

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.

@aymanbagabas
Copy link
Member

@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 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.

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.

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 🙂

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 replace directive in my go.mod file and that wouldn't be good for a public repo on github...

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.

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.

That's the goal of Ultraviolet, focus on the low-level terminal primitives, allowing building more friendlier libraries and frameworks on top.

@jaypipes
Copy link
Author

jaypipes commented Feb 5, 2026

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 🙂

LOL :) Here you go.. just made it public...

https://github.com/jaypipes/gt/

@jaypipes
Copy link
Author

jaypipes commented Feb 5, 2026

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.

LOL :) That's what I had made. Even called it Box.

I created a separate interface called Node that handles the generic DOM tree-management things and created an Element interface (and element.Element concrete struct) that builds on top of Box and Node and adds the "handler" stuff...

@jaypipes
Copy link
Author

jaypipes commented Feb 5, 2026

@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.

@aymanbagabas
Copy link
Member

@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 uv/dom or something. I would love to see UV being integrated in UI frameworks like Fyne and other Go based ones.

@jaypipes
Copy link
Author

jaypipes commented Feb 5, 2026

@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 uv/dom or something. I would love to see UV being integrated in UI frameworks like Fyne and other Go based ones.

rock on. which Slack community?

@aymanbagabas
Copy link
Member

rock on. which Slack community?

https://charm.land/slack/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants