Jump to content

Jim Kring

JKI Team
  • Posts

    2,199
  • Joined

  • Last visited

  • Days Won

    105

Everything posted by Jim Kring

  1. 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.
  2. 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?
  3. 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?
  4. 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.
  5. Thanks for reporting this. It should be fixed in the next build >= 2718.
  6. Thanks Patrick. This will be fixed in the next build.
  7. 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.
  8. 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,
  9. 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.
  10. Thanks for reporting this! Will check it out and report back soon.
  11. 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
  12. 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.
  13. 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.
  14. It looks like this will be fixed in the next build >=2717
  15. 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"?
  16. Thanks for reporting this. We've seen it happen, too, and will see if we can fix the issue.
  17. 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.
  18. @kosist @Mariano Aristu Here is a possible solution: Please let us know if you have any other suggestions. Note: it will usually/ideally show the package's Display Name (instead of file_name).
  19. There are some really great ideas and observations in your post @kosist. Yes, this is something that we're thinking about and working on. In an ideal world, a user would activate a virtual environment and all the LabVIEW IDE extensions installed into the virtual environment would show up in the IDE. There are a variety of possible solutions and I think that none of them are 100% complete, due to the fact that LabVIEW extensions (right-click menus, project providers, tools menu) must be installed globally (based on how LabVIEW presently works). In the short term, I think that allowing flexibility to users (that allows installing into both the global and/or virtual environment) while at the same time providing some visibility and warnings around possible problems/conflicts will be most helpful as we figure out more automated/ideal solutions.
  20. Thanks for the great post with detailed steps to reproduce! I have a few thoughts about the situation you described: Dragon Should Probably Not Allow Installing Packages into Both Global and Virtual Environments First, I generally think Dragon should move in the direction of not allowing a package to be installed globally AND in the virtual environment, due to the conflicts and cross-linking that can happen. Right now, Dragon is allowing that in order to have flexibility until we work out all the details and more fully understand the various use cases. Caraya Should Probably Build JKI SM Into Itself (not expose it as a dependency to users) Second, I would like for Caraya to not depend on the JKI State Machine (so, perhaps it should build in the JKI State Machine as an internal dependency and not expose it to users) -- it's such a core utility, it's not actually a library that gets built into the end-user's distributable application, and it's probably better not to expose users to a dependency constraint. All that is to say: "Maybe eventually Caraya shouldn't require installing the JKI State Machine, so part of this problem might go away" Libraries and IDE Extensions Should Probably Be Split onto Separate Packages As you pointed out in this other topic, the JKI State Machine may eventually be split into two packages: One that contains the library code that the user will call directly in their applications (which will naturally be best installed into the lv-venv) and another that contains the LabVIEW IDE extensions: right-click menus, etc. (which will need to be installed globally). This eventuality we're considering doesn't directly follow from the example you posted about Caraya, yet I figured it was worth mentioning and we're giving it a bit of thought right now. This would possibly require package developers to be more aware of virtual environments and the need to split a package into two parts -- and, it would be nice if VIPM's package builder and/or VIPM/Dragon could help do this automatically. Again, we're thinking about the best ways to do this. Try Installing Caraya into the Virtual Environment It might be a good idea to install Caraya into your virtual environment. I think there may be a few quirks that don't work great like the Tools menu options, but for the most part, I think Caraya works well when installed into the lv-venv.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.