Tk on Windows and Mac OS X 10.6
in [Ruby]
|
From: mdiam on 20 Feb 2010 05:01 On Feb 19, 3:26 pm, saLOUt <salout...(a)googlemail.com> wrote: > > My idea would be to create a stand alone ruby sumo distrib (rubylab ?) > > with Ruby + Tk + Qt + FFI + some science selected extensions. > > Didn't read everything. Just want to mention that there will be a Qt- > Ruby-Gem for Windows release very soon. For Linux there should be pre- > build packages available for most common distributions. > > First adress for ruby + Qt/KDE:http://lists.kde.org/?l=kde-bindings Great new, thank you for the link. (I hope the Qt-Ruby-Gem will be multiplatform) -- Maurice
From: mdiam on 20 Feb 2010 05:13 On Feb 19, 6:13 pm, Roger Pack <rogerpack2...(a)gmail.com> wrote: > > If you have a recipe on how to build this full Ruby/Tk distrib from > > sources, I could test it on Macosx and some linux. > > These source would be : > > - ruby-1.9xxx > > - tcltk-8.5xxx or tcltk-8.6xxx > > > My idea would be to create a stand alone ruby sumo distrib (rubylab ?) > > with Ruby + Tk + Qt + FFI + some science selected extensions. > > The only real cross platform distro I'm aware of is "rawr" for jruby. > If all you need is swing or the eclipse swt you're good to go (there's > examples of ruby wrapping the swt in the redcar project). Not really, jruby (that I like) work on java which can be see as a platform by itself. So if you need to use other lib (such as glpk (c), lemon (c++) , coin-or (c++), .. you have or play with jni interface. The FFI ffi-tk ruby project should work with any plateform (e.g. jruby but also macruby, etc...). But if Hidetoshi hasn't choose that way (i.e. ffi) for tk, propably there is a good reason (like the threads, or simply it much more work ?) -- Maurice
From: Roger Pack on 20 Feb 2010 15:50 > One more thought, on my feeling from what I read in this newsgroup > about Ruby/Tk on Windows: > _Until_ a very good solution is available, I think, it would be good > to have a clear description on how to install Ruby/Tk on Windows, > using for example ActiveTCL, and having binaries for download. > Something like Roger Pack provides, but even more. I've updated http://wiki.github.com/rdp/ruby_tutorials_core/tk to be a little more verbose. Hopefully that will be enough of a stop gap until somebody comes in and patches RubyInstaller to have the Tk binaries... -r -- Posted via http://www.ruby-forum.com/.
From: Hidetoshi NAGAI on 21 Feb 2010 01:20 From: Axel <a99.googlegroups.a99(a)dfgh.net> Subject: Re: Tk on Windows and Mac OS X 10.6 Date: Sat, 20 Feb 2010 16:15:07 +0900 Message-ID: <c8479617-faeb-41af-b96d-a0ea083c6fae(a)f42g2000yqn.googlegroups.com> > One more thought, on my feeling from what I read in this newsgroup > about Ruby/Tk on Windows: > _Until_ a very good solution is available, I think, it would be good > to have a clear description on how to install Ruby/Tk on Windows, > using for example ActiveTCL, and having binaries for download. Of course, if you can, it is the best way to install Tcl/Tk (and Ruby) on your environment. I never think to change current standard relation between Ruby and Tcl/Tk libraries. I think that most of troubles on installation of a binary distribution depend on: (1) install wrong version (not supported by tcltklib.so) of Tcl/Tk. (2) "Path" environment variable doesn't include the folder of Tcl/Tk libraries. Tcl/Tk stubs are usually effective. But sometimes, it generates errors by uncertain reason. # On a linux box, I get such errors. # tcltklib.so with stubs made for Tcl/Tk8.4 doesn't work for Tcl/Tk8.5, # but works for Tcl/Tk8.6. # And os the same box, the one made for Tcl/Tk8.5 doesn't work for 8.6. If can, it is better to distribute 3 version (for Tcl/Tk8.4, 8.5, and 8.6) of tcltklib.so. -- Hidetoshi NAGAI (nagai(a)ai.kyutech.ac.jp)
From: Hidetoshi NAGAI on 21 Feb 2010 01:21
From: mdiam <maurice.diamantini(a)gmail.com> Subject: Re: Tk on Windows and Mac OS X 10.6 Date: Sat, 20 Feb 2010 19:16:41 +0900 Message-ID: <f758cf0f-774f-47a2-8069-1d53ea4b08f7(a)f15g2000yqe.googlegroups.com> > The FFI ffi-tk ruby project should work with any plateform > (e.g. jruby but also macruby, etc...). > But if Hidetoshi hasn't choose that way (i.e. ffi) for tk, > propably there is a good reason (like the threads, or simply > it much more work ?) Because I'm not familiar with FFI, I don't have good ideas to soleve complexity of combination of callbacks, threads, and exceptions. For example ... The eventloop is running on thread1. thread2 calls Tk function1 (send to thread1; serialized on event queue). thread1 get thread2's request from the event queue. thread1 call callback1 on Ruby. callback1 (running on thread1) calls Tk function2. function2 call callback2 on Ruby. And, an exception is raised in callback2. Then, how should we treat the exception? Tcl/Tk functions know nothing about Ruby threads. Of course, there are some methods to solve it. However, those methods may have other problems; slow operation or response (with lock process), depend on global variables, explosion of entry tables, CPU power eater (by busy loop), and so on. To solve or avoid all of them on Ruby only may be difficult. # I agree that ffi-tk is valuable even if it has some restrictions. -- Hidetoshi NAGAI (nagai(a)ai.kyutech.ac.jp) |