Re: [Lsacon-development] Re: Kylix Text Parser Developers...

[valerio <_o...@li...>]

> OK, I don't know GTK (yet). Would there be problems integrating the
> interface with our pascal parser objects later? I'm all for pascal when it
> comes to handling data. But I share your concerns about Kylix because I
> finally figured out there's going to be lots of strange library problems
> running a GUI App with it (no problems running console Apps, though). So
> GTK is OK if we can make the "OPascal Backend" talk to the GTK Frontend.


I propose that we should keep using an avanced environment. If we leave 
Kylix, we would choose between Kdevelop, Kdestudio and Glade. All them offer 
a basic visual interface writing and a very good GUI. Glade works with GTK 
while the other two work with Qt.


> RPM keeps a software database, we should be able to give it a nice
> interface (like the one on SuSE 7.3). Don't know about Debian but bound to
> find out! The big problem would be to hide all the package dependency
> problems, probably it makes sense to have the interface say something like
> "errr, in order to install this software you need additional stuff, shall I
> take you to the download page?"

we would only need to write a frontend to rpm, that already does things like 
dependency checks, architecture checks and so on.....




anyway, I see there are many good ideas about what to provide after we get a 
good basis environment (i mean: something that parses XML files and makes an 
interface on-the-fly). The problem is that we should keep these ideas 
somewhere and get them back when we already have the program working. In 
fact, lsacon project is so modular, that we will get it do almost everything, 
like installation/de-installation, configuration, backups, profile 
management, and so on..... we should not focus on writing a very robust and 
efficient parser, maybe an editor, a nice interface, and a good documentation 
to let other developers take advantage of it. Just think about InstallShield 
for windows, everybody uses it every day, and it's only meant to provide easy 
and standard installation/de-installation procedure.....


I think it's time to choose what environment (Kylix or not -- commercial or 
open source) to use, and therefore what language (Kylix, C++, only XML?).
This choice is crucial because we all know Delphi (and then, Kylix), but do 
we know C++ enough? As for me, no :-)


Valerio