Ariel Calò (ariel_) asked do you want that i put the trigger stuff in the digrams for Application Server or is it a temporary hack that will eventually disappear? Jan Ischebeck (siesel) said I think that GTrigger will stay, its likely to change a bit. (like much of the rest of appserver) The only thing which is really a hack is [...] the way triggers are called, and the way methods are implemented (methods are using triggers at the moment).

Dmitry Sorokin (ra3vat) reported problems with the idea to assign trigger to first field of the form as a work-around for the lack of a trigger on opening a form, as discussed in . Arturas Kriukovas (Arturas) said i don't know why the trigger isn't fired when the form is opened - the focus is set in that field regardless of whether you get there from another tab or from form start. Dmitry tested again with all PRE POST FOCUSIN FOCUSOUT combinations, all of which were not triggering properly when the form was opened.

Further to , Derek Neighbors (dneighbo) said he was going to post the Debian packages that Jeff Bailey (jbailey) had done. He pointed Jeff to two bugs submitted on the old ones to see if you addressed in yours. Jeff said Those bugs don't apply because I don't automatically setup the database. =) - I want feedback first whether the basic setup is right before I start coding in extra stuff like that. Derek reported that setting the packages up with dpkg generated a dependancy error - Package wwwconfig-common is not installed. Andrew Mitchell (ajmitch) suggested that's why you use apt-get to install :) Jeff said he had thought of removing that dep, but I'll use it when I start putting in the automatic-virutal-host-creation stuff..

He confirmed that the Debian package did not set up the database as of time of writing - There's a whole lot of work I'll have to do with debconf to do that right. If Derek was happy with these packages as a first draft, then I'll upload it to Debian. and slowly add features and such. Derek said deb seems to work for me, get it in sid :) - we should work on it configuring the db, possibly with a separate Debian package for each supported database. Jeff said that, when he had written it, The debconf page will give you the choice of what database (with some sanity checks, like needing the libraries installed).

Some days later, further to , Nick Rusnov (nickr) asked did you ever make any progress with the pysablot author? Derek Neighbors (dneighbo_) said um yeah he said he isnt killing it and i think he takes packages and are cool with us packaging and putting in sid. Nick said he would need a version on sourceforge with a readme and a copying in order to be able to submit an official Debian package for it. Jeff Bailey (jbailey) confirmed that the Debian packages for DCL were now in the Debian sid distribution - so anything you want on it, please file wishlist bugs. That way I can keep track of it using the normal Debian Bug Tracking System.

Responding to , Jason Cater (jcater) felt that statements like dneighbo's should be qualified - i.e., "It is HIGHLY suggested that you update." --> "..if you run DCL on an untrusted network". He imagines we are one of the few ppl running a "public" dcl instance. There were similar issues around that NOLA notice last week - if you are running on an untrusted network, then the package has issues but of course the question then has to be raised, why are you running it on an untrusted network?? especially for mission-critical systems like accounting.

Further to , Jason Cater noted The cvs version of designer is undergoing some needed restructuring... if cvs is broken and you are relying on cvs designer to get your work done, then you might want to tag your gnue/designer module as the 0.3.x branch - That branch is only for bug-fixes. Andrew Mitchell (ajmitch) said he will probably still play with cvs designer, but keep an old copy around :) Jason felt that would be advisable - /me tries not to break designer when he commits - but sometimes they slip by me.

Marcos Dione (StyXman) asked do you know the status of scrollbars? there's a rumor here that they're working... James Thompson (jamest) said i added a <tag> and code to create the widget and that is all - i thought someone else worked on making them do something, but he did not really have time to discuss ideas as of time of writing. Marcos said he would hack it here, and when it's done, we'll talk about it. He asked should I implement it @ uidriver level, or @ gfobject (in fact, gfscrollbar)? Jason Cater (jcater) suggested gfscrollbar, with any wx-specific stuff in uidriver. James said there should already be a gfscrollbar file IIRC. Marcos said yes, it is, but is a litlle... uh, spartan :)

Marcos asked are events and triggers the same? I'm a little confused... James said that events == events internal to forms - button clicks, requests for next record, etc, etc whereas triggers == chunks of code that are attached to certain "trigger events" that are specified in the gfd, grd, etc files - pre-commit, pre-update, etc, etc. Marcos asked how are events handled by gfobjects? hacking the dispatchEvent function? James explained objects registers with other objects to listen to events via a registerListener functoin IIRC - trigger events are hard coded into the program. Marcos said he would need new 'events' on gfscrollbar [...] like 'scrollUp' event, which should do something.. James said there is a dictionary of events in the objects that listen for them - you can look at either GFForm or GFInstance for example. He explained you create a entry that maps an event to a specifc handler function - and that's it.

Later, Marcos asked how do I bind a function to a event? thru a eventHandler? James gave an example in the GFInstance.py code. Marcos asked whether this meant, if he wanted a GNUe Forms scrollbar (gfsb) to have events, I just write the functions that handle the events and then register them to listen to the new events? events are global? James said events are only passed to objects that request to listen to events - so not really global Marcos said yeah, but I mean 'global' in the sense that anyone can listen to certain event... or I'm misunderstandin what events are for. I what the UIsb to call the GFsb's 'event' handler... Jason interjected that the intent was so UI* doesn't have to know about GF* internals, and vice versa, but had to run before he could explain further. Marcos asked would you say that calling gfsb functions from uisb is bad? James said yes - all that should be passed via events. Marcos asked which is the difference between calling self._eventHandler and dispatchEvent? James said you wnat to use dispatchEvent 99.9% of the time - that sends the event to the objects that have registered to listen to it. Marcos noted that most of the examples use the other one... James said sigh, maybe someone changed something. However, I'm pretty sure you'd want to use dispatchEvent to send the actual events. Marcos asked ok, suppose I dispatch the event. how do I say the certain func in gfsb is listening? call to registereventlistener in gfsb's constructor?. Jason confirmed this.

Some days later, Marcos said he was still having issues with events. He was trying to put behaviour on {gf,ui}scrollbar - so, I want to make the uisb send a n event that the gfsb is listening to. James asked have you happened to look at UIButton in the wx driver? it maps a wx event to a GF event. Marcos noted that it uses self._eventHandler instead of dispatchEvent. I was told to use the latter.... James looked, and said this doesn't work like I remember it, although it appeared the confusion comes from some of this being wxpython "events" and some of this being gnue "events". He explained in the button code you've got EVT_BUTTON() which sets the function to call when the user generates a wx button click - then the next line containing the (event.eventHandler) is pushing the mouse and UI event handlers onto the wx event processing stack. We used to have every widget contain the duplicate code for this IIRC. The reason we're passing that event.eventHandler in is that those classes (mouse and UI event) dont register as event aware.

