Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
I think we are making the things too complex. Initially, we wanted to remove the code of the existing generator for the CssResource and deprecated the existing syntax. It's why we have introduced the in-memory automatic conversion. Now, we've decided to keep the existing generator in GWT 2.7. So I think that we had better to remove this automatic conversion and choose the right generator in fonction of the file extension. People that want to use GSS have to use files with .gss extension. Old files with .css extension will continue to work because the current generator will be used for these kind of files. For the uibinder, we add a temporary attributes (and/or we can foreseen an configuration property that enable GSS by default in UiBinder.) That simplify a lot the implementation, removes three configuration properties (CssResource.enableGss, CssResource.legacy, CssResource.conversionMode) and we support all uses cases of application using third party libraries that will result of a mix of GSS and CSS. So it's simpler for the user and simpler for us. In the next release of GWT, when we remove the code for the existing generator, we will be able to reintroduce this automatic in-memory conversion if we want still to support the old syntax. Now I think we have to mark the current syntax of CssResource as deprecated in favor of GSS. In order to able to remove the generator in the next releases. Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the extra directory) if the -extra flag is set. Julien On Mon, Oct 6, 2014 at 11:43 PM, 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: We worked on a migration plan a few weeks back. I don't think we need to mix css and gss together inside the same app. At this point, the libraries have multiple reasonable options on compatibility: 1- Provide both css and gss file for the resource (recommended). The library will work fine regardless if the app enables gss or not as the right file will be chosen for the app. That's what we will do for internal resources in the SDK. 2- Keep providing the css file and make sure it works in strict mode. The library will work fine in css mode and will work with gss only if the legacy mode is enabled. 3- Keep the old css that requires lenient mode. The library will work fine in css mode and *may* work with gss if lenient legacy mode is enabled. More problematic part is the css inside uibinder. Like you said, simplest option is to introduce a temporary attribute in ui:style tag that marks the content as gss. In this case it is more tricky for the library to support compatibility mode similar to the mode (1) above. Either the lib should write the style that both compiles with css and gss or if it is not feasible then it should extract the resource to a file and follow the two file approach described above. On Mon, Oct 6, 2014 at 12:54 PM, Julien Dramaix julien.dram...@gmail.com wrote: Hmm but still a bit of work if a library has lots of inline styles and wants to use GSS stuff. If you want to use GSS in all of your inline styles, you have first to convert them to GSS and it will take more time than simply adding an attribute that say that this inline style is using GSS. The problem with UiBinder is that we don't know if the developer is using CSS or GSS because the CssResource interface is generated and we cannot based our logic on the file extension as we do with normal CssResource. I have still to investigate but I'm pretty sure that adding an attribute will be the easiest way to support correctly GSS in uibinder inline style. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2FYLyv%3DWYfOi0TqtojPbCTPkgzApW6J3BwnmJP19HVAQ%40mail.gmail.com
[gwt-contrib] Re: Last call for patches
Hi, I assign you for an old waiting patch : https://gwt-review.googlesource.com/#/c/5341/ Allow to set emptyTableWidget and loadingIndicator in uibinder Can you add this patch to GWT 2.7 Thanks, Patrice Le mardi 7 octobre 2014 02:40:27 UTC+2, Daniel Kurka a écrit : Hi all, as a reminder: Please make sure to get your patches in for GWT 2.7 until tomorrow (October 7th). -Daniel -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a9bc2401-8f3d-4204-9be6-833e433fcc17%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
I didn't take notes in the meetup so I cannot recall all the reasons (perhaps someone else did?) but I think one of the reasons to introduce in memory conversion was to get rid of the CSS generator code with the GSS release and another one was the possible complications of coexisting css and gss in the same page (e.g. name collisions). Given that we cannot get rid of the CSS generator in 2.7 and if you think everything would be fine with css/gss mixed together (e.g. with prefixes), I'm totally fine with kicking in-memory conversion out and it is definitely not required for 2.7 even if we decide to keep it. However, arguably there might be still value in having an experimental flag to enable GSS as it is not well tested yet. On Tue, Oct 7, 2014 at 1:37 AM, Julien Dramaix julien.dram...@gmail.com wrote: I think we are making the things too complex. Initially, we wanted to remove the code of the existing generator for the CssResource and deprecated the existing syntax. It's why we have introduced the in-memory automatic conversion. Now, we've decided to keep the existing generator in GWT 2.7. So I think that we had better to remove this automatic conversion and choose the right generator in fonction of the file extension. People that want to use GSS have to use files with .gss extension. Old files with .css extension will continue to work because the current generator will be used for these kind of files. For the uibinder, we add a temporary attributes (and/or we can foreseen an configuration property that enable GSS by default in UiBinder.) That simplify a lot the implementation, removes three configuration properties (CssResource.enableGss, CssResource.legacy, CssResource.conversionMode) and we support all uses cases of application using third party libraries that will result of a mix of GSS and CSS. So it's simpler for the user and simpler for us. In the next release of GWT, when we remove the code for the existing generator, we will be able to reintroduce this automatic in-memory conversion if we want still to support the old syntax. Now I think we have to mark the current syntax of CssResource as deprecated in favor of GSS. In order to able to remove the generator in the next releases. Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the extra directory) if the -extra flag is set. Julien On Mon, Oct 6, 2014 at 11:43 PM, 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: We worked on a migration plan a few weeks back. I don't think we need to mix css and gss together inside the same app. At this point, the libraries have multiple reasonable options on compatibility: 1- Provide both css and gss file for the resource (recommended). The library will work fine regardless if the app enables gss or not as the right file will be chosen for the app. That's what we will do for internal resources in the SDK. 2- Keep providing the css file and make sure it works in strict mode. The library will work fine in css mode and will work with gss only if the legacy mode is enabled. 3- Keep the old css that requires lenient mode. The library will work fine in css mode and *may* work with gss if lenient legacy mode is enabled. More problematic part is the css inside uibinder. Like you said, simplest option is to introduce a temporary attribute in ui:style tag that marks the content as gss. In this case it is more tricky for the library to support compatibility mode similar to the mode (1) above. Either the lib should write the style that both compiles with css and gss or if it is not feasible then it should extract the resource to a file and follow the two file approach described above. On Mon, Oct 6, 2014 at 12:54 PM, Julien Dramaix julien.dram...@gmail.com wrote: Hmm but still a bit of work if a library has lots of inline styles and wants to use GSS stuff. If you want to use GSS in all of your inline styles, you have first to convert them to GSS and it will take more time than simply adding an attribute that say that this inline style is using GSS. The problem with UiBinder is that we don't know if the developer is using CSS or GSS because the CssResource interface is generated and we cannot based our logic on the file extension as we do with normal CssResource. I have still to investigate but I'm pretty sure that adding an attribute will be the easiest way to support correctly GSS in uibinder inline style. -- 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 . To view this discussion on the web visit
Re: [gwt-contrib] Removal of IE6/7 specific code from the code base
I've just submitted a shallow removal of IE6 specific code in https://gwt-review.googlesource.com/#/c/9513/ - this patch starts with all .gwt.xml files that mention the user.agent value ie6 and removes those property checks, along with any classes *only* referenced from those rebind rules. Far from a complete job of what remains, but takes another swipe at removing old dead junk. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9c02912b-fd7f-4594-9287-061d166ead8c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
Sorry for the thread necromancy, but aside from https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion this was the only relevant existing conversation I could find on the topic. In GWT 2.6 user.client.Element was finally deprecated, though done in a way to avoid any backward compatibility breakage. For example, UiObject now has two setElement methods, one for user.client.Element and another for dom.client.Element. However, UiObject.getElement still returns user.client.Element, as do a few other methods, as of master when I write these words. I'm submitting a patch that first amends UiObject.getElement and SimplePanel.getContainerElement to return dom.client.Element. My thinking is that we need an API-breaking release which still holds user.client.Element, but doesn't actually use them, allowing downstream libraries or projects to be compatible with more than one release. The alternatives as I'm currently seeing them, after deprecating in an initial release a) force a big jump, removing all traces of user.client.Element at once, meaning a library that is compatible with 2.x may not be compatible with 2.x+1. Not ideal (as a downstream library author, who doesn't want to force users to only support a single version of GWT at a time, as bugs do happen, even in GWT), but certainly easier to maintain. b) do this two-step dance, making API breakage twice, but with the goal of shifting to the new API within GWT itself (and encouraging it downstream), then a version later removing the old one. Any library/project compatible with N is then compatible with N+1 in as many cases as possible. If we like b), I'd leave any static DOM methods, but dig in further and hit any overridable methods. If a) is preferred, we can just cut to the chase and remove user.client.Element entirely today. Initial patch (subject to later discussion) is at https://gwt-review.googlesource.com/9514. On Monday, December 21, 2009 5:10:47 PM UTC-6, Thomas Broyer wrote: Hi Googlers, How about deprecating c.g.g.user.client.Element and c.g.g.user.client.DOM altogether and port all existing widgets to c.g.g.dom.client.*? A first pass, say in 2.1, wouldn't break public APIs, still using c.g.g.user.client.Element as public and protected methods' return type and fields; only the second pass (in 2.2 or even 2.3) would completely get rid of c.g.g.user.client.Element. As for c.g.g.user.client.DOM, there are a few methods that have no equivalent in c.g.g.dom.client.* (getChild/insertChild/etc. for instance, which deal with child elements, not child nodes). Those would have to either be moved to c.g.g.dom.client.Element or removed altogether in the end (which means deprecated with replacement API vs. just deprecated in the mean time). Most widgets have complete control over their DOM, so changing from child element to child node shouldn't break them. I volunteer to providing patches (probably one widget at a time), but I'd like to know upfront if I'd waste my time or if it'd have a chance of being accepted. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/04e16fb1-6fd5-456f-b421-771c6761da86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
Hi all, summarizing the discussion I just had with Julien: We want to have the in memory conversion in GWT 2.7 (even if it is not battle tested yet), since this is the way to move foward. We can even do a followup release (2.8) as soon as google is using it in production and we sorted all issues out. If GSS is turned on we will: - We will make a decision which generator to use based on file extension - You can not mix gss / css on the same interface - In UiBinder we will add a new attribute to tell that this interface needs gss (default css) - If lib has gss in it the app using that lib needs to have it enabled. I think there is good value in including this in GWT 2.7 since we can ask for external feedback as well, while at the same time making sure its mature within google. -Daniel On Tuesday, October 7, 2014 8:55:27 AM UTC-7, Goktug Gokdogan wrote: I didn't take notes in the meetup so I cannot recall all the reasons (perhaps someone else did?) but I think one of the reasons to introduce in memory conversion was to get rid of the CSS generator code with the GSS release and another one was the possible complications of coexisting css and gss in the same page (e.g. name collisions). Given that we cannot get rid of the CSS generator in 2.7 and if you think everything would be fine with css/gss mixed together (e.g. with prefixes), I'm totally fine with kicking in-memory conversion out and it is definitely not required for 2.7 even if we decide to keep it. However, arguably there might be still value in having an experimental flag to enable GSS as it is not well tested yet. On Tue, Oct 7, 2014 at 1:37 AM, Julien Dramaix julien@gmail.com javascript: wrote: I think we are making the things too complex. Initially, we wanted to remove the code of the existing generator for the CssResource and deprecated the existing syntax. It's why we have introduced the in-memory automatic conversion. Now, we've decided to keep the existing generator in GWT 2.7. So I think that we had better to remove this automatic conversion and choose the right generator in fonction of the file extension. People that want to use GSS have to use files with .gss extension. Old files with .css extension will continue to work because the current generator will be used for these kind of files. For the uibinder, we add a temporary attributes (and/or we can foreseen an configuration property that enable GSS by default in UiBinder.) That simplify a lot the implementation, removes three configuration properties (CssResource.enableGss, CssResource.legacy, CssResource.conversionMode) and we support all uses cases of application using third party libraries that will result of a mix of GSS and CSS. So it's simpler for the user and simpler for us. In the next release of GWT, when we remove the code for the existing generator, we will be able to reintroduce this automatic in-memory conversion if we want still to support the old syntax. Now I think we have to mark the current syntax of CssResource as deprecated in favor of GSS. In order to able to remove the generator in the next releases. Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the extra directory) if the -extra flag is set. Julien On Mon, Oct 6, 2014 at 11:43 PM, 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com javascript: wrote: We worked on a migration plan a few weeks back. I don't think we need to mix css and gss together inside the same app. At this point, the libraries have multiple reasonable options on compatibility: 1- Provide both css and gss file for the resource (recommended). The library will work fine regardless if the app enables gss or not as the right file will be chosen for the app. That's what we will do for internal resources in the SDK. 2- Keep providing the css file and make sure it works in strict mode. The library will work fine in css mode and will work with gss only if the legacy mode is enabled. 3- Keep the old css that requires lenient mode. The library will work fine in css mode and *may* work with gss if lenient legacy mode is enabled. More problematic part is the css inside uibinder. Like you said, simplest option is to introduce a temporary attribute in ui:style tag that marks the content as gss. In this case it is more tricky for the library to support compatibility mode similar to the mode (1) above. Either the lib should write the style that both compiles with css and gss or if it is not feasible then it should extract the resource to a file and follow the two file approach described above. On Mon, Oct 6, 2014 at 12:54 PM, Julien Dramaix julien@gmail.com javascript: wrote: Hmm but still a bit of work if a library has lots of
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
Can you also summarize why we need in memory conversion as opposed to simpler alternative? So it is documented for the next time when we will have similar discussion :) On Tue, Oct 7, 2014 at 4:00 PM, Daniel Kurka danku...@google.com wrote: Hi all, summarizing the discussion I just had with Julien: We want to have the in memory conversion in GWT 2.7 (even if it is not battle tested yet), since this is the way to move foward. We can even do a followup release (2.8) as soon as google is using it in production and we sorted all issues out. If GSS is turned on we will: - We will make a decision which generator to use based on file extension - You can not mix gss / css on the same interface - In UiBinder we will add a new attribute to tell that this interface needs gss (default css) - If lib has gss in it the app using that lib needs to have it enabled. I think there is good value in including this in GWT 2.7 since we can ask for external feedback as well, while at the same time making sure its mature within google. -Daniel On Tuesday, October 7, 2014 8:55:27 AM UTC-7, Goktug Gokdogan wrote: I didn't take notes in the meetup so I cannot recall all the reasons (perhaps someone else did?) but I think one of the reasons to introduce in memory conversion was to get rid of the CSS generator code with the GSS release and another one was the possible complications of coexisting css and gss in the same page (e.g. name collisions). Given that we cannot get rid of the CSS generator in 2.7 and if you think everything would be fine with css/gss mixed together (e.g. with prefixes), I'm totally fine with kicking in-memory conversion out and it is definitely not required for 2.7 even if we decide to keep it. However, arguably there might be still value in having an experimental flag to enable GSS as it is not well tested yet. On Tue, Oct 7, 2014 at 1:37 AM, Julien Dramaix julien@gmail.com wrote: I think we are making the things too complex. Initially, we wanted to remove the code of the existing generator for the CssResource and deprecated the existing syntax. It's why we have introduced the in-memory automatic conversion. Now, we've decided to keep the existing generator in GWT 2.7. So I think that we had better to remove this automatic conversion and choose the right generator in fonction of the file extension. People that want to use GSS have to use files with .gss extension. Old files with .css extension will continue to work because the current generator will be used for these kind of files. For the uibinder, we add a temporary attributes (and/or we can foreseen an configuration property that enable GSS by default in UiBinder.) That simplify a lot the implementation, removes three configuration properties (CssResource.enableGss, CssResource.legacy, CssResource.conversionMode) and we support all uses cases of application using third party libraries that will result of a mix of GSS and CSS. So it's simpler for the user and simpler for us. In the next release of GWT, when we remove the code for the existing generator, we will be able to reintroduce this automatic in-memory conversion if we want still to support the old syntax. Now I think we have to mark the current syntax of CssResource as deprecated in favor of GSS. In order to able to remove the generator in the next releases. Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the extra directory) if the -extra flag is set. Julien On Mon, Oct 6, 2014 at 11:43 PM, 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: We worked on a migration plan a few weeks back. I don't think we need to mix css and gss together inside the same app. At this point, the libraries have multiple reasonable options on compatibility: 1- Provide both css and gss file for the resource (recommended). The library will work fine regardless if the app enables gss or not as the right file will be chosen for the app. That's what we will do for internal resources in the SDK. 2- Keep providing the css file and make sure it works in strict mode. The library will work fine in css mode and will work with gss only if the legacy mode is enabled. 3- Keep the old css that requires lenient mode. The library will work fine in css mode and *may* work with gss if lenient legacy mode is enabled. More problematic part is the css inside uibinder. Like you said, simplest option is to introduce a temporary attribute in ui:style tag that marks the content as gss. In this case it is more tricky for the library to support compatibility mode similar to the mode (1) above. Either the lib should write the style that both compiles with css and gss or if it is not feasible then it should extract the resource to a file and follow the
