Time Nick Message 02:39 MTDiscord celeron55, Zughy: It was a lot in a PR, but not too much overall. It also offered code that would be very handy for mobile users later on. I could remove the desktop part, but I don't see the need in creating another PR, even if nobody really wanted to review it. 02:41 MTDiscord I dont really understand why the incentive was to close it and sweep it under the rug instead of negotiating a bit further. I understand there are priorities but this kind of thing is stuff that corporations do when they step into open source but want to deflate their issue list. 02:42 MTDiscord actually thats not a good example but my point may have slipped through the lines; I wish someone negotiated a bit more, or even just.. reviewed it? 02:43 MTDiscord Not to mention: 2.3 UI Improvements. While it doesn't fall directly under the roadmap word for word, it does improve the UI in some ways, more so on mobile. 02:45 MTDiscord Better elastic scrolling though, overall, could be useful for those on mobile. If we can allow (somewhat broken) smooth scrolling to come in; why did mine get stopped at the door? 02:55 MTDiscord All in all, If you're gonna have a roadmap that blocks little things like this that much, then you're gonna have a pretty narrow road full of traffic jams and little things swept under the rug. At the same time, I do acknowledge priorities to a degree, but this feels abrasively enforced in my situation... 04:24 MTDiscord I pretend to be an expert at road traffic in Transport Fever 2, he's absolutely correct 07:56 celeron55 @cscscscscscscscscscscscscscscscs (yes, this is how the name looks like on IRC... silly) "sweep it under the rug" is the wrong impression. it's more about following the process to keep everything moving for everyone. doing too much negotiating is really bad for pretty much everyone involved. don't get too attached to your PRs, they're just a tool. so stop complaining and split it 07:59 celeron55 and don't try to "escalate" from Zughy. Zughy is your best friend when comparing to anyone else from the team :D 08:00 celeron55 for the record, i think this is your PR. it wasn't mentioned (no link or number) and your nick differs so it's unclear https://github.com/minetest/minetest/pull/15221 08:01 MTDiscord thats it 08:04 MTDiscord But you see, there's a bit of a problem, it's not as simple as just "moving the code out" because my new code depends on the new logic entirely a bit. Sure, I can try to rewrite that little piece, but right now I don't feel all too motivated to really work on this anymore. 08:06 MTDiscord the roadmap is there, I get it, but I still feel like it's just being used oddly here. There are plenty of PRs that don't fall under the roadmap at all, like say, the touchscreen one right above, which honestly probably falls near mine a little bit too. It just happens to garner more attention. 08:07 celeron55 what is the hardest part of a collaborative volunteer project like this one? 08:08 celeron55 it's not optimization. not UX. not marketability. not whether the end result is fun or not 08:08 celeron55 it's code review 08:08 celeron55 all code has to be designed for code review first, and everything else second 08:08 celeron55 to make it easier 08:10 MTDiscord And when nobody actually reviews a darn thing and just closes my pr? No "possible close" tag or even a mention of other ideas? Why are you shocked that I escalated it to IRC? 08:10 sfan5 i thought it was going to be "prioritizing which things to do / not do, or in which order" 08:11 celeron55 sfan5: well, that kind of is a prerequisite to doing anything at all, but yeah maybe 08:12 MTDiscord If its not marketability, then why did the name change occur? If its not optimization, well... damn, sorry bud, i know that. If its not UX then.... ???? What is the point you are really making here? I get code review is important but your point would've been nice if someone actually reviewed my code... 08:13 celeron55 @cscscscscscscscscscscscscscscscs yes it's not a mystery me why you're escalating it. it's just that aside from doing you a personal favor outside of the actual process that's supposed to be the same for everyone, i can't help you in any acute way 08:13 celeron55 to me* 08:14 celeron55 if you want to see a better process, you can come back next year and hope we managed to improve it 08:15 celeron55 i'd say every year it's been a bit better 08:17 celeron55 @cscscscscscscscscscscscscscscscs in any case, you'll probably need to present the PR as a bugfix, in one way or another. maybe it could be considered one as-is. i can't say i'm a scrolling expert 08:18 MTDiscord I was just typing about that really; I don't think what I did was even near considered a "feature", more so a rather minor improvement, which just so happened to also fix a little bug anyway. 08:18 MTDiscord I appreciate you being respectful at least, I apologize if I seem a little angered, it's a rough week.. er, month for me. But that doesn't matter. Sorry if I seem a bit off the rails about this. 08:21 celeron55 we separate bugfixes from features very strongly and they get completely different handling. in order for something to be a bugfix, you need to be able to define what's working wrong currently, and then propose a minimal change to make it work properly. this is very different compared to a feature, which can be absolutely anything 08:23 celeron55 sometimes some rework is acceptable in a bugfix. it depends 08:26 MTDiscord So, if we aren't considering features at all... how would I even handle this? of course i can fix the first little bug but the smooth scrolling code would still be pretty meh. But what about android users too? This PR, while I did design it to make scrolling feedback look "pleasant" on desktops, can honestly feel very natural for android users. 08:27 MTDiscord This is entirely why I would've liked if there was some actual feedback put in before deciding to just close my PR, then hopefully allowing me to discuss further on snail mail instead of here. If it was just done in bulk then that's fair, but.... well.. thats.. not actually a good way to handle stuff like that. I get PR's are a tool as you've stated, but tools deserve to be used right at the minimum. With what 08:27 MTDiscord was done, my PR was marked as low priority by completely hammering me in the head. 08:28 MTDiscord I'll see what I can do, but I really am stumped on how I could roll the elastic code out... at the very least, for android users... 08:33 celeron55 well, unfortunately PRs (and issues) are partially a popularity contest, and this is out of necessity, because there's only so much attention available 08:34 celeron55 if some code is necessary to make it work correctly, then of course it's necessary. this will of course depend on how you define "correct". i wish you the best luck :D 08:34 celeron55 if you're targeting touchscreens with the fixes, you probably want to make sure the desktop experience doesn't change. people absolutely hate mobile stuff leaking onto desktop 08:36 celeron55 anyway, i can assure you anything labeled as a bugfix will get many times the attention from reviewers that any feature is able to get 08:39 MTDiscord Sure but that honestly makes me feel evil besides the first PR 08:40 MTDiscord and in all honesty, you are kind of admitting that working on the engine is a strange disaster and that the current system really isnt the best, but i will assume (its almost 4am) it probably isnt even truly in your hands, though not sure 08:41 MTDiscord If i feel the motivation to do this again, I think ill scrap the elasticity and at the very least make scrolling on trackpads actually good (not a bugfix, but... should garner attention i hope) 08:43 celeron55 i have R&D in software and hardware both as my hobby and profession, and i can say every project has its "strange disaster" parts 08:44 MTDiscord elasticity can come later, maybe, but to be fair that is the bulk of the PR and im oddly attached to the code since it is only 40 lines of despair, trail and error, and blood from my eyes, that got put on display like a school fair only to receive the fattest F a judge could even scrawl 08:47 MTDiscord Right celeron, i kind of should be used to this. ive dealt with abysmally shitty projects and its kind of sad how many open source projects do not have great entry points, even if they are run by stressed out maintainers. But thats off track and i need to sleep. Thanks for talking with me 08:47 celeron55 good night! 08:49 celeron55 (i used to be the stressed out maintainer, but then i decided my own wellbeing is more important and became the "this is fine" maintainer instead 08:49 celeron55 ) 09:05 MTDiscord celeron55: before i truly sleep, i can tell you things ive learned on maintainers and, more importantly, from much wiser maintainers 09:06 MTDiscord Be friendly. Be welcoming. And honest to god, do not rush! Even if its your 1000th time talking to some new contributor, you have to treat them like gold, even if they are a pain, more so, treat them like a customer actually, meaning, be respectful if they are rude. 09:08 Desour we should imo indeed try to apply some strategies to attract new contributors 09:08 MTDiscord And rushing... it might be a problem luanti may have considering how semi-frequently it feels we are getting versions. Versions, release candidates... all fine stuff, but this may actually harm more than it helps if done too fast. It can also help keep a project alive by setting goals, however, if you cut too short in release gaps, you may create pretty miserable maintainers 09:09 Desour maybe give each new contributor one PR that is reviewed, even if quite bad/semi-good or uninteresting. 09:11 MTDiscord Desour: the nicest dev i ever met ended up completely reiterating through the rules on his code guidelines, gave proper feedback with good reiteration, without ever pointing me to some file or stating the obvious. He was a pretty old guy, but a wise guy all the more. This is what good and friendly maintainers do. They treat their contributors like extremely special customers. Nothing is more demotivating than 09:11 MTDiscord getting told to check the docs or "figure it out" and treating them like trash when they are in fact dedicating an extremely valuable amount of their time, even just to fix a little typo or one line bugfix. Everything matters 09:12 celeron55 well, i do agree (you can probably tell), but i don't think i'm going to force that onto the team 09:13 MTDiscord That may sound like im stating the obvious, and mood 100% comes into play, but treating contributors like ants or pests barging in with ideas outside of your own, is not only how you scare contributors, but even users. 09:13 MTDiscord Oh certainly, in fact im getting offtopic here so please dont take this as me enforcing some magic hand of mine on how this project i wrote small prs should work. 09:14 celeron55 it's still just a process, out of necessity, that people unfortunately have to put themselves into 09:14 celeron55 there's nothing that would make it somethign else 09:14 celeron55 something* 09:15 celeron55 it's nothing more, nothing less 09:16 celeron55 as for getting along with people in general... well, i'm assuming some others are reading this discussion and might learn something from it 09:16 MTDiscord like i said ive seen worse projects, but ive also seen the worst come to them as well. It is something people should be wary of. How you act, how you manage, and all that, completely represents a project too, sometimes reaching out to the users themselves, if you aren't careful. It is a difficult goal and good communication is by far the hardest part of computer programming entirely. 11:54 MTDiscord For the record, your PR didn't receive an "F"; a better comparison would be an overworked teacher failing to grade the assignment at all (and communicating that)... 11:55 MTDiscord FWIW your PR was something I had on my radar, but it simply wasn't up high enough on my priority list for me to take a proper look (yet). 11:57 MTDiscord I try to be welcoming to newcomers, but ultimately it is an unsolvable problem if the resources simply aren't available. Some corners need to be cut, some time needs to be saved. 11:58 MTDiscord If I tried to give everyone, or even just more people than I can handle, proper feedback, what happens is that I stretch thin; the quality and form of my feedback diminishes. 11:59 sfan5 yeah. no amount of policies can fix there being not enough time to respond to everything that shows up in the PR and issue queue 12:00 sfan5 reading stuff is easy and you often have an idea in mind what the response should be. but putting it into words takes time, or you end up with "no" or "this won't work" responses 12:02 sfan5 there's also a paradox with contributions where sometimes working with the submitter to get the idea into a mergeable shape is many times more work than doing it yourself 12:07 MTDiscord I wonder: What if we could get contributors to help each other? At least for first looks and testing, contributors should to a reasonable extent be able to do that too. Once the contributions have then become a bit more polished, core devs would have an easier job. 12:10 [MatrxMT] I don't think it's gonna work in practice 12:11 [MatrxMT] Cutting corners and admitting our human limits sound like a healthier approach. Contributors are already warned about the roadmap when they open a PR. If they decide to go through, that's on them 12:12 [MatrxMT] I clearly remember swagtoy opening another PR and answering "idc" to the roadmap question. If they don't care, why should we? 12:16 [MatrxMT] We should probably make the roadmap more evident though. It doesn't seem we have any contributing guidelines in the readme (I can't find them), so people might end up working on something just to toss into the bin once they try to open a PR 12:16 [MatrxMT] The first time, that is 12:16 MTDiscord Zughy: They do care, at least about the elastic scrolling PR. 12:17 [MatrxMT] That's not how mutual respect works :P 12:17 MTDiscord merging #15444, #15402, #15204, #15415 in 10m 12:17 ShadowBot https://github.com/minetest/minetest/issues/15444 -- Add particle blend mode "clip" (2nd try) by appgurueu 12:17 ShadowBot https://github.com/minetest/minetest/issues/15402 -- Fix rendering regression with TGA type 1 files with BGRA8 color by appgurueu 12:17 ShadowBot https://github.com/minetest/minetest/issues/15204 -- Fixed naming conventions for CMatrix4::setRotationRadians() and setInverseRotationRadians() by PichiBeta 12:17 ShadowBot https://github.com/minetest/minetest/issues/15415 -- Support LuaVoxelManip in core.spawn_tree by cx384 12:19 MTDiscord We should probably update the roadmap, it's 3 years old at this point? 12:19 Desour linking CONTRIBUTION.md in the readme would indeed be good. wanna make a PR Zughy? 12:21 [MatrxMT] luatic: we had a survey a year ago and point didn't change. Theoretically we shouldn't touch it for another year 12:21 [MatrxMT] Desour: I see what I can do in the evening :) 12:35 MTDiscord Well I give it an F for, fantastic 12:37 sfan5 @luatic please wait with 15415 12:38 MTDiscord sfan5: ok 12:39 MTDiscord ah right, i see you have self-requested a review. sorry. 12:42 sfan5 you can merge 15453 tho 12:48 MTDiscord hmm i haven't tested that yet, so i think i'll refrain for now 12:49 sfan5 it will be fine 12:53 [MatrxMT] someone should do a screenshot that bloom looks the same before/after before merging 12:54 [MatrxMT] *screenshot comparison to confirm that 12:55 MTDiscord frankly the first thing i'm asking myself is: why isn't the color clamped earlier? bloom is just fetching from the rendered image, why do we let that go out of the [0, 1] range? 13:20 sfan5 we should change all the particles in MTG to clip 13:24 sfan5 @luatic I think we forgot something. what happens with blend mode clip but alpha < 1? 13:25 sfan5 it will go into the solid render pass 13:34 MTDiscord I'd be excited to see Luanti encouraging more contribution, but as luatic shows, it seems the whole core dev team already isn't able to keep up with the contribution we have. Any PR that takes a very long time to review because there aren't enough resources to do so wastes both the resources of the contributor and the reviewer. Why not make some kind of compromise? Apportion important tasks to willing contributors to get them done so 13:34 MTDiscord the reviewers don't bear such a heavy load, and then review some of their own PRs in exchange. 13:36 MTDiscord When someone gives a contribution, it's because they want to support a project. So tell them how they can support it. If they're spending their time generating work that isn't very helpful to the project as a whole, then they're not contributing. 13:38 Desour or they want to have some kind of feature themselves 13:38 Desour and nobody would do it for them 13:40 MTDiscord Then maybe what they're doing isn't a contribution. 13:40 MTDiscord Do you want more contributors, or more PRs? 13:41 MTDiscord Frequently people do want to see certain features, and likely other people will enjoy those features, too, but if all they do is put up PRs for their own feature they want, then the problem will get worse, not better. 13:42 Desour I want people to be able to get stuff they want into the engine, if they can provide a proper implementation 13:43 Desour otherwise we're a closed garden, where nobody but we can decide what changes happen 13:44 Desour s/decide/influence/ 13:44 Desour and luanti should be community driven, not coredev driven 13:46 MTDiscord That's nice to want, but how can that be possible? I am an Apache Committer and I've interned two summers at a well known company writing C++ code for a caching web proxy. I have the skill to implement features for Luanti, but as the years go on my desire to do so wanes more and more. Even the tiny cleanup PRs that I normally make at work in-between waiting for other reviews take weeks or even months to get merged. Extrapolating, it 13:46 MTDiscord would take years per feature I implement. It would waste my time. It's not even worth it for me to attempt any kind of large contribution. 13:47 MTDiscord Though I will say, glTF was super encouraging, and that was pulled off by getting multiple people on the development group to help speed up review and get it prioritized. 13:47 MTDiscord Even that took a very long time, though. 13:49 [MatrxMT] I just want to point out that we're back to ~80 PRs, so I don't we're poorly managing the PR traffic 13:49 [MatrxMT] *I don't think 13:50 MTDiscord What would be the "motivation" of a reviewer? What's in for them? IMO the job is simply not appealing, same as QA and documentation unfortunately. If we somehow make those appealing, then people will take them. 13:50 [MatrxMT] If we reach the 7 digit, I might be moved 13:51 MTDiscord I will give a piece of actionable feedback... not having an automatic code formatter is a very annoying inefficiency for contributors. 13:52 MTDiscord I don't want to waste a long review cycle just finding out that some detail of my code style isn't acceptable thank you very much. I need to know that my code style will be accepted without putting in tons of effort, and it also takes that burden off the reviewer. 13:52 MTDiscord Saving both parties' time is way more important than having that one line break in exactly the right place that everybody likes. As long as its consistent it's ok if there's an ugly formatting here and there. 13:55 MTDiscord Zughy if you want to have a problem with number of PRs again, I can singelhandedly do it, I just need to wait for winter break and then I can do multiple PRs a day if I spend 6 hours a day on it. 13:59 [MatrxMT] I'd really prefer if you reviewed existing PRs instead :P 14:00 [MatrxMT] (But not a core dev) 14:00 [MatrxMT] e.g. the UI API PR 14:36 MTDiscord How much of someone else's time do you think I'd save my reviewing that PR? 14:40 MTDiscord Are there guidelines for doing reviews that are in line with the core dev's priorities? A core dev still has to approve it in the end. 14:41 MTDiscord Is this #14263 we're talking about? 14:41 ShadowBot https://github.com/minetest/minetest/issues/14263 -- [NO SQUASH] Create new UI API (Formspec/HUD replacement) by v-rob 14:44 MTDiscord If he splits c26a26d into its own PR I can review that. School comes first, though, so it could take a few weeks. 14:48 MTDiscord He has unit tests for those functions. Do you realize how awesome that is? xD 15:34 [MatrxMT] Overstepped my role here josiah_wi, my bad 16:33 MTDiscord So apparently calling the graphics backend a driver is incorrect 16:34 MTDiscord yeah right, it's not gonna drive me anywhere 16:54 MTDiscord sfan5: "what happens with blend mode clip but alpha < 1? it will go into the solid render pass" - i don't understand the problem with this 16:54 MTDiscord the material type and type param are set properly such that it should be clipping. the solid render pass is intended for alpha in {0, 1}, we just discard fragments where alpha is clipped to 0. 16:59 MTDiscord just tested real quick, works as expected 17:04 MTDiscord @luatic Thats kinda also what i was expressing, i get you guys have plenty of other things to do as well. 17:05 MTDiscord Its just a little unrelated to what actually happened here. 17:05 MTDiscord > What if we could get contributors to help each other? I have tried to pitch in on some issues when I see them. I actually do find it fun when im bored and am looking for something to do. However, Idon't think what i've suggested was overall helpful. 17:07 MTDiscord Zughy, I do care, and honestly I think i actually apologized about the "idc" thing. It was like 5am when i finished that PR i think, so I was kind of just joking around to keep my sanity. But it came out rudely. I shouldn't have done that and I understand what you are getting on about 17:08 MTDiscord Whcih also led me to ask why we have to prompt the PR open-er to actually say "yes" or something about that question. It seems somewhat unneccesary and goes back to how I think that our contribution guidelines are somewhat overwhelming. At the same time there isnt good better ways to do it that come to my mind. 17:09 MTDiscord A "You are encouraged to read the roadmap" markdown comment would be preferred instead of nagging someone trying to finally rush their PR out the door because they just wrote all their code and might only now see the roadmap thing and feel a bit discouraged. 17:20 MTDiscord Except, honestly, when you word stuff like this, you are treating PRs like cars on a highway or statistics for marketing. In a corporation this might be more acceptable, but for a FOSS project, you are treating them like a nuisance worth ridding of (and you aren't wrong), which i dont personally think is the best way to put it. 17:20 MTDiscord Im not going to judge any longer, I think I am annoying people more than I'd like to, but I did want to express opinions and you are welcome to discard them to the shredder 17:21 MTDiscord I think minetest had a guy who was 10x worse about this stuff so who am i to lay down the meta here 18:24 SFENCE_arch sfan5: Here is some summary of problems I found with SDL and OpenGL ES 2 -> https://github.com/minetest/minetest/issues/15457 18:46 Krock @luatic : Yes. I'll re-review. 18:47 Krock sfan5: that's interesting. I didn't know it would apply deltas to master. That's strange but also more efficient, I guess. 19:02 sfan5 @luatic I thought it would clip the texture alpha and then apply the transparency 19:02 sfan5 but that doesn't actually make sense 20:49 celeron55 poll: without looking, guess the length of two things: 1) the current formspec documentation, 2) v-rob's experimental new ui api documentation 20:49 celeron55 length in lines 20:50 Krock 1 is probably 1500 lines. the new API doc should be rather brief (didn't document all the things modders have yet come up). I guess 500 lines. 20:51 celeron55 i'll wait 2 more answers before spoiling it 20:52 MTDiscord 1: 1200 lines 2: 800 lines 20:53 Krock holy smokes 20:53 sfan5 2000 and 5000 20:57 MTDiscord What is it now? We want to know! 21:00 celeron55 i counted them as: 1) 1056, 2) 1790 21:01 celeron55 i was surprised by the length of both, not sure which one more 21:01 Krock I found the same numbers and was equally surprised. 21:01 celeron55 i decided to count these, because i started reading v-rob's docs, every line from the start, but at some point i was like "ok, how long is this going to take?" 21:02 Krock five hours later 21:02 celeron55 after that i was like "ok wtf, how long is the formspec doc" 21:02 celeron55 turns out, UIs are very complicated 21:03 celeron55 ... but not as complicated as sfan5 thinks 21:04 celeron55 he got the ratio the right way around, though 21:05 v-rob I've been adding more code samples yesterday and today. It's now at 2001 lines 21:05 v-rob Sorry but not sorry? 21:06 v-rob I believe in good documentation 21:06 Krock I suppose it's good to have UI documentation in a separate file at least. 21:06 celeron55 v-rob's doc is relatively fleshed out, but lots of basic things are still to be done and not documented 21:06 celeron55 i'm not really implying anything here. just being a statistician 21:07 v-rob Still, tons of the documentation is about the fundamentals of the UI. When we add new elements, they'll only get a single relatively small section. 21:07 v-rob Per element, that is 21:07 v-rob I don't want bloated docs, but I never want people to have to guess at how something works. 21:08 Krock it would be very convenient if we could somehow rely on established concepts, such as flexboxes from HTML / CSS 21:09 Krock "For documentation: see w3cschools" (in that sense) 21:10 Krock I quickly browsed through the documentation, and it's very detailed. Nice ASCII visualizations too. 21:10 v-rob Now, for some more statistics: guess the number of lines of code in the UI API PR without including documentation, and guess the number of lines in guiFormSpecMenu.cpp alone. 21:10 celeron55 i think about 2000 lines is about the length of the Programming In Lua book 21:11 celeron55 for comparison 21:11 v-rob Oof. Word wrapped? 21:11 celeron55 well i'm just trying to produce a ballpark figure 21:13 celeron55 maybe yours is more like half of that 21:13 celeron55 i won't even tell the numbers i'm trying to base this on because i basically pulled them out of my rear 21:14 v-rob Anyhow, for the previous statistic: the UI API is 5657 lines (including all the builtin Lua code, not just the C++), guiFormSpecMenu.cpp is 5070 lines. If you add all the Irrlicht GUI code to the second number, I think the UI API is smelling pretty good in terms of code complexity. 21:15 v-rob I'm really looking forward to the day that we have a formspec compatibility layer for the UI API, and I can rip all that disgusting code out. 21:16 celeron55 well, these comparisons are fun, but i'll have to sleep over them to come up with any conclusions. however, it's interesting the amount of documentation per line of code varies by a large factor like that 21:16 celeron55 given that both documentations are considered to be complete, in one way or another 21:17 v-rob I would argue that one is more complete than the other, but I'm at least somewhat biased :) 21:24 celeron55 completeness is important, but here's something i look for: how long do you have to read before you get to trying out stuff 21:26 celeron55 if you look at the PIL book, you notice that there's a preface with chapters like "audience", "about the book" and whatever (multiple pages), but then, once the "real thing" begins, the second line is print("Hello World") 21:26 celeron55 https://www.lua.org/pil/contents.html 21:26 v-rob Well, I added an introductory code sample at line 40 yesterday, so I guess that's better (?) 21:27 celeron55 i think it would be good if somewhere after the introduction chapters in your doc, there would be a minimal fully structured example 21:27 celeron55 yeah that sounds good. like something that can be run and when run, it shows up an ui 21:28 v-rob Yeah, it's definitely a problem that the current version only has two examples of a fully formed program, all the way down in the middle of the documentation. 21:30 [MatrxMT] perhaps it would be good to split the doc up? I understand you want to have everything documented and specified so that people don't have to guess, but most people won't need that amount of information most of the time. 21:31 [MatrxMT] Lua has PIL and the reference manual: one thing that you can read if you want to get something done, another one if you need a specification to figure out some detail. 21:32 v-rob Well, let' 21:33 v-rob Why does apostrophe need to be so close to the enter key? 21:33 [MatrxMT] But ofc that's additional work as well 21:34 v-rob Anyhow, the first half of the docs is all detailed exposition on the concepts found in the UI API. The second half is reference information about all the elements. You don't need to read the second half at all until you need to use a specific element, in which case you can look it up. 21:35 v-rob The first half is probably more detailed than a lot of people may want it to be. 21:37 [MatrxMT] Ok, but I wouldn't have to read the first half if I could just get some examples with short explanations, also allowing me to understand the concepts 21:37 v-rob Perhaps I'll pass the buck and say that this is like the Lua Reference Manual, and the easy explanations should be left to rubenwardy's modding book or similar >:D 21:38 [MatrxMT] I also still have some API design feedback to give, ideally I would have given it already, but I haven't yet invested the time to get my thoughts into an understandable shape... 21:39 v-rob No worries, I've got time. There's still a few small changes still have to complete before I mark the PR as ready for review again. 21:40 v-rob I guarantee it will be no later than this weekend 21:41 [MatrxMT] Unfortunately part of it is also reiteration of previous feedback you may have already considered done 21:41 [MatrxMT] Yeah, I see you have time, it's been 3 months since my review :P 21:42 v-rob Is it regarding bg vs. fg images? 21:46 v-rob Re. the docs: I think it's best to make the official documentation as detailed as possible, but since that's not the best method for everyone, I'll make a separate text that gives much simpler explanations and examples (since I understand everything the best). Perhaps I can contribute it to the modding book or similar at some point. 21:48 [MatrxMT] yeah, haven't looked on a technical level again and wanted to avoid technical discussion right now for that reason, but I guess I've already spoilered too much 21:50 grorp I see you've separated it into box_image and icon_image iiuc, but I think that only makes more obvious what's wrong: the API is now use case specific instead of simply having a general API to show images 21:51 grorp with a goal of the new UI API being to be more flexible and less quirky, that doesn't make sense imo, since having two separate image APIs for different use cases seems like the opposite of that 21:52 v-rob (For reference, here's an updated image of the box model if you haven't already seen it: https://github.com/minetest/minetest/blob/ad92136fa4a0fbdd8b41113a8df0ecdda001b0c7/doc/experimental_ui_api.md?plain=1#L855-L875) 21:56 grorp Suppose I want a background image working like object-fit: cover. That's what I'd assume you'd want for e.g. a fullscreen menu background. You wouldn't want stretching or tiling or no-stretch-filling there. 21:57 grorp box_image and icon_image each have a hardcoded "CSS object-fit value" (can't think of a better way to say this). How would the API design extend to that case? Do you just introduce another image type? 22:03 v-rob I made the distinction between them because I do think images are separated into use-cases. Box images are entirely thematic, since they distinguish one element from another, what with 9-slice borders around buttons, tiled backgrounds on webpages, animated elements, and so forth. I can't think of a single case where you'd want these to be anything but stretched or tiled (9-slice or otherwise). On the other hand, icon images are primarily content, just 22:03 v-rob like text, which is why `icon_place` exists to choose where the image appears in relation to the other contents of the element. It's more like the `` tag than the CSS `background-image` property. It's rare to want content images to be stretched, which is why I never introduced any sort of property for choosing how to fit the icon image. I can't think of any case in which you'd want a content image to be tiled or 9-sliced. That's the rationale 22:03 v-rob behind the decisions I made. 22:04 v-rob What they are emphatically not is two entirely generic images layered on top of each other. The fact that `icon_place` exists in the box model is a testament to that. On a Cancel button in Gnome, there is the button background, the button text, and an X image next to the text. The X is the icon image and the background is the box image. Neither should be substituted for the other. 22:07 v-rob I think there may be merit to having a object-fit property for the icon image, so you can have stretched/covered images without having to resort to hacks like using the box_image property where you shouldn't. But I don't think the box image needs an object-fit property because there's simply no need given what it's meant to display. 22:09 v-rob As for a fullscreen menu background: that seems like a good place for a centered icon image, since it's displaying content rather than thematic styling of an element, so that counts in favor of object-fit for icon images. 22:09 v-rob I'll stop talking now :) 22:12 v-rob (I'm second-guessing myself as to whether GNOME uses an X image or not. I don't use GNOME, but I _think_ it does. Still, I suppose you get the idea) 22:13 grorp the problem I see is that you're designing the API for two specific use cases, not for giving modders the possibility to do whatever they want with it 22:15 grorp and it's not the API of like, the button element, where I would understand having a specific API to easily show an icon next to the label, but the API of the generic UI element 22:19 grorp ok, good night anyway :) 22:21 grorp probably I should also comment on the PR again on the other stuff... 22:22 grorp and gnome cancel buttons don't have icons :) 22:26 v-rob I suppose my main point is that I wouldn't have added two separate types of images if I didn't think that both had a purpose. I can't think of any case where you'd layer two images on top of each other unless one was content (like an arrow on a scrollbar button or dropdown) and the other was theme. However, content images come up often enough that I think extra style properties for them have merit. If anyone can think of a case where you'd need icon 22:26 v-rob image properties on a box image or vice-versa, I'd be glad to reconsider. But I don't want to needlessly add style properties that serve no purpose. 22:27 v-rob Ultimately, I want to resist needless bloat, which is what I think would happen if box and icon images are equated. 23:29 [MatrxMT] huh, we have no contributing file at all 23:31 [MatrxMT] I'll start working on one tomorrow, I've been pretty busy today 23:38 MTDiscord That doesn't sound right, I think there is one 23:38 MTDiscord Can't check atm though 23:39 [MatrxMT] oh silly me, github folter 23:39 [MatrxMT] *folder