*** dsmith has quit IRC *** reinhard has joined #gnuenterprise *** Vee has quit IRC *** kilo has joined #gnuenterprise *** holycow has joined #gnuenterprise *** bluesbaron_ has joined #gnuenterprise *** bluesbaron_ has left #gnuenterprise *** sjc has joined #gnuenterprise *** sjc has quit IRC *** holycow has quit IRC *** btami has joined #gnuenterprise *** mbredl has joined #gnuenterprise On install of gnue-appserver (./setup.py install") a "unknown locale: us" error-message interrupts the install. How do I fix that? set it to en_us how? export LC_ALL="en_us" thanks *** johannesV has joined #gnuenterprise Did the - export LC_ALL="en_us" - , still get the ValueError: unknown locale: us . Any clues? got it: export LANGUAGE=en_us does the trick . Thanks reinhard wrote in an email, that unset LANG and LC_ALL environment variables, or set them to something correct. "us" is no correct language code (it would be "en" for English). *** mbredl has quit IRC johannesV: i find 2 remaining issues with gtk2 ui 1. selecting with mouse (for cut and paste) doesn't works yet 2. clicking in a scrollbar between the thumb and an arror doesn't work yet kilo: can you try intro.gfd with gtk2 ui setting pointsize=18 ? strange, but it looks good on XP, but some withgets are overlaps on UHU for me i think we have font issues :( *** reinhard has quit IRC i dont know how to enter my birthday in the gnue-appserver sample.gfd form (gtk2 and wx ui) must be a bug then ;) SachaS: this has nothing to do with ui, but with the display- and inputmask which is set to %X (and %x) in sample.gfd, which means locale-default btami: thanks, i'll try to fix that; regarding fonts: i'm going to remove all explicit font-setting code, so the application-default-font (set by theme) will be used this should make things clear; but i don't think it would solve your problem with intro.gfd, since this depends on the size_request ()-calls we make (due to a missing layout-manager) johannesV so how do you enter a date? which locale do you have ? en_AU.UTF-8 take a shell an enter: date +'%x' or date +'%X' (for time) oh gotcha using this format should work // let me try yes thanks 1/1/1971 does not work u need 1/1/71 thanks. how about date time? its not very intuitive you would have a format like: '%x %X' which has to be entered accordingly with space. let me try but i think jamest has input- and display-masks on it's schedule for the next thing to be done SachaS: the mask to be used is specified in the sample.gfd; just search for the term 'mask' ok got it. thanks. last meeting can be in the future ;) i think reinhard suggested once to have the ui specific date dialog poping up if a user wants to. thanks again. well, to accomplish this a GFEntry would have to know it's a date/time field *** jamest has joined #gnuenterprise *** johannesV_ has joined #gnuenterprise *** jcater has quit IRC *** johannesV has quit IRC *** chillywilly has quit IRC *** chillywilly has joined #gnuenterprise *** chillywilly has joined #gnuenterprise *** jcater has joined #gnuenterprise hi hi chillywilly *** reinhard has joined #gnuenterprise reinhard: forms seems to work ok haven't really hammered on it though gtk2 ui wouldn't start up but i imagine I'm missing a dependency hope to play more tonight jamest: great i guess the gtk used in wx must still be gtk1 yep there seem to be some versions of wxgtk that work with forms and work with gtk2 but most of the gtk2 versions of wx seem to break with gnue it's our extr33m3 code it is that cr4ppy code *** gsoti has joined #gnuenterprise reinhard: wx now officially supports to compile with gtk2 many "new" distros ship wx compiled with gtk2 like UHU-Linux we have issues with dropdown events and with fonts but seems it's not wx, but gtk/gnome related as i have font issues with gtk2 ui too http://www.gnuenterprise.org/~btami/intro-with-pointSize16.png *** sjc has joined #gnuenterprise *** kilo has quit IRC *** ajmitch_ has quit IRC *** holycow has joined #gnuenterprise *** btami has quit IRC *** ajmitch has quit IRC *** ajmitch has joined #gnuenterprise *** Vee has joined #gnuenterprise *** kilo has joined #gnuenterprise *** deke has quit IRC *** deke has joined #gnuenterprise *** gsoti has quit IRC *** bluesbaron_ has joined #gnuenterprise *** ajmitch_ has joined #gnuenterprise *** btami has joined #gnuenterprise *** johannesV_ has quit IRC *** johannesV has joined #gnuenterprise is gnue-navigator broken in the current svn ? *** holycow has quit IRC works for me maybe it's because you've set forms default ui = gtk2? and start navigator with wx hmm, have to try DB000: self.manager.handleStartupError( DB000: AttributeError: Instance instance has no attribute 'handleStartupError' johannes@Boston:~/prj/gnue/gnue-appserver/samples$ gncvs appserver.gpd /home/johannes/bin/gncvs: line 9: 2801 Speicherzugriffsfehler /usr/bin/python2.3 ${SCRIPT} "$@" :) using no default-ui, aka wx i get the segfault too but only when exiting before, everything works fine yeah, that's correct if i try to install python2.3-gnome apt suggest to remove about 14 packages, including gnome-core and the like ... isn't that crazy ? s/python2.3-gnome/python2.3-gnome2/ not for me maybe you should apt-get upgrade before? upgrade is running already do you have it installed ? no but i tried and it didn't want to remove any packages still want's to remove gnome-core gnome-themes nautilus and much more are there newer replacements for this packages in sarge ? reinhard@london:~$ dpkg --list | grep gnome-core ii gnome-core 50.sarge.1 The GNOME Desktop Environment -- essential c ii gnome-core 50.sarge.1 The GNOME Desktop Environment -- essential c hmmm if i call a apt-get upgrad it says about 84 packages are kept behind ah try apt-get dist-upgrade hmm, but i'm using sarge ?? am i ?ยด if an upgrade requires a package to be removed because of a conflict with newer version the upgrade is not done on dist-upgrade err it is not done on upgrade but it is done on dist-upgrade oh, yeah, now it would download about 145 mb :) (have to check limit first) so you'll update cups probably and it'll remove gnutls in its old version or how that library was i had the same thing upgrading ... right, cups is also upgrading there was a move from libgnutls7 to libgnutls10 in cups * chillywilly is dist-upgrading too :) which cause several packages to not update with normal upgrade because installing libgnutls10 requires deletion of some other packages may i be curious to ask what you need python-gnome for? tell him no johannesV ;) gtkhtml2 it's needed by gnue-navigator i was just wondering how gnue-nav is working maybe i'll put a few evenings into this part :) oh it's needed by gtk2 ui for navigator? btw. navigator has a bug: self.manager has no attribute 'handleStartupError' right, seems so but i havent verified if it's needed seems as if the view-panel in nav has to be able to handle html for previewing reports? maybe please don't put too much work in navigator especially not in the UIxxx files no that's just the way we did wx's it was easiest to get clickable options in wx by using their html panel jcater: all the UIxxx files in navigator have this note: # This file is nothing but a temporary hack. Navigator should # reuse GNUe Form's UI* classes if at all possible. is it worth putting effort in navigator's UI classes? or will they be ditched at some point anyway? well, but the form's UI* classes haven't a 'official' tree-support, do they ? the problem w/navigator is no ui has actually been defined I think most have liked the wx html-style but there were several prototypes I'm not sure how much of form's UI classes could be use but if nothing else, we do need to separate a lot of the logic out of UIwx and into some base file like forms does it jcater: thanks jcater: btw, there is something in forms i don't understand in the keyboard handlers of the several ui's if command == 'JUMPRECORD': but isn't form's ui-stuff to much connected with GF* ? global _PROMPTFORRECORD action = _PROMPTFORRECORD() johannesV: right I can neither see how command could actually become JUMPRECORD that's why I said I'm not sure if form's ui* can really be reused or not nor do i see a global variable _PROMPTFORRECORD * jcater thinks probably not reinhard: that was a jamest hack that I do not claim to understand :) ok thanks jcater :) re form ui vs. navigator ui actually i think the same we will need separate ui drivers for navigator but there should be a defined api for those drivers yes i think so too right and I think the navigator api can be a lot simpler than form's as it will do a lot less like: the view-panel must understand html or xml or ... jcater: i think so, too what about displaying reports? johannesV: I think that is outside the scope of navigator I think navigator just tells the report engine,"generate a report, and use this panel to render on" i would like to be able to preview reports in navigator but navigator might hint to reports that is can handle various formats like "you can use html if it's easier" reinhard: right ah ok i understand navigator will not render a raw xml file hmm, yeah, sounds good (but i still haven't looked into nav-source in much detail= just like navigator handles embedded forms s/=/) (well, when it doesn't crash :) navigator just tells forms it can use a certain panel to render on jcater: yes, so we actually think the same :) ok, i've just found a bug in gtk2-forms-driver ... :) it cannot render a form in a given parent-container :) reinhard: which tool is that to remove or detect unused debs ? (something with orphane ...) deborphan *** btami has quit IRC *** johannesV has quit IRC *** btami has joined #gnuenterprise only reading some of the backlog.. be careful with dist-upgrade you can fsck a testing box REAL quick with that command i.e. i suggest using upgrade day to day and only do dist-upgrade if you ahve a situation you understand teh reamifications on (which it sounds like this is one of those) where are the PRMPTFOR vars ? i thought they were not in use any, an old hack that wasn't needed anymore for example in uidrivers/wx/common.py probably old remains also, i thought forms did tree's now didn't someone submit a patch for that? the romanian boy did it, but without any doc so he followed standard GNUe procedures then rofl yes :) jamest: there is something that makes it quite hard to write ui drivers for forms (IMHO) many functions have just a single parameter besides self "event" where nowhere is documented which fields of "event" are set for which function (like setTitle, formAlert, beginWait, ...) I *think* it could make ui construction much more straightforward if we had, say, functions like _setTitle (self, title) _formAlert (self, message) heh, i liked that too :) _beginWait (self) etc also, some of these functions could be implemented as functions of the form instead of functions of the UIdriver so the "finding out which form we currently have" could go to the base driver what would you think? all those functions are processed using events there should currently be a seperation (at least at function call level) of the UI driver from the Virtual GFForm ys yes sorry i think i didn't explain clearly the base UIdriver.py connects for example the setTitle event to the self.setTitle function all uidrivers must overwrite setTitle the definition of self.setTitle is self.setTitle (self, event) which makes it hard for a person that wants to implement that function to find out what "event" actually is in this case i.e. if there is event.title, event.text, event.name, event.caption or even event.data : :) but if the base uidriver would *implement* a self.setTitle like that def self.setTitle (self, event): if hasattr (self, '_setTitle'): self._setTitle (event.title) and the definition of the _setTitle function was _setTitle (self, title): everything would be clear do i make sense? yes makes sense to me ah ok in this special case i would even implement the base setTitle like uiForm = weirdCodeToFindOutTheUIFormFromTheEventParameter uiForm._setTitle (event.title) so derived uidrivers would not implement a uiDriver.setTitle but a uiForm.setTitle which would even be more straightforward still makes sense? bbl yes sounds ok to me I'd like to see two things, though 1. reverse the "_" naming scheme so the drivers implement setTitle(title) and the base driver defines _setTitle(event) which itself calls setTitle(event.title) 2. I still think it should pass the event as a final parameters even if 99% of the ui drivers don't need the event it's still there in case there's some non-standard part of the event they need uiForm = weirdCodeToFindOutTheUIFormFromTheEventParameter I also wonder how that'd be implemented but I'm all for cleaning up the API *** holycow has joined #gnuenterprise as to the _ naming scheme most people seem to use _foo for "protected" functions functions not part of the "outside" API of the object true that was my thought functions being called from parents or children in object hierarchy it depends on who is the "outside" target audience imho, it would be the person implementing the GTK2 driver or the wx driver so I would use "_" for stuff in the base driver that the GTK2/wx/win32 developers don't need to see not vice-versa that is just my opinion, though hmm at least we should be consistent i have always viewed the system as foo = gets called from not self _foo = will only be called by self as to events there are no "non-standard parts of the event" imho there are fields of the event that get set upon generation of the event sure now well * jcater is just thinking ahead it look to me as if you don't want to define an api because you fear that it might change someday like wx functions get their corresponding events that's not true at all I just see utility in passing the raw event just in case I'm not 100% sold on this I just see possible use in the future using the raw event means not defining the parameters at all all IMHO of course but it shouldn't normally use the event this is just if it needs it in the future, for whatever reason I'm not really in the position to decide forms API so you mean something like setTitle (self, title, event): where the code would actually use "title" and "event" was just for "future use"? right... rarely would a uidriver need the event but it is there if it needs it the question is what will the uidriver be able to do with the event * jcater reminds himself that we are all thinking in terms of GUI drivers but our uidrivers are designed to handle more than just that when it can't rely on what components it has such as braille interfaces, phone scripts, etc remember all those events are generated by the GF layer *** havoc has quit IRC so what's the costs of not passing the event now only to need it later? vs passing it now and not using it it'd force api change right? yes but only for those deriving from _base ui driver as that isn't even a technical requirement knowingly introducing a new parameter *is* an api change IMHO as long as it responds properly to the events in that case, we should likely be doing this in _commonGuiToolkit instead of _base independent of whether the old API differs from the new one *syntactically* or not jcater: my understanding was that _commonGuiToolkit is for UI's that have menus and toolbars and how much overhead would there be in passing events which for example curses doesn#t have either i'm on the fence on this one fwiw curses should but I guess it doesn't right now which is ok I'm not sure curses should have a menu and I'm quite sure curses shouldn't have a toolbar certainly not a toolbar (a menu as in menu bar) a status bar curses has a status bar (not now, but will have, actually) if curses had a menu bar i think it should be hidden most the time accessed via hotkey http://www.gnuenterprise.org/~jcater/screenshots/curses-intro.png is how it used to look jcater: i see this is not really what i was targeting at with curses ui hmm not trying to create a GUI in text mode what were you after? *** havoc has joined #gnuenterprise did you look at what curses looks like now? yes and what do you think? I just assumed it was in early stages of development i think curses should be rather hotkey based than menu based it might help if we could get a screenshot of sql*forms 3 running a form and for example i think there should be no border around the form honestly what's in svn isn't what I envisioned as that eats 2 columns and 2 lines i don't think a border is needed as it was pseudo GUI you could put underlines and boxes on the forms to help seperate jamest: that's what i was trying to say and it was hot key based i didn't want pseudo gui but my memories fade jcater: what was it that you envisioned? reinhard: i think if you don't want menubar in curses, you have to put hotkeys somewhere this takes 1 line too jamest: i can post a screenshot of forms so why not have a menubar? jcater: please i'm not saying jcater's screenshot is what we should have but it will give people an idea of what at I think of when building forms jamest: well, what you're describing is likely a cross between what reinhard wants and what I wanty as his sql forms is the exact same version i used years ago btami: hotkey line gives you the information directly he's like a word perfect user instead of hiding behind a second user doesn't upgrade except once every 25 years but hotkey line doesn't go far jamest: not true *** holycow has quit IRC we've only been unsupported for 10 yrs not 25 my bad this is a big momemt i can't wait the inspiration for forms about to be expressed in a .png jcater: ok, so is it only the menu bar? or is it other stuff, too, that you are missing? reinhard: 1 line for hotkeys is not enough for put all hotkeys in, so menubar is much better IMO i would think once we have a basic (working) ui that people could add it w/ config options what would be the prefered way for users to access the menu bar? alt or fork it and have curses and guicurses btami: with curses? doesn't work that's the old dos showing thru :) jcater: really not trying to offend you *** dimas has quit IRC the screenshot you posted gives me the look and feel of DOS edit.exe or debconf :) *** holycow has joined #gnuenterprise he posted a screenshot? * jamest looks about i didn't get the url http://www.gnuenterprise.org/~jcater/screenshots/curses-intro.png yes, i'v seen tvision and pytvision ajmitch: didn't notice that debconf has a menu bar ;-) i know it's not curses heh * ajmitch will bbl reinhard: what's your target display unit? instead a char based gui reinhard: yes, because of future navigator integration jamest: sorry, i don't understand the question neato jcater: sorry, what question was this the answer for? :) the screenshot you posted gives me the look and feel of DOS edit.exe http://www.ncsmags.com/~jason/gnue/forms1.png http://www.ncsmags.com/~jason/gnue/forms2.png http://www.ncsmags.com/~jason/gnue/forms3.png is old sql-forms it's primary form was like reinhard is doing http://tvision.sourceforge.net/snapUni.jpg but individual form pages could be like what I'm doing and be popup reinhard: what do you see at the target for the curses driver (an xterm window, a vt320 display, other?) and debconf was a model for my colors, borders, etc, btw jamest: in any case not an xterm window *** dsmith has joined #gnuenterprise those screens are what some year i'd like to see forms do with a curses driver though I'm delighted with any working driver today jamest: the sql-forms screens? yes that would cover a lot of the systems I see around town and what is the major difference between current curses driver fwiw, what you don't see is sql-forms has a popup menubar and what you would like to see? for things like point of sale, ordering from local lumberyard, etc banks it seems that around here a lot of sales apps are windows boxes telneted into a unix box yeah a putty window over ssh is also a target platform i am working towards reinhard: give me a minute to pull up the new curses jamest: please don't use intro as a demo switch between pages isn't functional yet if there are no blocks as there is no ctrl-pageup/down in curses available ok i wouldn't hold anything agaist anyone as final :) erm parse error jamest: what does that mean? :) reinhard: regardless, I'm happy to see work on curses ya i want my data sent over ssh. I hope it's not telnet/802.11b (no wep) and you've done a lot slcbjm: no, we use ROT13 over ftp so it'll be safe actually the start of this discussion was that i said that curses doesn't derive from _commonGUItoolkit jamest: *laugh* I store all of my passwords using rot13. Like this one, yrrgcnffjbeq I store mine in l33t 1tsd3r3ksf4ult hmm,that would actually make a good gnue password lol roflmao * jamest needed that jamest: did you start a form with curses? trying people keep asking me to work ignore them like I do well just pulled up my zip maintneance after all my experiences with curses interfaces looks like a positive start we would very soon need user customizable colors :) that's on the todo :) i think jamest: so what is it what you were missing on curses? I'd try to reuse my colors.py from cursing/ it handled custom colors, iirc and wasn't too tied into cursing *** kilo has quit IRC yeah that's very close to what i was thinking of except that i would load color schemes from files maybe reinhard: I think that was my next step jcater: so my question IIRC is still open what else other than the menu bar are you missing from the new curses ui? it's ok as a start I would like the option to run smaller forms in a popup you mean dialogs? like I had done in the original yes ok would make sense have to run *** jamest has left #gnuenterprise I store mine in l33t <-- rofl *** btami has quit IRC night all *** reinhard has quit IRC *** jamest has joined #gnuenterprise *** sjc has quit IRC *** gsoti_away has joined #gnuenterprise *** bluesbaron_ has quit IRC *** chillywilly has quit IRC *** wayneg has quit IRC *** chillywilly has joined #gnuenterprise *** bluesbaron_ has joined #gnuenterprise *** wayneg has joined #gnuenterprise *** GNUe569 has joined #gnuenterprise *** GNUe569 has quit IRC *** holycow has quit IRC *** jcater has quit IRC *** jcater has joined #gnuenterprise *** gsoti_away has left #gnuenterprise *** holycow has joined #gnuenterprise *** jcater_ has joined #gnuenterprise *** jcater has quit IRC *** bluesbaron_ has quit IRC *** jcater_ has quit IRC *** jamest has quit IRC *** jcater has joined #gnuenterprise anyone home? *** jcater has quit IRC