f.fracassi at gmx.net
Wed Jun 13 03:50:41 PDT 2001
On Wednesday 13 June 2001 04:44, Jesse Tie Ten Quee wrote:
> On Tue, Jun 12, 2001 at 07:52:24PM -0700, Andy wrote:
> > That opened up a nice can of worms, there :)
> No worries thou, this was going to happen one way or another, at least
> now it's open to discussion and we are thinking about it.
> > I can totally understand that. The problem with C/C++ is that the
> > languages arent really designed with text processing in mind. What could
> > be done, however, is write the backend in text-processing-happy perl with
> > the frontend in C++, nice and perty Qt or something.
> That's actually a very good idea, it would problably be the Right Thing
> Todo(tm) right now.
Hm, I don't quite agree, I think that building everything in C/C++ (or any
othe non interpreted language) is a worth the extra effort, since it has some
drawbacks. With Perl for example, the Perl interpreter has to be installed,
and all the extensions we use, too. In case of a installation CD (or disk)
we would have to provide it.
The C/C++ aproach would have the advantage that we have some executables
which are small and work out of the box.
> I should take a look at Qt's XML Classes, now that i think about it..
Good Idea, I think I'll do so, too (It's about time, that I learn some XML)
> (well considering we can get some perl guys that will want todo it
> *gently nudges Simon again*)
> > I'm a bad CompSci guy. Whatever describes what you want to do, how you'll
> > do it etc will probably be good enough. If the fe and be are begin
> > developed seperately, then interfaces between them would probably need to
> > be defined then, to sooth teething problems.
> > One thing that should be considered a must: internationalization. Most
> > coders out there probably have very little or no experience of i18n
> > matters, so I think these should be considered in the design document.
> > This means no hard coded strings for UI stuff etc. Not too hard, but we
> > should include it in the standards specs, so we dont wind up with too
> > many problems down the road.
> Can't speak for perl, but i know for Qt it has some nice support. (at
> least for the frontend then), lets keep that in mind also, k guys?
I would be happy to help out if you go with C/C++ and qt.
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss