GUI controls for instrumentation

[Kenneth Porter]

I'm tasked to write a front end for an instrumentation application for 
"that other operating system" ;) and I'd like to use GUI controls that are 
cross-platform portable for an eventual Linux port. What would the list 
recommend? I essentially need something that resembles the front panel of 
an oscilloscope, along with some dial indicators and knobs. I've also been 
thinking about making it web-accessible, so perhaps a Java-based solution 
would be suitable.

[Lamont R. Peterson]

On Friday 24 March 2006 07:37pm, Kenneth Porter wrote:
>  I'm tasked to write a front end for an instrumentation
> application for
>  "that other operating system" ;) and I'd like to use GUI controls that are
>  cross-platform portable for an eventual Linux port. What would the list
>  recommend? I essentially need something that resembles the front panel of
>  an oscilloscope, along with some dial indicators and knobs. I've also been
>  thinking about making it web-accessible, so perhaps a Java-based solution
>  would be suitable. 
Qt.

Trust me, I've written enough code in various languages and using various 
frameworks and toolkits to know that when you want stable, simple, reliable 
cross-platform code, Qt is excellent.

But, on this list in particular, I know there will be many who will think me 
an idiot for making that recommendation.  I'm not saying that Qt is the 
end-all, be-all of code.

I know that several people will want to point out how C++ is a "bad" language. 

Some will try to tell you how Qt's licensing is "not free".  Others will
tell 
you that performance will be horrible if you go with Qt.

Well, I will let them have their opinions.

In the end, you have to make your choice.  So I recommend that to take an 
*objective* look at all the options suggested.  Don't let the fact that this 
solution or that is in a language you are less familiar with (or do not know) 
sway you, either.  Sure, it's a normal metric to include, but it should never 
be an absolute blocker, IMHO.

Qt is free and you can get a commercial license, as well.

C++ with Qt is a very easy to read, write and use language.  The flexibility 
and simplicity of your code will amaze you.

C++ can outperm C for the same task.  Mind you, I'm not saying that it will 
without work, but it has been shown to do so in many instances.

Qt performance is excellent.  In fact, it's very hard to beat.

Qt is small.  Including the libraries for Windows deployments is very easy.

Let the flames begin. :)

P.S.  Please, don't flame on this list.
-- 
Lamont R. Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409

[Joe Desbonnet]

For full portability you have many options. Personally I would go the
Java route. With excellent free IDEs like Eclipse you can get very
productive in that environment.

But there are several approaches:

1. Use applets which communicate via socket to server side (could be
in Java or other language)
2. Use stand alone application (in SWT or Swing or ...)
3. Use web based GUI using 'AJAX' like techniques. See
http://developer.yahoo.com/yui/index.html for some examples of what is
possible. This approach will probably not work for fast moving  data
eg an oscillascope display.
4. Use SVG: I've seen some excellent demos of SVG in action:
see http://www.adobe.com/svg/demos/
5. Use Flash (there are some dynamic flash generation frameworks, but
I know nothing about them).
6. Run the application on the server and use a light weight VNC client.

[Nicolas Mailhot]

