[
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