Menu
▾
▴
opengtoolkit-developers — OpenG Toolkit developers mailing list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(53) |
Nov
(66) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(5) |
Mar
(72) |
Apr
(15) |
May
|
Jun
|
Jul
(10) |
Aug
(2) |
Sep
(18) |
Oct
(2) |
Nov
|
Dec
(6) |
| 2005 |
Jan
(41) |
Feb
(28) |
Mar
(14) |
Apr
(18) |
May
(10) |
Jun
(6) |
Jul
(5) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|
From: Jim K. <ji...@ji...> - 2003-12-02 07:05:20
|
<http://sourceforge.net/projects/opengtoolkit/> -= oglib_appcontrol-2.1-1.ogp =- Changes from 2.0-2 --> 2.1-1 -------------------------------- 2003-12-01 [FIX] 'Mangle VI Name' window title no longer shows '__ogtk' |
|
From: Jim K. <ji...@ji...> - 2003-12-02 07:05:18
|
<https://sourceforge.net/projects/opengtoolkit/> -=3D all_packages-2.1.3 =3D- oglib_appcontrol-2.1-1 oglib_array-2.0-1 oglib_boolean-2.0-1 oglib_comparison-2.0-1 oglib_error-2.0-1 oglib_file-2.2-1 oglib_lvdata-2.1-1 oglib_lvzip-2.0-2 oglib_msgqueue-2.0-1 oglib_numeric-2.0-1 oglib_string-2.0-1 oglib_time-2.0-1 oglib_variantconfig-2.2-1 ogrsc_dynamicpalette-0.6-1 ogrsc_restart-1.0-1 Notes: * dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X * OpenG Toolkit 2.x packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib -=3D 2.1.3 Changelog =3D- all_packages 2.1.2 --> 2.1.3 -------------------------------------- oglib_appcontrol 2.0-2 --> 2.1-1 (fixed palette) -=3D 2.1.2 Changelog =3D- all_packages 2.1.1 --> 2.1.2 -------------------------------------- oglib_file 2.1-1 --> 2.2-1 ("Strip Path Extension" = +PolyMember) -=3D 2.1.1 Changelog =3D- all_packages 2.1.0 --> 2.1.1 -------------------------------------- oglib_variantconfig 2.1-1 --> 2.2-1 (added missing VI back into = palette) -=3D 2.1.0 Changelog =3D- all_packages 2.0.7 --> 2.1.0 -------------------------------------- ogrsc_restart +1.0-1 -=3D 2.0.7 Changelog =3D- all_packages 2.0.6 --> 2.0.7 -------------------------------------- oglib_variantconfig 2.0-1 --> 2.1-1 (Added "found?" outputs to Read = VIs) -=3D 2.0.6 Changelog =3D- all_packages 2.0.5 --> 2.0.6 -------------------------------------- oglib_lvdata 2.0-1 --> 2.1-1 (+Variant Constant and palette mod) -=3D 2.0.5 Changelog =3D- all_packages 2.0.4 --> 2.0.5 -------------------------------------- ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette) -=3D 2.0.4 Changelog =3D- all_packages 2.0.3 --> 2.0.4 -------------------------------------- ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) -=3D 2.0.3 Changelog =3D- all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) -=3D 2.0.2 Changelog =3D- all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) -=3D 2.0.1 Changelog =3D- all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
|
From: Jim K. <ji...@ji...> - 2003-12-02 06:31:51
|
<http://sourceforge.net/projects/opengtoolkit/> -= ogfwk_opengoop-0.6-1.ogp =- v0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on all platforms. It has optional components that depend on the OpenG Toolkit v2.x Changes from 0.5-1 --> 0.6-1 -------------------------------- 2003-12-01 [Fix] 'Set Modified Data' now releases semaphore even if error in. Changes from 0.4-1 --> 0.5-1 -------------------------------- 2003-12-01 [NEW] Added a progress dialog to the wizard Changes from 0.3-1 --> 0.4-1 -------------------------------- 2003-12-01 [NEW] Package is now compatible with LV 7.0 [FIX] Wizard now works in LV 7.0 (Open VI Reference to template problem, fixed by option 0x02) [MOD] '(Un)Flatten Object to(from) File' now linked to OGTK-2.x |
|
From: Jim K. <ji...@ji...> - 2003-12-02 06:08:17
|
<http://sourceforge.net/projects/opengtoolkit/> -= ogfwk_opengoop-0.5-1.ogp =- v0.5 is compatible with LabVIEW 6.0, 6.1, and 7.0 on all platforms. It has optional components that depend on the OpenG Toolkit v2.x Changes from 0.4-1 --> 0.5-1 -------------------------------- 2003-12-01 [NEW] Added a progress dialog to the wizard Changes from 0.3-1 --> 0.4-1 -------------------------------- 2003-12-01 [NEW] Package is now compatible with LV 7.0 [FIX] Wizard now works in LV 7.0 (Open VI Reference to template problem, fixed by option 0x02) [MOD] '(Un)Flatten Object to(from) File' now linked to OGTK-2.x |
|
From: <Bjo...@si...> - 2003-11-27 09:39:29
|
Read the license again this morning, and it is even more clear to me that "Authorized applications" are only those applications that NI will protect (infringement vise), see 12 A (1) and 16. They are to be copyrighted by you AND NI. The license does not say anywhere that all your applications has to be "Authorized applications". To me this is rather straight forward, maybe because i'm not native english speaking and don't put any other meaning in the name "Authorized applications" other than a strict definition of one kind of applications? It is also rather obvious since NI cannot legally be held responsible for infringements you make on their behalf if NI have software that does not infringe, and you also are at risk infringing the existing NI software. Software made with NI's software is also most likely to infringe other software made with NI's software (particularly LabVIEW). So if more software is copyrighted by NI, this will make any legal disputes rather simple, for NI at least. Needless to say, NI wants most software to be copyrighted by NI. But they do not own us, and we are not emploid at NI, so they cannot force us to make only "Authorized applications". > -----Original Message----- > From: Rolf Kalbermatter [mailto:rol...@ci...] > Sent: 27. november 2003 09:28 > To: ope...@li... > Subject: RE: FW: More NI License Problems [k.v...@ve...] > > > Jim Kring [mailto:ji...@ji...] wrote: > > > 1) NI doesn't mean what the license says and they change it. > > From what I've heard out of NI in the past, the intent of the > > license is to protect NI's software from being wrapped and > > resold. > > I can second that. It's not like they are an evil empire or such. > > > 2) NI means what the license says but they have to change it, > > because the overwhelming majority of LabVIEW developers will stop > > using it if the license doesn't change. > > They do listen and marketing has still more power within NI than > lawayers. Personally I believe this new clause is more of an accident > of someone to entusiastic about protecting NIs intellectual > and business > property than a well informed decision. > > After all I believe even if they would want to, they most > probably wouldn't > succeed in court in stiffling business competition in such a > way. In a lot > of countries, and I would guess the US too, this license > agreement would > most likely at least in this part be considered null and void > in court. > And that they are after Open Source developers seems almost outragous. > If they would, they would damage their own reputation very severaly > and maybe put themself in a tighter spot than MS has been lately. > > Last but not least, my english isn't at all perfect but that > passage will > give even a linguist a hard time to understand what the > intend might have > been, which makes it a weak point in the license for most courts. > > Rolf Kalbermatter > > > Kevin Valentine wrote: > > > > > > Thanks for the info Jim. > > > > > > This looks bad for me. I'm doing a presentation at an NI site > > > on December 10th. I'm showing how to use OGIC, Comedi, and > > > Linux-GPIB under the Linux > > > OS. (see http://www.minkhollowsystems.com/WALUG.html) > > > > > > Quite frankly, I've been following the discussion and I'm a > > > little freaked out. I'm starting to wonder if I should do the > > > presentation. Are there legal issues in dumping VISA for an > > > open source alternative. Based on what Greg > > > McKaskle said in one of his previous posts, "As for writing > > > your own VISA, that is certainly a possibility. Or maybe you > > > pass the hat and pay Dan M to write you one ;)" (see > > http://messages.info-labview.org/2003/11/13/03.html), > > it would appear that he is rather supportive of the development of > > alternatives to NI's toolkits. > > > > I have zero interest in rewriting VISA but I would certainly like to > > continue my efforts in producing VI libraries that work with > > open source > > hardware > > drivers. > > > > OGIC and Linux-GPIB are dead men walking. They're definitely > > replacements. > > Comedi, on the other hand, provides what NI cannot - drivers > > for 3rd party > > hardware. > > > > -Kevin > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
|
From: Rolf K. <rol...@ci...> - 2003-11-27 08:25:57
|
Jim Kring [mailto:ji...@ji...] wrote: > 1) NI doesn't mean what the license says and they change it. =20 > From what I've heard out of NI in the past, the intent of the > license is to protect NI's software from being wrapped and > resold. =20 I can second that. It's not like they are an evil empire or such. > 2) NI means what the license says but they have to change it,=20 > because the overwhelming majority of LabVIEW developers will stop > using it if the license doesn't change. They do listen and marketing has still more power within NI than lawayers. Personally I believe this new clause is more of an accident of someone to entusiastic about protecting NIs intellectual and business property than a well informed decision. After all I believe even if they would want to, they most probably = wouldn't succeed in court in stiffling business competition in such a way. In a = lot of countries, and I would guess the US too, this license agreement would most likely at least in this part be considered null and void in court. And that they are after Open Source developers seems almost outragous. If they would, they would damage their own reputation very severaly and maybe put themself in a tighter spot than MS has been lately. Last but not least, my english isn't at all perfect but that passage = will give even a linguist a hard time to understand what the intend might = have been, which makes it a weak point in the license for most courts. Rolf Kalbermatter > Kevin Valentine wrote: > >=20 > > Thanks for the info Jim. > >=20 > > This looks bad for me. I'm doing a presentation at an NI site=20 > > on December 10th. I'm showing how to use OGIC, Comedi, and=20 > > Linux-GPIB under the Linux=20 > > OS. (see http://www.minkhollowsystems.com/WALUG.html) > >=20 > > Quite frankly, I've been following the discussion and I'm a=20 > > little freaked out. I'm starting to wonder if I should do the=20 > > presentation. Are there legal issues in dumping VISA for an=20 > > open source alternative. Based on what Greg=20 > > McKaskle said in one of his previous posts, "As for writing=20 > > your own VISA, that is certainly a possibility. Or maybe you=20 > > pass the hat and pay Dan M to write you one ;)" (see=20 > http://messages.info-labview.org/2003/11/13/03.html), > it would appear that he is rather supportive of the development of > alternatives to NI's toolkits. >=20 > I have zero interest in rewriting VISA but I would certainly like to > continue my efforts in producing VI libraries that work with=20 > open source > hardware=20 > drivers. >=20 > OGIC and Linux-GPIB are dead men walking. They're definitely=20 > replacements. > Comedi, on the other hand, provides what NI cannot - drivers=20 > for 3rd party > hardware. >=20 > -Kevin=20 |
|
From: Jim K. <ji...@ji...> - 2003-11-27 05:09:41
|
<https://sourceforge.net/projects/opengtoolkit/> -=3D all_packages-2.1.2 =3D- oglib_appcontrol-2.0-2 oglib_array-2.0-1 oglib_boolean-2.0-1 oglib_comparison-2.0-1 oglib_error-2.0-1 oglib_file-2.2-1 oglib_lvdata-2.1-1 oglib_lvzip-2.0-2 oglib_msgqueue-2.0-1 oglib_numeric-2.0-1 oglib_string-2.0-1 oglib_time-2.0-1 oglib_variantconfig-2.2-1 ogrsc_dynamicpalette-0.6-1 ogrsc_restart-1.0-1 Notes: * dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib -=3D 2.1.2 Changelog =3D- all_packages 2.1.1 --> 2.1.2 -------------------------------------- oglib_file 2.1-1 --> 2.2-1 ("Strip Path Extension" = +PolyMember) -=3D 2.1.1 Changelog =3D- all_packages 2.1.0 --> 2.1.1 -------------------------------------- oglib_variantconfig 2.1-1 --> 2.2-1 (added missing VI back into = palette) -=3D 2.1.0 Changelog =3D- all_packages 2.0.7 --> 2.1.0 -------------------------------------- ogrsc_restart +1.0-1 -=3D 2.0.7 Changelog =3D- all_packages 2.0.6 --> 2.0.7 -------------------------------------- oglib_variantconfig 2.0-1 --> 2.1-1 (Added "found?" outputs to Read = VIs) -=3D 2.0.6 Changelog =3D- all_packages 2.0.5 --> 2.0.6 -------------------------------------- oglib_lvdata 2.0-1 --> 2.1-1 (+Variant Constant and palette mod) -=3D 2.0.5 Changelog =3D- all_packages 2.0.4 --> 2.0.5 -------------------------------------- ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette) -=3D 2.0.4 Changelog =3D- all_packages 2.0.3 --> 2.0.4 -------------------------------------- ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) -=3D 2.0.3 Changelog =3D- all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) -=3D 2.0.2 Changelog =3D- all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) -=3D 2.0.1 Changelog =3D- all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
|
From: Jim K. <ji...@ji...> - 2003-11-27 05:08:46
|
<http://sourceforge.net/projects/opengtoolkit/> -= oglib_file-2.2-1.ogp =- Changes from 2.1-1 --> 2.2-1 -------------------------------- 2003-11-26 added "Strip Path Extension - 1D Array of Strings.vi" to PolyVI "Strip Path Extension" |
|
From: Jim K. <ji...@ji...> - 2003-11-27 04:34:20
|
<http://sourceforge.net/projects/opengtoolkit/> -= oglib_variantconfig-2.2-1.ogp =- Changes from 2.1-1 --> 2.2-1 -------------------------------- 2003-11-26 Fixed palette. There were two instances of "Write Key (Variant)" and "Read Key (Variant)" was missing. Changes from 2.0-1 --> 2.1-1 -------------------------------- 2003-11-20 Added "found?" outputs to "Read INI Cluster" and "Read Section Cluster". The "found?" output will be TRUE only if all elements (recursively) are found. |
|
From: Jim K. <ji...@ji...> - 2003-11-27 04:31:28
|
<https://sourceforge.net/projects/opengtoolkit/> -=3D all_packages-2.1.1 =3D- oglib_appcontrol-2.0-2 oglib_array-2.0-1 oglib_boolean-2.0-1 oglib_comparison-2.0-1 oglib_error-2.0-1 oglib_file-2.1-2 oglib_lvdata-2.1-1 oglib_lvzip-2.0-2 oglib_msgqueue-2.0-1 oglib_numeric-2.0-1 oglib_string-2.0-1 oglib_time-2.0-1 oglib_variantconfig-2.2-1 ogrsc_dynamicpalette-0.6-1 ogrsc_restart-1.0-1 Notes: * dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib -=3D 2.1.1 Changelog =3D- all_packages 2.1.0 --> 2.1.1 -------------------------------------- oglib_variantconfig 2.1-1 --> 2.2-1 (added missing VI back into = palette) -=3D 2.1.0 Changelog =3D- all_packages 2.0.7 --> 2.1.0 -------------------------------------- ogrsc_restart +1.0-1 -=3D 2.0.7 Changelog =3D- all_packages 2.0.6 --> 2.0.7 -------------------------------------- oglib_variantconfig 2.0-1 --> 2.1-1 (Added "found?" outputs to Read = VIs) -=3D 2.0.6 Changelog =3D- all_packages 2.0.5 --> 2.0.6 -------------------------------------- oglib_lvdata 2.0-1 --> 2.1-1 (+Variant Constant and palette mod) -=3D 2.0.5 Changelog =3D- all_packages 2.0.4 --> 2.0.5 -------------------------------------- ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette) -=3D 2.0.4 Changelog =3D- all_packages 2.0.3 --> 2.0.4 -------------------------------------- ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) -=3D 2.0.3 Changelog =3D- all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) -=3D 2.0.2 Changelog =3D- all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) -=3D 2.0.1 Changelog =3D- all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
|
From: Jim K. <ji...@ji...> - 2003-11-27 03:58:24
|
Kevin, I wouldn't freak out, yet. I can see two simple sollutions: 1) NI doesn't mean what the license says and they change it. From what = I've heard out of NI in the past, the intent of the license is to protect = NI's software from being wrapped and resold. 2) NI means what the license says but they have to change it, because = the overwhelming majority of LabVIEW developers will stop using it if the license doesn't change. -Jim Kevin Valentine wrote: >=20 > Thanks for the info Jim. >=20 > This looks bad for me. I'm doing a presentation at an NI site=20 > on December 10th. I'm showing how to use OGIC, Comedi, and=20 > Linux-GPIB under the Linux=20 > OS. (see http://www.minkhollowsystems.com/WALUG.html) >=20 > Quite frankly, I've been following the discussion and I'm a=20 > little freaked out. I'm starting to wonder if I should do the=20 > presentation. Are there legal issues in dumping VISA for an=20 > open source alternative. Based on what Greg=20 > McKaskle said in one of his previous posts, "As for writing=20 > your own VISA, that is certainly a possibility. Or maybe you=20 > pass the hat and pay Dan M to write you one ;)" (see=20 http://messages.info-labview.org/2003/11/13/03.html), it would appear that he is rather supportive of the development of alternatives to NI's toolkits. I have zero interest in rewriting VISA but I would certainly like to continue my efforts in producing VI libraries that work with open source hardware=20 drivers. OGIC and Linux-GPIB are dead men walking. They're definitely = replacements. Comedi, on the other hand, provides what NI cannot - drivers for 3rd = party hardware. -Kevin |
|
From: <Bjo...@si...> - 2003-11-26 13:00:30
|
Hmm, was forced to actually read the license agreement :-) There are two things here: 1.E "Authorized Applications." Means only those applications that: (i) you create with development versions of the SOFTWARE that you have validly licensed and (ii) which do not, as solely determined by NI, perform (by themselves or in combination with other products) the same or similar functions as (or are otherwise intended to replace or supplant any component of) the SOFTWARE or any other software of NI. Notwithstanding the foregoing, any application created with the SOFTWARE acquired under an evaluation license is not an Authorized Application. AND 3. Restrictions. You may not: (i) reverse engineer, decompile, or disassemble the SOFTWARE (except to the extent such foregoing restriction is expressly prohibited by applicable law); (ii) sub-license, lease, or rent the SOFTWARE; (iii) (other than as expressly permitted under this Agreement) distribute in whole or part, modify, or create derivatives of the SOFTWARE or applications created with the SOFTWARE; and (iv) directly or indirectly, export, re-export, download, or ship the SOFTWARE in violation of the laws and regulations of the U.S.A. and the laws and regulations of the applicable jurisdiction in which you use or are downloading the SOFTWARE. Under no circumstance is "floating" or shared use permitted under this Agreement. Nothing in this Agreement, however, is intended to prevent you from creating your own driver interface software for use with NI software and third party hardware; provided, however, that in doing so you do not modify or use (in whole or part) any of the driver interface SOFTWARE. What most people seem to forget or just not take into consideration is within the paranthesis in 3, which is a standard phrase on all license agreements: "except to the extent such foregoing restriction is expressly prohibited by applicable law"; The laws are in fact very clear on that point, and effectively make everything about reverse engineering, decompiling, or disassembling, as well as 1E irrelevant (if 1E is interpreted as "You are not allowed to create anything but Authorized applications"). The last sentence in 3 is also interesting. The license state what an Authorized application is and how an Authorized application is to be deployd (12). Not anywhere does it say that you are not allowed to make "unauthorized applications". In fact in (16) it say that NI shall defend at its own expense any claims (infringements etc) resulting from your use of the software as long as the applications you have made are in fact "Authorized application", if not, you are on your own. So, my (correct or wrong) interpretation is simply that if you write "Authorized Applications" as defined in 1E, then NI will take care of any infringements claims on their behalf. However, if I should for instance use some OpenG subroutine for which equivalent subroutine exist from NI, then i'm on my own. Fees in connection with Autorized applications are defined in 12.B > -----Original Message----- > From: Jim Kring [mailto:ji...@ji...] > Sent: 26. november 2003 01:58 > To: ope...@li... > Subject: FW: More NI License Problems > > > Hello OpenG Developers, > > I just sent this email to the Info-LabVIEW mailing list. > This has many > implications for OpenG projects. I'm not yet sure what NI's > response is -- > we'll have to wait and see. > > -Jim > > -----Original Message----- > From: Jim Kring > Sent: Tuesday, November 25, 2003 3:01 PM > To: 'info-labview' > Subject: More NI License Problems > > > Hello Info-LV'ers, > > For those of you who haven't read your NISLA (NATIONAL > INSTRUMENTS SOFTWARE > LICENSE AGREEMENT) lately, I suggest that you take a look. > The VISA Serial > issue (see thread: "Distributing built application with VISA > = Not free") is > only the tip of the iceberg, it seems. The definition of what is an > "Authorized Application" (the only type of application you > are allowed to > create, per the NISLA) has grown to exclude *ANY* > applications that compete > with *ANY* National Instruments software. This seems to > imply that if one > is developing a software product that NI finds valuable, it > would be well > within NI's rights to start development of a similar product > and then issue > the competitor a cease and desist order. This is very > troubling, in my > opinion, and seems to affect the rights of anyone who > distributes *ANY* > software written in LabVIEW, for sale or for free. > > Any thoughts? Please, someone at NI, tell me that I am wrong. > > Regards, > > -Jim Kring > > > Section 1 Part E of the NATIONAL INSTRUMENTS SOFTWARE LICENSE > AGREEMENT > > -- August 2001 (circa LabVIEW 6.1) -- > 1.E. "Authorized Applications." Means only those > applications that: (i) > you create with development versions of the SOFTWARE that you > have validly > licensed and (ii) are not in themselves general purpose tools > that permit > the development of applications to acquire, display, or analyze data. > ------------------------------------- > > -- April 2003 (circa LabVIEW 7.0) -- > 1.E. "Authorized Applications." Means only those > applications that: (i) > you create with development versions of the SOFTWARE that you > have validly > licensed and (ii) which do not, as solely determined by NI, > perform (by > themselves or in combination with other products) the same or similar > functions as (or are otherwise intended to replace or > supplant any component > of) the SOFTWARE or any other software of NI. Notwithstanding the > foregoing, any application created with the SOFTWARE acquired under an > evaluation license is not an Authorized Application. > ------------------------------------- > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
|
From: <Bjo...@si...> - 2003-11-26 09:10:57
|
While i'm no lawyer, my previous experience with similar things makes me think that it is rather clear that it is against the law to prevent people from doing derivative work based on the work of others (Labview in this case). At least in Europe, a license like the one you describe will in fact be illegal. They can charge a fee or similar for distribution, for instance a fee for each LV runtime environment (or similar) you distribute (just as you have to pay for the LV development environment license), but they cannot do anything at all with the LV code you are developing and distributing, that is your work and is protected by the law (copyrights, and in some cases patents). If what you are making has been made before (by NI), it is of no relevance legally unless you infringe some copyrights or patents. In Europe it is illegal to make agreements (against better knowledge) that doesn't follow the laws, such an agreement is in any case worth nothing in court and i guess it is the same in the US. Seems to me that NI is trying to prevent someone from making a LV clone of some sort. While understandable why NI is trying to do that, a LV clone is perfectly legal as long as no copyrights or patents are infringed, regardless of any license. > -----Original Message----- > From: Jim Kring [mailto:ji...@ji...] > Sent: 26. november 2003 01:58 > To: ope...@li... > Subject: FW: More NI License Problems > > > Hello OpenG Developers, > > I just sent this email to the Info-LabVIEW mailing list. > This has many > implications for OpenG projects. I'm not yet sure what NI's > response is -- > we'll have to wait and see. > > -Jim > > -----Original Message----- > From: Jim Kring > Sent: Tuesday, November 25, 2003 3:01 PM > To: 'info-labview' > Subject: More NI License Problems > > > Hello Info-LV'ers, > > For those of you who haven't read your NISLA (NATIONAL > INSTRUMENTS SOFTWARE > LICENSE AGREEMENT) lately, I suggest that you take a look. > The VISA Serial > issue (see thread: "Distributing built application with VISA > = Not free") is > only the tip of the iceberg, it seems. The definition of what is an > "Authorized Application" (the only type of application you > are allowed to > create, per the NISLA) has grown to exclude *ANY* > applications that compete > with *ANY* National Instruments software. This seems to > imply that if one > is developing a software product that NI finds valuable, it > would be well > within NI's rights to start development of a similar product > and then issue > the competitor a cease and desist order. This is very > troubling, in my > opinion, and seems to affect the rights of anyone who > distributes *ANY* > software written in LabVIEW, for sale or for free. > > Any thoughts? Please, someone at NI, tell me that I am wrong. > > Regards, > > -Jim Kring > > > Section 1 Part E of the NATIONAL INSTRUMENTS SOFTWARE LICENSE > AGREEMENT > > -- August 2001 (circa LabVIEW 6.1) -- > 1.E. "Authorized Applications." Means only those > applications that: (i) > you create with development versions of the SOFTWARE that you > have validly > licensed and (ii) are not in themselves general purpose tools > that permit > the development of applications to acquire, display, or analyze data. > ------------------------------------- > > -- April 2003 (circa LabVIEW 7.0) -- > 1.E. "Authorized Applications." Means only those > applications that: (i) > you create with development versions of the SOFTWARE that you > have validly > licensed and (ii) which do not, as solely determined by NI, > perform (by > themselves or in combination with other products) the same or similar > functions as (or are otherwise intended to replace or > supplant any component > of) the SOFTWARE or any other software of NI. Notwithstanding the > foregoing, any application created with the SOFTWARE acquired under an > evaluation license is not an Authorized Application. > ------------------------------------- > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
|
From: Kevin V. <k.v...@ve...> - 2003-11-26 06:34:23
|
Thanks for the info Jim. This looks bad for me. I'm doing a presentation at an NI site on December 10th. I'm showing how to use OGIC, Comedi, and Linux-GPIB under the Linux OS. (see http://www.minkhollowsystems.com/WALUG.html) Quite frankly, I've been following the discussion and I'm a little freaked out. I'm starting to wonder if I should do the presentation. Are there legal issues in dumping VISA for an open source alternative. Based on what Greg McKaskle said in one of his previous posts, "As for writing your own VISA, that is certainly a possibility. Or maybe you pass the hat and pay Dan M to write you one ;)" (see http://messages.info-labview.org/2003/11/13/03.html), it would appear that he is rather supportive of the development of alternatives to NI's toolkits. I have zero interest in rewriting VISA but I would certainly like to continue my efforts in producing VI libraries that work with open source hardware drivers. OGIC and Linux-GPIB are dead men walking. They're definitely replacements. Comedi, on the other hand, provides what NI cannot - drivers for 3rd party hardware. -Kevin |
|
From: Jim K. <ji...@ji...> - 2003-11-26 00:58:30
|
Hello OpenG Developers, I just sent this email to the Info-LabVIEW mailing list. This has many implications for OpenG projects. I'm not yet sure what NI's response is = -- we'll have to wait and see. -Jim -----Original Message----- From: Jim Kring=20 Sent: Tuesday, November 25, 2003 3:01 PM To: 'info-labview' Subject: More NI License Problems Hello Info-LV'ers, For those of you who haven't read your NISLA (NATIONAL INSTRUMENTS = SOFTWARE LICENSE AGREEMENT) lately, I suggest that you take a look. The VISA = Serial issue (see thread: "Distributing built application with VISA =3D Not = free") is only the tip of the iceberg, it seems. The definition of what is an "Authorized Application" (the only type of application you are allowed = to create, per the NISLA) has grown to exclude *ANY* applications that = compete with *ANY* National Instruments software. This seems to imply that if = one is developing a software product that NI finds valuable, it would be = well within NI's rights to start development of a similar product and then = issue the competitor a cease and desist order. This is very troubling, in my opinion, and seems to affect the rights of anyone who distributes *ANY* software written in LabVIEW, for sale or for free. Any thoughts? Please, someone at NI, tell me that I am wrong. Regards, -Jim Kring Section 1 Part E of the NATIONAL INSTRUMENTS SOFTWARE LICENSE AGREEMENT -- August 2001 (circa LabVIEW 6.1) -- 1.E. "Authorized Applications." Means only those applications that: = (i) you create with development versions of the SOFTWARE that you have = validly licensed and (ii) are not in themselves general purpose tools that = permit the development of applications to acquire, display, or analyze data. ------------------------------------- -- April 2003 (circa LabVIEW 7.0) -- 1.E. "Authorized Applications." Means only those applications that: (i) you create with development versions of the SOFTWARE that you have = validly licensed and (ii) which do not, as solely determined by NI, perform (by themselves or in combination with other products) the same or similar functions as (or are otherwise intended to replace or supplant any = component of) the SOFTWARE or any other software of NI. Notwithstanding the foregoing, any application created with the SOFTWARE acquired under an evaluation license is not an Authorized Application. ------------------------------------- |
|
From: Jim K. <ji...@ji...> - 2003-11-22 22:48:59
|
<https://sourceforge.net/projects/opengtoolkit/> -= ogrsc_restart-1.0 =- ogrsc_restart-1.0 supports... LabVIEW 6.0, 6.1, 7.0 on Windows LabVIEW 7.0 on Mac OS X LabVIEW 7.0 on Linux |
|
From: Jim K. <ji...@ji...> - 2003-11-22 22:47:46
|
<https://sourceforge.net/projects/opengtoolkit/> -=3D all_packages-2.1.0 =3D- Notes: * dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib -=3D 2.1.0 Changelog =3D- all_packages 2.0.7 --> 2.1.0 -------------------------------------- ogrsc_restart +1.0-1 -=3D 2.0.7 Changelog =3D- all_packages 2.0.6 --> 2.0.7 -------------------------------------- oglib_variantconfig 2.0-1 --> 2.1-1 (Added "found?" outputs to Read = VIs) -=3D 2.0.6 Changelog =3D- all_packages 2.0.5 --> 2.0.6 -------------------------------------- oglib_lvdata 2.0-1 --> 2.1-1 (+Variant Constant and palette mod) -=3D 2.0.5 Changelog =3D- all_packages 2.0.4 --> 2.0.5 -------------------------------------- ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette) -=3D 2.0.4 Changelog =3D- all_packages 2.0.3 --> 2.0.4 -------------------------------------- ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) -=3D 2.0.3 Changelog =3D- all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) -=3D 2.0.2 Changelog =3D- all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) -=3D 2.0.1 Changelog =3D- all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
|
From: Jim K. <ji...@ji...> - 2003-11-20 09:15:41
|
<https://sourceforge.net/projects/opengtoolkit/> -=3D all_packages-2.0.7 =3D- Notes: * dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib -=3D 2.0.7 Changelog =3D- all_packages 2.0.6 --> 2.0.7 -------------------------------------- oglib_variantconfig 2.0-1 --> 2.1-1 (Added "found?" outputs to Read = VIs) -=3D 2.0.6 Changelog =3D- all_packages 2.0.5 --> 2.0.6 -------------------------------------- oglib_lvdata 2.0-1 --> 2.1-1 (+Variant Constant and palette mod) -=3D 2.0.5 Changelog =3D- all_packages 2.0.4 --> 2.0.5 -------------------------------------- ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette) -=3D 2.0.4 Changelog =3D- all_packages 2.0.3 --> 2.0.4 -------------------------------------- ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) -=3D 2.0.3 Changelog =3D- all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) -=3D 2.0.2 Changelog =3D- all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) -=3D 2.0.1 Changelog =3D- all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
|
From: Jim K. <ji...@ji...> - 2003-11-20 09:14:44
|
-= oglib_variantconfig-2.1-1.ogp =- Changes from 2.0-1 --> 2.1-1 -------------------------------- 2003-11-20 Added "found?" outputs to "Read INI Cluster" and "Read Section Cluster". The "found?" output will be TRUE only if all elements (recursively) are found. |
|
From: Jim K. <ji...@ji...> - 2003-11-18 04:14:27
|
-=3D oglib_lvdata-2.1-1.ogp =3D-
Changes from 2.0-1 --> 2.1-1
--------------------------------
2003-11-17
* New VI - "Variant Constant" is a "merged VI" that was added to the
palette. This allows users to drop a Variant constant onto the block
diagram.
* Palette Change - Added "Variant Constant" and "Get TDEnum from Data" =
to
the Palette
Changes from 1.6-1 --> 2.0-1
--------------------------------
2003-07-03
* Cosmetic - "Array Dim(s) from TD.vi", "Parse String with TDs.vi", =
"Strip
Units.vi" - removed ".vi" extension from VI Window Appearance for =
palette VI
title
* New VI - "Remove Typedefs from Variant.vi"
* Added "Remove Typedefs from Variant.vi" to "Type Descriptor" =
subpalette.
2003-05-06
* New VI - "Get Array Element Default Data.vi"
* New VI - "Unwrap VVariant"
* New suPalette - VVariant
* Added Variant primitives to Data Tools Root palette.
* Addtion to VArray Palette - "Get Array Element Default Data.vi"
2003-04-24 merge from the branch unit_dev
* Added Typedefs:
** Type Descriptor.ctl >>> array of I16. All VIs using a TD are now =
linked
to this typedef.
** Base Units.ctl >>> an enum typedef for base units as described in =
App
Note 154=20
** Physical Units.ctl >>> a cluster of {Base Unit, Exponent}
* Added VIs:
** Array Dim(s) from TD.vi >>> we had only one with variant input.
** Get Element TD from Array TD.vi >>> we had only one with variant =
input.
** Get Physical Units from TD.vi >>> outputs an array of Physical Units =
each
base unit with its exponent
** Get Physical Units.vi >>> same as previous except for variant input.
--------------------------------
2003-04-23 *** 1.6 Released ***
--------------------------------
|
|
From: Jim K. <ji...@ji...> - 2003-11-18 03:58:15
|
-=3D all_packages-2.0.6 =3D- Notes: * dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib -=3D 2.0.6 Changelog =3D- all_packages 2.0.5 --> 2.0.6 -------------------------------------- oglib_lvdata 2.0-1 --> 2.1-1 (+Variant Constant and palette mod) -=3D 2.0.5 Changelog =3D- all_packages 2.0.4 --> 2.0.5 -------------------------------------- ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette) -=3D 2.0.4 Changelog =3D- all_packages 2.0.3 --> 2.0.4 -------------------------------------- ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) -=3D 2.0.3 Changelog =3D- all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) -=3D 2.0.2 Changelog =3D- all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) -=3D 2.0.1 Changelog =3D- all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
|
From: Niels H. <ni...@ha...> - 2003-11-16 20:50:11
|
Jim, Thanks a lot. The "2D Dynamic Palette" view is exactly how I normally have my controls palette set-up. It's is really neat. All the best Niels At 10:13 16-11-2003 -0800, you wrote: >Niels and All, > >I have figured out a solution. The Dynamic Palette View package now >installs two palette views: "Dynamic Palette View" and "2D Dynamic Palette >View". The 2D Dynamic Palette View is identical to the Dynamic Palette >View, with the exception that the Controls palette has Classic (2D) controls >submenus and has a submenu called "3D Controls", which contains all of the >3D controls. > >The "2D Dynamic Palette View" (./menus/2ddynamic/) contains only two mnu >files (root.mnu and 3dctrls.mnu) which link to mnu files in the Dynamic >Palette View (./menus/dynamic/), so there is virtually no duplication of >work in supporting the additional palette view. > >I have released ogrsc_dynamicpalette-0.6-1.ogp, which includes the 2D >Dynamic Palette View. This package is part of all_packages-2.0.5.ogp.zip. > ><http://sourceforge.net/projects/opengtoolkit/> > >I'll update the OpenG Toolkit Downloads page on OpenG.org with instructions >that include the 2D Dynamic Palette View. > ><http://www.openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3A+Downloads> > >Regards, > >-Jim > > > -----Original Message----- > > From: ope...@li... > > [mailto:ope...@li...] > > On Behalf Of Jim Kring > > Sent: Saturday, November 15, 2003 10:45 AM > > To: ope...@li... > > Subject: RE: "Classic Controls" package > > > > > > Niels, > > > > > > > > Jim, > > > > > > I certainnly agree with you,- espicially relating to the > > OpenG Style. > > > > > > However, I'd preferred that it was the other way round: > > Having the 2D > > > controls in the main entry and the 3D controls as a sub > > menu. You're > > > actually creating quite a lot more non-GUI windows than GUI windows! > > > > > > > You're right! Hmmm... Well, the original idea for the > > Dynamic Palette View was that it was going to be just like > > the "default/advanced" Palette View, but with the palettes, > > synch'ed to specific folders. However, I really like your > > idea. The problem is that I think that this would create > > quite a bit of work. I'll have to think about that one, for > > a little while. I am also hesitant to change the Dynamic > > Palette View to a 2D controls because I don't want to turn > > off users who are not OpenG Developers and really like the > > super cool 3D controls ;-) It would be great if there were a > > really easy way to allow users to choose between 3D and 2D > > controls as the root controls palette of the Dynamic Palette View. > > > > > > > > BTW the 'Complete Waveform' control has a bad linkage in 'Numeric'-> > > > 'Classic Numeric'! > > > > > > > Actually, I don't think that there is such a thing as > > 'Complete Waveform' > > (any more). The numeric controls palette links to this > > missing control but > > the ./menus/default/readonly.txt file prevents the question mark from > > appearing in the palette. I haven't yet decided if I want to > > delete this > > dead-link or just make it disappear with a readonly.txt file. > > I'll fix this > > before the official release of 'Classic Controls'. > > > > > Just my $0.02. > > > > > > All the best > > > Niels > > > > > > > Regards, > > > > -Jim > > > > > > > > > > > > ------------------------------------------------------- > > This SF. Net email is sponsored by: GoToMyPC > > GoToMyPC is the fast, easy and secure way to access your computer from > > any Web browser or wireless device. Click here to Try it Free! > > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=/g22lp.tmpl > > _______________________________________________ > > OpenGToolkit-Developers mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > > > > > >------------------------------------------------------- >This SF. Net email is sponsored by: GoToMyPC >GoToMyPC is the fast, easy and secure way to access your computer from >any Web browser or wireless device. Click here to Try it Free! >https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target/g22lp.tmpl >_______________________________________________ >OpenGToolkit-Developers mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers All the best Niels |
|
From: Ed D. <ed...@cf...> - 2003-11-16 18:58:18
|
I like the idea too. I've always had my Controls palette setup with both the 3D and Classic = as separate menus sitting next to each other so I have easy access to = whatever one I want. So my Controls palette ends looking like; 3D numeric - Classic numeric - 3D string - Classic string and so on. This makes it easier to get to what you want by only having to go to a = top level menu. Ed -----Original Message----- From: ope...@li... on behalf of = Jim Kring Sent: Fri 11/14/2003 7:57 PM To: ope...@li... Cc:=09 Subject: "Classic Controls" package Hello All, I have an idea I want to bounce off of the group. Personally I like to use Classic (2D) Controls for all non-GUI VIs, and think that this should be part of the "OpenG Style" of coding. The = reason for using 2D Controls is related mostly to performance and memory = issues, but I also think that they simply look much "cleaner". So, I have = created a package called "ogrsc_classic_controls". It is an add-on for the = Dynamic Palette View. What it does is the following: For each of the 3D = controls menus it adds the corresponding 2D controls menu as a submenu. For = example, the Classic (2D) Numeric Controls menu is added as a submenu of the 3D Numeric Controls. To me, this seams like a more natural route, for = getting to classic controls, than having to go in to the root classic controls submenu and then navigating to the control type I need. Any thoughts? BTW, the "classic_controls" package is a good example of the flexibility provided by the Dynamic Palette View. -Jim |
|
From: Jim K. <ji...@ji...> - 2003-11-16 18:19:32
|
The Dynamic Palette View package now installs two palette views: = "Dynamic Palette View" and "2D Dynamic Palette View". The 2D Dynamic Palette = View is identical to the Dynamic Palette View, with the exception that the = Controls palette has Classic (2D) controls submenus and has a submenu called "3D Controls", which contains all of the 3D controls. Changes: ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette View) ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) |
|
From: Jim K. <ji...@ji...> - 2003-11-16 18:17:23
|
-=3D all_packages-2.0.5 =3D- =20 Notes: =20 * dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib =20 -=3D 2.0.5 Changelog =3D- =20 all_packages 2.0.4 --> 2.0.5 -------------------------------------- ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette) =20 -=3D 2.0.4 Changelog =3D- =20 all_packages 2.0.3 --> 2.0.4 -------------------------------------- ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) =20 -=3D 2.0.3 Changelog =3D- =20 all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) =20 -=3D 2.0.2 Changelog =3D- =20 all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) =20 -=3D 2.0.1 Changelog =3D- =20 all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
4 messages has been excluded from this view by a project administrator.
