This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 251719 - [Launchers] project properties, gravity and run commands
Summary: [Launchers] project properties, gravity and run commands
Status: NEW
Alias: None
Product: cnd
Classification: Unclassified
Component: Project (show other bugs)
Version: 8.1
Hardware: All All
: P3 normal (vote)
Assignee: ilia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-08 14:59 UTC by tbrunhoff
Modified: 2016-04-27 08:53 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
a not-wide-enought-window screenshot (48.01 KB, image/png)
2015-04-08 14:59 UTC, tbrunhoff
Details
runPullDown.tiff (1.19 MB, image/tiff)
2015-04-12 21:57 UTC, tbrunhoff
Details
editConfigurations.tiff (460.12 KB, image/tiff)
2015-04-12 21:58 UTC, tbrunhoff
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tbrunhoff 2015-04-08 14:59:09 UTC
Created attachment 153096 [details]
a not-wide-enought-window screenshot

This has two related parts: the dialog layout and, in particular, the run commands. This is in reference to CND projects (if that makes a difference).

Nearly all of the categories in the project properties presents name/value pairs with equal gravity for the UI layout. IIRC, this used to be something that could be adjusted by dragging the divider, but this is not available anymore. This presents two problems for the values in the run command:

1. the values in the "Run Command" can easily be wider than the text edit widget used to display them. The window itself can be resized, but even on my 2560x1440 display it is absurd, with the label getting half of the window. This would be slightly better if the divider could be moved, but would make much more sense if the label column got a fixed width wide enough to contain the widest label. Please see the attached screen shot that is still not wide enough. Note also that the dropdown for past run commands is also limited to the width of that text edit widget.

2. The history of run commands is a very nice feature, but it lacks maintainability. Individual lines can be edited after one is selected, but the user cannot control how many or which commands in the history are kept. For comparison, look at how Jetbrains Pycharm allows command lines to be easily created, maintained, and named.
Comment 1 tbrunhoff 2015-04-08 15:00:03 UTC
Product Version: NetBeans IDE Dev (Build 201503240001)
Updates: Updates available
Java: 1.7.0_45; Java HotSpot(TM) Client VM 24.45-b08
Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18
System: Linux version 3.14.27-100.fc19.x86_64 running on i386; UTF-8; en_US (nb)
User directory: /home/toddb/.netbeans/dev
Cache directory: /home/toddb/.cache/netbeans/dev
Comment 2 Alexander Simon 2015-04-08 15:34:04 UTC
Hi Tod,

Could you explain why you do not use launchers?
Launchers are more convenient start/maintain different command lines. 
If you do not know this feature, open file nbproject/private/launcher.properties


Alexander
Comment 3 tbrunhoff 2015-04-08 17:29:07 UTC
Never knew about launchers. Perhaps I missed its introduction. Keep in mind I've been using NB since 2008!

There are a couple of good things about launchers: it provides a way to record and maintain command lines permanently, and it is relatively easy to run/debug. Its a good thing that the ide watches the file and updates the menu. For this reason, I'll certainly start using them.

However...
- this feature is a big step backwards for an ide. Seriously? Text editing on a free-form syntax.
- Neither debug nor run do the build first, even though project properties are marked to do so. That's a huge miss!
- there's confusion between the launcher1.runDir and the location of OUTPUT_PATH. If I specifiy launcher1.runDir=.. the ide complains that "/home/toddb/src/srcapp/omneon/codecs/obj.linux64/cli-codec does not exist or is not an executable." Note that it has the correct full path name, but it can't find it. common.rundir does the same.
- why aren't launchers and the run/debug dialog integrated? They do the same thing, but launchers provides more control and the dialog lacks control and UI ease.
- There's no way to specify a linkage between the "Debug Main Project" keystroke and one of the launchers.
- there appears to be no line continuation in launchers to handle really long command lines, so I cannot do something like:
    launcher2.displayName="encode 100 generated frames 1080p avci100"
    launcher2.runCommand="${OUTPUT_PATH}" \
                         -debug graphDebug=summary \
                         -debug threadGroupDebug=thread \
                         generator:type=grid:n=100:width=1920:height=1080:fps=59.94p:fourcc=W210 \
                         encoder:type=avc:avcpreset=rp2027:bitrate=200000000:ncpu=4 \
                          io:type=output:path=grid.avc

