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
About the possible calendaring API...

When I was envisioning a calendar/date-/timepicker widget API that I never had time to implement yet, I was thinking that since the primary function of such a widget would be *selection* of *dates*, the most sensible thing would be to copy the API of the list (with few modifications of course):
  • Constructor style bits:
    SWT.SINGLE, SWT.MULTI // Either single or multiple dates selection support
  • Methods for setting and getting the selected dates (included three flavors for all three ):
    public Date[] getSelection(); // Returns the array of selected dates
public void setSelection(Date[] selection); // Sets selection of dates
public Calendar[] getSelectedCalendars(); // Returns selection in Calendar objects
public void setSelectedCalendars(Claendar[] selection); // Set selection in calendar objects
public long[] getSelectionInMillis(); // Return selected date values in milliseconds
public void setSelectionInMillis(long[] selection); // Set selection in milliseconds
  • Standard selection change events:
    SWT.Selection  // whenever user initiated selection change event occurs
SWT.DefaultSelection  // not quite sure, but the general usage seems to imply doubleclicking
In addition there should be an API to help navigate through dates - the most logical API for this would probably look much like java.util.Claendar class:
  • get/set time like in calendar class (these will set/get only a single selection values - mot sure how these should behave in multiselect date widget):
    public int get(int field)
public void set(int field, int value)
public void set(int year, int month, int date)
public void set(int year, int month, int date, int hourOfDay, int minute)
public void set(int year, int month, int date, int hourOfDay, int minute, int second)
public long getTimeInMillis()
public void setTimeInMillis()
  • Calendar mode/behavior tuning:
    public TimeZone getTimeZone()
public void setTimeZone(TimeZone value)
public boolean isLenient()
public void setLenient(boolean lenient)
public int getFirstDayOfWeek()
public void setFirstDayOfWeek(int value)
public void setMinimalDaysInFirstWeek(int value)
public int getMinimalDaysInFirstWeek()
public int getMinimum(int field)
public int getMaximum(int field)
public int getGreatestMinimum(int field)
public int getLeastMaximum(int field)
public int getActualMinimum(int field)
public int getActualMaximum(int field)
  • Modify/compare selected values:
    public void add(int field, int amount)
public void roll(int field, boolean up)
public void roll(int field, int amount)
public boolean before(Object when)
public boolean after(Object when)
  • Control date/time selection limits - (these would be great help for a datepicker presentation to show "out of bounds" values as "disabled"):
    public int getLowerBound(int field)
public long getLowerBoundMillis()
public Calendar getLowerBound()
public Date getLowerBoundTime()
public void setLowerBound(int field, int value)
public void setLowerBoundMillis(long milliseconds)
public void setLowerBound(Date value)
public void setLowerBound(Calendar value)

public int getUpperBound(int field)
public long getUpperBoundMillis()
public Calendar getUpperBound()
public Date getUpperBoundTime()
public void setUpperBound(int field, int value)
public void setUpperBoundMillis(long milliseconds)
public void setUpperBoundTime(Date value)
public void setUpperBound(Calendar value)
  • Anything else I forgot...?
Of course - I added probably more flavors of the various API methods that might be necessary, but this is just an initial suggestion and most of these methods would delegate to a single method anyway (I assume it would be methods dealing with Calendar, as this is much easier to manipulate than long values and Date object is almost deprecated)

If done right - this would make a great abstract class API that all kinds of date widgets would inherit from.
This way it would make it possible to introduce various national calendar widget implementations (e.g. Jewish, Buddhist, Julian, etc) and still be able to operate them via th same api.

Jeremy Dowdall kirjutas mulle  midagi seesugust: 
It would, however, be great if the Nebula group could work on a date 
selection API in conjunction with the SWT team because, unlike table
widgets, there is no "commonly understood" way for a date selector to
be programmed.  In doing so, I think it is understood that SWT's first
and foremost goal is to native widgets and thus will have limitations
on what it can and can't do with an API.  I think it is perfectly
reasonable that the Nebula widget could adjust to the SWT API and only
add functionality on top.  I imagine developers learning all the new
widgets would appreciate some common ground.
-- 
  Roland Tepp

begin:vcard
fn:Roland Tepp
n:Tepp;Roland
org:Videobet
adr:;;;Tallinn;;;Estonia
email;internet:roland@xxxxxxxxxxxx
title:Software Developer
x-mozilla-html:FALSE
url:http://www.videobet.com/
version:2.1
end:vcard

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Back to the top