Le samedi 25 mars 2006 à 03:59 +0000, Joe Desbonnet a écrit :
>  For full portability you have many options. Personally I would go
> the
>  Java route. With excellent free IDEs like Eclipse you can get very
>  productive in that environment. 
Java server-side is a good idea.
On the client part it's a shockingly bad idea (and I include applets
there). Googling will find you boatloads of apps that choose java for
portability and still can not run on anything else than windows, because
just deploying the right JVM on all the systems you may target is a
major problem (and I'm not even counting the free stacks there).

If it where that easy, we'd have the latest eclipse version in Fedora
with all the major plugins instead of the current situation.

As a rule, if you can go thin-client just do it. Fat client in any
language will always be a deployment nightmare

-- 
Nicolas Mailhot

[Dariusz J. Garbowski]

On 03/25/2006 10:11 AM, Nicolas Mailhot wrote:
>  Le samedi 25 mars 2006 à 03:59 +0000, Joe Desbonnet a écrit :
> > For full portability you have many options. Personally I would go the
> > Java route. With excellent free IDEs like Eclipse you can get very
> > productive in that environment.
>  
>  Java server-side is a good idea.
>  On the client part it's a shockingly bad idea (and I include applets
>  there). Googling will find you boatloads of apps that choose java for
>  portability and still can not run on anything else than windows, because
>  just deploying the right JVM on all the systems you may target is a
>  major problem (and I'm not even counting the free stacks there). 
I tend to disagree -- get Java from Sun and you should have no problem 
unless your application is especially written to *not* run on anything 
else than some particular platform. And I'm speaking from experience: 
running lots of Java desktop applications on both Linux (at home) and 
Windows (at work). Few examples:

- Druid (druid.sf.net),
- JMeter,
- NetBeans (all versions, starting from 3.5 up to 5.0) with a few plugins,
- Azureus,
- IntelliJ IDEA,
- few NASA applications (e.g. Mars24j),
- Eclipse (since 2.1 up to all sorts of development releases 3.2) with 
*lots* of plugins (MyEclipseIDE, Subclipse, BIRT, Mylar, WebTools 
Platform, QuantumDB, GEF, VisualEditor, Jigloo, EMF...)
- RawView (http://www.through-the-lens.net)

and more... Successfully with no special treatment to make it work on 
either OS. And these are only some GUI applications I use/used. There's 
more non-GUI software too.


>  If it where that easy, we'd have the latest eclipse version in
> Fedora
>  with all the major plugins instead of the current situation. 
Heh, it *is* that easy -- get Sun's Java stack, install, download your 
app of choice, install and run!

Regards,
Dariusz


		
___________________________________________________________ 
Yahoo! Photos � NEW, now offering a quality print service from just 8p a photo
http://uk.photos.yahoo.com

[Nicolas Mailhot]

Le samedi 25 mars 2006 à 10:47 +0000, Dariusz J. Garbowski a écrit :

>  > If it where that easy, we'd have the latest eclipse version
> in Fedora
>  > with all the major plugins instead of the current situation.
>  
>  Heh, it *is* that easy -- get Sun's Java stack, install, download your 
>  app of choice, install and run! 
It's not, I'm sorry. You require lots of end-user work to make it
anything like work. That's why a stupid app like the logitech remote
controler (which has very simple fontionnality) is still not available
for linux even if it was written in java to be cross-platform.

For a developper java is easy. As soon as you need an average end-user
to make it work and are paying the support costs it suddenly is no
longer anywhere near a good choice.

And I'm not even talking about the differences between jvm behaviour (if
you think you can go sun-only just compare the arches sun, ibm and bea
support)

-- 
Nicolas Mailhot

[Dariusz J. Garbowski]

On 03/25/2006 10:59 AM, Nicolas Mailhot wrote:
>  Le samedi 25 mars 2006 à 10:47 +0000, Dariusz J. Garbowski a écrit :
>  
> >> If it where that easy, we'd have the latest eclipse version in Fedora
> >> with all the major plugins instead of the current situation.
> > Heh, it *is* that easy -- get Sun's Java stack, install, download your 
> > app of choice, install and run!
>  
>  It's not, I'm sorry. You require lots of end-user work to make it
>  anything like work. That's why a stupid app like the logitech remote
>  controler (which has very simple fontionnality) is still not available
>  for linux even if it was written in java to be cross-platform. 
There's nothing in the applications themselves to stop working on Linux. 
Work user has to put comes from the fact that distributions tend to make 
user's life more difficult by not making it trivial to have e.g. Sun's 
JRE installed (I don't want to blame distro developers here, Sun is 
probably the most guilty by not allowing to repackage and redistribute 
JRE). Yet situation is IMHO similar to proprietary NVidia drivers: users 
just have it easier thanks to the work of Livna developers (at least on 
Fedora). And, hey!, users still manage to install proprietary nvidia 
drivers from NVidia rather than Livna, with all the hassle it makes! 
Users are not stupid, they are ready and able to do quite a few things 
when they have clear instructions.

Let's say we have "Livna JRE" to install using yum. What's missing to 
make running Java apps trivial is making sure that there is at least a 
simple shell script to run it from command line. Say, user opens up "Run 
Command" dialog and types "jmeter" and it just starts. Of course the 
script would need to line on $PATH. Other "use case" is user opens up 
application's directory and double clicks the script. Application 
starts. Many applications already do provide it: NetBeans, Eclipse, 
JMeter...

Then a step further is packaging applications for distro, like each 
other native application.


>  For a developper java is easy. As soon as you need an average
> end-user
>  to make it work and are paying the support costs it suddenly is no
>  longer anywhere near a good choice. 
Nothing to do with Java applications, it's all about packaging. If your 
application is packaged for Linux, it will be easy to run! Vice versa it 
can be difficult for Windows if it's not packaged for Windows. Where's 
Java fault here?


>  And I'm not even talking about the differences between jvm
> behaviour (if
>  you think you can go sun-only just compare the arches sun, ibm and bea
>  support) 
You asked about *easy* way -- the easiest, least troublesome is to use 
Sun's JRE. You are free to try other solutions too. You have this 
freedom. It's good. Don't want problems? Try Sun first. If you really 
need to run on more exotic hardware, you are likely to hit other issues, 
yet it's a particular JRE's issue. Bug IBM/Sun/BEA to fix it :-)

Same with free stack. Everybody knows it's not quite there yet to run 
all Java software. And yes there's a few Java apps out there using sun.* 
packages -- not a Java issue either. Bug application developer to fix it 
so it's ready for free stack.

Want to avoid as much issues as you can? Get Sun's JRE and make sure 
it's on your PATH before free stack is.

Regards,
Dariusz

	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com

[Nicolas Mailhot]

Le samedi 25 mars 2006 à 11:30 +0000, Dariusz J. Garbowski a écrit :
>   Yet situation is IMHO similar to proprietary NVidia drivers: users 
>  just have it easier thanks to the work of Livna developers (at least on 
>  Fedora). And, hey!, users still manage to install proprietary nvidia 
>  drivers from NVidia rather than Livna, with all the hassle it makes!  
Again that's all fine and dandy with hobbyists/gamers/whatever which are
ready to make all kinds of stupid sacrifices gratis pro deo. In a work
context (and I think oscilloscope qualifies) that's a direct helpdesk
redirection which *will* cost lots of money to someone.

java GUI is not realistic unless you're not fronting the support calls
nor are paying for them one way or another.

-- 
Nicolas Mailhot

[Dariusz J. Garbowski]

On 03/25/2006 11:51 AM, Nicolas Mailhot wrote:
>  Le samedi 25 mars 2006 à 11:30 +0000, Dariusz J. Garbowski a écrit :
> >  Yet situation is IMHO similar to proprietary NVidia drivers: users 
> > just have it easier thanks to the work of Livna developers (at least on 
> > Fedora). And, hey!, users still manage to install proprietary nvidia 
> > drivers from NVidia rather than Livna, with all the hassle it makes! 
>  
>  Again that's all fine and dandy with hobbyists/gamers/whatever which are
>  ready to make all kinds of stupid sacrifices gratis pro deo. In a work
>  context (and I think oscilloscope qualifies) that's a direct helpdesk
>  redirection which *will* cost lots of money to someone.
>  
>  java GUI is not realistic unless you're not fronting the support calls
>  nor are paying for them one way or another. 
I see where you're coming from. And I can see this may be a problem. I 
work in a big company on a web application that serves Java applet. 
Occasionally we used to have JRE/plugin issues however since company 
standardizes and pushes (via update mechanism) JRE on each user's 
machine we do not see that anymore. In fact we have more issues with 
Acrobat Reader...
But I can see that in some environments Java on the desktop may be a 
support issue.

