Derek Neighbors (derek) noted that Jason Cater (jcater) had made a KILLER script to allow GNUe tools such as navigator/forms to connect to the database back-end using ssh (secure shell) tunnels - you run it and it asks you questions - and voila it makes a custom script for you to do tunnels. We use it for gnue as we regularly use postgres on a remote server - run gnue client locally tunneling 5432 to a remote server - and so its like you are running on local net :) - we will likely add it directly into the framework

Referring back to . Jan Ischebeck (siesel) asked will the gadfly dbdriver creates new databases if there are no databases defined? Andrew Mitchell (ajmitch) said that the GNUe driver to talk to Gadfly (a database system for small databases, written directly in python) was not working yet. Jan said he had considered using Gadfly for the sample databases in GNUe, as discusssed in , as both Gadfly and GNUe were written in python. However, gadfly don't support date/time types :(.

Later, Jan said he had changed the gadfly dbdriver a bit. Andrew said that, previously, i could play with designer & build a form - but it didn;t like me running the form. Jan asked if Andrew had used the version of gadfly in debian/testing. Andrew said he had used a newer gadfly - since the one in debian/testing is orphaned - it is sad & lonely & the code has been picked up by someone else Jan confirmed this - seems that cvs hasn't changed a lot since the 1.0 release, the only files I found changes are documentation.

It was asked if the GNUe tools were production-ready as of time of writing. Andrew Mitchell (ajmitch) said forms & designer are - reports might be. He appreciated the importance of 'production-ready' - it's fine being able to use it in your own, since you can fix bugs if they appear - but for production use you need to trust it :) Jan Ischebeck (siesel) said that Application Server was usable already, but there still features missing ( internal table/object directory, transaction support in appserver itself) and it has to be made much more stable :). However, as Andrew noted, not even phpgw is 1.0 ;).

Further to , Marcos Dione (StyXman) asked re: enabling and disabling widgets from triggers, don't you think that some 'bridge' is necessary from the GFthing to the UIthing and even to the widget? Jason Cater (jcater) said the bridge was events - we are event-driven. Marcos asked so, the widget (or the UIthing) should 'listen' for a 'disable' event? ...and should 'demultiplex' the event to the right widget? Jason said yes, but we usually use a proxy event - the UIdriver would probably listen for the event. Marcos asked ain't events a little overkill for enabling/disabling widgets? or is it the way to make GF things talk to UI things? Jason said the latter - and I don't think it's overkill - as you just communicate with the GF* widgets to enable/disable them - but at the same time, if the underlying UI wants to grey them out, it could also listen for the event - it's what events are made for! :) He explained the trigger will be at the GFEntry level - i.e., it would be GFEntry.enable() and if anything wanted to listen in it could (such as the graying out). Marcos asked how the UI things should be able to talk to its widget. afaik, the only way to reach a widget is to traverse the tree starting from the _form of a UIForm object? Jason did not see why this was necessary - the UIdriver will listen for an event itself then contact the widgets.

Phil Cole (filc) asked Is there a proposed method yet for "zooms". i.e. when adding a purchase order being able to "zoom" from the supplier field on the purchase order to a form containing a list of suppliers? /me is not sure how "zooms" going to interact with nstti, as discussed in . Jason Cater (jcater) said I wouldn't worry about it at this point. Phil thought it's quite a major issue for a usable forms. Jason agreed, but I don't think it has anything to do with nstti, though.

Alesandro Bottoni said he was strongly impressed by the rational and ambitious design of the GNUe tool suite and by the high quality of this 0.3.0 release - they impersonate the new "GUI Building Technology", based on XML, that most of us were waiting since a long time.

He asked Which is the real name of the GNUe Forms client? The documents cite "gfclient" but on my hard disk there is only an executable named "gnue-forms". Jason Cater explained that the executable names had been changed at version 0.3.0 for consistancy - Any references to gfclient should in fact be gnue-forms.

Alesandro also asked What is the "psycopg" (or something like that) database driver that is called from within a few of your samples? Jason replied that "psycopg" is currently our preferred library to talk with PostgreSQL. Pypgsql and Pygresql are two other libraries..

