--- Log opened Fri Jan 01 00:00:27 2016
20160101 00:28:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160101 00:33:05-!- Necrosporus_ is now known as Necrosporus
20160101 00:44:53-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160101 00:47:38-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160101 00:47:45-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160101 00:48:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20160101 00:49:38-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160101 01:05:26-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20160101 01:30:49-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has joined #wesnoth-dev
20160101 01:31:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160101 02:06:42< Aginor> morning vultraz 
20160101 02:22:40-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160101 02:47:48-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has joined #wesnoth-dev
20160101 02:51:24-!- TheJJ [~rofl@ipbcc36ea9.dynamic.kabel-deutschland.de] has quit [Ping timeout: 245 seconds]
20160101 02:58:19-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160101 03:01:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160101 03:06:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20160101 03:09:05-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has joined #wesnoth-dev
20160101 03:14:13< Aginor> hey ancestral 
20160101 03:14:21< Aginor> happy new year (ish?)
20160101 03:18:27-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160101 03:31:54-!- gfgtdf [~chatzilla@f054138193.adsl.alicedsl.de] has joined #wesnoth-dev
20160101 03:32:02< gfgtdf> Aginor: happynew year
20160101 03:32:09< Aginor> gfgtdf: the same to you
20160101 03:32:20< gfgtdf> Aginor: about 24209
20160101 03:32:25< Aginor> yes?
20160101 03:32:31< Aginor> I'm testing my fix to it right now
20160101 03:32:34< gfgtdf> Aginor: i think we should tr tokeep the fix very simple
20160101 03:32:39< Aginor> or trying to
20160101 03:32:47< Aginor> look at PR572
20160101 03:33:01< gfgtdf> Aginor: becasue we will mostikeleyremove it when SDL2.0.4 is releasaed
20160101 03:33:05< Aginor> I think we want the global event context anyway
20160101 03:33:20< Aginor> and then it's simply a matter of removing the code in that #ifdef
20160101 03:33:26< gfgtdf> i Aginor what exactly doesit?
20160101 03:33:37< gfgtdf> the global event handler
20160101 03:34:32< Aginor> allows you to register for SDL_Events in a global context, ie, the registering class won't stop receiving events just because some other component made a new event context
20160101 03:35:31< gfgtdf> Aginor: what exactly is a event context (sry i dont know the events.cpp code tht muhc)
20160101 03:35:58< Aginor> I can only speak about what I've figured out, so I'm not quite sure what the original intent was
20160101 03:36:22< Aginor> gfgtdf: trying to gauge my level of detail; Are you familiar with gui programming and event handling?
20160101 03:36:50< gfgtdf> Aginor: im a little familiar with the gui2 code.
20160101 03:37:06< Aginor> sorry for asking, but I have no idea what your experience is :)
20160101 03:37:16< Aginor> I mean in general, not within the wesnoth context
20160101 03:38:27< gfgtdf> Aginor: no not really
20160101 03:38:48< Aginor> ok :)
20160101 03:39:45< gfgtdf> Aginor: i mean i weould sure manage to rite a gui aplication
20160101 03:39:50< gfgtdf> write*
20160101 03:40:10< gfgtdf> Aginor: but i dont know any advanced techniques
20160101 03:41:00< Aginor> So there's a way to register for receiving events, dispatched from the big event-loop in events.cpp. The event loop looks for all handlers in the last registred context, not sending events to any previously registered contexts. An event context here is simply a collection of event listernes
20160101 03:41:39< Aginor> the class in wesnoth that acts as an event listener is sdl_handler (events.hpp), which has the methods join(), leave() and handle_event(...)
20160101 03:41:45< gfgtdf> Aginor: which code changes teh event contect ?
20160101 03:41:59< Aginor> join and leave is simply registering for current context
20160101 03:42:01< gfgtdf> Aginor: y the gui2 code also has a sdl_listener
20160101 03:42:24< Aginor> the context is changed by simply creating a new instance of the event context class, it's done in the constructor
20160101 03:43:16-!- TheJJ [~rofl@ipbcc36ea9.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160101 03:43:17< Aginor> there's also some code to change context programatically, which seems to be used to send events to the GUIX panel with focus
20160101 03:44:20< gfgtdf> Aginor: so this code here https://github.com/wesnoth/wesnoth/blob/master/src/gui/auxiliary/event/handler.cpp#L453 creates a events::conect to prevent the background from reciveing events?
20160101 03:44:39< Aginor> yes
20160101 03:45:49< Aginor> the focus-following code probably comes into play there to have multiple components playing nicely together
20160101 03:49:23< gfgtdf> Aginor: i also tested that reszing worksnw much better
20160101 03:49:31< Aginor> cool
20160101 03:49:36< gfgtdf> Aginor: even better then in 1.12.5 i think
20160101 03:49:50< Aginor> I'm still compiling my reference
20160101 03:49:59< Aginor> gfgtdf: does that mean I can merge 572?
20160101 03:50:07< Aginor> or was that not what you tested?
20160101 03:50:13< gfgtdf> Aginor: i think the more we port togui2 the less evnt conext we need
20160101 03:50:23< gfgtdf> Aginor: noi just tested master
20160101 03:50:31< Aginor> actually, I can't merge it yet, I need to add an sdl1 guard
20160101 03:50:51< gfgtdf> Aginor: i no use the dll i linked in the bugreport
20160101 03:51:16< gfgtdf> Aginor: but since the bug will mostlikleey still effect officalwindows releasees this is still an issue
20160101 03:51:26< Aginor> yes
20160101 03:51:27< gfgtdf> s/i no/no i
20160101 03:51:53< Aginor> bah, my windows is incredibly slow
20160101 03:52:22< gfgtdf> Aginor: virtual machine?
20160101 03:52:32< Aginor> yes
20160101 03:52:38< gfgtdf> Aginor: just wesnoth orwindows in general?
20160101 03:52:57< Aginor> windows in general
20160101 03:53:12< Aginor> I blame virtualbox
20160101 03:53:23< gfgtdf> Aginor: are there an sdl2 related issues left to be fuxed before next 1.13 release
20160101 03:53:37< gfgtdf> ?
20160101 03:53:45< Aginor> potentially a windows issue, let me find the bug
20160101 03:55:17-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has joined #wesnoth-dev
20160101 03:56:26< Aginor> https://gna.org/bugs/?23910
20160101 03:57:13< Aginor> gfgtdf: there's also a bunch of bugs that need to be confirmed as fixed
20160101 03:57:31< gfgtdf> Aginor: hmm why won't the butracker image attachments not showin browser?
20160101 03:57:38< gfgtdf> Aginor: they want to be donloaded
20160101 03:58:02< Aginor> I guess that's just how it is
20160101 03:58:25< gfgtdf> Aginor: :/
20160101 03:59:22< Aginor> gfgtdf: PR566 needs to be sorted as well, but I think that should build upon the global context I introduced in PR572
20160101 04:00:09< gfgtdf> Aginor: i'dlike if pr566 was tested to build ith sdl1 before beeing merged
20160101 04:01:01< Aginor> gfgtdf: I'll be making sure we don't break SDL1 before the next release
20160101 04:01:08< Aginor> I test everything both under 1 and 2 :)
20160101 04:01:41< Aginor> https://gna.org/bugs/index.php?24210 could also be fixed
20160101 04:01:57< Aginor> and there's: https://gna.org/bugs/index.php?24209
20160101 04:02:08< Aginor> apart from that I know of no SDL2 specific bugs
20160101 04:02:30< Aginor> credits are having a transparency issue in both SDL1 and SDL2 though, that needs some fixing too
20160101 04:03:22< gfgtdf> Aginor: you have a planon what do do afterthisinf that bug?
20160101 04:03:45< Aginor> gfgtdf: which bug?
20160101 04:04:08< gfgtdf> Aginor: thenonss you mentioned
20160101 04:04:34< Aginor> I have no imediate plans to try to tackle any of those bugs apart from 24209 right now
20160101 04:04:47< Aginor> I want to finish that and make all resize handling good
20160101 04:04:58< Aginor> s/resize/window/
20160101 04:05:20< Aginor> then I probably need to spend a couple of days doing consulting work in my spare time instead of wesnoth
20160101 04:05:39< Aginor> why do you ask?
20160101 04:07:47< ancestral> Aginor: Happy New Year
20160101 04:07:52< ancestral> 10 PM here, but close enough
20160101 04:08:30< ancestral> Time to change all the relevant copyright dates to 2016
20160101 04:08:37< ancestral> (I hear vultraz is an expert at this)
20160101 04:08:52< Aginor> ancestral: that's pretty easy :)
20160101 04:09:40< Aginor> find src -name "*.?pp" | xargs sed -i 's/Copyright year 2015/Copyright year 2016/g'
20160101 04:09:52< Aginor> or something similar ;)
20160101 04:09:53< ancestral> git commit
20160101 04:09:56< ancestral> :-P
20160101 04:10:35< Aginor> git diff first .)
20160101 04:10:49< Aginor> I have really shot myself in the foot doing similar things in the past
20160101 04:15:15-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160101 04:30:18< Aginor> still compiling under windows :/
20160101 04:36:29-!- oldlaptop [~quassel@50-37-38-205.mskg.mi.frontiernet.net] has quit [Ping timeout: 276 seconds]
20160101 04:37:47< Aginor> ok
20160101 04:37:51< Aginor> PR572 works
20160101 04:38:16< Aginor> gfgtdf: what's the correct preprocessor directive to use to target all windows builds across all compilers?
20160101 04:38:20< Aginor> _WIN32 ?
20160101 04:39:43< Aginor> _WIN32 looks right
20160101 04:43:02-!- gfgtdf [~chatzilla@f054138193.adsl.alicedsl.de] has quit [Ping timeout: 250 seconds]
20160101 04:50:35< vultraz> allos, Aginor 
20160101 04:51:17< vultraz> this global events stuff looks good
20160101 04:51:38< vultraz> the prefs event handler could usei t
20160101 04:51:41< vultraz> use it*
20160101 04:52:03< Aginor> vultraz: that's certainly what I was thinking
20160101 04:52:25< Aginor> I'm about to do a force-push though, I had broken SDL1
20160101 04:52:34< Aginor> about to re-test now to make sure it still works
20160101 04:55:05< vultraz> Aginor: I think it may in fact fix the issue I was struggling with yesterday 
20160101 04:55:41< Aginor> it allows a nice separation of concern between the event loop code and anything that needs to always be notified about... anything
20160101 04:56:13< vultraz> tell me when you've force-pushed 
20160101 04:57:12< Aginor> done
20160101 04:57:37< Aginor> I'll let it sit a bit for people to examine, but I think it's ready to merge
20160101 04:57:43< Aginor> it fixes the bug on windows
20160101 04:57:53< Aginor> and adds the very useful global event context
20160101 04:59:27< vultraz> could you take a look at 566 next when you have time? see if there's anything you want me to change/fix, esp for SDL1 
20160101 05:00:58< Aginor> vultraz: sure
20160101 05:03:31< Aginor> doing an SDL1 build with it now
20160101 05:05:05< vultraz> hmm... uh... where do I hook the prefs events into global?
20160101 05:05:35< Aginor> you um, wait for PR572 to be merged ;)
20160101 05:05:46< vultraz> no no, I pulled it locally :P
20160101 05:05:54< vultraz> so I can test if it fixes my bug
20160101 05:05:54< Aginor> look at the change to video.cpp and video.hpp where I've done it
20160101 05:06:50< vultraz> ok, so you created a subclass
20160101 05:06:56< Aginor> vultraz: http://pastebin.com/iuts5ZFM
20160101 05:07:11< Aginor> you could just as well subclass the original preferences class
20160101 05:07:30< Aginor> I might do that in cvideo once SDL1.2 is dropped
20160101 05:08:26< vultraz> hm... looks like that code needs to be sdl2 only
20160101 05:08:38< Aginor> yes
20160101 05:09:02< Aginor> and you probably need to add the right SDL1 handling there too
20160101 05:09:19< vultraz> ugh
20160101 05:09:29< Aginor> much ugh
20160101 05:09:47< vultraz> indeed
20160101 05:10:38< Aginor> vultraz: does that PR have the 568 commits in it?
20160101 05:11:22< vultraz> no, i merged 568 to master
20160101 05:11:27< Aginor> ok
20160101 05:11:37< Aginor> but has 566 been rebased on top of that?
20160101 05:12:30< vultraz> yes, 566 has been rebased on master 
20160101 05:13:29-!- Appleman1234 [~Appleman1@KD119104018199.au-net.ne.jp] has quit [Ping timeout: 246 seconds]
20160101 05:16:27< Aginor> good :)
20160101 05:17:56< Aginor> vultraz: http://pastebin.com/BaQidwQw
20160101 05:18:03< Aginor> I added the SDL version check
20160101 05:18:21< Aginor> I think you need to compile and fix for SDL 1 too :/
20160101 05:19:20< vultraz> D:
20160101 05:19:22< vultraz> nuuu
20160101 05:20:22< vultraz> ok, some of these are obvious fixes
20160101 05:27:00< vultraz> Aginor: the only error I don't understand is invalid use of non-static member function
20160101 05:28:03< vultraz> should min_allowed_width/height be static?
20160101 05:29:04< Aginor> vultraz: you're missing paranthesis so it's a reference to the function itself
20160101 05:30:01< vultraz> missing then?
20160101 05:30:06< vultraz> them*
20160101 05:30:39< Aginor> change result.push_back(current_resolution); to result.push_back(current_resolution());
20160101 05:30:49< Aginor> video.cpp:843
20160101 05:31:52< vultraz> oh I was looking at the wrong line
20160101 05:31:58< vultraz> my 843 is different 
20160101 05:32:33< Aginor> video.cpp:834
20160101 05:32:39< Aginor> I transposed some digits
20160101 05:34:43< vultraz> Aginor: pushed a commit, try building again
20160101 05:37:04< vultraz> BTW, the final issue seemed tobe with certain window events not being caught by the prefs handler 
20160101 05:37:16< vultraz> so 572 should almost certainly fix that
20160101 05:37:23< Aginor> indeed
20160101 05:37:58< vultraz> If 566 builds, you're welcome to merge in current state, then 
20160101 05:43:13< Aginor> it builds
20160101 05:43:22< Aginor> I'll give it more of a test and review first
20160101 05:43:35< Aginor> I'm slightly worried it'll break SDL1, but it's looking good
20160101 05:47:29< Aginor> vultraz: I'm not sure, but I think something dodgy is going on with resizing in your PR
20160101 05:47:52< Aginor> it's always been flaky for m in SDL1 though, that's one of the reasons I started doing SDL2 stuff
20160101 06:01:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160101 06:01:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160101 06:01:44< vultraz> Aginor: I can't guarantee anything will work in sdl1, TBH. But that's also a point, SDL1 has its own problems
20160101 06:02:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160101 06:06:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160101 06:10:07-!- Appleman1234 [~Appleman1@KD119104015241.au-net.ne.jp] has joined #wesnoth-dev
20160101 06:10:51< Aginor> yup
20160101 06:11:01< Aginor> but we don't want to cause regressions
20160101 06:12:07< vultraz> true, true
20160101 06:12:52< Aginor> hmm
20160101 06:13:03< Aginor> it gets the window state wrong in SDL1 when I maximize
20160101 06:13:08< Aginor> and start again
20160101 06:13:11< Aginor> and dimensions
20160101 06:13:47< Aginor> I think we need someone else to test with sdl1 and linux
20160101 06:13:59< vultraz> isn't that an existing problem
20160101 06:14:08< Aginor> I'm not sure
20160101 06:14:20< Aginor> I will make a reference build shortly to compare with
20160101 06:15:10< vultraz> yay for ccache 
20160101 06:17:54< vultraz> Aginor: BTW, there is no preferences class, only a namespace
20160101 06:18:30< Aginor> ah
20160101 06:18:50< Aginor> I hadn't realised :)
20160101 06:19:43< celticminstrel> About 90% of the time, :: indicates a namespace rather than a class.
20160101 06:20:00< Aginor> yes...
20160101 06:20:18< Aginor> I just hadn't put 2 and 2 together for that for some reason
20160101 06:20:26< celticminstrel> :)
20160101 06:20:40< vultraz> celticminstrel: I did not know this
20160101 06:21:17< celticminstrel> Well, unless it follows template arguments, obviously.
20160101 06:21:30< Aginor> vultraz: PR566 doesn't save window size for me in SDL2
20160101 06:21:40< Aginor> I reset all game preferences
20160101 06:21:43< Aginor> started the game
20160101 06:21:44< vultraz> say what 
20160101 06:21:47< Aginor> resized it
20160101 06:21:48< celticminstrel> Barring template metafunctions, classes are usually made to be instantiated. The :: syntax on the other hand would reference static members of the classes.
20160101 06:22:00< Aginor> quit and then restarted
20160101 06:22:10< Aginor> window size is 1024x768 both times
20160101 06:22:26< vultraz> gotta try this..
20160101 06:22:56< vultraz> Aginor: I did the exact same thing and it saves for me :|
20160101 06:22:59< vultraz> whut
20160101 06:25:45< Aginor> I'll run it through a debugger to see
20160101 06:26:33< vultraz> I did notice maximized state wasn't saving for me, though... bleh
20160101 06:27:52< Aginor> celticminstrel: do you have any opinions on PR572?
20160101 06:28:43 * Aginor facepalms
20160101 06:28:54< Aginor> vultraz: I built master, not your PR
20160101 06:29:05< vultraz> derp :P
20160101 06:29:16< Aginor> trying all over again
20160101 06:35:00< celticminstrel> I don't really know what to think of it... so I guess, no opinions.
20160101 06:35:01< Aginor> vultraz: it gets window size wrong when restarting the game maximized. state is maximized, but base window size is the previously maximized state
20160101 06:35:11< Aginor> celticminstrel: ok :D
20160101 06:35:43< vultraz> Aginor: as in, it's not really "maximized", just the size of being maximized?
20160101 06:35:56< Aginor> vultraz: both, I think
20160101 06:36:23< Aginor> no
20160101 06:36:33< Aginor> vultraz: not really maximized, just the size of maximized
20160101 06:37:06< vultraz> I have some local changes that might fix that
20160101 06:37:10< vultraz> not sure, testing now
20160101 06:38:31 * celticminstrel sleep
20160101 06:40:52< Aginor> celticminstrel: sleep well
20160101 06:42:35-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160101 06:49:40< Aginor> vultraz: I think SDL1 is as good as it ever was
20160101 06:49:53< Aginor> but it's always been pretty broken for me
20160101 06:50:49< vultraz> good, good
20160101 06:53:12< vultraz> Aginor: dunno if this is a problem, but it seems certain functions cause resize events to be fired twice
20160101 06:53:23< vultraz> ie, my prefs handling function can get handled twice in certain cases
20160101 06:53:36< vultraz> I wonder if that would fix if I used 572....
20160101 06:54:14< Aginor> vultraz: this is your cause
20160101 06:54:16< Aginor> case SDL_WINDOWEVENT_SIZE_CHANGED: // Fall through to RESIZED case SDL_WINDOWEVENT_RESIZED:
20160101 06:54:34< Aginor> SDL_WINDOWEVENT_SIZE_CHANGED always preceeds a SDL_WINDOWEVENT_RESIZED
20160101 06:54:45< Aginor> maybe it's bettert to only handle one of them
20160101 06:54:51< vultraz> ohhhhhhhh
20160101 06:54:56< vultraz> ok, testing again
20160101 06:55:50< vultraz> hm
20160101 06:56:03< vultraz> ok, so on maximize, both MAXIMIZE and RESIZE get handled
20160101 06:56:35< Aginor> yeah
20160101 06:56:45< Aginor> or at least that's what I expect
20160101 06:56:56< vultraz> and resize can set the maximized flag to false
20160101 06:58:14< vultraz> Aginor: quick off topic while I'm thinking about it: did you notice the weird drawing behavior in the credits screen
20160101 06:58:35< Aginor> vultraz: I did, I haven't looked into it though
20160101 06:58:41< vultraz> ok
20160101 06:58:42< Aginor> it's present in both SDL1 and 2
20160101 07:01:42< vultraz> ok, I think I fixed the maximize state bug
20160101 07:01:50< Aginor> sweet
20160101 07:01:57< Aginor> I'm agoing to merge PR572 now
20160101 07:02:03< vultraz> I moved _set_maximize(false) from the RESIZE event to set_resolution()
20160101 07:02:16< Aginor> yup
20160101 07:02:22< vultraz> now there's only... one more bug left 
20160101 07:02:26< Aginor> there's probably more scope for cleanup
20160101 07:02:29< Aginor> which one?
20160101 07:02:57-!- irker263 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160101 07:02:57< irker263> wesnoth: Andreas Löf wesnoth:master 544b61534c71 / src/ (events.cpp events.hpp video.cpp video.hpp): Fix bug #24209 and add a global event scope http://git.io/vuf5i
20160101 07:02:57< irker263> wesnoth: Andreas wesnoth:master cb74629a88ac / src/ (events.cpp events.hpp video.cpp video.hpp): Merge pull request #572 from aginor/master http://git.io/vuf5P
20160101 07:03:02< vultraz> sometimes when setting resolution on a maximized window, the size will change but the state will still be considered maximized for the window (ie, the restore button is present not the maximize button)
20160101 07:03:37< vultraz> purely an internal matter, since quitting at that point and restarting will give you a window of the size you set, and the correct state
20160101 07:04:02< Aginor> you probably need to call SDL_RestoreWindow to make it non-maximized
20160101 07:05:05-!- d4nf [~d4nf@ool-182ee6a9.dyn.optonline.net] has quit [Ping timeout: 260 seconds]
20160101 07:09:05< Aginor> vultraz: I think window.cpp (twindow) might need a few changes, to not simply remove fullscreen mode when changing the resolution. And adding a wrapper aroudn the restore function
20160101 07:09:40< Aginor> that way you have more flexibility around changing window size while maximised or fullscreen
20160101 07:09:59< vultraz> Aginor: so I should remove SDL_SetWindowFullscreen(window_, 0); from twindow::set_size()?
20160101 07:10:28-!- iceiceice [~chris@ext-74.ias.edu] has joined #wesnoth-dev
20160101 07:10:28-!- iceiceice [~chris@ext-74.ias.edu] has quit [Changing host]
20160101 07:10:28-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160101 07:10:42< Aginor> I'd say so
20160101 07:10:54< Aginor> you'll need to add some other checks to compensate for it though
20160101 07:11:20< Aginor> I'm about to disappear for a while, but I can help you to do those changes later if you want
20160101 07:11:38< Aginor> I'd also suggest you use the general event handling that I introduced in PR572 now :)
20160101 07:12:14< vultraz> Aginor: I can just add a class to the prefs namespace, right?
20160101 07:18:49< Aginor> I see no reason why not
20160101 07:19:07< vultraz> 'k
20160101 07:40:49< ancestral> Aginor: Entering and leaving fullscreen works much better now, thanks
20160101 07:41:12< ancestral> Now if only changing the resolution while in fullscreen actually changed the native resolution of the computer…
20160101 07:41:32< vultraz> ancestral: why would you change res in fullscreen?
20160101 07:41:44< Aginor> ancestral: I made a conscious decision to not change the native resolution
20160101 07:42:12< ancestral> Because maybe I have an old CRT and I can choose a smaller res meaning larger UI
20160101 07:42:45< vultraz> DO you have an old CRT? :P
20160101 07:42:54< ancestral> No, but it’s hypothetical
20160101 07:43:05< ancestral> Or maybe I want to choose a HiDPI resolution
20160101 07:43:09< Aginor> we could turn it into an advanced option to pick resize mode
20160101 07:43:45< vultraz> i mean, games do usually allow setting res in fullscreen...
20160101 07:44:09< vultraz> but they don't change the native res, do they?
20160101 07:44:09< ancestral> vultraz: Let me clarify
20160101 07:44:37< ancestral> vultraz: Right now, at least on the Mac, there is no way to change the resolution of the screen while using Wesnoth
20160101 07:45:20< ancestral> This was possible in previous versions, so something changed/regressed (and maybe it’s just changes with SDL2)
20160101 07:46:08< Aginor> ancestral: yes, I picked which one of the two fullscreen modes to use. Changing it to the other (which you're requesting) would be trivial
20160101 07:46:32< Aginor> it's SDL_FULLSCREEN vs SDL_FULLSCREEN_DESKTOP
20160101 07:47:02< ancestral> Hmm
20160101 07:47:04< Aginor> I picked the desktop version because I prefer to run games in the native resolution if I can
20160101 07:47:07< ancestral> IS that a flag?
20160101 07:47:13< Aginor> yes
20160101 07:47:20< Aginor> it's an SDL define
20160101 07:48:07< Aginor> sorry, it's SDL_WINDOW_FULLSCREEN vs SDL_WINDOW_FULLSCREEN_DESKTOP
20160101 07:48:11< Aginor> https://wiki.libsdl.org/SDL_CreateWindow
20160101 07:49:47< Aginor> this might be something for OS X
20160101 07:49:49< Aginor> https://wiki.libsdl.org/SDL_HINT_VIDEO_MAC_FULLSCREEN_SPACES?highlight=%28\bCategoryDefine\b%29|%28CategoryHints%29
20160101 07:50:36 * vultraz wonders when 2.0.4 will come out
20160101 07:51:27< ancestral> Aginor: Cool, though not concerned about Spaces atm
20160101 07:51:38< ancestral> StandYourGround will be happy to see Spaces support is there though
20160101 07:52:20< Aginor> vultraz: nobody knows ;)
20160101 07:53:22< vultraz> i saw a thread from like summer 2014 saying they wanted to release it "next month"
20160101 07:54:33-!- Roniga [~androirc@161.79.69.111.dynamic.snap.net.nz] has joined #wesnoth-dev
20160101 07:54:46< ancestral> If they’re in South America that might be January ;-)
20160101 07:54:58< Roniga> Hi again
20160101 07:55:04< vultraz> hah
20160101 07:55:04< ancestral> Hi
20160101 07:55:56< ancestral> vultraz: Is SDL 2.0.3+dev fairly stable?
20160101 07:56:03< vultraz> I have no idea
20160101 07:56:17< vultraz> I'm not an SDL dev :P
20160101 07:56:33< ancestral> I would imagine these likely are maintenance releases?
20160101 07:57:00< Roniga> I'd rather we used 2.0.3, that way we are in a sensible state
20160101 07:57:24< Roniga> And it will work with
20160101 07:57:25< ancestral> Of course
20160101 07:57:37< Roniga> With linux distros and stuff
20160101 07:57:46< ancestral> I was insinuating that if vultraz was impatient he could build his own with the latest source
20160101 07:58:25< Roniga> Ah, right 😁
20160101 07:59:04< ancestral> Aginor: I’m swapping those flags you mentioned
20160101 07:59:09< ancestral> We’ll see how it behaves
20160101 07:59:44< vultraz> ancestral: could you not commit anything, though
20160101 08:00:01< Roniga> Beware that theres a few places in the code
20160101 08:00:47< ancestral> vultraz: I’m not commiting anything. If I do, it goes in a branch. If I’m serious, I’ll ask for a PR
20160101 08:00:57< vultraz> ok
20160101 08:01:06< ancestral> Aginor: I have changed fullscreen res
20160101 08:01:25< ancestral> Just some odd behavior now existing fullscreen and changing to other resolutions
20160101 08:01:51< ancestral> Or maybe in some scenarios, both flags can be used?
20160101 08:01:59< Roniga> I havent done any work on that :)
20160101 08:02:10< Roniga> So it woyldnt suprise me
20160101 08:02:24< ancestral> Let me rephrase
20160101 08:02:29< vultraz> is Roniga Aginor o_O
20160101 08:02:36< ancestral> In some situations, both of those flags could be used
20160101 08:02:40< ancestral> perhaps\
20160101 08:03:42< Roniga> Vultraz: read my nick backwards
20160101 08:03:45< ancestral> vultraz: palindromic
20160101 08:03:49< vultraz> I did
20160101 08:03:54< vultraz> that's why I even suspected 
20160101 08:04:43< Roniga> Ancestral: we could change those flags, but i think desktop fullscreen makes more sense
20160101 08:04:55< vultraz> dammit, i've broken my build
20160101 08:05:03< ancestral> So here’s the thing
20160101 08:05:04< vultraz> trying to change prefs handling to global
20160101 08:05:36< ancestral> There’s a button that says “Change Resolution”
20160101 08:05:50< vultraz>  multiple definition of `preferences::event_handler in linker....
20160101 08:05:53< vultraz> hmm
20160101 08:05:55< vultraz> ok so maybe
20160101 08:06:01< vultraz> the class in the namespace doesn't work
20160101 08:06:02< ancestral> There will be times when someone would like to run Wesnoth fullscreen at non-native resolutions
20160101 08:06:09< ancestral> Maybe they’re hooked up to an external display
20160101 08:06:47< ancestral> Maybe they have bad eye sight
20160101 08:07:06< ancestral> The alternative (and this is possible) is make the game resolution independent
20160101 08:07:09< Roniga> Ancestral: youre trying to cater to use-cases that would never work with SDL1
20160101 08:07:21< ancestral> But, that means scaling everything
20160101 08:07:28< Roniga> External displays that is
20160101 08:07:28< vultraz> scaling! D:
20160101 08:07:54< ancestral> I don’t see how you can have neither of these options
20160101 08:09:04< vultraz> Roniga / Aginor: this is what I have... guess I'm doing it wrong http://pastebin.com/dW4rVT9G
20160101 08:10:17< Roniga> Vultraz: i can't tell anything useful from that at the moment
20160101 08:10:24< ancestral> The “change resolution” button needs to work
20160101 08:10:49< ancestral> (eventually)
20160101 08:10:54< vultraz> problem is I don't really understand what I'm doing 
20160101 08:11:07< vultraz> so I'm just trying to copy what you were doing :/
20160101 08:11:24-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20160101 08:11:35< Roniga> Ancestral: i can see where you're coming from, but I'm more inclined to remove it
20160101 08:12:17< ancestral> Why remove it?
20160101 08:12:21< vultraz> ancestral: I have to agree with that, though
20160101 08:12:32< ancestral> Most every game has the ability to change the resolution
20160101 08:12:38< ancestral> Some people have gigantor monitors
20160101 08:12:56< ancestral> Some people have slow-ass computers, so playing at a small resolution means better framerates
20160101 08:13:09< vultraz> ancestral: for example, what happens if someone on a retina display chooses a "SD" resolution  - how do we handle that 
20160101 08:13:19< ancestral> If you want to remove this feature, you absolutely need to get some consensus about it
20160101 08:13:29< ancestral> Becuase you’re talking about a very important feature
20160101 08:14:18< ancestral> (vultraz: Well, and for me, basically it’s defaulting to the SD “half” resolution, but I can’t choose the actual 2x resolution)
20160101 08:14:30< Roniga> Yes...
20160101 08:15:04< vultraz> ancestral: wait, it doesn't give you native res?
20160101 08:15:08< ancestral> (My situation is more about Hi-DPI and is less important/absolutely backburnery)
20160101 08:15:19< ancestral> vultraz: Alright let me explain
20160101 08:15:42< ancestral> My monitor has a native pixel resolution of 2560 x 1600
20160101 08:16:01< ancestral> Most apps do not natively support “retina” or Hi-DPI resolutions
20160101 08:16:23< vultraz> shouldn't we work on that for us?
20160101 08:16:25< ancestral> Therefore, the default behavior if not supporting it, is to pixel double
20160101 08:16:46< ancestral> It’s the difference of pixels and points
20160101 08:17:38< vultraz> so you get...1 game pixel taking up...2 display pixels?
20160101 08:17:40< vultraz> or something?
20160101 08:17:51< ancestral> Yeah, basically Wesnoth draws a pixel
20160101 08:17:57< Roniga> 4 pixels
20160101 08:17:59< ancestral> It takes up 4 pixels on my screen
20160101 08:18:01< ancestral> Right
20160101 08:18:04< ancestral> 2 x 2
20160101 08:18:28< ancestral> vultraz: If Wesnoth wants true retina support, then everyone’s going to need to make 2x assets
20160101 08:18:37< ancestral> Sliders that are twice as big
20160101 08:18:46< ancestral> Window elements that are twice as big
20160101 08:18:50< vultraz> LB made those, though
20160101 08:18:56< ancestral> He did quite a few
20160101 08:19:10< ancestral> Then you have to decide, what about pixel art?
20160101 08:19:21< vultraz> that... is a good question
20160101 08:19:27< ancestral> Do we leave pixel art as-is? (A very good argument is, yes, we do)
20160101 08:19:27< vultraz> Jetrel would be the guy to ask
20160101 08:19:55 * Jetrel_bot shambles in
20160101 08:20:02< ancestral> Long story short: Wesnoth cannot just support Hi-DPI without changes to assets
20160101 08:20:08< ancestral> But
20160101 08:20:13< ancestral> Wesnoth might not need true support
20160101 08:20:21< ancestral> And I’m not asking for that
20160101 08:20:48< ancestral> Hi Jetrel_bot
20160101 08:20:51< ancestral> :)
20160101 08:21:01< Jetrel_bot> hey
20160101 08:21:30< ancestral> <insert LotR Mordor meme>
20160101 08:21:54< Jetrel_bot> so yeah, uh, my take on retina support is that it's totally reasonable to enable it, so that things like e.g. portraits scale more cleanly
20160101 08:22:30< Jetrel_bot> But it's absolutely unreasonable to to redo any of the art besides *maybe* the gui art, and even that's asking for a lot
20160101 08:22:59< Jetrel_bot> It should be on the same basis as a website, basically
20160101 08:23:29< ancestral> vultraz: Have you seen the reddit page?
20160101 08:23:37< ancestral> Wesnoth’s reddit page banner
20160101 08:23:55< vultraz> Jetrel_bot: and we already have 2x assets for a large number amount of the gui so that's great
20160101 08:23:57< Roniga> Ancestral: would you be able to enable that hint for spaces support and check how that behaves? I think it's related to the desktop fullscreen support
20160101 08:24:04< vultraz> I've asked LB to do 2x cursors too 
20160101 08:24:08< ancestral> That banner is a quick hack “supporting” retina displays
20160101 08:24:12< vultraz> s/number//
20160101 08:24:18< vultraz> ancestral: yes, why
20160101 08:24:49< ancestral> It’s an asset with twice the pixel information jammed into the pixel area designed for normal DPI
20160101 08:24:58< Jetrel_bot> ancestral:  I would (strongly) say that the proper way to support retina displays is to provide one version of an asset, at a high resolution.
20160101 08:25:12< ancestral> ^ exactly that
20160101 08:25:17< Jetrel_bot> Providing multiple versions at different resolutions is evil.
20160101 08:25:20< ancestral> It’s just
20160101 08:25:46< ancestral> Either images in the game will be twice as small
20160101 08:25:53< ancestral> Or you need to make some new images or
20160101 08:26:02< ancestral> You will scale up the images, which is the status quo
20160101 08:26:10< Jetrel_bot> ancestral:  sigh
20160101 08:26:37< ancestral> It’s not really a needed thing right now. What Wesnoth needs right now is a theme for HD displays
20160101 08:26:42< Jetrel_bot> ancestral:  obviously "images in the game will be twice as small" and "you need to make some new images" are ludicrously out of the question
20160101 08:26:52< ancestral> Exactly!
20160101 08:27:01< Jetrel_bot> so that solves that decision. :P
20160101 08:27:19< Jetrel_bot> ancestral:  I mean, I can see why people fret about it
20160101 08:27:33< Jetrel_bot> ancestral:  but it's definitely a "making the mountain come to mohammed" sort of thing
20160101 08:27:37< ancestral> Roniga: The last merge you put in makes Spaces work correctly
20160101 08:28:48< ancestral> When I tried changing the flags, I got some resolution changing, but lost some fullscreen toggling. Probably what I did was too simplistic, and some additional logic is required
20160101 08:29:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160101 08:29:53< ancestral> So yes, I think we’ve agreed, the advantage if Wesnoth were to truly support Hi-DPI/retina displays would be to have nicer UI elements (which LB has contributed quite a bit)
20160101 08:30:01< Roniga> Fullscreen-desktop is pretty much the same as spaces support
20160101 08:30:26< Roniga> Something you're kind of arguing against :)
20160101 08:30:47< ancestral> I’m not sure we’re quite on the same page
20160101 08:31:04< ancestral> I think it’s doable to have both resolution changing and Spaces support
20160101 08:33:46< ancestral> Roniga: Your last commit works great. The only thing is I still can’t change resolutions (which we’ve talked about; not necessary for everyone, but perhaps good to have for some people; a feature that’s been a part of Wesnoth for years…)
20160101 08:33:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20160101 08:34:49< ancestral> When I did the dirty hacky thing of just changing the name of the flag by removing _DESKTOP I immediately got some resolution-changing ability (when I launched the app it correctly changed my screen to 800 x 600 as I specified previously)
20160101 08:35:09< ancestral> But it doesn’t refresh until I leave the app and go back in
20160101 08:36:03< Roniga> It probably doesn't try to apply the setting until at game start as it would override the window size otherwise.
20160101 08:36:27< ancestral> Also, when I try to leave fullscreen, it doesn’t actually leave fullscreen
20160101 08:36:37< Roniga> I haven't looked at that code since i made the changes in September
20160101 08:36:44< vultraz> ancestral: you might want to test your changes on top of 566
20160101 08:36:53< Roniga> Even on vanilla master?
20160101 08:36:55< ancestral> vultraz: Which is what I did
20160101 08:37:00< vultraz> oh
20160101 08:37:02< vultraz> ok
20160101 08:37:15< vultraz> Jetrel_bot: what's that a reference to?
20160101 08:38:03< ancestral> Bottom line: Aginor: Great patch, Spaces works, fullscreen toggling works. Downside? Changing resolutions isn’t working yet.
20160101 08:39:25< ancestral> I’ll double-check Gna and if a bug report isn’t listed for changing display resolutions while in fullscreen I’ll submit one
20160101 08:39:44< Aginor> ancestral: There was an initial discussion about this for SDL2 when I made the change
20160101 08:40:02< Aginor> which is why I'm a bit argumentative now :)
20160101 08:40:08< ancestral> No problem
20160101 08:40:38< Aginor> there was a consensus, and that was that the desktop-fullscreen version was better than changing the native resolution
20160101 08:40:42< ancestral> I’m just a little surprised to learn this is somehow XOR
20160101 08:40:57< ancestral> That both features can’t be had
20160101 08:41:04< Aginor> I'm not entirely sure it is, but it's harder
20160101 08:41:19< Aginor> and I may have misunderstood the documentation
20160101 08:42:01< ancestral> I mean, sure, I’d rather have fullscreen toggling than changing display resolutions
20160101 08:42:44< Aginor> the "other games does it" argument sits poorly with me as well, because I'm not convinced we need it
20160101 08:43:15< Aginor> but I'm also aware that I might not know how most people prefer to play the game :)
20160101 08:43:23< vultraz> ancestral: Dota 2 has an option to use native desktop res or set it specifically (along with aspect ratio and window mode (ie borderless window, etc)). 
20160101 08:43:25< Aginor> (as in, how they interact with it)
20160101 08:43:33< vultraz> wonder if that might be something to consider
20160101 08:43:34< ancestral> With RTSes it’s essential
20160101 08:43:57< ancestral> With turn-based games… honestly, maybe not?
20160101 08:44:02< ancestral> Aginor: But here’s the deal
20160101 08:44:13< ancestral> If Wesnoth abandons resolution changing
20160101 08:44:44< ancestral> We absolutely need an “HD” theme/extension
20160101 08:45:14< ancestral> Many people who change the resolution are doing it for framerates, or as an admittedly crude (but effective) way to make it bigger on the screen
20160101 08:45:36< ancestral> And right now, the UI already looks really tiny on most displays
20160101 08:45:58< vultraz> Indeed
20160101 08:46:02< vultraz> we need an HD theme 
20160101 08:46:12< vultraz> I think everyone can agree on that
20160101 08:46:15< Aginor> that's a different kettle of fish though
20160101 08:46:40< ancestral> But that needs to be in place if in-game resolution changing goes out the window
20160101 08:47:40< Aginor> so many old, open, fullscreen bugs
20160101 08:47:52< Aginor> at least I will be able to close them all soon :)
20160101 08:47:59< ancestral> (And ideally, we gotta figure out why pango/cairo/something isn’t rendering Deja Vu fonts on the Mac, because Helvetica shows up even 30% visually smaller, compounding the problem)
20160101 08:48:18< ancestral> Aginor: I say We and I really probably don’t mean you at all :)
20160101 08:48:45< ancestral> I’m happy the fullscreen stuff is working! So thank you for that
20160101 08:50:54< ancestral> Alright, I gotta go to bed
20160101 08:51:02< vultraz> hey, I helped :P
20160101 08:51:03< Aginor> ancestral: here's what I think:
20160101 08:51:18< ancestral> vultraz: Thank you :)
20160101 08:51:21< Aginor> 1. Keep the current status of desktop-fullscreen
20160101 08:51:34< Aginor> 2. Make an advanced preferences option for resolution-changing desktop
20160101 08:51:56< Aginor> 3. Only show the resolution button when the advanced preference option is enabled.
20160101 08:52:59< ancestral> As long as it works
20160101 08:54:03< ancestral> Theming is a good alternative. It’s sort of a poor-mans UI scaler
20160101 08:54:26< Aginor> I personally is sooooo not keen on touching the theming :D
20160101 08:54:36< ancestral> It’s super kuldgey
20160101 08:54:42< ancestral> *kludgey
20160101 08:55:17< Aginor> I have mucked about with GUI1 enough in the last couple of days to know it won't be fun
20160101 08:55:20< ancestral> You’re probably wise not to touch it
20160101 08:55:32< Aginor> which reminds me, vultraz asked for help
20160101 08:56:12< vultraz> yes :) I really can't figure out how to hook into the global event thing
20160101 08:56:27-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has quit [Quit: End Transmission.]
20160101 08:56:59< Aginor> vultraz: I can't find your link in my scrollback
20160101 08:57:21< vultraz> http://pastebin.com/dW4rVT9G ?
20160101 08:57:21< Aginor> found it
20160101 08:57:27< Aginor> as soon as I complained :D
20160101 08:58:33< Aginor> your diff looks right to me
20160101 08:58:37< Aginor> what's the error?
20160101 08:59:14< vultraz> large number of " multiple definition of `preferences::event_handler_'" errors in the linker
20160101 08:59:30< vultraz> C:/TDM-GCC-32/bin/../lib/gcc/mingw32/5.1.0/../../../../mingw32/bin/ld.exe: .objs-release\src\actions\attack.o: bad reloc address 0x154 in section `.rdata'
20160101 09:02:10< Aginor> update your header file and take out the function definition for handle_event there
20160101 09:02:20< Aginor> gah
20160101 09:02:21< Aginor> no
20160101 09:02:30< Aginor> I'm not reading properly and I'm missing things
20160101 09:07:30< Aginor> have you forc push since rbasing on top of 572?
20160101 09:07:41< Aginor> force pushed even
20160101 09:08:42< vultraz> Aginor: just did
20160101 09:12:02< Aginor> vultraz: I feel like I'm making this much harder for you than it needs to be by having turned it into a moving target :/
20160101 09:13:27< vultraz> Aginor: it's not that much of an issue. But if you want, we could merge 566 and work in master
20160101 09:13:33< vultraz> it does work as-is currently
20160101 09:16:21< Aginor> ok
20160101 09:16:42< Aginor> don't declare your variables in the header files, declare them in the implementation
20160101 09:17:27< Aginor> if you really want to declare them in the header file, make them extern in the header file and declare without the extern in the implementation
20160101 09:19:00< Aginor> vultraz: I think it'll just start to work if you do that
20160101 09:23:11< vultraz> build, it does
20160101 09:23:36< vultraz> work, it does too
20160101 09:23:38< vultraz> :D
20160101 09:24:23< Aginor> :D
20160101 09:24:45< vultraz> want to deal with the cleanup of twindow now?
20160101 09:25:33< Aginor> by declaring it in the headr file it'll implicitly be declared in every cpp-file that includes it. which will make the linker angry when it finds lots of multiple definitions
20160101 09:25:53< Aginor> if you want to
20160101 09:26:14< Aginor> otherwise it might be good to rebase and squash some of those commits and get it merged
20160101 09:26:31< vultraz> What should I squash?
20160101 09:26:42< Aginor> just bringing it up again ;)
20160101 09:27:32< vultraz> I've already rebased and don't think any of the commits can be easily squashed
20160101 09:27:47< Aginor> no, not without a bunch of reordering and stuff
20160101 09:27:59< Aginor> let's get it merged then if everything works :)
20160101 09:29:24< vultraz> As far as I can tell, it does. Besides the small window restore issue, but we can deal with that in master
20160101 09:29:51< vultraz> (since it'll go along with cleaning up twindow)
20160101 09:30:09< Aginor> yup
20160101 09:30:19< irker263> wesnoth: Charles Dang wesnoth:master d4cd7d5a6d4a / src/sdl/ (window.cpp window.hpp): Add new twindow setter functions: maximize() and center() http://git.io/vuJeq
20160101 09:30:22< irker263> wesnoth: Charles Dang wesnoth:master 79012123b251 / src/gui/dialogs/ (lobby_main.cpp title_screen.cpp): Removed event pump call from fullscreen helper functions in SDL2 http://git.io/vuJem
20160101 09:30:25< irker263> wesnoth: Charles Dang wesnoth:master f25d41779478 / src/preferences_display.cpp: Removed unused anon functions http://git.io/vuJeY
20160101 09:30:28< irker263> wesnoth: Charles Dang wesnoth:master c0bf5e51c882 / src/video.cpp: Center window when changing mode http://git.io/vuJeO
20160101 09:30:31< irker263> wesnoth: Charles Dang wesnoth:master 6272190ec548 / src/ (video.cpp video.hpp): Restrict CVideo::modePossible to SDL1 only http://git.io/vuJe3
20160101 09:30:34< irker263> wesnoth: Charles Dang wesnoth:master 20634adcfb7b / src/game_preferences_display.cpp: Call display change functions directly when changing from prefs instead of using http://git.io/vuJes
20160101 09:30:37< irker263> wesnoth: Charles Dang wesnoth:master eb1335b64b59 / src/video.cpp: Add flag detection for maximized and fullscreen to CVideo::window_state http://git.io/vuJeG
20160101 09:30:40< irker263> wesnoth: Charles Dang wesnoth:master 8732d8179cf3 / src/ (preferences_display.cpp video.cpp video.hpp): Added and deployed getter method for current window resolution http://git.io/vuJeZ
20160101 09:30:43< irker263> wesnoth: Charles Dang wesnoth:master c425bd8b159c / src/events.cpp: Save new resolution on window resize http://git.io/vuJen
20160101 09:30:46< irker263> wesnoth: Charles Dang wesnoth:master 02b992821a33 / src/ (events.cpp preferences.cpp preferences.hpp): Reimplement preference flag event handling in member function hook http://git.io/vuJec
20160101 09:30:49< irker263> wesnoth: Charles Dang wesnoth:master a3b3c6b1043d / src/ (preferences.cpp preferences.hpp video.cpp): Add initial handling and retention of maximized window state http://git.io/vuJeC
20160101 09:30:52< irker263> wesnoth: Charles Dang wesnoth:master 185402dc1fb9 / src/preferences.cpp: Added a safety check for event type in prefs window event handling http://git.io/vuJeW
20160101 09:30:55< irker263> wesnoth: Charles Dang wesnoth:master 98e0bdd83792 / src/ (game_launcher.cpp video.cpp): Refactored handling of window modes in SDL2 http://git.io/vuJel
20160101 09:30:58< irker263> wesnoth: Charles Dang wesnoth:master 8af99510ea4d / src/game_launcher.cpp: Allow -r command line flag to explicitly override previously saved maximized sta http://git.io/vuJe8
20160101 09:31:01< irker263> wesnoth: Charles Dang wesnoth:master 75080d8fdc5c / src/preferences.cpp: Allow prefs window SIZE_CHANGED to fall through to RESIZED http://git.io/vuJe4
20160101 09:31:04< irker263> wesnoth: Charles Dang wesnoth:master 4d9882a95ec6 / src/video.cpp: Reworked fullscreen handling a bit http://git.io/vuJeB
20160101 09:31:07< irker263> wesnoth: Charles Dang wesnoth:master bd3601b78cd0 / src/video.cpp: Make sure the SDL_WINDOW_RESIZABLE flag is always set in SDL2 http://git.io/vuJeR
20160101 09:31:10< irker263> wesnoth: Charles Dang wesnoth:master a18f86c93e64 / src/ (preferences.cpp video.cpp): Fixed compilation on SDL1.2 http://git.io/vuJe0
20160101 09:31:13< irker263> wesnoth: Charles Dang wesnoth:master d9cd1d7f94b5 / src/ (preferences.cpp video.cpp): Explicitly set maximized flag to false when setting resolution instead of on res http://git.io/vuJeE
20160101 09:31:16< irker263> wesnoth: Charles Dang wesnoth:master a6f35e51866c / src/ (events.cpp preferences.cpp preferences.hpp): Move prefs window event handling to global event context http://git.io/vuJeu
20160101 09:31:19< irker263> wesnoth: Charles Dang wesnoth:master eb58f07ffe0f / src/ (12 files in 3 dirs): Merge pull request #566 from Vultraz/display_cleanup http://git.io/vuJez
20160101 09:31:26< vultraz> \o/
20160101 09:32:56< Aginor> nice!
20160101 09:33:00< Aginor> vultraz: good job!
20160101 09:33:03< vultraz> :D
20160101 09:33:06< vultraz> ty ty
20160101 09:33:46< Aginor> vultraz: do you know where the create_network screen is made?
20160101 09:33:56< Aginor> as in, implemented?
20160101 09:34:04< vultraz> create_network?
20160101 09:34:32< vultraz> no I don't
20160101 09:34:37< vultraz> loonycyborg might
20160101 09:34:51< Aginor> and old multiplayer lobby
20160101 09:35:08< Aginor> they all share the same bug now (background isn't redrawn on resize)
20160101 09:36:23< vultraz> Aginor: the mp lobby is probably game_initialization/multiplayer_lobby.*pp
20160101 09:38:32< Aginor> thanks
20160101 09:44:23< irker263> wesnoth: Andreas Löf wesnoth:master afabf8c8a16f / src/ (4 files in 3 dirs): Add more invokations of the top-level GUI1 event handler to redraw the GUI on re http://git.io/vuJfE
20160101 09:44:27< Aginor> much useful
20160101 09:44:34< Aginor> many bugs squashed
20160101 09:44:37< vultraz> I wonder if GUi2 can use the global events thing
20160101 09:44:46< Aginor> don't try :)
20160101 09:44:46< vultraz> since right now it handled it itself
20160101 09:44:52< vultraz> nah, I won't :P
20160101 09:44:59< vultraz> GUI2 is toooo complicated
20160101 09:45:01< Aginor> it also relies on the focus
20160101 09:45:07< Aginor> it might actually just work
20160101 09:45:10< Aginor> do try :)
20160101 09:46:12< vultraz> one step at a time :P
20160101 09:46:19< vultraz> first let's clean up twindow
20160101 09:47:50< vultraz> if we start tweaking gui2 we should decide if each dialog should be its own SDL window
20160101 09:48:04< vultraz> instead of its own twindow::window_instance
20160101 09:49:50< vultraz> I believe I have fixed that restore state bug :D
20160101 09:53:14< vultraz> Aginor: do you think there's any reason to catch SIZE_CHANGED in prefs anymore?
20160101 09:53:19< vultraz> if not I'll remove the fallthrough
20160101 09:54:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160101 09:54:51< Aginor> only for SDL1
20160101 09:55:50< vultraz> you mean only SDL1 needs to catch that?
20160101 09:55:57-!- Kwandulin [~Miranda@p200300760F250AE9FDB75A99D6C6F313.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160101 09:56:21< irker263> wesnoth: Andreas Löf wesnoth:master 52762abe45b6 / src/game_initialization/multiplayer_ui.cpp: Relayout multiplayer windows on a window size change http://git.io/vuJJE
20160101 09:56:28< Aginor> I think so
20160101 09:56:28< vultraz> because the entire function is SDL2 only
20160101 09:56:42< Aginor> you probably have a better view of it than I do right now
20160101 09:56:55< vultraz> I think I'll just remove it
20160101 09:58:38< Aginor> I'll trust your judgement .)
20160101 09:58:46< irker263> wesnoth: Charles Dang wesnoth:master ddb6a2c8edab / src/sdl/window.hpp: Fixed a few comments http://git.io/vuJJw
20160101 09:58:49< irker263> wesnoth: Charles Dang wesnoth:master fbb564d2c62b / src/ (sdl/window.cpp sdl/window.hpp video.cpp): Move fullscreen-to-windowed mode handling to a separate twindow::restore() funct http://git.io/vuJJr
20160101 09:58:52< irker263> wesnoth: Charles Dang wesnoth:master b11879a2bc7d / src/preferences.cpp: Catch window restore in prefs and flag maximized as false http://git.io/vuJJo
20160101 09:58:55< irker263> wesnoth: Charles Dang wesnoth:master 75e76038b630 / src/preferences.cpp: Remove fallthrough handling case of SDL_WINDOWEVENT_SIZE_CHANGED http://git.io/vuJJK
20160101 09:58:58-!- Roniga [~androirc@161.79.69.111.dynamic.snap.net.nz] has quit [Ping timeout: 256 seconds]
20160101 09:59:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160101 09:59:16< vultraz> That was surprisingly simple 
20160101 10:00:26< Aginor> .)
20160101 10:00:39< Aginor> that's what comes from tidying things up
20160101 10:01:02< Aginor> my two commits fixed all of the mp GUI1 screens when it comes to resizing and the like
20160101 10:01:12< Aginor> and the editor, I think
20160101 10:01:17 * Aginor goes to test the editor more
20160101 10:02:33< Aginor> looks... acceptable
20160101 10:02:44< Aginor> not awesome, but not horribly corrupted or unusable
20160101 10:07:52< Aginor> right
20160101 10:08:03< Aginor> as of now, I don't know of any major SDL2-related bugs
20160101 10:08:25< vultraz> I think that gray screen thing might still happen but I will have to test
20160101 10:08:25< irker263> wesnoth: Nils Kneuper wesnoth:master e88c75b563a9 / / (10 files in 9 dirs): updated Russian translation http://git.io/vuJUG
20160101 10:08:30< irker263> wesnoth: Nils Kneuper wesnoth:1.12 231ebb400de6 / / (10 files in 9 dirs): updated Russian translation http://git.io/vuJUZ
20160101 10:08:39< Aginor> vultraz: gray screen thing?
20160101 10:08:58< vultraz> Aginor: the thing where the window turns all gray if you alt-tab out and back
20160101 10:09:02< vultraz> it might be gone now
20160101 10:09:21< Aginor> I think it is .)
20160101 10:09:23< Aginor> please check
20160101 10:09:36< Aginor> if comment on the bug so I know
20160101 10:09:47< Aginor> there's too many bugs for me to keep track of in my head :/
20160101 10:10:10< vultraz> Just a sec, I'm moving the min_allowed_width/height variables from prefs to CVideo
20160101 10:12:29< Aginor> I think they should stay in prefs
20160101 10:12:37< vultraz> you think so?
20160101 10:13:05< vultraz> prefs doesn't use them at all, though
20160101 10:13:10< Aginor> it's an requirement from the UI, not something that's required from the video
20160101 10:13:22< Aginor> so yes, I think it makes sense to keep it there
20160101 10:13:23< vultraz> hm
20160101 10:13:28< vultraz> ok
20160101 10:13:41< vultraz> I'll change them to static member variables, though
20160101 10:13:43< vultraz> instead of functions
20160101 10:13:54< Aginor> I like the functions ;)
20160101 10:14:14< Aginor> it makes it easy to change in the future (if we would ever want to do that)
20160101 10:24:40< vultraz> Aginor: I think the grayscreen bug is gone
20160101 10:25:25< Aginor> good
20160101 10:25:36< Aginor> please comment on the bug so I can close it officially :)
20160101 10:25:43< Aginor> hmm
20160101 10:26:08< Aginor> I just started HttT and the initial cutscene is looking terrible
20160101 10:26:12< Aginor> I think it needs some fixing
20160101 10:26:44< vultraz> hmmmmm
20160101 10:26:58< vultraz> I seem to have a corner case of incorrect state handling.. X_X
20160101 10:27:50< vultraz> if you set resolution after maximizing a window it will launch the next time "the size of maximized" but not actually maximized 
20160101 10:28:26< Aginor> yes, that's broken
20160101 10:28:59< vultraz> and... toggling fullscreen off gives you the same 'size of maximized' thing. Damn
20160101 10:29:04< vultraz> I thought I had this all fixed X_X
20160101 10:29:41< vultraz> but at least I can't reproduce the grayscreen thing
20160101 10:30:18< Aginor> is there a scenario that spawns a mage of light on the first level?
20160101 10:30:32< Aginor> I want to have a quick look at https://gna.org/bugs/index.php?23712
20160101 10:31:28< vultraz> the test scenario might
20160101 10:31:33< vultraz> also you can easily stick one in with WML
20160101 10:32:07< vultraz> {GENERIC_UNIT 1 (Mage of Light) 10 10}
20160101 10:32:29< Aginor> I know absolutely nothing about the WML :)
20160101 10:32:35< Aginor> I've stayed away from it so far
20160101 10:32:55< Aginor> hmm
20160101 10:33:06< Aginor> I think it's that particular unit that's broken
20160101 10:33:13< Aginor> not something in the graphics code
20160101 10:33:21< Aginor> how are halos defined for a unit?
20160101 10:33:54< vultraz> in WML
20160101 10:34:21< vultraz>  halo=halo/illuminates-aura.png
20160101 10:42:03< vultraz> Aginor: submitted some bug updates
20160101 10:43:07< Aginor> thanks
20160101 10:43:37< vultraz> now I need to figure out the cause of this new maximized state issue
20160101 10:44:21< irker263> wesnoth: Andreas Löf wesnoth:master 4b3510172263 / changelog: update changelog http://git.io/vuJId
20160101 10:44:23< irker263> wesnoth: Andreas Löf wesnoth:master 594ce7f11981 / / (14 files in 11 dirs): Merge branch 'master' of github.com:wesnoth/wesnoth http://git.io/vuJIF
20160101 10:45:13< Aginor> woops
20160101 10:45:19< Aginor> didn't mean to get a merge in there :/
20160101 10:45:50< Aginor> I need to figure out why the buttons stop working for you
20160101 10:46:48< Aginor> vultraz: what menu is it you've tested with?
20160101 10:46:59< vultraz> the ones in the editor
20160101 10:47:19< zookeeper> vultraz, so i take it that you know about that [message] TC problem?
20160101 10:50:24< vultraz> you mentioned it
20160101 10:52:26-!- Roniga [~androirc@161.79.69.111.dynamic.snap.net.nz] has joined #wesnoth-dev
20160101 10:53:45-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160101 10:56:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160101 10:59:19-!- Roniga [~androirc@161.79.69.111.dynamic.snap.net.nz] has quit [Ping timeout: 245 seconds]
20160101 11:00:04< Kwandulin> Is the ellpise tag in [unit type] working? I can't get it to work
20160101 11:00:33< zookeeper> vultraz, okay. is that more your or celtic_minstrel's thing?
20160101 11:00:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 245 seconds]
20160101 11:04:25< zookeeper> Kwandulin, works for me.
20160101 11:04:54< zookeeper> at least in master, didn't test in 1.12.
20160101 11:04:55< zookeeper> ellipse="misc/ellipse-hero"
20160101 11:05:20< Aginor> argh...
20160101 11:05:31< Aginor> why can't gui1 and gui2 use the same event context
20160101 11:05:37< Aginor> can't they all be friends?
20160101 11:31:40< Aginor> hmm
20160101 11:31:43< Aginor> they are
20160101 11:35:03< Kwandulin> Mhh, I still can't get the ellipse working with custom images inside the add-ons/my_campaign folders. I can verify that it does work with misc/ellipse-hero, though. Does the tag only work for images that were defined by the main game (ellpise-hero, ellipse-nozoc)?
20160101 11:35:42< Kwandulin> I imagined that the ellipse tag would just work like the halo tag, just within a different 'layer'
20160101 11:39:50-!- travis-ci [~travis-ci@ec2-54-159-167-112.compute-1.amazonaws.com] has joined #wesnoth-dev
20160101 11:39:51< travis-ci> wesnoth/wesnoth#8079 (master - 52762ab : Andreas Löf): The build has errored.
20160101 11:39:51< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/99692968
20160101 11:39:51-!- travis-ci [~travis-ci@ec2-54-159-167-112.compute-1.amazonaws.com] has left #wesnoth-dev []
20160101 11:59:53< zookeeper> Kwandulin, no, i'm pretty sure it doesn't.
20160101 12:00:36< zookeeper> most likely you're just doing it wrong somehow
20160101 12:35:23-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Quit: Bye]
20160101 12:55:34-!- Roniga [~androirc@161.79.69.111.dynamic.snap.net.nz] has joined #wesnoth-dev
20160101 12:59:10-!- TheJJ [~rofl@ipbcc36ea9.dynamic.kabel-deutschland.de] has quit [Ping timeout: 256 seconds]
20160101 13:00:03-!- Roniga [~androirc@161.79.69.111.dynamic.snap.net.nz] has quit [Client Quit]
20160101 13:04:39-!- TheJJ [~rofl@ipbcc36ea9.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160101 13:45:55-!- irker263 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160101 14:16:45-!- gfgtdf [~chatzilla@f054138193.adsl.alicedsl.de] has joined #wesnoth-dev
20160101 14:17:29< gfgtdf> Aginor, vultraz: didyou test whether sdl1 currently builds?
20160101 14:17:40< vultraz> yes he said ie builds
20160101 14:17:42< vultraz> it*
20160101 14:24:04< gfgtdf> vultraz: yi juyt saw there is an extra fix sdl1.2 commit
20160101 14:24:41< gfgtdf> vultraz: you know the thime for next 1.13 relrase?
20160101 14:28:03< zookeeper> gfgtdf, http://www.wesnoth.org/irclogs/2015/12/%23wesnoth.2015-12-31.log <- maybe you have an idea
20160101 14:28:22< zookeeper> (10:28)
20160101 14:28:33< gfgtdf> zookeeper: hmm y thta bug amkeses sense
20160101 14:28:50< gfgtdf> zookeeper: i'll fix in in master today or tomorrow
20160101 14:28:57< zookeeper> oh, cool
20160101 14:29:10< zookeeper> also note that i guess the same would apply to recruitment of traitless units
20160101 14:29:18< gfgtdf> zookeeper: idknow whether its eaasy to backpoer
20160101 14:30:07< gfgtdf> zookeeper: also the siminilar and easier bug reported by ravanna wasnt that eas to backport (i needed multiple commits)
20160101 14:31:34< gfgtdf> zookeeper: y there is lready a codd for 'undoing actions that clear shroud(move,recruit,recall)' i'll just try to move return village code there
20160101 14:31:47< gfgtdf> code
20160101 14:32:07< zookeeper> all right
20160101 14:38:45-!- gfgtdf [~chatzilla@f054138193.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.3/20151223140742]]
20160101 15:28:35-!- prkc [~prkc@catv-80-98-216-55.catv.broadband.hu] has quit [Quit: Leaving]
20160101 15:29:00-!- prkc [~prkc@catv-80-98-216-55.catv.broadband.hu] has joined #wesnoth-dev
20160101 15:41:23-!- heirecka [~heirecka@j61898.servers.jiffybox.net] has joined #wesnoth-dev
20160101 15:41:23-!- heirecka [~heirecka@j61898.servers.jiffybox.net] has quit [Changing host]
20160101 15:41:23-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev
20160101 15:55:47-!- gfgtdf [~chatzilla@f054138193.adsl.alicedsl.de] has joined #wesnoth-dev
20160101 15:56:07< gfgtdf> Aginor , vultraz storyscreen is broken in current master
20160101 16:01:17< gfgtdf> Aginor , vultraz loadgame dialog is also quiet bugged+
20160101 16:01:48< vultraz> gfgtdf: hm?
20160101 16:01:50< vultraz> gfgtdf: how
20160101 16:02:36< gfgtdf> of you close it the previousoly windows becomes bugged
20160101 16:02:39< gfgtdf> if*
20160101 16:03:57< vultraz> previously windows?
20160101 16:05:19< gfgtdf> ?
20160101 16:06:34< vultraz> " it the previousoly windows"
20160101 16:07:36< gfgtdf> the previous window
20160101 16:10:49< gfgtdf> somehow imgur gives me errors whne i try to upload images
20160101 16:18:37< zookeeper> Aginor, the halo bug can't really be from the unit, the halo definition is as it has always been.
20160101 16:20:25< zookeeper> what other unit did you test? there are no others in mainline
20160101 16:21:08< zookeeper> the wose shaman has a halo, but it's done in a standing anim
20160101 16:21:55< zookeeper> ah, TRoW has one, let's see...
20160101 16:24:31< zookeeper> huh. the autumn shyde's (barely visible) halo works right, it seems.
20160101 16:24:58< zookeeper> likely because it's 72x72
20160101 16:27:28< zookeeper> however, now even the MoL's halo stays on the unit sometimes/often. as per my comment, the last time i tried it was never on the unit.
20160101 16:29:19-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160101 16:39:11-!- oldlaptop [~quassel@50-37-38-205.mskg.mi.frontiernet.net] has joined #wesnoth-dev
20160101 16:41:12< vultraz> gfgtdf: any objection to 573?
20160101 16:45:00< gfgtdf> vultraz: hmm how do you know that they are never called ?
20160101 16:45:38< vultraz> well, primarily: https://github.com/wesnoth/wesnoth/pull/573/files#diff-f476fcd725a882707d1f488bda48aaefL878
20160101 16:46:01< gfgtdf> vultraz: right
20160101 16:46:32< gfgtdf> vultraz: y i think that mkaes sense
20160101 16:48:21< vultraz> so can I merge?
20160101 16:48:30< gfgtdf> vultraz: y
20160101 16:48:46-!- irker127 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160101 16:48:46< irker127> wesnoth: Charles Dang wesnoth:master 23f9cdefa66b / src/gui/widgets/ (25 files): gui2: removed never accessed code path and related functions http://git.io/vuUYo
20160101 16:48:47< irker127> wesnoth: Charles Dang wesnoth:master 0b3b251c59bf / src/gui/widgets/ (25 files): Merge pull request #573 from Vultraz/small_gui2_cleanup http://git.io/vuUYK
20160101 16:49:00< vultraz> ty
20160101 17:17:33-!- d4nf [~d4nf@ool-182ee6a9.dyn.optonline.net] has joined #wesnoth-dev
20160101 17:23:49-!- travis-ci [~travis-ci@ec2-54-87-72-53.compute-1.amazonaws.com] has joined #wesnoth-dev
20160101 17:23:50< travis-ci> wesnoth/wesnoth#8085 (master - 0b3b251 : Charles Dang): The build has errored.
20160101 17:23:50< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/99720565
20160101 17:23:50-!- travis-ci [~travis-ci@ec2-54-87-72-53.compute-1.amazonaws.com] has left #wesnoth-dev []
20160101 17:24:48-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20160101 17:31:40< vultraz> Aginor: I have discovered the cause of the final maximized bug
20160101 17:32:22< vultraz> Aginor: for some reason, the resized event is catching and setting the resolution to the 'old' window resolution when you change the res
20160101 17:33:05< vultraz> so set_resolution() stores the new res and then resized saves it again
20160101 17:42:00< vultraz> and this is really, really annoying >_>
20160101 17:42:13< vultraz> also, seems like there *might* be a case of MAXIMIZED not being handled
20160101 17:42:26 * vultraz is very disappointed
20160101 17:57:53-!- vincent_c [~bip@107.191.117.101] has quit [Ping timeout: 255 seconds]
20160101 17:59:53-!- Kwandulin [~Miranda@p200300760F250AE9FDB75A99D6C6F313.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160101 18:18:14-!- vincent_c [~bip@107.191.117.101] has joined #wesnoth-dev
20160101 18:24:48-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20160101 18:29:26-!- Kwandulin [~Miranda@p200300760F250AE97958587897B5926C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160101 19:50:21< Aginor> vultraz: yes, that needs to be removed for SDL2 now
20160101 19:50:54< Aginor> gfgtdf: can you give me an example of a broken story screen? 
20160101 19:51:20< Aginor> gfgtdf: what do you mean "loading screen is buggered"? It looks fine for me, can you give an example?
20160101 19:51:36< vultraz> Aginor: wait, what needs to be removed?
20160101 19:52:19< gfgtdf> Aginor: try to resze dring storyscrren
20160101 19:52:30< gfgtdf> Aginor: badsically rsiting is hobbly broken again in curent master
20160101 19:52:35< gfgtdf> reszing
20160101 19:53:10< gfgtdf> Aginor: i made multiple funyn screenshots but somehow imgur gives me an error wh i try to upload.
20160101 19:54:42< Aginor> gfgtdf: resizing during storyscreen has always been broken
20160101 19:55:00< Aginor> at least according to shadowm
20160101 19:55:05< gfgtdf> Aginor: not like that
20160101 19:56:35< gfgtdf> Aginor: also it worked much better 2 days ago on master
20160101 19:56:44< gfgtdf> ir 1 day ago no sure
20160101 19:56:46< gfgtdf> or*
20160101 19:57:10< Aginor> presumably because I'm now forcing the game to redraw, but the storyscreen doesn't
20160101 19:57:17< gfgtdf> Aginor: now resizing it horryb broken not only in storyscrtren
20160101 19:57:40< gfgtdf> Aginor: basically evnever a dialog is open
20160101 19:57:43< gfgtdf> whenever
20160101 19:57:55< Aginor> gfgtdf: what's horribly broken?
20160101 19:57:57< vultraz> uhhh
20160101 19:58:04< vultraz> gfgtdf: are you sure you ahve current master
20160101 19:58:06< vultraz> have*
20160101 19:58:13< gfgtdf> vultraz: yes
20160101 19:59:13< Aginor> and is it more or less "horribly broken" now than when I started?
20160101 19:59:59< gfgtdf> Aginor: what do you mean than when you stared ?
20160101 20:00:13< vultraz> Aginor: could you clarify what you mean above?
20160101 20:00:20< vultraz> (about 'needs to be removed for sdl2)
20160101 20:01:32< Aginor> vultraz: the call to the set_size/set resolution call needs to be removed for SDL2. I'm not sure it's ever been needed, but resizing in SDL1 has always been so broken for me that I cannot tell
20160101 20:02:20< vultraz> Aginor: but window->set_size() is what sets the resolution
20160101 20:02:27< vultraz> without that, how does it set window size?
20160101 20:03:02< vultraz> set_resolution just calls setMode which calls set_size
20160101 20:03:15< vultraz> _set_resolution is a different function that sets the prefs value
20160101 20:03:17< Aginor> gfgtdf: in the last few days I've been trying to fix the resize code under SDL2. I'm asking you if it is better or worse now. I would also appreciate it a lot if you could provide me with better feedback than "it's horribly broken with dialogs" because for me it isn't.
20160101 20:03:20< vultraz> set_resolution affects the window
20160101 20:03:33< Aginor> 06:31 < vultraz> Aginor: I have discovered the cause of the final maximized bug
20160101 20:03:36< Aginor> 06:32 < vultraz> Aginor: for some reason, the resized event is catching and  setting the resolution to the 'old' window resolution when you  change the res
20160101 20:03:50< vultraz> oh, I should have clarified
20160101 20:03:58< gfgtdf> Aginor: i'd say that current master with SDL2 is a little worse than 1.12.5
20160101 20:03:58< vultraz> it's setting the prefs variables to the old resolution
20160101 20:04:00< Aginor> vultraz: we should not have the resize event setting the resolution under SDL2.
20160101 20:04:04< vultraz> the window is set to the correct size
20160101 20:04:20< vultraz> but the prefs resolutions variables are set
20160101 20:04:23< vultraz> on resize
20160101 20:04:39< gfgtdf> Aginor: but master from 1 day ago worked even better than 1.12.5 iirc.
20160101 20:05:41< gfgtdf> Aginor: i'm currently building a17bd9233135e612a62b739fe95e772ea56bbce5 to check again
20160101 20:05:51< vultraz> Aginor: to sum it up, resize events don't change the resolution - they're only setting the resolution prefs variables. Meaning the resize event is suppose to be caught after using set_resolution to change a window's dimensions 
20160101 20:06:19< vultraz> BUT
20160101 20:06:24< vultraz> set_resolution calls setMode
20160101 20:06:38< vultraz> when you set it to"windowed" mode, 3 functions are called
20160101 20:07:00< Aginor> there's no need to call setMode when setting it to windowed any longer though
20160101 20:07:05< Aginor> you removed that yesterday
20160101 20:07:14< vultraz> I...did???
20160101 20:07:30< vultraz> I don't recall doing that
20160101 20:07:34< Aginor> by introducing the call to restore windows
20160101 20:07:39< vultraz> oh
20160101 20:07:41< vultraz> right
20160101 20:08:01< vultraz> I added that 
20160101 20:08:05< Aginor> you never actually started using the call though :)
20160101 20:08:15< vultraz> I did
20160101 20:08:25< Aginor> yes, once
20160101 20:08:32< Aginor> (I think)
20160101 20:08:54< vultraz> yes, before set_mode
20160101 20:09:10< vultraz> er
20160101 20:09:12< vultraz> set_size
20160101 20:09:14< vultraz> not mode
20160101 20:09:34< vultraz> so basically what happens:
20160101 20:09:51< vultraz> 	SDL_SetWindowFullscreen(window_, 0);
20160101 20:09:53< vultraz> 	SDL_RestoreWindow(window_);
20160101 20:09:54< vultraz> 	SDL_SetWindowSize(window_, w, h);
20160101 20:09:56< vultraz> 	SDL_SetWindowPosition(window_, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED);
20160101 20:09:58< vultraz> whenever you use set_resolution
20160101 20:10:39< Aginor> mmm
20160101 20:11:09< vultraz> now I *think* the problem is this
20160101 20:11:24< vultraz> well
20160101 20:11:25< Aginor> gfgtdf: I started the test scenario, opened up the preferences and resized. Works for me.
20160101 20:12:13< vultraz> ok so set_resolution sets its flags after calling setMode
20160101 20:12:56< vultraz> but for some reason, setMode's SDL calls trigger the resize event... AFTER the _set_resolution call in set_resolution, but with the old window dimensions :|
20160101 20:13:02< vultraz> I'm phrasing itbadly
20160101 20:13:12< vultraz> but basically, the old window dimensions get set as the "new" ones
20160101 20:13:45< Aginor> I'm not sure I'm following
20160101 20:13:51< Aginor> or maybe I am loosely
20160101 20:14:45< vultraz> the resolution variables get set twice
20160101 20:14:53< vultraz> first to the correct new value
20160101 20:15:00< Aginor> gfgtdf: I go to the title screen, open prferences, resize. Works for me.
20160101 20:15:04< vultraz> second to the old window size
20160101 20:15:58-!- gfgtdf [~chatzilla@f054138193.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
20160101 20:16:10< Aginor> vultraz: I'm not sure I'm buying that. I've never seen any such behaviour when I've been instrumenting the SDL events. The only way to possibly get that is by trying to set the window size programatically
20160101 20:20:37< vultraz> Aginor: http://pastebin.com/09RqX8yt
20160101 20:21:58< vultraz> wait... a second
20160101 20:22:00< Aginor> vultraz: did you also instrument event.window.data1 and event.window.data2?
20160101 20:22:02< vultraz> idea
20160101 20:22:10< vultraz> Aginor: instrument?
20160101 20:22:23< Aginor> vultraz: add debug stuff
20160101 20:24:41< vultraz> http://pastebin.com/hWbTHNwx
20160101 20:25:42< Aginor> vultraz: is this using the "set resolution" button?
20160101 20:25:57< vultraz> yes
20160101 20:26:03< Aginor> ah
20160101 20:26:10< vultraz> ah?
20160101 20:26:18< Aginor> that's broken :D
20160101 20:26:37< vultraz> :|
20160101 20:26:43< vultraz> due to what?
20160101 20:27:44< Aginor> I haven't looked at it in a long time, but I recall it doing a few silly things when trying to set the window state
20160101 20:27:55< Aginor> where's the entry point in code?
20160101 20:28:34< vultraz> the res dialog is dealt with in bool show_video_mode_dialog(display& disp) at preferences_display.cpp:119
20160101 20:32:54< Aginor> vultraz: what window state are you in when this happens?
20160101 20:33:19< Aginor> video.cpp:614 is looking interesting
20160101 20:33:27-!- gfgtdf [~chatzilla@f054138193.adsl.alicedsl.de] has joined #wesnoth-dev
20160101 20:33:44< gfgtdf> hmm i tested at that commit and it also had those problems.
20160101 20:33:45< Aginor> vultraz: the handling of that button (or the sequence of events) are looking much more sensible than what I recall
20160101 20:33:54< Aginor> gfgtdf: storyscreen is broken
20160101 20:33:57< gfgtdf> i'm sure i didnt have thise problems when i sid yesterday '20160101 03:49:23< gfgtdf> Aginor: i also tested that reszing worksnw much better'
20160101 20:34:02< gfgtdf> said*
20160101 20:34:22< vultraz> Aginor: that's something else that frustrates me to to no end
20160101 20:34:24< gfgtdf> maybe i did somethign different
20160101 20:34:36< vultraz> Aginor: it happens if you use the button on a wesnoth session that started maximized
20160101 20:34:37< Aginor> gfgtdf: I started the test scenario, opened up the preferences and resized. Works for me.
20160101 20:34:50< vultraz> Aginor: it does NOT happen if you use it on a wesnoth session that started windowed and then was maximized
20160101 20:34:58< Aginor> vultraz: and stays maximised? because you never change the window size
20160101 20:35:14< vultraz> Aginor: set_resolution calls setMode which changes window size
20160101 20:35:31< Aginor> 09:15 < Aginor> gfgtdf: I go to the title screen, open prferences, resize. Works for me.
20160101 20:35:34< vultraz> Aginor: in both cases, the window is set to the chosen dimensions
20160101 20:35:47< Aginor> gfgtdf: story screen is buggered
20160101 20:36:25< Aginor> gfgtdf: I can make the menu buttons and end turns disappear when I resize with a gui2 dialog (you can tell which they are because they stay centered).
20160101 20:36:37< Aginor> gfgtdf: so I'm not sure what you're claiming is broken
20160101 20:36:47< vultraz> Aginor: this is the output from the latter case http://pastebin.com/vawdtVAG
20160101 20:37:42< gfgtdf> Aginor: y i am currently a little confused myself. I thought 'll do more tests to know for sure whetzher i remembered it worng
20160101 20:37:50< vultraz> Aginor: compare to the output from the former (bugged) case http://pastebin.com/3LjRCbXw
20160101 20:37:55< vultraz> Aginor: I don't understand this
20160101 20:38:47-!- Kwandulin [~Miranda@p200300760F250AE97958587897B5926C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160101 20:41:03< vultraz> Aginor: actually, I might... have a possible cause
20160101 20:41:20< vultraz> Aginor: since all this is being tested in the titlescreen, it's also subject to GUI2's event handling
20160101 20:41:43< vultraz> Look what happens when you add logging to the MAXIMIZED and RESTORE events: http://pastebin.com/r0KEhg12
20160101 20:42:23< Aginor> vultraz: I think GUI2 window is still trying to set sizes
20160101 20:42:29< Aginor> let me dig up the code and check
20160101 20:42:31< vultraz> gui2's handling is gui/auxiliary/events/handler.cpp:399
20160101 20:42:39< vultraz> I ran into this before
20160101 20:42:42< vultraz> it set size twice
20160101 20:42:45< vultraz> I mean
20160101 20:42:54< vultraz> that code results in size being set twice
20160101 20:43:42< Aginor> yes, it should simply never be invoked
20160101 20:44:26< vultraz> are you saying setMode should never be invoked from set_resolution? 
20160101 20:44:36< vultraz> where, then, should it be called?
20160101 20:44:39< Aginor> no...
20160101 20:44:43< vultraz> oh
20160101 20:44:50< vultraz> nvm then
20160101 20:44:58< vultraz> you mean the gui2 handling?
20160101 20:45:03< Aginor> I'm saying that GUI2 should never invoke any of the set_resolution code as a result of an event
20160101 20:45:32< vultraz> ah
20160101 20:46:39< vultraz> commenting out that section of code and testing
20160101 20:48:02< vultraz> well that doesn't break anything but
20160101 20:48:07< vultraz> it doesn't fix the issue :|
20160101 20:48:21< gfgtdf> vultraz: which issue?
20160101 20:48:52< vultraz> gfgtdf: if you start wesnoth in a maximized window then set resolution, next time you start it it will be in the wrong resolution 
20160101 20:49:14< gfgtdf> vultraz: set resolutions via the poreferences dialog ?
20160101 20:49:20< vultraz> ya
20160101 20:49:29< gfgtdf> vultraz: i actually wonder why we have teh dialog in the first place
20160101 20:49:56< gfgtdf> vultraz: i mean that are teh advantges over resizing the windowsize via dragging
20160101 20:50:00< vultraz> gfgtdf: but that does NOT happen if you start wesnoth un-maximized, then maximize, and then set rsolution. if you do that, next time you start it it will be the correct resolution 
20160101 20:50:15< Aginor> gfgtdf: for non-native full screen
20160101 20:51:24-!- d4nf [~d4nf@ool-182ee6a9.dyn.optonline.net] has quit [Ping timeout: 245 seconds]
20160101 20:52:30< gfgtdf> Aginor: actually using the dialog in fullscreen does nothing here
20160101 20:52:45< vultraz> right
20160101 20:53:51< Aginor> gfgtdf: that's what vultraz is looking into
20160101 20:54:01< vultraz> um
20160101 20:54:12< vultraz> no it isn't :/
20160101 20:54:40< Aginor> vultraz: you are, it should all just work if you get it to work in the current case ;)
20160101 20:57:06< Aginor> heh
20160101 20:57:16< Aginor> making th storyscreen resize aware isn't fun
20160101 20:57:58< vultraz> the loadscreen isn't resize-aware either
20160101 20:58:20< gfgtdf> Aginor: hmm i really think we shoudl try to mkae it gui2, makin a widget that does teh test appear that was shouldnt be that hard
20160101 20:58:29< irker127> wesnoth: Charles Dang wesnoth:master 350c3acd229c / src/gui/ (dialogs/lobby_main.cpp widgets/window.cpp): Restrict GUI2 calls to set_resolution to SDL1.2 only http://git.io/vuTYe
20160101 20:58:36< Aginor> gfgtdf: go ahead
20160101 20:58:48< gfgtdf> Aginor: and uaually our plan i to move anythin to gui2 anyway
20160101 20:58:50< Aginor> gfgtdf: which test by the way?
20160101 20:58:59< gfgtdf> text*
20160101 21:02:45< irker127> wesnoth: Charles Dang wesnoth:master 7913841300c3 / src/gui/dialogs/lobby_main.cpp: Remove local handling of resize from GUI2 lobby http://git.io/vuTOl
20160101 21:03:44< vultraz> Aginor: I'd really appreciate it if you could ponder this issue as well
20160101 21:03:48< Aginor> gfgtdf: are you talking about re-doing the story screen?
20160101 21:03:51< vultraz> it's driving me nuts :|
20160101 21:03:54< Aginor> vultraz: ok
20160101 21:04:07< Aginor> vultraz: I'll drop the story screen for now ;)
20160101 21:04:45-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has joined #wesnoth-dev
20160101 21:04:52< gfgtdf> Aginor: well yes but im not say ing that i'll actually do this actually
20160101 21:05:18< Aginor> gfgtdf: raise a bug about it and maybe someone will pick it up
20160101 21:05:22< gfgtdf> Aginor: at lest for me there are more important gui2 related fixes i i would want to do some gui2 programming
20160101 21:13:19< Aginor> vultraz: I'm struggling to reproduce that here...
20160101 21:13:27< Aginor> vultraz: steps are this?
20160101 21:13:31< Aginor> 1. start wesnoth
20160101 21:13:34< Aginor> 2. maximize
20160101 21:13:37< Aginor> 3. exit
20160101 21:13:43< Aginor> 4. start wesnoth
20160101 21:13:49< Aginor> 5. change resolution
20160101 21:13:51< Aginor> ?
20160101 21:15:22< vultraz> Aginor: it only happens if wesnoth is already maximized at start
20160101 21:15:26< vultraz> so, start, maximize, quit
20160101 21:15:29< vultraz> start again, change res
20160101 21:15:41< Aginor> vultraz: it never starts maximized for me
20160101 21:16:45< Aginor> vultraz: if I manually maximize the window it never unmaximizes it though
20160101 21:17:24< vultraz> it won't start maximize if you maximze during the loading screen, FYI
20160101 21:17:29< vultraz> another unrelated issue >_>
20160101 21:17:36< vultraz> but that second thing is weird
20160101 21:17:38< vultraz> :|
20160101 21:17:39< Aginor> vultraz: I wait for the title screen every time
20160101 21:17:54< vultraz> o_o
20160101 21:18:21< vultraz> but how
20160101 21:18:24< vultraz> we have the same code
20160101 21:18:38< vultraz> you are on latest master, right
20160101 21:18:40< Aginor> set_mode does different actions than from what set_resolution tels preferences too
20160101 21:19:17< vultraz> hm?
20160101 21:22:34< Aginor> you always claim the window size changes, which isn't true
20160101 21:22:51< vultraz> it...does for me :|
20160101 21:23:05< vultraz> (not in fullscreen mode, of course)
20160101 21:28:51< Aginor> hmm
20160101 21:28:59< Aginor> get_flags doesn't do what you think it does
20160101 21:32:21< vultraz> that was there before I started my work
20160101 21:32:22< vultraz> and i left it
20160101 21:35:22< Aginor> I might have some changes to commit shortly
20160101 21:41:26< irker127> wesnoth: Andreas Löf wesnoth:master 4b2fabfd7eaf / src/ (events.cpp preferences.cpp sdl/window.cpp sdl/window.hpp video.cpp): Ask the window for it's state when trying to decide what the state is http://git.io/vuTCd
20160101 21:41:35< Aginor> it doesn't fix everything
20160101 21:41:40< Aginor> but try that ;)
20160101 21:41:55< Aginor> it's doing the right thing there now
20160101 21:42:51< Aginor> although I think you've got the chance of preferences and video disagreeing about what the current window state is
20160101 21:43:53-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20160101 21:47:18-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 256 seconds]
20160101 21:47:27-!- travis-ci [~travis-ci@ec2-54-197-112-133.compute-1.amazonaws.com] has joined #wesnoth-dev
20160101 21:47:28< travis-ci> wesnoth/wesnoth#8087 (master - 7913841 : Charles Dang): The build passed.
20160101 21:47:28< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/99748983
20160101 21:47:28-!- travis-ci [~travis-ci@ec2-54-197-112-133.compute-1.amazonaws.com] has left #wesnoth-dev []
20160101 21:55:16< vultraz> building
20160101 22:03:37< vultraz> Aginor: now fullscreen AND resolution setting is broken D: 
20160101 22:03:48< Aginor> vultraz: progress!
20160101 22:03:57< Aginor> (they all work for me)
20160101 22:04:02< vultraz> the wrong kind of progress!
20160101 22:04:05< vultraz> :P
20160101 22:04:16< Aginor> I think the calls to .restore() might be bad
20160101 22:07:43< vultraz> possibly
20160101 22:08:04< vultraz> I don't get how stuff can work for you let be totally broken for me
20160101 22:08:10< vultraz> yet*
20160101 22:11:22< vultraz> guess we have to keep working
20160101 22:12:12< Aginor> diffeernt OS and window manager
20160101 22:12:27-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160101 22:12:30< Aginor> I won't be able to do more wesnoth today, I need to do some consulting instead
20160101 22:13:55< vultraz> alright
20160101 22:14:01< vultraz> i need some sleep 
20160101 22:14:08< vultraz> and i have stuff to do today too
20160101 22:14:13< Aginor> yeah :)
20160101 22:14:16< Aginor> sleep is good
20160101 22:14:16-!- prkc [~prkc@catv-80-98-216-55.catv.broadband.hu] has quit [Remote host closed the connection]
20160101 22:14:27< vultraz> we're making progress, though :)
20160101 22:14:35-!- prkc [~prkc@catv-80-98-216-55.catv.broadband.hu] has joined #wesnoth-dev
20160101 22:16:14< Aginor> indeed
20160101 22:16:28< Aginor> we certainly are :)
20160101 22:17:22< Aginor> I still need to figure out why some of the game buttons disappear on a redraw when gui2 is in a dialog
20160101 22:20:29< Aginor> and rework the story screen to work redraw itself nicely
20160101 22:20:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160101 22:21:09< Aginor> it's a bit awkward that there's no toplevel entity that manages drawing order, but everything happens through the order of regstered event handlers
20160101 22:21:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160101 22:27:18< zookeeper> celticminstrel, as i've mentioned to vultraz, [message] now fails to TC sprites (when the speaker doesn't have a portrait).
20160101 22:27:40-!- travis-ci [~travis-ci@ec2-50-19-55-155.compute-1.amazonaws.com] has joined #wesnoth-dev
20160101 22:27:41< travis-ci> wesnoth/wesnoth#8088 (master - 4b2fabf : Andreas Löf): The build was fixed.
20160101 22:27:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/99752945
20160101 22:27:41-!- travis-ci [~travis-ci@ec2-50-19-55-155.compute-1.amazonaws.com] has left #wesnoth-dev []
20160101 22:39:02-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160101 22:39:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160101 23:20:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160101 23:20:15-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 240 seconds]
20160101 23:21:47-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160101 23:31:43-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has joined #wesnoth-dev
20160101 23:47:37-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160101 23:57:01-!- new_one [~new_one@162.243.146.104] has quit [Ping timeout: 250 seconds]
20160101 23:57:20-!- new_one [~new_one@2604:a880:1:20::22e:d001] has joined #wesnoth-dev
20160101 23:58:52-!- ypnos_ [~ypnos@lme51.informatik.uni-erlangen.de] has joined #wesnoth-dev
--- Log closed Sat Jan 02 00:00:07 2016