Re: Back from holidays

Hi Luis!

On Tuesday 27 August 2002 16:53, CARVALHO Luis Passos wrote:
> I'm back from holidays.

Welcome back.

> Went to the beach once. Went to Lisbon (our capital) for a week with my
> family. You never went there? You should. Very pretty. Then again, I'm
> biased. ;)

Well, I went a few days to the Lago di Garda, camping with some friends. Nice 
place, too. During the heavy rain where some camping sites were flooded. Not 
our, thought, we had great sunshine!

> First things first, a wee bug, more of an annoyance really: If povray's
> default .ini file has a line setting Display=on, we get two windows every
> time we call povray for some rendering. This is very distracting. We just
> need to add -D to the calling of povray. I did it at home, but don't recall
> the object now.

Oh no, not another one. I got a bug report that KPovModeler always segfaults 
after rendering some weeks ago. The reason was that animation options were 
set in the povray ini file.
I will add the -D option.

> For kpovmodeler 1.1:
> I think we have a problem with the automatic use of .ini files by povray.
> IMHO, either we stop povray of using the default .ini file, or if that's
> not possible, we provide an .ini file of our own. Otherwise we're
> susceptible to any new setting the users place on povray. Since kpovmodeler
> works as a front-end to povray, all options must be set through
> kpovmodeler.

I think povray always reads the global .ini file.

> Now on to the library objects (If you would like to see it, I can send some
> screenshots to the list):

Upload some screenshots and send the link.

> How does it work:
>   Importing: It's in "Insert | Library object", with the pmdeclare icon.
> Opens an Open File dialog, with a preview of the objects. It starts in the
> users local data directory (~/.kde/share/apps/kpovmodeler/library). You can
> browse all the files, searching for the one you want. When you select the
> file it places it on the scene, at the location where you have the cursor.

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.

>   Exporting: Only declares are allowed. Checks if all required objects are
> selected and notifies of what's missing. If nothing's missing, Shows a
> dialog where you fill the metadata about the object(s) and select a
> preview. Opens a save as dialog in ~/.kde/share/apps/kpovmodeler/library.
>
>   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.

> 	2. Auxiliary files (bump maps, material maps or density files, for
> example)
>
> Problem 1.:
> 	Please choose one of the following:
> 		a) Make Insert Library Object have a sub menu with two
> options: Global Library and Local Library
> 		b) Add a toolbar button to switch between Local Library and
> Global Library to the open file dialog.
> 		c) You're so incredibly stupid Luis, it's a wonder how you
> know how to breathe!
>                Obviously, the solution is _______________________________.

Of course you're incredibly stupid ;-)
It's so obvious: One folder for each library and no merging when exporting 
objects.

> Problem 2.:
> 	In order to find out which objects have auxiliary files, I will add
> two methods to PMObject:
> 		/** Does the object need auxiliary files? */
> 		virtual bool needsAuxiliaryFiles( ) const { return false; }
> 		/** Returns the list of auxiliary files needed by the
> object. */
> 		virtual QStringList auxiliaryFiles( ) const { return
> QStringList( ); }
>
> 	If the objects need auxiliary files, these will be added to the
> library object file.

Yup, good idea.

> PS: Man, I missed writing these long ramblings.
>     Didn't you miss reading my long ramblings?
>     I missed writing them.
>     *laughs histerically*
LOL! Sure :-)

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. 

An example from PMBlendMapModifiers, just to get the idea how simple the 
property system will be:

<pmblendmapmodifiers.cpp>

// some macros first:

PMDefinePropertyClass( PMBlendMapModifiers, PMProperty );
// This defines a property class PMProperty (for typesafe method references)

PMDefineEnumPropertyClass( PMBlendMapModifiers,
                           PMBlendMapModifiers::PMWaveFormType,
                           PMWaveFormProperty );
// This defines an enum property class for PMBlendMapModifiers::PMWaveFormType

[...]

PMMetaObject* PMBlendMapModifiers::metaObject( ) const
{
   if( !s_pMetaObject )
   {
      // class information and inheritance hierarchy
      s_pMetaObject = new PMMetaObject( "BlendMapModifiers", Base::metaObject( 
) );
      s_pMetaObject->addProperty( new PMProperty( "frequencyEnabled",
          &PMBlendMapModifiers::enableFrequency,
          &PMBlendMapModifiers::isFrequencyEnabled ) );
      s_pMetaObject->addProperty( new PMProperty( "frequency",
          &PMBlendMapModifiers::setFrequency,
          &PMBlendMapModifiers::frequency ) );
      s_pMetaObject->addProperty( new PMProperty( "phaseEnabled",
          &PMBlendMapModifiers::enablePhase,
          &PMBlendMapModifiers::isPhaseEnabled ) );
      s_pMetaObject->addProperty( new PMProperty( "phase",
          &PMBlendMapModifiers::setPhase,
          &PMBlendMapModifiers::phase ) );
      s_pMetaObject->addProperty( new PMProperty( "waveFormEnabled",
          &PMBlendMapModifiers::enableWaveForm,
          &PMBlendMapModifiers::isWaveFormEnabled ) );
      s_pMetaObject->addProperty( new PMProperty( "waveFormExponent",
          &PMBlendMapModifiers::setWaveFormExponent,
          &PMBlendMapModifiers::waveFormExponent ) );
      
      PMWaveFormProperty* p = new PMWaveFormProperty( "waveForm",
          &PMBlendMapModifiers::setWaveFormType,
          &PMBlendMapModifiers::waveFormType );
      p->addEnumValue( QString( "RampWave" ), RampWave );
      p->addEnumValue( QString( "TriangleWave" ), TriangleWave );
      p->addEnumValue( QString( "SineWave" ), SineWave );
      p->addEnumValue( QString( "ScallopWave" ), ScallopWave );
      p->addEnumValue( QString( "CubicWave" ), CubicWave );
      p->addEnumValue( QString( "PolyWave" ), PolyWave );
      s_pMetaObject->addProperty( p );
   }
   return s_pMetaObject;
}

</pmblendmapmodifiers.cpp>

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!

Andreas

--------------------------------------------------
 Andreas Zehender, Dipl. Ing. (BA)
 Student, 10. Semester Informatik
 http://www.azweb.de
 [email protected] | [email protected]      
--------------------------------------------------



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