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 starts respecting fallback values; it will
generate for ie7, ie9 and ie10. We can also extend the syntax so you can
say !ie9 and that will prevent the rule to match generating ie9 and also
ie10 (because it will follow ie9). That would solve most of the problems,
right?
- Or alternatively we can have a special syntax for opting-in to fallback:
e.g. ~ie6 will match ie6 and anything that falls back to ie6 (i.e. ie7).

@Thomas: I agree it is not an easy task however people who thinks that they
need to add a new user.agent, is already copying the code and adding it
anyway so I'm not sure if we are going to save much by not making it little
bit easier. I think most important question is; if you guys think that this
change adds value and useful in the long run or not. If it is not, I'm ok
with dropping it.



On Thu, Sep 12, 2013 at 11:50 AM, Goktug Gokdogan <gok...@google.com> wrote:

> 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 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 doing this broke internals of a variety of GWT widgets. The fallback
>> attribute let ie7 behave as ie6 (and ie10 as ie9) if a replace-with rule
>> set did not define specific behavior for it, but the CssResource generation
>> process creates types based on all properties available, not just the
>> properties that the CSS file was written to expect. This means that if you
>> have
>>
>> @if user.agent ie6 ie8 {
>>   //...
>> }
>>
>> then the enclosed content will only be in the _ie6 and _ie8 generated
>> classes, not _ie9 (good), _ie10 (good), or ie7 (bad). Without a fallback
>> mechanism that makes sense in CssResource, any existing GWT widget that
>> uses ClientBundle may be unusable in a project that builds its own user
>> agents.
>>
>> This is the only case we ran into before we decided it wasn't worth it -
>> GXT 3 can and should run along side or in conjunction with standard GWT
>> widgets, so this was a deal-breaker right off the bat.
>>
>>
>> On Wed, Sep 11, 2013 at 4:40 AM, Thomas Broyer <t.bro...@gmail.com>wrote:
>>
>>>
>>> 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
>>>> with the original during updates.
>>>> The root cause of this is the determination of user.agent during
>>>> runtime is statically defined in this package. I created a patch so that
>>>> code snippets to extract user agent can be defined and injected from
>>>> outside so that new permutations can be added externally without forking
>>>> the original package.
>>>>
>>>> If you hit this issue before, please take a look at https://gwt-review.
>>>> **googlesource.com/4500 <https://gwt-review.googlesource.com/4500> and
>>>> see if would make your life easier.
>>>>
>>>
>>> Not opposed to it in principle, but adding a new user.agent is not an
>>> easy task, and more often than not people actually want to add a new
>>> property to be used in conjunction to user.agent in deferred-binding rules
>>> (e.g.
>>> https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion);
>>> so I'm not sure this is the right move, as it makes it easier to do things
>>> the wrong way.
>>>
>>> As a side note, I think we should add a way to "alias" property values
>>> so we can progressively rename "gecko1_8" to "gecko" and possibly "safari"
>>> to "webkit" [1] without breaking anyone. I think this can be "faked" today
>>> using fallback-value and excluding the fallback value from the possible
>>> values (i.e. <extend-property name="user.agent" value="gecko"
>>> fallback-value="gecko1_8"/><set-property name="user.agent"
>>> value="ie6,ie8,ie9,gecko,safari,opera"/> notice the absence of "gecko1_8"
>>> here but thanks to the fallback-value, <if-property-is name="user.agent"
>>> value="gecko1_8"/> should continue to work and match the "gecko"
>>> permutation) but we cannot <set-property> the user.agent property in GWT
>>> proper as it would break those who new values and expect the set of
>>> "possible values" to automatically grow with their new value.
>>>
>>> [1] Daniel thinks we should add a "chromium" permutation –he said
>>> "blink", but I believe "chromium" would be a better name: it's not only
>>> about the rendering engine, but also the JS engine–, I know "webkit" can be
>>> used with other JS engines than JavaScriptCore but I'm unsure anyone would
>>> do it nowadays, and "webkit" probably still better matches reality than
>>> "safari".
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> 218.248.6165
>> niloc...@gmail.com
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to