During the week, there were several beta versions of the new releases of the GNUe Tools, including:

• A second beta version of GNUe Common 0.6.1.99, including improvements in datasources, definitions, Remote Procedure Calls (RPC) and utilities.
• A second, third and fourth beta version of GNUe Forms 0.5.13.99. including support for the new 2.6 version of the wx GUI interface driver, and user defined keystroke handlers.
• A second beta version of GNUe Application Server 0.4.99, including a new (object oriented) RPC interface and a switch to using Python's built-in datetime library instead of the external mx.DateTime package (thus removing a dependancy for the project).

Anyone interested in testing these pre-releases could download them from http://www.gnuenterprise.org/downloads/prereleases.php

Reinhard Müller (reinhard) referred back to the interbase problem with commits destroying open cursors that are not fetched to the end of the resultset which he was working on a solution to. He suggested that we just fetch the whole resultset for interbase especially since a fetch up to the end of the result set happens quite frequently anyway, I think this should be acceptable. Bajusz Tamás (btami) pointed to a forum posting outlining another possible approach, but Reinhard felt that his suggestion was better, as it could also apply to a similar problem in sqlite3. This was not an issue with some other relational data base management systmes - postgres just lets the cursor survive a commit. He added we can always remove it again later and do the "proper" fix, if we see that we have performance problems with the fetchall - but as I said at latest when you click on the save button, the whole resultset will be fetched into memory anyway. Johannes Vetter (johannesV) applied the fix and reported ok, works fine for sqlite3 now.

Whilst Reinhard's solution might appear to be a bit of a cop-out, it highlights some of the problems that GNUe inevitably runs in to by trying to be database-agnostic and not require a particular RDBMS system. You almost have to work to the lowest common denominator, and re-create any missing RDBMS functionality within GNUe itself.

Bajusz Tamás (btami) reported a bug in the gtk2 uidriver. He had a multi-paged form, with a multi-row grid on page 1 and 3, displaying the same data. Changes made on page 1 were not being reflected when moving to page 3. Johannes Vetter (johannesV) asked what about other ui-drivers ? - Tamás said that these were OK, so Johannes said it must be a user interface driver problem, rather than an underlying problem with GNUe Forms. He would look at this is detail when he could. Tamás said that it was not 'mission critical' for him as our inhouse app (this form) runs on XP boxes with win32 driver - i'm just testing it with all drivers on my linux box.

Further to , James Thompson (jamest) asked reinhard: i was going to work on the sample tonight you mentioned wanting a fishhook and all datatypes - any other things you want to see in there? Reinhard Müller (reinhard) said naturally master/detail - master/detail/detail would be good, as there have been bugs only appearing in 3-level case. James siad he already jad that - and I know I need to add a boolean - did you want date as well as datetime? Reinhard said yes - we also have time values (time without date) - they are especially interesting. James had not ever had use for something like that so I'm not sure where'd i'd graft that in.

James Thompson (jamest) asked how did parameter support in forms change recently? He reported the trigger namespace function references GFForm._parameters - which no longer exists. Reinhard Müller (reinhard) every GFForm should have a _parameters. James said he was using parameters in on-startup. Reinhard said that's probably the only place where they don't work ;-). James said that i'm thinking about moving that to on-activation instead of on-startup anyway as it should still work for a main form - /me recalls the on-activation gave dialog forms a chance to set themselves up - but i still wonder if the on-startup parameter issue should be concidered a bug - as it shouldn't choke. Reinhard was sure it should be considered a bug - but I have no idea how to fix it best - *sigh* we haven't found a way to deal with parameters that works for every case... I don't know if there is any chance to pass the parameters to the form before it is activated. James asked how are parameters handled now? Reinhard they are passed to activateForm so they are available from activation - for the __main__ form, the command line parameters are passed - and for dialogs, the parameters are passed that were given in runDialog (or how that was called) - most notably they should be available in ON-ACTIVATE.

Sacha Schlegel (sacha) said he had just seen Jan Ischebeck's (siesel) gnueneterprise firefox plugin. looks nice. Dmitry Sorokin (dimas) asked where this available from. Sacha said I think siesel had it in his web folder - siesel posted the url in this channel.

Reinhard Müller (reinhard) asked whether the gnue-runtime-environment for the Microsoft Windows packages for GNUe included the wx2.6 drivers. Bajusz Tamás (btami) said no - i'm waiting for a new designer release - the latest released designer is running with wx 2.6, but GNUe Forms was currently not working with wx 2.6, as discussed in , and had to be used with wx 2.4. It wasn't possible to package up both wx 2.4 and 2.6 in the same setup.exe package. Reinhard wondered is designer ready for a release? Tamás suggested asking Jason Cater (jcater).

Tamás uploaded a new version of the Windows setup.exe package, but noted that for the wx26 ui you have to apply the latest commit i made because the wx26 wants to introspect the version from the filesystem. Reinhard did a new beta release of GNUe Forms to incorporate this change - /me looks back to that time when preparing a release took 3-4 hours... - now it took about 20 seconds - plus the time the script needs to run.

Johannes Vetter (johannesV) reported using the newly created exe-files, wx26-uidriver works perfectly (as well as the sqlite3-driver) - i've also check the address-app (from contrib) ... works fine. so i'll create new osx-packages then. James Thompson (jamest) asked so is wx2.6 replacing the win32 dirver then? Johannes said actually my plan was to replace *all* drivers (except curses) with the wx26-driver (at least in the long run) so we have to maintain only two drivers, wx26 and curses. Reinhard wanted to keep a qt user interface driver as well. James said that he used KDE, but was actually using the wx 2.4 driver to run GNUe as it's the only one that doesn't butcher my legacy forms. This meant using gtk1 - and people hate it - but it's all i have as at time of writing that works. Johannes asked is there a wx2.6 available for kde. James did not know of one, but noted that GNUe Forms was still usable under KDE - just not w/ native widget set.

The next day , James noted that in the qt world, pyqt4 is going RC very soon, and qt 4.1 is out - the current qt uidriver for GNUe is (or at least was) qt3 - i'm not sure if it's worth the effort to stick with qt3 when it'll soon be obsolete. Johannes felt it made more sense to create a uidriver for qt4 then ... as this is a task scheduled for this summer.

James Thompson (jamest) said that he was looking thru my hacked up gnue-navigator at the house last night - i'm still interested in a workbench style framework so I can embed my forms and custom apps at work. This was actually more feasible if the number of user interface drivers was reduced, as discussed in . Johannes Vetter (johannesV) suggested what about having navigator as beeing just another gfd :) (GNUe Forms Definition) - to not have a navigator as subproject at all :) James said he was thinking navigator be more like a netbeans or eclipse for python - that the other apps would run inside of - eclipse calls it a rich client platform Johannes said that he wasn't entirely serious about scrapping Navigator, i think navigator is special enought to do it's own impl. but maybe it could reuse uidriver's code. James said that his idea would not use uidrivers at all - it'd have a few abstrations for menus, toolbars, and such that would link to native widget sets - then it'd have a way to offer up workspace windows to apps - those would be native panel type windows inside navigator - where forms could treat that as a standard panel and draw the ui on it with ui drivers. It's a long term thing, not something ready any time soon.

Jason Cater (jcater) said what I'd like to see - having done some of this in designer, so having a wishlist coming from that - a gnue.common.ui structure, with drivers.wx, etc - a gnue.common.apps.GUIApp which is a subclass of GClientApp - and the ability to say your application *must* be a certain widget set. This would mean that I could just ask for panels, etc, and those panels would be native panels that my app uses normally - but it becomes part of the "navigator" desktop (for lack of a better word). James said his idea was similar with the addition of plug ins - so the navigator tree would be a plug in - that would add a nav panel that could launch other embed apps. Jason agreed - at a minimum it lets all the apps share the small little toolkit-specific utilities we've come up with - like loading icons, startup dialogs.