Eclipse Code Server Launcher Icon

[Brandon Donnelson]

I'm making some bug fixes with the Eclipse Code Server Launcher. And one of them is making it clear which launcher you have in the list. 

There are two launchers, the Web Application Launcher, which is getting renamed to GWT Application Launcher for clarity. More on that later. And the Code Server, which uses the CodeServer as an entry point. 

I'm attaching the images of what I've come up with for the image. But I'm open for suggestions, although if you suggest it, I hope you can design it because I don't have enough time or talent to make it better than what I'm proposing. 

Would you like to provide a proposal for for the Code Server Launcher Icon? 

By the way, I'm fixing some bugs aiming to make it easier to use with custom web servers. 

Thanks,

Brandon

[Brandon Donnelson]

That reminds me I need to change the classpath for it too. 

[Ignacio Baca Moreno-Torres]

I'll personally prefer the current logo (GWT logo) for the codeserver, because I think that the codeserver is the actual GWT part, and for the devmode and web application (which I suppose are a devmode or variants using some java web server) I will suggest a standard server icon plus a small GWT logo, so the GWT logo always means codeserver. You can even combine the jetty icon + gwt logo, or app engine + gwt logo, etc.

[Brandon Donnelson]

The problem with the current GWT logo is that I've already assigned that to the web application launcher and both look alike. I'd like to provide a little bit of distinction between the Web App launcher and Code Server Launcher icons, so that way it's obvious. The icon design looks promising tho. It has to be 16x16 so it's a bit too tall I think. 

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/WGLtekU5U5U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/97a5c6ff-fd45-42e5-9f67-3929467c9e1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Becker]

Here's two options I whipped up....

On Thursday, August 25, 2016 at 10:38:55 AM UTC-7, Brandon Donnelson wrote:

The problem with the current GWT logo is that I've already assigned that to the web application launcher and both look alike. I'd like to provide a little bit of distinction between the Web App launcher and Code Server Launcher icons, so that way it's obvious. The icon design looks promising tho. It has to be 16x16 so it's a bit too tall I think. 

On Thu, Aug 25, 2016 at 10:31 AM Ignacio Baca Moreno-Torres <ign...@bacamt.com> wrote:

I'll personally prefer the current logo (GWT logo) for the codeserver, because I think that the codeserver is the actual GWT part, and for the devmode and web application (which I suppose are a devmode or variants using some java web server) I will suggest a standard server icon plus a small GWT logo, so the GWT logo always means codeserver. You can even combine the jetty icon + gwt logo, or app engine + gwt logo, etc.

On Thursday, August 25, 2016 at 6:36:17 PM UTC+2, Brandon Donnelson wrote:

That reminds me I need to change the classpath for it too. 

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/WGLtekU5U5U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Ignacio Baca Moreno-Torres]

Uoo.. the eclipse guidelines are quite detailed! http://wiki.eclipse.org/User_Interface_Guidelines

[Brandon Donnelson]

Hm, based on the guidelines the server icon might make the most sense. That would be an easy manipulation then. The other option could be to just add the run arrow.

[Jens]

I guess the future is CodeServer + optional external servlet container.

So IMHO it would be more straight forward to just have "GWT Web Application" which always launches CodeServer.main() directly and not through DevMode.main(). Within this run configuration you can optionally choose to automatically launch an external servlet container as well, e.g. through Eclipse WTP or by running a second run configuration like a maven goal / gradle task or a terminal command.

=> normal GWT icon

If you want to support the legacy guys there would be "GWT Web Application (legacy)" which would launch classic DevMode

=> GWT icon with some standard Eclipse server icon

-- J.

[Brandon Donnelson]

Hm, I hadn't thought about making the CodeServer the default yet. I've been helping folks convert to super dev mode every chance I get so my feeling is that keeping the legacy the default method that starts up with SDM probably is the way to go on for a bit longer.  I've got to be careful I don't bite off more than I can chew so my goal is to get the CodeServer launcher running swimmingly. That said, I'm afraid of upsetting the applecart too much by doing any big changes. Since the CodeServer launcher came later, I've been keeping it as a new launcher. I think it's effective to use with custom integrated and external server runtimes. The integrated jetty server usually doesn't fit most enterprises production structures so it causes all kinds of dev strategy workarounds to make things work well. And using DevMode with -noserver works great for most things but the proxy of the arguments from DevMode doesn't work for every situation like CodeServer does. 

Although there is another branch for the GWT Eclipse plugin that I'm working on which will be the new and improved version. This I think might be the ticket to change the feature here. In fact I like the idea for this branch. I'm having to separate out the Google cloud tools to make way for combining up with the cooler stuff coming from the Google Cloud Plugin. 

Good idea, thanks. 

-Brandon

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/WGLtekU5U5U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/6e8f5a16-6d20-41b2-bb99-bb3964cbfda7%40googlegroups.com.

[Thomas Broyer]

On Friday, August 26, 2016 at 3:16:25 AM UTC+2, Brandon Donnelson wrote:

Hm, I hadn't thought about making the CodeServer the default yet. I've been helping folks convert to super dev mode every chance I get so my feeling is that keeping the legacy the default method that starts up with SDM probably is the way to go on for a bit longer.

FWIW, when the release notes say "DevMode is deprecated", people can understand it in 2 different ways; and I had the impression that Daniel Kurka at least interpreted it as com.google.gwt.dev.DevMode is deprecated.

I'm not sure we were all on the same line in the Steering Committee when saying "DevMode is deprecated"; I think most thought that "legacy dev mode" was deprecated, but c.g.g.dev.DevMode would stay (just losing its -nosuperDevMode).

I, for one, would have preferred that we didn't even integrate SDM within c.g.g.dev.DevMode in 2.7; or explicitly describe it as a transitional feature, encouraging everyone to switch to CodeServer even before 2.8.

In any case, if we do keep c.g.g.dev.DevMode in the future, I'll campaign (again) for removing its custom WebAppClassLoader and force users to put all their deps and compiled server classes into WEB-INF/lib and WEB-INF/classes.

So, I'm with Jens here wrt icons.

[JonL]

I have always considered the deprecation of "DevMode" to mean the deprecation of the "HostedMode"/GWT Dev Mode plugin combo and that SDM was the non-deprecated version. It sounds like some are considering losing SDM as the default run mode.  I think that would be a mistake and would make it appear that GWT is more cumbersome to use than it is.  Hosted Mode w./ Dev Mode Plugin was broken due to the deprecation of the NPAPI plugin, other than possibly refactoring out SDM from the DevMode class, I would personally consider removing SDM as breaking something that isn't broken for no particular reason.

Also, we use ivy for dependency resolution and due to a bug in the IvyDE classpath container, it does not load things it considers to be a source jar onto the classpath, we already deploy all our libs to WEB-INF/lib.

[Thomas Broyer]

On Friday, August 26, 2016 at 4:30:48 PM UTC+2, JonL wrote:

I have always considered the deprecation of "DevMode" to mean the deprecation of the "HostedMode"/GWT Dev Mode plugin combo and that SDM was the non-deprecated version. It sounds like some are considering losing SDM as the default run mode.  I think that would be a mistake and would make it appear that GWT is more cumbersome to use than it is.  Hosted Mode w./ Dev Mode Plugin was broken due to the deprecation of the NPAPI plugin, other than possibly refactoring out SDM from the DevMode class, I would personally consider removing SDM as breaking something that isn't broken for no particular reason.

I don't understand what you mean.

DevMode can mean either "dev mode using the browser plugin", or "the c.g.g.dev.DevMode entrypoint class".

SDM, to me, can only mean "dev mode using compiled-on-the-fly JS", so it'd be the opposite of "dev mode using the browser plugin", without saying "how" you run it.

The opposite of "the c.g.g.dev.DevMode class" is CodeServer (i.e. "the c.g.g.dev.codeserver.CodeServer class").

And SDM could be used either through c.g.g.dev.DevMode or CodeServer.

So for SDM, there's no terminology problem, and yet I don't understand what you mean by "removing SDM".

CodeServer will stay, that's a given. The question (to the Steering Committee) is whether c.g.g.dev.DevMode will stay with only its SDM mode, or whether it'll be removed (and SDM can only run through CodeServer, which would remain the only "development mode" of GWT).

[JonL]

I guess I didn't word it correctly.  I think I am talking more of the experience of running the CodeServer and the embedded Jetty Server serving the app, in one shot utilizing the eclipse plugin has become synonymous in my head with SDM.  Where as running the web app on an external server and manually starting the CodeServer, I don't so much attribute to being "super", but more "cumbersome" dev mode.  So I guess what I am trying to say is that from the eclipse development perspective, utilizing the plugin, there should always be a one shot command that starts up the CodeServer and deploys the app for you and then maybe you start a browser using SDBG Plugin, should remain the most cumbersome experience for utilizing the plugin, by default.  

I don't use the maven plugin, but I would guess by discussion that there is a similar experience where the maven plugin starts up the codeserver and uses DevMode plugin for deployment.  

So ultimately, I think, unless there is a better way, across all these plugins to provide a similar getting started experience where you run one command to start the CodeServer and a deployment server, my vote, if it counts for anything, would be to keep c.g.g.dev.DevMode with only SDM and refactor it possibly so that its clear to what it is and separate it, cognitively, from the old classic DevMode utilizing the browser plugin.

[Ignacio Baca Moreno-Torres]

Em... this is kind of related, some days ago I speak about this with manolo in gitter; currently the CodeServer use the standard nocache.js instead of the compile-on-refresh (actually uses the compile-on-refresh the first time, but subsequent compilations uses the standard one). And... does not makes more sense that the codeserver compilations always uses the compile-on-refresh nocache.js? I think that this is in general quite useful, but is even more useful for client only project so the codeserver serves all the resources (just need to move your index.html into a public folder like this https://github.com/ibaca/rxcanvas-gwt/blob/master/src/main/java/rxcanvas/public/index.html). Hopefully this will promove using codeserver alone even more.

[Brandon Donnelson]

I'm all for the CodeServer being the main entrypoint for SDM launching. Although we need IDEA to get on board and add the launcher too. I do think some of the pain can be taken out of the process when running the code server with another web server/device process. Like Eclipse has server runtimes, which you can automatically work with. I suspect once the kinks get worked out with working with the Code Server and web server/device runtimes, DevMode will decrease in use. I'd really like to have a code server nocache.js implement the -bindAddress as the hostName instead of window.location to really make it effective with external servers, so a proxy doesn't have to be setup and launcherDir can plan the xxx.nocache.js sdm launcher script. For most enterprise operations, I running the baked in jetty web server is not effective and not very flexible but for a few. Anyway, Eclipse is getting upgrades to the code server launcher. The next version will focus on the code server as the main entry point I think. I'll ask for more feedback as that comes together. 

[Brandon Donnelson]

I changed web application icon to have an icon with a server. I renamed the launcher name to super dev mode which is the code server launcher. 

[Brandon Donnelson]

Oops, wrong screenshot. 

[Brandon Donnelson]

Changing the launcher shortcuts