9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "rob pike, esq." <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] How about some software?
Date: Tue, 18 Jun 2002 22:45:28 -0400	[thread overview]
Message-ID: <ec59612401a4d1468d1501a5e0182c2b@plan9.bell-labs.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

I've dabbled with this a couple of times.  Once I even got working
code that was kinda fun, but I dropped it because I didn't like the
implementation.  All it did was display an image, no input was
available, but e.g.  clicking on foo.gif put foo.gif in an acme window
(this was before plumbing, and was in fact part of the inspiration
behind doing plumbing in the first place, so i could move button 3
rules out of acme code).

After some further thought, I decided the best plan was to represent a
window in acme as a published (via nameimage) image file in the draw
device.  Perhaps that image would not be the window itself, but its
backing store (to use old terminology), but the point is that external
programs could get access to the window much as they do in rio.  Such
windows would need auxiliary files to drive them, and would in the end
require a great deal of duplication of rio's functionality, which is
one of the reasons I didn't pursue it (too much work, too much
duplication) but I was hoping to find a way that some of acme's
structure could survive.  It seemed the best way to achieve that might
be to allow old programs (say, sam) to run in an acme window but not
to push acme very far to make that happen.  Instead, it would be more
productive to design new I/O mechanisms that allowed programs written
specifically for this environment to run there.  This might mean, for
instance, a special toolkit that allowed click-through for selection
and plumbing events.

It was all very vague, even after a couple of throwaway attempts,
but what was clear was that I didn't want to reproduce rio, I wanted
to make an acme-like feel possible for graphics, but I had only
rudimentary ideas about how to do that.

-rob

[-- Attachment #2: Type: message/rfc822, Size: 2477 bytes --]

From: FJ Ballesteros <nemo@gsyc.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] How about some software?
Date: Tue, 18 Jun 2002 19:01:01 +0200
Message-ID: <3D0F674D.5992D721@gsyc.escet.urjc.es>

Time to think about adding images to acme?

I scheduled one week late in July as part of my vacation just to think
about it and give it a try.

Any plans? ideas?

My current idea is just to pretend that an acme window can accept
libdraw requests, it's size would be fixed to the current acme window
size.
No graphics mixed with text, since graphics programs draw their own
text.
Does it make sense?


"rob pike, esq." ha escrito:
>
> > why not lynx? Ascii browsers are fast!
>
> The various piece parts we have here that let Acme do web things
> are sufficient for much webbing, but without pictures it's really
> not the same experience.  images.google.com is worthless, for
> example, and that's one of my favorite services.
>
> -rob

             reply	other threads:[~2002-06-19  2:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-19  2:45 rob pike, esq. [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-06-19  4:40 okamoto
2002-06-19  4:36 rob pike, esq.
2002-06-19  4:31 okamoto
2002-06-19  4:22 rob pike, esq.
2002-06-21 10:08 ` peter a. cejchan
2002-06-19  4:00 okamoto
2002-06-19  2:46 rob pike, esq.
2002-06-18 17:05 Russ Cox
2002-06-17 18:35 rog
2002-06-17 18:17 rog
2002-06-17 16:56 rob pike, esq.
2002-06-17 17:25 ` Micah Stetson
2002-06-17 16:51 andrey mirtchovski
2002-06-17 16:42 rob pike, esq.
2002-06-18 17:01 ` FJ Ballesteros
2002-06-17 13:40 rob pike, esq.
2002-06-17 15:58 ` Sam
2002-06-17 16:35 ` Ronald G Minnich
2002-06-17 18:53 ` Christopher Nielsen
2002-06-17  9:20 Ben

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec59612401a4d1468d1501a5e0182c2b@plan9.bell-labs.com \
    --to=rob@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).