*** kilo has joined #gnuenterprise
<kilo> good morning
*** reinhard has joined #gnuenterprise
<k-man> hi kilo
<k-man> hello all
<reinhard> good morning all
<reinhard> quit
<reinhard> oops
*** btami has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<btami> good morning
<johannesV> good morning
*** yure has joined #gnuenterprise
<btami> reinhard: as i'm reading issue102 in roundup, i feel with krizz
<btami> the clear form button now gives an empty resultset, but most user want to clear the form (the last record you edited)
<btami> and dont want to lose the last queried resultset
<johannesV> but it is not "clear form" but "rollback", isn't it ?
<btami> ?
<btami> my users think it's an undo like button
<btami> but they disappointed after clicking it
<reinhard> btami: it might sound strange now to you, but I wholeheartly agree
<kilo> :)
<reinhard> I would rather like to see an "undo" than a "clear"
<reinhard> actually I can't see any advantage of "clear" against "undo"
<btami> i find no usefulness of a "clear" button as it works now
<btami> :
<btami> yep
<johannesV> hm, so what about transactions then ?
<reinhard> undo might be tricky with appserver
<johannesV> how to revert up to the last commit ?
<reinhard> for 2-tier, undo can simply reset all records to original state
<btami> if no "save" was before, why "clear" ?
<reinhard> btami: would you think the "undo" should also start a new transaction?
<reinhard> hmm.... actually it would have to
<btami> sure
<reinhard> so also changes from other users would/should become visible then?
<reinhard> so we would have to requery anyway
<btami> yep
<reinhard> now if another user created a new record meahwile, would that new record be shown after undo?
<reinhard> think a grid with 5 entries
<reinhard> user changes one entry and hits "undo"
<reinhard> after that grid shows 6 entries
<reinhard> would that be what the user expects?
<btami> why not?
<reinhard> I have found it hard to predict what users expect :-)
<kilo> i think it should show the most recent state of the DB
<kilo> so yes, 6 rows
<kilo> erm entries
<reinhard> so we would have to store the last query and simply redo it
<kilo> yes
<reinhard> same would actually go after the commit
<btami> i just gave the same feedback from our collegues (using inhouse app) ass krizz wrote
<kilo> i have some users who can handle situations like this
<btami> s/ass/as
<btami> :)
<reinhard> as now after commit no new records are displayed
<reinhard> the only question to remain is whether this breaks the holy sql*forms compatibility
<reinhard> :)
<kilo> indeed
<btami> i don't think we want sql*forms compatibility :)
<btami> we want intuitive user interface
<kilo> and free whisky
<btami> and world peace
<kilo> and free willy
<btami> maybe, a new toolbar icon can solve the compatibility, if needed
<reinhard> let's ask jamest/jcater about this in the afternoon
<kilo> or we could keep this functionailty and put a new icon there
<btami> agree
*** docelic has joined #gnuenterprise
<kilo> @roulette
<bigbrother`> kilo: *click*
<bigbrother_> kilo: *click*
<kilo> hmmm twisted, 2 revolvers firing the same time... :)
<dimas> :)
<dimas> scary games
<kilo> :)
<kilo> hmm we have some more peaceful ones iirc
<kilo> !coin
<kilo> @coin
<bigbrother`> kilo: heads
<bigbrother_> kilo: tails
<kilo> :)
<kilo> and @dice 2d6
<kilo> @dice 2d6
<bigbrother`> kilo: 3 and 6
<bigbrother_> kilo: 4 and 2
<dimas> :)
*** dimas__ has joined #gnuenterprise
*** dimas__ has quit IRC
<reinhard> all who work with vim: I've committed 2 helpful files for your local .vim/ directory under gnue-common/utils/vim
<btami> bbl
*** btami has quit IRC
*** dimas__ has joined #gnuenterprise
*** jamest has joined #gnuenterprise
<jcater> reinhard: I wouldn't describe our goal as "holy sql*forms compatability"
<jcater> forms has already moved well beyond what sql*forms offered
<jcater> and broke several of it's bad designs
<jamest> well, replaced with several of it's own
<jcater> but having said that, I didn't get from the conversaion what is the problem with Clear?
<jcater> just the wording of that buttun isn't clear (no pun intended?)
<jcater> or the functionality isn't needed?
<jcater> I would agree "Clear" maybe isn't the best word to describe it
<jcater> to me "Revert to Database" or "Reset" or something might be clearer
<reinhard> 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
<reinhard> and of course talking about "holy sql*forms compatibility" was only teasing :)
<jamest> i see that as 2 separate functions
<jamest> i wouldn't mind seeing an undo
<jamest> and clear used to be called rollback but users didn't grok the meaning
<jamest> i'm not sure how other places do it but here users will
<jamest> query something to edit it
<jamest> clear
<jamest> enter a new record
<jcater> yeah, same here
<jcater> I think it does make sense to requery on rollback of the block/datasource is set to auto-query, though
<reinhard> jamest: I don't understand
<reinhard> jamest: query something to edit it
<reinhard> jamest: clear
<reinhard> do they save in between?
<jamest> yes
<jamest> a better example
<reinhard> so why do they clear instead of insert?
<jamest> i think it's mental, they want a clean slate to work with
<jamest> they also know with a blank screen they aren't accidentally changing a previously loaded record
<reinhard> ah ok
<jcater> that's the same behaviour I see here
<reinhard> I think then I see use for both
<reinhard> undo and clear
<jamest> fwiw: users are completely oblivious to the MOD, INS, OK status bar
<jamest> i gave up trying to get them to use it
<jcater> I wouldn't call it "undo" though
<jcater> as I see a very real need to implement real undo behavior
<jamest> Refresh?
<jamest> f5 in Kate :)
<reinhard> revert?
<jcater> Refresh / Reload / Revert
<jcater> revert is my favorite as I see it in a lot of editors
<reinhard> I think the main focus is on forgetting what was not yet saved
<jcater> yeah
<reinhard> and refreshing data from other transactions is only a welcome side effect
<jamest> and reload may have other meanings if the users don't back off
<reinhard> so I think revert would be best
<jamest> "just a sec.  I'm reloading"
<jcater> sigh
<jcater> speaking of which
<jcater> I have to drive to work
<jcater> bbi30m
<reinhard> ok
*** jcater has left #gnuenterprise
<reinhard> and then you would still make "clear" destroy all unsaved changes?
<reinhard> or would we clearly separate the function of destroying unsaved changes and clearing the resultset?
*** CirrusImage has joined #gnuenterprise
<reinhard> and "clear" would only have the function of making a query with 0 results?
<chillywilly> hi
<jamest> in my mind clear is nothing but a rollback
<jamest> and the current behaviour of not prompting for "save unsaved changes" is bad
<reinhard> ok
<reinhard> so we would prompt on clear?
<reinhard> (FWIW, that's what I would prefer, too)
<jamest> it's what I do in my java sales system
<jamest> yes, no, cancel
<reinhard> exactly
<jamest> btw, any ideas on how long till the next forms release?
<reinhard> probably months
<jamest> one of my users started hitting a bug against triggers fired in buttons
<reinhard> I think it might make sense to branch from the last 0.5 release if necessary
<reinhard> for such kinds of bug fixes
<reinhard> as forms will probably be a fast moving target over the next months
<reinhard> we will of course use svn in house or so
<reinhard> but I wouldn't install it to users
<chillywilly> HELLO :)))
<reinhard> hi chillywilly
<johannesV> hey, a <field> of a <block> cannot have a style "checkbox", can it ?
<reinhard> I don't think so
<reinhard> but I guess that's a remains of the days when <field> was <entry>
<johannesV> hm, so why do we use it in GFField then ?
<johannesV> ok, that's what i was thinking too ...
<jamest> it probably should have moved to entry
*** jcater_ is now known as jcater
*** sacha has joined #gnuenterprise
<jcater> style is still in gffield?
<johannesV> yeah
<johannesV> now it's removed .. :)
*** derek has quit IRC
<CirrusImage> johannesV- just tried the wx26 uidriver on win32 and it looks great, except..
<CirrusImage> dropdowns don't seem to work
<johannesV> CirrusImage, wxPython 2.6.2 is broken on win32 (wrt dropdowns)
<johannesV> please use either 2.6.1* or 2.6.3*
<johannesV> but i'm not sure if 2.6.3 really has all issues fixed
<CirrusImage> that explains it
<johannesV> yeah, i'm sorry, but i can't do more on that atm ..
<johannesV> 2.6.3 is out for a couple of days right now
<johannesV> so you might want to check that first
<johannesV> 2.6.1 is known to work fine
<CirrusImage> also, resetForeignKey() gives me an error
<CirrusImage>  TypeError: _updateChoices() takes exactly 2 arguments (1 given)
<johannesV> ah, ok
<johannesV> that one i can fix ... CirrusImage are you using svn or packages ?
<CirrusImage> svn
*** kilo has left #gnuenterprise
<johannesV> ok
<johannesV> calling from which trigger ?
<CirrusImage> On-Action
<johannesV> hm, works fine for me ...
<johannesV> can you past the traceback ?
<johannesV> s/past/paste/
<CirrusImage> Traceback (most recent call last):
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\forms\uidrivers\wx26\widgets\button.py", line 81, in __on_button
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\forms\GFObjects\GFButton.py", line 103, in _event_fire
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\forms\GFObjects\GFButton.py", line 110, in __fire
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\forms\GFForm.py", line 975, in refreshDisplay
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\common\definitions\GObjects.py", line 252, in walk
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\common\definitions\GObjects.py", line 252, in walk
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\common\definitions\GObjects.py", line 252, in walk
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\common\definitions\GObjects.py", line 249, in walk
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\forms\GFForm.py", line 984, in __refreshDisplay
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\common\events\EventController.py", line 152, in dispatchEvent
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\forms\uidrivers\_base\UIdriver.py", line 394, in updateEntry
<CirrusImage>    File "C:\Program Files\GNUe\bin\gnue\forms\uidrivers\wx26\widgets\_base.py", line 188, in setValue
<CirrusImage>  TypeError: _updateChoices() takes exactly 2 arguments (1 given)
<CirrusImage> I haven't tried it since I last updated a couple days ago
<johannesV> CirrusImage, fixed in svn
<johannesV> thanks for reporting !
<johannesV> please note that gnue-forms is undergoing massive changes atm as we are restructuring  ...
<jcater> (designer too)
<jcater> johannes/reinhard, just fyi, designer has decoupled itself from the forms ui-drivers
<jcater> so changes inside uidrivers won't break designer
<reinhard> jcater: this is good to hear
*** yure has quit IRC
<johannesV> hm, if a tag has a ValueSet defined, doesn't this raise an exception if one passed another value (than listed in ValueSet) ?
<johannesV> i mean, i can do <field name="foo" ... case="HARhar"/>
<johannesV> and nothing happens :)
<reinhard> seems to be a bug in the parser
<johannesV> instead in the trigger-function triggerSetCase() we do an assert(value in ('mixed','upper','lower')) which gets removed by optimization on installation
<jcater> I'd call this a deficiency of the parser
<jcater> there are several such tests the parser should do that it doesn't do
<jcater> that I'm sure our fine friends from Austria will fix
<johannesV> :)
<johannesV> ok, so if you all are ok with fixing it, i'll try to ...
*** chillywilly has quit IRC
*** chillywilly has joined #gnuenterprise
<reinhard> johannesV: great
<jcater> am I right in thinking that a box is now a container widget
*** SachaS has quit IRC
<jcater> so <box x=10 y=20 ><field x=0 y=0> </box>
<jcater> causes the field to really be at 10,20? (or 11,21 ... whichever)
<jcater> or am I imagining this?
<reinhard> I'm not sure
<reinhard> what would you think makes more sense?
<jcater> to me, if box is going to be a container object
<jcater> any children's layout (whether char-based or other) should be relative to that container
<jcater> that just seems intuitive to me
<jcater> a box may not be a container object at the moment, though
<jcater> but I swore siesel added that feature
<jcater> (I guess I can look :)
*** k-man has quit IRC
<jcater> okay, it appears it does not support that
*** johannesV_ has joined #gnuenterprise
<johannesV_> currently a box is derived from GFContainer, but it was never used as such
<johannesV_> so it does not map positions
<jamest> box, last I knew, also always showed up on screen
*** johannesV has quit IRC
<jamest> so it'd suck up screen space unless we dropped the border
<johannesV_> jamest, right, that's it's only use atm
<jcater> okay, I know this is something that was talked about at length a few years ago, but it didn't change
<jcater> jamest: yeah, I wasn't saying box should be *the* container
<jcater> but should box be *a* container
<jamest> oh, yeah
<johannesV_> i think a box should be a container after doing all the stuff wrt layoutmanagement
<johannesV_> where i can imagine having a <box type=... label="foo"> ... being a box with a border and a label, and a <box type="..."> being a box without a border and label
<johannesV_> but it should be always the parent of <entry ...> and other stuff the like
<johannesV_> bbl
*** dimas__ has quit IRC
*** derek has joined #gnuenterprise
<derek> http://burrowburrow.com/robots/goat.html
<jcater> lol
<jcater> I need that for my front yard
<jcater> (wife would kill me, but it'd be worth it)
*** derek has quit IRC
*** derek has joined #gnuenterprise
<jamest> jcater: can't you just tweek the truck on blocks a bit?
<jamest> add horns or something?
<jcater> good point
*** k-man has joined #gnuenterprise
*** yure has joined #gnuenterprise
<docelic> oii yure
<yure> hy docelic
*** johannesV_ has quit IRC
*** sjc has joined #gnuenterprise
<reinhard> cu all
*** reinhard has quit IRC
*** CirrusImage has quit IRC
*** yure has quit IRC
*** kilo has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** kilo has left #gnuenterprise
*** k-man has quit IRC
*** jcater has quit IRC
*** k-man has joined #gnuenterprise
<k-man> morning all
*** jamest has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** sjc has quit IRC
*** derek has quit IRC
*** sacha_ has joined #gnuenterprise
*** sacha has quit IRC
*** derek has joined #gnuenterprise
*** derek has quit IRC
*** sacha__ has joined #gnuenterprise
*** sacha_ has quit IRC
*** ncjp has quit IRC
*** jamest has quit IRC
*** sacha_ has joined #gnuenterprise
*** sacha__ has quit IRC
*** sacha_ has quit IRC
*** ncjp has joined #gnuenterprise
*** k-man has quit IRC
*** derek has joined #gnuenterprise
*** docelic has quit IRC
*** sacha_ has joined #gnuenterprise
*** sacha__ has joined #gnuenterprise
*** sacha_ has quit IRC
*** sacha__ has left #gnuenterprise
*** sacha has joined #gnuenterprise
*** bigbrother has joined #gnuenterprise
*** chillywilly has quit IRC
*** bigbrother_ has quit IRC
*** chillywilly has joined #gnuenterprise
*** sacha has quit IRC
*** sacha has joined #gnuenterprise
*** weex has joined #gnuenterprise