Re: Wishlist - What GWT developers want for Christmas

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I imagine they want your contacts for the same reason they want your
email and social network info: to send out marketing spam (or
information, if you see the glass half-full).

There's an easy workaround though: sign up with an address from
Mailinator or another throwaway-email service.

On 12/11/2012 02:33 PM, maticpetek wrote:
> Dear Joonas,
>We have couple discussion in this forum about given email address to
> access survey result. Some people see this as interference between
> commercial interest of Vaadin and community. I don't think so and I also
> express my opinion. If some company invest their time & resources to
> prepare survey and present results - this is good for all community and
> you can have my email to send me product updates. Ok, I also think you
> have cool product and I want information from your company.
>But could you please explain me why you need access to my Google
> Contacts information if I login with my Google Account? Or to my friends
> lists from Facebook if I login with Facebook connect? What will list of
> my personal friends, family members and business partners have to do
> with GWT wishes voting system? Frankly speaking, I think this si very
> bad sign for feature customers (like I am) for you company product &
> services. And as I say - you have cool product and I really wish you all
> the best. 
> 
> Regards,
>Matic
> --
> GWT stuff twitter  - http://twitter.com/#!/gwtstuff
> 
> 
> 
> On Tuesday, December 11, 2012 7:45:59 PM UTC+1, Joonas Lehtinen wrote:
> 
> We just published all of the 2600+ wishes you guys added to the
> Future of GWT survey on most important things needed in GWT. Take a
> look:
> 
> https://vaadin.com/gwt/report-2012/wishlist
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Google Web Toolkit" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-web-toolkit/-/eTea0PDOwtAJ.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDHj2UACgkQ5IyIbnMUeTsJbwCfSmWaf7mSQrf0xtV7NiYn9lOP
PjcAn0ihnOM6YZrReS6PSwGjw0GPrz53
=e+m4
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: The Future of GWT Report 2012 Published

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yeah, the email-collection page is obnoxious, though I suppose I
understand why it's there.  I should point out that mailinator.com is
made for exactly this situation.  You provide any address at
mailinator.com, then browse to http://mailinator.com to check messages
sent to that address with no signup or password check.  Messages stay
around for a short time, maybe 30-60 minutes.

On 12/04/2012 10:30 AM, AJ wrote:
> Thank you for releasing these results.
> 
> However, I find it disconcerting and somewhat ominous that Vaadin
> is using this survey as a marketing tool. It would have been
> preferable, in my opinion, if the report had been released as a
> direct link in the notification email I received, instead of
> sending me to a Vaadin marketing page with a form to request an
> email that contains a link to download the report. The community is
> already concerned about the future of GWT since it was released as
> open source. Linking it so closely Vaadin does not quiet those
> concerns.
> 
> On Tuesday, December 4, 2012 9:25:55 AM UTC-5, jchimene wrote:
> 
> On 12/4/2012 4:19 AM, Joonas Lehtinen wrote:
>> *The GWT community have been having many questions about the 
>> Future of GWT. Questions like: Where is GWT going? How is GWT
>> used today? What are the challenges they are facing? What is the 
>> competition? Should I build my next project with GWT?
>> 
>> When joining the GWT steering committee and deciding to include
>> a full copy of GWT into Vaadin 7 we had the same questions. In
>> the end we stepped forward and asked the GWT community. Now after
>> 2 months of asking and receiving responses to the dozens of 
>> questions we had from over over 1300 GWT users, we compiled all
>> of this together and are proud to present you with some answers
>> in for of 30 page long report. We would like to thank everyone
>> who participated: You - the very active GWT community who
>> answered, GWT steering committee members and other GWT experts
>> who helped create the questions and analyze the answers, Vaadin
>> team and David Booth who coordinated the effort.
>> 
>> Enough talking, download your personal copy of The Future of GWT 
>> Report at:* * https://vaadin.com/gwt/report-2012 
>>  *
> 
> My friend, Marge Innovera, wishes you would mention her in the
> report.
> 
> Cheers, jec
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/H2noDq7oMLAJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlC+SgcACgkQ5IyIbnMUeTtS1ACfb+ZHmxUaQpap6UviajvD6c2y
2SoAnR+YA+1kh3EZyiiHd4VDoJPmbb0Q
=+Raw
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: SuperDevMode not so super

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

If I could hook Eclipse up to Firefox or Chrome and step through code,
that would make SDM much more workable.  Is that currently possible?

If so, is it possible to inspect the internal state of an object
defined in Java, compiled to JS, and running in a browser VM?
Breakpoints and stepping line by line are great, but losing object
inspection would be a big step back.

On 11/14/2012 09:58 PM, Chris Lercher wrote:
> On Thursday, November 15, 2012 2:53:37 AM UTC+1, Thomas Broyer
> wrote:
> 
> SourceMaps could then be used by your IDE so you could put 
> breakpoints in your editor window.
> 
> 
> I can see the potential - it could be big. I do have a few doubts
> though:
> 
> 1. Would this also allow me to inspect the internal state of
> objects from within my IDE? (Is this even possible?) 2. What about
> super-sourced classes, which are - at least in Eclipse - usually
> excluded from the build path to avoid error messages (that's 
> probably the smaller problem, as I imagine, that this could be
> taken care of by the IDE plugins)
> 
> 
> 
> Embedded browsers, even if using the exact same engine, don't
> behave like their "full blown" counterparts (IE, when embedded,
> has different rules for switching between IE5.5Quirks/IE7/IE8/etc.
> modes for instance)
> 
> 
> I think, living with these differences in Dev Mode would be ok.
> The situation was different back in Hosted Mode's time, because
> Super Dev Mode was missing. I believe, that Dev Mode currently has
> some important use cases, which Super Dev Mode can't cover (yet?)
> For these use cases, the browser differences are often not that
> important.
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/65KGTSLnUJ0J. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlClHDEACgkQ5IyIbnMUeTsejwCcCepJDymqjpECsv7PXhXnbciF
L9gAn34/OEEJArXpXU6zq+10OlSmvs2L
=QD9T
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: SuperDevMode not so super

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/2012 08:33 PM, Oliver Krylow wrote:
> Also the promise of gwt is NOT to abstract the browser or web 
> technologies and semantics away from you, but rather to bring good
> and structured workflow and tooling to web development .

Well, sort of.  Or perhaps that's how it is for you.  A structured
workflow and tooling is very welcome for web work, where the dominant
technologies have grown organically over decades to do things far
beyond their originally intended purposes.

HTML/CSS/JS are the web's assembly language.  Most (definitely not
all!) developers don't need to care what CPU instructions their C
compiler or language JIT runtime generates, and that's a Very Good Thing.

That GWT goes beyond the papering-over of browser differences provided
by Jquery-level JS libs is similarly a very good thing.  Every
browser, JS, or HTML detail that I don't need to care about frees up
mental resources that I can use toward actually solving the problems
my apps need to solve.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlClGYQACgkQ5IyIbnMUeTvIiwCbBVZH3si+AqROg3zmLOOkdvP4
+XUAn21jNnz+95Lm4ycNS2/J/qD85yCL
=eUK1
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: SuperDevMode not so super

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm glad SDM works for you; the ability to see HTML or CSS changes
quickly is definitely a pro.

But losing the IDE debugger is a big con.  No browser debugger that
I'm aware of matches the functionality of Eclipse or IntelliJ.  Losing
the ability to debug the client and server from the same 'place' is
also a con.

I'd rather be kept as insulated as possible from the javascript
environment, at least by default.

On 11/14/2012 03:34 PM, emurmur wrote:
> I am really enjoying SuperDevMode.  My desire is to program to the 
> browser, not to a high-level GWT api.  I've build an MVP framework
> on top of lower level browser api's, so no UI Binder, no request
> factory, no GWT widgets.  Compiles are fast.  Debugging in Chrome
> works well. There are some things to get used-to, and I generally
> prefer the IDE debugger's ui, but debugging the actual code in the
> actual execution environment at full speed is a big benefit.  I can
> make changes to html or css and simply reload the page and I'm
> debugging again in 2 seconds. If I step a little too far in the
> code, I can reload and I'm debugging again in 2 seconds.  If I
> change a line of Java code, I need to recompile, but that takes
> about 5 seconds in my app.  So SuperDevMode and source maps are
> ideal for me.  If feel like I'm getting the productivity of a
> Javascript work flow and the structure and code-reliability of
> Java.
> 
> Ed
> 
> On Wednesday, November 14, 2012 11:35:59 AM UTC-8, Clint Gilbert
> wrote:
> 
> On 11/14/2012 09:47 AM, Andrew Mackenzie wrote:
> 
>> IMHO, SuperDev is not the fix for this, and GWT is exploring a 
>> path (Source maps, browser debug, etc) that breaks one of the
>> best and distinguishing points of GWT.
> 
> 
> Agreed.  The inability to debug using an IDE makes super dev mode
> a non-starter for me.
> 
> SDM solves a problem for the browser plugin maintainers, which I 
> completely understand, but it creates problems for users like me.
> 
> 
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/30Xavun1iLYJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCkHU0ACgkQ5IyIbnMUeTu+CgCeIUSy71ESOJp0bx2QJ3ky+W1Q
VTIAoKKg/DCWuGXWPd8LZsMsppqwUZfU
=YTPA
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: SuperDevMode not so super

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/2012 09:47 AM, Andrew Mackenzie wrote:
> 
> IMHO, SuperDev is not the fix for this, and GWT is exploring a
> path (Source maps, browser debug, etc) that breaks one of the best
> and distinguishing points of GWT.
> 

Agreed.  The inability to debug using an IDE makes super dev mode a
non-starter for me.

SDM solves a problem for the browser plugin maintainers, which I
completely understand, but it creates problems for users like me.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCj8lEACgkQ5IyIbnMUeTvFtwCfcMOnIYxXwTsiZu87tDuT1yrJ
pL0AoKi8fJKLYPaOohoR3PzZdRaEWWUO
=bIqT
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Intellij for GWT app development. Is it worth it?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm not an Eclipse fanboy by any stretch, but it's what I use.  I work
closely on the same codebase with a committed IntelliJ-user.  Over the
1.5 years or so, I've noticed we've had about the same amount of
crashes, gotchas, and annoyances with our IDEs.  What's been different
is the gotchas themselves, not the time spent resolving them.  Neither
of us would switch; the other side just isn't compelling enough.

On 10/22/2012 01:28 PM, Dennis Haupt wrote:
> intellij costs a few hundred dollars per year, eclipse costs a few
> hours per week. make your choice.
> 
> Am 22.10.2012 18:18, schrieb Thomas Broyer:
>> 
>> 
>> On Monday, October 22, 2012 5:31:02 PM UTC+2, Joseph Lust wrote:
>> 
>> I seem to recall Ray Cromwell preaching about his love for
>> IntelliJ during Google IO this year (Future and History of GWT).
>> If it works well for him, I'm convinced.
>> 
>> 
>> I actually hear many preaching about their love for IntelliJ.
>> I'll definitely have to try it, but I fear that I'll get too used
>> to it and need features of the Ultimate version, and my boss is
>> unlikely to start buying licenses (well, actually, who knows?)
>> 
>> -- You received this message because you are subscribed to the
>> Google Groups "Google Web Toolkit" group. To view this discussion
>> on the web visit 
>> https://groups.google.com/d/msg/google-web-toolkit/-/SXB7o7ZapssJ.
>>
>> 
To post to this group, send email to google-web-toolkit@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> google-web-toolkit+unsubscr...@googlegroups.com. For more
>> options, visit this group at 
>> http://groups.google.com/group/google-web-toolkit?hl=en.
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCFjt4ACgkQ5IyIbnMUeTvQ+wCgjSvQgvComxFp5YgIo30Ze9un
GdwAnis9zYMZKxjdQfJmBQr/Kwf+wZiy
=9M9N
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Are you happy with GWT?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

1) Has largely been a non-issue for us in practice, since we use
UIBinder.  We devs take a mockup from our designer, extract chunks of
HTML from it, and parameterize them into UIBinder widgets.

We end up with an app whose DOM structure is 99% the same as the
designer's mockup, which means we can use the mockup's CSS without any
modifications.  For devs like us that would prefer to stay as removed
from CSS as possible to concentrate on other things, this is a huge win.

That said, if styling isn't important - and it isn't for a good chunk
of internal CRUD-oriented apps - it's not that big a deal if 'view
source' shows "ugly" nested tables or not.

