AltME groups: search

Don't think there is a built-in function for that.
Try this:
>> to-char base-convert/from-base "7c" 16
== #"|"
Base-convert.r is in the REBOL.org script library

next-ip: func [ip][to-tuple debase/base to-hex (to-integer to-binary 
ip) + 1 16]

the parentheses improves readability, but are optional if you swap 
the operands :

next-ip: func [ip][to-tuple debase/base to-hex 1 + to-integer to-binary 
ip 16]

There are many ways to do that.

Show image
Show image upside down below it.
Put alpha gradiant of table colour in front of that.

It will alos look a lot better if you add a feathered ellipse near 
the base of the highlight colour from the image.

The search function is changing a bit.  I'm simplifying the look 
so that it is only two blocks:

db/search [logic][action]


There will no longer be a database block.  Instead a database and 
field will be inputed together such as:

db/search [my-base.field-name > 1][my-base.field-name]


In that example it would check the database called "my-base" and 
check its fieldname which is called simply "field-name" in the example 
above to see if it is greater than the value  of 1.  If it is then 
it returns the field-name value.

I can see two reasons why a top 10 could have more than10 entries 
in it.....


.....First, it is about ranking -- if 100 people graduate from a 
class, and 30 of them all have identical top scores, then the top 
1 position is held by 30 people.
Depending then on how you define "top 10": the top 10 is either:
* the top 30 graduates; or

* some larger number (the total graduates with the highest distinct 
ten scores -- which could be all of them).


Second,. it could be an unconscious homage to the 10 reasons why 
Base Camp Sucks (It seems the Base Camp developers also chose to 
disregard user priorities, but they at least deny requests as they 
are made rather than play mind games with the user community):
http://www.whybasecampsux.org/

It seems the Base Camp developers also chose to disregard user priorities
  that is pretty rude....unfair, and untrue...shame....

If you go to files and browse to upload, is the base dir the same 
as it always has been?

Yes, I did hear problems with other people connecting to ALtme.
The base of the files are in the same places.

Oldes, I'd be surprised if the link handler were dramatically different 
to the IOS Conference link handler.  You could use that as a base 
with which to offer a fix?

well Altme serves as a knowledge base as well.

I'm just suprised, that Rebol/Core shows me more memory using stats 
but less in top than Rebol/Base where I have less memory in stats 
but more in top

>> enbase/base to binary! 255.0.0 16
== "FF0000"

what is the easiest/most direct way to convert an integer value into 
a 4 byte binary (equivalent to to a 4 byte unsigned LONG) ?


for some reason, this kind of thing is not 'simple in REBOL I expected 
this to work. but didn't even get a one byte binary.

>> to-binary 100
== #{313030}


100 is a numerical value, not a string, I would have expected (in 
base 16 which is default) :
#{64}

Given that 1/1/0000 is a base is doesn't seem logical to me to able 
to subtract from it . I'd go with a script error or if that's not 
desirable return the base value ie 1/1/0000

issue-to-binary: func[clr] [debase/base as-string clr 16]

issue-to-binary: func[clr] [debase/base clr 16]

i think base 64 uses /

with BASE being a string with 64 1s and 64 0s, this is a way to get 
64 random bits:

Rebolinth anyone can write an SVG emitter, just like there is a Flash 
emitter. I think this complex and unique enough that it shouldn't 
be included in the base. But 3rd party script will do.

Allen - you may not be interested if Carl's rotary serves your needs 
but I find the FX5 rotary that Frank Sievertsen created some years 
ago to be a bit more usable because he added the left and right arrow 
navigation to the base rotary.   Clicking on the rotary itself rolls 
it forward but with the FX5 one, you have a back option instead of 
having to cycle through the list.    The rotary is still a bit cumbersome 
without key board support that is specific to the widget when it 
has focus.

I make a listview widget multicolumn multi resizing with drag&drop 
Viewed bar effet like in Win32API and multi widget type capable in 
only 3 weeks and using less than 300 That's the illustration that 
REbgui and VID base concept are pretty good  !!

AGG based app - nice :-) http://www.epsitec.ch/cresus/documents/base-f.php

Volker - thanks for 'dirty explanation. It seems to be handy. But 
- does 'dirty work for other elements too, as e.g. check-box? In 
old x-base days, we used to use scatter and gather methods. So, if 
'dirty flag solves just fields, it shows incompetence of designer 
imo ;-), such thing should be done via accessor functions - set-face, 
get-face, which eventually can even format output, e.g. in the case 
of radio button to translate into some other value. Robert with Cyphre 
e.g. defined "form dialect" for Robert's private IOS effort. Did 
not see it in action, but probably it tried to solve things in more 
general way.

So - stating that - I would really appreciate such things to be documented 
or at least discussed. If we start to add such things into VID, it 
should be agreed upon by more wider audience. I e.g. have rather 
good experience with x-base databases, others surely too, but if 
the solution works for 80% of cases only, it will once again lead 
programmers to simply ommit what is available and introduce own, 
more complex scenarios ....

we need something like VID2, created from scratch (or almost), and 
strong enough to serve as a building base for applications.

it's not that VID is not good, it's that its purpose was not to be 
the ultimate gui framework, but more of an example of what you can 
do; indeed, now we have RebGUI too. but, the problem with that way 
of thinking, is that in practice developers need a solid base to 
start. so it's much better for everyone to provide it.

hmm, I would like to know Mike, what actually were you doing? Because 
- in old DBF x-Base days it worked like that - you simply had "cursor" 
at some db position and you moved by using 'skip command .... of 
course even then, it was wise to use indices and to limit the scope 
of data you work with ...

Now on cursors - of course, old x-base aproach is possible with SQL 
too, it is called "live cursor" or something like that. But with 
larger systems, adming don't allow or don't like to see it, as it 
consumes additional resources. Some of databases even don't have 
it. IIRC mySQL will introduce it from version 5.0, or maybe I am 
wrong ....

I guess it would be a good base for a spreadsheet?

I use http://polly.rebol.it/test/test/desktop/test-desktop.rfor 
my own site, there you can specify passwords for base-urls. but all 
hardwired still.

Graham, if you have trouble, maybe convert to base 64 using ENBASE 
?

So, instead of forcing the conversion of the bytes stream in the 
block data model. The list view could interrogate the controller 
to extract the data from the base model.

view-root is the base-dir for /view-related files. originally that 
was where the exe is, due to multi-user it is now somewhere in the 
users home. important things there: %public/ for the cache, %user.r 
(not sure if it is the only place where it looks for it), %desktop/ 
for desktop-icons etc, %local/ for local index.r . basically if i 
want to install something view-related, i use view-root at base.

>> view layout [base-text "hello" with [focus self]]
** Script Error: Invalid graphics face object
** Where: focus
** Near: show face

there is another VID base doc, simpler, might help you start.

http://www.rebol.com/docs/view-guide.html

honestly, I literaly learned all of the VID tricks my doing this:

Looks like the instructions are written for someone who already knows 
how to use it...
- run the script  ## this dosn't seem to do anything

- Run the parse-analysis.r script and use the tokenise-parse function 
to get the base data.  ## dont understand what this means, tried 
a few things but they all give errors.

The example works, but I cant even see the parse expressions in it 
so I dont understand why it works or how to adapt it for my own example.

When I first looked at this in April I got quite frustrated because 
it looked as if it was there to help newbies learn about parse, but 
it was too hard for newbies to understand how to use... now I can 
at least understand how to run the example.  Thanks

NZ at Scott Base ?

so out side the base, one is essentially in Rod Serling's  home ....

currently we can't download a single message knowing his Id. We only 
can download all the base, and the remaining messages each time the 
client sync. Not a good system to my mind

Which exposes a nice bug in A110. There is no longer an issue! type 
which can be used for arbitrary base literal numbers.

First of all, we never had a type that could be used for arbitrary 
base literal numbers, except the string types.

A binary is only formatted with hex characters (if the binary-base 
is 16). A string would actually containthe hex characters themselves.

So to-hex would be shortcut for enbase/base to-binary num 16. Rather 
useless.

3. CONSTRUCTION OF PORTABLE ALUMINUM LADDERS


3.1 Aluminum ladders are divided into two basic types of construction, 
viz:, solid beam and truss.


3.1.1  Solid Beam Aluminum Construction- This type of ladder has 
a solid side rail construction with aluminum rungs connecting with 
the side rails at fourteen inch intervals. The connection is generally 
either by a welded joint between rung and side rails, or by an expansion 
plug pinching the rung tightly to the side rails and internal backup 
plates. (Figure 2 A)


3.1.2  Aluminum Truss Construction- In the aluminum truss design, 
the top and bottom rails are connected to rung assemblies or rung 
blocks by rivets. The rungs are either welded or expansion plugged 
to the rung plate assemblies, which are supported by the top and 
bottom rails. (Figure 2B)
	

