*** reinhard has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** dneighbo has joined #gnuenterprise
*** dneighbo_ has quit IRC
*** dimas has joined #gnuenterprise
* SachaZzz is back (gone 10:27:57)
<SachaS> how do I exit a curses session? ctrl c is not working here
<SachaS> hmmm curses is working how about that?
<SachaS> amazing :)
<SachaS> i feel a bit bad
<SachaS> i think i am surrounded by wizards
<SachaS> :)
<dimas> hello SachaS
<SachaS> hi dimas
<dimas> does gnue require python2.3 nowadays?
<SachaS> i am not sure I use debian unstable so have 2.3 running.
<SachaS> i think reinhard wants gnue to be compatible with woody ... so I would say whatever python version is in debian stable is still supported by gnue
<dimas> i have only 2.2 here
<SachaS> and is it not working?
<dimas> will try to reinstall now
<johannesV> SachaS: Ctrl-Q
<johannesV> dimas: it should work with python2.1
<dimas> johannesV: thanks
*** kilo has joined #gnuenterprise
<SachaS> thanks johannesV
<SachaS> curses is cool
<SachaS> :)
*** holycow has quit IRC
<SachaS> the "show record" button in the gnue-appserver sample is not invoked when pressing enter or space ...
<SachaS> and no pulldowns
<SachaS> well still very cool
<kilo> morning everone
<johannesV> SachaS: yeah, i've noticed this too
<johannesV> but i don't know if reinhard has added this function by now
<johannesV> hi kilo
<kilo> hi johannesV, will try gtk interface asap
<johannesV> greak
<johannesV> erm, great
<ajmitch> hi
<dimas> python setup.py install
<dimas> You need GNUe-Common 0.5.2 or newer installed to install GNUe-Forms
<johannesV> hi ajmitch
<dimas> it is just after cvs install of common
<kilo> johannesV: it looks great, but...
<kilo> i found an error...
*** sjc has joined #gnuenterprise
<dimas> svn 6006, what have i missed? how to check what version of common is installed?
<ajmitch> dimas: you'd want to match a cvs install of common with a cvs release of whatever tools, I think
<ajmitch> so you'd use setup-cvs.py
<dimas> i did setup-cvs.py for common
<ajmitch> which won't install common into the python dirs
<dimas> seems there is no setup-cvs.py for forms
<ajmitch> like a release would
*** sjc has quit IRC
<ajmitch> there should be
* ajmitch waits for svn to update, and will look
<ajmitch> actually setup-cvs.py in common does all the tools
<ajmitch> so you should be able to use gfcvs to start gnue-forms
<ajmitch> there's only one because everything used to be in one module in cvs :)
<dimas> error if i try gfcvs
<dimas> [ds@exodus intro]$ gfcvs intro.gfd
<dimas> Traceback (most recent call last):
<dimas>   File "/home/ds/svn/gnue_head/gnue-forms/scripts/gnue-forms", line 30, in ?
<dimas>     from  gnue.forms import GFClient
<dimas>   File "/home/ds/svn/gnue_head/gnue-common/.cvsdevelbase/gnue/forms/GFClient.py", line 40, in ?
<dimas>     from gnue.common.logic.language import CompileError
<dimas> ImportError: cannot import name CompileError
<ajmitch> great! :)
<ajmitch> at least this is showing the right stuff, so johannesV can fix it ;)
<dimas> :)
<ajmitch> class CompileError (Error):
<ajmitch>   pass
<ajmitch> hmm, I see it there...
<johannesV> me too
<johannesV> dimas: do you have a directory called 'language' in you gnue-common/src/logic ?
<johannesV> i know this has changed during time from a package into a module (dir vs. file)
<ajmitch> I don't see any recent changes to that area
<johannesV> oh, they're not recent !
<johannesV> this has been changed about 2 or 3 months ago
<dimas> yes i have
<ajmitch> svn revision 6006 should work fine then...
* ajmitch does setup-cvs.py
<dimas> it was discussed in http://www.gnuenterprise.org/irc-logs/gnue-public.log.2004-04-13
<johannesV> dimas: what does 'yes i have' mean, do you have a language-dir ?
<ajmitch>   5821   johannes class CompileError (Error):
<dimas> johannesV: i have language dir there
<johannesV> ok, this is obsolet and has to be removed
<ajmitch> johannesV: confirmed here
<ajmitch> I get the same forms error
<ajmitch> hmm, why is the language dir still there?
<ajmitch> svn should have removed it
<johannesV> i don't know why it's not removed on a svn update ??
<johannesV> right
<johannesV> dimas: do you have a directory called 'adapters' ?
* ajmitch has an adapters dir
<dimas> yes for adapters
<johannesV> ok, so you should also have a file called 'language.py'
<johannesV> so remove the language-dir and try again ...
<ajmitch> revision 5519 shoudl have removed the languages dir
<dimas> it went further, then other error
<dimas> just svn collision
<kilo> sometimes i just delete the whole gnue stuff and check it out from svn again
<ajmitch> ok, gfcvs starts here now
<kilo> it keeps it tidy
<ajmitch> kilo: that shouldn't be needed :)
<kilo> shouldn't, shouldn't, but it works
<ajmitch> ugh, I really need that gtk2 driver, wx looks ugly ;)
<dimas> johannesV: it works here too, thanks
<johannesV> great !
<johannesV> ajmitch: gtk-driver is updated in current svn
<johannesV> most of it should work now
<kilo> johannesV: i open a form with form.run(...)
<kilo> it does show up, but with no icons
<johannesV> it seems as if there is a problem with the dropdown in a master-detail-join 
<johannesV> but i'll work on it :)
<kilo> and says
<kilo> (gnue-forms:2543): Gtk-WARNING **: Attempting to add a widget with type GtkImage to a container of type GtkVBox, but the widget is already inside a container of type GtkVBox, the GTK+ FAQ at http://www.gtk.org/faq/ explains how to reparent a widget.
<ajmitch> johannesV: excellent :)
<johannesV> kilo: can you send me the gfd ?
<johannesV> kilo: or at least a simple sample to reproduce ?
<ajmitch> hmm
<ajmitch> enter in login box still doesn't work ;)
<kilo> they are in gnue-packages/base/util/forms
<ajmitch> looks much nicer though
<kilo> CDict.gfd tries to open the other one
<johannesV> ajmitch: enter in login-box should first jump from username to password and then calling accept
<ajmitch> ok
<ajmitch> :0:> gfcvs -u gtk2 ~/devel/web/phpgroupware/GNUe/accounts_mysql.gfd 
<ajmitch> DB000: /usr/local/src/cvs/gnue-svn/gnue/gnue-common/.cvsdevelbase/gnue/forms/uidrivers/gtk2/UILoginHandler.py:80: DeprecationWarning: but we use it for a constructor for convenience
<ajmitch> DB000:   entry = gtk.Entry ()
<ajmitch> warnings... :)
<ajmitch> it doesn't change focus here
<johannesV> and you have to modify the pointSize in gnue.conf (if you haven't already)
<johannesV> hmm, that's strange ...
<johannesV> i do not get such a depreciationWarning
<ajmitch> hmm, pointsize is a little large, true.. :)
<ajmitch> what pygtk are you using?
<johannesV> i'm using sarge
<johannesV> but i don't know the pygtk version of sarge
<ajmitch> ii  python-gtk2                  2.3.90-1      
<ajmitch> for sid
<ajmitch> I'll just lookup sarge
<johannesV> ii  python-gtk2    2.2.0-1        Python bindings for the GTK+ widget set
<ajmitch> hmm, I'm using python-gtk2 from experimental, not unstable, I think
<ajmitch> it's 2.2.0-2 in unstable
<kilo> OT: http://www.madness.at/~mad/pix/softwarewar.png
<kilo> johannesV: status bar update fails
<kilo> DB000:   File "/home/gabor/SVN/gnue/gnue-common/.cvsdevelbase/gnue/forms/uidrivers/gtk2/widgets/form/widget.py", line 187, in _setStatusBar
<kilo> DB000:     self.statusBar1.push (context, text.encode ('utf-8'))
<kilo> DB000: UnicodeDecodeError: 'utf8' codec can't decode bytes in position 3-5: invalid data
<ajmitch> gar, found out why apt-move decided to ignore a bunch of critical packages :)
<johannesV> kilo: ok, have noticed that
<kilo> ok
<kilo> ajmitch: why?
<ajmitch> forgot to remove file:/ lines
<ajmitch> so it didn't mirror anything on those that I neglected :)
<ajmitch> which was a fair chunk of packages
*** holycow has joined #gnuenterprise
<kilo> hey, where is r5997??? i committed po translations yesterday and can't see the mail about it
<ajmitch> email is missing
<kilo> changes are there but email is missing
<reinhard> johannesV: i have problems with dropdown in gtk2
<johannesV> i've just fixed it :)
<johannesV> but i'm in test phase
<reinhard> try enter a contact person in hotline.gfd
<reinhard> ah
<johannesV> right
<reinhard> ok
<reinhard> and for the record
<johannesV> exactly that problem has been fixed
<johannesV> (one minute ago)
<reinhard> in curses ui, dropdowns, buttons and checkboxes are subfunctional
<reinhard> (nice word btw ;-))
<johannesV> it's not commited now but give me 5 more minutes
<reinhard> no hurry
<johannesV> i'd like to check for kilo's encoding problem in status bar
<johannesV> before i commit
<ajmitch> fast work :)
<johannesV> well, i've detected that problem yesterday evening, so i had a hole night to think about :)
<kilo> oh, i just received email about my yesterday commit...
<johannesV> damn svn keywords 
<johannesV> each time i'd like to add that Id keyword i take the wrong ...
<johannesV> is it "svn propset svn:keywords +Id file"
<johannesV> or svn propset svn:keywords +"Id" file
<johannesV> ?
<reinhard> without the +
<johannesV> oh, i think it's 'svn propset svn:keywords "Id" file
<johannesV> thanks
<reinhard> svn propset svn:keywords Id file
<johannesV> got it 
<johannesV> so i'll do another commit (i'm sorry for that)
<johannesV> ok now it's correct
<johannesV> kilo: can you try your status-bar-form again ?
<johannesV> this problem should be solved in the current svn
<reinhard> johannesV: are you ready for bug reports
<reinhard> ?
<johannesV> of course :)
<reinhard> when i focus out from a dropdown with enter
<reinhard> the text remains selected
<johannesV> right
<reinhard> actually it remains selected when i focus out no matter how
<johannesV> right, too
<reinhard> that shouldn't be IMHO
<reinhard> only the entry currently having the focus should have a selection
<johannesV> ok, i'll try to fix that
<johannesV> kilo has reported another one, where calling another form using runForm () fails
<johannesV> do you have found other bugs ?
<reinhard> yes
<reinhard> in a dropdown
<reinhard> selecting an entry by typing the first few letters doesn't work
<johannesV> that's correct, but i've to check if gtk supports this
<reinhard> i think that is something that should be done by the GF level
<reinhard> because it works for curses and i didn't do anything to make it work
<johannesV> hm
<johannesV> sure ?
<reinhard> yes
<reinhard> it works with curses
<reinhard> and i didn't do anything :)
<johannesV> ok
<reinhard> i think it's GFDisplayHandler.py, lines 805 to 810
<johannesV> ok, the tab-highlighting problem is solved 
<reinhard> a little side note
<reinhard> "official" standard for gpl header is
<reinhard> # Short line descirbing purpose of the file
<reinhard> #
<reinhard> # Copyright 2000-2004 Free Software Foundation
<reinhard> # 
<reinhard> # This file is part of GNU Enterprise
<reinhard> #
<reinhard> # GNU Enterprise is free software...
<reinhard> I try to use that for the files I write
<johannesV> ups
<johannesV> there's a mistake in about.py ...
<reinhard> most of the existing files are wrong
<johannesV> is # Short line describing 
<johannesV> the first line ?
<reinhard> with the Copyright line at the end of the GPL block
<reinhard> i am not sure if that is a real problem or not
<reinhard> just trying to follow the recommendations
<reinhard> yes
<reinhard> the first line
<reinhard> something like
<reinhard> # GNU Enterprise Forms - Curses UI Driver - Label Widget
<johannesV> hmm, i thought the copyright comes at the end
<reinhard>   To do so, attach the following notices to the program.  It is safest
<reinhard> to attach them to the start of each source file to most effectively
<reinhard> convey the exclusion of warranty; and each file should have at least
<reinhard> the "copyright" line and a pointer to where the full notice is found.
<reinhard>     <one line to give the program's name and a brief idea of what it does.>
<reinhard>     Copyright (C) <year>  <name of author>
<reinhard>     This program is free software; you can redistribute it and/or modify
<reinhard>   To do so, attach the following notices to the program.  It is safest
<reinhard> to attach them to the start of each source file to most effectively
<reinhard> convey the exclusion of warranty; and each file should have at least
<reinhard> the "copyright" line and a pointer to where the full notice is found.
<reinhard>     <one line to give the program's name and a brief idea of what it does.>
<reinhard>     Copyright (C) <year>  <name of author>
<reinhard>     This program is free software; you can redistribute it ...
<reinhard> oops, pasted twice
<reinhard> that is from the original COPYING file
<reinhard> so first line is program's name and a brief idea of what it does
<reinhard> then comes Copyright
<reinhard> then the usual text
<johannesV> ok i changed my /home/defaults/gnue
<johannesV> :)
<reinhard> :)
<johannesV> so back to that GFDisplayHandler problem
<johannesV> i think i know why it's not working
<reinhard> well, that's a start ;-)
<kilo> johannesV: statusbar fix affirmed, thx
<johannesV> np, the runForm () seems to take a bit longer
<johannesV> meanwhile i try to fix the auto-select on combos
*** ajmitch has quit IRC
*** ajmitch has joined #gnuenterprise
*** holycow has quit IRC
*** jamest has joined #gnuenterprise
*** ajmitch_ has quit IRC
<dimas> reinhard: how to select pages in curses ui?
<reinhard> dimas: page up/down
<dimas> does not work for me
<chillywilly> hi
<reinhard> i really had problems with curses because there is only a little number of keys available
<reinhard> for example, there is no shift-pageup/pagedown
<reinhard> also, there are no shift-cursor up/down
<reinhard> and only 20 function keys
<reinhard> not to speak about key combinations with ctrl or alt
<dimas> :(
<reinhard> dimas: do you have current cvs?
<reinhard> i just did the page change yesterday night
<dimas> yep
<reinhard> hmmm
<dimas> i deleted curses from forms source and updated
<dimas> may it be something obsolete in common code?
<reinhard> no
<reinhard> i don't access common at all
<dimas> ok
*** jproby has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** ajmitch has quit IRC
<reinhard> dimas: page up/down works perfectly for me
<reinhard> maybe a terminfo problem?
<dimas> i'm not familiar enough with terminfo to check
<jproby> do you have a bugzilla set up somewhere ?
<jproby> sorry - hello ;^)
<reinhard> hi
<reinhard> this here is our bugzilla ;-)
<jproby> ok so you may allready know that when you make a query on a modified form
<reinhard> dimas: what happens when you press page up/down?
<dimas> reinhard: nothing
<dimas> and i can't exit from the form
<jproby> you have a message [fine] but then query mode is still activated with "execute query" disabled
<dimas> reinhard: wait
<jamest> jproby: odd, what version you running
<jamest> i just tried svn from yesterday and can't reproduce
<jamest> i get the message and return to entry mode
*** kilo has quit IRC
*** johannesV has quit IRC
<dimas> reinhard: it does not work for intro.gfd but works file for layout.gfd in gnue-samples
<dimas> fine
<reinhard> dimas: that's strange
<reinhard> changing pages with page up/down doesn't work in intro.gfd
<reinhard> neither in curses nor in other uis
<reinhard> you have to use ctrl-page keys
<reinhard> but they are not available in curses :-(
<reinhard> fwiw
<reinhard> closing the form works for intro.gfd, too
<reinhard> for me
<reinhard> with ctrl-Q
<dimas> ok, then it works as for you here
<reinhard> pgup/pgdown are next block and previous block
<reinhard> i am not really sure what that means
<reinhard> it did change pages for me for most forms
<reinhard> the key bindings are defined globally, ui independent
*** btami has joined #gnuenterprise
<johannesV_> hi btami
<btami> hi all
<btami> reinhard: pgup/pgdn changing pages if they have different blocks in
<btami> btw. key bindings can redefine in gnue.conf
<btami> at least i'v fixed it once before...
<dimas> hello btami
<btami> maybe we can change the defaults
<btami> hi dimas
<btami> to let it work with all ui
<dimas> bye, cu all tomorrow
<reinhard> btami: i have no idea what an intuitive key binding for changing pages would be
<reinhard> *maybe* it is page up and page down
<reinhard> but on the other hand
<reinhard> if i have a multi row form
<reinhard> i would expect pgup/pgdown to scroll n records up/down
<btami> yes, i like it this way too
<btami> isn't key binding can be context sensitive?
<btami> like you (and me) want to see they work
<btami> another example: the tab key
<btami> it used for navigate to next entry, but
<btami> i like it in multi line edits work as usual=whitespace
<btami> and another one: enter key in multiline edit
<btami> can make new line
<btami> in these cases +ctrl produces de original behaviour
<btami> this is just my loud thinking...
*** jcater has joined #gnuenterprise
<btami> bbl
*** btami has quit IRC
*** andrew has joined #gnuenterprise
*** AndrewSmart has quit IRC
*** AndrewSmart has joined #gnuenterprise
*** AndrewSmart has quit IRC
*** AndrewSmart has joined #gnuenterprise
*** ajmitch_ has joined #gnuenterprise
*** ajmitch has joined #gnuenterprise
* AndrewSmart slaps AndrewSmart a few times
<jamest> :)
<AndrewSmart> have to wake up a bit :)
* AndrewSmart was playing with the new IRC software version which supports self-slapping
<reinhard> good moring USA
<reinhard> jamest: I was looking at the event handling mechanism in forms
<reinhard> currently all UI's have the code there
<reinhard> to handle a keypress
<reinhard> when the current widget is a button
<jamest> reinhard: ok
<reinhard> then send a buttonActivated
<reinhard> when the current widget is a checkbox
<reinhard> then send a requestTOGGLECHECKBOX
<reinhard> apart from some hacks to make <Return> doing a newline inside a multiline entry
<reinhard> etc
<reinhard> this code is actually the same all over again for every UI
<reinhard> now I thought if it wouldn't be better if
<reinhard> just every widget would be able to handle the requestKEYPRESS
<reinhard> and do what is appropriate
<reinhard> so for a keypress, the UI level would just generate the requestKEYPRESS
<reinhard> no matter what widget had the focus
<reinhard> and all that logic would be in the GF layer
<jamest> sounds reasonable
<reinhard> really?
<reinhard> i think you should think twice
<reinhard> ;-)
<jamest> i'm trying to recall how ths stuff works
<jamest> let me look at the source for a sec
<jamest> ok, i'm a bit confused
<jamest> it seems that in wx there is a common keyboard handler
<jamest> are you saying to break this out and put in the _base widget for each driver
<jamest> w/ widget set specific logic
<jamest> then override that class in the widgets that require different handling
<jamest> ?
<jamest> or are you talking about movving those checks like requestTOGGLECHECKBOX into the GF tree?
<jamest> and only sending case characters thru 
<jamest> or
<jamest> something else entirely(tm)
<jamest> bbiab
<reinhard> the latter
<reinhard> <jamest> or are you talking about movving those checks like requestTOGGLECHECKBOX into the GF tree?
<reinhard> <jamest> and only sending case characters thru 
<reinhard> exactly this
<jamest> i like that
<jamest> anything that can make the UI drivers "dumber" i'm all for
<jamest> :)
<jamest> and I can't think of anything (off the top of my head) that this might break
<jamest> well....
<jamest> would you do the same thing for mouse events?
<jamest> bbiab, for real this time
*** chillywilly has quit IRC
*** chillywilly has joined #gnuenterprise
<reinhard> jamest: ok, i'll do it
<reinhard> as to mouse events,
<reinhard> the only uidriver i've had a closer look is curses
<reinhard> so i can't really talk about mouse events
<reinhard> jamest: i'll just write and you can read when you're back
<reinhard> i've thought of a system in the GF* layer
<reinhard> where the GFInstance gets an event
<reinhard> and asks the GFObject with the current focus "do you want this event"
<reinhard> if the GFObject says "no" then GFInstance handles or throws away if there is nothing to do
<reinhard> so for example a button or a multiline edit could "steal" the return-key event from the normal handler
<reinhard> without ugly hacks
<reinhard> what would you think about that?
<reinhard> a third thing
<reinhard> several ui's have native routines for displaying message boxes, about boxes and simple entry boxes (e.g. for requesting a record number to jump to)
<reinhard> we've started a change that lets the UIdriver implement e.g. a messageBox method
<reinhard> but if the UIdriver doesn't implement it, the [ugly] "forms" message box is used
<reinhard> what's your opinion about that?
<jcater> fwiw, it was originally that way
<jcater> but jamest took it out in favor of a generic form-based popup dialog
*** jproby has quit IRC
<jamest> i put in the generic message box setup so forms can define their own dialogs and pop them up via triggers
<AndrewSmart> BTW: any comments on the twiki changes?
<jamest> and that we'd only have to create those dialogs once and they'd work on w/ any complete ui driver
<jamest> and yes, they are a bit ugly, though I imagine we could purdy them up a bit
<jamest> and I'm not proud, if people want to go back to the per widget set std dialogs that is cool
<jamest> though I really need forms to continue to support custom dialogs defined via gfd syntax
<reinhard> sure
<reinhard> i also need dialogs in gfd
<reinhard> and what about the other idea
<jamest> um
<reinhard> with the focused widget being asked if it wants to handle an event
<reinhard> on GF level
<jamest> right now it passes the event to all of them doesn't it
<jamest> or wait
<jamest> GFInstance dispatches all events to the object it thinks needs them right?
<reinhard> right
<reinhard> but it doesn't let the object decide if it needs them
<reinhard> so we would probably introduce a new event like
<reinhard> requestENTER
<reinhard> (to make it distinguishable from <tab> which would remain requestNEXTENTRY)
<reinhard> and GFInstance would *ask* the current focus object
<reinhard> "do you want to handle a ENTER event?
<reinhard> "
<jamest> hmmmm
<reinhard> and the object could say "yes" or "no"
<reinhard> depending e.g. on whether it is a multiline or not
<jamest> and focus is currently handled per form right?
<jamest> i think I had to do that to get the nested forms (dialogs) working
<reinhard> yes, i think focus is per form
<jamest> not sure if/how that would be impacted
<jamest> the only other thing I wonder about 
<jamest> the event system can do some things that might be impacted
<jamest> IIRC it can
<jamest>   queue events, then release them all at once when requested
<jamest>   completely ignore events
<jamest>   an event can add a new event after itself in the queue
<jamest> i'm not saying any of these will be effected
<jamest> just tossing out things I can think of that might complicate things
<reinhard> i'd say nothing of that would matter
<reinhard> as we just change the function that's called for event handling
<reinhard> so all these mechanisms already have happened
<jamest> i don't see why not to filter
<jamest> one thing I hoped to do some year
<jamest> (heck, it may already do it now)
* jamest is collecting his thoughts
<jamest> man, has it been so long
<jamest> i seem to recall the event system taking a shotgun approach to dispatching
<jamest> it transmitted to everything that registered regardless of if that object actually cared about the event type
<jamest> which may be what you're talking about here
<jamest> i wanted to somehow track what each object wanted event wise to reduce the wasted overhead in sending events the recipients ignored
<jamest> but damn, it's been too long, i can't make myself remember the details
<reinhard> I don't think the GF* widgets register as an event listener
<reinhard> and FWIW I don't think they should
<jamest> they don't
<jamest> long, long ago they did IIRC
<jamest> and the performance was the suck
<reinhard> I figured that :)
<reinhard> thus my approach to handle this outside the event system
<jamest> IIRC the history was a GFInstance approach, migrated to per widget, GFInstance quickly reborn
<jamest> i can't think of aything that would be bad about adding your filter
<jamest> if I understand it right it should actually reduce the unneeded work caused by events that aren't wanted
<jamest> as now it just passes them thru and drop out right?
<reinhard> yes
<reinhard> but that's the same it does now AFAI understand
<jamest> so you'd be blocking the unwanted events to cut down on that crap
<reinhard> my main reason to do it is to remove those hacks wrt enter on multiline entries etc
<jamest> as well as give you the extra features you want
<jcater> while we're talking about changes
<jcater> and multilines
<jcater> one change I want to see
<jcater> I think field needs a multiline="Y|N"
<jamest> now that I've confused myself, i support it 100% (for today ;)
<jcater> and not use height="" as an assumption
<jcater> as that will break horribly when we get layout management working
<jamest> works for me
<reinhard> jcater: let me hug you
<reinhard> that's exactly what johannesV_ and I talked about some days ago
<reinhard> but I didn't want to bring up layout management
<jamest> the height assumption was based upon the old <entry> only system in a absolute placement character based environment
<reinhard> *yet*
<reinhard> :)
<jamest> doesn't fit in the new forms model
<jcater> reinhard: layout management is high on my wants list
<jamest> (it was also less typing in the gfd in the days before designer existed :)
<jcater> just below the input masks
<reinhard> jcater: that's good
<jcater> sigh
<jcater> I'll be glad when I have time to gnue again
<jcater> I'm hoping that come september, I will be able to devote a lot more time
<jamest> i should be starting back up within the next few weeks
<reinhard> cool
<reinhard> so i will be able to send you my wishes again?
<reinhard> :)
<jamest> :)
<reinhard> another proposal
<reinhard> what would you think if I added to gDebug output
<reinhard> besides the file and the line
<reinhard> also date and time of the message
<reinhard> could help greatly with profiling things
<jamest> fine w/ me
<chillywilly> you should use the python logging module ;)
*** gsoti has joined #gnuenterprise
*** johannesV_ has quit IRC
<jcater> http://money.cnn.com/2004/07/21/news/midcaps/krispy_kreme/index.htm?cnn=yes
<jcater> oh, yeah
<chillywilly> Lord
*** johannesV has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
<jamest> holy crap
<jamest> the bytewise guys are code machines as of late
<jcater>  /msg jamest they're starting to make us bad
<jcater> s/us/us look/
<jamest> :)
<AndrewSmart> did you ever think about migration old oracle forms applications to GNUe ?
<johannesV> :)
<jcater> very much so
<jcater> but pl/sql -> python wouldn't be fun
* jcater has given that a lot of thought, actually
<jcater> I do plan to do a oracle reports --> gnue reports converter though
<jcater> I'm just missing a few things in reports before I can do that
<AndrewSmart> i have written a report data aggregation engine
<AndrewSmart> you can define hierachical report structures, every hierarchy can retrieve their data from a different data source
<AndrewSmart> group change, report events (= python scripts) and so on: already working
<jcater> we have all that in reports too
<AndrewSmart> ok
<AndrewSmart> what about just converting the forms & the block & field-definitions, importing the PL/SQL statements into the python events as comments?
<jcater> that would be easy to do
<jcater> except for a couple of differences
<jcater> gnue forms, as of yet, doesn't support overlapping pages
<jcater> or popup pages, per say
<AndrewSmart> I know people which would be very interested
<jcater> though preliminary support for "dialogs" is in there
<AndrewSmart> because "just doesn't have the time" or some architectural problems?
<jcater> former
<AndrewSmart> ah
<AndrewSmart> I probably know the answer, but I ask: what about a report designer?
<AndrewSmart> any thoughts/ideas here?
<jamest> lol
<jamest> gnue designer should (in theory) work with any GObject based tree (forms, reports, navigator)
<jamest> the big problem w/ reports is that it's almost too flexible
<AndrewSmart> you have some special attributes in reports you usually don't have with forms
<AndrewSmart> for example
<AndrewSmart> page headers, page breaks, page sums
<jamest> reports is far more flexible than that
<AndrewSmart> any flexiblity ends at the end of the paper, I would say :)
<jamest> it can merge data w/ rtf or postscript forms, or output std text, or raw xml
<jamest> and convert the output types on the fly
<jamest> so I can get the same report as a html file, or pdf, or tex, or xml
<derek> jamest: i would see us making "report types" kind like dtd's
<derek> then making designer modules/plugins to support those "types"
<jamest> the markup changes as well based upon your desires
<jamest> i use simple tabulation for most basic reports which has it's own markup
<derek> i cant remember if we call them filters or adapters at this point
<jamest> but other filters (adapters?)
<jamest> i think adapters
<jcater> derek: fwiw, that's the way it works now
<jcater> we just need that dtd now
<derek> right
<jcater> for the comprehensive "universal" reports
<jamest> that's what I'm trying to say :)
<derek> im just saying that is how i would see designer dealing with the "flexibity" issue
<jamest> we need a standard one that designer could then have support written for
<derek> it would require a rosetta stone :) (i.e. dtd)
<derek> btw: we have a new CIO named here
<jamest> i don't think you'll find a rosetta stone for this
<derek> and they havent crushed free software usage here yet
<jamest> Derek "Hippie" Neighbors
<nickr> fuqn hippies
<jamest> all they do is smoke pot and smell bad
<jamest> (and write free software)
<jcater> jamest: but, but, but
<jcater> how can you classify derek as a hippie by that last part?
* jcater hides
<nickr> ba-Zing!
<AndrewSmart> did you think about using/integrating reportlabs pdf creation library?
<jcater> we do
<jamest> AndrewSmart: done
<AndrewSmart> ah
<jcater> Andrew, you're not from NZ, are you?
<jamest> reports is evil
<AndrewSmart> I have still to dig into the details
<jamest> pure evil
<AndrewSmart> nope, I'm from Germany
<nickr> reports are way more complicated than they should be, it seems.
<derek> which is worse... germans or kiwis
* derek runs ;)
<AndrewSmart> but I'm born in Monterey, California
<AndrewSmart> hope this helps
<jcater> we had a string of andrews from NZ at one time
<AndrewSmart> I'm allergic to kiwis, BTW
<jamest> i'm not sure a rosetta stone is possible for designer/reports
<derek> monterey is half way between germany and kiwi ville i suppose ;)
<AndrewSmart> :)
<jamest> i use reports to do merging data into a postscript template created in windows (applewriter printer) and sent to fax
<jcater> I do a lot of RTF merges in reports
<jamest> to generate my dhcp and dns text files based upon my machine database
<jcater> also,label printing
<jamest> to create simple tabular reports
<derek> damn not quite half
<derek> 6,879 from Monterey to Christchurch, New Zealand and 5,934 from Monterey to Munich, Germany
<jamest> making designer support such random things completely would be a huge undertaking
<reinhard> i have a technical question
<reinhard> in forms
<reinhard> GFParser.py
<jamest> but if the author of the universal adaptor would finish the damn things
<derek> jamest: it is dumb to finish them now
<jamest> then I imagine designer could be made to support something like that, maybe a simple subset
<reinhard> line 1125
<derek> much better to make sure that thousands of production reports exist first
<derek> then release teh specification that breaks them all
<derek> DUH!!!!!!!!!
<reinhard> the "buildImportableTags" is called each time when the function is run
<reinhard> istead of storing the *result* of buildImportableTags in the global xmlElements
<reinhard> s/istead/instead/
<reinhard> is there any reason for this?
<jamest> is that function ever called more than once per form?
<reinhard> it's called once per form and once per dialog
<jamest> at startup?
<jamest> right?
<reinhard> yes
<AndrewSmart> derek: since its Duesseldorf, around 800 km away from Munic, maybe you get a better 50:50 relation :)
<jcater> derek: fwiw, universal won't replace the others
<reinhard> i measured startup time on my system
<jamest> i imagine it's cruft from when forms only supported 1 form in memory
<jcater> the others just may go into no-maintenance mode
<reinhard> for curses it needs 4 seconds
<reinhard> for wx it needs 7 seconds
<reinhard> to start a form
<reinhard> that's too much
<reinhard> and i'm trying to speed that up
<jcater> reinhard: fwiw
<jcater> I think that is a huge overlook on our part
<jcater> buildImportableTags should only be inside that if block
<jcater> you are absolutely right... no reason that should be on the return line being done each time
<reinhard> ok
<reinhard> that saves about 0.4 seconds
<reinhard> which is 10% for curses ui
<reinhard> that's a start :)
<jcater> yip
<jamest> reinhard: you using the built in profiler at all?
<reinhard> nope
<reinhard> using gDebug messages at strategic points :)
<jamest> you know it's there?
<jamest> as it was added when things got slow
<reinhard> i know it's there
<jamest> lots of useless info, and a few things that are actually helpfull :)
<reinhard> yip
<derek> i think its time we rewrite it in C
<reinhard> that's the usual thing with built-in profilers
<derek> to make it faster
* derek runs REALLY fast
<jamest> pyrex
<reinhard> i really get along with this
<derek> screaming... just kidding as dodging the objects being hurled his way
<reinhard> no problem
<jamest> cool
<jamest> i mainly use it to find function calls that are being called way more than expected
<reinhard> anyway thanks for the info
<reinhard> you find really funny stuff if you do it like this
<reinhard> like
<jamest> i've wondered what pickeling the gfobj tree and storing as a form.gfc file would do to it
<AndrewSmart> how much of the performance stuff belongs to wxwindows?
<jamest> ?
<jamest> i don't think wx slows us down much if at all
<jamest> at least I don't recall it being an issue
<derek> reinhard: you plan on revamping the gtk2 driver?
<jamest> i think most our startup time is burnt going thru the phased init'd of or form object tree
* derek has great interest in it but no time
<jamest> reinhard please tell me I'm full of it if I'm wrong
<jamest> heck, even if I'm right I'm probably still full of it
<derek> jamest: i like the idea of "compiled" gfd's
<derek> BUT it worries me from a freedom standpoint
<reinhard> jamest: *parsing* needs (for intro.gfd) 0.15 seconds
<derek> how much was total start time
<derek> is there a way to run forms in memory and loads forms on demand
<jamest> reinhard: that include the phased init?
<derek> er let me rephrase that
<reinhard> 3.5 - 3.7 seconds with curses ui
<reinhard> 7 seconds with wx ui
<derek> if i open openoffice it is slow
<derek> but additional documents are fast
<derek> i know debian started making a "quickstarter"
<derek> that basically loads some of openoffice overhead by default
<derek> would there be benefit to a gnue-quickstart
<reinhard> 5 seconds for gtk2 ui
<reinhard> (congratulations to johannesV)
<derek> or is the speed issue having to do with opening the forms themselves
<reinhard> i'm still finding out
<derek> also i think we need to look at some point driver/database performance
<AndrewSmart> maybe connecting to the database?
<AndrewSmart> connecting to oracle takes a lot of time
<reinhard> AndrewSmart: no
<derek> as i know that queries degrade with large recordsets
<reinhard> AndrewSmart: i purposely took a form that doesn't connect to a db
<derek> faster in gnue than with say psql
<AndrewSmart> ok :)
<AndrewSmart> i'm silent :)
<reinhard> AndrewSmart: so wx makes 2 of the 7 seconds
<reinhard> appearently
<derek> but i think its good to start with no db and get the file open and read optimized some
<jcater> fwiw
<jcater> I think this is important long term
<jcater> but we've tended to not focus on profiling
<jcater> as you have to have a working app to profile
<jcater> though I think forms is about to that point
<reinhard> jcater: right
<jcater> where it's maturing
<jcater> and it's time
<reinhard> jcater: i was just *so* annoyed by the long time the form took to start
<reinhard> when i was working on the curses driver
<jcater> reinhard: don't get me wrong
<jamest> reinhard: why not fire it up with --profile
<jcater> I'm happy to see this :)
<jamest> then exit
<reinhard> so i thought i'd spend some thoughts on this
<jamest> iirc it generates 3 reports, one of which is total time per function
<AndrewSmart> I'm gone now
*** johannesV has quit IRC
<AndrewSmart> cu tomorrow
*** AndrewSmart has left #gnuenterprise
<SachaS>  see ya later
<reinhard> jamest: about 50% of startup time is phaseInit
<SachaS> he is a machine :)
<reinhard> did you ever consider loading dialogs on demand?
<SachaS> must be one of those i robot
*** SachaS has quit IRC
<reinhard> not loading dialogs on startup would speed up the startup by 1.2 seconds
<reinhard> which is about 1/3
*** btami has joined #gnuenterprise
<jcater> reinhard: i would welcome that
<jcater> as long as it is hidden from end user
<reinhard> it would probably result in a short delay when a dialog is called for the first time
<reinhard> about 1/2 second
<reinhard> probably even shorter
<jcater> there's several such things I'd like to do like that
<jcater> like delay filling blocks/fields
<jcater> until a getValue is actually called
<jcater> or a go_field, or whatever is called
<jcater> this way, if I have detail blocks on other pages
<jcater> those don't have to get filled until either a trigger tries to access that block
<jcater> or user displays that block
<reinhard> coolest thing would be
<reinhard> start the form without dialogs
<jcater> but those kinds of things aren't priorities imho
<reinhard> and while waiting for user input, load dialogs in a seperate thread :)
<jcater> hmm
<reinhard> btw i'm just kidding for the moment :)
<jcater> thread is a bad word
* jcater shudders
*** gsoti has left #gnuenterprise
<jamest> i was thinking threading it too
<jamest> but i have no idea how painful this is wrt python
<jamest> and I didn't know if it's cross platform
<reinhard> can anybody explain why all connections are in the trigger namespace?
<reinhard> because the code to put them there
<reinhard> *opens* every connection
<reinhard> which can take quite some time when your connections.conf has some entries
<jamest> i was thinking this was so someone could call functions defined in the connection namespace
<jamest> like getting the date maybe?
<reinhard> for my connections.conf, this costs 1.2 seconds of startup
<reinhard> when i load all dialogs on startup
<reinhard> (it's done again for each dialog)
<jcater> hmm
<jcater> it shouldn't open them all
<jcater> how strange
<reinhard> apart from the fact, that i'm using a non-database form here
<jcater> it should put them in the namespace, but iirc that should be a placeholder until actually used
<reinhard> to be precise
<reinhard> it calls getConnection
<reinhard> ok let me correct
<reinhard> it does not log into the connection
<reinhard> (of course, as we have no username and password
<reinhard> )
<reinhard> but it instantiates a connection object
<reinhard> which can already be quite expensive (performance wise)
<jcater> well, I suppose we could add placeholder objects that don't fully initialize until they are called
<jcater> but I would think that would be an unnecessary diversion at this point
<reinhard> it wouldn't help much
<reinhard> as i see it
<reinhard> most of the time is the *loading* of the connection modules
<reinhard> the dynamic import of the module and all that
*** kilo has joined #gnuenterprise
<jamest> while i love seeing the performance improvements
<jamest> am I the only one that finds it amusing that hours are being invested to shave 1 second startup time
<jamest> :)
<reinhard> i expect forms to be started more than 3600 times by me
<reinhard> within the next, say, 2 years
<reinhard> and it lets you learn much about forms
<reinhard> for example
<reinhard> i've just saved 0.8 seconds startup time
<jamest> i'm all for it
<reinhard> by simply removing 2 unused connections form connection.conf
<jamest> i did that years ago in forms
<jamest> it's just funny
<jcater> a proxy object would solve that problem
<jcater> ------
<jcater> class ConnectionProxy: 
<jcater>   def __init__(self, creator, *args, **parms): 
<jcater>     self.__creator__ = 
<jcater>     self.__parms__ = params
<jcater>     self.__args__ = args
<jcater>     self.__object__ = None
<jcater>   def getattr(self, name): 
<jcater>     if name[:2] == '__': 
<jcater>       return self.__dict__[name]
<jcater>     else:
<jcater>       if not self.__object__: 
<jcater>         self.__object__ == self.__creator__(*self.__args__, **self.__parms__)
<jcater>       return self.__object__.__dict__[name]
<jcater>  
<jcater> test = ConnectionProxy(GConnections.getConnection, args..)
<jcater> test.connect()
<jcater> ----
<jcater> something like that
<jcater> i.e., the connection would never be created until a trigger actually tried to access it
* jcater goes back to coding javascript
*** SachaS has joined #gnuenterprise
<btami> bbl
*** btami has quit IRC
<derek> jcater: sick bastard
<derek> reinhard: javascript not proxyobjects :)
* jcater was being serious
<jcater> if startup creation is so large for those objects
<jcater> then it might make sense to do a proxy objecty
<jcater> *object
<reinhard> jcater: it is not
<reinhard> the time consuming stuff is the dynamic loading
<reinhard> e.g. when you use provider=psycopg
<reinhard> it has to search what directory psycopg is a subdir of
<reinhard> you can speed up by using provider=postgresql.psycopg
<jcater> but I was saying proxy the entire getConnection call
<jcater> ah
<reinhard> if you have a smart connections.conf it can make the problem go away
<derek> would it make sense to make more intutitive
<derek> provider_type=postgresql
<derek> provider_driver=psycopg
<derek> or something similar
<derek> in dcl we did something that was for different reason but which we MIGHT hit here
<derek> database=postgres
<derek> major_ver=7
<reinhard> jcater: with changing my connections.conf i reduced startup time from 3.6 to 2.6 seconds
<derek> minor_ver=4
* SachaS goes and changes his connections.conf
<derek> reinhard: the intel sales person in the office here tells me to tell you
<derek> upgrading your PC will shave off a second too ;)
<reinhard> hehe
<reinhard> please don't tell him
<derek> rofl
<reinhard> i'm using a celeron 700 with x over network
<SachaS> night all
<holycow> nite SachaS
* SachaS is away: away
<jamest> lol
<jamest> reinhard: my first stab at making forms faster was so it'd run ok on a dual sun ultra enterprise 2
<jamest> with dual 167Mhz cpus
<jamest> i really ought to get that box running again just to see how it runs there :)
*** jamest has left #gnuenterprise
*** kilo has quit IRC
<SachaS> reinhard: a f1 help key would be useful, where a window shows the curses key (f11 clear, f8 query mode, f9 search, ctrl+q etc)
<reinhard> SachaS: i am planning to show the most important f keys in the last line on the screen
<reinhard> that's why this line is still free
<SachaS> ;)
<SachaS> ok will shutup
<SachaS> ;)
<reinhard> np :)
<chillywilly> la la la la
<chillywilly> laaaaaaaaaaaaaaa
<ajmitch> hello 
<SachaS> when hitting space in "human" box crashes curses ui
<reinhard> yeah
<reinhard> check box and button are next on my todo
<SachaS> damn there should be more of you
<SachaS> :)
<SachaS> wasnt there supposed to be a packages chat tonight?
<SachaS> night all
* SachaZzzz thinks its about time to have a real world beer chat in Austria someday soon
*** sjc has left #gnuenterprise
*** holycow has quit IRC
<reinhard> night all
*** reinhard has quit IRC
*** dsmith has joined #gnuenterprise
*** dneighbo has quit IRC
*** dneighbo has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** jcater_ has joined #gnuenterprise
*** gsoti_away has joined #gnuenterprise
*** gsoti_away has quit IRC
*** bluesbaron_ has joined #gnuenterprise
*** bluesbaron_ has left #gnuenterprise
*** dsmith has quit IRC