*** reinhard has joined #gnuenterprise
*** jcater has quit IRC
*** johannesV has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** sjc has joined #gnuenterprise
<reinhard> btami: just fyi
<reinhard> btami: i told you that you have to enclose all callback hooks in try/except in windows driver like we did in gtk2 driver
<reinhard> most probably you don't need to do that
<reinhard> like we in gtk2 also wouldn't have needed it and therefore removed it again
<reinhard> so all you really could do is create a nifty exception message box with a >>detail button to display the traceback
<reinhard> (preferredly in a copy&paste-able way)
<reinhard> see _showException in gtk2/UIdriver.py
<btami> reinhard: i'd noticed it all from commit messages :)
<btami> fortunately, e was lasy enough not to do anything yet :)
<btami> s/e/i
<reinhard> :)
<btami> btw. what do you think about how/where to define the "default character set" when creating new db for
<btami> appserver
*** wt has joined #gnuenterprise
<btami> with kinterbasdb we can do that in create_database()
<btami> if we do nothing, all new db created will have ascii as default
<btami> and its not too good...
<reinhard> what would be the reason to create the database with a (internal) character set other than unicode / utf-8 ?
*** sjc has quit IRC
<reinhard> s/would/could/
<btami> i like unicode too
<reinhard> do i understand correctly that
<reinhard> internal character set != client encoding
<reinhard> ?
<btami> yes
<reinhard> so i'd propose to always use unicode for internal
<reinhard> so we can still use any client encoding we want
<ajmitch_> hello
<btami> i'm ok with this
*** sjc has joined #gnuenterprise
<btami> ajmitch_: hi
<reinhard> and don't need another parameter that will just confuse many users not familiar with character sets
<btami> ok
<reinhard> btami: do you know what it would take to change this?
<ajmitch_> reinhard: when's appserver 0.2 due out?
<ajmitch_> 0.1 should be in sarge in 3 days
<reinhard> ajmitch_: i'll do the gnome way
<reinhard> release version n+1 as soon as n reaches sarge
<reinhard> ;-)
<ajmitch_> 0.1.9x?
<ajmitch_> heh
<reinhard> ajmitch_: 0.1.90 was released yesterday
<btami> reinhard: the question is how we can do(can we?) it with postgresql/mysql/etc. database creation
<btami> i know only the kinterbasdb way
<ajmitch_> ok, should I bother packaging it? :)
<reinhard> just didn't get around to announce it yet
<reinhard> ajmitch_: please try packaging it
<ajmitch_> no new common?
<reinhard> there won't be many changes between 0.1.90 and 0.2
<reinhard> and it would be a test if packaging works
<reinhard> as you already did find problems in packaging in the pas
<reinhard> past
<reinhard> yes, new releases for common and forms
<ajmitch_> reinhard: please tell me that you lowercased the tarball name? ;)
<reinhard> they could be packaged in any case
<reinhard> and yes, tarballs are lowercase
<btami> :)
<ajmitch_> yet more releases...
<reinhard> especially for you :)
<ajmitch_> excellent!
* ajmitch_ looks on the website
<reinhard> ajmitch_: however, it might be better to not upload new releases until those before have hit sarge
<ajmitch_> I won't
<reinhard> ok
<ajmitch_> it took long enough to get the last ones uploaded ;)
<reinhard> 0.2 might take a week or so
<ajmitch_> sarge doesn't appear to be freezing anytime soon
<reinhard> if we don't find serious problems
<ajmitch_> do you have a list of what's new in common & forms?
<ajmitch_> we should really test reports & navigator & designer when new releases come out
<reinhard> btami: as to postgres, you usually define the internal encoding of the db when you install it
<reinhard> btami: so i'm not sure if we should do anything at all there
<johannesV> reinhard, but this can be changed on creation of every single db in postgres (diffrent vom setup)
<reinhard> johannesV: then it might be good to change it in postgres to always use unicode, too
<btami> cool
<johannesV> CREATE DATABASE name
<johannesV>     [ [ WITH ] [ OWNER [=] eigentümer ]
<johannesV>            [ LOCATION [=] 'pfad' ]
<johannesV>            [ TEMPLATE [=] template ]
<johannesV>            [ ENCODING [=] kodierung ] ]
<reinhard> johannesV: and you could check how that works in mysql (brrr) and sqlite (double brrr)
<johannesV> but i'm not sure if this is a *new* feature in 7.4.*
<reinhard> johannesV: ah ok
<johannesV> well, mysql-driver does *not* support create_db () by now
<btami> btw. 7.5 is coming!
<reinhard> johannesV: please check this out for postgres and sqlite
<johannesV> yeah
<johannesV> i'll check it
<SachaZzzz> morning
<reinhard> btami: and if you could care for interbase it'd be great
<btami> i will
<reinhard> and all our main db backends would be up to date again
<reinhard> thanks both :)
<johannesV> btami, please note there are different versions of kinterbasdb module around the web
<reinhard> ajmitch_: as to reports, navigator and designer
<reinhard> many people use them from cvs with current common
<johannesV> so if your create_database () can handle encoding, please make sure which version you're using
<reinhard> so i'm not too worried
<johannesV> (last time we had major differences in the  win*modules and the linux-modules and the debian-modules)
<btami> ok
<SachaS> see ya later
*** SachaS has quit IRC
<ajmitch_> cdbs makes rolling new packages so nice & easy ;)
<ajmitch_> good, only one (intentional) lintian error
<reinhard> ajmitch_: fwiw, new forms & appserver depend on new common
<ajmitch_> I guessed that they would :)
<ajmitch_> common & appserver built
<reinhard> ajmitch_: thanks, great
*** agx has joined #gnuenterprise
<ajmitch_> hi agx
<agx> morning ;-)
<ajmitch_> ok, new forms just about done as well
<ajmitch_> done
<reinhard> ajmitch_: any lintian messages?
<ajmitch_> nothing new
<ajmitch_> only one because I set the distribution to UNRELEASED ;)
<reinhard> ah :)
*** kilo has joined #gnuenterprise
*** sjc has quit IRC
*** SachaS has joined #gnuenterprise
*** sjc has joined #gnuenterprise
<kilo> good morning
<SachaS> hi kilo
<kilo> hi SachaS, how are you?
<SachaS> good thanks
<SachaS> got a job :)
<SachaS> job = paid work
<kilo> oh poor you...
*** agx_ has joined #gnuenterprise
<kilo> oh, now i understand everything!!!
<kilo> i've read that an avarage american spends 8.6 hours sleeping and only 3.7 hours working
<kilo> and even worse, they only spend 20 minutes a day thinking
<SachaS> :)
*** agx_ has quit IRC
*** agx has quit IRC
*** btami has quit IRC
*** lekma has joined #gnuenterprise
<lekma> morning all
<kilo> hi lekma
<lekma> hi kilo
*** btami has joined #gnuenterprise
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
<lekma> is the new release officially out?
<ajmitch_> yes
<ajmitch_> new release of forms & common, I think appserver is a prerelease
<ajmitch_> lekma: fyi tarballs & dirnames inside them are lowercased now
<lekma> ajmitch_: can i use what's on the webserver to update gentoo pakages
<lekma> ?
<reinhard> appserver is a release, but a beta version
<ajmitch_> lekma: sure
<ajmitch_> reinhard: ok, wasn't sure what you were calling it :)
<reinhard> actually i don't mind very much :)
<ajmitch_> lekma: I presume the ebuilds will need to be updates
<lekma> ajmitch_: yep
<lekma> do you mind if i keep technotes in the doc?
<ajmitch_> shouldn't be a problem
<ajmitch_> I guess :)
* ajmitch_ is just a packager
<reinhard> lekma: no problem
<reinhard> lekma: they are intended for developers, but they are in no way "secret" :)
<lekma> well they are pruned in setup.py
<lekma> so i thought you didn't want them in docs
<lekma> but i find them useful
*** sjc has quit IRC
<lekma> ajmitch_: but the official name is still GNUe (uppercase) right?
<ajmitch_> one would assume so..
<ajmitch_> it's just standard that tarballs be lowercase
<lekma> :-)
<lekma> just to be sure
<lekma> there is still a man page for gnue-import in common eventhough it was removed
<reinhard> lekma: excellent bug report
<lekma> this was not a bug report
<reinhard> it was:)
<reinhard> and the bug is fixed for the next release
<lekma> :-) so i'm doing bug reporting wiyhout knowing it
<lekma> s/wiyhout/without
<kilo> johannesV: if you, on your machine type 'gfcvs foo.gf' so to not be able to open the file, ie produce a file not found error, what happens
<kilo> ?
<SachaS> running for lunch
<SachaS> have a nice weekend.
*** SachaS has quit IRC
<johannesV> Unable to open file
<johannesV> [Errno 2] Datei oder Verzeichnis nicht gefunden: 'foo.gf'
<johannesV> in a nice gtk-error-dialog bos
<johannesV> s/bos/box
<kilo> hmmm, i get unicode error...
<johannesV> well, shall i try hu-locale
<kilo> if you could
<reinhard> johannesV: looks like a %s exception formatting
<johannesV> it says i've found a bug in gnue
<johannesV> :)
<johannesV> reinhard, yes, i think so too
<kilo> yes, yes
<johannesV> i can track it down
<reinhard> johannesV: and if you change that, please also change it to be only one line
<reinhard> i hate multiline exception messages
<reinhard> they break exception display in curses ui :)
<kilo> my true love is the 'unexpected internal error'. who expects errors... 8-))
<johannesV> Unable to open file
<johannesV> [Errno 2] Nincs ilyen fájl vagy könyvtár: 'foo.gf'
<johannesV> is that better ?
<johannesV> :)
<johannesV> for reinhard: Unable to open file: [Errno 2] Nincs ilyen fájl vagy könyvtár: 'foo.gf'
<btami> johannesV: locale.getlocale() in i18n returns 1250 not cp1250 on win
<btami> and ISO8859-2 not iso88569_2 on linux
<btami> so it's not a valid Python encoding
<johannesV> kilo, please svn-up
<johannesV> btami, where does that encoding conflict ?
<btami> errors.py line 127
<btami> LookupError: unknown encoding: 1250
<kilo>  /msg johannesV btami is sooo eager to put a Details button somewhere, that he needs a messagebox badly...
<johannesV> btami, what does locale.getencoding () return ?
<johannesV> we're interessted in encoding at this place
<johannesV> not the locale-string
<johannesV> ah, damn
<johannesV> i mean what does i18n.getencoding () return
<btami> 1250
<johannesV> and in pyhton: foo = unicode ('bar', '1250') gives an error ?
<johannesV> have to leave for lunch now
<btami> yes, the same
<johannesV> maybe i can set up a windows environment for gnue over the weekend and try it there
<btami> there is no 1250 encoding in Python
<btami> yust cp1250
<johannesV> hmm, so this seems to be a bug in python or in locale-module
<btami> s/yust/just
<johannesV> :)
<btami> no
<btami> locale.getlocale gives som RFC names
<btami> but Python uses hes own encoding names
<btami> as you can see in lib/locales or what...
<btami> lib/encodings
<btami> it just needs a mapping, like we did it in same dbdrivers
<btami> bbl
*** btami has quit IRC
<lekma> is there any log option for appserver
<lekma> ?
<lekma> i mean logging in a file
<lekma> it seems i've exhausted the patience of people around here...
<reinhard> lekma: no
<reinhard> except for gnue-appserver > logfile
<reinhard> :)
<lekma> i may be wrong (cause it's been long since i did it) but gnue-appserver > logfile send only the startup lines to the file and nothing else, even if you add --debug-level xx
<reinhard> then maybe you need to add 2>&1
<lekma> well it seems i did
<lekma> gnue-setupdb is now all that is needed to setup an initial gnue appserver, right? (i ask all those question just to be sure, even if sometimes they do seem stupid)
<reinhard> lekma: correct
<lekma>  i may be wrong but gnue-setupdb seems not to be in params['scripts'], it is then not installed...
<lekma> can someone please verify
<reinhard> lekma: correct, and fixed
<reinhard> that's why we do prereleases :)
<lekma> are common and forms also pre-releases?
<reinhard> no
<reinhard> we hope there are no serious bugs :)
<lekma> so i'll wait for appserver release to update ebuilds (they seem good so far, i just wish forms and appserver used the same syntax for installing docs as in common)
<lekma> but it's no big deal
<reinhard> lekma: i don't understand
<lekma> in gentoo the docs folder are versionned
<lekma> so in common i just have to add params['version'] to the copy_to
<lekma> and in forms i have to replace share/doc/gnue-forms share/doc/gnue-forms-0.5.7 everywhere
<lekma> in appserver it's only 2 lines
<reinhard> lekma: hmmm
<reinhard> lekma: i might have a look at that
<reinhard> maybe i can add a parameter for the doc directory
<reinhard> to setup.py install
<lekma> reinhard: ok, but it really is no big deal
<reinhard> setup.py install --docdir=/foo/bar
<reinhard> if i have time and am bored ;-)
<lekma> did you see my asking for explanations on messages?
<lekma> cause the OnInit case seems strange
<lekma> what should i expect when i call messge('something')
<lekma> ?
<reinhard> that returns a string
<reinhard> it doesn't display a message or anything else
<reinhard> it just gets the string
<reinhard> so you can for example
<lekma> well in an OnInit it has a colateral behaviour that it doesn't store new records
<reinhard> return message ('foo')
<reinhard> that's strange
<lekma> ie when i use it with generated forms
<reinhard> will have to test that
<lekma> and on a side note please tell me if my testing various features in a disordered fashion and coming bugging you is annoying
<lekma> ie if i'm a pain in the ass
<lekma> i can stop
<reinhard> lekma: please don't
<reinhard> lekma: you help massively to improve the quality of gnue
<reinhard> lekma: apart from that i want to help where you have problems
<lekma> yeah yeah :-)
<reinhard> but also you might have to accept that i can't always react immediately
<reinhard> this does *not* mean you are annoying :)
* ajmitch_ can do annoying..
<lekma> :)
<kilo> lekma: it's not annoying, it is called testing...
*** SachaS has joined #gnuenterprise
*** kilo has quit IRC
<reinhard> hmmm
<reinhard> this release script starts to become really cool
<SachaS> hi reinhard :)
<SachaS> alles klar? :)
<reinhard> hi SachaS
<SachaS> my sister marries in the civil hall this afternoon in about 2 hours, guess I have to get ready ;)
* SachaAway is away: away
*** gsoti_away has joined #gnuenterprise
*** agx has joined #gnuenterprise
*** agx has quit IRC
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** jamest has joined #gnuenterprise
*** holycow has quit IRC
*** kilo has joined #gnuenterprise
<chillywilly> anyone know of any open source/free "knowledge base" software?
<kilo> freemind on sf
<chillywilly> iut'd alos be nice if somehow you could integrate that with bug tracking/issues software
<chillywilly> like you could take an incident and elevate it to a "knowledge base" article or some such thing
<kilo> i've heard of something named... err... hmm.... gnue, yes, gnue. you can produce your own software with it easily and quickly 8-))
* chillywilly looks at freemind
<chillywilly> yea I coudl roll my own
<chillywilly> but I have more important things to do
<kilo> more importan??? 8-))
<chillywilly> yea
<kilo> hmm, strange...
<dimas> hi all
<dimas> kilo: would you continue to work on gnue-packages?
<kilo> hi dimas
<kilo> yes, but not alone
<dimas> who's else? :)
<kilo> hmmm, you?
<dimas> i could test
<dimas> already started
<kilo> i would say only testable package is LOC
<dimas> i need comm also
<kilo> doable in reasonable time
<dimas> will you be here at weekend?
<kilo> mainly yes, depends on weather
<dimas> ok
*** jcater has joined #gnuenterprise
<reinhard> kilo: we have to talk about packages
<reinhard> (but not now)
<dimas> reinhard: would you please kick to awake me when you start talking about it?
<reinhard> dimas: i can try :)
<dimas> thanks :)
<reinhard> in short (so you can think about it over night)
<reinhard> i am tempted to view the current loc module as overkill
<reinhard> there are 5 classes (== 5 tables in the database)
<reinhard> and that doesn't even contain the name
<reinhard> if i look what's coming in the person.gcd module
<reinhard> it seems like the information like
<reinhard> ---
<reinhard> Mister Reinhard Müller jr.
<reinhard> Enga 2
<reinhard> 6890 Lustenau, Vorarlberg
<reinhard> Austria
<reinhard> ---
<reinhard> will be distributed to about 8 tables
<reinhard> and i don't have a good feeling about that.
<reinhard> that's my main concern
<reinhard> apart from little details like i'm not sure we want the module name capitalized
<reinhard> or we want separate modules for location, person, communication etc.
<reinhard> instead of a single "base" module containing all basic stuff that has to be installed anyway
<reinhard> however, gotta go prepare dinner for kids
*** holycow has joined #gnuenterprise
<reinhard> jamest or jcater: can you please change the channel topic to something more neutral like
<reinhard> Watch http://www.gnuenterprise.org/project/news for new releases!
<dimas> reinhard: separate modules for location, person, communication etc. could be a requirements for someone
<holycow> congrats on the release guys :)
*** wendall911 has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
<kilo> dimas: i think it'll be about 3 hours from now that i will be here
<dimas> i need more testing first
<kilo> ok, i will be there and you'll see
<dimas> now i use simplified classes in realworld example
<dimas> 8 tables for keeping person's info could be overkill
<dimas> but i can't expect it in 1 table too
<kilo> i dont have time now, will explain it in detail later
<dimas> certanly i need separate entities for person, phones, towns (not so sure about streets/locations) and so
*** sjc has joined #gnuenterprise
*** nsk has joined #gnuenterprise
*** dcmwai has quit IRC
*** ChanServ sets mode: +o jcater
*** jcater changes topic to "Watch http://www.gnuenterprise.org/project/news for new releases!"
*** jcater sets mode: -o jcater
*** johannesV has quit IRC
*** mixi has quit IRC
*** mixi has joined #gnuenterprise
*** nsk has left #gnuenterprise
*** cilkay has quit IRC
<reinhard> jcater: thanks
<reinhard> dimas: i agree on separate entity on person and communication as that is a master/detail relationship
<reinhard> also i agree on separate country table as that makes sense
<reinhard> a sub-country-entity table (like u.s. states) probably makes sense; i can't judge because we don't have such a thing here
<reinhard> however a table for zipcodes and towns could already be problematic
<reinhard> at least here in at (and afaict also in de) there's no 1:1 relationship between zipcode and town
<reinhard> ...dimas: reinhard: separate modules for location, person, communication etc. could be a requirements for someone...
<reinhard> could you explain that?
<dimas> for example currently i need separate person, towns, address, communications separated
<dimas> though zip could be included in address info as simple field
<reinhard> what do you mean with "separated"?
<reinhard> sparate classes or separate modules?
<dimas> separate classes
<reinhard> ok, thought you were explaining why they should be separate modules
<reinhard> i agree on separate classes
<reinhard> acutally after reading through loc.gcd again
<reinhard> i am a bit uncomfortable with the street class
<dimas> i do not fully understand the issue (proper use) of modules
<reinhard> and the separate fields for number,building,staircase,floor etc.
<reinhard> dimas: think gnue module ~= debian package
<reinhard> off to watch tv, will be in and out
<reinhard> please just write, will answer in advertising breaks
<nickr> addict
<dimas> yesterday i was trying to reduce number of modules in my example, and reducing it even more evil then have too many
*** btami has joined #gnuenterprise
<dimas> as after i changed .gcd's i need to change all forms where full qualified names are used
<dimas> there is no street class in loc.gcd and it is overkill for me now how it is done there
<rm-tv> dimas: you have current svn?
<rm-tv> i have a street class :)
<dimas> updating.
<rm-tv> dimas: changing modules is always evil of course
<rm-tv> the more it's important to have some kind of strategy for modules from the start
<dimas> it was a place class previously, i se it now
<dimas> see
<dimas> rm-tv: if i have zip property defined as string(6) - field on the form constructed from .gld file is too short for it
<rm-tv> dimas: which ui?
<rm-tv> should work with gtk2, wx has problems with recognizing the font size IIRC
<wendall911> rm-tv: know why savannah went with svn instead of gnu-arch?
<wendall911> rm-tv: just curious is all
<rm-tv> wendall911: savannah went svn?
<rm-tv> that's new to me
<rm-tv> you sure??
<wendall911> rm-tv: hmmm, I thought you guys used savannah for svn
<wendall911> rm-tv: sorry if I assumed incorrectly
<rm-tv> you did :)
<rm-tv> we use our own svn server
<wendall911> rm-tv: so why did you guys choose svn over gnu-arch then ;)
<rm-tv> that was a decision of jamest and jcater
<rm-tv> i think we discussed svn, arch and even something else
<wendall911> rm-tv: ok, cool. I still use cvs for all my projects and am just gathering info. I really like the features of arch
*** wt has quit IRC
<rm-tv> wendall911: we have made quite good experience with svn
<rm-tv> kilo and dimas: did you actually ever look at base.gcd, base-*.gld and currcalc.gfd?
<kilo> yes, i've even reverse engineered your gl module
<rm-tv> reverse engineered??
<kilo> yes, drawn uml dia from that
*** cilkay has joined #gnuenterprise
*** btami has quit IRC
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** sjc has quit IRC
<kilo> yo, people, i am here
<kilo> dimas: wake up
*** holycow has quit IRC
<rm-tv> kilo: did you see my comments on loc.gcd?
<kilo> yes, i am 1) just writing my explanations 2) in a difficult process of chosing... gues what
<rm-tv> kilo: what whiskey to drink?
<kilo> yessss
<rm-tv> :)
*** sjc has joined #gnuenterprise
<rm-tv> ls
<rm-tv> err
<rm-tv> wrong window
<rm-tv> kilo: on a side note
<rm-tv> if we have references address -> zip -> region -> country
<rm-tv> then the reference address -> country seems to be redundant
<kilo> it is optional either this or that
<rm-tv> one option would be to enter an address without zip and city?
*** wendall911 has left #gnuenterprise
<rm-tv> rofl
<rm-tv> I have a theory that it's impossible to prove anything, but I can't prove it.
<rm-tv> nice quote :)
<kilo> rm-tv: erm, i have written a txt file with all my comments, what should i do now? copy it here?
<rm-tv> if it's less than 10 kb
<kilo> definitely
<rm-tv> so shoot :)
<kilo> LOC module notes
<kilo> It is divided into 5 classes just because to be more atomic.
<kilo> I think anyone can bring up an example where only a country, or only a zip code/city name pair is needed.
<kilo> In my own practise there is a firm where all of the streetnames of a given city is stored and only those names are used. So there esixts a need for storing all the streetnames of the town, so that no mistyping or something like that can occur.
<kilo> And envision it like this: county, region, zip and street classes are on the lower level, address class is over them, kind of aggregating them. It is already an example of reuse.
<kilo> 
<kilo>     It can seem that dividing an address into such detail is not important. Well, it is called LOC module, that is it can be used to store postal addresses or physical locations too. And why number/floor/door and so on are stored in address class? Because we need it here in Hungary to fill in a state tax form, in that divided form. So that is already an example of the use of a module.
<kilo>     Accessing a region name like Address.LOC_zip.LOC_region.LOC_name can seem tedious and like overkill. I myself also find it little bit difficult because of the need to write the LOC_ part everywhere. I would be happier if it was simpler, but i can live with that notation, as i know Reinhard has done his best to ease the use of appserver. It is a limitation and we have to use it this way.
<kilo> 
<kilo>     Such detail can be seen as overkill, but i don't think so. This module as a base module, must serve a good reliable basis for different kind of applications. If someone needs a simpler representation of a postal address, he/she/it<g> can put in a single entry in his own application's gcd for holding that.
<kilo> that's it
<rm-tv> hmmm
<rm-tv> you really have an application where all street names of all cities are stored?
<kilo> no, all streetnames of a given city
<rm-tv> and this company has only customers in that city?
<kilo> yes, its public sector
<rm-tv> my concern is
<rm-tv> if we use this address format for, say, the customer database in gnue
<rm-tv> it means that every gnue user has to fill in the street names table
<rm-tv> s/table/class/ :)
<rm-tv> otherwise an address cannot be entered
<rm-tv> most of the users i know of don't have 2 customers in the same street usually
<rm-tv> so even if there is a button to add a new street to the streets table
<rm-tv> i think it's quite annoying for the user to have to do that for every new address he enters
<rm-tv> however, the division of street/numbers/stair/door etc. for tax form is an argument i understand
<SachaS> me likes to have more fields than necessary, and have the forms giving a limited view on it.
<kilo> i agree with that, but i think these two definition modes are both usable
<rm-tv> kilo: also, i think we have to decide on a general strategy
<lekma> jcater: on a side note, do you remember the blue goat icon i made for designer?
<rm-tv> will "standard" "official" gnue packages provide the most full-blown data design imagineable
<kilo> take out own street for example. it is calle Makkoserdo sor. it is stated like that on each street table. But it's official spelling is Makkos-erdo sor. So one sitting in an office and entering the streetnam eof a customer could fill it this way once, that way another time. that means a single entity is named two different ways...
<rm-tv> and users will "switch off" things they don't need
<lekma> cause at this time i made a patch to incorporate it in designer
<lekma> so if you want it, please tell me
<rm-tv> or do we want to provide a "base" users can extend
<rm-tv> the former is the SAP way of doing things
<jcater> lekma: sure
<kilo> re base/fullblown: i have looked at several uses and standars defining addresses/locations. this LOC module is a very very little common part of them.
<kilo> in the README i've already pointed out some possible extensions
<rm-tv> kilo: you are also talking about an address management to be used in an erp system, right?
<rm-tv> for example to enter customer data, vendor data etc
<kilo> tha mi fallain, tapaidh leibh
<kilo> sorry, not aimed here
<lekma> you can fetch it in http://www.orwex.net/gnue-dev/gnue_overlay_20040812.tar.bz2 in the folder dev-python/gnue-designer/files/gnue-designer-icon.diff
<kilo> yes, address management also
<lekma> it mormally applies cleanly on 0.5.4
<rm-tv> to be honest, what i've seen most for that is address-line-1 to address-line-5
<rm-tv> probably a distinction between zip and city
<rm-tv> and probably selection of a country from a list of countries
<rm-tv> if i understand it correct, it's not possible with your gcd to enter an address with a street not being listed in the street class, right?
<kilo> you can put one entry on a form and then customize the gcd so that it could handle single-line entry and then try to split it considering common-sense use in that country
<rm-tv> kilo: i'm talking about the street name there
<kilo> re streetname: yes. it is a weak point. maybe there should be two alternative ways to enter it
<rm-tv> if i live in a street called "Enga" there has to be a record in LOC_Street with the name "Enga", right?
<rm-tv> ah
<rm-tv> ok
<rm-tv> also the distinction between street name and street type seems uncommon to me
<kilo> right, but the business logic could be so that it would recognise str or strasse and put a record in street class
<kilo> street name is purely the name, and type is like street,boulevard, road, etc.
<rm-tv> this makes it so complicated
<rm-tv> you have telegraph road in english
<rm-tv> rue de la fayette in french
<rm-tv> and in german we even have bahnhofstrasse
<jcater> not to butt-in on a conversation I haven't been following
<rm-tv> (in one word)
<jcater> but we do millions of pieces of mail here at my office
<rm-tv> jcater: we know that you always do that ;-)
<kilo> to be honest it should be stored in an other class... but then i would have to hear that there are 6 classes in the module 8-)))
<rm-tv> j/k
<jcater> and that address scheme is a recipe for disaster imho
<jcater> rm-tv: there's a reason most places have address1 ... 5
<jcater> just in the US, addresses are very, very inconsistent
* jcater couldn't imagine world-wide
<rm-tv> jcater: i'm not sure what you're trying to hint us here
* jcater goes back to his hole
<kilo> i've received a post from an australian guy from here some weeks ago, and the australian post has standards for mail addresses...
<rm-tv> jcater: you think address 1-5 is better or worse?
<jcater> for the residential part of the address, address1-5 would be more universal
<jcater> but still separate out postal code, country, foreign region, city, etc
<jcater> that's the way I usually see it
<jcater> and for good reason
<rm-tv> jcater: actually i would 100% agree with you if there wasn't the "etc"
<rm-tv> which i'm not sure what is behind that :)
<rm-tv> s/is/could be/
<jcater> well
<jcater> s/etc/
<jcater> those are the ones I see
<rm-tv> jcater: ok, thanks :)
<rm-tv> kilo: also, your system completely breaks if there is a po box
* rm-tv envisions next release of designer
<rm-tv> New features/chages in 0.5.5:
<rm-tv> * Added goat icon
<rm-tv> :)
<SachaS> good night
<rm-tv> night SachaS
<rm-tv> grrr
<rm-tv> i always wanted to go to LegoLand once :)
<SachaZzz> ;)
<kilo> what if i tumble in legoland and break up some buildings? Do i have to stay and rebuild it?
<rm-tv> kilo: i think there is no whiskey in legoland
<kilo> rm-tv: pobox would simply go to address class
<rm-tv> ;-)
<kilo> i can tumble anywhere regardless of whisky
<rm-tv> kilo: but then, you need another table where you define what "pobox" is in different languages
<rm-tv> seriously
<kilo> i dont follow
<kilo> why
<rm-tv> in the address you have to write
<rm-tv> for example
<rm-tv> BYTEWISE Software GmbH
<rm-tv> Postfach 4711
<rm-tv> 6890 Lustenau
<rm-tv> Austria
<rm-tv> if the po box is a separate property
<rm-tv> would that hold "4711" or "Postfach 4711"?
<kilo> it is a quiestion of report design. you have to customize that report that prints the address
<kilo> 4711
<rm-tv> but if i have a customer in england, too
<kilo> then there is the country info...
<rm-tv> i would have to write "po box 4711" for that customer
<kilo> and based on the country the report uses another string
<rm-tv> i am not sure if the levels of complexity we add here are worth it
<rm-tv> in other words
<rm-tv> i'm not sure how i would explain this to the average accountant
<rm-tv> that was used to type his addresses with the typewriter until yesterday
<kilo> i dont agree. with a good ui it can be handled.
<kilo> a do agree on the need to have another way to enter streenames
<kilo> if the modules dont reach a given complexity, imho it is no use to even develop them
<kilo> i dont see no reason behind defining a module for addresses that only holds lines
<rm-tv> well
<rm-tv> personally i don't target at a complex system
<kilo> nor do i
<rm-tv> i target at a system that's easily usable and understandable in pracitce by non-computer-experts
<rm-tv> let me put it that way
<kilo> i write an invoice system. i dont have to use all the properties of the address class. but i can use the same class to specify the address of an employee, so that i could fill his tax form
<rm-tv> well
<rm-tv> that's again the strategy question
<rm-tv> is the base address class the "maximum" and invoicing leaves parts of it "unused"
<rm-tv> or is it the "minimum" and payroll extends it
<kilo> but anyhow, i wuold be very very happy if other people also told their opinions. it is only some 5 people. not any of the americans has commented. only we here in central europe...
<rm-tv> yes, me too
<rm-tv> (would be happy)
<rm-tv> mabe someone reads the log
<kilo> and i feel we do know very well what the other 4 of hat 5 thinks, and keep on repeating the same again and again...
* kilo is little bit frustrated
<rm-tv> actually i think i haven't discussed with anybody except you
<rm-tv> and i can't remember something else in the logs
<kilo> i hope to talk to dimas in the weekend
<lekma> if i may add my opinion on the address matter
<kilo> re max/min approach: well, i may be wrong, i am not an organizer, i am an engineer. so maybe you are right reinhard, dunno
<lekma> i think as jcater and reinhard that address1...5 is enough for basics
<lekma> ie address1...5 + zip + town +country
<reinhard> lekma: for the statistics - which country are you from?
<kilo> nl he is i think
* reinhard is forgetting things...
<lekma> i'm french but leaving in the netherlands and working sometimes with germans
<reinhard> oh
<reinhard> poor sucher
<reinhard> sucker
<reinhard> ;-)
<lekma> :)
<kilo> you got the best 8-))))
<lekma> but at the moment i work for a dutch/french company
<lekma> addresses are so inconsistent that it's better to avoid specifics
<kilo> well, problem is that one day i agree and the other day i dont
<lekma> and i used to work (in another life) for a marketing department that made huge mass mailing
<reinhard> kilo: then we'll wait for a day you agree and talk again then
<reinhard> ;-)
<kilo> but the next day i will turn everything back 8-))
<lekma> so when we redesigned the address db we sticked with basic 1...5 design
<lekma> and a lot of trouble went away
<lekma> the downside is people putting manually putting data have to stick to a few rules to keep the whole a bit consistent
<reinhard> i think i'll call it a night
<reinhard> bye all
<lekma> bye
*** reinhard has quit IRC
<kilo> lekma: that downside is what i fear...
<lekma> you shouldn't
<lekma> :)
<lekma> if you keep it simple
<kilo> i shouldn't. i do. on a weekly basis i have to correct db entries because the customer wes clever enough to put in 'heater' as the name of all the 30000 heaters, and then he can't find the one he looks for
<lekma> :)
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
<lekma> good night/afternoon/evening(/morning?) everyone
*** lekma has quit IRC
<nickr> wha? oh
*** jamest has quit IRC
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** kilo has quit IRC
*** jamest has joined #gnuenterprise
*** sjc has quit IRC
*** jcater_ has joined #gnuenterprise
*** jcater has quit IRC
*** gsoti_away has left #gnuenterprise
*** MiXi^ has joined #gnuenterprise
*** MiXi has quit IRC
*** PeterD has joined #gnuenterprise
<PeterD> Kilo: I read a log and want to comment on zip codes/postal codes
<PeterD> I Australia Postal Codes are allocated to suburbs/cities probably based on postal distribution.
<PeterD> Sometimes few suburbs got the same postal code. I noticed to that big organisations like
<PeterD> telcos, universities, banks got allocated own postal code.
<PeterD> In Poland Postal Codes in big cities are allocated to the streets, sometimes both sides of street got different codes or group of street numbers on this street got allocated separate codes.
<PeterD> In small country town the same  postal code is allocated to few streets.
<PeterD> Most of villages in country sides got one postal code allocated to them
<PeterD> the postal codes got format of five numbers xx-xxx  where the first two represent big city
<PeterD> or administrative region
*** mdean has quit IRC
*** PeterD has quit IRC
*** holycow has joined #gnuenterprise