Regards,
Dariusz


		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security
Centre. http://uk.security.yahoo.com

[Nicolas Mailhot]

Le samedi 25 mars 2006 à 12:06 +0000, Dariusz J. Garbowski a écrit :
>  .
>  But I can see that in some environments Java on the desktop may be a 
>  support issue. 
Java is only write-once, run everywhere if you define everywhere as a
very specific static OS image :(

If you have 100% control of the systems and can deploy a single
controlled jvm everywhere, yes java-on-desktop is doable

-- 
Nicolas Mailhot

[Ralf Ertzinger]

Hi.

On Sun, 26 Mar 2006 18:05:46 +0200, Nicolas Mailhot wrote

>  If you have 100% control of the systems and can deploy a single
>  controlled jvm everywhere, yes java-on-desktop is doable 
If you have 100% control of the systems _every_ language is
write-once-run-anywhere. Even BASIC.

[Lamont R. Peterson]

On Sunday 26 March 2006 09:15am, Ralf Ertzinger wrote:
>  Hi.
>
>  On Sun, 26 Mar 2006 18:05:46 +0200, Nicolas Mailhot wrote
>
>  > If you have 100% control of the systems and can deploy a single
>  > controlled jvm everywhere, yes java-on-desktop is doable
>
>  If you have 100% control of the systems _every_ language is
>  write-once-run-anywhere. Even BASIC. 
Which is basically why Java doesn't buy you anything in the portability arena.  
There are some applications for which Java is an ideal choice (like dealing 
with lots of XML).

For an instrumentation application, Java would be a HUGE mistake.

For an instrumentation application, C++ is a very sane choice.  There are lots 
of benefits and lots and lots of libraries for all sorts of I/O, control & 
input cards/systems out there.
-- 
Lamont R. Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409

[Kenneth Porter]

--On Tuesday, March 28, 2006 1:03 AM -0700 "Lamont R. Peterson" 
<lamont(a)gurulabs.com&gt; wrote:

>  For an instrumentation application, Java would be a HUGE mistake.
>
>  For an instrumentation application, C++ is a very sane choice.  There are
>  lots  of benefits and lots and lots of libraries for all sorts of I/O,
>  control &  input cards/systems out there. 
You seem to presume that one must code the whole thing in one language as a 
monolithic application. I don't expect some of my deployments to have a 
display. It might be a little "brick" computer buried in a rack or inside 
some OEM factory equipment.

I expect to code the "back end" that talks to the hardware in C++, because 
my vendors' expose their API's either as C++ or C, and because I will be 
exposing an API to my customers. But the front end is going to be separate 
and may be attached either as a linked application (ie. exe/dll or 
executable/so) or via TCP/IP, possibly local. There may even be multiple 
"heads", with some acting as remote monitors while others act as control 
panels.

One reason I don't want a monolithic application is because it gives me the 
freedom to try different front-ends based on platform support for control 
libraries. I might have a web front-end using SVG, a local one with Qt, or 
perhaps something using Java for either.

I expect any control library will give me the common stuff like windows and 
radio buttons. It's the more esoteric stuff like oscopes, gauges, and knobs 
that I'm trying to nail down.

[Lamont R. Peterson]

On Tuesday 28 March 2006 07:44am, Kenneth Porter wrote:
>  --On Tuesday, March 28, 2006 1:03 AM -0700 "Lamont R.
> Peterson"
>
>  <lamont(a)gurulabs.com&gt; wrote:
>  > For an instrumentation application, Java would be a HUGE mistake.
>  >
>  > For an instrumentation application, C++ is a very sane choice.  There are
>  > lots  of benefits and lots and lots of libraries for all sorts of I/O,
>  > control &  input cards/systems out there.
>
>  You seem to presume that one must code the whole thing in one language as a
>  monolithic application. I don't expect some of my deployments to have a
>  display. It might be a little "brick" computer buried in a rack or inside
>  some OEM factory equipment. 
No, I don't make that assumption, though I see why it would appear that way.  
Thanks for catching it.

However, most times I have seen Instrumentation apps, they are coded in one 
language plus an embedded scripting language is included for automating or 
"linking" of controls, inputs & outputs.  At least, that's the way the 
commercial toolkits usually did things.

Of course, this might no longer be the case, as I really haven't seen or done 
anything with instrumentation packages in about 5 years or so.  Then again, 
in this kind of area, I'm sure most people are sticking with what works.  
It's a pretty well established field.

>  I expect to code the "back end" that talks to the hardware
> in C++, because
>  my vendors' expose their API's either as C++ or C, and because I will be
>  exposing an API to my customers. But the front end is going to be separate
>  and may be attached either as a linked application (ie. exe/dll or
>  executable/so) or via TCP/IP, possibly local. There may even be multiple
>  "heads", with some acting as remote monitors while others act as control
>  panels. 
Yes.  That was part of what I was thinking/trying to say.  Most such libraries 
are C++ or (less commonly over time) C.  That's another one of the reasons I 
recommended Qt.  The main reason being that the OP asked about portability.

>  One reason I don't want a monolithic application is because it
> gives me the
>  freedom to try different front-ends based on platform support for control
>  libraries. I might have a web front-end using SVG, a local one with Qt, or
>  perhaps something using Java for either. 
Yup.   Keeping flexibility in the design is a good idea.

>  I expect any control library will give me the common stuff like
> windows and
>  radio buttons. It's the more esoteric stuff like oscopes, gauges, and knobs
>  that I'm trying to nail down. 
Ah.  Well, there are plenty of libraries out there.  I haven't looked, lately 
(like I said) at such widget sets, but I have seen (at least some of) them 
for Qt, too.

Thanks.
-- 
Lamont R. Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409

[Kenneth Porter]

--On Tuesday, March 28, 2006 9:06 AM -0700 "Lamont R. Peterson" 
<lamont(a)gurulabs.com&gt; wrote:

>  No, I don't make that assumption, though I see why it would
> appear that
>  way.   Thanks for catching it. 
Sorry for misreading you.

>  However, most times I have seen Instrumentation apps, they are coded
> in
>  one  language plus an embedded scripting language is included for
>  automating or  "linking" of controls, inputs & outputs.  At least,
> that's
>  the way the  commercial toolkits usually did things. 
I've been thinking about incorporating either Perl or Tcl as my scripting 
language. Any other choices I should consider?

>  Yes.  That was part of what I was thinking/trying to say.  Most such
>  libraries  are C++ or (less commonly over time) C.  That's another one of
>  the reasons I  recommended Qt.  The main reason being that the OP asked
>  about portability. 
That was me. ;)

