lua now has a widget userdata that can be used
to set/get widgets properties as one would
expect, a lot of the set/get_dialog_xy function
were converted into modifiable properties of
the widget userdata. This in particular allows
us to get rid of the strange 'path to widget'
type of arguments of gui2 functions.
It currently generates lot of compiler wanrings,
I will fix this in a later commit.
One of the main advantage is that it makes it
much easier to add new api, previously a lot
of functions where overused, probably because
that was just easier than creatign a new
function. For example set_dialog_value returned
multiple value of listbox objects. (the
compatibility path doesn't support this
particular feature yet but i don't think it is
important, it probably wasn't even used at all,
since it also wasn't documented).
This also adds some new features, like an 'add_item'
function to add an item to a listbox, a 'type'
property of widgets to query the type of a
widget and a 'item_count' property to count the
number of children in an item.
Im still not 100% sure about the
property /function names, in particular:
1) i might rename 'items' to 'elements' or
'children' in some functions. Not sure yet
2) I might rename the 'value' property to
'value_compat' to make clear that its only
supposed to be used by the
backwards_compat.lua code.
A next step in improving this api might be
to introduce a (reusable!) 'window' userdata
so that the implementaion of wesnoth.show_dialog
would become:
```
function wesnoth.show_dialog(wml, preshow, postshow)
local dialog = gui.create_dialog(wml)
preshow(dialog)
local res = dialog:show()
postshow(dialog)
return res
end
```
However this is currently not really possble
since the pure existance of a gui2::window
object blocks the gui1 code (the main game view)
from receiving events. So we clearly cannot luas
gc take ownership of gui2::window objects.
Made use of them where applicable. There are a whole bunch of cases where the dialog
object only exists to check its return value, but I'll update those separately.
Unlike other widgets where `this` is the event target, the tree nodes fire the event
with the tree widget itself as the target.
I had added a fire-event call in f97dc8ae12, but with
the target as the node. I don't think there was any way that would have worked...
changed.
When a dialog registered a new callback in the callback handler, the new
callback was called as a result of the same event that fired the original
handler.
The solution is to simply stop processing of the event after executing the
original handler.
commit 8000a868 added an invalidate layout() call to fix issues arisiong from widgets that change its site when their 'value' is changes.
But with this, some dialogs, in particular the custom help dialgog in the addon "world conquest 2", reacted much slower to user input because invalidate_layout() causes the dialogs to recaclulate all its siszes which is very slow. Since most of the widgets, in particular 'multi_page' don't change their size when the value is changed, this commit fixes the mentioned custom help dialog by not calling invalidate_layout() when cahnging the value of those widgets.
(cherry picked from commit 808bd59dae)
This was never finished, is not maintained, suffers from a lack of features the "old" listbox
class now has, and seems (according to the logs) to be have been superceded by the pane widget.
At the very least, the pane widget seems to be what mordante was working with in his early
prototype of a new addon manager, and not this 2010 list class.
(cherry-picked from commit 458dd284b8)
This also covers handling of legacy DescriptionWML for [set_menu_item],
and tweaks its handling in the other cases (mainly [multiplayer_side]).
I added the next_dev_version constant intending to use it, but then
decided not to do so; however I left it in in case someone finds it useful.
This mostly has to do with moving various components into more logical locations instead of
all mushed together in gui/widgets/settings.*pp. To that end, the following changes have been
made:
* The gui2::init function has been moved to its own file in the gui/ toplevel.
* load_settings() has been merged into init().
* All functions and code relating to gui theme definitions have been moved to their own file.
* All code relating to widgets or window static init have been moved to their own file.
* window::update_screen_size has been moved out of the window class and into settings.cpp.
* The unimplemented free-stadnding version of load_widget_definitions has been removed.
* gui_definition::read and gui_defintion::load have been merged into the gui_definition ctor
and greatly simplified.
* Some functions relating to builder_widgets have been renamed for clarity.
* add/remove_single_widget_defintion now access the current gui theme instead of the default.
This looks like it was a mistake made in the original code.
* Since the static registry is now externally linked, the unit tests accessor for window types
has been removed.
* Documentation has been updated. The wikidoc comment for gui_definition has been removed. It
was rather out-of-date and needed to be reworked anyway.
* widget_builder_func_t's signature is now to take a config reference and not a copy, though
REGISRER_WIDGET had already passed register_builder_widget a lambda that took a reference.
* Various other misc cleanups and improvements.
* Dropped unused CVideo class member references.
* Replaced the lone usecase of the CVideo member in loadgame with the singleton and removed said member.
* Removed CVideo references from a bunch of addon management functions.
* Cleaned up a *lot* of now-unnecessary forward CVideo declarations.
This a two part commit. First:
----------------------------------------------------------------------------------------------------
Added and deployed two new helper macros for the standard implementations of the static execute
and display functions. I also made use of a variadic template in order greatly simplify code
maintenance. Now, even if the dialog's ctor parameters change, no one has to worry about updating
the associated execute/display functions (though of course, this only applies if the helper macros
are used). \o/
I did not deploy the macro in cases where there were multiple overloads or the functions did more
than just show their dialogs. I might add an additional __VA_ARGS_ parameter to the macros later.
Do note for the end_credits dialog I moved the default empty-string parameter from the display
function to the ctor.
Second:
----------------------------------------------------------------------------------------------------
Another change is that modal_dialog::show and modeless_dialog::show no longer take CVideo arguments.
Since the video argument couldn't be included in the parameter pack (maintaining the argument would
have meant making it the first one, which would be just as much work), and using CVideo::get_singleton
in the macros would require adding video.hpp includes in a whole bunch of files, I simply removed the
argument. I had been intending to do this for a while anyway.
This therefor also removes the CVideo argument from:
* All dialog display/execute functions.
* modal_dialog::show
* modal_dialog::build_window
* modeless_dialog::show
* modeless_dialog::build_window
* wml_exception::show
* gui2::show_message
* gui2::show_error_message
* gui2::show_transient_message
* gui2::show_transient_error_message
* gui2::show_wml_message
* gui2::build
* gui2:🪟:window
* gui2::dialogs::tip::show
* Various GUI2-related Lua functions. The video_dispatch helper was also removed.
* Any functions that took a CVideo argument for the sole purpose of passing it to one of the above.
Ya know, all these damn CVideo arguments didn't actually do anything, besides an occasional check to
CVideo::faked. At the end of the pipeline, they just got assigned to the video_ member of gui2::window.
Huge code bloat for nothing.
This affects uses of both set_callback_item_change and set_callback_value_change.
Finally we get rid of most of the conditional GUI2_EXPERIMENTAL_LISTBOX handler setups. \o/
[ci skip]
- Support for multimenu buttons
- Support for selecting multiple items in listboxes and stacked widgets
GUI2 C++ API:
- Documentation fixups
- Function to test if a layer of a stacked_widget is selected
- Function to test if a row of a listbox is selected
- listbox::select_row now returns false if it failed to select/deselect anything
- Functions to count and select options of a multimenu_button
- multimenu_button now always has keep_open, so the function to set it is removed
- multimenu_button now assumes every option has a toggle
although stacked_widget supports similar functionality this is currently
not easily doable from the lua gui2 api. In particular
1) stacked_widget cannot add pages dynamically
2) multi_page can only contain one type of widget.
3) a stacked_widget inside a multi_page is ineffective since it
generates many unused widgets
4) a multi_page inside a stacked_widget is just unhandy to use
Any click on a row with a toggle button will now toggle that row's button prior to closing the dialog, unless the
keep_open flag was set, in which case the click will toggle the button but the dialog will not close.
Clicks directly on the toggle buttons themselves are unchanged.
Change all includes to start at the base instead of assuming the directory where included from.
This makes it more apparent exactly which header has been included, since many have the same name.
This also allows moving all header files out of the src directory.
