Jim Kring
-
Posts
2,203 -
Joined
-
Last visited
-
Days Won
106
Posts posted by Jim Kring
-
-
Those a great ideas, Patrick.
One important point of clarification:
The VIPC Editor does not provide any indication about what is currently installed. It only shows package states relative to the list of packages in the configuration.
Also, about the current design/process:
We're working to improve the workflows and visualization of information in the Resources tree. We still have a ways to go. Until then, we want to make opening the VIPC "easy enough" (it's only a right-click menu away), but we're intentionally not putting the "VIPC" button on the project sidebar, because we want to encourage people to use the Resources tree as the first place they go to manage the project's package dependencies.
-
1
-
-
Hi Patrick,
This is a "rough area" that we're still figuring out the best way to visualize that there's a different version installed and whether it's in the VIPC. So, for now, we's showing both package versions.
There are a couple ways to work this out, currently.
In the Resources Tree
1) Right-click on 1.6 (which is in the VIPC but installed) and choose "Remove from VIPC"
2) Right-click on 1.8 (which is installed by not in the VIPC) and choose "Add to VIPC"
In the VIPC Editor
1) Right click on (A) the Resources navbar button, (B) the Resources node in the tree-view, or (C) the lv-venv node in the tree-view and choose "Open VIPC File" - this will open the VIPC in the VIPC Editor Window.
2) Right-click on 1.6 and choose "Change to Version >> 1.8" or another version of your choosing.
Please let me know if these answered your question and whether they work for you, or if you have any additional thoughts/questions about this workflow.
-
1
-
-
8 minutes ago, p.irvin@levylab.org said:
Yes I also use alt-tab a lot, and that is the correct answer to "quickest way", but alt-tab doesn't help me prove my point
-
Point taken. The screenshot you posted shows that it’s not obvious where the project can be found.
Note: The dragon project window is currently running inside of the “VI Package Manager.exe” process, so the Dragon/LabVIEW project will actually show up in the taskbar under the VIPM logo/button.
This additional indirection is not helpful to users trying to find the project in the taskbar. We may soon split the dragon project out into its own process, which would address that point, yet it would still create the core issue in that the dragon/labview project does not show up under the “LabVIEW” taskbar item/icon (which will be missing entirely if there are no VIs open).
I tend to use Alt+Tab reflexively (it’s much more obvious to see the project window that way). I also do use the taskbar quite a bit, too, and so I also do experience the problem you’ve discovered.
-
Got it! Thanks for confirming/clarifying 😊
-
Hi Patrick,
This is a "known behavior".
I agree it's unexpected and we're considering options.
The technical reason this happens is that the project window (which is a window of the LabVIEW.exe process) becomes a child of Dragon and so Windows removes it from the taskbar.
Aside from it feeling "weird", has it hindered your workflow?
-
Ah, OK. So, you're finding that you move from Dragon/LabVIEW over to the Source Code Control client (e.g. GitHub Desktop) in order to do various development SCC tasks like Commit/Push/Pull/etc. So, you'd like to make it faster/easier to switch over from within Dragon/LabVIEW to performing those SCC operations in the client. Does that sum it up?
Related Question: Do you ever find yourself ever needing to jump over to the GitHub (or other website) project/repository page for performing development tasks?
-
That's a good idea, Patrick.
Moving forward: We're hoping to reach a level of usability (that we haven't totally reached yet) with Dragon such that the VIPM Main UI isn't needed.
Please let us know when you find yourself needing to go into VIPM Main UI (instead of using the features in the Dragon project environment), and we'll work on addressing/streamlining those use cases.
-
Thanks for reporting this. It should be fixed in the next build >= 2718.
-
Thanks Patrick. This will be fixed in the next build.
-
Thanks Patrick. This will be fixed in the next build.
-
Patrick, this is a great idea and you've identified a common problem: user double-clicks on a project and it opens in the wrong version of LabVIEW.
I can see how putting some smarts into the middle of this would be a huge help for users.
-
Hi Patrick,
Great idea!
I’d like to learn a little bit more about what you’re thinking. Can you explain more about the what project tasks/work you’re trying to accomplish when you’d click on that button?
ps - The screenshot of m your post didn’t seem to come through.
thanks,
-
Hi @Mathilde (CC: @Francois Normandin)
Thanks for your interest in code coverage with Caraya.
There's not currently a built-in feature for doing code coverage in CaraYA. Do you have thoughts on how you would want to calculate coverage?
I've implemented some simple coverage tools in projects by using naming conventions for my tests and enforcing that each public member of a library has a test associated with it.
-
Thanks for reporting this! Will check it out and report back soon.
-
Confirmed. This will be fixed in the next build.
-
To add further clarification:
If the project is not using a virtual environment, then any required packages (per the VIPC) will be installed into the global environment
-
1
-
-
Yes, I can see how it would be useful to “remember” which packages are in the lv-venv before deleting it, so that the can be installed globally, if needed.
The user can do this themselves by adding the packages to the VIPC before deleting the lv-venv.
Then the packages will still show as required and Dragon will suggest installing them into the global environment.
> Based on this thread https://forums.vipm.io/topic/3670-display-list-of-missing-required-packages/ as per now Dragon "cares" just about packages installed locally, isn't it?
Not exactly. What I meant was: if a project uses an lv-venv, then dragon will assume it should install any required packages (as defined in the VIPC) into the lv-venv. There’s no way, currently, to specify that some of the required packages should be installed into the global environment and others into the lv-venv.
Eventually, we may have the package flagged as requiring the global environment, and that’s how dragon would know a required package should be installed globally and not in the lv-venv.
For now, if a project uses an lv-venv, then the user will have to keep track of which required packages need to be installed globally.
-
1
-
-
Thanks for reporting this issue. I think drag & drop within the tree got enabled accidentally during some experimentation, but we intended for this to be disabled. So, for now, I think we're going to disable it again (so users cannot drag & drop items in the tree).
Eventually, this could be a nice feature for moving packages from the global to virtual environment, yet there are other ways to achieve that use case and I don't think we want to prioritize drag & drop within the tree, at this time.
Please let me know if that thinking makes sense.
-
Here's what we're considering:
-
1
-
-
It looks like this will be fixed in the next build >=2717
-
Thanks for posting about this use case and concerns -- you're right about how things currently work and how this can cause issues.
One possible solution would be to warn the user that deselect "Install Packages Under Dragon Project Folder" checkbox will delete the virtual environment (lv-venv) folder. If Dragon did that, then there's no way that the lv-venv files get left behind and create confusion for the user. My gut instinct is that this would be the best option, because there's no good reason to keep the lv-venv folder around after the user has chosen not to use it.
An additional consideration is that if a user has already been using an lv-venv folder and their project VIs are linked to the lv-venv VIs, then they will need to relink to the package VIs in the global environment after re-installing the packages globally (which were previously in the lv-venv).
Do you have any thoughts about this approach of just deleting the lv-venv (after warning the user) if the user unselects the checkbox to "Install Packages Under Dragon Project Folder"?
-
Thanks for reporting this. We've seen it happen, too, and will see if we can fix the issue.
-
That's a good point Mariano. Right now, Dragon assumes that anything in the VIPC should get installed into the virtual environment -- this is an area of use case and feature investigation.
Would you want to be able to specify in Dragon that specific packages should be installed globally vs in the lv-venv? Ideally, the user should not need to worry about such things, yet at the moment it is a consideration the user must make.
VIPM 2020 doesn't start
in VI Package Manager (VIPM)
Posted
Ah, OK. Thanks @Sam Grayson.
It's helpful to know that the issue may have something to do with .NET.