Dmitry Sorokin said that The very next thing for those of us living in non-ascii part of the world after we successfully downloaded, installed GNUe Forms is trying to customize example forms to our native language.. He reported the exception he had got trying to do this, but noted Just setting encoding="koi8-r" to xml header I've got it running back again. He asked Can anyone from non-ascii part of the world change that form.gfd to your native langiage, test it on your system and send it to me in any cases? Please provide encoding which it in. Jason Cater suggested getting an i18n sample directory in CVS. We should try to gather as many forms like this as possible so the developers can have a test suite of forms.

Some days later, on IRC, Dmitry (ra3vat) said that fixing the problems required minor changes in site.py. James Thompson (jamest) asked isn't site.py a python installed config file? - is there a way to do this from within our app?. Dmitry said i think it is - but not one step action. Alternatively, it might help to have that setting in binary snapshot - and some readme for others distribution. Derek Neighbors (dneighbo_) suggested i think the question would be can we make linux binaries as well that include our own version of python etc - but thats a whole other topic. James wasn't keen - i'd hope we can implement a solution in GClientApp.py for the i18n problems. Derek said my desire to have COMPLETE binaries on all platforms has nothign to do with i18n - rather i see it much easier to support shipping a disk that is completely self contained, the way that other GNU/Linux-based applications did it. James said i think this ties into the need for a gnue-setup which he had previously discussed with Jason Cater.

The next day, Arturas asked for James' advice on the problems with no i18n data on forms. He explained we have a label in form with i18n characters and instead of those characters something like A[] appears on screen. Based on testing so far, i18n are handled correctly inside python, but when they come up to the wx-forms something goes wrong. James said this sounds very familure - someone from india a while back patched forms to work with some type of i18n stuff - said something about requiring a special gtk. Arturas said that Dmitry had forwarded him that e-mail, but i found nothing about special gtk module there (i might have missed something). Dmitry confirmed i do not know (understand) what's wrong with current gtk - and there was no details on that in Aditya's message.

James asked has this been tested on win32 yet? Dmitry said it worked for me with one-byte encoding, seems it is very depend on different settings - like locale, fonts ... He had started to reinstall gnue under w32 to test again. Later, he confirmed got the same behaviour under w32 - title and tips work, labels don't. He confirmed that GNUe in Microsoft Windows used wxPython as well. Arturas felt this supported the idea that there is problem in wx.

Later, Bajusz Tamás (btami) confirmed he was seeing the same problem - they are OK for me in labels but not in messages in gnue.conf.

The next day, Arturas suggested i have one idea about i18n (internationalization) - why i doesn't work in forms. Since UTF-8 is unicode variable-width encoding, some characters (the normal ASCII range) would be one-byte and others two-byte. If you used a non-ASCII single-byte character set such as Cyrillic, it worked. He guessed that Aditya has not made support for UTF-8 but only support for his local one-byte width fonts. Dmitry wasn't sure - he did much more then me - with one-byte encoding there are not much problem - just setting everithing up properly. Arturas thought that his fonts had to be one-byte width as he had had the same problems as we if his fonts were real unicode but he asn't sure. Dmitry thought forms works properly with utf or unicode strings right now - we should look closely on wxpython and system level. Arturas said that some documentation on the wxWindows website stated 'unicode is not yet fully supported' :(. Dmitry wondered if there is differences between linux and w32. Arturas didn't think so, but Dmitry noted the reference was to wxpython problem that encoding=wxFONTENCODING_UTF8 is not supported yet under linux - that's why i'm trying to test it under w32.

Later, Arturas confirmed he was trying i18n on Microsoft Windows as well - downloading python for win32 now - half an hour left :\ James sympathised - modems suck. Arturas said he was actually on university lan :) :) - (maybe all my university is on modem? ;). Calum Morrell (drochaid) thought that would certainly explain the speed problem :).

Derek Neighbors announced We started using GNUe DCL for internal project management of the GNUe project a few months back. Since the merger of our projects we have jumped full swing and have instituted the email gateway for support requests. Which means end users of GNUe can now easily submit bug reports and/or feature requests via email!

He added As we start using the system more religiously as developers we be able to do our project timelines and roadmaps within GNUe DCL and paint a better picture for those monitoring the project. I am going to try to commit to giving some sort of update via news story at least once a month as well to supplement the weekly Kernel Cousins.

Some days later, on IRC, Harald Meyer (Harald1) asked am I right, that gnue depends on python > 2.1? If yes should I report code whose only purpose was python 1.5.2 compatibility as a bug? Derek Neighbors (dneighbo_) asked Harald to report it via the new DCL-email gateway, unless there was an attatchment to go with it, because dcl gateway appears to be eating attachments as of time of writing.

Bajusz Tamás (btami) made my first work order in DCL - responsible:jcater :) Jason Cater (jcater) sighed I'm starting to not like dcl - ppl expecting me to work :). Seriously, he did have concerns about people submitting bugs against cvs head - as that's a given :). Daniel Baumann (chillywilly) suggested that a bug tracking system should be more than just users reporting bugs, I think it should be more like a TODO type thing for developers too ;) Later, Derek (dneighbo) noted that the Free Software Foundation, who were starting to use DCL internally, had requested the addition of 'nagware' :) - i.e. you can set a 'date' on a ticket and have it notify you if the date passes. The discussion as to whether this was a good idea or not degenerated rapidly.

Christian Selig reported Setup from CVS (checkout five minutes ago) works well, except for some bugs he posted, including ImportError: No module named mx.DateTime. He said I "fixed" the problem by commenting out the import line *g*, but then a simple test form would not work. Harald Meyer suggested Maybe you just need to install it from http://www.lemburg.com/file/python/mxDateTime.html. Derek Neighbors confirmed this. Harald also suggested You should use Python 2.1.x and not 2.2, as it has some bugs, which let designer crash.

