|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
/me thinks double entry book-keeping is a bit like XML - when you first look at it, you think it's over-fussy and precise but the more you get into it the more you relalise the power you have by placing restrictions on yourself - actually, that probably describes the GPL pretty much as well
Table Of Contents
Introduction
This Cousin covers the three main mailing lists for the GNU Enterprise project, gnue, gnue-dev and gnue-announce. It also covers the #gnuenterprise IRC channel. A great deal of development discussion for this project goes on in IRC. You can find #gnuenterprise on irc.openprojects.net:6667, or you can review the logs. For more information about the GNU Enterprise project, see their home page at http://www.gnuenterprise.org.
1. Layout manager for GNUe Forms
5 Jun 2002 - 6 Jun 2002 (4 posts) Archive Link: "[gnue-dev] Layout Management and Forms"
Topics: Forms, Designer, Reports
People: Jason Cater, John Lenton, Derek Neighbors
Jason Cater said that layout management was not a priority issue for the "core forms team (myself included)" , as they were happy to use absolute "x,y positioning" . However, other people were interested in layout management, so there needed to be discussion about the best way of supporting this without cluttering "up the forms code or the forms GFParser with support for all the different layout management styles." His proposal was to "Remove ANY positioning tags/attributes from the basic Forms XML schema and implement all positioning using Layout Adapters, qualified by an XML namespace in the XML file" , and he gave some examples. He suggested "A few layout engine adapters would be part of the core GNUe distribution and would always be available. Official apps could only use these core adapters, which of course initially would only be Character (x,y) positioning." . This approach:
It would, however, "break any existing forms. This could be alleviated by adding code in GFObjects that implicitly converts" from the old to the new format, both in Forms and Designer.
He also suggested that the Layout manager concept "might also be useful in Reports" but he had not really thought that through yet.
John Lenton suggested using Cascading Style Sheets (CSS), "because they give us a separate, orthogonal namespace in which to talk about attributes of the widgets and stuff we define in the XML. So do namespaces, but IMHO CSS is cleaner" . He gave several possible file formats. Also, if a designer did use "the 'old-style' absolute positioning attributes" , this would need to be handled consistently too. However, he understood why layout managers was not a priority at the moment.
On IRC, Derek Neighbors (dneighbo) said "at first my gut reaction was what does css have to do with layout - but the more i thought about it, it might not be an all bad idea - as it might address my concern on how to make 'web applications' that dont look normal forms embedded in a browser" . John (Chipaca) said that the whole point of CSS was "to separate design from content - if the idea is that one same form should be able to be layed out in different ways, then CSS it is." Jason (jcater) said "define "different ways" - as I'm not sure we were talking same thing in the emails to the list" . What he was looking for was "adding layout engine support to the GFDs - i.e., allow developers to use GridBag layouts if they want instead of absolute" but "the developer would still have to choose which engine he wanted to use - and code the form accordingly" . Derek said "i think what im thinking that CSS adds is layout separate from gfd - i.e. i slap widgets and such down in the .gfd then let the CSS (or somethign similar) define how they are placed and such" . Jason said he thought "CSS could complement what I'm after - but I still think they are addressing different issues" . Derek said "well layout is relative - mainly i dont want something that looks like a gnue form in the middle of my website/ecommerce site etc - i watn it to integrate into my marketing look" . The GNUe Forms Definition and Jason's layout manager "handles the 'base' layout of where thigns belong in a general sense - and a CSS allows by target to define some additional things" . Jason said he was "not opposed to this - but I think it is separate from what I'm trying to accomplish" .
John asked how the layout manager would work - "Do you need entities to do it?" If so, then XML namespaces would be needed. Jason said that "absolute positioning will use attributes" as at present - other layout managers might need to use entities, but he personally was only interested in the absolute positioning layout manager. He emphasised that "I don't want any layout logic in" the GNUe Forms parser code. He wondered "if there are any CSS parsers for Python" . John mentioned "XIST" .
Later, John noted that Jason's proposal would allow the developer to change layouts, but not the end user. Jason said that was a different topic - "we are not talking "what color will this widget be?", "what size will this font be?"" but the fundamental underlying layout of the form, which had to be the developer's responsibility. Derek said that, with web-enabled applications, you might want to split form/logical design from layout design. He agreed with Jason that there were two separate issues here, but hoped there might be a clever way of resolving both of them together or in similar ways. Jason said "even if you separate layout logic into separate files, you have to have a way to denote the relations between the locations of the objects" . He agreed "we should be able to support multiple "layouts" of the same form using the same GFD - but I'm trying to address how to denote the layout (wherever that layout is located)" .
2. Changing widget attributes at run time
5 Jun 2002 Archive Link: "[IRC] 06 Jun 2002"
Topics: Forms
People: James Thompson, Marcos Dione
Continuing Issue #32, Section #9 (30 May 2002: Customising the main tool bar and menu bar in Forms) , James Thompson (jamest) said that Marcos' supressible toolbar widget was similar to ideas he had had - "i wanted to add visible attributes to lots of stuff in forms" including the toolbar. This would allow the toolbar to be switched on and off using triggers, and "hiding a toolbar would have same syntax as hiding a entry widget - consistancy is a good thing :)" Marcos Dione (StyXMan) asked "why wait till code is run? set the toolbar optional by tag or attr. Easier, and more consistent for the developer." James explained "because all the other widgets will work like this too" . Marcos certainly liked the idea of being "able to do things to widgets @ runtime" - not just visible/invisible, but also enable/disable. James said that Marcos' "work w/ the toolbar would make this easy to implement" . Marcos explained how this would work, but noted "defining your own menubar must be done by xml, not triggers." James said that "the self attribute in triggers" was not currently working, which made triggers and trigger libraries less useful "if they have to have hardcoded references" . However, it had been some time since he had looked at this.
3. Using <option> tags to support optional widgets
5 Jun 2002 Archive Link: "[IRC] 06 Jun 2002"
Topics: Forms
People: James Thompson, Jason Cater, Marcos Dione, Michael Maluck
Reprising Issue #32, Section #29 (4 Jun 2002: Maintaining UI independance whilst allowing custom widgets) , Marcos Dione (StyXman) said he was not keen on using the <option> XML tag to hook in non-standard widgets - he would prefer to use attributes on tags, or even allow new tags for new widgets. James Thompson (jamest) said that GNUe Form Definition (.gfd) files used to support "attributes in several different" ways - both "<tagname attr="foo"> or <tagname> <option name='attr'>foo</option>" had been supported - however, "we ended up scrapping that old way" . Also, the <option> tag had at one stage been used for multi-line code like triggers "however triggers ended up different anyway :)" . Jason Cater (jcater) noted, however, that <option> tags were still used to "assign non-standard properties to objects in forms that can be retrieved in triggers - that's why I don't want to get rid of options" completely. He agreed, however, that "in the cases where an option replaced a standard tag, I've never been really thrilled" .
Marcos understood the need to keep the <option> tag for this, but did not see how it would link to the GFOption object that would handle it - as there was usually a one-to-one relationship between Forms XML tags and Forms objects. Jason said the <option> tag worked differently - "all objects have a getOption() method that retrieves any <option>s set on it - so basically, any non-standard attributes would be options" . However, "there will actually be a GFOption object implicitly created" .
Marcos asked how the <options> and <option> tags would interact - "I realize that <options> is for gouping <option>s together - but how does a <options> gets related to its parent?" . The GNUe Forms Parser code implied that all <option> tags were children of the <options> tag, which was a child of the overall <forms> tag. Jason said "the GFParser file isn't quite correct."
Michael Maluck (madlocke) re-expressed his preference for "a way to add new tags" for new widgets " but still being able to create valid dtds" , as this would make the XML more understandable. He was not sure how this would work, however - it might be better to "delete all options, because options force men to make up decisions ;)" He said "it's like with mirrors... when you look into it, it will always show you. you can't tell the mirror to show something you want to see. there is actually no option ;) - but ok you have the option to destroy the mirror ;)" Marcos felt "wowo, that was deep. you'll teach me zen?" .
Later, Marcos said that, for common <option>s such as tooltips, having to re-write the code to handle it each time would be a pain - "you'll try to move the tooltip code to a class" , and part of the core widgets. Other <option>s would be more one-offs. "I guess the answer is: no, don't do it in general. that's what jcater or jamest said yesterday - do it case by case" . Michael said "i understand their complaints about new tags/attrs that are not in the core very good" , and he needed to give some more thought to the best way of allowing optional widgets - he did not want to end up with unofficial patches or an unsupported fork.
4. Multi-select widget in Forms
5 Jun 2002 Archive Link: "[IRC] 06 Jun 2002"
Topics: Forms
People: Marcos Dione, Jason Cater, James Thompson, Derek Neighbors, John Lenton
Marcos Dione (StyXman) asked if there was a "multiselect widget" . Jason Cater (jcater) said "not yet" . He added "we need to think thru how we want it handled - it'd be a block style" . Marcos did not see why - he was talking about being able to select multiple records for a single field. Jason said he was "thinking of "fallback" - i.e., what would a UI driver fall back to if it doesn't support this nifty new feature" , especially how you would "tie that directly to a datasource?" .
James Thompson (jamest) said that "the one thing that sucks about putting it in a block is navigation - as I have a similar need that I do via a block of dropdowns" . Jason said "I need something similar too - so I'm not arguing against such a thing" . Derek Neighbors (dneighbo) said he thought a good form dialog was more important, as "i dont need the multi select really 'in' a form but rather as a 'utility' to rapidly assign data" , creating many to many relationships between the primary keys of two tables via a switch table - "once assigned it can be displayed in grid" . Derek and Marcos traded some practical examples of this. Marcos said, in his particular case, he "would prefer a muktiselect list box" as "the options are just a few in this particular case" . John Lenton (Chipaca) suggested "if they're really few, surely checkboxes are better?" . Marcos said that checkboxes existed, but it was not always easy to get the data back in the database from these.
The next day, Marcos said "I'm gonna do a listbox" , and asked "should I just extend entry or better to add a new class?" . James confirmed that all the entry widgets were "all <entry> tags with a style" . Marcos said the box would start off single-select, but would eventually support multi-select.
5. GNUe Navigator development and testing
5 Jun 2002 Archive Link: "[IRC] 06 Jun 2002"
Topics: Navigator
People: Derek Neighbors, James Thompson, Jason Cater, Bajusz Tamás
Derek Neighbors (derek) did some testing of Navigator. James Thompson (jamest) noted that menu line entries in the GNUe Process Definition (.gpd) file - the standard file format for Navigator - now supported both <title> and <description> tags. He confirmed that using Navigator to launch both Reports and non-GNUe applications was still supported. Derek noted that "image works now - about box doesnt work" . James said the "menu doesn't work yet at all - it's only there for looks at this time :)" Navigator also "does single login for multiple forms - which is nice" .
Later, Derek posted some screenshots to the website for the " navigator open screen" and " navigator in actoin" . Jason Cater (jcater) said that the web version of Navigator "should be working" but he had not "tested it out in last day or two" . It was not as advanced as the Navigator full client yet, however.
The next day Bajusz Tamás (btami) asked "is there any special reason navigator uses treecontrol instead of classic menus? in a main window?" . He explained "some users (accountants) hate using mouse - and a main window with menus is maybe simpler" . James Thompson (jamest) said that "the tree can be navigated via the cursor keys - and we're just trying things out to see what people think" . Bajusz said that he did not like having two windows - one for Navigator and one for the form. James explained "navigator can launch forms, reports, executables - anything you want really - I have mine here launching IIRC perl scripts" . He added "just remember though we're still very much so playing - so if you want to see something just describe it" . His users needed to be able to "have multiple forms open at same time" , which is why he personally preferred the new layout to earlier versions of Navigator. Bajusz suggested "1 main window with menubar(navigator) - and forms,reports are the child windows in it - like excel opened with more then one xls" . James thought this was "an interesting idea - may have to do some more playing" . He noted that "navigator takes ui drivers - so nothing prevents us from making something like that in it's own UIwxmdi.py" . He said "the entire UI system is under reworking - we need to start a wishlist" as "I really would like to get most the UI stuff nailed down this next release" .
Later, Derek Neighbors (dneighbo) thought Navigator was "giong good though im not sure of two things - a. why its dual paned - b. that we cant make gpd's load into menus if we so desire" . This second option would be useful for curses (text-only) users "or people really liking deep ugly menus :)" .
6. Nola as an alternative to GNUe Financials for fund accounting
6 Jun 2002 Archive Link: "[IRC] 07 Jun 2002"
Topics: Financials (Accounting)
People: Andrew Mitchell, Derek Neighbors, Peter Sullivan
Andrew Mitchell (ajmitch) asked "anyone know of any small/medium business accounting software" ? Derek Neighbors (dneighbo) suggested "nola - its not gnue but well - its accounting that looks promising to do some gnue stuff too" . Peter Sullivan, remembering Issue #26, Section #7 (21 Apr 2002: Nola - free alternative to GNUe Financials?) said that Nola was "a LAMP application (Linux, Apache, MySQL, php) - screenshots look moderately sophisticated (but then so do ours) - jcater downloaded for a look-see, you might want to ask him when he wakes" . He noted that "there's an online demo" on their website. He felt the "look and feel isn't terrible, isn't wonderful - and being GPL gets you lots of gold stars in my book ;-)" . Andrew said he "would still like something GNUeish tho - web-based is ok but not ideal for things like printing reports, invoices, etc" .
Andrew said he "doesn't like NOLA's UI that much" . Peter felt it was "LAMPish" . Andrew said that "DCL could be called LAMPish, but i think it has a better UI - so does phpGW" . Derek said that "nola is far from perfect BUT i think its far enough that its a decent start - and it would be worth building gnue screens for and such" . He would "probably get gnue screens for it" .
Derek said he would probably do some work on Nola to "make it support fund accounting" , so that you could record separate funds "with self balancing set of accounts - usually used to observe some restriction or limitation of resources" . This was a fairly common requirement in the US government sector, but he would be using it for church accounts, where there were separate funds for different church purposes - "only instead of having a ton of bank accounts you have paper (or virtual) ones" . Peter said he had seen similar set-ups, where "each directorate has own balance sheet - but the "Cash" figure is not real cash - just their share of the central balance sheet" . Derek said "generally every fund has assests, liabilities, fund balance" . Peter said "I keep wavering as to whether this is a good idea" in cases where it was not a statutory requirement, as "the control aspects can be done w/ good row security" instead.
7. Re-coding or re-using GNU-RPC on other projects
6 Jun 2002 Archive Link: "[IRC] 07 Jun 2002"
Topics: Common
People: Dan Kuykendall, Jan Ischebeck, Jason Cater, Derek Neighbors, Dan Bethe, Peter Sullivan, Bradley Kuhn
Dan Kuykendall (Seek3r) asked if there was any documentation on GComm (GNU-RPC). Jan Ischebeck (siesel) said there was some preliminary documentation in CVS. Dan said he was "building some code in php to support xml-rpc and soap in much the same way. if you already have things defined then I can look at doing mines much more like yours" . Jan said that, as of time of writing, it was too early to decide "which functions should be made general available for all drivers and which are private functions." Dan said "Im mostly concerned with the basic functions developers wanting to the the GComm are supposed to use. Like what they do to start the client, how they package up their params (selecting data types), and how they make the calls, and then how the return comes back. Ditto with creating a server. how they add functions, how they are documented. If I can make mine look like a port. so that it basicly matches, then it will be more generally consistant. Syntax will be a little diff because of the diffs between python and php" . Jan said "ok, thats quite easy. the only difference between python and php implementation will be" that python would allow you to "just request an service object and then all method call on that service object will be transparently executed on the server" as part of GComm. Dan said he could "do the same with php" .
Jan said that, as of time of writing, "the api is quite simple: client: 1. atach(interface,options) 2. request('servicename') 3. transparent calls" . As it was not web-based, it used its "own socket port" . Dan said he could not do this, "Since in PHP I am stateless. I have to wait for the web server to kick me into life" . Jan did not think this was a problem - "It just means that you have to parse the description file one time per method call ;) - or you keep a preparsed file in a php file" .
Dan asked if GComm could detect incoming requests using different RPC protocols, and select the appropriate driver. Dan and Jan worked through some examples. Dan concluded that, in php, he would have to do direct access in a different way to the python-based GComm. There might be problems detecting what type of object was being sent, but "if they use this future GTypeCast, they will be giving you an object that you can then get the type and data from" - this could also be done in PHP. He asked if the data returned by an RPC request was automatically converted into python variables. Jan confirmed this. Passing multiple parameters to a function would have to be done differently in PHP to python - although PHP version 4 could do it the python way, Dan needed to use PHP version 3 for GPL compatibility. Jan said he would be prepared to change the way the python-based GNU-RPC worked, provided "it doesn't means changing heaps of code" .
Dan asked whether "GComm and GNUe RPC are two different things?" . Jason Cater (jcater) said that "GComm was the original working name before any coding was done" . It was now interchangeably referred to as GNUe Common, GNU-RPC or GNUe-RPC. He emphasised that it was "only one implementation - the "standard" or "proposal" can be called whatever - but our implementation I'd think we would call GNUe-Something" . Dan confirmed he was "gonna try building a PHP version today with the xml-rpc driver" for use on "the new web services I am developing for DotGNU" .
Later, Derek Neighbors (dneighbo) said he did not "see the value in spending time REPLICATING gnurpc for every language" but would prefer to "rather see someone wrap the python so php could use it" . This was "not a python is right everything else is wrong thing - its a why write same code over and over in diff languages only to have to maintain it?" .
Dan Bethe (dtm) noted that Dan Kuykendall was "currently redesigning" phpGroupware (phpgw) "somewhat to decouple the server and client and to make it language neutral - not requiring php" . Dan K. was keen on working with GNUe, but Dan B. felt there had been some communication issues. Peter Sullivan (psu_) noted that "GNUe Common was named GNU-RPC precisely because it was meant to be usable by other projects" . Dan B. said that Dan K. "still wants to collaborate - and collaboration will probably be greatly enhanced by his rearchitecture" . Derek noted that, although it was not quite the same issue as phpgw using GNU-RPC, two separate people had started writing GNUe Forms clients in php, "and after grokking common" decided to use (and in one case, help to develop) that instead. It was much more than "merely data abstraction (ala PEAR or PERL DBI or libGDA)" - "its complete programmer abstraction" including features "like handling master detail relationships adn complex queries and foreign key look ups and the such" . He felt that there were several ways of working with phpgw, depending on what Dan K. wanted.
Peter noted that "we were going to make that one-off meeting in #gnuproject" (Issue #5, Section #11 (26 Nov 2001: The GNU Project - Meeting of the Minds) ) "a regular thing - but everyone is too busy" . He had done a prototype web page for it. Derek said "i will look if i have time at this - and try to reconvene a meeting - as i think there are several thigns for the agenda" . He was keen to keep the various business-related GNU projects working together. One key issue was "where GNUe is at with its rpc abstraction - as there is definitely prototype stuff there" . Dan B. said that phpgw's recent change in architecture meant that they would become more interested in "broad interoperability" . Derek said he needed to speak to Bradley Kuhn.
8. Free accounting packages for SMEs and Chart of Accounts design
7 Jun 2002 Archive Link: "[IRC] 08 Jun 2002"
Topics: Financials (Accounting)
People: Nicholas Lee, Peter Sullivan
Nicholas Lee (esands) said he was not aware of any "SME open source business (accounting) software avaliable at the moment" . He added "For myself I'm using gnucash at the moment. Only thing else out there AFAIA is sql ledger and maybe nopa. Not sure how good nopa is. There are all pretty hacky." . Peter Sullivan (psu) said that a simple General Ledger (GL) would not take long to write, but "a GL w/o Purchase and Sales Ledger is fairly pointless" . Nicholas said he "was hoping gnue would be RAD enough for me to hack together some tools I could us in my businesses. Not quite there yet." .
Nicholas agreed that "GL is pretty straight-forward. Dealing with the complications of multiple GLs and business logic is obviously harder" . Peter said that "GL is really just a big dustbin where you can store things to find 'em later - All the fuss over data warehousing - Accountants have had them for years - we just called 'em General Ledger" . Nicholas felt "The operative word is "hope" to find then later.... Isn;t it? ;)" Peter replied "not if you have a good enough chart of accounts" . He personally "prefers Chart of Accounts formats that cannot be depicted in real space - i.e. at least 4 dimmesnions of analysis" . Nicholas said that, for small to medium enterprises (SMEs), a "4.2 code GL is good enough" . Peter suggested "keep the posting codes short - and build the reporting logic via parent-child relationships - one less keystroke on a million transactions is a million less keystrokes ;-)" Nicholas agreed - especially "when I've been the one punching though codes at times. 8)" .
9. Free Java
7 Jun 2002 Archive Link: "[IRC] 08 Jun 2002"
Topics: Why GNUe?
People: Perry Lorier, Peter Sullivan
Reading Issue #32, Section #1 (27 May 2002: Freedom issues with using Compiere as an alternative to GNUe) , Perry Lorier (Isomer) admitted he risked a large debate, but asked "why people believe Java is so evil? there are GPL Java compilers/runtimes no? you can write GPL Java code? /me fails to see why it's non-free?" . Peter Sullivan (psu) said "you can wriite GPL Microsoft Acess - but you still have a non-free dependancy" . He noted "well, there are definantly no free Java compilers/runtimes - since to be Java, you have to be licensed by Sun - but there may be "java-like" or "java-compatible" ones" .
10. DCL - more than just a bug tracking system
7 Jun 2002 - 10 Jun 2002 Archive Link: "[IRC] 08 Jun 2002"
Topics: DCL
People: Perry Lorier, Peter Sullivan, Derek Neighbors
Perry Lorier (Isomer) asked "are there any reasonably complete GNUe "apps"?" . Peter Sullivan (psu) said that DCL was "part of the GNUe family but not yet part of the GNUe architecture - although there are some GNUe Forms that work w/it now it's still mainly a php app" . It started as a bug-tracking system, but was "evolving into general project mgt / contact management / multi-user to do list application" . The GNUe Project's DCL server was set up for read-only guest access "if you want a look-see ;-)" .
Some days later, it was asked whether DCL would be a drop in program for a typical helpdesk. Derek Neighbors (derek) said "i think its a stronger projects/work order system than a help desk - but i think it does helpdesk ok - and you have the code :)" . GNUe and DCL had now merged (as discussed in Issue #19, Section #14 (5 Mar 2002: GNUe/DCL merger announced) ), and "currently we are gutting the contact management for next realease that will be the base for a gnue crm that fsf will be using - already in cvs for working version there are gnue screens" . He was also using GNUe Reports with it as well. Later, he pointed to "a screenshot of a gnue'ized dcl - going against production dcl data" .
11. GNUe Application Server API
7 Jun 2002 Archive Link: "[IRC] 08 Jun 2002"
Topics: Application Server
People: Jan Ischebeck
It was asked why geasList had a geasSession field when geasInstance did not. Jan Ischebeck (siesel) explained "because geasList needs access to geasSession to get an GConnections object to create a list. geasInstance don't need that." This meant that loading an instance or creating a new instance had to be done "over the list object" . The reason for this was "to move the resultset / row paradigm into an api. so you have to retrieve an object list, before you can get single instances." He explained that the current release of Application Server was "a (minimal features/as soon as possible production ready ) version of appserver - I hope that the overnext version will support much part of ODMG standart."
12. Problems with floating point fields in PostgreSQL
9 Jun 2002 - 11 Jun 2002 Archive Link: "[IRC] 10 Jun 2002"
Topics: Common
People: Marius Gedminas, Derek Neighbors, Jason Cater
Catching Derek Neighbors (dneighbo) on a late night rush after Team USA got a lucky draw against South Korea in the soccer World Cup, Marius Gedminas (mgedmin) asked "if someone's working on problems with PostgreSQL numeric types - (SQL errors like "operator = not defined for numeric and double") (when trying to update a record containing a numeric field)" using the psycopg database driver. He reported "basically postgres wants explicit typecasts in statements like UPDATE employee SET foo=bar WHERE numericfield=123.4::numeric" . Derek was able to reproduce the bug - "someone has introduced a bug in cvs OR the pyscopg driver in sid has been changed - as when i ran this form before" the form had worked. They both tried various alternatives, including =1, ='1' and =1:numeric. Marius confirmed that his PostgreSQL reference book implied that it "wants a typecast when it sees a numeric type in the WHERE part" . He confirmed that "it works fine when you try to add new records - it fails when you try to update them - or perform a query (no error messages, but no results either in that case)" . He gave the workaround he had developed - "I don't like that though" . Derek agreed - "if it chokes other db's it needs to be in the postgres driver" and not in the GNUe code. He asked Marius to submit it as a bug, and the workaround as a possible patch, pending an "official patch" .
He noted that there was no problem with integer fields, which had previously been the case - fixing this had apparently "fried the float numeric type" , but only for PostgreSQL. It also seemed to matter whether floating point fields were referred to as 100 or 100.0. He could see several issues emerging here, and felt it was "best to address" the next day - or more, accurately, later in the same day after some sleep!
Later, Jason Cater (jcater) said he was not impressed that PostgreSQL could not "handle implicit numeric conversions" . He felt that getting the database driver code to check for specific numeric types and do the conversion itself if necessary "may not be too hard" but if it meant "we have to do full-on introspection at form load time" to check the types of all numeric fields "that could be a big performance hit" . Derek said he "hopes this is a postgres bug, but doubts it - as i have postgres 6.5.x here and it does same thing" . Jason felt "any "reason" they can provide is a technical one that should be hidden from SQL users" .
Marius pointed out that "forms currently perform the updates by constructing an SQL statement and listing all fields in WHERE clause. Is there a way to use only the primary key instead?" Jason said "that's something we need to look at" . For most databases, "the database's "row id" is used - IF the database supports such a thing" . However, in PostgreSQL 7.2 and higher, "oid's are optional" .
There was some discussion about whether this, and the numeric conversion problem, were desirable or not. But, as Derek noted, "postgres is a db people will be using, we need to support their quirks whether we agree or disagree with them" . He suggested changing Forms to identify different types of numeric field separately. Jason said he "was trying really hard to avoid that - as it goes into support issues I didn't want to deal with" . Derek said he did not like it either, but the only other way of resolving the issue was to use database introspection to check the exact type of numeric fields every time they were used.
Some days later, Marius suggested resolving the issue of having to list all of the fields in the WHERE clause of an update query by having a 'key' attribute against each entry field on a form - "and the SQL query should only list fields with key==TRUE in the WHERE part" . Derek said he was not sure of this - "all too often people dont make proper keys" . Marius felt that "imho the union of all fields in a block is less likely to be a proper key than a developer defined set of fields" . Jason said he had "purposely avoided that approach" in the past. Given that "we're gonna have to do a quick schema lookup on form startup" anyway "so we can solve these numeric issues" , the code might "as well as get the primary keys if defined - and fall back to using the whole record if a table has no primary key" . This was not ideal, but "would solve several issues at once" .
13. Developing and testing GNUe
9 Jun 2002 Archive Link: "[IRC] 10 Jun 2002"
Topics: Forms
People: Derek Neighbors
Derek Neighbors (derek) said "one should be able to do useful things with gnue w/o being a GNUe developer - BUT - i think they need to be a developer of some level to do something - i.e. they shouldnt have to be a GNUe tool developer, but they should have application development experience" . For testing, "currently i have like 3 forms i use to 'test' things - as i find forms that 'break' things - i try to shovel them into my 'test' suite" . He wanted "to look at unit tester that will test functions of GNUe w/o actually running forms - at some point we will need to build or find a free test suite to automate testing" since "as more people start to bring GNUe into production the more important test suite will come" .
14. Updating dropdown entry lists within Forms
9 Jun 2002 Archive Link: "[IRC] 10 Jun 2002"
Topics: Forms
People: Aditya Gilra, Derek Neighbors
Aditya Gilra (aditya_gilra) said "we're trying to change the list of values in a dropdown entry from a trigger" and asked how to do this. Derek Neighbors (derek), referring back to Issue #32, Section #27 (3 Jun 2002: Look-up combo boxes in Forms) said "this is known issue" , as "the dropdowns get loaded at start time only - it is a problem for others as well, we have started to discuss best way to handle - as we dont want them updating all the time as that could be a large penalty hit" on performance. No real conclusion had been reached yet.
15. Scrollbars for grids
9 Jun 2002 Archive Link: "[IRC] 10 Jun 2002"
Topics: Forms
People: Marcos Dione, Derek Neighbors, James Thompson
Marcos Dione (StyXman) noted, as previously discussed in Issue #20, Section #13 (12 Mar 2002: Wizard changes in Designer) , that the code for scrollbars was currently empty, and asked for suggestions. He was "thinking in a kind of block, that could have any amount and kind of entry's - you then say how much rows want to see at once, and the block should pass that info to its childre, i.e., the entry's" . Derek Neighbors (derek) said "that was jamest original intent iirc" . James Thompson (jamest) confirmed "my quick and dirty scrollbars were going to do - look at the block/datasource to get record count and based upon the rows (visible) set the size of the scroller - then set the up/down of the scroolbar to only really do a next/prev record event - after each next/prev event have the scrollbar look at the top visible record and adjust the scroller position to be about right." Everyone encouraged Marcos to try some code out with his own ideas - Derek even tried some reverse psychology on him.
16. Perl and GNUe
10 Jun 2002 Archive Link: "[IRC] 11 Jun 2002"
Topics: Common
People: Derek Neighbors, Jason Cater
It was asked whether there were perl bindings for GNUe. Derek Neighbors (derek_) said "yes and no - i expect that the trigger engine" in GNUe Common "will eventually support perl if someone writes the perl hookup" . Jason Cater (jcater) suggested looking "at zope's Perl Script support - as they have perl bindings for python" . Derek emphasised that "we are not against such a thing but are limited on resources so its not high priority as of yet" . For people with an interest in writing forms-like interfaces in perl, he recommended entity - although it had different goals and hence was not as database-orientated or cross-platform as GNUe.
17. Properties box in GNUe Designer
10 Jun 2002 Archive Link: "[IRC] 11 Jun 2002"
Topics: Designer
People: Derek Neighbors
A problem with Designer was reported - it's was not letting users edit anything in the properties editor. Derek Neighbors (derek) said that was a known wxPython bug - "make the property editor big enough the scroll bar goes away - and then you should be able to edit" . If the object has too many properties for the screen size even when maximised, Derek suggested "um virtual desktops :) - thas how i solved it" .
18. Defining the dependancies between GNUe Packages
10 Jun 2002 Archive Link: "[IRC] 11 Jun 2002"
Topics: Base
People: Derek Neighbors, Jason Cater, Neil Tiffin
Derek Neighbors (derek) asked for feedback "on packaging and such" . He had discussed this with Neil Tiffin (neilt) on several occasions, including Issue #15, Section #7 (4 Feb 2002: Private GNUe applications and GNUe Templates) . The issue was that "packages have overlap - dcl for example needs contact info as would say invoicing (vendors) etc etc etc as would salesforce automation - but each needs 'varying' degrees." At one time, a "base" package had been proposed, "but do to do that schemas and such would have be done properly to break apart and such" . With the work going on to add contact management to DCL and for the Free Software Foundation (FSF), "then maybe its time to do it more 'officially'" .
He was not sure of the best approach, but expected to need "something like apt/dpkg only specifically for gnue to manage dependencies and such" . Jason Cater (jcater) said that he had not thought about it much, "and my mind thinks in relational, 2-tier fashion" . Derek said that the same principles of packaging would apply to n-tier applications using Application Server. Jason pointed to a very old document of his - "but that only addresses updating schemas - not dependencies/conversions/upgrades" . Derek noted that the document had neatly predicted the need for a database-independant way of creating and updating database schemas, which they now had with the DCL schema generator that used XML. This could be expanded to include not just the data about what tables and fields were required, but also meta data about dependancies "to say when to use what - obvioulsy its vastly more complex than this - but its a start" . Jason said that the existing XML parsing code in GNUe could be used "so you could have a "pre-install" trigger - and a "pre-dependency-check" trigger :)" .
19. Widgets on resized forms
11 Jun 2002 Archive Link: "[IRC] 12 Jun 2002"
Topics: Forms
People: Marcos Dione, James Thompson
Marcos Dione (StyXman) asked "why forms 'drops' widgets that would be outside the current form?" . "they don't appear, even if I resize the form manually (i.e., with the mouse)" . James Thompson (jamest) explained that "the form size is set at startup time via it's height and width - it doesn't bother to create UI widgets for anything outside that set size" . Marcos said that now he was hoping to add a scrollable widget, this might need changing. James had "never considered putting widgets inside a scrollable widget" , but looking at the code he could not see why this would not work, and explained how to test in the code whether a widget was created or not. Marcos reported "the widgets get created, but the ones that 'fall' off window's region are not shown..." . James said that the User Interface driver must not be re-sizing the container widget when the form was resized. It might be possible to write code to do this triggered by "onsize event" .
20. Entering null values in numeric fields
11 Jun 2002 Archive Link: "[IRC] 12 Jun 2002"
Topics: Forms
People: Marius Gedminas, Chad Walstrom, Derek Neighbors
Marius Gedminas (mgedmin) asked "suppose I have a numeric field in the database and I create an entry field in a form - can I enter NULL values into the db by leaving this field blank?" Chad Walstrom (^chewie) suggested logging this as a bug in DCL if "you don't find it in the current bug database" . Later, Marius reported "ah, solved the issue with nulls - apparently empty entry field is stored as NULL in the db if it is typecast as "numeric"" . In his case, "a couple of my field were missing that typecast" . Derek Neighbors (dneighbo) asked Marius to close the ticket in DCL for the issue "so jamest knows what you did and can look to see if either a. there needs to be a fix b. there just needs to be better documentation" .
21. Creating a fixed number of child records for a parent
11 Jun 2002 Archive Link: "[IRC] 12 Jun 2002"
Topics: Forms
People: Marius Gedminas, Derek Neighbors
Marius Gedminas (mgedmin) asked "suppose I have a master/detail form where for each master record there is a fixed number of detail records" . How could he create the empty detail records when the master was created, so that they just needed editing. Derek Neighbors (dneighbo) said "i think it can be solved via master/detail hookup along with triggers" . Marius noted that this "is basically the same as ticket 58" in DCL.
22. Using docstrings in python
11 Jun 2002 Archive Link: "[IRC] 12 Jun 2002"
People: Derek Neighbors, Jason Cater
It was asked why GNUe's python source files had # comments at the start of each module rather than proper python docstrings. Derek Neighbors (dneighbo) thought "we really should be using doc strings - so that we can build things with pydoc or happydoc" , as previously discussed in Issue #32, Section #13 (1 Jun 2002: man and info pages for GNUe) , but "we dont want code to be littered with documentation i.e. the source is not hte place for the api manual" . Jason Cater (jcater) felt that "docstrings REALLY reduce the readability of the code imho" . Derek said "im thinking happydoc actually works with # stuff" . Jason agreed. Derek said that a file generated from happydoc could form the shell of the API documentation.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |
