--- Log opened Sat Nov 03 00:00:46 2018 20181103 00:05:16-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20181103 00:11:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181103 00:18:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181103 00:43:27< mattsc> celticminstrel: I entirely agree with your last comment and was thinking this too. And if we’re talking about ‘station_x/y’, it makes perfect sense to just call it ‘station’. But for ‘return_x/y’ calling it just ‘return’ sounds … weird. 20181103 00:43:37< mattsc> But it might be the way to go anyway/ 20181103 00:44:08< celticminstrel> I see what you mean about return_x/y. 20181103 00:44:28< mattsc> I’m going to bundle and squash all the MAIs together for this anyway, so changing that is no problem. 20181103 00:45:11< celticminstrel> Not sure what you mean by that. 20181103 00:45:34< mattsc> I mean it’s no extra work to change that. 20181103 00:45:50< mattsc> Since I already need to squash commits anyway. 20181103 00:46:07< mattsc> Not that it’s all that much work to squash in the first place … 20181103 01:29:35< mattsc> celticminstrel: so since you say id is used in other places, how about just ‘return_id’, ‘station_id’, … ? 20181103 01:36:07< irker083> wesnoth/wesnoth:1.14 Jyrki Vesterinen a0cc8cbdff battle_context: implement move construct AppVeyor: All builds passed 20181103 01:37:51< mattsc> Of course, there’re enemy_x/y and healer_x/y in the bottleneck MAI, and healer_id and enemy_id is a bit misleading. 20181103 01:58:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181103 02:43:56< celticminstrel> mattsc: Hmm, maybe? It doesn't really evoke "location" as well, but perhaps it would be okay. 20181103 02:44:27< celticminstrel> ...and then I saw your followup comment and more or less changed my mind. 20181103 02:44:32< celticminstrel> That's probably too misleading. 20181103 02:49:56< mattsc> So … abc_loc_id? 20181103 02:51:41 * celticminstrel shrugs. 20181103 02:51:49< celticminstrel> I'm okay with that or abc_loc. 20181103 02:59:17< mattsc> Okay. Probably the latter then, it’s shorter. 20181103 03:11:37< irker083> wesnoth/wesnoth:1.14 Steve Cotton 1c8c73bc44 Tutorial S2: Hints about whether to leve AppVeyor: All builds passed 20181103 03:48:37< celticminstrel> The --wconsole flag doesn't seem to work when I launch through Visual Studio. Any idea why? 20181103 03:48:56< celticminstrel> Visual Studio Code, I mean. 20181103 03:50:46< celticminstrel> It does work if I launch from the integrated terminal though, at least. 20181103 03:54:44< irker083> wesnoth: Celtic Minstrel wesnoth:master 420afdf88e72 / data/core/macros/ai_controller.cfg: Deprecate {AI_CONTROLLER} and related macros (addresses #3668) https://github.com/wesnoth/wesnoth/commit/420afdf88e7214e7ff7ff01c6dbcd9d2a8c28dd7 20181103 04:04:03<+wesdiscordbot> I don't know 20181103 04:08:17<+wesdiscordbot> celmin: I said 1.15 not 1.17 20181103 04:08:53<+wesdiscordbot> forgot to reiterate that earlier 20181103 04:09:56< celticminstrel> You can't deprecate something for removal in the release you're releasing. That doesn't make any sense whatsoever. 20181103 04:10:53< celticminstrel> If we go for a rolling-release cycle it could be changed to 1.16, though. 20181103 04:15:01<+wesdiscordbot> technically it would be deprecated in 1.15 and removed in 1.16 20181103 04:15:44< celticminstrel> The deprecated directive takes the version it's to be removed in, not the version it's deprecated in. 20181103 04:20:28< irker083> wesnoth/wesnoth:1.14 Steve Cotton cbd4efa6bf Tutorial S2: Hints about whether to leve AppVeyor: All builds passed 20181103 04:55:19< celticminstrel> Got all the command-line flag handling done for the schema validator. 20181103 04:55:40< celticminstrel> Supported modes are: --validate --use-schema 20181103 04:55:43< celticminstrel> --validate-core 20181103 04:55:50< celticminstrel> --validate-addon 20181103 04:56:02< celticminstrel> --validate-schema 20181103 04:56:22< celticminstrel> Just need to finish the schema schema validator and then it should be ready... :/ 20181103 04:56:38< celticminstrel> (ie, the actual implementation behind --validate-schema) 20181103 04:57:21< celticminstrel> I'm probably not going to do a second-pass validation of the core WML. 20181103 04:58:21<+wesdiscordbot> would --validate-core be something to add to travis? 20181103 04:58:24< celticminstrel> FTR, --validate and --validate-schema are command-line tools (they don't launch the game), while --validate-core and --validate-addon perform the validation through the config cache as you load various things. 20181103 04:58:39< celticminstrel> --validate-core could be added to Travis, yes. 20181103 04:59:04< celticminstrel> Though by itself it's not sufficient for that TBH. 20181103 04:59:17< celticminstrel> ... 20181103 04:59:19< celticminstrel> Well... 20181103 04:59:30< celticminstrel> Maybe if combined with various other flags and run multiple times. 20181103 04:59:42< celticminstrel> Like --validate-core --campaign= 20181103 04:59:49< celticminstrel> Or --validate-core --multiplayer 20181103 04:59:53< celticminstrel> Or --validate-core --editor 20181103 05:00:32< celticminstrel> But by themselves those lines won't exit the game, they'll just keep running... 20181103 05:01:26< celticminstrel> I think --validate-core --test would validate all the test scenarios 20181103 05:01:40< celticminstrel> And --validate-core --tutorial (if that exists) would validate the tutorial. 20181103 05:02:40< celticminstrel> Maybe I can improve on it somehoe, I dunno; but right now, as I mentioned a minute ago, --validate-core and --validate-addon run "in the background" while you're using the game. 20181103 05:02:50< celticminstrel> ^somehow 20181103 05:04:06< celticminstrel> tl;dr --validate-core is something that would be good to add to Travis BUT it's not really ready for that ATM. 20181103 05:08:01<+wesdiscordbot> alright 20181103 05:08:48< celticminstrel> If the Lua Plugin API supported campaigns, that would probably help with validating core actually. 20181103 05:09:10< celticminstrel> You could run --validate-core --plugin=validate.lua and it would load every campaign, start an MP game, and open the editor, then quit. 20181103 05:09:49< celticminstrel> Maybe two MP games - one on the default map and one on ANL. 20181103 05:11:35<+wesdiscordbot> what about running --validate on the cache files? 20181103 05:11:36< celticminstrel> (Obviously the plugin API would also need to support the editor for that... though the editor is probably the least important area to validate, so I guess it could be skipped.) 20181103 05:11:47<+wesdiscordbot> or anything > 69 bytes, at least 20181103 05:11:55< celticminstrel> Actually, you probably could use --validate instead for this. 20181103 05:12:27< celticminstrel> My example had --validate in conjunction with --use-schema, but if you just use --validate it defaults to the core schema, and it additionally honours --preprocessor-defines. 20181103 05:13:05< celticminstrel> So for every campaign, run "wesnoth --validate=data/_main.cfg --preprocessor-defines=CAMPAIGN_DEFINE" 20181103 05:14:41< celticminstrel> And also run one for MULTIPLAYER, one for ANL's define, one for the EDITOR define, one for the TEST define. Maybe also one for no defines. 20181103 05:15:34< celticminstrel> You could even go further and validate every campaign on every difficulty. 20181103 05:15:55< celticminstrel> Not sure if that's worthwhile, as the differences per difficulty are generally quite small, but... it's a possibility. 20181103 05:16:38< celticminstrel> (I doubt --validate would work on the actual cache files, though.) 20181103 05:16:48< celticminstrel> (Also, --validate bypasses the cache entirely.) 20181103 05:16:56< celticminstrel> (As does --validate-schema.) 20181103 05:17:13< celticminstrel> (Which BTW could also be something to add to Travis.) 20181103 05:18:48< celticminstrel> Thinking about --validate and --validate-schema, I feel like it might be a bit weird how it takes an arbitrary filepath but then evaluates it in the WML virtual filesystem, so any macro inclusions in that file will be expanded relative to the data and userdata directories... 20181103 05:19:08< celticminstrel> Should I make it take a filepath in the virtual filesystem instead? 20181103 05:19:11< celticminstrel> I dunno. 20181103 05:19:16< celticminstrel> Anyway sleeo. 20181103 05:19:20-!- celticminstrel is now known as celmin|sleep 20181103 05:19:23< celmin|sleep> ^sleep 20181103 05:19:25<+wesdiscordbot> Could you add an issue on github with all this info when it's ready? 20181103 05:19:39<+wesdiscordbot> this seems like something that would be great to have automated 20181103 05:19:42< celmin|sleep> You mean, after the PR is merged? 20181103 05:19:49<+wesdiscordbot> yeah 20181103 05:19:54< celmin|sleep> 'kay 20181103 05:20:01<+wesdiscordbot> thanks 20181103 06:10:24< irker083> wesnoth/wesnoth:master mattsc 1112c336d9 Return Guardian MAI: support named locat AppVeyor: All builds passed 20181103 06:12:18<+wesdiscordbot> celmin, for https://github.com/wesnoth/wesnoth/issues/3668 how about letting the player (optionally?) control the AI sides ? 20181103 06:13:20<+wesdiscordbot> Not sure how that would affect balancing (player may be smarter than the AI) 20181103 06:13:53<+wesdiscordbot> If it makes the scenarios too long the player could be given the option of droiding the ally side at some points 20181103 06:27:11-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20181103 06:55:18-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20181103 07:08:33< irker083> wesnoth: josteph wesnoth:master 9e8db93893b5 / src/help/help_impl.cpp: help: Call gettext on ToD topic strings that are already marked translatable https://github.com/wesnoth/wesnoth/commit/9e8db93893b5d88c24fc7db043aedd330cde4a48 20181103 07:31:30<+wesdiscordbot> Unfortunately that crap is back 20181103 07:33:18<+wesdiscordbot> Very unfortunate 20181103 07:58:41< irker083> wesnoth: Iris Morelle wesnoth:master 8033e252d4c7 / changelog.md src/display.cpp: Fix [change_theme] requiring a separate action to refresh the UI afterwards https://github.com/wesnoth/wesnoth/commit/8033e252d4c70fc16f26775ca8fde58b6e41f91d 20181103 07:58:44< irker083> wesnoth: Iris Morelle wesnoth:master c0fd17628e63 / src/display.cpp: Fix [change_theme] not updating themed map borders correctly in some cases https://github.com/wesnoth/wesnoth/commit/c0fd17628e633a9812448d481331c22ee49cedb8 20181103 08:04:11<+wesdiscordbot> @Vultraz I have no idea how easy or hard it will be to (re)-fix.. but let's look at the bright side, at least master is playable again 20181103 08:04:33<+wesdiscordbot> Those particular bugs are unfixable 20181103 08:04:44<+wesdiscordbot> With the current API 20181103 08:04:58<+wesdiscordbot> It’s not particularly important 20181103 08:05:12<+wesdiscordbot> But they’ve been plaguing us for years and I had been glad to fix them 20181103 08:05:17<+wesdiscordbot> But again, not important 20181103 08:06:05<+wesdiscordbot> Understood 20181103 08:06:20<+wesdiscordbot> It must be frustrating to see them again after they've already been fixed 😦 20181103 08:07:11<+wesdiscordbot> Indeed 20181103 08:10:12<+wesdiscordbot> by the way, when's 1.14.6 going to be? 20181103 08:10:48<+wesdiscordbot> have a PR or two I need to merge before that 20181103 08:12:22-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20181103 08:13:10-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Client Quit] 20181103 08:14:27-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20181103 08:36:35< irker083> wesnoth/wesnoth:1.14 Nils Kneuper ba6d4bb4fa updated Chinese (Traditional) translatio AppVeyor: All builds passed 20181103 09:58:37<+wesdiscordbot> @josteph it's not been scheduled 20181103 10:23:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181103 10:33:02< Ravana_> it was possible to undroid sides with 1.12, I suspect it was not intentionally disabled 20181103 10:49:15< irker083> wesnoth/wesnoth:master Celtic Minstrel 420afdf88e Deprecate {AI_CONTROLLER} and related ma AppVeyor: All builds passed 20181103 11:38:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181103 12:58:47<+wesdiscordbot> @Vultraz It would be good to have more than one week for the translators this time 20181103 13:06:11< celmin|sleep> @jostephd - Not really what I was thinking, but certainly a possibility for the mainline uses of AI_CONTROLLER. 20181103 13:08:45< celmin|sleep> Uh... @josteph that is. 20181103 13:09:09<+wesdiscordbot> Sure, sevu, but I don’t anticipate it soon 20181103 13:09:49-!- celmin|sleep is now known as celticminstrel 20181103 13:49:34-!- irker083 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20181103 14:09:33-!- gfgtdf [~Daniel@xd527914a.dyn.telefonica.de] has joined #wesnoth-dev 20181103 14:46:05-!- irker110 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20181103 14:46:05< irker110> wesnoth/wesnoth:1.14 nemaara a5f8156d4f TSG S7b: adjusted gold values AppVeyor: All builds passed 20181103 15:29:36<+wesdiscordbot> maybe have it around the same time as 1.15.0? 20181103 16:07:07-!- buhman [~rewt@c-73-162-194-50.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 20181103 16:08:57-!- buhman [~rewt@c-73-162-194-50.hsd1.ca.comcast.net] has joined #wesnoth-dev 20181103 16:16:40< irker110> wesnoth/wesnoth:master Iris Morelle c0fd17628e Fix [change_theme] not updating themed m AppVeyor: All builds passed 20181103 17:48:56<+wesdiscordbot> Regarding logging on the Steam release on linux, the instructions at https://forums.wesnoth.org/viewtopic.php?f=4&t=46166#w0steamunix say to modify the launch options in Steam in order to have logs. Would it be possible to instead always do that in the start.sh script? 20181103 17:50:28<+wesdiscordbot> @loonycyborg You're the Steam packager on GNU/Linux. Can you answer Penta's question above? 20181103 17:51:22<+wesdiscordbot> I'm asking particularly in regards to https://github.com/wesnoth/wesnoth/issues/3685#issuecomment-435606902 20181103 18:00:44-!- travis-ci [~travis-ci@ec2-107-20-116-200.compute-1.amazonaws.com] has joined #wesnoth-dev 20181103 18:00:45< travis-ci> gfgtdf/wesnoth#1410 (skip_unit_attribute - 77b64cf : gfgtdf): The build is still failing. 20181103 18:00:45< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/450268658 20181103 18:00:45-!- travis-ci [~travis-ci@ec2-107-20-116-200.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181103 18:03:51<+wesdiscordbot> I can but not sure where to direct it better 20181103 18:04:04<+wesdiscordbot> also perhaps steam has own support for keeping logs 20181103 18:04:39<+wesdiscordbot> I don't think it's good idea to place it in user's home dir 20181103 18:11:13< irker110> wesnoth: jostephd wesnoth:1.14 0601bbccd6b1 / data/campaigns/Heir_To_The_Throne/scenarios/06_The_Siege_of_Elensefar.cfg: HttT S6: Point out exactly where the ford is. (#3677) https://github.com/wesnoth/wesnoth/commit/0601bbccd6b13aa3f3039557a02235f82a69596c 20181103 18:11:47< irker110> wesnoth: jostephd wesnoth:master 8a4fd24b2b19 / data/campaigns/Heir_To_The_Throne/scenarios/06_The_Siege_of_Elensefar.cfg: HttT S6: Point out exactly where the ford is. (#3677) https://github.com/wesnoth/wesnoth/commit/8a4fd24b2b1964f7278345e744089ec3e530e71b 20181103 18:13:46<+wesdiscordbot> what about in the preferences directory? 20181103 18:14:00<+wesdiscordbot> or the game install directory 20181103 18:17:51< irker110> wesnoth: josteph wesnoth:master 801e1c62345c / data/ (2 files in 2 dirs): WML: {REMOVE_LABEL} now takes an optional EXTRA_WML argument. https://github.com/wesnoth/wesnoth/commit/801e1c62345c4bddfa9e0bce2162b041bd750546 20181103 18:17:53< irker110> wesnoth: josteph wesnoth:master d00c540107f9 / changelog.md: Update changelog for last commit https://github.com/wesnoth/wesnoth/commit/d00c540107f9b3fe8f21ede987d93217620b5467 20181103 18:18:48<+wesdiscordbot> X11 puts its logs in ~/.local/share/xorg/ 20181103 18:19:08<+wesdiscordbot> which doesn't sound right, /usr/local/share/xorg/ is not where log files go 20181103 18:19:33<+wesdiscordbot> It's the .local directory in your home directory. 20181103 18:19:43<+wesdiscordbot> (It's hidden because its name starts with a dot.) 20181103 18:20:45<+wesdiscordbot> Yes, I know that, but I assume ${HOME}/.local/share/ should be analogous to /usr/local/share/ 20181103 18:21:04<+wesdiscordbot> it should? 20181103 18:21:16<+wesdiscordbot> as in, they should point to the same location? 20181103 18:21:18<+wesdiscordbot> no 20181103 18:21:26<+wesdiscordbot> There's no logs place in the XDG specification is there? 20181103 18:21:26<+wesdiscordbot> I mean, what kinds of files they should contain 20181103 18:21:40<+wesdiscordbot> @shadowm Nope. Just checked. XDG_CACHE_HOME is closest, I think 20181103 18:22:20<+wesdiscordbot> @Pentarctagon /usr/share/ contains a directory per package, that contains read-only data for that app. ~/.local/share/ should be the same for apps that are installed by the user 20181103 18:23:10<+wesdiscordbot> You could use the data dir like we already do on Windows 20181103 18:23:54<+wesdiscordbot> log_windows.cpp, lg::finish_log_file_setup() 20181103 18:24:00<+wesdiscordbot> cpp const std::string log_dir = filesystem::get_user_data_dir() + "/logs"; 20181103 18:24:44<+wesdiscordbot> Do note that the system I wrote for Windows is a bit more elaborate than that 20181103 18:24:50<+wesdiscordbot> Because it includes log rotation 20181103 18:25:58<+wesdiscordbot> If you extended this to Linux and Mac it would make instructions for accessing the logs far easier to convey in forum posts/bug reports 20181103 18:26:49<+wesdiscordbot> But there's also a lot of platform-specific code in there because Windows 20181103 18:29:48<+wesdiscordbot> (For those who don't know why I wrote all that, it's because on Windows stderr and stdout are impossible to get if your executable image isn't marked to use the "console" susbystem unless you do a lot of non-trivial crap yourself, and we needed to handle all of that ourselves after the crummy code SDL 1.2 used (which caused issues with FS permissions and necessitated UAC FS virtualization because it used the current 20181103 18:29:48<+wesdiscordbot> working directory as the location for the log files) disappeared once we switched to SDL 2.0.) 20181103 18:34:01< irker110> wesnoth/wesnoth:master newfrenchy83 b94a1fa9a1 Revert don't sroll in teleport bevause b AppVeyor: All builds passed 20181103 18:49:31< irker110> wesnoth: gfgtdf wesnoth:master 469c8a3c8ef6 / src/server/ (game.cpp game.hpp): fix mpserver errormessage https://github.com/wesnoth/wesnoth/commit/469c8a3c8ef6496fb4faa166932473b77edc26fd 20181103 18:49:33< irker110> wesnoth: gfgtdf wesnoth:master d67276b25bf8 / src/play_controller.cpp: fix possible oos when giving side to an oberver when a player left https://github.com/wesnoth/wesnoth/commit/d67276b25bf8d91a5a94327f954e8ce2d69bd647 20181103 19:01:17<+wesdiscordbot> @shadowm porting this stuff to non-windows sounds like a nice idea. How hard of a task that would be? 20181103 19:01:49<+wesdiscordbot> because that's exactly what makes me dislike the idea of just redirecting it somewhere in start.sh 20181103 19:01:51<+wesdiscordbot> If my memory serves the only Windows-specific parts are the ones that deal with the file description switcharoo and --wconsole 20181103 19:02:07<+wesdiscordbot> *file descriptor 20181103 19:02:21<+wesdiscordbot> lack of log rotatation and stuff 20181103 19:04:23<+wesdiscordbot> And the reason the file descriptor switcharoo is a thing is that Wesnoth needs to log ASAP and on Windows there's no way to get logs out if something fails before the user data dir is created/initialized 20181103 19:04:40<+wesdiscordbot> So the initial logs are written to the user profile's temporary dir 20181103 19:04:40<+wesdiscordbot> there's a MessageBox() call in there 20181103 19:05:34<+wesdiscordbot> Then once the user data dir's final location is known the logs are redirected to NUL as a first step, because Windows holds exclusive locks on open files 20181103 19:05:46<+wesdiscordbot> Then they are moved to their final location and redirected back to the files on the new location 20181103 19:06:18<+wesdiscordbot> (People who've tried to delete or rename a file while an application is using it on Windows should know exactly what I mean) 20181103 19:08:31<+wesdiscordbot> I had some fun time messing with dll replacement long time ago because apparently they were locked even when application using them wasn't running 20181103 19:08:38<+wesdiscordbot> I meant to replace the MessageBox() call with a SDL 2 message box API call once we dropped support for SDL 1.2, but my interest in contributing died out first 20181103 19:09:35<+wesdiscordbot> I also wanted to add more SDL 2 message box API calls for early failures since e.g. on Linux the only indication that Wesnoth was unable to start, if you are not looking at stderr somehow, is that you won't see the main window. 20181103 19:10:15<+wesdiscordbot> what does sdl2 message box use on linux? 20181103 19:10:43<+wesdiscordbot> If I remember correctly it uses xlib or xcb directly to draw a crude dialog. Don't quote me on that though. 20181103 19:11:35<+wesdiscordbot> Or writes to the console if somehow the video driver is not X11 or it wasn't possible to connect to the X11 server, etc. 20181103 19:13:16<+wesdiscordbot> "But what about wayland" -- I'm NVIDIA blob trash, I don't know anything about Wayland other than that even taking NVIDIA out of the equation it's still a work in progress to get it to the same level of usability (for the average user) X11 is atright now 20181103 19:13:50<+wesdiscordbot> Also I think directfb is dead 20181103 19:14:13<+wesdiscordbot> So that only leaves X11 and Wayland as video drivers that anyone should care about on Linux 20181103 19:14:20<+wesdiscordbot> And there is XWayland for anyone who needs X compatibility, for now anyway. 20181103 19:14:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181103 19:15:50<+wesdiscordbot> xwayland will be a must for long time yet 20181103 19:16:04<+wesdiscordbot> and sdl would have a lot more stuff to implement on wayland 20181103 19:16:09<+wesdiscordbot> than just dialog boxes 20181103 19:16:17<+wesdiscordbot> also clientside window decorations 20181103 19:16:23<+wesdiscordbot> somewhat tangentially: https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Weston-More-Developers 20181103 19:16:36<+wesdiscordbot> otherwise sdl apps will look like crap on GNOME 20181103 19:17:11<+wesdiscordbot> When you put it like that I can't tell if you're talking about Wayland or Windows 3.11 20181103 19:19:16<+wesdiscordbot> I seem to recall reading that back in the day, before the Windows 95 USER revamp, window frames were each application's responsibility 20181103 19:20:05<+wesdiscordbot> And that it was the W95/NT 4.0 implementation that moved their message loop to the operating system itself 20181103 19:20:43<+wesdiscordbot> (Except when special snowflake applications decide that they need to have their own non-standard UI, which happens all the time even today.) 20181103 19:21:07<+wesdiscordbot> Including Discord. 😛 20181103 19:21:13<+wesdiscordbot> And Steam 20181103 19:21:50<+wesdiscordbot> it's ongoing philosophial debate: client-side window decorations on GNOME vs server-side window decorations on KDE 20181103 19:22:01<+wesdiscordbot> still it doesn't imply all apps drawing own stuff 20181103 19:22:09<+wesdiscordbot> because they use gui toolkits 20181103 19:22:20<+wesdiscordbot> Needless to say I wasn't impressed when I found out that Gnome 3 promoted/enforced client-side window decorations. 20181103 19:22:21<+wesdiscordbot> sdl is just caught in this bad situation 20181103 19:22:33<+wesdiscordbot> because it's not a gui toolkit yet does own GUI 20181103 19:22:46<+wesdiscordbot> At least it would be nice if there was a toolkit-agnostic window decoration library. 20181103 19:22:59<+wesdiscordbot> I have used Gnome 3 a bit and I can't deny that the way they use CSD looks cool 20181103 19:23:00<+wesdiscordbot> Otherwise programs are simply going to look different depending on toolkit. 20181103 19:23:09<+wesdiscordbot> But it's not practical from an architectural standpoint 20181103 19:23:35<+wesdiscordbot> And also only helps exacerbate the preexisting issue of UI inconsistency on Linux 20181103 19:23:46<+wesdiscordbot> GNOME doesn't offer any way for apps to look native on it other than use GTK 20181103 19:23:53<+wesdiscordbot> wrt decorations 20181103 19:24:25<+wesdiscordbot> probably sdl will have to have module that uses gtk to draw dialog boxes and decorations 20181103 19:24:44<+wesdiscordbot> or perhaps reuse a third party lib that does it for all users like SDL 20181103 19:25:02<+wesdiscordbot> I'm not happy with "We Hate 3rd-Party Devs" Toolkit ever becoming a de facto standard either 20181103 19:25:27<+wesdiscordbot> But I guess they were already on that position thanks to KDE being... KDE. Even before Gnome 3 20181103 19:26:07<+wesdiscordbot> there's a protocol for app for determining which way to use 20181103 19:26:13<+wesdiscordbot> so sdl could be like 20181103 19:26:36<+wesdiscordbot> if it sees serverside decorations are supported then it just proceeds as before 20181103 19:26:38<+wesdiscordbot> (I mean I love Plasma but sometimes the devs seem to forget that a lot of their audience are people who expect the same level of quality macOS and Windows have/used to have) 20181103 19:26:52<+wesdiscordbot> if not it whips up its sdl support and draws window with it 20181103 19:27:38<+wesdiscordbot> @loonycyborg Sure, it can be done. It's just... bad that SDL developers need to do all that extra work. 20181103 19:28:21<+wesdiscordbot> it's a consequence of linux not having an agreed upon api for those things 20181103 19:28:35<+wesdiscordbot> even using xcb directly might get obsolete soon 20181103 19:28:43<+wesdiscordbot> "but ecosystem fragmentation is a feature" 20181103 19:28:52<+wesdiscordbot> "more options for everyone" 20181103 19:29:10<+wesdiscordbot> well I expect it will naturally standardize eventually 20181103 19:29:33<+wesdiscordbot> (I'm pretty much directly quoting the average Linux advocate who doesn't actually write UI applications.) 20181103 19:29:56<+wesdiscordbot> like many projects doing same thing tend to eventually converge 20181103 19:30:04<+wesdiscordbot> with many redundant ones dying off 20181103 19:30:15<+wesdiscordbot> gtk vs qt is very unusual situation 20181103 19:30:31<+wesdiscordbot> There's some ideological background to it 20181103 19:30:40<+wesdiscordbot> When KDE started, Qt was non-free 20181103 19:30:55<+wesdiscordbot> Gnome was started because KDE depended on non-free components 20181103 19:31:33<+wesdiscordbot> but I think there were more philosophical differences than that 20181103 19:31:46<+wesdiscordbot> People wanted a desktop environment for GNU so anything Qt-based was a big no-no 20181103 19:31:55<+wesdiscordbot> because otherwise gnome would just die after kde and qt going 100% opensource 20181103 19:32:13<+wesdiscordbot> By the time Qt's licensing model changed Gnome had already gained traction across several major Linux distributions 20181103 19:32:49<+wesdiscordbot> And KDE gained reputation for being a buggy mess later on, even before KDE 4 20181103 19:33:36<+wesdiscordbot> (Which, you know, was supposed to be a beta, but people didn't get the memo because the KDE devs were not particularly at PR at the time.) 20181103 19:33:43<+wesdiscordbot> *good at 20181103 19:33:52<+wesdiscordbot> kde is a lot more classic currently than gnome 20181103 19:34:02<+wesdiscordbot> By then Ubuntu had already become big 20181103 19:34:09<+wesdiscordbot> like it still provides taskbar and things like that 20181103 19:34:19<+wesdiscordbot> GNOME works already in totally different way 20181103 19:34:19<+wesdiscordbot> And because it was Debian-based, it was already using Gnome 20181103 19:34:26<+wesdiscordbot> might be even better for new people 20181103 19:34:47<+wesdiscordbot> but oldfags like me who are getting too lazy to learn would feel more comfortable on kde 😛 20181103 19:34:51<+wesdiscordbot> And then Ubuntu kept becoming bigger and bigger and using Gtk and Gnome applications even when they switched to Unity and eventually to Gnome 3 20181103 19:34:53<+wesdiscordbot> Don't say that word 20181103 19:35:15<+wesdiscordbot> actually 20181103 19:35:21<+wesdiscordbot> this kinda another point 20181103 19:35:30<+wesdiscordbot> Unity managed to die off 20181103 19:35:39<+wesdiscordbot> so GNOME could too 20181103 19:35:49<+wesdiscordbot> No, it was because of all the nonstandard shit it brought to the table 20181103 19:36:27<+wesdiscordbot> Ubuntu packages are/were full of patches to make applications do special stuff on Unity that they couldn't on any other desktop environment 20181103 19:36:51<+wesdiscordbot> Hello., lots of familiar name here 😃 20181103 19:37:11<+wesdiscordbot> That was a maintenance nightmare for packagers, and the patches weren't getting upstreamed because, again, special snowflake desktop environment 20181103 19:37:35<+wesdiscordbot> Unity was made for Ubuntu by Canonical 20181103 19:37:39<+wesdiscordbot> hi 😛 20181103 19:37:51< irker110> wesnoth/wesnoth:master newfrenchy83 59aaeafc3f Revert don't sroll in teleport bevause b AppVeyor: All builds passed 20181103 19:37:55<+wesdiscordbot> Unlike Gnome and Plasma which are full desktop environents of their own and usable on any platform 20181103 19:38:00<+wesdiscordbot> I haven't followed the game for quite a while, I heard that you are moving to Godot? 20181103 19:38:03<+wesdiscordbot> Without weird invasive patches 20181103 19:38:45<+wesdiscordbot> And with the whole Mir fiasco etc. it became clear that Canonical's NIH syndrome would become its own downfall 20181103 19:38:59<+wesdiscordbot> @Nephro Moving to Godot is currently being evaluated by creating a prototype. 20181103 19:39:10-!- travis-ci [~travis-ci@ec2-23-20-141-244.compute-1.amazonaws.com] has joined #wesnoth-dev 20181103 19:39:11< travis-ci> wesnoth/wesnoth#20060 (master - d67276b : gfgtdf): The build passed. 20181103 19:39:11< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/450288119 20181103 19:39:11-!- travis-ci [~travis-ci@ec2-23-20-141-244.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181103 19:39:25<+wesdiscordbot> Development on 1.15 continues in parallel 20181103 19:39:37<+wesdiscordbot> So yeah that's where we are today. Unity is dead (except on LTS) and Gnome's status as the king of Linux desktop environments is pretty much consolidated in spite of its flawed design philosophy. 20181103 19:39:50<+wesdiscordbot> Thanks, Canonical. 20181103 19:40:24<+wesdiscordbot> And Mir still exists. 20181103 19:40:28<+wesdiscordbot> 😄 20181103 19:40:40<+wesdiscordbot> I don't see it going anywhere 20181103 19:40:50<+wesdiscordbot> I read today that apparently Mir devs recommend using Mir's support for Wayland 20181103 19:41:08<+wesdiscordbot> So what is the point of Mir again? Do the devs even remember anymore? 20181103 19:41:17<+wesdiscordbot> canonical really like trying to take control of important parts of desktop linux 20181103 19:41:40<+wesdiscordbot> I guess they just wanted to "invest" their money in something. 20181103 19:41:41<+wesdiscordbot> and fail hard because they don't have enough hands or good enough software design skills 20181103 19:41:47<+wesdiscordbot> @Pentarctagon I've read on the mailing lists that there is a need for a MySql coonector for Godot. Who might know more about that, I'd be interested in working on that. 20181103 19:41:50<+wesdiscordbot> Also does anyone else remember when they had Upstart for a few years and then decided to drop it in favour of systemd because it was too much of a maintenance burden? 20181103 19:41:53< irker110> wesnoth: Celtic Minstrel wesnoth:schema 028e51e2b545 / / (12 files in 7 dirs): Add a validator subclass specialized for validating WML schemas against the WML https://github.com/wesnoth/wesnoth/commit/028e51e2b545769ea756e8edfb44d32f2e2d6c68 20181103 19:41:55< irker110> wesnoth: Celtic Minstrel wesnoth:schema 350dd9fc7b8f / / (5 files in 2 dirs): Add several command-line options to invoke the schema validator https://github.com/wesnoth/wesnoth/commit/350dd9fc7b8fa994e4a26a2cad380e23a8a3cc21 20181103 19:42:16<+wesdiscordbot> They were essentially waiting to drop it as soon as Debian chose a sysv init replacement. 20181103 19:44:31<+wesdiscordbot> It's great to write your own stack all by yourself and show it to everyone and brag about it, but it's not a great long-term strategy wrt maintainability, let alone interoperability 20181103 19:44:36-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20181103 19:45:03<+wesdiscordbot> if it's good enough other people will help out with it 20181103 19:45:12<+wesdiscordbot> but canonical stuff wasn't good enough 20181103 19:45:14<+wesdiscordbot> Meanwhile, I'm waiting for the day systemd announces systemd-libc or whatever 20181103 19:45:19<+wesdiscordbot> Which no-one will use 20181103 19:45:37< buhman> can't wait for systemd-libc 20181103 19:45:51<+wesdiscordbot> I'm actually using systemd-networkd 20181103 19:46:10< buhman> what we really need is systemd-systemd 20181103 19:46:19<+wesdiscordbot> because it's easier to get going than any dedicated network manager with my simple network config 😛 20181103 19:46:31<+wesdiscordbot> I guess that's a good point 20181103 19:46:53<+wesdiscordbot> I've always treated networkmanager as a blackbox because I don't even know where its config goes to 20181103 19:47:20<+wesdiscordbot> networkmanager is one of the few things al DEs use in common 20181103 19:48:17<+wesdiscordbot> I think Canonical needed Mir for mobile … but that didn't work out, so noone needs Mir anymore. Same for Unity 20181103 19:48:43<+wesdiscordbot> there will be a purism phone that will be using GNOME 😛 20181103 19:48:44<+wesdiscordbot> Oh yeah where's my Ubuntu phone, wasn't everyone supposed to have one by 2018 or something 20181103 19:48:48<+wesdiscordbot> For Unity, the goal of the whole shell was in the name. 20181103 19:49:54<+wesdiscordbot> In general, pretty much everyone has now learned that the same UI simply doesn't work on desktop and mobile. They are different devices, with different use cases. 20181103 19:50:07<+wesdiscordbot> @shadowm and buhman, https://distrowatch.com/weekly.php?issue=20150330#community 20181103 19:50:15<+wesdiscordbot> Remember when Microsoft was like "WINDOWS ON EVERYTHING" 20181103 19:50:15<+wesdiscordbot> @jyrkive Also different input methods 20181103 19:50:58<+wesdiscordbot> I'm not sure I've heard of anyone supporting Windows mobile in ages 20181103 19:51:12<+wesdiscordbot> they did kinda ditch that 20181103 19:51:12<+wesdiscordbot> App vendors, I mean 20181103 19:51:50<+wesdiscordbot> Yeah, even Microsoft itself gave up on Windows Phone. 20181103 19:52:29<+wesdiscordbot> I know that when I was working at Rovio, MS was paying us for WinPhone ports of our games. They were made by the Operations department, though, not us. 20181103 19:53:03< celticminstrel> Please review schema everyone! If there are no comments at all by next weekend I may just merge it. 20181103 19:53:35<+wesdiscordbot> Yeah I imagine most of the people who support Windows mobile only do so because Microsoft asked them (read: paid them) to 20181103 19:54:23<+wesdiscordbot> Unfortunately out of that botched experiment we got the incomprehensible mess that's desktop Windows today 20181103 19:54:44<+wesdiscordbot> basically the same as with unity 😛 20181103 19:54:54<+wesdiscordbot> Indeed. Desktop Windows was hurt in MS's attempt to join the mobile space. 20181103 19:55:37<+wesdiscordbot> probably you can reuse same gui toolkit both in desktop and mobile but will need different shells 20181103 19:56:09<+wesdiscordbot> Yes, I think that can be made to work. 20181103 19:56:38<+wesdiscordbot> The Unity game engine has its own UI toolkit, and in my experience it has been okay at least for mobile development. 20181103 19:57:15< celticminstrel> Does iOS use the same Cocoa toolkit or does it have its own? 20181103 19:57:21<+wesdiscordbot> @Konrad2 would you be interested in playtesting my TSG rewrite? 20181103 20:06:30<+wesdiscordbot> Yes. Would it be a problem if I put that off till next week though? I plan to finish the campaign Pantherlord and also finish playtesting AtS2 till then. (PL is in the last scenario and AtS2 is in the last scenarios.) 20181103 20:06:32< buhman> @josteph though, a viable linux kernel replacement would be a welcome thing 20181103 20:06:46<+wesdiscordbot> BSD? 😛 20181103 20:07:32<+wesdiscordbot> that's fine, I'm not done with the elvish branch anyway 20181103 20:08:33< buhman> there's some incredibly smart people working on https://github.com/fuchsia-mirror/zircon ; including the author of https://github.com/littlekernel/lk 20181103 20:09:31< buhman> zircon's system call model is also very interesting imo: https://github.com/fuchsia-mirror/zircon/blob/master/docs/concepts.md 20181103 20:14:49<+wesdiscordbot> Interesting. Their security model reminds me of the capability model: https://en.wikipedia.org/wiki/Object-capability_model 20181103 20:48:43-!- gfgtdf [~Daniel@xd527914a.dyn.telefonica.de] has quit [Quit: Leaving] 20181103 21:07:27-!- travis-ci [~travis-ci@ec2-54-81-193-81.compute-1.amazonaws.com] has joined #wesnoth-dev 20181103 21:07:28< travis-ci> wesnoth/wesnoth#20065 (schema - 350dd9f : Celtic Minstrel): The build has errored. 20181103 21:07:28< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/450300440 20181103 21:07:28-!- travis-ci [~travis-ci@ec2-54-81-193-81.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181103 21:09:12< irker110> wesnoth: Celtic Minstrel wesnoth:schema 52c4dc0e3d13 / / (12 files in 7 dirs): Add a validator subclass specialized for validating WML schemas against the WML https://github.com/wesnoth/wesnoth/commit/52c4dc0e3d130e1d6dfb6b2ca8defb1621cd31c7 20181103 21:09:14< irker110> wesnoth: Celtic Minstrel wesnoth:schema 8ef0c1734d71 / / (5 files in 2 dirs): Add several command-line options to invoke the schema validator https://github.com/wesnoth/wesnoth/commit/8ef0c1734d717898c9505dd5fce0ad29898dca49 20181103 21:09:45< celticminstrel> (Forgot to remove some debugging code.) 20181103 21:17:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181103 21:34:07-!- behalebabo [~behalebab@unaffiliated/behalebabo] has quit [Ping timeout: 240 seconds] 20181103 21:40:22-!- behalebabo [~behalebab@unaffiliated/behalebabo] has joined #wesnoth-dev 20181103 21:44:36< buhman> celticminstrel: what do you think about using metamethods for widget attribute access? instead of set_tooltip_value(value, ...), it would be w:attrs.tooltip = value 20181103 21:45:10< celticminstrel> Um. Isn't that literally what I just posted on that issue report? 20181103 21:45:15< buhman> not quite 20181103 21:45:20< celticminstrel> Oh, not quite indeed. 20181103 21:45:32< celticminstrel> Still, yeah, that would be good for simple things like setting a label's value.3 20181103 21:45:49< celticminstrel> It'd be wgt.value = something 20181103 21:46:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181103 21:46:04< celticminstrel> The : is only for member function calls. 20181103 21:46:06-!- behalebabo [~behalebab@unaffiliated/behalebabo] has quit [Ping timeout: 264 seconds] 20181103 21:46:13< celticminstrel> x:f() is shorthand for x.f(x) 20181103 21:48:15< buhman> yeah, that might be more concise/better 20181103 21:49:03< celticminstrel> FTR, the "gui" module is something I was adding in the lua_reorg PR to contain all GUI-specific functions. 20181103 21:49:13< buhman> is that still open? 20181103 21:49:18< celticminstrel> Yeah. 20181103 21:50:42< buhman> oh, just literal renames 20181103 21:50:51< celticminstrel> Mostly, yeah. 20181103 21:51:32< celticminstrel> But if we're gonna actually do a new API for the general GUI2 library, then I'll remove those functions from the "gui" module and just put the stock dialog calls there for now. 20181103 22:14:06-!- behalebabo [~behalebab@unaffiliated/behalebabo] has joined #wesnoth-dev 20181103 22:19:55-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20181103 22:28:44-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20181103 22:30:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181103 22:56:11< irker110> wesnoth/wesnoth:1.14 Steve Cotton 2855e2ce29 Tutorial S2: Hints about whether to leve AppVeyor: All builds passed 20181103 22:59:39-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds] 20181103 23:25:47-!- behalebabo [~behalebab@unaffiliated/behalebabo] has quit [Ping timeout: 240 seconds] 20181103 23:31:28-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] --- Log closed Sun Nov 04 00:00:47 2018