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