>  Ah.  Well, there are plenty of libraries out there.  I haven't
> looked,
>  lately  (like I said) at such widget sets, but I have seen (at least some
>  of) them  for Qt, too. 
Yep, that's what I'm really looking for, what goes on top of the more 
generic stuff. I know of NI's Measurement Studio but want to explore 
alternatives. Source access is very important to me. With commercial stuff, 
that means I can continue to maintain it if the vendor goes belly-up or 
discontinues the product.

Qt does look like a good foundation. Has anyone here experience with 
wxWidgets? I looked into it a few years ago and it used the "sizer" meme 
for window control placement, which I prefer to the fixed placement of the 
Windows-based tools I've seen. At the time I looked at it, it had a basic 
dialog editor that understood sizers, and a commercial dialog editor was 
available.

[Alan Cox]

On Tue, Mar 28, 2006 at 09:10:01AM -0800, Kenneth Porter wrote:
>  I've been thinking about incorporating either Perl or Tcl as my
> scripting 
>  language. Any other choices I should consider? 
Certainly python has some good bindings to gtk and kde. It's structured, its
very stable between versions and it looks like source code unlike perl. A lot
of the Fedora system config tools use python.

[T. E. Pickering]

we do a lot of instrument interfacing here at the MMT under fedora and
use a variety of things.  most of the code to support our wide-field
instruments is tcl/tk.  we use critcl to pull in dll/.so files to
access C/C++/vendor code from them.  the adaptive optics people use a
combination of tcl/tk, C, and IDL.  the facility spectrographs use
ruby-gnome.  we inflict a wide variety of guis on the telescope
operators.  we still have some left-over perl-tk guis, several systems
are using ruby-gnome, the guiders are largely tcl-tk with a sprinkle
of labview, the wavefront sensor interface is a mix of tcl-tk/blt and
ruby-gnome, and the mirror cell guis are raw X via windx running under
vxworks (bleah!).

i really like ruby-gnome and found it better and easier to use for
very interactive guis than the python or perl bindings.  we need
information to continually update in our windows while maintaining
continuous interactivity.  i find that ruby threads are an easier,
more straightforward way of doing this than managing a bunch of gtk
timeouts or idles.  when i first started using ruby-gnome a few years
ago there was no easy/safe way of using python's threads with its gtk
bindings.  i haven't looked recently to see how that's changed.  it's
too bad ruby's gtk/gnome bindings haven't yet found their way into
fedora extras.  i may have to join up and do it myself....

that said, interface stuff i'm currently working on is utilizing AJAX
techniques to interface with php and ruby back-ends.  so far i'm
finding this a lot more flexible in many ways than using some widget
set thanks to the extreme mutability of DHTML.  i also like the fact
that you can write one piece of software rather than two.  the back-end
generates its own interface.  for other things there's a degree of
clumsiness when dealing with the browser sandbox and trying to get it
to interact with other things on the system.  javascript can't do
system calls while system calls from php/cgi run as user apache.  this
is a deal-breaker for some of our stuff, but not an issue for many
other things.

tim

-- 
+--------------------------------------------------------------------+
|  T. E. Pickering, Ph.D.            |              MMT Observatory  |
|  Assoc. Staff Scientist            |           933 N. Cherry Ave.  |
|  tim(a)mmto.org  [phone]      |             Tucson, AZ 85721  |
+--------------------------------------------------------------------+
>  Ok, I see you know what you're doing :-) 
Either that or I've gotten pretty good at faking it.

[Joe Desbonnet]

I would love to see the DHTML/AJAX stuff in action, if it's convenient
to make available as a demo page.
Thanks,
Joe.

On 3/30/06, T. E. Pickering <tim(a)mmto.org&gt; wrote:

>  that said, interface stuff i'm currently working on is utilizing
> AJAX
>  techniques to interface with php and ruby back-ends.  so far i'm
>  finding this a lot more flexible in many ways than using some widget
>  set thanks to the extreme mutability of DHTML.  i also like the fact
>  that you can write one piece of software rather than two.  the back-end
>  generates its own interface.  for other things there's a degree of
>  clumsiness when dealing with the browser sandbox and trying to get it
>  to interact with other things on the system.  javascript can't do
>  system calls while system calls from php/cgi run as user apache.  this
>  is a deal-breaker for some of our stuff, but not an issue for many
>  other things.
>
>  tim
>
>  --
>  +--------------------------------------------------------------------+
>  |  T. E. Pickering, Ph.D.            |              MMT Observatory  |
>  |  Assoc. Staff Scientist            |           933 N. Cherry Ave.  |
>  |  tim(a)mmto.org  [phone]      |             Tucson, AZ 85721  |
>  +--------------------------------------------------------------------+
>  > Ok, I see you know what you're doing :-)
>
>  Either that or I've gotten pretty good at faking it.
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[T. E. Pickering]

