kazdragon / munin Goto Github PK

It's not a library until it's used.

A layout that aligns components according to compass points -> North, South, East, West, and Centre.

a layout that spreads components evenly across an NxM surface.

A Client would be the top level UI component that is responsible for

• The actual draw-to-client scenario (involving screens, windows, etc.)
• Non-component UI behaviour (e.g. screen buffers, title bars, etc.)

Should also include badges e.g. Coveralls.

Adapt cmake script to make it installable and detectable.

Implementation of the acceptance test has shown that the relationship between the Window and the canvas upon which it is drawn is too loose. In particular, whenever the size of the window is changed, the canvas size must also change, and also a redraw must be scheduled.

There is also the side-effect that the draw function has very weird parameters. If canvas were instead a member, then many of these details would go away.

However, canvas cannot currently be a reference member, and thus cannot be injected for tests: resizing a canvas requires an assignment to a completely new canvas. Creating a new canvas function to resize it would solve this problem.

A component that composes a scroll frame with a viewport to another central component.

A component that displays only the given image (e.g. like Brush, but not repeating)

A draw operation is not an event, and should be logically const (even if some caching operations are happening behind the scenes).

Brush should redraw itself entirely whenever the pattern is changed.

Like Horizontal Strip Layout, but ... vertical.

For example, one cannot do:

munin::make_image(content, 'X');

It may be that a component can be enabled or disabled, but what that means is unique to the component (e.g. a button may not be clicked, a text field can be clicked but not edited, etc.)

Therefore, this should not be a generic property of component. It should instead be down to the concrete types, and only manipulable from the owners of the component.

A single-lined text field.

This would allow better debugging. For example, if the tree contained "{button: position:{x,y}, size:{w,h}, text:{"OK"}}, then this would allow a test application to determine where precisely a button was located on the screen and what it contained.

And possibly to click it.

Including autogeneration on codedocs.xyz.

A component that displays a subsection of the underlying component.

Paradice provided a helper function called view that allowed easier composition of layouts. E.g.

auto container = view(
make_compass_layout(),
left_ui_component, compass_layout::heading::west,
right_ui_component,
compass_layout::heading::east);

At the moment, Compass Layout expects only one component in each direction. This is how it worked in Paradice. It could be improved such that if there are multiple components in a direction, those components are "stacked", similarly to the current workaround that is, e.g. creating a compass layout with a component on the south, and the adding a container to the middle that uses a compass layout on the south, and so on.

A component that takes a pattern and repeats it across its surface.

A layout that aligns layouts to be top/centre/bottom, left/centre/right.

e.g. contributing, code of conduct, licence, etc.

Split into src and include directories for better inclusions of common utilities e.g. mocks.

A type of frame that has scroll bars.

A multi-line text field.

The piece that brings the whole together and makes everything work is the Window abstraction. Cleaning this up should involve:

• Removing dependency on ASIO. Instead, the provided context should supply the functions needed.
• Making sure all tests cases are covered, including interactions with the terminal, and repaint algorithms.

This should have been done as I went along, but apparently I need to remind myself.

A composite component is an intermediary class that allow a component to use another component (e.g. a container) as the basis for its design.

At the moment, Window just blindly paints out each requested redraw area. However, it could coalesce these repaint requests as Paradice did so that elements are not redrawn over and over again.

A layout in which the preferred size is a fixed value and components are placed and sized manually.