RE: Back from holidays

> 
> I think povray always reads the global .ini file.
> 

I checked. That's true.

> 
> Upload some screenshots and send the link.
> 

In your mail you suggested some things that change a few dialogs. I'll
complete the changes then upload some screenshots.

> 
> What do you think of this idea: A non-modal dialog similar to 
> the file manager 
> with folders, entries, forward, backward buttons etc. To 
> insert objects into 
> the scene drag the entry onto the object tree.
> 

Yes, I agree. It's just a pitty that I won't be able to use KFileDialog, but
I was already reaching the conclusion that it wasn't customizable enough for
our needs.

> >
> >   What's missing:
> > 	1. Dealing with a global library and a users library, since the
> > dialog can only start in one of the places
> 
> You should support any number of object libraries and merge 
> all into a common 
> directory structure.
> 

Object Libraries are just folders in the file system, containing sub-folders
and several *.kpml.

So, what I was thinking was:
	In PMSettingsDialog have a page for library locations (name, url)
	Have a PMLibraryObjectBrowser which is a dialog with the following
layout:
		Library:  |__________|v|  (That's a combo box of all
libraries, if you were wondering)
		+-----------------------------------+-----------+
		|						|
|
		|	File Browser (KDirOperator)	| Preview	|
		|						|
|
		+-----------------------------------+-----------+

	The standard file browsing classes in KDE don't implement Drag&Drop,
but the includes give locations of classes that do support it. Anyway,
either I implement it myself or use those classes.
	Comments?

> Of course you're incredibly stupid ;-)

Well, at least you could lie. :)

> Just for your information:
> I am working at the properties framework which I need for the 
> new dynamic 
> insert possibilities system (and scripting, of course) which 
> I need to remove 
> the PMObjectType type for the plugin framework. Puh, sentence end. 
> 

It's good to see obscure english is not used only by me. ;)
But I understood what you wrote.

> An example from PMBlendMapModifiers, just to get the idea how 
> simple the 
> property system will be:
> 
> <pmblendmapmodifiers.cpp>
>
> [...]
>
> </pmblendmapmodifiers.cpp>
>

Hmmm... eeeehhh... yeess... I seeeee.... good.
 
> That's all. You can now read and set properties typesave(!) 
> with a PMVariant 
> type with:
> 
> bool PMObject::setProperty( const char* name, const 
> PMVariant& v ); and
> PMVariant PMObject::property( const char* name ) const;
> 
> As example:
> 
> PMBlendMapModifiers* object;
> object->setProperty( "waveForm", PMVariant( "PolyWave" ) )
> object->setProperty( "waveForm", PMVariant( 
> "ANotDefineWaveFormType" ) ) will 
> return false because the type is not defined.
> object->property( "waveForm" ) will then return a string variant with 
> "PolyWave" as value.
> 
> Couldn't be simpler!

Do you mind if I take your word for it? ;-)

Now seriously. I think I understood it. The general idea at least.
When we allowed to commit again, just write a paragraph or two explaining
what needs to be changed in every object,
so that you don't have to change everything alone.

Regards,
Luis

PS:
"You've never known fear until you've faced the menacing jaws of work."
Luis Carvalho, 2002-08-27, after a rather tiring workday, still feeling the
scent of past holidays.

List archive and information: http://mail.kde.org/mailman/listinfo/kpovmodeler-devel