On Jul 16, 10:25 pm, vasudevram <[EMAIL PROTECTED]> wrote: > [ Though the OP posted his message to comp.lang.ruby, I'm cross- > posting it to comp.lang.python, since he mentions Python as a possible > alternative he's looking at, and also because I've recommended Python > for his stated needs. Also, interested to see what other Pythonistas > have to say in response to my reply. > - Vasudev] > > > On Jul 16, 2007, at 2:21 AM, Michael Reiland wrote: > > At the heart of the issue is the fact that I refuse to use Java for this > > project, I prefer not to use .Net because of the portability issues, > and > I'd like to get away from C++ for obvious reasons. > > > To me this means Ruby, Python, or, as mentioned above, Perl. If anyone > > can tell me of a way to meet the above requirements in either Python > or > Perl, I'm all ears (I just prefer Ruby). > > Yes, I think it would be really great for the Ruby community and for > the growth of the language if wxRuby was more mature as a GUI toolkit. > (Not knocking the wxRuby developers at all, its great that they've > even done what they have - I know that creating other language (like > Ruby) bindings to a C++ lib is a non-trivial task). > > My suggestion: Python + wxPython + Python DBI + (Py2Exe + InnoSetup) > *might* meet all your needs. (As with any decision about what software > technologies to use, you'll have to evaluate the suggested options to > see if they fit your needs.) > > Note: I've used and like both Ruby and Python (saying this after using > many, though not all, language features and libraries of both > languages), and am not trying to discourage you from using Ruby for > your needs; its just that, based on your needs as described, it looks > to me as if Python meets them better than Ruby at present: > > > 1. GUI - Native Look and Feel. According to wxRuby the bindings aren't > > mature enough for production use. Does anyone have any experience > with > this and/or can you offer alternatives that provide a native look and > feel (I > > I don't know enough about wxRuby to comment. > > wxPython has this (Native Look and Feel), I think (used it some, a > while ago), not 100% sure, you can check on the site - http:/www.wxpython.org > - to make sure. The site does say that it is cross-platform: > > "wxPython is a cross-platform toolkit. This means that the same > program will run on multiple platforms without modification. Currently > supported platforms are 32-bit Microsoft Windows, most Unix or unix- > like systems, and Macintosh OS X. > " > > but that doesn't necessarily mean that it will have native look and > feel on all supported platforms. (The two are not the same thing.) > That's why you will need to check. > > wxPython pros: Its fairly easy to learn, at least for simple GUI apps > (e.g. a few widgets / controls and a file dialog or two). I was able > to build these simple ones - see the code, article and screenshots > available here (or from links from here): > > http://www.packtpub.com/article/Using_xtopdf > > - in quite a short time, starting from zero knowledge of wxPython (I > did know some Python from before), just by looking at the sample apps, > and some reading of the docs. > > See the quotes about wxPython:http://www.wxpython.org/quotes.php > > >2. Databases - contemplating using ActiveRecord, but I would like to use > > ODBC to support multiple types of DB's in a uniform way (if you know > of > alternatives to ODBC or ActiveRecord, please let me know). > > I think, but again, not sure, that Python DBI + appropriate database > drivers, may meet this need. Basically Python DBI is similar to ODBC > (roughly), and to Perl DBI + DBD, as I understand. There's also ODBC > support in the Win32 extensions package for Python - IIRC, Google for > 'win32all' to get it. Its also available as a link from the Python for > Win32 MSI installer on python.org. > I've used Python ODBC some, it works and is easy to use. > See this for a simple example: > > http://jugad.livejournal.com/2006/07/07/ > > (See the second post at that page, titled "Publishing ODBC database > content as PDF > ". The code shown in the post is not indented as per proper the Python > syntax (LiveJournal messed up the indentation), sorry about that, but > its trivial to correct if you know Python indenting rules). Also read > the Python ODBC docs and examples, of course. > > >3. Binary - Are there any utilities for compiling Ruby into a binary > > executable? The issue is twofold, speed, and not handing the > customer > the source :) > > For Python, there is py2exe (for Windows only). I used py2exe recently > and it works well enough for the simple cases that I tried. (I tried > building EXEs for a simple Python hello-world program, and for a > simple wxPython GUI app based on my xtopdf toolkit. Both worked ok.) > For cross-platform (Windows and Linux, IIRC), there is PyInstaller > (Google for it), haven't tried it out yet, just downloaded it > recently. > > I don't think you'll gain much speed by this compiling step, though > (over and above what Python gives you itself, when it compiles > your .py files to .pyc files). The purpose of py2exe is more to hide > the source code than to speed it up, as I understand (could be wrong). > > Note: py2exe only creates an EXE and DLLs needed, from your source and > its required Python modules. To create an installer, try InnoSetup > (for Windows only). I recently tried it out, version 5, again, it > worked well. Could create Windows SETUP.EXE-type installers for the > two EXEs described above. Worked ok. > > I first learned Python, have been using it for some time for various > projects, and then learned Ruby, and have done some projects with Ruby > too. > > I've been reading both the Ruby Cookbook and the Python Cookbook > rather thoroughly in the last few weeks (and trying out and modifying > many of the recipes), and what I've observed is that the two languages > are roughly similar in features. For basic features common to most > languages (constants, variables, arrays, hashes/dictionaries, file I/ > O, classes, objects, modules/libraries, etc. - they work roughly in > the same fashion - though syntax obviously differs, you can mostly do > what you can in one of them, in the other as well. (Note that I'm not > talking about libraries here - this will obviously differ as each > language will have its own set of libraries for doing various tasks, > like networking and other areas - though even here there is a good > amount of overlap/similarity.) > > For more advanced language features related to object-orientation, > metaclasses / metaprogramming, both have some support, but you might > or might not be able to do in one, what you can do in the other. > > HTH > Vasudev Ram > Site:http://www.dancingbison.com > PDF toolkit (in Python):http://sourceforge.net/projects/xtopdf > Blog:http://jugad.livejournal.com
P.S.: Some more thoughts: If you'd really prefer to work in Ruby, but find after investigation, that the wxPython recommendation I've made is worth pursuing, you could check out this other approach: - Write the GUI in Python + wxPython - Write the rest of the app - the back end - in Ruby. - Connect the two via any one of the following distributed computing technology options: - sockets (lowest level, more coding needed, need to create your own proprietary, application-specific (though not necessarily very difficult) "protocol" on top of the sockets layer - XML-RPC (less coding than sockets, fairly easy to code with, supports most/all basic scalar data types (string, int) of Python/ Ruby, also supports 'structs' and arrays. XML-RPC structs are not really structs in the C sense, they more or less map to hashes/ dictionaries of Ruby/Python respectively. A Binary XML-RPC data type is also available, it works by Base-64 encoding your binary data. Have tried out this type as well as the simple scalar types, they work. (E.g. I could generate a PDF file on the server in response to a client method call, and send the PDF back to the client as the method response, using the Binary data type.) In XML-RPC you can either use the register_instance or register_function functions to register your class's callable methods or your standalone callable functions so the client can call them. Each of these approaches (register_function vs. register_instance) has its pros and cons - e.g. IIRC, you can register any number of functions, but you can only register one instance of an object - so if using this approach, you'd need to either a) have all your callable code in one class, or make that one class a manager/controler class that delegates to other classes to do the needed work. - SOAP. Ruby's stdlib has SOAP support. Python has SOAPpy and a few others, not sure whether those projects are active and supported currently. You will need to check this out. Comments similar to those for XML-RPC above. - ICE from ZeroC - www.zeroc.com . This is like a lighter CORBA. Some of the key developers are prior CORBA experts, like Michi Henning who wrote a well-known C++/CORBA book. But check out the licenses for ICE; IIRC, the open source version is under the GPL. You have to pay for a commercial license. ICE supports Python for both client and server, has Ruby support (need to check if both client and server, or client only). - HTTP calls. Use Webrick or Mongrel HTTP server libraries - you can "mount" instances of classes into the HTTP servers that these libraries allow you to create and run. (This is similar to Java servlets running inside a Java servlet container.) "Call" the methods of these instances from the Python + wxPython GUI front end via the appropriate HTTP client library (urllib or urllib2 or httplib2) for Python, open-uri for Ruby. I've checked this out (briefly), it works, and is a neat and somewhat powerful technique, IMO. (What this implies is that the client for your HTTP server, need not be a browser - it can be a command-line or GUI client; and, though you're using HTTP, you need not use HTML, and in particular, you need not render HTML in your client; you can, for instance, use XML and generate/parse it at either end.) HTH Vasudev www.dancingbison.com -- http://mail.python.org/mailman/listinfo/python-list