GNUe Traffic #32 For 8 Jun 2002

                               By Peter Sullivan

 New releases of Forms, Designer and Common and first releases of Reports and
                         Application Server announced.

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Introduction
  * Threads Covered

    1.  27 May 2002 - 29 May 2002 (22    Freedom issues with using Compiere as
                                  posts) an alternative to GNUe
    2.  29 May 2002 - 30 May 2002        Using GNUe with very small 'databases'
    3.  29 May 2002 - 2 Jun 2002  (1     New releases
                                  post)
    4.  29 May 2002                      GNUe Reports as a server application
    5.  29 May 2002                      Master/detail in GNUe Reports
    6.  29 May 2002                      Documentation standards for GNUe
    7.  29 May 2002 - 3 Jun 2002         Debian packages for GNUe and DCL
    8.  30 May 2002                      Using VISA/Mastercard merchant
                                         accounts with GNUe
    9.  30 May 2002                      Customising the main tool bar and menu
                                         bar in Forms
    10. 30 May 2002                      wxGrid widget in Forms
    11. 30 May 2002                      Using GNUe for invoicing
    12. 31 May 2002 - 1 Jun 2002         Application Server version numbering
    13. 1 Jun 2002                       man and info pages for GNUe
    14. 2 Jun 2002                       Application Server development
    15. 2 Jun 2002                       GNUe executables file names
    16. 2 Jun 2002                       Enter and execute queries in Forms
    17. 2 Jun 2002                       <block> and <option> tags - obsolete?
    18. 2 Jun 2002 - 4 Jun 2002          Triggers in Forms and Reports
    19. 2 Jun 2002                       Problems running GNUe from WinCVS
    20. 3 Jun 2002                       GNUe Project - cathedral or bazaar?
    21. 3 Jun 2002                       Writing packages with the GNUe Tools
    22. 3 Jun 2002                       Conditions in Application Server using
                                         prefix notation
    23. 3 Jun 2002                       What is GNUe? article on website
    24. 3 Jun 2002                       Post-release Publicity
    25. 3 Jun 2002                       Debugging GNUe Navigator
    26. 3 Jun 2002                       GNUe Common RPC naming
    27. 3 Jun 2002 - 4 Jun 2002          Look-up combo boxes in Forms
    28. 4 Jun 2002                       GNUe Class Definitions (.gcd) support
                                         for new Application Server
    29. 4 Jun 2002                       Maintaining UI independance whilst
                                         allowing custom widgets
    30. 4 Jun 2002                       Project Papo's first release

Introduction

This Cousin covers the three main mailing lists for the GNU Enterprise project,
gnue (http://mail.gnu.org/mailman/listinfo/gnue) , gnue-dev (http://
mail.gnu.org/mailman/listinfo/gnue-dev) and gnue-announce (http://mail.gnu.org/
mailman/listinfo/gnue-announce) . It also covers the #gnuenterprise IRC
channel. A great deal of development discussion for this project goes on in
IRC. You can find #gnuenterprise on irc.openprojects.net:6667, or you can
review the logs (http://www.gnuenterprise.org/irc-logs/) . For more information
about the GNU Enterprise project, see their home page at http://
www.gnuenterprise.org (http://www.gnuenterprise.org) .

1. Freedom issues with using Compiere as an alternative to GNUe

27 May 2002 - 29 May 2002 (22 posts) Archive Link: "Compiere now #1 on
sourceforge"

Topics: Why GNUe?, Financials (Accounting), Application Server

People: Todd Boyle, Christopher Brown, Derek Neighbors, Stephen Compall, Anders
Lindback, Robert Campbell, Ian Stewart, Christopher Brown

Todd Boyle was impressed with the "257,000 downloads" for Compiere (http://
www.compiere.org/) shown on their site on Sourceforge (http://sourceforge.net/
project/stats/?group_id=29057) . He had test-driven it, and wondered "Are there
any ERP professionals out there, who have reviewed this, who can provide a
whole, big-picture perspective?"

Christopher Brown said that "Part of the challenge in it is that it's a J2EE
system, thus meaning that it's only quasi-open-source" , as "you need to get
J2EE licenses from SunSoft, and a port to PostgreSQL won't change that." Derek
Neighbors said "Well certainly if 275,000 downloaded and are USING it, Oracle
should send out the 'pirate' patrol, call the BSA. As we (GNUe Core Team)
wanted to evaluate and so we downloaded and even though we had working Oracle
systems we didnt have the NEWEST versions and that was what required to even
play. So I find it not likely that a quarter million of sourceforge users have
an up to date legal license of Oracle. :)" Later, Todd said "I asked the guy
whose Compiere I tested, and he said it was running on a freely downloadable
Oracle database, with limitations against commercial use."

Todd said that most Small to Medium Enterprises were trapped in closed-source
solutions as of time of writing, and he felt that it was unfair to criticise
Compierer for being "not open enough" when it was "9000% more open than"
closed-source software. Derek said that "The goal of the GNU project is to
write Free Software specifically GPL anywhere they can." If other people had
different moral bases, then "its perfectly ok, but that doesnt mean everyone
should lower the bar to such standards."

Todd also felt "There is no need to badmouth Java." He noted that "It has
critical mass of developers and many excellent products" some of which were
open-source, some commercial. Derek said "There is nothing non-commerical about
Free Software. It can be bought, sold and used for commerce just like any
proprietary software can be." However, "Critical mass and lots of developers
means little if you are enslaved" , as Microsoft's customer base was
discovering with the latest "upgrade or die deathline next month" .

Todd said that saying that Free Software was not necessarily non-commercial
"contributes to my fear that GNUE, from viewpoint of a non-developer is
effectively, not different than a commercial and proprietary product" in trying
to acheive user lock-in. Was GNUe seeking "more to vanquish other software than
interoperate with it" ? He thought GNUe should "demonstrate the opposite -- a
culture of respect for the other software in the world, especially something
like Java that is NOT a commercial monopoly." He did not see that GNUe would
actually free the end users - "we are reliant forever on developers." Support
for "APIs or XML interfaces" to allow interoperability were an important part
of building trust, as interoperability was "the long-term protection against
high costs that comes from competition." He felt that issues such as "churn and
complexity and support costs" were "stronger weapons of Microsoft today than
the legal copyright." He thought it would be good "if any of the GNUE
developers could attend the OMG/OASIS Interop. conference in Orlando at the end
of June" .

Derek said that Microsoft was not the enemy - "propeitary software is the
enemy. Microsoft just has to be the ogre wielding the largest club at this
stage." . GNUe had already and would continue to "interoperate on any level
that does not violate the GPL which we operate under, but we will not change
our license nor submit code to something that enslaves others." He said the big
difference with free software such as GNUe was that you did not have to trust
the core developers - "You can hire one of numerous GNUe consulting firms to do
it for you. (Already there are several of these, see our sponsors page) or you
can hire any competent python programmer to do it for you as you have the
source code."

Stephen Compall said that "Interoperability, vendor independence, code
reusability [...], portability, better security, and lack of backdoors are some
effects that Freedom has on code. This is why I can say that even those who
don't care about freedom are much better off with free software." He believed
that GNU-RPC was a good example of interoperabilty within the GNUe project,
providing "standard Remote Process Communication (my personal redefinition of
the abbrev.) across many protocols." . He felt that "Java is really a
commercial monopoly, until Sun relinquishes legal control of it" even if they
would not "be tying royalties to Java anytime soon." For a pure end-user,
reliance on developers was an inevitable consequence of finding "it beneficial
to use computers" , but with GNUe, you were not dependant on the GNUe
developers in particular - "Anyone who wishes to leave is free to take the code
and ask another developer to work on it." .

Christopher Brown said that Sun's own web site made it clear that Java was a
proprietary product - "There may be multiple salescritters, and they may even
be at multiple companies, but if you want the J2EE that is required in order to
run Compiere, then you have to go through the Sun monopoly on J2EE." The only
alternative was "what is often termed "software piracy," despite the usual lack
of murder, rape, and looting properly associated with the crime of "piracy."" .

Anders Lindback said that JBOSS (http://www.jboss.org/) was an "an Open Source,
standards-compliant, J2EE application server" . Derek said "It is my
understanding that JBoss is not J2EE. In fact, I recall a rather big to do
about this with Enhydra at one point." Robert Campbell said "They consider
themselves J2EE-compliant, but the official Sun test is cost-prohibitive. JBoss
is licensed under the LGPL." He appreciated that GNUe would not want to change
to JBoss or Java at this stage, but wondered what the basis for the original
decision against Java was. Derek said that "4 years ago finding a Java virtual
machine that actual ran and did useful thing on GNU/Linux was not a trivial
thing." They had "listed the goals of what we wanted, and to our knowledge
nothing fit the bill." He emphasised "that even though a PRODUCT might be GPL/
LGPL that doesnt mean the TOOLS associated to build it are. I believe JBOSS
runs with blackdown or the likes now, but even that is on shaky ground." .

He concluded "You can love us or hate us, its up to you, but if you want a JAVA
platform GNUe is not for you. The core team has written applications in java
and thought frankly it, well wasnt for us. That doesnt mean other people dont
find it useful. We fully support anyone WANTING to do things in JAVA with GNUe.
For sometime we aided Ian Stewart in making a Java forms client, its in our CVS
still. All parts of GNUe are interoperable. If you wanted to use JBoss nothing
is stoping you. Should be as trivial as writing a driver in GNUe common and
going to town." .

Christopher Brown said that "JBoss doesn't solve the "independence from Sun
Java" issue; it requires a fully functional JVM version 1.3. Try and find one
of those that's not licensed from Sun..." With so many languagues available
with free implementations, it made sense for a free software project to choose
one of those. He said "Java's pretty neat, but the set of libraries that people
expect to use are a morass of license complexities; there are no two ways about
that. When GNUe was started, as a project, Java wasn't an acceptable option.
Today, with the licensing complexities, it's still not an acceptable option."
And that was without considering functionality issues, which was a "a
completely separate discussion :-)"

Earlier, he said that installing both Oracle and Java as pre-requisites for
Compiere was quite complex - he felt that "GNUe is pretty bad in the same
respect; it's quite daunting to get it up and running; it offers the small
mercy that you don't have to sign your life away on the off-chance that you
actually want to use it in "production." As GNUe hopefully improves, it should
become less daunting to install; the lack of licensing complexity ["can we
install that without negotiating a contract with Sun/Oracle?"] is always an
advantage." He felt that if the GNUe developers did use code from Compiere, "It
wouldn't buy them any "functional" standards" , and would create a dependancy
on two non-free software products. If the dependancies were not an issue for
people, they could just use Compiere directly.

Derek said that, although the forthcoming port of Compiere to PostGreSQL would
remove (one of) the non-free dependancies, Compiere itself was still licensed
under the Mozilla Public License (MPL). "I dont see how sane developers could
contribute to a project with this type of license w/o being fearful of having
the rug pulled out from under them." The MPL "is free software so it certainly
falls under the 'usable' category. However, it is not a strong copyleft license
- which would make submitting code to it not the wisest decision (imho)." Even
AOL/Time Warner had recognised this, with the "dual license MPL/GPL of mozilla"
.

Todd said that, although access to the source code "provides an upper limit on
the amount of loss or damage the SME can suffer from the software" , there was
still a cost in changing away from GNUe, as with other systems. This was one of
the reasons that companies often ran down their old financial systems and kept
them for read-only access rather than migrate the transactions. He felt that
"With Microsoft already selling great plains at $1000" , they could "keep
dropping the price, grooming the code, making the database stand up without
maintenance, making the software easier to configure and use, until it is taken
for granted" . Their control of the operating system, whether Windows or .net,
would destroy the competition, with their accounting system becoming the
standard that others needed to comply with. Mid-range ERP vendors and their
networks of Value Added Resellers (VARs) would also be vulnerable. "Mickey has
500 million desktops! They have cash reserves of what, $30 billion? How can
anything compete with that?" The launch of X-Box showed how Microsoft could
enter new markets. GNUe was important because it could end up as the only
competitor to Great Plains, in the same way that GNU/Linux might or might not
prove to be the only effective competitor to Microsoft Windows in the operating
systems market.

2. Using GNUe with very small 'databases'

29 May 2002 - 30 May 2002 Archive Link: "[IRC] 30 May 2002"

Topics: Forms, Common

People: Derek Neighbors, Andrew Mitchell

Derek Neighbors (dneighbo) suggested "you could implement gadfly driver for us
:) - or xml driver - so that we could have gnue lite :)" Also, "interbase used
to to have personal interbase which was basically an interbase for desktops but
same API - i wonder if firebird" (the free 'fork' of Interbase) also had this.
Andrew Mitchell (ajmitch) felt that "a light db that could be installed would
work ok - still overkill for some" .

3. New releases

29 May 2002 - 2 Jun 2002 (1 post) Archive Link: "[Gnue-announce] New Releases
of GNUe Forms, Designer, Common, Reports, AppServer"

Topics: Forms, Designer, Common, Reports, Application Server, DCL

People: Jason Cater, James Thompson, Daniel Baumann, Derek Neighbors, Bajusz
Tam?s, Reinhard M?ller, Jan Ischebeck, Andrew Mitchell, Marcos Dione

On IRC (http://www.gnuenterprise.org/irc-logs/gnue-public.log.30May2002) ,
Jason Cater (jcater) asked "anyone have any critical outstanding bugs in any of
the products?" James Thompson said he had two - "if you have a dropdown pulling
values from a datasource - and the key is an int field - the system blows up" .
Also, "if you have an int field in your db and attempt to commit - it's value
is converted to a float and the commit bombs" . Jason thought "that last one's
gonna be a biggie to fix" .

Jason posted a pre-release candidate - the actual release date would depend "on
how many critical bugs y'all find in my prereleases :)(" . He would hope to
have it tagged in CVS fairly soon, even if the "Win32 binaries and
announcements" were not. Daniel Baumann (chillywilly) asked "which day is it
that derek like's to release on Sunday?" Derek Neighbors (dneighbo) said "i
prefer to do our freshmeat 'announcements' on diff days - so say we have forms,
reports, common, designer ready - i like to do one a day for maximum exposure -
but on our website and announce list would do them all as one" . It was
possible that DCL might be ready to release as well, "and have an all out GNUe
release :)" - including even "appserver too actually" , as "it seems to have
the functionality they said it would have" for version 0.0.1.

Derek downloaded a pre-release, and noted that it required python's distutils,
which were not included in the main debian package for python - "i think they
consider distutils as 'special' - more a 'developers' tool than a standard
library" . There also didn't appear to be a scripts directory in the tar ball.
Jason Cater (jcater) said "it should be included - but not sure why distutils
didn't" . Later, he reported that the problem was "last release we commented
out the scripts = ['scripts/gnuedtd'] line - as end users won't use that anyway
:)" He did a third pre-release and uploaded it.

Daniel Baumann (chillywilly) and Andrew Mitchell (ajmitch) also did some more
testing of the new pre-release tar ball.

The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.31May2002)
, Derek reported some "issues with preleases on this box" , but Jason Cater
(jcater) thought these might be from traces of a previous prerelease. Derek
fixed this, and tried various test forms, all of which passed.

Derek said that the release would include the first (version 0.0.1) release of
Application Server - "it is nothing more than a 'good faith' release though
i.e. it does things and works as advertised for the features given - but is not
overtly useful just yet" . Jason asked "am I supposed to be packaging up
appserver for this release too?" . Derek said "um if you can great - if not it
will afll on appserver team - my impression was siesel had pretty much run
tests and should just be a ./setup.py sdist or whatever - and then put in
prerelease dir - and we push bugs to appserver-support@gnuenterprise.org :)"

After the weekend (http://www.gnuenterprise.org/irc-logs/
gnue-public.log.03Jun2002) , after some help from Jan Ischebeck (siesel),
Bajusz Tam?s (btami) reported "the appservertest is ok now on win32 except
deleting records" .

Reinhard M?ller (reinhard) noted "in all setup.py the author_email point to
obsolete mail addresses" . He suggested "i think they should point to
gnue-dev@gnu.org" . Derek said it depended on the context - "my gut reaction
might be they point to product-support@gnuenterprise.org" , the bug-reporting
addresses. Jason said "I think he's talking about the distutils Setup() thing"
, in which case it should point to the "info@gnue.org" address.

Jason asked people to test one final set of tarballs - "if these install ok,
then these are the release" . He said "tonight we are releasing GNUe-Forms
0.3.0, GNUe-Common 0.3.0, GNUe-Designer 0.3.0, GNUe-Reports 0.0.1, and
GNUe-AppServer 0.0.1" . James said he would tag CVS for the release. Marcos
Dione (StyXman) found a minor bug in Designer - James said it would have to be
"a "known bug" for this release :)" . James reported that "common, forms,
designer, reports, appserver all tagged [...] jcater is moving the tarballs
into the downloads area - we've released" . There was much rejoicing in the
streets of #gnuenterprise.

Derek asked whether "tonight i can relase to the world? i.e. freshmeat and
friends" . He said "congrats to all whom helpd with this release - as i think
we had a lot more people testing and installing than in the past - and
submitting patches. jcater and jamest extra thanks to you guys as i know you
are both busy as hell" . Jason said he had a release announcement ready, which
he was just proof-reading one last time.

He wondered if his description of Application Server 0.0.1 was fair. Daniel
Baumann (chillywilly) thought it was - "it was just to prove that you can make
a nice appserver by using common ;)" . Jason said that "what's cool is look at
the changelogs - not many commits to anything besides common - well, relatively
speaking" . Daniel said "common rocks my socks" .

Jason also noted that "in this release, we have 1) man pages 2) mechanisms for
spread-out file systems (i.e., everything doesn't have to be under gnue/ - so,
there's no reasons people shouldn't do debs and rpms :)" . Derek said that the
lack of man pages had been one of the reasons that GNUe debian packages had not
been included in Debian 3.0 (woody). Jason said "didn't know that - or I
would've done it a long time ago" . Derek said it had been a bit moot, "because
well our packages were broked so they didnt belng in woody" . There was no
chance of making woody now.

Jason posted the official announcement to the mailing list for:

  * GNUe Forms 0.3.0
  * GNUe Designer 0.3.0
  * GNUe Common 0.3.0
  * GNUe Reports 0.0.1
  * GNUe Application Server 0.0.1

He noted "All of these releases are targeted at developers. The five products
are available in source form from our website" . There were also "Windows
installers for GNUe-Designer and GNUe-Forms that include all the basic
dependencies -- you only have to download a single setup.exe!" All of the
packaes ran on GNU/Linux, 32-bit versions of Microsoft Windows, FreeBSD and
(except for Reports and Application server) Sun Solaris. He listed the
changelogs for Forms, Designer and Common - Reports and Application Server were
initial releases.

4. GNUe Reports as a server application

29 May 2002 Archive Link: "[IRC] 30 May 2002"

Topics: Reports

People: Jan Ischebeck, Derek Neighbors

Jan Ischebeck (siesel) asked "how GRServer should work, if its finished?" Derek
Neighbors (dneighbo) said "it will be the reporting engine in distributed mode
i.e. it is the reports engine accessed via some sort of rpc" . There was an old
diagram at http://gnuenterprise.org/docs/reporter/flowchart.html, which was
"dated enough to be confusing but not so dated its horridly wrong" - he would
see if he could update it. The initial release of Reports would not be done as
a remote server at all - "just as static server - and the release after that
woudl probably be ironing out bugs and getting better transformation support -
and then the release after that would maybe start tackling distributed reports"
. Jan said he had done some work on in GNU-RPC to support remote Reports, but
he would not commit these until discussing them after the release.

5. Master/detail in GNUe Reports

29 May 2002 Archive Link: "[IRC] 30 May 2002"

Topics: Reports, Forms

People: Jason Cater, John Lenton, Derek Neighbors

Further to Issue #30, Section #2  (16 May 2002: Development work on GNUe
Reports) , Jason Cater (jcater) reported he was struggling with "reports master
/detail" . Derek Neighbors (dneighbo) said he had some test reports. Jason said
"To get the subtotal to work, I always have to have the NEXT record loaded as
well as the current record - that fscks up the auto-loading of the detail
sources - but I'm getting there, darn it!" . John Lenton (Chipaca) felt that
"master/detail in general (and not only in reports) is slightly twisted" , but
admitted he "isn't actually proposing a solution, you'll note" . Derek said
that master/detail in Forms was now fairly stable, although it had caused
problems in its day. Later, Jason reported "I think master/detail in reports is
ready for primetime - or at least a primetime beating" .

6. Documentation standards for GNUe

29 May 2002 Archive Link: "[IRC] 30 May 2002"

People: Jason Cater, Jan Ischebeck, Daniel Baumann

Further to Issue #4, Section #4  (14 Nov 2001: Using non-free tools for GNUe
Documentation) , Jason Cater (jcater) reported that "xforms is LGPL" , which
removed the last non-free dependancy for LyX. The pre-release tar balls
included "the Text and PDF versions of the docs" - lyx could "spit out LaTex,
PDF, Postscript, DOCBOOK, RTf, etc :)" Jan Ischebeck (sledge_) asked "do you
really want to rely on gui tools?" Jason said "I don't want to program docs - I
can say that for sure" . People did not have to use LyX to edit the source for
the documents - "LyX is just LaTeX after all - just as hand editable as
docbook" . They had resorted to lyx as "WE COULD NOT GET DOCBOOK TOOLS TO WORK
UNDER DEBIAN - after months and months of wasted trying" . Daniel Baumann
(chillywilly) said he had not had any problems. Jason said "we honestly tried
docbook - and it was more effort than worth" . Daniel asked "so when is lyx
going to use the free xforms?" Jason said that this was probably dependant on
the current freeze for the release of Debian 3.0 (woody). Daniel said "I just
want to be able to install it without adding non-free section" - he might try
compiling the free version from source. He noted "wow, 1.2.0 was just released
- like yesterday" . However, he noted that the release notes for LyX 1.2.0 made
it clear that LyX still depended "on a non-free version of xforms" as "as 1.0.0
hasn't been released" .

7. Debian packages for GNUe and DCL

29 May 2002 - 3 Jun 2002 Archive Link: "[IRC] 30 May 2002"

Topics: DCL

People: Nicholas Lee, Jason Cater, Derek Neighbors, Andrew Mitchell, R?mi
Perrot, Jan Ischebeck, Reinhard M?ller, James Thompson, Nick Rusnov, Daniel
Baumann, Jeff Bailey

Nicholas Lee (esands) asked "the debian/ stuff in the cvs is not upto date
right?" Jason Cater (jcater) said "definitely not" . Derek Neighbors (dneighbo)
said that Jeff Bailey had not liked "the way it was laid out" . He asked Andrew
Mitchell if he "could pretty pretty pretty pretty please be our maintainer for
dcl - we are having to issue a release this week :)" Andrew Mitchell (ajmitch)
said "iirc jbailey was doing debs for that, and became maintainer" . Derek said
"i think he said he was almost done but got caught up iwth life - if you could
finish them up - and then everytime we release tweak as necessary - that would
be great - as he is swamped" . He said that "on gnue packages i dont know if
anything has officially been started - but i would check with nickr and jbailey
first incase they have started" . Andrew sent some e-mails to try to
co-ordinate.

Some days later (http://www.gnuenterprise.org/irc-logs/
gnue-public.log.02Jun2002) , R?mi Perrot (jetto) asked "I see a debian dir. is
there a debian package ?" Jan Ischebeck said "there is a quite old debian
package. for now you better stay with cvs and wait for the next release for a
debian package " . R?mi said "I ask this as I am a debian maintainer." Reinhard
M?ller (reinhard) suggested "quick hold him! :)" . Jan said "i'm not quite
shure who did the last debian packages. but we are in the release phase at the
moment and it seems that although there are some who know something about
debian packaging, there is no real debian maintainer." Jason Cater (jcater)
said "we have 3 or 4 deb creators here but no debs" . He noted "most developers
here run debian" .

The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.04Jun2002)
, James Thompson (jamest) asked "what's the stat on .debs?" Several people said
they needed them with various degrees of desperation. Nick Rusnov (nickr) said
that he had not "tested it but the prototype debian/ for gnue-common looks just
about done" . He could probably get the GNU-RPC (GNUe Common) package done
fairly quickly, and "from common to others will be a trivial move I think" .

Looking at the new release, he said that some of the changes he had expected in
setup.py did not seem to be there - "basically I had thought we'd modified it
to accept a path to hardcode the location of a config file which would softcode
all other paths" . The --config-file option appeared to be broken. Jason Cater
(jcater) asked for "a run down on where stuff will go" . Nick gave the
debian-preferred locations for various types of files. Jason said that the
debian install script for Common would have to create the configuration file
before running the --config-file option, and gave an example of the contents it
needed. "then for all the other tools, use --cfg-file /path/to/this/file" .

Nick said that he needed "to give this file in a ... non-commital way - like
'these are the paths you should install to under --root, and this is the path
that the config file will be at later'" . Jason said that "I don't think any of
the tools (besides common) looks for the existance of that file - so you can
actually create the file wherever" . Nick asked "how will the other apps find
the various parts after installtion, then? or do they do that through common?"
Jason said "the other tools record where the file should be - so when their
executable script is run they look for the file - they don't actually look for
it when you do the ./setup.py" . Nick said he understood, but "I need to say
weher things SHOULD be and wher ethey SHOULD go (in relation to --root, which
will eventually be /)" . He asked, if he had a debian-setup.cfg file in the
debian/ directory, "how do I invoke setup to use that for the installation, and
do I have to install that osmewhere in the target directory?" Jason said "when
running the setup.py's for anything BUT common, you'll need to pass" the
location of that file using the --cfg-file option.

After some more discussion, Jason concluded "setup.py will not install to the
right places - you'll have to probably do your own install script to move the
files around" . Nick said "Whats the point of using setup.py at all? might as
well just write a debian-specific makefile and bypass all this bullshit" .
Daniel Baumann (chillywilly) asked if the proble was with the distutils. Nick
agreed, saying "I'm going to have to completely rewrite" the debian packaging
work he had already done "to work around distutils' brokeness - my plan is to
write a makefile to do it The Debian Way(tm) - it shouldn't be that hard."

James Thompson (jamest) asked "there is no way to do this in our setup system?"
He would like "to see setup.py stuff in common - so we have a real install
system" . Daniel suggested "./configure - make install - ;P" . Jason said
"that's probably what we'll need for debian support - but that can't be our
main install mechanism" as GNUe also needed to support "Win32 installs - Mac
installs" . Daniel said "mac run on top of unix - and supports auto tools -
win32 well you guys made a separate installer for that anyway" . James said
that a setup.py was easier "than autotools for dealing w/ python" , adding "i
think with some effort we could mold distutils and our setup stuff into a kick
ass setup system - it's just not been a priority" .

8. Using VISA/Mastercard merchant accounts with GNUe

30 May 2002 Archive Link: "[IRC] 31 May 2002"

Topics: Financials

People: Derek Neighbors

After a long disussion about electronic payment methods, Derek Neighbors
(dneighbo) referred back to Issue #9, Section #2  (18 Dec 2001: Credit Card
Verification) , saying "at one time last year was workign with some folks (
http://www.mainstreetsoftworks.com/) to do merchant stuff for GNUe - i.e. to
support it in GNUe. it was not free software but they were willing to give us
the software for free and set us up for testing and such - then like a month
later they were basically swallowed by red hat and i stopped pursuing it" as
they "got busy and we got busy" . He added "mainly our biggest issue is they
didnt support python - and since it wasnt open source we couldnt write support
and give back to them" . However, if they were at Linux World Expo in San
Fransisco, he would "try to meet with them to revamp the issue - as its
somethign we need to address" . He said that a credit card merchant account was
more expensive than a service like paypal, but "there are a LOT more visa/
mastercard holders than paypal holders" .

9. Customising the main tool bar and menu bar in Forms

30 May 2002 Archive Link: "[IRC] 31 May 2002"

Topics: Forms, Navigator

People: Marcos Dione, Jason Cater, Derek Neighbors, John Lenton

Marcos Dione (StyXman) asked how to set options for his new main tool bar and
main menu widgets. If it was just "a form option" he would just use "a <form>
attr" but, as the tool bar itself would need attributes, "I propose a new tag."
Jason Cater (jcater) asked whether Marcos was trying to "enable/disable the
toolbars - or customization" . For the latter, "jamest has a lot of code in
place for that that we need to work with" . Marcos clarified that it was not
for "customization of the buttons on the toolbar, but sat, the toolbar
position, direction, etc," Jason said he did not "think the forms file is the
place for that" - "I personally think that's more of a gnue.conf setting" Derek
Neighbors (dneighbo) said "i guess i envisioned is that we woudl have base menu
and base toolbar and you could configure those via gnue.conf" but "at form
level you could shut them off" . He felt that "'custom' menus/toolbars woudl be
from navigator" . He "definitely do NOT think mneus and tool bars belong in
forms files - forms should be able to 'manipulate' those items but should not
generate them - if that makes sense" .

John Lenton (Chipaca) gave an example - "on the billing screen the toolbar is
completely superfluous: you don't want to do 'next record'; you just want to
bill stuff. but in the same application we might have a 'product inventory'
thing, where the toolbar (or its functionality) is needed" . Derek clarified
that "im not saying cant do custom - im saying custom belongs (imho) in
navigator (.gpd) not in .gfd" . He explained "think of it as a framework and
the menu/toolbar are part of the framework and not the form - so to navigate
between different forms you probably would use menus and such - if you put
these in the form you would be repeating the menu structure all over which
would be a complete nightmare" . He emphasised that GNUe was not intended to be
a "feature laden gui's" like glade - "its designed to do hard core business
applications" which could be (as far as possible) UI-independant.

10. wxGrid widget in Forms

30 May 2002 Archive Link: "[IRC] 31 May 2002"

Topics: Forms

People: Bajusz Tam?s, Jason Cater

Bajusz Tam?s (btami) asked "have you seen wxgrid examples in wxpython? what do
you think about a real grid in forms?" . Jason said "I would see it as a type
of block - we have to be really careful of what we add - as wx is just one UI
available" . He added "I hate making widgets only for wx - but I'm thinking if
it's a "style" of block - then if the UI doesn't support a grid-style thingy -
it can fall back to a normal block" .

11. Using GNUe for invoicing

30 May 2002 Archive Link: "[IRC] 31 May 2002"

Topics: Financials

People: Jason Cater

Recommendations were requested for printing and tracking invoices using free
software. Jason Cater (jcater) said "there aren't many good options :( - I've
been looking at NOLA recently - it may serve your needs... not sure - it is
web-based, though" . However, "GNUe will provide invoicing soon - but I assumed
you needed a solution that would work for you today" . It was favourably noted
that GNUe was supporting real GUIs and not just HTML forms. Jason said he
agreed - "I think web apps are another great tool to have in the toolbox - but
not the only tool" .

12. Application Server version numbering

31 May 2002 - 1 Jun 2002 Archive Link: "[IRC] 01 Jun 2002"

People: Derek Neighbors, Jason Cater, Reinhard M?ller

Derek Neighbors (dneighbo) asked about version numbers for the new Application
Server as opposed to the old GEAS - "if we release appserver 0.0.1 when like
0.3.0 or something already exists" . Possible solutions were "a. we dont do a
'public' release until functionality surpasses the old geas - b. we release
with a higher version number even though there is regression - c. we just break
logic :)" . Jason said "I'd go with a) or c)" , although "siesel asked me today
to hold off a little on appserver - as he found some not-so-good problems w/it
- so I'm wondering if we shouldn't just hold off a week or two on appserver -
(that would let them get conditionals working)" . However, this was really up
to the Application Server people. "um, actually, I know he found an issue w/
win98 support - but honestly, if that's what his issue is, I'd say Windows
support for a 0.0.1 is, quite frankly, a laudable, but not very important goal"
.

The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.02Jun2002)
, Reinhard M?ller (reinhard) added "executable names for releases i would
propose to have gnue-appserver gnue-forms gnue-designer etc as this is least
dangerous for name conflicts - i could imagine some other project uses gforms
too for example." Also, "appserver is not geas it is replacing geas - so i see
no problem at all starting with appserver-0.0.1 - even when we had geas-0.3.0 -
and this is one of the reasons why i beg everyone to not name any "publicly
visible" (outside the source) things "geas"" .

13. man and info pages for GNUe

1 Jun 2002 Archive Link: "[IRC] 02 Jun 2002"

People: Jason Cater, Daniel Baumann, Jan Ischebeck, Derek Neighbors

Jason Cater (jcater) tracked down "the Linux Man-Page-HowTo" in preparation for
doing some man pages for GNUe. Daniel Baumann (chillywilly) suggested "we
should have info pages" . Jason said he had "added a --dump-man-page option to
GBaseApp - so if you find me a reference on info files I'll add a
--dump-info-file too :)" Daniel said "info pages are a lot nicer, imho ansd
tend to be more verbose and have excellent key bingdings for navigation ;)" -
also "info is the gnu documentation system - but whatever" .

Later, Jan Ischebeck (siesel) said "the auto created man files are cool. :)"
Jason said he had uploaded the man files to the website (http://
www.gnuenterprise.org/~jcater/man/) . Derek Neighbors (dneighbo) said that
ideally "man pages should be docbook" as these could then be automatically
converted to both man and info formats - "anyhow as long as we have man pages
it matters not how :)" . Jason clarified that the man files were being
generated from the inline help - "gfclient --help" - so docbook could be
automatically generated too. Doing it this way meant that "as soon as someone
adds a new command line option it is automatically documented - both in the
--help and in the man file" . Derek said this was a good idea - "some day i
will look at making it generate docbook instead (or in addition" ).

Daniel asked "doesn't python support inline docs in the code?" Derek said "it
was voted we didnt want to encourage 'docs' in code - i.e. we encourage CODE
comments - but we dont want to bloat the source with 'docs'" . Having said
that, "i still think we should be giving every function a one line description
- so we can use pydoc/happydoc to generate a SHELL - to help developers see the
big picture with opening a ton of files to find things" . Jason said "the one
reason pydoc and stuff would still be useful is to compare its annotations to
the current documentation to see what is lacking i.e., I'd still trust the
comments to be more up to date than the docs but I certainly wouldn't want to
rely on the comments to learn the api if that makes sense" . Things like GNUe
Common's API were not worth documenting until they had stabalised anyway.
Daniel agreed, yoda-like, "the source you read to become a jedi you must" .

14. Application Server development

2 Jun 2002 Archive Link: "[IRC] 03 Jun 2002"

Topics: Application Server

People: Reinhard M?ller, Jan Ischebeck

A few changes were proposed to the Application Server documentation. Reinhard
M?ller (reinhard) agreed, saying "i think it's important to distinguish between
tables/columns/fields (database side) and classes/instances/attributes (object
side)" . He was "not sure about storing object definitions visually - i'd like
more to store them structured and then have a tool that creates uml from that"
. He noted that a direct link between tables and Application Server objects
"could become difficult, because a) we might decide to ditch" GNUe Class
Definitions (gcd) - "b) DB syntax doesn't exist for every type of attribute
(for example for indirect fields) - c) DB syntax may be depending on database
backend" . He liked the idea of using dashed arrows to indicate dependancies on
the GEAS architecture diagram. Jan Ischebeck (siesel) said that "the signature
of a method should be provided by GEOR" , as should the field type. However,
"the whole GEOR stuff isn't defined yet" . As of time of writing, passing
parameters was not a problem "because GNURPC didn't check the parameter format
on method calls at the moment :(" , but this was likely to do better checking
in the future. He said "the next step and the next interface to define is the
interface to transfer GConditions to appserver." . It was asked if there were
plans to allow the conditions to be more complex, including ORs. Jan explained
how the syntax for this would work.

15. GNUe executables file names

2 Jun 2002 Archive Link: "[IRC] 03 Jun 2002"

Topics: Forms, Designer, Reports, Navigator, Application Server

People: Reinhard M?ller, James Thompson, Jan Ischebeck, Jason Cater, Andrew
Mitchell, Derek Neighbors

Reinhard M?ller (reinhard) noted that "The apps are installed into /usr/local/
bin as gfclient, gfdesigner, gnuenav, grrun, and grserve" , which he did not
like. James Thompson (jamest) agreed - "we should clean up the names for
consistancy" . Reinhard suggested "what about gnue-forms gnue-designer
gnue-navigator gnue-repclient gnue-repserver gnue-appserver ?" James said "i
think i'd be ok w/ that if the -'s work on all OSes" . Jan Ischebeck (siesel)
said that, given that support for MS-DOS was impossible, due to lack of python
2.x, all target operating systems "support the long names" . For the CVS
versions, James had "wondered about gcvs-forms, gcvs-designer, etc - but that's
a lot of typing :)" Reinhard agreed - "for cvs commands i like the short names"
.

Jason Cater (jcater) said he was "not sold on gnue-repclient and
gnue-repserver" . Later, Andrew Mitchell (ajmitch) asked "is this for package
names or executable names?" Jason confirmed "executables" , but Reinhard
pointed out that "however i think they would fit well for package names, too :)
" . It was agreed to use just gnue-reports for the Reports client, but no-one
seemed prepared to commit themselves between Jason's choices of
"gnue-reportserver or gnue-reports-server ?" . Derek Neighbors (dneighbo) said
"i do not think there is any reason to be overtly shortened - as if they are
having to start the server a lot, we have larger problems than a name :)" The
reason he was "pro longer names in this case is to prevent confusion" . James
agreed, pointing out that the existing gfclient name conflicted "with gadfly's
client program which existed prior to us - and gfdesigner doesn't make sense"
as Designer was intended to design things other than Forms. James posted the
final list of proposed executable names as "gnue-forms gnue-designer
gnue-navigator gnue-appserver gnue-reports gnue-reports-server" and went off
"to break cvs and all previous installs for our tools" .

16. Enter and execute queries in Forms

2 Jun 2002 Archive Link: "[IRC] 03 Jun 2002"

Topics: Forms

People: Michael Maluck, James Thompson, Jason Cater

Michael Maluck (madlocke) asked "why is there a query button for a form? why
not just query at startup?" James Thompson (jamest) said "because I may not
want to pull every record - i may want to input a filter" . Jason Cater
(jcater) said "I have a 6 million record customer database, I don't want any
raw queries happening against that table :)" James said "you can make a form
prequery by adding the prequery flag to the datasource tag" as part of
designing the form. To apply a filter to a query, "press the enter query button
- then put in std sql wildcard stuff in the fields" , using % for a
multi-character wildcard and _ for a single-character wildcard, "then exec the
query" . Michael noted that the tooltip for the Enter Query button still said
'prepare query'. James said "i think we went to enter query everywhere, musta
missed one" .

17. <block> and <option> tags - obsolete?

2 Jun 2002 Archive Link: "[IRC] 03 Jun 2002"

Topics: Forms, Reports

People: James Thompson, Jason Cater, Michael Maluck

Michael Maluck (madlocke) asked whether the block tag was still needed - he
could see no difference between a block and a datasource. James Thompson
(jamest) said blocks "used to do more - now they handle navigation IIRC - also
a datasource != a table" . Jason Cater (jcater) said that "datasources are
pretty generic - i.e., nothing forms-specific (or any tool-specific) should go
there - every tool that uses datasources has some logical "layout" or other
processing section like blocks e.g., reports has <sections> that handle
grouping - they logically serve the same function as blocks - but handle
report-specific functions. As we implement block "styles" (e.g., this infamous
grid that everyone wants) you'll begin to see the usefulness of blocks more and
more" . Michael said "but visual grouping and data grouping are too different
things, aren't they?" , asking "can i have more than one block for the same
datasource?" Jason "wouldn't recommend it, but I think you can" .

Michael said that blocks might cause problems for the layout manager he was
writing, as entries from the same block might need to go in seperate parts of
the form. James noted that "IIRC the new appserver uses" datasources without
blocks.

18. Triggers in Forms and Reports

2 Jun 2002 - 4 Jun 2002 Archive Link: "[IRC] 03 Jun 2002"

Topics: Forms, Reports, Common

People: Michael Maluck, James Thompson, Jason Cater

Michael Maluck (madlocke) asked what the main differences were between "this
old and new trigger stuff." James Thompson (jamest) said that the "main diff
currently is they are moving out of forms into common" which meant that other
tools such as Reports could theoretically use them. However, as of time of
writing, the triggers were "still too formsish" .

Two days later (http://www.gnuenterprise.org/irc-logs/gnue-public.log.05Jun2002
) , Michael asked "what kind of namespaces you wanted to create" for triggers.
James said that "the trigger namespace code is in common - and I think will
work ok minus a few issues" . The main thing "I still had left to do was
implement a real trigger manager that could merge namespaces, allow for other
trigger languages - right now the whole thing is still too forms dependent" .
Michael asked "you use the word trigger now for both, the event handling and
the code that is executed for an event, right?" Jason Cater (jcater) confirmed
this.

19. Problems running GNUe from WinCVS

2 Jun 2002 Archive Link: "[IRC] 03 Jun 2002"

Topics: Forms

People: Reinhard M?ller, James Thompson, Derek Neighbors, John Lenton

A bug was reported with Forms running from CVS on Windows - the \directory /
slashes in the path for a graphic image file were the wrong way around in the
latter part of the path. Reinhard M?ller (reinhard) suggested "please try to
remove your gnue.conf - there was an incompatible change - and gnue.conf isn't
updated from cvs as it is generated on setup.py" . James noted that this
problem was "from when I broke things like a month ago" . Derek Neighbors
(dneighbo) said he was "just trained to always copy his .conf files to backup"
before any changes. It was reported that deleting the gnue.conf file did not
solve the problem. Reinhard asked "could it be you have another gnue.conf
somewhere?" . After some searching, this proved to be the case. James noted
that "gnue.conf should be completely optional now" , with all applications
assuming default values if they could not find the file, rather than reporting
an error.

Problems were also reported with corrupted graphic image files. John Lenton
(Chipaca) said this was because "you're using wincvs - if anyone of you guys
have access to CVSROOT, there's this file you edit to tell cvs that .png files
are 'b'" for binary. James said that GNUe had a common CVSROOT with some other
projects, so he would need to check with them before making this change.

20. GNUe Project - cathedral or bazaar?

3 Jun 2002 Archive Link: "[IRC] 04 Jun 2002"

Topics: Why GNUe?

People: Dan Bethe

Eugence Rosenfeld (eugeneai) asked about the scalabilty and performance of the
GNUe tools. He was thinking of using GNUe as the basis for a very large
project, which could lead to sponsered developers. He asked about reference
sites. Dan Bethe (dtm) said "GNUe is in production at several sites - including
for a large county government in the US - i dont know how that compares to your
needs though." Eugence asked if the development model was more cathedral or
bazaar. Dan said "that's a fascinating question :) I think it's bazaar because
it's a volunteer effort, but it is voluntarily organized. The group has chosen
a leader. Individuals defer to others' expertise and leadership. They trust
each other, but they double-check their work. There are several leaders in
various projects, and one overall project leader. They choose to be that way,
and there's nothing requiring it. It's just a good idea."

21. Writing packages with the GNUe Tools

3 Jun 2002 Archive Link: "[IRC] 04 Jun 2002"

Topics: Financials, Manufacturing, Application Server

People: Jason Cater

It was asked if, with the latest release of the tools, the emphasis would now
shift to the packages like Financials and Manufacturing. Jason Cater (jcater)
said "probably not with this release - the application server is only at 0.0.1
- but is advancing very rapidly" . There was not really any existing code for
the packages, but there were some proposals in CVS.

22. Conditions in Application Server using prefix notation

3 Jun 2002 Archive Link: "[IRC] 04 Jun 2002"

Topics: Application Server

People: Jan Ischebeck, Reinhard M?ller

Jan Ischebeck (siesel) reported "first step on the way to appserver 0.0.2 is
done. GConditions support is working." Reinhard M?ller (reinhard) asked "can
you build complete trees with prefix notation?" They swapped a few examples.
Jan said "the only thing where i have to change the tree is if i get AND
(a,b,c) it becomes AND(a,AND(b,c))" . Reinhard asked "any reason you use prefix
and not postfix?" Jan said "prefix is a bit easier to parse." He said "the plus
of postfix and prefix over infix is that it doesn't need brackets" . Postfix
notation was the same as Reverse Polish Notation (RPN).

23. What is GNUe? article on website

3 Jun 2002 Archive Link: "[IRC] 04 Jun 2002"

People: Peter Sullivan, Jason Cater

Peter Sullivan (psu) pasted a "new version of the "What is GNUe?" article for
the website based on what dneighbo and reinhard keep saying whenever newbies
ask the q in this channel ;--)" .

GNUe Enterprise is (or will be) three linked things:

 1. A set of tools which provide a development framework for enterprise
    information technology professional to write or customise data-aware
    applications and deploy them effectively across large or small
    organisations. The GNUe platform boasts an open architecture and easy
    maintenance. It gives users a modular system and freedom from being stuck
    with a single-source vendor.
 2. A set of packages written using the tools, to implement a full Enterprise
    Resource Planning ( ERP) system. From human resources, accounting, customer
    relationship management and project management to supply chain or
    e-commerce, GNUe can handle the needs of any business, large or small.
 3. A general community of support and resources for developers writing
    applications using the GNUe Tools (whether part of the 'official' GNUe
    Packages or not). GNUe is a Free Software project with a corps of volunteer
    developers around the world working on GNUe projects. This provides the
    added benefits of easy internationalization of applications. The project is
    working to provide a worldwide GNUe community

The page would include a link to the Status page - "onus is obviously then to
keep Status doc up to date ;-)" . Jason Cater suggested revising the first
point to "A set of tools, such as a data-aware user interface, a reporting
system, and an application server, ..." . Peter agreed - "as we have lots of
e.gs in second para but not first" .

24. Post-release Publicity

3 Jun 2002 Archive Link: "[IRC] 04 Jun 2002"

People: Derek Neighbors, Jason Cater, Andrew Mitchell

Derek Neighbors (dneighbo) confirmed he was handling the publicity for the new
releases. The www.gnuenterprise.org website and gnue-announce mailing list had
been updated for all the releases, and announcements about GNUe Designer and
GNUe Common (GNU-RPC) had been posted to freshmeat. This had already driven up
traffic on the website - "looked at the stats - past 3 months they are anemic -
but in 2 hours after forms release its been off the hook - im suprised ash is
still standing - about 40k hits in a few hour period" . He would phase the
freshmeat announcements for Forms, Application Server and Reports over the next
few days. Jason Cater (jcater) noted "well, no complains on mailing lists or in
irc" and wondered "are ppl giving up quickly on it, or are they not having
issues?" Derek said he was "debating on listing on our other regulars" but
would probably post to "icewalkers, linuxapps (or whatever the name was), cnet
and such" at the weekend. Andrew Mitchell (ajmitch) suggested "you'd get quite
a few hits if it got on linuxtoday.com" .

25. Debugging GNUe Navigator

3 Jun 2002 Archive Link: "[IRC] 04 Jun 2002"

Topics: Navigator

People: Jason Cater, Peter Sullivan, Derek Neighbors, Andrew Mitchell, Michael
Maluck

Jason Cater (jcater) said "we should probably clean up navigator a bit and
release it" . Peter Sullivan (psu) said that Navigator had never been released
- it had been "said it would be in next release - and avail from CVS in
meantime - I guess that's still true" . Jason said "we could release navigator
any day now, I suppose - there's nothing that says all the tools need to be
released at the same time" . Jason said "it has a l33t HTML based display -
(not browswer, just html renderer) that's skinnable :)" . However, "I'm having
issues with wxHTML and catching the URL clicks" . He had reported this, but had
been told "it's a bug on my end" . He had really wanted to fix this "before
releasing - as that would kick some arse" . Derek Neighbors (dneighbo)
confirmed "i think we need not release things at same time - i am willing to do
some testing - and contact the list for wx and light a fire to get a response"
, especially if the bug was easily reproducable.

Jason noted that Navigator could be used in conjunction with KDE, to
automatically "build a KDE menu" from the definition file "so each form/report/
etc is an option on the menu" . Andrew Mitchell (ajmitch) reported that "it
worked for my gnome menu too" , but not under "a gnome2 setup - different dirs
- you could use the debian tools to install into debian menus tho" .

Jason asked other people to have a look at his problem code in UIweb.py - "it
could use another set of eyes" and he had not used the wxHTML classes other
than for this. Derek commented that free software was "the only place where the
users explain to the developers how to use the software" . Andrew and Michael
Maluck (madlocke) were both able to reproduce the error. Derek asked "are we
all using latest greatest wxPython?" as the problem might have been fixed in
later versions. Andrew confirmed he was using 2.3.2.1 - "needed the newer
version for stuff i'm doing" .

Jason tried to find any useful references on Google, but only got "11 responses
- 2 of which are us" . He could not see any difference between his code and the
working sample code - "did I mispell OnLinkClicked or something?" . He reported
"I fixed it - apparently it's a C++ <--> Python integration issue - I was
building a MyHtmlWindow instance and then right after it, overloading the
OnLinkClicked - but the overloading was negating out somehow. I dunno - it's
hard to explain" . Derek said that was "the best kind of bug" . Jason did some
more testing, and reported "ok, if anyone wants to play with the -u web driver,
it's committed in cvs - it's amazing what 4 months of not looking at something
can do :) - btw, just for the record, it is a wxPython bug" .

26. GNUe Common RPC naming

3 Jun 2002 Archive Link: "[IRC] 04 Jun 2002"

Topics: Common

People: Jan Ischebeck, Daniel Baumann, Jason Cater

Jan Ischebeck (siesel) asked "did you had a look at the GComm Proposal the last
days? Although there is still much missing, I hope it make GNURPC a bit more
clear" . Daniel Baumann (chillywilly), remembering Issue #1, Section #2  (
24 Oct 2001: GNUe Common vs. GNU Comm project) , suggested "you should rename
it - in fact the code should be renamed to reflect it too - GComm is actually a
meta project creaed by Dave for GNU Telephony software, iirc - which is also
part of GNUe (sorta)" . Jason Cater (jcater) thought that "GnuRPC is misleading
- this is a GNUe thing" . He did not think that the filenames were a problem,
"but if you think GComm.py is misleading, change it to GRpc.py" . The official
name for GNU-RPC "is "GNUe-Common RPC Abstraction" as far as I'm concerned" .
Jan said that he would like "communication" in the name somewhere, as it was
intended to cover MOM ( "Message Oriented Middleware" ) as well as RPC. Daniel
said he "was meaning to work on it cause I had ideas for this big middleware
thing, but didn't have time and can't keep up with the code machine that is
jcater ;P" .

27. Look-up combo boxes in Forms

3 Jun 2002 - 4 Jun 2002 Archive Link: "[IRC] 04 Jun 2002"

Topics: Forms

People: Derek Neighbors, Jason Cater, James Thompson, Perry Lorier

Derek Neighbors (dneighbo) reported a problem with the master/detail wizard in
Forms. Where one table had both a child-parent and a parent-child relationship
with another (e.g. departments have employees, but some employees are also
managers of departments), then look-up combo boxes (e.g. to allow users to look
up the manager name rather than the manager ID) were failing. He said "maybe im
being lazy here - but if i wasnt familiar with forms i would be scratching my
head pretty hard why this didnt work" . He explained "its not a bug really -
what happens is the wizard makes it typecast (correctly) - but the combobox
while storing an int, really displays text - so when you select it disappears"
as the displayed text value was "not a valid integer :)" . He said "if we dont
call it a bug and fix it - we probably need to institute some error message" .

Derek also noted that "there seems to be no way to update combo box contents" -
the usual enter query/execute query hotkeys updated the fields in the main
form, not the combobox. Jason Cater (jcater) said he was "torn as to "correct"
behaviour" . Derek said it could be done via triggers, "but im inclined that
someday someone will want - so i wouldnt be opposed to making it an 'option'" ,
with a "requery="true"" attribute on the combo box's XML tag. He was not sure
how common this would be.

The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.05Jun2002)
, it was asked how to use a drop-down box to add a parent record "on the fly,"
using a button to call another form and then refreshing the drop-down list to
include the new value. James said "right now the values in a dropdown are
populated at form initialization - but never reloaded - so if the values in the
table the dropdown pulls form change you have to reload the form. I'm open to
ideas on how to deal with this - i didn't want to refresh values prior to each
opening of the dropdown as thats a pretty big performance hit" and "and not all
db's support a way for a table to notify apps that it's values have been
altered. i had wondered about adding a menu entry to tell the form to refresh
it's lookup information - but that requires the user to know the table values
changed in the first place" . Perry Lorier (Isomer) noted that "postgres
supports notification" .

To allow a form to call another form, James noted that "there was at one time a
runform() command in the trigger system - but I'm not sure it's functional at
the moment as it had troubles w/ launching multiple multipage forms - so it may
be disabled - what i did as a work arround was launch a whole new form instance
via pythons (IIRC) system command - it's been a while though since I did a form
like that and it's at home so I can't check" . A workaround was proposed, but
it meant that when the child form was closed, the main form also closed.

Later, Derek said his "suggestion was an option on the entry (dropdown) for
refresh="true". If that is set then when an f7/f8 is performed the dropdown
contents are refreshed - i dont know if that is a good 'coding' solution - but
it would be acceptable to me as a forms developer" . James said "that might get
ugly on large dropdowns" . Derek said that was why the default for refresh
would be false - "so there is no performance hit unless you specifically ask
for it - the other option is we dont provision for it and force people to use
triggers to get the behavior" . There was some support for James' original idea
for a toolbar button and/or menu option to refresh all the dropdowns in a form.

Derek said "i like idea of adding option per entry - then user doesnt have to
think about it - it just happens" . He assumed "that when you do an f8/f9 only
the datasource you are in gets requeried and sources linked to it - i.e. master
detail" . His idea would mean this "would just be extended to look for foreign
keys" used in dropdown as well. James agreed - "the bad side of this is I
typically notice my dropdown is lacking as I'm entering/altering a record - not
before I query" . Derek agreed, but said the only alternative was to re-query
the dropdown every time it was used, but this "has the most severe performance
penalty (which is why i dont like it)" . Another suggestion was to put a dummy
row into all dropdowns that, when selected, called a subform and updated the
drop-down afterwards. Derek said "i was thinking of some mechanism like that,
but then thought maybe the menu option to 'refresh' dropdowns or such would be
more elegant in that situation" .

28. GNUe Class Definitions (.gcd) support for new Application Server

4 Jun 2002 Archive Link: "[IRC] 05 Jun 2002"

Topics: Application Server

People: Jason Cater, Jan Ischebeck, Derek Neighbors, James Thompson, Reinhard
M?ller

Jason Cater (jcater) noted that Jan Ischebeck (siesel) was "working on a GCD
parser" and warned "I think we are moving away from GCD files - and to XML that
can be parsed with GParser - so I'm not sure if you want to be spending any
time on the GCD stuff" .

Jan said he was not keen on the GNUe Class Definition (gcd) format "but I
thought that we should stay with gcd until the xml format for appserver objects
is well defined" . Derek Neighbors (dneighbo) said "i really dislike the idea
of using the gcd's" . He would prefer to put effort into getting the triggers
in GNUe Common working over RPC - "at which point we have something highly
functional and not overly complex - and then we can start arguing about
objects" . He thought that "the gcd's are not of any use without a TON of work"
, which meant "gcd data is not useful until you have a full object/relational
engine" . As previously discussed, he would prefer to start with just getting
"remote methods working (as it seems remote data works now) - and we have a
HUGE victory quickly - then we tackle how we want to approach object to
relational" .

Jan noted "the GTrigger stuff works well if the whole object tree is stored in
xml files. If we want to store class/table method/trigger definitions in the
database, GTrigger has to be changed a LOT to make that possible." James
Thompson (jamest) asked why - "wouldn't triggers load from the db upon
initialization?" Jason said that "bear in mind that the only thing tying us to
XML is the loadObject methods and the dumpXML - but once the object is created,
it's created" . He personally thought "it will be a very small step from
XML-stored" GNUe definition files of various kinds "to database-stored (for
those who insist on having stuff in the database) :)" .

Jan said "the thing which I don't like in GTriggers is that it is a) closely
connected to the GObj ( which is great if you don't have heaps of it
(performance?)) b) it defines namespaces which should defined in a more global
way in appserver. ( this is the same as GNURPC stores the local copy of dynamic
objects, which is allready done by appserver )" . James said "I'm cool w/
changes to the GTrigger system that make it more usefull/flexible" . Jan said
"I think the GTrigger system is quite optimal for its actual use. even new
languages should be easy to add - but it would be great if we could split it in
two parts: a very very general one and a part which implement the Namespaces
and GObj Tree specific functions." He needed "to dig deeper into GTrigger.py."
to decide if this was sensible or not.

Later, Reinhard M?ller (reinhard) said "i saw the commit for the gcd parser -
it's your choice; we have a working gcd parser in the old geas code in c -
maybe you would want to write a python wrapper around that instead of
reimplementing it" . Derek said he still did not think gcds had a future -
"once we get to a gcd state it should be xml - and we shouldnt have much work
in parsing it - as we have a working xml parser already - which would imho be
much quicker than wrapping the old one" . Jan noted that "if you look in the
appserver/ROADMAP there is no object/relational mapper mentioned." Derek
agreed, and said "the current gcd's have almost no methods - they are mostly
properties (field definitions) - but they are laidout like objects which makes
them horrid for relational access - and why i say they are not highly useful w/
o an object/relational mapper (imho)" . Jan concurred - "i have counted ONE
method has code" . Derek said "believe me i wish more than anyone that i could
put those gcd's to use" but he felt that the changes for the new Application
Server were such to make backwards compatability impracticable.

