GNUe Traffic #111 For 10 Apr 

Editor: Peter Sullivan

By Peter Sullivan

"would that be what the user expects?" - "I have found it hard to predict what users expect :-)" - "we want intuitive user interface" - "and free whisky" - "and world peace."

Table Of Contents


This covers the three main mailing lists for the GNU Enterprise ( project, plus the #gnuenterprise IRC channel.

1. Differences between packaged releases and source code version

4 Apr  Archive Link: "[IRC] 04 Apr 2006"

Summary By Peter Sullivan

Topics: Common

People: Reinhard MüllerAndrew Mitchell

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 :)" .

2. Behaviour of Clear button

5 Apr  Archive Link: "[IRC] 05 Apr 2006"

Summary By Peter Sullivan

Topics: Forms

People: Bajusz TamásJohannes VetterReinhard MüllerJason CaterJames Thompson

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.

3. Input Masks for Numeric, Date and Text data

6 Apr  Archive Link: "[IRC] 06 Apr 2006"

Summary By Peter Sullivan

Topics: Forms

People: James ThompsonReinhard MüllerJason Cater

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.

4. Block navigation in Forms

7 Apr  Archive Link: "[IRC] 07 Apr 2006"

Summary By Peter Sullivan

Topics: Forms

People: Johannes VetterReinhard MüllerJames ThompsonJason Cater

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" .







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.