lsacon-development — planning and development mailing list

Re: [Lsacon-development] what's our project stage? :)

[tapia <ta...@ei...>]

> So it seems that we'll use GTK.

Great. I love Gnome. :-)

> Now I need some advice on how to use GTK while programming in pascal,
and
> what tools to use to develop, like a free pascal compiler or so....
someone
> should compile a list of the "official tools" with some links to
resources
> and documentation. I think that we all should use the same things.

Well, there are some links:

http://www.freepascal.org
  The free pascal compiler. As they say in the web: "The language syntax
is semanticly compatible with TP 7.0, some extensions used by Delphi
(classes, rtti, exceptions, ansistrings) are also supported."

http://www.lazarus.freepascal.org/
  A Delphi clon. I don't know how usable is it (I tried it a long time
ago), but it is in active development.

two GTK binding for Pascal:

http://www.freepascal.org/packages/gtk.html
  This is the "base" binding. I don't know what version of GTK support,
but I suppose it is 1.2. GTK 2.0 is now being developed, and I think
it's the version we would use. That's the reason I think we would do all
the graphical stuff in C.

http://gtkpas.sourceforge.net/ Based in the freepascal package, it is
better, in my opinion. Absolutely object-oriented design.

But I must insist: GTK is C, and the releases for the pascal bindings
are not very fast. C is not difficult if you know pascal. The graphical
modules would be written in C, and the non-graphical libraries, in
pascal. I think it's the better way.

> If we decide which tools to use, I'll re-start writing
> the interface module. I still have to write the interface-on-the-fly
> module.....

If we decide to use GTK, it is not necessary to write this. LibGlade (a
GNOME library) uses XML for creating intefaces dinamically. When
Thasmudyan release a version of the XML parser, we can use it to build
the interfaces.

