*** tech1_ has joined #gnuenterprise
*** shmooz has quit IRC
*** dcmwai has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<kilo> good morning
<kilo> reinhard: finished translations, green lamp for release
<reinhard> ok thanks
<reinhard> johannesV: are german translations also up to date?
<johannesV> reinhard, yes
<johannesV> i've updated them yesterday (only needed in common though)
<reinhard> ok thanks
<johannesV> sorry, but i've seen this typo just this moment ...
<johannesV> kilo: have you been successfull with <import-trigger> ?
*** btami has joined #gnuenterprise
<kilo> johannesV: no
<johannesV> ok
<kilo> iirc there was some namespacing problem
<johannesV> seems so yes
<johannesV> anyway it's kind of a philosophical question wether to integrate trigger-code into forms or not
<johannesV> for *large* trigger it could be helpful for reading the gfd, but one would have to provide two files to the client then
<johannesV> oth one could ask if *large* triggers are a *right* solution to a given problem ...
<johannesV> (like doing things in appserver instead on the client side)
<kilo> in my case it should serve code reuse. if you look at the invoice forms, nearly all contain the same code in the startup trigger
<johannesV> right
<johannesV> maybe i can fix something ...
<kilo> not vital at all
<johannesV> hmm, importing dialogs does not work too ...
<johannesV> that's really bad
<kilo> hmm
<kilo> same error?
<johannesV> yes, the error appears to happen in GParser.py line 451 (GImportItem.primaryInit)
<johannesV> actually the parent of type None (which is a GFForm instance) has an attribute _app which is None too
<johannesV> so it cannot provide a property called '_parameters'
<kilo> i see
*** dcmwai has quit IRC
<johannesV> ok, i've fixed it but it's not very usefull though ...
<johannesV> now the dialog (which is a form with style=dialog) get's loaded by GFParser.loadFile ()
<johannesV> but this leads to all phased inits which ends up in an activateForm (__main__)
<johannesV> so the dialog superseeds the *real* main form and i get a clash ...
<johannesV> i think we let ja* fix that importing stuff
<kilo> i agree
<johannesV> the quick-fix was to either use findParentOfType (None)._instance in common.GParser
<kilo> did it fix import-trigger too?
<johannesV> or to add a '_app': instance to forms.GFParser
<johannesV> haven't tried yet ... just a sec
<johannesV> no, it's not useable at all
<johannesV> because the import-trigger leads to a loadFile ()
<johannesV> and loadFile expects a *complete* form-definition (gfd)
<johannesV> including form-tag, logic, layout, ...
<johannesV> but i can try it with that stuff all there ...
<johannesV> ok
<johannesV> importing works ...
<johannesV> yes, importing triggers definitly works
<kilo> so i haave to define a foo form that contains them triggers
<johannesV> right
<johannesV> i'll try to replace that dialog-import thingy using a runForm () with params ...
<kilo> hmmm, it's kind a ... hmmm...   interesting
<kilo> like when a woman is neither beautiful, nor nice, nor clever, then you say, she is 'interesting'...
<johannesV> :)
<johannesV> does runForm () work for you ?
<johannesV> oho ...
<johannesV> shit
<johannesV> i've got it
<johannesV> it's the name-tag !!
<johannesV> if you set a <form name="foo" title="bar">
<johannesV> you !!!! cannot !!! open it using gnue-forms
<johannesV> :)
<johannesV> cause it's missing the key __main__ in the formsDictionary
<johannesV> ok, so, if i *remove* the name-attribute from my dialog-form everything is ok
<johannesV> we can circumvent that import-dialog problem by using an external form with style="dialog" which get's called using runForm ('dialog.gfd', parameters)
<johannesV> this has the same effect as a call to activateDialog ()
<johannesV> wrt to trigger-import i think we really wait for jamest or jcater to ask what's all about that _app/_instance thing
<kilo> ok, as i've said eariler, it is not vital at all
*** btami has quit IRC
<johannesV> hmm, we cannot set 'navigable' attribute on GFButtons ?
<kilo> if it is a child of GFTabstop, it should be navigable
<johannesV> but i want a button which does *not* get the focus
<johannesV> so usually we do this by setting navigable="False"
<johannesV> but navigable is no valid xml-attribute of <button>
<kilo> hmmm
<johannesV> now it's possible :)
<kilo> does it not break string freeze?
<johannesV> no, i don't think so
* kilo did not get the commit mail yet...
<kilo> bbl
*** kilo has quit IRC
*** sjc has quit IRC
*** kilo has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** lekma has joined #gnuenterprise
<lekma> hello everyone
*** btami has joined #gnuenterprise
<lekma> is the appserver able to return base64 encoded string
<lekma> ?
<lekma> i have a systemInvalidParameter from gnue.common.rpc.drivers.xmlrpc.pw_xmlrpc typeconv.py
<lekma> python_to_rpc doesn't know about binary/base64
<lekma> rpc_to_python neither
*** jearl has joined #gnuenterprise
*** jearl has left #gnuenterprise
<reinhard> lekma: is it a blob?
<lekma> no it's a base64 encoded string which has a type 'str'
<lekma> which is puzzling??
<lekma> i return a pdf
<lekma> generated with htmldoc
<reinhard> strange, yes
<reinhard> stuff being of type string should work acutally
<reinhard> maybe you want to convert it to unicode in the procedure
<reinhard> but still it should work with string
<reinhard> in fact, typeconv doesn't do *anything* for StringType??
<lekma> what i do is:
<lekma> pdfString = base64.encodestring('www.python.org')
<lekma> print type(pdfString)
<lekma> print pdfString
<lekma> return pdfString
<lekma> i what i have is the typeconv error
<lekma> the base64 string is correctly printed
<lekma> and the type is 'str'
<reinhard> what exception do you get exactly?
<lekma> well now it works
<lekma> it seems i had some trouble in another proc
<reinhard> oh
<lekma> that was returning something
<reinhard> i already thought i have faith healer capabilities
<lekma> but still i don't know how to send a base64 object via xmlrpc
<lekma> another toubling thing is when i have very long procedures stored in db
<reinhard> probably you have to encode it
<reinhard> i don't think xmlrpc supports binary data
<reinhard> what is the trouble with long procedures?
<lekma> when requesting the content (the string)
<lekma> i only receive part of it....
<lekma> in db it is correct
<reinhard> which db?
<lekma> but in xul
<lekma> i have only part of it
<lekma> pg
<lekma> postgresql
<reinhard> psycopg?
<lekma> psycopg
<lekma> yep
<reinhard> ok
<reinhard> I think johannesV can look into that tomorrow
<lekma> thx
<reinhard> actually it can be anywhere where it gets cut
<reinhard> psycopg, common, xmlrpc, appserver...
<lekma> and xul
<reinhard> we'd have to create a testcase and follow the way of the string
<reinhard> oh hm
<lekma> :)
<reinhard> can you test what happens when you have a form on gnue_procedure?
<lekma> yep that's what i've done and realized only part of the proc was displayed
<reinhard> ah yes, that's another thing johannes should look at
<reinhard> generated form for gnue_procedure doesn't work
<reinhard> lekma: ok, so it would not be xul, correct?
<lekma> sorry i was talking about xul and not gnue-forms, my mistake
<lekma> :(
<reinhard> oh ok
<reinhard> did you try a gnue-forms form?
<reinhard> maybe we'll wait until johannes fixes generated form for gnue-procedure
<lekma> i'll test in other cases where i have long description also
<reinhard> anyway thanks for reporting
<reinhard> in case it is a bug we will happily include fix before release
<lekma> ok it's not an appserver bug, gnue-forms is correctly displaying 10 000 chars where xul stops at 4 082....
<reinhard> phew
<reinhard> thanks for testing lekma
<lekma> i should have tested it before reporting, sorry
<reinhard> it's really no problem
<reinhard> i'd prefer a bug report too much against a bug report too less
<btami> reinhard: just another forms bug:if a gfd has an image widget, but pil has not installed, gnue-forms quits, instead of skip that image widget
<btami> is this the correct behaviour?
<reinhard> btami: I don't think so
<reinhard> however, I didn't ever even *look* at image support in forms
<reinhard> I think the best would be to report it to BUGS
<btami> just try gnue-contrib gnue-invoice INV_Head form, it has a nice goat image :)
<btami> i hate this BUGS file, koz i know many other bugs reported in DCL, but hate to type them again...
<reinhard> I hate DCL because it doesn't work ;-)
<btami> me too :)
<btami> we can blame derek, but it doesn't help :)
<btami> dneighbo: setup DCL again please!
<btami> or something better
*** qmpel has joined #gnuenterprise
*** qmpel has left #gnuenterprise
<johannesV> reinhard, i can remember we have defined to *not* generate forms for system classes
<johannesV> acutally it should raise an exception if a system-class has been called
<johannesV> (will fix that)
<reinhard> thanks
<reinhard> did you see that lekma's problem was a xul side bug?
<reinhard> so no need to track that one further
<reinhard> i was understanding that we don't provide gld files for system classes
<lekma> it's a bug in vcXMLRPC.js
<reinhard> i am not sure why form generation should not work
<lekma> mjablonski from zope
<lekma> hit the same bug
<lekma> and fixed it
<reinhard> oh
<reinhard> don't you just have to *love* free software?
<johannesV> reinhard, well we're skipping all 'gnue_*' properties ... (except the specials)
<johannesV> so generating a form for gnue_* does not contain very much :)
<reinhard> ah
<reinhard> aaaaaahhhhhhh
<reinhard> gotcha
<reinhard> ok I take back everything I said and fully agree with you now :)
<johannesV> if i add such an exception now (saying something like: cannot generate form for system class) it will introduce another translatable string
<reinhard> right
<reinhard> so please delay that change to after the release
<johannesV> ok
<reinhard> silly question
<reinhard> what would happen if i tried to generate a form that simply has no properties
<reinhard> or only such with pos="0"?
<reinhard> actually the same error would occur, right?
<johannesV> that's not silly ... :)
<johannesV> but it would display the same error
<reinhard> so then (after the release) it should be better to check for a error like "no displayable properties"
<reinhard> also, at some point a module could extend gnue_* classes
<reinhard> with, say, a html formatted help text
<reinhard> so we shouldn't *define* system classes to not work with generated forms
<johannesV> a class could not have *no* properties if it has been created by gnue-readgcd
<johannesV> (because the stamp-fields are added automatically)
<reinhard> johannesV: right
<reinhard> but still i would check for number of properties > 0
<reinhard> instead of check for the module name "gnue"
<reinhard> also, I think we still should show the error
<reinhard> for classes that would *only* display the stamp fields
<reinhard> as a form only with stamp fields doesn't make much sense :)
<johannesV> it's already fixed
<johannesV> after loading the props their number will be checked (specials not including)
<johannesV> if this number is 0 --> the exception is raised
<reinhard> excellent
*** dcmwai has joined #gnuenterprise
<reinhard> kilo: you here?
<johannesV> i won't commit until you did the release
<reinhard> if kilo pops up here
<reinhard> please commit and quickly regenerated the po files
<reinhard> so that kilo can add the hu
<reinhard> and you can add the de
<johannesV> ah, ok
<reinhard> it's somehow insane to keep back a bug fix for a release :)
<reinhard> I'll be off for today
<reinhard> cu tomorrow
<lekma> bbl
*** lekma has quit IRC
*** reinhard has quit IRC
<johannesV> bbl
*** holycow has joined #gnuenterprise
*** holycow has quit IRC
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** btami has quit IRC
*** sjc has joined #gnuenterprise
*** AndreaKBG has joined #gnuenterprise
*** johannesV has quit IRC
*** RalphSuperMaxiEr has joined #gnuenterprise
<RalphSuperMaxiEr> gnegna citrigna
*** RalphSuperMaxiEr has left #gnuenterprise
*** dcmwai has quit IRC
*** lekma has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
*** dcmwai has quit IRC
*** AndreaKBG has left #gnuenterprise
<kilo> good night
*** kilo has quit IRC
*** ajmitch_ has joined #gnuenterprise
*** cilkay has quit IRC
*** mustafa has quit IRC
*** sjc has quit IRC
*** shmooz has quit IRC
*** dcmwai has joined #gnuenterprise
*** lekma has quit IRC
*** ajmitch_ has quit IRC