29. Maintaining UI independance whilst allowing custom widgets

4 Jun 2002 Archive Link: "[IRC] 05 Jun 2002"

Topics: Forms

People: Marcos Dione, Michael Maluck, Jason Cater, Derek Neighbors, John Lenton
, Jan Ischebeck, James Thompson

Marcos Dione (StyXman) asked "why does the <option> tag exist?" If it was "just
a way to let some features not be implemented by some" User Interface (UI)
driver then "I think is the Wrong Way (tm)...." . Michael Maluck (madlocke)
noted that it was "only used for tooltips and version numbers" as of time of
writing. Jason Cater (jcater) said "options aren't part of the core code -
i.e., you could add your own option types and values to widgets - and access
those in triggers" . Michael said this could also be done by updating "existing
xmlElements - and if an attribute is not marked as required - drivers not
supporting it could just ignore it..." Jason said "if you are arguing that
tips, title, version, etc should be attributes and not options I will certainly
go along with that - btu if you are arguing to get rid of options altogether I
don't agree there" as "I just think it'd make sense to have these non-standard
things not cluttering up the main xml definition" .

Michael said that a form parser for a particular UI should be able "to support
everything required and interpret it in it's own way and to be able to just
ignore some things - like this it is natural that some renderers support more
than others" . Jason clarified that "the form parser does not ignore anything -
the UI drivers can ignore things if they need to" . Michael gave an example -
"you have a button with picture and text - the basic definition only allows
text" . Jason said that "in this case if we all agreed to support mixed
buttons, then an image" attribute would be added to the existing button tag,
not using the <options> tag. Michael said that adding an image attribute to the
existing button tag "does not make sense with curses" . Marcos said that the
"ncurses UIdriver should ignore the image attr" . There was no need to create a
new picture button widget unless "you don't like to touch the originals" .

Jason asked "are you saying we need to provide a way for the end-developer to
add his own elements ? or are you saying we need different xmlElements for
different UI drivers" ? He did not like this second idea, as "you end up with
different" XML Document Type Definitions (DTDs) "for each UI driver and then
you run into overlap issues" . He totally agreed that people needed to be able
to add new widgets, but "I don't like the idea of our different UI drivers
implementing their own xmlElements" . Derek Neighbors agreed - "it goes against
the goal of one xml file many UI's" .

He "would rather have a limited widget set that is almost 100% portable to all
ui's than a billion widgets where you must look at a matrix to see what widgets
will work with what ui drivers - if people want that they are better off using
glade/gtk - or qt - or MFC/visual basic" . If widgets were "highly specific to
a 'ui' - what is the point in over head of abstraction" ? However, he did not
want to force people to create a fork to be able to do what they wanted. "I
think we need to make a way to do supported/not supported - so if people want
to do wild stuff fine - but we wont support it (i.e. if someone uses it and the
developer goes by by they are on their own) - and we define what is ok for
OFFICIAL GNUe apps" .

Derek said that the decision between extending existing tags and creating new
ones would need taking on "almost a case by case basis" - for an image button,
he would prefer to add an image="" attribute to the existing <button> tag
(along with a mandatory text="" alternative for non-graphical clients).
However, "if you start say lets do a toolbar with a toolbar tag i get nervous -
as curses supporting a toolbar is a much larger stretch" . Michael said that
form designers needed to know that certain basic widgets were supported in all
UIs, with other widgets optional.

Marcos supported Jason's "point on 'no, dtd per uidriver is bad'" , as "then
you could easily get clash of entities/tags names in different UIdrivers" .
John Lenton (Chipaca) said "if you write a valid" GNUe Form Definition (.gfd)
in XML, "it should make a form with any of the drivers - even if it is missing
some gizmo if the driver doesn't support it" . Marcos said that, if each UI
used its own DTD, "how do you say a .gfd is valid? I mean, which is the .dtd
you're using?" XML documents such as a gfd should be checked "against dtd's,
not some possible broken parser" . Michael asked "if you want a strict dtd like
defined in xml spec then i ask why you are doing this xmlElements" ? Jason said
"we can generate DTDs from our xmlElements" - "people are always requesting
DTDs - so we are writing a script that will generate a DTD from xmlElements" .

Michael said he still thought the only problem with a seperate DTD for each UI
"is whene two different extensions conflict - everything else can be handled as
superset of attrs" . Marcos felt that was not exactly a small problem! He asked
"are there xml elements ouside GFPArser.py?" Jason said that the shared
GConditions and GDataSources code in GNUe Common used XML too. Marcos asked
whether there would be a single DTD that could validate any GNUe-related XML.
Jason said it was more "important to have a well-defined, common xml structure"
than a formal DTD file to validate this.

Marcos agreed that "we don't need that lot of widgets" and supported deciding
on them on a case by case basis. Jason said that, using the <option> tag,
adding an image to a button would require "<button text="foo"> <option name=
"src" value="pathtofile/file.png"/> </button> given our current parser" .
Marcos was concerned that "the option class should then be too much clever" as
it would always need to know the context of "what widget definition" it had
been invoked by.

Derek emphasised that he supported people extending GNUe, but "im concerned
with management of it" . It was an important feature of GNUe that it was UI
independant, supporting "win32, curses, gtk, html etc" . If "all of a sudden
its littered with custom widgets that work on only one or two of these ui's" ,
this could affect the overall reputation of the product. As such, he would
prefer "to only support widgets that can be expressed or be optional(on all
ui's) - no option BY UI" . "If a widget is mandatory for the application to
work its real hard to say well the widget only works on X - as that means the
application only works on X" .

Marcos said the question was "can we extend/make new widgets without hacking
gnue?" Jason said "we intend to - but you can't currently do it well without
getting into GNUe internals" as of time of writing. Jan Ischebeck (siesel) said
that, if the <options> tag was not used for this, "then there is a need for an
forms extention interface where you can add new types with ease and in an
standart way" . Marcos said he did not think many more standard widgets were
necessary - the rest could be dependant "in the sense that they could not be
rendered and the app still works" .

He added that you did not need graphics for a usable UI - even things like
dropdown combo boxes and tooltips could be done on curses terminals if
required. Jan said "A good designed text only screen can help you input stuff
much faster than all that windowZ stuff" . Marcos agreed totally, but said
"that's another discussion" . James said that "when the curses interface worked
it knew nothing about dropdowns" but "it still validated that the entry value
was in the dropdown list" . Because Forms did not use "the UI widget logic to
validate input" this "let the form fail gracefully back" . He noted that "the
curses client didn't do a menu at first" , but he felt that "if it's considered
core then it has to be in all drivers - even if the menu on curses came up on
hot key" .

Marcos concluded "core things should be rendered by all uidrivers, and
optional" widgets "are just that, optional." Extra widgets might be core or
optional - they would usually be optional, but "if you come with a super-giga
widget that does zillions of things simply, then it should be discussed if it's
core or not." He was still hopeful that his two new widgets (as discussed in
Issue #32, Section #9  (30 May 2002: Customising the main tool bar and menu bar
in Forms) ) might become 'core,' but he realised that people had not had time
to look at them in the rush for the new releases. Jason clarified "I am NOT
opposed to allowing end developers to add extensions to GNUe that are not
supported by us. (Custom controls, if you will). I think it's a BAD idea, but
I'm not opposed to it. I AM opposed to having GNUe-supported UI's (or anything
else "official") extend the base XML schema." This was why he liked the
<option> tag as a general-purpose container for any custom widgets or
attributes.

30. Project Papo's first release

4 Jun 2002 Archive Link: "[IRC] 05 Jun 2002"

People: Derek Neighbors, Marcos Dione

Derek Neighbors (dneighbo) asked "did you guys release papo?" Marcos Dione
(StyXman) said that papo, an application using the GNUe framework, was "out.
check out savannah.gnu.org/projects/papo (http://savannah.gnu.org/projects/papo
) " . Derek asked "is it something usable - i.e. do the forms work and such" ?
Marcos said "yes, the form works. it's in is phoetal stage, but works." Papo
would eventually be a full Enterprise Resource Planning system for Small to
Medium Organisations.

Later, Derek said he "did download and test drive PAPO :)" and had put a story
and screenshots on the GNU Enterprise web site. He said "its kind of cool to
see spanish forms :) - bad though that im too dumb to change my locale - so
that tool tips such would be spanish" as well.

 

 

 

 

 

 

                                Sharon And Joy
                                        

Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License version 2.0.

</html>