> As far as I am aware, NI doesn't even know what they want to port over.
- this is exactly what concerns me (and, I'm sure, a lot of other engineers).
It's a pity that such a great programming language ("G") crippled by a 35-year old IDE with bitmapped graphics scaled up on a 4k screens.
It's probably not that bitmaps are used, but that 35 year old programming techniques are used. That means not enough decoupling, especially on the graphics department. Raw GDI is used everywhere, so refactoring will need everything to change.
With enough decoupling, replacing those bitmaps with vector graphics wouldn't be that hard.
Not to add more fuel to the fire, but... if a company doesnt seem to understand that the background of their logo should match the background of their webpage then I guess we cant expect it to understand that their IDE should be revised.
Well the times when Greg McK has kept us up to date with the internal matters of LV are definitely long gone. As a still enthusiastic user of LabVIEW, the one and only graphical power tool to program DAQ applications, I don't feel competent enough to comment on the overall internal structure of LV. However, I assume that a lot is due to the main choice of the underlaying fundament (the OS). Historically LV was first developed on the Classic MacOS in 1986 at a time when there was no alternative for a graphical programming language like LV. For a long time thereafter LV had to remain on bitmap graphics to stay compatible with Windows even though the MacOS switched to vector graphics pretty early on. In any case, to think about how LabVIEW shall be used in the long run is a difficult an therefore even more important challenge. It's my personal experience that there is nothing like LabVIEW when it comes to accurately interact with real world signals. In this respect I find cosmetic things like zoom possibilities a minor concern. After all if a BD becomes too cluttered you can always nest the code into a subVI which is a kind of the built in zoom LV always offered. The ultra high resolution screens we use now, make the display of LV code problematic. For this the zoom capability of the underlaying OS should be used for.
Just my 0.01CHF worth of a comment and no oil into the fire on this...
Still a very happy LabVIEW 2021 user on one of these slick M1 MBpros
For this the zoom capability of the underlaying OS should be used for.
Of course bitmaps could be scaled the same way by LabVIEW.
For a zoom in, vectors are not required. Often vectors just look better, especially for non integer zoom factors.
I would exchange all the zooming capabilities in the world for proper package and dependency management
because PPLs are a nightmare for me.
@LevK ha scritto:
It's really disappointing to see absolutely nothing from NXG ported to LabView in 2021, there isn't even a roadmap for future NXG features after 2021.
NI LabView team really needs a success in this one, but without sharing their vision on the future of LabView, - it might end up just like LabView NXG.
I told you in my previous post.
LV 2021 = HARD SKIP
LV 2022 = FIRST version with something "under the hood" implemented. Early adopter. SKIP
LV 2023 = "IF" everything goes well and NI didnt bankrupt, we can EVALUATE this version
LabVIEW can die honestly, it's not the end of the world.
We still have :
1) the NI hardware and their drivers in C/.NET
2) we have mature multiplaform languages (.NET and Python)
3) we have mature multiplatform IDES (Visual Studio, VSCode)
4) we have mature ecosystems (package managers, github, libraries, forum, etc...)
IF NI wants to stay engaged in software, it could sell libraries, like "Actor Framework", or powerfull framework/libraries used in this niche application (electronic testing / production / development).
There are companies that sells UI controls (DevExpress) for ages, or libraries for stocks charts, etc....
Another option is to focus on "specific software applications" like TestStand, or other applications that solve specific problem.
LabVIEW is becoming stale and not on par with 2021 technologies.
If this stale situation continues, LabVIEW will hinders many engineers careers, by putting them out of labour market.
Sorry, but truth hurts
Sorry, but truth hurts
The truth is that this is a possible future, but it's not the only possible future.
We have two ears and one mouth so that we can listen twice as much as we speak.