date:20140506

Re: [SOLVED] Re: OutOfMemoryError after upgrade to OS X Mavericks

2014-05-06 Thread Harmeet Kaur

 

Hey E.P,

Thanks Cristiano and E. P .

Reinstalling the same version would not have worked.

I updated my jdk and that solved the issue.


Thanks,

Harmeet

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

NumberFormat.setForcedLatinDigits

2014-05-06 Thread Denis Dzenskevich

Hello,

There is a method NumberFormat.setForcedLatinDigits, according to javadoc 
it should

* Specify whether all new NumberFormat instances will use *latin 
 digits*
* *and related characters *rather than the localized ones.


I faced with an issue that under Russian locale, it doesn't replace decimal 
separator: NumberFormats created afterwards, continue to use 
locale-specific comma instead of latin dot.

In code, it tries to replace it:
  protected static NumberConstants createLatinNumberConstants(
  final NumberConstants orig) {
final String groupingSeparator = remapSeparator(
orig.groupingSeparator());
final String decimalSeparator = remapSeparator(
orig.decimalSeparator());
final String monetaryGroupingSeparator = remapSeparator(
orig.monetaryGroupingSeparator());
final String monetarySeparator = remapSeparator(
orig.monetarySeparator());
...


But it uses the same function
  protected static String remapSeparator(String separator) {
char ch = separator.length()  0 ? separator.charAt(0) : 0x;
if (LOCALIZED_DOT_EQUIVALENTS.indexOf(ch) = 0) {
  return .;
}
if (LOCALIZED_COMMA_EQUIVALENTS.indexOf(ch) = 0) {
  return ,;
}
return \u00A0;
  }

to replace both grouping and decimal separator (and also monetary grouping 
and monetary decimal).
This approach doesn't work well if e. g. one locale has comma as decimal 
separator and another one has comma as grouping separator.

Also, there are test cases in GWT that asserts (probably mistakenly) that 
comma should be preserved (com.google.gwt.i18n.client.NumberFormat_fr_Test 
and NumberFormat_ar_Test).
  public void testForceLatin() {
assertFalse(NumberFormat.forcedLatinDigits());
NumberFormat.setForcedLatinDigits(true);
assertTrue(NumberFormat.forcedLatinDigits());
NumberFormat decLatin = NumberFormat.getDecimalFormat();
assertEquals(1\u00A0003,14, decLatin.format(1003.14));
assertEquals(-1\u00A0003,14, decLatin.format(-1003.14));
NumberFormat.setForcedLatinDigits(false);
assertFalse(NumberFormat.forcedLatinDigits());
assertEquals(3,14, decLatin.format(3.14));
NumberFormat unforced = NumberFormat.getDecimalFormat();
assertEquals(3,14, unforced.format(3.14));
  }

So what's the expected behavior here? Should setForcedLatinDigits always 
force latin decimal separator?
And if yes, why this complex logic to remapSeparator is used instead of 
simply returning '.' as decimal separator?

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

PlaceHistoryMapperGenerator failing error

2014-05-06 Thread Rogelio Flores

After a big git merge with conflicting files, our project doesn't
gwt-compile anymore. It gives this error which I don't remember seeing
before:

[INFO]Computing all possible rebind results for
'com.mycomp.HistoryMapper'
[INFO] Rebinding com.mycomp.HistoryMapper
[INFO] Invoking generator
com.google.gwt.place.rebind.PlaceHistoryMapperGenerator
[INFO] [ERROR] Generator
'com.google.gwt.place.rebind.PlaceHistoryMapperGenerator' threw an
exception while rebinding 'com.mycomp.HistoryMapper'
[INFO] java.lang.NullPointerException
[INFO] at
com.google.gwt.place.rebind.PlaceHistoryMapperGenerator.writeGetPrefixAndToken(PlaceHistoryMapperGenerator.java:122)

I haven't found any related info here or elsewhere online. There's the
possibility of course that one or more of our files were corrupted during
the merge, but there's nothing obvious that is wrong since there's no
errors highlighted in the IDE. Regular (non-gwt) compile works, and I
manually checked all conflicting files. The only related reported issue
I've found is this one:

https://code.google.com/p/google-web-toolkit/issues/detail?id=8036

but I don't think that issue fails during gwt compilation. Given the class
where the NPE occurs, I suspect it has something to do with my
Places/Tokenizers, but turning on DEGUG logLevel doesn't provide more info.
Does anyone have a clue seeing the above snippet?

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

Re: PlaceHistoryMapperGenerator failing error

2014-05-06 Thread Rogelio Flores

One detail I forgot: using gwt 2.5.1.

On Tuesday, May 6, 2014 7:55:28 AM UTC-4, Rogelio Flores wrote:

After a big git merge with conflicting files, our project doesn't
gwt-compile anymore. It gives this error which I don't remember seeing
before:

https://code.google.com/p/google-web-toolkit/issues/detail?id=8036

Re: PlaceHistoryMapperGenerator failing error

2014-05-06 Thread Thomas Broyer

Things to try: clean your project (all outputs) and remove the
.gwt-unitCache.
Also, set a breakpoint where the NPE is thrown to try to find what can be
the cause.
If you can provide me a repro case, I could debug myself if you prefer.

On Tuesday, May 6, 2014 1:55:28 PM UTC+2, Rogelio Flores wrote:

After a big git merge with conflicting files, our project doesn't
gwt-compile anymore. It gives this error which I don't remember seeing
before:

https://code.google.com/p/google-web-toolkit/issues/detail?id=8036

Add Google map for GWT into FormPanel

2014-05-06 Thread Huang Bruce

Hi all,

I am new to GWT and face some problem here. I need to show up Google map on 
a form in my GWT web.
First, there has a windowForm.class which extends FormPanel and I have 
wrote a mapWindowForm.class which extends this windowForm.class as below.
http://paste.ideaslabs.com/show/Q0ThysUrSF
And the problem is how shall I add this map  final MapWidget map = new
 MapWidget(Location, 2); which is a MapWidget into this FormPanel: 
mapWindowForm.class

This system was developed by GWT-2.5.0. The library I have imported is 
gwt-maps-1.1.1.jar(Maps v2 API 
1.1.1https://code.google.com/p/gwt-google-apis/downloads/detail?name=gwt-maps-1.1.1.zipcan=2q=),
 
so I give 2 as the second parameter in Maps.loadMapsApi(). Unfortunately, 
the first time to call mapWindowForm.class, the window.alert showed up, 
indicated that the Map.loadMapsApi() has not successed. But the second time 
to call this class, the window.alert didn't show up until I have refresh 
the web page. When I tried to give 3, it shows the sensor shall be given 
as true of false. When I tried to use gwt-maps-3.8.1(Maps v3 API), the 
import were not work.

So, I am not sure that is the MapWidget doesn't create or the MapWidget 
doesn't add into the FormPanel succeed/

Thanks.

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

Re: PlaceHistoryMapperGenerator failing error

2014-05-06 Thread Rogelio Flores

Thanks for offering your help Thomas.

I had tried cleaning everything before with no success.

We're using a Tokenizer Factory, and noticed that if we commented out the
last Place tokenizer method we added (in one of the branches merged) and if
we created the Tokenizer statically within the Place object instead so that
we add it to our HistoryMapper using @WithTokenizers, then we can compile
and the app works fine.

I did debug the gwt code and was able to see that within
PlaceHistoryMapperGenerator.java, the prefix comes as null for the second
Place we have in our tokenizer factory (which is not the last one we added,
but it always fails on this one, or at least this is the first one that
comes as null). Other properties are not null however, such as
placeTypeName, which also comes from the PlaceHistoryGeneratorContext. As
another data point, all methods in the factory have a @Prefix defined, but
I know at least one of the tokenizers provided in @WithTokenizers does not.

Since we have a workaround, I probably won't dig any further, but I'm
wondering if there's somehow a limit to the number of Places we can have
through a Tokenizer Factory. Previous to adding the last place that gave us
problems, we had 54 there, plus 6 on the @WithTokenizers annotation. I know
there's nothing bad or special about the last place added, because I tried
adding a completely different one and I got the same issue.

I don't see a quick way to provide a repro case, as I've only seen this
issue after adding more than 60 places and with a custom tokenizer factory,
otherwise I'd provide one, or if I find myself with extra time... I've
already spent more time on this than I wanted ;-(

On Tuesday, May 6, 2014 8:40:00 AM UTC-4, Thomas Broyer wrote:

On Tuesday, May 6, 2014 1:55:28 PM UTC+2, Rogelio Flores wrote:

After a big git merge with conflicting files, our project doesn't
gwt-compile anymore. It gives this error which I don't remember seeing
before:

https://code.google.com/p/google-web-toolkit/issues/detail?id=8036

but I don't think that issue fails during gwt compilation. Given the
class where the NPE occurs, I suspect it has something to do with my
Places/Tokenizers, but turning on DEGUG logLevel doesn't provide more info.
Does anyone have a clue seeing the above snippet?

Re: GWT treeItem expand button missing in Internet Explorer

2014-05-06 Thread Alexey Panteleev

Any solution for this issue? I am experiencing the same and need to make 
our app work in IE8

On Wednesday, October 13, 2010 1:33:08 PM UTC-7, 12ock wrote:

 Hi, 

 I am having trouble displaying the expand (+/-) button for TreeItem in 
 internet explorer 8. It works fine in firefox. Basicly i parse an xml 
 file into tree structure and display it in the browser, if a node has 
 children, there should be an expand button (+/-) beside it. 

 Help please! 

 Thanks 



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

Re: XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID

2014-05-06 Thread Jan Przybylo

GWT team appears to be vry reponsive... :\

I have the same problem and still can't find any solution...

Does anyone know how to fix it? maybe I should be setting all cookies with 
/ path and remove invalid cookies bu trying to overwrite it using the same 
name, also / path but setting date expires to current timestamp? So the 
path is what I'm considering changing. 

What you guys think?

Thanks in advance for any kind of help.

Jan



W dniu piątek, 1 czerwca 2012 02:47:28 UTC-4 użytkownik Josh napisał:

 Hi,

 I recently re-engineered some custom XSRF/CSRF protection code in my open 
 source GWT-based application to use the new recommended protection 
 introduced in GWT 2.3 as described in 
 https://developers.google.com/web-toolkit/doc/latest/DevGuideSecurityRpcXsrf. 
  Since I develop and deploy mainly in Tomcat all seemed well.  However 
 some users of the project deploy to Glassfish and Jetty Java Servlet 
 Containers, both of which immediately started having problems with all RPC 
 calls getting blocked throwing a java.lang.IllegalArgumentException: 
 Duplicate cookie! Cookie override attack? exception.

 Looking into why, I've determined the problem being JSESSIONID, the 
 session cookie and what GWT recommends to base XSRF token from, is in both 
 application and root path for the host for different reasons, causing the 
 exception to be thrown when the application sees both cookies in scope: 
 (tracked on http://code.google.com/p/webpasswordsafe/issues/detail?id=58)

 *What steps will reproduce the problem?*
 1. Glassfish- visit admin console (http://host:4848/ creates JSESSIONID 
 cookie for / , visit WPS (http://host:8080/WPS creates JSESSIONID cookie for 
 /WPS
 2. Although on different ports, cookie spec doesn't care and both instances 
 of JSESSIONID cookie are in scope to WPS, the GWT Google code sees both when 
 it calls getCookie() and throws an exception 
 java.lang.IllegalArgumentException: Duplicate cookie! Cookie override 
 attack? and doesn't allow any requests to work.

 1. Jetty- visit one of their sample servlets (i.e. http://host:8080/dump/info 
 creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS creates 
 JSESSIONID cookie for /WPS
 2. Although different contexts, Jetty servlet sets its at root path so both 
 are in scope to WPS, blah blah blah same exception and reason as the 
 Glassfish example above.

 There is no way to configure the GWT code to ignore the duplicate cookie 
 check without modifying their code.  It would be ideal if it just checked for 
 and cared about the cookies defined in the /WPS application context and 
 ignored the others or allowed a way to configure it to call 
 com.google.gwt.user.server.Util.getCookie() passing true (allow duplicates) 
 as the last parameter rather than hardcoding false.  Admittedly this may not 
 be possible in the former case, and not completely secure in the later case.  
 But basing this all on the JSESSIONID in real world usage isn't working 
 either.


 The workaround when I had this same issue when I was rolling out my own XSRF 
 protection code previously to GWT 2.3 was to use a different unique cookie 
 name that basically just duplicated the last JSESSIONID value and set that 
 extra cookie when that session was first created.  You'd think if this new 
 way was Google's official documented and mandated way to protect against 
 XSRF, even using JSESSIONID in their example, it would just work out of the 
 box.  But clearly not, unless their code was never tested with Jetty or 
 Glassfish.  Very surprising.


 Is there a preferred way to handle this from the GWT team that isn't 
 documented, or is my kludge workaround the only way?  Preferably a solution 
 that works for all servlet containers, I know there are Tomcat-specific, 
 Jetty-specific, etc settings to tweak default JSESSIONID behavior but those 
 are not standard and even worse kludges.


 Thanks for your attention to this and any advice as far as best practices,

 ~Josh





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

Re: XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID

2014-05-06 Thread Jan Przybylo

GWT team appears to be vry reponsive... :\

I have the same problem and still can't find any solution...

Does anyone know how to fix it? maybe I should be setting all cookies with 
/ path and remove invalid cookies by trying to overwrite them using the 
same name, also / path and setting date expires to current timestamp? So 
the path is what I'm considering changing. 

What do you guys think?

Thanks in advance for any kind of help.

Jan

W dniu piątek, 1 czerwca 2012 02:47:28 UTC-4 użytkownik Josh napisał:

 Hi,

 I recently re-engineered some custom XSRF/CSRF protection code in my open 
 source GWT-based application to use the new recommended protection 
 introduced in GWT 2.3 as described in 
 https://developers.google.com/web-toolkit/doc/latest/DevGuideSecurityRpcXsrf. 
  Since I develop and deploy mainly in Tomcat all seemed well.  However 
 some users of the project deploy to Glassfish and Jetty Java Servlet 
 Containers, both of which immediately started having problems with all RPC 
 calls getting blocked throwing a java.lang.IllegalArgumentException: 
 Duplicate cookie! Cookie override attack? exception.

 Looking into why, I've determined the problem being JSESSIONID, the 
 session cookie and what GWT recommends to base XSRF token from, is in both 
 application and root path for the host for different reasons, causing the 
 exception to be thrown when the application sees both cookies in scope: 
 (tracked on http://code.google.com/p/webpasswordsafe/issues/detail?id=58)

 *What steps will reproduce the problem?*
 1. Glassfish- visit admin console (http://host:4848/ creates JSESSIONID 
 cookie for / , visit WPS (http://host:8080/WPS creates JSESSIONID cookie for 
 /WPS
 2. Although on different ports, cookie spec doesn't care and both instances 
 of JSESSIONID cookie are in scope to WPS, the GWT Google code sees both when 
 it calls getCookie() and throws an exception 
 java.lang.IllegalArgumentException: Duplicate cookie! Cookie override 
 attack? and doesn't allow any requests to work.

 1. Jetty- visit one of their sample servlets (i.e. http://host:8080/dump/info 
 creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS creates 
 JSESSIONID cookie for /WPS
 2. Although different contexts, Jetty servlet sets its at root path so both 
 are in scope to WPS, blah blah blah same exception and reason as the 
 Glassfish example above.

 There is no way to configure the GWT code to ignore the duplicate cookie 
 check without modifying their code.  It would be ideal if it just checked for 
 and cared about the cookies defined in the /WPS application context and 
 ignored the others or allowed a way to configure it to call 
 com.google.gwt.user.server.Util.getCookie() passing true (allow duplicates) 
 as the last parameter rather than hardcoding false.  Admittedly this may not 
 be possible in the former case, and not completely secure in the later case.  
 But basing this all on the JSESSIONID in real world usage isn't working 
 either.


 The workaround when I had this same issue when I was rolling out my own XSRF 
 protection code previously to GWT 2.3 was to use a different unique cookie 
 name that basically just duplicated the last JSESSIONID value and set that 
 extra cookie when that session was first created.  You'd think if this new 
 way was Google's official documented and mandated way to protect against 
 XSRF, even using JSESSIONID in their example, it would just work out of the 
 box.  But clearly not, unless their code was never tested with Jetty or 
 Glassfish.  Very surprising.


 Is there a preferred way to handle this from the GWT team that isn't 
 documented, or is my kludge workaround the only way?  Preferably a solution 
 that works for all servlet containers, I know there are Tomcat-specific, 
 Jetty-specific, etc settings to tweak default JSESSIONID behavior but those 
 are not standard and even worse kludges.


 Thanks for your attention to this and any advice as far as best practices,

 ~Josh





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

Re: XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID

2014-05-06 Thread Jens

You can create a new base class for your servlets and override 
XsrfProtectedServiceServlet.validateXsrfToken() to adjust it to your needs.

-- J.

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

Ongoing discussion of Jetty problems in Eclipse with 2.6.1-rc2 (issue #8526)

2014-05-06 Thread pronovic

This is a place where we can continue the discussion about issue #8526, 
rather than having a conversation within the bug report.

https://code.google.com/p/google-web-toolkit/issues/detail?id=8526

Summary so far: GWT 2.6.1-rc2 includes changes intended to fix issue #8526. 
 I've tested the changes, and they appear to work when I start dev mode on 
the command-line.  All of my Cucumber tests work in this situation, and I 
haven't seen anything broken when spot-checking by hand.  

However, when I try to start dev mode from Eclipse, using the standard Run 
As  Web Application provided by the Google Plugin for Eclipse, things are 
different. I get basically the same error I saw with GWT 2.6.0, prior to 
the recent fix (stack trace below).

I am working in Eclipse Kepler (build id 20130320-2352) using Google Plugin 
for Eclipse 3.5.1.v201312301723-rel-r43.  Although I use the Google Plugin 
for Eclipse, all of my dependencies come from Maven (via Gradle), and I do 
not rely on any bundled SDK provided by the Eclipse plugin.

I've tried a variety of different workarounds as documented in the bug 
report.  I've also tried a few other wild guesses not documented there, 
like starting over in a completely fresh workspace, changing JVMs (both 1.6 
and 1.7), installing new bundled SDKs , moving the GWT jars to the top and 
bottom of the Eclipse classpath.  The result is the same no matter what I 
do.  

KEN

--

Starting Jetty on port 
   [WARN] Failed startup of context 
c.g.g.d.s.j.WebAppContextWithReload{/,file:/C:/Ken/Workspaces/GWT/SscTestSite/SscTestSite/war/},C:\Ken\Workspaces\GWT\SscTestSite\SscTestSite\war
java.lang.IllegalArgumentException: Object of class 
'com.google.gwt.dev.shell.jetty.JettyLauncher.WebAppContextWithReload' is 
not of type 'org.eclipse.jetty.webapp.WebAppContext'. Object Class and type 
Class are from different loaders.
at 
org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:323)
at 
org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:281)
at 
org.eclipse.jetty.webapp.JettyWebXmlConfiguration.configure(JettyWebXmlConfiguration.java:103)
at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:468)
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1237)
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at 
com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:541)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at 
org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:162)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.server.Server.doStart(Server.java:282)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:740)
at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:522)
at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:1104)
at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:844)
at com.google.gwt.dev.DevMode.main(DevMode.java:322)

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

Re: [gwt-contrib] Re: GWTproject site menu

2014-05-06 Thread Manuel Carrasco Moñino

Hello,

I have committed some patcheshttps://gwt-review.googlesource.com/#/c/7180/,
and deployed a demo version http://gwtproject.gquery.org so as you guys
can test the new menu distribution.

What I've done based on Thomas suggestion is to maintain a
tochttps://gwt-review.googlesource.com/#/c/7180/17/src/main/resources/toc.mdfile
instead of moving or renaming pages.

Apart from the menu distribution, the demo includes some navigation fixes,
small css changes, and the ability to adapt to mobile screens when the
window is narrowed.

Once this distribution is reviewed I want to focus on updating some
contents, especially outdated pages.

Feel free to give feedback.

- Manolo

[1] https://gwt-review.googlesource.com/#/c/7180/
[2] http://gwtproject.gquery.org
[3]
https://gwt-review.googlesource.com/#/c/7180/17/src/main/resources/toc.md

On Wed, Apr 9, 2014 at 1:36 PM, Manuel Carrasco Moñino man...@apache.orgwrote:

Sorry forgot the link to the document :-(

https://docs.google.com/document/d/1LJm-xDAK23uASwK59JUAnAeaNjPH5dF9N4LWdgSI9Ik/edit

- Manolo

On Wed, Apr 9, 2014 at 1:36 PM, Manuel Carrasco Moñino
man...@apache.orgwrote:

Hi all,

Julien and me have created a document with some plans about the
gwtproject.org site.
Please, feel free to add any comment you have.

On Wed, Apr 9, 2014 at 9:28 AM, Julien Dramaix
julien.dram...@gmail.comwrote:

Hi Manolo,

It's something I wanted to do for a while. Let's organize a conf call to
talk about that.

Julien

On Mon, Apr 7, 2014 at 8:40 PM, Daniel Kurka danku...@google.comwrote:

If you move stuff around you will need to make sure that links (also
external) won't break. (we still get a lot of traffic from external links)

But I think working on the navigation menu of the page is quite overdue.

-Daniel

On Mon, Apr 7, 2014 at 4:53 PM, Jens jens.nehlme...@gmail.com wrote:

Sounds reasonable :)

-- J.

--
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/d/optout.

--
Google Germany GmbH
*Dienerstr. 12*
*80331 München*

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

--
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/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/CAM28XAv_-4R_uR-G40yKbPgV4PpGxLcctXZ%3DR__K%3DuFcoqe8vA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWTproject site menu

2014-05-06 Thread 'Goktug Gokdogan' via GWT Contributors

Looks better; thanks for the work.

Some suggestions:
- Removes the versions submenu from Downloads as it is already included as
a link from Downloads page.
- Move GWT surveys under resources
- Perhaps we can group Making GWT Better, Life of an Issue, Steering
Committee under a submenu
- Release Notes - drop it from menu? its already linked from Downloads
page.
- In Documentation menu:
- We need to re-order stuff for people who are reading documentation in
a sequential manner.
e.g. Communicate with a server should probably earlier, maybe in
basics?
- We may want Organize Projects and Compile/Debug to be part of coding
basics.
- Drop IE9 specific page from menu
- Perhaps group RequestFactory, Act.Places, Validation, Access., I18N
etc. in Advanced Topics

On Tue, May 6, 2014 at 8:57 AM, Manuel Carrasco Moñino man...@apache.orgwrote:

Hello,

I have committed some patcheshttps://gwt-review.googlesource.com/#/c/7180/,
and deployed a demo version http://gwtproject.gquery.org so as you
guys can test the new menu distribution.

What I've done based on Thomas suggestion is to maintain a
tochttps://gwt-review.googlesource.com/#/c/7180/17/src/main/resources/toc.mdfile
instead of moving or renaming pages.

Apart from the menu distribution, the demo includes some navigation fixes,
small css changes, and the ability to adapt to mobile screens when the
window is narrowed.

Once this distribution is reviewed I want to focus on updating some
contents, especially outdated pages.

Feel free to give feedback.

- Manolo

[1] https://gwt-review.googlesource.com/#/c/7180/
[2] http://gwtproject.gquery.org
[3]
https://gwt-review.googlesource.com/#/c/7180/17/src/main/resources/toc.md

On Wed, Apr 9, 2014 at 1:36 PM, Manuel Carrasco Moñino
man...@apache.orgwrote:

Sorry forgot the link to the document :-(

https://docs.google.com/document/d/1LJm-xDAK23uASwK59JUAnAeaNjPH5dF9N4LWdgSI9Ik/edit

- Manolo

On Wed, Apr 9, 2014 at 1:36 PM, Manuel Carrasco Moñino man...@apache.org
wrote:

Hi all,

Julien and me have created a document with some plans about the
gwtproject.org site.
Please, feel free to add any comment you have.

On Wed, Apr 9, 2014 at 9:28 AM, Julien Dramaix julien.dram...@gmail.com
wrote:

Hi Manolo,

It's something I wanted to do for a while. Let's organize a conf call
to talk about that.

Julien

On Mon, Apr 7, 2014 at 8:40 PM, Daniel Kurka danku...@google.comwrote:

If you move stuff around you will need to make sure that links (also
external) won't break. (we still get a lot of traffic from external links)

But I think working on the navigation menu of the page is quite
overdue.

-Daniel

On Mon, Apr 7, 2014 at 4:53 PM, Jens jens.nehlme...@gmail.com wrote:

Sounds reasonable :)

-- J.

--
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/d/optout.

--
Google Germany GmbH
*Dienerstr. 12*
*80331 München*

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

--
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/CAM28XAv_-4R_uR-G40yKbPgV4PpGxLcctXZ%3DR__K%3DuFcoqe8vA%40mail.gmail.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAv_-4R_uR-G40yKbPgV4PpGxLcctXZ%3DR__K%3DuFcoqe8vA%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

Re: [SOLVED] Re: OutOfMemoryError after upgrade to OS X Mavericks

NumberFormat.setForcedLatinDigits

PlaceHistoryMapperGenerator failing error

Re: PlaceHistoryMapperGenerator failing error

Re: PlaceHistoryMapperGenerator failing error

Add Google map for GWT into FormPanel

Re: PlaceHistoryMapperGenerator failing error

Re: GWT treeItem expand button missing in Internet Explorer

Re: XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID

Re: XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID

Re: XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID

Ongoing discussion of Jetty problems in Eclipse with 2.6.1-rc2 (issue #8526)

Re: [gwt-contrib] Re: GWTproject site menu

Re: [gwt-contrib] Re: GWTproject site menu

14 matches

Site Navigation

Mail list logo

Footer information