Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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