Marcos asked how do I tell that ceratin gfsb's method should be called? James said that's mapped in the GFInstance - all events are processed thru there as sort of a clearing house - so you'd setup a funciton in there that did the approprate calls to the lower level gfobjects. You'd set your uiscrollbar to process certain events like button does with EVT_BUTTON( - there it sets it up so that it's own self.buttonHandler gets called when an event button is pressed - it then uses _setDefaultEventHandlers to shove the standard event handler classes for mouse and keyboard support onto it's event processor stack. The alternative, but non-standard, way would be register the handlers directly, which will generate a GNUE Event that is picked up by GFInstance. He noted its is prefectly OK for GFInstance to just ignore the event if it determines the state of the form is such that the event should not be honored, and remarked all key presses are passed back to the form for processing prior to the UI changing - so if I enter a lowercase a and the field is set to case="upper" then the GFInstance and friends insert an uppercase A instead then tell the UI to update - it also does the focusing.

He also said you'll notice a lot of events are named requestFOO - because the UI is a slave to the GNUe Forms (GF) tree - it can make requests from the GF tree but it's not allowed to update it's own contents w/o getting events back from the GF tree - it's not allowed to change focus with events from the GF tree - it's a complete mindless slave to the GF tree humbly requesting that something be done then waiting until it's told to do something. This was so that we had a single code base that handled things like max length, input masks, uppercase conversion, etc, etc - i didn't want to see each UI implement things in their own fashion, as UI (User Interface) independance was an important goal of GNUe Forms.

Marcos asked would you say that I should 'build' a new event, like requestSCROLL?. James said oh yes, new events would probably be required - event name are hardcoded in gfinstance yes. If we allow UI plug-ins in the future we'll need some way to register them - but everything so far is pretty much std behaviour so I'm not too worried about the hard coding

Arturas Kriukovas (Arturas) reported i have found that in common/src/FormatMasks we have at least 3 files (DateMask.py, NumberMask.py, TextMask.py) that each of them defines things like monthNames, weekdayNames over and over - wouldn't it be simplier to define all them once in BaseMask.py? Jason Cater (jcater) said NumberMask and TextMask aren't even implemented - so the code you see there is a cut and paste from DateMask - and DateMask isn't even finished.

Later, Arturas noted that in common/src/dbdrivers/_dbsig/DBdriver.py - found - return value.strftime(self._dateTimeFormat). As far as i understand 'strftime' function gives date\time string formatted according to locale settings. But do i need localized SQL queries for database? I guess it shouldn't be there - he would correct it and commit into cvs if no-one disagreed. Later, Jason said self. _dateTimeFormat should be set to whatever postgresql needs - apparently, it is currently set with the "locale" mask.

Some days later, Arturas advised I have just changed common/src/dbdrivers/_dbsig/DBdriver.py file - could someone please review change - maybe you'll have some ideas how to improve source - it's a bit problematic now, but was converting dates by droping the decimals after the seconds. Jason Cater (jcater) warned you shouldn't be making postgres-specific changes in _dbsig or you'll break all the other drivers. He understood the problem, in that localised month names in queries were causing errors, I just don't agree with the solution - that was the purpose of _dateTimeFormat. If it was not working properly, it needed to be changed, not by-passed. Arturas agreed - i changed it so that now it gives fixed 'YEAR-MONTH-DAY HOUR:MINUTE:SECOND' format not the localised one. The dropping of the decimals for seconds was a slightly different issue, in that PostgreSQL holds date\time with ...,99 but it does not accept such format in queries :/ He guessed this might be better fixed elsewhere.

Daniel Baumann (chillywilly) asked the best way to specify operation parameters in a hypothetical xml markup of an object description language. Should it be <parameter name="element" mode="in" type="Object"/> or <paramater mode="in" type="Object">element</parameter>>. John Lenton (Chipaca) said he would probably have it more entity-oriented (less attributes), although both are equivalent, of course. Daniel said well I read that a general rule it to use attributes for metadata - data about the tag. He noted that forms markup seems attribute heavy - <form width="35" height="15" title="Input Validation Test"> wouldn't you want to do this like <form width="35" height="15> <title>Input Validation Test</title>....

Perry Lorier (Remosi), reading , discovers that you guys suggest the worst possible solution "mm/dd/yy" for internal representation - /me goes and finds a shotgun to preform some reeducation. He declared that the one true date format is "YYYY-MM-DD" and noted that the proposed format was not y2k compliant, it's ambigious with the european "dd/mm/yy"' John Lenton (Chipaca) said that dd/mm/yy was not so much European as non-USAean.

Two days later, Perry asked can anyone tell me why (At least in the KC) it was agreed to use "mm/dd/yy"? for internal date formats? Andrew Mitchell (ajmitch) suggested probably because of the unhealthy american influence. Perry said yyyy-mm-dd seems to be a much more logical system to use - theres even a ISO standard about it. Andrew certainly prefers it - makes sorting in a list much simpler. Perry suggested well, if american's persist to use their silly systems we'll have to buy a few plane tickets and go and beat them around the head with a large, wet, and slightly smelly trout. Derek Neighbors (dneighbo) vigorously countered um cause americans are the best - and we dont want your puking metric system or messed up concept of date formatting - you can even take your stinking celsius too. Perry goes and prepares the fish, before Derek quickly clarified btw im completely kidding - only the french would use that as a reason ;) I mean after the dateline was stolen from them, who would blame them for their ire.

Andrew Mitchell (ajmitch) asked how the Forms client written in PHP was coming along? Jan Ischebeck (siesel) said I hope to bring phpforms to a stable state soon, but there are too many small problems, and I don't have a good debugger :( - and after using python I don't like PHP anymore ;) Andrew said i'd imagine handling python triggers in php would have been fun. Jan said this is the reason for using phpforms with appserver, so triggers can be moved into appserver.

Christian Selig (sledge_) asked anyone of you familiar with xml2sql? He i just found a bug in pgsql.xsl in gnue cvs - all scripts make a match="/", pgsql.xsl has match="/schema". Jan Ischebeck (siesel) said yes, because pgsql.xsl is the only one which supports the new GNUe schema file format ( *.GSD ), as discussed in . pgsql.xsl is the only one which can create insert statemenets out of the <data> part of an .GSD. Christian asked is gsd already defined / is there doc? Jan said there is DTD in designer/src/schema - and you can create it with designer. Jan explained that the new format included support for constrains = NOT NULL, UNIQUE, ... a foreign key is an constrain too.