Finally, Alesandro asked I read that a HTML renderer (or "client") is under work. Which is its development status at the moment? Jason said The HTML client is really early in development. It is not usable at the moment.

Alesandro Bottoni repored problems trying to run the "inventory " sample on my RH7.3 (with wxWindows 2.3, wxPython 2.3.2, PostgreSQL 7.X and so on...). He was getting an error message of Error: Unable to log in after 4 attempts. Jason Cater said this could be several things. I'm not sure how well supported the Pygresql driver is. I'd recommend you grab psycopg. He suggested checking the postgresql.conf file to make sure that your postgresql was set up to listen on TCP/IP. Logging into postgresql as psql -h localhost inventory would force pgsql to use TCP/IP to communicate (just like GNUe does) instead of a sockets file. Also take note of the pg_hba.conf file. It defines permissions based on the communication method. Generally, the default setup is to be more permissive with local sockets-based communications and more strict with inbound network connections (even if "inbound" is from localhost.)

Stan Klein confirmed that The shell output does not demonstrate that Postgres is listening. I'm having a similar problem. For security reasons, the Red Hat default for Postgres is to *not* listen. The shell output you cite above looks like something I also got, which is based on a different (single user, non-Internet-port) interface to Postgres. He had been reading the Postgres docs and the config files trying to figure out (a) how to get Postgres to listen, and (b) how to configure my Bastille-Linux firewall to prevent an outsider from accessing the port. He later reported I got PGAccess to work. - the postgresql.conf file needed editing to change the parameter tcpip_socket to true. Then do /sbin/service postgresql restart.

Peter Sullivan announced We are in the process of preparing new releases of the main GNUe tools, which should be out in the next few days. As usual, in the rush to a new release, the GNUe Developers will be posting daily (or so) pre-release versions or release candidates for people to download and try to break. Anyone is welcome to try the pre-releases - any problems should normally be reported via the IRC channel. However, if you want something a bit more stable, you might prefer to hold off until these become the official current releases. Christopher Brown felt it was rather disappointing that none of the releases are .deb-packaged - ensuring compatibility with the quickly-evolving versions of Python is a challenge at least from a packaging perspective. Jason Cater agreed 100% about the need for .debs. All of the core developers use Debian systems, so this really hits home with us too. We do, however, have someone working on debs; hopefully they will be ready in time for our final release. He emphasised that these are prereleases and not releases, explaining We will probably do a prerelease a day for the next several days. (We may be using the term "prerelease" differently than other projects -- I'm not sure.)

Further to , Derek Neighbors (derek) said let me know what it will take for me to help with release before mid week next week - as im doing big demo at community college next weekend - and really would like to be demoing 0.4.0 and have it ready for release :) Jason Cater (jcater) was really working on it - even installing mysql (sigh!) to look at the issues w/that driver. He wanted to do first round of prereleases tomorrow - then hopefully one a day until release. He was ready to get this release out the door - as I need to do some major breakage to designer - designer has grown all it can grow without moving to an event model like forms uses - the current spaghetti mess is starting to get confusing. Andrew Mitchell (ajmitch) asked what will be released?. Jason said common, forms, reports, designer, navigator(?), appserver. Reports and Application Server would be at 0.0.2 - common, forms, designer will be at 0.4.0.

Andrew noted that GNUe could have issues with not having a current wxpython debian package for sid, as discussed in - default python is 2.2 in sid now. Jason sighed I distinctly remember reading on the debian lists a few weeks ago that they would *not* switch to 2.2 - they were waiting for 2.3. He was very afraid of python 2.2 - imho, python 2.2 changed enough stuff - that it should've been 3.0 - some stuff that worked under 2.[01] won't work under 2.2.

Later, Jason announced that round one of the pre-releases had been put on the website. Daniel Baumann suggested (chillywilly) someone should put the prerelease urls in the topic. Jason asked on the snapshots.php page - why do you have a debian section? Peter Sullivan (psu) explained all the downloads use the same file listing php code - I added .deb as a seperate section 'cause we have DCL debs now in /current - /me must work out how to supress empty sections as you won;t be the last to ask that Jason was just *really* hoping you weren't expecting me to do nightly .debs. Daniel suggested that's what ajmitch is for ;). Peter said he would announce the pre-releases on the mailing list and on the web site. Jason suggested reinforcing that these aren't releases yet - so don't be shocked by issues :).

