Johannes Vetter (johannesV) announced ok, that's another bug removed from the new wx26 driver which allowed GNUe Application Server to work with version 2.6 of the wx user interface libraries, adding if anybody finds another one, please let me know. Bajusz Tamás (btami) pointed out that if you click on a tab in a multi-page form, it loses the focus - and selection with up/down keys from a dropdown doesn't work yet - just with Shift+up/down - but it's not intuitive, imho. Johannes said that, to check this, he'd created a sample application just using the base wx driver, and i could use the up/down keys without shift-key to navigate within the popup. Reinhard Müller (reinhard) wondered if it's the form catching the keypress before the UI gets it but this was not the case - Johannes just added a debug-print to the __keypress signal handler and found that it does not get anything. In any case, this works fine for gtk and osx.

Jason Cater (jcater) said that these sorts of issues were the main reason we split away from using wx into all the more-targeted UI libraries for GNUe Forms. Using the wx libraries to abstract the GNUe Forms code away from specific user interfaces had been a quick way of being able to support many different user interfaces and operating systems all at once (as described in ), but having a "native" driver for each user interface library was the better long-term option in terms of being able to fully support different UI drivers. James Thompson (jamest) cheerfully added welcome to our (wx) hell - we hope you like it here.

Johannes reported back that i've found out why up/down does not work for dropdowns on wx.MSW - it is the menu-item for "next record" and "previous record" which are bound to up and down keys - on wx.MSW the menu seems to have a higher priority than the current control - so the keypress is eaten by the menu !! He developed a work-around for this by changing the "key_PrevRecord" and "key_NextRecord" in gnue.conf (as an intermediate solution). But he would send an e-mail to the wx developers to see if this could be fixed properly within wx, however.

Reinhard was reminded that I have never liked the cursor keys being bound to record navigation - I feel it's plain wrong to have the cursor keys bound to a menu item as a hotkey. Johannes noted that it's very problematic in this case. Reinhard noted that there are quite a lot of controls that use cursor keys natively - multi line edits, dropdowns, radio buttons (that we don't have anyway) - and we will either break that native behavoiur (like it is now with the dropdowns) - or it will be impossible to go next/prev record when the focus is on such a control, because the control will eat the keypress. James said this had been done in GNUe Forms originally to emulate Oracle Forms, but asked what would you replace those keys with? Reinhard was not sure but suggested setting aside four function keys matching first, prev, next, last might be an option, but that would mean to redefine other f-keys, too - alt cursor keys might be another option. James wasn't keen on using the function keys, but i could live with the alt-curs-up|down setup i imagine as it would require little new learning for the people here - and alt left right could work same as shift-tab/tab i imagine. However, Reinhard believed that alt cursor keys are not available on curses, the text-only user interface which GNUe needed to support, along with the graphical user interfaces (as previously discussed in ) - and in any case, alt left right might be useful to change tabs. Johannes noted that this currently used ctrl-page-up/down.

James noted that some of the current key mappings were not ideal - F12 == new record - F11 = rollback - two functions that shouldn't be anywhere near each other on the keyboard. In any case, Johannes pointed out that F11 was used by the window-manager on os x and so was unusable on Apple Macs. Other potentially usuable function keys were also already mapped in different operating systems. James wondered if we'll need environment specific mappings. Nobody was that keen on this, especially since they could see themselves using GNUe on different operating systems at the same time, but felt that it might be unavoidable - James just did not see us finding one magic keybinding set that works everywhere.

Some days later, Tamás asked that keypresses should be configurable - i have more than 100 old customers using my old foxpro based app from 1992 - using up/down arrows to change next/prev record - they will kill me, if i ever chage it to shift/ctrl/alt +up/down - we (kilo and me) started to rewrite it in gnue - fortunately we have no deadlines in stone. At first, Johannes did not think he could do very much about that, as i don't get that event at all (at control-level) Reinhard suggested maybe it would be an idea to *not* assign cursor up/down as a menu hotkey as well. Johannes said that would help, and if we skipp up/down in the keymappers getEventKeyStroke .. it still works (as the keymapper can still associate the event) - but it is not bound in the menu. Later, he reported that he had got it working so that users could still use the up/down keys for next/previous record generally, but that whilst in a dropdown these keys would navigate between drop-down entries instead.

Tamás downloaded the changes, and was happy with the up/down behaviour, but noted that enter doesn't select from the dropdown as expected. Johannes investigated and reported that it jumps to the next entry on win, but it does not on gtk2 .... He found the bug and fixed it.

Tamás then reported that after pressing the enter key the focus is going to the next entry now, but the selected value from the dropdown is not ok. After some digging, Johannes discovered that this was a bug in the underlying wx 2.6.2.1 driver - according to the mailinglist this bug should be fixed with 2.7.

The next day, Johannes reported back the dropdown-problem is a known issue and the wx developers would be trying to look at it this weekend according to an e-mail he had received - meanwhile i'd prefer using wx 2.6.1.0 as it is working perfectly with that version. Tamás confirmed he had tried it with 2.6.1.0, and it's ok. Johannes confirmed he was still looking at the page-switching problem, I've not found the pb right now ....

In the midst of a potential vi-versus-emacs holy war, Reinhard Müller (reinhard) suggested that syntax highlighting and automatic indenting would be nice for writing triggers in designer ... not so sure whether i'm still joking or not, actually :-). Jason Cater (jcater) said that GNUe Designer already did highlighting - in fact, he has been working on designer a lot this weekend - expect some mm, mmm goodness. Reinhard had seen your huge commits, and it's great to see you back gnue'ing again.

He asked what's your take on layout management? will it cause problems for designer?. James Thompson (jamest) noted that designer currently uses forms wx ui driver to render the form (unless something radically changed) - iirc it also links into the events from forms to capture focus events to know what is being edited. Reinhard deduced that basically as long as the wx driver can render it, it will be not a big problem? Jason confirmed this - but he might need to change this. from a coding standpoint, it is great - as when a feature is added to forms - then designer automatically supports it. However, wx won't let us capture all events on an object consistently enough - so it makes the designer experience "lacking" - so I'm experimenting with drawing the controls within the GNUe Designer code itseld rather than leaving this to the wx libraries. Reinhard wondered if maybe wx2.6 has become better on that. Jason replied not really - actually stuff that I could get away with in 2.4 - won't work in 2.6 - /me found out the hard way this weekend :).

