Forum: Ruby is GUI a weak point?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
greg.rb (Guest)
on 2006-04-05 00:25
(Received via mailing list)
Ruby seems pretty eash to code and understand. However, as a
non-professional programmer, I find GUI the hardest part so far.
GTK didn't work out of the box on windows. It is too bad because it
looked like it would be one of the better GUI choices. I guess I will
have to try FOX.
 Any suggestions?

Are there any good examples of getting tk widget data to ruby?

Here is a simple example where I try to build an interface for the user
to pick information which will then be sent to ruby to process.

#example:

require 'tk'

cash_locs=['NONE','NY1','NY2','NJ1','ETC.']

root = TkRoot.new() { title "PICK LOCATION" }
bar = TkScrollbar.new(root).pack('side'=>'right', 'fill'=>'y')
fromLoc = TkVariable.new
list = TkListbox.new(root){}
list.pack('side'=>'left', 'fill'=>'both', 'expand'=>true)
list.yscrollbar(bar)

cash_locs.each { |loc|
  list.insert('end', loc)
}

button = TkButton.new(root) {
text 'OK'
command proc {fromLoc.value=list.curselection(),TkRoot.new.destroy}
}
button.pack()
TkButton.new(nil, 'text'=>'Quit',
             'command'=>proc{TkRoot.new.destroy}).pack('fill'=>'x')

Tk.mainloop()

puts 'USER PICKED: '+cash_locs[fromLoc.value.to_i]
Bret P. (Guest)
on 2006-04-05 09:24
(Received via mailing list)
These days most people use the web for their GUI's. Have you considered
this? It doesn't have to be a web app per se. Ruby has lots of good
options in this area.
Michal S. (Guest)
on 2006-04-05 12:24
(Received via mailing list)
On 4/4/06, greg.rb <removed_email_address@domain.invalid> wrote:
> Ruby seems pretty eash to code and understand. However, as a
> non-professional programmer, I find GUI the hardest part so far.

Generally, gui is the hard part of software that has to communicate
with the user. It takes a lot of work to get at least some gui with
the most importatnt options somewhere, and even more difficult to make
one that is easy to use.

Some people find gui builders helpful. They allow you to design
dialogs, menus, etc, and just load them ito your application. iirc
qtruby supports such thing.

Creating dialogs on the fly is more versatile. You can add different
controls when your application is in different states. But then you
should look for toolkit with ruby bindings that makes constructing the
layout easy.

For example, the tk toolkit only provides very primitive ways of
arranging elements. I am not sure if the ruby library provides some
more complex layouts.  But with tk alone it may be quite hard to
create a dialog with different kinds of elements that won't make the
users run away :)

Thanks

Michal
Hidetoshi NAGAI (Guest)
on 2006-04-05 13:23
(Received via mailing list)
From: "greg.rb" <removed_email_address@domain.invalid>
Subject: is GUI a weak point?
Date: Wed, 5 Apr 2006 05:23:59 +0900
Message-ID: <removed_email_address@domain.invalid>
> Are there any good examples of getting tk widget data to ruby?
>
> Here is a simple example where I try to build an interface for the user
> to pick information which will then be sent to ruby to process.

I couldn't understand what you want to ask.
Although the following is one of the samples rewriting yours,
it may not be able to answer your question.
===================================================================
require 'tk'

cash_locs=['NONE','NY1','NY2','NJ1','ETC.']

#--------------------------------
# callback function

def put_picked_value(s)
  puts 'USER PICKED: ' + s
end

#--------------------------------
# GUI part

Tk.root.title 'PICK LOCATION'

TkButton.new(:text=>'Quit',
             :command=>proc{exit}).pack(:side=>:bottom, :fill=>:x)

f = TkFrame.new.pack(:fill=>:both, :expand=>true)

list = TkListbox.new(f)
list.yscrollbar(TkScrollbar.new(f).pack(:side=>:right, :fill=>:y))
list.pack(:side=>:left, :fill=>:both, :expand=>true)

list.insert(:end, *cash_locs)

list.bind('ButtonPress-1',
          proc{|y| put_picked_value(list.get(list.nearest(y))) },
          '%y')

Tk.mainloop()
===================================================================
Carl W. (Guest)
on 2006-04-05 14:18
(Received via mailing list)
I am thinking about this problem at the moment. There are a lot of
toolkits for ruby, but they all require different libraries and are a
bit painful to get running. I am writing software for both OSX and
linux.

I have played with the following toolkits but I haven't made any
decisions:
- Gtk2
- Qt
- wxRuby

There are plenty of others but one thing that I would like to see/like
to start is a wrapper that allows you to switch between all of the
given frameworks using some sort of configuration.

I think it would be good to describe the interface for a button,
window, pane etc and then put wrapper classes around all of the
toolkit implementation classes.

I'm not sure how much interest this would generate in the community
but I would be interested to find out.

Cheers,
Carl.
unknown (Guest)
on 2006-04-05 14:31
(Received via mailing list)
> There are plenty of others but one thing that I would like to see/like
> to start is a wrapper that allows you to switch between all of the
> given frameworks using some sort of configuration.
>

Seems like a lot of effort for very little return. As somebody else has
already said, if you want a cross-platform GUI, you're probably going to
want to be using Rails.

There really isn't such thing as a cross-platform GUI application,
outside of web-land. It always needs tweaking, refining, polishing and
testing for every major platform; as a result, what you're suggesting
offers very little.

Martin
Carl W. (Guest)
on 2006-04-05 14:40
(Received via mailing list)
Java offers cross platform gui development that doesn't require
tweaking. Rails is great but webapps aren't everything. When you are
trying to develop 3d applications or applications that just need to be
run on a desktop (there are still plenty) then ruby is lacking.
Caleb T. (Guest)
on 2006-04-05 14:43
(Received via mailing list)
On Apr 5, 2006, at 6:29 AM, removed_email_address@domain.invalid wrote:

> want to be using Rails.
Using Rails and a web interface is a nice way to present data to an
end user, but it's not always a viable solution.  For example, my
company does diesel engine testing in real time.  There's no way a
web based Rails interface would even come close to being able to meet
our needs for that.

Now, to present the generated data to the end user - Rails works
beautifully.  But the web is not the end all be all for GUI
applications.

> There really isn't such thing as a cross-platform GUI application,
> outside of web-land. It always needs tweaking, refining, polishing and
> testing for every major platform; as a result, what you're suggesting
> offers very little.

I would argue the same is true in webland, since most people designer
end up having to support IE, Firefox, Safari, and more.
unknown (Guest)
on 2006-04-05 14:52
(Received via mailing list)
On Wed, Apr 05, 2006 at 07:37:27PM +0900, Carl W. wrote:
> Java offers cross platform gui development that doesn't require
> tweaking.

Believe me, it doesn't. I've spent a significant proportion of my
professional career pushing against this prevalent misfact.

Friends don't let friends Swing.

SWT, despite IBM's claims to the contrary, needs separate builds for
each platform, similar but not the same UI code, and a significant
amount of work to get the UI to look and feel "right" on Windows, Linux
and Mac OS X, and fit in fully with its UI conventions and way of
working.

Even then, SWT is DOG SLOW on Linux, almost to the point of uselessness.
See: Eclipse.

Ruby's nearest equivalent to SWT is wxRuby, which you've already tried.

There is no such thing as a cross-platform UI. Even with wxRuby, you'll
need to do a lot of work to get the UI to a point where Mac users,
Windows users and Linux users will all hate it equally.

Martin
unknown (Guest)
on 2006-04-05 14:55
(Received via mailing list)
>
> I would argue the same is true in webland, since most people designer
> end up having to support IE, Firefox, Safari, and more.
>

True. But increasingly, the lovely, lovely people behind Rails and Dojo
are doing the hard work so we don't have to.

Martin
Mark V. (Guest)
on 2006-04-05 16:00
(Received via mailing list)
On 4/5/06, Michal S. <removed_email_address@domain.invalid> wrote:
> On 4/4/06, greg.rb <removed_email_address@domain.invalid> wrote:

> For example, the tk toolkit only provides very primitive ways of
> arranging elements. I am not sure if the ruby library provides some
> more complex layouts.  But with tk alone it may be quite hard to
> create a dialog with different kinds of elements that won't make the
> users run away :)

Layout options in Tk and most GUI toolkits are much less primitive
than HTML layout.
unknown (Guest)
on 2006-04-05 16:06
(Received via mailing list)
On Wed, Apr 05, 2006 at 08:57:30PM +0900, Mark V. wrote:
> than HTML layout.
HTML has no layout out at all.

And Lo, the lord spake, and he gaveth of the world CSS, and saw that it
was good.

Of course, that's an issue for graphic designers. We're programmers. Let
people with some taste do the CSS and laying out.