ta...@ei...                 |      c~~p ,---------.
ta...@us...     | ,---'oo  )           \
ces...@hi...|( O O                  )/
--------------------------------| `=^='                 /
http://www.eitig.com            |       \    ,     .   /
http://www.es.gnome.org         |       \\  |-----'|  /
http://lucas.hispalinux.es      |       ||__|    |_|__|

[Lsacon-development] what's our project stage? :)

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

Hi guys,

since we are still deciding what tools/libraries/languages to use, I think we 
are quite at the beginning :)

Actually, so far we've got many good things like a pair of dtd's and some 
documentation. This will help us focusing over the project development stage. 

I didn't know that Kylix used a modified Qt library. I agree that it would be 
not a good idea to use it anymore. I'll keep being a Borland fan anyway ;)

I like the idea of using object pascal since we all know it. I have no reason 
to prefer a library instead of anoher, so if you choose one because you know 
it to be good, I'll accept your choice :)
So it seems that we'll use GTK.
Now I need some advice on how to use GTK while programming in pascal, and 
what tools to use to develop, like a free pascal compiler or so.... someone 
should compile a list of the "official tools" with some links to resources 
and documentation. I think that we all should use the same things.

I know some url's have been posted in this mailing list. I'm sorry I didn't 
get notice of them. If we decide which tools to use, I'll re-start writing 
the interface module. I still have to write the interface-on-the-fly 
module.....


greetings
Valerio

[Lsacon-development] Re: Lsacon-development digest, Vol 1 #38 - 6 msgs

[Ivan D. <iva...@ya...>]

At 12:26 PM 2/9/2002 -0800, you wrote:
>Send Lsacon-development mailing list submissions to
>         lsa...@li...
>
>To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/lsacon-development
>or, via email, send a message with subject or body 'help' to
>         lsa...@li...
>
>You can reach the person managing the list at
>         lsa...@li...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Lsacon-development digest..."
>
>
>Today's Topics:
>
>    1. Re: Kylix Text Parser Developers... (Thasmudyan)
>    2. Re: Kylix Text Parser Developers... (tapia)
>    3. Re: Re: Kylix Text Parser Developers... (tapia)
>    4. Re: Kylix Text Parser Developers... (valerio)
>    5. Re: Re: Kylix Text Parser Developers... (valerio)
>    6. Re: Re: Kylix Text Parser Developers... (tapia)
>
>--__--__--
>
>Message: 1
>From: "Thasmudyan" <tha...@gm...>
>To: "IVAN DE JESUS DERAS TABORA" <i....@un...>
>Cc: <lsa...@li...>
>Date: Fri, 8 Feb 2002 22:10:26 +0100
>Subject: [Lsacon-development] Re: Kylix Text Parser Developers...
>
> > How I can join the mailing list?
>Go to the SourceForge lsacon website http://sourceforge.net/projects/lsacon
>and choose "mailing lists". Click something there that looks like "join".
>
> > At 01:29 PM 2/8/2002 +0100, you wrote:
> > >Hello,
> > >
> > > > I've been thinking about lsacon, and I have some ideas:
> > > >
> > > > - First of all, making the interfaces with kylix is not a good idea.
>I'm
> > > > going to learn GTK when I finish my exams, so we can go this way (it's
>a
> > > > very standard graphic library, and very good for dinamically build
> > > > interfaces). Object pascal is still a very good languaje for the XML
> > > > parser (we don't depend on gnome or KDE xml libraries) and the other
> > > > libraries.
> > >
> > >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.
>
>
> > If we use GTK, what is implemented in C/C++, we could change the XML
>parser
> > to C++.
> > I think the project is new, then, there's no problem to change the
>language...
>
>Hm, I don't know, I like Pascal very much. Yeah, that's not a very
>sophisticated reason. In my experience it has been easier to develop more
>stable applications much faster with Delphi, where as the (somewhat limited)
>experience I have with C++ was not a very comfortable one. But in the end
>it's all personal preference. And we've done quite a bit of work in Kylix
>already, but no THAT much I admit.
>So: we're a team, we'll do what most of us feel comfortable with. If the
>others like your suggestion, then we'll go with it. If they have the same
>feeling about Pascal/C++ like me then we'll try and stick with O.Pascal for
>the backend (if that's possible). {Quite a pity that Mono isn't quite there
>yet, there'll be a Pascal compiler for it some day I think...}
>
>In general I think we should use the tools that bring us to where we want to
>go, elegantly and reliable. Tools that give us the freedom to go anywhere we
>want. We should also avoid fancy libraries that are either not widely in use
>or constitute unecessary bloat / unstableness.
>
>What do you think?
>
>
>
>
>
>--__--__--
>
>Message: 2
>From: "tapia" <ta...@ei...>
>To: "IVAN DE JESUS DERAS TABORA" <i....@un...>
>Cc: <lsa...@li...>
>Date: Sat, 9 Feb 2002 11:46:41 +0100
>Subject: [Lsacon-development] Re: Kylix Text Parser Developers...
>
> > OK, I don't know GTK (yet). Would there be problems integrating the
> > interface with our pascal parser objects later?
>
>There are two GTK bindings for pascal:
>
>http://www.freepascal.org/packages/gtk.html
>
>http://gtkpas.sourceforge.net/ (better, in my opinion. Absolutely
>object-oriented design).
>
> > So GTK
> > is OK if we can make the "OPascal Backend" talk to the GTK Frontend.
>
>I don't know if we can do it, but I think we must study it. It must be
>easy associate a GTK signal (the O.Pascal events) with a kylix function.
>
> > 1. The controls a typical Windows user would expect to see (like
>Network
> > Panel as you said).
>
>Ok.
>
> > 2. Apps for which there is very poor graphical config support (for
>example I
> > can configure MS IIS 5.0 for Windows  very easily with the MS
>Management
> > Console GUI but it is still A PAIN to configure the Apache webserver
>for
> > Linux).
>
>Some months ago we said we will do lsacon modular. We will have the core
>program, and the users could download "definition" files, with the
>instructions for configuring several things. It would be a XML file.
>
>Something like this:
>
><module="apache">
>bla bla bla
></module>

This is an excellent idea, because the core program could be small, and the 
configuration tools could be added as modules, but we must think very well 
the core program so in the future, we doesn't have problems as "redefine 
the core program to configure something, this must be posible by added a 
module".


> > 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!
>
>Debian is nice for this, we can do it calling apt-get. You write
>"apt-get install mozilla" by example, and apt downloads and installs
>*all* needed packages. But not only this, it upgrades old packages if
>necessary. Wonderful, I love debian. :-)
>
> > Good example may be Ximian Red Carpet which
> > automatically downloads needed stuff.
>
>Yes, that's the idea.
>
> > > - Look at the mandrake code for the screen configuration. I like it
>a
> > > lot.
> >
> > You actually looked at the code or the interface? What are the things
>you
> > liked? (Sorry, don't have Mandrake)
>
>No, I've not looked to the code, but I've been using the tool, and it's
>great. The day is only 24 hours. :-)
>
> > I'd especially like to investigate the GTK idea because I've seen the
> > potential Kylix problems, too.
>
>Kylix uses a modified QT library. If you want to run a graphical kylix
>app, you must have this library. Definitively, that's not very portable.
>:-)
>
>ta...@ei...
>ta...@us...
>---------------------------------------------
>http://www.eitig.com
>http://terminus.sourceforge.net
>
>
>
>
>--__--__--
>
>Message: 3
>From: "tapia" <ta...@ei...>
>To: "IVAN DE JESUS DERAS TABORA" <i....@un...>
>Cc: <lsa...@li...>
>Subject: Re: [Lsacon-development] Re: Kylix Text Parser Developers...
>Date: Sat, 9 Feb 2002 11:49:39 +0100
>
> > Hm, I don't know, I like Pascal very much. Yeah, that's not a very
> > sophisticated reason. In my experience it has been easier to develop
>more
> > stable applications much faster with Delphi, where as the (somewhat
>limited)
> > experience I have with C++ was not a very comfortable one. But in the
>end
> > it's all personal preference. And we've done quite a bit of work in
>Kylix
> > already, but no THAT much I admit.
>
>I prefer object pascal, too. It's not the better languaje in the world,
>but i like it. I have some knowledges of C, but not C++.
>
>I think we must write the backend with Kylix, and the frontend with
>C+GTK.
>
>ta...@ei...
>ta...@us...
>---------------------------------------------
>http://www.eitig.com
>http://terminus.sourceforge.net
>
>
>
>
>--__--__--
>
>Message: 4
>From: valerio <_o...@li...>
>Reply-To: _o...@li...
>To: lsa...@li...
>Date: Fri, 8 Feb 2002 20:43:50 +0100
>Subject: [Lsacon-development] Re: Kylix Text Parser Developers...
>
>Hi guys,
>
>first of all, I'd like to tell Ivan welcome :)

Thanks...


> > - First of all, making the interfaces with kylix is not a good idea. I'm
> > going to learn GTK when I finish my exams, so we can go this way (it's a
> > very standard graphic library, and very good for dinamically build
> > interfaces). Object pascal is still a very good languaje for the XML
> > parser (we don't depend on gnome or KDE xml libraries) and the other
> > libraries.
>
>Well, actually, Kylix is totally based over Qt libraries. It only exports its
>classes in a Delphi-fashioned style. This means that you write code as you
>usually do with Delphi, but you are using Qt libraries. In my opinion, Qt is
>as standard as GTK, and I found Qt programs to be stronger (but this mean
>nothing, I know :))
>Anyway I don't think there's a great problem as almost every Linux machine
>has both Qt and GTK libraries installed (that's why you can run Gimp while
>using KDE, or StarOffice while using Gnome....)
>
> > We would develop *user oriented* controls, like this:
> >
> > - GENERIC deinstall software utility. Users don't have to know if they
> > are using rpm or deb packages. They not even have to know if they are
> > using packages. They have installed programs, they use them, and they
> > have to deinstall them in a easy way.

QT and GTK are great but we must use only one of them, because know two 
libraries will be a problem.
Remember this two libraries are very standar.


>This would be useful, but it looks like something different than the original
>idea... a good feature would be an auto configuration tool. For example, wine
>is available as daemon, and Mandrake installs it by default. This should let
>you run windows programs directly by executing them from the shell (or
>clicking on them from konqueror...). But this doesn't work because Mandrake
>does not configure wine while installing the system, and wine configuration
>isn't that easy if you never used it before.
>It would be great if a tool configured it automatically by looking your
>system.
>Cd burning software comes already installed with the distributions, but it's
>never configured when you run it the first time. Non-skilled users may not
>know how to configure a program like that.....
>We would plan to add lsacon basic auto configuration for most popular
>programs.
>
> > - Easy network configuration. No firewall, router and that kind of
> > things utils. Some basic items: network IP, hostname, DNS servers, maybe
> > gateway (in advanced configuration)... A clone of the Windows 98 network
> > config menu.
>
>Yes, this is a good idea. I think about a series of wizards that present the
>user a very few choices; the user will also be able to enter an expert mode
>or even a simple text editor, and manually manage the configuration. This
>way, newbies will not be afraid of Linux complexity, and skilled users will
>not feel like working with windows  (cool graphics, no control....)
>
>
>
>Valerio
>
>
>
>--__--__--
>
>Message: 5
>From: valerio <_o...@li...>
>Reply-To: _o...@li...
>To: lsa...@li...
>Subject: Re: [Lsacon-development] Re: Kylix Text Parser Developers...
>Date: Fri, 8 Feb 2002 21:00:00 +0100
>
> > 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 :-)

Yes this a good idea, we need to start to learn some librarie, (QT or 
GTK),  the environment (kdevelop, kdestudio, Glade)



>Valerio
>
>
>
>--__--__--
>
>Message: 6
>From: "tapia" <ta...@ei...>
>To: <_o...@li...>,
>         <lsa...@li...>
>Subject: Re: [Lsacon-development] Re: Kylix Text Parser Developers...
>Date: Sat, 9 Feb 2002 13:33:53 +0100
>
> > Well, actually, Kylix is totally based over Qt libraries.
>
>That's not exact. Kylix is *based* on Qt, but a modified ones. If you
>don't have the Qt version provided by Borland, you won't run a kylix
>executable. I can't understand why borland is doing it, but...
>
> > In my opinion, Qt is
> > as standard as GTK, and I found Qt programs to be stronger (but this
>mean
> > nothing, I know :))
>
>It's easy to know if the user is using Gnome or KDE. We can build the
>interface in Qt or GTK depending on it, but it is double work (learning
>and using two graphic toolkits).
>
> > This would be useful, but it looks like something different than the
>original
> > idea... a good feature would be an auto configuration tool. For
>example, wine
> > is available as daemon, and Mandrake installs it by default. This
>should let
> > you run windows programs directly by executing them from the shell (or
> > clicking on them from konqueror...). But this doesn't work because
>Mandrake
> > does not configure wine while installing the system, and wine
>configuration
> > isn't that easy if you never used it before.
>
>I don't like it very much. I think that the problem you are talking
>about must be solved by the mandrake installation program, not by
>external tools. We can (we would!) write a wine configuration tool, with
>panels and buttons and that lovely stuff :-) If you want to make it even
>easier, write a wizard who make some hardware comprobations, but I don't
>like the "absolutely automatic" auto-detection tools outsides of the
>operating system installation. It is one of the things make windows 98
>unstable.
>
> > Yes, this is a good idea. I think about a series of wizards that
>present the
> > user a very few choices; the user will also be able to enter an expert
>mode
> > or even a simple text editor, and manually manage the configuration.
>This
> > way, newbies will not be afraid of Linux complexity, and skilled users
>will
> > not feel like working with windows  (cool graphics, no control....)
>
>That's my idea, too. :-)
>
>Bye.
>
>ta...@ei...             |      c~~p ,---------.
>ta...@us... | ,---'oo  )           \
>                             |( O O                  )/
>http://www.eitig.com        | `=^='                 /
>http://www.es.gnome.org     |       \    ,     .   /
>http://lucas.hispalinux.es  |       \\  |-----'|  /
>                             |       ||__|    |_|__|
>
>
>
>
>
>--__--__--
>
>_______________________________________________
>Lsacon-development mailing list
>Lsa...@li...
>https://lists.sourceforge.net/lists/listinfo/lsacon-development
>
>
>End of Lsacon-development Digest


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

[tapia <ta...@ei...>]

> Well, actually, Kylix is totally based over Qt libraries.

That's not exact. Kylix is *based* on Qt, but a modified ones. If you
don't have the Qt version provided by Borland, you won't run a kylix
executable. I can't understand why borland is doing it, but...

> In my opinion, Qt is
> as standard as GTK, and I found Qt programs to be stronger (but this
mean
> nothing, I know :))

It's easy to know if the user is using Gnome or KDE. We can build the
interface in Qt or GTK depending on it, but it is double work (learning
and using two graphic toolkits).

> This would be useful, but it looks like something different than the
original
> idea... a good feature would be an auto configuration tool. For
example, wine
> is available as daemon, and Mandrake installs it by default. This
should let
> you run windows programs directly by executing them from the shell (or
> clicking on them from konqueror...). But this doesn't work because
Mandrake
> does not configure wine while installing the system, and wine
configuration
> isn't that easy if you never used it before.

I don't like it very much. I think that the problem you are talking
about must be solved by the mandrake installation program, not by
external tools. We can (we would!) write a wine configuration tool, with
panels and buttons and that lovely stuff :-) If you want to make it even
easier, write a wizard who make some hardware comprobations, but I don't
like the "absolutely automatic" auto-detection tools outsides of the
operating system installation. It is one of the things make windows 98
unstable.

