GNUe Traffic #109 For 27 Mar 

Editor: Peter Sullivan

By Peter Sullivan

"my other famous comment is ... framework X is all the rage right now, but in 2 years gnue will be here and foox.com will be a non resolving url :)"

Table Of Contents

• Printer-Friendly Format
• Text Format
• XML Source
• Introduction
• Threads Covered

  1.	21 Mar		Unicode characters in wx user interface to GNUe
  2.	21 Mar		Mouse Wheel event in GNUe
  3.	21 Mar		Other free and open source software ERP projects
  4.	22 Mar		Null value for checkboxes
  5.	27 Mar		GNUe Application Platform to replace Navigator?
  6.	26 Mar  - 27 Mar	(3 posts)	New releases of GNUe tools

Introduction

1. Unicode characters in wx user interface to GNUe

21 Mar  Archive Link: "[IRC] 21 Mar 2006"

Summary By Peter Sullivan

Topics: Forms

People: Johannes Vetter

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 Issue #108, Section #7  (16 Mar : wx 2.6 and Microsoft Windows version of Forms) , and suggested "have you tried using 2.6.1" in the meantime.

2. Mouse Wheel event in GNUe

21 Mar  Archive Link: "[IRC] 21 Mar 2006"

Summary By Peter Sullivan

Topics: Forms, Common

People: Johannes Vetter, Reinhard Müller

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" .

3. Other free and open source software ERP projects

21 Mar  Archive Link: "[IRC] 21 Mar 2006"

Summary By Peter Sullivan

Topics: Financials (Accounting)

People: Reinhard Müller, Derek Neighbors

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" .

4. Null value for checkboxes

22 Mar  Archive Link: "[IRC] 22 Mar 2006"

Summary By Peter Sullivan

Topics: Forms

People: Johannes Vetter

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.

5. GNUe Application Platform to replace Navigator?

27 Mar  Archive Link: "[IRC] 27 Mar 2006"

Summary By Peter Sullivan

Topics: Navigator

People: James Thompson, Reinhard Müller, Jason Cater

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.

6. New releases of GNUe tools

26 Mar  - 27 Mar  (3 posts) Archive Link: "[Gnue-announce] GNUe Common Library 0.6.2 released"

Summary By Peter Sullivan

Topics: Common, Forms, Application Server

People: Reinhard Müller

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" .

Sharon And Joy