[dcontrol] More universal

[Philipp Kindt]

Ok, if debconf just asks questions and this is not enough,
another proposition:

I do not think it is a good idea to write a special kind of module for
everything that is to be configured, because we would hardly ever cover
any aspect of the system.
We need something more universal.
So a cool thing would be providing some sort of markup language for the
configuration gui. 
It would consist of some basic "widgets", which could be interpreted by
the different frontends.
There could be simple things like dropdown menus for most basic things
and options to call external code for more specific things. Every option
in a config file could obtain values like that. Fancy functions like
hardware detection would be possible as well.
This makup scripts could be either in a seperate file for a certain
configuration file or as remarked areas right within the configuration
files.

What do you think about that? 
   
On Thu, 2004-08-19 at 15:21,
debcontrol-general-request@lists.alioth.debian.org wrote:
> Send Debcontrol-general mailing list submissions to
> 	debcontrol-general@lists.alioth.debian.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.alioth.debian.org/mailman/listinfo/debcontrol-general
> or, via email, send a message with subject or body 'help' to
> 	debcontrol-general-request@lists.alioth.debian.org
> 
> You can reach the person managing the list at
> 	debcontrol-general-admin@lists.alioth.debian.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Debcontrol-general digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Names, code, work (=?iso-8859-1?q?Fabricio=20Cannini?=)
> 
> --__--__--
> 
> Message: 1
> Date: Wed, 18 Aug 2004 23:29:44 -0300 (ART)
> From: =?iso-8859-1?q?Fabricio=20Cannini?= <segfaulter@yahoo.com.br>
> To: debcontrol-general@lists.alioth.debian.org
> Subject: Re: [dcontrol] Names, code, work
> 
>  --- Paranoid <paranoid@pcwereld.be> escreveu: 
> > > CFG looks much like what i was thinking, 
> > > but with more layers.
> > > 
> > > Layer 1:
> > > High-level GUI (QT, GTK, HTML, etc) 
> > > that will do the eye-candy stuff.
> > > 
> > > Layer 2:
> > > Mid-level componentized python scripts,
> > > will be used by the GUI to handle the config
> > files.
> > > 
> > > Layer 3:
> > > Low-level raw config files.
> > > 
> > 
> > I was more thinking about something like this (maybe
> > it's the same as
> > yours, just clarifying then):
> > 
> > 1: general gui abstraction library (layer 0 would be
> > gtk/...)
> > 2: core, uses one protocol to communicate with layer
> > 1
> > 3: config file parser
> > 
> > So the only thing that would need te be written when
> > porting to another
> > interface/gui is layer 1, and this only needs to be
> > written once since
> > it's common to everything we write (given a specific
> > interface).
> 
> 
> Yes, it somehow gets to the same place.
> I was thiking about the following to the QT port:
> 
> 1- Strip out KDE's Kcontrol;
> 2- Pick the config modules that interest to us;
> 3- Write the one's that we need as KControl plugins;
> ( That's why i love KParts ;-) 
> 
> There's a set of libraries called sig++, 
> which were develop as bindings between python and C++
> code,
> so it can save the day (i'm seriously thinking in
> writng the gui's in python, as D3C is not a
> performance-savvy app.
>  
> 
> > > I've mentioned python (even thought i love Perl)
> > > because it is not a small project, 
> > > that must be very well organized (OO coded) 
> > > to grow with minimal pain, and python seems the
> > > language that best fits our needs.
> > > 
> > > I want to hear from you creatures, 
> > > what do you think about these ideas??
> > 
> > I was toying with python,lex & yacc. Someone did the
> > work to port
> > lexing/parsing to python, maybe we should take
> > advantage of this, since
> > writing parsers using only regexps+python/perl isn't
> > my favorite
> > timespending...
> > 
> > I'm not a big fan of CFG, but their parsers could be
> > reused i think.
> > The problem i had with them was the usage of XML.
> > (which imho is just a
> > little bloat to represent a tree of data).
> > 
> > They switched to WBEM recently (XML not being
> > supported anymore). I
> > don't know much about the WBEM protocol, but i get
> > the impression it's
> > quite large/extensive (which doesn't mean it's bad).
> > It's network
> > transparant though. afaik a wbem-lib for python
> > doesn't exist.
> > 
> > So that leaves us with these options:
> > a) Cut the WBEM piece out, and use whatever is below
> > it (parsers in perl
> > probably)
> 
> 
> No way.
> 
> 
> > b) Use python lexing/parsing and define our own
> > interface. (python has
> > CORBA/RPC like features afaik, so these things could
> > be network
> > transparent without much code) 
> 
> 
> Both GTK/GNOME and QT/KDE are CORBA/RPC capable 
> (KDE uses DCOP, which is a superset of CORBA), 
> so it won't be our worst problem.
> 
> BUT, excuse the pun, but this is a HUGE but,
> network transparency shouldn't be a priority.
> 
> 
> > c) Write a WBEM library for python/whatever we're
> > going to use and
> > include the WBEM layer from CFG
> > d) something else... :p 
> 
> 
> In a moment of despair, we could use XML/RPC!! ;-)
> 
> 
> > For GUI abstraction: what about extending debconf,
> > or just write
> > something ourselves?
> 
> 
> Really no. Debconf misses many features, 
> has an awkward design, and is written in perl.
> That's why QT Designer && Glade were made.
> 
> Best to you.
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Debcontrol-general mailing list
> Debcontrol-general@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/debcontrol-general
> 
> 
> End of Debcontrol-general Digest