--- Log opened Mon Feb 08 00:00:43 2016
20160208 00:07:51-!- legoktm is now known as legoktm[NE]
20160208 00:16:46-!- gfgtdf [~chatzilla@f054133106.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20160208 00:27:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160208 00:31:32-!- SpoOkyMagician [~chatzilla@cpe-74-136-45-198.kya.res.rr.com] has quit [Quit: later all]
20160208 00:32:16-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160208 00:54:43-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160208 01:06:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160208 01:10:34-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 272 seconds]
20160208 02:36:12-!- berte [~berte@unaffiliated/berte] has quit [Quit: Leaving]
20160208 02:54:49-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160208 02:57:11-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160208 03:23:14-!- legoktm[NE] is now known as legoktm
20160208 03:47:07-!- markus_ [~mjs-de@f048238028.adsl.alicedsl.de] has joined #wesnoth-dev
20160208 03:51:00-!- mjs-de [~mjs-de@x5ce483a1.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160208 03:55:34-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160208 03:57:00-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160208 04:00:59-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160208 04:17:20-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160208 04:17:26-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160208 04:18:08-!- markus_ [~mjs-de@f048238028.adsl.alicedsl.de] has quit [Remote host closed the connection]
20160208 04:51:27-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160208 04:55:16-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160208 05:25:46< vultraz> celticminstrel: so maps are unsorted?
20160208 05:25:58< celticminstrel> Uhhh.
20160208 05:26:06< celticminstrel> Hashmaps are unsorted.
20160208 05:26:10< celticminstrel> Tree-maps are sorted.
20160208 05:26:12< vultraz> because you said you just add to them with map[firstkey]
20160208 05:26:14< celticminstrel> So... maps are sorted.
20160208 05:26:23< celticminstrel> In C++ at least.
20160208 05:26:31< celticminstrel> Yes, you add to them with map[key].
20160208 05:27:16< celticminstrel> That puts the key-value pair directly into its sorted position.
20160208 05:27:55< celticminstrel> Well... map[key] = value.
20160208 05:30:19< vultraz> so it gets added to the ..end of the map?
20160208 05:31:04< celticminstrel> No. It gets added at the sorted location.
20160208 05:31:35< celticminstrel> Which likely as not will be in the middle somewhere.
20160208 05:39:30< vultraz> alphabetically? 
20160208 05:39:33< vultraz> or how is it sorted
20160208 05:41:38< celticminstrel> It's sorted based on the comparator template argument.
20160208 05:41:44< celticminstrel> Which defaults to something sensible.
20160208 05:42:01< celticminstrel> eg, ascending numerical order for numeric types, or ascending lexicographical order for strings.
20160208 05:42:18< celticminstrel> (So yes, alphabetically.)
20160208 05:57:54< celticminstrel> (Why do you care about how it's sorted?)
20160208 05:59:36-!- narsimha [67e4dd68@gateway/web/freenode/ip.103.228.221.104] has joined #wesnoth-dev
20160208 06:09:33-!- narsimha [67e4dd68@gateway/web/freenode/ip.103.228.221.104] has quit [Ping timeout: 252 seconds]
20160208 06:10:28< vultraz> celticminstrel: i just want to understand the data type
20160208 06:15:24< vultraz> celticminstrel: if I do '&groups_[group_id]' will that return a pointer to the value member of groups_[group_id]?
20160208 06:16:51< vultraz> also, does checking for a map member that does not exist return null
20160208 06:16:56< vultraz> or false
20160208 06:18:56< vultraz> because if so, my code is simplified greatly 
20160208 06:23:59< vultraz> oh, wait
20160208 06:24:10< vultraz> wait, no
20160208 06:25:57< vultraz> hm
20160208 06:33:12-!- Kwandulin [~Miranda@p200300760F0BC54CC5CD5A32B53DC63B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160208 06:38:04< celticminstrel> That's an interesting question with a surprising answer.
20160208 06:38:29< celticminstrel> Using map[key] to check for a map member that does not exist causes the member to be added with a default-initialized value.
20160208 06:39:11< celticminstrel> To check whether a member exists before adding it, use map.find() or map.insert().
20160208 06:39:46< celticminstrel> (The former returns end() if it doesn't exist, while the latter I think does something different when it exists.)
20160208 06:40:11< celticminstrel> &groups_[group_id] should indeed be a pointer to the value of that key.
20160208 06:40:57 * celticminstrel poke vultraz 
20160208 06:41:04< vultraz> ahh
20160208 06:41:12< vultraz> so if(groups_.find(id)) {
20160208 06:41:43< celticminstrel> if(groups_.find(id) == groups.end()) { groups_[id] - new_group; }
20160208 06:41:52< celticminstrel> I think that's how find works.
20160208 06:42:04< celticminstrel> (It's different from the global find function, of course.)
20160208 06:43:20< vultraz> huh. error: no matching function for call to 'gui2::tgroup::tgroup()'|
20160208 06:43:34< vultraz> when I try this "return &groups_[group_id];" 
20160208 06:43:42< vultraz> guess maybe I should move that out of the header
20160208 06:43:49< celticminstrel> Map elements need to be default constructible, I believe.
20160208 06:43:58< vultraz> oh?
20160208 06:43:59< celticminstrel> I wrote - instead of = up there by mistake, BTW.
20160208 06:44:18< celticminstrel> Yeah, because of what I said about what map[id] does when the element doesn't yet exist.
20160208 06:44:26< vultraz> how do your ensure default constructibility 
20160208 06:44:46< celticminstrel> In fact, "map[id] = blah" first default-constructs a value, then copy-assigns blah to it.
20160208 06:45:03< celticminstrel> It's easy to ensure default constructibility. Just put a default constructor in your class.
20160208 06:45:13< celticminstrel> Does tgroup even have any constructors?
20160208 06:45:21< celticminstrel> If not, then it's automatically default-constructible.
20160208 06:46:08< vultraz> yes
20160208 06:46:18< vultraz> it has a constructor that takes a string
20160208 06:46:26< celticminstrel> What's the string for? The ID?
20160208 06:46:36< vultraz> tgroup(const std::string& id);
20160208 06:46:38< vultraz> yes
20160208 06:46:45< celticminstrel> Does it really need to know its ID?
20160208 06:46:57< vultraz> well...
20160208 06:47:03< vultraz> it might be useful
20160208 06:47:10-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Ping timeout: 245 seconds]
20160208 06:47:13< vultraz> if you're accessing the group directly 
20160208 06:47:19< vultraz> instead of going through the groups map
20160208 06:47:37< vultraz> can I provide a default id value?
20160208 06:48:22< celticminstrel> If you change it to tgroup(const std::string& id = ""); then it becomes default-constructible.
20160208 06:49:48< vultraz> i figured 
20160208 06:49:55< vultraz> learning, I am
20160208 06:54:32-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160208 07:00:12< vultraz> huh
20160208 07:00:15< vultraz> return &(groups_[id] = *(new tgroup(id))); is actually valid
20160208 07:00:26< vultraz> I'm surprised 
20160208 07:00:31< celticminstrel> Why?
20160208 07:00:38< celticminstrel> Which part surprises you?
20160208 07:01:13< vultraz> just usually when I've tried something like &() it usually complains about rvalues or functions as expressions
20160208 07:01:13< celticminstrel> Incidentally, I'm pretty sure it'll also work without the extra parentheses around "new tgroup(id)".
20160208 07:01:19< celticminstrel> Ah.
20160208 07:01:29< celticminstrel> Well, the thing is, the assignment operator returns an lvalue.
20160208 07:01:59< celticminstrel> Basically, it assigns the RHS to the LHS and then returns the reference to the LHS.
20160208 07:04:30< vultraz> Map has been successfully set up :D
20160208 07:04:58< celticminstrel> I do want to point out though that *(new tgroup(id)) is highly suspicious.
20160208 07:05:09< celticminstrel> Why are you using new here?
20160208 07:05:22< celticminstrel> You could probably drop the new and the * and have it work perfectly.
20160208 07:05:47< vultraz> to create a new tgroup object?
20160208 07:05:50< celticminstrel> "new" is not required to create a new instance of a class.
20160208 07:05:54< vultraz> oh
20160208 07:06:09< celticminstrel> "new" only indicates that it should be allocated dynamically, on the heap.
20160208 07:06:39< celticminstrel> tgroup(id) alone creates a tgroup object, allocating it on the stack (which means it'll be destroyed when the function returns).
20160208 07:06:46< celticminstrel> Then the assignment operator copies it from the stack into the map.
20160208 07:07:04< celticminstrel> (So it won't be destroyed after all, or at least, one copy of it won't be.)
20160208 07:08:17< vultraz> using 'new' means a copy won't be destroyed?
20160208 07:08:23< vultraz> or not using 'new' means that
20160208 07:08:40< celticminstrel> Using "new" means it won't be destroyed until you explicitly "delete" it.
20160208 07:08:57< vultraz> ahhh
20160208 07:09:55< celticminstrel> Not using "new" means it will be destroyed when the current scope ends (at the next closing brace, basically).
20160208 07:10:19< vultraz> better, that is
20160208 07:10:19< celticminstrel> But, if in the interim you copy it into something else, such as a map or vector, then that copy won't be destroyed.
20160208 07:10:35< celticminstrel> (Maps and vectors actually use "new" internally to keep track of their contents.)
20160208 07:11:08< celticminstrel> So, basically, *(new tgroup(id)) is almost certainly an indication of a memory leak (and definitely is in this particular case).
20160208 07:11:17< vultraz> ty for pointing that out
20160208 07:12:39< vultraz> how would I go about deleting a map element, if I wanted to implement a remove_group() function? map::erase()?  and what would happen to the pointers stored in each map's tgroup's member_ vector?
20160208 07:13:07< celticminstrel> Erase should work.
20160208 07:13:40< celticminstrel> Unless I'm mistaken, the pointers in the member_ vector point to widgets that are owned by the dialog.
20160208 07:13:46< celticminstrel> Am I mistaken?
20160208 07:13:57< vultraz> that is correct, afaik
20160208 07:14:12< celticminstrel> Then the dialog is responsible for deleting them - the group doesn't have to do anything about them.
20160208 07:14:32< vultraz> ok, good
20160208 07:15:44< vultraz> hm
20160208 07:16:08< vultraz> also have to deal with any widget-class pointers to groups...
20160208 07:16:28< vultraz> like each ttoggle_button object has a pointer to the group it's in
20160208 07:16:42< vultraz> wouldn't deleting the map element make those stale
20160208 07:16:49< celticminstrel> Since the group knows all the widgets that point to it, it can probably notify the widgets about its demise in its destructor.
20160208 07:17:13< vultraz> the tgroup destructor?
20160208 07:17:16< celticminstrel> Yeah.
20160208 07:17:32< celticminstrel> When does that pointer actually get set? Is it when the widget is added to the group?
20160208 07:17:50< vultraz> yes, and the widget class handles that
20160208 07:18:24< celticminstrel> So, the widget adds itself to the group, and gets a pointer to the group in return?
20160208 07:18:43< celticminstrel> You could add a "remove_from_group()" function to tselectable_.
20160208 07:22:38< vultraz> pure virtual, i assume?
20160208 07:23:36< celticminstrel> Unless you want to move the pointer to tselectable_ too, yes.
20160208 07:24:00< vultraz> the pointer would have to be protected, right
20160208 07:24:12< celticminstrel> If you moved it, it would have to be protected.
20160208 07:33:22-!- Kwandulin_2 [~Miranda@p200300760F0BC54CB9AB233697CED5E4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160208 07:34:15-!- Kwandulin [~Miranda@p200300760F0BC54CC5CD5A32B53DC63B.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20160208 08:27:06-!- zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] has joined #wesnoth-dev
20160208 08:44:23-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160208 09:05:05-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160208 09:09:31-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160208 09:14:58-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160208 09:34:07-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160208 09:51:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160208 09:55:48-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160208 10:45:09-!- Kwandulin_2 [~Miranda@p200300760F0BC54CB9AB233697CED5E4.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160208 12:18:35-!- Kwandulin [~Miranda@2003:76:f0b:c54c:17b:9e8f:68d8:a467] has joined #wesnoth-dev
20160208 12:32:38-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160208 12:34:00-!- Kwandulin [~Miranda@2003:76:f0b:c54c:17b:9e8f:68d8:a467] has quit [Ping timeout: 250 seconds]
20160208 12:40:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160208 12:44:44-!- Kwandulin [~Miranda@p200300760F0BC5AC017B9E8F68D8A467.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160208 13:09:50-!- gfgtdf [~chatzilla@f054133106.adsl.alicedsl.de] has joined #wesnoth-dev
20160208 13:11:15-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160208 13:53:52< vultraz> gfgtdf: could you look over https://github.com/Vultraz/wesnoth/commit/346bbc241df5aec2be9209c9c4a09bbf7d30cfa8 when you have time
20160208 13:58:19-!- mjs-de [~mjs-de@f048238028.adsl.alicedsl.de] has joined #wesnoth-dev
20160208 15:30:17< gfgtdf> vultraz: well i'd still reccomend  to rename the group class to seomthing that makes clear that it can only handle tselectables_ like toggle_group or something.
20160208 15:30:25< gfgtdf> vultraz: tgroup::id() and tgroup::id_ seem to be usused. Maybe you should remove it.
20160208 15:30:34< gfgtdf> vultraz: i dont think it makes sesne that group_operator behaves differently for toggle buttons and toggle panels
20160208 15:30:57< gfgtdf> vultraz: it'd be better to have tgroup in a seperate file. If you are not sure, it's usualyl best to follow the 'one class per file' pattern.
20160208 15:31:13< gfgtdf> vultraz: i'd liek to see how its meant to be used before i approve it
20160208 15:31:39< gfgtdf> vultraz: also it shoudl be possible to specify the group of a togglebutton/panel in wml
20160208 15:32:32< gfgtdf> vultraz: like in [toggle_button] group_id = "compression_mode" ... [toggle_button] or similar in the .cfg file
20160208 15:35:59< gfgtdf> vultraz: also i wonder whether it shodul maybe go into a seperate pr. since the gui2 prefs dialog is already not so easy to review.
20160208 15:37:15< vultraz> yeah I can do that
20160208 15:37:31< vultraz> gfgtdf: I actually have a local change to move it to a separate file so I'll do that
20160208 15:37:48< vultraz> gfgtdf: I want to keep the id around just for utility purposes 
20160208 15:39:43< vultraz> gfgtdf: I wanted to make the add_to_group behavior the same for all of tselectable but I couldn't find where get_window was defined
20160208 15:40:02< vultraz> gfgtdf: also there's already a usecase embedded 
20160208 15:40:27< gfgtdf> vultraz: i meant  group_operator not add_to_group 
20160208 15:40:38< vultraz> gfgtdf: oh right. but toggle panels already have that behavior
20160208 15:42:25< gfgtdf> vultraz: hmm what do you mean by 'have already the baheviour'
20160208 15:42:44< vultraz> gfgtdf: the behavior I added for toggle buttons is basically the radio button behavior
20160208 15:42:50< vultraz> only one button in the list may be selected at once
20160208 15:43:03< gfgtdf> vultraz: that is a feature of lists and not oof toggle panels
20160208 15:43:03< vultraz> but don't toggle panels already have that
20160208 15:43:08< vultraz> Ohhh
20160208 15:46:51< vultraz> gfgtdf: so I should add the same group behavior to toggle panels?
20160208 15:54:10< gfgtdf> vultraz: y maybe it shoudl just be put diectly into tselectable_
20160208 16:12:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160208 16:14:24-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160208 16:14:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20160208 16:16:26< vultraz> gfgtdf: ok Im ight as well move add_to_group too
20160208 16:16:33< vultraz> gfgtdf: do you know where get_window is defined
20160208 16:16:43< vultraz> or do I need to leave that in the dialog
20160208 16:17:04< gfgtdf> vultraz: in twdget, tselctable_ has no access to windowcurrently.
20160208 16:17:11< vultraz> ok
20160208 16:17:22< vultraz> then I'll leave the add function in the dialog
20160208 16:23:32-!- Kwandulin [~Miranda@p200300760F0BC5AC017B9E8F68D8A467.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160208 16:27:52-!- zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] has quit [Quit: Leaving]
20160208 16:48:53-!- Greg-Bog_ is now known as Greg-Boggs
20160208 16:49:46-!- Kwandulin [~Miranda@p200300760F0BC5AC1D3A9F3B878EDB27.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160208 17:23:49-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160208 17:39:58< vultraz> celticminstrel, gfgtdf: https://github.com/wesnoth/wesnoth/pull/588
20160208 17:40:18-!- gfgtdf [~chatzilla@f054133106.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
20160208 17:41:43-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160208 17:43:37< celticminstrel> There's an extraneous blank line added to combobox.cpp.
20160208 17:44:23< vultraz> noticed
20160208 17:45:00< vultraz> I'm still a little unsatisfied with the event execution, but...
20160208 17:45:46< celticminstrel> tselectable_::remove_from_group doesn't need an argument.
20160208 17:46:01< vultraz> hm?
20160208 17:46:24< celticminstrel> It doesn't need an argument. It's supposed to remove itself from the group, right?
20160208 17:46:41< vultraz> yes
20160208 17:46:47< vultraz> just use 'this'?
20160208 17:46:59< celticminstrel> Yes, and group_operator should be virtual so that it can be overridden.
20160208 17:47:26< celticminstrel> Extraneous blank lines added/removed in toggle_button.cpp.
20160208 17:47:27< vultraz> btw, can you explain why I need that return statement
20160208 17:47:42< celticminstrel> Hm?
20160208 17:47:45< vultraz> return set_value(this == widget);
20160208 17:47:49< celticminstrel> You don't.
20160208 17:48:20< vultraz> oh
20160208 17:48:27< vultraz> so I guess set_value_bool doesn't need it either
20160208 17:48:31< celticminstrel> Looking at execute_group_actions, I realize it actually doesn't need an argument now either.
20160208 17:48:54< celticminstrel> Oh, wait.
20160208 17:49:06< vultraz> doing widget->group_operator(widget) doesn't work
20160208 17:49:08< celticminstrel> The function passed is bound to a specific widget, so maybe it does need the argument.
20160208 17:49:10< vultraz> ALL the buttons get toggled on
20160208 17:49:48< celticminstrel> I feel like tgroup::remove_member should be calling clear_group_pointer (which maybe should be renamed too, but no idea to what).
20160208 17:50:49< celticminstrel> Do you think that clear_group_pointer, remove_from_group, and group_operator will need to be accessed by anyone other than groups?
20160208 17:51:09< celticminstrel> I'm just wondering if it might be better to make them private (or protected for group_operator).
20160208 17:51:22< vultraz> clear group pointer... no
20160208 17:51:33< vultraz> i don't think widgets should publicly access that...
20160208 17:51:41< vultraz> remove_from_group, yes, that should be public
20160208 17:51:59< celticminstrel> Well, widgets can clear their own group pointer by directly assigning null to it, though.
20160208 17:52:08< vultraz> right
20160208 17:53:02< vultraz> the removal thing is a little complicated
20160208 17:53:34< vultraz> I've forgotten my chain of thought...
20160208 17:53:45< celticminstrel> I feel like your code is failing to enforce the required constraints.
20160208 17:54:01< vultraz> I would like to make things a little simpler...
20160208 17:54:13< celticminstrel> What's the purpose of tselectable::add_to_group?
20160208 17:54:23< vultraz> to call twindow::add_to_group
20160208 17:54:30< vultraz> and set the widget's group pointer
20160208 17:55:55< vultraz> I was also going to see if I could make tgroup use twidget again..
20160208 17:55:57< celticminstrel> Is twindow::groups() necessary?
20160208 17:56:17< celticminstrel> I don't think that's worth it when you don't have a use-case.
20160208 17:56:34< celticminstrel> This does feel a little convoluted.
20160208 17:57:10< vultraz> see the thing is, everything is split between twindow, tgroup, and tselectable_ (and the latter two rely on each other)
20160208 17:57:31< vultraz> twindow to hold the master group map, so it has functions to add to a group...
20160208 17:57:46< vultraz> then internal tgroup functions for adding/removing members...
20160208 17:58:03< vultraz> but tselectable deals with the functions that a widget should actually use
20160208 17:58:29< vultraz> tselectable_::add_to_group should be implemented and then used..
20160208 17:58:38< vultraz> not twindow::add_to_group
20160208 17:59:01< vultraz> becuase the former calls the latter which eventually calls tgroup::add_member...
20160208 17:59:14< vultraz> yet since we preserve a group pointer twindow is left out for the removal process
20160208 17:59:30< vultraz> and tgroup::remove_member is called directly
20160208 17:59:39< vultraz> by tselectable::remove_from_group
20160208 17:59:55< vultraz> which also deals with setting the widget group pointer to NULL
20160208 18:00:19< vultraz> but if you call twindow::remove_group.. the tgroup::destructor will set all the widget pointers of its members to NULL...
20160208 18:00:33< vultraz> celticminstrel: me things I screwed this design up :|
20160208 18:00:42< vultraz> thinks 
20160208 18:01:40< vultraz> PLUS
20160208 18:01:51< vultraz> I haven't even implemented widget value pairs
20160208 18:02:05< vultraz> which is 80% of what the oft-duplicated radio button code does
20160208 18:02:33< vultraz> and I found even WITH the group paradigm, a lot of the code remains
20160208 18:02:35< vultraz> which sucks
20160208 18:03:05< vultraz> but radio groups with widget values should be a thing specialized in ttoggle_button 
20160208 18:03:10 * vultraz groans
20160208 18:03:11< vultraz> what have I done
20160208 18:04:25< vultraz> celticminstrel: advice on design, I need
20160208 18:11:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160208 18:23:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160208 18:28:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160208 18:33:34< celticminstrel> Yeah.
20160208 18:34:05< celticminstrel> The general idea is fine, but it's too diorganized and fails to satisfy all required constraints.
20160208 18:35:58< celticminstrel> Partly because you wanted to generalize it beyond just toggle buttons, but that's not the sole reason for this convolution.
20160208 18:36:16< celticminstrel> So... twindow needs to know about the groups... why?
20160208 18:36:31 * celticminstrel poke vultraz
20160208 18:36:42 * celticminstrel isn't intending to imply that it doesn't need to know.
20160208 18:37:09< vultraz> celticminstrel: because the groups need to be in some class where the entire dialog can see them
20160208 18:37:20< vultraz> and there's only one instance 
20160208 18:37:30< vultraz> (there should only ever be one group vector at once)
20160208 18:37:38< vultraz> and there's only one twindow class per window
20160208 18:37:47< vultraz> and one dialog per window
20160208 18:37:51< vultraz> because window = dialog
20160208 18:37:55< celticminstrel> And why does the entire dialog need to see them?
20160208 18:37:57< vultraz> so it's kinda like a singleton
20160208 18:38:09< celticminstrel> It's not a singleton. That's not even close to what a singleton is.
20160208 18:38:13< vultraz> ok
20160208 18:38:14< vultraz> nvm
20160208 18:38:16< vultraz> but anyway
20160208 18:38:17< celticminstrel> A singleton has only one instance in the entire program.
20160208 18:38:27< celticminstrel> Anyway, why does the entire dialog need to see them?
20160208 18:38:48< vultraz> so different widgets can be added to the group
20160208 18:38:53< vultraz> er
20160208 18:38:55< vultraz> to a group
20160208 18:39:01< celticminstrel> (BTW, as far as I can see you forgot to implement WML support for groups. But we can save that for when the underlying stuff is done.)
20160208 18:39:36< celticminstrel> Here's why I think twindow needs to know about the groups.
20160208 18:39:59< celticminstrel> 1. Storing all the groups in one place makes it easy to enforce uniqueness of group IDs.
20160208 18:40:31< celticminstrel> 2. Since the groups are all in one place, a dialog can thus query the group of its choice and obtain the ID of the currently selected element in the group.
20160208 18:40:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160208 18:41:14< celticminstrel> 3. I think you also have a point - it's easier to collect several disparate widgets into a group if the groups are stored in a central location.
20160208 18:45:24< celticminstrel> Next question: Why does the toggle button need to know about its own group?
20160208 18:46:50-!- mjs-de [~mjs-de@f048238028.adsl.alicedsl.de] has quit [Remote host closed the connection]
20160208 18:48:50< vultraz> celticminstrel: so as to use the tgroup internals, I think..
20160208 18:49:08< celticminstrel> Meaning...?
20160208 18:49:18< vultraz> er...
20160208 18:49:21< vultraz> remove_member, I guess
20160208 18:49:29< celticminstrel> ...eh?
20160208 18:49:37< vultraz> oh, and so it knows its in a group
20160208 18:49:42< vultraz> it's*
20160208 18:50:14< celticminstrel> Right, because group action occurs in response to a click on any member widget.
20160208 18:53:57< vultraz> er
20160208 18:53:59< vultraz> right
20160208 18:54:00< vultraz> yes
20160208 19:08:26-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20160208 19:26:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20160208 19:41:20-!- gfgtdf [~chatzilla@f054133106.adsl.alicedsl.de] has joined #wesnoth-dev
20160208 19:41:33< gfgtdf> in [terrain_mask] border=yes is just the same as addin 1 to each x= and y= ?
20160208 19:44:23< celticminstrel> I think so.
20160208 19:44:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160208 19:44:30< celticminstrel> Or was it subtracting?
20160208 19:45:35< celticminstrel> It means something like "this map was constructed so as to have a border of unaddressable tiles".
20160208 19:46:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160208 19:58:57-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds]
20160208 20:24:12-!- irker164 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160208 20:24:12< irker164> wesnoth: gfgtdf wesnoth:master c55faadecc03 / src/ (config.cpp config.hpp): fix config::valid_id() https://github.com/wesnoth/wesnoth/commit/c55faadecc030ddcacc6dfd971f84555e54742ce
20160208 20:24:12< irker164> wesnoth: gfgtdf wesnoth:master 6d1d5f09b897 / src/variable_info.cpp: remove useless check_valid_name() calls https://github.com/wesnoth/wesnoth/commit/6d1d5f09b897b9075a5e4c8224d76d192200d537
20160208 20:24:12< irker164> wesnoth: gfgtdf wesnoth:master 969157d79e90 / src/help/ (help_impl.cpp help_topic_generators.cpp): fix color in help unit resitances https://github.com/wesnoth/wesnoth/commit/969157d79e907261494cf52fbc8ccaf6551cfcd7
20160208 20:24:13< irker164> wesnoth: gfgtdf wesnoth:master c1e080f2d4d4 / src/game_initialization/playcampaign.cpp: always proceed with a mp campaign if you are the host. https://github.com/wesnoth/wesnoth/commit/c1e080f2d4d4987815f3a92bcbfd143fc103cf91
20160208 20:24:14< irker164> wesnoth: gfgtdf wesnoth:master 12b40cf45801 / src/scripting/ (game_lua_kernel.cpp lua_pathfind_cost_calculator.hpp mapgen_lua_kernel.cpp): make wesnoth.find_path function available to lua ganerators. https://github.com/wesnoth/wesnoth/commit/12b40cf45801c0b7fb1773ccccfc3af33057c027
20160208 20:24:16< irker164> wesnoth: gfgtdf wesnoth:master 80a99f828c51 / src/scripting/ (mapgen_lua_kernel.cpp mapgen_lua_kernel.hpp): make wesnoth.random avaiable in for lua map gerneration https://github.com/wesnoth/wesnoth/commit/80a99f828c515dee7201c3bc0026ef3c984e387d
20160208 20:24:18< irker164> wesnoth: gfgtdf wesnoth:master 37e613b6fcfe / data/multiplayer/scenarios/ (Random_Scenario_Lua_Cave.cfg Random_Scenario_Lua_Cave.lua): Added a sample lua map generator https://github.com/wesnoth/wesnoth/commit/37e613b6fcfedb44cc501439965da94b4913633e
20160208 20:29:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160208 20:43:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160208 20:53:13-!- Kwandulin [~Miranda@p200300760F0BC5AC1D3A9F3B878EDB27.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160208 21:11:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160208 21:25:59-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160208 21:38:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160208 21:47:35-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Ping timeout: 240 seconds]
20160208 21:51:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160208 22:02:33-!- prkc [~prkc@46.166.188.217] has joined #wesnoth-dev
20160208 22:08:39-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160208 22:15:18< irker164> wesnoth: gfgtdf wesnoth:master ac79ff350a6d / data/multiplayer/scenarios/Random_Scenario_Lua_Cave.lua: improve lua sample cave generator. https://github.com/wesnoth/wesnoth/commit/ac79ff350a6d12fe7e0f9812f5edbb24a4b5d16b
20160208 22:26:27-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Remote host closed the connection]
20160208 22:35:16< irker164> wesnoth: gfgtdf wesnoth:master fc1c9ff69944 / data/multiplayer/scenarios/Random_Scenario_Lua_Cave.lua: fix error in lua sample mapgenerator https://github.com/wesnoth/wesnoth/commit/fc1c9ff69944cbc17ec1e3ea2b26f64cbac7c282
20160208 22:38:35< irker164> wesnoth: gfgtdf wesnoth:master 527c3b1a1e78 / data/multiplayer/scenarios/Random_Scenario_Lua_Cave.lua: fix sample lua cavegen https://github.com/wesnoth/wesnoth/commit/527c3b1a1e78c3fc56f96b64bdf52708e327ea24
20160208 22:39:40< irker164> wesnoth: gfgtdf wesnoth:master acc5ef3b8df9 / data/multiplayer/scenarios/Random_Scenario_Lua_Cave.lua: fix sample lua cavegen https://github.com/wesnoth/wesnoth/commit/acc5ef3b8df91dc0bacc05db3e8a06a752bcfea8
20160208 22:58:31< shadowm> vultraz: https://forums.wesnoth.org/viewtopic.php?p=593787#p593787  I know there's an answer from zookeeper on the next page but since I had told you to keep an eye on the thread...
20160208 23:00:13< zookeeper> i should have some water optimizations in tomorrow. it's far from a magic bullet, but hopefully will help a bit.
20160208 23:01:06< vultraz> shadowm: thanks. been busy, as you can see; my response is basically the same as zookeeper's
20160208 23:03:29< vultraz> I haven't heard from Aginor, so I don't think a Friday release is likely
20160208 23:06:22< shadowm> Yes vultraz I know you've been busy with less urgent stuff that doesn't involve community interactions.
20160208 23:06:28-!- mjs-de [~mjs-de@f048238028.adsl.alicedsl.de] has joined #wesnoth-dev
20160208 23:16:44< vultraz> zookeeper: did you see doofus's mountain tweaks yesterday?
20160208 23:16:51< zookeeper> yes
20160208 23:17:01< vultraz> ah, you were the download
20160208 23:21:58< shadowm> zookeeper: You don't need to type anything into the reason boxes when using OC aban.
20160208 23:22:28< shadowm> With a custom reason: Banned IP for reason “[OCBAN: gopalamj] Spam.” » 122.177.114.77
20160208 23:22:33< shadowm> Without a custom reason: Banned IP for reason “[OCBAN: james44] IP address used for spamming” » 182.190.200.201
20160208 23:22:51< zookeeper> ohh, right. didn't know that so i added it just to make sure.
20160208 23:23:13< shadowm> I vaguely recall explaining this to you before.
20160208 23:23:22< zookeeper> quite possible!
20160208 23:37:00< zookeeper> P.S. my beach waves terrain rules are absolutely awful and i need to fix that too.
20160208 23:39:18< zookeeper> ...and the feathering of the masks too. although that's something i've always known and i've just wondered why no one ever complained about it.
20160208 23:48:26-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 272 seconds]
20160208 23:50:44-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160208 23:52:36-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 248 seconds]
--- Log closed Tue Feb 09 00:00:04 2016