Time Nick Message 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 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:46 MTDiscord should https://github.com/minetest/minetest/issues/7247 be closed as the PR to solve the issue has been merged? 16:58 Krock closed. 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 21:55 MTDiscord +1 bump :) 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 :: 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 `` 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 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