Reinhard Müller (reinhard) said that the version of GNUe running as a Debian package read the connections.conf file (which told GNUe which databases to connect to, and how) from /etc/gnue/connections.conf. Andrew Mitchell (ajmitch) confirmed this, saying that the version of this file in /usr/local/gnue/etc was used when set up from source code since /usr/local should never ever be seen in a package in order to comply with Debian packaging guidelines. He would do Debian packages for the new releases soon - I just need to get around to it :).

Bajusz Tamás (btami) noted that the clear form button now gives an empty resultset, but most users want to clear the form (the last record you edited) - and dont want to lose the last queried resultset. Johannes Vetter (johannesV) commented that it is not "clear form" but "rollback", isn't it ? Tamás said my users think it's an undo like button - but they are disappointed after clicking it. Reinhard Müller agreed - actually I can't see any advantage of "clear" against "undo", but undo might be tricky with appserver - for 2-tier, undo can simply reset all records to original state He noted that "undo" would also have to start a new transaction - so also changes from other users would/should become visible then as we would have to requery anyway. This would involve storing the last query and simply redoing it.

Later, Jason Cater (jcater) said he wasn't sure what the issue was - was it just the wording of that buttun isn't clear (no pun intended?) He would agree "Clear" maybe isn't the best word to describe it - to me "Revert to Database" or "Reset" or something might be clearer. Reinhard replied that the basic point was that a function to undo all changes since the last save (but "stay" in the current resultset) would be more useful than replacing the current result set with an empty one. James Thompson saw this as 2 separate functions - i wouldn't mind seeing an undo - and clear used to be called rollback but users didn't grok the meaning. I'm not sure how other places do it but here users will query something to edit it then clear, then enter a new record. Reinhard didn't understand this behaviour - why do they clear instead of insert? James said i think it's mental, they want a clean slate to work with - they also know with a blank screen they aren't accidentally changing a previously loaded record. Reinhard said that, in that case, he could see use for both undo and clear. James noted that fwiw: users are completely oblivious to the MOD, INS, OK status bar - i gave up trying to get them to use it.

Reinhard asked whether you would still make "clear" destroy all unsaved changes? or would we clearly separate the function of destroying unsaved changes and clearing the resultset? James felt that in my mind clear is nothing but a rollback - and the current behaviour of not prompting for "save unsaved changes" is bad. Reinhard agreed.

James Thompson was trying to regrok the input mask system. This, as of time of writing, allowed you to have input masks that were a mix of alpha, number and date elements, but not a mix of just number and date elements - he had removed this restriction as I thought it somewhat arbitrary Reinhard Müller (reinhard) felt that combining something else with dates sounds odd to me anyway. James agreed - just about the only thing I could think of where I'd posibly use that is a made up code with a date-stamp element like YY-MMDD###### or some such thing. Reinhard felt that this could still cause problems if the numeric part was right-padded with spaces, which would be the normal behaviour for numbers.

Reinhard added that the question is what kind of value you want to get from the mask, actually.James said right now it's always a string. Reinhard felt that was inefficient, as it implied doing two type conversion when we get datetime from the database, and we need to push datetime into the database. James said that there would need to be at least two different input masks anyway - one for display, and one for editing, but this would mean Forms would need to store two values per field then?. Reinhard said that this was 'sort-of' the case already - the displayhelpers have a "value" and a "work" variable.

James suggested in the case of numbers - we'd always return a Decimal instance or a Decimal and/or int. Reinhard wasn't sure whether all of the backend databases that GNUe worked with supported decimals.

Later, Jason Cater (jcater) noted that input masks were supposed to return the appropriate data type - it does separate out 3 types of masks - numeric, date/times, and general strings - each set having its own set of mask elements - so MMDD isn't gonna work in numeric without changing the code. He had actually put most of the effort into the numeric input masks to start with, so it was possible that the date input masks were not as fully featured. He had started with numeric as it in my mind is by far the hardest to get right - with comma-addition, fixed or floating decimal support, and support for optional characters such as currency signs.

Johannes Vetter asked what was the intention behind setting the initial focus to the first focusable entry of the *first* block defined in a gfd ? instead of using the first focusable entry of the *first* <page> defined ? It was also noted that the way the focus moves in the order the fields appear in the block was also annoying. Johannes noted you'd have to define a focusorder to avoid it, right ? Reinhard Müller (reinhard) felt that the order of the entries appearing in the GNUe Forms Definition file (gfd) would make up a good default focus order - in any case a better focus order than the fields in the block. This was agreed - if people wanted to change the default order, they could always set the focusOrder on each widget. Reinhard still could not understand the whole concept behind block based navigation - I mean - when we separate logic and ui it makes no sense to bind focus navigation to the logic instead of to the ui.

Later, James Thompson (jamest) said this might cause him problems - i'll have to do tests but I imagine the focus order change will break every form I have - not that I'm really against the change though, i haven't thought it thru yet :) The reason for having block-based naviagtion was it allowed you to hold navigation to a specific set of your data - off the top of my head invoice entry might be a good example - the master invoice block at the top of the page would be for contact info, totals, etc - the detail block of line items would be at the bottom. You could then use blocks for efficient navigation to allow both selection from a drop-down list and direct entry of new items. He added i guess if form had true container widgets like an expanded <box> then those could replicate and eventually replace the block functionality - but we'd also have to think about the 1:N field:entry relationship - as now a focus trigger on a block would fire for each entry linked to that field. Jason Cater (jcater) added a group of multi-row entries linked together by a block is much more than just a "layout" issue - they have fundamentally different logic. I'm not opposed to moving to a layout-based "container" for that - but just keep in mind, you're shifting from one set of problems to another set - as then you need to move logic concepts into the layout. Reinhard could see the logic of the block-based focus navigation when it comes to master/detail - it seems I need to think more about it.