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

List:       kde-core-devel
Subject:    Re: Plans for KUrl in kconfig_compiler [was: Plans for KUrl in
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2007-03-12 19:56:13
Message-ID: 20070312195613.GA21163 () morpheus ! apaku ! dnsalias ! org
[Download RAW message or body]

On 12.03.07 14:31:18, Adam Treat wrote:
> On Monday 12 March 2007, Andreas Pakulat wrote:
> > Uhm, right. I shouldn't write half asleep :) What I need to change (as
> > far as I can see) is kconfig_compiler and possibly KConfigSkeleton and
> > KCModule (haven't looked into these two in detail, so am not sure).
> >
> > Sorry for the confusion.
> 
> No, you need to change the KConfigDialogManager class to be aware of 
> KUrlRequester

It is already, I think. At least it already recognizes a widget called
kcfg_foobar that has KUrlRequester type. So the widget is in the
knownWidget list of the KConfigDialogManager.

> and make sure that KUrlRequester has a USER property.

Thats also already the case.

>  Then you 
> need to modify the KConfigDialogManager propertyMap and changedMap so that 
> KConfigDialogManager is aware of the signal KUrlRequester uses to let you 
> know the USER property has changed state.

Thats something that is missing indeed. But this is not the real
problem...

One problem is: kconfig_compiler doesn't support KUrl at all and
apparently it doesn't support the KConfigSkeleton::ItemProperty type
either.

Anyway, I found that using the code that I quoted still doesn't work
because when using a String type for the property
KConfigSkeleton::ItemString calls QVariant::toString() which returns an
empty string for a KUrl.

So either a new ItemKUrl type is needed or kconfig_compiler needs to get
support for the ItemProperty class which should also be able to handle
this.

Andreas

-- 
So you're back... about time...
[prev in list] [next in list] [prev in thread] [next in thread]