> Yes, this is a good idea. I think about a series of wizards that
present the
> user a very few choices; the user will also be able to enter an expert
mode
> or even a simple text editor, and manually manage the configuration.
This
> way, newbies will not be afraid of Linux complexity, and skilled users
will
> not feel like working with windows  (cool graphics, no control....)

That's my idea, too. :-)

Bye.

ta...@ei...             |      c~~p ,---------.
ta...@us... | ,---'oo  )           \
                            |( O O                  )/
http://www.eitig.com        | `=^='                 /
http://www.es.gnome.org     |       \    ,     .   /
http://lucas.hispalinux.es  |       \\  |-----'|  /
                            |       ||__|    |_|__|

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

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

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

Hi guys,

first of all, I'd like to tell Ivan welcome :)

> - First of all, making the interfaces with kylix is not a good idea. I'm
> going to learn GTK when I finish my exams, so we can go this way (it's a
> very standard graphic library, and very good for dinamically build
> interfaces). Object pascal is still a very good languaje for the XML
> parser (we don't depend on gnome or KDE xml libraries) and the other
> libraries.

Well, actually, Kylix is totally based over Qt libraries. It only exports its 
classes in a Delphi-fashioned style. This means that you write code as you 
usually do with Delphi, but you are using Qt libraries. In my opinion, Qt is 
as standard as GTK, and I found Qt programs to be stronger (but this mean 
nothing, I know :))
Anyway I don't think there's a great problem as almost every Linux machine 
has both Qt and GTK libraries installed (that's why you can run Gimp while 
using KDE, or StarOffice while using Gnome....)

> We would develop *user oriented* controls, like this:
>
> - GENERIC deinstall software utility. Users don't have to know if they
> are using rpm or deb packages. They not even have to know if they are
> using packages. They have installed programs, they use them, and they
> have to deinstall them in a easy way.

This would be useful, but it looks like something different than the original 
idea... a good feature would be an auto configuration tool. For example, wine 
is available as daemon, and Mandrake installs it by default. This should let 
you run windows programs directly by executing them from the shell (or 
clicking on them from konqueror...). But this doesn't work because Mandrake 
does not configure wine while installing the system, and wine configuration 
isn't that easy if you never used it before.
It would be great if a tool configured it automatically by looking your 
system.
Cd burning software comes already installed with the distributions, but it's 
never configured when you run it the first time. Non-skilled users may not 
know how to configure a program like that.....
We would plan to add lsacon basic auto configuration for most popular 
programs. 

> - Easy network configuration. No firewall, router and that kind of
> things utils. Some basic items: network IP, hostname, DNS servers, maybe
> gateway (in advanced configuration)... A clone of the Windows 98 network
> config menu.

