*** weex has quit IRC
*** reinhard has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<reinhard> good morning all
*** kilo has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** btami has joined #gnuenterprise
<btami> good morning
<kilo> good morning
<yure> morning :)
*** docelic has joined #gnuenterprise
*** dimas__ has joined #gnuenterprise
*** dino4k has joined #gnuenterprise
*** yure has quit IRC
*** dino4k has quit IRC
<kilo> python 2.5 approaching, alpha 1 is out
*** btami has quit IRC
<reinhard> *wow*
<reinhard> python 2.5 will natively include sqlite3
*** sacha has quit IRC
*** yure has joined #gnuenterprise
*** jamest has joined #gnuenterprise
<jamest> wow, python 2.5 includes sqlite?!?
<reinhard> well to be precise
<reinhard> the sqlite3 bindings for python
<reinhard> not the c library itself (but it will most probably depend on it in that case)
<jamest> odd
<jamest> why include the binding at all
<jamest> unless as a way to point people to a simple sql based backend
<reinhard> well
<reinhard> I think for the same reason as they included TK bindings
<reinhard> to have something working out of the box without external dependencies
<jamest> i guess that would make some sense
<jamest> on input masks
<jamest> the code in there was blocking the mixing of types in some cases
<reinhard> I saw you joined the commit party :)
<jamest> i'm trying to regrok the input mask system
<jamest> i put in lots of comments on my last attempt and while they help they aren't quite enough :)
<jamest> if A = alphanum and # = numeric and D = date
<jamest> the system was ok with a mask like
<jamest> AAAAA
<jamest> AAA ### DDDDDDD
<jamest> but not things like
<jamest> #### DDDDDDD
<jamest> i removed that block as I thought it somewhat arbitrary
<jamest> as the biggest danger I could see is when we tell it to go right to left (as in numeric input)
<jamest> dealing with dates could be odd, but no worse than a A # D combo
<reinhard> combining something else with dates sounds odd to me
<jamest> i'd agree with that
<jamest> the only thing I could think of where I'd posibly use that
<jamest> is a made up code like for an rma
<jamest> YY-MMDD######
<jamest> or some such thing
<reinhard> hmmmm
<reinhard> agree
<jamest> i'm hoping jcater will recall more about the blocks in place
<reinhard> but that would then have to be
<reinhard> 06-040600017
<reinhard> not 06-0406   17
<reinhard> while for only #####
<reinhard> you would want    17 instead of 00017
<jamest> but in building a mask you had to pass in the mask and two booleans (date=t/f numeric=t/f)
<jamest> which it would then build the mask, and compare to results to the booleans
<jamest> so if numberic was T and there were date tokens in the mask it'd abort
<jamest> however the mask "type" was set based upon the contents of the mask
<jamest> and not the booleans
<jamest> so the booleans  only provided verification and seemed to hard code specific type info into the mask creation
<jamest> i think the mask should set the type and all verification should be internal to the tokenizer
<reinhard> I think I agree
<reinhard> well
<reinhard> hmmm
<reinhard> yes and no
<reinhard> the question is what kind of value you want to get from the mask, actually
<reinhard> I think if you have a numeric mask, you want to get a number
<reinhard> for a date mask, you want to get a datetime object
<jamest> right now it's always a string
<reinhard> but we might also define that it's up to the caller to convert
<jamest> and I see that as ok as we're linking to a text field
<jamest> as with the mask
<jamest> mm/dd/yy
<reinhard> but it adds a lot of overhead
<reinhard> like we get datetime from the database, and we need to push datetime into the database
<reinhard> and somebody needs to do the conversion
<jamest> as I type 99
<jamest> the mask is formatting that
<jamest> so how can I return a valid datetime for that?
<jamest> even though I'm expecting a date as the final result
<jamest> and we might have 3 different masks for a field
<jamest> (and the 3rd one pops right out of my head)
<jamest> but the 1st two are "as displayed when not editing" and "while editing"
<jamest> and if the input mask system returned a datetime object for input you'd have to then somehow map that datetime object back to the displayed value in the widget on the screen
<reinhard> I'd think
<reinhard> the mask object would be able to return a string to display on screen
<reinhard> and a final value to store in the database
<reinhard> they must be different
<reinhard> as I might want to see 04/06/06 on screen, but the DB wouldn't understand that anyway
*** derek has quit IRC
<jamest> so forms would be adjusted to store two values per field then?
<reinhard> IIRC it already does
<reinhard> the displayhelpers have a "value" and a "work" variable
<jamest> yes
<jamest> but the gffield didn't know about that I didn't think
<jamest> it passed it's value into the displayhelper which produced the appropriate output
<jamest> though my memory is probably too outdated
<reinhard> that's correct
<reinhard> but IMHO the GFField should also be allowed to pass a datetime object
<reinhard> and shouldn't have to bother with string representation
<jamest> i can see value in that
<jamest> and during the intermediate step
<jamest> say the partial entry of 2006-03-06
<reinhard> the GFField is only updated when you tab away from the field anyway
<jamest> the display helper/input mask system would keep the va
<reinhard> so no need to convert during intermediate step
<jamest> yeah, that was what I was going to ask :)
<reinhard> as a nice side effect
<reinhard> the mask system would throw an exception if the conversion can't be done
<reinhard> which would make it impossible to tab away from a wrong date
<jamest> so in the case of numbers
<jamest> we'd always return a Decimal instance or a Decimal and/or int
<reinhard> for ints I think an int
<reinhard> I have no idea where we stand with regards to decimals
<reinhard> I don't know if all backends support Decimal
<jamest> i try to never use them in house
<reinhard> (though I highly doubt it)
<jamest> why not provide an adaptor for db modules that require it
<jamest> as in my triggers in forms I convert all fields to Decimal when doing math
<jamest> as python's built in decimal will burn you
<jamest> but in any case I have to get them working prior to worrying about that :)
*** btami has joined #gnuenterprise
<jamest> i figured input masks would be as good a component as any to make my 1st GAP test component from
*** kilo has left #gnuenterprise
<jamest> man there were a lot of commits yday weren't there
<reinhard> yes
<reinhard> btw I really wonder how comes I get moderator messages from commit-gnue
<jamest> that's the gnu.org list isn't it?
<reinhard> yes
<jamest> you'd have to be listed as a list administrator
<jamest> i imagine when you were made a moderator of the announce list one of us just slapped your name on all of them :)
<jamest> sigh, my gnu.org email address is a spam pit
<jamest> it's the only place I still really get spam from
<reinhard> I am a moderator of the announce list?
<jamest> reinhard: i thought we did that so you could release your own annoucements
<reinhard> ah
<reinhard> no I am just set to "may post on this list"
*** dimas__ has quit IRC
<reinhard> anyway
<reinhard> it would make more sense to discard any non-@gnuenterprise.org mails on commit-gnue than to moderate it
*** docelic has quit IRC
*** jcater has joined #gnuenterprise
<jcater> I missed the party
<jcater> input masks were supposed to return the appropriate data type
<jcater> it does separate out 3 types of masks
<jcater> numeric, date/times, and general strings
<jcater> each set having its own set of mask elements
<jcater> so MMDD isn't gonna work in numeric
*** johannesV has quit IRC
<jcater> (this was the plans... don't want ot sound like a dictator :)
<jcater> (this is where I was taking them)
<jcater> jamest: I was putting all of my effort into only one of the 3
<jcater> I forget which one
<jcater> but I wanted to get the core code down before writing the other two
<jcater> which may be why it just returns a string now
<jcater> I think it was numericd
<jcater> numeric
<jcater> that I was working on
<jcater> as it in my mind is by far the hardest to get right
<jamest> numeric is the one that is broken atm
<jamest> text and date work fine
<jcater> with comma-addition, fixed or floating decimal support, and support for optional characters
<jcater> (# iirc)
<jamest> yes
<jcater> cool
<jamest> iirc it's the decimal or comma tokens that puke
<btami> jcater: is something missing in designer svn head?
<btami> DB000:    File "/adat/svn/gnue/.cvsdevelbase/gnue/designer/forms/PagePainter/skins/common.py", line 27, in ?
<btami> DB000:     from gnue.designer.ui.wx.uihelpers.doccanvas.colors import color_map
<btami> DB000:  ImportError: cannot import name color_map
<btami> t
<jcater> hmm
<jcater> what svn version are you on?
<btami> 8383
<jcater> sigh
<jcater> that explains why my changes aren't showing up
<jcater> I renamed colors.py to settings.py as I added font info
<jcater> but that file is seeing my colors.pyc
<btami> ah
<jcater> let me commit a fix
<jcater> you should know though, I'm actively working on designer
<jcater> it should run, but isn't fully functional yet
<btami> yes, i know
<jcater> plus, I'm developing it at work on a Mac, then svn committing and editing at night on Ubuntu, so hopefully I don't have any platform-specific wx-oddities
* jcater needs to set his windows laptop up to run it too, so I can test it there
<btami> it's ok now, thx
<jcater> are you testing it out on windows, by chance?
<jcater> if so, could you do me a huge favor and open a form, view the page layout painter, and take a screenshot ... I have been having some issues with wx's mapping of system colors and fonts
*** johannesV has joined #gnuenterprise
<btami> jcater: downloading wxpython 2.6.3.2 for windows...
<jcater> ... if you have time
<btami> DB000:    File "c:\python24\Lib\site-packages\gnue\designer\forms\PagePainter\PagePainter.py", line 64, in init
<btami> DB000:     dc = wx.PaintDC(self)
<btami> DB000:    File "C:\Python24\Lib\site-packages\wx-2.6-msw-unicode\wx\_gdi.py", line 4540, in __init__
<btami> DB000:     newobj = _gdi_.new_PaintDC(*args, **kwargs)
<btami> DB000:  PyAssertionError: C++ assertion "wxAssertFailure" failed in ..\..\src\msw\dcclient.cpp(221): wxPaintDC may
<btami> ted only in EVT_PAINT handler!
*** derek has joined #gnuenterprise
<jcater> well, fsck me
<jcater> thanks, btami
<jcater> guess I better set up a windows test machine :)
<btami> :)
<jcater> roflmao
<jcater> googlign for that error
<jcater> returns an irc log from 2003
<jcater> as the 2nd hit:
<jcater> <btami> DB000:   File "c:\python23\Lib\site-packages\gnue\designer\base\startup\Startup.py", line 49, in startupStatus
<jcater> <btami> DB000:     self.drawText(wxWHITE)
<jcater> <btami> DB000:   File "c:\python23\Lib\site-packages\gnue\designer\base\startup\Startup.py", line 54, in drawText
<jcater> <btami> DB000:     dc = wxPaintDC(self.GetSplashWindow())
<jcater> <btami> DB000:   File "C:\Python23\Lib\site-packages\wxPython\gdi.py", line 1077, in __init__
<jcater> <btami> DB000:     self.this = gdic.new_wxPaintDC(*_args,**_kwargs)
<jcater> <jcater> unless it's an easy fix, then i might be able to right now
<jcater> <btami> DB000: wxPython.wxc.wxPyAssertionError: C++ assertion "wxAssertFailure" failed in c:\PROJECTS\wx\src\msw\dcclient.cpp(216): wxPaintDC may be create
<jcater> <jcater> wha?
<jcater> I guess I never learn, eh?
<jamest> sure you have
<jamest> back then
<jamest> <jcater> wha?
<jamest> now
<jcater> jcater: so you know the answer 3 yrs from now when you do this again, you were supposed to use wxClientDC outside of OnPaint, wxPaintDC inside of it
<jamest> <jcater>well, fsck me
<jamest> you've learned that you're in for some rough wx loving
<btami> rofl
<btami> goat luvin or something :)
*** derek has quit IRC
*** derek has joined #gnuenterprise
<btami> jcater: http://www.gnuenterprise.org/~btami/gnue-designer.png
<jcater> thanks
<jcater> btami: is that emulated winxp?
<btami> yes
<jcater> what are you using?
*** sacha has joined #gnuenterprise
<btami> VMware Player
<btami> notice that toolbar icons look same (wrong) on native XP, contrary to gnue-forms with wx26
<btami> johannesV knows something about wx toolbar icons on win32...
<btami> hmm, and the toolbar for layout editor ismissing
<btami> maybe it's by the reorganisation
*** derek has quit IRC
*** btami has quit IRC
*** derek has joined #gnuenterprise
<reinhard> off for today
<reinhard> cu all
*** reinhard has quit IRC
*** derek has quit IRC
<johannesV> what's the problem with toolbar icons ?
<dimas> for us guys - how you name registration mark on a car? sign, number, mark or what?
<jcater> license plate ?
<dimas> yes, that name?
<johannesV> there's a problem with guessing the transparent colour on win32, so there's an option to turn that off ...
<johannesV> # Make sure to disable the color-remapping in windows
<johannesV>     wx.SystemOptions.SetOption ('msw.remap', '0')
<johannesV> this option has to be set *before* a toolbar get's created and the icons will look good :)
*** derek has joined #gnuenterprise
*** jcater has quit IRC
*** derek has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** klasstek has joined #gnuenterprise
*** yure has quit IRC
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** weex has joined #gnuenterprise
*** johannesV has quit IRC
*** docelic has joined #gnuenterprise
*** weex has quit IRC
*** kilo has joined #gnuenterprise
*** jamest has quit IRC
*** kilo has left #gnuenterprise
*** klasstek has quit IRC
*** sjc has quit IRC
*** derek has quit IRC
*** jcater has quit IRC
*** derek has joined #gnuenterprise
*** sacha has quit IRC
*** sacha has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** dimas has quit IRC
*** dimas has joined #gnuenterprise