Object and texture library

[CARVALHO Luis Passos]

> 
> Hi Luis!
> 

Hi!

> Some feedback to the object and texture library (through the 
> mailing list 
> because of the list archive)
> 
> I hacked together a form with the qt designer
> (see http://www.kpovmodeler.org/tmp/objectlibraryform.png).
> I think that would be a good layout for the dialog.
> 

One thing I like about you is that you have good taste when it comes to
layout.
That's much better than what I had.

> Some suggestions:
> 
> - The list should be a QIconView showing all objects of one 
> library with the 
> rendered preview as icon (like a light table in a photo 
> studio, one of the 
> ideas I got from the image browser I mentioned).
>

Agreed.
 
> - If you select an item, its description and keywords are 
> displayed right as 
> well as the object hierarchy in the tree view. I think the 
> existing tree view 
> can be extended to be useable without a part. All drag and 
> drop functionality 
> would be implemented already. One could then drag only parts 
> of the stored 
> object or texture into the scene.
> 

I'll look into extending the tree view. Expect questions soon. ;)

What about inter-dependencies between parts inside an object?
I have code to go through all objects checking for dependencies. 
Maybe we could ask the user if we should add the dependencies when they
exist?

> - Libraries should be opened and closed inside the browser, 
> not in the 
> settings dialog. Especially two library paths (in the povray 
> page and the 
> object library page) are irritating to the user. Maybe we 
> have to rename the 
> povray library path in the povray page. Some users sent me 
> mails because they 
> found no way to open the povray includes although they added 
> the povray 
> include directory to the library paths.

I'll write about this in another mail. I noticed the possibility for
confusion when I was building the settings dialog class.

> I added tool buttons in the form. These should be included in 
> a toolbar. A 
> KToolbar can be used without a main window although mentioned 
> otherwise in 
> the documentation. The KDE file dialog uses one, too.
> 

Will do.

> - Do you want to create a library archive for each object and 
> texture? I would 
> create one zipped tar for a library. An object is saved 
> inside the archive 
> with your three files, but named <id>.xml, <id>.kpm, <id>.png 
> where id is an 
> unique number inside the library.
>

My first idea was that a library is a directory in the file system.
That's why you see the path in the combo box. You could add an alias so the
user adds
"file://home/username/modeler/libraries/lib1" as "My own objects" and always
sees "My own objects" in the browser.

Changing the library to a single zip simplifies file management, however
adding/removing objects from a library will be a more complex operation,
particularly when you start having several hundred objects in a library.

How about sub-folders in a library. Should we keep these? I personally like
organizing
my files in deep trees but I know there aren't many people like me.
 
> - Objects should be editable inplace in the object browser, 
> maybe with an edit 
> and browse mode.

Are you sure about this? Personally I don't like that very much.
What about having a modify button that opens another kpovmodeler with the
object?
What do you gain by having the editor inside the object browser?
And what if the changes you do to the object cause changes to it's preview?

> An image drag onto the icon list sets the preview, a kpm 
> object drag onto the 
> tree view sets the data. I will extend the povray render 
> widgets to allow the 
> user to drag the rendered image around (in the povray render 
> widget and the 
> texture preview). I implemented something similar for my 
> master thesis.
> 

That's great news, I was going to suggest the drag'n'drop of the rendered
images precisely because of adding new objects
to the library.

As for your idea for the creation of the object, it is done in two separate
actions and that can pose some problems. The operation of adding an object
to a library should be atomic and visibly so. Adding an object implies
creating all three files .xml, .png and .kpm. However I agree that building
a new object for a library could benefit from not being done all at once.

What about the following:
	- We have a dialog for creating objects for the library (similar to
the one I have now). Let'as call it a constructor.
	- The user selects create new library object
	- He then drags an image into the new constructor or clicks on the
preview to open a file
	- He fills all text fields with name, description and keywords
	- He also drags all objects he needs into the tree.
	- When the user is satisfied, he pushes the constructor's button
"Add to library" and selects which library to add the object to.
	- If you close or "cancel" the constructor you loose the object you
were creating.

> - Your objects are restricted to one declaration at the 
> moment (correct me if 
> I'm wrong). We should extend this to multiple objects of any 
> kind. Especially 
> complect objects consist allways of multiple declarations.
> 

Hmmm... Just checking the code. You are restricted only to declarations.
One or many doesn't matter.

> I have no concrete ideas for search results. Maybe they could 
> be displayed in 
> a kind of virtual object library, selectable in the combo box.

How about this?

Select a toogle button for filter. When you do that a dialog box with fields
for Name, Description and Keywords appears.
You put in the words you want to search. The filter is then applied to any
library you select from the combo.

> 
> So far my ideas.
> Any comments are welcome.
>