Christian Selig (lupo_) asked is it possible that gnue<->mysql interaction sucks a bit, or is it me? Reinhard Müller (reinhard said well most of us use postgres but it _should_ work. Christian pasted his error messages, and proposed some fixes, but he rerun it and there is still a problem. James Thompson (jamest) explained what was happening. Christian said okay, gforms now complains about a missing key msg_first when calling gconfig.get('msg_first'). James said he wasn't getting that problem. Reinhard pasted a part of derek's commit from last night. He wondered if anonymous CVS access was a bit behind - i think it gets synced nightly (U.S. night that is). James said nope, it's instantaneous - pulls from the same tree, I use anoncvs for gnue installs other than my own :) He explained that the code used fetchmany(0) rather than fetchmany() because we use the cursor arraysize attribute later in the code which is supposed to be used if size isn't specified - it defaults to 5 - so by setting that to 0 for everyone it seems it'd seem to disable our prefetching system. He said that fwiw - the mysql db driver may be perfectly fine - what we've noticed is that the driver authors all read the spec differently.

Christian said i have "fixed" the problem for now by changing the mysqldb driver - gnue forms now starts and after "execute query", the first five entries are displayed correctly - the sixth one is empty and no further browsing is possible :-(. James suggested a quick workarround that sucks - on your <datasoure> tags add a cache=####### (some number bigger than the records in your db :). Christian thought okay, that sucks too much :). Alternatively, James suggested replace fetchmany with fetchall() IIRC that should work - we had to do that in pygresql driver . Christian said this bears similar problems. James said he wasn't a mysql user - so I can't really test this out. Christian said he would try to squash them when i have some time.

Derek Neighbors (derek) had added first and last record calls and corresponding menu options, initially for use with DCL. He still need to add buttons to the toolbar for them - and bind the keystrokes - but via menu they work. James Thompson (jamest) reminded Derek but you did know that jump to record exists right? Derek agreed, but said his additions were useful where i do not know exact record i want. He pointed out that there was a potential problem with the jump to record, in that it traps for if you exceed bound of lastRecord - BUT some of our DBdrivers dont support lastRecord, most notably ODBC. James said my users want a find function - so that they can scan the records in memory for a string of text in any field. Derek said he had been looking at something similar.

Later, Derek asked how he could map compound keystrokes in forms for his new navigation functions. He wanted to make last record ctrl+down and first record ctrl+up - but i soon found sawfish uses those - so i changed to shift+down & shift+up. Jason Cater (jcater) suggested Ctrl+Home or Ctrl-End. Derek said he wasn't too fussed, but we have screwed concept of blocks :) so pgup/pgdn are used (imho) in correctly which was one reason i had to do a first/last. He also asked say i make a 'grid' by doing rows="10" - and i load 100 records into that grid - the gripe is you have use arrows to navigate - instead of being able to do pg dn/up - to jump like 10 records at a time - i realize we have a 'jump' and now a first and last - but how are your users responding to this? - or is there another key that will do this kind of navigation? - or will this navigation come with the 'scrollbar'? Jason said he was planning to do row jumping - just not a high priority. He defended our block concept. Derek said he still wasn't convinced as to their usefulness :)

Howard Shaw (grum) asked about the status of GNUe forms for HTML/CSS. Derek Neighbors (dneighbo) said there were 2 different implementations being built concurrently - neither implementation in cvs or being done by core team - one is a new forms client written in php but using gnue common via xml-rpc (iirc) - it seems to work fairly well but havent seen jens for over a week so dont knwo if it will re surface - other implementation is in webware/python server pages and basically is just a 'ui driver' for existing forms implementation - havent seen madlocke for month or more so that avenue could be dead. Howard asked have you ever looked at ERW (Entities and Relationships on the Web)? It was hosted on GNU's equiv of SourceForge, but I don't think it is a GNU proj. He had thought of it when I read the comments in the last kernel cousin about GNUe becoming an Access replacement.. Derek said we dont AIM to be an access replacement - more the comment is right now we are a suitable access replacement with REAL databases.

Howard felt GNUe was selling itself short by not having samples readily accessible on the website. Derek agreed - we are too heads down in the framework and are losing people - because we dont have applications - if we had applications (even one moderately sophisticated one) - so people could see the 'power' of the framework - i think many more folks would be using gnue.

Howard Shaw (grum) asked does any part of GNUe currently handle DB creation? I.e. the actual design and installation of tables?. Derek said that we have a generic XML formate - that will then create a script for about any db - the idea was we would make it so you could do table def in DIA - run a style sheet to convert it to our xml db format - and run a style sheet to make the create script - at SOME point we will have all a tool do this. Howard said he had uncovered a java app that takes an XML doc describing a set of Entity/Relationships and generates SQL to create the tables. Derek said that woudl be a fairly trivial task for gnue but wasn't a priority as they lack resources. Howard said he was thinking about taking this guy's java app and rewriting in Python to give a basis for porting to GNUe. Derek said the reason he thought this would be fairly trivial was its all xml transformation - so if i make something in DIA, DIA makes xml - i simply author an XSLT style sheet to convert from DIA to the XML table schema standard of gnue - and gnue alread has a set of XSLT style sheets to convert form our table schema standard to dbs like mysql, oracle, postgres, etc etc etc - so really the only 'task' is to write style sheet to go from DIA XML to GNUe Table Schema XML. He recognised that getting it to point where its a nice gui tool - and not using files but rather streams etc etc - is a much more laborous venture - but at gnue we like to start small that gets a good return on effort and build up. A good palce to start would be with straight up table definitions in DIA as they are less 'complex' and still get a good 'bang' for the buck - as if i can basically 'document' my schema in dia - i now have a way to generate the actual db w/o doing additional work.

Daniel Baumann (chillywilly) said he was working on a geas proposal. Jason Cater (jcater) wondered what the definition files will look like. Daniel gave some sample class definitions, written in Object Definition Languague (ODL). Jason said he thought they should be in XML, as:

He added I'm game for whatever - but just an observation that we already have an infrastructure for xml. Reinhard Müller (reinhard) said basically my plans are that [...] the appserver will take the object definition from the database and will not mind how they got into the database. People could write filters to get object definitions from their own preferred format to the object database. Derek Neighbors (dneighbo) said i think if we dont do xml on the class defs we will pay fo rit - and this is a change from my original stance. Reinhard said eventually we will have a business object designer where i can model my objects visually at which point the object definition file format would be less important. Derek hoped this would be sooner rather than later - as we can use existing designeer :). People could always just edit the xml file or whatever the definition is in that way too using their favourite text editor, whether emacs or vi.

Daniel just whipped up a quick diagram. Looking at it, he concluded xml would be asier to parse... [...] ok, jcater you just may indeed get your xml definitions ;). He said we just need designer to let us design business objects then ;) Jason confirmed that Designer was meant to be all purpose - it's modularized :) Daniel suggested I think odl vs. xml is a debate for another time as those are implementation issues that can be worked out after the apis are defined - but I think I like xml too - I'm torn. Derek said one of the reasons we keep saying XML is designer is good at reading/writing XML :) - so with a lot LESS work - we can have an visual appserver tool.

The next day, Daniel and Reinhard discussed Daniel's diagram further. Daniel explained that Object Definition Languague would be the equivalent of GNUe Class Definitions (.gcd), and the ODL compiler would be the equivalent of the GCD parser. The arrows on the diagram represented flow of direction. The odl compiler creates code stubs (generation) - I figured why not since we are using a dynamicaly typed langauge and we could have the methods then hook into the methods adapter. Reinhard warned not sure if i am a friend of self modifying code. Daniel pointed out that everytime you change the idl interfaces in current geas the idl-compiler modifies the stubs ;) Reinhard agreed, but not at runtime - in normal use the interface doesn't get changed. He said i can imagine it could be hell to debug such a thing - not sure if it's easy to debug code that doesn't even exist as a source file.

Daniel emphasised we can just have tools that use the api too and go backwards to odl descriptions, in fact we can go either way - that was the point of the diagram - say you used a tool that add a Class class - then it could generate an odl and that can be preprocessed into python code stubs. Reinhard suggested those python stubs would be class definitions for the business objects, and said i think i like that :).

Reinhard was not too hot about odl. Daniel said it's very similar to current gcds - has 'relationships' to maintain referntial intergrity - like if one object has a relationship to another and then object goes away you can clean it up so it doesn;t refer to it anymore - it's just idl witha few extras. Reinhard said that it should not need a programmer to define objects [...] we have to think in user space. Daniel asked ok, but how do you envision us bridgin the gap? odl is just our internal object description format (or could be) - we need tools to make describing business processes easy right - and then from that meta info we generate code and methods? He said you would need to map business concepts to object concepts right? for code generation - now, can we do this in layers? like deal with an appserver that uses object descriptions etc, then abstract that up to a business process mapping? or would it be better to include a busines process thing at the core somwhere?. Reinhard said he did not see much difference between a business object and a "normal" object. Daniel asked do we use odl and then have a business process mapping to objects or do we use some format already that incorporates business process stuff?

Reinhard said that a business process would be something like - first a order is entered, then it must be printed out - then the boss must check it - then it is faxed to the supplier etc. - this is what derek calls "workflow" and i don't think this should be _in_ the appserver Daniel agreed but it could be an easy way for people to 'design' thier business software instead of writing gcds [...] say if it was gra[hical and we had more 'concepts' and components - a sorta 'dummy' layer for them to customize GNUe. Reinhard commented i would say that navigator will do such a thing - like listing the actions in the logical order - like you have a menu where you see all actions in the order they have to happen. Daniel said I thought right now all it did was make menus. Reinhard agreed, but said geas will provide business objects - and workflow is the way how these objects are _used_ - but doesn't have impact on their definitions.

Daniel asked how does the business guy designa GNUe pacakeg then? ;) - wouldn't that visual designer somehow eventually create the object definitions to carry out theri design? and maybe even generate method code if it was generic enough?. Reinhard suggested the visual designer _will_ create the object definition - it will probably not create method code however. Daniel suggested well stubs at least. Reinhard agreed - it is a software to software information transfer - not a human to software information transfer - and for software to software transfers XML is the best method. Daniel suggested well you could markup odl in an xml format - just like you could for any format - to make the xml gods happy ;) - or should that be 'gurus'? He noted that OIF is a data exchange format for the objects - and someone was nice and made an xml markup of that and you can download it off the odmg site. He suggested so mayeb having that be xml would appease everyone. However, that really doesn't define the 'schema' of the object(s) though as ODL (GCD) does.

Jason Cater (jcater) said that Forms and Designer were coded in python. GNUe Application Server (GEAS) had originally been written in C, but it is being rewritten in python - we have an extensive common library for python - that all the other tools already used - that was already far ahead of geas - so it made sense to reuse a lot of this. Some doubts were expressed whether python would be fast enough for an Application Server. Jason said the beauty of python is its integration with c - it's trivial to prototype an app in python and get it going quickly and find the pieces that are slow and recode those in C - of course, we've yet to have to do that for any of the other tools - so we're pleased w/python - but the main benefits are speed of deployment and ease of maintenance He added incidentally, from experience, I don't buy the "it needs to be in C or C++", myself - I do understand where that comes from - esp. when people try to do such servers in java and they churn along slowly. Later, Derek Neighbors (derek) added python is like delphi/powerbuilder done properly w/o an ide - i.e. it isnt as strongly typed (as pascal) but implements lists and dictionaries as data types and is highly object friendly - i.e. python the language is better than pascal the language - but as a visual tool delphi wins as it has a much better visual component model in the VCL - but it isnt really xplatform like python. On the issue of using python for GEAS instead of C, i will start by saying 95% of the appserver market today is contained in java based appservers - i believe in many areas python is faster than java or equal to - so if java is up to the task i see no reason to believe python is not. He said because a vendor says C++ is only way to do appserver i dont believe it, adding i have long ago learned that using a 'faster' tool doesnt always make for a 'faster' product - example our old appserver was in C - yet our python common libraries were beating it in performance. He liked python's error handling - it is a 'safe' language much as java was supposed to be. He thought python was the right choice for the new GEAS as a. its being done in a distributed development environment (so readability and maintainibity) are HIGH priority for productivity and b. most businesses will sacrifice speed in favor of having a maintainable system that is stable. If some parts needed to run quicker, since we are highly modular - we can port modules to C to get performance.

Derek Neighbors (derek) posted a list of the 24 available triggers in GNUe Forms, classified as Entry, CurrentEntry (all commented out currently), Block, Page and Form. He asked what happened to the one time functioning On-New-Record trigger?

The next day, Derek said i meant to bug you about on new record trigger support which used to exist *iirc* and now it doesnt. He was trying to set up a database where records stored modified on , modified by. He wanted to use pre-commit post-commit triggers at 'form' level iirc but i dont know how i would change the records that had been 'updated'. Jason Cater (jcater) said for your contact manager, we used pre-commit irrc [...] which isn't a good solution, but it is a solution. This was for the primary key sequence. He said he would write the code for the datasource-level triggers next week if you need it - shouldn't be hard now that jamest has the common-based trigger system. Daniel Baumann (chillywilly) asked is that common based trigger system supposed to support multiple languages?. Jason confirmed this - the common trigger system defines namespaces - which is a small step from language-independence, although we haven't experimented with other languages other than python as at time of writing. Daniel said he was interested because we have this thing we called GEMA - GNUe Methods Adapter which was in the proposals for the new GNUe Application Server (GEAS) - it's the multi-langauge methods thing. He wondered if GEAS could use this part of GNUe Common as well.

Some days later, Jason warned we've changed the block-level triggers a little bit on you - so beware. He explained <pre-commit> no longer gets called "for each block" but gets called "for each pending record" plus you have <pre-insert>, <pre-delete> and <pre-update> which all get called for records that were inserted, deleted, and modified (but not inserted or deleted). James said autofill will break though - but it's fixable. Jason warned note that <pre-commit> will get called even if the other 3 get called.

Derek Neighbors (derek) said that jbailey is making debs for most recent dcl and is the new 'debian maintainer' (i.e. has authority to upload the packages). However, now that Andrew Mitchell (ajmitch) was back, im sure he would LOVE some one to really 'maintain' the packages - and then he can act as the 'uploader'. He said we just needed emergency debians - as its a requirement somewhere. Andrew said i'll talk to jbailey when i see him next, i'll see what he thinks :). Derek said actually if you were willing to do it, it would surely get you debian maintainership i.e. im sure he would sponsor you - and you would just need to get your keys signed. Andrew said that was already in hand. Derek said that Jeff Bailey had only 'adopted' dcl as its old maintainer 'abandoned it'.

Daniel Baumann (chillywilly) asked are you happy that we will have a GOAT modules in GEAS ;)? - GNUe Object Access Translator, disclaiming hey, it wasn't my idea) - it's in the architecture guide reinhard did. He added and I guess it is now tie for return of the GEDI. Jason Cater (jcater) suggested we should call the reporting engine NIAGRA - that's a cool recursive name - Niagra Is A Great Recursive Acronym. David McWherter (dtm) suggested yeah well just ocme up with acronyms -- we'll figure out their meaning and what to implement behind them, later.

Later, Andrew Mitchell (ajmitch) returned, claiming he had heard you were doing GEAS in python so i decided to come back & hack some ;). Reinhard Müller (reinhard) said that although i'm supposed to lead the development he was buried in real work :(. Andrew said he would read up some of the proposals so he could comment.

Later, Daniel confirmed we are rewriting in python and integrating with common ;) He felt they really need to document common better though - as I read the code and I immediately get lost in the details ;). He had been looking at the triggers stuff and GObject. He thought the triggers look very formsish though and wondered how this would fit with GNUe Application Server (GEAS). He had I thought the 'methods' or 'trigger' system was going to be more of a generic object thing that could be shared.

He had also thought GObject might also fit the ODMG Object Model by adding that api to it - the 'Object' api. He liked Gnome's concept of GObject and i see no reason why we shouldn't have something similar. Andrew suuggested a GNUeObject?. He said neilt's pic for GEAs makes stuff a bit simpler to understand - so everything will basically be a python object? :) - you want them to all derive from the mighty GNUeObject, so that they all have common methods, attributes?. Daniel thought that would be cool. Andrew felt it's a logical way to do things, in my limited experience :), adding for each .gcd defined object, they implicitly derive from the base GNUeObject. Daniel said this linked to his ideas on ODMG, because odmg calls for one that implements certain metods for persistence, and they use one for an object that cna be described using xml.

Andrew said that we're in agreement then over GObject/GNUeObject, and the next step was we'd need to agree on what common methods/attributes each child inherits. Daniel said he was thinking that the 'Object' inteface in odmg would be implemented by the current GNUeObject/GObject that lives in GObjects.py This could support not only ODMG stuff, but also all common things that are base to our object system, imho. Andrew said this would make it easy for people writing business objects, give them a nice base to work with :).

He thought the object repository will be interesting to build. Daniel said I see that as a ODL or ODL markup langauge repository which could be used in several ways, similar to smalltalk binding. He would explain more later. Andrew asked what holds the state of each object instance? the database?. Daniel said ODL also does 'state' of an object rather than just 'interface' - tha database will have the 'state'; of source. Andrew noted that the state is basically just the attribute values anyway :). Daniel suggested you could do lazy loading via a proxy - use a reference and only hit the db for the object state if it is used - lieka smart pointer in c++.

Andrew clarified so objects & methods are still quite separate? Daniel agreed, but suggested we should have a methods adapter or 'server' even. That way you could get the meta objects - process the odls - go in any direction - get the python stubs. Andrew asked about multi-threading, warning python doesn't scale wonderfully when doing MT, from what i hear Daniel said there were several ways of doing this: one thread per transaction, one thread doing database operations, under one transaction, multiple threads each with their own separate transaction and so on. However, programmers must not pass objects from one thread to another running under a different transaction - multiple threads sharing one or more transactions is difficult and requires the client to do concurrency control. He noted that the 'Object' interface also support locking and concurrency according to the code.

He also liked the metadata interface - and the Database interface support a schema() operations which wil allow you to traverse the metaobject graph of the 'object repository' - every object will have a class and a metaobject describing the object - so you get your intropection. He also thought the Database and Transaction interfaces are very cool - they are the last 2 in odmg.txt He liked the idea of using ODMG, as I just didn't want to bother designing my own interfaces when there's something out there already ;).

Daniel concluded see I have a bunch of ides to organize ;) - then we can get down to bidness ;). Andrew said he was ready to help out. Daniel said mayeb after i geta rough draft out someone can catch on and help me organize - that someone being you ;).

The next day, Daniel asked why do triggers look so form-like? - wouldn't it be nice to have a common object model that was ui independent? James Thompson said it's not ui dependent - any object in a gfobj tree can expose itself to triggernamespace. Daniel pointed out that it uses the 'events' that the forms like, such as pre-focus....blah, saying that's a ui widget thing is it not?. Derek Neighbors (derek) said that because you can specify something that uses ui doesnt mean its ui dependent. James said those are forms triggers [...] triggers don't have to be tied to forms.

Daniel said that what he was talking about was a common object model and asked you do agree there can be some refactoring? He added that he would like to add this interface toe GObject to support persistence. James said i don't think we'll need refactoring so I guess I can agree to it - as i think we're flexible now - triggers are implemented in common and are applicatoin independent - so they'll work in reports with NO UI :)

Derek said that until common is either fully documented Daniel would probbaly have to look at the source code to answer many of these questions - i think you have some darned good ideas - but talking in abstract is not very fruitful right now :) Daniel said I have loked at code, which was how many of these issues had come up. Derek suggested what would really really really really help is if you could take the code and walk through it doing some sort of doc based on it - i think it would get you to point where your common questions are answered and we have a common ground to discuss geas on. James said I'm starting that this week - as reinhard requested it but this is first time I've had the chance. Derek felt it was better to focus James and Jason Cater on other needs :) Daniel said documenting is too crucial at this stage especially if we are to intergrate things, however I would settle for more jcater and jamest channel occupancy to answer questions ;) - even a 'meeting' or two.

Daniel uploaded some documentation for his ideas to help in object identity (as every object would get an id in geas) and for concurrency control (multiple people access business objects). James said that python handled much of this internally. Daniel said we still need a locking mechanism of our own to avoid phantom reads and similar problems. His proposed locking model is consistent with OMG's concurrency service model althought we can do more sophisticated locking than their 'pessmistic' locking model - basicaly we want the system to remain consistent and users to have isolation until someone commits the transaction. James said he would have to think about this some - as it may graft in ok to our datasource model but he would need to give it some thought.

Harald Meyer suggested users should be able to customize the forms to select which fields are visible and in which order. I understand that this is already possible with gnue using the designer, but I don't think this is a good way, because the user sees too much and maybe changes something which he/she doesn't understand. He had tried to implement a trigger-based solution and failed, using several different approaches. James Thompson said Access to various properties is a relatively new feature of triggers. The UI has not yet been restructured to take advantage of it :( When that happens then what you reqest should be possible via triggers. Other planned features for GNUe Forms included:

Christian Selig (sledge_) said i've tried out the simple wizard which does it's job perfectly well - but i don't underschtand the master/detail wizard. James Thompson (jamest) explained master/detail relationships are primary/foreign key setups - you choose a table that is the master - then link other tables to it via a matching field. He explained master/detail is old oracle terminology that jcater and I are both used to using. He remembered one thing I still need to add to that wizard is page support. He explained pages are just like pages of a book - you can have a form that is several pages long.

Christian asked why aren't the position (x,y,w,h) attributes in the properties window? James explained the x, y, width, height properties are in the properties window - they are also at the bottom of the screen - you may have to scroll down a bit to see them. There was a known bug that sometimes you can't edit the properties on a window with a scrollbar - if you increase the size of the property window to get rid of the scroll bar then it will work - major PITA i know.

Christian also asked is it possible to create a form which only gives a "basic info" on a data set, and on clicking a button, opens a more complete view? James replied right now, no - it's easy to create the two forms and have a button launch the more detailed form - however we don't have a system for seeding the detail form with query values - it would be a very nice feature though

James asked dneighbo_: did you start a tutorial on desginer/forms? Derek Neighbors (dneighbo_) said i had a 'tutorial' started in the form of an 'article' for linuxjournal - i think it might be in cvs - i want to finish it as an article (intro) - but we really need a raw tutorial as well.

Derek Neighbors (deke) said that it appears that the paths in the gpd are relative to where gncvs runs? not where the .gpd lives?. James Thompson (jamest) said IIRC you can set that in gnue.conf. Derek said the problem there is its still relative i think - but more so if you have lots of different gnue apps by different developers - you wouldnt want this to be the same. He confirmed that if you used an absolute path in gnue.conf, it was just appended: No such file or directory: '/home/dneighbo/gnue//home/dneighbo/cvs/fsfoffice/contacts/phone_type.gfd' . However, absolutes in the gpd do work.

Derek Neighbors (deke) asked you mind if alter navigator?. He noted that you define 'type' yet you always start GNUe Forms. I'm thinking we define in gnue.conf runCommands for report, designer, forms, etc. James Thompson said i added a type=app - where you can use any valid shell command. Derek found the _runApp functionality, and commented thats what you get for misleading docs :) This was the cue for the usual round of 'Documentation? We have doccumentation?' comments. Derek said he would take a stab at adding support for the other GNUe tools - unless you want to save it for arturas - should be able to pretty much use the form code. The big problem is reports isnt full fleshed out so its kind of a moving target - well i guess not too much.

Derek Neighbors (deke) noted that, where querys span pages then if i go to tab one and do a query - then go to tab two and do a query - then go back to tab one - the result set is gone in tab one. He had been trying to do a contact manager databse as one form - and each one of the tables on a 'tab' - but i think instead will go back to original way of individual forms and use navigator. James Thompson (jamest) noted entering a query clears all blocks on the form - i guess it should only clear the current block and it's children. Jason Cater (jcater) said I'm torn, adding my knee-jerk reaction is a user-initiated query should clear the entire form - but a trigger-generated query should be able to do both - I do think detail blocks would always be cleared. Derek said fwiw i ran into this before but slightly different scenario - i know that THIS usage of forms is not typical and have no problem doing single forms for it. However, some day a more realist need could come up. James said I've some forms where i could use something similar but I'm not 100% sold on the idea either - it's a pretty simple change IIRC. Derek said this is one of those we have some time to sit on if we choose.

Derek Neighbors (deke) asked whether Navigator could define a default source for login and having it persist? as it really sucks being prompted for login on every form. James Thompson (jamest) agreed, but I have no clean, secure way to pass username/password info around - and putting it on the gfclient command line would be insane. Jason Cater (jcater) said the plan was to not use "gfclient formname" but to create an actual GFClient.py instance and pass it the formname and the connections object.

Derek Neighbors (deke) reported an interesting debug message :) - DBdriver.py You've got your bar in my foo! And you've got your foo on my bar! Two great reams that ream well together! James Thompson (jamest) confessed that was my error message to tell me something went to shit - however I don't recall what that something was :(. Jason Cater (jcater) suggested you need to enclose those messages in _() (the gettext interface) - so we can get those translated. Nick Rusnov (nickr) said I'd like to see that message in italian - or esperanto. Daniel Baumann (chillywilly) suggested Catalan please.

James referred back to the source and confirmed what this means is you've hit an error in the sql code used to pull the next sequence value. Derek confirmed he had wrong sequence name - he was actually not working with my own tables so forgot naming.

It was asked why the old version of GNUe Application Server used CORBA instead of SOAP. James Thompson (jamest) suggested CORBA is very close to COBRA and snakes are cool. SOAP implies bathing and no one in here does that. Actually CORBA was mature at the time that was decided...we really want to be transport independent. Later, Derek Neighbors (dneighbo) added the most important thing is that with gnurpc in common soon we can support any RPC you want - XML-RPC will be teh first to be heavily tested as its the protocol the FSF has decided to make its standard for interoperation for now - when we chose CORBA it and MS DCOM were the only VALID choices (read that worked (this was nearly 3 years ago) - well there was Java RMI too but since dont java that wasnt valid either