3.2 The base of the portable aluminum ladder is provided with either 
steel spikes or swiveling rubber safety shoes and aluminum spikes. 
For ladders equipped with the swiveling device, the rubber pads should 
be utilized when the ladder is to be raised and used on hard surfaces. 
(Figure 2A, 2B)
 3. CONSTRUCTION OF PORTABLE ALUMINUM LADDERS

It was rejected as a base type because it was deemed unnecessary, 
but could be added as a UDT.

{CC:
This is the presenting complaint.


HPI:
Developed over a few days

CURRENT MEDICATIONS:
METHOTREXATE SODIUM EQ 2.5MG BASE once weekly
METHOTREXATE SODIUM EQ 2.5MG BASE once weekly
Plaquenil 200 mg two daily
Prednisone 5 mg od
Salazopyrin EN 500 mg  two bd with food
Ultram Oral Tablet 50 MG qid prn
}

Pekr if you saw viva-rebol code you could see parse will be usefull 
for the function click and go  part

instead of the weak actual solution base  on  either any [ find ...] 
]

as area-tc is base on parse to draw on screen having a better understanding 
of parse would lead to the creation of a all purpose ritch text rendering 
widget using an adapated dialect

What about parsing another similar language?

http://www.rebol.org/view-script.r?script=qml-base.r

the reason for the // is to allow relative paths like: //www.rebol.com/ 
  where the scheme is the same as the base url. Nobody has ever used 
this; also, it could have been achieved by using :www.rebol.com/ 
instead... so, yeah, it was not really a good idea. I also don't 
think ftp:file.txt (meaning, change scheme, but keep host and path) 
has ever been used and not sure it's supported by software. so in 
practice http:www.rebol.com/ would have worked.

CTX-REBGUI/COLORS is an object of value:
	window          tuple!    236.233.216
	widget          tuple!    244.243.238
	edge            tuple!    127.157.185
	edit            tuple!    255.255.255
	over            tuple!    255.205.40
	menu            tuple!    49.106.197
	btn-up          tuple!    200.214.251
	btn-down        tuple!    216.232.255
	btn-text        tuple!    77.97.133

CTX-REBGUI/EDIT is an object of value:
	...
	tabbed          block!    length: 5
	hilight-on-focus block!   length: 2
	caret-on-focus  block!    length: 4
	action-on-enter block!    length: 3
	...

ctx-rebgui/widgets/set-sizes unit-size font-size


Plus many widgets have various option flags to control some aspect 
of their behavior.


Probably not skinning in the true sense but enough to change basic 
scale, colors and behaviors to cover the major use cases as they 
have been presented to me thus far. Skinning that lets you change 
"look & feel" to the extent that the GUI can mimic native Windows, 
OSX, C64, etc could be done but at what price in complexity and delivery 
time? And what percentage of folks would just stick with the default 
look & feel anyway. Another way of saying this is to ask whether 
it is a good idea to put 80% of your effort into satisfying the needs 
of 5% of your user-base?

Just cross-posting Geomol's styles: http://home.tiscali.dk/john.niclasen/canvas/newstyles.r
Might be a nice base for RebGUI.

http://shadwolf.free.fr/RebGUI-038-shad.zip

REBGUI 0.38 Shadwolf version !!!


- FULL  retail files no need to merge them back  with previous REBUI 
version
- Didec-requestdir mini app 
- Listview as base object  
- Demo-listview.r shows how to use the listview widget.

now  i will rework on rkini my irc client and base it on RebGUI

live from the net distro have been yet intented in projects like 
libskins written  Etienne Alaurent  the base concept was to  call 
the  distro url website install.r files if the  distro wasn't yet 
present on the harddrive .... this produce a probleme with  1.2.8+ 
rebol/view version as a public directory was created localy to the 
running script directory so u get as many distro of libskins installed 
 in ur harddrive that  u get scripts using lib skins....

Decided to go with a simple manifest / checksum approach. Long term 
we really need something like Anton outlined previously (multi-level 
caching with the option to control it on an app by app basis). Anyway, 
have a try of this:

	do http://www.dobeash.com/files/rebgui/get-rebgui.r


