| Time |
Nick |
Message |
| 00:29 |
|
SFENCE joined #minetest-dev |
| 01:57 |
|
SFENCE joined #minetest-dev |
| 02:08 |
|
v-rob joined #minetest-dev |
| 02:16 |
|
SFENCE joined #minetest-dev |
| 02:39 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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... |
| 03:01 |
|
SFENCE_arch joined #minetest-dev |
| 03:39 |
|
citrons joined #minetest-dev |
| 03:47 |
|
v-rob joined #minetest-dev |
| 03:48 |
|
SFENCE joined #minetest-dev |
| 03:48 |
|
v-rob joined #minetest-dev |
| 03:59 |
|
SFENCE joined #minetest-dev |
| 04:24 |
MTDiscord |
<jordan4ibanez> I pretend to be an expert at road traffic in Transport Fever 2, he's absolutely correct |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:33 |
|
v-rob joined #minetest-dev |
| 05:46 |
|
SFENCE joined #minetest-dev |
| 06:16 |
|
SFENCE joined #minetest-dev |
| 07:01 |
|
v-rob joined #minetest-dev |
| 07:21 |
|
SFENCE_arch joined #minetest-dev |
| 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 |
<cscscscscscscscscscscscscscscscs> thats it |
| 08:03 |
|
SFENCE joined #minetest-dev |
| 08:04 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> Sure but that honestly makes me feel evil besides the first PR |
| 08:40 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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:45 |
|
whosit joined #minetest-dev |
| 08:46 |
|
Desour joined #minetest-dev |
| 08:47 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> celeron55: before i truly sleep, i can tell you things ive learned on maintainers and, more importantly, from much wiser maintainers |
| 09:06 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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] |
<Zughy> I don't think it's gonna work in practice |
| 12:11 |
[MatrxMT] |
<Zughy> 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] |
<Zughy> 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] |
<Zughy> 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] |
<Zughy> The first time, that is |
| 12:16 |
MTDiscord |
<luatic> Zughy: They do care, at least about the elastic scrolling PR. |
| 12:17 |
[MatrxMT] |
<Zughy> That's not how mutual respect works :P |
| 12:17 |
MTDiscord |
<luatic> 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 |
<luatic> 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] |
<Zughy> 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] |
<Zughy> Desour: I see what I can do in the evening :) |
| 12:29 |
|
Noisytoot joined #minetest-dev |
| 12:35 |
MTDiscord |
<jordan4ibanez> Well I give it an F for, fantastic |
| 12:37 |
sfan5 |
@luatic please wait with 15415 |
| 12:38 |
MTDiscord |
<luatic> sfan5: ok |
| 12:39 |
MTDiscord |
<luatic> ah right, i see you have self-requested a review. sorry. |
| 12:42 |
sfan5 |
you can merge 15453 tho |
| 12:48 |
|
hwpplayer1 joined #minetest-dev |
| 12:48 |
MTDiscord |
<luatic> 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] |
<grorp> someone should do a screenshot that bloom looks the same before/after before merging |
| 12:54 |
[MatrxMT] |
<grorp> *screenshot comparison to confirm that |
| 12:55 |
MTDiscord |
<luatic> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> Then maybe what they're doing isn't a contribution. |
| 13:40 |
MTDiscord |
<josiah_wi> Do you want more contributors, or more PRs? |
| 13:41 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> Even that took a very long time, though. |
| 13:49 |
[MatrxMT] |
<Zughy> 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] |
<Zughy> *I don't think |
| 13:50 |
MTDiscord |
<bastrabun> 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] |
<Zughy> If we reach the 7 digit, I might be moved |
| 13:51 |
MTDiscord |
<josiah_wi> I will give a piece of actionable feedback... not having an automatic code formatter is a very annoying inefficiency for contributors. |
| 13:52 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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] |
<Zughy> I'd really prefer if you reviewed existing PRs instead :P |
| 14:00 |
[MatrxMT] |
<Zughy> (But not a core dev) |
| 14:00 |
[MatrxMT] |
<Zughy> e.g. the UI API PR |
| 14:36 |
MTDiscord |
<josiah_wi> How much of someone else's time do you think I'd save my reviewing that PR? |
| 14:38 |
|
SFENCE_arch joined #minetest-dev |
| 14:40 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> He has unit tests for those functions. Do you realize how awesome that is? xD |
| 15:29 |
|
SFENCE joined #minetest-dev |
| 15:34 |
[MatrxMT] |
<Zughy> Overstepped my role here josiah_wi, my bad |
| 15:57 |
|
loggingbot_ joined #minetest-dev |
| 15:57 |
|
Topic for #minetest-dev is now Luanti (fka Minetest) core development and maintenance. Chit chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 16:08 |
|
v-rob joined #minetest-dev |
| 16:33 |
MTDiscord |
<jordan4ibanez> So apparently calling the graphics backend a driver is incorrect |
| 16:34 |
MTDiscord |
<rollerozxa> yeah right, it's not gonna drive me anywhere |
| 16:41 |
|
cx384 joined #minetest-dev |
| 16:54 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> just tested real quick, works as expected |
| 17:00 |
|
v-rob joined #minetest-dev |
| 17:04 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> @luatic Thats kinda also what i was expressing, i get you guys have plenty of other things to do as well. |
| 17:05 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> Its just a little unrelated to what actually happened here. |
| 17:05 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> > 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> 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 |
<cscscscscscscscscscscscscscscscs> I think minetest had a guy who was 10x worse about this stuff so who am i to lay down the meta here |
| 17:24 |
|
v-rob joined #minetest-dev |
| 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 |
| 19:11 |
|
wsor4035 joined #minetest-dev |
| 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 |
|
v-rob joined #minetest-dev |
| 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 |
<siliconsniffer> 1: 1200 lines 2: 800 lines |
| 20:53 |
Krock |
holy smokes |
| 20:53 |
sfan5 |
2000 and 5000 |
| 20:57 |
MTDiscord |
<siliconsniffer> 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 |
|
mtworker joined #minetest-dev |
| 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:05 |
|
mtworker left #minetest-dev |
| 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 |
|
cranez joined #minetest-dev |
| 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 |
|
cranez joined #minetest-dev |
| 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] |
<grorp> 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] |
<grorp> 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 |
|
vampirefrog joined #minetest-dev |
| 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] |
<grorp> 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] |
<grorp> 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] |
<grorp> 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] |
<grorp> Unfortunately part of it is also reiteration of previous feedback you may have already considered done |
| 21:41 |
[MatrxMT] |
<grorp> 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 |
|
grorp joined #minetest-dev |
| 21:48 |
[MatrxMT] |
<grorp> 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 `<img>` 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] |
<Zughy> huh, we have no contributing file at all |
| 23:31 |
[MatrxMT] |
<Zughy> I'll start working on one tomorrow, I've been pretty busy today |
| 23:33 |
|
v-rob joined #minetest-dev |
| 23:33 |
|
panwolfram joined #minetest-dev |
| 23:38 |
MTDiscord |
<greenxenith> That doesn't sound right, I think there is one |
| 23:38 |
MTDiscord |
<greenxenith> Can't check atm though |
| 23:39 |
[MatrxMT] |
<Zughy> oh silly me, github folter |
| 23:39 |
[MatrxMT] |
<Zughy> *folder |
| 23:40 |
|
Sharpman joined #minetest-dev |
| 23:46 |
|
Sharpman joined #minetest-dev |
