GNUe Traffic #32 For 8�Jun�2002

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

This Cousin covers the three main mailing lists for the GNU Enterprise project, gnue, gnue-dev and 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. For more information about the GNU Enterprise project, see their home page at http://www.gnuenterprise.org.

Todd Boyle was impressed with the "257,000 downloads" for Compiere shown on their site on Sourceforge. 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 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.

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

On IRC, 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, 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, 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.

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.

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.

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

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

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

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

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.

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

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

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

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

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.

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

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

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.

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

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.

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

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.

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

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:

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

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

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

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

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

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.

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="/GNUe/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.

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

�
Kernel Traffic Latest�\|�Archives�\|�People�\|�Topics	Wine Latest�\|�Archives�\|�People�\|�Topics	GNUe Latest�\|�Archives�\|�People�\|�Topics
Czech

1.	27�May�2002�-�29�May�2002	(22 posts)	Freedom issues with using Compiere as 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 post)	New releases
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

GNUe Traffic #32 For 8�Jun�2002

By Peter Sullivan