Yes, this is a good idea. I think about a series of wizards that present the 
user a very few choices; the user will also be able to enter an expert mode 
or even a simple text editor, and manually manage the configuration. This 
way, newbies will not be afraid of Linux complexity, and skilled users will 
not feel like working with windows  (cool graphics, no control....)



Valerio

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

[tapia <ta...@ei...>]

> Hm, I don't know, I like Pascal very much. Yeah, that's not a very
> sophisticated reason. In my experience it has been easier to develop
more
> stable applications much faster with Delphi, where as the (somewhat
limited)
> experience I have with C++ was not a very comfortable one. But in the
end
> it's all personal preference. And we've done quite a bit of work in
Kylix
> already, but no THAT much I admit.

I prefer object pascal, too. It's not the better languaje in the world,
but i like it. I have some knowledges of C, but not C++.

I think we must write the backend with Kylix, and the frontend with
C+GTK.

ta...@ei...
ta...@us...
---------------------------------------------
http://www.eitig.com
http://terminus.sourceforge.net

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

[tapia <ta...@ei...>]

> OK, I don't know GTK (yet). Would there be problems integrating the
> interface with our pascal parser objects later?

There are two GTK bindings for pascal:

http://www.freepascal.org/packages/gtk.html

http://gtkpas.sourceforge.net/ (better, in my opinion. Absolutely
object-oriented design).

> So GTK
> is OK if we can make the "OPascal Backend" talk to the GTK Frontend.

I don't know if we can do it, but I think we must study it. It must be
easy associate a GTK signal (the O.Pascal events) with a kylix function.

> 1. The controls a typical Windows user would expect to see (like
Network
> Panel as you said).

Ok.

> 2. Apps for which there is very poor graphical config support (for
example I
> can configure MS IIS 5.0 for Windows  very easily with the MS
Management
> Console GUI but it is still A PAIN to configure the Apache webserver
for
> Linux).

Some months ago we said we will do lsacon modular. We will have the core
program, and the users could download "definition" files, with the
instructions for configuring several things. It would be a XML file.

Something like this:

<module="apache">
bla bla bla
</module>

> 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!

Debian is nice for this, we can do it calling apt-get. You write
"apt-get install mozilla" by example, and apt downloads and installs
*all* needed packages. But not only this, it upgrades old packages if
necessary. Wonderful, I love debian. :-)

> Good example may be Ximian Red Carpet which
> automatically downloads needed stuff.

Yes, that's the idea.

> > - Look at the mandrake code for the screen configuration. I like it
a
> > lot.
>
> You actually looked at the code or the interface? What are the things
you
> liked? (Sorry, don't have Mandrake)

No, I've not looked to the code, but I've been using the tool, and it's
great. The day is only 24 hours. :-)

> I'd especially like to investigate the GTK idea because I've seen the
> potential Kylix problems, too.

Kylix uses a modified QT library. If you want to run a graphical kylix
app, you must have this library. Definitively, that's not very portable.
:-)

ta...@ei...
ta...@us...
---------------------------------------------
http://www.eitig.com
http://terminus.sourceforge.net

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

[Thasmudyan <tha...@gm...>]

> How I can join the mailing list?
Go to the SourceForge lsacon website http://sourceforge.net/projects/lsacon
and choose "mailing lists". Click something there that looks like "join".