Perry Lorier (Remosi) reprised his amazing .so->idl idea, as previously discussed in . You know how nm can tell you all the symbols in a .so (or .o for that matter) right? and how "stabs" can tell you the type of a symbol if it was compiled with -g, or, alternatively, c++filt will tell you if it was compiled using gcc, right? :) Daniel Baumann (chillywilly) said he had never used that before - he asked is c++filt apt-gettable? Perry said it's in binutils. givin that type information you should be able to write an idl file (for gnurpc for instance). He recognised that you need to of course figure out which symbols are actually defined in the .so/.a/.o that you're linking - but it could be a really easy way to automatically load, say, openssl into python. You could take the openssl.so file generate some idl for it, then use gnurpc to use openssl as if it was a python module without having to spend ages defining all the normal glue logic. If you did it right python could catch the import function and do all of that automatically - so you could have a .so (eg openssl.so) and then just go "import openssl" in python and have it do all the work for you ;). Andrew Mitchell (ajmitch) felt this also may open up licensing holes :) Perry agreed - but so does allowing multiple .c files in a gcc invocation :).

The next day Perry said he had been experimenting with my idea. It needs some hand hacking at the moment - and I'm only doing c<->c and no RPC inbetween - but proof-of-concept is functional :).

Jan Ischebeck (siesel) asked about the differences between german and american accounting. Reinhard Müller (reinhard) said he did not know - from what i understand american accounting serves a different purpose - read: austrian/german accounting is done mainly to satisfy the tax authority and to calculate the taxes to pay, whereas us american accounting seems to me to replace what we have in german "controlling" or "kostenrechnung" as well i.e. it serves as a source of information for the management and/or the investors. Jan Ischebeck (siesel) asked if that meant american accounting is just a kind of GuV ? GuV = Gewinn & Verlust Rechnung ( don't know the english equivalence). "Profit and Loss calculation," as far as I can tell. Reinhard said i would believe us accounting does _more_ than german accounting - sometimes i also get the feeling that us accounting doesn't have the strict concept of systematic account numbers. Jan said hmmm, I thought german accounting would allready be kind of too much (especial for lasy students who have to understand it ;) ). Reinhard said that US accounting seemed to be more detailed (at least that is my understanding) - they do "kostenstellen" and "kostenarten" and "kostenträger" etc. all in accounting Cost accounting and/or management accounting? as far as I can tell - although i could misunderstand that.

Perry Lorier (Remosi) reported seeing the security problems in DCL, as previously discussed in , mentioned at bugtraq. Derek Neighbors (dneighbo) said in some ways dcl isnt even on real 'version' numbers so releasing it to bugtraq seems kind of odd - but there are people using it in production so its understandable i guess. He had found bugtraq really great to work with - provided samples of how to exploit - and gave us a month before releasing publicly so we could fix. Perry felt that php is a b'stard of a thing to get secure. Derek said it was a catch 22 - i wanted to notify all dcl users immediately BUT to do so 'overly' publicly would be remiss as no patch was available. Perry agreed - you have to patch the hole first :) - and by the email it sounds like that there were serveral :) Derek said well i did say in commit list and irc we were closing security holes - i just didnt specifically say what they were until i had committed the fix for each one. Then bundled when all were done and did full blow release to freshmeat, all announce lists and such and ulf gave us like a week after release to let the users patch - which i think was fair.

Federico Heinz (perlhead) asked Any pointer on where forms gets its fonts? He found the font is hideously large. And the encoding is not ISO-8859-1, which sucks too. He noted that the gnue.conf had a setting to choose monospaced or proportional fonts, but the comment in the file stated # Normally, default font style and size is used, according to the active theme - But it doesn't mention which "theme" we're talking about. It sure doesn't use my gtk theme's settings... Jason Cater (jcater) said you probably wanna change pointSize=10 (or so) in your gnue.conf - somehow the default was increased and got passed us the last release. Federico pointed out that gnue.conf says pointSize is for fixed with only... Jason said he didn't know forms worked properly w/o fixed width fonts - I haven't tested it that way. Federico reported It worked for the size. He felt The comments in gnue.conf are misleading as they gave the impression that the default is fixedWidthFont=0. Jason agreed and said /me will change that.

On the encoding, Federico reported that the form I'm executing begins with "<?xml version="1.0" encoding="ISO-8859-1"?>" but I get ciryllic characters instead of accented ones. He suspected it's because forms is picking a font with the wrong encoding... but I can't find out which. He went off to check.

Two days later, Federico reported by fiddling in the forms source, I fixed my encoding problem! He had added ISO-8859-1 as an option to the widget.SetFont parameters - It seems the problem is that wx (or the python wx bindings, or *something*) does not get the encoding right unless you force it. Arturas Kriukovas (Arturas) confirmed about a 3 days ago this was fixed in CVS - was added option in gnue.conf. Marcos Dione (StyXman) confirmed that Project papo was currently using its own forked CVS - I'll tell our cvsmaster to sync if he finds it suitable... The reason for the fork was we are hacking some things we need into gnue, but we can't send patches yet because we hadn't give the copyright to gnu yet. So, we 'forked' till we cand send our 'improvements' to the gnue's guys. Federico wondered whether there was a need for a further gnue.conf option - The configuration file site.py has an "encoding" option, which would work pretty well for this.. Arturas pointed out that this encoding option is for database, not the Forms client display.

Ariel Calò (ariel_) asked who is maintaining gnuedtd?. Jason Cater (jcater) said me, sort of, adding patches are welcome. Ariel reported several bugs - 1) the nice boxes around the comments are not recognized by nsglms ( and other parsers i think) - 2) an entity that must be further referenced must be defined as <!ENTITY % foo "bar"> and not <!ENTITY foo "bar"> - 3) %true and %false are declared AFTER %boolean. Jason said he was wondering about #2 - as the sample dtd's I was learning from didn't have them - but other ones I saw later did have them. He committed some fixes. Ariel said that the first problem was not only affecting emacs but also sabcmd - when i run sabcmd with pgsql.xsl to get a .sql batch file it complaints about nested comments. He confirmed that changhing all the minuses with pluses will work.. He felt that compatability with emacs' XML mode was important, since until we have a working designer for schemas the best way to write xml documents is using emacs. and if you want from emacs all the nice features like inserting the elements semi-automatically you have to specify the DOCTYPE (i.e the dtd) in the xml (or gsd,gfd...) file.

Derek Neighbors (dneighbo) asked anyone here have manufacturing experience? He was seeing manufacturers that distribute/wholesale/retail as being an 'odd' animal - but one that is more and more common with mom and pops and the internet - ToyMan: is an example of that :) What im seeing packages lacking is they can do one or the other but not both - i.e. you can get ok cheaper manufacturing packages but they dont do any retail or more importanting shipping stuff - or you can get a quickbooks/peachtree for cheap that does retail ok but wont let you manage the manufacturing side. I see the 'inventory problem' and the 'shipping problem' as the two areas where gnue can kick arse fast. Stuart Quimby (ToyMan) agreed - something that hooked into my ecomm package and played nice would be excellent.

Derek asked What im wondering is should inventory be separate tables for manufacturing and distribution - i.e. have inventory tables for the the 'components' you use to manufacture and inventory tables for the 'products' you sell or distribute. Stuart did not see the need for that - inv is inv. Derek said this matched the quick talks i have had with others, but for me im seeing some disconnect - im thinking you have inventory that use to 'build' - then you have an 'allocation' table that says you need xyz components to make product A. Stuart said he used a Bill of Materials (BOM) table for that - very simple structure - highly self referential. He noted *any* package that has a bom will do that - it's just implemented badly, usually. Derek said i think i might see the light as to it being all one structure - its just a matter of the 'allocation' table - that says what things in inventory are needed to make product A. Things could get more complicated if manufactured products were then used as the basis for other manufactured products. Stuart said that his own database handled this - it's *very* simple structure with just 3 fields, Assmemb, Part, Qty but you can handle *any* situation with that - an Assemb. can also be a Part - so that way you build up sub-assem.

Derek Neighbors (dneighbo) said that if you are doing gnue in a print shop you might want to look at NOLA (or our current branch that is getting moded for re-entry) - as NOLA was designed for printshop accounting - although in fact their changes would likely make it less print-shop orientated and more generic. He felt accoutning is easy - its a debit or a credit - right or left column - and it should net to zero - nice and easy - unless you are enron. Daniel Baumann (chillywilly) felt accouting is boooooring Andrew Mitchell (ajmitch) felt enron had some creativity.