Just one thought in this thread regarding a future gui interface. Keep in mind that others will want to port pspp to other architectures, in my case, OS X with the Quartz gui architecture. Hopefully any decisions you make won't be too tied to a library set that will make it very difficult when porting to another gui environment. Marshall
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Darrington Sent: Tuesday, October 25, 2005 12:38 AM To: Ben Pfaff Cc: [email protected]; John Darrington Subject: Re: [Pspp-cvs] Changes to pspp/src/algorithm.c On Mon, Oct 24, 2005 at 08:38:06PM -0700, Ben Pfaff wrote: If I recall correctly, you're aiming to produce import/export filters for OpenOffice (or related software). I don't know whether a library is the best way to do this, at least for now. Separating out the necessary code may be difficult, and the result may be ugly. Gnumeric import/export filters is certainly one purpose. But also makes a gui easier to develop. If we don't have a seperate libary, then the alternatives are: a) have the gui inextricably entwined in the pspp code; or b) Duplicate large parts of pspp internals in the gui. Furthermore, if the library is to be used by external code (not just by code in the PSPP codebase), then it commits us to a particular ABI, so that if we change internals that the library includes (and we certainly will), then it breaks the external code. The latter is what really worries me. I really don't want to commit to any ABI now. I agree that perhaps it's premature to make that commitment now. But I don't think it's a bad thing to do ultimately. And if we can do that separation now it'll be easier to think (at least for me) how an ABI ought to look. So my suggestion is that we should really do one of the following: 1. Separate the library but only use it within the PSPP source tree. Use it to write program(s) to convert PSPP file formats to/from other formats. or 2. Add PSPP command line syntax that causes PSPP to just do a file conversion and exit, when invoked as e.g. `pspp --convert --from foo.dat --too foo.xml'. That way we don't even have the separate the library. I think I prefer #2. What do you think? For a gui I think #2 would be unworkable. It would have to open a pipe and do a conversion on every button click, expose event etc. Even if we had a multithreaded application and could cope with the latency, there'd be a lot of code to parse some internal gui format which wouldn't be used for anything else and would be quite ugly. I'd much prefer #1, and let the gui make a simple wrapper around the pspp objects (eg dictionary) which can emit their own signals. Let's just define the "PSPP source tree" to include the gui. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://pgp.mit.edu or any PGP keyserver for public key. _______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
