On Wed, Mar 23, 2011 at 2:18 PM, Philippe Beaudoin <
philippe.beaud...@gmail.com> wrote:
> Nice. And will you have the shorter:
>
> For permutations that are guaranteed to support it?
>
Eventually... maybe. When we drop support for older versions of webkit and
FF, we could switch those to lose
I'm really looking forward to the new widgets. Sounds extremely promising!
2011/3/23 John LaBanca
> @dflorey -
>
> We do plan to include some HTML5 widgets using the Appearance pattern.
> HTML5 widgets follow a cool pattern where you can inline the fallback into
> the HTML5 element. Browsers t
Nice. And will you have the shorter:
For permutations that are guaranteed to support it?
On Wed, Mar 23, 2011 at 11:11 AM, John LaBanca wrote:
> @dflorey -
> We do plan to include some HTML5 widgets using the Appearance pattern.
> HTML5 widgets follow a cool pattern where you can inline the f
@dflorey -
We do plan to include some HTML5 widgets using the Appearance pattern.
HTML5 widgets follow a cool pattern where you can inline the fallback into
the HTML5 element. Browsers that do not support the HTML5 element naturally
show the fallback, while browsers that do support the HTML5 wid
Antoine, I think the Appearance plan is closer to what you want than
you realize.
In particular, you should know that we're working on a change to
UiBinder to allow it to generate SafeHtmlRenderer instances, and then
to allow those instances to manage cell event handling. We'll share a
design prop
I am wondering if you are considering to use html5 widgets if available and
provide a fallback gwt implementation for browsers that do not (yet) support
widgets like
http://slides.html5rocks.com/#semantic-tags-2
I think in general GWT has the right tools for using native browser stuff
whenever
With the appearance pattern your proposed Theme class would be the same as a
GWT module containing all the deferred bindings for changing all the
appearance classes of all widgets. So you would inherit this theme module
and you are done. I think you could also overwrite a specific deferred
bind
Hi,
I'm fairly new in the GWT development but I'm not sure that the selected
development answers the initial need. Let me explain you why (sorry it is
rather long). It is also very possible that I'm completely wrong.
The main goal is allowing the developers to easily theme their application.
As a
Sorry for the long delay. I just read through the email chain and tried to
encapsulate the common concerns below:
*Appearance: abstract class or interface*
**I still think Appearance should be an abstract class. tbroyer is correct
that adding a method might be a breaking change for some apps, bu
On Monday, February 28, 2011 12:42:30 PM UTC-8, John LaBanca wrote:
>
> On Mon, Feb 28, 2011 at 3:14 PM, Jeff Larsen wrote:
>
>>
>>
>> On Mon, Feb 28, 2011 at 1:34 PM, John LaBanca wrote:
>>
>>> Let me clarify what I had in mind for replacing the default GWT
>>> appearance. In the future, we m
On Mon, Feb 28, 2011 at 3:14 PM, Jeff Larsen wrote:
>
>
> On Mon, Feb 28, 2011 at 1:34 PM, John LaBanca wrote:
>
>> Let me clarify what I had in mind for replacing the default GWT
>> appearance. In the future, we might add a new DefaultAppearance
>> implementation, but would leave the existing
On Mon, Feb 28, 2011 at 1:34 PM, John LaBanca wrote:
> Let me clarify what I had in mind for replacing the default GWT appearance.
> In the future, we might add a new DefaultAppearance implementation, but
> would leave the existing one. We would probably give it some trendy name,
> like ModernA
Ok, I understand better now. In that case I see no difference between:
new ButtonCell(myResources)
and
new ButtonCell(new DefaultAppearance(myResources))
I prefer the second one, as the first one does not make it obvious that:
new ButtonCell()
and
new ButtonCell(myResources)
lead to potent
Let me clarify what I had in mind for replacing the default GWT appearance.
In the future, we might add a new DefaultAppearance implementation, but
would leave the existing one. We would probably give it some trendy name,
like ModernAppearance or DefaultAppearance2013, leaving DefaultAppearance.
On Mon, Feb 28, 2011 at 10:30 AM, Jeff Larsen wrote:
>
> By forcing the user to do
>
> new DefaultAppearance(Resource)
>
> you're removing their ability to globally change the appearance. You've now
> introduced a much tighter coupling than was there previously. As a for
> instance, lets say I wan
> On Saturday, February 26, 2011 9:14:37 PM UTC+1, Philippe Beaudoin wrote:
>> 1) The ButtonCell(DefaultAppearance.Resources) constructor can be
>> confusing, I think it should be dropped.
>> 2) Providing a custom DefaultAppearance.Resources lead to somewhat smelly
>> code.
>
> -1 on both the abo
On Mon, Feb 28, 2011 at 3:22 AM, Thomas Broyer wrote:
> On Saturday, February 26, 2011 9:14:37 PM UTC+1, Philippe Beaudoin wrote:
>> 1) The ButtonCell(DefaultAppearance.Resources) constructor can be
>> confusing, I think it should be dropped.
>> 2) Providing a custom DefaultAppearance.Resources le
On Saturday, February 26, 2011 9:14:37 PM UTC+1, Philippe Beaudoin wrote:
>
> John, I really like this idea. It's well thought-out and the customization
> hooks seem at once powerful and easy to use. I like the use of
> to provide a simple way to perform an app-wide appearance
> switch. Here
On Sat, Feb 26, 2011 at 4:35 PM, Jeff Larsen wrote:
>
> Sorry, that is far better, but there still is a problem. With that way of
> doing things is then you've lost your ability to use the .gwt.xml file to
> swap out the Appearance as you're now using a new instead of a GWT.create.
There are stil
I thinks there is a misunderstanding. My proposal is just to not provide the
convenience constructor, so instead of:
new ButtonCell(resources);
You'd do:
new ButtonCell(new DefaultAppearance(resources));
Making it crystal-clear that your ButtonCell is using DefaultAppearance. The
convenien
>
> *1) The ButtonCell(DefaultAppearance.Resources) constructor can be
> confusing, I think it should be dropped.
> *
>
> I would prefer the option. Lets say you have a 2 styles of buttons. A blue
> cancel button and a grey standard type button. With the current proposal, I
> would be able to u
*1) The ButtonCell(DefaultAppearance.Resources) constructor can be
confusing, I think it should be dropped.
*This constructor gives the impression that you are using the app-wide
Appearance where in fact you are using DefaultAppearance. This could lead to
the following confusing use case:
- T
> - There is no public addStyleName on ButtonCell so the user cannot
> apply a custom CSS class and then rely on CSS selectors to style
> deeper elements.
True, but ButtonWidget would have addStyleName/removeStyleName.
John is right that appearances could be added/deprecated, but I was
thinking
John, I really like this idea. It's well thought-out and the customization
hooks seem at once powerful and easy to use. I like the use of
to provide a simple way to perform an app-wide appearance
switch. Here are a couple of remarks:
Sorry it's so long. Here is the *tl;dnr* version:
1) The But
It would be great if localized messages would be moved to ClientBundle so
that we can include localized messages as part of the widget styling. This
is e.g. very useful for tooltips etc.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I am really, really excited about this.
+1 for aggressive Ruby style deprecation. It would be nice to get rid of the
FooListeners/SourcesFoo stuff that is just clutter now and has
been deprecated since 1.6
I have no problem with ButtonWidget naming style however. In eclipse you can
just type
Thomas Broyer wrote:
> Finally, I don't really like the Widget suffix naming convention, that's
> what "namespaces" (packages in Java) are for (tell a Button from another
> Buton), but I sure could live with it.
> I already have those "naming conflicts" using Guava and gwt-dev –which
> includes a
I support the overall idea.
A few notes though:
I'm worried about the events in the ButtonCell example. If they're just
there to provide hooks to inject styles, then:
1. you probably don't need them if you use a "native button" appearance;
which means you're listening to events but doing
28 matches
Mail list logo
