[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KConfigXT Parameterized Groups
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2005-01-17 22:09:05
Message-ID: 200501171509.13798.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 17 January 2005 03:38, Esben Mose Hansen wrote:
> Me, I was looking for support for user defined structs. I tried path the
> paramterized variants, and found path insufficient for this purpose.
> However, it is possible to inject a class between KConfigSkeleton and the
> KConfig compiler, so I'm writing the support there.
>
> I could shine this up to 4.0 and make it a general support for custom
> objects, if it has any interest.

yes, KConfigXT needs a number of improvements for 4.0, user defined data sets 
being one of them. i wonder, however, if making the developer write more code 
(toVariant, toMyStruct, etc) is the only/best way? would "nested" KConfigXT 
objects be enough?

i know on one project i worked on several years ago we needed an XML file that 
described a config file (w/out any real parameters on what the target config 
file looked like). what i ended up doing was allowing the definition of 
"complex" types in one section (between <def></def> tags) that were agregates 
of basic types. so one might have something like:

<def>
        <type name="socket" begin="(stream|dgram)"          end="\s"/>
        <type name="proto"     begin="(tcp|udp)"     end="\s"/>
        <type name="flags"     begin="(wait|nowait)"  end="\s"/>
        <type name="user"     begin="([^\s]+)"       end="\s"/>
        <type name="server"   begin="([^\s]+)"       end="\s"/>
        <type name="args"     begin="([^\s][^\n]*)"   end="\n"/>
        <type name="linecomment"    begin="#([^\n]*)"  end="\n"/>

        <type name="service"  begin="([a-zA-Z0-9][^\s]*)"  end="\n">
       <element name="socket"  typeref="socket"  multi="false"   opt="false" 
strict="true" optend="false"/>
       <element name="proto"   typeref="proto"   multi="false"   opt="false" 
strict="true" optend="false"/>
       <element name="flags"   typeref="flags"   multi="false"   opt="false" 
strict="true" optend="false"/>
       <element name="user"    typeref="user"    multi="false"   opt="false" 
strict="true" optend="shared"/>
       <element name="server"  typeref="server"  multi="false"   opt="false" 
strict="true" optend="shared"/>
       <element name="args"    typeref="args"    multi="false"   opt="true"  
strict="true" optend="shared"/>
    </type>

    <type name="off-service"  begin="(#)"  end="\n">
        <element name="service" typeref="service" multi="false" opt="false" 
strict="true" optend="shared"/>
    </type>
</def>

(bounds and other norm checking went elsewhere... an oversight,in retrospect.. 
and it used regular expressions and things like defined endings, because it 
was used as a run-time parser generator  =)

anyways, the idea should be fairly evident. later in file you would then 
define where, how many and in what order (if any) the previously defined 
elements would/could appear. you could even create new entries by simply 
asking the ConfigXML object for a new entry in the file for any given element 
that lined up with the definitions.

i imagine the same or something similar could be done with KConfigXT: have a 
section that defines complex types with much the same syntax as the rest of 
the file and give each of those definitions a name that can be referenced 
later in the file and expanded as necessary.

config group names also need to be able to be templatized for apps like kicker 
or kmail which use variable group names to store information. for instance, 
kicker stores the details of the buttons you create in such groups.

in my dream world, we'd be able to say something like

	settings.create("KMenuButton", "_1");

and we'd get a new kmenu button entry. or

	new KMenuButton(settings.kmenuButton("_1"));

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]