Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [nebula-dev] Date submissions - Eric and Jeremy

Christopher J Gross wrote:
> 
> Ok cool.  So back to the comparison of the two date widgets...
> 
> Eric, based on my reading of your write-up, it seems like your widgets
> are better at the actual text entry/verification and that perhaps

Um... you should try out the widgets; I did not have a pleasant
experience.  Sorry, I've been trying to figure out a polite way to say
it but... looks my time is up.
The write-up has many errors that are plainly described on the website,
and one even on this mailing list... the snippets were apparently run
successfully though, so I'm not really sure where the miscommunication
occurred.

 One thing that was pointed out that I did not fully realize - testing a
custom pattern with the CDCSnippet is confusing.  The way to do it is to
select the first format option "Custom Pattern (type in)", and then
overwrite "Custom Pattern (type in)" with your own pattern.  I put up a
screenshot as an example:
 http://www.aspencloud.org/images/screenshots/Screenshot-CDCSnippet.png

 When I read the write-up, I also thought it sounded like the greatest
difference between the two submissions is that the CDatepicker has a
clock component, so I downloaded and ran the Comp4SWT code.

 CCalendar
  - no focus mechanism
  - select a day in the next month and the calendar jumps
  - no navigation other than month buttons (no keyboard or mouse wheel)
  - no scroll (weekly or otherwise)
  - selected day is not always visible
  - day buttons don't fill the body horizontally
  - no visual feedback to user what day the mouse is over
  - selection occurs even if mouse is moved off the day
  - only partially i18n'ed (no translated tooltips or properties file)

 DateChooser
  - CCalendar does not work if DateChooser is on a MODAL dialog
  - navigation does not follow whole Calendar fields
  - no mouse inc/dec
  - keyboard inc/dec of one field changes other fields
  - allows empty Calendar fields
  - does not block invalid keys (they write zeros)
  - allows editing mid-field, but adds new zeros at the beginning
  - custom formatter tries to reinvent java.text.DateFormat classes

Sorry to be so negative, but after reading the write-up I was really
surprised to find such limited functionality; seeing the 1.0 version
number was even more disheartening.

> Perhaps we could have one generic formatted text widget (like your
> FormattedText) that could optionally be wired up to other popup widgets.
>  We could define some contract between the popup and the text.  This
> technique might make it easier to have a time text with a time popup, a
> date text with a date popup and a datetime text with a datetime popup.

One textual selection widget would probably be best; my thought was that
this would (sooner or later) be a native SWT widget (and thus posted API
questions to BUG 19945) and that native and custom calendar and clock
components could be swapped in and out (perhaps by subclassing, perhaps
even at runtime via reflection).  I would recommend against multiple
text widgets as setting the date/time format, or pattern, should tell it
what type of graphical selection widget(s) are necessary; through my own
use, and feedback I've received, this setting should be as similar to
the java.text.DateFormat classes as possible since we're coding in java.
CDatepicker is currently in this abstraction process as it now has two
completely different types of clock - analog and discrete (per
discussion on this thread with Roland).
Eric's "themes" seem like a good idea that some users would really
prefer, so there could also be a calendar component which worked that way.

>  We might be able to go further and even have other texts and popups
> unrelated to date/time.  How about a color picker where the text value
> is the RGB and the popup is a color wheel or something?  

This is a definite, but first I think we need to figure out a good base
design for pop-up widgets.  I'm really tired of reviewing widgets that
do not work on MODAL dialogs - it is a project far far away from cool
and exciting but I think it is pretty essential.
I will gladly offer up my DropButton and DropCombo classes, though I was
honestly hoping someone had a better solution.
Once that is covered, I use pop-ups for every kind of text field and
currently have a number pad and calculator which could also be contributed.

> 
> 
> *Steve Northover <Steve_Northover@xxxxxxxxxx>*
> Sent by: nebula-dev-bounces@xxxxxxxxxxx
> 
> 09/18/2006 03:19 PM
> Please respond to
> Nebula Dev <nebula-dev@xxxxxxxxxxx>
> 
> 
> 	
> To
> 	Nebula Dev <nebula-dev@xxxxxxxxxxx>
> cc
> 	Nebula Dev <nebula-dev@xxxxxxxxxxx>, nebula-dev-bounces@xxxxxxxxxxx
> Subject
> 	Re: [nebula-dev] Date submissions - Eric and Jeremy
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> Just to be clear, it is a proposed item, not committed.
> 
> 
> *Grant Gayed/Ottawa/IBM@IBMCA*
> Sent by: nebula-dev-bounces@xxxxxxxxxxx
> 
> 09/18/2006 03:14 PM
> Please respond to
> Nebula Dev <nebula-dev@xxxxxxxxxxx>
> 
> 	
> To
> 	Nebula Dev <nebula-dev@xxxxxxxxxxx>
> cc
> 	
> Subject
> 	Re: [nebula-dev] Date submissions - Eric and Jeremy
> 
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> 
> Yes, native (where supported, emulated otherwise) date/time picker is in
> the plan for swt for 3.3, and much of the implementation work is done.
> 
> Grant
> 
> *Christopher J Gross <chris.gross@xxxxxxxxxx>*
> Sent by: nebula-dev-bounces@xxxxxxxxxxx
> 
> 09/18/2006 02:56 PM
> Please respond to
> Nebula Dev <nebula-dev@xxxxxxxxxxx>
> 
> 
> 	
> To
> 	Nebula Dev <nebula-dev@xxxxxxxxxxx>
> cc
> 	Nebula Dev <nebula-dev@xxxxxxxxxxx>, nebula-dev-bounces@xxxxxxxxxxx
> Subject
> 	Re: [nebula-dev] Date submissions - Eric and Jeremy
> 
> 
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> 
> 
> (Sorry for the late response, was on vacation last week)
> 
> Thanks for the write-up Eric.  I've just now read that the main SWT team
> is planning on developing a date picker widget as part of 3.3.  This
> would make a Nebula date widget unnecessary.  One of the founding
> principles of the Nebula project is to augment SWT, but not to compete
> with it.  
> 
> Perhaps one of the SWT guys who might be reading this could chime in and
> confirm this.  If so, it seems to make this whole discussion moot.
> 
> Regards,
> -Chris
> 
> 
> *Eric Wuillai <eric@xxxxxxxxxx>*
> Sent by: nebula-dev-bounces@xxxxxxxxxxx
> 
> 09/14/2006 06:05 PM
> Please respond to
> Nebula Dev <nebula-dev@xxxxxxxxxxx>
> 
> 	
> To
> 	Nebula Dev <nebula-dev@xxxxxxxxxxx>
> cc
> 	
> Subject
> 	Re: [nebula-dev] Date submissions - Eric and Jeremy
> 
> 
> 
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Chris, Jeremy,
> 
> I passed a few hours to study Jeremy's implementation to try to find
> differences between our two submissions.
> I will try to give you my vision of the differences I have noticed.
> Jeremy, please correct me if I made mistakes. Complete me also if I
> missed something.
> 
> First, I think that basically the calendar (CCalendar vs CDatePicker)
> and the combo (DateChooser vs CDatePickerCombo) have the same main
> features :
> - calendar : date selection, month navigation, locale support.
> - combo : controlled input of date values, with field navigation and
> support for different formats and locales.
> 
> Differences on the technologies used
> ------------------------------------
> - Comp4SWT : Java 5.0 / Eclipse 3.1 (not tested on 3.0).
> - AspenCloud : Java 1.4 / Eclipse 3.2 (incompatible with 3.1, caused by
> the use of the Spinner widget).
> 
> Differences between calendars
> -----------------------------
> CCalendar :
> - Implementation based only on basis SWT widgets : labels and buttons.
> - Colors customisation (header, days labels, day cells...), based on
> color themes, with 3 default themes provided and possibility to create
> new ones.
> - Possibility to set the font used.
> - A look that match more to this kind of control in other technologies
> (I know, it's subjective).
> 
> CDatePicker :
> - The clock !!!
> - Direct selection of month and input of year.
> - Implementation based on custon widgets for days grid, navigation buttons.
> - "Go today" button.
> 
> Differences between combos
> --------------------------
> I just test CDatePickerCombo with its snippet. Not with custom patterns,
> so can not say if exotic patterns are fully supported.
> 
> DateChooser :
> - Date input in the Text widget is delegated to a FormattedText /
> DateFormatter. So it supports differents input and display patterns.
> - No support for the moment of long format for months input (month names
> with pattern MMM or MMMM).
> - Calendar used for input is in lenient mode. So the increment /
> decrement with arrows on a field has effect on the superior field.
> - Limited to date values (its not a DateTimeChooser ;-) But time and
> datetime input are supported by FormattedText with the corresponding
> formatters.
> - Button with an image, with the possibility to change the image used.
> - Possibility to set the font used, common to the text widget and the
> calendar.
> 
> CDatePickerCombo :
> - Field selection does not allow to select the full content of the Text
> widget for copy / paste operations.
> - Possibility to use month names for input, limited to increment /
> decrement by the arrows. Input by keyboard is impossible.
> - Support time input.
> - Spinner
> 
> Comp4SWT FormattedText
> ----------------------
> In complement, Comp4SWT has FormattedText with its formatters. And I
> think that is the main difference.
> FormattedText is a decorator based on the same principles that JFace
> viewers. It acts as a controller, delegating the formatting features to
> formatters (the model). This gives the possibility to associate
> formatters on a Text widget in function of values to edit. Formatters
> can be instanciated and passed in parameter of FormattedText. They can
> also be created automatically when a value is setted and no formatter
> has been provided. This is realized by a customizable factory.
> Text widget is created by the FormattedText, or can be passed in
> parameter. Then it is possible to use FormattedText in UI Forms.
> 
> Formatters provided actually are :
> - DateTimeFormatter : date and time values. Support two patterns : one
> for input and one for display (when focus is outside the Text widget).
> - DateFormatter : extends DateTimeFormatter to limit patterns to date.
> - TimeFormatter : extends DateTimeFormatter to limit patterns to time.
> - NumberFormatter : Number values. Support too input and display patterns.
> - MaskFormatter : Mask input for strings, allowing to control the format
> of strings like phone numbers.
> 
> FormattedText gives a consistent way to create forms with input and
> display formatting features for differents kinds of values. Formatters
> model is extendable and the factory allowes to replace default
> formatters for standard types, or add new ones.
> 
> To end this comparison, I think that DateChooser and CDatePickerCombo
> have two differents and incompatible implementations of the text input.
> On the other hand, I think really possible to use, with a minimum
> effort, both calendars. It is also possible to extend DateChooser to
> support time pattern, with support of Jeremy's clock.
> 
> Last, but not least, congratulations to Jeremy for the clock. It's
> really a good job!
> 
> Regards,
> 
> Eric
> 
> Christopher J Gross a écrit :
>>
>> Hi Eric,
>> Hi Jeremy,
>>
>> I'm excited that more and more widgets being offered up to Nebula, but
>> I'm also a little concerned about the overlap.  Users who come to the
>> Nebula webpage will be confused if they are confronted with multiple
>> widgets of the same type.  I am not strictly against that, but if there
>> are multiple similar widgets I'd like to see them differentiate
>> themselves in some way.  The table widgets we have, all take somewhat
>> different approaches.  
>>
>> Can you guys let us know what differentiates the date widgets?  Why
>> would someone use one over the other?  If they are similar, could you
>> guys combine efforts?
>>
>> Regards,
>> -Chris
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> nebula-dev mailing list
>> nebula-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/nebula-dev
> _______________________________________________
> nebula-dev mailing list
> nebula-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/nebula-dev
> _______________________________________________
> nebula-dev mailing list
> nebula-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/nebula-dev
> _______________________________________________
> nebula-dev mailing list
> nebula-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/nebula-dev
> _______________________________________________
> nebula-dev mailing list
> nebula-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/nebula-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> nebula-dev mailing list
> nebula-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/nebula-dev


Back to the top