Fix these bugs and integrate with the dialog, and I think you will have something useful.
Comment 4 tbrunhoff 2015-04-08 17:37:32 UTC
- the order presented in the run/debug menu is not the same as either the order of the launchers in the file or the number specified in the launcher name.  I have launcher1, launcher2, launcher1 in that order in the file.  After adding launcher3, the menu is presented as 3, 1, 2.
Comment 5 tbrunhoff 2015-04-08 17:40:43 UTC
- the template launcher.properties file misspells "macroes". Its "macros".
Comment 6 Vladimir Voskresensky 2015-04-08 17:42:03 UTC
(In reply to tbrunhoff from comment #3)
> - there appears to be no line continuation in launchers to handle really
> long command lines, so I cannot do something like:
>     launcher2.displayName="encode 100 generated frames 1080p avci100"
>     launcher2.runCommand="${OUTPUT_PATH}" \
>                          -debug graphDebug=summary \
>                          -debug threadGroupDebug=thread \
>                         
> generator:type=grid:n=100:width=1920:height=1080:fps=59.94p:fourcc=W210 \
>                         
> encoder:type=avc:avcpreset=rp2027:bitrate=200000000:ncpu=4 \
>                           io:type=output:path=grid.avc
> 
Todd, I use line continuation and it works fine for me in launchers.
BUT! Make sure you have line break directly after "\" and no spaces!
i.e. you can use View->Show non-printable symbols
Comment 7 tbrunhoff 2015-04-08 18:00:05 UTC
> I use line continuation and it works fine for me

Right! I think I saw this when I used rundir and confused the cause with the symptom. Thanks.
Comment 8 Vladimir Voskresensky 2015-04-09 10:30:40 UTC
(In reply to tbrunhoff from comment #5)
> - the template launcher.properties file misspells "macroes". Its "macros".
Thanks!
Comment 9 Vladimir Voskresensky 2015-04-09 10:40:50 UTC
(In reply to tbrunhoff from comment #3)
> Never knew about launchers. Perhaps I missed its introduction. Keep in mind
> I've been using NB since 2008!
> 
> There are a couple of good things about launchers: it provides a way to
> record and maintain command lines permanently, and it is relatively easy to
> run/debug. Its a good thing that the ide watches the file and updates the
> menu. For this reason, I'll certainly start using them.
> 
> However...
> - this feature is a big step backwards for an ide. Seriously? Text editing
> on a free-form syntax.
> - Neither debug nor run do the build first, even though project properties
> are marked to do so. That's a huge miss!
> - there's confusion between the launcher1.runDir and the location of
> OUTPUT_PATH. If I specifiy launcher1.runDir=.. the ide complains that
> "/home/toddb/src/srcapp/omneon/codecs/obj.linux64/cli-codec does not exist
> or is not an executable." Note that it has the correct full path name, but
> it can't find it. common.rundir does the same.
> - why aren't launchers and the run/debug dialog integrated? They do the same
> thing, but launchers provides more control and the dialog lacks control and
> UI ease.
> - There's no way to specify a linkage between the "Debug Main Project"
> keystroke and one of the launchers.
For this I use "Run history" - have a look at small arrow rightward from big Run button on toolbar. It has history of run launchers.
The same for big Debug button and Debug history of Launchers :-)
Comment 10 Vladimir Voskresensky 2015-04-09 10:44:17 UTC
(In reply to tbrunhoff from comment #3)
> 
> However...
> - this feature is a big step backwards for an ide. Seriously? Text editing
> on a free-form syntax.
It is my fault :-)
I hardly needed run/debug with different very complex list of parameters.
Managing/switching them in Run panel was inconvenient.
NB was in UI frozen state already, so I could have only text based management.

Btw, launcher.properties file can be put as nbproject/launcher.properties and checked-in into repository.
The nbproject/private/launcher.properties overrides settings from global one.
I use this feature as well :-)
Comment 11 Vladimir Voskresensky 2015-04-09 10:50:23 UTC
Btw, when I see bugs with paths used in public nbproject/launcher.properties I just put them as absolute values in per-user nbproject/private/launcher.properties, so it fixes most cases.

And you can do the same with your runDir.
Btw, if your runDir is the same for all your launchers, just use "common" feature:
common.runDir=your-path
Comment 12 tbrunhoff 2015-04-09 18:10:38 UTC
> For this I use "Run history" - have a look at small arrow rightward from big 
> Run button on toolbar. It has history of run launchers.

Not sure which issue you are referring to. This is another way to get at the launchers. Which issue do you think this "fixes"?
Comment 13 tbrunhoff 2015-04-09 18:14:24 UTC
> NB was in UI frozen state already, so I could have only text based management.

Too bad.  This would have been a nice detail. IMO, editing the command line in the dialog box is painful (right-click on project, select properties, click on run, click on the ... button, then edit). I like the launchers... they just need to be better integrated.

I'd say you have a foothold now. Perhaps you can fix things up!
Comment 14 tbrunhoff 2015-04-09 18:22:25 UTC
> when I see bugs with paths used in public nbproject/launcher.properties I just 
> put them as absolute values in per-user nbproject/private/launcher.properties, 
> so it fixes most cases.
This won't work in my environment. Right now I have 25 build trees, all of the same code.  Some are different releases, different branches, and some are identical revisions with different changes in them. So an absolute path would work for whatever I am working on for the moment, but the idea is to make them reusable over time.

I can get around it by using relative paths in the arguments, but sometimes the effect of the command is dependent on the (relative) directory from which it is run, particularly in the case of validation within the same build tree. Please fix this.
Comment 15 Vladimir Voskresensky 2015-04-10 13:13:24 UTC
(In reply to tbrunhoff from comment #12)
> > For this I use "Run history" - have a look at small arrow rightward from big 
> > Run button on toolbar. It has history of run launchers.
> 
> Not sure which issue you are referring to. This is another way to get at the
> launchers. Which issue do you think this "fixes"?
I hoped it can help for a while as workaround to your comment:
"- There's no way to specify a linkage between the "Debug Main Project" keystroke and one of the launchers."
I use from project context menu Run->Name Of Launcher then from project context menu Debug->Name Of Launcher.
Then if I switch to another launcher I can quickly reach the previous from toolbar's history for global Run/Debug
Comment 16 Vladimir Voskresensky 2015-04-10 13:17:38 UTC
(In reply to tbrunhoff from comment #13)
> > NB was in UI frozen state already, so I could have only text based management.
> 
> Too bad.  This would have been a nice detail. IMO, editing the command line
> in the dialog box is painful (right-click on project, select properties,
> click on run, click on the ... button, then edit). I like the launchers...
The same with me. Text file was so easy to manage and copy&paste launchers there to make modification that... it was enough for most launcher users :-)

> they just need to be better integrated.
> I'd say you have a foothold now. Perhaps you can fix things up!
You mentioned Pycharm. 
After all our discussions. Could you attach screen shots from it to demonstrate what you'd like to have in NB.
Comment 17 Vladimir Voskresensky 2015-04-10 13:21:04 UTC
(In reply to tbrunhoff from comment #14)
> I can get around it by using relative paths in the arguments, but sometimes
> the effect of the command is dependent on the (relative) directory from
> which it is run, particularly in the case of validation within the same
> build tree. Please fix this.
Can you clarify, please, on the examples of your files layout for i.e. 2 projects.
what if you use 
common.runDir=${PROJECT_DIR}/${OUTPUT_PATH}/../..
Comment 18 tbrunhoff 2015-04-12 21:55:46 UTC
> Could you attach screen shots from it to demonstrate what you'd like to have in NB.

Yes, and thanks for asking. These shots are taken from my mac. Pycharm is written in Java, so the UI on a mac vs linux is the same parallel as for NB. The project is a python CLI interface to a sqlAlchemy database.

'runPullDown.tiff' is a menu next to the run button, which can be used to select the run configuration. This is in contrast to NB's config pulldown for the higher level config, which includes the last selected run, the make args, source files, etc. Java is similar to Python in that there aren't make commands, preprocessor defines, includes, etc. NB is much more influences by java and command-line args for java are not nearly as common as command-line args for C and C++... and python. With that said, Pycharm makes it easy to select the run configuration, and it is harder to change things like python packages, the selected interpreter, etc.

NB now has the launcher pulldown, but it is missing the ability to configure the run, or see the currently selected run configuration.

From the menu shown in runPullDown.tiff, you can select 'edit configurations', which takes you directly to what is seen in editConfigurations.tiff. Note that, unlike NB, there is no additional navigation to change the command line.  This is what the run and debug config should be in NB. There is a 'copy' icon (third from the left, top of the window) where you can start with an existing run config.

I would think that a creation of a run/debug specific config would be useful for CND. I understand that it might not be quite as useful for java. If you had such a run/debug config, a merger of that with the launcher would make lots of sense. And given access to a launcher, you probably would not need a separate dialog for run vs debug, because it would be easier to accomplish with the new config.

I know you folks have to worry about the larger picture. So this is probably not as easy as I have described here.
Comment 19 tbrunhoff 2015-04-12 21:57:44 UTC
Created attachment 153146 [details]
runPullDown.tiff
Comment 20 tbrunhoff 2015-04-12 21:58:25 UTC
Created attachment 153147 [details]
editConfigurations.tiff
Comment 21 Vladimir Voskresensky 2015-04-13 14:26:13 UTC
Todd, thanks for the images. 
Btw, one more hint while we don't have UI for managing Launchers:
- to have quick access to "Edit Launchers" I added launcher.properties file to "Important Files" folder
Comment 22 Vladimir Voskresensky 2016-04-27 08:53:10 UTC
Todd, have a look at recently implemented https://netbeans.org/bugzilla/show_bug.cgi?id=258806.
Please, try it and if you have feedback there is still time to improve before release