but be aware that it writes its files to the *current* directory 
(as determined by 'what-dir) and replaces any "base" files with a 
differing checksum (so make a copy of any local changes you have 
made and want to keep).


I've also updated the issues log at: http://www.dobeash.com/it/rebgui/issues.html

A mix could be a self-extracting script for base-distro, and then 
downloading the updates. only a single server-lookup and only a few 
bytes more.

Jerry, Alain Goye created a outliner he called NoteReb http://alain.goye.free.fr/rebol/NoteReb.r
that may give you a base to learn from .. if you need to.

Robert: "Is there a way to re-use widgets like done with 'style in 
VID? For example: I have a drop-list specification, I need at several 
places but I don't want to copy the code."

Short answer, no.


If you have a "style" that is sufficiently different from the base 
widget (that is used often) then consider:

1) modify the widget's defaults in %rebgui-widgets.r, or
2) modify them inline, as in:

	ctx-rebgui/widgets/<widget>/<facet>: <value>

3) derive a new widget that works exactly the way you want.

ESC can be fixed by changing the last few lines of 'process-keystroke 
(in %rebgui-edit.r) to read as follows:

;			#"^[" [
;				;	ESC
;				hide-popup
;			]
		][
			either all [
				event/key = #"^["
				find view*/pop-list view*/pop-face
			][
				hide-popup
			][
				;	if key is assigned to an action do it
				if any [
					not view*/focal-face
					find [button] view*/focal-face/type
				][
					if f: select face/keycodes event/key [f/action f exit]
				]
			]
		]


Only the last of multiple keystrokes provided is used; but note that 
SPC is already mapped to button (so specifying #"^M" would give it 
two mappings ... a keystroke mapping and it's base "SPC activated 
on focus" default).

Yes, on a per widget base. I'm talking about a complete data-form 
with several widgets.

Had a look at porting Henrik's list-view over to RebGUI. Main challenge 
would be to convert / merge 4 styles (list-icon, list-field, list-text 
and list-view) into a single rebface. This would require quite a 
bit of code restructing. The actual internals don't need too much 
work (functions and feel code are pretty VID/RebGUI neutral), but 
a lot of references to RebGUI 'standards' need to be added; such 
as:

	default-* objects instead of system objects
	ctx-rebgui/sizes
	ctx-rebgui/colors


And the span facet needs to be added (and support logic added) to 
enable dynamic resize / rescale. Given the amount of code that needs 
to be changed, I don't believe a VID and RebGUI version can be [easily] 
built from the same code-base (i.e. the port will in effect create 
a fork).


Also, from a code complexity POV, the list-view widget is almost 
as large as *all other widgets combined* ... and it includes functionality 
that could probably otherwise go into a grid / spreadsheet type widget 
(list-view is almost a GUI framework in its own right now! ;)). If 
anyone's in doubt, I think Henrik's work rocks and fills a much needed 
gap in VID functionality. ;)

Having converted (or at least used as a starting base) a number of 
VID styles to RebGUI widgets I've observed that the final code is 
40%-60% smaller (YMMV) and easier to understand in that most of the 
logic resides in the widget itself (i.e. it is self-contained). But, 
once the code to be converted reaches a certain size where I can 
no longer 'grok' it in a single reading (about a hundred lines for 
me) I find it easier to code from scratch. ;)


I'd also break it into two separate widgets: grid and list-view, 
and look at the minimum function set each requires (KISS).


Simplest way to start is to read all the doco under 'RebGUI Documentation' 
at http://www.dobeash.com/RebGUI/then look at the source code of 
a few widgets (start with something simple like %button.r then move 
onto %table.r which shares a lot in common with list-view).