On 10/10/2012 04:13 PM, Shaun Tarves wrote:
> There is no doubt that what GWT does, it's really good at. However,
> some things that I've found GWT really isn't good at:
> 
> 1) Producing clean HTML
> 
> The structure of GWT "page views," especially with GWT widgets, is
> really poor. The DOM gets bloated with lots of extra elements that
> are used for focus and positioning. There are ways around this, but
> I feel like I'm constantly fighting with GWT to generate HTML
> structure on my terms.
> 
> For example, some of the most lauded constructs in GWT are the
> Cell-based widgets (CellTable, and CellList, specifically). With
> CellLists, you are stuck with divs. There's no way around it. So
> that means if you want to make a good data model-backed list and
> render it as a UL with LIs, you're SOL.
> 
> 2) The history mechanism is really powerful, but it's important to
> get your URL structure correct from the start. The built-in history
> token parser is a little too rigid in that it forces the first part
> of your URLs to be of the form :yyy and then anything you want
> after that. When you dive deeper into GWT, you'll understand the
> limitations of the PlaceHistoryMapper and why you might want to
> avoid the tokenizers and write your own parser.
> 
> 3) The GWT CSS compiler doesn't understand any CSS3 attributes.
> Also, browser-specific attributes (such as the * hack for IE) throw
> warnings on compiling. It's not really GWT's fault (it's a Java
> compiler issue), but be aware nonetheless.
> 
> Just a few things to keep in mind.
> 
> On Wednesday, October 10, 2012 1:53:26 PM UTC-4, Charlie Youakim
> wrote:
> 
> Great posts.  I am truly gracious of all the responses to this
> question I posted.  I feel like we have made the right move going
> in this direction.
> 
> On Wednesday, October 10, 2012 1:28:05 PM UTC-4, Joseph Lust
> wrote:
> 
> *Praise*
> 
> I think it is best to assert that /GWT is to Javascript what Scala
> is to Java/. GWT is a higher level web framework. Sure, your devs
> can learn every browser quirk and go bare metal, writing verbose
> code. But they can also just focus on the higher level of logic,
> interactions and reusability.
> 
> Put simply, the GWT framework allows you to carry out nearly every
> best practice in web application design, and do so in a robust,
> automated manner. Sure, you can sprite your images, minify and
> obfuscate your CSS, combine your JS files, then minimize them, then
> run them through the Closure compiler, then gzip them, and repeat
> for each language you plan to i18n for. Or you can just hit compile
> in GWT. And you can unit test that process as well. Awesome!
> 
> Coming from being a script kiddie in 1997, having done PHP
> frameworks, C# & ASP.Net, and raw JS with ExtJs, there is no better
> way to create RIA’s than GWT. I used to hate my life when I fought
> with debuggers in FF and raw HTML code to get a blasted form to
> come up right. Now I just put a few UiBinder XML tags in with
> something like gwt-bootstrap and it is done and pretty. Life saver.
> Why would you do it any other way?
> 
> And, to note what you can do with this. My employer, a large
> financial institution, uses GWT as their standard inhouse
> technology for enterprise web applications. One team just finished
> a 400 screen application and I’m currently working on a bleeding
> edge, HTML5/canvas based flagship product which is 200kLOC strong.
> GWT makes these applications, their rapid turnaround, and very high
> level of quality possible.
> 
> *Terms and Conditions*
> 
> This is not for script kiddies. You should have a good grasp of
> OO, Java, and JS. GWT itself is a bit dogmatic. This means it
> requires competent developers.  Once they read all the docs on the
> Google Dev pages, they’ll be in good shape. Still, becoming a
> serious GWTer is not a weekend effort. Thus, if you want to create
> a simple blog, stick with PHP and WP, but if you want a highly
> optimized, complex web application, go with GWT.
> 
> Sincerely,
> 
> Joseph
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/Wysu0gYQN3MJ. 
> To post to this group,

Re: Are you happy with GWT?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm quite happy with GWT.  I prefer it for the type-safety, good
tooling, and language features that support programming-in-the-large
(whatever that means) that are all absent when working in Javascript.
 Being able to debug code running in a browser with an IDE is fantastic!

With GWT, we devs spend much less mental energy juggling the
interactions of several templating systems and dynamic, typo-prone
browser APIs, plus our designer can work with what we do via UIBinder
quite naturally.  (We actually take his mockups and turn the HTML
directly into UIBindered widgets.)

The only downside of GWT is Java.  We do all our server-side work in
Scala, and having to go back to Java's verbosity and (comparatively)
anemic collections API now that we're used to a higher-level language
is a drag.  (My coworker calls it "coding through mud".)

It's worth dealing with Java though.  I couldn't imagine writing
dynamic, single-page webapps any other way.  I've written several in
pure JS, and I would never go back to that.


On 10/05/2012 11:53 AM, Charlie Youakim wrote:
> I'm deciding on whether to switch my team to GWT.  I think the
> biggest thing for me as the tech lead for the company is "Are you
> happy with your choice to use GWT?"
> 
> My reasons for thinking to switch:
> 
> -Javascript is a fast and free language, sometimes too fast and
> free for a large team.  Coding standards can vary from developer to
> developer, and maintaining architectures can be difficult 
> -Javascript mistakes are only caught in runtime.  The fact that 
> GWT(Java) would catch 90+% of our simple mistakes makes me more 
> confident that our clients won't. -Javascript allows for rapid
> development, but not so rapid bug fixing. -Strict Java coding + a
> strong architecture at the outset creates a great foundation to
> build from.  I've even seen this in my firm's Android apps.  They
> are very stable.
> 
> But for me, I'd really like to hear from developers active in the 
> community.  Are you happy?  Or do you wish you went a different
> route? My goal is to have my dev team work more on new projects
> rather than fixing old projects.  I am hoping that GWT can help
> with that.  thoughts?
> 
> -Charlie
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/7HVAiaphHqwJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBvWP0ACgkQ5IyIbnMUeTs1oQCgqa/bveNbhKxskyK1rBLRSBqI
otQAmgKXwQriwtalaxi/B/03hpX5GYta
=YPUg
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Future of GWT survey

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cool, thanks for the pointer.  I knew about Xtend, but didn't put see
the implications of its compiling to Java for GWT development.

I'm quite happy with Scala in general, but something statically-typed
and less verbose than Java would be very welcome for GWT work.

On 09/20/2012 09:54 PM, RonS wrote:
> Sounds like you're set with Scala, but another advanced JVM
> language option is XTend (http://www.eclipse.org/xtend/).
> 
> They recently added GWT support: 
> http://blog.efftinge.de/2012/08/gwt-programming-with-xtend.html 
> <http://blog.efftinge.de/2012/08/gwt-programming-with-xtend.html>
> 
> 
> On Thursday, September 20, 2012 1:23:06 PM UTC-5, Clint Gilbert
> wrote:
> 
> I would /love/ to be able to use a language other than Java - in 
> particular, Scala - for GWT development.  On my project, we use
> Scala for all our other JVM work, and it's been a massive
> boilerplate killer, plus easily graspable by
> curious-but-merely-mortal developers like me.
> 
> The folks here: http://scalagwt.github.com/ have a working
> prototype, but the last I heard, they needed to submit a patch
> upstream to GWT. (Or maybe their patch needed to be accepted, I
> don't know.)
> 
> I like GWT quite a lot, and would not make a dynamic web UI
> without it, but the biggest drag is having to go back to Java.
> 
> On 09/19/2012 09:23 AM, Joonas Lehtinen wrote:
>> What is your opinion on the future of GWT? How should GWT
>> develop? What technologies should it better support? ...
> 
>> We all would like to get answers to these questions, right? To
>> do so, we created survey with help of Ray Cromwell, Artur
>> Signell, Mike Brock, David Chandler, Daniel Kurka and Bhaskar
>> Janakiraman.
> 
>> If you want to help finding the best direction for GWT, please
>> fill the survey at: http://bit.ly/GWT2012 (it will take just 10 
>> minutes)
> 
>> When the results are collected, the will share the information
>> with you.
> 
>> - Joonas @ Vaadin
> 
>> -- You received this message because you are subscribed to the 
>> Google Groups "Google Web Toolkit" group. To view this
>> discussion on the web visit 
>> https://groups.google.com/d/msg/google-web-toolkit/-/i8aXw78yueQJ
>
>> 
<https://groups.google.com/d/msg/google-web-toolkit/-/i8aXw78yueQJ>.
>> To post to this group, send email to 
>> google-we...@googlegroups.com. To unsubscribe from this group,
>> send email to google-web-toolkit+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/google-web-toolkit?hl=en
> <http://groups.google.com/group/google-web-toolkit?hl=en>.
> 
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/nHUat9IKTUsJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBcrzoACgkQ5IyIbnMUeTvt+wCeNNJTTUHxPX+sbClsVa+/OzeO
tNAAn3h1KY3mMSHTCPUtadE0xCbz4Svl
=WcsT
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Future of GWT survey

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I would /love/ to be able to use a language other than Java - in
particular, Scala - for GWT development.  On my project, we use Scala
for all our other JVM work, and it's been a massive boilerplate
killer, plus easily graspable by curious-but-merely-mortal developers
like me.

The folks here: http://scalagwt.github.com/ have a working prototype,
but the last I heard, they needed to submit a patch upstream to GWT.
(Or maybe their patch needed to be accepted, I don't know.)

I like GWT quite a lot, and would not make a dynamic web UI without
it, but the biggest drag is having to go back to Java.

On 09/19/2012 09:23 AM, Joonas Lehtinen wrote:
> What is your opinion on the future of GWT? How should GWT develop? 
> What technologies should it better support? ...
> 
> We all would like to get answers to these questions, right? To do
> so, we created survey with help of Ray Cromwell, Artur Signell,
> Mike Brock, David Chandler, Daniel Kurka and Bhaskar Janakiraman.
> 
> If you want to help finding the best direction for GWT, please fill
> the survey at: http://bit.ly/GWT2012 (it will take just 10
> minutes)
> 
> When the results are collected, the will share the information with
> you.
> 
> - Joonas @ Vaadin
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/i8aXw78yueQJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBbXuIACgkQ5IyIbnMUeTt9xACeKdEjE0Da6ao0ohTfrxIlLuNZ
kUMAn1va40R5Wrb3Gnk9lhw5i1tXEk/W
=GdQB
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Future of GWT survey

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We are at my organization.  We don't love Maven, but it fits with our
infrastructure here, and we prefer the declarative style to a
scripting-oriented one.

On 09/19/2012 10:10 AM, Paul Robinson wrote:
> One question missing from the survey that would have been
> interesting is the number of people using Maven with GWT.
> 
> On 19/09/12 14:23, Joonas Lehtinen wrote:
>> What is your opinion on the future of GWT? How should GWT
>> develop? What technologies should it better support? ...
>> 
>> We all would like to get answers to these questions, right? To do
>> so, we created survey with help of Ray Cromwell, Artur Signell,
>> Mike Brock, David Chandler, Daniel Kurka and Bhaskar
>> Janakiraman.
>> 
>> If you want to help finding the best direction for GWT, please
>> fill the survey at: http://bit.ly/GWT2012 (it will take just 10
>> minutes)
>> 
>> When the results are collected, the will share the information
>> with you.
>> 
>> - Joonas @ Vaadin -- You received this message because you are
>> subscribed to the Google Groups "Google Web Toolkit" group. To
>> view this discussion on the web visit 
>> https://groups.google.com/d/msg/google-web-toolkit/-/i8aXw78yueQJ.
>>
>> 
To post to this group, send email to google-web-toolkit@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> google-web-toolkit+unsubscr...@googlegroups.com. For more
>> options, visit this group at 
>> http://groups.google.com/group/google-web-toolkit?hl=en.
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To post to this group,
> send email to google-web-toolkit@googlegroups.com. To unsubscribe
> from this group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBbXZwACgkQ5IyIbnMUeTuhDgCghsNlB7O0ly3B5NopVVVssJqH
Nx4An0WBCkxyMXdRn9vSmxmS4I3FuyRG
=JLX/
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: any chance to get FF15 dev plugin

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Same here, thank you!

On 08/30/2012 09:08 AM, koma wrote:
> confirmed working for FF15 on Linux 64-bit... thx !
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/b43tvSGdKBkJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA/458ACgkQ5IyIbnMUeTuPhgCfTwaBuniMvzI42o4ZyqTGMneb
ptgAni599Nj31sB6fjOBxcE24OemJw+3
=B8oE
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Elemental in GWT 2.5 is what?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> (just like everyone else doing web dev out there, in JS, CoffeeScript, Dart, 
> etc.)

TLDR: There are many of us out here, I suspect, for whom this is exactly
what we do not want.

Elemental sounds cool, but I'm glad it's optional. I hope that stays
the case, and that the permuted-compile use case stays well-supported
for the foreseeable future.

On 07/10/2012 05:06 PM, Clint Gilbert wrote:
> I can see how this would be helpful for some apps - ones that need
> HTML5 features, only need to support one (or a couple) of up-to-date
> browsers, like mobile or tablet apps as others have mentioned.
> 
> But a huge selling point of GWT at my organization (where we don't
> need HTML5 features and need to support as many browsers as possible,
> even older IEs) is that a compiled GWT app more-or-less Just Works on
> all our target browsers.  Our devs mostly don't know - and don't want
> to know! - browser-specific quirks or workarounds.  We don't even have
> easy access to Windows machines for testing with IE.
> 
> I get that UA sniffing is error-prone, but in my experience with GWT's
> UA sniffing and permuted compiles, it works well enough to make
> browser-specific fixups much, /much/ rarer than when I wrote apps with
> plain JS and Jquery.
> 
>> the most recent versions of
>>> browsers, where differences are vanishing a bit more each day
>>> that passes, thanks to the many standardization efforts
> 
> I really hope you're right, though I'm very, very skeptical about this.
> 
> Implementing browser-specific workarounds and feature detection was
> such a miserable process compared to having GWT do a permuted compile
> that I do /not/ want to go back.
> 
> That code using Elemental is more easily mocked out and unit tested is
> a great thing, for sure.
> 
> On 07/10/2012 04:49 AM, Thomas Broyer wrote:
> 
>> DISCLAIMER: this is what I know about Elemental, and my
>> interpretation of it, and I haven't yet looked closely at it (its
>> internals). Everything below can be read online (e.g. on Google+)
> 
>> On Tuesday, July 10, 2012 12:34:13 AM UTC+2, mp31415 wrote:
> 
>> I'm trying to make some sense from that Elemental feature. But I'm 
>> definitely missing something. On 2.5 main page there is a link to
>> a brief article about Elemental which really does not add much.
>> GWT team is notoriously bad on documentation side and it's not
>> getting any better. Just please don't tell me to shut up and use
>> something else. It's impossible to see the big picture without some
>> background information, like what was missing before, what real
>> purpose of the feature is. It's very nice that we can now call some
>> latest API but what about the more trivial stuff that say  UiBinder
>> was in charge so far? Or maybe it is not about UI but more about
>> better hiding JSO types? Or something totally different at all?
> 
> 
>> The main thing about Elemental is that, for the most part, it's 
>> auto-generated, which makes it a breath to maintain: grab the IDL
>> files from WebKit (yes, the same files that are being used to
>> generate the C++ code that powers Chrome and Safari, themselves
>> being more or less copies of what can be found in W3C specs) and
>> regenerate the Java files out of them. The goal is to be as close
>> to the browser as possible, removing all abstraction layers. That
>> implies there's no deferred-binding being used: it's not meant to 
>> hide browser discrepancies, it's meant to be used in environments
>> where those discrepancies don't exist or can be worked around in
>> your code (code running in a UIWebView in a mobile "native" app, as
>> a Chrome extension, or simply targeting only the most recent
>> versions of browsers, where differences are vanishing a bit more
>> each day that passes, thanks to the many standardization efforts). 
>> Ideally, you no longer produce 1 permutation for each user agent,
>> but a single one running everywhere (just like everyone else doing
>> web dev out there, in JS, CoffeeScript, Dart, etc.)
> 
>> In addition to that, Elemental is made of interfaces for the most
>> part, so you can easily mock things in unit-tests, contrary to 
>> com.google.gwt.dom.client.* and the like.
> 
>> (BTW, UiBinder doing "trivial stuff"? really?)
> 
> 
>> It's not any better with all other features in fact, but right now 
>> my gripe is about Elemental.
> 
>> I looked at the Collide project code. They reference elemental.* 
>> packages all

Re: Elemental in GWT 2.5 is what?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I can see how this would be helpful for some apps - ones that need
HTML5 features, only need to support one (or a couple) of up-to-date
browsers, like mobile or tablet apps as others have mentioned.

But a huge selling point of GWT at my organization (where we don't
need HTML5 features and need to support as many browsers as possible,
even older IEs) is that a compiled GWT app more-or-less Just Works on
all our target browsers.  Our devs mostly don't know - and don't want
to know! - browser-specific quirks or workarounds.  We don't even have
easy access to Windows machines for testing with IE.

I get that UA sniffing is error-prone, but in my experience with GWT's
UA sniffing and permuted compiles, it works well enough to make
browser-specific fixups much, /much/ rarer than when I wrote apps with
plain JS and Jquery.

> the most recent versions of
>> browsers, where differences are vanishing a bit more each day
>> that passes, thanks to the many standardization efforts

I really hope you're right, though I'm very, very skeptical about this.

Implementing browser-specific workarounds and feature detection was
such a miserable process compared to having GWT do a permuted compile
that I do /not/ want to go back.

That code using Elemental is more easily mocked out and unit tested is
a great thing, for sure.

On 07/10/2012 04:49 AM, Thomas Broyer wrote:
> 
> DISCLAIMER: this is what I know about Elemental, and my
> interpretation of it, and I haven't yet looked closely at it (its
> internals). Everything below can be read online (e.g. on Google+)
> 
> On Tuesday, July 10, 2012 12:34:13 AM UTC+2, mp31415 wrote:
> 
> I'm trying to make some sense from that Elemental feature. But I'm 
> definitely missing something. On 2.5 main page there is a link to
> a brief article about Elemental which really does not add much.
> GWT team is notoriously bad on documentation side and it's not
> getting any better. Just please don't tell me to shut up and use
> something else. It's impossible to see the big picture without some
> background information, like what was missing before, what real
> purpose of the feature is. It's very nice that we can now call some
> latest API but what about the more trivial stuff that say  UiBinder
> was in charge so far? Or maybe it is not about UI but more about
> better hiding JSO types? Or something totally different at all?
> 
> 
> The main thing about Elemental is that, for the most part, it's 
> auto-generated, which makes it a breath to maintain: grab the IDL
> files from WebKit (yes, the same files that are being used to
> generate the C++ code that powers Chrome and Safari, themselves
> being more or less copies of what can be found in W3C specs) and
> regenerate the Java files out of them. The goal is to be as close
> to the browser as possible, removing all abstraction layers. That
> implies there's no deferred-binding being used: it's not meant to 
> hide browser discrepancies, it's meant to be used in environments
> where those discrepancies don't exist or can be worked around in
> your code (code running in a UIWebView in a mobile "native" app, as
> a Chrome extension, or simply targeting only the most recent
> versions of browsers, where differences are vanishing a bit more
> each day that passes, thanks to the many standardization efforts). 
> Ideally, you no longer produce 1 permutation for each user agent,
> but a single one running everywhere (just like everyone else doing
> web dev out there, in JS, CoffeeScript, Dart, etc.)
> 
> In addition to that, Elemental is made of interfaces for the most
> part, so you can easily mock things in unit-tests, contrary to 
> com.google.gwt.dom.client.* and the like.
> 
> (BTW, UiBinder doing "trivial stuff"? really?)
> 
> 
> It's not any better with all other features in fact, but right now 
> my gripe is about Elemental.
> 
> I looked at the Collide project code. They reference elemental.* 
> packages all over the place and elemental classes carry copyright 
> statement from 2010. So is it new or just recently opened by
> Google?
> 
> 
> Elemental is not new. It's only been open-sourced recently.
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/VEaRwNLJXKIJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/8mXAACgkQ5IyIbnMUeTv1MgCfSPQ3CKPjH6O8CO/BTrTjD5u7
seoAn0wClmR20P5YTpbAEP1s3W1/ZmQU
=6gQe
-END PGP SIGNATURE-

