[OT] Re: GUI's and the Rouge, Part III (yes, finally) 1/2

Hal, i gots to know more. need to know about your plugable work. i’ve
done work on a couple such designs myself. what have you come up with so
far?

~transami

p.s. love the book, just picked it up a few days ago. thanks.

···

On Tue, 2002-07-30 at 08:43, Hal E. Fulton wrote:

I’ve been experimenting with the “pluggable” UI concept.
Since I don’t understand MVC that much, I’m probably
reinventing the wheel (or rediscovering fire). But it’s
an interesting concept to me.

Anyone who wants to discuss it, speak up.

Cheers,
Hal

^^^^^^^

Could as well advocate a windows only package, remember, GNU's not Unix,
Linux's Gnu, Unix's not Linux - there are others out there, and most
do not have gpm. Curses at least is portable.

-Martin

···

On Fri, Jul 26, 2002 at 09:31:22PM +0900, Massimiliano Mirra wrote:

On Fri, Jul 26, 2002 at 07:51:25PM +0900, Thomas Dickey wrote:

there’s a development kit for curses:
http://www.vexus.ca/products/CDK/
better (fewer bugs, etc):
CDK – Curses Development Kit (a library of widgets)

As a point of interest, here’s something else from the Debian
database:

Package: libctk3
Priority: optional
Section: libs
Installed-Size: 119
Maintainer: Pete Lypkie (Debian) plypkie@debian.org
Architecture: i386
Source: libctk
Version: 3.0.24
Depends: libarr0, libc6 (>= 2.2.3-1), libglib1.2 (>= 1.2.0), libgpmg1 (>= 1.14-16)
Filename: pool/main/libc/libctk/libctk3_3.0.24_i386.deb
Size: 51928
MD5sum: 24d6cf97952b63301943bac345a55189
Description: Console Tool Kit
Console Tool Kit is a toolkit for writing textbased GUIs. The syntax is
almost the same as GTK+. It provides mouse support on the console through
gpm.

This DID work, just not from clicking through IE/Win32…I know, I
know, get a real OS…I just used the command line FTP.

Thanks,

Rich

“My other machine runs OS X”

From: Rich Kilmer [mailto:rich@infoether.com]
Sent: Friday, July 26, 2002 8:26 AM
To: ruby-talk ML
Subject: RE: curses dev kit, was Re: [OT] Re: GUI’s and the Rouge

The link to the code is not functional…

From: Thomas Dickey [mailto:dickey@saltmine.radix.net]
Sent: Friday, July 26, 2002 6:51 AM
To: ruby-talk ML
Subject: Re: curses dev kit, was Re: [OT] Re: GUI’s and the Rouge

Tom Sawyer:

Had a look at ncurses recently? :slight_smile:

no, never used it. nice design? would it worth binding too in
order

···

-----Original Message-----

-----Original Message-----
clemens fischer ino-waiting@gmx.net wrote:

On Thu, 2002-07-25 at 08:02, Massimiliano Mirra wrote:
to
have console capability?

there’s a development kit for curses:

http://www.vexus.ca/products/CDK/

better (fewer bugs, etc):

http://invisible-island.net/cdk/


Thomas E. Dickey dickey@radix.net dickey@herndon4.his.com
http://dickey.his.com
ftp://dickey.his.com

The link to the code is not functional…

actually it is (but I get occasional reports from people who have trouble
getting to that host).

···

Rich Kilmer rich@infoether.com wrote:

-----Original Message-----
From: Thomas Dickey [mailto:dickey@saltmine.radix.net]
Sent: Friday, July 26, 2002 6:51 AM
To: ruby-talk ML
Subject: Re: curses dev kit, was Re: [OT] Re: GUI’s and the Rouge

clemens fischer ino-waiting@gmx.net wrote:

Tom Sawyer:

On Thu, 2002-07-25 at 08:02, Massimiliano Mirra wrote:

Had a look at ncurses recently? :slight_smile:

no, never used it. nice design? would it worth binding too in order to
have console capability?

there’s a development kit for curses:

http://www.vexus.ca/products/CDK/

better (fewer bugs, etc):

CDK – Curses Development Kit (a library of widgets)


Thomas E. Dickey dickey@radix.net dickey@herndon4.his.com
http://dickey.his.com
ftp://dickey.his.com


Thomas E. Dickey dickey@radix.net dickey@herndon4.his.com
http://dickey.his.com
ftp://dickey.his.com

I’ve been experimenting with the “pluggable” UI concept.
Since I don’t understand MVC that much, I’m probably
reinventing the wheel (or rediscovering fire). But it’s
an interesting concept to me.

Anyone who wants to discuss it, speak up.

Cheers,
Hal

Hal, i gots to know more. need to know about your plugable work. i’ve
done work on a couple such designs myself. what have you come up with so
far?

Oh, nothing earth-shattering. I have a couple of apps I’m
playing with, and putting all the user interface stuff
into modules.

Have come up with some simple concepts and rules of thumb.
For example, there is a kind of “one-way coupling” of the UI
module with the “core” of the app. That is, the UI methods
are allowed to know the details of the app itself, but the
app need not (is not allowed to) know the details of the
UI code.

Except: The UI code must have a simple common interface for
whatever GUI or TUI is implemented. Typically I have
implemented this as fairly high-level routines like
ui_prompt_user_yes_no(msg) which e.g. will display a msg and
get a yes or no response. In Tk or Fox I use buttons; at the
simplest level I use puts and gets.

I use a ui_init for whatever initialization needs to be done.
In pure text, this may be empty.

I use a ui_eventloop that translates in a straightforward way
into Tk or Fox code. In pure text form, it can simply call a
method that displays a menu and/or gets a command via gets.

Within each module (in the methods), I can reference data
members as needed and they will spring into the existence in
the class into which I’ve included the module. These can be
used to store info related to Tk or Fox widgets or whatever
is needed. It’s a slight increase in coupling, but if the
“core” code doesn’t know about the new member variables (and
it shouldn’t), then it won’t normally be referencing them.
There is, of course, the chance that the same name will
accidentally be used for a “core” variable and an “interface”
variable. Since I’m writing both, this doesn’t usually happen
to me. You can reduce the chance by a prefix like “ui_”, i.e.
@ui_root or whatever.

Incidentally, there was some discussion about whether people
actually ever write an app with a text interface and add a
GUI later. I’ve been trying that with these two apps, and I
like it a lot so far. It helps with SOC (separation of concerns)
and it makes the interface easier to switch around.

p.s. love the book, just picked it up a few days ago. thanks.

Thank you.

Hal

···

----- Original Message -----
From: “Tom Sawyer” transami@transami.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 10:40 AM
Subject: Re: [OT] Re: GUI’s and the Rouge, Part III (yes, finally) 1/2

On Tue, 2002-07-30 at 08:43, Hal E. Fulton wrote:

So? It doesn’t say that it depends on gpm, it says that if it’s
there, it’ll be used to make mouse available. I don’t see a problem
with that.

Massimiliano

···

On Fri, Jul 26, 2002 at 09:37:31PM +0900, Martin Weber wrote:

Console Tool Kit is a toolkit for writing textbased GUIs. The syntax is
almost the same as GTK+. It provides mouse support on the console through
gpm.
^^^^^^^

Could as well advocate a windows only package, remember, GNU’s not Unix,
Linux’s Gnu, Unix’s not Linux - there are others out there, and most
do not have gpm. Curses at least is portable.

It seems that quite a few of us have been experimenting with interface
abstraction by using standard tools only.

I wonder if there is merit in the idea of joining minds and creating a
proof-of-concept application that uses the best of what we’ve learnt.

In the worst case a fine tuned skeleton could be produced that people
would be able to use as a guideline; in the best case a design pattern
could be isolated and then required at will, like observer.rb or
forwardable.rb.

Just a thought.

Massimiliano

···

On Wed, Jul 31, 2002 at 03:16:27AM +0900, Hal E. Fulton wrote:

I’ve been experimenting with the “pluggable” UI concept.
Since I don’t understand MVC that much, I’m probably
reinventing the wheel (or rediscovering fire). But it’s
an interesting concept to me.
Hal, i gots to know more. need to know about your plugable work. i’ve
done work on a couple such designs myself. what have you come up with so
far?
Oh, nothing earth-shattering. I have a couple of apps I’m
playing with, and putting all the user interface stuff
into modules.

…except you use its mouse support. I prefer using things which do
not tempt me to use non portable stuff when I want to use their “full
power”.

-Martin

···

On Sat, Jul 27, 2002 at 12:16:26AM +0900, Massimiliano Mirra wrote:

On Fri, Jul 26, 2002 at 09:37:31PM +0900, Martin Weber wrote:

Console Tool Kit is a toolkit for writing textbased GUIs. The syntax is
almost the same as GTK+. It provides mouse support on the console through
gpm.
^^^^^^^
[…]

So? It doesn’t say that it depends on gpm, it says that if it’s
there, it’ll be used to make mouse available. I don’t see a problem
with that.

It’s an interesting thought.

It’s not obvious to me that it can be done in the
general case, but I’d love to be proved wrong.

I had thought of using RubyRED as just such a
proof-of-concept app. But I badly need to refactor
it, as I’ve made some poor decisions in creating it.

Hal

···

----- Original Message -----
From: “Massimiliano Mirra” list@NOSPAMchromatic-harp.com.web-hosting.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, August 01, 2002 8:16 AM
Subject: Re: [OT] Re: GUI’s and the Rouge, Part III (yes, finally) 1/2

It seems that quite a few of us have been experimenting with interface
abstraction by using standard tools only.

I wonder if there is merit in the idea of joining minds and creating a
proof-of-concept application that uses the best of what we’ve learnt.

In the worst case a fine tuned skeleton could be produced that people
would be able to use as a guideline; in the best case a design pattern
could be isolated and then required at will, like observer.rb or
forwardable.rb.

Just a thought.

Massimiliano (and all other interested parties):

i believe you have a plan. and i would love to host that endeavor.

i’m curious to know how you see the design pattern being different from
the model-view-controller pattern. a higher level meta-pattern on top of
mvc? i guess we’ll find out.

anyway, i think your idea is a must-do.

which brings me to GUtopIa. i want to let you know that the GUI project
i’ve been talking about has gotten under way. go to

http://www.rubygui.org.

i’ve also set up a savannah account to host the development cvs and
mailing lists, etc. i set up two mailing lists which should be ready
later this evening: gutopia-dev and gutopia-user. we could use one or
the other to host this initial disscusion (preferably gutopia-dev, but
participants would have to sign up as gutopia developers.) (NOTE: I HAVE
TO THANK CURT HIBBS FOR ALL THIS! THANKS CURT!)

you can see an example of my initial work on the site. and there is
source available at the savannah site. i feel i have done pretty well at
refining the gui “code pattern” but i am still not 100% satisfied with
it on a few points. and who knows perhaps there’s a much better way too!
(Be aware that while i have laid-out a fairly good appraoch of beginning
with a back-end GUI that is already available for Ruby and migrating to
a more capable one, all is still very much subject to change and open to
suggestion.)

i would think the best approach to this discussion would be to announce
the upcoming discussion with a prior call for submissions of related
materials --simple “white-papers” and/or code samples to act as a bases
for the discussion.

if this sounds good to you let me know, (and all other interested
parties) and i will proceed.

~transami

···

On Thu, 2002-08-01 at 07:16, Massimiliano Mirra wrote:

It seems that quite a few of us have been experimenting with interface
abstraction by using standard tools only.

I wonder if there is merit in the idea of joining minds and creating a
proof-of-concept application that uses the best of what we’ve learnt.

In the worst case a fine tuned skeleton could be produced that people
would be able to use as a guideline; in the best case a design pattern
could be isolated and then required at will, like observer.rb or
forwardable.rb.

worse than that - many of those packages have not been built on anything
except for Linux.

···

Martin Weber Ephaeton@gmx.net wrote:

On Sat, Jul 27, 2002 at 12:16:26AM +0900, Massimiliano Mirra wrote:

On Fri, Jul 26, 2002 at 09:37:31PM +0900, Martin Weber wrote:

Console Tool Kit is a toolkit for writing textbased GUIs. The syntax is
almost the same as GTK+. It provides mouse support on the console through
gpm.
^^^^^^^
[…]

So? It doesn’t say that it depends on gpm, it says that if it’s
there, it’ll be used to make mouse available. I don’t see a problem
with that.

…except you use its mouse support. I prefer using things which do
not tempt me to use non portable stuff when I want to use their “full
power”.


Thomas E. Dickey dickey@radix.net dickey@herndon4.his.com
http://dickey.his.com
ftp://dickey.his.com

No, it’s much easier: mouse support in console is essential for you
and optional for me.

File.chmod won’t work in Windows 98, yet we’re both programming in
Ruby. Why? Because the object of non portability is optional to both
of us.

Massimiliano

···

On Sat, Jul 27, 2002 at 12:29:02AM +0900, Martin Weber wrote:

So? It doesn’t say that it depends on gpm, it says that if it’s
there, it’ll be used to make mouse available. I don’t see a problem
with that.

…except you use its mouse support. I prefer using things which do
not tempt me to use non portable stuff when I want to use their “full
power”.

Tom Sawyer wrote:

which brings me to GUtopIa. i want to let you know that the GUI project
i’ve been talking about has gotten under way. go to

http://www.rubygui.org.

i’ve also set up a savannah account to host the development cvs and
mailing lists, etc. i set up two mailing lists which should be ready
later this evening: gutopia-dev and gutopia-user. we could use one or
the other to host this initial disscusion (preferably gutopia-dev, but
participants would have to sign up as gutopia developers.) (NOTE: I HAVE
TO THANK CURT HIBBS FOR ALL THIS! THANKS CURT!)

You’re welcome. I’m just happy that to see this happenning, and I anxiously
await the fruits of you project’s efforts.

Curt

It seems that quite a few of us have been experimenting with interface
abstraction by using standard tools only.

I wonder if there is merit in the idea of joining minds and creating a
proof-of-concept application that uses the best of what we’ve learnt.

In the worst case a fine tuned skeleton could be produced that people
would be able to use as a guideline; in the best case a design pattern
could be isolated and then required at will, like observer.rb or
forwardable.rb.

Massimiliano (and all other interested parties):

i believe you have a plan. and i would love to host that endeavor.

i’m curious to know how you see the design pattern being different from
the model-view-controller pattern. a higher level meta-pattern on top of
mvc? i guess we’ll find out.

I don’t know if it is a design pattern in the Gang Of Four sense. It
might be a program design pattern, rather than an architecture design
pattern. Or a coding pattern, e.g. distributing code among modules so
as to be able to play with clever conditional require’s. In any case
I think there is a working pattern somewhere, even if its pieces are
spread among the works of different authors.

(``Pattern’’ might not be the most correct term here, but you get the
sense.)

As to the reason of actualizing it with standard tools: given that
we’re able to write program logic that follows a convention when it
comes to GUI (a little meta language, one could say), not only it
becomes simple for us to provide it with a GUI based on our favourite
toolkit, it also becomes simple for others to provide it with a GUI
based on their favourite toolkit.

I believe that, if a program is worthy, and ground is well prepared,
open development will do its job and people will happily design
interfaces for it. The key point is that it has to be made very easy,
almost routine work for them, for this to work: if yesterday I built a
GTK interface for your program, and today I’m building a GTK interface
for another one, the tasks will have to look extremely similar, and in
neither case I will have to investigate the internals of the program.

There are examples of this around. Take `licq’: it’s got GTK, QT,
KDE, ncurses and maybe more interfaces. It probably can’t be done
easily with complicate programs, but that’s fine – I doubt one would
take the time to build an alternate interface for Illustrator, however
well paved the road may be. :wink:

anyway, i think your idea is a must-do.

which brings me to GUtopIa. i want to let you know that the GUI project
i’ve been talking about has gotten under way. go to

http://www.rubygui.org.

i’ve also set up a savannah account to host the development cvs and
mailing lists, etc. i set up two mailing lists which should be ready
later this evening: gutopia-dev and gutopia-user. we could use one or
the other to host this initial disscusion (preferably gutopia-dev, but
participants would have to sign up as gutopia developers.)

I’ll sign on the usr list for now. :slight_smile:

(NOTE: I HAVE TO THANK CURT HIBBS FOR ALL THIS! THANKS CURT!)

Yeas, he’s patron to rpkg as well. Can’t thank him enough. :slight_smile:

you can see an example of my initial work on the site. and there is
source available at the savannah site. i feel i have done pretty well at
refining the gui “code pattern” but i am still not 100% satisfied with
it on a few points. and who knows perhaps there’s a much better way too!
(Be aware that while i have laid-out a fairly good appraoch of beginning
with a back-end GUI that is already available for Ruby and migrating to
a more capable one, all is still very much subject to change and open to
suggestion.)

i would think the best approach to this discussion would be to announce
the upcoming discussion with a prior call for submissions of related
materials --simple “white-papers” and/or code samples to act as a bases
for the discussion.

Hmmm, theoretically fine, but ask around and I bet ten people out of
ten will tell you they can spare one hour to write code but not one to
explain it. Given the expressive nature of Ruby code (and a bit of
attention on our side not to obfuscate it ;-)) I think we could just
throw our code in with some comment and let a bigger picture emerge.

if this sounds good to you let me know, (and all other interested
parties) and i will proceed.

Brainstormers wanted. :slight_smile:

Massimiliano

···

On Fri, Aug 02, 2002 at 04:21:15AM +0900, Tom Sawyer wrote:

On Thu, 2002-08-01 at 07:16, Massimiliano Mirra wrote:

That’s ok. Just pick the ideas up from RubyRED that you deem
relevant, we can then test/apply them on something started from
scratch.

About what kind of application can be chosen: let’s pick one of the
three or four GUI application we use most often. For example, I use a
music player, a spread sheet, and an instant messenger. All of them
seem to fit within a MVC scheme, with the added characteristic in the
case of the instant messenger that output doesn’t necessarily happen
in response to a user event but also to a remote event. So among the
three I’d pick up the messenger as the most representative. And I
would rule out programs that rely on very specialized widgets such as
a 3D modeller.

Still brainstorming… :slight_smile:

Massimiliano

···

On Thu, Aug 01, 2002 at 11:59:37PM +0900, Hal E. Fulton wrote:

In the worst case a fine tuned skeleton could be produced that people
would be able to use as a guideline; in the best case a design pattern
could be isolated and then required at will, like observer.rb or
forwardable.rb.
It’s an interesting thought.

It’s not obvious to me that it can be done in the
general case, but I’d love to be proved wrong.

I had thought of using RubyRED as just such a
proof-of-concept app. But I badly need to refactor
it, as I’ve made some poor decisions in creating it.

Well, yeah, but Ruby itself makes it easier to write portable code.

Portable doesn’t only mean “run on windows and unix”, it also means
“Run on any unix”.

File.chmod will work on solaris, AIX, *BSD, Mac OS X etc. too.

That library most probably won’t. Curses will.

It’s like those “Unix Downloads” whose source files #include <linux/…h>.

But hey, for LINUX ONLY stuff, guess you can use it and get happy with it :slight_smile:
You’re just crippling your possible audience (if you’re developing useful open-
source stuff), and I suppose not all of us here want to do that.

-Martin

···

On Sat, Jul 27, 2002 at 06:15:37AM +0900, Massimiliano Mirra wrote:

On Sat, Jul 27, 2002 at 12:29:02AM +0900, Martin Weber wrote:

So? It doesn’t say that it depends on gpm, it says that if it’s
there, it’ll be used to make mouse available. I don’t see a problem
with that.

…except you use its mouse support. I prefer using things which do
not tempt me to use non portable stuff when I want to use their “full
power”.

No, it’s much easier: mouse support in console is essential for you
and optional for me.

File.chmod won’t work in Windows 98, yet we’re both programming in
Ruby. Why? Because the object of non portability is optional to both
of us.

^^^^^^^^

That’s the point: you don’t know. Ground criticism of a software on
facts instead of prejudices, and I’ll gladly thank you for what will
be a useful warning.

Massimiliano

···

On Sat, Jul 27, 2002 at 06:23:26AM +0900, Martin Weber wrote:

No, it’s much easier: mouse support in console is essential for you
and optional for me.

File.chmod won’t work in Windows 98, yet we’re both programming in
Ruby. Why? Because the object of non portability is optional to both
of us.

File.chmod will work on solaris, AIX, *BSD, Mac OS X etc. too.

That library most probably won’t. Curses will.

Okay, how about this. I was getting that piece of library, and after some
hacking to the configure scripts of both libctk and libarr it would even
start compiling. And now we come to the point I mentioned: “Unix” software
including “linux” headers. Want a taste ?

gcc -DHAVE_CONFIG_H -I. -I. -I. -I/home/phaeton/tmp/include -g3 -O2 -DNDEBUG -Wall -I… -I/usr/pkg/include/glib/glib-1.2 -I/usr/pkg/lib/glib/include -c ctkmain.c -Wp,-MD,.deps/ctkmain.TPlo -fPIC -DPIC -o .libs/ctkmain.lo
ctkmain.c:42: linux/vt.h: No such file or directory
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gmake[2]: *** [ctkmain.lo] Error 1
gmake[2]: Leaving directory /alt/space/tmp/libctk/libctk-3.0.25/ctk' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory /alt/space/tmp/libctk/libctk-3.0.25/ctk’
gmake: *** [all-recursive] Error 1

Now happy ?

If you aren’t spend a second view on the ctkmain.c:42 line above.

My system doesn’t have a vt.h, in fact my system (NetBSD) handles
virtual terminals way different from linux. And if I see a library
which already requires linux specific stuff… (interesting warning
from the configure:

configure: error: libctk really recommends gpm - disable with ‘–disable-gpm’ if you really know what you’re doing
)

…then it’s no prejudice to expect it not to work on non linux platforms.
I have met more than one so called “unix” software (lib/app) which only
works on linux. But hey, guess you will want me to get a precompiled
lib and use it on my system’s binary linux emulation instead ? Fine, I
can do that, most probably. The picture changes for those solaris, AIX, etc.
users out there. As I said, even there will be a curses.

-Martin

···

On Sat, Jul 27, 2002 at 11:23:06PM +0900, Massimiliano Mirra wrote:

On Sat, Jul 27, 2002 at 06:23:26AM +0900, Martin Weber wrote:

No, it’s much easier: mouse support in console is essential for you
and optional for me.

File.chmod won’t work in Windows 98, yet we’re both programming in
Ruby. Why? Because the object of non portability is optional to both
of us.

File.chmod will work on solaris, AIX, *BSD, Mac OS X etc. too.

That library most probably won’t. Curses will.
^^^^^^^^

That’s the point: you don’t know. Ground criticism of a software on
facts instead of prejudices, and I’ll gladly thank you for what will
be a useful warning.

Of hearing a fact at last, yes.

Massimiliano

···

On Sun, Jul 28, 2002 at 01:50:01AM +0900, Martin Weber wrote:

Now happy ?