>  I would love to see the DHTML/AJAX stuff in action, if it's
> convenient
>  to make available as a demo page. 
a publicly available one is at http://mmto.org/weather/.  that was
kinda my first hack at AJAX stuff to try it out.  other stuff is in
the pipeline, but either for internal use only or not quite ready. 

tim

-- 
+--------------------------------------------------------------------+
|  T. E. Pickering, Ph.D.            |              MMT Observatory  |
|  Assoc. Staff Scientist            |           933 N. Cherry Ave.  |
|  tim(a)mmto.org  [phone]      |             Tucson, AZ 85721  |
+--------------------------------------------------------------------+
When you are about to do an objective and scientific piece of investigation
of a topic, it is well to gave the answer firmly in hand, so that you can
proceed forthrightly, without being deflected or swayed, directly to the goal.
		-- Amrom Katz

[Dariusz J. Garbowski]

On 03/26/2006 05:05 PM, Nicolas Mailhot wrote:
>  Le samedi 25 mars 2006 à 12:06 +0000, Dariusz J. Garbowski a écrit :
> > .
> > But I can see that in some environments Java on the desktop may be a 
> > support issue.
>  
>  Java is only write-once, run everywhere if you define everywhere as a
>  very specific static OS image :( 
Come to think of that... Any multi-platform, multi-os or even 
multi-distro (where w95/w98/w2k/wxp can be called "distro" for the 
purpose of this argument) will suffer from mentioned support issues:

- different libraries available
- differnt environment
- etc...

This is why commercial applications are most of the time officially 
supported only on limited number of platforms, be it w2k/2xp and not 
w95/w98, be it Red Hat Enterprise and SuSE but not Debian and Mandrake, 
etc. :( There comes community help :-)

Regards,
Dariusz

	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com

[Nicolas Mailhot]

Le dimanche 26 mars 2006 à 17:58 +0100, Dariusz J. Garbowski a écrit :
>  On 03/26/2006 05:05 PM, Nicolas Mailhot wrote:
>  > Le samedi 25 mars 2006 à 12:06 +0000, Dariusz J. Garbowski a écrit :
>  >> .
>  >> But I can see that in some environments Java on the desktop may be a 
>  >> support issue.
>  > 
>  > Java is only write-once, run everywhere if you define everywhere as a
>  > very specific static OS image :(
>  
>  Come to think of that... Any multi-platform, multi-os or even 
>  multi-distro (where w95/w98/w2k/wxp can be called "distro" for the 
>  purpose of this argument) will suffer from mentioned support issues 
Sure, but other software communities recognize the problem and try to
create tools to ease the pain. Sun java is unfortunately often in denial
and lala-lala land when you try to tell them there is a wide margin
between write once and run everywhere in the actual world

-- 
Nicolas Mailhot

[Lamont R. Peterson]

On Sunday 26 March 2006 10:27am, Nicolas Mailhot wrote:
>  Le dimanche 26 mars 2006 à 17:58 +0100, Dariusz J. Garbowski a écrit
> :
>  > On 03/26/2006 05:05 PM, Nicolas Mailhot wrote:
>  > > Le samedi 25 mars 2006 à 12:06 +0000, Dariusz J. Garbowski a écrit :
>  > >> .
>  > >> But I can see that in some environments Java on the desktop may be a
>  > >> support issue.
>  > >
>  > > Java is only write-once, run everywhere if you define everywhere as a
>  > > very specific static OS image :(
>  >
>  > Come to think of that... Any multi-platform, multi-os or even
>  > multi-distro (where w95/w98/w2k/wxp can be called "distro" for the
>  > purpose of this argument) will suffer from mentioned support issues
>
>  Sure, but other software communities recognize the problem and try to
>  create tools to ease the pain. Sun java is unfortunately often in denial
>  and lala-lala land when you try to tell them there is a wide margin
>  between write once and run everywhere in the actual world 
I have yet to write Qt code on one platform that required any tweaking (except 
to add Windows Registry use when the "need" arose) to compile on all other 
platforms for which Qt is available and to which I have access.

Qt is great write once, compile many places portability.
-- 
Lamont R. Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409

[Joe Desbonnet]

Qt is a widget library / GUI framework. In most projects I've been
involved with our preferred language and platform determined the
choice of widget library, not the other way around.

Qt would be a great option if your are committed to C++. However it
would be a mistake to be forced to use C++ just to use Qt.

BTW: from experience Java is very portable across Windows / Linux for
server side and client side applications. Of course you need to test
as you develop on both platforms -- that applies to perl, python etc
also.  Outside of Linux/Windows you do have to work a little harder to
maintain portability with Java.

Getting a bit OT and religious for fedora I think...

Joe.




On 3/28/06, Lamont R. Peterson <lamont(a)gurulabs.com&gt; wrote:
>  On Sunday 26 March 2006 10:27am, Nicolas Mailhot wrote:
>  > Le dimanche 26 mars 2006 à 17:58 +0100, Dariusz J. Garbowski a écrit :
>  > > On 03/26/2006 05:05 PM, Nicolas Mailhot wrote:
>  > > > Le samedi 25 mars 2006 à 12:06 +0000, Dariusz J. Garbowski a écrit :
>  > > >> .
>  > > >> But I can see that in some environments Java on the desktop may be a
>  > > >> support issue.
>  > > >
>  > > > Java is only write-once, run everywhere if you define everywhere as a
>  > > > very specific static OS image :(
>  > >
>  > > Come to think of that... Any multi-platform, multi-os or even
>  > > multi-distro (where w95/w98/w2k/wxp can be called "distro" for the
>  > > purpose of this argument) will suffer from mentioned support issues
>  >
>  > Sure, but other software communities recognize the problem and try to
>  > create tools to ease the pain. Sun java is unfortunately often in denial
>  > and lala-lala land when you try to tell them there is a wide margin
>  > between write once and run everywhere in the actual world
>
>  I have yet to write Qt code on one platform that required any tweaking (except
>  to add Windows Registry use when the "need" arose) to compile on all other
>  platforms for which Qt is available and to which I have access.
>
>  Qt is great write once, compile many places portability.
>  --
>  Lamont R. Peterson <lamont(a)gurulabs.com&gt;
>  Senior Instructor
>  Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
>  GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
>
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>

[Rudolf Kastl]

2006/3/25, Dariusz J. Garbowski <thuforuk(a)yahoo.co.uk&gt;:
>  On 03/25/2006 10:59 AM, Nicolas Mailhot wrote:
>  > Le samedi 25 mars 2006 à 10:47 +0000, Dariusz J. Garbowski a écrit :
>  >
>  >>> If it where that easy, we'd have the latest eclipse version in Fedora
>  >>> with all the major plugins instead of the current situation.
>  >> Heh, it *is* that easy -- get Sun's Java stack, install, download your
>  >> app of choice, install and run!
>  >
>  > It's not, I'm sorry. You require lots of end-user work to make it
>  > anything like work. That's why a stupid app like the logitech remote
>  > controler (which has very simple fontionnality) is still not available
>  > for linux even if it was written in java to be cross-platform.
>
>  There's nothing in the applications themselves to stop working on Linux.
>  Work user has to put comes from the fact that distributions tend to make
>  user's life more difficult by not making it trivial to have e.g. Sun's
>  JRE installed (I don't want to blame distro developers here, Sun is
>  probably the most guilty by not allowing to repackage and redistribute
>  JRE). Yet situation is IMHO similar to proprietary NVidia drivers: users
>  just have it easier thanks to the work of Livna developers (at least on
>  Fedora). And, hey!, users still manage to install proprietary nvidia
>  drivers from NVidia rather than Livna, with all the hassle it makes!
>  Users are not stupid, they are ready and able to do quite a few things
>  when they have clear instructions.
>
>  Let's say we have "Livna JRE" to install using yum. What's missing to
>  make running Java apps trivial is making sure that there is at least a
>  simple shell script to run it from command line. Say, user opens up "Run
>  Command" dialog and types "jmeter" and it just starts. Of course the
>  script would need to line on $PATH. Other "use case" is user opens up
>  application's directory and double clicks the script. Application
>  starts. Many applications already do provide it: NetBeans, Eclipse,
>  JMeter...
>
>  Then a step further is packaging applications for distro, like each
>  other native application.
>
>
>  > For a developper java is easy. As soon as you need an average end-user
>  > to make it work and are paying the support costs it suddenly is no
>  > longer anywhere near a good choice.
>
>  Nothing to do with Java applications, it's all about packaging. If your
>  application is packaged for Linux, it will be easy to run! Vice versa it
>  can be difficult for Windows if it's not packaged for Windows. Where's
>  Java fault here?
>
>
>  > And I'm not even talking about the differences between jvm behaviour (if
>  > you think you can go sun-only just compare the arches sun, ibm and bea
>  > support)
>
>  You asked about *easy* way -- the easiest, least troublesome is to use
>  Sun's JRE. You are free to try other solutions too. You have this
>  freedom. It's good. Don't want problems? Try Sun first. If you really
>  need to run on more exotic hardware, you are likely to hit other issues,
>  yet it's a particular JRE's issue. Bug IBM/Sun/BEA to fix it :-)
>
>  Same with free stack. Everybody knows it's not quite there yet to run
>  all Java software. And yes there's a few Java apps out there using sun.*
>  packages -- not a Java issue either. Bug application developer to fix it
>  so it's ready for free stack.
>
>  Want to avoid as much issues as you can? Get Sun's JRE and make sure
>  it's on your PATH before free stack is.
>
>  Regards,
>  Dariusz
>
>
>
>
>  ___________________________________________________________
>  Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
> http://uk.messenger.yahoo.com
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  
theres gcj... why would a linux user make his source dependendant on
non free things?

regards,
rudolf  kastl

[Rudolf Kastl]

2006/3/28, Rudolf Kastl <che666(a)gmail.com&gt;:
>  2006/3/25, Dariusz J. Garbowski <thuforuk(a)yahoo.co.uk&gt;:
>  > On 03/25/2006 10:59 AM, Nicolas Mailhot wrote:
>  > > Le samedi 25 mars 2006 à 10:47 +0000, Dariusz J. Garbowski a écrit :
>  > >
>  > >>> If it where that easy, we'd have the latest eclipse version in
> Fedora
>  > >>> with all the major plugins instead of the current situation.
>  > >> Heh, it *is* that easy -- get Sun's Java stack, install, download your
>  > >> app of choice, install and run!
>  > >
>  > > It's not, I'm sorry. You require lots of end-user work to make it
>  > > anything like work. That's why a stupid app like the logitech remote
>  > > controler (which has very simple fontionnality) is still not available
>  > > for linux even if it was written in java to be cross-platform.
>  >
>  > There's nothing in the applications themselves to stop working on Linux.
>  > Work user has to put comes from the fact that distributions tend to make
>  > user's life more difficult by not making it trivial to have e.g. Sun's
>  > JRE installed (I don't want to blame distro developers here, Sun is
>  > probably the most guilty by not allowing to repackage and redistribute
>  > JRE). Yet situation is IMHO similar to proprietary NVidia drivers: users
>  > just have it easier thanks to the work of Livna developers (at least on
>  > Fedora). And, hey!, users still manage to install proprietary nvidia
>  > drivers from NVidia rather than Livna, with all the hassle it makes!
>  > Users are not stupid, they are ready and able to do quite a few things
>  > when they have clear instructions.
>  >
>  > Let's say we have "Livna JRE" to install using yum. What's missing
> to
>  > make running Java apps trivial is making sure that there is at least a
>  > simple shell script to run it from command line. Say, user opens up "Run
>  > Command" dialog and types "jmeter" and it just starts. Of course the
>  > script would need to line on $PATH. Other "use case" is user opens up
>  > application's directory and double clicks the script. Application
>  > starts. Many applications already do provide it: NetBeans, Eclipse,
>  > JMeter...
>  >
>  > Then a step further is packaging applications for distro, like each
>  > other native application.
>  >
>  >
>  > > For a developper java is easy. As soon as you need an average end-user
>  > > to make it work and are paying the support costs it suddenly is no
>  > > longer anywhere near a good choice.
>  >
>  > Nothing to do with Java applications, it's all about packaging. If your
>  > application is packaged for Linux, it will be easy to run! Vice versa it
>  > can be difficult for Windows if it's not packaged for Windows. Where's
>  > Java fault here?
>  >
>  >
>  > > And I'm not even talking about the differences between jvm behaviour (if
>  > > you think you can go sun-only just compare the arches sun, ibm and bea
>  > > support)
>  >
>  > You asked about *easy* way -- the easiest, least troublesome is to use
>  > Sun's JRE. You are free to try other solutions too. You have this
>  > freedom. It's good. Don't want problems? Try Sun first. If you really
>  > need to run on more exotic hardware, you are likely to hit other issues,
>  > yet it's a particular JRE's issue. Bug IBM/Sun/BEA to fix it :-)
>  >
>  > Same with free stack. Everybody knows it's not quite there yet to run
>  > all Java software. And yes there's a few Java apps out there using sun.*
>  > packages -- not a Java issue either. Bug application developer to fix it
>  > so it's ready for free stack.
>  >
>  > Want to avoid as much issues as you can? Get Sun's JRE and make sure
>  > it's on your PATH before free stack is.
>  >
>  > Regards,
>  > Dariusz
>  >
>  >
>  >
>  >
>  > ___________________________________________________________
>  > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
> http://uk.messenger.yahoo.com
>  >
>  > --
>  > fedora-devel-list mailing list
>  > fedora-devel-list(a)redhat.com
>  > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  >
>
>  theres gcj... why would a linux user make his source dependendant on
>  non free things?
>
>  regards,
>  rudolf  kastl
>  
personally i use pygtk and python ... pretty easy to rad develop good
looking and fast (compare swing lol) gui applications. Pretty trivial
to build the gui in  glade/gazpacho and then just autoattach the
signals.  theres also the zope application server actually.