-- 
You received this message because you

Re: Super Dev Mode general question

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I understand that browser plugins are problematic.  I wouldn't want to
be responsible for building a new plugin for each week's Firefox
release.  (Obviously, I'm joking.)

But debuggers in current Java IDEs are very robust and full-featured.
 Every Javascript debugger in every browser that I've ever tried has
been inadequate in comparison.

Hopefully regular dev mode will live on for long enough for JS
debuggers to improve significantly, though I fear that will take a
long time.

Count me among those who will miss the useful features of the existing
dev mode when it goes away.

On 07/09/2012 10:51 AM, Thomas Broyer wrote:
> 
> 
> On Monday, July 9, 2012 3:24:19 PM UTC+2, sanny...@gmail.com
> wrote:
> 
> Hello,
> 
> I recently found this topic about Super Dev Mode appearing in GWT
> 2.5. I am happy that new way of debugging is coming to the GWT 
> development process. But I am not happy that there are plans to
> discard current DevMode in the future. At least, each official
> mentioning of SuperDevMode means that it will replace current
> DevMode.
> 
> If this is true, then I am not happy at all.
> 
> Debugging in the IDE of choice was always top feature of GWT for
> me. Ability to freely navigate code, use typesafe autocompletion
> in evaluate expression boxes, drop stack frame feature and all
> other hundreds of java-specific little features is great joy.
> Forcing developers to discard all this and be tied to browser is at
> least major regress.
> 
> I could not find any discussion on this topic, if there's any, 
> PLEASE direct me to the page where it all was discussed and
> decision was made, i want to see the arguments. I found only
> "browser plugins are instable" topic. But people, concept is
> already working satisfactory for several years and I don't want to
> lose it in future because it is not 100% perfect and crashes
> sometimes.
> 
> Telling "source code maps are being implemented in browsers at the 
> moment" and at the same time arguing that SuperDevMode will make
> us browser-independent seems like lame joke. At least, not all
> browsers will. But even if all major browsers (Chrome, FF, Safari,
> IE) will, source maps is only part of the picture. The debugging in
> all browsers has its own interface, keymaps etc, and, as I wrote
> above it never compares to the IDE/Native java debugging. In other
> words, it does not compare!
> 
> TLDR: questions: 1) Is it true that SuperDevMode will replace
> DevMode
> 
> 
> Who knows? More seriously, you can be assured DevMode will stay for
> quite some time.
> 
> 
> 2) If yes, then for the sake of God, why such regress?
> 
> 
> Browser plugins are a nightmare to maintain. The plugin for Chrome
> is known to be buggy and unstable. Every 6 weeks, the plugin for
> Firefox has to be updated (we could choose to only support Firefox
> ESR, but I doubt you'd be happy; I wouldn't be). I've heard there
> had been issues with the Safari plugin on OS X at some point, due
> to a browser upgrade. The only stable plugin for now is the one for
> IE, and even that one required some work to make it compatible with
> IE9 and the newer versions of Windows. Generally, browser vendors
> don't help us maintain plugins.
> 
> Due to this fact, no new plugin is being developed, so debugging
> in Opera, or Safari on Windows, won't ever be possible (OK, that's
> rhetoric anyway, as nobody minds ;-) ).
> 
> But now we also have to support mobile development: iOS, Chrome
> for Android, Firefox Mobile, Windows 8, etc. and those browsers
> don't even allow us to use plugins! And that's where SuperDevMode
> shines with its plugin-free approach: it brings DevMode to any
> single browser out there, at the expense of using the browser's own
> dev tools.
> 
> So, what the future is? Honestly, to me, the future is in wire
> protocols for JS debuggers. Opera has had one for long, Chrome too.
> Mozilla is building one. I can't tell for IE but at least you can
> debug a local IE instance so it's better than nothing, and we can
> have hopes that DevMode as we know it will be supported for quite a
> long time (compared to other browsers). With such protocols, your
> IDE could connect to your browser and use SourceMaps to give you
> (almost) the same debugging experience as if you were running your
> code "natively" (technically, I believe it could also be made so;
> based on an experiment I made a few years back to bring DevMode to
> Adobe AIR through the Flash debugger). This, to me, is the way
> forward. It would however require a tremendous amount of work, so 
> it's not going to happen any time soon.
> http://code.google.com/p/chromedevtools/ could help here I guess, 
> but it's still a very tiny part of what's needed to bring the same
> level of debugging as with the current DevMode.
> 
> 10 years after the Internet Bubble, web dev is only starting to
> make its revolution towards "professionalization" (MVC was seen as
> a thing of the past unt

Re: Firefox 13 DevMode Plugin

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thank you!

On 06/07/2012 01:54 PM, Alan Leung wrote:
> For the folks with fancy CPUs running Linux.
> 
> http://acleung.com/ff13-linux64.xpi
> 
> -Alan
> 
> On Thu, Jun 7, 2012 at 9:40 AM, Yuri C  > wrote:
> 
> LOL! I wish you didn't mention that. That way I would have much 
> stronger faith in people's goodness :)
> 
> Meanwhile patiently waiting for the 64bit linux version :)
> 
> 
> On Thursday, June 7, 2012 11:00:54 AM UTC-4, Thomas Broyer wrote:
> 
> 
> 
> On Thursday, June 7, 2012 4:32:40 PM UTC+2, Yuri C wrote:
> 
> I also hope that you get something from Google for your effort.
> Altruism needs to be encouraged :)
> 
> 
> Well, Alan gets a salary from Google ;-)
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/m8-0ryj21_wJ.
> 
> To post to this group, send email to 
> google-web-toolkit@googlegroups.com 
> . To unsubscribe from
> this group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com 
> . For
> more options, visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.
> 
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To post to this group,
> send email to google-web-toolkit@googlegroups.com. To unsubscribe
> from this group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk/Q8AIACgkQ5IyIbnMUeTtpnQCgmWzKers5dAb0iJtqJnc1LsVb
xYQAmPiqzeWKfQUXr+j97BH2VjQ1wRM=
=UH0i
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Google IO 2012 : no GWT session ?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/19/2012 03:34 AM, kritic wrote:
> Regardless of what the GWT team says, I do believe GWT as it is now
> will be phased out.

I fear you're right.  I get the same feeling, for the reasons you
mentioned.  It's too bad, because Dart, while an improvement over
straight JS, brings - for me - the worst parts of JS (dynamic typing)
and Java (unhelpful verbosity) though with some welcome improvements
to structure-ability and defining anonymous functions.

Scala-GWT is getting quite close to a first release.  It's a long
shot, but I hope it takes off.  Scala is extremely well-suited to
cutting out huge amounts of ui-callback boilerplate without
sacrificing any type-safety.




> Don't get me wrong, I think the features that GWT provides are 
> second to none and the work put into it has been nothing short of
> impressive, but it has to be recognized that it is also becoming a
> rather pain in lower back for Google simply because it uses Java.
> Seems odd, but I really think the whole thing with Android is
> leaving a bad taste. I really do think Java will become used less
> and less for future projects (especially GWT).
> 
> The way GWT is now, like I wrote already, will probably be shifted
> to something else. Dart is all the rage right now and it's nice,
> however it almost feels like an attempt to replace GWT. Golang (Go)
> is another language that is very well thought out and could
> conceivably replace Java within, at least, Google.
> 
> Perhaps emscripten has been looked at by the GWT team. Perhaps it
> may be better to use something like that - which will introduce a
> mix of languages with all the same features as GWT? I would enjoy
> that. I think many would. Right now, though, I am keeping my
> distance from GWT. Even though it's a fantastic technology.
> 
> On Thursday, May 17, 2012 2:00:00 AM UTC-4, Celinio Fernandes
> wrote:
> 
> Hello, I just noticed that the schedule for Google IO 2012 is now
> available : https://developers.google.com/events/io/sessions 
>  Not sure whether
> it is definitive or not. I see that this year there is no session
> dedicated to GWT. How come ? But there are 2 sessions dedicated to
> Dart. Is this a sign ?
> 
> 
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/vNfMwXAhWxcJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk+5Ia4ACgkQ0GFaTS4nYxvqIgCgnsnCT/Ao33GcZXQ39ugiBQKm
cfUAoIMFRYGGsFUUX1OB8rjjJtH8g8v2
=nKad
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: GWT Debug & Firefox (for the n'th time)

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Are you missing the GWT dev mode plugin?  The Linux versions are here:

http://acleung.com/ff12-linux32.xpi
http://acleung.com/ff12-linux64.xpi

You can search through this list's archives for messages from

Alan Leung (acle...@google.com)

with the subject "Firefox 12 release".  That thread contains links to
FF12-compatible plugin builds for other OSes.



On 05/15/2012 02:32 PM, Rori Stumpf wrote:
> I made the mistake of upgrading to FireFox 12. I thought Chrome
> would work for GWT debug, but that pig still isn't flying. So...
> where can I download FF 10? I've spent 1/2 hour trying to find it 
> on the web, everything I found points back to FF12.
> 
> Thanks.
> 
> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit 
> https://groups.google.com/d/msg/google-web-toolkit/-/JHwQUu00KqEJ. 
> To post to this group, send email to
> google-web-toolkit@googlegroups.com. To unsubscribe from this
> group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com. For more options,
> visit this group at 
> http://groups.google.com/group/google-web-toolkit?hl=en.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ypr0ACgkQ5IyIbnMUeTttnwCfVnUqE0mb5EDbajVXD5DufLRT
acsAoJPH67bK4n44zIRAQICwky9+WOxT
=3ZYF
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Can UI components be tested through JUnit/GWTTestCase?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've been able to test Widgets with JUnit in a project I'm working on.
I'm able to make widgets, see that they respond to external events
(notifications about state they observe, or event types they're
subscribed to via an EventBus, that sort of thing), and even send UI
events to them:

final MyWidget myWidget = new MyWidget(...);

myWidget.someButton.fireEvent(new ClickEvent() { });

//assert that the right things happened

The anonymous subclass of ClickEvent feels a little hacky, but it works
for us because our widgets (for the most part) just care that they got
clicked, they don't care about x and y coords, etc etc.

Writing the tests was relatively straightforward, but getting them to
run as part of a Maven build took some doing. A pom with all the
necessary incantations is here:

https://open.med.harvard.edu/svn/shrine/trunk/code/webclient/pom.xml

I don't know if that's minimal or not; I started with what was generated
by the gwt-maven-plugin, and tweaked the pom until it did what I wanted.
:/  We use a TestSuite (ugh) and follow the naming conventions for test
classes and suites recommended by the gwt-maven-plugin docs.

On 04/24/2012 04:50 PM, King_V wrote:
> Ok, I found some old messages (several years old) that says this
> cannot be done.
> 
> However, when I look at:
> https://developers.google.com/web-toolkit/doc/latest/DevGuideTesting#DevGuideJUnitSetUp
> 
> this seems to imply that you can actually test GUI items on a browser
> with such tests.  I might well be completely misinterpreting what it's
> there for, though.
> 
> However, I'm baffled as to how to do so.
> 
> For example, I might normally put MyWidget into the RootPanel as
> follows:
> 
> RootPanel.get().add(new MyWidget("Some text here"));
> 
> 
> But how would I do this in a JUnit test case / GWTTestCase?
> 
> Thanks.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk+XRSEACgkQ0GFaTS4nYxviVACeMqLdXljCkWI3lrS9tCDBulvF
pqkAn24TZuVGsdOccZTBDCWlGsGjpMi/
=G4pS
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Why not use applets?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

That may be true, but the perceptual damage is done.  I never bothered to keep 
up with
Applet developments because the user experience was so bad for so long.  (10+ 
years?  I'm
pretty sure I saw my first applet in 1995, but I don't know if it was running 
in a browser.)

So does the JVM plugin start up as fast as Flash now?  If so, that's great.

D Peters wrote:
> For the record -- a significant amount of the common applet
> performance gripes were cleared up in 6u10.  I'm suprised that so many
> java developers know nothing about this release.  This was a milestone
> for JavaFX to move forward -- since it was built on top of a lot of
> these improvements.  If you don't mind JavaFX in the browser (it
> doesnt have to run as JNLP, by the way)-- then you probably won't mind
> using an applet -- because it is essentially running as an applet.  As
> more people develop JavaFX applications, and it becomes more
> widespread, you will have a broader base of users who can also use
> applets.
> 
> > 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ0nnnrZoE3ArapxERCEXgAJ92wRZF3eFht2GJCgSgRuEWFxCuGACgrRBr
jfDfHe8ibw3yQnkcEy+NP/A=
=g5Pl
-END PGP SIGNATURE-


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Why not use applets?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

