*** reinhard has joined #gnuenterprise *** btami has joined #gnuenterprise *** johannesV has joined #gnuenterprise *** kilo has joined #gnuenterprise *** dimas has quit IRC good morning hi kilo *** sjc has joined #gnuenterprise *** holycow has quit IRC *** cilkay has left #gnuenterprise johannesV: did you manage to look at my sample? kilo, kind of did you start it or could not? i've started trying but haven't really much time to dig into oh, i see i'm currently fighting another round regarding introspection :) your secret love... :) have added support for index-detection to postgres and will start now with it for interbase this year's commit statistics reinhard:476 johannes:381 jcater:273 btami:143 jamest:63 kilo:63 jan:47 dneighbo:15 dhill:1 dimas:1 florin:1 gnue:1 really ? where did you get that numbers from ? hmm, damn, i'm not the number one ... :( *lol* reinhard is first because he has automatic release scripts and he releases every two weeks 8-))) i will publish the script soon *lol* yeah, that's it ... :) johannesV: http://www.gnuenterprise.org/~kilo/contribs.sh.txt *** havoc has quit IRC *** havoc has joined #gnuenterprise *** chillywi1ly has joined #gnuenterprise *** chillywilly has quit IRC *** reinhard has left #gnuenterprise *** reinhard has joined #gnuenterprise bbl *** btami has quit IRC *** kilo has quit IRC *** dimas has joined #gnuenterprise *** johannesV_ has joined #gnuenterprise *** jamest has joined #gnuenterprise hello jamest any gnueing these days? *** stan has joined #gnuenterprise reinhard: yes *** johannesV has quit IRC jamest: cool not as much as I'd hoped for as i need to get datasources looked at *** cilkay has joined #gnuenterprise *** cilkay has left #gnuenterprise what's the standard way of retrieving data from the connection manager? from run() in a GClientApp subclass I'm trying self.getConnectionManager().getDataObject(connection_name, "object").createResultSet() but iterating over it doesn't seem to work. also i can't see any calls to getDataObject from gnue-forms code, so where about should I look to see where it is doing it? stan the datasource wrapper let me get sample datasource = DataSourceWrapper(self.connections, attributes={'connection': self.connectionName, 'name': 'dtsProd', 'table': 'state', }) resultSet = datasource.createResultSet(conditions={'state':state}, readOnly=1) return resultSet after that you can more or less treat that resultSet as a python dictoinary if creating new record you can do invoice = invoiceResultSet.insertRecord() *** jcater has joined #gnuenterprise then invoice['field_name']=value when all done with your changes you post those changes invoiceResultSet.post() then wrap it up with a commit on the connection self.connections.commitAll() --- gnue-navigator is there any documentation about its goals, its principles the general structure of implementation etc? we find gnue-apserver to be in a state where it doesn't need much more for now and considered navigator the "least dangerous" part to hack around in (as opposed to forms, reports or designer where one can really badly break stuff if he doesn't know what he does) (although i think reports is the part that would need more work more badly than others, especially ui integration) anyone ever use sqlrelay? bbl reinhard : i suspect we probably want navigator to be like peopletrees in peoplesoft and i forget the term SAP uses for similar functionality hmmmm we seem to have a problem if we open a record in a form, commit, make a new change, re-commit it'll abort reinhard: i don't think there is a good navigator doc http://help.sap.com/saphelp_46c/helpdata/en/49/2dfe88088b11d396a9006094b9867b/content.htm is a bookmark I made years ago which is what I had in mind jamest: that sounds strange the abort, not the fact that we don't have a navigator doc :) *** sjc has quit IRC jamest: i think i can reproduce here are the steps to reproduce open zipcode.gfd jamest: i *can* reproduce already looking at the problem as am I at least we now have reasonable error messages but this has changed a bit :) ah no you don't use gtk2 so you don't see the traceback in a detail field of the error mesage, right? the problem seems to be that _initialData is None i see the traceback in a popup dialog in wx ah ok *** sjc has joined #gnuenterprise >>> a = {"a":"aaa", "b":"bbb"} >>> x = {}.update(a) >>> x >>> print x None >>> {}.update() seems to not work as expected jcater: can you give a short rationale behind that change? * jcater has to go back and look * reinhard hopes it really was jcater - this was from the back of my brain I really think forms should still dump tracebacks to console I like the popup but think it shoudl do both just mho sucks for tracking bugs jcater: makes a little problems for curses interface however but it's at the uidriver level anyway, isn't it? every uidriver has a function showException where you can do what you want yes exactly in gtk2 we have the traceback in a separate field where you can copy & paste and everything - self._initialData = {}.update(self._fields) + self._initialData = {} + self._initialData.update(self._fields) (of course + and - exchanged) that seems to be the change that broke it undoing it seems to fix it whoops iirc, that was in context of some debugging and I added the old code back only apparently slightly different (and incorrectly) (obviously) I still blame derek that's clear :) dammit derek, stop making jcater break stuff! see, this is why dcl is a bad fit for us anyone commiting a fix for bug tracking or should I i committed * jcater is sure I can pin this on the dcl discussion somehow cool *** sjc has quit IRC *** sjc has joined #gnuenterprise continued on navigator so it basically gets down to a kind of tree control at the left border of a window? that lets you select your forms, reports, or external resources (like web pages?) at the core, it is a way to menu-ize or structure this kind of stuff and lets you create ui's around that but for gui's, I personally like the tree on left approach would we see it rather in the same window as the current form or in a separate window? (speaking for gui's) it lets you embed forms on the right side not working particularly well yet, iirc but basics are there one of the things we haven't addressed yet that's the point i'm aiming at, actually is how it gives feedback on what is running i.e. if I open zipcode.gfd from navigator then go to something else and come back to zipcode.gfd it needs to keep track of that and also account for possibility of multiple copies of each form as well as the fact that navigator seems to have it's own uidrivers (while there is mentioned in the comment that it's a quick hack and should share forms ui) i was tossing around ideas about this yeah one of the ideas was but honestly after working on it myself I'm not sure how much actual code could be shared between forms and navigator other than basic concepts and dir structure as they have two completely different purposes hmmm I'm not presenting that as the gospel just my gut feeling after working in both for a while please tell me what you think about this: in forms, every ui implements a simple tree widget that can optionally be docked at the left of the form like the toolbar is docked at the top navigator is acutally ui-less but opens a form with no controls, but with tree option set this is what the user sees then when user selects a menu item at the left navigator gets called via kinda callback function bbiab...lunch takes the *existing* form instance replaces the (previously empty) GFTree contents with the new contents and passes control back to the form so no separate windows where one is embedded into the other (which seems to make problems technically in some ui's) but only one window -- *** wendall911 has joined #gnuenterprise *** SachaS has joined #gnuenterprise reinhard: how would that work with reports and external apps? one possible way to go could be to have all ui functions in foms basically forms being able to show the menu at the left side and forms being able to show some html instead of an actual form i'm also not saying it's the way we must go but i see quite some overlap between what is in forms now and what would be needed in navigator starting with login handlers error handling and it seems that the "embedding one window into another one" is not so easy hmmmm also IIRC currently a new GFInstance is created by navigator when you switch forms this system would reuse the GFInstance that's correct which could have some effect on performance when switching forms only the connection manager is shared last I looked i think i see where you're going i really need to toss out some other ideas while thinking of them dynamic menus in forms dynamid toolbar ACK access controls in navigator show/hide widgets in forms hmmm enable/disable widgets in forms that's what appserver is about :) how would appserver tell navigator to show and not show options based upon user? well appserver would dynamically generate a gpd based upon user like it now dynamically generates a gfd based upon user (currently, user only defines the language, as we have no access control in appserver yet, but everything is prepared) i dont like dynamic gfd i do like i idea of dynamic gpd in fact currently i have a program that creates them for me based on table data let me restate that i like dynamic gfd for SOME purposes, but on a whole too limiting derek: same here derek: to *have* dynamic gfd doesn't mean to use that *exclusively* cool figured as much as long as it is optional it is a nice feature I'm not sure I get the direction you're talking about for navigator I think it's going to be very limiting, for one *** johannesV_ has quit IRC SachaS are you around jcater: limiting in terms of? what kind of other applications you will be able to embed? you won't be able to embed things outside gnue anyway so external stuff will always be a separate window AFAIU jcater: i would like to understand your concerns if you have time later to discuss bbl reinhard: not so we planned to embed other things too, if possible * jcater is kind of in and out today so having a hard time thinking about this but jamest and I had discussed quite a bit of what we eventually wanted (but neither took notes :) shame shame chillywi1ly: you should be our secretary but don't wear the short skirts lick me *** holycow has joined #gnuenterprise * jcater kicks chillywi1ly * jcater assumes since the k key is next to the l key, you mistyped that ok, jelly donut man pffft * jcater is down 27 lbs so far :) but I miss my donuts tremendously how'd you lose that much weight exercise?!? hacker's diet well aren't we disciplined http://www.fourmilab.ch/hackdiet/www/hackdiet.html my department has actually been doing it my assistant has lost >65 lbs so far weight and hair sound lovely sounds *** jamest_ has joined #gnuenterprise *** jamest has quit IRC jcater: if it is technically *possible* to embed other things into a container (which i am not sure about actually) this could be implemented in forms, too i guess the main point in this idea is to put all ui dependent stuff into a single location instead of having separate uidrivers for forms, reports, navigator bbl again *** reinhard has quit IRC seems to me you are trying to combine navigator and forms into one product instead of being two separate tools did you write a GNUe eact watch jcater ? eat ;P *** wendall911 has left #gnuenterprise *** wendall911 has joined #gnuenterprise *** sjc has quit IRC *** kilo has joined #gnuenterprise *** reinhard has joined #gnuenterprise jcater: not quite I'm trying to merge the UI dependent parts of forms and navigator not trying really asking if it makes sense reinhard: originally, that was my plan but the more I worked on it the more it seemed there was a lot less overlapped than I expected so questioned the advantage of merging (other than just one place for code) hmmm I know that's a vague statement trying to think the other way around * jcater is a tad rushed today :( (but when am I not?) what are the disadvantages of merging ? jcater: basically my problem is i need several functions like a really working navigator a ui for reports and actually i need that in *this* century ;-) so i try to find out a way how this would be really implementable one of the starting points was that this embedding stuff seems to be like asking for trouble I take the point of view that trying to make a form wrapper for a form (in the shape of gnue-navigator) is asking for trouble, myself navigator pretty much works as is can you do input validation with gnue forms? chillywi1ly: yeah but it involves standing over a user w/a whip via triggers? lol navigator works okay for me not perfect, but at what i have looked at it is so different than forms that it appears to be more sensible to make it be a container for forms than a part of forms my understanding is that 1 out of 4 ui's work in navigator however i could be mistaken not counting web ui i'm curious how we'd handle external apps and reports i've got python scripts listed in my gpd files eventually i'd have liked to see navigator run those inside a shell in it's window i'd see no need to handle them different than now not sure if you could embed an xterm window inside a wx window AFAICT "embedding" currently means that gfinstance gets passed form pointer and instead of creating a new form (wx level) it reuses the wxWindow it gets passed I'm not sure if something similar is doable with non-wx based applications afaik btami sees big problems with realizing embedded forms in nav in win32 as does johannes in gtk2, FWIW then I don't see how the other approach would work as how else are you going to encapsulate a form within the other form? short of a similar embedding approach i.e., passing whatever high-level "panel" to the uidriver I think I didn't explain well enough what i think of is handling the tree much like the menu bar or the toolbar no embedding at all how do you handle multiple forms being opened? of course there have to be 2 options to open a form a) by replacing the current form that's in the "main frame" b) by opening up a new window b) would still require a new GFInstance to be created as a separate window with embedded forms now, you can't have more than 1 open can you? I thought so one of the things needing added was tracking what forms were open iirc it can handle > 1 form launched problem is there isn't a way to recall the open ones so its part way done iirc so now if i use navigator and i switch forms using the menu at the left all forms i ever used since starting navigator remain open? so i will have 200 open forms in the evening? (if i do embedded forms of course) if you close the seperate ui it'll close them if embedded then it leaves them open and stores them it just doesn't have the ui to jump back to them which is currently a bug stamp a big IIRC on that not a feature one of the things we were discussing was having the tree show open instances of the form below the actual option or something similar ok now i see how i misunderstood navigator my view was always much like well, take nautilus or evolution with it's folder tree (didn't want to say windows explorer and outlook ;-)) when i want to go to item maintenance reinhard: jamest and I are kde users, so you might have to elaborate :) i click on item maintenance then when i want to modify customers i click on customer maintenance this closes item maint form and opens customer form i've always seen it, and use it as a tool to herd the users everything they need to do is on the left they launch forms and move between open forms via that left menu or run reports, or launch apps the left menu only displays the things that user is allowed to do almost like a combination of the start button and task bar in one and navigator (optionally) remembers the login info so the user isn't constaintly reentering username/password (maybe that's a poor analogy, though) hmmm i start to understand i think so your users have 20 forms open *purposedly* and i guess they don't use embedded forms really well not 20 maybe but > 1 is that correct? yes but I envisioned a flag, too, that could force certain forms to be singleton as there are some that really don't need to be open multiple times but those are generally the exception, not the rule just being curious how long does it take to open a form on the systems your users work on? it takes > 4 sec here with wx an i figure my users wouldn't accept that btw guys, congrats on the latest releases was a while back but ... :) ehe holycow: thanks i'm finally getting a bit of breathing room to actually even check on this * holycow waves to all