Object and texture library

Andreas Zehender kpovmodeler-devel@mail.kde.org
Fri, 3 Jan 2003 10:39:53 +0100


Hi Luis!

On Thursday 02 January 2003 20:30, CARVALHO Luis Passos wrote:
> One thing I like about you is that you have good taste when it comes to
> layout.

Hmmmmmmmmm. That sounds nice :-)

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

Sure!
I took a quick look at the tree view code. There are many references to the 
part. The cleanest solution would be to copy the code and to create a new 
class. Be warned: The selection code is quite tricky.

> 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?

Yes.

> 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.

Doesn't the ktar class support adding and removing of files?
Hmmm, after looking at the documentation I noticed that removing files is not 
supported. When you open a tar archive inside konqueror, you can't delete 
files, too. I will dig through the karchiver code how tar files are handled 
there.

Directories inside the archive are supported. I like to organize files in deep 
trees, too. We should definitely support a directory structure in libraries. 
Maybe we could add an index file in each directory (and the top level 
directory) for directory descriptions. Directory and file names are not fully 
unicode. The description in the index files could be used as library and 
directory names inside the browser.

> > - 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?

Maybe that was not clear enough. I don't like the idea of a separate "add 
object to library" menu item. The library should be editable inside the 
browser when in a special edit mode, not the objects data. You should be able 
to set the data by draging objects from the tree view onto the browser, not 
to edit the data inside the browser.

> 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.

My fear is that this method is too complicated to create huge libraries. 
Imagine the case that I want to convert a povray include file with 30 
textures to a library.
I create a new library and switch to edit mode. I don't want to specify the 
library after each object, only once.
I then drag one declaration after the other onto the icon view. That 
automatically creates a new object and presets the name and data. If you name 
the files <id>.* and choose an unique id for the new object, you can store 
incomplete objects inside the archive without any problems. You can then edit 
all attributes and the object name, because it is independent of the file 
name but stored inside the <id>.xml file. All attributes have to be editable 
after the object creation.

> > - 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.

Ah, you can select multiple declarations and create the object? Didn't notice 
that. I just played around a bit.

> > 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.

You would still have to dig through directories to find objects. The search 
result has to be flattened.

Greetings, Andreas

-- 
--------------------------------------------------
 Andreas Zehender, Dipl. Ing. (BA)
 Student, 10th semester computer science
 http://www.azweb.de
 az@azweb.de | zehender@kde.org      
--------------------------------------------------