One reason is that Applets annoy users.  You need to install the Java
plugin, then when an applet loads, it takes a long time for the JRE to
fire up, and the browser hangs the whole time.

Meanwhile, Flash starts right up.  Flash ads might be obtrusive, but the
startup overhead of the Flash applet is not.  I'd much rather code in
Java than Actionscript, but I'd much rather use a page with flash apps.
 (Barring, of course, annoying all-Flash UIs.)

Dobes wrote:
> Recently while cursing the slowness of GWT compilation, the slowness
> in the browser, and the lack of Java 6 features, it occurred to me
> that if GWT had simply been built on top of the Java Applet technology
> it could really overcome these limitations.
> 
> Does anyone know why GWT wouldn't be much better if it were java
> bytecode running in an applet?  All the major browsers support
> applets, the Java VM runs the code nice and fast, and applets have
> decent access to the DOM and the ability to run javascript.
> Everything that is needed to implement GWT is available to an applet,
> as far as I can tell.
> 
> Thoughts?
> 
> If I had time I'd experiment and try making a knock-off of GWT using a
> hidden applet so I could just write every in Java, run and debug it in
> the Java VM ... could even use Java's built-in RPC mechanism if I
> wanted to.  Interesting concept, although it's likely I'm missing
> something important about why the GWT team didn't go this route in the
> first place.
> 
> 
> 
> > 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknRtrcACgkQ0GFaTS4nYxse4gCdGzMi6OHfrYlxAyIYsC7RXllX
gCgAoNBthgVoS4aM4N2jhfuFcIk8AiCL
=9vRG
-END PGP SIGNATURE-


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Approaches to develop a stateful application

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In case you're still on the fence, I suggest you keep as much of your state as 
possible
(preferably all of it) on the client.  It's just easier.  You can think of an 
instance of
your EntryPoint class being around while your app is open in a browser window 
or tab.
That class has fields, and there's your state.  GWT apps are a lot like desktop 
apps in
that way.

stsch wrote:
> Hi,
> 
> I have just started with GWT. What are the approaches to develop a
> stateful GWT application? Could any of the experts please summarize
> this a bit for a beginner and maybe point me/us to some reference
> material?
> 
> Thanks,
> -StSch-
> > 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJx+dlrZoE3ArapxERCFwZAJ0XrijghlJyN9vjwBbr7vvZfyYhLQCfdCqb
1165OOIC2BnZqyrj9YeLTZA=
=5aRG
-END PGP SIGNATURE-


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Stupid Question on Client side Session

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Or you could make them non-static member fields of your EntryPoint class.  You 
can think
of there being an instance of that class around for as long as your app is open 
in a
browser window or tab.

We use that approach in our app here.  (Static fields felt to much like globals 
in this
case.)  Actually, our EntryPoint class contains a final field of type Context, 
which is a
class we've defined to store all of our client-side state.

Lothar Kimmeringer wrote:
> joe young schrieb:
> 
>> So what is the best suggestion to store those data, is there something
>> like session in client side?
> 
> You can define variables static. This has some effects in hosted mode
> if you open more than one window but should work in a browser.
> 
> 
> Regards, Lothar
> 
> > 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJv/41rZoE3ArapxERCMPhAJ9zggC2AeNTSWHUxetyBt3DDuzf5wCfe/Io
xc7ymU9OscV1ZHqdsA3+1MA=
=/Vo9
-END PGP SIGNATURE-


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Client-side JSON Serialization?

[Clint Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thanks very much, I'll take a look at wgtjsonrpc.

My app needs to serialize a non-trival map of data: String => Date-range class 
=> other
user-defined type => data POJO, currently.  I'm familiar with Overlay types, 
and somewhat
familiar with JSNI, so I think I could write a class that wraps a 
JavaScriptObject and
uses that handle as the backing map.  Then I could just serialize the wrapped 
JSO.  But
then I'd lose some useful features of a Java Map, like being able to use 
non-primitive
types for keys, nice methods like keySet(), etc, no?

Shawn Pearce wrote:
> Roll your own, or look at gwtjsonrpc:
> 
>   
> http://android.git.kernel.org/?p=tools/gwtjsonrpc.git;a=blob;f=README;hb=HEAD
> 
> You can also look at JSNI and the JavaScriptObject subclassing tricks in the 
> GWT documentation (under JavaScript Integration) to build Java objects that 
> are more directly JavaScript entities, and thus more easily serialized with 
> JavaScript JSON libraries.
> 
> On Tue, Dec 16, 2008 at 18:34, 
> clint.gilb...@childrens.harvard.edu
>  
> mailto:clint.gilb...@childrens.harvard.edu>>
>  wrote:
> 
> I'm sorry if this has already been answered, but after searching a bit
> I didn't come up with any answers.  Does anyone know of a way to
> serialize objects to JSON on the client side?  Ideally, it would work
> similarly to the json2.js lib from json.org that I was using 
> prior to
> moving to the GWT, but anything relatively straightforward that
> performs well is fine with me.
> 
> I tried wrapping the json2.js lib in a native method that calls
> $wnd.JSON.stringify():
> 
> public abstract class JSONSerializer
> {
>public static final native String serialize(final Object object)/*-
> {
>return $wnd.JSON.stringify(object);
>}-*/;
> }
> 
> but it pins my CPU and runs for several minutes when serializing
> anything but a trivial object.  The problem seemed to be the verbosity
> (completeness?) of the object when marshalled across the Java-
> toJavascript boundary by the GWT.  I'd also like to control the
> mapping of Java properties to JSON ones.
> 
> Surely there's a better way?  Or will I have to roll my own?
> 
> 
> 
> 
> > 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJSU+ErZoE3ArapxERCFm6AKCBhbEn83de4ivjGGgBAagpEAFGaQCeIDJL
3xJzW9oU0UXdC9WuiFUbm3M=
=/zOi
-END PGP SIGNATURE-


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---