*** dimas has quit IRC
*** reinhard has joined #gnuenterprise
*** wayneg1 has joined #gnuenterprise
<reinhard> hmmm
<reinhard> looking at the logs
<reinhard> it seems i don't miss much here when i'm asleep :)
*** johannesV has joined #gnuenterprise
<reinhard> good morning johannesV
<reinhard> you still working on gtk2?
<reinhard> or is everything fixed now?
*** wayneg has quit IRC
<SachaS> :)
<SachaS> morning reinhard
<reinhard> good morning SachaS
<SachaS> how are you?
<SachaS> what do you think of a gnue-beer meeting somewhen soon again. Close to you and johannesV?
*** wayneg has joined #gnuenterprise
<reinhard> not sure
<reinhard> i'm quite busy at the moment
<reinhard> i will go on holiday in about 2 weeks
<reinhard> and have to finish a lot of stuff before that
<reinhard> maybe a short beer, yes :)
<SachaS> so after your holidays is no problem at all
*** btami has joined #gnuenterprise
<johannesV> good morning !
<SachaS> morning johannesV
<johannesV> reinhard: just commited the last 'known' bug in gtk2
<SachaS> i was telling reinhard that we should go for a gnue-beer one day, maybe after reinhards holidays.
<johannesV> well, there is something i'd like to fix: accelerators in menus
<johannesV> atm they're just added to the menu-label using "%s\t%s" % (lable, hotkey)
<johannesV> and gtk2 has an Accelerator support (which could do that automatically and correct aligned and so forth)
<reinhard> yeah i would like that better
<reinhard> however
<reinhard> what would be really cool
<johannesV> well this needs some additional functionallity in the KeyMapper
<reinhard> if you could care for the german translations for appserver and common today
<johannesV> n.p.
<reinhard> so we can release with updated po files for german
<johannesV> what do i have to do ?
<johannesV> btw. speed has been improvemed quite well, i think we're on the right way ... :)
<SachaS> see ya later
<johannesV> by SachaS
* SachaS gone writing thesis
<johannesV> s/by/bye/ :)
*** SachaS has quit IRC
<johannesV> reinhard: do i have to update my .po files in order to start with translation ?
<btami> hi all
<johannesV> hi btami
<reinhard> johannesV: po files for appserver and common should be current
<reinhard> btami: i have a improvement proposal for win32 ui driver for forms
<johannesV> hmm, but then if i look at GBaseApp in common, the docstrings need an urgent fix
<btami> hi reinhard, johannesV
<btami> can you help to fix this:
<btami> DB000:   File "/home/tamas/svn/gnue/gnue-common/.cvsdevelbase/gnue/common/definitions/GObjects.py", line 340, in dumpXML
<btami> DB000:     textEncoding=textEncoding, xmlnamespaces=xmlnamespaces)
<btami> DB000: TypeError: dumpXML() takes at most 3 non-keyword arguments (4 given)
<btami> i just wanted to save gauntlet.gfd after tweakin on it a little...
*** wayneg1 has quit IRC
<johannesV> from where did you get this error ?
<btami> i was fighting with dumpXML in several places before...
<btami> gesigner
<btami> designer
<johannesV> yeah, me too
<btami> when presss save
<johannesV> so if you safe a gfd from within designer ?
*** dimas has joined #gnuenterprise
<btami> yes, with gauntlet.gfd
<dimas> hi all
<btami> hi dimas
<reinhard> btami: you can now implement a method messageBox (self, message, kind, title, cancel) to display a native message box
<reinhard> message is the message to display
<reinhard> kind is "Question", "Info", "Warning" or "Error" (Question is a yes/no message box)
<reinhard> title is the text for the title bar
<reinhard> cancel is a boolean defining whether cancel button should be available
<reinhard> the method should return True on Ok or Yes button
<reinhard> False on No button
<reinhard> and None on Cancel button
<reinhard> --
*** holycow has quit IRC
<dimas> hello btami
<btami> reinhard: so we will prefer native instaed of .gfd for messages?
<btami> i'm OK with it
<btami> johannesV: may i add some items for gtk2 ui TODO ?
<johannesV> please
<btami> listbox entry type
<btami> fix scrollbar widget
<btami> status line messages for menu items
<johannesV> btami: do you have a sample for a scrollbar gfd
<johannesV> status line messages for menu items ?
<btami> when you step through menu items, the long description of the menu item can appear in the status line
<reinhard> btami: yes we prefer native message boxes
<reinhard> they look *much* better
<btami> johannesV: i will try to add a sample gfd for scrollbar 
<btami> reinhard: OK
<btami> johannesV: the last one is
<btami> clipboard handling (cut and paste with mouse ctrl-c/v/x)
<johannesV> ok, will look at this after finishing the translation
<btami> johannesV: thx
<btami> anyhow, the gtk2 ui is now better then wx!
<btami> it has working dropdowns!
<btami> btw. you guys now diving into forms more and more, so i bring my wery old unsolved issue
<btami> can you remember the "antry width not accurate" bug in DCL?
<btami> if you define an entry with width="4"
<ajmitch> hi
<btami> and you type 1234
<btami> tha last char you typed (4)
<btami> is not fully visible
<btami> we get the average char width from the font we use, but
<btami> the ui using come pxels himself for drowing the inpot box and the caret in it
<btami> so the usable place counted in pixels not enough for displaying the "4" in my example
<btami> to solve this issue in win32 ui, i'v added some extra pixels when creating the native window for the entry
<btami> but this not a good solution, koz this way scrollbars can't be position precise next to an entry
<johannesV> btami: right, do you have a better idea ?
<johannesV> hi ajmitch
<btami> johannesV: unfortunately i haven't :(
<johannesV> reinhard: i've updated the po-file now, but after running commons setup-cvs.py the changes aren't reflected in appserver ?
<reinhard> sorry
<reinhard> you have to delete the old de.gmo first
<reinhard> actually
<reinhard> deleting *.gmo and running "make gmo" in po dir should do the job
<reinhard> no need to rerun setup-cvs
<johannesV> ok, it's working
<btami> johannesV: http://www.gnuenterprise.org/~btami/scrollbar.gfd
<btami> johannesV: it shows the "antry width not accurate" bug too
<btami> s/antry/entry
<johannesV> ok, thanks
*** SachaS has joined #gnuenterprise
<johannesV> reinhard: how would you translate 'parsed' ?
<reinhard> in which context?
<johannesV> parsing file
<reinhard> hmm...
<reinhard> "Datei einlesen"
<btami> bbl
*** btami has quit IRC
<johannesV> ok, but what about: "The file cannot be parsed."
<johannesV> "Datei kann nicht eingelesen werden" ?
<reinhard> maybe
<reinhard> i have no better idea
*** SachaS has quit IRC
*** SachaS has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<johannesV> hi kilo
*** wayneg has quit IRC
*** kilo has quit IRC
*** jamest has joined #gnuenterprise
<reinhard> jcater: you here?
<reinhard> jcater_: maybe you?
<reinhard> jamest: i was thinking about this event passing thing we talked about yesterday
<reinhard> i had a closer look at the current event system
<reinhard> and i thought maybe we could even make this a feature of the event system
<jamest> yes?
<reinhard> just to sum up what we want
<reinhard> we want every event first passed to the focus widget, if that handles the event then it's ok, otherwise the normal event handler for GFInstance would get the event
<reinhard> i see 2 more or less elegant ways of achieving that
<reinhard> a) event controller can be cascaded, i.e. we always inform the GFInstance event controller what the "sub" event controller of the current focus element is
<reinhard> when the event controller wants to dispatch an event, it first tries if the sub controller handles it
<reinhard> otherwise he calls the correct handler from his own list
<reinhard> b) event controller can register a function for the "__before__" pseudo event
<reinhard> the __before__ function is always called before the actual handler(s) are called
<reinhard> this __before__ function would be implemented in GFInstance and try to delegate the event to the focus entry
<reinhard> in both cases, if the focus widget handles the even, it can drop the event
<reinhard> and therefore suppress further processing of the event
<reinhard> like when the multiline edit has already processed the return key
<reinhard> we don't want the instance to process it, too (and move the focus to the next entry)
<reinhard> now which of both ways would you prefer?
<reinhard> or am i nuts?
<reinhard> or did you fall off your chair laughing?
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
<jamest> hmmm
<jamest> you're wanting to put this in common itself?
<reinhard> parts of it, yes
<jamest> as an optional (aka: it won't change standard event processing) hook
<reinhard> yeah
<jamest> as I know i've got apps that use events for almost all communications
<reinhard> an optional hook that is called before normal event processing is done
* jamest doesn't want them to break
<jamest> i'm not 100% sure I'm following this
<reinhard> so please ask
<jamest> in a) you are allowing nested event controllers to any level
<reinhard> yeah
<jamest> in b) you are allowing a single overridable function per target of the event
<reinhard> not sure if in a) a controller could have more than one subcontrollers
<jamest> but in a) controller 1 (c1) could contain c2 which could contain c3
<reinhard> what do you mean with "target"?
<reinhard> yes
<jamest> in b) you have 1 function only
<reinhard> yeah
<reinhard> well
<jamest> so only 1 level of customization can happen 
<reinhard> actually
<jamest> which would work in the case of forms
<reinhard> i would have as many functions as i want
<reinhard> just have to register them all as listeners to the pseudo "__before__" event
<reinhard> also i would for the sake of completeness
*** gsoti has joined #gnuenterprise
<reinhard> also have a __after__ hook
<reinhard> which gets every event *after* the normal processing in case it wasn't dropped by then
<reinhard> the advantage i see in b) is i have a single function that gets called for every event
<reinhard> where i can do very central stuff
<reinhard> but as you said in a) we have more levels of abstraction
<jamest> man, if someone ever used A extensively i don't think i'd want to read the code
<jamest> tracing an event thru the system might get ugly :)
*** jcater has quit IRC
<reinhard> :)
<reinhard> after thinking a bit
<reinhard> i would vote for b)
*** jcater has joined #gnuenterprise
<jamest> i think i'd be ok with either one
*** nickr has quit IRC
*** nickr has joined #gnuenterprise
<SachaS> something funny of the upcoming president candidacy: www.spy.org/this_land
*** gsoti has quit IRC
<SachaS> checkbox is working in curses.
<reinhard> not perfectly
<reinhard> look where the cursor is when the checkbox has the focus
<reinhard> then do svn up
<reinhard> and look again :)
<reinhard> btw
<reinhard> you might want to notice
<reinhard> that you can toggle the checkbox with space
<reinhard> you can set the checkbox to True with 1 or + keys
<reinhard> and you can set it to False with 0 or - keys
<reinhard> which means you can use checkboxes with the numeric keypad
<SachaS> :)
<SachaS> amazing. curses makes fun to work with
<SachaS> text is flashing and stuff
<SachaS> :)
<SachaS> curser where it has to be
<SachaS> :)
*** dimas_ has joined #gnuenterprise
*** dimas has quit IRC
*** holycow has joined #gnuenterprise
*** sjc has joined #gnuenterprise
<dimas> is that default befaviour now to embed form into a navigator frame?
<dimas> GNUe Common Version 0.5.5.99
<dimas> ------------------------------------------------------------
<dimas> Error: Traceback (most recent call last):
<dimas> gException: Sourcecode contains tab character at position 404
<dimas> what is this error message about?
<dimas> which sourcecode?
<reinhard> maybe a trigger code in your form?
*** gsoti has joined #gnuenterprise
<dimas> reinhard: most likely. absolute position of trigger sourcecode?
<reinhard> i have no idea
<reinhard> i think i have never seen this error
<reinhard> must leave for lug meeting
<reinhard> l8r all
*** reinhard has quit IRC
*** reinhard has joined #gnuenterprise
<reinhard> forgot to say
<reinhard> seems like our webpage wasn't updated since june 14
<reinhard> l8r
*** reinhard has quit IRC
<jcater> sigh
<jcater> I hate computers
*** dcmwai has joined #gnuenterprise
<jamest> dimas: i think it's character position in trigger
<jamest> as triggers do check for tabs 
<dimas> jamest: thanks, seems so
<jamest> not sure why we report by character
<jamest> vs breaking apart and scanning for tab line by line
<jamest> probabaly something to do with derek
*** gsoti has left #gnuenterprise
*** dcmwai has quit IRC
*** johannesV_ has quit IRC
*** johannesV has joined #gnuenterprise
*** Vee2d2 has quit IRC
*** Vee2d2 has joined #gnuenterprise
*** johannesV has left #gnuenterprise
<SachaS> see you later or tomorrow
*** SachaS has quit IRC
<derek> jcater: is there a way we can have logging bot email one of us nightly, as well as the nightly tarball process as well as the website update?
<derek> as it seems these processes have tendency of stopping and we dont notice for a few weeks.. if we had nag mail included in the the processes we would recognize sooner (i think)
<jcater> um
<jcater> well
<jcater> it has been emailing nightly
<jcater> I just get a lot of "nag" emails nightly =)
<jcater> actualyl, it has been running and updating, fwiw
<jcater> it somehow ran into some permission issues
*** siesel has joined #gnuenterprise
<siesel> hi all
<ajmitch> hi siesel
<ajmitch> how are you?
<siesel> fine :)  
<siesel> just a bit busy  :(
<ajmitch> haven't seen you here much lately :)
<siesel> what about you?
<ajmitch> busy with uni again
<ajmitch> about to go off & do some work now
<siesel> cool
<siesel> what kind of work? 
<siesel> still connected with dotgnu or doing gnuE rollout ;)
<ajmitch> phpgw upgrade
<siesel> that nice stuff
<ajmitch> yep
<ajmitch> ok, got to go, bbl :)
<siesel> cu
<chillywilly> hey hey hey
<siesel> hi chillywilly
<chillywilly> wassup dude?
<chillywilly> I wish I had come change to get a soda...I would kill for one
<chillywilly> hmmm, my plugin registry that uses a python metaclass is not working the way I would like it to
<siesel> my lvm root setup isn't working, and it seems that I can't fix it :(
<chillywilly> blah
*** SachaS has joined #gnuenterprise
<SachaS> hi everyone
<SachaS> hi siesel
<siesel> hi SachaS
<SachaS> how are you?
<SachaS> long time no see
<siesel> I'm fine, got a good job now.
<SachaS> still the same, the one you dont get any time for gnue?
<siesel> yeah. And what is worse: I've to code a bit MS ACCESS :(
<SachaS> outch
<SachaS> outsch
<siesel> But that has to change. Last week I began to work on setup-cvs.py to support win32
<SachaS> your talking about setup-csv.py of gnue?
<siesel> yep
<SachaS> did you check out the progress of appserver, lately?
<siesel> I just read commit notes. And that looks like they are making good progress
<siesel> I really have to set it up on my win32 only laptop
<SachaS> i see
<siesel> night all
*** siesel has quit IRC
*** jamest has left #gnuenterprise
*** dneighbo_ has joined #gnuenterprise
*** dneighbo has quit IRC
*** jamest has joined #gnuenterprise
*** wayneg has joined #gnuenterprise
<SachaS> good night
* SachaS is away: away
*** gsoti_away has joined #gnuenterprise
*** holycow has quit IRC
*** SachaS has quit IRC
*** sjc has quit IRC
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
<wayneg> Is there any docs on writting a python class/package that can be used as a datasource ?
<chillywilly> hmmm, I don't think so
<chillywilly> read the source ;)
<chillywilly> that's about all there is for writing  db driver, afaik
<chillywilly> shouldn't be too hard...there's some nice base classes
<wayneg> thanks chillywilly =)
<jcater> gnue-common/src/datasources/drivers/Base
<jcater> will show you all the exposed methods 
*** jamest has quit IRC
*** jcater has quit IRC