Is GUI a weak point?

ruby-talk
21

azrael@cream.org 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.

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

22

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 Kramer

···

On Wednesday 05 April 2006 09:40 am, azrael@cream.org 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.

23

Where can I find examples and sample codes of web interface GUI programming
in Ruby?

Thank you

Victor

···

On 4/5/06, Logan Capaldo <logancapaldo@gmail.com> wrote:

On Apr 5, 2006, at 9:32 AM, azrael@cream.org 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.

24

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

Martin

···

On 5 Apr 2006, at 17:49, Logan Capaldo wrote:

On Apr 5, 2006, at 9:32 AM, azrael@cream.org 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.

25

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.

26

Martin Coxall 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.

···

--
Posted via http://www.ruby-forum.com/\.

27

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/classes/Tk/Tile.html 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.

···

On 4/5/06, Chris Alfeld <chris.alfeld@gmail.com> 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.

--
R. Mark Volkmann
Object Computing, Inc.

28

Chris Alfeld 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

29

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...

30

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

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

···

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.

31

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.

32

Chris Alfeld 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.

···

--
Posted via http://www.ruby-forum.com/\.

33

> 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? :slight_smile:

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.

···

On 4/7/06, tony summerfelt <snowzone5@hotmail.com> wrote:

On Wed, 5 Apr 2006 23:54:26 +0900, you wrote:

34

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.

···

On 4/6/06, Chris Alfeld <chris.alfeld@gmail.com> wrote:

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 Woodward
0412218979
cjwoodward@gmail.com

35

Message-ID: <b40ff0a0604051158r5a6d6e1fpf93d09840659db0f@mail.gmail.com>

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-ruby-in-kansai-20060128.pdf&gt;\.
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,

···

From: "Chris Alfeld" <chris.alfeld@gmail.com>
Subject: Re: is GUI a weak point?
Date: Thu, 6 Apr 2006 03:58:04 +0900
--------------------------------------------------------------
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.
--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)

36

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.

37

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

···

On 5 Apr 2006, at 22:06, Carl Woodward 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.

38

[...]

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.

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 :wink:

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

···

On 4/5/06, Carl Woodward <cjwoodward@gmail.com> wrote:

--
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

39

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.

···

--
Posted via http://www.ruby-forum.com/\.

40

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