Some days later, Jason Cater (jcater) was working on the NEWS files and release announcements, and getting concerned about whether the tools could be justified as a 0.4.0 release - maybe I should be releasing Forms 0.3.1, Designer 0.3.1, Common 0.3.1, AppServer 0.0.2, Reports 0.0.2, and Navigator 0.0.1. Andrew Mitchell (ajmitch) asked philosophically what qualifies as a new major version? Jason said new features :) - the only thing new in forms is the GTK driver - this is basically a housecleaning release once I look at it. Now, designer did undergo vast changes - it's probably worthy of a 0.4.0 - but I hate to jump it ahead of the rest of them. He looked at common's changelog - if there's more in common than I realize, it might push forms to 0.4.0 Andrew felt that only the schema support is 'major'. Jason was torn as I think designer is worthy of a 0.4.0 - but I don't want to rush it ahead of the others. Poor form's changelog is depressing. Daniel Baumann (chillywilly) suggested go with the gut ;) but Jason said that did not help, as the gut says donuts - but that's irrelevant.

Jason asked what is _featuretest? - is that appserver's playground / sandbox ? Daniel said yes - just some crack that jan and I put in there. Jason proposed a news file/change log for Application Server, and asked Daniel and Jan Ischebeck (siesel) to review it. Daniel said it looked like a fair assessment - there's probably more there... but it's getting late and my recall functions are slowly deteriorating ;P.

The next day, Reinhad suggested i don't think appserver/_featuretest should go in release. Daniel Baumann (chillywilly) agreed - it's not releasable. Reinhard explained that _featuretest was a subdirectory of appserver that contains alpha type of code.

Andrew Mitchell (ajmitch) said he would attempt to roll some quick & messy debian packages to go with the new releases, as previously discussed in and other threads. Jason Cater (jcater) was enthusiastic, but asked can we *please* get it into cvs this time, though. Andrew said he would want Nick Rusnov (nickr) to check them before he tried to get someone to put them into sid - jbailey or nickr can do that. He asked package names like gnue-forms, gnue-appserver ok? gnue-appserver should conflict & replace the Debian package for the old, depreciated version of GNUe Application Server (GEAS). The gnue-common will be one package that suggests/recommands db driver dependencies. Derek Neighbors (dneighbo) said up front im cool with basic to get going - evenutally i would like to see gnue-common, gnue-common-mysql, gnue-common-psycopg, etc ;) - so it knows to get those dependencies as well - and would setup sample connections.conf file and the likes - muahhahaha - but baby steps for the moment.

Later, Andrew reported ok, got a gnue-common package, now to make it work within the Debian packaging guidelines - since apparantly modules are meant to be in /usr/lib/pythonX.Y/site-packages. Jason Cater (jcater) said we are an application, not a module though - c.f., Zope. Andrew put a test .deb package for GNUe Common on the web for people to test ok, "deb http://ajmitch.dhis.org/debs ./", apt-get update, apt-get install gnue-common but warned probably won't work wonderfully on woody yet. He still had to do things like move docs around and other crap - also might have to move things to fit debian policy as opposed to your opinions :). But Jason said that Andrew's work was a big start - it's much better than what we've had (namely, nothing).

The next day, Andrew reported that he had got a rather awful gnue-common package done but it is not fit for uploading, mainly due to problems with distutils. Further to , Jeff Bailey (jbailey) pointed to some documentation on how automake and python work together, for any who might want to be convinced to Come Back To The Light Side Of The Force.. Andrew asked how will it go for windows packagine? Jeff said that he believed that the GNUe core developers were willing yo require cygwin for developpers although not for end users. End users on Microsoft Windows would probably be using some pre-compiled set-up. Andrew noted they've been using mcmillan & inno.

