Mellroth Posted October 28, 2009 Report Share Posted October 28, 2009 I don't have time at the moment to add a topic for each feature/idea so I'll just add them as I have them listed. Since I'm completely new to VIPM, I've probably missed how things should be done. /J General: * Resent builds list bug? If I build a package from C:\labview-modules\A and then move the source folder so I build from C:\svn\modules\A. If I then build the package from the new folder the old build will still be seen in the "Recent" menu, but there is no way to distinguish my two builds from the different A folders. I would like to see the complete path if a build name exists twice, and I'd also like to be able to remove items from the recent list. * In the advanced settings, there is a number of settings that are likely to be the same for all packages I'm building. As far I can tell these settings always defaults to VIPM defaults, some of the settings I'm talking about are; - Namespace settings - Build output folder (if changed to a central storage location) - installation locations - Descriptions (e.g. the URL field defaults to "http://jkisoft.com/vipm/professional/", where I'd like to see my companys URL instead by default) * I haven't found a way to increase the build number in the package name, so why is this number in the package name. If it is unused it should be stated somewhere. * Currently VIPM skips folders starting with '_', but this is something that I'd expect to be a user setting. I might want to temporarily skip a folder without renaming it to '_folder name'. My suggestion would be to let the user select the name pattern to skip, and be able to skip more than one type of folder and even single files. * In the main view I'd like to be able to see the source files in "file view", much like the project explorer do in LabVIEW. This view would allow me as a user to quickly locate any VIs outside of my source folder, and could also be used to set include/exclude on every file/folder. Build: * If I forget to change some setting during the build, I'll have to rebuild the whole package again. It should be enough to edit/change the built package directly, to save me the time it takes to build all VIs again. Perhaps with an automatic increase of the build number. * I'd like to be able to save a build to a new location, i.e. make a copy of all the build settings and not start fresh all the time * I really miss a setting to manually exclude a number of VIs/CTLs. And VIs calling missing VIs/CTLs should generate a warning/error, not just result in a failed build. Palettes: * Missing possibility to define icon for a group of modules, e.g. I want to add a subpalette to user.lib to store my built modules, this subpalette gets the defaultpalette icon. * I don't understand why a changed VI package name is not enforced on the palette directly (or at least have this as an option), as it is right now I'll have to right click on the icon and select rename. This is a bit strange since both the VI package name and the palette name is taken directly from the folder name, and that this name is enforced on the icon. * I'd like to be able to put a VI or ctl in more than one location on the palettes, e.g. in both main palette as well in a subpalette * When updating a package to a new version, new VIs might have been added or removed from the source folder. Today it seems like we have to rebuild our palettes manually, or add new elements one by one. I'd really like to see a synch operation, i.e. right click on palette and select resynch, this launches a dialog where removed and added items are displayed. It is then up to the user where to put the new methods in the correct palette location. * Why not support adding a *.mnu file directly? In my case I have the mnu files prepared and ready to use, but I still have to redo them in VIPM. Error handling: * Build log, when a build fails it would be very nice to have a build log, specifying exactly at what step (and the causing VI/CTL) the build failed * Possibility to exclude failing VIs would be nice (with a warning) * During my first days of testing I have seen a lot of different failures due to (and this is the main reason for my Error handling request): - linking outside source folder - diagram disable structure holding non executable code causes the build to fail - Using SinWave PtByPt Link to comment Share on other sites More sharing options...
Jim Kring Posted October 29, 2009 Report Share Posted October 29, 2009 Thanks for all the great suggestions and issue report! I wanted to let you know that I've read them and agree with your point. I'll respond, as soon as I can, in more detail on each of your feedback items. Thanks! Link to comment Share on other sites More sharing options...
Jim Kring Posted October 31, 2009 Report Share Posted October 31, 2009 > I don't have time at the moment to add a topic for each feature/idea so I'll just add them as I have them listed. No problem. And, thanks for your patience - that was a long list > Since I'm completely new to VIPM, I've probably missed how things should be done. Possibly, but in each case, I'm sure there are ways that we can improve the software to make things easier or more obvious to users. > Resent builds list bug? If I build a package from C:\labview-modules\A and then move the source folder so I build from C:\svn\modules\A. If I then build the package from the new folder the old build will still be seen in the "Recent" menu, but there is no way to distinguish my two builds from the different A folders. I would like to see the complete path if a build name exists twice, and I'd also like to be able to remove items from the recent list. I agree with you and have found this annoying myself (I use VIPM a lot at JKI). I've raised the question with our team (about how we can improve this) -- I'll report back here, once we've hashed it out. In the advanced settings, there is a number of settings that are likely to be the same for all packages I'm building. As far I can tell these settings always defaults to VIPM defaults, some of the settings I'm talking about are; - Namespace settings - Build output folder (if changed to a central storage location) - installation locations - Descriptions (e.g. the URL field defaults to "http://jkisoft.com/vipm/professional/", where I'd like to see my companys URL instead by default) You're not the first person to mention this, and I experience this one, too. The pain points come in two different ways: 1) when you're creating a new package 2) when you want to update common settings for multiple packages. Right now, you can address use case #1 by creating a "template" VI Package project. In fact, this is useful for organizing all of your common files like any documentation, unit tests, project file, etc. > I haven't found a way to increase the build number in the package name, so why is this number in the package name. If it is unused it should be stated somewhere. Can you please clarify this a little? Here's a screenshot to show how we use all of the fields, including the package version: > Currently VIPM skips folders starting with '_', but this is something that I'd expect to be a user setting. I might want to temporarily skip a folder without renaming it to '_folder name'. My suggestion would be to let the user select the name pattern to skip, and be able to skip more than one type of folder and even single files. I'll pass this feedback along to the team. Basically, we wanted to make it easier to create new palettes for people converting existing libraries (stored under user.lib) to VI Packages. Note, you can manually add a folder (such as one that was skipped) to the palettes. Just drag and drop the folder from Windows File Explorer onto the palette in the VI Package Builder palette editor. > In the main view I'd like to be able to see the source files in "file view", much like the project explorer do in LabVIEW. This view would allow me as a user to quickly locate any VIs outside of my source folder, and could also be used to set include/exclude on every file/folder. Yes, this would be nice. We've tried to avoid creating too many features that reproduce functionality available in LabVIEW. Actually, we recommend that you create a LabVIEW Project (*.lvproj) file for your VI Package Source VIs. You can then use all the features of the LabVIEW Project Explorer (like the Files View) to see if you have files outside your project root. > If I forget to change some setting during the build, I'll have to rebuild the whole package again. It should be enough to edit/change the built package directly, to save me the time it takes to build all VIs again. Perhaps with an automatic increase of the build number. Yes, it would be nice if the build were faster in cases where it could be. I'm thinking about this, and I can see how the implementation could be very tricky, in caching the build output and reusing cached VIs when possible. I'll pass this suggestion along to the VIPM team. > I'd like to be able to save a build to a new location, i.e. make a copy of all the build settings and not start fresh all the time For this use case, we recommend copying the entire VI Package Source Folder -- you can think of it as your Project. Or are you saying that you want to create a new VI Package Source Folder with only the build setting copied, but not the VIs? > I really miss a setting to manually exclude a number of VIs/CTLs. Yes, this would be very useful, and we're working on something that should make this possible. > And VIs calling missing VIs/CTLs should generate a warning/error, not just result in a failed build. Yes, I agree. We need to improve the displayed message. > Palettes: [...] > [...] > Error handling: > [...] I'll post again with my thoughts on your Pallets and Error handling feedback. I've got to run, now, but I wanted to respond to some of your feedback, as soon as I could. Thanks, -Jim Link to comment Share on other sites More sharing options...
Mellroth Posted November 3, 2009 Author Report Share Posted November 3, 2009 ...that was a long list Sorry about that. I'll try to hide my lack of understanding better, by keeping my posts small and spread out over time ...The pain points come in two different ways:1) when you're creating a new package 2) when you want to update common settings for multiple packages. Right now, you can address use case #1 by creating a "template" VI Package project. In fact, this is useful for organizing all of your common files like any documentation, unit tests, project file, etc. By "template", do you mean an "empty" source folder just containing your build specification, and all common files. I looked in the documentation to find such a feature, but couldn't find any mention of it. And how can you include documentation files in the build? > I haven't found a way to increase the build number in the package name, so why is this number in the package name. If it is unused it should be stated somewhere.Can you please clarify this a little? Here's a screenshot to show how we use all of the fields, including the package version: I meant that after the version number there is an additional build number, that is out of my control. This number is listed in VIPM in the "Release" column. > I'd like to be able to save a build to a new location, i.e. make a copy of all the build settings and not start fresh all the timeFor this use case, we recommend copying the entire VI Package Source Folder -- you can think of it as your Project. Or are you saying that you want to create a new VI Package Source Folder with only the build setting copied, but not the VIs? Just want to copy the build settings. Thanks for all your help. /J Link to comment Share on other sites More sharing options...
Jim Kring Posted November 4, 2009 Report Share Posted November 4, 2009 > Sorry about that. I'll try to hide my lack of understanding better, by keeping my posts small and spread out over time Don't worry about it -- I just feel bad when I can't keep up with you (and respond to all your feedback, at once) > By "template", do you mean an "empty" source folder just containing your build specification, and all common files. I looked in the documentation to find such a feature, but couldn't find any mention of it. I wasn't referring to a VIPM feature, per se. What I meant is that you can create a VI Package Source Folder and use it as a "template" by manually copying it when you want to start a new VI Package project. > And how can you include documentation files in the build? We don't have any built-in features (yet) for including documentation files. However, you can create a post-build hook VI (see here and here) to add documentation files to your VI Package. > I meant that after the version number there is an additional build number, that is out of my control. This number is listed in VIPM in the "Release" column. Ah, I see what you mean. This is the package "revision" number. The idea is that this number can be rev'ed when the package contents don't change, only the package attributes change. This isn't a feature that we yet support in VIPM's package builder. > Just want to copy the build settings. Ya, that's what I figured. Hopefully the technique of (manually) creating and copying a "template" VI Package Source Folder will work for the time being. > Thanks for all your help. Sure, no problem. Thanks for the great feedback. Link to comment Share on other sites More sharing options...
Jim Kring Posted November 4, 2009 Report Share Posted November 4, 2009 OK, picking up where I left off... Palettes: > Missing possibility to define icon for a group of modules, e.g. I want to add a subpalette to user.lib to store my built modules, this subpalette gets the defaultpalette icon. I need some clarification, here. Are you saying that you want to create a root-level palette entry like "OpenG" and "JKI Toolkits" and have all your packages install their packages, under it? > I don't understand why a changed VI package name is not enforced on the palette directly (or at least have this as an option), as it is right now I'll have to right click on the icon and select rename. This is a bit strange since both the VI package name and the palette name is taken directly from the folder name, and that this name is enforced on the icon. Right now, the palette generation is automatic only when you initially create the package/palette and when you add new subpalettes. We could probably keep track of which ones were auto-generated (not edited/customized) and regenerate them -- I think that's what you're suggesting. Great idea! > I'd like to be able to put a VI or ctl in more than one location on the palettes, e.g. in both main palette as well in a subpalette That should already work (I've done this before). Just add the VI or CTL to each palette on which you want it to appear. > When updating a package to a new version, new VIs might have been added or removed from the source folder. Today it seems like we have to rebuild our palettes manually, or add new elements one by one. I'd really like to see a synch operation, i.e. right click on palette and select resynch, this launches a dialog where removed and added items are displayed. It is then up to the user where to put the new methods in the correct palette location. This is a great idea. We've discussed (internally) having the ability to set a palette sync with folder contents. I can see how it would also be useful to have some dialog to help you sync. > Why not support adding a *.mnu file directly? In my case I have the mnu files prepared and ready to use, but I still have to redo them in VIPM. That's a good idea. I'll pass this along to the JKI team. Error handling: > Build log, when a build fails it would be very nice to have a build log, specifying exactly at what step (and the causing VI/CTL) the build failed I agree that this is important and it is on the roadmap. > Possibility to exclude failing VIs would be nice (with a warning) Agreed. > During my first days of testing I have seen a lot of different failures due to (and this is the main reason for my Error handling request): - linking outside source folder - diagram disable structure holding non executable code causes the build to fail - Using SinWave PtByPt Yes, I'll work with you on this in the other thread. Thanks, Link to comment Share on other sites More sharing options...
Mellroth Posted November 5, 2009 Author Report Share Posted November 5, 2009 Are you saying that you want to create a root-level palette entry like "OpenG" and "JKI Toolkits" and have all your packages install their packages, under it? Yes please! > I don't understand why a changed VI package name is not enforced on the palette directly (or at least have this as an option), as it is right now I'll have to right click on the icon and select rename. This is a bit strange since both the VI package name and the palette name is taken directly from the folder name, and that this name is enforced on the icon.Right now, the palette generation is automatic only when you initially create the package/palette and when you add new subpalettes. We could probably keep track of which ones were auto-generated (not edited/customized) and regenerate them -- I think that's what you're suggesting. Great idea! That is a great idea, but I meant that when you change the "VI Package Name" in the main window of VIPM, the name of the palette should update as well. At the moment I have to change the palette name by right clicking and selecting "Rename...". Both "Rename..." and "VI Package Name" seems to be able to automatically update the icon, and is therefore somehow linked. > I'd like to be able to put a VI or ctl in more than one location on the palettes, e.g. in both main palette as well in a subpalette That should already work (I've done this before). Just add the VI or CTL to each palette on which you want it to appear. Sorry, I meant by drag-n-drop. Ctrl-drag could copy icon from one palette to another. /J Link to comment Share on other sites More sharing options...
Jim Kring Posted November 5, 2009 Report Share Posted November 5, 2009 > Yes please! OK, you're not alone - I'll add you to the growing list of people who want this feature > That is a great idea, but I meant that when you change the "VI Package Name" in the main window of VIPM, the name of the palette should update as well. At the moment I have to change the palette name by right clicking and selecting "Rename...". Both "Rename..." and "VI Package Name" seems to be able to automatically update the icon, and is therefore somehow linked. Oh, I see what you mean. Yes, that would be nice. I'll pass this request along to the VIPM team. Sorry, I meant by drag-n-drop. Ctrl-drag could copy icon from one palette to another. This is a great idea, too. I'll pass it along to the team. [update: We have an internal tracking number for this feature request >> Case 9969: VIPB Palette Editor should allow copying palette items via Ctrl+Drag] Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.