vkhaitan at gmail.com
Thu Nov 3 22:57:51 GMT 2005
My idea was a rudimentry one, and it has to be not just refined but also
extended, I already know. My only purpose was to find out the trouble with
For tackling the configuration trouble, I had two mre ideas.
One was utilizing macro, which i immediately abandoned because of being
The other one was quite good, But I didn't think much about it.
that is moc/kconfig_compiler like parser of code. It will have much greater
flexibility, but for the time being, I forget it.
> On Wednesday 02 November 2005 10:44, Vinay Khaitan wrote:
> > registerOption(QObject* instance, QString key, void* function)
> Non-type-safe function pointers are really not appealing to me.
Definitely I second it. actually void* was just first thing came into my mind
in a millsecond :)
Cant we make registerOption aware of type of function?
instead of void* we can have QVariant* ? then registerOption() function would
find out the correct type and make that function type-safe?
If QVariant comes out to be overhead or non-safe(because of automatic
casting), we can make similar lightweight class with type safety and new
classes can be registered like QMetaType?
> Anyhow the idea seems broken to me. No support for options that depend
> on each other, so for every option callback being activated we'd set up
> everything in a way, and then another callback is called and we set up
> things differently; and relayout/update everything - where we could have
> done the right thing in the first place.
> If the amount of options remains, the complexity remains, the code just has
> to be written "correctly" to handle those cases, unless the number of
> options is reduced.
This problem surfaced when I was talking with a other dev.
I had the idea of key parsing by library for the purpose of calling correct
function sequence or correct function. We can have the key passed like "key1?
key2: key3", for the purpose of multiple option dependent call ?
I dont like this idea, because, it still doesn't hide configuration thingie
from main code flow.
What I envision is that, actually multiple option dependent call are construct
of programming logic, instead of real world need.
see this example:-
we have two boolean option
in certain situation,
object would be shown when (!("keep hidden" && "auto-hide"))
and in a different situation it would be (! "keep hidden" )
for this purpose, we will have only one function registered "void show(key)"
this function would see which situation is relevant at present. This will
totally hide the configuration things from main code.
What is important to node here is that, our real world need is only one, to
show the object. so that is what is registered.
May be the situation cant be seen only from the main code, because not all
parameter is present in other code.
in that case, the function can be made of variable argument list, just like
One more solution, which comes to my mind is that , we can have somehow
specified the interdependence of options to library, so that it can tackle
the situation of calling a function or not calling?
The only thing to say on this is that the possibility or arraging code to look
more readable and cleaner is surely there. We must investigate it.
More information about the kde-core-devel