Minetest logo

IRC log for #minetest-dev, 2014-08-20

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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/mine​test/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,f38B2​Kc,Bc7XFKy,9EtZoJz,AO0ODuy,bJbBz9c,Pk7​arBt,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/com​mit/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/minete​st-classic/source/21dfc691421d33de7922884ea6a​1fbeebaea7a57: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/Ra​ining+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/t​echnic_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 Donaudampfschiffahrtsgesellschaftskapi​tä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 Ihavetogotothestorebecause​Iranoutofspacesandhyphens!
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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext