A problem was reported with using the wx user interface in GNUe Forms - when using unicode characters, such as Greek, they would display fine when entered, but would not save. Johannes Vetter (johannesV) asked ah, so after jumping to the next field the text disapears ? - i've already sent a bug report to the wx mailing list yesterday evening. He explained all unicode-characters generate a wx.EVT_TEXT event (containing a proper unicode-string) - gnue-forms has to process the wx.EVT_CHAR event (to make use of it's display-handlers) - and that wx.EVT_CHAR event returns a *wrong* unicode-character. He noted that 2.6.2.1 is broken anyway (dropdowns), as discussed in , and suggested have you tried using 2.6.1 in the meantime.

Johannes Vetter (johannesV) had experimented with wx.EVT_MOUSWHEEL ... it could be quite easy to fire previous-/nextRecord events as a result of a wheel-event. But the problem was how to determine the block which needs to be scrolled - we could bind such an event to each GFEntry, so one could use the wheel to scroll the corresponding block of each control (without havin a scrollbar). Reinhard Müller (reinhard) thought we should have that in 0.6 when we have layout management - and we can define which vbox/hbox would be bound to a block regarding mouse wheel events.

Reinhard Müller (reinhard) said he would have preferred it if the TinyERP project had approached us for cooperation, but they didn't - and now we both are in a project state where it's not easy to cooperate much any more. Derek Neighbors (derek) believe i contacted tiny erp - for 3 years every year i would compile all similar projects and email them for collaboration - that is how DCL got bundled under us - ARIAS got bundled (or was going to at one time) under us. He explained that Arias was the original NOLA software - i think jcater and myself helped port to postgres - and did some work fixing up directory structures from original NOLA - even started making some GNUe screens for it at one point - it kind of died on the vine.

Johannes Vetter (johannesV) reported that the checkbox-widget could be set up to have three states, true, false and 'not-set' - the 'not set' value would be displayed on xp i think the box is gray - haven't checked though on all platforms here right now. He noted that he was not sure if gnue-forms supports tri-state-checkboxes at all as of time of writing but i'm sure we will with the 0.6 series - since we do have that third state (=NULL). He noted that several of the databases that GNUe supported allowed NULL values for a boolean data type.

James Thompson (jamest) said ok, so about a year ago I talked about expanding navigator - now I'd like to actually start working on it. My initial goal was a framework the other gui apps could build from - and netbeans does this quite well. He explained i use gclientapp a lot - but most of the time I don't need all it has to offer - it tended to get used by default. For an improved GNUe Navigator, he had done some rough notes about required features:

• Non-GUI
• configuration
• debugging
• profiling
• file storage
• authentication
• GUI
• menus
• toolbars
• status bars
• windows

This would be rather more ambitious in scope than the current Navigator, which was just a way of launching Forms or Reports. He was currently calling it 'GNUe Application Platform,' (GAP) but this was not important. It would have a foundation (the primary application), a service registry (to manage components - this would always be loaded), and then utilities for things like logging support, configuration processing, debug support, profiler, command line processor and datasources.

Reinhard Müller though this sounds interesting and useful as a development platform. James gave some examples of how it could be used. He added i could also see the base UI framwork being part of GNUe Application Platform so then navigator, forms, designer, appserver would all derive from gap and only load the components they need.

Jason Cater (jcater) was concerned that this would require a complete rewrite of everything, as much as a reorganization? Reinhard was also wary - I always thought we have one or two abstraction levels too much, not too little ;-) - so I'm wondering where the benefits are. James explained that it would allow more changes to be loaded as a config file at runtime, rather than change the underlying application. Jason realised that addComponent('gap.utility.datasources') may or may not coincide with a gap.utility.datasources? - it could be any class registering itself as providing that "service". James confirmed this - the other components of forms wouldn't be looking for say gDebug specifically - they'd say "give me whatever provides gap.application.debug" - and use that if it's loaded This would mean you'd no longer have hard coded dependency between the various sections of gnue. This was pretty similar to what the Zope 3 interfaces were doing - he gave some examples.

James noted so where we'd end up is - a system made of components with a well defined API via an interface - loaded components would register with some type of manager - components could ask for the component that provided the "Foo Service" then use that service without hard coded links between components. Reinhard was still trying to understand how we would use this in gnue-forms - I can't imagine a situation where I would want to, say, replace the GDebug system with something different for instance. But I could really imagine something like this useful for adding new GF* elements to forms - like we have no tree view, so I can write my own and plug it in - but I think that could be done with python's abilities to dynamically load modules.

James explained eventually forms, designer, appserver, navigator all use this system - so instead of saying "what can I do in forms" - we pull back and say, what can I do in the app. Here I have lots of GClientApp stuff - lots - but each business application written using the GNUe Tools would only need to load the options it needed, not the whole of each tool. If an application needed some functionality that wasn't in any of the existing tools, the GNUe Application Platform would provide a standard way of plugging it in. He gave some possible examples of this.

Jason could see how all of this could be done without the component system jamest is describing, going on like we're doing now - but I do see true value in this direction. Reinhard won't stop you anyway - but I'm slightly worried about the overhead this adds to gnue in terms of complexity and number of abstraction levels - which probably means higher learning curve for people wanting to hack gnue. James felt the opposite, as did Jason - by having a single, unifying, interface to the rest of GNUe, GAP could actually make things simpler.

Reinhard Müller (reinhard) announced new releases of several of the GNUe tools:

GNUe Common Library 0.6.2 featured the following fixes and changes for datasources:

• Fixed requery in multy level master/detail relationships
• Fixed requery for deletion of more than one detail record
• Updated appserver driver for Appserver's new RPC interface
• Don't mark a record set as dirty if a field is set to old value
• Support for defining ownership of created databases
• Fix for databases for which cursor's don't survive commits

Meanwhile, on Remote Procedure Calls, code had been added to Clean up all objects on lost connection by calling _destroy() on them and in Utilties, he had Fixed uuid generation for 64bit architectures and Mac OS. There was also a New splash screen image as well as code cleanup, documentation updates and several smaller bug fixes.

GNUe Forms 0.5.14 now supported the new wx26 user interface drive and allowed user defined keystroke handlers. He had also fixed parameter handling and done several other minor bug fixes.

GNUe Application Server 0.5.0 had a New (object oriented) RPC interface and now used Python's in-built datetime library instead of the external mx.DateTime module. It also now had Support to run as a service under windows.