Update: Read *and* Write images against Windows Clipboard
[1/19] from: greggirwin::mindspring::com at: 21-Sep-2002 12:07
Here's an upated version of win-clip that let's you read *and* write images.
The implementation is very basic, using an old, obsolete, API call
(GetBitmapBits) as an initial test. The more "modern" approach (i.e.
GetDIBIts) will be quite a bit more work. If you need a more flexible,
powerful, up-to-date function (e.g. for palette mapping, bitmap conversions,
direct JPG support, etc.), that would be the way to go. In any case, I'd
love to hear if this works for people, or if you have any problems on
specific versions fo Windows or REBOL.
Same disclaimer(s) as before:
Requires View/Pro or Command (for library access).
Doesn't work on View 1.2.1. Looks like you can't use an image! as a routine
parameter under that version.
In light of the recent thread on the pros and cons of cross-platform support
in scripts, let me say that this particular bit of functionality, along with
some other Windows-specific stuff, is required for a project I'm working on.
The target platform is Windows and integration with some other software is
required. In this kind of scenario, I could do one of three things:
a) Try to talk them out of Windows as a target. In this case,
I think they're making the right choice. Supporting other
platforms doesn't make any business sense at this point.
b) Use another tool for the project. That would mean going to
a Windows specific tool in my case because that's where my
background is and how I would be most effective.
c) Use REBOL, promote it, and design things to make going
cross-platform possible in the future.
I chose option C.
--Gregg
P.S. Watch for wrap!
REBOL [
Title: "Windows Clipboard Library"
File: %win-clip.r
Date: 21-Sep-2002
Author: "Gregg Irwin"
eMail: [greggirwin--acm--org]
]
win-clip: context [
win-user: load/library %user32.dll
win-gdi: load/library %gdi32.dll
null-buff: func [
{Returns a null-filled string buffer of the specified length.}
len [integer!]
][
head insert/dup make string! len #"^@" len
]
BITMAP: make struct! [
Type [integer!]
Width [integer!]
Height [integer!]
WidthBytes [integer!]
Planes-BPP [integer!]
;Planes [integer!] ; WORD needs to be 2 bytes
;BitsPixel [integer!] ; WORD needs to be 2 bytes
Bits [char*] ; LPVOID
] none
; This is an obsolete function, but it may work for us.
get-bitmap-bits: make routine! [
hbmp [integer!]
cbBuffer [integer!] ;// number of bytes to copy
lpvBits [image!] ;// pointer to buffer to receive bits
return: [integer!]
] win-gdi "GetBitmapBits"
create-bitmap: make routine! [
width [integer!]
height [integer!]
planes [integer!]
bits-per-pel [integer!]
lpv-bits [image!]
return: [integer!] ; HBMP on success, 0 on failure
] win-gdi "CreateBitmap"
get-bitmap-object: make routine! [
hgdiobj [integer!] ;// handle to graphics object of interest
cbBuffer [integer!] ;// size of buffer for object information
lpvObject [struct! [(first BITMAP)]] ;// pointer to buffer for
object information
return: [integer!]
] win-gdi "GetObjectA"
; 0 on failure
CF_TEXT: 1
CF_BITMAP: 2
_open: make routine! [
hwnd-owner [integer!]
return: [integer!]
] win-user "OpenClipboard"
; Returns 0 on failure
open: does [
either 0 <> _open 0 [true][false]
]
close: make routine! [
return: [integer!]
] win-user "CloseClipboard"
; Returns 0 on failure
clear: make routine! [
return: [integer!]
] win-user "EmptyClipboard"
; Returns 0 on failure
get-data: make routine! [
format [integer!]
return: [integer!]
] win-user "GetClipboardData"
; Returns 0 on failure; hData on success
; After SetClipboardData is called, the system owns the object
; identified by the hMem parameter. The application can read
; the data, but must not free the handle or leave it locked.
set-data: make routine! [
format [integer!]
hMem [integer!]
return: [integer!]
] win-user "SetClipboardData"
is-clipboard-format-available?: make routine! [
format [integer!]
return: [integer!]
] win-user "IsClipboardFormatAvailable"
; Returns 0 if format is not available
is-format-available?: func [format [integer!]] [
either 0 = is-clipboard-format-available? format [false][true]
]
; It looks like we either need to clear the clipboard, or write
; some text to it via the clipboard scheme, in order for image stuff
; to work. What happens is that the DIB rendering format doesn't
; update if we don't do that and that is what gets pasted into most,
; if not all, apps (even though the BITMAP format is in the clipboard
; with our data.
write: func [data] [
either not image? data [
system/words/write clipboard:// form data
][
if open [
clear
set-data CF_BITMAP create-bitmap data/size/x data/size/y 1
32 data
close
]
]
]
read: func [
{Returns a string! for CF_TEXT values and an image! for CF_BITMAP
values. Right now, the old GetBitmapBits API, which is tagged as
obsolete, is used to get the image data. It was easy to implement
and test, whereas the more up-to-date approach would be to use
GetDIBits, but that entails a lot more work.}
format [integer!] {Only CF_TEXT and CF_BITMAP do anything reasonably
useful at this time. Other formats will return the handle of a
clipboard object in the specified format.}
/local result hbmp bmo
][
either format = CF_TEXT [
system/words/read clipboard://
][
result: none
if all [open is-format-available? format] [
result: get-data format
if format = CF_BITMAP [
hbmp: result
bmo: make struct! BITMAP none ; bmo = BitMap Object
either 0 <> get-bitmap-object hbmp length? third bmo bmo
[
result: make image! to pair! reduce [bmo/width
bmo/height]
get-bitmap-bits hbmp length? result result
][
result: none
]
]
close
]
result
]
]
]
;win-clip/write "abc"
;win-clip/write to image! layout [button]
;wait .1 ; need to wait here for some reason, or sometimes it doesn't
; see the data we just wrote.
if win-clip/is-format-available? win-clip/CF_BITMAP [
if img: win-clip/read win-clip/CF_BITMAP [
view layout [image img]
]
]
;halt
[2/19] from: greggirwin:mindspring at: 21-Sep-2002 12:34
Already found a little issue. The BITMAP clipboard format looks great, but
the DIB format (also available if you write the CF_BITMAP format) has the
last few pixels of each scan line wrapped to the left. This is bad since the
DIB is what seems to get pasted by some apps.
No solution at this time, just be aware. (and maybe let me know what apps
get a bad image :)
--Gregg
[3/19] from: brett:codeconscious at: 22-Sep-2002 11:02
> Here's an upated version of win-clip that let's you read *and* write
images.
Thanks for sharing it Gregg!
Never know when it will come in handy :^)
Regards,
Brett.
[4/19] from: gscottjones:mchsi at: 21-Sep-2002 22:34
From: "Gregg Irwin"
> Here's an upated version of win-clip that let's you
> read *and* write images. The implementation is
<<quoted lines omitted: 7>>
> works for people, or if you have any problems on
> specific versions fo Windows or REBOL.
Hi, Gregg,
I've been sitting on the sideline on this one (I haven't taken the /Pro
plunge), but like Brett, I certainly wanted to thank you for boldly going
where no one (seems) to have gone before. Some questions come to mind, and
they are not necessarily focussed at you, per se. But your posting gives a
springboard for asking.
When I peruse the raw rebol executable, I actually can find that many of
these routines are called from within REBOL (not GetDIBIts though). We (the
list
people) have previously been under the impression that clipboard://
can only read and write text from/to the clipboard. So the mystery for me
is, why are these function calls there? I began to wonder how it is we knew
about the clipboard:// scheme to begin with. As far as I can tell, it
started in the /View beta days, and is currently only "documented" on the
rebolforces website, and, of course, it comes up on the list on occasion.
It was one year ago tomorrow when you asked whether maybe it just required
some trick of encoding (or whatever), but apparently no response came. It
was only in March of this year when Holger indirectly implied that binary
clipboard operations were platform specific, and so was not yet supported,
but might be one day.
So, I'm curious if there are other reasons why these function calls would be
in the executable. Anyone have any ideas?
...
> In light of the recent thread on the pros and cons
> of cross-platform support in scripts, let me say
<<quoted lines omitted: 16>>
> future.
> I chose option C.
And a noble choice it is! Viva la Rebolution!
A thought that frequently comes to mind when these threads come up is a
variation on option B. Leverage the rapid development of REBOL with the
broader support available in another cross-platform environment. I've
played with this idea by setting up an echo server that lets me easily
tinker with REBOL interacting with the server. My rough, proof-of-concept
projects have been as simple as getting access to the command line to using
libraries to manipulate images. The proof of concept showed me that it
could work (despite the rough and ready coding), but it means running
another independent process (kind of like running a MySQL server, etc).
I've been rather surprised that we have not seen more of this being done. I
know that I personally like things to be really clean when ever possible,
but as I've said too many times to count, I just salivate at the thought of
all the great supporting extensions that have been developed elsewhere going
unused in REBOL.
By the way, what little I can see, it seems as though other broadly
cross-platform solutions avoid using binary through the clipboard. REBOL
does not stand alone on this issue.
Thanks, again, for your contributions.
--Scott Jones
[5/19] from: jason:cunliffe:verizon at: 21-Sep-2002 23:21
Thanks Gregg!
I really need this... Not working yet for me. Any ideas why?
./Jason
>> do %win-clip.r
** Script Error: Invalid argument: image!
** Where: context
** Near: get-bitmap-bits: make routine! [
hbmp [integer!]
cbBuffer [integer!]
lpvBits [image!]
return: [integer!]
] win-gdi
Win98se 500MHz 256Mb
REBOL/Command/View 2.0.0.3.1 25-May-2001
Internet Protocols 1.59.0 1-May-2001/19:18:45
Network Auto-Configure 1.6.0 12-Apr-2001/22:03:40
Windows Installer 1.50.0 29-Apr-2001/16:00:17
ODBC Access 1.2.0 30-Mar-2001/23:54:47
Dynamic Library Access 1.4.0 11-Apr-2001/19:40:04
Oracle Access 1.2.0 30-Mar-2001/23:54:47
MySQL Access 1.1.0 11-May-2001/23:54:23
Command Shell Access 1.5.0 30-Mar-2001/23:54:48
Graphics 1.1.0 15-May-2001/15:57:24
View and VID 1.155.0 15-May-2001/15:47:04
View Desktop 1.26.0 25-May-2001/19:44:34
Sound 1.2.0 10-May-2001/15:59:26
Preferences 1.51.0 14-Apr-2001/22:15:04
Encryption 1.3.0 2-Apr-2001/22:19:11
Big Numbers 1.2.0 2-Apr-2001/22:19:11
DH/DSA Encryption 1.2.0 2-Apr-2001/22:19:12
RSA Encryption 1.3.0 13-Apr-2001/0:12:42
FastCGI 1.2.0 7-May-2001/23:32:31
Secure Socket Layer 1.3.0 24-Apr-2001/17:12:59
Licensing 1.8.0 15-May-2001/21:03:19
[6/19] from: anton:lexicon at: 22-Sep-2002 16:50
Yes, Gregg mentioned that it doesn't work in
rebol 1.2.1 because it doesn't support the
image! datatype in a routine! definition.
I suppose that version of Command you have
corresponds with 1.2.1 ?
Is there perhaps a newer beta of Command
to try ?
Anton.
[7/19] from: anton:lexicon at: 22-Sep-2002 16:31
Very cool Gregg, I successfully copy and paste
image into photoshop on windows2000 for both:
REBOL/View 1.2.8.3.1 3-Aug-2002 (latest beta)
REBOL/View 1.2.5.3.1 6-May-2002
Anton.
[8/19] from: greggirwin:mindspring at: 22-Sep-2002 10:55
Hi Jason,
Anton beat me to the punch. I'm guessing your command aligns with the old
View that didn't support image! types in a routine call. I tinkered with a
few different things, e.g. using char*, string!, or binary! as the data type
and converting, but nothing worked straighy-away like image! so I just went
with that.
--Gregg
[9/19] from: greggirwin:mindspring at: 22-Sep-2002 10:56
<< I successfully copy and paste image into photoshop on windows2000 for
both: >>
Thanks Anton! Glad to know it works somewhere else.
--Gregg
[10/19] from: greggirwin:mindspring at: 22-Sep-2002 11:55
Hi Scott,
<< When I peruse the raw rebol executable, I actually can find that many of
these routines are called from within REBOL (not GetDIBIts though). We (the
list
people) have previously been under the impression that clipboard://
can only read and write text from/to the clipboard. So the mystery for me
is, why are these function calls there? >>
There are a number of related APIs that would be used for many other
purposes beyond clipboard support. It's hard to write a Windows app without
using a certain number of API calls just to accomplish basic tasks. The
clipboard specific calls would be used for text support that the
clipboard:// scheme allows today.
<< I began to wonder how it is we knew
about the clipboard:// scheme to begin with. As far as I can tell, it
started in the /View beta days, and is currently only "documented" on the
rebolforces website, and, of course, it comes up on the list on occasion. >>
A few places mention it. I think Brett does on CodeConscious, and the
Clipboard reblet in IOS is a prominent example. I don't know if it's in any
offical docs though, so I'm not sure how it came to light either.
<< By the way, what little I can see, it seems as though other broadly
cross-platform solutions avoid using binary through the clipboard. REBOL
does not stand alone on this issue. >>
And I can see why! The approach I've taken for this first whack is very
simplistic and, as I already posted, may not work correctly if an app pastes
from the DIB format in the clipboard rather than the BITMAP format. The API
I'm calling is easy to use - but obsolete (not even sure if XP supports it),
and the simple approach of using CreateBitmap and limiting things to single
plane bitmaps using 32 bits per pixel is probably not acceptable as a robust
solution for a product. If I were to expand this to be up to date, with
broad support for any type of image that might be used, the code base could
easily be 50 times as large. There are at least three versions of the
BITMAPINFOHEADER structure now, with varying support for things like
compressed images (e.g. JPG), depending on which version of Windows you're
on, and some APIs even work differently depending on *how* a bitmap was
created! AAAaaahhh!! :)
Ultimately, I much prefer the idea of something like the ARexx ports Jason
mentioned. A portable way to programmatically talk between apps. Writing
lots of little apps makes much more sense when you can link them up via a
simple IPC mechanism to perform big tasks. Brett (I think) started playing
around with something on this a while back (play-apps), but I don't remember
how far he got.
Integrating apps on Windows is not always easy. In the old days DDE was
king, then OLE, then COM, and always you could pump messages, send
keystrokes, and use the clipboard. There has never been a single, simple,
long-term solution to the problem though. I'm using the latter three because
they are kind of a "lowest common denominator". Pumping messages is easy
enough, provided you can find out what the messages are that you need to
send. Sending keystrokes is a bit more involved, but my send-keys dialect
seems to be working pretty well (anybody care to test it? :). Now the basic
clipboard stuff is there, so I can automate things pretty well in order to
integrate them with the REBOL pieces. It may be low tech, but it works.
Sorry for rambling! I hope I answered your question in there somewhere. :)
--Gregg
[11/19] from: gscottjones:mchsi at: 22-Sep-2002 14:28
Hi, Gregg,
From: "Gregg Irwin"
...
> If I were to expand this to be up to date, with broad support
> for any type of image that might be used, the code base could
> easily be 50 times as large. ...
There is no rush as long as it is finished by next weekend!
;-)
...
> I hope I answered your question in there somewhere. :)
Yup! Thanks. Of course, answers beget more questions, but you need to be
focusing on your project rather than educating me on things that have
evidently been discussed on the list on more than one occasion. Thanks
again for the answers. I'll do some poking around in my spare time.
--Scott Jones
[12/19] from: greggirwin:mindspring at: 22-Sep-2002 14:55
Hi Scott,
<< Of course, answers beget more questions...>>
Ask away. Sometimes the best way for me to learn things to is answer
questions. Not that I'll necessarily be *able* to answer your questions
but... :)
--Gregg
[13/19] from: gscottjones:mchsi at: 22-Sep-2002 19:13
From: "G. Scott Jones
> << Of course, answers beget more questions...>>
From: "Gregg Irwin"
> Ask away. Sometimes the best way for me to learn things
> to is answer questions. Not that I'll necessarily be *able*
> to answer your questions but... :)
Hi, Gregg,
You are a brave person, but you should feel no particular obligation to
answer, of course.
I've already partially answered some:
1) IPC ???
When I plugged this into google, I ended up at the organization IPC started
in 1957 as the Institute for Printed Circuits, that became Institute of
Interconnecting and Packaging Electronic Circuits, and then became IPC in
1999 but without acronymic meaning this time. (Funny how circular life can
be sometimes :-). Sensing an understandable wrong turn by google, I checked
around some more, and surprisingly was turning up nothing that seemed
communication related. Using my fine, intuitive mind, I "made up" an
anticipated acronym of "inter process communication", and was then only off
by a small hyphen. Not bad. However, I saw lots of talk about "it" but no
substance. Deciding that this is no dot.not marketing thing, I decided I
would search more throroughly later. If you already know of a link to a
single, concise over-view, that would be of help, but please don't waste
your time looking for it! :-)
2) ARexx
Figuring that this was probably not the uncle of T Rex, I was more quickly
successful with google and discovered that it is an Amiga Thang, almost as
if it were a contraction of "Amiga" and "Rexx" or something. With the
wonderful, glowing terms in which I saw it described, I really came to
regret not having more money in 1984 and buying that dang Amiga whose specs
I drooled over. But having another year of medical school left before I
would start earning my $3 an hour that would earn as a resident in training,
my finances said otherwise. My TI994A would have to last another two years,
through a rejected Apple loan saying I was a student (no kidding?), up to
the incredible excitement generated by Windows 1.0 !!!! Generous in-laws
finally floated a loan to buy my first non-toy PC. But ... I seem to have
digressed. (Wow, that Windows 1.0 was something else, literally ...
sucka!).
OK, so reading quickly between the lines, it sounds like the Amiga was
blessed with an advanced scripting language that could listen on a port and
be passed stuff. Cool ... really makes me appreciate learning the finer
points of line numbering methods in gwbasic. But again I digress. Looking
at the list, I saw numerous references to Arexx (I'm beginning to suspect
that there may, ... just may be some link between Amiga and REBOL and loyal
fans. <humor alert> Hmmm, another day's research. </humor alert>).
3) When I was pondering my alternative, cross-platform server with which I
could set up my own inter-process communication with REBOL, I began to
entertain what would the best language and/or scheme look like. Petr had
once said he envisioned printer support as looking like a scheme, but I was
unable to get a vision of what this would look like. I was seeing, for my
own home-grown IPC, something more like a query language dialect, like SQL
(not SQL, just similar ;-). I could see that a photographic support
back-end might also use a query language. What I quickly began to
appreciate is that I could easily be starting on a process of reinventing
the wheel (hmm, let me see, PI = 3.1.....). That was just about the time
that other matters became very pressing in my life, so "everything" was
shelved (including the font stuff you generously sent me).
I guess if there is a question in here, it would be what do those who are
formally trained in this area see, in an overview sort of way, as the way
REBOL might communicate with this resource-rich server. Maybe this *is*
what the IPC thing is all about, which I will eventually discover once I do
more research. If this answer is immediately obvious to you or a list
member, it would be wonderful to learn more. It would also be great to not
reinvent the wheel and use a method that is generic enough to grow.
4) Finally, and this is more of a question to myself, I wonder whether it
wouldn't be better to take the approach you are taking, and bravely go
through the Windows interface and avoid additional "kruft" (I like clean,
simple things, including installations).
There are other questions (there always are, but hey, maybe I should be more
bandwidth conscious), but I'm ready to go make some dinner. (Yes, that was
my stomach that was growling just a few minutes ago.)
:-)
--Scott Jones
[14/19] from: greggirwin:mindspring at: 23-Sep-2002 12:27
Hi Scott,
<< 1) IPC ??? ... Using my fine, intuitive mind, I "made up" an
anticipated acronym of "inter process communication", and was then only off
by a small hyphen. >>
Yes, you're right on. And no, it's not a .NET thing. There are many forms of
IPC, some of which I mentioned. Shared memory, pipes, sockets, and command
line arguments are other common mechanisms. IPC, to this layman, is anything
that lets two processes communicate. Sockets are used more often now, it
seems, and they are a good mechanism because they can extend from local use
to intra- and internet use without drastic architectural changes.
Since REBOL is all about communication, I think we'll see new IPC models and
mechanisms built that will be really fabulous.
I don't have any great links handy. Sorry.
<< 2) ARexx
Figuring that this was probably not the uncle of T Rex...>>
Model A versus Model T? :)
<< OK, so reading quickly between the lines, it sounds like the Amiga was
blessed with an advanced scripting language that could listen on a port and
be passed stuff. >>
Yes. Big time. I'm not an Amigan either, and also had a TI994A, by odd
coincidence. Hopefully, if I ever get something going along these lines, RT
and the Amigans out there will chime in to contribute suggestions based on
their experience.
<< I guess if there is a question in here, it would be what do those who are
formally trained in this area see, in an overview sort of way, as the way
REBOL might communicate with this resource-rich server. Maybe this *is*
what the IPC thing is all about, which I will eventually discover once I do
more research. If this answer is immediately obvious to you or a list
member, it would be wonderful to learn more. It would also be great to not
reinvent the wheel and use a method that is generic enough to grow. >>
There are so many ways it could go. One big architectural choice is whether
it's completely peer to peer, or if you have some kind of IPC server process
that helps manage and negotiate things, maybe providing lookup services and
such. There's definitely a holy grail hiding in there somewhere. :)
In some cases, a specific dialect would be the way to go. If, for example,
you have an IDE, plug-in tools could integrate very tightly, and cleanly,
with something tailored to that need. OTOH, it could probably be built on a
very generic system that would be widely applicable. To me, this is a case
where the basic pieces of the infrastructure could (maybe should) be built
in at a lower level and the higher level IPC stuff is basically a bunch of
dialects tuned for specific needs and industries. I see the power of
dialects as something that should be leveraged on both the human and
computer side of things. Imagine the power of the phrase "Any messages?" and
how that single messaged could be processed and passed around by both humans
and processes.
I think we'll see lots of little things appear and, eventually, some kind of
standard will appear. I don't kow that RT can just put something out there
right now though. There are so many ways it could go, we almost have to try
lots of different approaches to see what works well in different contexts.
The first things we see will very likely be modeled on concepts that exist
today, but the really good stuff we haven't even thought of yet.
<< (including the font stuff you generously sent me). >>
Carl Read is taking it to the next level with his font-requester stuff. Very
cool!
<< 4) Finally, and this is more of a question to myself, I wonder whether it
wouldn't be better to take the approach you are taking, and bravely go
through the Windows interface and avoid additional "kruft" (I like clean,
simple things, including installations). >>
Eventually, when the world wakes up and there are zillions of REBOL apps out
there with something like ARexx-meets-MightyMouse (Small, but powerful,
American cartoon character for those unfamiliar), that can tie them all
together across the universe, life will be simpler. :) Until that time,
we'll have layers of kruft (good word :) here and there. If I have a layer
of Windows stuff that lets me control other apps, that's a start, and it's a
point of reference for what works and what doesn't.
I just can't wait until apps have dialected interfaces. :)
--Gregg
[15/19] from: carl:cybercraft at: 25-Sep-2002 0:07
On 24-Sep-02, Gregg Irwin wrote:
> << 2) ARexx
> Figuring that this was probably not the uncle of T Rex...>>
<<quoted lines omitted: 6>>
> these lines, RT and the Amigans out there will chime in to
> contribute suggestions based on their experience.
I just use ARexx, (in an unaware kind of way:), but have never
programmed in it. I believe it's a port of Rexx, though perhaps
enhanced. It was included with later Amigas, but wasn't a product
developed by Commodore. I think there was some argument over it
somewhere along the line. But anyway, plenty of info about Rexx
here...
http://www2.hursley.ibm.com/rexx/
> << (including the font stuff you generously sent me). >>
> Carl Read is taking it to the next level with his font-requester
> stuff. Very cool!
Steady on Gregg! Neither of us has seen it working yet! (;
--
Carl Read
[16/19] from: anton:lexicon at: 25-Sep-2002 1:49
> << 2) ARexx
Yep, Amiga REXX.
> << OK, so reading quickly between the lines, it sounds like the Amiga was
> blessed with an advanced scripting language that could listen on
<<quoted lines omitted: 5>>
> and the Amigans out there will chime in to contribute suggestions based on
> their experience.
I had a lot of fun with ARexx, after I figured out
how to get it to connect to a program's arexx port!
I used it to do things that I use rebol to do now.
For instance, I just moved some directories around,
reorganising my mp3 collection, and then as a
consequence, my favourite playlist had links to
old filepaths which were incorrect. I quickly made a
rebol script to fix those that were incorrect.
I would have used ARexx to do this job almost as
easily, were I still using the amiga.
The practice on amiga for applications to make
available an arexx port was great, and allowed
others to glue applications together and
automate all sorts of boring, repetitive tasks,
that normally required you to click click click
with your mouse until you go crazy or give up.
It would be good to make an example of a rebol
app that listens on a port for instructions.
It could reject connections that do not originate
from the same machine.
Perhaps we could agree to a standard port (& scheme,
I suppose it would be http:// ) to be used in this
way, then it would be easy to have some generic code
that shows how to connect to and control a whole bunch
of rebol applications.
Ah, but wait, then programs clash with each other,
all trying to serve on the same port.
Maybe imagine some sort of registering program,
maintaining a list like:
4300 Rebol-port-registry (this program)
4321 Bulge
4322 Morph
4400 Video-studio
Each of the programs Bulge, Morph & Video-studio would
seek out Rebol-port-registry on port 4300 at start up,
and register themselves with a "unique" port number.
Then any other program can come along and connect
to Rebol-port-registry to look up what port a
particular program is serving on, so then they
can communicate directly.
So in the end a program could control those three
above to work together, perhaps, for example, getting
Video-studio to save some frames of a video, then
getting Bulge and Morph to process those frames
in a way that Video-studio cannot do already, then
saving and reimporting back into the video.
It's just an idea. :)
Anton.
[17/19] from: gscottjones:mchsi at: 24-Sep-2002 5:56
From: "Gregg Irwin"
...
> There are many forms of IPC, some of which I mentioned. Shared
> memory, pipes, sockets, and command line arguments are other
> common mechanisms. IPC, to this layman, is anything that lets two
> processes communicate. Sockets are used more often now, it seems,
> and they are a good mechanism because they can extend from local
> use to intra- and internet use without drastic architectural changes.
Good. Then conceptually I am not off-base in the concept.
> There are so many ways it could go. One big architectural choice is
> whether it's completely peer to peer, or if you have some kind of
> IPC server process that helps manage and negotiate things, maybe
> providing lookup services and such. There's definitely a holy grail
> hiding in there somewhere. :)
Also, good. I wanted to be sure that the holy grail had not already been
found, and that I simply had not been invited to the ceremony!
> ... I see the power of dialects as something that should
> be leveraged on both the human and computer side of things.
Agreed!
> There are so many ways it could go, we almost have
> to try lots of different approaches to see what works
> well in different contexts. The first things we see will
> very likely be modeled on concepts that exist today,
> but the really good stuff we haven't even thought of yet.
Good point. And likely a truism in life, also.
SJ> << (including the font stuff you generously sent me). >>
> Carl Read is taking it to the next level with his font-requester
> stuff. Very cool!
I must have been asleep at the wheel, as I seemed to have missed this. I'll
look back.
> ... layers of kruft (good word :) ...
I don't know where I picked this up. Out of curiosity I looked in several
dictionaries: not there. I would like to think that it is at least
onomatopoeia, but is probably just a malapropism (I live in the Ozarks,
afterall :-).
Thanks, Gregg. I appeciate the time you took and the ideas.
--Scott Jones
[18/19] from: gscottjones:mchsi at: 24-Sep-2002 11:44
From: "Carl Read"
> But anyway, plenty of info about Rexx here...
>
> http://www2.hursley.ibm.com/rexx/
Thanks, Carl. Out of curiosity, I think I'll have a look.
--Scott Jones
[19/19] from: greggirwin:mindspring at: 24-Sep-2002 11:03
Hi Scott,
<< I would like to think that it is at least onomatopoeia, but is probably
just a malapropism (I live in the Ozarks, afterall :-). >>
You surely dispel any misconceptions about sterotypical Ozarkian
backwards-wordianisms! I think I'm legally allowed to make jokes like that
since I live in Idaho. ;)
--Gregg
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted