Bajusz Tamás (btami) felt that the win32 forms driver is ready for a 0.5.1 release but would welcome some more testing. As of time of writing, wxPython was still the default user interface, but you can use --ui win32 , if you don't want wx for login. The next stage in Microsoft Windows compatability would be to add a GDI report filter to reports - many cheap "Windows-only" printers talk only GDI with no other printer control language - and unfortunately they are getting popular. Dmitry Sorokin (ra3vat) reported that dropdown boxes looks thicker then regular entries, is that mandatory look&feel for them? He and Tamás traded screenshots, and discovered that it depended what point size you were using for the characters. Tamás concluded i see the problem, but i think this is not a gnue,wx problem, but gui in general, if you got it on linux too.

Two days later, Dmitry felt it can't be a bug in widget library. Tamás disagreed - with pointSize=10 you will see, qt is OK ! which implied it was not the GNUe code causing the problem - you will see, that the problem disappears with higher pointsizes Dmitry asked what do you think could be done to solve this for smaller pointsizes? Tamás suggested finish qt driver :), but Dmitry did not understand how qt is better than native win32 for windows? Tamás thought their gui toolkit (qt), is independent from standard win32 gui API.

Reinhard Müller (reinhard) noted that, in the Application Server code, currently, the default for rpctype is "pw_xmlrpc" - could we change that to "xmlrpc"? This was the normal Remote Procedure Call (RPC) method in the Debian stable distribution of GNU/Linux. He noted that this defult would only apply where no config file exists (or the option is not mentioned in config file). Jan Ischebeck (siesel) recommended leaving the pw_xmlrpc driver as default option, because its the only one working on windows in server mode and its included in the default python distro - new in python 2.2 ;). Reinhard noted he was currently using python 2.1 - he was torn between having a default that did not work on Debian stable and having a default that did not work on Microsoft Windows. Jan suggested what about a fall back list? Reinhard was not sure how this would work. Jan said that this would be similar to the fall back mechanism already in the database drivers. Jason Cater (jcater) explained 0.5.0 introduced a fallback mechanism - if you say provider=oracle it tries the various Oracle database drivers in turn - likewise w/postgres, etc - it may not be working perfectly as this was the first release. Reinhard thought it sounded like this could be used for rpc driver fallback as well.

Reinhard Müller (reinhard) noted in appserver i can request a list of objects - i can have two lists "open" at the same time for the same class. But now our current definition is that for updating and inserting data - we don't tell which list should be affected by that transaction. He suggested various possibilities - no lists affected, all lists affected, all lists that 'fit' affected, or we add a parameter to tell which list should be affected. Jan Ischebeck (siesel) asked what the difference between the second and third options was. Reinhard gave an example - list 1 has all german customers - and list 2 has all u.s. customers - if i add a german customer then the second option means the new record is visible in both lists - the third option means the new record is only visible in list 1.

Jan felt that neither of the first two options really make sense. Reinhard noted that the fourth option is by far the easiest to implement - as it is exactly what common's dbdriver's do. Reinhard and Jan discussed the pros and cons of the various options.

Reinhard felt that the first option is close to unusable in pracice - because when i enter a new record i want to see it after i'm finished entering it :) Jan disagreed, as the record is stored on client side till an COMMIT - If a commit happens, the new record is inserted (remote) and its new gnue_id should be added to its representation in the local cache. However, Reinhard pointed out that after the commit the record stays in the list on client side, doesn't it? and it would disappear on server side - so client list and server list will be out of sync - which could lead to a mess when for example fetching further (previously unfetched) records. He still preferred the fourth option, even if form's dbdriver could "hide" the drawbacks of the first option.

Jan did not like the fourth option, as it makes our simple API too complicated. He preferred the third option, but Reinhard felt this would cause similar problems with keeping client and server in sync to the first option, and there might be states where the "original conditions" aren't even defined - for example when you just opened a form and inserted a record without selecting something first. Jan noted that the nearest equivalent to this "multiple list" problem in a normal relational database to this was a cursor - and I had a look in the postgres user manual and there is no way to insert a record into a cursor or remove a record from a cursor. Reinhard concluded that this meant the first option was exactly what a pure database would do - but he felt that we at least want to be _better_ than a database :-). He suggested reconsidering this later.

Jan Ischebeck (siesel) noted that there are some pysablot packages which are required for gnue reports. Jason Cater (jcater) said that Nick Rusnov (nickr) had done some unofficial Debian packages for pysablot (a utility to allow python programs such as GNUe to access the Sablotron XML programs), but these could not be uploaded as offical Debian packages as we were waiting for license clarification upstream, iirc. However, pysablot is only required for the demo stuff - all the new stuff doesn't need it. Jan asked about the other sablotron wrappers for python, noting that he had tried reports doing pdf export with reportlab, great stuff :) Jason was not keen - we tried it. Jeff Bailey (jbailey) suggested using something else like http://xmlsoft.org/XSLT/python.html. Jason had not seen this, but pointed out that the xslt processor for reports is pluggable - i.e., someone just needs to wrap that package and reports supports it. Jeff thought this might already have been done.

Christian Selig (lupo) wondered why Jason was not keen on XSLT generally for GNUe Reports. Jason said that the idea behind using xslt in the first place was that non-programmers could do their own output filters, but after doing several ourselves, I don't think that's a reasonable goal - xslt is great for going from xml --> some other xml-like format - but going from xml to text, postscript, pcl, etc is using the wrong tool imho.

Jan asked whether the native pdf / ps creation of reports was working already? /me wants to printout some tables with chinese characters, and its possibly easier to tweak the native ps creation algorithm than to tweak reportlab. Jason was not sure - he thought Bajusz Tamás (btami) had added some native ps generation but Jason himself was now working on the next generation markup - based on styles, etc. However,it's got a ways to go before useful and he was concentrating on Designer at the moment. But he noted that reports can output docbook directly - I've been meaning to add an example report to that effect - but I'm having to learn docbook at the same time.

Warren Turkal wondered Why is this project developing their own schema language instead of using the W3 standard XML Schema language? Derek Neighbors noted there was x-forms W3 standard as well. Much of GNUe's initial work on its own formats predated these standards, and if GNUe did use them you have no say what so ever unless you are willing to pay big corporate money to sit on the board - obviously impracticable for a free software project like GNUe. Jason Cater added Also, the XML Schema defines a heirarchial-based schema, whereas our goal is to create a simplified relational schema without much of a learning curve. XML Schema is well-suited for replacing DTDs, but I don't think defining relational databases is a good fit. Christian Selig agreed - It is not the right thing for describing databases, because we rely on relational ones (currently, and I don't think that will change till way past 1.0). Leandro Dutra hoped that will never change! I really can't imagine anything I would not do with a relational database.