Leaderboard

Hi All This thread has been created to blog about information relating to the OpenG 4.0 Release. It will contain what we did and why we choose to do it and anything else we find interesting. Please feel free to add in any comments or feedback about the release. I will just keep adding to this thread. Cheers Jonathon Green OpenG Developer

Dear OpenG and LAVA Communities, I’m happy to announce that the OpenG 4.0 release is now available for download. OpenG 4.0 is a synchronised release of all packages that form the OpenG Library: The release includes the following features: Fix to all outstanding bugs (at design time). Package sources upgraded to, and tested in, LabVIEW 2009. Packages now built using VIPM 2010. I will be posting more about this release in the near future. On behalf of Jim Kring and OpenG.org, thank you. Jonathon Green OpenG Developer Installation Open up VIPM 2010 and if not configured to do so press Check All Package Repositories for Available Packages, then choose one of the two options below: Install the OpenG Toolkit package - this package will configure your system to install all the latest packages as well as remove any non-Library packages no longer required (don’t worry it won’t remove any VIs you are using). This is recommended for new or basic users. Manual installation - upgrade required packages on a package-per-package basis. Note: OpenG Builder is not part of the OpenG Toolkit and therefore will need to be manually upgraded (if required).

Upgrading to VIPM 2010 This feature does not have a direct benefit to end-users of OpenG - but its dear to my heart as we sure spend a lot of time working on it - I learnt to appreciate the time it takes to make edits to an SVN Repo over the web The driving force behind migrating from OpenG Package Builder (OGPB) to VIPM 2010 as the primary package building application was that package building is now available in VIPM 2010 Community Edition i.e. it is free! This is huge in itself, but it now means that the OpenG package building process is a lot easier and will benefit from new features over time. Don’t get me wrong, OGPB is a great product, has its use cases and OpenG currently still builds select packages using it, but this will make it easier for Developers join up and help out by using a familiar environment. The OpenG projects' disk hierarchy was changed to better support the migration from OGPB to VIPM 2010 (where a project forms an individual release e.g. OpenG Application Control Library). A lot of thought was given to this new layout so that the disk hierarchy can be scaled in the future and would also be easy to navigate for new Developers. Additionally, older OGPB etc... support files have been cleaned-up and/or removed. On a side note, changing from OGPB (which have .ogp file extensions) to VIPM (which have .vip file extensions) packages creates no problems as VIPM considers this an upgrade (as long as the file name has not changed and the version has increased) - this was a very important point in upgrading the packages. So in summary, the transition was very manual, but its all done now, and adding to it is as simple as, so it was well worth the effort. Check out an example of how we upgraded a project here on the OpenG Wiki.

We Fixed Bugs Too! At the time of design we fixed all outstanding bugs in the Tracker for all packages. We also made use of another new feature of VIPM 2010 - Release Notes. Release Notes allows you can check out the upgrade in detail when you add the package in VIPM or when you popup and select Get Info on a package in the main window. It includes the ability to easily track fixes via their SourceForge IDs - if you file OpenG bug reports this is similar to getting an NI CAR#.

All The Packages Below is a list of all packages that have been updated that are part of the OpenG 4.0 Release: OpenG Application Control Library OpenG Array Library OpenG Boolean Library OpenG Buttons Library OpenG Comparison Library OpenG Dictionary Library OpenG Error Library OpenG File Library OpenG LabVIEW Data Library OpenG LabVIEW ZIP Library OpenG Large File Library OpenG MD5 Digest Library OpenG Message Queue Library OpenG Numeric Library OpenG Picture Library OpenG Port IO Library OpenG String Library OpenG Time Library OpenG Variant Configuration File Library OpenG Builder OpenG Toolkit Note that OpenG LabVIEW ZIP Library, OpenG Port IO Library and OpenG Builder are the only packages not upgraded to and tested with LabVIEW 2009 as part of this release. There are a few reasons for this relevant to each package therefore, the sources for these projects remain as per their previous release. However, the palette location was required to be changed in order to be consistent with the OpenG 4.0 release. As a result OpenG LabVIEW ZIP Library (oglib_lvzip) and OpenG Port IO Library (oglib_portio) versions' were both bumped up to 4.0. OpenG Builder (ogrsc_builder) - not considered part of the OpenG Toolkit - was incremented using the Fix version number only. It was also decided that some of the packages would be merged. These were mainly palette only packages - don't worry i.e. this does not relink VIs or anything like that! The following packages are redundant and have been merged as follows: ogmnu_appcontrol_plus is now available as a sub-palette in OpenG Application Control Library ogmnu_classic_sync is now available as a sub-palette in OpenG Message Queue Library nilib_rectangle is now available as a sub-palette in OpenG Picture Library As mentioned in a previous post, ogsrc_dynamicpalette is also redundant. One package was renamed in order for automatically generated palettes to be in alphabetically order - ogctl_buttons was renamed to oglib_buttons.

Using VIPM 2010's Custom Category Feature One of the new features of VIPM 2010 is the Custom Category which, is an easy way to provide a top level category palette for a Toolkit (not just OpenG’s – but your own too!). OpenG decided to use this awesome new feature however, it creates a consequence that I need to point out in case you come across it and think its a bug: When an OpenG 4.0 package and an older package are installed together, two palettes will appear in the Functions (or Controls) palette. Which would look something like this: Being a neat freak this one annoys me but of course this does not create any functional issues - more aesthetic or organisational ones. This is why the OpenG 4.0 release was synchronised. The benefit of releasing Libraries in individual packages is well known however, to minimise this annoyance we released them all at the same time (assuming a lot of users would upgrade at once). This issue was identified early on in the OpenG 4.0 process and we decided that we wanted to incorporate the Custom Category feature and that it would be better to handle it now, as we upgraded to VIPM 2010, rather than later. Previously, the ogsrc_dynamicpalette.ogp package was a dependency of all OpenG Library packages and handled installing all menus etc... Now, each package will create the top level category palette if it does not exist - or replace it if newer, making the ogsrc_dynamicpalette.ogp package redundant (with respect to OpenG 4.0). Anyways, I really like the Custom Category feature

Upgrading to LabVIEW 2009 We decided to upgrade the sources to LabVIEW 2009 in an effort to keep OpenG current. The great thing about packages is that if OpenG users are programming in an earlier LabVIEW version then the newest release, all previous releases will still work. Upgrading allows OpenG to take advantage of new features as well as to unit test in a later version to increase quality and identify any issues early. This is a standard progression as OpenG 3.0 migrated sources from 6.1 to 8.2 for the same reasons.

Thanks for the kind words Jim, it was a pleasure Hi Greg, this (LabVIEW ZIP Library) is a known issue, but we have now documented it.