I finally manage to come back to this; sorry for the delay.
@Jens: What you are suggesting (i.e. plugins) makes sense. But right now
compiler doesn't really have a real understanding of user agents and that
is a much bigger change than what I'm am planning here.
@Colin: If CssResource generator
Sorry guys, I didn't have time to read the feedback, too many things to
handle right now.
I'll go through them when I have the chance to look into this change again.
On Wed, Sep 11, 2013 at 8:10 AM, Colin Alworth niloc...@gmail.com wrote:
I've got to second Thomas on this point - adding a new
Sounds nice, although the next logical step would be to ask for permutation
processing hooks. What happens if I define a user.agent safari-mobile but
the JavaToJavaScriptCompiler executes some visitors for the webkit user
agent? I assume they won't get executed anymore.
As an example, I had
On Wednesday, September 11, 2013 11:00:36 AM UTC+2, Jens wrote:
Sounds nice, although the next logical step would be to ask for
permutation processing hooks. What happens if I define a user.agent
safari-mobile but the JavaToJavaScriptCompiler executes some visitors for
the webkit user
On Wednesday, September 11, 2013 3:10:56 AM UTC+2, Goktug Gokdogan wrote:
I recently noticed that developers are forking c.g.gwt.useragent in order
to be able to add new browser permutations to existing ones. This is
suboptimal and causes code duplication and possibly trying keep it in sync
I've got to second Thomas on this point - adding a new user.agent is very
non-trivial at least without an overhaul of CssResource generation. In GXT
3 we took the route of providing our own PropertyProviderGenerator and
adding a few new user agents (ie7, ie10 for a start), but quickly found
that
