Re: [e4-dev] Getting rid of the swt fragment e4.ui.widgets.fragment

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

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 <tom.schindl@xxxxxxxxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

07/16/2009 01:27 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev