muesli4/libwtk-sdl2

Simplistic SDL2 GUI framework in early developement.

libwtk-sdl2's Issues

List entry won't draw most entries with sdl-2.0.10

The list entry widget doesn't draw some of the text to display. It seems like it only draws the first list entry and even that one is strangely limited.

This may be related to how basic rendering works and how SDL_RenderSetViewport and SDL_RenderSetClipRect are used. See:

libwtk-sdl2/src/draw_context.cpp

Line 112 in f7bd729

void draw_context::draw_entry_text(std::string text, rect abs_rect, int texture_x_offset, int texture_y_offset)

Add new event to reset widgets

In some cases in event handling widgets have to be reset to their initial state (i.e. only state related to user input).

Implement an interface for drawing GUI elements

In its current state the library implements one hard-coded theme in https://github.com/muesli4/libwtk-sdl2/blob/master/src/draw_context.cpp. This should be replaced with a more modular approach. Perhaps the class can be split into:

• Drawing primitives: Rendering primitives that are specific to a platform and library which would make porting fairly easy.
• Theme engine: An interface for theme engines that use the drawing primitives.

Duplicate touch and mouse events are not filtered

A newer version of SDL2 has the annoying behavior of producing additional mouse button events for touch devices. This leads to issues on some widgets (e.g., swipe_area gets triggered twice even though it was hit once).

Ensure text_button does not draw over boundaries

text_button should not draw outside of its box. Provide a mechanism to ellipsize or scroll.

Add cmake based build script?

Autotools will require the users to install a full posix shell like cygwin or msys2.

Add license to project

Add a license to the project and the files.

Add and propagate events for scrolling

• Add scrolling events.
• Find a clever way to propagate scrolling events to widgets. Picking the active widget may not be good enough. For example, one could first try to propagate it to the active widget, if it is supported by it, and otherwise try some hierarchy-based heuristic (bottom-up from active widget, top-down from root widget to visible widgets).