I should have written: "date selector API" rather than "date selection API", meaning the API for the whole widget.
Does this get/set pair imply that (at least initially) the SWT widget will not have a time component? Steve Northover wrote: > >> It would, >> however, be great if the Nebula group could work on a date selection API >> in conjunction with the SWT team because, > > We are in agreement. The current thinking is get/set 3 integers (day, > month, year). We have yet to figure out what to do with the formatting > but will consult the operating systems (and Nebula). I'm pretty sure > that's not what you are asking, is it? > > > > *Jeremy Dowdall <[EMAIL PROTECTED]>* > Sent by: [EMAIL PROTECTED] > > 09/18/2006 05:43 PM > Please respond to > Nebula Dev <[email protected]> > > > > To > Nebula Dev <[email protected]> > cc > > Subject > Re: [nebula-dev] Date submissions - Eric and Jeremy > > > > > > > > > Steve Northover wrote: >> >> Sure. The focus of SWT is native so a native version of the control is >> first priority for SWT. For example, WinCE and phone versions of SWT >> have long wanted this native widget. However, the native version of the >> control might be somewhat less flexible for desktop applications or some >> types of programs. For example, a native calendar widget is unlikely to >> provide fine control over how a day is drawn or allow you to draw your >> own adornments over top. A program that was based around a calendar >> might find this too restrictive and have need of an emulated version. >> Hence, the Nebula one. Do you agree? > > As I work on a calendaring application, I certainly do agree that the > present native widgets are too restrictive. For this type of > application a graphical date selector is a prominent part of the UI > which the user will reference and interact with on a very regular basis. > Being such an integral part of the application, I cannot afford for it > to appear and operate as differently as it does on each platform - I > need a date selector which will blend in with the native widget set, but > maintain a consist interface. I also do not want to be restricted with > the functionality of 1/8 of my usable space, and thus may optimize more > than the native widgets. > Many other applications may not need/want these changes and so I did not > see the Nebula widget and SWT widget directly competing. 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. > _______________________________________________ > nebula-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/nebula-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > nebula-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/nebula-dev _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
