Idea: Linux PIM in Ruby

Lyle Johnson wrote:

Hal Fulton wrote:

Lyle: Is it hard to put a bunch of tiny subwindows inside a parent
frame? I’ve never done that in Fox.

Sure, definitely. That’s what layout managers are all about.

I was thinking not of tiled windows but overlapping, like notes
on a (physical) bulletin board. Probably easy, I’ve just never
done it.

I think it would be fun/informative to try to abstract away the
GUI here… I’ve tried that two or three times before with
mixed success.

In other words, I’d create a layer that would never change, then
create a mapping from that to Fox. (But nothing too fancy –
just wrap some calls if possible, not create a new GUI system.)

Then for example it would easy(-ier) to switch later from Fox
to GTK or wxWin or whatever, or even make alternatives.

Hal

Hi Hal,

···

On Sun, 7 Dec 2003 02:42:20 +0900, Hal Fulton hal9000@hypermetrics.com wrote:

I will check out hnb and Leo, but I’ll make another comment along
these lines.

While you’re surfing, also take a look at the Visual Knowledge Builder
at http://www.csdl.tamu.edu/VKB/

It has some nice features, but is written in Java …

s.

Emmanuel Touzery wrote:

i just dealt with that today :O)
FXText does support underline and strikethrough,

(also text background and foreground color btw)

Hal Fulton wrote:

I think it would be fun/informative to try to abstract away the
GUI here… I’ve tried that two or three times before with
mixed success.

In other words, I’d create a layer that would never change, then
create a mapping from that to Fox. (But nothing too fancy –
just wrap some calls if possible, not create a new GUI system.)

Then for example it would easy(-ier) to switch later from Fox
to GTK or wxWin or whatever, or even make alternatives.

wouldn’t it be smarter to have a core which knows nothing about GUI and
then several GUI layers ontop of it?
you think application directing GUI. how about GUI directing
application? seems cleaner to me, but then again…

emmanuel

Emmanuel Touzery wrote:

Hal Fulton wrote:

I think it would be fun/informative to try to abstract away the
GUI here… I’ve tried that two or three times before with
mixed success.

In other words, I’d create a layer that would never change, then
create a mapping from that to Fox. (But nothing too fancy –
just wrap some calls if possible, not create a new GUI system.)

Then for example it would easy(-ier) to switch later from Fox
to GTK or wxWin or whatever, or even make alternatives.

wouldn’t it be smarter to have a core which knows nothing about GUI and
then several GUI layers ontop of it?
you think application directing GUI. how about GUI directing
application? seems cleaner to me, but then again…

I think that is pretty much what Hal is saying.

I would also like to reinforce this theme: A core “engine” with no gui. The
gui can then be developed independently or, if you wish, separate (but
similar) gui applications can be written that all use this same core engine.

I have a longer term plan to create a ruby implementation of naked objects
(www.nakedobjects.org) using wxRuby, and an engine like this would make a
great candidate for auto-generating a gui.

Curt

···

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.548 / Virus Database: 341 - Release Date: 12/5/2003

Curt Hibbs wrote:

Emmanuel Touzery wrote:

Hal Fulton wrote:

Then for example it would easy(-ier) to switch later from Fox
to GTK or wxWin or whatever, or even make alternatives.

wouldn’t it be smarter to have a core which knows nothing about GUI and
then several GUI layers ontop of it?
you think application directing GUI. how about GUI directing
application? seems cleaner to me, but then again…

I think that is pretty much what Hal is saying.

Yes, that is what I meant.

I would also like to reinforce this theme: A core “engine” with no gui. The
gui can then be developed independently or, if you wish, separate (but
similar) gui applications can be written that all use this same core engine.

In practice, I find this difficult.

To get back to basics: I think the GUI serves as an I/O mechanism.

Sometimes the engine drives (calls) the GUI, to fill a window with data
or throw up a window or whatever.

Sometime the GUI drives the engine: The user pushes a button, and an
engine method gets called.

Hmm, can we separate these logically? Make two modules or classes,
perhaps?

I have a longer term plan to create a ruby implementation of naked objects
(www.nakedobjects.org) using wxRuby, and an engine like this would make a
great candidate for auto-generating a gui.

I’ve heard of naked objects, but I don’t yet understand them.

Auto-generating a GUI sounds cool but difficult.

Function doesn’t directly imply layout, for instance.

Hal

Hal Fulton wrote:

I think it would be fun/informative to try to abstract away the
GUI here… I’ve tried that two or three times before with
mixed success.

In other words, I’d create a layer that would never change, then
create a mapping from that to Fox. (But nothing too fancy –
just wrap some calls if possible, not create a new GUI system.)

Then for example it would easy(-ier) to switch later from Fox
to GTK or wxWin or whatever, or even make alternatives.

Interesting idea. I like the idea in that it seems like a good way
to write automated unit tests for GUIs, by having a mapping onto
some sort of mock object that just records the GUI operations
requested (e.g. gray this menu item, display these items in the list box
etc.)

Brett

Hal Fulton wrote:

I would also like to reinforce this theme: A core “engine” with no
gui. The
gui can then be developed independently or, if you wish, separate (but
similar) gui applications can be written that all use this same core
engine.

In practice, I find this difficult.

To get back to basics: I think the GUI serves as an I/O mechanism.

Sometimes the engine drives (calls) the GUI, to fill a window with data
or throw up a window or whatever.

Sometime the GUI drives the engine: The user pushes a button, and an
engine method gets called.

Hmm, can we separate these logically? Make two modules or classes,
perhaps?

the engine doesn’t need to know the user entered the data, or whether
it’s from a preference file etc. no need for the engine to open up a
window. the engine justs gets parameters with the input values and spits
out output values. if the engine wants to display warnings or whatever,
it should send “events” or exceptions for the GUI to pick up. the GUI
can display a dialog box, something in the system tray etc. the engine
doesn’t know and doesn’t care. this exists and is quite spread. consider
mp3 playing libraries and mp3 players, libavcodec and xine and mplayer
etc, or even cdrecord and CD burning apps under linux (although then the
connection engine/GUI is more loose because the engine is a full-blown
text app).

emmanuel

Hal Fulton wrote:

Curt Hibbs wrote:

Emmanuel Touzery wrote:

Hal Fulton wrote:

Then for example it would easy(-ier) to switch later from Fox
to GTK or wxWin or whatever, or even make alternatives.

wouldn’t it be smarter to have a core which knows nothing about GUI and
then several GUI layers ontop of it?
you think application directing GUI. how about GUI directing
application? seems cleaner to me, but then again…

I think that is pretty much what Hal is saying.

Yes, that is what I meant.

I would also like to reinforce this theme: A core “engine” with no gui. The
gui can then be developed independently or, if you wish, separate (but
similar) gui applications can be written that all use this same core engine.

In practice, I find this difficult.

To get back to basics: I think the GUI serves as an I/O mechanism.

Sometimes the engine drives (calls) the GUI, to fill a window with data
or throw up a window or whatever.

Sometime the GUI drives the engine: The user pushes a button, and an
engine method gets called.

Hmm, can we separate these logically? Make two modules or classes,
perhaps?

I shall regret posting the moment I thump ‘send’ :slight_smile:

Any repliers, please DELETE the whole script first … once is enough.

This paltry effort has, I hope, full separation of concerns.
The PIM is a server to whatever the TUI/GUI client.

As a non-programmer (SysProg), the challenging part of OOP is
leaving the ‘real world’ and getting right inside the object
rather than opening a class and force-feeding it with data
through accessors from an external ‘main’ method as most of
us start doing.

···

#---------------------------------------------------------------

‘ui_text’

class UI
Version = ‘Text 0.0.1 (boxy)’
#Text-only version (FX | VR | TK | WX etc. coming soon… :slight_smile:
def initialize(pim)
@pim = pim
@setup = false
@cmd = ‘setup’
end

def msgloop
loop do
@args = @cmd.split(/\s+/)
@cmd = @args.shift
# Sophisticated command parser … cuh!
case @cmd
when /setup/
unless @setup
@setup = true
puts ‘Initialising layout manager :-))’
help()
end
when /nt/
draw_box_each()
when /q(uit)?/, /exit/
return @cmd
when /h(elp)?/
help()
when /^\n/
else
puts “I’m afraid I can’t do … #{@cmd} #{@args}”
end
print "\nReady > "
@cmd = gets
puts
end
end

def help
puts ‘’, ‘Minimally useful commands available:’
puts ’ h(elp) - … this’
puts ’ q(uit) - Exit’
puts ’ nt - list of Name & Tel’
end

Cruft alert - plz ignore this meth.

def draw_box_each
# calls each_‘cmd’ (e.g. each_nt) in PIM for content
bar =‘’
@pim.method(“each_#{@cmd}”.intern).call do |row, nt, det|
if row == 0
# Title
line_width = 0
det.each {|n| line_width += (n+2)-1}
bar = ’ |—| ’ << ‘-’ * line_width << ‘|’
puts bar
print ’ | n ’
nt.each_with_index do |nm, eix|
printf(“| %-*s”, det[eix], nm) # heading
end
puts ‘|’, bar
else
printf(" |%2d “, row)
nt.each_with_index do |ent, col|
printf(”| %-*s", det[col], ent) # entries
end
puts ‘|’
end
end
puts bar
end
end

#---------------------------------------------------------------

class PIM
Version = ‘0.0.1 (alpha)’

private_class_method :new
def initialize
@nt_struct = Struct.new(:name, :tel)
@nt_detail = [30, 15] # field widths
@nta = nil
end

def PIM.run
UI.new(new).msgloop # Pass PIM object to whatever UI
puts “\nThank you for using PIM #{Version} with #{UI::Version}\n\n”
sleep 2
end

#######
private
#######

def each_nt
@nta || load_nt
# Column titles first (index = 0)
yield 0, @nt_struct.members.map {|e| e.capitalize}, @nt_detail
@nta.each_with_index do |nt, ix|
yield ix+1, nt, @nt_detail
end
end

def load_nt
@nta =
while nt = DATA.gets
nt = nt.chomp.split(/,\s*/)
@nta << @nt_struct.new(*nt)
end
end
end

#require ‘ui_text’

PIM.run # Return when UI receives quit

Test data follows END

NOT suitable for this kind of app!!

END
Yukihiro Matsumoto, 11-111-1111
bbb b bbbbbb, 22-222-2222
ccccccc ccccc, 33-333-3333

#----------

This isn’t a bid to join (or be banned from) a team.

If anything develops, it may be converted from
a Linux PIM (what’s that ?) to a splendid vruby/swin
PIM (?) targeted at we occupants of the sinking ship
Hal (apparently) can’t wait to abandon :slight_smile:

'Scuse the cheek.
Maximum respect to all open-sourcerers.

daz

Emmanuel Touzery wrote:

Hal Fulton wrote:

I would also like to reinforce this theme: A core “engine” with no
gui. The
gui can then be developed independently or, if you wish, separate (but
similar) gui applications can be written that all use this same core
engine.

In practice, I find this difficult.

To get back to basics: I think the GUI serves as an I/O mechanism.

Sometimes the engine drives (calls) the GUI, to fill a window with data
or throw up a window or whatever.

Sometime the GUI drives the engine: The user pushes a button, and an
engine method gets called.

Hmm, can we separate these logically? Make two modules or classes,
perhaps?

the engine doesn’t need to know the user entered the data, or whether
it’s from a preference file etc. no need for the engine to open up a
window. the engine justs gets parameters with the input values and spits
out output values. if the engine wants to display warnings or whatever,
it should send “events” or exceptions for the GUI to pick up. the GUI
can display a dialog box, something in the system tray etc. the engine
doesn’t know and doesn’t care. this exists and is quite spread. consider
mp3 playing libraries and mp3 players, libavcodec and xine and mplayer
etc, or even cdrecord and CD burning apps under linux (although then the
connection engine/GUI is more loose because the engine is a full-blown
text app).

I think its a good approach. The idea is to embody the interface between the
engine and the UI with an api. This is a worthy goal whether or the api is
call-based or message-based.

Also, while there would be an initial learning curve, you should consider
using FreeBASE. This would give you a ready-built, dynamically-extendable
plugin system (always a good idea in a complex system), plus a built in
messaging engine and data-store (with persistence). The time you would save
by using it would be way more than the time you spent learning it. Plus Rich
and I would be happy to help you get up-to-speed as it would be nice to see
it used somewhere besides FreeRIDE (I’m going to use it in Naked Ruby).

Curt

···

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.548 / Virus Database: 341 - Release Date: 12/5/2003