| Time |
Nick |
Message |
| 00:00 |
VanessaE |
(my screens' gamma is calibrated) |
| 00:00 |
VanessaE |
also that's a good reference shot for relative sizes and positioning in Unified Inv |
| 00:01 |
Zefram_Fysh |
the issue isn't screen gamma but file gamma, in the PNG. your screenshot displays at different brghtnesses for me with different viewers, as do mine |
| 00:01 |
|
hmmmmmm joined #minetest-dev |
| 00:01 |
VanessaE |
oh ok, no worries. off topic. something you can look at later since you now have a reference image. |
| 00:03 |
Zefram_Fysh |
I can arrange for my screenshots to be packaged like that one, sure. yours has no gAMA chunk, whereas mine do. I think the fix is for me to apply the gamma by modifying the image data |
| 00:04 |
sapier |
hmm way more clean then I expected indeed ... |
| 00:04 |
Zefram_Fysh |
thanks |
| 00:04 |
sapier |
a couple of additional black magic values added ... |
| 00:04 |
sapier |
lets see how code's gonna behave |
| 00:06 |
|
hmmmmm joined #minetest-dev |
| 00:07 |
Zefram_Fysh |
I had a go at explaining the magic numbers in comments. we can't really avoid having magic numbers, because they're mostly describing the proportions that the engine has used until now, which we can't make any less magic |
| 00:11 |
Zefram_Fysh |
fwiw, I think cleaner ways to specify form element positions (which we certainly do want) are better tackled by lua code that takes a structured form specification and renders it to a formspec string. the formspec string would have all the current nastiness, just hidden by the library |
| 00:12 |
Zefram_Fysh |
I've got the beginnings of such a library on my unified_inventory dev branch |
| 00:12 |
VanessaE |
like fstk |
| 00:13 |
Zefram_Fysh |
ah, I didn't know that existed. yes, exactly that kind of library |
| 00:14 |
sapier |
nice work zephram now please reenable scaling factor and fix the scrollbars too |
| 00:15 |
Zefram_Fysh |
what is gui_scaling meant to do that I broke? I don't really understand its intent |
| 00:16 |
sapier |
it's supposed to scale the gui |
| 00:16 |
Zefram_Fysh |
and what's wrong with scrollbars? |
| 00:16 |
sapier |
they scale according to dpi while you disabled this for fixed size menu thus scrollbars in tables get really huge on high dpi |
| 00:17 |
sapier |
you'll have to change the table gui element to let it know not to scale the bar by dpi |
| 00:17 |
sapier |
it's our own so this can be done |
| 00:18 |
Zefram_Fysh |
OK, I'm going to have to experiment a bit to see the proper behaviour around dpi and gui_scaling. thanks for the pointers |
| 00:18 |
sapier |
and gui scaling is supposed to scale the whole gui independent of any other setting |
| 00:18 |
sapier |
so fixed guis are scaled too |
| 00:18 |
Zefram_Fysh |
OK |
| 00:20 |
sapier |
and please don't add another derived irrlicht class we just got rid of one which became a major showstopper due to irrlicht changing api |
| 00:22 |
sapier |
btw did you realize fonts getting bigger on using scaling factor sometimes reverting back to small later? It's not a major issue but I wonder where it's from |
| 00:24 |
Zefram_Fysh |
show me your solution to the tab-control problem, I can incorporate that in place of the shim class |
| 00:25 |
Zefram_Fysh |
what do you mean by "reverting back to small later"? which text exactly is at a surprising size? |
| 00:27 |
sapier |
https://github.com/sapier/minetest/tree/formspec_pos_cleanup |
| 00:28 |
sapier |
it's quite similar to yours except that I'm using fact that a disabled irrlicht tabcontrol just ignores events |
| 00:28 |
sapier |
so I can handle them manually in formspec menu |
| 00:29 |
sapier |
Zefram_Fysh: all of it |
| 00:29 |
Zefram_Fysh |
oh, that's neat enough |
| 00:29 |
|
^v joined #minetest-dev |
| 00:29 |
sapier |
if I click the scrollbar for gui scaling at some positions the fonts suddenly get one level bigger |
| 00:29 |
|
ImQ009 joined #minetest-dev |
| 00:29 |
sapier |
clicking it again reverts to old size |
| 00:30 |
Zefram_Fysh |
ah, I see, I can reproduce it. think I know what the cause is (basically a rounding problem). will fix |
| 00:31 |
sapier |
I'd have preferred to cleanup the formspec mess but in order to get at least scaling fonts I'd accept your variant ... if you get the gui scaling and dpi things work again |
| 00:31 |
Zefram_Fysh |
you said fixed-size forms are meant to be scaled. so when you use that scrollbar, should the entire menu form be getting larger? |
| 00:31 |
sapier |
yes |
| 00:31 |
Zefram_Fysh |
OK |
| 00:32 |
sapier |
it's been originally added for some android devices where menu was just to small to hit the buttons |
| 00:34 |
sapier |
can you explain: pos.Y += (stof(v_pos[1]) + 17.0/60.0) * (float)spacing.Y; |
| 00:35 |
Zefram_Fysh |
that's the change in how label positioning is computed. hang on, will take a while to explain... |
| 00:36 |
sapier |
come on you spread magic numbers everywhere and sell try to sell it as good? ... no matter I don't even wanna know ... may others get crazy on maintaining this |
| 00:37 |
Zefram_Fysh |
the old way was that pos.Y was padding + specified-position.Y * spacing.Y, then the top edge of the rectangle was at pos.Y + imgsize.Y/2 - m_btn_height. so the top edge of the text was at padding + specified-position.Y * spacing.Y + imgsize.Y/2 - m_btn_height |
| 00:39 |
Zefram_Fysh |
in the new version, pos.Y represents the height at which the first line of text is to be centred. the 17/60 is the nominal size of imgsize.Y/2 - m_btn_height + text-height/2, expressed in inventory slot height |
| 00:40 |
Zefram_Fysh |
by doing that part of the computation at the floating-point stage, rounding that would cause misalignment is avoided. the label can be reliably aligned with a button's text |
| 00:40 |
sapier |
well let it be the positioning is useless anyway in current formspec |
| 00:45 |
sapier |
hmm buttons are slightly to small ... guess whole font is a little bit smaller |
| 00:47 |
Zefram_Fysh |
the menus get a slightly smaller font with my patch. that's tweakable. the current size arises from keeping the fixed-size scaling as similar as I could |
| 00:48 |
sapier |
well the buttons get significant smaller while menu is still same size that's not good |
| 00:48 |
Zefram_Fysh |
trying current master, frobbing the "GUI scale factor" scrollbar doesn't affect the size of the menu containing it at all. are you sure it's meant to? would that be an intentional change? |
| 00:48 |
sapier |
especially as it breaks vanessaE's "space to control" ratio ... which started all that discussion |
| 00:49 |
Zefram_Fysh |
OK, will tweak |
| 00:49 |
sapier |
gui scale factor works on restart only in current master ... and yes it's broken there |
| 00:50 |
sapier |
that's been one of those issues I targeted to fix |
| 00:50 |
Zefram_Fysh |
ah, I see |
| 00:56 |
Zefram_Fysh |
right, your font_engine branch shows some live size changing from that scrollbar. but it scales only font size, not the whole GUI |
| 00:57 |
sapier |
yes because the font_engine is really the font part only |
| 00:57 |
Zefram_Fysh |
right |
| 00:57 |
sapier |
the gui_scaling fix is in those formspec fixes |
| 00:58 |
sapier |
because I didn't find a way to fix all of those issues at once without breaking any formspec ... if you manage to do great |
| 00:58 |
|
paramat left #minetest-dev |
| 01:10 |
VanessaE |
sapier: "space to control" ? |
| 01:10 |
sapier |
too much empty room in between buttons (your saying) |
| 01:11 |
VanessaE |
right. |
| 01:11 |
VanessaE |
too much empty space between groups, too |
| 01:11 |
Zefram_Fysh |
Vanessa: does http://www.fysh.org/~zefram/tmp/x3.png look right to you in respect of brightness? |
| 01:12 |
VanessaE |
Zefram_Fysh: yep, seems good to me |
| 01:14 |
Zefram_Fysh |
how much space should be between buttons, relative to button size? |
| 01:15 |
sapier |
tat's not defined |
| 01:15 |
sapier |
same as before ;-) |
| 01:15 |
Zefram_Fysh |
well yes, that's why I'm asking |
| 01:16 |
sapier |
formspecs don't have consistent coordinates witdths and heights so what are you asking for? |
| 01:16 |
VanessaE |
Zefram_Fysh: just whatever was the case before, as a function of relative size. |
| 01:16 |
sapier |
make a screenshot look at it ... that's the only way to do it right now |
| 01:16 |
VanessaE |
if the spacing was 1% of the neighboring buttons, keep it that way |
| 01:16 |
VanessaE |
etc. |
| 01:17 |
VanessaE |
(though more likely it would be closer to 0.25%) |
| 01:17 |
Zefram_Fysh |
different DPI and gui_scaling values give radically different values for the same form. I'd like to end up with the proportions being consistent for each form |
| 01:18 |
sapier |
ok guess now you're where I was yesterday |
| 01:24 |
sapier |
hopefully you find a less invasive solution |
| 01:24 |
Zefram_Fysh |
what would you say is meant to be "fixed" about "fixed-size" forms? |
| 01:24 |
sapier |
fixed as of staying same size on window resize |
| 01:25 |
Zefram_Fysh |
excellently clear, thank you. I was getting awfully confused |
| 01:25 |
sapier |
originaly this was a workaround for formspecs not scaling correct but now it needs to be this way becaus of vanessae's "space to control" to control ratio ;-) |
| 01:25 |
* VanessaE |
growls ominously at sapier |
| 01:26 |
sapier |
I know this is not exactly your words but it's at least by meaning what you didn't like at first ;-) |
| 01:26 |
Zefram_Fysh |
I think a change to the text-to-inventory-slot proportions will yield a better space-to-control ratio while remaining compatible with the old system |
| 01:26 |
VanessaE |
sapier: I'm a graphic artist. you know this. |
| 01:26 |
VanessaE |
so you know all too well that I care about layout :) |
| 01:27 |
sapier |
yes and I never did say you're wrong but I did know how much arguing and work this would be |
| 01:27 |
sapier |
Zefram_Fysh: define "keep compatible" ;-) |
| 01:28 |
Zefram_Fysh |
compatible = not breaking existing formspecs. we get to precisely define the things that were previously variable, mainly text size relative to other elements, but keep the positioning and sizing rules otherwise unchanged |
| 01:29 |
sapier |
well didn't I mention yesterday that "we get to precisely define" is the big issue? |
| 01:30 |
Zefram_Fysh |
I don't recall you saying that |
| 01:32 |
sapier |
I didn't tell everyone did understand what I meant nor that I may have been not precise enough |
| 01:55 |
|
Zeno` joined #minetest-dev |
| 02:27 |
Zefram_Fysh |
turns out the tab control doesn't need to be disabled. preprocessEvent() gets control regardless. it looks like the preprocessEvent hook is meant for exactly this sort of situation |
| 02:34 |
|
sapier1 joined #minetest-dev |
| 02:35 |
sapier1 |
Zefram_Fysh: what irrlicht version do you use? because for me without disabling the control the event gets first passed to tabheader and is consumed |
| 02:35 |
Zefram_Fysh |
I have 1.7.3 installed |
| 02:36 |
sapier1 |
strange are you sure it really works? you wouldn't notice in main menu |
| 02:36 |
Zefram_Fysh |
it is noticeable for me at main menu, because I haven't yet tweaked the font size there back up. I tried disabling the preprocess entirely and did see misplaced hotspots |
| 02:37 |
Zefram_Fysh |
you have 1.7.3 also? |
| 02:37 |
sapier1 |
yes ... I'll try again |
| 02:40 |
sapier1 |
you're right must've been a unnoticed compile error when it didn't work .. even better |
| 02:50 |
|
sapier1 left #minetest-dev |
| 02:54 |
ShadowNinja |
''tell sapier I reworded your comments to put them in proper english. If it doesn't mean what you want tell me why or fix it. And please stop messing up the wiki pages. |
| 02:54 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 02:56 |
|
^v joined #minetest-dev |
| 03:09 |
ShadowNinja |
''tell sapier I mentioned that identifiers should use separated_words style to avoid things like get_bool/getbool, and combos like get_worldpath. Also, don't change or remove guidelines unless they're obviously mistaken or you've discussed them and reseived agreement on the change. |
| 03:09 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 03:17 |
|
Miner_48er joined #minetest-dev |
| 03:22 |
|
VanessaE joined #minetest-dev |
| 03:43 |
|
Hunterz joined #minetest-dev |
| 04:03 |
Zefram_Fysh |
''tell sapier new version of my form scaling patch in the same places as the previous one |
| 04:03 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 04:05 |
Zefram_Fysh |
''tell sapier I noticed that checkboxes don't scale with gui_scaling. the text scales fine, but the box itself has fixed size. it looks like Irrlicht doesn't provide a way to affect it. should we do something about it? |
| 04:05 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 05:37 |
|
hmmmm joined #minetest-dev |
| 05:41 |
|
Hunterz joined #minetest-dev |
| 07:26 |
|
nore joined #minetest-dev |
| 08:10 |
|
vifino joined #minetest-dev |
| 08:28 |
|
Garmine joined #minetest-dev |
| 08:38 |
|
exio4 joined #minetest-dev |
| 08:50 |
|
sapier joined #minetest-dev |
| 08:51 |
sapier |
Zefram_Fysh: not the checkboxes are an open issue I havent found a solution for by now too |
| 08:52 |
Zeno` |
I just wanna delete my current fork heh |
| 08:52 |
Zeno` |
it's all messed up |
| 08:53 |
sapier |
ShadowNinja: it's a discussion page not some high lyrics bad english isn't a really good reason (imho) |
| 08:57 |
Zeno` |
sapier, you're in a book I just read |
| 08:58 |
sapier |
Zeno`: a book? |
| 08:58 |
Zeno` |
You're famous! |
| 08:58 |
Zeno` |
yes |
| 08:58 |
sapier |
what's the title? |
| 08:59 |
Zeno` |
http://en.wikipedia.org/wiki/Kevin_J._Anderson#Terra_Incognita_Series |
| 09:00 |
Zeno` |
bbiab, eating dinner |
| 09:03 |
sapier |
Zefram_Fysh: you still ignore dpi for main menu |
| 09:04 |
sapier |
well except of scrollbar ;-) |
| 09:07 |
sapier |
Another (unrelated) bugfix is tabheader using y screensize for it's witdh ... while screensize.Y is still not exactly correct it's at least more suiteable, better fix would be finding our how much offset irrlicht does internaly and calculate tabcontrol from button captions ... but that's a nice to have compared to Y->X change |
| 09:10 |
sapier |
You lack special handling for non freetype fonts ... they provide a different font height so text is way to big |
| 09:14 |
|
casimir joined #minetest-dev |
| 09:23 |
|
Megaf joined #minetest-dev |
| 09:26 |
|
PilzAdam joined #minetest-dev |
| 09:41 |
Zeno` |
https://github.com/minetest/minetest/pull/1543 <-- I think this should be regarded as a bug fix rather than an encancement |
| 09:42 |
sapier |
Zeno`: instead of discussing about enhancement/bug/feature you should try to get someone review it because it's quite irrelevant how it's labeled to when it's merged ... at least as long as there's no release within the next two weeks ;-) |
| 09:43 |
Zeno` |
it's been reviewed |
| 09:43 |
Zeno` |
by RBA and SN at least |
| 09:44 |
Zeno` |
Pretty sure hmmmm looked at it as well, but I can't be sure about that |
| 09:44 |
sapier |
then why don't you tell them to merge it? |
| 09:44 |
sapier |
both of them are allowed too |
| 09:44 |
Zeno` |
time zones |
| 09:44 |
sapier |
-o |
| 09:44 |
Zeno` |
lol |
| 09:45 |
Zeno` |
sapier, will you merge it? |
| 09:45 |
sapier |
in short I believe you don't want it to be relabeld but merged, discuss about what you want not something else ;-P |
| 09:45 |
Zeno` |
yes, I want it merged :P |
| 09:45 |
sapier |
no because I don't know l-systems and can't tell if it's correct or not |
| 09:46 |
Zeno` |
ok :) |
| 09:46 |
sapier |
>>if no seed is provided, the engine will create one<< well I can tell this description is wrong |
| 09:47 |
Zeno` |
how so? |
| 09:47 |
sapier |
as you always need a seed it's gonna be created now too, the difference (for what I remember) is that you now create a random one |
| 09:47 |
Zeno` |
currently if no seed is provided then the seed is 0 |
| 09:48 |
sapier |
which is a perfectly fine seed too |
| 09:48 |
Zeno` |
But that does not match any of the documentation related to l-system trees |
| 09:48 |
Zeno` |
yep, it is |
| 09:49 |
Zeno` |
actually, let me check. It may not even be 0. It may be implementation defined |
| 09:52 |
sapier |
Zefram_Fysh: Most things look quite fine even with complex forsm so good work, yet there are some glitches to adress, I did do some screenshots and marked the most irritating things: http://imgur.com/eeaMcGN,tExC4hr,f38B2Kc,Bc7XFKy,9EtZoJz,AO0ODuy,bJbBz9c,Pk7arBt,0nXfr0Q,P5O3gN2,RXpGmth,NXylk2C |
| 09:53 |
sapier |
And yes as you can see there some of them have been in original formspecs too ... no surprise ... still inconveniant |
| 09:55 |
Zeno` |
yes, currently the seed is implementation defined |
| 09:55 |
Zeno` |
https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_env.cpp#L760 |
| 09:56 |
Zeno` |
It's *probably* 0 for gcc, but... who knows |
| 09:57 |
Zeno` |
It's not initialised so it could be anything really |
| 09:58 |
Zeno` |
As a side effect of that, https://github.com/minetest/minetest/issues/1542 is caused |
| 10:01 |
Zeno` |
I suppose I could run valgrind, but I can see it's not initialised in some circumstance |
| 10:02 |
Zeno` |
s |
| 10:12 |
realbadangel_ |
if no seed is provided then it should be set to a fixed one, zero is as good as any other value |
| 10:13 |
realbadangel_ |
and hmm, or SN doesnt dont know nothing bout lsystem trees |
| 10:15 |
realbadangel_ |
problem with seeds raised when PA demanded trees to be repetitive with given seed |
| 10:15 |
realbadangel_ |
the idea i dont like at all |
| 10:19 |
realbadangel_ |
sapier, https://github.com/RealBadAngel/minetest/commit/7847614784758b009e41ac4b0a4cea6fb26954e8 |
| 10:19 |
realbadangel_ |
another bunch of fixes |
| 10:20 |
realbadangel_ |
nodeboxes will be shaded again, but still no correct lighting |
| 10:21 |
realbadangel_ |
i found quite good implementation of lighting for nodeboxes in DarkRose's Voxelands |
| 10:21 |
realbadangel_ |
it has some flaws but it is way better than our own |
| 10:23 |
realbadangel_ |
https://gitorious.org/minetest-classic/minetest-classic/source/21dfc691421d33de7922884ea6a1fbeebaea7a57:src/content_mapblock.cpp#L252 |
| 10:25 |
sapier |
realbadangel_: can you check and in case it's fine merge zeno's patch (once he did fix the description) |
| 10:25 |
Zeno` |
it's not set to 0 |
| 10:26 |
Zeno` |
(currently) |
| 10:26 |
sapier |
or fix it yourself it should be mentioned that if no seed is given a random value is used |
| 10:26 |
sapier |
and make sure providing 0 as seed really works ;-) |
| 10:26 |
sapier |
manually providing 0 |
| 10:26 |
|
sapier left #minetest-dev |
| 10:27 |
realbadangel_ |
well, 0 is also a seed |
| 10:27 |
Zeno` |
yes, 0 is a seed but it's not set to zero |
| 10:27 |
realbadangel_ |
i think that random should do better |
| 10:27 |
Zeno` |
it's set to some implementation defined value |
| 10:28 |
Zeno` |
because there is no default (it stays un-initialised currently) |
| 10:28 |
realbadangel_ |
ok, i will take care of it today in the evening |
| 10:29 |
Zeno` |
anyway, speak to Vanessa... I'm over the fix :) there are good arguments on both sides |
| 10:29 |
realbadangel_ |
i want it to be as random as possible |
| 10:29 |
realbadangel_ |
plants have to be random |
| 10:30 |
Zeno` |
ok, check the pull request out. |
| 10:31 |
Zeno` |
The other option is to have Lua side provide a seed, but it seems that everyone I speak to expects it to be a random seed unless one is explicity provided |
| 10:31 |
Zeno` |
I'm cool with whatever solution pops up, but the undefined (well, implementation defined) behaviour at least probably needs to be fixed |
| 10:33 |
Zeno` |
VE (moretrees is the main mod that uses l-stuff?) seems to think it's better to set a random seed C++ side if none is provided and I tend to agree with her |
| 10:35 |
Zeno` |
and the patch won't break existing mods anyway |
| 10:35 |
Zeno` |
it'll just make the trees actually random |
| 10:48 |
realbadangel_ |
thats ok |
| 10:48 |
realbadangel_ |
moretrees is the only mod for l-system trees |
| 10:49 |
realbadangel_ |
but i do plan another one, which will use engine drawtype microblocks |
| 10:49 |
realbadangel_ |
which will allow smaller but way more detailed trees and plants |
| 10:50 |
Zeno` |
lokking forward to that! |
| 11:00 |
Zeno` |
was looking forward to the music as well, of course :( |
| 11:03 |
realbadangel_ |
with music we wont agree i afraid |
| 11:03 |
realbadangel_ |
most seems to like something different |
| 11:04 |
Zeno` |
yeah :/ |
| 11:06 |
realbadangel_ |
maybe this could work? http://grooveshark.com/#!/s/Raining+In+Warszawa/2G7YNi?src=5 |
| 11:07 |
Zeno` |
I like it |
| 11:07 |
Zeno` |
I liked the last one as well of course lol |
| 11:08 |
Zeno` |
actually I like the last one better |
| 11:08 |
Zeno` |
although flying around in my test map this is awesome |
| 11:09 |
realbadangel_ |
all of them are aviable in my version of ambience mod |
| 11:10 |
realbadangel_ |
https://github.com/minetest-technic/technic_game/tree/master/mods/ambience |
| 11:10 |
|
ImQ009 joined #minetest-dev |
| 11:11 |
Zeno` |
perhaps one of the "cracktro" would be better |
| 11:11 |
Zeno` |
since people seem to want something short |
| 11:11 |
Zeno` |
crackto tracks* |
| 11:15 |
realbadangel_ |
folks like PA seems to like something "unnoticeable" |
| 11:15 |
realbadangel_ |
like they couldnt turn the speakers off :P |
| 11:15 |
Zeno` |
well, it is difficult |
| 11:17 |
realbadangel_ |
walkin without the pants on the street is also somehow difficult if not strange |
| 11:17 |
realbadangel_ |
and game is doing so |
| 11:18 |
PilzAdam |
realbadangel_, Im generally against any music provided by the engine |
| 11:18 |
PilzAdam |
it should be done by games |
| 11:18 |
Zeno` |
there was a german group who did awesome (short) NT tracks |
| 11:18 |
Zeno` |
wish I could remember their name |
| 11:19 |
realbadangel_ |
PilzAdam, either way we need the music |
| 11:20 |
realbadangel_ |
but imho games should provide ingame music |
| 11:20 |
realbadangel_ |
and there should be one main title |
| 11:21 |
realbadangel_ |
if it was made like you are saying, switching from one game to another in main menu will switch the music scores |
| 11:21 |
Zeno` |
what about speaker only? |
| 11:21 |
realbadangel_ |
dumb idea |
| 11:21 |
Zeno` |
https://www.youtube.com/watch?v=Wu5zd5fCaPA |
| 11:21 |
Zeno` |
no sound card, nothing |
| 11:22 |
realbadangel_ |
i did same tricks on zx specrum |
| 11:22 |
realbadangel_ |
*ZX Spectrum |
| 11:22 |
|
lanxu joined #minetest-dev |
| 11:22 |
Zeno` |
=D |
| 11:23 |
realbadangel_ |
playing mods on Z80 was even harder than on PC |
| 11:25 |
realbadangel_ |
bbl |
| 11:26 |
Zeno` |
night RBA |
| 11:27 |
|
proller joined #minetest-dev |
| 11:27 |
realbadangel_ |
night? im off to work ;) |
| 11:27 |
Zeno` |
yeah, same diff |
| 11:29 |
|
casimir joined #minetest-dev |
| 11:42 |
|
PenguinDad joined #minetest-dev |
| 11:48 |
Zefram_Fysh |
''tell sapier if fixed-size forms are to scale by DPI, then they're not gaining anything by borrowing the logic of dividing the screen size. maybe we should drop the pretence of a fixed screen size, and let fixed-size forms be centred on the real screen. what do you think? |
| 11:48 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 11:53 |
|
Eater4 joined #minetest-dev |
| 11:57 |
Zefram_Fysh |
''tell sapier the form glitches you identify mostly consist of forms assuming quite a small font size relative to other form elements, such that in the old system they only work right with large screen sizes. in picking a fixed ratio of font size to inventory slot size it's inevitable that some forms like this will start looking bad on all screen sizes. it's the flip side of making forms with the opposite assumption now look good on all screen s |
| 11:57 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 12:00 |
Zefram_Fysh |
''tell sapier once the fixed proportions are in the engine, mod authors can tweak their forms (once) to suit it and will then have their forms look good to everyone. I can work on patches for the specific mods you're looking at there if you like; which are they? |
| 12:00 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 12:17 |
|
proller joined #minetest-dev |
| 12:33 |
|
Jordach joined #minetest-dev |
| 12:38 |
|
deltib joined #minetest-dev |
| 12:40 |
|
Taoki joined #minetest-dev |
| 13:02 |
sfan5 |
''tell sapier <sapier> you do keep som issues back till I fixed the other ones on purpose don't you? || lolwat; no I don't, most of the issues I reported were reported previously but you did not fix them |
| 13:02 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 13:03 |
Zeno` |
''tell sfan5 that I said hello |
| 13:03 |
HLuaBot |
I'll tell that to "sfan5" next time I see them around. |
| 13:03 |
sfan5 |
''tell Zeno` hi |
| 13:03 |
HLuaBot |
I'll tell that to "Zeno`" next time I see them around. |
| 13:04 |
Zeno` |
xD |
| 13:14 |
|
MichaelRpdx joined #minetest-dev |
| 13:17 |
|
rubenwardy joined #minetest-dev |
| 13:26 |
sfan5 |
''tell sapier forgot to mention this: "Config" is not a verb |
| 13:26 |
HLuaBot |
I'm already holding too many messages for that user. |
| 13:27 |
sfan5 |
''tell ShadowNinja -HLuaBot/#minetest-dev- I'm already holding too many messages for that user. pls2fix |
| 13:27 |
HLuaBot |
I'll tell that to "ShadowNinja" next time I see them around. |
| 13:27 |
sfan5 |
*sigh* |
| 13:27 |
Robby |
/msg MemoServ |
| 13:28 |
Robby |
(if they are registered nicks) |
| 13:32 |
rubenwardy |
sfan5: what if it is short for configure? |
| 13:32 |
sfan5 |
it is |
| 13:32 |
rubenwardy |
then it is a verb |
| 13:32 |
Zeno` |
it's a noun |
| 13:32 |
sfan5 |
but did you see an entry in the other menus that uses short nouns instead of verbs? |
| 13:33 |
rubenwardy |
no, "configuration" is a noun |
| 13:33 |
sfan5 |
no, "config" is a noun, not a verb |
| 13:33 |
rubenwardy |
yes, if it is short for configuration. Which it is usually |
| 13:34 |
sfan5 |
anyway |
| 13:34 |
sfan5 |
<sfan5> but did you see an entry in the other menus that uses short nouns instead of verbs? |
| 13:35 |
Zeno` |
perhaps all functions should have a suffix... e.g. config_noun(), config_verb() |
| 13:36 |
PenguinDad |
not the best idea imo |
| 13:36 |
Zeno` |
:) |
| 13:36 |
rubenwardy |
much easier to use config and configure :) |
| 13:39 |
|
rubenwardy joined #minetest-dev |
| 13:42 |
celeron55 |
what |
| 13:42 |
celeron55 |
< realbadangel_> problem with seeds raised when PA demanded trees to be repetitive with given seed |
| 13:42 |
celeron55 |
< realbadangel_> the idea i dont like at all |
| 13:42 |
celeron55 |
is this a joke? |
| 13:42 |
celeron55 |
RBA does not know what the purpose of a seed is? |
| 13:43 |
sfan5 |
celeron55: did you read the dicussion yesterday about warning clients with old versions via the server list? |
| 13:43 |
celeron55 |
no, i dont't care atm |
| 13:43 |
sfan5 |
hm, ok |
| 13:54 |
Zeno` |
celeron55, I am sure RBA knows what a seed means |
| 13:55 |
Zeno` |
The issue is, should Lua-side provide a random seed if none is explicitly given |
| 13:55 |
Zeno` |
If it was C I'd say no. If Lua (BASIC-like) I'd say yes |
| 13:56 |
Zeno` |
The documentation for l-system trees *implies* that they have random aspects |
| 13:57 |
Zeno` |
But they're not random (at the moment) at all, because they all use the same (implementation defined) seed unless it's set in treedef via Lua |
| 13:57 |
VanessaE |
if something says it's random, and does not say "you must provide a seed", then it is clearly implied that you don't need a seed to get random behavior. |
| 13:57 |
VanessaE |
and the API says clearly that it is random. |
| 13:58 |
Zeno` |
Yes, so it's a bug |
| 13:58 |
Zeno` |
(the current behaviour) |
| 14:00 |
VanessaE |
the seed is neither indicated to be mandatory nor optional, but is among parameters that are most definitely optional (e.g. you don't have to use ALL of the rules, or the fruit, or all the leaves, etc etc etc), ergo the seed is optional. |
| 14:00 |
VanessaE |
therefore, the C++ side needs to provide something internally that guarantees apparently random behavior, as far as Lua is concerned., |
| 14:00 |
Zeno` |
Correct |
| 14:01 |
VanessaE |
If the modder wants predictable behavior e.g. the exact same tree shape and orientation, they can provide the seed themselves. |
| 14:01 |
VanessaE |
doing it any other way goes against the common usage AND the intent of the spawn_tree() function |
| 14:03 |
|
rubenwardy joined #minetest-dev |
| 14:07 |
|
Jordach_ joined #minetest-dev |
| 14:17 |
|
iqualfragile joined #minetest-dev |
| 14:28 |
|
proller joined #minetest-dev |
| 14:36 |
|
hmmmm joined #minetest-dev |
| 14:44 |
|
Zeitgeist_ joined #minetest-dev |
| 14:45 |
|
Calinou joined #minetest-dev |
| 15:02 |
|
NakedFury joined #minetest-dev |
| 15:10 |
|
ImQ009 joined #minetest-dev |
| 15:43 |
|
twoelk joined #minetest-dev |
| 15:48 |
|
damiel joined #minetest-dev |
| 15:48 |
|
VanessaE joined #minetest-dev |
| 15:58 |
|
Hunterz joined #minetest-dev |
| 16:02 |
nore |
thoughts on https://github.com/minetest/minetest/pull/1562 ? |
| 16:03 |
|
NakedFury joined #minetest-dev |
| 16:10 |
rubenwardy |
Would rather have wildcare optional dependancies. Ie: mesecons_* |
| 16:10 |
rubenwardy |
* mesecons_*? |
| 16:13 |
nore |
that's not the same at all |
| 16:14 |
|
Robby joined #minetest-dev |
| 16:19 |
|
alexxs joined #minetest-dev |
| 16:27 |
|
Calinou joined #minetest-dev |
| 16:45 |
|
khonkhortisan joined #minetest-dev |
| 16:55 |
|
twoelk joined #minetest-dev |
| 17:08 |
|
zat joined #minetest-dev |
| 17:11 |
|
Krock joined #minetest-dev |
| 17:29 |
|
Megaf joined #minetest-dev |
| 18:04 |
|
proller joined #minetest-dev |
| 18:54 |
|
Weedy joined #minetest-dev |
| 19:10 |
|
sapier joined #minetest-dev |
| 19:12 |
sapier |
Zefram_Fysh: not sure why you want to drop it? Fixed size only means it doesn't change with window size. Instead it keeps size it would have at default window size. |
| 19:14 |
sapier |
dpi and manual gui scaling are quite similar, actually they have exactly same effect the only difference is on some architectures dpi can be automatically detected. "gui_scaling" will allways be some manual thing a user can adjust the gui to her/his personal preference. |
| 19:15 |
sapier |
It's debateable if we really should provide dpi and gui_scaling as settings because it might result in confusion. |
| 19:15 |
VanessaE |
then don't bother |
| 19:15 |
VanessaE |
if we already have one control to rule them all, then use it? |
| 19:15 |
VanessaE |
:) |
| 19:15 |
Zefram_Fysh |
at the moment the computation of form sizes for the fixed-size case is done a roundabout way, by pretending that the screen size is fixed and then using the logic that scales according to screen size. if fixed-size forms are to scale according to DPI, it's much less useful to borrow that logic. the only real remaining effect of the fake fixed screen size is that the form stays at the same offset from the top of the window when the window size ch |
| 19:16 |
sapier |
give me a second I need to read your comments hulabot lost too |
| 19:16 |
sfan5 |
sapier: can you please "Config mods" -> "Configure mods"; "Config" is not a verb |
| 19:18 |
sapier |
seems you guys confused hulabot ;-) |
| 19:18 |
VanessaE |
haha |
| 19:18 |
sapier |
sfan5: I actually meant this to be a joke do you want to convince me I should have taken it more serious? ;-) |
| 19:19 |
sfan5 |
what? |
| 19:20 |
sfan5 |
can you provide some context? |
| 19:20 |
sapier |
Zefram_Fysh: at least at standard window size forms have to be non glitched |
| 19:20 |
sapier |
sfan5: my comment with you holding issues back till I fixed the other ones ;-) |
| 19:20 |
Zefram_Fysh |
I fixed multi-line labels, which was the first of your form glitches |
| 19:21 |
sfan5 |
sapier: please try harder to indicate jokes |
| 19:21 |
sapier |
I'll try to add a <joke></joke> tag around them ... but I can't promise to not forget about them |
| 19:22 |
Zefram_Fysh |
did you find a form that is OK at standard window size at the moment and becomes glitchy with my patch? the ones that glitch will mainly currently glitch at smaller window sizes |
| 19:23 |
sapier |
hmm actually that ugly glitch was there before |
| 19:24 |
sapier |
did you fix the non freetype issue yet? |
| 19:24 |
Zefram_Fysh |
not touched that yet |
| 19:25 |
sapier |
VanessaE: do you hav messed up textures on dreambuilder too? |
| 19:25 |
sapier |
Zefram_Fysh: that one is still a no-go |
| 19:26 |
VanessaE |
sapier: where specifically? |
| 19:26 |
VanessaE |
I missed something |
| 19:26 |
sapier |
Zefram_Fysh: while your fixes still don't adress the issue I intended to fix I believe they're way more easy to get applied to core |
| 19:26 |
Zefram_Fysh |
things I currently know I need to fix: DPI scaling for fixed-size forms; non-freetype font selection. anything else? |
| 19:27 |
sapier |
tabheader width ... there's a bug using y screensize instead of (at least) x screensize ... better would be a exact calculation but I didn't see any issue with just using x (y is most likely a copy n paste error) |
| 19:28 |
Zefram_Fysh |
ah yes, I've noticed tabheaders growing scroll buttons when the window gets short in height |
| 19:28 |
sapier |
btw how hard do you expect it to be making label font size configurable in your variant? |
| 19:28 |
Zefram_Fysh |
that's really an independent bug, but can roll it into this patch |
| 19:29 |
sapier |
well without scaling you almost wouldn't notice it |
| 19:29 |
sapier |
btw gui_scaling and dpi can make a gui smaller then default size too, hope you do handle this |
| 19:30 |
Zefram_Fysh |
font size variability within a form fits easily into the architecture. we'd have to use font overrides for the labels, which is easily arranged |
| 19:30 |
Zefram_Fysh |
it scales smaller than default size just fine. try it |
| 19:32 |
Zefram_Fysh |
font size selection in formspecs should be in terms of the target baseline-to-baseline height, which defaults to 0.4 inventory slots. specifying it that way makes it easy to integrate into form layouts |
| 19:39 |
sapier |
Zefram_Fysh: don't talk about layouts in combination with formspec |
| 19:39 |
sapier |
there are none |
| 19:39 |
Zefram_Fysh |
huh? |
| 19:40 |
Zefram_Fysh |
are you using some special meaning of the word "layout"? |
| 19:40 |
sapier |
imho a layout would include consistent positioning so you can really write a layout ... now it's gonna be trial and error forever ;-P |
| 19:41 |
Zefram_Fysh |
my patch does introduce mostly-consistent positioning. one can use formspecs to place elements precisely |
| 19:41 |
sapier |
no it doesn't |
| 19:41 |
sapier |
place a button and 1,2 and right next to it a textfield at 5,2 ... they'll not be at same height |
| 19:42 |
sapier |
not will a button at 2,2 and a filed at 2,3 start at same width or a button with width 2 have same width as a field with width 2 or a checkbox with width 2 |
| 19:42 |
Zefram_Fysh |
that issue is just about the elements' positions being specified in different ways, due to the historical offsets. if you take account of the offsets, you can precisely align them already |
| 19:43 |
Zefram_Fysh |
no trial-and-error needed |
| 19:43 |
sapier |
I always can use a calculator with some strange values, noone will do it that way so it is trial and error |
| 19:43 |
Zefram_Fysh |
I matched the alignments in your test tab by computation, not trial and error |
| 19:43 |
sapier |
as I said you can always use a calculator |
| 19:44 |
Zefram_Fysh |
few humans will handle the offsets manually. that's why there should be a library to do it for them |
| 19:44 |
sapier |
formspecs are PURE manually |
| 19:44 |
Zefram_Fysh |
formspecs are eminently feasible to generate by code |
| 19:44 |
sapier |
there's no gui designer for them unless you volonteer to write one |
| 19:45 |
sapier |
of course Zefram_Fysh siri will write my forspec definition for a special confuration menu ... you're dreaming ;-) |
| 19:46 |
sapier |
but no need to discuss about that mess ppl are lazy and will prefere to do trial and error instead of fixing their existing formspecs |
| 19:47 |
sapier |
btw no sane person will rememer after a week if it's been size*19/60 or size*90/109 ... |
| 19:48 |
VanessaE |
so document it? |
| 19:48 |
Zefram_Fysh |
I don't expect people to remember it. that's what libraries and documentation are for |
| 19:48 |
VanessaE |
and I don't mean in the source code. |
| 19:48 |
VanessaE |
(source code != documentation) |
| 19:48 |
sapier |
VanessaE: no sane person will find it in lua_api.txt nor will anyone understand it in less time then trial and error will take ;-) |
| 19:49 |
VanessaE |
if they can't find it, that means the person who put it there is an idiot :) |
| 19:49 |
Zefram_Fysh |
my UI branch has a big comment documenting a significant subset of the formspec positioning rules. it's full of those awkward fractions |
| 19:49 |
VanessaE |
sapier: remember this mantra: "Whoever designed this ______ is/was an idiot!" :-) |
| 19:49 |
sapier |
quite similar to damage calculation ... I had to look at code when I wanted to know how it's done ... and I don't have any idea how it is done again now ... it's just to complicated |
| 19:49 |
VanessaE |
(fill in the blank) |
| 19:50 |
sapier |
well Zefram_Fysh succesfully destroyed the chance to fix that mess ;-) |
| 19:51 |
VanessaE |
my husband and I say this all the time, for all manner of things from software/user-interface to things in the physical world, and 99.9% of the time, we're right :) |
| 19:51 |
sapier |
unless he fails to fix the remaining issues but I don't expect them to be non fixable (except the button glitch) which won't be a blocker |
| 19:51 |
|
proller joined #minetest-dev |
| 19:52 |
sapier |
sfan5: sorry lost track what did you mean with Config? |
| 19:52 |
VanessaE |
sapier: "config" is a noun, not a verb. |
| 19:53 |
VanessaE |
either use a different word or spell out "configure". |
| 19:53 |
sapier |
context please? |
| 19:53 |
Zefram_Fysh |
"config mods" |
| 19:53 |
VanessaE |
[08-20 15:19] <sfan5> sapier: can you please "Config mods" -> "Configure mods"; "Config" is not a verb |
| 19:54 |
sapier |
you english guys are crazy everywhere you save digits but there you use the long form ;-P |
| 19:54 |
VanessaE |
sometimes, the short form of the word looks wrong :) |
| 19:54 |
sapier |
not to me ... maybe there's some region of the world where config is a english verb? |
| 19:54 |
VanessaE |
you non-english guys are crazy everywhere, using dashes to join words instead of spaces ;) |
| 19:55 |
VanessaE |
if you put a period after it, it suggests an abbreviation |
| 19:55 |
VanessaE |
then it's valid. |
| 19:55 |
VanessaE |
"Config. mods" |
| 19:55 |
sapier |
germans don't use dashes we don't need them |
| 19:56 |
VanessaE |
this would be valid english for a "word" that isn't otherwise valid by itself in this context. \ |
| 19:56 |
exio4 |
sapier: germans don't need spaces either |
| 19:56 |
sapier |
Donaudampfschiffahrtsgesellschaftskapitänswitwenmietshauskaminkehrermeister is a perfectly fine german word ... well at least as of grammar |
| 19:56 |
VanessaE |
I see dashes used a lot where a space is correct, and words run together where some kind of delimiter belongs |
| 19:57 |
VanessaE |
yeah but I see it done with english words too :) |
| 19:57 |
VanessaE |
this is NOT right :) |
| 19:57 |
sapier |
yes we germans have a strange habit to invent english words |
| 19:57 |
sapier |
well words sounding english |
| 19:57 |
VanessaE |
not just sounding english. actual english words :P |
| 19:58 |
sapier |
"Public viewing" or "Handy" for example |
| 19:58 |
VanessaE |
doesn't matter |
| 19:58 |
VanessaE |
(because to be fair, we do it too :P ) |
| 19:59 |
VanessaE |
but a program's user interface should be treated as a "formal writing" medium |
| 19:59 |
sapier |
It's quite ironic english ppl did take the word for "kindergarten" from a language whos ppl have quit low birth rate |
| 20:00 |
VanessaE |
indeed. |
| 20:01 |
sapier |
sfan5: any other wrong words in that gui? because I will not fix next one tomorrow ;-P |
| 20:02 |
Zefram_Fysh |
the use of the word "kindergarten" in the English language is mainly a US phenomenon, not universal. in England we call it a "nursery" |
| 20:02 |
Zefram_Fysh |
all west European countries have low birth rates |
| 20:02 |
sapier |
at least in newzeeland it's used too |
| 20:03 |
VanessaE |
here a nursery is something you'd get after running plantlife modpack for a while :P |
| 20:03 |
VanessaE |
or in a hospital's birth ward |
| 20:03 |
Zefram_Fysh |
we use "nursery" for the plant establishment too |
| 20:03 |
khonkhortisan |
IhavetogotothestorebecauseIranoutofspacesandhyphens! |
| 20:04 |
VanessaE |
khonkhortisan: serves you right for using a dvorak layout or whatever it was ;) |
| 20:04 |
khonkhortisan |
Well, I also use a compose key for spanish and am in the middle of setting up pinyin for chinese |
| 20:04 |
sapier |
khonkhortisan: I've got a lot of hyphens here because of not using them, you can have mine. |
| 20:05 |
VanessaE |
really though, here a nursery is generally reserved for babies when they're still limited to cribs and the like |
| 20:05 |
khonkhortisan |
That's what it sounds like to me, something involving babies. |
| 20:06 |
khonkhortisan |
and nurse-ing |
| 20:06 |
khonkhortisan |
(hyphen for emphasis) |
| 20:06 |
VanessaE |
otherwise kindergarten is just another grade in school. |
| 20:06 |
VanessaE |
(albeit a very low work level one) |
| 20:07 |
khonkhortisan |
I was doing math with reader rabbit, then went to kindergarten to sort m&ms by color. |
| 20:08 |
sapier |
sorry to interrupt but could we get back to minetest? ;-) can someone test https://github.com/minetest/minetest/pull/1565 |
| 20:08 |
VanessaE |
sapier: what's minetest? |
| 20:08 |
khonkhortisan |
minetest and yourstest |
| 20:08 |
sapier |
it's supposed to not change anything |
| 20:09 |
VanessaE |
oh wait, that's right..this is some sort of coding channel isn't it. |
| 20:09 |
sapier |
well at least nothing already existing |
| 20:09 |
* VanessaE |
looks |
| 20:09 |
khonkhortisan |
ourtest and histest, all'y'all'stest and nonav'y'all'stest |
| 20:09 |
VanessaE |
sapier: holy... |
| 20:10 |
VanessaE |
oh, lots of changes buried under spacing changes ;) |
| 20:10 |
VanessaE |
what's the real purpose of this? |
| 20:10 |
khonkhortisan |
Yeah, can the spacing be a separate commit? |
| 20:10 |
VanessaE |
(the title is sorta obscure) |
| 20:10 |
sapier |
two things, whitespace fixes |
| 20:10 |
sapier |
ok three things |
| 20:10 |
sapier |
some bugfixes (especially now really allowing subtabs) |
| 20:11 |
khonkhortisan |
I see parents being mentioned |
| 20:11 |
VanessaE |
inb4 prollr says something about spaces. |
| 20:11 |
sapier |
and the other major improvement by now form data have been saved in a predefined structure now you create that structure prior use |
| 20:11 |
sapier |
so you can have two three whatever |
| 20:12 |
VanessaE |
sapier: ah. could be useful. like a multi-page formspec |
| 20:12 |
sapier |
yes that one was created some time ago before I disabled code style fixing in my editor |
| 20:12 |
VanessaE |
but without having as much work to create it |
| 20:12 |
sapier |
actually it's quite simple with this changes |
| 20:12 |
khonkhortisan |
I say each c++ line that otherwise has no text in it should be filled with non-breaking spaces and other things that are neither space nor tab for the files to be dual-C++ and whitespace (the language). |
| 20:13 |
sapier |
github should improve their diff tool to hide whitespace only changes on demand |
| 20:13 |
sapier |
as any other diff too can do |
| 20:13 |
VanessaE |
wait a minute here...sapier, when did fstk become part of upstream? |
| 20:13 |
sapier |
on last mainmenu cleanup |
| 20:13 |
VanessaE |
oh ok |
| 20:13 |
VanessaE |
I missed that |
| 20:14 |
sapier |
it's not part of lua api |
| 20:14 |
VanessaE |
still wip? |
| 20:14 |
sapier |
nor can you use the current version in game |
| 20:14 |
sapier |
these update make it possible to use it, you still have to load the files manually |
| 20:15 |
sapier |
wip as in "not complete" yes ... and as in "not tested by a lot of ppl" |
| 20:15 |
VanessaE |
yeah |
| 20:15 |
sapier |
mainmenu as well as mobf_settings use it ... later one a copy of that code I suggest to merge |
| 20:16 |
|
NakedFury joined #minetest-dev |
| 20:16 |
VanessaE |
oops, +File: fstk/ui.lua (Mainmenu only!) |
| 20:16 |
VanessaE |
wait, ignore that. |
| 20:17 |
VanessaE |
I might suggest renaming this before you make it "official" though |
| 20:17 |
VanessaE |
fstk suggests "filesystem toolkit". maybe formtk? |
| 20:18 |
sapier |
renaming ... only if there's no other way to do it because renaming always breaks things |
| 20:18 |
VanessaE |
I know but in this case, no one can possibly have used it yet |
| 20:18 |
VanessaE |
so it can't break anything :) |
| 20:18 |
VanessaE |
(I don't suggest renaming the lib you use in mobf) |
| 20:18 |
sapier |
if you have a really good suggestion and othere believe this needs to be changed too |
| 20:19 |
sapier |
I'm not scared about mobf but about mainmenu, docs ... things like that |
| 20:19 |
VanessaE |
my only suggestion would be "formtk" |
| 20:19 |
VanessaE |
otherwise I have no idea |
| 20:19 |
VanessaE |
but "fstk" just screams "filesystem" |
| 20:19 |
VanessaE |
think "fsck" |
| 20:19 |
sapier |
well for mtk ... |
| 20:19 |
VanessaE |
way too similar. |
| 20:20 |
VanessaE |
mtk? |
| 20:20 |
VanessaE |
mftk? |
| 20:20 |
VanessaE |
minetest forms tool kit |
| 20:20 |
VanessaE |
(or mother--- ....;) ) |
| 20:20 |
sapier |
I'll rename it to susy ... honoring the goof old yet unprooven supersymetry theory |
| 20:20 |
VanessaE |
haha |
| 20:23 |
sapier |
btw formtk is to long to be a "short" ;-) |
| 20:23 |
VanessaE |
:P |
| 20:24 |
sapier |
ftk? |
| 20:24 |
VanessaE |
*does quick google search* |
| 20:24 |
VanessaE |
"Forensic Toolkit" |
| 20:24 |
sapier |
you'll find something for any 3 letter shortcut ;-P |
| 20:24 |
VanessaE |
only kidding :) |
| 20:25 |
exio4 |
msusy |
| 20:25 |
sapier |
considering the positioning of formspecs forensic wouldn't be worst thing ;-) |
| 20:25 |
VanessaE |
ftk or mftk are workable if you don't mind what some people will take the "f" or "mf" to mean in jest. :) |
| 20:25 |
sapier |
what's "m" for? |
| 20:26 |
|
Mikeonline joined #minetest-dev |
| 20:27 |
sapier |
despite the naming issue could someone test it? ;-) |
| 20:28 |
VanessaE |
which would fit well with the way people think of formspecs ;) |
| 20:28 |
sapier |
it's rebased don't know how many times, so chances there might have sliped in a issue are there |
| 20:29 |
VanessaE |
it's minetest, did you honestly expect there not to be an issue? ;) |
| 20:48 |
sapier |
https://github.com/minetest/minetest/pull/1565 ok plz review .. shall others do the whitespace fixes |
| 21:11 |
Zefram_Fysh |
sapier: new version of my form patch. think everything necessary is fixed |
| 21:11 |
|
NakedFury joined #minetest-dev |
| 21:12 |
|
Mikeonline left #minetest-dev |
| 21:15 |
Zefram_Fysh |
you should also consider adding a new public method to the font engine for the form code to use. I haven't touched the font engine innards at all, but what the form system tries to get from the font engine could be done a bit more conveniently from there |
| 21:15 |
sapier |
what do you need? font code is work in progress |
| 21:16 |
Zefram_Fysh |
firstly, the form code really wants to request fonts by pixel size, but the getFont interface has some scaling of the size parameter. it uses pixel sizes internally, so the form code is descaling just to cancel out the scaling of the size parameter |
| 21:18 |
sapier |
well I can add this function but imho the font dpi handling is supposed to be done at a single location and not spread around throughout code |
| 21:19 |
Zefram_Fysh |
secondly, the search for the target font size would feel nicer if it used a cache like the one that the font engine uses internally at a lower level. that could be integrated into the font engine, which would expose a method for selecting fonts by baseline-to-baseline height instead of em height |
| 21:19 |
sapier |
once again what exactly do you want? |
| 21:20 |
Zefram_Fysh |
sure, scaling should be done in limited places, but the form handling is a special case because it has to do its own DPI and scaling logic for the non-font stuff, and the fonts must follow that |
| 21:20 |
sapier |
why? |
| 21:20 |
Zefram_Fysh |
the ideal interface for the form code to use would be fe->getFontByFullPixelHeight(h) |
| 21:20 |
sapier |
you know the base font size and you know your relation |
| 21:21 |
|
khonkhortisan joined #minetest-dev |
| 21:21 |
sapier |
imho you're duplicating code to formspecs |
| 21:22 |
Zefram_Fysh |
why what? the font selection for the form must follow the size of non-font elements in order to achieve consistent proportions between text and non-text form elements |
| 21:22 |
sapier |
either dpi and gui_scaling is applied in formspec only ... which would cause a lot of issues within non formspec texts ... or formspec gui shouldn't handle dpi/gui_scaling for fonts at all |
| 21:23 |
sapier |
everyhing else results in "here we do it this way, here that way, and thee another way" |
| 21:24 |
sapier |
and adding that function is quite a mess in fontengine because it's basically duplicating half of it |
| 21:25 |
sapier |
or at least rewriting |
| 21:25 |
Zefram_Fysh |
if all the font scaling were done in the font engine, the form stuff that wants to size relative to the screen would have to convert the screen size into inches in order to make font requests. you can't get away from having some of this scaling logic, specifically for fonts, in the form engine |
| 21:25 |
sapier |
no it doesn't |
| 21:25 |
sapier |
you know your base size don't you? |
| 21:26 |
Zefram_Fysh |
what do you mean by "base size" here? |
| 21:26 |
sapier |
in 800x600 a image/slot whatever you wanna use has one specific size |
| 21:27 |
sapier |
to get the correct font just request "font_default_size * (current_slot_size/800x600slotsize) |
| 21:28 |
sapier |
this way you always get correct font and don't need to handle dpi/gui_scaling on your own |
| 21:29 |
sapier |
and we don't have to bloat font_engine api |
| 21:29 |
sapier |
or do I miss some point? |
| 21:31 |
Zefram_Fysh |
the current_slot_size depends on scaling factors |
| 21:31 |
sapier |
at some time you have it's size |
| 21:32 |
sapier |
and for what I remember the slot size doesn't depend on font size so not an issue |
| 21:32 |
Zefram_Fysh |
all the size computations are done with values scaled by gui_scaling and DPI. those are incorporated really early on |
| 21:33 |
sapier |
still you're messing up layers if you demand raw fonts |
| 21:33 |
sapier |
font_engine is designed to hide the dpi gui scaling dependencys |
| 21:33 |
Zefram_Fysh |
for your formula to work, the 800x600slotsize would have to be a virtual value scaled in the same way. it would be a really artificial value, not a meaningful base size, so it would amount to explicitly descaling for the font request |
| 21:33 |
sapier |
no it doesn't need to scale at all |
| 21:34 |
Zefram_Fysh |
anyway, this API addition is not required. the current layered approach works |
| 21:34 |
sapier |
well what you do there is a hack |
| 21:34 |
Zefram_Fysh |
yes, it's a hack |
| 21:34 |
sapier |
instead of letting font_engine do what it's supposed to do you try to trick your own behaviour |
| 21:35 |
Zefram_Fysh |
ultimately the form engine does want fonts scaled, but not as simply as always multiplying by DPI and gui_scaling. it's only that simple for the fixed-size forms |
| 21:36 |
sapier |
but the scaling done within formspec is something Additional to gui_scaling and dpi |
| 21:37 |
sapier |
yes you have to apply them to your elements to so formspec is as of layers somehow in parallel to font_engine (at least partial) |
| 21:37 |
Zefram_Fysh |
the form engine scales variable-size forms according to screen size |
| 21:37 |
sapier |
yet not using the scaling capabilitys provided by font engine but reimplementing it on your own is bad design |
| 21:41 |
sapier |
Zefram_Fysh: can you explain baseline-to-baseline compared to em size? |
| 21:41 |
sapier |
because at least non ttf sizes are specified by same size you would specify in e.g. word |
| 21:42 |
|
exio4 joined #minetest-dev |
| 21:42 |
sapier |
maybe there's the inconsistency between ttf and non ttf fonts |
| 21:43 |
sapier |
that font searching code is crap |
| 21:43 |
Zefram_Fysh |
em height is normally the height of an "M", from baseline to top of the glyph. baseline-to-baseline is the interval between lines of text, from one baseline to the next, and is the more important value for layout |
| 21:44 |
Zefram_Fysh |
I thought maybe the non-freetype fonts were being selected by baseline-to-baseline height, but they're not |
| 21:44 |
sapier |
so your baseline to baseline is basically useless because any new irrlicht version or maybe even irrlicht setting will break it |
| 21:44 |
Zefram_Fysh |
I didn't check on the height of their "M"s. maybe their selection size doesn't really match "M", or maybe it's just those particular fonts that are funny |
| 21:44 |
Zefram_Fysh |
what? how do you figure that? |
| 21:45 |
sapier |
come one you do a lot of calculations there trying to find out the size of the font while you not even know what size function returns |
| 21:45 |
sapier |
this can be different for ttf and irrlicht fonts |
| 21:46 |
sapier |
and even more relevant even if this code is correct it's complex as hell |
| 21:47 |
Zefram_Fysh |
the code examines the actual size of the fonts, and this works consistently between freetype and non-freetype fonts. I hoped that 85% factor would be consistent enough, but turns out it's not, so it has to go empirical |
| 21:47 |
Zefram_Fysh |
the code is as complex as it needs to be to solve the problem |
| 21:47 |
sapier |
empirical checks usually are wrong for at least some situations different from the tested ones |
| 21:49 |
sapier |
well noone's gonna understand that code thus if there's any error in future it's gonna be your job to fix it |
| 21:50 |
sapier |
and it doesn't fix the positioning issue |
| 21:50 |
sapier |
actually now it's even broken on default size :-( |
| 21:51 |
Zefram_Fysh |
what's broken? |
| 21:51 |
sapier |
label positioning |
| 21:53 |
sapier |
http://imgur.com/IsCtt18 |
| 21:53 |
sapier |
see "1/12" at default size |
| 21:54 |
Zefram_Fysh |
under the old system it was impossible to reliably align a label with buttons. that form was always at the mercy of the variable font size |
| 21:55 |
sapier |
you said you can do font_scaling without breaking formspecs |
| 21:55 |
Zefram_Fysh |
with my patch, it *is* possible to reliably align. the formspec will need an edit to achieve it |
| 21:56 |
Zefram_Fysh |
indeed, I haven't broken formspecs. that form has misalignment there now, but that's not a new misalignment |
| 21:56 |
sapier |
I don't care what is additionally possible with my patch you can even write formspec positioning without using a calculator ... yet it's not what you told to do |
| 21:57 |
sapier |
that text was aligned correct at default size before don't pretend it was missaligned at default size |
| 21:57 |
Zefram_Fysh |
I never said this patch would make alignment easy. I said it would make it possible, and remain compatible with existing formspecs |
| 21:57 |
sapier |
it was even aligned correct if you did scale |
| 21:58 |
sapier |
no Zefram_Fysh you did say different, you said "font scaling is possible without breaking formspecs" ... I can look for your exact words if you insist but that's been the meaning |
| 21:58 |
Zefram_Fysh |
sure it would have been aligned for some combinations of font selection and graphic scaling |
| 21:59 |
sapier |
you did not make any limitation |
| 21:59 |
sapier |
because I remember having told that current positioning system is not sufficent to get scaling work without glitches |
| 22:00 |
sapier |
now you did implement yours, and it is way less invasive then mine true |
| 22:00 |
|
paramat joined #minetest-dev |
| 22:00 |
sapier |
yet it's not what you initially claimed to deliver |
| 22:00 |
Zefram_Fysh |
I agree with my earlier statement that font scaling is possible without breaking formspecs. I do not consider a formspec to have been broken where it didn't reliably have an alignment and now doesn't have it at all |
| 22:01 |
sapier |
oh so now we reinterpret the term "broken" to fit your interpretation |
| 22:03 |
Zefram_Fysh |
"without breaking" only rules out making a form newly broken. that aspect of that form was already in a broken state. not that that's the form author's fault |
| 22:04 |
sapier |
you did newly break the inventory at default size |
| 22:04 |
sapier |
well even at any other isze |
| 22:04 |
sapier |
because that text there WAS aligned correct before |
| 22:05 |
Zefram_Fysh |
by that argument, any change at all breaks something in some situation |
| 22:05 |
sapier |
your differences are way less then mine, but as they still have inconsistent positions between elements I'd not be sure if they are more easy to fix |
| 22:06 |
Zefram_Fysh |
that's a fair point |
| 22:06 |
sapier |
if you can't fix that issue we still can't merge it without broad discussion |
| 22:06 |
sapier |
because you really change alignment of widely used elements |
| 22:06 |
sapier |
I guess the result of that discussion will be positive |
| 22:06 |
Zefram_Fysh |
I can't fix the fact that the patch changes some visible things |
| 22:08 |
sapier |
Remember me saying I can't add font_scaling without changing positioning ... What you did now is implementing the variant with minimal visible changes. That's gonna make discussion way more easy |
| 22:09 |
sapier |
And reduces chance the real fix I did gets any positive feedback to zero |
| 22:09 |
paramat |
Since you're on the subject ... in recent commit 4ca, in the configure mods menu, scrolling by repeatedly clicking the arrows or in the scroll bar will actually enable mods |
| 22:09 |
sapier |
well I'm used to do work for trash in minetest |
| 22:10 |
sapier |
paramat: we didn't change anything there recently are you sure this is a new behaviour? |
| 22:11 |
sapier |
Zefram_Fysh: In case you don't intend to try to find a even better fix I suggest making some screenshot showing the differences so we can do a open discussion |
| 22:11 |
Zefram_Fysh |
fair enough |
| 22:12 |
sapier |
one small thing please rething about that crapy font detection code |
| 22:12 |
Zefram_Fysh |
I can also do a patch to fix that particular form |
| 22:12 |
sapier |
well at least split it to a separate function |
| 22:13 |
sapier |
so we know what is hack and what (at least a little bit less stange) formspec code |
| 22:13 |
paramat |
sapier i can't be sure it's new behaviour because i always clicked-and-dragged before |
| 22:13 |
Zefram_Fysh |
I thought about using a binary search in an earlier version, and did shy away from it. that's where the 85% scaling to get estimated em height came from. I revived the search idea because the fixed factor didn't work for the non-freetype fonts, as you noticed |
| 22:13 |
Zefram_Fysh |
separate function, sure |
| 22:13 |
paramat |
i'll open an issue about it |
| 22:15 |
sapier |
Zefram_Fysh: bad thing about that is in worst case you're gonna check same font way more then once |
| 22:15 |
Zefram_Fysh |
I see the ugliness too |
| 22:16 |
sapier |
btw there is a function to get font height in font engine |
| 22:16 |
Zefram_Fysh |
fortunately everything is cached and quick to look up, so the redundant-looking checks are really cheap |
| 22:17 |
sapier |
still you should remove the font height function or does it do any different then that one within font_engine? |
| 22:17 |
paramat |
sapier, bug happens in 0.4.10 stable too, just checked |
| 22:17 |
sapier |
Zefram_Fysh: except of using a different text |
| 22:18 |
sapier |
paramat: ok thanks please mention this in issue |
| 22:18 |
Zefram_Fysh |
it is slightly different. the form code one counts kerning height which the font engine doesn't, but the kerning height is zero for all the fonts I'm using here |
| 22:18 |
sapier |
Zefram_Fysh: unsigned int getTextHeight(unsigned int font_size=FONT_SIZE_UNSPECIFIED, FontMode mode=Unspecified); |
| 22:18 |
sapier |
ok I see |
| 22:19 |
Zefram_Fysh |
but also, font_effective_height() is used in several places where the code already has a pointer to the font object, so that's quicker than looking up the font again through the font engine would be |
| 22:19 |
Zefram_Fysh |
I could use getTextHeight in the search code, if it counted kerning height |
| 22:19 |
sapier |
still providing that height by font engin wouldn't mess up the layers |
| 22:19 |
Zefram_Fysh |
indeed |
| 22:20 |
Zefram_Fysh |
would you like it done that way? getTextHeight to include kerning height, and form code to use getTextHeight in the search |
| 22:21 |
sapier |
no I don't consider kerning height to be part of text height |
| 22:21 |
Zefram_Fysh |
the string passed to getDimension is mostly ignored by the irrlicht innards. with "Ay" I'm just making an effort to include both capital height and descender space, in case irrlicht later stops ignoring the actual characters |
| 22:22 |
sapier |
I'd call it "lineHeight" |
| 22:22 |
Zefram_Fysh |
"line height" is a good term. I was looking for something snappier than "baseline-to-baseline height" |
| 22:23 |
sapier |
any minimum kerning height? |
| 22:24 |
Zefram_Fysh |
I don't know whether the kerning height is allowed to be negative. kerning parameters generally can be |
| 22:24 |
sapier |
ok I'm just gonna assume kerning to be 0 for requests with invalid font size |
| 22:25 |
sapier |
I do return 4 as minimum size in those cases anyway |
| 22:25 |
Zefram_Fysh |
yes, 0 is a sensible substitute if you're faking up a size |
| 22:26 |
sapier |
yes but font size 0 did result in quite some crashes ;-) |
| 22:26 |
Zefram_Fysh |
I mean, 0 is sensible for the kerning height |
| 22:26 |
Zefram_Fysh |
sensible also to avoid 0 as a fake text height |
| 22:27 |
sapier |
how did you change the alignment? |
| 22:27 |
sapier |
for example to make a text be alingned to a button how much offset do I have to use? |
| 22:28 |
Zefram_Fysh |
it's simplest if you give the button notional zero height. (its actual height is fixed.) then the Y coord for the label must be 0.2333333 less than the Y coord for the button |
| 22:29 |
sapier |
lol ... I should stop reading your code .... having that much magig numbers in there I'm almost sure this will break something |
| 22:29 |
Zefram_Fysh |
insert rant about an unmemorable magic number |
| 22:29 |
sapier |
0.2333333??? (0.2 + 1/3* 0.01)? |
| 22:30 |
Zefram_Fysh |
the only alignment you can reliably do with labels in the old system is to the *bottom* of the label. and that still works |
| 22:30 |
Zefram_Fysh |
0.2 + 1/3 * 0.1 |
| 22:30 |
sapier |
Zefram_Fysh: do you really expect someone to use 7 digit positioning? |
| 22:30 |
Zefram_Fysh |
it's actually 7/30 |
| 22:30 |
sapier |
at worst I did use 3 digits by trial and error by now |
| 22:31 |
Zefram_Fysh |
I expect a library to use sufficient digits |
| 22:31 |
sapier |
and for sure no 7/30 notation |
| 22:31 |
sapier |
stop telling about things that don't exist Zefram_Fysh |
| 22:32 |
sapier |
if there was a library doing the calculations I'd not even think about using your code instead of fixing the numbers in a correct way ... because in this case we could hide all the changes in that library ;-P |
| 22:32 |
Zefram_Fysh |
you could only do that if (nearly) everyone were using the library |
| 22:33 |
Zefram_Fysh |
it sure would be easier |
| 22:33 |
sapier |
you can only assume your 7 digit numbers beeing calculated by a library if (nearly) everyone uses it too ;-P |
| 22:35 |
sapier |
hmm |
| 22:35 |
sapier |
you did same thing I did |
| 22:35 |
sapier |
only honor first size element |
| 22:37 |
sapier |
that change should be mentioned too |
| 22:37 |
Zefram_Fysh |
what change? |
| 22:38 |
sapier |
right now any following size element would be evaluated too ... not sure for what to use that ... but I guess someone could use that bug to make it a feature |
| 22:38 |
Zefram_Fysh |
button positioning and sizing logic doesn't change with my patch |
| 22:38 |
sapier |
usually noone abuses that feature ;-) |
| 22:38 |
Zefram_Fysh |
(the actual height does change, but the fact that the user can't control the height doesn't change) |
| 22:39 |
sapier |
size[] tag |
| 22:39 |
sapier |
there could be a fixed size tag in it |
| 22:39 |
Zefram_Fysh |
the height field of button[] is actually used, but it just modifies the position |
| 22:39 |
sapier |
followed by a not fixed one |
| 22:40 |
sapier |
guess that'd result in some crazy things |
| 22:40 |
Zefram_Fysh |
er, do you mean having multiple size[] elements in one formspec? |
| 22:40 |
sapier |
yes right now this is possible |
| 22:40 |
Zefram_Fysh |
yes. is it actually done? |
| 22:40 |
sapier |
I'd consider it to be a bug ... but still it is possible |
| 22:41 |
sapier |
I don't do it that way but I'm not everyone |
| 22:41 |
Zefram_Fysh |
I didn't worry too much about compatibility with such forms. it could be made strictly compatible if necessary, but I think we're better off with simpler code unless such necessity actually shows up |
| 22:43 |
sapier |
double screen_dpi = porting::getDisplayDensity() * 96; .... do you really have to convert anything back and forward don't know how many times? |
| 22:43 |
Zefram_Fysh |
you can see where screen_dpi is used |
| 22:43 |
sapier |
this is going to be wrong if we once decide default is now 140 ... and noone will know it's been hardcoded in there too |
| 22:44 |
Zefram_Fysh |
I'd rather have had a getDisplayDPI() function than this scaled version |
| 22:45 |
sapier |
yes but you claim things that just aren't true too "is 0.53 inch" I'd be surprised if this was true for me too |
| 22:46 |
Zefram_Fysh |
oh, minetest gets my DPI wrong, because it's a config variable that I didn't set. if it wanted the right answer it should ask X, which does know the right value because it asked the monitor |
| 22:46 |
sapier |
and there's no need to do this, you have magic numbers anyway just use something different instead of 0.53 and you can use the display density direct |
| 22:47 |
|
EvergreenTree joined #minetest-dev |
| 22:47 |
Zefram_Fysh |
I think that magic number would be much less clear than the current separation |
| 22:47 |
sapier |
you can try to ask x on windows |
| 22:47 |
Zefram_Fysh |
that's why it's in porting:: |
| 22:48 |
sapier |
yes but now you do a multiplication which is quite a heacy operation on each regen |
| 22:48 |
Zefram_Fysh |
new version of patch is up, moves the font search into a separate function |
| 22:49 |
Zefram_Fysh |
a floating-point multiplication is not a noticeable expense in the context in which that code runs |
| 22:49 |
sapier |
fine still try to avoid calculations in cases whery you can make preprocessor do it |
| 22:49 |
sapier |
on android devices each multiplication counts |
| 22:50 |
sapier |
it's good style to avoid runtime calculations where preprocessor can do too |
| 22:52 |
sapier |
btw images do still ignore dpi settings |
| 22:53 |
Zefram_Fysh |
images? image[] elements get scaled with the form as a whole |
| 22:53 |
sapier |
no try at credits tab |
| 22:54 |
sapier |
the minetest icon ignores dpi as well as gui_scaling |
| 22:54 |
Zefram_Fysh |
interesting |
| 22:55 |
Zefram_Fysh |
"image[0.5,1;" .. core.formspec_escape(logofile).."]" -- no size specified |
| 22:55 |
Zefram_Fysh |
lua_api.txt doesn't describe that usage |
| 22:56 |
sapier |
well seems to work ;-) |
| 22:56 |
Zefram_Fysh |
yeah. the code for it is there, and it just omits any mention of size. seems to mean that it'll translate PNG pixels directly to screen pixels with no intervention |
| 22:56 |
sapier |
guess that means "just show as is" |
| 22:57 |
Zefram_Fysh |
I suggest that the formspec should specify a size. then it'll scale |
| 22:58 |
Zefram_Fysh |
4,4 seems about right, and does make it scale |
| 22:58 |
sapier |
It's getting boring but "it did work before" ... so it's a valid usecase ... you can't assume noone is doing it that way ... and I guess the fix won't be two days of work |
| 22:59 |
Zefram_Fysh |
it doesn't look like sizeless image[]s would ever have done anything different than pixel-for-pixel |
| 22:59 |
sapier |
yes but dpi and gui_scaling have been added lately so this is just another bug with it to be fixed |
| 23:05 |
sapier |
Zefram_Fysh: you should be glad the more we find now the less will users discover |
| 23:14 |
|
Miner_48er joined #minetest-dev |
| 23:15 |
|
sapier left #minetest-dev |
| 23:45 |
|
paramat left #minetest-dev |
| 23:54 |
|
sfan5 joined #minetest-dev |
