[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kpovmodeler-devel
Subject:    Re: KDE 3, current status of textures, declares, etc...
From:       Andreas Zehender <zehender () kde ! org>
Date:       2001-09-06 18:10:09
[Download RAW message or body]

Hi!

Some answers before my holiday:

> On the course of developing textures I've found a lot of places where a
> class inherited of PMDeclare has to be developed (PMTextureDeclare,
> PMObjectDeclare, PMColorMapDeclare, PMSkyDeclare,... well, it goes on and
> on and on. Each of these objects is alike, changing only on canInsert(),
> description() and isA(). It seems to me a great waste of time, developing
> all these diferent objects, actions, menu entries, tool bar icons, etc for
> an object that is basically the same everywhere.
> So my idea is to just have one PMDeclare, with one action, icon, menu
> entry, etc, which implements "#declare <ident> =". At first, it's type is
> PMTUnknownDeclare, and accepts any child that. As soon as a child is
> inserted in the tree, PMDeclare::type() will return the current
> PMTObjectDeclare or PMTextureDeclare or whatever. All the PM*Declare
> classes existing now would disappear. The icon would be put next to
> translate, rotate, scale, comment and other generic use objects in the
> toolbars. What do you think?

I totaly agree. I will implement this as soon as I have the time.

> - One thing that has me worried is the speed the toolbars are growing.
> We're only just starting and the graphical objects toolbar already features
> 15 icons or so. The textures toolbar will have many icons as well. What i'm
> getting at is that maybe we should split the toolbars a bit more. I don't
> know, maybe basic geometric solids in one toolbar, complex shapes (blobs,
> patches, meshes, lathes, etc.) on another, globally valid objects like
> translate, rotate, scale and comment on another, etc. That way the user can
> individually select what he intends to use, uncluttering his workspace much
> more.

This can easily be changed. I don't worry about that at the moment. All you 
have to change is the kpovmodelerui.rc file.

> - Maybe this it's still a bit soon but, at least in the camera view, there
> should be a way to hide lines in the object, instead of seeing the whole
> wireframe. I mention it now because I don't know if it can have impact on
> the definition of each of the objects or just on the rendering on the
> camera view.

A feature I _plan_ is to calculate the csg wire frame out of a CGS object. 
Don't know if I can implement that. Seems a tricky part!
Another idea: A "hide" flag for each graphical object. Not all objects inside 
a CGS have to be displayed.

> - How hard would it be to assign a different color to an object on the
> wireframes? This, with the addition of the previous one, would make the
> preview much more useful.

I will change the rendering to use the quick color of an object. This will be 
the clearest solution for the user.

> - Zooming and Translating the views. Right Click+'select from menu' is a
> bit cumbersome. Using alt+drag and ctrl+drag would be better IMHO.
> Shouldn't need much work I think.

Alt+drag drags the window on the screen, ctrl is for selection of multiple 
control points. I thought about that problem but the keyboard has too less 
special function keys :-)
Perhaps I add some hotkeys: Directions to move the view and Ctrl+direction to 
scale the view.

> - Regarding includes (collections of textures come to mind here), this is a
> sketch of how I see it implemented: PMInclude, which basically has a file
> name for the include file. When a PMInclude is inserted on the tree and a
> file is associated, it parses the file, adding every thing inside it as
> children of the PMInclude. The serialize*() methods shouldn't go through
> those children , instead it would just output the PMInclude's values. Also,
> editing on that entery branch should not be allowed. This is not very
> urgent, since, as it is now, we can just drag'n'drop the textures we want
> from one file to another very easily.

The readonly of the branch is simple: That is what the readonly flag of 
objects is for. But if the user edits the include file, or the include file 
is lost, the consistency of the scene is not guaranteed. That's why I didn't 
implemented include files.
What can be implemented without any problems is an import functionality. You 
select a file, get a listing of objects (eventually with a preview) and 
select some objects you want to import.

Well, enough TODO items, but good ideas.

Greetings, Andreas

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

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

[prev in list] [next in list] [prev in thread] [next in thread]