Martin
John (Guest)
on 2006-04-05 17:28
I haven't tried Gtk or wxRuby, but FxRuby (based on FOX GUI) is quite
good.  I find it to be easier to use than Ruby/Tk - for example, in
FxRuby, scrollbars come for free, there's a TreeList that's as easy to
use as any other language's tree view, and keyboard shortcuts (in a list
box, press 'b' and the selection should jump to the first item beginning
with 'b', that kind of thing) and mouse scroll wheels tend to work for
free.

One issue with Ruby is that there's no full all-singing-all-dancing IDE
which will do a lot of the hard work for you.  For example, C# guys
(including me when I'm not writing installations or programming Ruby)
get VS.NET or #Develop, both of which have form designers.  Since the
form designer works out all the positioning, it makes it easier for the
programmer.

However, since languages like Ruby don't have a full IDE (yet), you have
to do more manually.  To alleviate this, languages such as Ruby tend to
use GUI libraries that make this as simple as possible.  However, this
does not result in GUIs that look particularly nice, and .
John (Guest)
on 2006-04-05 17:29
John wrote:
> I haven't tried Gtk or wxRuby, but FxRuby (based on FOX GUI) is quite
> good.  I find it to be easier to use than Ruby/Tk - for example, in
> FxRuby, scrollbars come for free, there's a TreeList that's as easy to
> use as any other language's tree view, and keyboard shortcuts (in a list
> box, press 'b' and the selection should jump to the first item beginning
> with 'b', that kind of thing) and mouse scroll wheels tend to work for
> free.
>
> One issue with Ruby is that there's no full all-singing-all-dancing IDE
> which will do a lot of the hard work for you.  For example, C# guys
> (including me when I'm not writing installations or programming Ruby)
> get VS.NET or #Develop, both of which have form designers.  Since the
> form designer works out all the positioning, it makes it easier for the
> programmer.
>
> However, since languages like Ruby don't have a full IDE (yet), you have
> to do more manually.  To alleviate this, languages such as Ruby tend to
> use GUI libraries that make this as simple as possible.  However, this
> does not result in GUIs that look particularly nice, and .

and can be harder to implement.

Sorry about that!
unknown (Guest)
on 2006-04-05 17:33
(Received via mailing list)
On Wed, Apr 05, 2006 at 10:28:48PM +0900, John wrote:
> I haven't tried Gtk or wxRuby, but FxRuby (based on FOX GUI) is quite

Mac support only with X11. Gah.

Only use if you want Mac users to hate you. Really hate you.

Martin
zdennis (Guest)
on 2006-04-05 17:39
(Received via mailing list)
Caleb T. wrote:
>> want to be using Rails.
>
> Using Rails and a web interface is a nice way to present data to an end
> user, but it's not always a viable solution.  For example, my company
> does diesel engine testing in real time.  There's no way a web based
> Rails interface would even come close to being able to meet our needs
> for that.
>

Until they give the browser persistent connections to the server =)

Zach
unknown (Guest)
on 2006-04-05 17:42
(Received via mailing list)
> > Using Rails and a web interface is a nice way to present data to an end
> > user, but it's not always a viable solution.  For example, my company
> > does diesel engine testing in real time.  There's no way a web based
> > Rails interface would even come close to being able to meet our needs
> > for that.
> >
>
> Until they give the browser persistent connections to the server =)
>

Look at what GMail has been able to do with XMLHttpRequest.

If I were you, I'd check out Rails 1.1's RJS support, Dojo, etc., and
check out some of the suprisingly fab stuff you can do with Async
Javascript.

Martin
zdennis (Guest)
on 2006-04-05 18:22
(Received via mailing list)
removed_email_address@domain.invalid wrote:
>
> If I were you, I'd check out Rails 1.1's RJS support, Dojo, etc., and
> check out some of the suprisingly fab stuff you can do with Async
> Javascript.
>

What I'm getting at is that there is time involved with the setup,
handshake, connection and termination of each XmlHttpRequest. A
persistent connection only incurs each of those once.

To get good performance for lots of data it would be awesome to open a
connection and then to have it open for the remainder of the site visit.

=(

Zach
Randy K. (Guest)
on 2006-04-05 18:31
(Received via mailing list)
On Wednesday 05 April 2006 09:40 am, removed_email_address@domain.invalid wrote:
> > > Using Rails and a web interface is a nice way to present data to an end
> > > user, but it's not always a viable solution.  For example, my company
> > > does diesel engine testing in real time.  There's no way a web based
> > > Rails interface would even come close to being able to meet our needs
> > > for that.
> >
> > Until they give the browser persistent connections to the server =)
>
> Look at what GMail has been able to do with XMLHttpRequest.

I can easily imagine that the output the first poster (above) refers to
(the
results of diesel engine testing in real time), are oscilloscope type
stuff,
which generally would be difficult to reproduce (in real time) on a web
interface.  But, I suspect the frequency range required is not in the
MHz or
GHZ range, but instead in the KHz range?

In any event, at some point the web interface would find it difficult to
keep
up--say you're testing ICs (integrated circuits, just to avoid confusing
with
Internal Combustion engines) in real time.  But, at some point maybe you
resort to snapshots of the data, digital sampling / recording of the
data
(like sampling of audio or video streams), Fourier transforms (??), or
some
other (more) clever approach.

(sorry about losing the attributions, they were not in the post I'm
responding
to)

Randy K.
Chris A. (Guest)
on 2006-04-05 18:56
(Received via mailing list)
Cross platform GUIs is a very serious problem today and one without
clear solution.  I agree with everyone pushing the web interface but
it does have it's limitations.  Here's my suggestions (if a web
interface doesn't work):

1. Give up.  If you want a high quality GUI on multiple platforms give
up trying a single solution and realize that you will need to
implement the GUI in a native toolkit on each platform.  Yes, this is
a tremendous amount of work but, if you want high quality, it is the
only viable solution.  The difficulties can  be partially ameliorated
by proper abstraction and separation of GUI vs. non-GUI.

2. If it's simple, use Tk.  Tk has major limitations and is totally
unsuited for complicated modern interfaces.  That being said, it is
excellent for simple interfaces and is the closest thing to a cross
platform toolkit we have.  I've been using Tk with various languages
for over a decade now and have managed to build some rather
complicated GUIs/programs with it.  For simple GUIs and rapid
prototyping it has been a joy; for serious GUI work, a nightmare.

3. Pick whichever of the alternatives (see the rest of the thread) you
think will suceed in the future and hope you're right.  There is a
definite need for a crossplatform GUI toolkit; Tk is no longer
fulfilling that need, Java never did, and the other contenders are
only satisfactory on a subset of platforms.  Sooner or later one of
these contenders or a new one will provide good functionality on all
platforms.  My guess is Fox but I'm not taking bets.

c.
Mark V. (Guest)
on 2006-04-05 19:11
(Received via mailing list)
On 4/5/06, Chris A. <removed_email_address@domain.invalid> wrote:

> 2. If it's simple, use Tk.  Tk has major limitations and is totally
> unsuited for complicated modern interfaces.  That being said, it is
> excellent for simple interfaces and is the closest thing to a cross
> platform toolkit we have.  I've been using Tk with various languages
> for over a decade now and have managed to build some rather
> complicated GUIs/programs with it.  For simple GUIs and rapid
> prototyping it has been a joy; for serious GUI work, a nightmare.

Isn't this what Tk Tile (http://tktable.sourceforge.net/tile) is
supposed to address? Look at the Windows XP and Mac OS X screenshots
at this web site. Also see
http://www.ruby-doc.org/stdlib/libdoc/tk/rdoc/clas... for
documentation on using this from Ruby. I haven't tried it yet. If you
have, I'd love to hear your feedback on it.
Logan C. (Guest)
on 2006-04-05 20:52
(Received via mailing list)
On Apr 5, 2006, at 9:32 AM, removed_email_address@domain.invalid wrote:

> Mac support only with X11. Gah.
>
> Only use if you want Mac users to hate you. Really hate you.
>
> Martin

Some of us will merely be mildly disappointed.
zdennis (Guest)
on 2006-04-05 22:45
(Received via mailing list)
Chris A. wrote:

[snip]
>
> 3. Pick whichever of the alternatives (see the rest of the thread) you
> think will suceed in the future and hope you're right.  There is a
> definite need for a crossplatform GUI toolkit; Tk is no longer
> fulfilling that need, Java never did,

I love ruby, but I also utilize Java for thick client applications. It's
cross platform GUI capabilities have allowed our developers to develop
on multiple OSes. It has worked great for our client applications which
involve alot of 2D rendering. So what do you mean, "java" never
fulfilled the need? For RTS or heavy 3D I can agree with you it's not
the best, but for most business applications it's crossplatform GUI is
pretty good.

I am not looking to start flamewar on java. I just don't think java is
bad in all aspects, and it's crossplatform GUI toolkit (yes even swing)
is not so bad.

Zach
Victor S. (Guest)
on 2006-04-05 22:48
(Received via mailing list)
> > For example, the tk toolkit only provides very primitive ways of
> > arranging elements. I am not sure if the ruby library provides some
> > more complex layouts.  But with tk alone it may be quite hard to
> > create a dialog with different kinds of elements that won't make the
> > users run away :)
>
> Layout options in Tk and most GUI toolkits are much less primitive
> than HTML layout.

BTW, I'm now working on Ruby wrapper for great HTMLayout library
(http://terrainformatica.com/htmlayout/).

HTMLayout is html-based layouting engine, which has standard-simple
widgets
(edit, checkbox, combod...) and allows to create new widgets in plain
HTML.
The engine is small and fast and doesn't relies on IE, or Gecko, or
something else. As for now, it is working on Windows only (Mac planned,
*nix
questionnable) and is free for non-commercial use.

I am planning to publish my Ruby wrapper for HTMLayout (wrapper is
codenamed
HTMR) on rubyforge IF there would be interest to such project.


> R. Mark V.
> Object Computing, Inc.

Victor.
Victor R. (Guest)
on 2006-04-05 22:48
(Received via mailing list)
Where can I find examples and sample codes of web interface GUI
programming
in Ruby?

Thank you

Victor
Chris A. (Guest)
on 2006-04-05 23:00
(Received via mailing list)
I didn't mean to start a flamewar either or, for that matter, bash
Java.  I apologize if I came across as a Java hater.

I don't mean to say that Java has no good qualities or that it's GUI
support is universally bad.  But I do not believe it is the cross
platform solution it was intended to be.  Maybe my opinion is
malformed (I am competent in Java but hardly an expert) or my view of
the intentions/hype inaccurate.

My main complaint with Java is the difficulties I've run into in
porting Java applications to various platforms.  I've spent to much
time fighting with odd javac errors or even getting the JRE or JDK to
compile, or not core dump.  Whereas I have never had these problems
with, for example, Tk.

I'm also not fond of the Java GUI ergonomics but then I'm not really
happy with any of the toolkits ergonomics.

Java does have things it does well.  Also, very importantly, it
generated a lot of thought and activity in cross platform languages
and GUI toolkits.  Tk has strengths and weaknesses too.
Carl W. (Guest)
on 2006-04-06 01:07
(Received via mailing list)
No one is intending a flame war but I have seen java do a lot of good
thick client work and I have had it running (with speed) on linux,
windows and osx. This includes swing and SWT. I'm not saying that java
is great but I am saying that the ideas that they have work really
well for certian situations.

A lot of applications can be done in a webapp and webapps are great
for situations where you wish to deploy the applications easily and
you are trying to capture data from the user. They are even getting
better with respect to text editors, etc. But, I have worked in
consulting for a few years now and I see that ruby is losing a lot of
developers to .NET because of its gui support, even though the ruby
language is far superior. .NET has a single toolkit for gui
development that isn't really that good but it is documented and
supported. I believe that ruby could benefit from a well documented
and usable gui toolkit or abstract layer.

If this was inplace then ruby would be stronger as a complete platform
for application development and maybe more companies would start to
use it for all of their development.
Hidetoshi NAGAI (Guest)
on 2006-04-06 07:47
(Received via mailing list)
From: "Chris A." <removed_email_address@domain.invalid>
Subject: Re: is GUI a weak point?
Date: Thu, 6 Apr 2006 03:58:04 +0900
Message-ID: <removed_email_address@domain.invalid>
> Java does have things it does well.  Also, very importantly, it
> generated a lot of thought and activity in cross platform languages
> and GUI toolkits.  Tk has strengths and weaknesses too.

Maybe, in near future, Ruby/Tk applications will be able to be
exported to the Net.
I'm working on Ruby/TkORCA (Ruby/Tk on RFB canvas) which is a
framework to do that (see [ruby-talk:160371]).
One of the documents about that is
<http://www.dumbo.ai.kyutech.ac.jp/~nagai/learn-rub....
It is written in Japanese.
But some figures on it may help you to understand its concept.

The running demo on the site described in [ruby-talk:160371] is
still based on very old version of sources.
Current version on my environment for development can resize windows
of a daughter which is a sandbox to destribute an application
(the application is quite same as the one running on the local
windowing system).
If you want to deny a daughter to call some methods (e.g. 'load'
method), you can do it by calling
"TkORCA::MethodWrapper.deny_daughter_to_function('load')"
on the mother which is a observer/controller of daughters.
You can do also for class/module or instance methods by similar ways.
If you want to control a method-call instead of denying,
you can do that, for example,
--------------------------------------------------------------
TkORCA::MethodWrapper.wrap_function('load'){|orig_m, *args|
  file, wrap = args
  unless TkORCA.is_mother? {
     # check the file path
  }
  orig_m.call(file, wrap)
}
--------------------------------------------------------------
Of course, daughters cannot call such methods for definition.

Well, why should be Ruby/Tk?
The reason is "(Only?) Ruby/Tk has nessesary functions to implement
such features".

To implement a mother and daughters, a process must have some
independent widget sets.
One is widgets for implementing a kind of window-manager (for a
mother), and each of others is widgets for each daughter.
For security reason, even if a daughter succeeds to get a widget
object belongs to the window-manager, the framework is required to
disallow the daugher to control the widget.
And the framework must be able to decide to create a widget for which
widget set depend on the context of the script, bacause the framework
must load a GUI script (of course, it is a standalone script which can
run on the local) into a daughter.

Ruby/Tk can do them.
Martin C. (Guest)
on 2006-04-06 12:26
(Received via mailing list)
On 5 Apr 2006, at 17:49, Logan C. wrote:

>
> On Apr 5, 2006, at 9:32 AM, removed_email_address@domain.invalid wrote:
>
>> Mac support only with X11. Gah.
>>
>> Only use if you want Mac users to hate you. Really hate you.
>>
>> Martin
>
> Some of us will merely be mildly disappointed.

I dunno. Whenever I see X11.app spring to life, I think the Universe
has failed me.

Martin
Martin C. (Guest)
on 2006-04-06 12:36
(Received via mailing list)
On 5 Apr 2006, at 22:06, Carl W. wrote:

> No one is intending a flame war but I have seen java do a lot of good
> thick client work and I have had it running (with speed) on linux,
> windows and osx. This includes swing and SWT. I'm not saying that java
> is great but I am saying that the ideas that they have work really
> well for certian situations.

Ah, me to. But my point is, that even when you use SWT, a supposedly
cross-platform toolkit, you still end up having to support 3+
similar, but slightly different GUI codebases and polish each one to
the expecations of users for Linux/Mac/Windows.

It's a lot of work; the notion of a cross-platform gui is something
of a myth.

In Rubyland, wxRuby Å SWT.

Martin
Robert D. (Guest)
on 2006-04-06 12:51
(Received via mailing list)
On 4/5/06, Carl W. <removed_email_address@domain.invalid> wrote:
[...]

No one is intending a flame war but I have seen java do a lot of good
> developers to .NET because of its gui support, even though the ruby
> language is far superior. .NET has a single toolkit for gui
> development that isn't really that good but it is documented and
> supported. I believe that ruby could benefit from a well documented
> and usable gui toolkit or abstract layer.


You are right for sure, but why limit this to ruby, should we not at
this
point in time foresee the need of something more abstract.
I feel quite stupid writing this because I have so little GUI
experience,
but it strikes me very very clearly that I share the disgust for GUI
developping because it is sooo difficult.

For me it seems that what is needed is an *Open* GUI specification, way
on
top of GTK, KDE or whatever graphical interface.
If that could be done in a decent way ( sooo easy to say, sooo difficult
to
do) the rest would spring into life automatically.
Ruby, Python, Objective C, Perl6 (yes I know it is dead, but I am an
optimist) and all the other marvellous languages will implement it.

Such a beast could be inspired by things we might have learnt by SWING,
CSS,
Tk and so on.
It could defenitely be inspired by the already existing graphical
layers.
It will be crucial to be "pragmatic".

Please do not forget that we are still in the Stone Age of Computers,
like
in the old times of industry revolution, when each manufacturer created
his
own screws and you needed his own screwdrivers. (Dunno why I am suddenly
thinking about proprietary SW and protocols ;)


If this was inplace then ruby would be stronger as a complete platform
> for application development and maybe more companies would start to
> use it for all of their development.


It would, but I think our community (and no single language community
for
that matter) is not strong enough to pull that off alone, but please
make me
mistaken!

[...]
Just some thaughts

Robert


--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein
Martin C. (Guest)
on 2006-04-06 13:25
(Received via mailing list)
> You are right for sure, but why limit this to ruby, should we not
> at this
> point in time foresee the need of something more abstract.


This has already happened at least three times in XML; Mozilla's XUL,
GNOME's libglade and Microsoft's XAML.

Take your pick.

Martin
Carl W. (Guest)
on 2006-04-06 14:05
(Received via mailing list)
Not sure if anyone saw this today on slashdot:

OSDL to Bridge GNOME and KDE

"Open Source Development Labs is previewing work that will attempt to
make life easier for software companies by bridging GNOME and KDE. The
effort, called Portland Project, began showing its first software
tools on in conjunction with this week's LinuxWorld Conference & Expo.
Using them, a software company can write a single software package
that works using either of the prevailing graphical interfaces.
Working with Freedesktop.org on unifying interface issues, they plan
to release a beta version of the software in May and version 1.0 in
June. Ultimately, advocates hope that it will be part of a larger but
separate effort called Linux Standard Base, which is designed to make
the operating system easier for software companies to use."

Does anyone think that this direction is relavent for ruby?
Robert D. (Guest)
on 2006-04-06 14:15
(Received via mailing list)
On 4/6/06, Carl W. <removed_email_address@domain.invalid> wrote:
> that works using either of the prevailing graphical interfaces.
> Working with Freedesktop.org on unifying interface issues, they plan
> to release a beta version of the software in May and version 1.0 in
> June. Ultimately, advocates hope that it will be part of a larger but
> separate effort called Linux Standard Base, which is designed to make
> the operating system easier for software companies to use."


Of course somebody else has thaught about this before me, shame ;).
Thank
you for the link it seems very interesting indeed.

I thaught something more general might be needed, more clearly
abstracting
from the lower levels.

On the other hand it will be crucial to get it working soon, so I am
probably wrong!
And I have not studied this enough anyway to make stupid statements
(well it
has some rewards of its own to make stupid statements, it gets you
smarter
when reading the replies).

Does anyone think that this direction is relavent for ruby?


Well I am not qualified to answer this question :(. But if it evolves
into a
standard it will be, don't you think?

--
> Carl W.
> 0412218979
> removed_email_address@domain.invalid
>
>
Cheers
Robert

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein
John (Guest)
on 2006-04-06 22:13
Martin C. wrote:

> I dunno. Whenever I see X11.app spring to life, I think the Universe
> has failed me.
>
> Martin

Wow...  Guess you really don't like X11.

Currently, all our stuff is Windows-only internal tools for project
development (in fact, the only GUI thing I've done in Ruby so far is a
tool to show Rake dependencies).

However, if I do any cross-platform stuff that might be used on a Mac,
I'll definitely make sure I look at something other than FOX.
Chris A. (Guest)
on 2006-04-07 01:18
(Received via mailing list)
It's not so much that X11 is bad; it's good to have it available and
actually does a good job of running X11 concurrently with OS X.  But
it's just so disappointing.  Besides the memory/CPU cost/startup time
it emphasises that this is a limited port of an application written
for another architecture.  Although this applications work fine under
X11.app the keys are different (than actual OS X apps), the appearance
is different, the focus model may not be what they expect...
John (Guest)
on 2006-04-07 14:45
Chris A. wrote:
> It's not so much that X11 is bad; it's good to have it available and
> actually does a good job of running X11 concurrently with OS X.  But
> it's just so disappointing.  Besides the memory/CPU cost/startup time
> it emphasises that this is a limited port of an application written
> for another architecture.  Although this applications work fine under
> X11.app the keys are different (than actual OS X apps), the appearance
> is different, the focus model may not be what they expect...

I see.  I've only tried it on Windows and, bar a few quirks, it's quite
good - a million times better than Tk on Windows at least.  Take, for
example, the list box.  Under Ruby/Tk, the list box is essentially a
text box with a list of items - one per line, and clicking a line
selects that whole line.  You can't tap a key to go to an item beginning
with that letter (you can in FxRuby), and scollbars have to be manually
attached to a host control.  But, oh, they can't just be connected, no,
that would be too simple.  They have to be put on the form as a seperate
control.  But then you have to think about how that scrollbar docks to
the side of the listbox, so a frame is needed to make sure the controls
line up correctly, and then you have to tell it to act as a scrollbar
for the listbox, and also tell it to change the size of the thumb based
on the contents of the listbox.

I didn't even attempt to build a tree.  I ported my Rake dependency tool
to FxRuby, and found it ridiculously easy to build a dialog with a
couple of trees which do the job of the Tk version far better.  It has a
file browse dialog (which the Tk version didn't) to load the rakefile,
and even a search capability.

And not to mention the fact that it just looks better - it looks more
like a Windows app, which is good on Windows.
tony summerfelt (Guest)
on 2006-04-07 17:07
(Received via mailing list)
On Wed, 5 Apr 2006 23:54:26 +0900, you wrote:

> Tk has major limitations and is totally
>unsuited for complicated modern interfaces.

> I've been using Tk with various languages
>for over a decade now and have managed to build some rather
>complicated GUIs/programs with it.

> for serious GUI work, a nightmare.

ok, for those of us keeping score at home, which is it? :)

assuming tcl/tk what was missing in the gui ap that you couldn't find
an extension for?

http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
tony summerfelt (Guest)
on 2006-04-07 17:25
(Received via mailing list)
On Thu, 6 Apr 2006 03:47:02 +0900, you wrote:

>I am planning to publish my Ruby wrapper for HTMLayout (wrapper is codenamed
>HTMR) on rubyforge IF there would be interest to such project.

i think the ruby interest in this might drop off at the $350 price tag
for htmllayout.

for simple gui's i've been using RubyWebDialog, less work than
ruby/tk, and easily wrappable using rubyscript2exe.

http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Chris A. (Guest)
on 2006-04-07 18:39
(Received via mailing list)
Yes, Fox has a lot of very nice features and I'm keeping a very
interested eye on it.  It is unfortunate that it currently does not
run natively (without X11) on OS X.  If it did I would be using it and
not Ruby/Tk.

In defense of Tk, I gather from your comments that you arae using the
core Tk.  This provides fairly low level widget primitives.  There are
plenty of packages (many of whicih exist for Ruby/Tk) which provide
higher level widgets such as superior list boxes, trees, etc.  For
example BLT, Iwidgets, Bwidgets, ...  I view Tk as a lower level
toolkit than Fox and others, just as X11 is an even lower level
toolkit below Tk.

As I've written before I believe that Tk is not good for building
modern GUIs.  But when I say this I am not speaking of the widget set.
 I'm speaking of lacking core concepts.  Tk requires a root toplevel
to exist at all times: if you withdraw it it vanishes from the screen
but now, if you have no other toplevels, keyboard events don't
register; it has limited ability for a "first responder" type of
behavior; etc.
Chris A. (Guest)
on 2006-04-07 18:42
(Received via mailing list)
On 4/7/06, tony summerfelt <removed_email_address@domain.invalid> wrote:
>
> ok, for those of us keeping score at home, which is it? :)

They are not mutually exclusive.  Tk is a nightmare for serious GUI
work and I have dealt with that nightmare and done serious GUI work in
Tk.  It's not much of a nightmare if you wake up as soon as it starts
=)

> assuming tcl/tk what was missing in the gui ap that you couldn't find
> an extension for?

I don't understand the question.

c.
John (Guest)
on 2006-04-07 21:52
> In defense of Tk, I gather from your comments that you arae using the
> core Tk.

You gather correctly/

> There are
> plenty of packages (many of whicih exist for Ruby/Tk) which provide
> higher level widgets such as superior list boxes, trees, etc.  For
> example BLT, Iwidgets, Bwidgets, ...  I view Tk as a lower level
> toolkit than Fox and others, just as X11 is an even lower level
> toolkit below Tk.

Hmmm....  Well, the port is done.  If I'd looked into it properly, I
might have found those and gone that way instead.  But I'd already seen
Fox mentioned, and decided to give it a try, and it turned out ok.

Luckily, I'm expecting 90% of my work (build engineering, really) to be
command-line based tools or libraries to use in Rake, and a few GUI
utilities such as Rakedep.  I'm waiting for the DamageControl project to
come back to life, and I might modify my tool to import Rake projects
into that.

But, really, if Fox turns out to be not as good then it's really not
going to be a big deal for me.
Mark Haniford (Guest)
on 2006-04-09 01:11
(Received via mailing list)
On 4/6/06, Martin C. <removed_email_address@domain.invalid> wrote:
> cross-platform toolkit, you still end up having to support 3+
> similar, but slightly different GUI codebases and polish each one to
> the expecations of users for Linux/Mac/Windows.
>
> It's a lot of work; the notion of a cross-platform gui is something
> of a myth.
>
> In Rubyland, wxRuby Å SWT.
>
> Martin
>

When we talk about crossplatform, we're talking at the application
source code level, and not at the library implementation level.  The
vast majority of software is using some kind of operating system
service or native library at some point in time.

Of course you'll never have total native fidelity or have the full
range of desktop level services, but that's the price you pay for not
using the native GUI code for each and every platform.
This topic is locked and can not be replied to.