Jason Cater (jcater) said my problem with automake is that it's *nix-specific - which we are not. fwiw, I truly hate distutils as well - but it's cross-platform. jamest and I wanted to go w/custom installation program which was part of the rationale for developing our setup-cvs.py script for setting up the CVS version of GNUe, but /me doesn't really like any of our options :(. Jeff felt that the best option is to use an install shield like program for Windows users. Jason said we currently use a system like that but the users have to install the old fashioned way if they use anything other than postgres / mysql due to licensing problems in adding proprietary drivers to the bundle. Even then - if we made it work that way - we are maintaining several installer programs :'(. Jeff felt You are in any instance: Debian, REdHat, Windows. In none of those cases should the user need to do anything other than install the compiled python files through some non-shell method. The trick is what builds those methods. distutils/automake or whatever should be the tool that gets invoked in the creation of the installer, either through generating spec files, debian subdirs, or whatever type of script is required for the windows installer. Jason said that sounds great coming from a linux-centric background - it just seems soo out of place to be using automake for stuff that isn't being compiled, given that python was an interpreted language.

Derek Neighbors (derek) clarified that he did not mind if DEBIAN/RPM packaging requires make - i didnt say making make a mandatory item for developers was ok - just rather developers of deb/rpm etc packaging. Jeff noted that there were some technical difficulties getting distutils to work with the directory structure that GNUe used.

Arturas Kriukovas (Arturas) said it looks that i18n is coming to the end; if you had some time, maybe you could take a look at it and try to check what does not work, i'd be very thankful :) Derek Neighbors (dneighbo) noted that for font types you made a big assigment block in the code - the python way of doing this is 'dictionary' type structures - he was not saying it doesnt work, just there is better way to do it. Jason Cater (jcater) said the main difference was parse time. His preferred coding format for dictionaries was:

Derek suggested putting the dictionary values in brackets incase someone wishes to EXTEND it, but Jason said you will only confuse newbie programmers who might think the values were meant to be tuples.

Further to , Jason Cater (jcater) tried to build some Microsoft Windows self-installing .exes of the new pre-releases, but this latest version of wxPython replaced some of my system libraries. He included the following drivers in the windows binary package: mysql, psycopg (postgres), kinterbasdb (Interbase/Firebird), odbc, wxPython, mxDateTime, PyXML all in Win32 versions. He is going to try to get SAP-DB drivers in there. Peter said I assume we're not doing Reports exes, so no need for sablotron/pysablot? Jason agreed - /me isn't comfortable enough with .exes for reports probably until 0.1.0. He noted that this switch from python 2.1 to 2.2 is killing me - although nothing was really breaking as such, all these installers have hardcoded paths - so I have to modify the config files for both inno and mcmillan and other fun stuff!. Later, he noted /me doesn't think McMillan 4 works with Python 2.2 - but GNUe had had to upgrade to python 2.2 for the Win32 versions as the Win32 psycopg drivers for connecting to PostgreSQL required it.

The next day, it was asked what version of python GNUe required for changes to the source code (for instance, the SAP-DB drivers). Peter Sullivan (psu) said 2.0 and above, I believe for most stuff - ISTR Windows 32 users had some problems w/anything less than 2.2 - but freedom-luvving GNU/Linux ppl should be ok with 2.0 or 2.1. Derek Neighbors (derek) confirmed we to date have been compatiable to 2.x and above - we are finding 2.2 is has some significant changes - though i dont think we are at the point yet where we are going to say 2.2 and up - the windows release will be based on 2.2 (re: psu's comment) - as that is what version pyscopg (the only respectable windows driver we could find) required. But there was no need for GNUe source code to be 1.5.2 compatiable :).

Some days later, Jason reported that the mcmillan website noted that Release 4 has some incompatibities with Python 2.2. Migrating to Python 2.2 is the perfect time to also move to Release 5. He had been trying to avoid moving to release 5 of McMillan for the moment, as discussed in . He reported well, I managed to get McMillan 5 working w/GNUe Designer - except she segfaults - woohoo! - even the wxPython demo programs segfault.

Nick Rusnov (nickr) confirmed McMillan is the one with the specfile and the compiling, yes? does it also have an installer thingy? Jason said not - it creates .exes from python. We use Inno to do the installer - it's a pretty slick FREE graphical installer.

It was asked whether GNUe could be used to provide CRM, Accounting and Inventory, all tied into the cash register. Andrew Mitchell (ajmitch), referring to , noted that Jason Cater (jcater) has been looking at point of sales stuff lately - dcl has some CRM stuff - for accounting, we currently have acclite/nola to work off.

Andrew said GNUe could use whatever you feel like ;) for the back-end database - ideally modules should come with an xml schema which describes the database structure, and can be used on several different databases. He confirmed that he had run forms & designer on Microsoft Windows - this was just a matter of installing the windows packages ;). He was also trying to find out how best to package them for debian. It was noted that it was unusual for Debian support to be behind Windows for a free software project.

