Hi Tom, By "what should we do" I meant today, with no time left for e4.
But I took another go at copying the classes and I have a non-fragment version working (org.eclipse.e4.ui.widgets), thanks to some databinding help from Boris (pull on a thread and it just keeps going and going...). I've released the changes, have the contacts, photo, and self hosting workbench demos running, and Paul is about to do a test build. Future: I'd really love to see a future where it was easier to build custom widgets. On the web, the UI is quite rich because everyone just assembles everything from the basics (amazing what you can do with a box model, margins, borders, and images). What Steve and I discussed for SWT and tab folder specifically was a model where they provide the structural implementation (for example, TabItems are in TabFolders) and the client is left to draw whatever they want in the tabs plus control over margins/spacing. That'd be a good start, is all I needed, and would provide lots of avenue for exploration. Potentially the model could be expanded to other widgets to do things like richer borders, etc. Sounds like your ideas for Nebula are along same lines? Kevin Tom Schindl <[email protected]> Sent by: [email protected] 07/16/2009 01:27 PM Please respond to E4 Project developer mailing list <[email protected]> To E4 Project developer mailing list <[email protected]> cc Subject Re: [e4-dev] Cant't compile current e4 trunk Hi Kevin Kevin McGuire schrieb: > > Hi Tom, > > I think it should be much easier to write custom widgets. The ETab* > classes could for example be in Nebula. I had some discussions with > Steve on this subject about allowing clients to extend and draw their > own graphics within the custom widgets, leaving the basic widget > behaviour/structure in place, which matches exactly what we wanted to do > here. I think something along those lines is the right strategy in the > future. > > WRT. the fragment, yes I really regret the added complexity in setup. > The only other choices I see are: > > 1) Forgo the new widgets, just pull them -1 because where do we stop? We can't move a custom drawn widget to SWT simply because we are Platform-UI what picture would this make to the community who wants to see many other widget getting part of SWT and now we are adding a 3rd Tab-Widget to SWT though we alway argued that SWT should be as small and slim as possible? > 2) Copy CTab*. But then we need to copy listeners, and databinding, and... > Copy CTab* and move over to Nebula and enrich it with features or make it a new plugin in E4 for the time being. BTW we at Nebula are thinking of a base canvas implementation providing you with cool features like gradients, animation out of the box (even SVG interpretation is on the whish list) [1]. Nebula is hopefully going to get modified soon in a way that adoption from other projects might not be that a big problem any more. Soltution 3: Make SWT-people open the API for us. As outlined in my first reply I don't really know of the history of CTabFolder but to me it looks like it was created especially for the needs of Platform-UI, right? Still I really don't want it to be a fragment hijacking the SWT-Namespace because we are to some extend breaking our own rules we are trying to teach the consumers of our API (if something is not meant to be subclassed don't do it, package-visible stuff is not API and can break you at any given time so don't hijack my package simply because it is possible, ...). Tom [1]http://www.aspencloud.com/cwt -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl geschaeftsfuehrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5/1 A-6020 innsbruck phone ++43 512 935834 _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
