This reverts commit 51d6402453db08d3add2cdb571abbf1d60272142.
After discussion with @gfgtdf it was determined that this is not a useful feature after all, since it was in fact the default behaviour for the optimized path.
This means that they are now added to the interface module by default in C++, and only duplicated to the Wesnoth module in Lua.
Some additional functions were moved:
- wesnoth.scroll -> wesnoth.interface.scroll
- wesnoth.zoom -> wesnoth.interface.zoom
- wesnoth.get_mouseover_tile -> wesnoth.interface.get_hovered_hex
- wesnoth.color_adjust -> wesnoth.interface.color_adjust
- wesnoth.set_menu_item -> wesnoth.interface.set_menu_item
- wesnoth.clear_menu_item -> wesnoth.interface.clear_menu_item
Added wesnoth.units.get_hovered as an alias of wesnoth.interface.get_displayed_unit
Also backtracked the removal of wesnoth.get_recall_units, which is now available as wesnoth.units.find_on_recall - it's just more convenient than passing x=recall to wesnoth.units.find
This means that they are now added to the units module by default in C++, and only duplicated to the Wesnoth module in Lua.
Some additional functions were moved:
- wesnoth.create_unit -> wesnoth.units.create
- wesnoth.get_units -> wesnoth.units.find
- wesnoth.get_unit -> wesnoth.units.get
Deprecated wesnoth.get_recall_units in favour of wesnoth.get_units, which has gained the ability to match units on the recall list if x="recall" or y="recall" appears in the filter at toplevel.
The wesnoth.units module now acts like a metatable for unit userdata, meaning that any functions (or attributes) added to the module will be visible through any unit.
Of note:
* The image now created by Dockerfile-base-mingw is available on wesnoth's Docker Hub.
* Strict building is disabled, as there are a couple warnings that show up when crosscompiling.
The python2 trackplacer included both the handling of the file format, and the
GUI application. This trackplacer3 is a library for the file format, without
the GUI.
The new tmx_trackplacer is a command-line tool for exporting the data to
Tiled's .tmx format, and re-importing it back to .cfg files, so that the GUI of
Tiled can be used to avoid reimplementing the GUI of Trackplacer in Python 3.
The implementation uses Tiled's Object Layers (not Tile Layers). This allows
additional journey markers to be added with the "Insert Tile" tool, and
additional journeys to be added as new layers.
It can also read in a .cfg and then re-export it to a new .cfg file, to see if
the data is preserved. The format is chosen by the output filename.
The old trackplacer2 isn't removed in this commit - before removing it, I think
trackplacer3 needs some way to preview the animation.
----- Comments on the mainline campaigns: -----
AToTB, DM, LoW, NR and THoT will work with this. But:
Northern Rebirth's bigmap.cfg has a track RECOVERY whose STAGE1 starts with
an OLD_REST - that isn't handled by trackplacer, it must have been hand-edited.
That OLD_REST will be lost when read by either trackplacer2 or trackplacer3,
similarly the OLD_BATTLE of LoW's SAURIANS track will be lost.
Delfador's Memoirs SEARCH_STAGE1 is omitted from all subsequent parts of
SEARCH. Also in DM, SEARCH_STAGE3 has a point which is then moved in STAGE4
onwards - I guess a hand edit. Both of this will be overwritten if the file
is edited with either this tool or with the python2 trackplacer.
SotA's journey_chapter*.cfg files and WoV's bigmap.cfg file have some of the
trackplacer comments removed, they won't be handled by this tool, at least not
until better error handling is added.
This cursor is active when the widget has the mouse focus. You know,
like textboxes are wont to do anywhere else. Took long enough, although
there was an interaction issue with tooltips fixed in the previous
commit.
I still need to figure out how to make this work with GUI1 textboxes
(e.g. in-game console).
The colour version of the cursor was kindly provided by LordBob, and the
B&W version is my own.
Currently it's the gui2::window class' responsibility, by inheriting
from cursor::setter (yes) and offering absolutely no way to control it.
Unfortunately, it turns out that this can cause issues with tooltips
resetting the cursor at unexpected times when they get
displayed/hidden while having widgets change the cursor depending on
whether they have the mouse focus or not.
Right now the only modeless dialog we have is the tooltip dialog, and
really there's no reason to say that modeless dialogs should have the
ability to reset the cursor without explicitly asking for it. As for
modal dialogs... I don't entirely agree that they should do it either,
but for tradition's sake, let's just keep the current behaviour with
them.
(In an ideal world the cursor business would be managed by the window
managaer IMO, but I'm not ready to argue my case.)
