16:25:19 <prock> #startmeeting February Developer Meeting 16:25:19 <fifer> Meeting started Sun Feb 7 16:25:19 2010 UTC. The chair is prock. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:25:19 <fifer> Useful Commands: #action #agreed #help #info #idea #link #topic. 16:25:40 <prock> for those that haven't met fifer before... he is our meeting bot 16:26:02 <chew-ie> always a pleasure fifer :) 16:26:33 <prock> for those that are interested.. here is meetbot's manual: http://meetbot.debian.net/Manual.html 16:26:42 <prock> okay moving on 16:27:01 <prock> Agenda is here: http://wiki.fifengine.de/Meeting:2010/02/07 16:27:21 <prock> Lets get right down to business... FIFE 0.3.1 release 16:27:27 <prock> #topis FIFE 0.3.1 release 16:27:38 <prock> we have set our tentative release date to March 20th 16:27:54 <prock> I think we can easily reach that goal 16:27:58 <vtchill> hehe need to redo that topic line 16:28:05 <prock> oops 16:28:10 <prock> #topic FIFE 0.3.1 release 16:28:24 <prock> there we go 16:28:32 <prock> thanks vtchill! 16:28:45 <prock> so as I was saying.. we want to release that on March 20th 16:28:53 <prock> we have some outstanding tickets 16:29:03 <prock> #408 should be fixed 16:29:12 <prock> which brings us down to 10 tickets in total 16:30:07 <prock> lets go through them quickly 16:30:21 <prock> #407 (segfault on closing UH via windowmanager) 16:30:23 <chew-ie> #387 is IMO just one result of the sloppy eventhandling between fife and guichan - my guess that this one isn't easy to fix. I encountered similar problems 16:30:43 <chew-ie> sry :/ 16:30:48 <prock> no problem 16:31:02 <prock> vtchill... and update on #407? 16:31:33 <prock> I have a suspision that it's actually the way UH handles the quit message 16:31:36 <vtchill> still hitting the same point, its been tough to get any good info out of the debugger, i am now trying to trace through uh and see what happens on the close window call and trace that back into fife 16:32:01 <vtchill> it definitely could be so i am looking through their code to see 16:32:01 <prock> perhaps you can get some help from totycro? 16:32:27 <vtchill> yea he is usually fairly helpful, i will try and ask him about it 16:32:46 <prock> I dont think any other clients have that issue do they? Zero quits via the windowmanager? 16:33:17 <prock> I know rio_de_hola and the editor both quit fine 16:33:26 <vtchill> but currently it looks like when that last call to fife happens everything is torn down, so it is essentially accessing bad data 16:34:07 <chew-ie> yes, that would be my guess, too 16:34:51 <vtchill> i will continue to dig into it and hope to have a fix soon 16:34:59 <chew-ie> I once discovered engine.destroy() is needed to safely quit FIFE (otherwise you will e.g. don't get your desktop resolution restored if you run fife in fullscreen) 16:35:01 <vtchill> or at least the root cause and a solution 16:35:22 <chew-ie> UH added that one to their custom "basicapplication" - but I think there might be other bugs as well (in UH, that is) 16:35:48 <prock> Okay next ticket... #197 16:35:55 <prock> engine-sccript memory management 16:35:56 <vtchill> hehe, me again 16:36:07 <vtchill> that one is a tough really 16:36:26 <prock> this is an old one. Jasoka reported it.. hehe 16:36:41 <vtchill> we are certainly open to some bad things between client/fife when dealing with pointers 16:37:01 <prock> yes... chew-ie has encountered a few of them recently 16:37:21 <prock> This I would imagine is our highest priority ticket 16:37:26 <prock> or at least... it should be 16:37:38 <vtchill> basically the idea is that if for instance the client creates a new fife object and then passes it to fife (and transfers owernership) it needs to let fife know by setting the thisown 16:38:43 <vtchill> now their are a couple of things we should do: 1) we should try to limit where this is done and cut down the chances of it happening 16:39:28 <chew-ie> prock, just a short comment - about the disown-workaround for the bugged GenericRenderingNode 16:39:49 <vtchill> for that case i believe we shouldn't be using pointers at all 16:39:57 <chew-ie> I figured out that this is the least you want to do - if you try to work with the location again after you passed it to fife 16:40:34 <chew-ie> It took me some time that this location object basically is useless for further use after setting it to thisown = 0 16:40:59 <prock> chew-ie: I see 16:41:47 <chew-ie> though it's strange - as the location is passed to a python function and then to fife 16:42:00 <vtchill> anyhow i don't think there is a super easy way to have this automatically done where clients would not need to know about it 16:42:21 <vtchill> as i said limiting the places where the script creates the object and then hands it to the engine for owernership is the best thing i think 16:42:21 <prock> yeah... the clients would always have to be aware of it 16:42:47 <prock> unless we had some sort of factory class 16:43:03 <vtchill> the script should mostly request the engine to create things and then use those things... but never create them itself if it is ultimately an engine object 16:43:18 <chew-ie> so basically fife should use copies as often as possible 16:43:41 <chew-ie> mmh - or this way 16:43:49 <vtchill> no, fife should store originals... and clients should only use, not own them 16:44:10 <prock> and not create them 16:44:21 <chew-ie> just curious: what is it if I e.g. call fife.Location() - a fife object or a python object? 16:44:41 <vtchill> so instead of python: node = fife.GenericRenderNode().... fife.SetNode(node) 16:44:43 <vtchill> do this 16:45:10 <vtchill> python: node = fife.CreateRenderNode().... 16:45:20 <vtchill> so fife creates and owns the node and the client just uses it 16:45:44 <prock> is there a CreateRenderNode() function or is that something we would have to create? 16:45:54 <vtchill> it is something the engine would need to provide 16:45:55 <chew-ie> fife.SetNode(fife.GenericRenderNode(fife.location)) works as well - as we figured out 16:46:17 <chew-ie> ah, okay - got it 16:46:29 <chew-ie> this one we would have to create prock 16:47:00 <chew-ie> the whole api works like that that you are just calling pythonvar = fife.Class(params) 16:47:01 <vtchill> so the bottom line is... things that are ultimately going to be owned by the engine should be created by the engine... things that are owned only by script should be created and managed by script 16:47:34 <vtchill> that will eliminate 99% of these problems i think 16:48:09 <vtchill> also in general limit the pointers we pass around, unless they really need to be a pointer (eg. inheritance and polymorphic behavior cases) 16:48:09 <prock> is there a way we can hide constructors from the script which would prevent clients from trying to create fife objects? 16:48:48 <vtchill> sure you provide create functions everywhere and make all constructors private...but i wouldn't go that far 16:49:17 <prock> e.g. if I say: 'loc = fife.location()' I would get an error saying there is no default contructor 16:49:42 <vtchill> well its fine to create things like that on the client side... as long as the client is going to manage its lifetime 16:49:44 <chew-ie> would be safer to forbid it at all - I'd say 16:50:13 <vtchill> the problem occurs when you do: loc = fife.location() .... fife.instance.setLocation(loc) 16:50:22 <prock> the problem with a fife.createLocation() function... where does FIFE manage these locations? 16:50:27 <vtchill> and now the engine nor script has no idea who is managing lifetime 16:51:00 <prock> because the engine can create the object... but it's gotta keep track of it to delete it at some point 16:51:22 <vtchill> well things like location shouldn't be pointers 16:51:32 <vtchill> should only be references or full objects 16:52:25 <chew-ie> There is no reason (imo) for clients to store location objects at all - it's mostly a temporary object to control instance movement etc.. 16:52:25 <prock> right.... so we have a little work to do in the FIFE api... we shouldn't be passing location pointers around 16:52:59 <prock> in the GenericRenderNode I think it uses a pointer to a Location which causes all the grief 16:53:13 <vtchill> http://www.swig.org/Doc1.3/Python.html#Python_nn30 16:53:15 <prock> it sholud be a const reference 16:53:18 <vtchill> good description of the problem 16:53:21 <vtchill> yes it should be prock 16:53:45 <prock> okay easy enough then... we have to go through the entire FIFE api and fix all such situations 16:54:11 <chew-ie> vtchill already pointed out that there is a huge mess about the coordinate handling - maybe if we remove the location object handling from the client, this could solve a lot of problems already 16:54:13 <vtchill> it also mentions the %newobject directive as well 16:54:51 <chew-ie> so that e.g. from client side only x,y ints are passed to the proper fife methods 16:55:07 <vtchill> this bug is going to take some time prock, i don't think it is an immediate need as in clients can continue... so to get this done right it may need to be pushed out a little, but we will see just warning now 16:55:28 <prock> well... I dont really want to push it off 16:55:38 <prock> we have over a month 16:55:47 <vtchill> understood, just saying its an api change for a minor release 16:56:10 <prock> true... so we might be forced to wait until 0.4 16:56:18 <prock> I just hate pushing things off 16:56:25 <vtchill> doesn't mean we cant work on 16:56:26 <vtchill> it 16:56:31 <prock> branch? 16:56:42 <vtchill> yea probably so 16:57:03 <prock> we could start a 0.4.0 branch 16:57:06 <vtchill> i want to make sure everything i have read on it, is actually true when i go to implement it as well, i expect some surprises 16:57:30 <prock> which would include the memory management piece and other major changes 16:57:44 <vtchill> and yes chew-ie the coordinate system is confusing and we really need to understand it before making sweeping changes 16:58:32 <prock> okay so lets make a decision.. we are puchin #197 off to 0.4.0 but will create a branch to start work on it now 16:58:39 <prock> puchin = pushing 16:58:59 <prock> as it is not a trivial change and will require API changes 16:59:08 <prock> so it doesnt belong in 0.3.1 16:59:15 <prock> agreed? 16:59:28 <vtchill> i agree 16:59:45 <vtchill> the swig documentation also mentions typemaps which i am still unclear on for handling this 17:00:35 <prock> #agreed Ticket #197 should be moved to the 0.4.0 release as it requires an API change. 17:00:53 <prock> vtchill: can you put a summary in the ticket and move it to 0.4.0? 17:01:01 <vtchill> yep 17:01:11 <prock> thanks :D 17:01:11 <vtchill> can you mark that as an action plz 17:01:36 <prock> #action vtchill will put a summary of what we discussed into ticket #197 and move it to the 0.4.0 milestone 17:01:47 <prock> Okay next 17:02:01 <prock> #342... camera name clashes when opening maps 17:02:19 <vtchill> hehe me again 17:02:29 <prock> :D 17:02:35 <vtchill> so we all know why this happens 17:03:27 <prock> lets go over it quickly... FIFE stores all it's cameras in a single list? and 2 cameras cannot have the same name 17:03:43 <prock> I"m a little fuzzy on the details 17:03:56 <vtchill> yes 17:04:35 <prock> any easy way to solve this one? 17:04:39 <vtchill> view stores a list of all cameras 17:05:05 <vtchill> well that depends i think on how we want to approach it, to me each map can have multiple cameras 17:05:09 <prock> ahh thats teh problem... cameras should be stored in the "map" object 17:05:21 <vtchill> so cameras within the same map cannot have identical ids... but different maps can have cameras with the same id 17:05:30 <prock> exactly what I was thinking 17:05:34 <vtchill> so the fix would be to associate camera with map 17:05:47 <prock> which would mean an API change as well? 17:05:58 <vtchill> we could still store cameras by view... but internall append the map name to the camera name :P 17:06:11 <vtchill> that would fix it i think without api change 17:06:26 <prock> chew-ie: you still here? 17:06:38 <chew-ie> yes 17:06:49 <prock> do you work with cameras at all in zero? 17:06:54 <chew-ie> yes 17:06:58 <prock> I suppose to move them around 17:06:59 <prock> lol 17:07:15 <chew-ie> ^^ 17:07:34 <chew-ie> Don't see the problem here 17:07:39 <prock> sorry stupid question.. what I"m getting at is how do you access them? 17:07:48 <vtchill> by id 17:07:55 <prock> id = string name? 17:07:56 <vtchill> name 17:07:58 <vtchill> yes 17:07:59 <chew-ie> yes 17:08:10 <vtchill> and the name is based on the map file 17:08:18 <chew-ie> to me it's a "normal" behaviour of fife 17:08:21 <vtchill> unless they create a camera programatically 17:08:22 <prock> the map file specifies the name 17:08:27 <chew-ie> ..and the "bug" lives in the map loader 17:08:41 <vtchill> i dont think its the map loader that has the bug 17:08:52 <prock> its the way FIFE stores it's cameras 17:08:55 <vtchill> its the fact that the view class stores all cameras without knowlege of which map it is attached to 17:09:08 <prock> aye 17:09:14 <chew-ie> so - is that bad? 17:09:17 <vtchill> yes 17:09:26 <prock> that is why we get the camera name clash 17:09:26 <vtchill> never have 2 maps loaded with the same camera id 17:09:31 <chew-ie> I mean - cameras are controlled via the client 17:09:44 <vtchill> but like the editor... you may want to have 2 maps open to editing 17:09:51 <vtchill> but if they have same camera id you are hosed 17:10:06 <chew-ie> ..then the maploader can provide a unique id 17:10:25 <vtchill> the id is set by the client in the editor 17:10:31 <prock> okay I think this ticket should be your #1 priority vtchill... perhaps start another branch to work it out. I can help if you want. We just have to work out the details 17:10:37 <vtchill> that is why i proposed something like cameraId = mapId_cameraId 17:10:40 <chew-ie> or the client maintainer chooses different camera ids 17:10:54 <chew-ie> I just think, we are talking about IDs here 17:11:20 <chew-ie> (has to be unique IMO) 17:11:24 <prock> vtchill: but that doesnt really solve the problem.. what if botht he mapID and cameraID are the same? i.e. I would open 2 copies of the same map 17:11:26 <CheeseSucker> just a comment on the camera clash issue .. 17:11:29 <vtchill> chew-ie another problem right now to me is clients have to know the camera's name before they can request it 17:11:48 <vtchill> opening 2 copies of the same map would cause all sorts of problems 17:11:54 <vtchill> in the same instance of fife 17:12:14 <CheeseSucker> I have seen questions on how to implement paging maps, and if we bind the camera id to a map, it will break that functionality 17:12:17 <chew-ie> I see - so you would like to have something like map.getCamera() / map.getCameraId() 17:12:39 <prock> CheeseSucker: paging maps? i.e. no load times? 17:12:47 <CheeseSucker> paging maps, as in loading maps when you approach the edges 17:12:53 <CheeseSucker> so you have one large world 17:13:02 <prock> CheeseSucker: there are a lot of changes that would have to happen in order for that to work 17:13:14 <prock> CheeseSucker: I dont imagine we will implement that anytime soon 17:13:22 <vtchill> well for a proper fix... you really need the getCamera to request the camera for a certain map 17:13:36 <CheeseSucker> nope, but I think it actually is possible for a client to create something like that without modifying fife 17:13:47 <CheeseSucker> not sure though ... 17:13:49 <prock> CheeseSucker: probably.. but to do it properly 17:13:50 <chew-ie> how about that vtchill: cam_id = map_id + "_cam" 17:14:09 <prock> it shoudl be down within FIFE 17:14:19 <vtchill> as prock said opening more than 1 of the same map would cause problems then 17:14:36 <prock> vtchill and I will take this offline and come up with a few ideas 17:14:37 <vtchill> let me think about it a bit to see if i can come up with a sensible solution 17:14:47 <chew-ie> isn't that part of the loader logic? to check for existing ids? 17:14:54 <vtchill> also chew-ie i have a quick question from a clients perspective 17:14:56 <chew-ie> (and then to refuse loading the map) 17:15:11 <vtchill> not really for cameras 17:15:16 <vtchill> its in the view class 17:15:30 <chew-ie> yes, but the loader should ask the view - I'd say 17:15:31 <prock> okay lets move on 17:15:34 <vtchill> for instances yes, since those are per map 17:16:03 <chew-ie> vtchill, you had a question? 17:16:07 <vtchill> yea 17:16:24 <prock> can we take it offline guys? we are already pushing an hour 17:16:38 <prock> and we have only talked about 3 tickets.. hehe 17:16:39 <vtchill> how do you guys normally get your cameras in zero... do you just know the names already? 17:16:44 <vtchill> ok sure prock 17:17:32 <prock> okay so we havent decided on how it's going to be fixed.. but we will work on that one for 0.3.1 17:17:34 <chew-ie> for now we have on camera "main" - on all maps. (as our client purges loaded data before loading new one) 17:17:46 <vtchill> ok 17:18:11 <prock> Since we are moving #197.. I think that one is probably highest priority now.. hehe 17:18:31 <prock> I see CheeseSucker has done some work on #371 (clean up editor code) 17:18:46 <prock> CheeseSucker: anything of note for that ticket? 17:19:04 <prock> I was looking at it but to be honest I dont know enough Python to really clean that up 17:19:08 <chew-ie> one done, many left *scnr* 17:19:40 <chew-ie> it's a huge ticket, though 17:19:46 <CheeseSucker> well... 17:20:05 <CheeseSucker> it is basically just a lot of not very interesting work 17:20:12 <prock> lol 17:20:28 <chew-ie> *cough* it's called documentation *cough* 17:20:29 <CheeseSucker> I have started on a basic UML diagram to show how the editor is composed 17:20:46 <CheeseSucker> should make it a bit easier for new developers who want to work on the editor 17:20:47 <prock> true... we will have a discussion about the editor later in this meeting so lets move on for now 17:20:51 <CheeseSucker> yep 17:21:12 <prock> #375 (show/hide widgets) 17:21:28 <prock> chew-ie that one is yours. How is that coming along? 17:21:42 <chew-ie> no progress so far 17:21:48 <prock> we have had a discussion about it 17:22:31 <prock> okay... do you anticipate any issues? 17:22:44 <chew-ie> yes - and while it is possible from guichan side, it needs a lot of digging into pychan to just find out if the wrapper needs a major rewrite or just some small additions 17:23:01 <chew-ie> Problem is to keep track on widget hierarchy etc.. 17:23:27 <chew-ie> possible workaround was to set height / width to 0 - but this is a hack 17:23:38 <prock> right... hack is good :D 17:23:56 <prock> I"m okay with the hack 17:23:58 <chew-ie> ..and I bet guichan is doing it that way anyway :D 17:23:58 <helios_> hehe 17:24:10 <prock> can you mark it as a hack? 17:24:27 <chew-ie> I could provide a FIXME: :> 17:24:30 <CheeseSucker> I think it would be better to just set the widget to not be displayed, and let the pychan layout engine handle it ... 17:24:43 <CheeseSucker> shouldn't be too much work, and also is a less of a hack 17:24:44 <prock> yup... and can yhou refer to ticket #375 so people dont forget about it? 17:25:17 <chew-ie> CheeseSucker, that would make it necessary to keep track on the widget hierarchy 17:25:44 <prock> okay I"ll leave it up to debate.. but we need this one fixed by release date 17:25:48 <chew-ie> if you e.g. hide one widget, and remove some others around it, you don't know where to add your hidden widget again 17:26:00 <chew-ie> yes, let's move on 17:26:41 <CheeseSucker> chew-ie: no... you basically set _visible to False, and then skip the widget in the layout engine ... 17:26:57 <chew-ie> mmh.. interesting idea 17:27:11 <chew-ie> _real_widget then 17:27:16 * chew-ie notes that down 17:27:21 <prock> :D 17:27:35 <prock> okay... #387 (button doesn't react to click when drawn below mouse pointer) 17:28:04 <chew-ie> -> #387 is IMO just one result of the sloppy eventhandling between fife and guichan - my guess that this one isn't easy to fix. I encountered similar problems 17:28:17 <prock> damn... work is paging me... you guys continue.. I"ll brb 17:28:26 <vtchill> i have seen this happen a lot 17:28:36 <vtchill> especially in UH 17:28:41 <vtchill> on their main screen 17:29:14 <chew-ie> well... 17:30:10 <chew-ie> I don't know why - but UH main screen is slower then Zero's heaviest gui screen (with dozens of widgets and many hbox-vbox constructions) 17:30:30 <chew-ie> So I don't know if this one is due to "bad reaction" or to bad event handling 17:31:23 <vtchill> yea i noticed that as well chew-ie 17:31:33 <vtchill> not 100% sure why either 17:31:35 <chew-ie> but I know that guichan sometimes looses focus if you try "exoctic" things (read: don't go onto a button, click it, then make your next action) 17:32:02 <vtchill> also i will go back and check my c++ tutorials to see if this happens 17:32:07 <vtchill> i don't remember it happening there 17:32:19 <chew-ie> I once tried to make this: 17:32:40 <chew-ie> a context menu which is opened by a right click on the map - and closed if the RMB is released 17:33:00 <chew-ie> Works - but you shouldn't touch the context menu at all 17:33:41 <chew-ie> Because as soon as you do that, guichan is taking over - and the mouse event from the "map" is hanging around (and is only resetted as soon as you click on the map again) 17:34:03 <vtchill> hmm ok 17:34:45 <chew-ie> e.g. if you also highlight the instance and remove that outline on other mouse events (move) you'll notice that the outline stays 17:35:05 <chew-ie> Seems that the eventlistener isn't firing anymore to the map 17:35:13 <vtchill> well i think this one has had enough discussion, and for now it stays open and we can move on 17:35:17 <vtchill> that sounds a bit odd 17:35:32 <chew-ie> yip 17:36:17 <chew-ie> Just tell phoku the words "eventmanagement" and "FIFE" :D 17:36:39 <vtchill> hehe 17:36:42 <chew-ie> (it's a known design issue / guichan<->FIFE issue for years now) 17:37:12 <vtchill> okay #413 VFS crashes when navigating to restricted path 17:37:41 <chew-ie> I just can say this one is true here, too - although it takes some time to trigger the crash 17:37:52 <vtchill> this is me again, and i am planning to fix this by catching the boost filesystem exception and throwing a fife exception that we will need to handle 17:38:22 <vtchill> so this may be on the client to handle this, not sure yet 17:38:33 <vtchill> but it shouldn't crash regardless 17:38:45 <chew-ie> mmh... 17:39:12 <chew-ie> maybe False / None as return value 17:41:17 <prock> looks like some major issues at work 17:41:21 <prock> you guys will have to continue 17:41:27 <vtchill> np 17:41:42 <vtchill> could handle it as a None return value as well 17:41:51 <prock> #chair vtchill 17:41:51 <fifer> Current chairs: prock vtchill 17:42:03 <prock> okay vtchill.. you can use all the meeting bot commands now 17:42:08 <vtchill> k 17:42:11 <prock> http://meetbot.debian.net/Manual.html#commands 17:42:22 <chew-ie> don't know the code of e.g. the file browser module - but it should check for None / False 17:42:39 <vtchill> yep more than likely 17:42:42 <vtchill> ok i think that one is good 17:43:15 <vtchill> #443 undo/redo not working properly if another layer selected 17:43:24 <vtchill> anyone want to comment on this one or work on it 17:44:05 <chew-ie> looked it up: it just passes the list of available dirs & files to pychan - so should be no problem 17:44:15 <vtchill> k thanks chew-ie 17:44:25 <chew-ie> mmh.. 17:44:26 <vtchill> shouldn't be a hard fix then 17:44:53 <chew-ie> the undo/redo code of the editor is about to be refactored AFAIK 17:45:04 <chew-ie> CheeseSucker might know more about that 17:45:48 <CheeseSucker> the issue is that undo actions aren't bound to a layour 17:45:50 <chew-ie> same for #444 - I remember I read snippets about that on #fife 17:46:29 <CheeseSucker> so it will try to undo/redo on the currently active layer, instead of the original layer 17:46:41 <CheeseSucker> I will have a look at how to fix this issue ... 17:47:27 <vtchill> ok so this is your bug CheeseSucker ? 17:47:50 <CheeseSucker> yep 17:48:07 <vtchill> ok could you assign yourself to it on trac so we all know 17:48:39 <CheeseSucker> ok 17:48:46 <vtchill> #action CheeseSucker is going to assign himself to Ticket #443 and look into a solution 17:49:30 <vtchill> ok #444 docked widgets shrink when you click in them 17:49:32 <vtchill> the floor is open 17:50:38 <CheeseSucker> prock had a look at it 17:50:55 <CheeseSucker> he was about to commit a fix, but found that it introduced new bugs 17:52:00 <vtchill> ok so it is prock looking into this as of now.. or are you involved as well? 17:52:18 <CheeseSucker> I haven't had a look at it, no 17:52:31 <vtchill> ok np, so we will leave this bug then 17:53:23 <vtchill> and the last bug is a documentation bug, so i will leave it for now as well we can come back to it later 17:54:16 <vtchill> everyone good for moving on 17:54:29 <chew-ie> just a second 17:54:31 <vtchill> k 17:55:59 <chew-ie> re 17:57:40 <vtchill> ? 17:57:48 <CheeseSucker> re = back 17:57:53 <vtchill> ah ok 17:58:32 <vtchill> ok moving on to the 0.4 stuff 17:58:53 <chew-ie> sry ^^ 17:59:32 <vtchill> #topic 0.4 - FIFEdit 18:00:43 <CheeseSucker> ok, well this is where prock has a vision for the fife editor 18:00:58 <vtchill> #info Proposal to use a more feature rich GUI toolkit for FIFEdit 18:01:04 <vtchill> ok i will start 18:01:06 <CheeseSucker> ok 18:01:46 <vtchill> in my mind the editor is a must not only for attracting people but for testing the features of the engine 18:02:11 <vtchill> it needs to be easy to use, nice looking, and easily adaptable for new features 18:03:34 <vtchill> i proposed using a different gui toolkit for the editor because of the power it would give us, and the polish we need 18:04:15 <CheeseSucker> yep 18:04:20 <vtchill> i feel like a lot of the things that are holding the editor back are because of display or usability related things that stem from using pychan/guichan 18:05:14 <CheeseSucker> qt has python bindings, don't they? 18:05:22 <vtchill> so with that said i made a couple mock-ups this weekend using qt (and i stole the layout from your great mock up CheeseSucker) 18:05:32 <vtchill> http://www.use.com/fifedit_mockup_4a99c0b8433c80012a65 18:05:52 <vtchill> take a look at all the pictures there and notice how things are moved around seamlessly between the different look and feels 18:07:24 <CheeseSucker> is there a way to browse through the different styles without changing the url manually? 18:07:29 <vtchill> now obviously this is just a start, but it at least shows that i think qt is up to the task 18:07:48 <vtchill> i think it just add a p=# to the end of the same url 18:07:50 <vtchill> not 18:08:09 <vtchill> i was hoping it would put them all on a single url.. but it didn't 18:08:22 <CheeseSucker> yes, qt is a very powerful gui toolkit 18:08:42 <CheeseSucker> and IMO it would be better suited to the task than guichan is 18:08:47 <vtchill> for soemthing like an editor i think using a normal windowing gui toolkit is better than trying to use an in-game toolkit 18:08:59 <CheeseSucker> since, unlike games, the editor will require more advanced widgets, and also more standardized widgets 18:09:07 <vtchill> yes exactly 18:09:32 <CheeseSucker> have you looked at how we can integrate FIFE into qt? 18:09:39 <vtchill> i was also looking into plugins since that is a big part of the editor, and qt seems to support plugin based guis quite nicely 18:09:45 <CheeseSucker> IIRC we had a simple prototype using qt some years ago 18:10:12 <chew-ie> several prototypes - they never made it 18:10:14 <vtchill> i don't think it will be that hard, i have not tried it yet though 18:10:26 <CheeseSucker> would changing to Qt mean we would have to switch to C++? 18:10:38 <vtchill> well i was leaning that way 18:10:56 <vtchill> but qt does support python bindings so maybe it doesn't all have to be in c++ 18:11:30 <barra__out> there are both semiofficial and 3rd party python bindings for qt 18:11:48 <chew-ie> -> http://wiki.fifengine.de/images/a/ac/Editor_002.jpg 18:11:55 <vtchill> there are still a lot of questions obviously, but i think it is something worth pursuing, for now i think i am going to use fife build as a static c++ lib for the editor 18:12:00 <chew-ie> -> http://wiki.fifengine.de/images/5/56/FIFEditMockUp.jpg 18:12:24 <vtchill> hehe yep 18:13:43 <vtchill> this is obviously not something that is going to happen over night, so i was going to continue to work on this and try and get it loading a map and displaying information and then we will see where it goes from there 18:15:18 <chew-ie> Unfortunately - if we focus on that thing before FIFE 1.0, it has to happen over night - otherwise, well - I already said it: Content creation / manipulation will stall on client side 18:15:25 <vtchill> but regardless the editor needs a little TLC and it should be a large focus of our next major release 18:15:58 <vtchill> there is no reason why the current editor can't be use though 18:16:09 <CheeseSucker> TLC? 18:16:11 <barra__out> if vtchill works on it in a branch to explore how well qt would be suited for it, I don't see that problem arise chew-ie 18:16:24 <vtchill> tender loving care 18:16:29 <CheeseSucker> yep 18:16:36 <chew-ie> none for you as an engine programmer - yes. But the situation is different for people who try to use the engine 18:17:00 <vtchill> could you just continue to operate as if no editor changes are happening? 18:17:45 <vtchill> what if you had a year or so before it would be release? 18:18:49 <chew-ie> although python can be used to write prototypes, it's a lot of work to write tools for the current editor. If support is dropped for FIFedit in some months, all this work will be screwed. Second, branching our resources for this new editor apporach will stall other parts of the engine development (just think at your maploaders or the idea of the pathfinder rewrite vtchill) 18:19:21 <chew-ie> So, while I like the idea, too - I say it's the worst we can do _now_ (pre fife 1.0, that is) 18:19:38 <vtchill> well here comes the second benefit 18:20:04 <vtchill> the editor will force me to integrate map loader/saver, since the editor will rely on fife c++ lib 18:20:04 <chew-ie> pathfinder, c++ maploader, trigger support - that things does FIFE need 18:20:40 <chew-ie> nah, that's not an argument for me - starting a new work to finish the old one 18:20:45 <vtchill> also the editor will allow for quicker testing of more advanced pathfinding and ai, since the editor will be an integral part of using those features 18:21:00 <chew-ie> (don't get me wrong here - as I said - the idea is great - but the timing is wrong IMO) 18:21:25 <vtchill> well look at it this way, the only reason a map loader/saver was started in c++ is because i couldn't create tutorials in c++ without it 18:21:38 <vtchill> so i stopped working on tutorials to work on the map loading stuff 18:21:40 <chew-ie> as long as no python bindings are available for the editor, testing / development will be slowed instead of becoming faster 18:22:04 <vtchill> is that b/c no c++ resources 18:22:13 <chew-ie> b/c? 18:22:17 <vtchill> because 18:22:58 <chew-ie> who should write plugins for this new editor? 18:23:10 <chew-ie> I mean - from the client point of view? 18:23:12 <vtchill> well we are hoping everyone, engine people and clients 18:23:40 <chew-ie> We hardly have enough python programmers to get our projects running - now there will also be the need for c++ programmers in order to create a fife client 18:23:47 <vtchill> it is certainly possible, the qt guis can load plugins i saw an example that does this 18:24:16 <vtchill> that is still a question that needs to be answered, perhaps you can write a plugin in python while the main gui is in c++, i don't know the answer to that yet 18:24:24 <chew-ie> It might be possible, yes. For the current editor, it is already possible. 18:25:20 <vtchill> look at it from another perspective, i am creating a c++ client, why should i have to write my editor plugins in python...i don't even have any python programmers on my team 18:25:39 <chew-ie> heh 18:25:48 <chew-ie> so - if we stick to that example... 18:26:38 <chew-ie> there are three projects which are using FIFE/python - now one project steps in which wants to use c++ - and therefore we need a new c++ editor? 18:26:44 <chew-ie> interesting ^^ 18:26:48 <vtchill> i'm just saying the editor would benefit from a more robust and feature rich gui toolkit... but dont look at this as abandoning the old editor.. this is a longn term goal 18:27:05 <barra__out> to be fair: FIFE didn't support a pure C++ client out of the box yet 18:27:07 <chew-ie> I'm fine with it as a long term goal - FIFE 1.0 18:27:07 <vtchill> yes i agree with you, we want to make it easy for the python people since those are our clients, trust me 18:27:27 <barra__out> so it's not that surprising that there are no pure C++ clients in the works right now 18:27:35 <vtchill> well it may very well be a 1.0 thing... but even the current editor needs some polish if we are going to stick with it 18:28:11 <chew-ie> I also said to prock that we could re-evaluate the situation on FIFE 0.4.0 - but switching now, with all this undone stuff around ... 18:28:37 <barra__out> sorry to interrupt the discussion, maybe we can talk about this after the meeting: do you have any plans to try to recruit additional devs for future FIFE development? 18:28:40 <chew-ie> well, to me it seems like a quick fix or something like that 18:29:00 <barra__out> I wouldn't consider evaluating the idea in a branch a switch 18:29:07 <vtchill> i agree chew-ie i dont want to try and do so much that nothing gets done 18:31:22 <vtchill> alright well we can take this discussion offline for later, i think we all have valid points 18:31:23 <chew-ie> Just one detail about this idea what make me think this is a switch barra__out: vtchills motivation is that the current editor lacks polishing (both in terms of visual appearance and input handling / gui) 18:32:02 <barra__out> I think that vtchill's main concern is that the level of polish that he wants to see if hard / impossible to achieve with a library like pychan 18:32:18 <chew-ie> The current editor is by no means ready, but already it is compared with editor suits like unrealedit. That way, FIFedit has no chance 18:32:20 <barra__out> guichan was created as light-weight GUI lib for games 18:32:42 <barra__out> so using something more sophisticated for an editor suite sounds like a good idea to me 18:32:50 <chew-ie> would anybody had thought that guichan would support things like the panels CheeseSucker added? 18:33:13 <chew-ie> or utf-8? 18:33:27 <chew-ie> or mouse-hover-events? 18:33:35 <barra__out> utf8 support was added by the TMW devs AFAIR 18:33:41 <vtchill> i understand what you are saying chew-ie but why waste all that time on things that a gui kit should provide for normal windowed applications, we could be spending that time on polishing how the user interacts with the editor and the features the editor provides 18:33:55 <barra__out> and the TMW team moves away from guichan now 18:34:05 <barra__out> the old guichan lead devs don't work on it anymore either 18:34:20 <vtchill> its all about picking the right tool for the job, and i don't think guichan is the right tool for the editor 18:34:22 <barra__out> so with no active maintainer, I wouldn't put too much trust into the future of guichan 18:34:39 <chew-ie> I understand that there are way better gui kits out there - and I myself have a lot to improvise to make guichan work - but in all cases you have to invest a good amount of work. If you just keep on switching technology, you achieve nothing 18:35:14 <barra__out> I guess we can agree to disagree here :-) an editor is basically the definition of a GUI-heavy app IMHO 18:35:21 <vtchill> that is why i am trying to pick a standard one that has the backing of major developers (read paying companies) 18:35:34 <barra__out> and guichan was not made for these kind of apps 18:35:58 <vtchill> anyhow don't want to keep everybody forever 18:36:01 <vtchill> can we continue? 18:36:05 <barra__out> fine with me 18:36:48 <vtchill> #topic 0.4 - Pathfinding 18:37:37 <vtchill> ok so this is one area that i think fife is very light on support and i think chew-ie would agree 18:37:58 <chew-ie> trendynick did a lot of research on that topic and collected a bunch of links 18:38:07 <vtchill> we would like to handle a lot more sophisticated things within the engine and provide more information back to the client about pathing 18:38:21 <vtchill> yes a lot of links have been provided which should prove to be very helpful 18:38:48 <chew-ie> several connected tickets are out there, too trendynick took care about that 18:39:13 <vtchill> my personal thoughts on this is to implement navigation meshes and provide the client with the ability to build their nav meshes within the editor 18:40:23 <vtchill> this should be able to handle multilayer support with the use of transition spots and it gives the client a lot of power over the map pathing 18:41:26 <vtchill> it does however mean more work on the client to create the meshes... and pathing information would need to be stored somewhere, possibly separate than map, not sure yet 18:42:37 <vtchill> pretty good discussion on different approaches including nav meshes 18:42:38 <vtchill> http://www.ai-blog.net/archives/000152.html 18:44:29 <chew-ie> yeah, that's a nice article 18:45:20 <vtchill> it is a good bit of work to get this implemented but i think it will provide a lot better pathing information than what is currently in place 18:46:05 <vtchill> here is the line that worries me a little 18:46:06 <vtchill> If you're making a strategy game that's entirely 2D, then an approach based on a grid is usually better, since grids give you fast random access to any cell. 18:46:35 <vtchill> we could definitely make use of the grid since we already have it, which is close to what we do now 18:47:15 <vtchill> but we would still need to work out multi layer stuff 18:50:27 <vtchill> anyhow i don't think an approach is set in stone, this is something we are still researching and i am planning to look into all the links trendy provided, maybe something in there will help sway the argument 18:50:37 <chew-ie> you lost me there - I consider the multilayer stuff fixed as soon as the graph based pather is implemented - what is the problem with cell-based-hybrid-usage then? 18:51:15 <vtchill> well cell based isn't bad, but curently we only look on a single layer 18:51:39 <vtchill> like if you had something overhead in a different layer that prohibited moving on that cell, 18:52:08 <chew-ie> yes, but that is gone once the nav mesh is around - what is the problem if we use e.g. a random cell on layer current+2? 18:52:21 <chew-ie> (as target) 18:52:31 <vtchill> so moving between layers? 18:53:18 <chew-ie> I'm refering to that -> <vtchill> here is the line that worries me a little 18:53:27 <chew-ie> (plus the next 3 posts of you) 18:53:54 <chew-ie> As I read it you see a problem on mixing the nav mesh with the current approach - is that correct? 18:54:49 <vtchill> ah that same article i referenced mentions for strictly 2d based games since you have already have a grid it may just be easier to query the grid since that should be fairly fast random access 18:55:47 <vtchill> yea so the nav mesh gives you a lot of power when you dont necessarily know what is traversable, but in a tile based approach (mostly 2d) you kind of already know what is traversable just by querying the grid of tiles 18:56:45 <vtchill> so my concern was using a nav approach you could obviously still query the grid (ie. layer) for things, which then leads to the argument does the nav mesh provide enough of a benefit to warrant the development 18:58:01 <vtchill> so i see 2 distinct approaches, pursue the nav mesh approach, or augment the current pathing for better support 18:58:02 <chew-ie> but as we baked nav meshs for the map, the selected random cell coordinates have to be converted anyway - and if the target isn't present in the mesh, there is no path... 18:58:17 <vtchill> that is true 18:58:50 <chew-ie> the current pather e.g. then calculates the closest possible cell and returns a path to the instance 18:59:33 <chew-ie> the graph would do the same - but faster (as he has less space to deal with) 18:59:49 <vtchill> yes and supporting things like dynamic path recalculation would be nice 19:00:55 <chew-ie> like they e.g. would occur in a sheep herd :D 19:02:05 <vtchill> indeed, this is not set in stone yet and needs some serious thought about how we want to proceed 19:02:22 <vtchill> this is just preliminary 19:02:33 <chew-ie> I'd say in terms of flexibility, the graph based pather would fit nicely into FIFE's goals 19:02:54 <vtchill> yes i agree 19:03:33 <chew-ie> As already said - you can use the graph for a lot of additional things like checking lighting values 19:03:53 <chew-ie> (pathfinding towards lightsources, not target coordinates) 19:04:39 <vtchill> yep some definite possibilities 19:05:10 <chew-ie> mmh.. or sound emitters? 19:05:33 <vtchill> yep 19:05:46 <vtchill> we will save this stuff for another discussion though 19:05:54 <vtchill> i say we get through the 0.4 stuff and call it a day 19:06:35 <vtchill> #idea use navigation meshes for pathing support in FIFE 19:06:51 <vtchill> #topic 0.4 - Map loader/saver in c++ 19:07:39 <vtchill> alright so my plan is provide a MapLoader and a MapSaver class as exposed classes in fife, these will be interface classes that clients can extend 19:08:21 <vtchill> so MapLoader will have a virtual loadResource type function that will be responsible for loading a map, this is what the client will need to provide 19:09:46 <vtchill> I am planning to provide a FifeMapLoader and FifeMapSaver that will support the fife map format out of the box 19:09:58 <vtchill> these will be provided in c++ 19:10:01 <chew-ie> that's where the flexible solution for different mapformats comes in, right? 19:10:19 <chew-ie> (the loadResource function) 19:10:27 <vtchill> yes if the client has its own map format then they will need to provide the map loader, load resource function 19:11:12 <chew-ie> So an editor would just use the fife maploader which is supported by the custom loadResource 19:11:42 <vtchill> that is the current plan, but the editor could also use a client's map loader as well theoretically 19:11:48 <chew-ie> how can one pass his own loadResource to e.g. the editor? 19:12:34 <vtchill> the editor will call the same thing that the client would.... fife.getEngine().getMapSaver().saveMap(filename) 19:12:35 <chew-ie> I guess we still need a kind of plugin functionality here, right? 19:12:46 <vtchill> and if the client has passed in his own map loader then it will use his 19:13:11 <vtchill> note that the syntax is just pseudocode but the idea is there 19:13:25 <chew-ie> sure 19:13:40 <vtchill> a client will register a map loader, so theoretically if we provide a way for a client to register a map loader/saver with the editor that is all that is needed 19:13:52 <chew-ie> yip 19:13:56 <vtchill> so that will be an editor plugin yes 19:14:01 <vtchill> i understand what you are asking now 19:14:04 <vtchill> a little slow 19:14:12 <chew-ie> within the own client, that's easy - but the editor need those plugin structure 19:14:15 <chew-ie> :) 19:14:51 <vtchill> yes there will need to be a way from the editor to select the map loader/saver you want 19:15:22 <vtchill> still have not worked out the entire interface yet for it, but thats the general idea 19:15:58 <chew-ie> do you have a "stable" API already - one we can start to prepare the editor for (and perhaps also provide the ability to load custom loaders / savers until the c++ code is finished) 19:16:20 <vtchill> i hope to have it soon, its not there quite yet 19:16:24 <chew-ie> okay 19:16:35 <vtchill> i will definitely post something when it is though so other stuff can be done in preparation 19:17:14 <vtchill> #action vtchill will provide interface information for the map loader/saver as soon as it is ready so other work can start for integration of this feature 19:17:16 <chew-ie> sounds good : 19:17:46 <vtchill> i also haven't written the saving yet :-/ 19:17:51 <vtchill> only the loading 19:18:35 <chew-ie> any idea on how long that would take? 19:18:47 <vtchill> kind of put map stuff on the back burner for a little to try and investigate the bugs for 0.3.1, but hoping to get back to it soon 19:19:01 <chew-ie> yip 19:19:19 <vtchill> i dont think saving will be that hard, i would htink loading would be harder 19:19:42 <chew-ie> for now this is scheduled for 0.4.0? 19:20:12 <vtchill> the interface stuff is kind of complicated unfortunately... if it was just purely c++ it would be no problem, but i don't know swig too well so i am trying to learn what is proper and what wont work for interface type stuff and polymorphism between c++ and script side 19:20:16 <vtchill> yes 19:20:26 <chew-ie> we have #439 for 0.3.2 19:21:12 <vtchill> hmm yea, that may move the 0.4.0 19:21:19 <vtchill> since it will be interface changes 19:21:24 <vtchill> although we will see 19:21:48 <chew-ie> yip, that's the egg basically :D 19:22:13 <vtchill> #action vtchill and prock will figure out what to do about Ticket #439, it may need to be retargeted since it will involve interface changes 19:22:27 <vtchill> ok anything else on that topic/ 19:22:44 <chew-ie> It's a pity prock has to work right now 19:22:57 <vtchill> yes IT guy, never know when its going to come 19:23:03 <chew-ie> not from my side 19:23:06 <chew-ie> yip 19:23:23 <vtchill> hehe i'm just a programmer so my days are fairly fixed 19:23:27 <chew-ie> CheeseSucker, helios_ ⁻ still with us? :> 19:23:57 <vtchill> #topic 0.4 - Triggers 19:24:08 <vtchill> not sure who added this topic so I will open the floor 19:24:21 <chew-ie> prock - we had a short talk about that one 19:24:25 <helios_> yes I'm still alive chew-ie 19:24:42 <vtchill> ok so you want to say a brief of the discussion 19:25:07 <chew-ie> basically the idea was to use the quadtree for coord based trigger events - but no master plan like the nav mesh 19:25:22 <chew-ie> helios_, good to hear that :D 19:25:36 <helios_> *g* 19:26:19 <chew-ie> using the quadtree could save some cpu time - because triggers would only be checked if they are "near enough" 19:26:31 <vtchill> ah ok 19:27:08 <chew-ie> we found some thoughts about triggers at the wiki - and even some code 19:27:32 <chew-ie> But I'd say we all have to wrap our head around that to develop a plan 19:28:00 <vtchill> ok 19:28:13 <chew-ie> if the nav mesh pather is accepted, it might give some input, too 19:28:48 <vtchill> #action look into the current implementation of triggers and come up with plans to implement more efficient triggers 19:29:08 <vtchill> #idea use a quad tree type approach to limit the number of triggers fired 19:29:23 <chew-ie> The current implementation is nothing more than a class layout 19:30:06 <chew-ie> -> http://fife.trac.cvsdude.com/engine/browser/trunk/engine/core/eventchannel/trigger 19:30:27 <vtchill> ok 19:31:08 <vtchill> anything more on the topic? 19:31:54 <chew-ie> not from my side 19:32:29 <vtchill> ok should we delve into the last 2 topics, i am a little hesistant 19:33:06 <chew-ie> me too - prock should be around 19:33:18 <vtchill> ok 19:33:21 <vtchill> we will defer 19:33:36 <chew-ie> especially for the last point.. 19:34:20 <chew-ie> yip, good enough 19:34:22 <vtchill> #agreed save topics 0.4 - Manuals and 0.4 - Fog of War for another time 19:35:02 <vtchill> #info leaving topics 0.5 and Into the future for another time 19:35:19 <vtchill> so we done? 19:35:44 <chew-ie> basically - just want let you know one thing - no, two things :D 19:35:54 <chew-ie> 1) thanks for taking the chair ^^ 19:36:15 <vtchill> np... i tried to do my best prock impression 19:37:33 <chew-ie> 2) about the editor stuff - I might sound harsh on that topic, but as I said - I like the idea myself, but there are more things which have to be taken in consideration. E.g. supporting the projects FIFE relies on - as they rely on FIFE 19:38:29 <chew-ie> rushing such a step can break our "user base" - which contradicts the plans we have for FIFE 19:38:55 <vtchill> #endmeeting