cschreib / lxgui Goto Github PK

SDL is a fairly standard and widely supported rendering/input backend. Adding an SDL backend to lxgui would increase the number of projects that could use the library.

Differences with SFML:

• SDL is written in C, so I will likely have to write more boilerplate to get it all working, unless I use something like https://github.com/libSDL2pp/libSDL2pp? But then it has to be inter-operable with pure SDL, in case users use their C API or another C++ wrapper.
• SDL has support for WebAssembly / emscripten, which is really good for demos and getting people engaged.

Layered regions should not be allowed to be root, so let's enforce this with the type system. Remove the public function add_root_uiobject() and merge this functionality into create_frame() (the overload that takes > 1 parameter) to be renamed create_root_frame().

Currently the font rendered by SFML or SDL looks different and of slightly different size than that rendered by the OpenGL backend. This leads to inconsistencies in the GUI appearance depending on which backend is used.

This saves a bunch of dynamic casts all around. This holds for get_parent() and get_renderer().

• standard comments of the form <!-- ... --> are not recognized
• non-standard form <-- ... --> does not always work correctly?
• non-standard "smart" comment <!node> </node>, keep this?

Now that we no longer support C++03, we can get rid of the conditional support for "new" C++ features, such as nullptr, default template parameters, etc.

Now that the library no longer supports C++03, we should be able to get rid of the foreach macro and use language range-based for loop whenever we can.

utils::refptr -> std::shared_ptr
utils::wptr (probably unused?) -> std::weak_ptr

unique_ptr ideally

See uiobject::update_dimensions_().

This would :

• allow setting more than one callback for a given on... handler
• better manage callback lifetimes
• maybe be faster than std::function

However:

• need to use a library for that, either from https://github.com/cschreib/cobalt or some other source

Now that we no longer support C++03, we can mark as many classes as possible as "movable" to improve performance. Also not forgetting noexcept.

In such cases, the child has an implicit dependency on its parent, which uiobject::depends_on must account for

This is probably because of the use of mouse/keyboard state rather than events... Could mean refactoring the whole input class.

Most of the time currently they are caught by non-const ref.

Sometimes, ScrollFrame rendered by SFML display garbage data, as if the internal texture size was not set correctly. This can be seen immediately when the test executable is run, by looking at the left panel of the file explorer.

This creates fewer chances for circular dependencies

If a class is being destroyed, dynamic_cast() can return a null pointer if the derived class destructor has already been called. This can cause issues when the result of dynamic_cast is used to determine the type of the object being processed (i.e., to remove it from a special list).

In November 2020, Travis CI stopped providing free CI services to open source projects. lxgui burned through the free credit in an instant, and it is no longer possible to get builds from Travis CI unless I move to a paid plan. At $70 a month, that's not going to happen.

A replacement CI service must be found. GitHub actions are probably the best. Acceptance criteria:

• Must: able to build lxgui on both linux and windows
• Must: able to build and publish the documentation
• Should: MacOS support
• Should: able to publish build outputs (and ideally connect to github releases)
• Could: able to run static analysis (clang-tidy)
• Could: able to run tests

Currently, the Lua API of lxgui is undocumented. It follows closely the original WoW API, but:

• The WoW API has far more functions that lxgui does not (related to locking the interface to prevent cheating, or custom WoW-specific widgets, etc.)
• The WoW API isn't always super well documented (there are several websites and the quality varies)
• There are a number of differences between the functions in common between the two APIs

Acceptance criteria:

• The Lua API should be integrated in the Doxygen output if possible. This can use lua2dox. Not possible.
• The Lua API should have its own separate section so it doesn't end up mixing up with the C++ API
• The Lua API documentation is in the glue source next to the function, if at all possible.
• There are a few examples of documented functions, to specify how the documentation should be written (what level of detail, conventions, etc.).

Once this is done, getting the API fully documented can be a background task.

Currently gui::sprite could be derived in one of the renderer implementations. This has not proved necessary, so the feature should be removed for better performance.

• OnDragStop is removed
• OnReceiveDrag is implemented
• OnDragStart only triggers if the mouse is in the frame
• OnReceiveDrag only triggers if the mouse is in the frame

edit_box::move_carret_vertically_() and edit_box::get_letter_id_at_() are not implemented for multiline edit box.

For performance and memory footprint

For performance and simplicity

Errors coming from sol use default format. We can set our own format when calling the Lua script.

This is un-necessary.

Places where this can be avoided:

• add a get_parent() method to Lua glues that returns the right type already instead of uiobject*
• make uiobject parent a frame (#33)
• copy_from() : the inheritance code already checks using is_object_type(), so can use static_cast
• ...

• ConcTable
• SendString
• EmptyString

Some content of manager::remove_uiobject() require knowing if the object is a frame. This content should be put in a separate function remove_frame() which is called in the frame destructor.

Currently the library has 5 different namespaces with very generic names (input, utils, etc.). This will not play nice with other code bases using lxgui, so we should wrap all namespaces into a common namespace, such as lxgui.

Currently, the test project is buried deep in the folder hierarchy and relies on being part of the CMake build of the library. This is not practical for people who just want to explore the test to see what the library looks like. It is also not practical for people willing to integrate lxgui into their project, since it doesn't show how to use the FindLXGUI script etc.

sol is much easier to use for the end user. We should at least make this the main user-facing interface with Lua now, and slowly deprecate/replace luapp internally after v2.0.

gui::manager::get_lua() should return the sol wrapper, and internal usage of this should switch to sol
gui::uiobject::push_on_lua() also

Make conversion to c++17 easier later.

Given that the GUI and Input can now be provided by SFML, it should be possible to add a wrapper around gui::manager to initialize it with a full SFML implementation, which would make it easier on the user.