*** chillywilly has quit IRC *** chillywilly has joined #gnuenterprise *** holycow has quit IRC *** sjc has joined #gnuenterprise *** mancini has joined #gnuenterprise *** johannesV has joined #gnuenterprise *** Morphous_ has quit IRC *** SachaAway has quit IRC *** mancini has quit IRC *** Morphous_ has joined #gnuenterprise *** drewc has quit IRC *** Morphous_ has quit IRC *** Morphous_ has joined #gnuenterprise *** sacha has joined #gnuenterprise good morning good morning *** wayneg has quit IRC *** jproby has joined #gnuenterprise *** wayneg has joined #gnuenterprise *** kilo has joined #gnuenterprise morning hi kilo hi kilo fw: via lan und dann gateway. so what's new wrt gnue? have been offline most of the weekend wrong window shuold i look at glds or better deal with SachaS' time tracking and billing... *** wayneg has quit IRC SachaS: I've thoroughly studied both UBL and HR-XML recently do you think it would be good to use UBL to define base packages? kilo, on saturday I played with gnue .gcd creation from UBL xsd schemas. i was toying with it, that made me understand the structure of those schemas a little bit more the output of the UBL schema to gnue .gcd is not useful yet as I hit problems pretty soon. what problems? I did also, i am just curious what you encountered if it is good to base gnue packages on it? i dont know. but what I know is that "experienced" people are actively involved in UBL, so I think the quality is better than I could have done without any real experience. problems: for example an element references a type which references a type which references a type. there are like about 4 levels which probably is too much. yes, exactly. you have to dig down and look what the core type is naming is also problematic, they use quite long names then UBL is intended to be used as business documents, which are exchanged between trading partners. a question is if we can just apply it to be used in an application rather than a business document. but it is defenitely worth looking at it. as, maybe one day, gnue must be able to do business 2 business electronic commerce ;) there is an approach that says everything is a document it is like what do tou define to be a document kilo: do you mean even in a business application? yes a record of a customer is a document? ok. it is like the so-much-feared word 'object'. Everything can be defined to be an object. just like that, everything that has data of any kind can be thought of like a document you can transform it, view it, provide persistancy and so on ok. i could ask a UBL member, whether to base a business application data model on the UBL model is a good idea. it is the overhead that can be significant ok. email sent. will let you know his answer. ok so yuo want to track hours and then make a bill based on hours yes. actually i want to have gnue be my desktop :) so i can do everything in gnue (project management, addresses, calendar, notes, ...) i could track hours on a piece of paper, in a text file, openoffice spreadsheet, ... or in a gnue time"thing" application. yes, i was just thinking about my brother who does that solely in Excel... so i want to do it in gnue but I do not know what is the "right" way to do it. so something tells me to not just do it somehow but to try to do it the right way. but ;) a) i do not know the right way, and there might be no right way but more than one right way :) so maybe I should just do it somehow ;) maybe I should just shut up :) did you look at gnotime? not yet. did you? no yet. 8-)) *** dcmwai has quit IRC back *** SachaS_ has joined #gnuenterprise *** SachaS has quit IRC *** jproby has quit IRC *** Morphous_ has quit IRC *** Morphous has joined #gnuenterprise johannesV: what is the exact meaning of pos entry in glds? why are they 100-based? *** evangineer__ has joined #gnuenterprise *** PeterD has joined #gnuenterprise Hi all hi PeterD hi kilo kilo: I'm plying with yours location package ah, no... it is very much unfinished doing some australian locale based on Aus Post Office standards but international input is very much welcome are these standards available somewhere online? I noticed that postal codes and adress will be very country specific yes its a pdf file yes, it is my main concern, this module will be very much needing localization could you plz send it to me yes, what's yours email? in fact the LOC module was developped as one of the first gcd modules. it is a constant headache for me, it should be redesinged completely kilo@gnuenterprise.org What you think obout having some kind of dynamic adress selection dependent on locale? it was built on the old gnue-packages address module and Hungarian semi-standards imho a base address module should be developped and then localization could be made in ways of defining new modules, based on the core address module like there would be LOC.HU, LOC.US, LOC.AU etc that will be good but i need a starting spark or something divine to decide where to draw the limits if I got contact in HU , should select contry and all adress format entry field should be display in hu format for this contact or something like that hmm, that is a good idea, but should be used only with care brb *** kilo has quit IRC *** holycow has joined #gnuenterprise i got some schemas for international addresses (sorry another dead tree): 10:21 nicht viel. fuer mich ist es die Frage ob ich meine Server (web, email, ssh) anhaengen duerfte. 10:21 nicht viel = normal. sorry. i got some schemas for international addresses (another dead tree): http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq *** kilo has joined #gnuenterprise back kilo: the pos attribute specifies the order of the fields in the generated form it's 100-base, so other modules can set their properties in between other's (if they like to) ok, i need time to understanbd that i hate headache... is it gnue which makes you having headache ? *** mixi has joined #gnuenterprise kilo: are you waiting for list-fields in classrepository ? PeterD: received your email, i think it is very useful. thx johannesV: no, i think it ia the weather... and list fields... oh... yes *** mixi^ has joined #gnuenterprise *** mixi has quit IRC ok, kilo, so for what would you like to have list-fields *** jamest has joined #gnuenterprise *** PeterD has quit IRC *** holy_cow has joined #gnuenterprise *** _holycow_ has joined #gnuenterprise *** holycow has quit IRC *** thesandroid has joined #gnuenterprise *** thesandroid has left #gnuenterprise SachaS: what is your opinion about that oasis standarts? *** Morphous_ has joined #gnuenterprise *** Morphous has quit IRC dimas: i am an OASIS member, so I support it. OASIS has an open process, all mailinglists are public, its affordable for a private person (250 US$ per year) to become member, and the specifications are royalte free. whether the oasis standards are useful is another question. for some they are, for some they are not. In my example I became member because I wanted to contribute to the ebXML CPA negotiation technical specification ... *** johannesV_ has joined #gnuenterprise *** johannesV has quit IRC johannesV_: i cant remember now, i can not think due to my headache... but i rememer that we agreed some time ago that it is needed *** _holycow_ has quit IRC :( kilo: if you find any samples of list-properties, please let me know :) johannesV: in locale I see that I have en_AU.UTF-8, what do I have to put into the language attribute of labels tag? also what is the .gld file ending supposed? i will try to revive myself... johannes: in a .gld, what happens if a referenced type is from a different module? SachaS: i have working contact application that i'd like to fix and extend for new install, also need timetracking app. wonder if it would be useful to dig through oasis specs? *** jcater has joined #gnuenterprise dimas: you got a contact application working. there are 2 OASIS specifications I am aware of which have schemas concerning contacts/custmers/parites, this is UBL and Customer Information Quality. SachaS: downloading CIQ now also tutos and opengroupware have contacts, plus there are other open source applications (sql ledger, compiere and xcrms (customer relations ship management)) defenitely having contact schemas. CIQ apparently is very good for addresses. dimas, actually there are lots of screenshots of contact applications where you could double check for any possible attributes, associations. i dont know what the best approach is ... SachaS: i have my own contacts as gnue app. very simple and not tied to any standards and i know what i'd like to fix for next version dimas is your contact app gpl? SachaS: it was done for internal use and never distributed, i could share it here if needed DependencyType="C/O"> i like this one SachaS: from quick look into ciq it seems i'm mostly interested in mapping xcrl screma for db storage and building gnue forms around maybe check with kilo so we get that into a gneu package ... ok *** holycow has joined #gnuenterprise *** bluesbaron_ has joined #gnuenterprise *** bluesbaron_ has left #gnuenterprise *** holycow has quit IRC *** dcmwai has joined #gnuenterprise *** paci has joined #gnuenterprise *** paci has left #gnuenterprise johannesV: if i leave a nullable="false" field empty and commit, I get a traceback in the client but no nice exception window (in wx and gtk2) *** dcmwai has quit IRC *** holycow has joined #gnuenterprise *** holycow has quit IRC SachaAway: reference type: it doesn't matter where a reference-type come from (where it's defined) the ref-type must exist in classrepository SachaAway: locale en_AU.utf-8 formgenerator has the following order: en_AU, en, C in other words: from very special to general if there are no labels (even no C-locale) it will use a default derived from classrepository (although this last case implies no handling of lookups and the like) so it doesn't take care of locale-encoding because everything is treated unicode and get's encoded into UTF-8 (for forms-code) so en_AU.UTF-8 is treated the same way like en_AU.ISO8859-1 or just en_AU SachaAway: nullable=false: i'll try that; but i did some fixes concerning messages (and their translations) today afternoon maybe you svn-up and try again *** nickr has quit IRC *** nickr has joined #gnuenterprise *** SachaS has joined #gnuenterprise johannesV_ I think en_AU.UTF-8 was too long? changed to C ;) would have to try again with en_AU.UTF-8 Sacha: you have to use ok. thanks. i think gnue-common.apps.i18n will give us a proper en_AU although you're using en_AU.UTF-8 but i can try tomorrow yeah actually I have to think of which locale I want to use ;) *** SachaS has left #gnuenterprise as I am no longer in Australia. traceback: there seems to be some issues with translations, but the kind of reporting a server-side exception has not much to do with this so if you do something wired like 'not entering data into a requested field' appserver throws an exception, which arrives at the forms-client but the forms-client doesn't put this into a 'error-message-box' but just re-raises the exception ok. thanks anyway ;) that's all for it; but the error-message displayed in this "distant-Error" should use the proper encoding which it doesn't at the moment since i've translated all messages in common/form/appserver we encounter a lot of unicode-issues (thanks to our german umlauts) :)) i'll dig into this tomorrow yeah was a busy day :) today I have done a todo list in gnue. tomorrow I will do a nice form for it. forms-exception-handling: maybe we can think of hooking into sys.exception_hook and delegate all uncaught exceptions to the ui-driver's ErrorHandler-class then I might check with you how I should model the database for the time tracking thing... ok, great, just send me a mail with the planned app-model (or at least an ERD) well, no, i think if you've got an ERD you won't need me to model your db :)) *lol* :) anyway - we'll have a look at it tomorrow so have a nice evening ! no problems at all. u too. *** johannesV_ has quit IRC *** cilkay|away has quit IRC *** kilo has quit IRC *** kilo has joined #gnuenterprise hi kilo. how is your headache? not gone, but bearable now can try to think now. what should we consider, SachaS? maybe we could both look at a type and then discuss the type... *** Morphous_ has quit IRC *** Morphous_ has joined #gnuenterprise *** SachaS has quit IRC *** SachaS has joined #gnuenterprise SachaS: ok, i just dig into core.gcd *** cilkay has joined #gnuenterprise *** mixi^ has quit IRC *** mixi has joined #gnuenterprise *** sjc has quit IRC *** holycow has joined #gnuenterprise *** kilo has quit IRC *** jamest has quit IRC *** rnoh-htat has joined #gnuenterprise *** rnoh-htat has quit IRC *** Morphous_ has quit IRC *** Morphous_ has joined #gnuenterprise *** holycow has quit IRC *** rnoh-htat has joined #gnuenterprise *** rnoh-htat has quit IRC *** rnoh-htat has joined #gnuenterprise *** whizman has joined #gnuenterprise *** rnoh-htat has quit IRC hi gnue team - i have patched my copy of Forms to fix the spelling of "successful" in "successful query"... Is it useful to provide a patch in diff-u format for a change that might be considered trivial in scope? This is a fix to only one line of python code, but presumably *.po must be changed to match. *** Morphous_ has quit IRC *** Morphous_ has joined #gnuenterprise *** jamest has joined #gnuenterprise *** gsoti_away has joined #gnuenterprise *** Morphous_ has quit IRC *** Morphous_ has joined #gnuenterprise *** chillywilly has quit IRC *** chillywilly has joined #gnuenterprise *** dcmwai has joined #gnuenterprise *** Morphous_ has quit IRC *** Morphous_ has joined #gnuenterprise *** gsoti_away has left #gnuenterprise whizman: I don't think a diff is necessary for that *** rnoh-htat has joined #gnuenterprise *** rnoh-htat has quit IRC *** rnoh-htat has joined #gnuenterprise *** jamest has quit IRC *** rnoh-htat has quit IRC *** rnoh-htat has joined #gnuenterprise *** rnoh-htat has quit IRC re spelling "successful", the updated line of GFForm.py is: self.triggerSetStatusText(_('Query successful.')) Thanks. *** whizman has left #gnuenterprise