> At 01:29 PM 2/8/2002 +0100, you wrote:
> >Hello,
> >
> > > I've been thinking about lsacon, and I have some ideas:
> > >
> > > - First of all, making the interfaces with kylix is not a good idea.
I'm
> > > going to learn GTK when I finish my exams, so we can go this way (it's
a
> > > very standard graphic library, and very good for dinamically build
> > > interfaces). Object pascal is still a very good languaje for the XML
> > > parser (we don't depend on gnome or KDE xml libraries) and the other
> > > libraries.
> >
> >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.


> If we use GTK, what is implemented in C/C++, we could change the XML
parser
> to C++.
> I think the project is new, then, there's no problem to change the
language...

Hm, I don't know, I like Pascal very much. Yeah, that's not a very
sophisticated reason. In my experience it has been easier to develop more
stable applications much faster with Delphi, where as the (somewhat limited)
experience I have with C++ was not a very comfortable one. But in the end
it's all personal preference. And we've done quite a bit of work in Kylix
already, but no THAT much I admit.
So: we're a team, we'll do what most of us feel comfortable with. If the
others like your suggestion, then we'll go with it. If they have the same
feeling about Pascal/C++ like me then we'll try and stick with O.Pascal for
the backend (if that's possible). {Quite a pity that Mono isn't quite there
yet, there'll be a Pascal compiler for it some day I think...}

In general I think we should use the tools that bring us to where we want to
go, elegantly and reliable. Tools that give us the freedom to go anywhere we
want. We should also avoid fancy libraries that are either not widely in use
or constitute unecessary bloat / unstableness.

What do you think?

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

[Thasmudyan <tha...@gm...>]

Hello,

> I've been thinking about lsacon, and I have some ideas:
>
> - First of all, making the interfaces with kylix is not a good idea. I'm
> going to learn GTK when I finish my exams, so we can go this way (it's a
> very standard graphic library, and very good for dinamically build
> interfaces). Object pascal is still a very good languaje for the XML
> parser (we don't depend on gnome or KDE xml libraries) and the other
> libraries.

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.

> - Maybe we must think about what we want lsacon to do. There are lots of
> config tools (gnome control panel, kde control panel, drakconf, webmin,
> ximian setup tools...), so we must add some new ideas if we want making
> a useful app.

Yep, I see two main areas:
1. The controls a typical Windows user would expect to see (like Network
Panel as you said).
2. Apps for which there is very poor graphical config support (for example I
can configure MS IIS 5.0 for Windows  very easily with the MS Management
Console GUI but it is still A PAIN to configure the Apache webserver for
Linux).

> We would develop *user oriented* controls, like this:
>
> - GENERIC deinstall software utility. Users don't have to know if they
> are using rpm or deb packages. They not even have to know if they are
> using packages. They have installed programs, they use them, and they
> have to deinstall them in a easy way.

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?" Good example may be Ximian Red Carpet which
automatically downloads needed stuff. (The problem with Red Carpet is mainly
that you have to go through HELL if you want to install IT, although you can
opt to download the entire bloated Ximian GNOME Desktop for hundreds of MB.)

> - Easy network configuration. No firewall, router and that kind of
> things utils. Some basic items: network IP, hostname, DNS servers, maybe
> gateway (in advanced configuration)... A clone of the Windows 98 network
> config menu.

Yes.
Some additional samba integration would be nice, so you can connect to
Windows shares easily, since no average user would want to figure out the
command line "mount -t smbfs -o username=blablabla...". The average user
just wants to connect a Network Drive and be done with it.

> - Easy sound management tool. There are thousands of volume controls,
> but there are not integrated in a control panel. microphone volume,
> general volume, PC speaker...

Let's hope there's some hardware independence with Linux regarding the sound
drivers.

> - Look at the mandrake code for the screen configuration. I like it a
> lot.

You actually looked at the code or the interface? What are the things you
liked? (Sorry, don't have Mandrake)

> Well, there are some chaotic ideas. What do you think? :-)

Nice to see some activity returning :-)
I'd especially like to investigate the GTK idea because I've seen the
potential Kylix problems, too.

Re: [Lsacon-development] hi

[tapia <ta...@ei...>]

> > Anyway, I'd like to keep alive the project. Let me know if it's your
> purpose
> > too, so we can get back to work :)
>
> Yep, I know, we're a little behind schedule, ahem. I've quite a lot of
work
> to do with the parser and stuff. I will definetely continue, once this
> contract work is over. How about you other guys?

I'm listening too, but I think we can stop untill Thasmudyan end his
work. First, because he is the "leader" of the project, and second,
because he was writing the XML parser, absolutely necessary for the rest
of the work.

Enjoy! :-)

ta...@ei...
ta...@us...
---------------------------------------------
http://www.eitig.com
http://terminus.sourceforge.net

Re: [Lsacon-development] hi

[Thasmudyan <tha...@gm...>]

Hello,

> it's been a while since the last time I got a mail from this list....
should
> I think that we let our project die without a word?

No. I'm feeling a little embarrased because of the long silence period...

> As for me, I've been quite busy in the last pair of months (and, by the
way,
> I got a little job and achieved another exam :))), and I suppose it's been
> the same for you.

Yes, I can only agree. I've been quite busy in the last few weeks.
Congratulations for your exam! My company got a large contract last year and
I've been working overtime since. However, it will be finished by the end of
this month, so I get a bit more free time.

> Anyway, I'd like to keep alive the project. Let me know if it's your
purpose
> too, so we can get back to work :)

Yep, I know, we're a little behind schedule, ahem. I've quite a lot of work
to do with the parser and stuff. I will definetely continue, once this
contract work is over. How about you other guys?

Greetings
Thasmudyan

[Lsacon-development] hi

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

Hi guys,

it's been a while since the last time I got a mail from this list.... should 
I think that we let our project die without a word?

As for me, I've been quite busy in the last pair of months (and, by the way, 
I got a little job and achieved another exam :))), and I suppose it's been 
the same for you. 
Anyway, I'd like to keep alive the project. Let me know if it's your purpose 
too, so we can get back to work :)


greetings
Valerio

Re: [Lsacon-development] controls definition

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

> Just one minor thing: rename filename.dtd.xml for filename.dtd

thanks for the hint :)


Well, I think I can use that dtd as a good beta version. Now I can write the 
engine that reads a definition file and creates a gui.... by the way, I need 
to most recent version of the xml parser unit...


greetings
Valerio

Re: [Lsacon-development] controls definition

[tapia <ta...@ei...>]

> Let me know what you think about it; if it's good, I'll start working
on it
> to develop define runtime gui components

It's very clear (I'm newbie with XML, too), I like it very much.
Greetings! :-)

Just one minor thing: rename filename.dtd.xml for filename.dtd

ta...@ei...
ta...@us...
---------------------------------------------
http://www.eitig.com
http://terminus.sourceforge.net

