|
Programming C, bash, Python, Perl, PHP, Java, you name it. |
|
Thread Tools | Display Modes |
|
|||
Crossplatform UI Work
G'day all,
I hope that you might forgive this terribly "newbie" question... I have had a look around and I cannot actually find anything so I am at the point of asking. I wish to put together a simple application, mostly for personal use for now, but I would like to look into the future and supply some cross-platform compatibility. As a BSD user I have issues with many licenses (yes, I'm one of them, if you must) so I am interesting in learning how I could achieve something like this... I am not terribly apt with C/C++ but I am more than willing to learn (I should have a fair bot of time after November through to March and I would like to keep thinking in it). Basically what I want to know is: a) How are things like, say, Blackbox rendering things on X11? b) Is it easy to port this to, say, Windows, or is it almost a complete re-write? c) Where can I find information on how to do this, more or less, from scratch (or as needs be, from a BSD license)? Any knowledge on how this is done regarding X11 or how I might do it for a specific platform (BSD, Linux and Solaris I imagine should be similar if not the same; Windows; Mac) would be greatly appreciated. Regards, Alex. |
|
|||
Blackbox is a window manager, so I doubt there is anything that it does that isn't already available in more basic X Window primitives. You can always dig up its code & study it.
Quote:
If you are both new & concerned about porting, you might want to consider a cross-platfom toolkit like:
Last edited by ocicat; 21st October 2008 at 10:58 AM. |
|
|||
Yes, I did look at the corss-platform toolkits but I take offence to licenses fairly easily.
I'm in the process of backing up an encrypted partition from my laptop using a recovery CD as the main OS is playing up and it's overdue for my master plan (OpenSolaris + Xen), so I'll be pulling the source apart soon. Wasn't sure if that's all it was or there was something I was missing (I've never tried basic X stuff either). wxPython or Cairo are the least offensive licenses I've seen... I could write it in Java, I've been considering it, but I'd need a serious brush up having not used Java properly at all or in a long time Thanks. |
|
|||
blackbox/fluxbox sit directly atop of Xlib, porting it to a toolkit would be difficult.. one project "bb4win" clearly realized this, they rewrote almost everything from scratch.
Now, is using Xlib a bad thing? not really.. every modern OS has a native X server available, even if done by a 3rd party, so technically.. it's quite portable.. Still.. some people wouldn't like that requirement.. one option would be GDK, the low-level API used by GTK+.. or GTK+ for that matter. Both GTK+/GDK are under the LGPL vs the GPL, the "lesser" of 2 evils if you will.. but I've given it too much credit. |
|
||||
This is a thread I will reply to, because it is one I have given much thought to previously -> not just the GUI toolkit, but the entire personal framework of libs, tools, and langs for getting stuff done.
The major toolkits are: Code:
GTK Supports: C, C++, Java, PHP, Perl, Python, Ruby, C#, and probably Guile (scheme) Working with gtkmm (C++ bindings) on Win32 can be a bit of a pain in the butt to setup the development environment, to actually be able to compile and link (pkg-config != fun on win). You'll also need the gnu compiler. I've found GTK works best for Python if your goal is ease of portability. One advantage of GTK is it a few of the libraries commonly supporting it are also portable; with about as much pain as noted above ^ Don't bother with Java/Ruby bindings for GTK if you want to run on Windows, without getting 'jiggy with it' I've yet to use the PHP bindings, but they should be quite useful under Linux/BSD/Win Qt Supports: C++, Java, PHP, Perl, Python, Ruby, C#. Qt is natively C++, so you will need to understand C++ to read the documentation. It is a fine toolkit and portable (Unix, Mac, Win). The thing I like the most about Qt, it makes programming GUIs as painless as possible, while still being powerful. The only portable bindings you can count on (with ease) are C++ and Python for Qt4. Ruby and Perl bindings are currently broken on FreeBSD and do not support Win32. The PHP/C# bindings are likely far from mature but I've yet to try them out. The Java bindings have binaries for Linux/ Mac/Win32, but it's not in FreeBSD ports. The open source edition supports GCC on all the big targets; the professional edition will allow support for other compilers (MSVC++, Intel, probably HP-UX's, whatever) WxWidgets Supports: C++, Java, Python, Perl, Ruby, C#, Euphoria, Haskell, JavaScript, Lua, Squeak, and their own form of BASIC. Unlike GTK/Qt which only offer the ability to emulate native widgets through themes; WxWidgets uses native widgets and an abstraction library to call the native code. WxWidgets is a great toolkit, but one that I dislike the API of... but it's a great tool. Works well for C++ and Python; I've not tried the Java or C# bindings but they should work well. The bindings are fairly portable, but I would suggest using either C++, Python, or Ruby if you're working on FreeBSD most often. WxWidgets supports many C++ compilers, including GCC, MSVC++, and OpenWatcom. Tk/Tkinter Never used them, should be as portable as TCL. Should work well for Python, Perl, Ruby, and TCL at least. Without going into Java's AWT/Swing/SWT and trying to use them via Jython and such stuff... lol. For the most portable, I'd suggest GTK (Python/C), Qt (C++/Python), or WxWidgets (C++/Python). Qt and WxWidgets also have a good set of supporting classes to help out with a few odds and ends (e.g. regex), and GTK probably has the most widgets out of box. For working on software that is supposed to run on FreeBSD, Windows, Linux, and hopefully Mac OS X as painlessly as possible for the FreeBSD/Win using coder. I've found Python to be the single best language, unless you want to use Java. Ruby may as well be forgotten for cross platform work with GUIs IMHO. C++ will work quite well, if you are willing to deal with the portability and build issues. If not, go with Python. One reason I suggest Python + GTK / Qt / WxWidgets -> you have free choice of toolkit and many other libraries that are either standard issue or easy to install on FreeBSD / Win / Linux. Under C++ where there is a much smaller set of standard features, you need to factor your libraries portability as well, much much more so then in Python. An example, do you use regex from the same library most POSIX-basd apps use, Boost, Qt, WxWidgets, write your own, etc. Having rubber banned between ~6 languages and 2 operating systems a lot, switching to Python and a 'choice' set of libraries as made my life much more productive, then cursing at Windows for being an annoying development platform, outside of the Wintellectuals. If you're not familiar with any GUI tookkits, learning the basics of C++ and then starting with the Qt documentation is a good way b/c it is very well documented -> the Qt docs also reference many good books. Just my $0.25 opinion.
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
||||
If you need good cross platform GUI then PyGTK is for you:
http://pygtk.org/about.html Runs good at UNIX (Including Mac OS X) and Windows.
__________________
religions, worst damnation of mankind "If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”. vermaden's: links resources deviantart spreadbsd |
|
||||
For portability, compiled languages definitly have a disadvantage. You're probably well off to go with an interpretted language with a portable GUI API (such as the suggestions of Python and PyGTK), with a pseudo-code language with its own GUI API (like Java), or a pseudo-code language with a portable GUI API (like C# and Gtk#).
Using C or C++ will generally make portability more difficult than using an interpretted or pseudo-code language, where compatibility issues are constrained to the implementation (not a big deal for something like Windows .NET versus Mono .NET, or Java, and a virtually non-existant consideration for interpretted languages such as Python, Ruby, or Perl), and to the actual file and directory access (Windows uses C:\ where we use /, for example) and things of that nature, which exist as a concern which can be comparatively easily mitigate in any language, regardless of type. |
|
||||
If performance is important, then let the project use some interpreted language (like PyGTK) and write most important things/functions/algorithms in C.
__________________
religions, worst damnation of mankind "If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”. vermaden's: links resources deviantart spreadbsd |
|
|||
Ta guys!
Quote:
I looked at wxWidgets a while ago, I should look into it again. I mostly use Python, so that makes things easier in a sense... I was looking at PyGTK + PyCairo a while ago... Actually the wxWidget license looks good; as I said, I'm happy to give the code away but I wanted the choice of license I did that under... Thanks again guys |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
trunk0 does not work as expected | gosha | OpenBSD General | 0 | 1st August 2009 12:07 PM |
ATI Catalyst.... Does it work? | echoblack | OpenBSD Installation and Upgrading | 10 | 17th June 2009 09:04 AM |
ln -f at boot doesn't work | lordyan | OpenBSD General | 3 | 19th February 2009 03:50 PM |
Any chance to make work in FreeBSD ? | giga | FreeBSD General | 2 | 30th January 2009 10:07 PM |
Getting Qt4 to work on FreeBSD | enpey | FreeBSD Ports and Packages | 6 | 6th May 2008 07:20 AM |