James Thompson (jamest) asked if Reinhard Müller's (reinhard) proposals for layout management in Forms - to allow forms to move controls on a form to reflect the amount of space available when a form was resized - would mean taking out the char based placement. Reinhard said that he thought must leave that char based placement in for compatibility.

James asked how controls would be 'anchored' to the form. Reinhard replied I think we will need some way to define which control will be resized to what extent - but there will be useful defaults for most cases - like all text entries can resize horizontally - multi line entries can resize vertically, single line entries can't, etc. James explained how he would anticipate it working - typically a widget or panel can anchor at 1 or 2 side - which top and left would mean that the placement of that panel or widget would link to closest one to the top and closest to the left. If a widget was allowed to resize, then if I'm anchored to the top and left and I'm set to fill vertically then i'll grow downward till i hit the next widget or a container - so I could anchor the top and left of a widget to the panel itself - anchor another on left to the panel and top to the previous widet - then anchor another on left to the panel and on bottom to the panel - then the middle widget would fill the space between. He felt that in real life it works pretty well although doing something like that in forms would require some type of region tag that you could nest.

The next day, Jason Cater (jcater) was nervous going away from the pluggable layout system we had moved to to using a single, hardcoded layout manager like this. Jan Ischebeck (siesel) agreed - I hope to still be able to use the character based layout. Reinhard explained actually I would be aiming at making different layout systems work as opposed to the single, hardcoded x/y positioning we have now.

James noted that forms lets you plug in layout managers already - just no other layout managers have been written. Jason added that the intention was to have the layout plugin system in common instead of forms, too so that the other GNUe tools, not just GNUe Forms, could use it.

Reinhard asked how would you implement x/y positioning without accessing the x/y parameters? James said that positioning would be the job of the layout mgr entirely - if the user interface had built-in layout management features (which some did), these would be used, but if not, the layout management routines would handle this. Reinhard asked whether this would mean having and maintaining two complete sets of uidrivers? one for x/y based and one for layout management?

Reinhard had not yet understood why anybody should want char based positioning in a form for other reasons than to keep compatibility with old forms - especially as I figure char based positioning is a hell to implement in html or similar frontends. Bajusz Tamás (btami) gave the example of wanting forms that exactly matching reports providing by law - for example, for tax purposes.

James emphasised that i don't see layout management as something the UI objects should take part in - i think the entry objects should provide hints to the layout manager about what they want - but not participate in the layout. They could express a preference like now "i want to sit in the 3rd chair in isle 4" or relative to other objects but the layout manager would process these hints and stick them wherever it feels like honoring the hints - if it wants to do x/y positioning that would be ok - but it it wants to use UI specific containers then it could. Discussion continued.

Further to , Jason Cater (jcater) said that his view of GNUe Application Platform (GAP) was that it was a way of providing clients a cleaner way to get at the GNUe Common Library and each other. He noted that right now, all client apps are based on GClientApp, which takes care of initializing some services - gap is providing a way for all components of a tool to get at that "service" cleanly. For example, the current way of sharing connections was messy, and caused problems when refactoring code. And this was just connections - there were other componants that tools might want to share. GAP, by contrast, would allow any component of any tool to declare what components of other tools it needs - without creating an __init__ nightmare.

James Thompson (jamest) added that it also enables an application to only load the components it needs - like in my case I have lots of based on the core GNUe client application code - however not all need the command line parsing, or configuration file support - so in those cases I wouldn't make a request for that service and it wouldn't load. He hoped that eventually, if it proves out, all the other gnue apps could use gap as their base - and with the simple high level UI common setup you could say "I love designer, I do. I want to use it to edit all my python apps" - you could take designer's startup config file (that says which components to load) and remove the gui layout parts, leaving only it's trigger editor component to make it an editor for generic python code, not just GNUe triggers.

It was asked how GNUe dealt with different time zones - in a three-tier set up (forms talks to Application Server talks to back-end database), the users of a forms could be in different time zones to each other, and different to the time zone of the Application Server and/or the database server. This could create problems sorting entries by date/time order. Reinhard Müller (reinhard) noted that, as of time of writing, there is no timezone handling currently - so appserver just takes time values like you give it - so if you use gnue_createdate etc it's all in the timezone appserver is running in. Johannes Vetter (johannesV) noted that well, actuall python's datetime.datetime has no 'native' timezone either - instead one would have to implement timezone-support if needed. Reinhard noted that converting times values to UTC before storing in the db might not be what most users would expect - still somebody searching in the db directly via sql might be surprised to find "wrong" values.

Reinhard noted that the specification for XML-PRC (the XML specification for Remote Procedure Calls, which GNUe Application Server was intended to be compatible with) said that It should be specified by the server in its documentation what assumptions it makes about timezones. so it looks like you can't pass a timezone there by definition - and that we can define, for example, that all dates must be the timezone which appserver runs in.

Reinhard agreed 100% that timezone handling is a missing feature in appserver - which would have to be implemented by either documenting something, or some changes in appserver itself, or (most probably) both. I think it would make most sense to make the client responsible to send only UTC time values to the server - but then appserver would have to convert all automatically set times to UTC, too - like gnue_createdate etc - which currently is in appserver's local time zone - and I figure there's a whole bunch of other problems we might run into if we look closer, for example the fact that the date part of a datetime value can change when you convert timezones.

Reinhard concluded I think this really needs more thinking - also regarding different backends and how *they* are able to handle timezones. Later on, he documented the issue as a wishlist item for appserver.

Johannes Vetter (johannesV) asked what block-level focus-triggers were for in Forms. James Thompson (jamest) replied that they provide a higher level trigger than per entry level - so you could define a trigger that validates that fields x,y,z match a specific combo of values - and block navigation if they did not. In other words, they fire on any focus change in that block, not just on movement into or out of the block. This meant that, if you moved from one entry field to another in the same block, you would fire four triggers all at once - the focus-out trigger for the field and block and the focus-out trigger for the field and the block. Even if you were moving from one field within the block to another field still within the block. This was intended to match a similar feature in a proprietary database forms software package.