If you run into any brick walls (or find yourself asking, "why oh 
why did they do it that way?") just drop a note here. ;)

Graham, "is there going to be a formal syntax description for the 
rebgui dialect" ... I can certainly get the ball rolling, can you 
point me to a good format we can base it on?

Even if you change the base rules, they give greate exampes of formats.

not sure there is separate tree-view, but I would like to vote for 
one. tree-list might be good code base for introduction of separate 
tree-view?

Some crude benchmarks with %tour.r

	tooltips: true		60-70% CPU
	tooltips: false		3%


Heavy optimization cuts the first one by 5% and the second by 1%, 
but the base cause of the problem is this line in rebgui-display.r:

	find-face event/offset event/face ctx-rebgui/tooltip-sensitive


which is needed to get around the View detect bug described here: 
http://www.rebol.com/docs/view-system.html#section-5.7

It would be an excellent base upon which to rewrite Altme with file 
sharing.

- Pekr : Carl hasprepared his presentation the night before he given 
it (so he was not in great form this particular day ;-)


- About Internet connection : the scholl connection where we were 
is provided by an Italian telephon companie that ensure the security. 
Mario have tried more than a week before to have some opening on 
it. Lot of faxes, telephon calls and time lost. We were all disapointed 
of that, in or outside the Devcon.


- Rebcode : it will be part of Rebol soon. You can even try it if 
you want (windows builds folder, the zip file). But it still in design 
stage. The form, the capabilities and implementation are sugest to 
changes. Carl has insisted on the fact that rebcode will be a bit 
tricky to use. Kind of assembler code. Not for newbies.


- Rich text : Cyphre show us its work. Actually it's a .dll, like 
he did with AGG in the begining. It's not just a renderer : it's 
editable rich text. Dialect base like Carl's blog proposed. Nothing 
more to say, it's just a prototype, a proof of concept, like AGG 
was at its time. It use AGG as engine, so font can be aliased or 
not.

Yeah, the change line should read:

change third d debase/base h 16

I said, it wasn't easy. ;-P

isn't rebpro just /base package? I mean - without the mezzanines?

From the FAQ:

Is Wolfram|Alpha a search engine?

No. It's a computational knowledge engine: it generates output by 
doing computations from its own internal knowledge base, instead 
of searching the web and returning links.

Does Wolfram|Alpha get its data from the web?

No. It comes from Wolfram|Alpha's internal knowledge base. Some of 
the data in that knowledge base is derived from official public or 
private websites, but most of it is from more systematic primary 
sources.

Where does Wolfram|Alpha's data come from?

Many different sources, combined and curated by the Wolfram|Alpha 
team. At the bottom of each relevant results page there's a "Source 
information" button, which provides background sources and references.

Of course we can't prevent ppl from anything. Boron might be good 
test-base for the interpreter itself ...

I still think, that the best base, albeit commercial, is QNX - lot's 
of target embedded platforms covered ... REBOL could co-work-with, 
or replace Photon GUI ... I want View app in my car, then calling 
Cyphre and lamenting about some bug :-)

Steeve, yeah, but the situation in the USA is also because of a fragile 
economic base.

It is not the way to achieve a broad user base

Graham - why not? Have you ever worked with embedded SW? Those kits 
might cost much more. But - if you think it is not viable to extend 
an user base, then you are right. Carl would be better off with fully 
opensourcing R3, while still keeping his hand upon the direction 
of development, and benefiting from getting more new ppl onboard, 
some contractual work for special modules, etc.

which is a oneliner actually:

write clipboard:// probe copy/part enbase/base checksum/method/key 
"twitter" 'SHA1 ask/hide "password: " 64 8

it bugs me that they forked Android (based on a version prior to 
2.2) - that's a second strike. The first was that they bought Touchco, 
a very promising tech company which had one of the best and cheapest 
touchscreen implementations ($10/sq ft), good for both stylus and 
fingers. This should have been technology for the masses, not restricted 
to Amazon. Oh well, I guess it's still for the masses if they sell 
enough tablets with that tech, at some point. Forking Android though, 
screw them. With their user base, they have the potential to upset 
the Android cart.

I decided not to use anything of VID for elixir and instead base 
the whole architecture on liquids.

Gabriele - sorry, but it seems to me, that your pov is misleading, 
because you try to base it on incorrect presumption. There were some 
rules set. The rules were - Carl decides, I coordinate, write down. 
Sorry, but if someone disappears for 2 - 3 months, then morale of 
group can't be kept high. I am not blaming Carl for anything here, 
that was not my point, but I have to point to the reason of failure 
...

the most difficult part will to attract new developers, being able 
to extend native (C level) code base ...

So, what I prefer for initial release is - introduce us to particular 
subystems, give us doc with description of how you aproach UI creation. 
Styles can be added later. But I want to have flexible base first, 
which will count on all things needed to support big GUIs.