regards,
Rudolf Kastl

[Kenneth Porter]

--On Tuesday, March 28, 2006 11:31 AM +0200 Rudolf Kastl <che666(a)gmail.com&gt; 
wrote:

>  why would a linux user make his source dependendant on
>  non free things? 
Sometimes the functionality you need isn't available for free.

[Dariusz J. Garbowski]

On 03/28/2006 04:46 PM, Kenneth Porter wrote:
>  --On Tuesday, March 28, 2006 11:31 AM +0200 Rudolf Kastl 
>  <che666(a)gmail.com&gt; wrote:
>  
> > why would a linux user make his source dependendant on
> > non free things?
>  
>  Sometimes the functionality you need isn't available for free. 
Sorry for late answer (I went for holidays) but Kenneth answered for me 
;-) In any case I'm looking forward to being able to run any Java code 
on free stack without trying to figure out where the problem is and 
being able to tell that it's most likely an application issue (eg. the 
app using com.sun.* packages).

Regards,
Dariusz

	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com

[Andrew Overholt]

* Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt; [2006-03-25 05:12]:
>  On the client part it's a shockingly bad idea (and I include
> applets
>  there). Googling will find you boatloads of apps that choose java for
>  portability and still can not run on anything else than windows, because
>  just deploying the right JVM on all the systems you may target is a
>  major problem (and I'm not even counting the free stacks there).
>  
>  If it where that easy, we'd have the latest eclipse version in Fedora
>  with all the major plugins instead of the current situation. 
Perhaps I'm missing context here, but I sense an implication that something
is wrong with "the current situation".  Am I correct?

Andrew

[Dimi Paun]

From: "Andrew Overholt" <overholt(a)redhat.com&gt;
>  Perhaps I'm missing context here, but I sense an implication that
something
>  is wrong with "the current situation".  Am I correct?
Well, now that you mention it... :)
If I point the native Eclipse to one of my workspaces
that I created (and worked in) with the Java Eclipse,
it doesn't recognize it as a workspace at all, and
gives me the Welcome screen.

Trying to "Switch workspace" from the File menu has
the same effect. What gives?

-- 
Dimi Paun <dimi(a)lattica.com&gt;
Lattica, Inc.

[Andrew Overholt]

* Dimi Paun <dimi(a)lattica.com&gt; [2006-03-27 12:51]:
>  From: "Andrew Overholt" <overholt(a)redhat.com&gt;
>  > Perhaps I'm missing context here, but I sense an implication that
>  > something is wrong with "the current situation".  Am I correct?
>  
>  Well, now that you mention it... :)
>  If I point the native Eclipse to one of my workspaces that I created (and
>  worked in) with the Java Eclipse, it doesn't recognize it as a workspace
>  at all, and gives me the Welcome screen. 
That's odd.  I've never seen this behaviour before.  Please file a bug.

Andrew

[Dimi Paun]

From: "Andrew Overholt" <overholt(a)redhat.com&gt;
>  That's odd.  I've never seen this behaviour before.  Please
> file a bug. 
Here you go:
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186958

-- 
Dimi Paun <dimi(a)lattica.com&gt;
Lattica, Inc.

[Michael Favia]

Dimi Paun wrote:
>  From: "Andrew Overholt" <overholt(a)redhat.com&gt;
> > Perhaps I'm missing context here, but I sense an implication that
>  something
> > is wrong with "the current situation".  Am I correct?
>  
>  Well, now that you mention it... :)
>  If I point the native Eclipse to one of my workspaces
>  that I created (and worked in) with the Java Eclipse,
>  it doesn't recognize it as a workspace at all, and
>  gives me the Welcome screen.
>  
>  Trying to "Switch workspace" from the File menu has
>  the same effect. What gives?
>   
wfm. no reproduce.