It was also noted that GNUe made extensive use of XML, and Jason Cater (jcater) pointed to http://www.w3schools.com/ for information about it - I didn't learn XML there - but did learn XSL, DTD, XPATH, etc.

Marcos Dione asked why the ability to (open) run forms from triggers is 'disabled' (ok, commented out) in GTrigger.thisTrigger... Jason Cater said This has been fixed in CVS head.

Futher to , Reinhard Müller (reinhard) told Christian Selig (lupo) that we talked about meeting at the linux world expo in frankfurt. Christian felt that is a possibility. Derek Neighbors (dneighbo) suggested can we make thsi more public - i.e. open to ANY users/developers of gnue. Reinhard agreed, although he would prefer a "constructive" talk w/ 4-5 people at least as a part of the "program". Derek did not think this would be a problem - generally i think if you offerred no one would show except those genuinely looking to help code, although i heard uncle reinhard say he was buying dinner for anyone that showed :). Reinhard was not sure if we want to attract _so_ many people ;). More seriously, Christian felt it is important to gather and to know each other and discuss this or that issue - otherwise, jason will have to do all of the work *g*

Two days later, Reinhard said that he had spoken to Christian and we would prefer oct 31 for the meeting - he will try to organize a room where we can meet. He did not think we should exclude anybody from the meeting - but we have to take care that it remains prductive. Jan hoped that the room, lupo will organize, has network access :) Reinhard said that i hope it won't be a "hacking session" - but more a "talking about concepts and design session" - i would even say a flipchart could be more important than network access :).

Later, Derek Neighbors (dneighbo) suggested it would be great if you had internet access so that perhaps you could relay some of what was going on back to irc - that or design decisions need to come back in form of email or document

Later, Christian confirmed that i have spoken to volker dormeyer, the FSFE booth master who had promised to look for a room for a gnue devel meeting - reinhard spoke to me and proposed a meeting where we can talk about concepts, so no hacking session - though it could be advantageous to have a laptop available. He confirmed meeting time is october 31st from 10.00 AM till the evening.

Further to , Jan Ischebeck (siesel) asked do you have any i18 test form lying around? I want to add a gnue i18 test form to the new sample directory. Arturas Kriukovas (Arturas) said i have a form. Jan asked Arturas to add it to gnue/samples/testcases/ - possibly as an i18/fonttest.gfd or i18/unicodetest.gfd - If you have any comments about that form, it would be great to have a short README :). Arturas said i'll do my best (350 pages will be enough? :). Jan felt possibly a bit less descriptive. If you take the UNICODE 3.2 documentation as an example, it would be ok ;).

Later, Jan asked how should sample files be handeld for the coming release? I would recommend to remove all sample files from reports/samples forms/samples BEFORE the release, and already do a separated package of samples for this release, even if its not 100% working. It would be much easier then to just release a second samples package, than have to live with broken samples a long time. If we leave it the old way for this release, I would like to know, so I can update the examples in the old tree. Jason Cater (jcater) said the only issue with separating is I have to redo all my packaging scripts but this would not be a major job. Jan also asked about Forms which are used for "configuration and mangaging things" like connection.gfd for the connection.conf file, as referred to in , and manage_user.gfd for appserver user management. I would like to put these into a utils or so directory in the according package. i.e. connection.gfd into common/utils (already existant) and manage_user.gfd in appserver/utils. Jason agreed.

