| Time |
Nick |
Message |
| 00:26 |
|
queria^clone joined #minetest-dev |
| 01:02 |
|
queria^clone joined #minetest-dev |
| 01:47 |
|
MTDiscord joined #minetest-dev |
| 02:04 |
|
v-rob joined #minetest-dev |
| 02:23 |
|
MTDiscord3 joined #minetest-dev |
| 03:22 |
|
MTDiscord4 joined #minetest-dev |
| 04:18 |
|
MTDiscord joined #minetest-dev |
| 05:12 |
|
v-rob joined #minetest-dev |
| 07:34 |
|
MTDiscord joined #minetest-dev |
| 07:55 |
|
calcul0n joined #minetest-dev |
| 07:56 |
|
calcul0n_ joined #minetest-dev |
| 08:00 |
|
specing_ joined #minetest-dev |
| 08:35 |
|
calcul0n__ joined #minetest-dev |
| 08:39 |
|
calcul0n joined #minetest-dev |
| 08:47 |
|
Alias joined #minetest-dev |
| 09:02 |
|
entuland joined #minetest-dev |
| 09:43 |
|
queria joined #minetest-dev |
| 09:53 |
|
calcul0n joined #minetest-dev |
| 10:08 |
|
queria^clone joined #minetest-dev |
| 10:11 |
|
queria^clone^clo joined #minetest-dev |
| 12:49 |
|
Fixer joined #minetest-dev |
| 15:44 |
Krock |
sfan5: since we're already trying to support any kind of Settings hierarchies, how about making it generic, so that any structure can be created? I find it weird that the Settings constructor makes a bottom-up call to register itself; how about dealing with the hierarchy management directly inside SettingsHierarchy? |
| 15:44 |
Krock |
example: https://krock-works.uk.to/u/patches/0001-Support-any-Settings-hierarchies-with-fallbacks.patch |
| 15:45 |
Krock |
it would avoid having to deal with parent management manually, instead the top-down iterating process is used everywhere |
| 15:46 |
Krock |
also offering the option to specify any entry point in any fallback hierarchy |
| 15:47 |
|
Extex joined #minetest-dev |
| 15:47 |
sfan5 |
I don't see the big difference |
| 15:48 |
sfan5 |
except that you ask the hierarchy to create a settings object and not the other way |
| 15:48 |
sfan5 |
what do you mean by "dealing with parent management manually"? |
| 15:49 |
Krock |
that getParent() is not necessary, hence defining a clear fallback order within SettingsHierarchy which does the parent evaluation on its own |
| 15:49 |
Krock |
this easily allows chained orders, without having to care about getParent() at all |
| 15:51 |
sfan5 |
sorry, I don't see the functional difference to `Settings *getSettingsParent(int layer);` |
| 15:52 |
sfan5 |
do you mean that making it a virtual function is not necessary? |
| 15:54 |
Krock |
right. the inherited class does not need to take of that at all. this->createLayer(...) kind of specifies the priorities already |
| 15:55 |
sfan5 |
that's true |
| 15:55 |
Krock |
whereas your approach requires specifying the layer index AND getParent(), whereas latter is basically useless since the information is already provided |
| 15:56 |
sfan5 |
I only did this because I knew MapSettingsManager could get away with one if statement to implement getParent() |
| 15:57 |
sfan5 |
but you're right, it makes no sense to do this when a generic implementation would work everywhere |
| 15:58 |
Krock |
tbh If I were to fix the issue, I'd just slap in a public SL_MAP_DEFAULTS layer and add in this code whenever a feature requires it. whatever. that's what we've got now. |
| 15:58 |
Krock |
trying to improve it to the point of "perfection" |
| 15:59 |
Krock |
caveats: "friend class" is required, and also inherited classes that make use of "onLayerCreate"/"onLayerRemove" must call the virtual base function for proper functionality |
| 16:01 |
Krock |
creating two different callback function names (1x for base class, 1x for inherited) would solve latter |
| 16:09 |
sfan5 |
I don't think we'd need an inherited class at all |
| 16:44 |
|
olliy joined #minetest-dev |
| 16:46 |
MTDiscord |
<Jonathon> should https://github.com/minetest/minetest/issues/7247 be closed as the PR to solve the issue has been merged? |
| 16:55 |
|
calcul0n_ joined #minetest-dev |
| 16:58 |
Krock |
closed. |
| 17:03 |
|
calcul0n joined #minetest-dev |
| 17:04 |
|
Lone_Wolf joined #minetest-dev |
| 18:28 |
|
kilbith joined #minetest-dev |
| 18:29 |
kilbith |
sfan5? https://github.com/minetest/minetest/pull/10788#issuecomment-863782390 |
| 18:29 |
kilbith |
wish you were mobilized on that as much as shadows |
| 18:42 |
sfan5 |
I'm aware that the PR is waiting on me |
| 18:43 |
|
calcul0n joined #minetest-dev |
| 19:05 |
|
Extex joined #minetest-dev |
| 19:37 |
|
MTDiscord joined #minetest-dev |
| 20:00 |
|
specing_ joined #minetest-dev |
| 20:41 |
|
T4im joined #minetest-dev |
| 20:47 |
|
v-rob joined #minetest-dev |
| 21:55 |
MTDiscord |
<exe_virus> +1 bump :) |
| 22:12 |
|
kilbith joined #minetest-dev |
| 22:15 |
|
kilbith_ joined #minetest-dev |
| 22:19 |
|
Pexin joined #minetest-dev |
| 22:30 |
|
kilbith joined #minetest-dev |
| 22:33 |
kilbith |
v-rob: thinking to scrollbaroptions[], I think it's best to make a dedicated PR to transfer some options from tableoptions and scrollbaroptions to style properties |
| 22:33 |
kilbith |
and mark {table,scrollbar}options as deprecated ofc |
| 22:34 |
v-rob |
Yeah, that might be a good idea |
| 22:36 |
kilbith |
tableoptions are all about styling so the full element can be deprecated |
| 22:36 |
v-rob |
And scrollbaroptions[] can be split between style[] and new scrollbar[] properties |
| 22:37 |
kilbith |
ok, I agree |
| 22:38 |
v-rob |
On the matter of smallstep and largestep: I was thinking that they should probably be style[] properties because they could theoretically be applied to any scrollbar, such as one on a textarea |
| 22:40 |
kilbith |
and btw we could add animated images to button under the form of bgimg=myimg.png:5:200 (provided that :<frame count>:<frame duration> are detected) |
| 22:42 |
kilbith |
ideally state like :hovered should trigger a modder-provided function of which the formspec could be reloaded |
| 22:43 |
kilbith |
I am clear enough? |
| 22:43 |
v-rob |
Yeah, that's what the key and mouse event PR is for |
| 22:43 |
v-rob |
Which isn't the nicest interface, but formspecs aren't very nice, unfortunately |
| 22:43 |
kilbith |
ah yes |
| 22:45 |
kilbith |
pretty sure it's possible to send server-side events from :hovered |
| 22:47 |
kilbith |
rubenwardy: are you motivated enough to review the input event PR? |
| 22:48 |
kilbith |
if it's not you I don't see who else |
| 22:49 |
v-rob |
Actually, there's still the issue needing to be addressed of how keycodes should be handled since the PR won't be merged with the Irrlicht key names. |
| 22:50 |
kilbith |
and why? we are still using Irrlicht and once we switch to SDL2, that's low maintainance |
| 22:51 |
v-rob |
Ideally because we don't want compatibility layers |
| 22:51 |
kilbith |
and there are no concrete plan to move to SDL2 yet, so no reason to delay a PR for an hypothetical plan |
| 22:54 |
kilbith |
I guess there'd be more incentive to merge it if the core-devs had to develop a modern GUI like i3 |
| 22:54 |
v-rob |
sfan5 suggests that backend-independent names should be used like `<Return>` |
| 22:54 |
v-rob |
Heh, probably true |
| 22:54 |
kilbith |
and obviously I'm the only one to push it because I'm the only one to make modern GUIs |
| 22:54 |
kilbith |
sad but true |
| 22:56 |
v-rob |
It's quite the undertaking using formspecs. In the past, I tried making a really fancy computer mod with even just basic windowing, but I couldn't do it with formspecs. |
| 22:56 |
v-rob |
(Hence some of my incentive for working on the GUI) |
| 22:57 |
v-rob |
Actually, make "some" "a lot" |
| 22:59 |
v-rob |
Anyhow, I guess backend-independent names are probably the best, although I wish Lua events could just be a wrapper around SDL2. |
| 23:01 |
kilbith |
why not simply bump formspec_version on key names change? |
| 23:02 |
kilbith |
wait, the Lua API wouldn't be affected anyway? |
| 23:03 |
kilbith |
ah no, it would |
| 23:04 |
v-rob |
Now, if we had SDL2, I would make an awesome events API for both formspecs and in game. |
| 23:05 |
v-rob |
But it doesn't look like that's going to be a reality anytime soon |
| 23:06 |
|
Alias joined #minetest-dev |
| 23:06 |
kilbith |
idk why are you exposing the same key names than Irrlicht to the Lua API |
| 23:07 |
kilbith |
which could be given generic names |
| 23:08 |
v-rob |
Because `keycode.h` did it that way |
| 23:08 |
v-rob |
It made sense before there was any discussion on migrating to SDL |
| 23:08 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:27 |
|
kilbith_ joined #minetest-dev |
| 23:36 |
|
Extex joined #minetest-dev |
| 23:44 |
|
calcul0n_ joined #minetest-dev |