[Lsacon-development] controls (2)

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

here comes the attachment (sorry :))

Valerio

[Lsacon-development] controls definition

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

hi,

I've completed a first version of controls.dtd.xml
I've included some comments, I hope everything is clear and correct (this is 
my first dtd :))

Let me know what you think about it; if it's good, I'll start working on it 
to develop define runtime gui components


greetings
Valerio

Re: [Lsacon-development] gui preview

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

Hi,

> We'll have to keep in mind that most users are accustomed to the windows
> style. They don't care what goes on inside the computer, they just want to
> get their things done.

Well, honestly, I simply do not agree with this policy :-)
But anyway I get what you and Tapia mean, and I agree that we should make it 
as easy as possible.
So I propose -- the tree view will be kept (user will choose to show or hide 
it); on the other hand, I'll add a listview just alike windows' control panel 
to be shown instead of the empty panel.
Users customize the interface by choosing to show the listview, the treeview, 
or both. I guess it's enough until we decide for something else :-)

> I think the TreeView is good, because we'll have a hierarchical system and
> it represents that structure well. But I don't think we should display the
> tree by default.

I'm thinking of a kind of control panel that works with nested folders; it'll 
be clear when I show you a demo :))




Greetings

Valerio

Re: [Lsacon-development] gui preview

[Thasmudyan <tha...@gm...>]

> > Did you upload your new XMLParser? I'm waiting some features. :-)
> > last(), first() and some more little things.

Ehem... almost done... in a few hours... sorry for the delay.

Re: [Lsacon-development] gui preview

[tapia <ta...@ei...>]

> They don't care what goes on inside the computer, they just want to
> get their things done.

That's my idea, too.

> I'll go with Tapia on this one, that we'll have a very
> simplistic icon-style navigation and in ADDITION experienced users can
> always turn on the tree (or ...hehe... "explorer").

Yeah, that's a good choice.

> Keep in mind that the design itself should not be an issue for our
milestone
> 1. We'll get a real interface designer to work on the graphics (I've
already
> talked to one and he will help us). Let's focus on functionality and
> concepts at this time.

Did you upload your new XMLParser? I'm waiting some features. :-)
last(), first() and some more little things.

> Ok, keep it up... you're doing a great job, Valerio!

I agree. :-)

ta...@ei...
ta...@us...
---------------------------------------------
http://www.eitig.com
http://terminus.sourceforge.net

re: [Lsacon-development] gui preview

[Thasmudyan <tha...@gm...>]

Hello!

> > this is a very alpha version of the gui. The purpose is to show you
> > what I've got in mind about it.

Yes, I think, it's a great job, too. Especially since you're working on the
dynamic allocation of the Control, which is a feature we'll DEFINITELY need.

> It's a very good job, but I find it's very similar to the existant
> control panels in unix (Gnome and KDE), and it don't solve the problems
> they have. Maybe I'm wrong, but I'd prefer a more "windowser" style.

We'll have to keep in mind that most users are accustomed to the windows
style. They don't care what goes on inside the computer, they just want to
get their things done. Microsoft spent a lot of money finding out how the
average consumer works with the system and they integrated this information
into their OS - like in WinXP.
I think the TreeView is good, because we'll have a hierarchical system and
it represents that structure well. But I don't think we should display the
tree by default. I'll go with Tapia on this one, that we'll have a very
simplistic icon-style navigation and in ADDITION experienced users can
always turn on the tree (or ...hehe... "explorer").

> > - a text browser where the context based help system will be shown

> That's a great idea! The user don't have to go to the help, it appears
> automagically :-)

Yeah, I love it!

Keep in mind that the design itself should not be an issue for our milestone
1. We'll get a real interface designer to work on the graphics (I've already
talked to one and he will help us). Let's focus on functionality and
concepts at this time.

> As for now I'm working on a set of XML tags for defining a set of standard
> controls. My goal is to define a very little number of tags. I'll show you
an
> example when I get to a first result.

Ok, keep it up... you're doing a great job, Valerio!

Greetings

Thasmudyan

[Lsacon-development] controls definition

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

Hi,

I've completed the first revision of a controls definition model.
As for now, I propose 12 tags to define all the controls we may need. These 
tags should be even more than necessary for developing runtime interfaces to 
configuration files.

What I wrote down is a basic ruleset for gui purposes only; this means that 
there's nothing to link the interface elements to the actual configuration 
file contents. This is a more complicated topic and I'd like to get your 
ideas.

I think some changes would be necessary. Let me know what do you think about.


Valerio

Re: [Lsacon-development] gui preview

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

> The only matter is that I don't like the treeview for choosing the
> subject I will work with. Why don't show a *very* generic list of issues
> (network, printing, services, screen...) and the user choose one of
> them. Then, a new window will be open, and again some generic options
> will be shown (the IP of the netcards, the screen resollution... Things
> like that). For more specific configs, an "Advanced" button will bring
> us to the more complex features. I think that "pyramidal" look is more
> simple for the newbie user (that's the idea of lsacon, isn't it?).

I get what you mean.
In my opinion, this "windows-style" isn't that good. In fact, windows users 
never get a real understanding of what they are doing under the interface. It 
looks like the gui is meant to hide them what they are doing.
My idea of lsacon is to provide users a simple and easy to use interface to 
access *everything* inside a configuration file. This should not prevent, 
however, users to fastly reach what they are looking for.
What I want to say is that when you work with windows you hardly get to know 
how do the things work. There's a commonly diffused idea of stupid user.
If we provide a standard set of gui controls, we let users modify 
configuration files, while presenting them the actual way these files work.

On the other hand, I agree with you that the scheme I proposed is quite used 
in every configuration tool. In fact, I'd like to use a control like 
Outlook's side menu, where items are collected into a kind of "boxes". This 
would also let us add a box for last used items, and most used items. This 
also will divide items into very generic issues as you proposed. But I still 
believe that all of the configuration parameters should be visible to the 
user. Maybe we can divide them into two great groups named "basic" and 
"advanced", especially for the most critical things (such as, for example, 
lilo configuration).
Anyway, please remember that we'll always inform user about what is gonna 
change when he makes a choice, and we'll provide a strong backup system in 
order to reduce the chances of a system crash.

We can also provide two different interfaces, just alike Nero Burning Rom. In 
that program, if you choose the wizard interface, you can only change one or 
two major settings, while the other interface gives you total control on its 
features. The first one is faster when you have already set up all your 
preferences, but it's really uncomplete as a standalone gui....

> I like the general idea, with the above comment. Do you agree with me?

I agree with you at 50% :-)
So I propose, let me keep working with the actual gui until I complete a rule 
set for the standard controls. Then we will come back again on this subject. 

As for now I'm working on a set of XML tags for defining a set of standard 
controls. My goal is to define a very little number of tags. I'll show you an 
example when I get to a first result.


Greetings
Valerio

Re: [Lsacon-development] gui preview

[tapia <ta...@ei...>]

> this is a very alpha version of the gui. The purpose is to show you
what I've
> got in mind about it.

It's a very good job, but I find it's very similar to the existant
control panels in unix (Gnome and KDE), and it don't solve the problems
they have. Maybe I'm wrong, but I'd prefer a more "windowser" style.

The only matter is that I don't like the treeview for choosing the
subject I will work with. Why don't show a *very* generic list of issues
(network, printing, services, screen...) and the user choose one of
them. Then, a new window will be open, and again some generic options
will be shown (the IP of the netcards, the screen resollution... Things
like that). For more specific configs, an "Advanced" button will bring
us to the more complex features. I think that "pyramidal" look is more
simple for the newbie user (that's the idea of lsacon, isn't it?).

> - a text browser where the context based help system will be shown

That's a great idea! The user don't have to go to the help, it appears
automagically :-)

> I hope everything is clear. If you approve the general scheme I'll
keep
> working this way.

I like the general idea, with the above comment. Do you agree with me?

ta...@ei...
ta...@us...
---------------------------------------------
http://www.eitig.com
http://terminus.sourceforge.net

[Lsacon-development] interface

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

Hi again,

I solved the problem about creating new components at runtime.
As for now, I create them and put them into an array of TControl. This eats 
memory but it's the faster way to easy access to runtime components.

Now, I think it's time to define the standard components, so, here's a list:


- label
- edit and maskedit
- spinedit
- radiobutton
- checkbox
- button
- combobox
- listbox
- filedialog

In my opinion, the above are all necessary, and no one of them needs to be 
explained. I added filedialog because it is really useful, and provide us a 
very easy way to let users choose a file from the filesystem, almost without 
defining an interface for such an operation. My idea is that when a 
filedialog is encountered in the def file, a button like [...] or [Browse] is 
shown on the gui, and this buttons is linked to a filedialog component.

Then, we may add these controls:

- trackbar
- checklistbox
- fontdialog
- colordialog


trackbar is maybe the same as spinedit, but it can be used when you don't 
have an integer value to display (modem volume, screen resolution....).
fontdialog and colordialog are included for the same reason of filedialog, 
but they are less important. checklistbox would be virtually useless as 
checkboxes are already planned, but it's a great screen space saving and a 
way to ease collecting options together.

And, at last, other controls would be:

- stringgrid
- treeview
- listview



Now we have to define a rule set for the definition files. I believe we 
should make an effort to make them as short as possible. This means that 
composite controls should be the first choice (a spinedit rather than an edit 
with two buttons "+" and "-",  and so on).
We should also consider if it would be useful to write specialized 
components, for example a listbox containing all the system users.



Ok, this is enough for now :) I think it'd be useful to give me cvs access 
for upgrading new versions of the interface.
If you agree with at least the first controls list, I start writing some 
basic ruleset. This will require some time because I'm new to xml (by the 
way, I assume that definition files will be xml, is that right?)

There's the very last question: as Thasmudyan planned to support 
configuration for user-related things like themes and general desktop 
appearance, every user should be able to run LSACon. Obviously, they should 
definitively NOT be able to configure, for example, firewalling. How do we 
manage what features to make available to normal users?


Greetings
Valerio