[ https://issues.jboss.org/browse/JBIDE-10550?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-10550: -------------------------------- Description: The Server Editor has often been called "too busy" with unrelated settings populating it in a rather disorganized fashion. Less-often used settings, such as which pollers to use, or manually setting ports, have often been suggested that they be hidden a bit so as not to distract users. With several jiras open for adding additional settings (ex: expose management port? or, for openshift, automatically git-add new files before commit?), simply throwing them into the Server Editor would only serve to clutter it further. A uniform UI with a real design and intuitive location for new settings should be created, with clear outlines for what belongs in the server editor (very little) vs what is a more advanced setting and can be hidden (though still not too far... user should not need to go 'DIG' to find it). Currently, there are 4 key sections: Pollers, Ports, Credentials, and "Behaviour" (or mode... local vs rse). But, in recent builds, the "Behaviour" section has received several checkboxes that have more to do with launching, such as binding to all interfaces, or the server being remotely controlled and thus a dummy adapter. Other options, like the possibility of restarting a module on .class changes, have no obvious place to live, and, if added today, would most likely be added in the "Behaviour" section, which seems like it does not belong there. Also, an option like exposing the management port on launch would probably similarly be placed in this section, bringing the number of options for "Behaviour" to 4. This of course seems very wrong to me. was: The Server Editor has often been called "too busy" with unrelated settings populating it in a rather disorganized fashion. Less-often used settings, such as which pollers to use, or manually setting ports, have often been suggested that they be hidden a bit so as not to distract users. With several jiras open for adding additional settings (ex: expose management port? or, for openshift, automatically git-add new files before commit?), simply throwing them into the Server Editor would only serve to clutter it further. A uniform UI with a real design and intuitive location for new settings should be created, with clear outlines for what belongs in the server editor (very little) vs what is a more advanced setting and can be hidden (though still not too far... user should not need to go 'DIG' to find it). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10550?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-10550: -------------------------------- Attachment: JBIDE-10550_empty_editor.png Attached is what the editor might look like when all such options are moved. It would clearly be fairly empty. The new entry point for most options would be right-click server, properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10550?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-10550: --------------------------------------------- For me this is not really solving anything IMO - it is a fourth dumping ground of settings. We already got the server editor which is and always will be the primary location for settings as long as that is where Eclipse WTP has its settings. Adding more pages to this is better IMO than moving it to server properties. Beyond that there is the launch configuration page/dialog which can and does have settings already related to launches. And finally we have global server/runtime settings like classpath/file xpath setup in the Preferences. For me it feels like the underlying API/code is being used to drive the UI instead of looking at how the UI should look like and then do the proper mapping/setup in what fits an API behind the scenes. About your specific mentioned "new comers" "expose management port?" - if you by this mean which url and port to use for doing management operations? then you already have a Ports section, but you also in this need eventually to support setting the host used to connect for this and thinking about it this makes more sense together with admin username/password settings...in short - its too spread out now and the new setup continues that (bad) trend. "for openshift, automatically git-add new files before commit?" - I do not see this as a server specific setting - this is something handled at publish time and could just as well be a global behavior. Similar the "pattern for restart" could also be global IMO, but if it should be added to the server then this seem to fit into "Publishing" section. Can we edit/add to that ? On the topic of using Properties view then that I agree should not be a primary UI for configuring these things but it could be used as an alternative for getting an overview for certain parts of the UI which might be showing on separate pages. It's worth mentioning that the UI element that disturbs me the most is the non-intuitive "Server State Detectors". i.e. what does "JBoss 7 Manager Service" tell the user ? would it not make more sense this was called "Ping Management API" for start and "Attempt graceful shutdown" for Stop and then dependent on the server this was either handled via JMX or AS7 Management API ? And the title of that section should be more like the others, i.e. "Server State Detection" instead of "Detectors"....actually - "server" is a redundant word in our sections now that I look at it. Similar - "Timeout" is a bit weird since it afaik mean "just wait some random seconds without actually doing anything" ... and afaik there are timeouts in place for all the the other options - what is so special about this one ? The UI does not tell. "Web Port" could also be more less "low level" - maybe "Ping Web"? Now trying toggling all these I'm considering if there shouldn't be a label beneath these choices explaining what the current selected option does? About "ports" then couldn't these be split into a "Web" and "Management" section which for "Web" could have the Port and possibly an option for enabling for AS7 the "recompile .jsp on save" and then "Management" could have host/port and username/password settings tied together ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10550?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-10550: ------------------------------------------ Btw. I screenshotted the other server adapter editor when we started talking about this: http://community.jboss.org/wiki/DesigningANewUIForJBossASServerAdapter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10550?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-10550: --------------------------------------------- Thanks for reminding me about the screenshots you created - the TC adapter from SpringSource looks crowded but it is better than we got now since the options are logically grouped IMO. Thus this enforces my belief we can do this just fine in the server editor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10550?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-10550: -------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira