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.
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.
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.
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
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
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)
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
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.
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
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
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.
--On Tuesday, March 28, 2006 1:03 AM -0700 "Lamont R. Peterson" lamont@gurulabs.com 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.
On Tuesday 28 March 2006 07:44am, Kenneth Porter wrote:
--On Tuesday, March 28, 2006 1:03 AM -0700 "Lamont R. Peterson"
lamont@gurulabs.com 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.
--On Tuesday, March 28, 2006 9:06 AM -0700 "Lamont R. Peterson" lamont@gurulabs.com 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.
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.
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
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@mmto.org 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@mmto.org (520) 626-3755 | 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
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
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
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
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.
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@gurulabs.com 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@gurulabs.com 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
2006/3/25, Dariusz J. Garbowski thuforuk@yahoo.co.uk:
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@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
2006/3/28, Rudolf Kastl che666@gmail.com:
2006/3/25, Dariusz J. Garbowski thuforuk@yahoo.co.uk:
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@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
--On Tuesday, March 28, 2006 11:31 AM +0200 Rudolf Kastl che666@gmail.com wrote:
why would a linux user make his source dependendant on non free things?
Sometimes the functionality you need isn't available for free.
On 03/28/2006 04:46 PM, Kenneth Porter wrote:
--On Tuesday, March 28, 2006 11:31 AM +0200 Rudolf Kastl che666@gmail.com 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
* Nicolas Mailhot nicolas.mailhot@laposte.net [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
From: "Andrew Overholt" overholt@redhat.com
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@lattica.com [2006-03-27 12:51]:
From: "Andrew Overholt" overholt@redhat.com
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
From: "Andrew Overholt" overholt@redhat.com
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 wrote:
From: "Andrew Overholt" overholt@redhat.com
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.
Le lundi 27 mars 2006 à 12:23 -0500, Andrew Overholt a écrit :
- Nicolas Mailhot nicolas.mailhot@laposte.net [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" == Nicolas Mailhot nicolas.mailhot@laposte.net 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
--On Friday, March 24, 2006 8:33 PM -0700 "Lamont R. Peterson" lamont@gurulabs.com 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:
And as you can see, there's no Linux port.
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
-----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/
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Andrew Overholt -
Dariusz J. Garbowski -
Dimi Paun -
Jean-Luc Fontaine -
Joe Desbonnet -
Kenneth Porter -
Lamont R. Peterson -
Michael Favia -
Nicolas Mailhot -
Ralf Ertzinger -
Rudolf Kastl -
T. E. Pickering -
Tom Tromey