Hi Max,
I can see where you are coming from. One of the problems with email as a
forum for discussion is that too much becomes noise and too little can be
mistaken for apathy. My own perspecive on some of the issues you (and
pekr) have raised follows.
The REBOL community, such as it is, probably has a more diverse background
than other technical communities, with some areas of note being:
- A good mix of people from multiple OS backgounds (Windows, *NIX, Mac,
Amiga, other)
- Different positions / perspective on the proprietary / open source /
licencing question(s)
- Programming background (C [and derivatives such as Perl / Java], Basic,
Lisp, COBOL, etc)
- Involvement (full-time, part-time, academic, professional, hobbyist,
student, etc)
- Skill-level (general programming and / or REBOL-specific)
- Interests / focus within REBOL (GUI / graphics, Web / CGI, email,
concepts, dialects, parse, algorithms, etc)
This diversity is a *good* thing IMHO, and quite different from, say, the
PERL community which might come predominantly from an open-source *NIX C
background. That's not a bad thing in its own right, but mono-cultures are
not the domain of MS alone! ;)
In my case, running a software company that uses REBOL on Windows
exclusively, I spend eight hours a day with REBOL. Digesting each day's
REBOL list email takes about an hour of that time. I'd love to respond to
/ participate in more of the discussions but time is a big factor for me.
I try to at least look at every REBOL project that is released (pdf-maker,
konka, mysql protocol, rugby, async, steel to name but a few) but tend to
focus on those that meet the following requirements:
- they do not already do something that REBOL does *or* could be easily
implemented (by me) in REBOL
- they address a specific requirement that I currently have
- they are stable (it works, and changes don't invalidate what I have done)
pdf-maker and the mysql protocol are good examples of others code I have
used to solve specific reporting and database requirements respectively. I
started looking at rugby for simple client / server comms, but as often
happens, this list provided a dozen line solution to my problem so I ended
up rolling my own. Does this mean I will never use rugby? No. Does this
mean I don't appreciate the effort the author put into the project or
their generosity in making the fruit of their labour available to others?
No.
The reason I have this preference to roll my own is that I want to
understand / control as much of the problem domain as possible, in as few
lines of code as possible. I prefer using code with the RT stamp of
approval as I only have to worry about the entry-points not the details
(with non-RT code I find myself thinking of it as "external" and wanting
to verify / understand its implementation). I suppose REBOL has spoiled me
in this regard as its extensions are predominantly source-based (unlike
black-box binary extensions).
I would hazard a guess that most folks who spend some time with VID have
some sort of GUI library script with various pre-defined styles and / or
functions that they use. Is it a bad thing that we don't all use a common
community defined GUI library? No. My GUI library does the following
things:
- defines a base "element" size based on current font size
- uses stylize/master to standardize the size of all widgets
- sets default origin and spaceing based on current font size
These meet *my* requirements to have a GUI that can be specified in a
cell-like manner and adjusts dynamically to font size changes. It's not
complex, but it gets the job done. Would it meet anyone else's
requirements? Maybe a subset or a superset but not an exact fit.
Steel looks quite innovative and I like the fact that it is built directly
on View. If and when RT releases VID 1.3 I'll put the time in to look at
what each offers me and where I'm best off putting my limited R&D time.
Will I contribute to steel discussion / development? If I end up using it,
you bet!
Regards,
Ashley
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
