--- Log opened Sun Sep 11 00:00:33 2016
--- Day changed Sun Sep 11 2016
20160911 00:00:33< celmin> Perhaps the UI is updated but an underlying variable is not?
20160911 00:00:52-!- fabi_ [~fabi@176.0.92.30] has quit [Ping timeout: 240 seconds]
20160911 00:01:56-!- TC01 [~quassel@128.220.251.37] has joined #wesnoth-dev
20160911 00:02:21< tad_> celmin: I'll clear cache etc and start fresh
20160911 00:04:00< vultraz> cannot reproduce
20160911 00:04:21< celmin> Just to be sure, you loaded a regular save first, right?
20160911 00:05:58< tad_> celmin: Yes. Cleared all saves, played through, then reloaded the replay. But I'll retest when make finishes.
20160911 00:06:55< celmin> That was to vultraz 
20160911 00:07:09< vultraz> yes
20160911 00:10:04< celmin> There is no lua_geti :|
20160911 00:10:19< celmin> Only rawgeti
20160911 00:12:03< celmin> I think that was added in 5.3?
20160911 00:12:21< celmin> Yup. :/
20160911 00:13:39< vultraz> Let's update to 5.3 immediately :D
20160911 00:14:04< celmin> Can't do it immediately!
20160911 00:16:00< celmin> I wonder why they decided to introduce first-class integers though.
20160911 00:16:11< celmin> Or are the first-class? I'm not entirely clear on that.
20160911 00:17:06< celmin> "ipairs and the table library respect metamethods"
20160911 00:17:26< celmin> Okay, so does that mean __ipairs is no longer needed because ipairs() will call the __index and/or __len metamethods>
20160911 00:17:28< celmin> ^?
20160911 00:18:53< celmin> Anyway, the problem with updating is that it is almost certain to introduce subtle bugs.
20160911 00:19:02< celmin> So it has to be done with care.
20160911 00:19:03< tad_> Still getting those -Wmissing-field-initializers warnings.
20160911 00:19:13< celmin> …where?
20160911 00:19:31< tad_> src/game_launcher.cpp:184:77: warning: missing initializer for member ‘savegame::load_game_metadata::difficulty’
20160911 00:19:46< vultraz> oh come onn D:
20160911 00:19:50< tad_> And another file, same class, will show in a few more minutes
20160911 00:20:07< celmin> Ah. I bet that was recent.
20160911 00:20:10< vultraz> celmin: btw, since we haz chat widget, do you think i should put one in Create?
20160911 00:20:19< celmin> There's no room for it.
20160911 00:20:29< vultraz> (sadly we cannot do what dota does and keep it minimized)
20160911 00:20:37< vultraz> (since we have no layering system)
20160911 00:20:45< celmin> So if you want to add it, it'll have to be large resolution only.
20160911 00:20:55< vultraz> obviously
20160911 00:21:29< celmin> Which means you need to use four-argument find_widget, pass false as the fourth argument, and test if it returned null. (Or do you already know this?)
20160911 00:22:45< celmin> vultraz: Apparently __ipairs is deprecated, not removed. That would help a bit with such an update.
20160911 00:23:09< vultraz> I know how to use the 4-argument version of find_widget :|
20160911 00:24:43< celmin> Does anyone even use the hyperbolic trig functions?
20160911 00:24:58 * tad_ waves his hands.
20160911 00:25:06< celmin> ?
20160911 00:25:09< tad_> But I'm an old math geek. So don't count me.
20160911 00:25:15< celmin> I mean in Wesnoth. :P
20160911 00:25:27 * tad_ chuckles.
20160911 00:25:45< tad_> Well, then: no. Probably not.
20160911 00:26:04< tad_> In fact, I'd be amazed if anyone even looked for them.
20160911 00:26:21< celmin> It doesn't sound like any of the deprecated things would be a problem, then, except maybe __ipairs, and that seems easy to solve.
20160911 00:27:01-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 00:27:02< travis-ci> wesnoth/wesnoth#10830 (master - 6baee82 : Celtic Minstrel): The build failed.
20160911 00:27:02< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159025658
20160911 00:27:02-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 00:27:13< celmin> Huh?
20160911 00:27:29< celmin> Ohhh, the merge.
20160911 00:29:38< celmin> (It seems like an update to Lua 5.3 would mean we can just remove any __ipairs metamethods.)
20160911 00:29:48< vultraz> so, we *can* update to 5.3?
20160911 00:30:05< celmin> I guess, but obviously it needs to be PR'd and tested.
20160911 00:31:22< tad_> src/hotkey/hotkey_handler.cpp:534:50: warning: missing initializer for member ‘savegame::load_game_metadata::difficulty’ [-Wmissing-field-initializers]
20160911 00:31:25< celmin> The way I would do it is make a commit replacing all Lua files with 5.3 equivalent, then one or more additional commits with any Wesnoth-specific patches.
20160911 00:31:26< tad_> There's that other file ...
20160911 00:31:45< celmin> vultraz: Can you fix this one?
20160911 00:31:51< celmin> The missing field initializer one.
20160911 00:31:54-!- gfgtdf_ [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160911 00:32:14< celmin> Or maybe gfgtdf
20160911 00:32:15< vultraz> I don't get that error, though
20160911 00:32:23< celmin> But you know where it is.
20160911 00:32:28< celmin> Because tad_ pasted the lines.
20160911 00:32:33< tad_> It's several fields.
20160911 00:32:39< tad_> I just paste the first.
20160911 00:32:53< tad_> Sames ones, two files.
20160911 00:33:04< celmin> Basically the idea is that if you have a struct with 10 fields, your {braced-init-list} must have exactly 10 items.
20160911 00:33:21< celmin> So you should be able to fix it even though you don't get the error yourself.
20160911 00:33:39< celmin> (Though personally I'd prefer if that warning were nuked.)
20160911 00:33:56< celmin> (Then again, I did go cleaning it up elsewhere earlier.)
20160911 00:34:05< tad_> Well, if you NEED a non-zero initializer, it's a very good warning
20160911 00:34:39-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Ping timeout: 264 seconds]
20160911 00:34:42< celmin> tad_: But it also gives a warning for {0} and {}, which IIRC is a common way of requesting default (zero) initialization.
20160911 00:34:51-!- gfgtdf_ is now known as gfgtdf
20160911 00:34:55< vultraz> maybe tad_ could fix it since he has the full list
20160911 00:35:09< tad_> I'll look.
20160911 00:35:12< celmin> vultraz: You don't need the full list.
20160911 00:35:22< celmin> It's several errors in one spot from what I understand.
20160911 00:35:30< celmin> It's just emitting one error for each missing field, right?
20160911 00:36:52< gfgtdf> i personally dont think this is a very usefulwarning, speciall sicne it forces your to update each initlizer-list consutrction of an struct if you adda new field to it.
20160911 00:37:02< gfgtdf> what c++ realyl needs are names parmaeters though
20160911 00:37:14< celmin> BTW shadowm please review campaignd PR
20160911 00:37:18< gfgtdf> c actuall allows code like like { .filename = "" }
20160911 00:37:28< celmin> gfgtdf: You can doo a similar thing easily.
20160911 00:37:33< tad_> difficulty, show_replay, cancel_orders, summary, load_config, select_difficulty  || three places in src/game_launcher.cpp 184 191 543 || src/hotkey/hotkey_handler.cpp 534
20160911 00:38:05< celmin> Also, clang/GCC alreadt support that C99 syntax in C++. Unfortunately MSVC decided only to support it in C.
20160911 00:38:10< celmin> ^do
20160911 00:38:41< celmin> I do agree the warning isn't very useful though.
20160911 00:38:59< tad_> I'm looking at it.
20160911 00:39:41< celmin> Sudden thought - I wonder if adding default-initializers straight into the struct definition would silence the warnign?
20160911 00:39:44< celmin> ^warning
20160911 00:40:24< gfgtdf> celmin: i am not sure what you mean, but i wouldnt call wriring a params type with set_ methods for every function for that you want to allow named parameters 'easy'
20160911 00:40:32< vultraz> shadowm is on wesbreak and I don't think he wants to review the campaignd pr
20160911 00:40:40< vultraz> why do we need *him* to review it, anyway
20160911 00:41:27< vultraz> and for the record, I'm not doing the lua 5.3.3 PR
20160911 00:41:52< vultraz> I did the 5.3.1 PR and didn't get it right, I tried to do  5.3.2 pr and failed
20160911 00:41:56< vultraz> not doing a 5.3.3 one :|
20160911 00:43:26< gfgtdf> which remings me, we shoudl make use use std::excpetion_ptr in the for th rethrow stuff, this might allow us to instad of making fallthrough exceptions, make fallthough the default and mark non-fallthoigh exceptions instead.
20160911 00:43:57< gfgtdf> so thta lua wound anymore catch things liek for example 'bad_alloc' when thrown from our code.
20160911 00:44:27< celmin> gfgtdf: I was talking about the chained constructor idiom.
20160911 00:44:35-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160911 00:45:23< celmin> vultraz: He seemed to want to review it when I asked him a few days ago.
20160911 00:45:39< gfgtdf> celmin: well for named inilizer list this may be a solution, but for generall named-parameters for functions it is not.
20160911 00:46:03< celmin> gfgtdf: True, won't work for function params.
20160911 00:47:26-!- gfgtdf_ [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160911 00:48:32< vultraz> how the hell is it that panels screw up dimension calculations...
20160911 00:48:51< celmin> No idea! Doesn't window have a panel?
20160911 00:49:02-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 00:50:24-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160911 00:50:36-!- gfgtdf_ is now known as gfgtdf
20160911 00:51:28< vultraz> as far as I know
20160911 00:52:14< vultraz> oh come on, is this bug back??
20160911 00:52:21< vultraz> I guess it never went away...
20160911 00:52:23< vultraz> *curses*
20160911 00:52:30< celmin> ?
20160911 00:53:38< vultraz> any surface with a blur effect cannot handle variable state widgets with alpha components
20160911 00:54:10< vultraz> the background of the widget on state change becomes a clipping of the top of the window surface
20160911 00:55:30-!- gfgtdf_ [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160911 00:55:41< vultraz> celmin: https://drive.google.com/file/d/0B-mR9s8FduLLcWRjRTJCMFIzcDg/view?usp=sharing look here, at the Strict Sync button
20160911 00:56:10< vultraz> as you can see, for some damn reason it draw a copy of the panel border behind the toggle button when its state changes
20160911 00:56:19-!- gfgtdf__ [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160911 00:56:49< celmin> Is that a pane or a panel?
20160911 00:57:00-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160911 00:57:00-!- gfgtdf__ is now known as gfgtdf
20160911 00:57:25< celmin> Wait, do you have multiple MP campaigns installed?
20160911 00:57:45< vultraz> panel
20160911 00:57:46< vultraz> and yes
20160911 00:58:08< celmin> What's the difference between pane and panel anyway...
20160911 00:58:20< vultraz> I... don't know
20160911 00:58:49< vultraz> I think[pane] is an implementation detail of the matrix widget
20160911 00:59:05< vultraz> anyway, the issue *only* happens on surfaces with a blur effect
20160911 00:59:26< vultraz> there's something screwed up with the canvas handling of blurring
20160911 00:59:36< vultraz> well, actually, that's know...
20160911 00:59:44< celmin> [pane] is used in the titlescreen too.
20160911 00:59:53< vultraz> no, that's panel
20160911 01:00:00< vultraz> the same panel you see in my screenshot
20160911 01:00:19-!- gfgtdf_ [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160911 01:00:42< gfgtdf> i thought of the new list widget
20160911 01:01:00< vultraz> I don't understand the way gui2 draws the canvas, really..
20160911 01:01:10< vultraz> especially with regards to different states
20160911 01:01:19< vultraz> as far as I can tell, the canvas is different on a per-state basis
20160911 01:01:43< vultraz> for example, there's a bug that if the surface passed to canvas::blit is the video surface, you cannotblur it directly
20160911 01:02:01< celmin> Ah, you're right, whoops.
20160911 01:02:05< vultraz> because as soon as you mouse over a widget, the blue effect starts to effect everything besides the widget
20160911 01:02:09< vultraz> text, border, etc
20160911 01:02:17< vultraz> and can compount
20160911 01:02:26< vultraz> so it uses a workaround
20160911 01:02:50< vultraz> there's something fundamentally broken with the way twindow draws its children
20160911 01:02:54< vultraz> but I don't see it :|
20160911 01:03:14< vultraz> gfgtdf: what about it?
20160911 01:03:47< gfgtdf> i thought ot used [pane]
20160911 01:04:23< vultraz> pane seems to support adding new entries
20160911 01:04:27< celmin> [pane] does appear to be something intended for dynamic content, yeah.
20160911 01:05:59< vultraz> blur effects still need to be applied to the surface since we don't have OGL
20160911 01:06:53< celmin> vultraz: What is tlobby_main::active_window_ for?
20160911 01:07:01< vultraz> uh
20160911 01:07:03< vultraz> dunno
20160911 01:07:07< vultraz> something to do with th chatbox
20160911 01:07:08< vultraz> i guess
20160911 01:07:39< celmin> vultraz: It's triggering -Wunused-private-field for me.
20160911 01:07:55< vultraz> likely can remove
20160911 01:08:08< vultraz> the chatbox can handle its own active room 
20160911 01:08:11< celmin> You remove or I?
20160911 01:08:27< vultraz> you
20160911 01:08:51< celmin> You may want to consider enabling that warning if your compiler supports it, too.
20160911 01:08:54-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160911 01:09:49< vultraz> I do not know how to fix this blur issue :(
20160911 01:09:54< vultraz> where is Aginor when you need him
20160911 01:10:07< celmin> Aginor: you around?
20160911 01:10:08-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160911 01:10:25< vultraz> obviously I could just disable blur
20160911 01:10:27< vultraz> bu
20160911 01:10:32< vultraz> it'd be nice to fix it
20160911 01:11:07< vultraz> what I don't understand is why the passed surface is blurred
20160911 01:12:15< vultraz> or why these issues only happen on a state change
20160911 01:12:40< vultraz> mousing over a widget or something should *not* invalidate the entirety of the canvas
20160911 01:12:55< vultraz> it should mark a dirty rect the size of the widget and redraw that only
20160911 01:14:39< vultraz> but i can't even find the code that handles the changes when states change
20160911 01:15:22< gfgtdf> vultraz: i though evry state has its own canvas ?
20160911 01:15:47< vultraz> hmm..
20160911 01:16:22-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 01:16:54-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160911 01:16:55< vultraz> then obviously there's something broken with the way canvases are handled between states if blurring is active
20160911 01:18:02< celmin> Ah, now I'm getting the missing initializers? That's surprising, since I don't think I got them on the SDL stuff (maybe I just never built on Mac during that period?).
20160911 01:19:08-!- gfgtdf_ [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 01:19:18< vultraz> i've found the draw_background/children/foreground functions
20160911 01:19:25< vultraz> but how does that work with states
20160911 01:21:19-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160911 01:21:21< celmin> vultraz: Just to be sure, is empty string fine as a default difficulty?
20160911 01:21:32-!- gfgtdf_ is now known as gfgtdf
20160911 01:21:38< celmin> And false for show_replay, cancel_orders, select_difficulty>
20160911 01:21:40< celmin> ?
20160911 01:21:42< vultraz> should be
20160911 01:22:30 * celmin is fixing it by adding a constructor with defaulted parameters.
20160911 01:23:20-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 01:24:29< tad_> PR 770 clears the warnings I saw. I'd feel best if someone could test on clang and msvc ...
20160911 01:25:17< vultraz> it's ridiculous that one need to do that
20160911 01:25:21-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160911 01:25:55< tad_> SO comments are it's a bug never fixed, ot fixed in 4.7 which has reverted
20160911 01:26:26< celmin> Blah, we worked on the same thing.
20160911 01:26:39< celmin> Should I accept PR 770 or close it and push my version?
20160911 01:26:44-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160911 01:26:49< celmin> He's gone.
20160911 01:27:01-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20160911 01:27:25-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 01:28:07< vultraz> obviously the blurring effect is getting propagated up the canvas stack..
20160911 01:28:17< vultraz> blurring is background only..
20160911 01:29:17< vultraz> but different background may be blurred..
20160911 01:29:22-!- Bonobo [~Bonobo@2001:44b8:254:3200:415b:d70:4172:f4c7] has joined #wesnoth-dev
20160911 01:29:40< vultraz> and ok, even with the workaround, this doesn't explain why backgrounds of state changed widgets display clips of the background!
20160911 01:29:59< vultraz> which, for the record, doesn't go away with using the other blur method
20160911 01:32:29< vultraz> none of this makes sense
20160911 01:34:22< vultraz> not every widget even has background/foreground
20160911 01:34:26< vultraz> some have state_*
20160911 01:36:04< vultraz> with the "other", buggy blurring method, the background state seems to give a mini copy of the entire background surface..
20160911 01:36:13< vultraz> o-O
20160911 01:37:14< vultraz> I can't even fix the background issue
20160911 01:38:56< vultraz> it just doesn't make sense
20160911 01:39:00< vultraz> there's a canvas stack
20160911 01:39:07< vultraz> so it should just draw nicely on top of each other
20160911 01:39:49< celmin> vultraz: In the loadgame constructor, is the filename known?
20160911 01:39:55< vultraz> what?
20160911 01:39:57< vultraz> no
20160911 01:40:00< celmin> 'kay
20160911 01:41:08< vultraz> ok I think I... might know the issue...
20160911 01:41:11< vultraz> well, to one problem
20160911 01:41:24< vultraz> it's grabbing a rect from the top left..
20160911 01:41:31< celmin> "problem" and "issue" are kinda synonymous.
20160911 01:44:22< vultraz> OK
20160911 01:44:29< vultraz> I got it to stop displaying the border clip
20160911 01:44:36< vultraz> but there are still some artifacts..
20160911 01:44:37< celmin> Updating XCode, please no push
20160911 01:44:52< vultraz> not pushing
20160911 01:45:02< celmin> Just saying
20160911 01:45:11< celmin> In general to anyone
20160911 01:47:22< vultraz> well this is odd
20160911 01:47:27< vultraz> is [text_input] broken
20160911 01:48:08-!- gfgtdf_ [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 01:48:09< vultraz> hm, no..
20160911 01:48:26< celmin> Is what broken now
20160911 01:48:41< irker886> wesnoth: Celtic Minstrel wesnoth:master e3ab484f5e8b / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update XCode project https://github.com/wesnoth/wesnoth/commit/e3ab484f5e8be5b1fe4ce603cf7aa33351d77844
20160911 01:48:43< irker886> wesnoth: Celtic Minstrel wesnoth:master 9232b5bf87f5 / src/ (4 files in 3 dirs): Fix compiler warnings https://github.com/wesnoth/wesnoth/commit/9232b5bf87f501cae671eba8378c8ef04f105448
20160911 01:48:56< vultraz> moving to 7,5 in the test scenario seems to not work properly..
20160911 01:49:40< vultraz> also, move_units_fake is still broken (known for a long time)
20160911 01:51:07< celmin> Pretty sure tad was using it a lot?
20160911 01:51:39-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160911 01:51:42< celmin> Or are there separate move_unit_fake and move_units_fake?
20160911 01:51:47-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 01:51:48< vultraz> yes
20160911 01:51:50-!- gfgtdf_ is now known as gfgtdf
20160911 01:51:52< celmin> Sorry
20160911 01:52:05< vultraz> https://gna.org/bugs/index.php?23995
20160911 01:53:07< vultraz> perhaps someone can look into tha
20160911 01:53:08< vultraz> t
20160911 01:54:04< celmin> Someone broke the loading screen?
20160911 01:54:09< vultraz> what?
20160911 01:54:11< vultraz> no?
20160911 01:54:39< celmin> Not just that, even.
20160911 01:54:50< celmin> The loading screen never clears the screen before drawing now.
20160911 01:54:57< celmin> So everything goes on top of everything else.
20160911 01:55:07< celmin> And I'm getting artifacts when mousing over a button on the titlescreen.
20160911 01:55:08< vultraz> I have no idea what you're talking about 
20160911 01:55:21< celmin> It should be obvious what I'm talking about...
20160911 01:55:23-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160911 01:55:35< vultraz> it doesn't happen to me
20160911 01:56:03< tad_> Works for me, too
20160911 01:56:14< celmin> I guess it's probably related to the canvas refactor...
20160911 01:56:24< celmin> The gold outline is also missing the multiplayer select box.
20160911 01:56:51< celmin> Slider is missing its line in MP Create.
20160911 01:57:04< tad_> celmin: about pr 770 .. sorry had to bail for wife .. do what you wish
20160911 01:57:09< celmin> It looks like you're gonna have to revert that if you want to release 1.12.6 soon.
20160911 01:57:13< celmin> ^13
20160911 01:57:15< vultraz> your computer is fucked up o_O
20160911 01:57:25< celmin> Well, let's see if mattsc gets it.
20160911 01:57:38< celmin> And maybe ancestral.
20160911 01:57:40< vultraz> there is literally no reason that should happen
20160911 01:57:50< celmin> If it's just me, then maybe it can be left.
20160911 01:57:51< vultraz> and you didn't report this yesterday
20160911 01:58:01< celmin> I don't think I built yesterday.
20160911 01:58:42< celmin> At least the text box in Lua console erases itself.
20160911 01:58:50< celmin> Nothing is outlined, though.
20160911 01:59:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160911 01:59:12< celmin> I'll try a clean rebuild later, just in case, and maybe also see if there's an updated SDL2.
20160911 01:59:33< vultraz> I assume you're running 2.0.4
20160911 01:59:51< celmin> I don't remember, might be 2.0.3 or even 2.0.2.
20160911 02:01:03< vultraz> there's an info box for this :)
20160911 02:01:07< vultraz> right at the titlescreen :)
20160911 02:01:16< celmin> Oh yeah.
20160911 02:01:17< celmin> Handy
20160911 02:01:44< celmin> I guess anything drawn with the renderer is entirely missing.
20160911 02:01:50< celmin> So all I see is the images.
20160911 02:02:41< vultraz> you can still get log output
20160911 02:02:59< celmin> ?
20160911 02:03:03< vultraz> with the Copy to Clipboard button
20160911 02:03:17< celmin> What are you talking about?
20160911 02:04:03-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Ping timeout: 276 seconds]
20160911 02:04:34< celmin> Actually, buttons have a partial gold outline… the gold outline is drawn entirely with the renderer, right?
20160911 02:04:37< vultraz> that dialog has a Copy to Clipboard button
20160911 02:04:42< celmin> So the renderer may be sort of working.
20160911 02:04:44< vultraz> and uh.. yes
20160911 02:04:54< celmin> I have no idea why you're talking about a copy to clipboard button at all.
20160911 02:05:03< vultraz> in the Game Version dialog
20160911 02:05:07< vultraz> bottom left
20160911 02:05:17< celmin> Why?
20160911 02:05:25< vultraz> even if you cannot see the text you can click on that to copy the report to clipboard
20160911 02:05:29< vultraz> paste it in your text editor
20160911 02:05:32< vultraz> and see your sdl version
20160911 02:05:44< celmin> I can see the text.
20160911 02:06:00< celmin> I can see everything important, I think, it's mostly shading and lines that are missing.
20160911 02:06:17< celmin> (Plus the loading screen doesn't clear.)
20160911 02:06:21< vultraz> let's hope it's just you
20160911 02:07:28< celmin> If mattsc or ancestral gets it though, you'll probably want to temporarily revert if you plan to release 1.13.6 this month.
20160911 02:07:55< celmin> I have SDL 2.0.3.
20160911 02:08:09< celmin> Would I need to update everything SDL or just the main lib?
20160911 02:08:25< vultraz> main lib
20160911 02:09:08< tad_> wesnoth: /home/lundberg/wesnoth/src/replay.cpp:639: bool replay::add_start_if_not_there_yet(): Assertion `base_->get_pos() == 0' failed.
20160911 02:09:11< celmin> I'll try that later, then. Since swapping libs requires a full rebuild anyway, I'll do both at once.
20160911 02:09:24< celmin> But I want to finish what I'm doing first.
20160911 02:09:25< tad_> Sync'd PR 770 applied, too. Cleared cache/config/saves .. 
20160911 02:09:37< gfgtdf> tad_: when exactly ?
20160911 02:09:44< gfgtdf> when do you get the erro i mean
20160911 02:09:50< celmin> Sorry about 770, I pretty much fixed it at the same time as you. :|
20160911 02:09:51< tad_> Played HttT S01 and loaded as replay from Menu|Load once S02 was up
20160911 02:10:15< tad_> celmin: NP. Fixed is the important thing. Who doesn't matter
20160911 02:10:27< celmin> gfgtdf: Why are you asserting the nonexistence of the load data?
20160911 02:11:05< gfgtdf> there was a remove_load_data() before but i think there can never be a loadgame data in that situation.
20160911 02:11:29< celmin> And you tested a few possible routes?
20160911 02:12:41< gfgtdf> tad_: try adding a load_data_.show_replay |= is_replay_save(load_data_.summary); in savegame.cpp line 140
20160911 02:13:38< tad_> ok will do hang on
20160911 02:14:50< gfgtdf> vultraz: coudl it be that register_bool doesnt work properly when you disable the widget like its  done in the laodgame dialog with show_replay for replay saves ?
20160911 02:14:51< tad_> gfgtdf: line 140 is blank for me.
20160911 02:15:06< gfgtdf> tad_: yes
20160911 02:15:19< tad_> Ah. OK.
20160911 02:15:26< vultraz> gfgtdf: it should work..
20160911 02:15:34< gfgtdf> tad_: just in load_game_ingame() before the throw and after the 	if(!gui2::tgame_load::execute(game_config_, load_data_, video_)) {
20160911 02:16:57< tad_> 143 reads: 	// Confirm the integrity of the file before throwing the exception.
20160911 02:17:05< tad_> was 141
20160911 02:17:55< gfgtdf> tad_: ?
20160911 02:18:23< tad_> brb
20160911 02:18:29-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160911 02:22:49 * vultraz groans
20160911 02:22:58< vultraz> i cannot get rid of this artifact
20160911 02:23:14< vultraz> why should there be tint shadow..
20160911 02:23:17-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160911 02:23:57-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 02:24:19< tad_> Sorry about that. I'm building DEBUG and when it links everyhthing dies.
20160911 02:24:39< tad_> That patch worked, replay loads fine with it.
20160911 02:27:07< tad_> Should I put up a PR to document it so we don't forget?
20160911 02:27:19-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160911 02:27:40< celmin> Since you've already done it anyway, I guess you might as well? 
20160911 02:28:25< tad_> OK. Will only take a moment. Easy to close if it's not needed.
20160911 02:35:21-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160911 02:38:52< vultraz> oh my god what have I done
20160911 02:39:08< celmin> Black magic?
20160911 02:40:22< vultraz> so I simply cannot get this working
20160911 02:40:51< vultraz> i can make it slightly less broken, at least
20160911 02:41:36-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 02:42:33< irker886> wesnoth: Charles Dang wesnoth:master 9c239d1fabab / src/gui/core/canvas.cpp: Prevent copy of top border drawing when mousing over widgets with blurred parent https://github.com/wesnoth/wesnoth/commit/9c239d1fabab27d6ad99a0a66cfb02dde0691b42
20160911 02:42:50< vultraz> still leaves dark shadows around the borders though
20160911 02:43:04< vultraz> that I cannot fix
20160911 02:43:26< celmin> ...
20160911 02:43:41< vultraz> hm?
20160911 02:43:53< celmin> I'm just shocked that that change does anything.
20160911 02:46:24< vultraz> any programmer knows such things resolve themselves in one of two ways: It's Broken And I Don't Know Why, or It Works And I Don't Know Why :P
20160911 02:47:00< tad_> nah. that's only for senior programmers. 
20160911 02:50:49< vultraz> for the record
20160911 02:50:56< vultraz> we do a *lot* of hacky stuff with surfaces 
20160911 02:51:14< vultraz> for example
20160911 02:51:15< vultraz> get_surface_portion
20160911 02:51:30< vultraz> it creates a new surface with 'create_compatible_surface' and returns it
20160911 02:51:47< vultraz> what happens if you don't create a compatible surface and just use the passed surface?
20160911 02:51:51< vultraz> wesnoth goes haywire
20160911 02:52:15< celmin> Obviously?
20160911 02:52:23< vultraz> what does create_compatible_surface do? calls SDL_CreateRBGSurface
20160911 02:52:37< celmin> If you blit between surfaces with different colour formats...
20160911 02:54:07< vultraz> SDL_CreateRBGSurface is of course, creating a new surface
20160911 02:54:10< vultraz> so you have a function
20160911 02:54:22< vultraz> that creates a surface and calls another function that creates a new surface and returns it
20160911 02:54:30< vultraz> then copies part of that surface and returns it
20160911 02:54:49< vultraz> and in this case, in the renderer, all that is used to create ANOTHER surface
20160911 02:54:52< vultraz> which is then blurred
20160911 02:55:11< vultraz> oh, and guess what?
20160911 02:55:17< vultraz> blur_surface creates ANOTHER surface
20160911 02:55:19< vultraz> this time with make_neutral_surface
20160911 02:55:31< vultraz> taking the passed surface as  an argument
20160911 02:55:52< vultraz> in this case, optimize is false
20160911 02:56:01< vultraz> so it then returns that new surface
20160911 02:56:33< vultraz> now, what happens to that surface? it's blitted on to the surface originally passed to canvas::blit
20160911 02:56:36< vultraz> and THEN
20160911 02:56:40< vultraz> THAT surface is blitted onto the canvas :|
20160911 02:56:42< vultraz> how is this
20160911 02:56:43< vultraz> in ANY way
20160911 02:56:45< vultraz> optimal
20160911 02:57:04< vultraz> at least 4 new surfaces are created
20160911 02:57:35< celmin> To some extent it may be required to ensure that the surfaces are compatible, but… I don't really know
20160911 02:57:47< mattsc> Ooo, it compiles again.
20160911 02:58:07< mattsc> celmin: I’ve been away all day and am only here for a couple minutes now also.  What am I supposed to look at?
20160911 02:58:27< celmin> mattsc: I'm getting significant graphical glitches.
20160911 02:58:33< celmin> If you're getting them it'd be pretty obvious.
20160911 02:58:35< vultraz> mattsc: does wesnoth look normal for you when you start it
20160911 02:58:38-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160911 02:58:59< celmin> Particularly the loading screen.
20160911 02:59:44< mattsc> Loading screen as in loading a saved game, right?
20160911 02:59:55< mattsc> It looks different than it used to, but no glitches.
20160911 03:00:27< vultraz> no, the loading screen
20160911 03:00:30< vultraz> not the load game dialog
20160911 03:00:32< celmin> Even just when starting Wesnoth.
20160911 03:00:39< celmin> Sounds like you're not getting any issues.
20160911 03:00:44< vultraz> yeah
20160911 03:00:48< vultraz> which is good
20160911 03:00:49< mattsc> Oh, right ...
20160911 03:01:02< celmin> Like if you press F5 at titlescreen, it goes black, right?
20160911 03:01:07< celmin> With Wesnoth logo and loading text and such.
20160911 03:01:23< celmin> For me that's all just drawing over the titlescreen instead.
20160911 03:01:27< vultraz> well
20160911 03:01:36< vultraz> any graphical glitch that obvious would be immediately noticed
20160911 03:01:40< celmin> Yeah.
20160911 03:01:41< vultraz> so I think he's good
20160911 03:01:42< mattsc> Whoa, this is super fast now (the loading screen)
20160911 03:01:56< vultraz> mattsc: compared to.. yesterday?
20160911 03:02:00< mattsc> Yes, it goes black, all looking good.
20160911 03:02:14< vultraz> if compared to yesterday, then that's excellent
20160911 03:02:28< celmin> Well, I'll try a rebuild with updated SDL, at least.
20160911 03:02:28< mattsc> I’m having SDL 2.0.4 btw, since that question cameup.
20160911 03:02:47< celmin> Might poke a little at the canvas code as well.
20160911 03:02:57< mattsc> No, the loading screen looks the same.
20160911 03:03:10< vultraz> [14:01:36]	mattsc	Whoa, this is super fast now (the loading screen)
20160911 03:03:14< celmin> mattsc: Fast compared to when?
20160911 03:03:17< mattsc> Load game dialog, when clicking on a game, looks slightly different; but I don’t know since when.
20160911 03:03:17< vultraz> ^
20160911 03:03:30< mattsc> vultraz, celmin: I don’t know.
20160911 03:03:32< vultraz> fast compared to when
20160911 03:03:43< mattsc> I don’t know.
20160911 03:03:59< mattsc> I usually start from the CL, go to a different screen, come back a few seconds later.
20160911 03:04:04< celmin> mattsc: Are you comparing to the old loading screen with the progress bar?
20160911 03:04:18< mattsc> celmin: I … do … not … know 
20160911 03:04:20< celmin> 'kay
20160911 03:04:22< celmin> Shrug
20160911 03:04:28< mattsc> It takes something like 1.5 seconds
20160911 03:04:44< mattsc> I don’t remember it ever being so fast.
20160911 03:04:45< celmin> …nice
20160911 03:04:54< celmin> Yeah, that's… pretty amazing...
20160911 03:04:58< mattsc> But I don’t know when the last time is that I paid attention.
20160911 03:05:03< celmin> Barely enough time to see it
20160911 03:05:07< mattsc> Exactly.
20160911 03:05:10< vultraz> :D
20160911 03:05:14< mattsc> But it looks just fine in that time.
20160911 03:05:25< vultraz> well, yesterday I committed some changes
20160911 03:05:40< vultraz> that i expect have made significant improvements
20160911 03:05:42< vultraz> in performance
20160911 03:05:58< celmin> Hmm, maybe we should just make sure that F5 isn't actually broken though.
20160911 03:06:13< mattsc> Well, I don’t know how much of this is cached in OS X.  I could try to reboot and try again.
20160911 03:06:17< mattsc> But right now I am off.
20160911 03:06:29< celmin> Wesnoth itself caches stuff as well, but F5 should skip that.
20160911 03:06:34< vultraz> f5 works for me
20160911 03:06:43< vultraz> very fast
20160911 03:06:44< mattsc> Yes, for me also.
20160911 03:07:25< mattsc> I’ll need to be off and reboot anyway.  I’ll see how fast it is the first time around.
20160911 03:07:40< vultraz> bit slower for me
20160911 03:07:43< vultraz> but still not too bad
20160911 03:07:53-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160911 03:08:09< vultraz> smaller dialogs open basically instantly for me now 
20160911 03:08:12< celmin> Connect-to-server loadingscreens still need work.
20160911 03:08:12< vultraz> which is great
20160911 03:08:44< celmin> I forget, does storyscreen use floating GUI1 widgets or floating GUI2 widgets?
20160911 03:10:00< celmin> Is there any reason we can't replace the floating GUI1 widgets in the game interface with floating GUI2 widgets?
20160911 03:10:52< vultraz> storyscreen is gui1
20160911 03:11:13< vultraz> could be converted to gui2
20160911 03:11:17< vultraz> and what widgets do you mean?
20160911 03:11:25< celmin> Floating buttons, text box, etc.
20160911 03:11:34< celmin> Floating labels.
20160911 03:11:49< celmin> Maybe floating image widgets.
20160911 03:11:56< vultraz> right now widgets can only be used in a dialog
20160911 03:11:59< celmin> Not sure how the map would be handled though.
20160911 03:12:04< celmin> I'm not so sure about that.
20160911 03:12:14< celmin> What's to prevent you from manually calling place, etc?
20160911 03:12:22< celmin> And manually propagating events to them?
20160911 03:12:34< celmin> Not entirely sure how it would work, but it seems possible to me.
20160911 03:12:42 * vultraz shrugs
20160911 03:13:19< celmin> Looks like you're right about the storyscreen though: "namespace gui { class button; }" tells it all.
20160911 03:13:45-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160911 03:13:51< celmin> Maybe the storyscreen could serve as a test case for floating GUI2 widgets.
20160911 03:14:02< vultraz> why can't it be a dialog?
20160911 03:14:15< vultraz> I was thinking a dialog with a multipage widget
20160911 03:14:18< celmin> Part of the reason I think it's possible is because we already have floating widgets.
20160911 03:14:18< vultraz> one page per screen
20160911 03:14:26< celmin> Sure, the storyscreen could be a dialog.
20160911 03:14:36< celmin> I mean floating GUI2 widgets.
20160911 03:14:41< celmin> Because window is a widget.
20160911 03:14:46< vultraz> still need to figure out how to give the text panel different positions on a different page
20160911 03:15:00< celmin> Huh?
20160911 03:15:02< vultraz> right now pages are always the same
20160911 03:15:14< celmin> Yes, that's the point of a multipage widget.
20160911 03:15:18< vultraz> celmin: you can set the story text to appear at the top, bottom, or middle..
20160911 03:15:23< celmin> Ah.
20160911 03:15:27< vultraz> need to figure out how to control that on a page-basis
20160911 03:15:27< celmin> How?
20160911 03:15:33< vultraz> there's a wml key
20160911 03:15:39< celmin> I didn't know this.
20160911 03:15:54< vultraz> why don't we just have a set_position key..
20160911 03:15:58< vultraz> function
20160911 03:15:59< celmin> A what now.
20160911 03:16:11< vultraz> some way to set a widget's position
20160911 03:16:15< celmin> Uhh. We do?
20160911 03:16:19< celmin> Obviously.
20160911 03:16:51< vultraz> ok, you tell me how we could programically move a panel to the center of the screen
20160911 03:16:54< celmin> I'm not sure whether it's set_origin or place or some combination of the two, but the layout algorithms rely on this to work.
20160911 03:17:22< celmin> Maybe we could do the storyscreen as a dialog pair.
20160911 03:17:34< celmin> Make the background be a regular dialog.
20160911 03:17:44< celmin> And implement the text as a popup (like the debug clock).
20160911 03:17:54< celmin> Not sure exactly how popups work, mind you.
20160911 03:18:30< celmin> It seems like they're non-modal?
20160911 03:18:42< vultraz> yeah
20160911 03:18:59< celmin> But if you want to try manually placing a panel each time the page changes, then I won't try to stop you.
20160911 03:21:05< vultraz> btw
20160911 03:21:13< vultraz> i have an idea how to do the About dialog
20160911 03:21:15< vultraz> in gui2
20160911 03:21:21< celmin> You mean Credits?
20160911 03:21:24< vultraz> yes
20160911 03:21:29< celmin> What's the issue?
20160911 03:21:32-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160911 03:21:33< celmin> Scrolling text?
20160911 03:21:37< vultraz> text scrolling
20160911 03:21:43< vultraz> what if we have scrollbar panel
20160911 03:21:46< vultraz> but no scrollbar
20160911 03:21:52< vultraz> and call scroll() on a timer?
20160911 03:22:00< celmin> A solution to this would also solve my issues with the menus.
20160911 03:22:05< celmin> So I think this is a great idea.
20160911 03:22:06< vultraz> (obviously we'd need your menu code for this)
20160911 03:22:16< celmin> Well, we wouldn't need my menu code for it.
20160911 03:22:28< celmin> Rather, my menu code and your idea have a commen prerequisite.
20160911 03:23:01< mattsc> celmin, vultraz: loadscreen takes on the order of a second, possibly less, both on initial start up and on pressing f5.
20160911 03:23:04< celmin> Basically: Refactor scrollbar container so that it can operate correctly if the scrollbar does not exist.
20160911 03:23:13< vultraz> yes
20160911 03:23:21< mattsc> But it’s pretty much the same in 1.13.5 already.
20160911 03:23:46< celmin> So it's probably a result of the new loading screen rather than the canvas changes.
20160911 03:23:47< mattsc> The difference might be that, except for my own, I recently deleted all other campaigns of my 1.13 installation.
20160911 03:24:06< celmin> Ah, that could also make a difference.
20160911 03:24:07< vultraz> celmin: well, the canvas changes help :P
20160911 03:24:11< mattsc> So that’s maybe why it seems fast all of a sudden.
20160911 03:24:20< celmin> If there's less to load, of course it would be faster.
20160911 03:24:32< celmin> (When you say "all other campaigns" are you including mainline?)
20160911 03:24:33< mattsc> … and why I had no memory of when it changed  :P
20160911 03:24:48< mattsc> No, sorry, all other UMC stuff.
20160911 03:24:57< mattsc> I kept all the mainline campaigns.
20160911 03:26:27< tad_> OK. What am I missing about [filter_location] and radius? Zookeeper said it should work but I've never been able to get it to work the way he says. I end up doing a filter_condition and have_location with a bunch of junk to get it to tell when a unit is within a radius of a tile location
20160911 03:26:38< mattsc> Except for Archaic Era, for some reason ...
20160911 03:26:56< mattsc> I downloaded that for something … oh, [disable] special example, I think.
20160911 03:26:58< celmin> I suspect XCode 4 has a memory leak or something, because it seems to use more memory if I leave it open for awhile.
20160911 03:26:59< mattsc> Anyways ...
20160911 03:27:24< celmin> tad_: [filter_location] should work within a standard unit filter.
20160911 03:27:30< celmin> I think that's what he's trying to tell you?
20160911 03:28:22< tad_> so [filter]side=1[filter_location]x,y,radius=10,10,4[/filter_location][/filter] ???
20160911 03:28:32< celmin> Yeah, I think that should work.
20160911 03:28:48< celmin> The [filter] matches if the unit's location matches the [filter_location].
20160911 03:29:04< celmin> The full filter syntax is documented BTW: https://wiki.wesnoth.org/StandardUnitFilter
20160911 03:29:09< tad_> Seems odd to filter a filter but ok
20160911 03:29:55< celmin> I think it's partly for unity of syntax (using [filter_location] consistency when a SLF is needed), though that's violated in other places...
20160911 03:30:51< vultraz> celmin: so your problem with the loadscreen stage is that it doesn't set an initial stage label
20160911 03:31:01< tad_> I guess that's where I went wrong. I though [filter_location] was needed when filtering the event, not the [filter].
20160911 03:31:02< vultraz> celmin: and so it defaults to the default 'loading...'
20160911 03:31:04< celmin> The problem in connecting to server, yes.
20160911 03:31:10< celmin> I am aware of this.
20160911 03:31:14< vultraz> one can remove that label, but then you just get a flash of black
20160911 03:31:25< celmin> I don't get why that default is not immediately replaced, though.
20160911 03:31:38< vultraz> because nothing to do so is called in pre_show
20160911 03:32:00< celmin> But the call to progress() is the first thing in the lambda.
20160911 03:32:13< celmin> I tried wrapping the entire call to open_connection in a lambda, but that caused crashes.
20160911 03:33:16< celmin> (If it had worked it would've at least meant it only flashed to Loading once instead of between every stage.
20160911 03:33:16< celmin> (
20160911 03:33:23< celmin> )
20160911 03:34:30< celmin> vultraz: So I think I asked this before, but… when iterating over variations, which do you think should come first? [male], [female], or [variation]?
20160911 03:34:46< vultraz> uhh
20160911 03:34:51< vultraz> in that order
20160911 03:35:12< celmin> 'kay
20160911 03:36:20-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160911 03:38:29< vultraz> i wonder why this panel if combined with spacers causes window borders
20160911 03:38:31< vultraz> there's no need
20160911 03:40:06< vultraz> I think..
20160911 03:40:20< vultraz> maybe the window algorithm doesn't account for right_border etc properly?
20160911 03:40:26< vultraz> in [resolution]....
20160911 03:42:41< tad_> A dumb question before I turn in for the night .. why are we doing all this window widget work in SDL? It seems like re-inventing the wheel. Are there no good packages to do it already? Or is it all just to get a WML-style definition instead of using Qt or something like that?
20160911 03:43:33< vultraz> what do you mean?
20160911 03:43:58< vultraz> i only made a the gui2 canvas drawing primitives use an sdl renderer context instead of manual per-pixel surface manupulation 
20160911 03:44:03< vultraz> manipulation
20160911 03:45:27< tad_> You seem to be working on a lot of low-level stuff. I would expect that to render the map but I'm wondering about the dialogs and popups. Maybe I'm not understanding what you're doing, is all.
20160911 03:45:31< celmin> tad_: This is a very good question, and it mostly boils down to the fact that (primarily) one developer decided to implement the GUI system and we're semi-stuck with it because it's at least as much effort to replace as it is to fix. (Plus the WML-style definition.(
20160911 03:45:38< celmin> ^)
20160911 03:45:53< vultraz> since sdl has drawing functions 
20160911 03:45:56< vultraz> so we used that
20160911 03:46:04< vultraz> instead of reinventing the wheel
20160911 03:46:18< tad_> That's what I was wondering. So it's a question of which wheel to re-invent. OK. Thanks.
20160911 03:47:59< tad_> I feel like I've been a bit of a pain today. Most likely because I was upset with myself for messing up a PR and having to repair it. Anyway, sorry if I have been. Time for me to get some sleep.
20160911 03:49:22-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has left #wesnoth-dev []
20160911 03:50:12< celmin> I think I prefer working on Lua stuff rather than GUI stuff. >_>
20160911 03:50:32< Aginor> celmin: pong
20160911 03:50:45< celmin> vultraz: Still wanting to question Aginor about stuff?
20160911 03:50:46< Aginor> celmin: briefly
20160911 03:50:56< vultraz> ah, Aginor 
20160911 03:52:03< Aginor> indeed, it is I
20160911 03:52:56< vultraz> Aginor: did you read any of the logs or should i explain here?
20160911 03:53:13< celmin> Given that he's here "briefly"...
20160911 03:53:32< vultraz> ok
20160911 03:54:09< Aginor> I looked to see why I was highlighted
20160911 03:54:43< Aginor> I'll go and do a chore or two and you go tell me what you want me to apy attention to in the meanwhile
20160911 03:58:23< vultraz> Aginor: well, yesterday I converted the gui2 canvas to use an sdl renderer context, and used sdl's-built in functionality for lines, rectangles, and circles. This increased performance.  Because of my changes to the canvas, any operations are only drawn on-screen after all the items are processed (SDL_RenderPresent). However, images are still blitted directly to the canvas as they're loaded....
20160911 03:58:25< vultraz> ...I wanted to convert them to the aforementioned behavior, so I tried loading images into textures (SDL_CreateTextureFromSurface) and then using SDL_RenderCopy to pass them to the renderer. That worked, but certain semi-transparent pixels in the images weren't rendered correctly and instead shown completely black. From googling it seemed it might have something to do with premultiplied...
20160911 03:58:26< vultraz> ...alpha (or lack thereof), but I couldn't find anything regarding how to fix this in an SDL_Texture. Bunch of advice on using OGL, but we don't have OGL. :/
20160911 04:00:23< Aginor> ok, we're not really at the the point where I think we can start using textures, and I don't think we should start doing it in some places but not others
20160911 04:00:53< Aginor> generally, our alpha handling is a bit screwy, and I've put some workaround in place
20160911 04:01:26< celmin> Just to be clear, your experimetation with textures is uncommitted, right?
20160911 04:01:36< Aginor> so I'd suggest simply using sdl_blitsurface for now, but make sure to call the wesnoth wrapper
20160911 04:01:49< vultraz> celmin: yes
20160911 04:01:50< Aginor> because we can use the wrapper to convert into textures one day
20160911 04:01:51< celmin> ^+n
20160911 04:02:09< vultraz> it uses blit_surface, yes
20160911 04:02:40< Aginor> good
20160911 04:03:00< vultraz> one of the reasons I considered textures is apparently textures are scale to fit a target rect.. which would mean we wouldn't have to do surface manipulation for stuff like resize_mode = stretch
20160911 04:03:12< Aginor> as for surfaces->textures, I think SDL is already doing that internally
20160911 04:03:20< celmin> Images can't be passed through a SDL_Renderer then?
20160911 04:03:33< vultraz> not that I can see
20160911 04:03:35< Aginor> no, we use the unaccelerated blitting api
20160911 04:03:49< vultraz> (which is shitty :| )
20160911 04:03:52< Aginor> although we actually bootstrap the software rendering api as a part of it
20160911 04:04:00< celmin> So the renderer is only for primitives?
20160911 04:04:01< Aginor> which is same difference
20160911 04:04:18< vultraz> (our sdl wrappers create an *absurd* number of temporary surfaces)
20160911 04:04:39< vultraz> celmin: yes, the renderer is only for primitives 
20160911 04:04:51< Aginor> vultraz: if you want hardware acceleration, put effort into getting rid of the undraw stuff and everything that uses the custom blit function
20160911 04:06:23< vultraz> er, correcting myself from above
20160911 04:06:54< vultraz> the canvas uses sdl_blit (a direct wrapper for SDL_BlitSurface), not blit_surface (the custom blit function)
20160911 04:07:04< vultraz> (why do we even need a wrapper for the former >_> )
20160911 04:07:52< vultraz> Aginor: anyway, I hope you approve of the use of a renderer for the drawing primitives, at least
20160911 04:08:08< vultraz> Aginor: I also attempted to look into that surface blurring issue but got nowhere
20160911 04:08:48< Aginor> vultraz: the wrapper converts between the managed types and the raw sdl types, saving us from raw pointers.
20160911 04:09:13< Aginor> vultraz: it also allows us to do big changes withot changing hunderds of places in the code
20160911 04:09:33< Aginor> vultraz: it depends on how you implemented the renderer
20160911 04:10:01< Aginor> vultraz: I'd rather have you add to the SDL abstraction layer for those drawing primitives than doing it in GUI2
20160911 04:10:19< Aginor> since GUI2 doesn't generally sit right on top of SDL
20160911 04:11:50< vultraz> tcanvas keeps an SDL_Renderer* object that's reassigned with SDL_CreateSoftwareRenderer whenever the canvas is. Then all the "shapes" are run through, drawn (color is set with SDL_SetRenderDrawColor), and then after all that is done, SDL_RenderPresent is called.
20160911 04:12:42< Aginor> mmm
20160911 04:12:48< Aginor> that really breaks the abstraction
20160911 04:12:56< Aginor> I'd rather you didn't do it that way
20160911 04:13:00< vultraz> as I mentioned above, I've seen a noticeable improvement in performance.
20160911 04:13:13< vultraz> gui2 dialogs open slightly faster
20160911 04:13:22< celmin> Just for the record, this portion is committed.
20160911 04:13:27< vultraz> yes
20160911 04:13:32< vultraz> it is committed
20160911 04:13:34< Aginor> have a look at how it's already done in sdl_window, and if you're doing to do this, add the primitives to the video layer
20160911 04:13:46< Aginor> and there should only ever be ONE renderer
20160911 04:14:04< vultraz> But the other renderer is a window renderer :/
20160911 04:14:06< Aginor> that renderer is already created and managed elsewhere, so go find it, use it, abstract it
20160911 04:14:27< Aginor> but do not have GUI2 handle this as well or I will be very disappointed
20160911 04:15:35< vultraz> I thought the point of SDL_CreateSoftwareRenderer was that it can modify a surface
20160911 04:15:41< vultraz> SDL_SetRenderTarget only works on textures
20160911 04:16:07< Aginor> vultraz: if you make any of these changes, please do not commit them to master, I want a chance to review before they go in
20160911 04:16:41< Aginor> and you're not arguing about the same thing as I am, I'm arguing about the separation of concerns within the wesnoth architecture
20160911 04:16:53< Aginor> s/arguing/discussing/
20160911 04:17:26< celmin> You probably should use branches more, admittedly.
20160911 04:17:29< vultraz> well.. yes... but.. I don't see how this could be abstracted in the video class.
20160911 04:17:49< Aginor> have you looked at it and then also at the sdl window class?
20160911 04:17:51< celmin> I'd probably say it should be abstracted in sdl_surface? Not 100% sure.
20160911 04:18:04< vultraz> I have looked at it.
20160911 04:18:05 * celmin should maybe use branches a bit more too.
20160911 04:19:43< Aginor> vultraz: ok. Wrap that renderer properly and expose it, or leave it tied to the window class. Make cvideo (2?) expose the drawing primities that leverage the existing renderer
20160911 04:19:58< vultraz> where I'm confused is that, again, SDL_SetRenderTarget takes a texture. I'd think one would need that if I uses the window renderer to point the output to the canvas. Using SDL_CreateSoftwareRenderer allowed me to draw onto the canvas, which is a surface.
20160911 04:20:34< vultraz> *how* do I leverage the existing renderer to draw onto the canvas surface.
20160911 04:20:44< Aginor> why do you need a texture to draw a line/circle/square?
20160911 04:20:58< vultraz> I do not
20160911 04:21:02< vultraz> You're missing my point
20160911 04:21:06< celmin> I think the issue here can be boiled down to "vultraz does not understand SDL".
20160911 04:21:12< vultraz> :|
20160911 04:21:20< celmin> Why are you looking at SDL_SetRenderTarget if it requires a texture?
20160911 04:21:25 * celmin admittedly does not understand SDL either.
20160911 04:21:26< Aginor> no, I think the issue is not that
20160911 04:21:41< Aginor> I think the issue here is that I don't understand what vultraz is trying to tell me
20160911 04:21:45< celmin> Well, maybe.
20160911 04:21:52< Aginor> so we are talking past each other
20160911 04:22:04< vultraz> SDL_CreateSoftwareRenderer creates a renderer that works with the provided surface.
20160911 04:22:05< celmin> Yeah, okay, that makes sense.
20160911 04:22:22< Aginor> anyway, I need to get going
20160911 04:22:31< Aginor> talk to you laters
20160911 04:22:37< vultraz> So, I use the SDL_Render* functions, followed by SDL_RenderPresent, and it draws to the surface. In this case, the canvas
20160911 04:22:47< Aginor> but I reiterate, please don't put sdl primitives into gui2
20160911 04:23:00< celmin> I'm not sure if that's a request to revert or not.
20160911 04:23:21< vultraz> The *existing* SDL renderer is a window renderer. *How do I use the existing renderer to draw on the surface "canvas"?*
20160911 04:23:27< celmin> Though personally I'm in favour of (at least temporarily) reverting since it appears to have caused issues for me (and no-one else apparently).
20160911 04:23:42< Aginor> it's a request to not do bad things to the architecture, follow the existing design principles and keep the separation of concern between the different subsystems withing the game
20160911 04:24:02< celmin> Right, but the point here is that he already did it and committed it, so should we revert it temporarily or just fix it.
20160911 04:24:04< Aginor> vultraz: you never stated that initially.
20160911 04:24:15< vultraz> I.. did :|
20160911 04:24:23< vultraz> unless we're misunderstanding each other
20160911 04:25:09< Aginor> I just reread your statements from above, and I still don't see any mention of rendering to a surface
20160911 04:25:39< Aginor> sdl_surface is probably a good place to add this functionality to though
20160911 04:25:54< vultraz> ok, I perhaps wasn't clear.
20160911 04:26:04< Aginor> not inside gui2.
20160911 04:26:19< celmin> I'm not sure if it's because I already knew what this was about, but it was clear to me...
20160911 04:26:31< Aginor> if you committed it on master, I *strongly* suggest you revert, move it to a branch and fix it up there
20160911 04:26:35< celmin> And scrolling up, I do see the word "surface" a couple of times.
20160911 04:26:52< vultraz> (as for celmin's question, why am I looking at SDL_SetRenderTarget, it's because that seems to be a function that would do what I want - ie, pointing the renderer at a target - BUT that target needs to be a texture, not a surface)
20160911 04:27:45< Aginor> yes, you need to render to a texture and then use sdl_rendercopy
20160911 04:27:49< Aginor> which is dog slow
20160911 04:28:18< celmin> Is that slower than rendering directly to the surface with a software renderer?
20160911 04:28:36< Aginor> yes
20160911 04:28:44< Aginor> you'll have more copies of the data
20160911 04:29:09< Aginor> in an accelerated context you'll also be shipping the data between the video mem and ram
20160911 04:29:22< vultraz> Aginor maintains that only *one* renderer should exist, meaning one cannot use SDL_CreateSoftwareRenderer. As such, I'm asking him how he intends to make the window renderer draw on a surface. He now says SDL_RenderCopy would be needed, which he also says is slow.
20160911 04:29:33< vultraz> So then, what is to be done :|
20160911 04:30:12< Aginor> vultraz: I'm objecting to the usage of multiple renderers to the screen, which is what I thought you were talking about
20160911 04:30:50< vultraz> I'm all for fixing up in a branch, but I'd rather *not* revert since this results in a *noticeable* performance increase.
20160911 04:30:59< vultraz> Aginor: no, I am not creating multiple window renderers.
20160911 04:31:01< Aginor> quantify it
20160911 04:31:58< Aginor> anyway, I'm going to disappear
20160911 04:32:02< vultraz> I cannot give you hard numbers
20160911 04:32:10< vultraz> Just that it feels snappier.
20160911 04:32:21< Aginor> I'm getting rather aggrevated and that's not going to help anyone
20160911 04:32:33< Aginor> well, if it feels better, then do whatever you like
20160911 04:32:38< vultraz> :/
20160911 04:32:45< vultraz> Perhaps let's pick this up some other time.
20160911 04:33:01< Aginor> I like the feel of green backgrounds so maybe I should go and commit a change to do that
20160911 04:33:18< vultraz> ...
20160911 04:33:28< celmin> If you're cleaning it up in a branch anyway, I'd rather revert.
20160911 04:33:40< Aginor> not that I'm going to
20160911 04:33:48 * Aginor disappears
20160911 04:34:02< vultraz> Can we drop this discussion for now? We all have other things to work on.
20160911 04:34:06< vultraz> Let's pick it up next week.
20160911 04:35:00< celmin> Also, if Wesnoth is going to be broken for a week, it won't make me happy.
20160911 04:35:12< vultraz> See if updating to 2.0.4 fixes it
20160911 04:35:17< vultraz> That's a very useful think to know.
20160911 04:35:19< celmin> I'm planning to.
20160911 04:39:55-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160911 04:40:44-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160911 04:40:48-!- VultCave is now known as vultraz
20160911 04:46:46-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20160911 04:57:20< shadowm> celmin: You received the message from Dave in the end, yes?
20160911 04:57:25< celmin> Yeah.
20160911 04:57:41< celmin> Why do you ask?
20160911 04:59:35< shadowm> I noticed the other day you said you hadn't gotten a message even though me and at least one other person already had by that point, so I just wanted to make sure we weren't getting into a situation where one of the nominees would get dropped because the person in charge of the process didn't send him the confirmation message in time.
20160911 05:00:11< celmin> Okay.
20160911 05:01:22< vultraz> I ensured dave re-sent it to celmin yesterday
20160911 05:06:25< vultraz> hmmm
20160911 05:06:42-!- Kwandulin [~Miranda@p200300760F2C71B85017EE502311E351.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160911 05:06:44< vultraz> I think maybe.. panels don't behave correctly when calculating window size..
20160911 05:07:28< vultraz> but no, that doesn't make sense
20160911 05:07:34< vultraz> toggle_panels are also panels..
20160911 05:07:39< vultraz> so what's the issue..
20160911 05:08:14< celmin> So toggle_panel extends panel?
20160911 05:08:50< vultraz> hm, no..
20160911 05:09:03< vultraz> wait
20160911 05:09:04< vultraz> yes
20160911 05:09:42< vultraz> OH
20160911 05:09:43< vultraz> wait
20160911 05:09:47< vultraz> I understand now
20160911 05:09:57< vultraz> I forgot this is a stacked widget
20160911 05:10:14< vultraz> meaning the size of OTHER pages is considered
20160911 05:10:17< vultraz> yeeees.
20160911 05:10:51< celmin> Yeah, I think that's somehow also the problem with the 1024x768 version.
20160911 05:13:36< vultraz> I have fixed it :D
20160911 05:14:54< vultraz> celmin: I moved the setting page into a [scrollbar_panel]
20160911 05:15:02< celmin> Oh my...
20160911 05:15:29< celmin> I wonder if that'll work for the lower-res versions though, both of which still have nontrivial problems.
20160911 05:15:57< celmin> I wonder, is there any optional stuff that could be omitted altogether at 800x600?
20160911 05:16:20< vultraz> not really..
20160911 05:16:26< irker886> wesnoth: Ignacio R. Morelle wesnoth:master 2483fc80e4a5 / SConstruct: scons: Don't pass a C++ compiler flag to C compilers https://github.com/wesnoth/wesnoth/commit/2483fc80e4a57f7cdc0ff9fbeaed08d85699d0d6
20160911 05:16:33< celmin> Oh, thanks.
20160911 05:16:38< vultraz> \o/
20160911 05:16:45< celmin> I was going to look into that but hadn't yet gotten to it.
20160911 05:16:51< celmin> Now all that's left is the bad_alloc.
20160911 05:16:55< shadowm> What, was this a problem in the travis env well?
20160911 05:16:58< shadowm> *env as
20160911 05:17:03< celmin> Yes.
20160911 05:17:17< shadowm> Then why didn't anyone poke loonycyborg earlier or something?
20160911 05:17:26< celmin> Good question.
20160911 05:17:37< celmin> I even considered it but didn't for some reason.
20160911 05:18:00< vultraz> blah
20160911 05:18:03< shadowm> The commit has been there for 4 days. Travis builds and tests shouldn't be broken for longer than a single commit.
20160911 05:18:10< vultraz> i need a new mouse desperately 
20160911 05:18:26< shadowm> I see 82 commits since then.
20160911 05:18:33< celmin> I don't think I realized it was a problem until… yesterday? Mainly because there were multiple issues in the Travis build.
20160911 05:18:40< celmin> I've solved some of them since then.
20160911 05:18:45< shadowm> Well, 81 if you exclude my own.
20160911 05:19:06< celmin> I guess I'll go ahead and disable the title screen test for now.
20160911 05:20:16< vultraz> now the left mouse button is barely working
20160911 05:20:22< celmin> Fun.
20160911 05:20:39< celmin> That happened to me awhile back with my logitech mouse. Then someone got me a new one.
20160911 05:21:01< vultraz> yeah, will get a new one soon
20160911 05:21:28< celmin> Oddly enough, the new one is almost the same model but with the addition of side arrow buttons (which I don't really use).
20160911 05:22:40< irker886> wesnoth: Celtic Minstrel wesnoth:master 982aea6a02f1 / src/tests/gui/test_gui2.cpp: Disable title screen unit test https://github.com/wesnoth/wesnoth/commit/982aea6a02f128b9d7de5d5dfab9fef56ef1c916
20160911 05:22:56< celmin> Hopefully that'll finally fix the build.
20160911 05:23:30< celmin> ie, hopefully there are no other issues lurking
20160911 05:25:11< celmin> Travis has five builds still running/pending.
20160911 05:31:44< celmin> And, oddly, the first of those hasn't even started yet?
20160911 05:33:00-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160911 05:34:16< vultraz> im going to see if i can throw a gui2 credits screen together
20160911 05:37:00-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160911 05:38:05< celmin> Seems like should be pretty easy.
20160911 05:38:18< celmin> Might have to make do with it having a scrollbar for now, though.
20160911 05:38:42< VultCave> im going to see if i can throw a gui2 credits screen together
20160911 05:38:50< VultCave> yes
20160911 05:39:12-!- vultraz [~chatzilla@124.109.10.167] has quit [Ping timeout: 276 seconds]
20160911 05:39:24-!- VultCave is now known as vultraz
20160911 05:39:50-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160911 05:39:50-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160911 05:42:15< vultraz> hmm
20160911 05:42:26< vultraz> about stores the text in a vector of strings
20160911 05:42:42< vultraz> but gui2 would need it in... one giant-ass string p_p
20160911 05:51:31< vultraz> huh..
20160911 05:51:41< vultraz> the background image can be a comma-separated list?
20160911 05:51:44< vultraz> wonder when it changes
20160911 06:01:25< celmin> Well, you could use a listbox to maintain the vectoriness.
20160911 06:01:32< celmin> If you wanted to
20160911 06:01:35< celmin> Just saying.
20160911 06:01:49< vultraz> uh
20160911 06:01:50< vultraz> no
20160911 06:01:59< vultraz> we do not have toggle panel-less lists
20160911 06:03:23 * celmin shrug
20160911 06:05:00 * vultraz wishes border_size could be specified differently for each of the sides..
20160911 06:05:14< vultraz> that would simply code in various places where we use spacers
20160911 06:05:49< celmin> You could dynamically build a single-column grid.
20160911 06:06:07< vultraz> ..what?
20160911 06:06:58< celmin> I'm not sure whether a grid's row and column count are fixed after construction.
20160911 06:07:11< vultraz> I..what?
20160911 06:07:29< celmin> But even if they are, you could convert the [about] config to a [grid] config and pass it through the grid builder to get a grid.
20160911 06:07:47< celmin> If the grid's size is not fixed, you could construct an empty grid and add items.
20160911 06:07:59< celmin> I'm just pointing out that there are options other than putting all the text in one string.
20160911 06:08:23< celmin> Note that I'm talking about doing all this in the C++, not in the WML, just in case that was unclear.
20160911 06:09:14< celmin> Are you still confused?
20160911 06:10:11< celmin> I'm not really sure if what I'm proposing is better or worse than stuffing it into a single label, though.
20160911 06:10:19-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160911 06:10:30< celmin> Aw, you missed stuff, huh.
20160911 06:10:56< celmin> It feels better stylistically, but it probably also means 100 text surfaces instead of 1.
20160911 06:11:05< VultCave> celmin: why would I need such a thing?
20160911 06:11:33< celmin> I don't know whether you need it. I'm just trying to point out that your assumptions are faulty.
20160911 06:11:48< celmin> Like this one:
20160911 06:11:49< celmin> [Sep 11@01:42:43am] vultraz: but gui2 would need it in... one giant-ass string p_p
20160911 06:12:13< celmin> If you don't want it in one giant string, of course there are other options.
20160911 06:12:21-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 276 seconds]
20160911 06:12:23< celmin> If you also don't want it in a listbox, there are still other options.
20160911 06:12:27-!- VultCave is now known as vultraz
20160911 06:12:41< vultraz> hmm
20160911 06:12:44< vultraz> this is odd
20160911 06:12:53< vultraz> the text displayed when i forgot the newline characters
20160911 06:12:56< vultraz> now it doesn't display :/
20160911 06:13:01< vultraz> with them.
20160911 06:13:07< celmin> Fun...
20160911 06:13:16< vultraz> though let me try converting the formatting and then we'll see
20160911 06:13:25< vultraz> (the text has + and - in front..)
20160911 06:13:34< celmin> That probably wouldn't be it.
20160911 06:14:03< celmin> Just to be clear, do you dislike the idea of stuffing the entire credits into a single string?
20160911 06:14:10< vultraz> not really
20160911 06:14:24< celmin> So what does p_p really mean then?
20160911 06:14:45< vultraz> surprise
20160911 06:15:00< vultraz> i forgt, does string have find?
20160911 06:15:05< celmin> Huh. I would have never guessed that.
20160911 06:15:12< celmin> String has an overabundance of finds.
20160911 06:15:27< celmin> What exactly do you need?
20160911 06:15:37< vultraz> if first character is something
20160911 06:15:53< celmin> Uhh, str[0]?
20160911 06:15:58< vultraz> got it
20160911 06:16:03< celmin> You don't need find to test the first character.
20160911 06:16:14< celmin> str[0] == '+'
20160911 06:16:31< celmin> (Won't work for Unicode characters, mind you.)
20160911 06:16:39< vultraz> and then uh..
20160911 06:16:45< vultraz> how would i delete that character
20160911 06:16:53< vultraz> or..
20160911 06:16:54< vultraz> hm.
20160911 06:16:59< celmin> .erase(0) I think would do it.
20160911 06:17:03< vultraz> get the string from str[1] to end
20160911 06:17:10< celmin> .substr(1)
20160911 06:18:30< vultraz> ill need to get rid of these magic symbols later
20160911 06:18:47< vultraz> ah, NOW the text shows :D
20160911 06:18:54< vultraz> must've been something with those symbols
20160911 06:19:17-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160911 06:19:24< celmin> BTW, have you reviewed the credits yet to see if anyone needs to be moved from "misc" to elsewhere?
20160911 06:19:56< vultraz> not yet
20160911 06:22:51< celmin> I wonder why Travis is not building.
20160911 06:23:53< vultraz> ok what
20160911 06:24:09< vultraz> if I change the SIZE of scroll label, text doesn't show
20160911 06:24:13< celmin> Ah, could it be that tad's PRs are taking priority...?
20160911 06:24:21< celmin> Why do you need to change the size?
20160911 06:24:27< vultraz> if I remove the use of <small>, the label doesn't show
20160911 06:24:37< vultraz> is there some max size or something p_p
20160911 06:24:46< celmin> No idea.
20160911 06:25:37< celmin> There is a limit on the size of std::string, but I highly doubt you'd hit it unless you stuffed a while novel in there. Maybe not even then.
20160911 06:25:58< celmin> (That's why there's a max_size method or some such.)
20160911 06:26:28< celmin> ^whole
20160911 06:26:52< celmin> If you want to know whether scroll_label has a max size, you'll have to scan the code.
20160911 06:27:08< celmin> (And just to be sure, probably tcontrol and twidget too.)
20160911 06:28:43< celmin> Seems I was right about Travis. I guess there's a max number of jobs, and right now they're all being consumed by tad's PRs.
20160911 06:28:52< celmin> I guess we just need to wait it out.
20160911 06:31:08< vultraz> i see nothing about a max..
20160911 06:32:18< celmin> Then maybe it's getting so big that you hit placement failure?
20160911 06:32:42< celmin> It used to assert, now it just doesn't bother to place the widget and thus it doesn't show up.
20160911 06:46:32-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160911 06:47:41-!- celticminstrel is now known as celmin|sleep
20160911 06:49:15< vultraz> celmin|sleep: where was this assert again?
20160911 06:49:24-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160911 06:54:19-!- Kwandulin [~Miranda@p200300760F2C71B85017EE502311E351.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20160911 06:55:15-!- vultraz [~chatzilla@124.109.10.167] has quit [Ping timeout: 276 seconds]
20160911 06:55:17-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160911 06:55:39-!- VultCave is now known as vultraz
20160911 06:57:23-!- Kwandulin [~Miranda@p200300760F2C71125017EE502311E351.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160911 07:02:57< vultraz> this is weird
20160911 07:03:00< vultraz> the text is there..
20160911 07:03:09< vultraz> I can print it to stderr with label()
20160911 07:03:19-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160911 07:03:19-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160911 07:06:04< vultraz> it's like..
20160911 07:06:28< vultraz> if the text is ANYTHING but either wrapped in <small> or <big> and the widget uses definition = "default", it won't show
20160911 07:06:32< vultraz> what the hell?
20160911 07:06:52-!- celmin|sleep [~celmin@unaffiliated/celticminstrel] has quit [Ping timeout: 265 seconds]
20160911 07:11:29< vultraz> well, it works with <span size = 'smaller'>
20160911 07:11:32< vultraz> but...
20160911 07:11:35< vultraz> jesus, what the hell is going on here :|
20160911 07:12:20-!- Ivanovic_ [~ivanovic@p579FB681.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160911 07:12:45-!- Ivanovic_ [~ivanovic@p579FB681.dip0.t-ipconnect.de] has quit [Changing host]
20160911 07:12:45-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160911 07:13:20-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 250 seconds]
20160911 07:14:26-!- Ivanovic_ is now known as Ivanovic
20160911 07:16:02< vultraz> the text is there! it registers in the widget! so why doesn't it draw!
20160911 07:18:39< vultraz> in fact, the scrollbar even allocates *space* for it!
20160911 07:19:56< vultraz> the text even displays if I *don't* use the <small> tag and use the default_small label definiton
20160911 07:23:19-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160911 07:25:09-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 276 seconds]
20160911 07:25:13-!- VultCave is now known as vultraz
20160911 07:26:50-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160911 07:26:50-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160911 07:33:11-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 07:33:12< travis-ci> wesnoth/wesnoth#10850 (master - 659e482 : Charles Dang): The build failed.
20160911 07:33:12< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159042474
20160911 07:33:12-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 07:36:41-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160911 07:36:52-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160911 07:37:03-!- VultCave is now known as vultraz
20160911 07:39:59-!- vultraz [~chatzilla@124.109.10.167] has quit [Read error: Connection reset by peer]
20160911 07:40:25-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160911 07:43:05-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160911 07:46:25-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20160911 07:46:25-!- wedge010 is now known as wedge009
20160911 07:55:59< irker886> wesnoth: Charles Dang wesnoth:master 838c0e0a094d / data/gui/ (3 files in 2 dirs): Renamed title_screen panel definition and added a blur-less version https://github.com/wesnoth/wesnoth/commit/838c0e0a094d5fefe402151d778fb8cd2ee5f8dc
20160911 07:56:02< irker886> wesnoth: Charles Dang wesnoth:master 865f7262f925 / data/gui/widget/scroll_label_default.cfg: Added large scroll label definition https://github.com/wesnoth/wesnoth/commit/865f7262f92574fa794c30558ec6d21095bc16a3
20160911 07:56:05< irker886> wesnoth: Charles Dang wesnoth:master d0cae514ff0c / / (8 files in 5 dirs): Added basic GUI2 end credits dialog (incomplete) https://github.com/wesnoth/wesnoth/commit/d0cae514ff0cd4672a70b9e2925329fcd34db3be
20160911 08:24:15-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160911 08:34:08-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160911 08:51:43-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160911 09:05:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160911 09:11:58-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Ping timeout: 244 seconds]
20160911 10:18:29-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160911 10:21:57-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 276 seconds]
20160911 10:25:30-!- mjs-de [~mjs-de@x4db6b11d.dyn.telefonica.de] has joined #wesnoth-dev
20160911 10:29:05-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160911 10:38:41< irker886> wesnoth: Charles Dang wesnoth:master b789d8db1f65 / src/gui/dialogs/ (end_credits.cpp end_credits.hpp): End Credits: implements automatic (and slllooowww) scrolling https://github.com/wesnoth/wesnoth/commit/b789d8db1f656487b4d744bfd52fe706d2922e2d
20160911 10:40:53< vultraz> ITEM_FORWARD *really* is useless
20160911 10:41:32< vultraz> what we need is something that says "within the provided number of ms, move the scrollbar forward n"
20160911 10:41:34-!- Kwandulin [~Miranda@p200300760F2C71125017EE502311E351.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160911 10:42:36< vultraz> I'm not entirely sure how one would implement such a thing
20160911 11:09:01< irker886> wesnoth: Charles Dang wesnoth:master d2f31787dde4 / src/gui/dialogs/ (end_credits.cpp end_credits.hpp): End Credits: added some (as yet) unused code for scroll speed control and increa https://github.com/wesnoth/wesnoth/commit/d2f31787dde48fdb9218baed2a1397f8dfda66f9
20160911 11:10:26-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160911 11:20:04< irker886> wesnoth: Charles Dang wesnoth:master 4e21ae709e59 / src/gui/widgets/ (scroll_label.cpp scroll_label.hpp): Scroll Labels: allow setting text alignment https://github.com/wesnoth/wesnoth/commit/4e21ae709e59ea0ef693c7f3230d00fed0e56c0b
20160911 11:20:07< irker886> wesnoth: Charles Dang wesnoth:master d822e672bad4 / data/gui/window/end_credits.cfg: End Credits: centered text https://github.com/wesnoth/wesnoth/commit/d822e672bad43eeecec1b63cb476fd51b1e30ba4
20160911 11:21:09 * vultraz makes note at some point to refactor how scroll labels handle their label child
20160911 11:26:29-!- Kwandulin [~Miranda@p200300760F2C711231E86854C3451396.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160911 11:29:30-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160911 11:32:03-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 11:32:04< travis-ci> wesnoth/wesnoth#10861 (master - 9232b5b : Celtic Minstrel): The build has errored.
20160911 11:32:04< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159055253
20160911 11:32:04-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 11:34:46-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 11:35:53-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160911 11:36:05< irker886> wesnoth: Charles Dang wesnoth:master 20831bf8538a / data/gui/schema.cfg: Updated schema for 4e21ae709e59 https://github.com/wesnoth/wesnoth/commit/20831bf8538a3a081eae6ae244b04cfc33fed94d
20160911 11:37:19< vultraz> Still cannot figure out why the label won't draw if the text gets above a certain length or siz
20160911 11:37:20< vultraz> e
20160911 11:38:04< vultraz> i checked, and it's not that it doesn't fit on the canvas..
20160911 11:38:11< vultraz> something else is going on :/
20160911 11:40:14-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160911 11:40:34< irker886> wesnoth: Gregory A Lundberg wesnoth:master 07d609632c40 / src/savegame.cpp: Fix bug: Crash loading replay https://github.com/wesnoth/wesnoth/commit/07d609632c40096e1a547f3d3b3af27ca4e1b206
20160911 11:40:36< irker886> wesnoth: gfgtdf wesnoth:master 9915a10b6759 / src/savegame.cpp: Merge pull request #771 from GregoryLundberg/GL_fix_load_replay https://github.com/wesnoth/wesnoth/commit/9915a10b6759588bbaafe25a7f9c8f10c3c5eeec
20160911 11:42:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160911 11:42:23< vultraz> I wonder if it has to do with the scrollbar simply running out of space :P
20160911 11:47:27-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160911 11:48:00< vultraz> no, that seems fine..
20160911 11:50:16< vultraz> but it is indeed something with length
20160911 11:50:37< vultraz> if i remove a large portion of about.cfg, it works with the bigger size
20160911 12:01:54-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20160911 12:04:18-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160911 12:13:29-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 12:15:16< irker886> wesnoth: Charles Dang wesnoth:master 8604d811e071 / src/gui/dialogs/end_credits.cpp: End Credits: hack to hide the scrollbar https://github.com/wesnoth/wesnoth/commit/8604d811e071a2551e8e2c17cf85eb97fa81e5ed
20160911 12:16:21< vultraz> celticminstrel ^ you might be interested. as i said in the comment, that should likely become an ALWAYS_HIDDEN scrollbar mode or something. though, hidden still reserves space, so perhaps it doesn't help for your menu problem..
20160911 12:16:56< vultraz> (oh, bah, that contained a line I didn't want)
20160911 12:18:50< vultraz> (the commit, that is)
20160911 12:18:54< vultraz> oh well
20160911 12:19:36< vultraz> .. huh.. odd..
20160911 12:19:55-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 12:19:56< travis-ci> wesnoth/wesnoth#10863 (master - 9c239d1 : Charles Dang): The build is still failing.
20160911 12:19:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159060283
20160911 12:19:56-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 12:20:49< gfgtdf> vultraz: the end criedits scrolling is now gui2  ?
20160911 12:21:37< vultraz> gfgtdf: yes, but i still need to refactor the parsing of the configs and for some reason there's a really weird issue where if the font is too large or something the text won't show at all
20160911 12:22:23< vultraz> gfgtdf: if you want to see it enable the line about.cpp:234
20160911 12:22:30< vultraz> (it = the dialog)
20160911 12:24:04< gfgtdf> ok
20160911 12:24:40< vultraz> can't really make it default until I'm sure it will always display text
20160911 12:24:44< vultraz> which it doesn't :/
20160911 12:25:45< vultraz> and it's really odd because now it seems non-deterministic 
20160911 12:26:02< vultraz> ie, sometimes the same setting will result in it showing, sometimes not
20160911 12:26:47< vultraz> I'm thinking now maybe it has to do with the static data storage or something..
20160911 12:28:25< vultraz> what that should have to do with the size of the text i have no idea
20160911 12:28:36< vultraz> but i have confirmed in all places that the text fits on the canvas..
20160911 12:28:38< vultraz> so..
20160911 12:32:44-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160911 12:46:28< irker886> wesnoth: Charles Dang wesnoth:master 352e5f2600b0 / src/gui/dialogs/ (end_credits.cpp end_credits.hpp): End Credits: delay slightly before beginning scroll https://github.com/wesnoth/wesnoth/commit/352e5f2600b02937ab685d45845469cb30c8b3da
20160911 12:47:58< vultraz> hm
20160911 12:48:26< vultraz> it occurs to me that since one has the scrollwheel, perhaps the up/down speed controls aren't needed
20160911 12:48:41< vultraz> and there's no need to implement them
20160911 12:49:04< vultraz> still need to implement image switching, though
20160911 12:50:36< vultraz> in the old dialog, it looked like they were bound to distance scrolled
20160911 12:51:04< vultraz> I wonder if I should replicate that
20160911 12:51:13< vultraz> or put switching on a timer
20160911 12:52:31< vultraz> celticminstrel: don't forget to update XCode
20160911 13:01:37-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has joined #wesnoth-dev
20160911 13:01:37-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has quit [Changing host]
20160911 13:01:37-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20160911 13:01:51< mordante> servus
20160911 13:13:26-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160911 13:14:06-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 13:14:07< travis-ci> wesnoth/wesnoth#10865 (master - 2483fc8 : Ignacio R. Morelle): The build has errored.
20160911 13:14:07< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159071132
20160911 13:14:07-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 13:24:18-!- JyrkiVesterinen [~JyrkiVest@87-92-1-204.bb.dnainternet.fi] has joined #wesnoth-dev
20160911 13:36:33-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 13:36:34< travis-ci> wesnoth/wesnoth#10866 (master - 982aea6 : Celtic Minstrel): The build was fixed.
20160911 13:36:34< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159071520
20160911 13:36:34-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 13:43:35-!- Kwandulin [~Miranda@p200300760F2C711231E86854C3451396.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160911 13:50:42-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160911 14:00:28-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 14:00:29< travis-ci> wesnoth/wesnoth#10867 (master - d0cae51 : Charles Dang): The build was fixed.
20160911 14:00:29< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159082071
20160911 14:00:29-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 14:21:43-!- Kwandulin [~Miranda@p200300760F2C7112706EEA219F756484.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160911 14:27:58-!- travis-ci [~travis-ci@ec2-54-167-205-59.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 14:27:59< travis-ci> wesnoth/wesnoth#10868 (master - b789d8d : Charles Dang): The build was fixed.
20160911 14:27:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159096240
20160911 14:27:59-!- travis-ci [~travis-ci@ec2-54-167-205-59.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 14:32:10-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160911 14:32:12-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 276 seconds]
20160911 14:39:22-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160911 14:44:33-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 244 seconds]
20160911 14:44:33-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20160911 14:50:55-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160911 14:57:57-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 14:57:58< travis-ci> wesnoth/wesnoth#10869 (master - d2f3178 : Charles Dang): The build was fixed.
20160911 14:57:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159099014
20160911 14:57:58-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 15:02:11-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 15:03:44-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160911 15:04:42-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160911 15:12:42-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160911 15:24:11-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 15:24:12< travis-ci> wesnoth/wesnoth#10870 (master - d822e67 : Charles Dang): The build is still failing.
20160911 15:24:12< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159099891
20160911 15:24:12-!- travis-ci [~travis-ci@ec2-54-221-97-112.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 15:25:00-!- Bonobo [~Bonobo@2001:44b8:254:3200:415b:d70:4172:f4c7] has quit [Quit: Leaving]
20160911 15:39:20-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 15:47:11-!- irker886 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160911 15:50:37-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160911 15:51:00-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 15:51:01< travis-ci> wesnoth/wesnoth#10871 (master - 20831bf : Charles Dang): The build passed.
20160911 15:51:01< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159101280
20160911 15:51:01-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 16:17:04-!- travis-ci [~travis-ci@ec2-54-167-205-59.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 16:17:05< travis-ci> wesnoth/wesnoth#10872 (master - 9915a10 : gfgtdf): The build passed.
20160911 16:17:05< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159101775
20160911 16:17:06-!- travis-ci [~travis-ci@ec2-54-167-205-59.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 16:26:32-!- iceiceice [~chris@pool-71-172-187-9.nwrknj.east.verizon.net] has joined #wesnoth-dev
20160911 16:31:49-!- Kwandulin [~Miranda@p200300760F2C7112706EEA219F756484.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160911 16:34:43-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20160911 16:36:08-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160911 16:37:31< celticminstrel> [Sep 11@02:49:15am] vultraz: celmin|sleep: where was this assert again?
20160911 16:37:32< celticminstrel> I have no idea, check git logs for the commit where you removed it.
20160911 16:37:45< celticminstrel> Ah... he's not even here, huh.
20160911 16:38:07-!- iceiceice [~chris@pool-71-172-187-9.nwrknj.east.verizon.net] has quit [Quit: Ex-Chat]
20160911 16:41:24-!- travis-ci [~travis-ci@ec2-54-167-205-59.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 16:41:25< travis-ci> wesnoth/wesnoth#10873 (master - 8604d81 : Charles Dang): The build passed.
20160911 16:41:25< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159105054
20160911 16:41:25-!- travis-ci [~travis-ci@ec2-54-167-205-59.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 16:41:38< celticminstrel> \o/ I guess the build was fixed!
20160911 17:03:13-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160911 17:12:22-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has joined #wesnoth-dev
20160911 17:12:23< travis-ci> wesnoth/wesnoth#10874 (master - 352e5f2 : Charles Dang): The build was fixed.
20160911 17:12:23< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159107879
20160911 17:12:23-!- travis-ci [~travis-ci@ec2-54-198-245-65.compute-1.amazonaws.com] has left #wesnoth-dev []
20160911 17:20:31-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 17:36:24-!- Kwandulin [~Miranda@p200300760F2C7112BC0E050686F26C69.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160911 17:48:01-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160911 17:48:51-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160911 17:48:51-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160911 17:55:46-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 18:11:27-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160911 18:23:58-!- horus2 [~1@79.120.248.57.pool.invitel.hu] has joined #wesnoth-dev
20160911 19:07:16-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160911 19:07:22-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160911 19:13:04-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20160911 19:21:08-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160911 19:21:57-!- matthiaskrgr_ [~username@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20160911 19:21:59-!- matthiaskrgr_ [~username@unaffiliated/matthiaskrgr] has left #wesnoth-dev []
20160911 19:35:59-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160911 19:37:25-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 19:37:34< vultraz> celticminstrel: very important distinction - invisible widgets don't receive events 
20160911 19:37:47< celmin> Why do they need to?
20160911 19:38:12< celmin> Also BTW, the rebuild with SDL 2.0.4 fixed my issues. Not sure whether it was because of SDL 2.0.4 or just because of the clean build, though.
20160911 19:38:44< vultraz> good to know, though.
20160911 19:38:54< vultraz> it means I don't 100% have to revert
20160911 19:40:09< tad_> "error display: Tile at -999,-999 isn't on the map, can't scroll to the tile." Next campaign I want to look at is LoW and right off I get this error. It's caused by the map having no starting locations defined. Is this an error in the engine or are all maps required to have at least a side 1 starting location?
20160911 19:41:57< celmin> Doesn't hurt to revert though if you plan to redo it in a branch anyway.
20160911 19:42:18< celmin> tad_: It shouldn't be required to have starting locations defined, I think.
20160911 19:42:41< tad_> celmin: My bet would be a clean build. I just hit a hard linker failure when Boost updated on Arch today and "make all" fixed it
20160911 19:43:05< tad_> celmin: OK. I will find the error in the engine. Sorta though so but wanted to get a second opinion.
20160911 19:43:17< celmin> Yeah, it could've been just the clean build and not the SDL upgrade. (The issues I got were prior to both, but since upgrading SDL would require a clean build anyway, I did both at once. >_> )
20160911 19:43:58< celmin> tad_: I'm not quite certain it's an error in the engine, it could be something in the side tags; if the leader has no position specified, then it probably checks for that side's starting location? Something like that?
20160911 19:44:11< celmin> But it could be an engine error, I dunno.
20160911 19:44:31< celmin> Maybe we should ask zookeeper as well.
20160911 19:44:37< tad_> The leader has x,y set. I can put a side 1 starting location and (both occurances of) the error goes away.
20160911 19:45:02< tad_> It only honors the leader side 1 x,y  if I remove the spec in the [side]
20160911 19:45:14< celmin> "spec"?
20160911 19:45:52< tad_> specified. If I add side 1 start to the map and remove the x,y from [side] it honors the map. If I just add the start loc to the map it ignored it but the errors go away.
20160911 19:46:08< celmin> Ah, sounds like an engine error then.
20160911 19:46:24< celmin> I don't think it should be checking for locations defined in the map if it does not need them.
20160911 19:47:06< tad_> celmin: OK. I'll find the error and back-trace to where it did the check(s) which it didn't need to do. Strange it flags it twice, too, but 1 fix solves both.
20160911 19:47:12< zookeeper> hmh?
20160911 19:48:43< tad_> zookeeper: I'm "done pending requests" on HttT and DM PRs and starting on LoW and hit an error right off. I'll check 1.12.6 and then find the engine bug flagging the missing side 1 starting locations on the map when we don't need any since all sides specify x,y for all units, including leaders.
20160911 19:49:01< celmin> Mind you, in my personal opinion, it'd be better to use locations defined in the map. However, fabi seems to disagree, and LoW is his campaign IIRC, so I guess it can be left without map-defined locations.
20160911 19:49:53< tad_> celmin: (1) I agree with you about starting locations, (2) I bow to Fabi and Zookeeper, (3) doesn't matter, it's a bug needs swatting
20160911 19:50:21< vultraz> tad_: perhaps LoW is not the best target
20160911 19:50:46< tad_> It's next up on the hit parade and gotta be done sometime.
20160911 19:50:48< celmin> Question!
20160911 19:50:59< vultraz> yes, t'is a bug, but maybe you can tackle... Northern Rebirth? :P *is feeling sadistic* 
20160911 19:51:13< celmin> wesnoth.unit_types is not an array-like table. Should I make #wesnoth.unit_types give its size anyway?
20160911 19:51:15< zookeeper> good luck if you intend on error-fixing LoW (based on what i've heard)
20160911 19:51:20< vultraz> *rubs hands like comic villain* 
20160911 19:51:45< vultraz> celmin: yes
20160911 19:51:51< celmin> zookeeper: I thought all the LoW problems were in multiplayer.
20160911 19:51:58< tad_> Actually, if I skip LoW, Eastern Invasion is where I'd go next. I'm trying to work down the list because that's how new people will probably do it.
20160911 19:52:03< celmin> vultraz: So you don't mind violating the "rule" that # only counts array entries?
20160911 19:52:20< vultraz> what exactly is the table type, anyway
20160911 19:52:24< celmin> Note that defining #wesnoth.unit_types also means defining #u.variations.
20160911 19:52:26< celmin> Huh?
20160911 19:52:33< vultraz> unit_types
20160911 19:52:35< vultraz> what isit
20160911 19:52:57< celmin> It contains every unit type in the game indexed by its ID.
20160911 19:53:17< vultraz> so, map?
20160911 19:53:21< tad_> celmin: having an item count might be nice
20160911 19:53:22< celmin> You could call it that.
20160911 19:53:37< vultraz> item count would be nice
20160911 19:53:41< vultraz> not very useful
20160911 19:53:41< tad_> gtg wife has errands. 
20160911 19:53:45< celmin> tad_: I agree it might be nice, but in Lua # normally only applies to array-like tables, which is why I asked.
20160911 19:53:51-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160911 19:53:52< vultraz> #u.variations would be very useful, though
20160911 19:54:24< tad_> celmin: Then I'd suggest a function/method for all non-array (map?) tables like unit_type
20160911 19:54:32-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160911 19:54:44< celmin> Heh, that'd be handy...
20160911 19:54:57< zookeeper> tad_, celmin, so what was the problem? that you get an error if the map has no starting position, but the leader unit (directly in [side] or not?) has x,y?
20160911 19:55:03< celmin> Actually, I wish Lua provided that natively.
20160911 19:55:29< celmin> zookeeper: Yeah, error if no starting location in map, even though [side] specifies x,y
20160911 19:55:29< vultraz> zookeeper, tad_:  I would say add the starting position to the map
20160911 19:55:48< celmin> I'd agree, but I know fabi doesn't (for some reason).
20160911 19:55:59< vultraz> fabi: why is this
20160911 19:56:00< celmin> That said, it's still a bug.
20160911 19:56:15< celmin> So it needs to be fixed regardless of whether the starting position is added to the map in the end.
20160911 19:56:15< vultraz> inb4 "it's not portable to moonscript"
20160911 19:58:06-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20160911 19:58:08< vultraz> celmin: btw, have you tried the new credits screen?
20160911 19:58:25< celmin> I need to rebase, so no.
20160911 19:58:31< vultraz> also, I'm refactoring scrollbar mode right now
20160911 19:58:37< celmin> I did notice that the old one seemed to be scrolling kinda quickly.
20160911 19:58:40< vultraz> hopefully I'll have something for you soon
20160911 19:58:58< celmin> Though that might be just the latency of VNC, not sure.
20160911 19:59:15-!- Kwandulin [~Miranda@p200300760F2C7112BC0E050686F26C69.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160911 19:59:22< celmin> I should check directly on that computer as well… or I guess even just launch 1.12 on this computer to check...
20160911 19:59:27< vultraz> celmin: do you think i can just drop the up/down scroll speed controls since one can just use the mouse wheel to manually go up/down (finer control)?
20160911 19:59:35< celmin> No.
20160911 19:59:42< vultraz> why?
20160911 19:59:43< celmin> First, some people may still not have scroll wheels.
20160911 19:59:55< celmin> Second… was there even a second?
20160911 20:00:03< celmin> I feel like there was but I can't remember.
20160911 20:00:05< vultraz> I really don't care about the first.
20160911 20:00:06-!- JyrkiVesterinen [~JyrkiVest@87-92-1-204.bb.dnainternet.fi] has quit [Quit: .]
20160911 20:00:10< celmin> You should.
20160911 20:00:33< vultraz> Perhaps the solution then is to make up/down scroll the thing
20160911 20:00:41< vultraz> instead adjusting the speed 
20160911 20:00:44< celmin> Anyway, I didn't like it when OSX dropped the buttons, so don't think my opinion will change here.
20160911 20:00:49< celmin> What?
20160911 20:01:17< vultraz> in the old dialog, up/down made it go from 'not moving' to 'moving very fast' in a degree of steps
20160911 20:01:29< vultraz> i said perhaps i should just make it actually scroll.
20160911 20:01:46< celmin> I think adjusting the speed makes sense.
20160911 20:01:48< vultraz> since we really don't have a way to do otherwise.
20160911 20:01:52-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
20160911 20:01:58< celmin> Let's make it adjust the speed.
20160911 20:02:10< vultraz> ok, how do you propose to do that?
20160911 20:02:20< zookeeper> tad, celmin, vultraz, yeah that's certainly a bug. or at least there's no reason to require map starting positions.
20160911 20:02:38< zookeeper> (of course it's also harmless since it's apparently in stderr only)
20160911 20:02:44< vultraz> I only got it to scroll by adding a timer that uses scrolls ITEM_FORWARD every 10 ms.
20160911 20:03:39< celmin> So what you need is a way to adjust the delay.
20160911 20:03:48< vultraz> no
20160911 20:03:54< celmin> >
20160911 20:03:55< celmin> ?
20160911 20:04:01< vultraz> say you increase the timer delay to slow it down
20160911 20:04:05< vultraz> then it's no longer smooth
20160911 20:04:13< vultraz> what we need is to refactor scrollbars
20160911 20:04:22< vultraz> and say
20160911 20:04:24< celmin> I don't really get what you're saying.
20160911 20:04:29< vultraz> "scroll y distance over n time"
20160911 20:04:45< vultraz> and then have it do that *smoothly*
20160911 20:04:55< celmin> Though it seems like your problem could be solved by using .set_item_position(.get_item_position + blah) instead of .scroll(ITEM_FORWARD).
20160911 20:05:03< vultraz> no
20160911 20:05:07< celmin> Why?
20160911 20:05:09< vultraz> because that's not animated
20160911 20:05:12< vultraz> it'd just jump
20160911 20:05:24< vultraz> this *absolutely* needs to be smoothly animated.
20160911 20:05:43< celmin> That's why I said change the timer delay?
20160911 20:05:55< vultraz> it's down to 10 ms :|
20160911 20:06:19< celmin> And that's still fast?
20160911 20:06:27< vultraz> no, it's reasonable
20160911 20:06:39< celmin> But you want to slow it down even more?
20160911 20:06:43< celmin> Does 1 ms work?
20160911 20:06:45< vultraz> there's still some stutter but that's because of us using shitty surfaces
20160911 20:06:50< vultraz> ...
20160911 20:06:50< celmin> Not sure if every system would have that granularity.
20160911 20:07:01< vultraz> what?....
20160911 20:07:12< vultraz> even if this is max speed
20160911 20:07:14< celmin> I think it should be safe though, it's not like you're specifying times in nanoseconds.
20160911 20:07:22< vultraz> we need to make it slower or faster dynamiacally
20160911 20:07:33< celmin> Yes, of course, so we need to adjust the timer delay.
20160911 20:07:47< vultraz> OR
20160911 20:07:48< vultraz> as I said
20160911 20:07:59< vultraz> implement scrollbars to take a distance and a time
20160911 20:08:11< vultraz> and *smoothly* scroll distance over time.
20160911 20:08:11< celmin> I don't really see how that's any different.
20160911 20:08:31< vultraz> because
20160911 20:08:36< vultraz> imagine you slow it down to say, 100 ms.
20160911 20:08:45< gfgtdf> in which scenario excelty do you get the isues with missing stating locations ?
20160911 20:08:46< vultraz> it *only moves* every 100 ms
20160911 20:08:58< celmin> Yes, obviously.
20160911 20:08:59< vultraz> so it moves.... stop.... moves..... stop...
20160911 20:09:06< vultraz> whereas instead
20160911 20:09:15< celmin> Given that you're scrolling one pixel at a time, I don't think there's any other way.
20160911 20:09:48< vultraz> not... really
20160911 20:10:04< vultraz> I'm only using that to get it working
20160911 20:10:46< vultraz> instead, take the 100 ms example. instead of jumping 1 pixel every 100 ms, it should move 100 px over n time.
20160911 20:11:01< celmin> I don't see how that's any different.
20160911 20:11:10< vultraz> because then it's always moving
20160911 20:11:21< vultraz> and not pausing for 99 ms in between
20160911 20:11:27< celmin> That's impossible once the number of pixels is less than the time.
20160911 20:11:52< celmin> And you seemed to be against making it move more than one pixel at a time.
20160911 20:12:12< vultraz> no no no no no
20160911 20:12:32< celmin> Anyway, I'm pretty sure this is solvable, but I think I need to see it in action to really understand what you're complaining about...
20160911 20:13:02< vultraz> of course it can move more than 1 px at a time
20160911 20:13:09< celmin> So could we discuss this again once I've finished these Lua things? I think I only have three left.
20160911 20:13:20< vultraz> if you want the distance 100 px in 50 ms it will jump 2 px every ms.
20160911 20:13:46< celmin> And what if you want the distance of 50 px in 100 ms?
20160911 20:14:31< vultraz> 1 px every 2 ms.
20160911 20:14:45< celmin> Apparently we can't count on a timer of less than 10 ms.
20160911 20:14:56< vultraz> false
20160911 20:14:58< vultraz> i tested with 5 ms.
20160911 20:15:04< celmin> That means nothing.
20160911 20:15:33< celmin> So, since we can't count on a timer of less than 10 ms, we either have to make do with a timer of 10 ms, or do something that doesn't involve a timer.
20160911 20:15:55< vultraz> why cannot we count on it?
20160911 20:16:12< celmin> Oh, hold on a minute, these are old docs I'm looking at.
20160911 20:16:57< vultraz> obviously we cannot work with 0.5 ms or something, but down to 1 ms should work.
20160911 20:17:13< celmin> There's no guarantee of that.
20160911 20:17:24< vultraz> *however*
20160911 20:17:36< vultraz> 1 px every 10 ms does seem a good speed
20160911 20:17:44< vultraz> you'll have to observer yourself
20160911 20:18:00< vultraz> but I don't think I'd make it faster than 1/5
20160911 20:18:08< celmin> There's also no guarantee that the timer is called at exactly the requested time. You should think of the delay as a minimum delay, not an exact delay.
20160911 20:18:47< vultraz> ok, then how is this type of smooth scrolling done elsewhere :|
20160911 20:18:52< celmin> The point is that some CPUs may be incapable of a delay of less than 10 ms.
20160911 20:18:58< vultraz> why don't we see what mordante has to say.
20160911 20:19:31< celmin> I'm wondering if a scrolling thread would be able to do it, though that's still reliant on the built-in thread scheduling...
20160911 20:24:31-!- prkc [~prkc@46.166.138.130] has joined #wesnoth-dev
20160911 20:24:54< mordante> vultraz, is the FPS of Wesnoth no longer hard-coded at a maximum?
20160911 20:25:19< vultraz> I think it's still hardcoded 50 but that can easily be changed.
20160911 20:25:45< vultraz> max 50*
20160911 20:26:20< celmin> Ah, he responded.
20160911 20:26:30< celmin> Why would you want to change it?
20160911 20:26:36< mordante> I first had to read the discussion ;-)
20160911 20:27:30< mordante> with an update rate of 50 frames/sec every frame takes 20 ms so doesn't make sense to update a lot faster
20160911 20:28:01< mordante> also in the past SDL was not able to get the better than 10ms resolution
20160911 20:28:18< mordante> the resolution available depends on the operating system's timers
20160911 20:28:38< mordante> I don't know whether SDL2 uses high-resolution timers
20160911 20:32:43< mordante> and for automatic scrolling I would indeed use the set_item_position, it allows a more fine-grained stepping method
20160911 20:33:24< mordante> the scroll is intended for easy usage in listboxes in combination with keyboard shortcuts (and the buttons at the scrollbar)
20160911 20:35:05< celmin> Well, even if the timer is called every 20 ms, it doesn't need to actually scroll each time; it could check "do I need to scroll?" first.
20160911 20:35:52< celmin> I think I could figure this out if you want me to, vultraz.
20160911 20:36:02< vultraz> sure.
20160911 20:36:07< vultraz> I'm working on the scrollbar modes
20160911 20:36:19< celmin> Not quite sure what that means.
20160911 20:36:44< vultraz> going to look into the best way to integrate always hidden
20160911 20:36:47< vultraz> and buttons only
20160911 20:37:06< celmin> No need to worry about buttons only.
20160911 20:37:34< celmin> If you can get it working with a hidden or nonexistent bar, buttons only basically comes for free.
20160911 20:38:31< celmin> (Note that the "buttons only" mode that I want for menus will need a custom definition no matter what… either that, or extra repeating buttons in the listbox header/footer.)
20160911 20:39:01< celmin> …mind you, if you can get a mode that hides buttons instead of disabling them, that'd be helpful.
20160911 20:43:48-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160911 20:44:59-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection]
20160911 20:48:03< mordante> true it first needs to check whether to scroll or not, but if the minimum interval is 20 ms it would be easy to determine a 'nice' step size for 20ms
20160911 20:48:37< mordante> maybe even test the times between now() and the last update to determine the number of pixels to scroll
20160911 20:48:48< celmin> I was thinking of something like that, yes,
20160911 20:48:59< mordante> ok
20160911 20:50:39< celmin> While you're here, I wonder if you have any ideas on how to make text fade in a line at a time?
20160911 20:50:54< celmin> Presumably in a label control.
20160911 20:50:58-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160911 20:52:20< celmin> Or other similar text-appearing effect.
20160911 20:53:48< celmin> This is unrelated to the auto-scrolling case.
20160911 20:53:59< mordante> no good idea at the moment
20160911 20:54:32< mordante> but maybe also timer based and changing the alpha channel
20160911 20:54:54< mordante> but not sure how to directly do that in GUI2
20160911 20:54:57< gfgtdf> you mean for storyscreen ?
20160911 20:55:00< celmin> Yes.
20160911 20:55:59< mordante> maybe something could be done by adding more states to a widget and give a differnt alpha for every state
20160911 20:56:27< mordante> but not sure how many states would be required to get a smooth fade in or fade out
20160911 20:56:50< celmin> I wonder if a formula for alpha could do it… with a timer that changes a formula variable in the canvas...
20160911 20:57:04< celmin> Not entirely sure how alpha works here though.
20160911 20:58:25< vultraz> we need some sort of general alpha control
20160911 20:58:35< vultraz> not specialized to tcontrol.
20160911 20:58:58< celmin> ?
20160911 20:59:33< vultraz> we need some general way to control alpha components in the canvas.
20160911 21:00:20< celmin> Okay, I'm ready to push as soon as I rebase.
20160911 21:01:20< vultraz> still pondering how best to deal with this scrollbar thing..
20160911 21:01:22< mordante> celmin, the formula idea is probably better
20160911 21:01:37< vultraz> yeah, I second that
20160911 21:02:04< mordante> also not sure how alpha works, that differs in SDL1.2 and SDL2
20160911 21:02:18-!- horus2 [~1@79.120.248.57.pool.invitel.hu] has quit [Ping timeout: 250 seconds]
20160911 21:02:51< mordante> also haven't look at how SDL2 is implemented, but I assume it does a full frame update and let the GPU figure out what is dirty
20160911 21:04:08< vultraz> we aren't using sdl's capabilities to their full, just saying. we're still using way too much custom surface blitting.
20160911 21:04:46< mordante> ah ok
20160911 21:04:59< mordante> anyway I'm off now, night
20160911 21:05:39-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20160911 21:05:57< celmin> Push imminent
20160911 21:08:23< celmin> vultraz: I need to uncomment something to see the new credits, right?
20160911 21:08:37< vultraz> about.cpp:234
20160911 21:12:03-!- irker690 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160911 21:12:03< irker690> wesnoth: Celtic Minstrel wesnoth:master e90a256489f4 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update XCode project https://github.com/wesnoth/wesnoth/commit/e90a256489f4404e09b504434c0e27089be73e52
20160911 21:12:03< irker690> wesnoth: Celtic Minstrel wesnoth:master f1422579eb22 / src/scripting/lua_unit_attacks.cpp: Enable ipairs() iteration over unit attack lists https://github.com/wesnoth/wesnoth/commit/f1422579eb22e93856c8263c82e2ebedaa2d6f27
20160911 21:12:04< irker690> wesnoth: Celtic Minstrel wesnoth:master b8b1e8a22301 / src/scripting/ (5 files): Store unit methods in metatable instead of doing linear search https://github.com/wesnoth/wesnoth/commit/b8b1e8a223016bd22cd8ecfa3142d7e5b030aa24
20160911 21:12:05< irker690> wesnoth: Celtic Minstrel wesnoth:master 56a0f369cbe2 / src/scripting/ (game_lua_kernel.cpp lua_team.cpp): Add matches method to team metatable https://github.com/wesnoth/wesnoth/commit/56a0f369cbe2bd0d4c85b4b9ba172b7dbc34de37
20160911 21:12:06< irker690> wesnoth: Celtic Minstrel wesnoth:master eb187b23e4cb / src/scripting/lua_unit_type.cpp: Make unit types lookup table a userdata https://github.com/wesnoth/wesnoth/commit/eb187b23e4cb541098fdf4e18fe4632a4a407d9d
20160911 21:12:07< irker690> wesnoth: Celtic Minstrel wesnoth:master c621c95df83c / src/scripting/lua_unit_type.cpp: Include male/female variations in unit variations table iteration https://github.com/wesnoth/wesnoth/commit/c621c95df83c442d7528c6cbb619d29189a5589a
20160911 21:12:09< irker690> wesnoth: Celtic Minstrel wesnoth:master 2f5b9566901a / src/scripting/lua_unit_attacks.cpp: Add matches function to Lua unit attacks table https://github.com/wesnoth/wesnoth/commit/2f5b9566901a53d42b8608362c669c0902503d8a
20160911 21:12:11< irker690> wesnoth: Celtic Minstrel wesnoth:master 868321090145 / src/units/attack_type.cpp: Fix formula= in weapon filter causing the filter to pass even if other keys fail https://github.com/wesnoth/wesnoth/commit/8683210901455d0ae5ec44162f2a25a0e1c33143
20160911 21:12:13< irker690> wesnoth: Celtic Minstrel wesnoth:master 905e1a00a3b7 / changelog: Update changelog https://github.com/wesnoth/wesnoth/commit/905e1a00a3b73d57df414a4db2d27798cd7ebecf
20160911 21:21:50< vultraz> hm
20160911 21:21:59< vultraz> buttons only might be harder to implement than i thought
20160911 21:22:41< celmin> Imagine that
20160911 21:23:14< vultraz> :P
20160911 21:23:19< vultraz> thoughts on the EC screen?
20160911 21:23:28< celmin> Not yet
20160911 21:26:57-!- mjs-de [~mjs-de@x4db6b11d.dyn.telefonica.de] has quit [Remote host closed the connection]
20160911 21:28:28< vultraz> maybe I'll just implement always hidden for now..
20160911 21:30:15-!- gfgtdf_ [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 21:32:21-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160911 21:33:34-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 21:34:19-!- gfgtdf__ [~chatzilla@x50ab6c01.dyn.telefonica.de] has joined #wesnoth-dev
20160911 21:35:58-!- gfgtdf_ [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160911 21:36:11-!- prkc [~prkc@46.166.138.130] has quit [Remote host closed the connection]
20160911 21:38:02-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160911 21:38:14-!- gfgtdf__ is now known as gfgtdf
20160911 21:51:41-!- Appleman1234 [~Appleman1@KD119104106223.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20160911 21:53:32< vultraz> hm..
20160911 21:57:42< vultraz> celmin: for the record, if we solve this scrolling problem, we will be able to implement smooth scrolling
20160911 21:57:53< vultraz> for lists
20160911 21:57:55< vultraz> and stuff
20160911 21:58:10< celmin> Not sure how you draw that conclusion.
20160911 21:58:37< celmin> Anyway, I don't see anything wrong with the current list scrolling.
20160911 21:58:50< vultraz> It's not smooth :P
20160911 21:59:00< vultraz> it just jumps from place to place
20160911 21:59:00< celmin> It'd be nice if it were a bit more granular, I guess (scroll one item at a time instead of half a page).
20160911 21:59:15< celmin> But I don't think it needs to be totally smooth.
20160911 21:59:32< vultraz> But smooth scrolling is the way all current UIs do it
20160911 21:59:40< celmin> So?
20160911 21:59:59< celmin> Is your conclusion based on an analysis of games, BTW? Or just regular app UIs?
20160911 22:01:19< vultraz> both
20160911 22:01:25< celmin> Uhuh
20160911 22:01:28< celmin> If you say so.
20160911 22:01:50< celmin> Do you have data to show for your work?
20160911 22:02:01< vultraz> Not really, no
20160911 22:02:09< celmin> That's not very helpful, then.
20160911 22:02:15< vultraz> Just that all the games I've played in the past few years have had smooth scrolling
20160911 22:02:24< celmin> Vague statements of "Oh everyone else does this" don't mean much.
20160911 22:02:43< vultraz> anyway
20160911 22:02:47< vultraz> breakfast!
20160911 22:02:54< celmin> Also note that we've had at least on person in favour of non-smooth scrolling.
20160911 22:02:56< vultraz> do leave feedback on the EC screen
20160911 22:03:05< vultraz> yes, just one person.
20160911 22:03:17< celmin> Will do, once I get around to it. Maybe as much as an hour from now.
20160911 22:03:25< celmin> If there's one person, there could easily be more.
20160911 22:20:56-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160911 22:23:18< mattsc> Sigh.  We should disable -Werror in Xcode.
20160911 22:23:34< mattsc> Compiling has become super frustrating…
20160911 22:23:45< celmin> What happened now?
20160911 22:24:28< mattsc> This is the latest: src/gui/dialogs/end_credits.cpp:16:
20160911 22:24:29< mattsc> ../../src/gui/dialogs/end_credits.hpp:62:6: error: private field 'scroll_speed_' is not used [-Werror,-Wunused-private-field]
20160911 22:24:33< celmin> Aha.
20160911 22:24:43< celmin> That's intentional though.
20160911 22:24:59< mattsc> It’s intentional that I cannot compile?
20160911 22:25:52< celmin> No, it's intentional that the field is unused.
20160911 22:45:21-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160911 22:48:17-!- Appleman1234 [~Appleman1@KD119104119118.au-net.ne.jp] has joined #wesnoth-dev
20160911 22:49:20-!- gfgtdf [~chatzilla@x50ab6c01.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160911 22:49:23-!- gfgtdf_ [~chatzilla@x4e363f03.dyn.telefonica.de] has joined #wesnoth-dev
20160911 22:49:24-!- gfgtdf_ is now known as gfgtdf
20160911 22:53:15-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20160911 23:10:46-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160911 23:12:20< vultraz> WHYdid my computer shut down
20160911 23:24:21-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20160911 23:24:46-!- vultraz changed the topic of #wesnoth-dev to: 1.13.6 planned for late September | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160911 23:27:18-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160911 23:27:51< tad_> Would that all bugs were that straightforward.
20160911 23:28:42< celmin> vultraz: What was that topic update?
20160911 23:28:48< celmin> tad_: Yay?
20160911 23:28:54< vultraz> celmin: it's close to mid-September
20160911 23:29:03< vultraz> so it's likely going to be late september
20160911 23:29:07< celmin> I see.
20160911 23:30:04< tad_> celmin: GDB break on the message, check the call stack. Added code to look before leaping.
20160911 23:30:15 * vultraz is slightly annoyed that scrolling is still plagued by that shitty "jump" effect
20160911 23:30:24< celmin> Forget about it.
20160911 23:30:49< vultraz> hm?
20160911 23:31:05< tad_> Bah. There's "jump" effects a lot of places. I hate adding a move_unit_fake and watching it run forward 3, back 1, forward 2 and done.
20160911 23:31:57< vultraz> I thought it would go away in gui2 but..
20160911 23:32:00< vultraz> seems not >_>
20160911 23:32:22 * vultraz mutters about shitty surfaces
20160911 23:32:55< vultraz> but yeah that jump effect with a unit is new >_>
20160911 23:33:24< tad_> I can usually cause it simply by adding system load when running wesnoth. The game really does not handle stress well. (And who says code do not reflect its authors?)
20160911 23:33:35< vultraz> also apparently my always_hidden scrollbar mode also disables mouse wheel scrolling..
20160911 23:33:37< vultraz> blah
20160911 23:33:40< vultraz> *reverts*
20160911 23:34:21< celmin> Aww.
20160911 23:34:42< vultraz> i mean, I could commit it if you don't care about the mousewheel not working
20160911 23:34:51< vultraz> not that it'd fix your menu issue
20160911 23:35:42-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160911 23:37:16< tad_> celmin vultraz PR 772 fixes the bug I hit right out of the gate on LoW. I checked 1.12.6 and it did not exist there. So someone added the initial scroll (twice) code. You can merge it but I'd suggest asking around in case I squashed someone's idea fixing the bug.
20160911 23:37:43< vultraz> I don't think that'd be an issue
20160911 23:37:55< tad_> I considered "
20160911 23:38:44< tad_> "why twice" .. might have been a reason for it and the code was simply buggy. I changed it to only scroll once, and only if it should succeed.
20160911 23:39:19< tad_> Anyway. I'd done with the PR and off to find the next bug in LoW ..
20160911 23:39:50< celmin> vultraz: Any idea why the mouse wheel doesn't work?
20160911 23:39:57< celmin> I'd prefer it to work for menus though.
20160911 23:40:07< vultraz> None
20160911 23:40:23< tad_> Probably the event is being consumed by the hidden scroll bar?
20160911 23:41:15< vultraz> I still can't figure out the case of the text not showing if it's too long
20160911 23:41:25< vultraz> for example
20160911 23:41:30< vultraz> str << "<span size='x-large'>" << font::escape_text(line.substr(1)) << "</span>" << "\n";
20160911 23:41:32< vultraz> shows
20160911 23:41:33< vultraz> str << "\n<span size='x-large'>" << font::escape_text(line.substr(1)) << "</span>" << "\n";
20160911 23:41:35< vultraz> does not show
20160911 23:41:49< celmin> Pretty sure I mentioned something about an assert you removed.
20160911 23:41:50< vultraz> (that is, all lines with + preceding them)
20160911 23:41:57< vultraz> I tried readding it
20160911 23:42:06< vultraz> enabling checks to make sure it fit on the canvas
20160911 23:42:19< vultraz> made sure the scrollbar calculated correctly
20160911 23:42:21< vultraz> everything
20160911 23:43:37< vultraz> if I delete, say
20160911 23:43:40< vultraz> half of about.cfg
20160911 23:43:42< vultraz> it displays
20160911 23:44:09< vultraz> the label is set correctly
20160911 23:44:18< vultraz> if you print it out with .label() it's there
20160911 23:44:24< vultraz> but for some reason..
20160911 23:44:30< vultraz> under certain circumstances 
20160911 23:44:31< celmin> Well, obviously re-adding it won't work. What you'd need is to figure out something to do in the event that the condition is false, rather than just returning.
20160911 23:44:32< vultraz> it won't show :|
20160911 23:44:50< vultraz> it's set but not showing
20160911 23:44:51< celmin> Pretty sure it's just not being placed.
20160911 23:45:02< celmin> It doesn't have a position, so it's not being shown. Something like that.
20160911 23:46:56< vultraz> there's nothing in any of the debug logs that indicate a problem
20160911 23:49:06< tad_> Dunno which string builder you're using but is it set to line mode and that first \n is becoming \0?
20160911 23:49:45< vultraz> im using a stringstream
20160911 23:50:10< tad_> [18:41] <vultraz> str << "\n<span size='x-large'>" << font::escape_text(line.substr(1)) << "</span>" << "\n";
20160911 23:50:26< tad_> What happens if you do [18:41] <vultraz> str << "Test string\n<span size='x-large'>" << font::escape_text(line.substr(1)) << "</span>" << "\n";
20160911 23:51:13< vultraz> nope, still doesn't display
20160911 23:51:40< vultraz> for the record, it also doesn't display with the extra \n at the end, or with the label widget definition set to large
20160911 23:52:20< tad_> How about str << "<span size='x-large'>" << font::escape_text(line.substr(1)) << "</span>" << "\ntest\n";
20160911 23:52:42< tad_> What I'm looking at is does a second \n cause the issue
20160911 23:53:00< vultraz> nope
20160911 23:53:46< tad_> And you've dumped the stringbuilder and it's correct (can't see why not but never hurts to check)
20160911 23:56:44< tad_> I'm assuming you've checked that line.substr(1) != '\0'
20160911 23:57:24< vultraz> I did not
20160911 23:57:37< vultraz> but that really should have nothing to do with the size 
20160911 23:59:54< vultraz> ... oh this is odd O_O
--- Log closed Mon Sep 12 00:00:00 2016