*** dneighbo has quit IRC *** derek has joined #gnuenterprise *** reinhard has joined #gnuenterprise good morning all *** btami has joined #gnuenterprise *** kilo has joined #gnuenterprise good morning hi btami, kilo good morning *** johannesV has joined #gnuenterprise *** johannesV has quit IRC *** yure has joined #gnuenterprise *** yure has quit IRC *** johannesV has joined #gnuenterprise hi llo johannesV *** ajmitch_ has joined #gnuenterprise *** ajmitch has quit IRC *** yure has joined #gnuenterprise *** siesel has joined #gnuenterprise *** johannesV has quit IRC *** johannesV has joined #gnuenterprise *** johannesV has quit IRC *** johannesV has joined #gnuenterprise *** dimas has quit IRC *** btami has quit IRC *** dimas has joined #gnuenterprise *** jcater has left #gnuenterprise *** yure has quit IRC *** yure has joined #gnuenterprise *** jamest has joined #gnuenterprise *** kilo has left #gnuenterprise *** sjc has joined #gnuenterprise *** jcater has joined #gnuenterprise *** siesel has quit IRC *** yure has quit IRC *** dimas has quit IRC *** jcater has quit IRC jamest, is there already a connection between svn-commit and roundup ? and if so, how do i have to write the commit message ? I tried it but it didn't work IIRC *** btami has joined #gnuenterprise johannesV: i never got it to work ah, ok no problem, so i'll do it manually then *** derek has quit IRC *** derek has joined #gnuenterprise *** jcater has joined #gnuenterprise *** jcater has quit IRC *** dneighbo has joined #gnuenterprise *** klasstek has joined #gnuenterprise *** derek has quit IRC *** krizz has joined #gnuenterprise hello, what is the relation of tinyerp and gnuenterprise? krizz: we hate each other, and I wouldn't recommend anybody from tinyerp to meet me in a dark street j/k seriously I had a look at tinyerp, and it is a nice piece of software which I actually would recommend for anybody that needs a "shrink wrap" solution now it is a pity that its development was completely behind the curtain until they had a turnkey solution ready it would have been *great* if we had had the chance to join our efforts, we have similar approaches in many aspects however for weird reasons, gnue has developed its main strength in the "development platform" area rather than in the "turnkey solution" area so in short: while gnue and tinyerp aim for the same goal (free erp system), they are not related at all u r joking! isn't tinyerp a fork of gnue? no tinyerp was developed by one company (one person??) without any public appearance and when it was ready, it was published as Free Software these news were a big dissappointmenr for me :( i was almost sure, it was a result of gnue project anyway any pre-release in plans in the short while? yes in a week or two johannesV is working on a new wx2.6 ui driver for forms which looks very good and we are looking at some issues/bugs and it has been a long time since the last release anyway johannesV: just saw your commit, great! it could be nice to post such news in the project site johannesV: shall I write a short mail to gnue-dev explaining why this was changed, and how to use the rpc interface now? krizz: yes, agree * johannesV backreading log reinhard, that would be great ! ok johannesV: btw. have you seen our bugreport in http://www.gnuenterprise.org/irc-logs/gnue-public.log.2006-02-16 ? btw. the socket-error appears to show independently of the used ui-driver, when cancelling the login-dialog (but only on win xp) reinhard, i was told in the past in this irc channel, that it would be a good idea, to wait for a pre-release before i submit some greek localization. btami, will try that tomorrow, ok ? johannesV: thx * johannesV off to the kitchen again bbl *** btami has quit IRC krizz: yes, that's correct *** jcater has joined #gnuenterprise reinhard, so I just wait for a while more. sorry bothering guys, I just wanted to know some news about the project :D *** ncjp_ has quit IRC *** ncjp has joined #gnuenterprise krizz: you are welcome please ask whatever you want to know especially when it's stuff you need so you can help us :) ;) good bye *** krizz has quit IRC *** johannesV has quit IRC *** johannesV has joined #gnuenterprise *** jcater has quit IRC *** johannesV has quit IRC jamest: you have a minute? I think parameters in forms is still hosed, maybe more than ever ok though more than ever is a pretty big claim :) the first question of strategy is do we want every form to have its own set of parameters, or do all forms share a common parameter set? (question relates to cases where a gfd contains several forms) iirc parameters were global but they didn't need to be IIRC the latter case makes passing parameters from the main form to the dialogs kinda strange especially as for calling a dialog, you can pass it a parameter dictionary would that then replace the global parameter set? only for that dialog? what i use that for let me find sample hmmm i guess I don't use that anymore :) it's been a long time and I'm pretty sure I changed how i did things after the caseless dicts broke things for me but at one time the dict that was passed back and forth was global so the dialog would reset values then the calling trigger would reread the parms to get the updated info I dont know if anyone was using those param as 2 way communication anymore and I know what I used it for was always a hack AFAICT, the parameter dict given in activateForm has replaced the global parameter set for the called form so you would have looked inside the dict again after the dialog has run not looked with getParameter right? well, at one time it was all getParameter but I think that changed *** klasstek has quit IRC i think when we moved to caseless things broke here as command line params didn't work right anymore and I think I may have slapped something in there to get it going and it passed the "works for me" test but I seem to recall something not being right I'm sure you love pointing out to me how crappy my memory is getting don't you :) not exactly :) hmmm AFAICT the original state was all forms having their own _parameter property and all of them pointing to the same dict, except those that were assigned a different dict explicitly in runForm anyway actually I am trying to find a way that would be *right* i think right would be separate but I swear something stopped that * jamest drinks more caffeinated brain fuel it would mean, for example, that command line parameters are only passed to the main form? that wouldn't be very flexible would it unless params allowed formname.parameter=foo from the command line otherwise you would have to mix cmdline parameters with the parameters given in runForm which might make it extra hard to pass a good dictionary of parameters back to the caller in runForm *** klasstek has joined #gnuenterprise could each param tag it's source? *** yure has joined #gnuenterprise hmmm... maybe other question in that context do we want to require parameters to be declared with a tag? or is this voluntary and only needed if a default is wanted? *** klasstek has quit IRC i thought it was required atm no? no i don't case either way on that care i'd imagine that with a param list you could verify params are valid and not typos hmmm actually what are you using params for? my main reason now to deal with it is I use them for communication between dialogs and the main form i.e. I have a main form where I can enter first few letters of customer name then a dialog pops up and shows all customers starting with that name i'm thinking out loud here I select the one I want and in main form the whole customer record appears but what if forms/dialogs allowed for access to fields and an option to query on startup as most my startup params are either to prepopulate a form with a record or fill in the known values then hidden fields could be used to pass info back and forth which would already be dialog specific did that make any sense? I think fields are not shared between the different forms, are they? they are not currently ^^and I think that is good right as I have > 1 instance of a form open at a time here sorry I meant fields are not shared between the main form and the dialogs right, they are not shared what I was talking about handle = runForm('foo.gfd') theGoods = handle.blkName.fieldName or handle = runForm('foo.gfd', fieldValues = {'blkName.fieldName':value, 'blkName.anotherFIeld':value}, mode = 'populate') or handle = loadForm('foo.gfd') handle.blkName.fieldName = 'foo' handle.runForm() * jamest is really just thinking out loud here I really like the concept of parameters better, I think ok I see the different forms and dialogs within a .gfd much like separate functions within a .py file each with its own namespace and a well defined set of parameters passed back and forth i've always seen them as seperate instances hmmmm I need to think more about this reinhard: i'm really ok with whatever somehow I don't like the hidden field stuff as it means a lot of overhead (unbound block, etc) very true and your view of the forms being like object instances is sane and understandable *** jcater has joined #gnuenterprise while still for dialogs viewing them like a function call seems more natural to me another question to help me understand well, yes and no do you use subforms other than modal dialogs? i could see dialogs persisting after the call, so I could get more info from them if needed all mine are modal persisting in memory, but not on screen? yes that I could pop back up if needed forms currently doesn't do this of course so the function call also makes seens sense thus my yes and no :) *** klasstek has joined #gnuenterprise *** jcater has quit IRC do you have any cases where you pass parameters from commandline directly to a dialog? to a dialog? no i've really only got a few dialogs anymore and those mainly ask for confirmation let me think out loud, too the most straightforward way might really be that each form has one single, well defined (by tags) set of parameters that come from one well defined source and are returned back to one well defined point where for the main form, the parameters would come from the command line and for dialogs, the parameters would come from the call to runForm and be returned there back again and while it would be easy understandable, error-safe (regarding typos in param names) and straightforward, I can't think of anything that would not be possible with that i think that's fine if you really need cmdline params in a dialog you would have to pass it in the call of runForm *** jcater has joined #gnuenterprise *** ajmitch_ is now known as ajmitch *** jcater has quit IRC good night all night *** reinhard has quit IRC reinhard: in case you read the logs, do you have a plan to travel to Wiesbaden for the LinuxTag? *** klasstek has quit IRC *** jamest has quit IRC *** dneighbo has quit IRC *** jcater has joined #gnuenterprise *** sjc has quit IRC *** ajmitch has quit IRC *** ajmitch has joined #gnuenterprise *** lekma has joined #gnuenterprise hi *** derek has joined #gnuenterprise *** lekma has quit IRC *** derek has quit IRC *** derek has joined #gnuenterprise *** derek has quit IRC *** lekma has joined #gnuenterprise