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