Good GUI documentation

[Ruby Student]

[Note: parts of this message were removed to make it a legal post.]

Hello all you happy GUIsher!

Does anyone know of a good, well written book to learn one of the GUI
supported by Ruby?
I looked at:

Fox
TK
QTK
Jruby with netbeans
shoes
wxruby
wide studio
rubyonsteel
monkeybars

I want something simple or at least well documented. Preferable drag and
drop. I would like to worry just about the ruby code and not necessarily
about the creation of the widgets.
Something close to what Visual Basic provides. I know this is wishful
thinking. I would purchase the book or even purchase the GUI software (if it
is reasonable). But all the tools I mentioned have their limitations and
documentation is so so at best. I wish the tool to be cross-platform with
native look and feel.

I know about the recent GUI survey, which I think was very nice. The
question is, what's next?
At any rate, I will appreciate some info about a well documented GUI for
Ruby.

Thank you all

 

[Logan Barnett]

Hello all you happy GUIsher!

Does anyone know of a good, well written book to learn one of the GUI
supported by Ruby?
I looked at:

Fox
TK
QTK
Jruby with netbeans
shoes
wxruby
wide studio
rubyonsteel
monkeybars

I want something simple or at least well documented. Preferable drag
and
drop. I would like to worry just about the ruby code and not
necessarily
about the creation of the widgets.
Something close to what Visual Basic provides. I know this is wishful
thinking. I would purchase the book or even purchase the GUI
software (if it
is reasonable). But all the tools I mentioned have their limitations
and
documentation is so so at best. I wish the tool to be cross-platform
with
native look and feel.

I know about the recent GUI survey, which I think was very nice. The
question is, what's next?
At any rate, I will appreciate some info about a well documented GUI
for
Ruby.

Thank you all

We've done a lot to leave some good RDoc in place for Monkeybars, but
we do have very little in discussing how to bring it together, what do
real apps look like, etc. Recently we moved to Kenai and opened up a
wiki (http://kenai.com/projects/monkeybars/pages/Home). Our users have
been filling it with loads of documentation, which I think really
helps fill our documentation gap we have.

We're also really active on the mailing list and IRC.

Also, Monkeybars was designed with a GUI builder such as Netbeans in
mind. I don't write any code for making the layout for my production
apps in Monkeybars.

We don't have any Monkeybars books (yet), but we'd love to help you
get up to speed as quick as we can.

 

[Mark Roseman]

Does anyone know of a good, well written book to learn one of the GUI
supported by Ruby?

Though not a book, there is an extensive tutorial about using Tk with
Ruby that you can find at http://www.tkdocs.com

Mark

 

[Joel VanderWerf]

Hello all you happy GUIsher!

Does anyone know of a good, well written book to learn one of the GUI
supported by Ruby?
I looked at:

Fox

There's a good FXRuby book that came out recently:

http://www.pragprog.com/titles/fxruby/fxruby

It's lean, it's mean, what more could you want!

 

[Alex Fenton]

[Note: parts of this message were removed to make it a legal post.]

Hello all you happy GUIsher!

Does anyone know of a good, well written book to learn one of the GUI
supported by Ruby?

I believe the only Ruby-specific GUI books are for FxRuby (2008) and
Qt-Ruby (2005, documents previous version Qt3):

http://www.pragprog.com/titles/fxruby/fxruby
http://www.pragprog.com/titles/ctrubyqt/rapid-gui-development-with-qtruby

I want something simple or at least well documented.

Several have OK Ruby-specific API documentation (eg GNOME2, Wx, Fox),
but less of the kind of book-type material that guides you topic by
topic to understanding the toolkit's principles.

Preferable drag and
drop. I would like to worry just about the ruby code and not necessarily
about the creation of the widgets.

Most of the toolkits offer one or more GUI builders to design layouts.
Typically, you visually design the layout then write your code in a
separate tool (eg an editor) and load the layout in Ruby and attach code
to handle the user interaction.

However, few offer close integration between the GUI design and the
code: XCode (for OS X/Cocoa development) comes closest, but is of course
not cross-platform.

Something close to what Visual Basic provides. I know this is wishful
thinking.

Yes, for now, at least for cross-platform development.

I would purchase the book or even purchase the GUI software (if it
is reasonable). But all the tools I mentioned have their limitations and
documentation is so so at best. I wish the tool to be cross-platform with
native look and feel.

I know about the recent GUI survey, which I think was very nice. The
question is, what's next?

Given that most of the cross-platform toolkits are developed by quite
small volunteer teams they progress, but not usually at a revolutionary
speed.

Like most people, you want all the good stuff from a toolkit: powerful,
simple, Ruby-ish, cross-platform, native, stable, with great tools and
better documentation. In the same way, many hope to meet that special
someone with an enchanting laugh, hot body, high IQ, beautiful eyes, fat
salary, and a tireless appetite for partying. Though in real life it
rarely comes in one package, one can still find something where it
clicks and works ...

I'd think over what you want to do with GUI programming in Ruby: do you
want to make a profitable application, or create and share an
open-source tool, or scratch an itch and have some fun? And consider
what you think you *most* need - eg, do you need to get your head round
general principles of GUI development, like "event-driven programming"
or "model-view separation", or use a RAD tool, or have the "best"
cross-platform appearance and behaviour.

Perhaps, using the survey and what else you know, choose two or three
toolkits that seem best fitted to your needs, then try to create the
same simple application using each of those. Then decide which you
enjoyed using the most (this is really important), and which had the
result most pleasing to you.

If you're more than casually interested in GUI, you're doing well to
invest a little time: the APIs are often large and so a GUI toolkit can
be long-term relationship. I've been doing Wx since 2004 and I still get
nice surprises (and a very occasional nasty one).

hth
alex

 

[Michal Suchanek]

Hello all you happy GUIsher!

Does anyone know of a good, well written book to learn one of the GUI
supported by Ruby?
I looked at:

Fox
TK
QTK
Jruby with netbeans
shoes
wxruby
wide studio
rubyonsteel
monkeybars

I want something simple or at least well documented. Preferable drag and
drop. I would like to worry just about the ruby code and not necessarily
about the creation of the widgets.
Something close to what Visual Basic provides. I know this is wishful
thinking. I would purchase the book or even purchase the GUI software (if it
is reasonable). But all the tools I mentioned have their limitations and
documentation is so so at best. I wish the tool to be cross-platform with
native look and feel.

I have tried GTK recently .. and I was disappointed.

The wrapper for the library is pretty good AFAICT but it's still a C
widget library.

Many widgets are using an Adjustment for their data source (progress
bars, scroll bars, those range widgets, spinbuttons ..)

The Adjustment is sort of C range, and accepts only Floats as the
values. While it might be good enough for widgets with hidden values
and % progress bars it is not usable for widgets where you want to
show a value other than a simple number.

So to get date spinbutton, letter spinbutton, time range, etc. you
need to roll your own Range and your own widgets.

Actually the range widget seems to have some way of formatting the
text so you might get away with it for ranges that can be represented
as a float range and converted for display.

I guess this is unavoidable with C widgetry. Either the wrapper
implements flexible widgets that are incompatible with other languages
using the library or it uses the standard ones with limited C-friendly
functionality.


The other problem is with the GUI builder - Glade. While you can put
most (all?) simple widgets in place you can only create an outline for
a Treeview (this is how "list" and "table" is spelled in GTK). To put
together a working Treeview you have to do most of the work in your
code, the GUI builder cannot do that.

Still the GTK bindings are fine if you want something that works
reasonably in X and integrates well with the system. There is just
some mismatch between the language in which GTK is written and Ruby
unfortunately.

Thanks

Michal

 

[jonty]

Hello all you happy GUIsher!

Does anyone know of a good, well written book to learn one of the GUI
supported by Ruby?
I looked at:

Fox
TK
QTK
Jruby with netbeans
shoes
wxruby
wide studio
rubyonsteel
monkeybars

I want something simple or at least well documented. Preferable drag and
drop. I would like to worry just about the ruby code and not necessarily
about the creation of the widgets.
Something close to what Visual Basic provides. I know this is wishful
thinking. I would purchase the book or even purchase the GUI software (if it
is reasonable). But all the tools I mentioned have their limitations and
documentation is so so at best. I wish the tool to be cross-platform with
native look and feel.

I know about the recent GUI survey, which I think was very nice. The
question is, what's next?
At any rate, I will appreciate some info about a well documented GUI for
Ruby.

Thank you all

Although Shoes isn't drag and drop it is very easy to create simple ,
and not so simple, gui apps and
it is rather well documented on-line and via its integral manual, you
don't have to worry about widget creation - you just use them, look at
the examples to see what i mean

Although still work in progress it is fantastically cross platform and
has a good supportive mailing list

Have fun!

 

[Phlip]

I want something simple or at least well documented. Preferable drag
If you learned the "Shoes" platform, by Doctor Why, you would understand how
Ruby makes coding easier than drag-and-drop to draw the widgets!

 

[Phlip]

Also, Monkeybars was designed with a GUI builder such as Netbeans in
mind. I don't write any code for making the layout for my production
apps in Monkeybars.

I'm too lazy to search this up: Where's the best MonkeyBars screenshots?

 

[Logan Barnett]

I'm too lazy to search this up: Where's the best MonkeyBars
screenshots?

David Koontz creates a Monkeybars app using Netbeans from scratch.
http://rubyconf2008.confreaks.com/monkeybars-easy-cross-platform-guis.html

My blog has a few screenies in the posts:
http://www.logustus.com/2009/02/brushed-metal.html
http://www.logustus.com/2009/02/icons-using-rawr.html
http://www.logustus.com/2009/01/weekend-project-pasting-code-snippets.html

My company, Happy Camper Studios, makes its payroll with Monkeybars
apps.
This app is the 'alpha' app for Monkeybars. It inspired us to create it:
http://www.happycamperstudios.com/showcase/sat-interface/index.html

JotBot is a time tracking product that pops up and asks you what you
did on a regular interval:
http://www.happycamperstudios.com/showcase/jotbot/index.html

Twit and Twitter (I'm changing the name to Twittest) won first place
in the Java Script Bowl competition two years back.
http://www.happycamperstudios.com/showcase/twit-and-twitter/index.html

Blowmage has a proof-of-concept/prank app I wrote for him at
Mountainwest, but his blog appears to have died. I'll see if I can get
a screen shot of it sometime.

Netbeans itself:
http://www.netbeans.org/features/java/swing.html
http://www.netbeans.org/images/v6/5/screenshots/java-gui-builder.png

I hope that helps!

 

[James Britt]

Useful resources here:

http://kenai.com/projects/monkeybars/pages/Resources

My article at IBM developerWorks (listed at the above link) is slightly
out of date (it refers to monkeybars 0.6.4, while the current version is
1.0.1), but I've passed along updated code so the example app should run
fine.


--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 

[7stud --]

I want something simple or at least well documented.

The language itself isn't well documented--or even adequately
documented. The documentation is often non-existent or it's complete
shite. The powers that be could get good documentation for free if they
wanted. This is all they would have to do:

REXML#xpath


and then provide the means for users to post comments and within a year
the whole damn language would be completely documented by the users
themselves. See the php docs for the best docs of any language I've
encountered. Unfortunately, Ruby just shoots itself in the foot as far
as the docs go. It doesn't matter how great a language is advertised to
be--if the docs suck, the language sucks.

 

[Tom Cloyd]

The language itself isn't well documented--or even adequately
documented. The documentation is often non-existent or it's complete
shite. The powers that be could get good documentation for free if they
wanted. This is all they would have to do:

REXML#xpath


and then provide the means for users to post comments and within a year
the whole damn language would be completely documented by the users
themselves. See the php docs for the best docs of any language I've
encountered. Unfortunately, Ruby just shoots itself in the foot as far
as the docs go. It doesn't matter how great a language is advertised to
be--if the docs suck, the language sucks.

Umm. Having a bad day, are we? Well I DO love good documentation, so I'm
with you on that, but there's another point of view I want to suggest:
Documentation simply records (hopefully in a well-organized way) what
someone knows or thinks YOU'll want to to know. That same information is
very accessible in a supportive community.

I'm a rank amateur in Ruby, with very limited time. I find it generally
quite enough to have the available documentation plus the community
knowledge in this discussion list. It's certainly more current than any
written documentation could be.

Not a perfect solution, but a pretty good one!

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< (e-mail address removed) >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Zachary Brown]

I've Shoes to build a couple applications lately. Some of the
documentation is pretty good but there's holes in it. It requires a
little experimentation to get the hang of it.

As a note, I was someone that really hated working with GUI code but
Shoes changed my mind on that . _why has me sold.

-Zac

 

[James Gray]

The language itself isn't well documented--or even adequately
documented. The documentation is often non-existent or it's complete
shite. The powers that be could get good documentation for free if
they
wanted.

They are pretty accepting of documentation patches. I know because
I've submitted several. Have you?

With the energy used in this rant you could have documented a standard
library instead. I think that might help the community more.

James Edward Gray II

 

[David Masover]

See the php docs for the best docs of any language I've
encountered. Unfortunately, Ruby just shoots itself in the foot as far
as the docs go. It doesn't matter how great a language is advertised to
be--if the docs suck, the language sucks.

I would turn that on its head. PHP has decent docs, I'll grant, but rdoc
isn't completely bad. And when something isn't documented, in Ruby, the
source is readable enough that I can usually find out what's going on --
in PHP, it might not be so easy.

Docs are nice, especially for newbies, but if the language sucks, the
language sucks, and no amount of documentation will save it. On the
other hand, if the language rocks, docs are a nice bonus, but a lot of
it should be self-documenting anyway.

 

[Ruby Student]

[Note: parts of this message were removed to make it a legal post.]

I would turn that on its head. PHP has decent docs, I'll grant, but rdoc
isn't completely bad. And when something isn't documented, in Ruby, the
source is readable enough that I can usually find out what's going on -- in
PHP, it might not be so easy.

Docs are nice, especially for newbies, but if the language sucks, the
language sucks, and no amount of documentation will save it. On the other
hand, if the language rocks, docs are a nice bonus, but a lot of it should
be self-documenting anyway.

Thanks to everyone for their comments and recommendations.I greatly
appreciate all suggestions and comments.

 

[Michal Suchanek]

They are pretty accepting of documentation patches. I know because I've
submitted several. Have you?

The point he is trying to make is that at the very place where the PHP
docs are published on the web users can post comments - which are
sometimes offtopic or misleading but often they are covering gaps in
the docs.

I think that if there is one thing PHP did right this would be it.

Still even with those docs, as somebody pointed out, PHP is a bad
language for me too so I avoid it as much as I can.

Thanks

Michal

 

[Logan Barnett]

On Sat, Feb 14, 2009 at 08:14:43AM +0900, jonty wrote:
I have a question about Shoes, actually . . .

Where can I find a list of dependencies for it? I seem to recall
reading
that it depended on some other Ruby libraries, but haven't been able
to
find a comprehensive list.

Shoes is its own Ruby distribution. That's how you're able to
distribute a Shoes app without distributing Ruby.

 

[David Masover]

While I disagree with a lot of what 7stud says, I do believe that good
documentation is rather more important than you make it sound.
Sometimes, I don't want to *have* to read the source in order to use the
library -- or, in some cases, the application.

That is very true, and good documentation is very important.

However, I stand by what I said. Unless the documentation is
comprehensive, including a thorough HACKING document for how to start
playing with the internals, there's always the chance with any library
that I might have to dig into it and find out what's going on. The
longer and more extensively I use a library, the more likely this is, no
matter how good the docs are.

So, while I would like to be able to get that library's equivalent of
"Hello World" working without having to read source, and while I do
appreciate a good README at least, I'd say from there on, the importance
of documentation vs clean code drops sharply.

As an example: Kernel#autoload is reasonably well documented. It claims
to use 'require' under the hood. However, when I click "view source" in
the rdoc, I get a pile of C which isn't really understandable, at least
to me. It's also not very monkey-patchable.

So while the docs were great to get it working:

autoload :Foo, 'lib/foo'

they were problematic when I wanted something more dynamic -- and
there's really no way to do:

autoload :Foo do
require "some/#{interpolated}/value"
end

I even tried overriding Kernel#require, the way Rubygems does. And
autoload doesn't seem to use that custom require.

Contrast this to Rubinius. While I haven't tried this, it just took me
maybe five minutes on Github, without looking at any documentation, to
find where autoload is defined, and how it it works, and how to get the
effect I wanted (arbitrary code executed when the autoload is
triggered), probably even with the syntax I wanted -- all of which, if
there's a way to do in MRI, it probably requires intimate knowledge of C
and the MRI/YARV internals.

I think I found a grand total of two comments, each one line, maybe five
words.

Now, granted, the Ruby docs can probably be used for much of Rubinius,
to at least find out what it's supposed to do. But I should stress
again: MRI has good documentation via rdoc, but I just fell off a cliff
when it came to extending. Rubinius doesn't have documentation on its
website at the moment (though it is in the source tree), but I didn't
need the docs to figure it out.