|
From: Robert R. <rra...@ya...> - 2000-11-10 06:27:21
|
> In trying to get caught up with the latest versions I have a few questions.
> I'm a little unclear with the file structure and where things are supposed
> to be. The latest dynapi releases have no widgets - are the ones
> from 20001024-full.zip supposed to work with the latest or is the effort
> right now trying to get them to work and be re-integrated?
Yes, most of the widgets were removed recently. The idea is to have a
standard set of widgets (label, etc). Then, other people can offer
thre own packages separately. Its impossible to maintain people's
widgets in the main dynapi distribution. Since you've updated the
Label, viewport, etc, then they should be included in the next
release.
> I've made the necessary changes to my Label, ViewPort, ScrollBar,
> and ScrollWindow in order for them to work with the 11.06 release.
> Only 1 further change is needed/requested in dynlayer and that's
> to make SetSize the last command before issuing a create event:
>
> this.setVisible(this.visible)
> this.setSize(this.w,this.h)
> this.createChildElements()
> this.invokeEvent('create')
I'll make that change.
> Also, where are standard images (that are linked with widgets) going
> to be located? I think the images that are needed in widgets should be
> located along with the js files because they are essentially part of
> the api if widgets require them. Would the following structure be ok?:
>
> /dynapi/lib/
> /dynapi/lib/dynapi.js
> /dynapi/lib/api/
> /dynapi/lib/ext/
> /dynapi/lib/gui/
> /dynapi/lib/images/
> /dynapi/examples/
>
> That way we can require that you set the library path
> to "/dynapi/lib/", and no image directories have to sepecified
> when using dynwindow, or any others - they'll by default pick
> up the library path and use it +/images/widgetdir/. I realize
> there's an auto-include function now, but it should be easy to
> reconfigure it for such a directory structure.
The structure has changed a bit in the last release. Its now a true
file structure as in java. If you say include('dynapi.gui.xxx'), then
it loads xxx.js from <library-path>/dynapi/gui/ located in the library
path. This allows you to have separate packages than the dynapi
package (ex. widet-sets can be there own separate packages that will
be located in the library path, but in a separate directory than
dynapi). So, it now looks like:
js/
lib/
dynapi/
api/
dynlayer.js,etc...
gui/
...
anotherpackage/
gui/
etc.
So, the dynapi package should be separate than other peoples add-ons.
So, for the widgets that are to be included in the dynapi package,
they can have a images directory under the dynapi directory
<library-path>/dynapi/images/xxx.
> Next I think there should only be one set of widgets, none of these
> ibs, obc directories. Have one "gui" directory put em all in there,
> or at least the ones that should be part of the standard dynapi
> package. Other people can easily release their own "widget packs",
> but I think really they should be distributed and maintained
> separately if they are divergent from the structure/look/syntax of
> the "standard dynapi".
This issue should be solved with the new directory structure.
Previously when you said include('dynapi.gui.x'), it looked for gui
under the lib directory. Now it uses the packagename.
I posted the latest beta release at
http://dynapi.sourceforge.net/beta/dynapi-11.10-beta.zip. It removed
the .all and .unassigned arrays and renamed .allID and .unassignedID
to them. So to reference layers (or inline layers) by id you say:
DynAPI.document.all['layer1']. It also fixes the double-click problem
in inline layers in Netscape. It includes to loadPanel, but apparently
is does not work in IE 4, so this needs to be fixed. If you have your
widgets ready, then we can make a new release soon that will include
all of these changes.
\\Robert
--
rra...@ya...
|