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":

http://wiki.apache.org/incubator/PivotProposal

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:

http://code.google.com/p/javabuilders/

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.

Greg



Reply via email to