He confirmed that I'm not changing too much how designer works with forms - as I know you'll be changing some stuff - I'm working more on the designer code base itself - as designer was designed to be able to edit any GObject-based structure (any XML definition used for a GNUe object - whether it be a form definition, report definition, trigger or whatever) and I have a lot of GObject-based stuff in-house.

Peter Sullivan (psu) asked what's the current status of the project? His perception was: a) Two tier tools - pretty much mature, in that jcater and jamest have all the features they want - b) App Server - probably where 2-tier tools were when I was last here, i.e. useful 0.somethings but still needs work - c) Packages - still really waiting for anyone to take an interest. Not really a focus for any of the existing developers. James Thompson said that the two-tier tools (GNUe Forms, GNUe Reports, etc.) did not have all the features he wanted, but i've been unable to find time to GNUe seriously in years. Jason Cater felt that appserver is probably more stable than the 2-tier at this point - but that's for reinhard to say. Reinhard Müller (reinhard) said that appserver is more or less only missing 2 key features before 1.0: authentication/access control and transaction/locking support.

He added that the GNUe packages would actually be a focus for me, but I have no time. gnue-luca is started but stalled. This was a series of ERP packages for GNU Enterprise, targeted at small and medium companies. Its major aim is to provide a comfortable and easily usable solution for the most common tasks in such companies, while still remaining flexible enough that it can be extended to fulfill more specialized jobs. He added `Luca' is an acronym for 'Lightweight Utility for Company Accounting'. However, some people believe that the name was really chosen in memory of Luca Pacioli, an Italian mathematician (1445-1517) who is credited with the first publication of the `Venetian method' of keeping accounts, now known as double-entry bookkeeping. Peter remembered Double-entry bookkeeping is one of those things that was sort of discovered rather than invented - in that the Venetian merchants noted that whenever they sold something - they had to record the reduction of stock in the stock book - and the debt incurred by the merchant who bought it in their accounts receivable book - Soon they started cross-refering the two entries - and voila - double entry bookkeeping. The conversation drifted off onto Enron jokes.

It was reported that GNUe Forms was not even starting on Windows if it was not started from within the c:\program files\gnue\bin directory - was it necessary to set an environment variable to avoid this? James Thompson (jamest) didn't think that was necessary. He upgraded to the latest version, and couldn't reproduce the error - it loaded forms, let me login, then tracebacked. He suggested asking Bajusz Tamás (btami), who maintains the windows port.

Later, Tamás said that it sounded as if the problem might be that All gnue tools (forsm/ designer/ navigator/ reports/ appserver) depends on gnue-common. If it was not installed, this exception generated. He was intending to enhance all of the GNUe executables for Windows to check not only the existence of runtime, but gnue-common too. James wasn't sure that this was the issue, but didn't have time to look at it further.

James Thompson (jamest) asked do we have a real test schema for gnue?, clarifying i mean db structures. Reinhard Müller (reinhard) said I always use zipcode and the appserver sample. James said he had a very simple two-table database he often used, but this was not much of a test - i was hoping maybe we had something like MS's northwind db setup - it's a complete schema for a business as a sample.

Reinhard felt that we need to consolidate our samples and test forms - most of them are not maintained and not kept up to date. James confided that he might have some time to do some cleanup of samples - so I can start some unit tests. Reinhard suggested building a sample database in the gnue-samples dir - as it will be gpd, gfd, grd and everything. They discussed some of the details. Reinhard would prefer a *single* well-maintained sample, or at any rate one 2-tier and one appserver - where they could even be the same in principle - just ported to appserver - and the sample would not only contain the schema but also some data - that would really be great to have.

James asked whether it was better to have one GNUe Schema Definition (.gsd) file as the sample or can you easily load a whole dir of them? Johannes Vetter (joannesV) explained you could pass in a bunch of gsd's into a single call of gnue-schema - all that tables are then sorted to fulllfill all dependecies.

James looked at a simple address book sample he already had and asked is there a proper way to deal with postal codes internationally, as he was starting with the zipcode sample - and so I have zipcode and state - which are kinda americanized :). Reinhard explained it's usually postal code in british english - and for most of europe, the order is "zip city" - and as most countries in europe are a little bit smaller than the US, there is no need for a state.

Later, James confirmed i'm creating a testkit starting w/ an invoice - it's not suited for real world invoicing but it hits quite a few gotchas in tables (at least I think) and was uncovering some bugs in the code. He discussed the directory structure to store this in with Reinhard. He also said i'm working from the assumption that unit tests are going to expect - a fresh gnue db for each run. Reinhard confirmed that's what we have always done with our tests in appserver. James wished gnue-schema could deal with changes in the structure better - or an option to overwrite the existing db structures if passed a flag but Reinhard made the point that so far, we deliberately didn't make gnue-schema delete anything that is already there - just to not have the risk of accidentally deleting things, which James agreed with. Reinhard noted that it should work with adding columns - changing the type of an existing column is probably not possible for most databases that GNUe had drivers for, except with dropping and creating it again - which will lose all data.

The next day, Bajusz Tamás (btami) asked whether James had seen the gnue-invoice sample app in the gnue-contrib repository, but noted that this had dependancies on gnue-packages a bit. James explained all i'm after is a testkit for gnue - not really something fleshed out completely - but something we can all use in unit tests, samples, etc.

The next day, James asked whether the sample gsd files I put into gnue-samples could be expanded, and all applications and unit testing use these samples. Reinhard said we already did that in appserver, actually - gnue-appserver/tests/data.py. This was just data - the schema was in a different file.

Reinhard said that the sample data needed to include all possible field types - date, time, datetime, boolean, test, number with and without fractions - also an example of a fishhook where a table references itself for a foreign key. For instance, a part/item record could have a field defining a possible replacement/substitute part (which would be another item in the same table), or an employee record could have a field defining their boss (who would be another employee in the same table).

Later, Jason Cater (jcater) said he would just like to use something common for some of my stuff too. James said i think we're talking about revamping all the various samples in gnue - as so many are broken - and make a single, consistant sample system - nothing complex - that's what I started in gnue-samples. Jason had been using sample data sets with about 300 records, but the consensus was that a smaller data set was needed for the GNUe samples - Reinhard felt that 300 records is too little anyway to do performance tests - and OTOH it's too much as that you could easily predict what should come out of a specific operation. Jason agreed, saying that his sample set was mainly used for reporting tests - which explains the size. Reinhard noted in the appserver sample I think we had 5 records - I think something between 5 and 10 might be enough. Jason felt that this was about right for sample standing data tables, but that sample fact data tables needed to be larger for reporting or other aggregate-type things.

Hearkening back to several previous discussions, including , Reinhard Müller forwarded an e-mail from the Epydoc mailing list and asked What would others think about switching to Epydoc 3.0 for GNUe? Given our project size, we might make up good beta testers. This package was capable of partly automating the production of documentation from python source code and docstrings. James Thompson, having previously proposed Epydoc in , was keen.

James Thompson (jamest) said he had defined a coalesce() function - which works exactly like postgresql's coalesce, returning the first non-null value in the list of parameters. He wondered if any of this would be of use to others and if so where I'd put them in common. Reinhard Müller (reinhard) suggested that a chain of OR statements in python would do exactly the same. Johannes Vetter wasn't sure - watch out ! - and gave a possible counter-example.