I'm a little concerned about the direction to take Desktop Library 
II.  I want to make Sunanda and the team happy, but I don't really 
want a product with a pre-expired shelf life.  It's getting close 
to 3/4s complete, but have a feeling it may be an R2 only code base. 
 :(

So I'm still back to planning for say an Invoicing application for 
a site boss.  That will be R2 code base for quite some time, no?

I'm not debating or discussing the points you are making, I'm simply 
tired of offering some info, and then having snide comments made 
about words like "close" "soon" etc.  You guys keep waving the "democratic" 
flag…there is no democracy here…I don't have to be pummeled for offering 
information…you are way off base…

I am far from being off base, because I know what I am talking about, 
and I also understand your point. The examle with "democracy" was 
just that - example. It is quite some time when I saw some ironic 
or sarcastic comments here.

I think Pekr is just as curious as the rest of us and enjoys news...any 
news of Rebol3's present stage of deveoplment. I do not think he 
is off base asking for a monthly blog. Reichart, I read these many 
of these posts everyday and I rarely ever see "snide" remarks so 
I'm confused why your brasing yourself. Although, reiderating what 
we already know about the teams hardwork and that it should be "soon" 
does not add to the conversation or help Pekr's and the rest of our 
curiousities.  I normaly would not respond but Reichart's commnets 
struck a nerve with me: "I'm tired of offierng some info, and then 
having snide comments made..." If your comments are as useful as 
the one you made to start this tread, please just refrain.  Let''s 
move on...

My opinion is, that it is not me, who was off base, but it was Reichart's 
comment, which was simply inappropriate imo. But I talked to Reichart 
later privately, and he talked normally to me. It was also me, who 
reacted with explanation of my points. Well, while I used "Could 
someone please ask Carl", I used bold style, which could sound like 
I ordered RT to post a blog. I decided to use bold letters because 
sometimes the discussion here scrolls so fast, that I want it to 
be noticed by folks like Gabriele, who might connect later. btw - 
I still can see Reichart with his name here ....

and I don't like percents. I don't want to open that discussion here, 
because I already seen some discussion on it, and while it might 
seem trivial, it is not :-) But generally I refuse result which is 
different from what I got from calculator. So basically how following 
could be valid escapes my basic school knowledge:

12.3 * 110% = 13.4


Of course I would expect 12.3 + (10% from the base (12.3)) = 13.53, 
which is returned also by my Windows calculator. Even if I think 
about 110% as of 1.1, still 12.3 * 1.1 = 13.53.

IMO there is a bug in the doc :-)

Pekr, just calm down, how can someone write full docs, when VID3 
is not yet finished? Can't you wait a bit more? Where's the problem? 
Don't base your assumptions on some unfinished docs, I know you're 
eager to get R3, but, please, wait until it's done.

My take on graphical tables;  R2 had a beautiful base for this with 
list and supply.  Downside was that the documentation was so limited 
and late comming that no one could comes to grips and we all mostly 
ignored it.  We lost out on the ability to build on the shoulders 
of giants as using list and supply pretty much meant learning by 
expermentation, coding from first principles and not from tool kits 
and cookbooks.  Hopefully the power gems of R3 and VID3 will not 
suffer the same fate.

And R3/Core 3.1 - add rebcode as a base. Ppl already found its uses. 
IMO it was already usefull and it is a pity it was later excluded 
from the Core ...

Innovative stuff. Not something we can do with Syllable's C/C++ code 
base :-(

I'd like to try at least an equivalent of /Base to see at least how 
the core of the language has changed.  This is where I think all 
the transition pains/revelations for developers are going to be.

putting barriers to use in an already very small developer base is 
counter productive

I hope I'm not infringing on a copyright but this quote from the 
commentary of the Halloween I document 

http://catb.org/~esr/halloween/halloween1.htmlexplains that phenomenon 
quite nicely.

<q>

The difference here is, in every release cycle Microsoft always listens 
to its most ignorant customers. This is the key to dumbing down each 
release cycle of software for further assaulting the non-PC population. 
Linux and OS/2 developers, OTOH, tend to listen to their smartest 
customers. This necessarily limits the initial appeal of the operating 
system, while enhancing its long-term benefits. Perhaps only a monopolist 
like Microsoft could get away with selling worse products each generation 
-- products focused so narrowly on the least-technical member of 
the consumer base that they necessarily sacrifice technical excellence. 
Linux and OS/2 tend to appeal to the customer who knows greatness 
when he or she sees it.The good that Microsoft does in bringing computers 
to the non-users is outdone by the curse they bring upon the experienced 
users, because their monopoly position tends to force everyone toward 
the lowest-common-denominator, not just the new users.
</q>

james_nak: LIST-VIEW is in fact not used in dev-base. I wish it were, 
though. :-)

VID3 as a base, is based upon stronger foundation than VID2, that 
is clear even now ... but it needs to be more complete. I think that 
such things as release schedule should be well planned.