Hello,
I am currently learning how to write an ActiveX control and a plugin in C++.
I have still a lot of things to learn, but here are the first thoughts
about class structure.
We will need both an activex and a plugin version of the viewer: this
will require some different code for each version. We will have to keep
the different code at a minimum to avoid duplication.
Downloading of data from the server is done at the plugin/activex level
(doing it in the viewer core would be much more complicated), so we will
have to handle some communication between the viewer core and the
plugin/activex code.
I would implement the controller as an abstract class that defines the
required interface. It would be easier to create different controllers
that inherit from that class in a second time.
As soon as I will be able to create a very simple test plugin it will be
time to try porting it from Windows to the other platforms: this will
require some volunteers. The task will be rather simple:
- install the Gecko SDK to be able to build the plugin
- write a few lines of native code to show something on the screen.
This will not have anything to do with the viewer, it will be a test to
see if we are able to build a plugin on the various platforms. Of course
the build environment will be used for the plugin too.
Fulvio
Thomas Rauscher ha scritto:
>Hello,
>
>as I said, I would like to work more the "Extreme Programming" way,
>not in a "Waterfall" model, so I would like to start with some
>design work. We all know that what we want to do, can be done (look at
>Quicktime!) so the open question for the plugins are just
>implementation details.
>
>What I want to start with is a discussion of the basic object model.
>If this is clear, I would suggest we can start implementing a
>standalone viewer prototype (because it's much easier to debug) and
>implant this code into the different platform specific plugins.
>
>In my opinion, the rough class structure should look like this:
>
>* panorama
>
>abstract base class, platform independent
>
>These objects should hold all
>the image data and viewing parameters of one panoramic image (node)
>for example [min,max,default] X [pan,tilt,fov]
>HDR, Hotspots,...
>
>Subclasses:
>
>-- cubic
>6 cubefaces like QTVR
>
>-- cylindrical
>One image in cylindrical projection
>
>-- equirectlinear
>One image in equirectlinear projection
>....
>
>
>* controller
>
>Platform independent class to manage user interaction, like
>turn, tilt, ... goto next node,...
>contains [current] X [pan,tilt,fov]
>
>listens to browser events
>provide events
>
>* Render
>abstract baseclass. Platform dependent.
>Displays the image on the screen
>
>Subclasses:
>-- Legacy
>simple draw pixel method
>
>-- Direct2D
>draw pixel method for older Computers/to less VRAM
>
>-- DirectX
>Win32
>
>-- OpenGLBase
>Win32, Linux, MacOS,....
>
>-- OpenGLEx
>Use Hardware accelerated HDR display
>
>....
>
>* loader
>abstract baseclass, platform independent
>
>Decodes input files to panorama objects
>
>Subclasses:
>-- Quicktime VR
>
>-- PTViewer
>
>-- SPi-V
>
>.....
>
>
>All these classes are packed into a small platform dependent
>plugin/stand alone player, which handles the low level input/output
>and distributes it to the classes, and listens to events of the
>controller/render class.
>
>The code structure/sharing will be more complex, because some things
>can be shared for the platform (Win32: activeX/Netscape/Standalone,
>...) and some things for the browser (netscape: Win32/MacOS/Linux,...)
>but for this I would need to know more about all this things.
>
>But I think these layers are very small, so we can start with some
>prototypes for each platform, and than look, whats simmilar/reuseable.
>
>What do you think about these ideas?
>
>MfG,
> Thomas.
>
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Freepv-devel mailing list
>Freepv-devel@...
>https://lists.sourceforge.net/lists/listinfo/freepv-devel
>
>
>
>
|