-- 
Michael Favia          michael.favia(a)insitesinc.com
Insites Incorporated  http://michael.insitesinc.com

[Nicolas Mailhot]

Le lundi 27 mars 2006 à 12:23 -0500, Andrew Overholt a écrit :
>  * Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt; [2006-03-25
> 05:12]:
>  > On the client part it's a shockingly bad idea (and I include applets
>  > there). Googling will find you boatloads of apps that choose java for
>  > portability and still can not run on anything else than windows, because
>  > just deploying the right JVM on all the systems you may target is a
>  > major problem (and I'm not even counting the free stacks there).
>  > 
>  > If it where that easy, we'd have the latest eclipse version in Fedora
>  > with all the major plugins instead of the current situation.
>  
>  Perhaps I'm missing context here, but I sense an implication that something
>  is wrong with "the current situation".  Am I correct? 
The current situation is good but could be better. Lots of Eclipse stuff
is not packaged right now (WTP...). Though it's no fault of the
packagers, just that's there is a wide gap between writing and deploying
sanely java code on the desktop.

The Fedora java project is doing great stuff, given what they have as
input.

Regards,

-- 
Nicolas Mailhot

[Tom Tromey]

> >>>> "Nicolas" == Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net&gt; writes: 
Nicolas> The current situation is good but could be better. Lots of
Nicolas> Eclipse stuff is not packaged right now (WTP...). Though it's
Nicolas> no fault of the packagers, just that's there is a wide gap
Nicolas> between writing and deploying sanely java code on the
Nicolas> desktop.

Eclipse plugins are particularly a pain to build, I think more than
ordinary java programs.

I end up installing some plugins I like via the update sites.  This is
not super convenient, since it means I have another few hoops to jump
through after installing FC, but it isn't terrible.

Nicolas> The Fedora java project is doing great stuff, given what they have as
Nicolas> input.

Thanks :-)

Tom

[Kenneth Porter]

--On Friday, March 24, 2006 8:33 PM -0700 "Lamont R. Peterson" 
<lamont(a)gurulabs.com&gt; wrote:

>  Trust me, I've written enough code in various languages and using
> various
>  frameworks and toolkits to know that when you want stable, simple,
>  reliable  cross-platform code, Qt is excellent. 
I was looking at Qt. The developer license is pricey but probably doable. 
What does it provide for the kinds of controls I mentioned? Do you know of 
any demo apps I can look at that illustrate how well they function?

As an example of the kind of app I'm thinking of, consider a model train 
control panel which can control the speeds of various locomotives and 
report track conditions in real time (eg. graphing the impedance of the 
tracks).

For an example of the kinds of controls I'm looking for, National 
Instruments' Measurement Studio is an instrumentation GUI control library:

<http://www.ni.com/mstudio/>

And as you can see, there's no Linux port.

[Alan Cox]

On Mon, Mar 27, 2006 at 09:46:45AM -0800, Kenneth Porter wrote:
>  I was looking at Qt. The developer license is pricey but probably
> doable.  
Its free for free software

>  As an example of the kind of app I'm thinking of, consider a
> model train 
>  control panel which can control the speeds of various locomotives and 
>  report track conditions in real time (eg. graphing the impedance of the 
>  tracks). 
I take it you know about jmri, although its java not C and doesn't seem to 
like gcj yet

Alan
--
	"We didn't have the money so we had to think harder"
			- Colin Pillinger

[Jean-Luc Fontaine]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenneth Porter wrote:

>  I'm tasked to write a front end for an instrumentation
> application
>  for "that other operating system" ;) and I'd like to use GUI
>  controls that are cross-platform portable for an eventual Linux
>  port. What would the list recommend? I essentially need something
>  that resembles the front panel of an oscilloscope, along with some
>  dial indicators and knobs. I've also been thinking about making it
>  web-accessible, so perhaps a Java-based solution would be suitable.
>
>  
Tcl/Tk (in FC), with BLT/Tktable (in FE) for graphs/spreadsheet
tables, Vu extension for dials, tcllib (in FE) for HTTP, ....
These are completely cross-platform and free software. See moodss in
FE to get an idea about a GUI built with those.

- --
Jean-Luc Fontaine  http://jfontain.free.fr/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFEJSPdkG/MMvcT1qQRAj88AJ9njivNG4AF8jVKZpE2by2hYK8H2gCgvdO8
> k9em7sSTDkbw9FYa0RYnAuM=
> =tB9D
> -----END PGP SIGNATURE-----