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 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: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 sapier if I click the scrollbar for gui scaling at some positions the fonts suddenly get one level bigger 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 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 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: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: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. 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. 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. 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: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: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: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 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 realbadangel_ night? im off to work ;) 11:27 Zeno` yeah, same diff 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: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. 13:02 sfan5 ''tell 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: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: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 16:02 nore thoughts on https://github.com/minetest/minetest/pull/1562 ? 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 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 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: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] 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 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:27 sapier despite the naming issue could someone test it? ;-) 20:28 VanessaE [off]mftk could read as mother fucking tool kit 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: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 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 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 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 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