#1506 Some concerns about FWT

DanielFath Mon 25 Apr 2011

As of now all FWT's widgets have been blocked from extending using internal make. The design isn't really much adaptable and makes one having to extend a certain button a real nightmare.

So I've been thinking is there any way for FWT's classes other than fwt::Canvas and fwt::Pane to be extended? Is JavaScript the only block? Could we somehow make enhancing a Button in JS easier than having to write your own button from scratch? Maybe default to a conservatively stylized Dojo version?

Yuri Strot Mon 25 Apr 2011

The SWT is not extensible as well. The problem with SWT is that all implementation is platform specific and for different platforms you actually have different libraries with similar public API. With FWT you have similar problem.

Let's say you want to have button with different look and feel (for example with gradient background). In JavaScript you can use CSS, but it doesn't work in Java. So you have two options:

  • If you would like to use FWT only in browser you can create your fwt::Pane with native implementation. JS peer has access to DOM so you can create your own button with custom style.
  • If you want to use your button in any environment you should use common components and render your button on fwt::Canvas.

Extensible widgets will not help you in any case while all implementation is native.

DanielFath Mon 25 Apr 2011

When you mean all implementation is native you mean that in native as OS-specific or native as in Java? It strikes me that FWT is closer in execution than SWT (Labels can be made outside Shell much like Swing). Perhaps we could use a Swing binding for FWT :P In that case how would we switch from SWT binding to Swing?

Yuri Strot Tue 26 Apr 2011

When you mean all implementation is native you mean that in native as OS-specific or native as in Java?

I mean FWT delegates to Java SWT or JavaScript. And SWT itself delegates to different OS-specific implementation. If there is something which makes sense for any platform it can be implemented natively (SWT/JavaScript) and included to FWT by default.

Labels can be made outside Shell much like Swing

What do you mean?

Perhaps we could use a Swing binding for FWT :P In that case how would we switch from SWT binding to Swing?

We touched upon this topic with Brian a little and he suggests to start off with two versions of fwt pod (one for Swing and one for SWT) as much simplest way.

DanielFath Tue 26 Apr 2011

Labels can be made outside Shell much like Swing

What do you mean?

In SWT Label isn't really useful when it's outside Shell, it has no preffered size, etc. In Swing Label has a size regardless of whether or not is bound to a Panel or a Shell.

brian Wed 27 Apr 2011

In SWT Label isn't really useful when it's outside Shell, it has no preffered size, etc. In Swing Label has a size regardless of whether or not is bound to a Panel or a Shell.

That particular problem is pretty much universally true of any widget that requires font metrics to determine its preferred size. Pretty much ever widget tool requires you to target a specific graphics device before you can do things like compute font metrics (say one screen might be different than a printer). Sometimes you can fudge it and assume the display or metrics though.

As a general comment to this thread: FWT is designed to provide two things:

  1. a simple library of widgets for building basic UIs
  2. two clean plug points for custom widgets: Pane and Canvas

It is not designed as some super-duper-extend-whatever-you-want-framework. In the case of SWT, the widgets are backed by real peers so they aren't extensible anyways.

That said there might be some nice opportunities to create subclasses of Canvas for base customized widgets like custom buttons etc. And in fact Andy has built a really nice library of widgets specifically for browser environments that we will open source at some point.

Login or Signup to reply.