Author Topic: Regarding the next release  (Read 2568 times)

Florian Nücke

  • κρύα πόδια
  • Administrator
  • Hero Member
  • *****
  • Posts: 1985
  • MegaZine3 Developer
    • MegaZine3
Regarding the next release
« on: August 10, 2009, 05:41:43 pm »
Regarding the next version

This post shall give you all a short overview of what's to change with the next version.
This primarily affects developers and designers, but as there will be some changes
noticeable to everyone, I recommend everyone interested in the future use of the
MegaZine3 engine to read this.


First of all, the changes will be large enough to justify a major version increase, i.e. the
next version will be 2.0. The development of the 1.x line will be discontinued. Yes, even
if bugs are found / pending, sorry.

The two major changes coming are:
  • the basic architecture. This has been changed to a completely plugin-based approach,
    i.e. all features not directly "kernel" related are now realized through plugins, small swf files
    containing additional code, which can be loaded as needed. This should provide developers
    a much easier way of customizing the engine.
  • the way graphical elements (the GUI) is defined. The interface.swf / .fla is no longer.
    It has been replaced by a completely new approach: all GUI definitions are now written in
    an XML dialect I chose to call ASUL. More on that in the following. This should make it a lot
    easier to customize the appearance of the GUI.


Plugins

This paragraph is primarily addressed to programmers.

What everyone should know, is that starting from the next version, every feature that
should be available must be loaded by defining it in the plugins attribute of the book.
What plugins will be available will be published in an orderly fashion at a later date, so it
will be easy to look up which plugin does what, and how to load it.

The new version will offer a plugin interface, defined through an interface that plugins have
to implement. There will be a AbstractPlugin which all plugins should extend for a
uniform implementation, but theoretically it is possible to implement a plugin by just
implementeing the interface (properly).

Plugins will be compiled into one swf each. They will have a few possibilities to interact
with the engine:
  • Performing an action when a chapter or page is added to / removed from the book. *
  • Registering new "settings", i.e. attributes of the book tag, that will be parsed into the
    (rewritten) settings class.
  • Registering for attributes. This is meant as the primary link. A plugin can register for an
    attribute of a chapter, pageside, element proxy or element, and will be requested to handle
    the attribute when an element with such an attribute is added to the book, or, in case of
    the actual elements, completes loading.
  • Adding objects on top of the actual book, a page side or an element, inside a specifically
    designated plugin layer (pluginLayer property).

* Note that chapter and page removal has not yet been implemented.

More information on plugins, including dependencies, loading order, registration / initialization
will be forthcoming.


GUI definitions (ASUL)

This paragraph is primarily addressed to designers.

What everyone should know, is that starting from the next version, every definition of a GUI
element will be created using a XML definition file (.asul file). All this means to the end provider
is, that you will have one more folder in you megazine directory (the gui folder), which contains
those definitions and the graphics used in the gui (although this second part is only a convention).

The basic concept is similar to XUL, if you're familiar with that. What this means is that,
basically, there is a set of given GUI elements, each of which can be configured using an
XML node. So, the most basic example is a simple box:
Code: (xml)
  1. <box background="color(0xff0000)"/>
The background is optional, if not given the box will be transparent. As for nesting:
Code: (xml)
  1. <box background="color(0xff0000)" width="20" height="20">
  2.    <box background="color(0x00ff00)" x="5" y="5"/>
  3. </box>
This will create a green box inside a red box. Note that the default width and height of elements
is 10, so this creates a centered 10 by 10 box inside a 20 by 20 box.

There are many advanced features available, such as rather flexible layouting, more complex
objects (such as a window and a loading bar), and many more attributes. Those features may be
explained in a tutorial in the future. As soon as the next version is released and the API
documentation is updated, this can be used to look up possible attributes as well, as those will
be described in the class's documentation.

As you can imagine, this allows a much more flexible way of changing the interface. For some
examples, see the descriptors of the basic GUI, i.e. what's been in it before:
http://svn.mightypirates.de/megazine/trunk/bin/gui/
For a complex example, see the Options dialog:
http://svn.mightypirates.de/megazine/trunk/bin/gui/options.asul

A note to the programmers out there: the ASUL classes form an independent framework, so they
not dependant on the MegaZine3 engine. This means they can be used in other projects, too.
They are licensed, just like the MegaZine3 engine, under the GPL v3 license.

When?

There's still some work to be done. The gallery is almost completely migrated, but the help and
especially the navigation bar will take some more time. There are also a lot of small other regions
that need more work, plus a short testing / bug finding phase, before I'm ready to officially release
the new version.
That said, I won't make any promises, but I expect version 2.0 to be ready within the next two
or three weeks.

Until then, please excuse my lack of activity on the forum or inresponsiveness to mails, but I have
other things to do, as well, and currently prioritize finishing the new version over giving support.

Thanks for your attention,
Florian Nuecke
For the Snark was a Boojum, you see.

Before you ask a question
          After you get an answer
  • please document your problem with the answer in the Project Wiki. (e.g. in the FAQs)
  • help others out if you can, by answering their questions on the forum.