pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: Fwd: MODERATE for pivot-commits@incubator.apache.org
Date Mon, 04 May 2009 13:23:01 GMT
Hi Phillipe,

Thanks for taking the time to post. This is some great feedback - my comments below.

>Looks like you took the RIA side from the opposite of JavaFX: they
>started with the flashy stuff (pun intended) neglecting the GUI side
>(or rather delegating to Swing) while you took great care of the UI,
>being less heavy on the scenegraph/graphics effects (although I saw
>some are already there).

Exactly. As you noted, we do have support for animated transitions in our components, and
we have recently been working on a scene graph API and basic movie support; see pivot.wtk.media.drawing
and pivot.wtk.media.Movie.

>- JavaDoc: looks like lot is already there. I wonder how the
>pivot.collection differs from Java's one? Re-implementation or thin
>wrapper? In the first case, why?

The short answer is that the Java collection classes wouldn't have allowed us to create the
API that we wanted. We don't just use the collection APIs for generic data collections - they
are an integral part of the framework. They provide a consistent API across all classes that
require indexed or keyed access. 

Some specific differences:

 - Pivot's collections define minimal interfaces that provide all necessary operations but
are simpler to implement, including "lightweight" versions suitable for combining with other
collection interfaces. These include Sequence, Dictionary, and Group, which are used extensively
throughout the framework.

 - Pivot collections fire events, which allow callers to be notified when collections are
modified. This allows us to use collections as data models. Since many of our serialization
classes support deserialization of data directly to these types, it allows us to drop data
into components right off the wire.

 - Pivot collections support auto-sorting - the base Collection interface defines a comparator
property that defines the order in which values are stored/enumerated within the collection.
This is useful, for example, when a List is used as the data model for a TableView.

 - Pivot collections include built-in support for nested collections (i.e. tree data) via
the Sequence.Tree class. This class contains a number of utility methods for accessing data
in nested sequences and is useful when a List is used as the data model for a TreeView.

Note, however, that you aren't required to use Pivot's collections - you can of course still
use the java.util collections, and we do provide wrapper implementations for those in pivot.collections.adapter.

>I saw Pivot aims at taking a place in the RIA scene, taking the pure
>Java way (unlike JavaFX). How does it compare to the latter? And to
>Swing? What is the purpose of re-creating what Swing has already done?

Most of the comparison points are discussed in our proposal to the Apache Incubator; see the
section entitled "Comparison to Other Java-Based RIA Platforms":


However, one advantage that isn't mentioned in the proposal (since it was added later) is
that Pivot's drag/drop and clipboard APIs are a bit easier to work with than AWT's; see the
File Drag & Drop demo and the accompanying source code.

>I think it is much smaller (binaries) than JavaFX and as I said
>currently of slightly different scope. Does Pivot aims to be usable on
>JavaME (portable phones?). 

We'd love to see Pivot become available on mobile devices. However, this is largely dependent
on Java SE's availability on such devices. It's entirely possible that, if JavaFX can run
on a particular device, Pivot would also work there.

>I am not fan of the XML data description, I would have preferred a
>less verbose, more readable/easier to write markup, like Json (I saw
>you support it) or Yaml. But well, I can live with that.

You might want to mention your interest here:


It is a tool for building Swing UIs in YAML, and the author has previously mentioned the possibility
of adding Pivot support at some point.

>I saw some limitations of the text field, as I expected it to behave
>more or less like Windows' ones.

While many Pivot widgets do behave similarly to their Window's counterparts, Pivot does not
target Windows exclusively, so some UI behaviors are different; additionally, some features
simply may not have been implemented yet:

>- I expected the Home and End keys to bring me to start and end of
>field. They seem inactive.
>- I expected the Ctrl+Left/Right keys to go from word to word. They
>bring to start and end of field!

That's the default behavior on the Mac; Option-arrow moves from word to word. In the future,
we'd like to add support for platform-specific key mappings.

>- Ctrl+V does nothing there... Ctrl+C and Ctrl+X too.

In an unsigned applet, copy/paste only works within an application. However, trusted code
has full access to the system clipboard.

>- Double-click on a word doesn't select it.

This appears to be a bug - thanks. We'll look into it.

>Note: the calendars on the demo. The so called English (US) one is
>exactly the same as the Fran├žais (FR) one on my French computer. Did
>you took 'default' instead of 'US'?

Good catch. The locale for those calendars wasn't being set explicitly, so was using the system
default. This is fixed.

Thanks again for your comments. Please feel free to post any additional comments or questions
you may have. We'd also love to hear from you if you have any interest in contributing to
the project.


View raw message