Community
Participate
Working Groups
Created attachment 192950 [details] Patch against CVS head to add validation and flag as an error If the user doesn't specify a manual port and disables automatic launching of the browser how would they know what port was chosen? This configuration probably needs to be caught by the validation and flagged to the user at least as a warning. Based on my comments here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=342083#c2 After further thought it should probably be an error state. There doesn't seem to be a valid use case for having both disabled.
Created attachment 192952 [details] patch with tests only Added patch with test cases (all passing for me).
I agree that the use case for having the port chosen automatically without opening a browser is rare. However, with Jetty printing the the port number in the console, it is possible to deduce the URL that will point to the launched application. In my eyes, there should be a warning at most, though I wouldn't care too much and just leave it as it is. (I gave this issue a title - feel free to adjust if you see fit)
>After further thought it should probably be an error state. There doesn't seem >to be a valid use case for having both disabled. I also think that an error state is too hard. I'm OK with warning or information. Another alternatives could be: * to print the application URL into the console like jetty and don't do anything. * to show an warning decoration right of the port spinner with the appropriate tooltip.
Created attachment 193092 [details] Updated patch flagging only as warning Ok, I downgraded to a warning. I think that is sufficient. I would love to see a control decoration, I think that would be much better than the current system. I think all of the warnings should be changed to use control decorations at once though, so I didn't include it here.
Created attachment 193093 [details] Updated patch flagging only as warning Again, without the changes to the .launch file this time.
(In reply to comment #3) > * to print the application URL into the console like jetty and don't do > anything. Is this possible? I think it would be useful, especially if it were a clickable link.
Created attachment 193359 [details] merged and refoctored The patch looks good. I did some refectoring and renaming. I also adapt the patch to the CVS HEAD. Can be committed.
>I think all of the warnings should be changed to use control decorations at once though, so I didn't include it here. Our approach from the beginning is to use warnings/errors. May be it could be more user friendly with decorations but it is not a topic for now. >Is this possible? I think it would be useful, especially if it were a clickable link. To print the application URL into the console is possible but the console doesn't make the links clickable. When the user disabled the "open in browser" option then IMO a clickable link doesn't make any sense.
(In reply to comment #8) > >I think all of the warnings should be changed to use control decorations at > once though, so I didn't include it here. > Our approach from the beginning is to use warnings/errors. May be it could be > more user friendly with decorations but it is not a topic for now. In my opinion, we should conform with how the other launch configuration tabs work - and they display messages in the top dialog area. > >Is this possible? I think it would be useful, especially if it were a clickable > link. > To print the application URL into the console is possible but the console > doesn't make the links clickable. > When the user disabled the "open in browser" option then IMO a clickable link > doesn't make any sense. Are you sure that it is (without hacks) possible to print to the console? We would have to grab the console of the new process that we just started. Plus, I think it would be disturbing as the console belongs to the launched process, not to the launching process.
(In reply to comment #9) > Are you sure that it is (without hacks) possible to print to the console? We > would have to grab the console of the new process that we just started. Hmm, you are right. I just forgot this. We don't have access to the new process. Therefore, it will be a hack to print into the console.