Jan Ischebeck (siesel) asked do you remeber what meaning a self._triggerGlobal=1 setting has? James Thompson (jamest) said it becomes part of all trigger namespaces - that way you can call that function from any object not just the one that defined it. Jan asked But what is the difference to the global attribut in self._triggerFunctions? - In my understanding the global attribut in self._triggerFunctions adds that function to the global namespace, i.e. you don't have to call myform.setFocus, but you can directly call setFocus. He would investigate further.

Further to , Marcos Dione (StyXman) asked how to use form parameters, specially for 'conditioning' datasources. If necessary, he could port code for this from Reports. Jan Ischebeck (siesel) said it seems, that you can access a parameter in a condition tag in forms too, pasting some sample text. Marcos noted that the Forms parameter code was different from the Reports parameters code, which had both a GRStubParam and a GRConditionParam. Jason Cater (jcater) said that reports has two types of "output" parameters - one in the <condition> trees (which is GRConditionParam) and one in the layout/output code. Both share most of their code via GRStubParam. He did not see any need for something similar for Forms, which should only need one type of parameters.

The next day, Marcos said that the example Jan gave works, but not when using a <cparam> in <contidions>.... Jan asked you don't have provided a "default" attribute to the parameter?. Marcos replied nope, but I'm passing a value thru the command line... Without the cparamm tag, it worked, despite the fact that both cparam and getParameter call GFForm.getParameter. Jan said it seems that the parameter is used before the form is finally setup. i.e. its loaded by the condition before GFInstance.setForm() is called. Marcos also reported that when I run another form with runForm, I have problems passing parameters.

Further to , John Lenton (Chipaca) asked would adding a delegates system to dbsig be cool with y'all?. Federico Heinz (perlhead) explained It's a way to create classes whose instances solve a general problem but provides slots for client code to customize the functionality. The idea would be that the dbisg class, which defines messages for inserting, updating, and generally mangling records in the database would no longer do this directly, but would keep a list of delegates. A delegate is simply any object that responds to the class' (in this case dbsig's) delegation protocol. Jason Cater (jcater) said I like this in theory - In practice, this is going to be interesting to write and maintain. in effect, you would need more than an alternate "insert", "update", "delete" hook - you would need more a subclassed resultset. John explained the delegation protocol is something like: "I'm going to <foo>" - "No idea"/"Go on"/"Don't"/"I just did it" - you do this to all your delegates until one of them answers something other than "No idea". Federico said that no code would be removed from dbisg, as the existing "insert" or "update" code would be needed for where a delegate told the class to perform the operation itself rather than delegate it. The benefit was more ability to add functionality to dbsig without breaking stuff nor touching dbsig. For instance, transaction tables (recording all the previous states of a row of data in the database) would be implemented through a class that does nothing but listen to willUpdates - It would then find out whether the table is "transactional" or not. If it's not, it'd answer "ask somebody else" - So dbsig would continue to walk the list. If it is transactional, it would do the update/insert thing and answer "I did it for you".

Jason said I think I like this at first glance but there are a few areas I want to be sensitive to: 1. This is a critical part of gnue-common, where speed is important (think backbone of appserver and reports) so any code doesn't need to add a lot of bloat - 2. Odds are, the "delegates" will need to understand the dbdriver internals - so maintenance on delegates wouldn't be fun (but that would be the problem of the delegate writers, not me). He felt as long as we could do this without adding very much overhead - I think it might work - this will be a complex addition to gnue-common, though. John felt the overhead for people not using delegates would not be great - it would probably be one lookup of one array variable.

Jason added now, I know this isn't my problem - but assuming we do the delegates system, I still question how that'll solve your problems in adding transactional support - if a person updates a record you are wanting to just mark the existing record with an "old" date (or such) and start with a freshly inserted "current" row - the problem then is you have to manipulate the resultset's internal cache - otherwise if the user turns around and modifies the record again, they are doing so against an outdated version. Phil Cole (filc) wondered why the current row can't always be the up-to-date record and take, just insert a copy of the current row and call it the history record. John said we could do it either way, I guess - the way we had thought was such that you could get an _exact_ image of the system in a past time - the way you propose would be _almost_ exact, and the overhead is greater (on the database) - we'd have to update all the stuff that pointed to the old record to point to the new-but-historic record. Jason agreed, but I'm not sure you fully understand the needed coding in your delegate - you will be touching A LOT of internals unless you did it filc's way - /me personally doesn't care, as I won't be coding it :).

