This project is read-only.

Which GUI Would You Prefer?

May 9, 2010 at 10:24 PM
Edited May 9, 2010 at 10:29 PM

In the sake of delivering a workable client GUI binary the fastest, I'd like to hear from you about which platform you'd like to see delivered first.  The choice of platform dictates the programming language and focus of development.  For instance, for Linux/FreeBSD/Solaris/(and I guess Windows, too), a Java GUI would be focused on.  If Windows is the primary contender, then a Windows native binary (I code on Windows Server 2008 R2) would be delivered.  Also, since the RS232 serial and USB communication isn't compatible on Java (unless we distribute TXRX with the package), the connection mechanisms are fairly different. 

So, what do you prefer?  Have an opinion?  Here are some starters:

1. Windows
2. Linux
3. MacOS X
4. FreeBSD
5. Solaris

We probably won't be delivering a binary for OS2 Warp, as that may be a little esoteric for us but we're all ears.

Sep 17, 2010 at 5:36 PM

Aren't you lonely being the only one on here? That is to say, where are you for advertising? How did you intend to increase the user base?

Down to business, It's my understanding that FreeBSD being Unix-based, Linux source code for the client should compile and run on FreeBSD.

If there is ever a vote for Solaris, I will delete this post and bite my tongue off becoming mute; It's a nice system, but I havent heard anyone bring it up in years, and have only ever heard it joined with enterprise servers.

SO, shorten the List to win/lin/mac, or do away with the list entirely! I use all 3, at least 2 a day; between my Dell Inspiron 1545 Hackintosh (Mac), my HP mini 1030NR (7) and my home server (Linux).

Make the client available to these three platforms. I personally dislike win-systems and would vote for mac/lin like a large portion of the enlightened (DIY'ers, Hackers/Modders, Programmers, Engineers), the majority of computer users have a win-os. So then the native client should be for the Windows Platform, and Secondarily for Mac/Lin. But I would suggest a cross platform solution other than [slow] java: Python, build the libraries into the binary. It would extract where told as python files, modules, libraries, and a platform dependent executable to bring it all online.

Sep 21, 2010 at 9:59 AM

I've long since gotten used to being the singular driver for a given project.  It's strange for me when I'm thrown into the middle of projects with a large cast of developers since I'm used to flying solo on so many projects, although having a large cast of developers for a project sure is nice sometimes.  We don't have any budget for advertising besides posting to common-interest websites when the project goes into BETA.  As for increasing the user base, that's a tough one.  Our current strategy has been trying to get high hits on google searches for certain key words, but we've let that lapse a bit.  Any suggestions for free advertisement?

Ok, so sit down for a sec....this may hurt. :)  About 90% of the server software development has been on Open Solaris, although it ports and compiles currently on Solaris (x86), FreeBSD (x86/64), and Ubuntu Linux (x86_64).  It hasn't been tried on mac darwin or windows yet.  However, since Oracle bought Sun and they basicially trashcanned Open Solaris, all the work has moved to Ubuntu Linux machines and continues there.  The server runs on a multi-processor machine that is binary compatible with any of our FreeBSD or Linux boxen we have been developing on, so ultimately, the server software platform will probably be determined by which platform it performs better on.

I think we're going down the road you suggest in that we are supporting windows, linux, and mac (more in that order) regarding client apps, although the current client prototype is in C++ on Windows.  If we went to a multi-platform GUI it would probably have to be Java as that's the experience we have inhouse, although there is some clamoring for Qt which could work on all platforms, once written.  Just, again, there's not a lot of experience with Qt here so there would be some consider spin-up time on getting to the level of proficiency we'd probably need, but Qt seems promising.  The Python issue is partially the same thing: there's not expert level experience with python here and those that have used it say it's ugly to write and prone to having incompatibility problems between even minor versions, which would mean probably having to provide a compiled native binary for each platform of python.

These are some good thoughts you've brought up.  Thanks for giving us your input!

Oct 28, 2010 at 11:48 AM

We've shortened the list of supported operating systems from four platforms to two supported/target platforms:  Linux and Windows
Target cross-platform tool or SDK:  Qt

Thanks for your suggestion.