Re: [luxor-xul-develop] Luxor goals for the future

[Gerald B. <ge...@va...>]

Hello David,

> Is there a document anywhere that specifies the
> goals of the Luxor
> project, and the plan for acheiving them?

  Well, there's a "Blue Sky - What's Next?" which is
about two years old I think.

  For high-level goals you might wonna check out the
VanX talk titled "Luxor: The "Linux Kernel" for
Desktop Apps - Uniting XUL, SVG, HTML, Velocity, Web
Start, XSL/T, Python and more online @
http://luxor-xul.sourceforge.net/talk/vanx-jul-2002/slides.html


  If I may quote:

 Luxor Xul Design Principles - Freedom, Choice,
Excellence

    * Reuse, Reuse, Reuse. Build on existing
infrastructure. Don't reinvent the wheel, the tooth
brush or the alphabet.
    * No hidden agenda. No backdoor. No lock-in.
    * No sacred cows. Cut the crap. No bullshit. Clean
it up, Mr. Fix.
    * No kings or queens. Everyone is welcome. Working
code beats know-it-all blabber.
    * Release early. Release often. No big bang and
design behind closed door a la Billy Boy and the
Yes-man brigade.
    * Modul-mania. Extensible. Embeddable.

    Five Freedoms - Xul Charter

    * Freedom to Choose Your Runtime - Java, Mono,
C/C++
    * Freedom to Choose Your GUI Designer -
    * Freedom to Choose Your GUI Toolkit - Swing, SWT,
Gtk#, Qt
    * Freedom to Choose Your Scripting Language -
Python, Perl, Tcl
    * Freedom to Choose Your Programming Language -
Java, C#, Shark
 
> >From the Luxor overview:
> -Separate the UI into 4 distinct parts: content,
> appearance, behavior,
> locale
> -Make UI building easier than writing it all in Java
> -Free from GUI toolkit lock-in
> 
> Others I think should be included:
> -Ease of development (rewording of #2 above;
> easy-to-use API with complete documentation)

   Definitely. Everyone agrees on making the API much
easier to use. Also I guess everyone agrees on
complete documentation. However, who's going to put in
some cycles?

   One idea is to use XDoclet tags to mark public API
methods and use the XDoclet tags to generate some
docs. 

   The current API reference is online @
http://luxor-xul.sourceforge.net/apiref.html

> -Well-defined XML formats

  Definitely. I've started to use the Relax NG XML
schema language to define the XML UI format. Again I
suggest using XDoclet tags to mark XUL tags
  e.g. @xul.tag.name=hbox etc.

> -Simplicity (avoiding feature creep, excess XUL
> tags, etc.)

  I'm all for keep it simple stupid and also for
cleaning up the current API.

> -Use "standard" libraries when appropriate
> -Dependencies on external libraries only when
> "needed"

  Well, the Luxor philosophy is don't reinvent the
wheel, the toothbrush and so on and also to avoid the
not invented here (NIH) syndrom.

  I consider Apache libraries such as log4j, Velocity,
commons-collection, commons-beanutils, etc.
"standard". 

  Another philosophy of Luxor is modul-mania, that is,
to put non-Luxor code in separate libraries/modules
(e.g. Rachel, Salsa, Caramel, Houston, etc.) to help
reuse.

  If you think that "branding" each library is
excessive I open to fold all libraries under a single
umbrella/namespace.

> With these in mind, I think that the first goal
> should be ease of
> development, with the discussion in the user list on
> Thursday in mind,
> starting with discussion of how we think users
> should interact with the
> Luxor API, and then design of an API that
> facilitates this.
> 
> An approach:
> -Have a class (for now, call it XulManager) with the
> following methods:
> Object getRootComponent(final String path);
> Object getComponent(final String path, final String
> id);

  Your suggested helper methods are more than welcome.
I suggest using get() instead of getComponent() and
loadForm() instead of getRootComponent() for example.
 
> The "path" argument is the name of a XUL bundle (set
> of XML files), which
> defines a top-level window (frame, dialog, etc.). 
> Using getRootComponent,
> you can retrieve that window.  Alternatively, using
> getComponent, you can
> retrieve any arbitrary component within the window
> by id as specified in
> the XUL.
> 
> In this example, the return types are Object.  This
> allows flexibility as
> to the GUI toolkit used to implement the manager.
> 
> -For a particular GUI toolkit, provide a Facade.
> For example, a SwingFacade might provide the
> following methods:
> public final JPanel getPanel(final String path,
> final String id);
> public final JFrame getFrame(final String path);
> public final JDialog getDialog(final String path);
> public final JWindow getWindow(final String path);
> public final JTextArea getTextArea(final String
> path, final String id);
> public final JTextField getTextField(final String
> path, final String id);
> ...

  I support your idea of using type-safe helper
methods. As far as I rember I already started to
create some e.g. getPanel, getFrame, etc.

> If it turned out that retreiving components by id
> was a frequent
> operation

  Well, I think getting widgets by id is the most
important operation, thus, my suggestion to use simply
get( String id ).

> we could have a variation on the Facade
> that was specific to a
> XUL bundle, thus requiring only the component id as
> an argument.
> 
> -XML format restructuring
> As stated on the Luxor overview, we wish to separate
> the UI into 4
> distinct parts.  Our existing XUL format handles
> content/layout fairly
> well, though it could use a bit of tuning.
> 
> Appearance can be handled by CSS, which is a
> standard format with a
> standard API to read (SAC).  Rather than embed our
> styling information in
> the XUL file, I would prefer to have it in an
> external file, to promote
> distinctness between the 4 UI parts.

  Well, Anakreon just checked in his code into CVS
that supports external CSS sytlesheets. I wrote up a
Memphis Sun story a while ago. See
http://luxor-xul.sourceforge.net/sun/2003/12/luxor_xul_now_sports_external_css_stylesheets.html

> I think that behavior should be handled by some form
> of behavior mapping
> XML file, where you associate standard GUI
> controller classes with
> components defined in the layout file.  For example,
> you could have an
> entry specifying that the action for the OK button
> should be
> com.something.OKAction, and that the mouse listener
> for a certain table
> should be com.something.MyListener.  This might also
> be an appropriate
> place to allow things like setting custom models,
> renderers, editors, etc.

  Well, for behavior I suggest scripting and also
auto-wiring using reflection using naming conventions
as you suggested.

> For localization, traditional Properties
> ResourceBundles are a good start.

  Sorry. Resource Bundles are too Java specific. The
idea of XUL is to be language independent. Thus, I
suggest using simple string tables, that is, Java
properties files but without any Java resource bundle
classes and use our own
locale-sensitive/culture-sensitive lookup instead
similar to Mozilla or Microsoft .Net.

> These could be linked into the layout file either by
> defining certain
> attributes to specify the name of a key in the
> ResourceBundle, or by using
> a ${key} syntax to allow localization in any
> attribute. 

  Well, this already works using Velocity
preprocessing of XUL documents. Sorry, if it's not
advertised anywhere.

> I'm less
> clear on how the internationalization of layouts
> themselves works.  For
> example, when in a locale with right-to-left reading
> order, the labels
> should be to the right of their associated GUI
> objects.  Perhaps to
> support this, we should look up layout files by
> locale similarly to how
> localization properties files are located.

  Sounds like a reasonable approach.

  Let me know if this answers your questions and what
part you want to take on.

   - Gerald