John said look at it this way: if we don't do it with delegates we'd have to do it _in_ dbsig. Jason said but my big fear is you get into this and realize that doing it your way isn't going to get the results you want without recoding dbsig again too - just something to think about. John said I suspect dbsig _will_ be slightly modified throughout - but I don't think the headhaches will come from there, rather from fighting the cache, as you said - I don't know, but isn't there a way to tell the cache it's outdated? Jason said I don't think there's a reliable way to do that.

Phil asked Could the history records be written to a seperate table by the delegate? Then you don't have to worry about the cache. John agreed, but felt that this would mean that GNUe would be dictating the form of the database. Jason said that the alternative - rewriting GNUe Forms to meet your peculiar needs might be worse - but not so much in this particular case, as transactional/history support is commonly needed. John said but there are about 3 decisions to make for transactional/history support, with a very large amount of options per decision, and I think gnue should support them all - and either you bloat up dbsig by supporting them _all_, or you add some mechanism of extending what you do support while at the same time providing extensions to cover the typical cases. The delegate both for doing history as part of the main table, and Phil's suggestion of doing history in a seperate table might should probably eventually become part of gnue anyway. Jason said all I was pointing out is that you might want to reconsider how you do your history. John said our database is such that doing historics in any other way is a PITA because of references - it was the norm rather than the exception to have to refer back to historic entries, hence the need to keep them in the same table as the live entries - otherwise, we'd have to do "on update cascade" and that has other security and integrity issues.

Jason Cater (jcater) asked Jan Ischebeck (siesel) I notice you committing against the sqlite driver - are you actually using that driver? Jan said I don't want to use it for anything important. But I hate it that all examples which needs database access don't work at once. so I think of providing a database file, which is already populated, with the examples. So you just have to start the examples up and everything is working. I tried to use gadfly, but gadfly don't support "LIKE" conditions, so ... :(. He asked whether the description of the "configfile" dbadapter should go in README.databases. Jason felt that a technote might make more sense - as the README.databases is there to detail to the end user what choices he has for his databases but he was not sure. Jan said he will add a technote first, and move it to README.databases/obscure, when there are more obscure drivers like that :) - like the imap driver you planned to write ;)

Dmitry Sorokin (ra3vat) said i have gnue.po gnue.mo for translations/ru, can they get into release? it should not brake anything to fear about. Jason Cater (jcater) said sure. Dmitry said he would ask Arturas tomorrow to check and commit.

Marcos Dione (StyXman) reported problmes closing with the 'x' of the X-windows manager, when I close all the windows something is still there so the app does not finish - closing with the 'exit' button from the toolbar closes another window but the one I wanted to close - and also closing the last one gives me a segmentation fault. Jason Cater (jcater) said the seg fault was a known problem with wxpython, but that the issue with closing the wrong window needs work. Marcos said that thinking about it I suppose that wx has problems with multiple windows with multiple toolbars, all with the same 'actions' Maybe that was the problem - as the same 'action' is defined for both windows....

The next day, Marcos said I _think_ I fixed the problems with multiple windows. Well, I jusr saw that all the windows registered to the same wx's events. So, I added a constant per window. I used ... ... the instance's serial number, multiplied by 1000 and added to wx's 'action' nunbers - where action numbers are those in ... ... EVT_MENU in UIDriver. Peter Sullivan (psu) noted that this will break if an individual client has more than 1000 windows open at once ;-) - unlikely to be a problem in practice. Marcos said he was not sure how to test his solution - the only thing I know is that closing all windows doesn't quit the app if opened windows >1. Jan Ischebeck (siesel) noted that if the wx action number is an int2 this would mean a maximum of 65536/1000 ~= 66 possible forms instances - if we totaly move away from fixed numbers and just dynamicly increase that wx action number, we could possibly get much more instances in that actiion number address space. wx windows can handle it without giving fixed number.