Re: [9fans] How about some software?

[okamoto@granite.cias.osakafu-u.ac.jp]

This is a multi-part message in MIME format.
--upas-vgpazmcnyyozejxnqjhamcqfci
Content-Disposition: inline

Do you think we need to have graphic programs in acme itself?
I supposed it's not possible or not easy (at least to me ;_;), if we want
to keep the benefits of acme.

If we could have a mechanism to communicate with external graphics
programs and acme, say such that when we need some more complicated
interactive user action, such that giving many data for GUI DBMS, we can
use acme's editer and that coworking graphics programs.

I'm not sure that kind of mechanism has been implemented already or not.
Multiple threading may serve for it?

I may saying something stupid, if so please neglect it.

Kenji


--upas-vgpazmcnyyozejxnqjhamcqfci
Content-Type: message/rfc822
Content-Disposition: inline

Received: from granite.cias.osakafu-u.ac.jp ([192.168.1.3]) by diabase; Wed Jun 19 11:45:30 JST 2002
Received: from elmo.cias.osakafu-u.ac.jp (elmo.cias.osakafu-u.ac.jp [157.16.103.2])
	by granite.cias.osakafu-u.ac.jp (8.9.3/8.9.3) with ESMTP id LAA06632
	for <okamoto@granite.cias.osakafu-u.ac.jp>; Wed, 19 Jun 2002 11:36:37 +0900
Received: from mail.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6])
	by elmo.cias.osakafu-u.ac.jp (8.9.3/3.7W-02040219) with ESMTP id LAA16204
	for <okamoto@granite.cias.osakafu-u.ac.jp>; Wed, 19 Jun 2002 11:46:23 +0900 (JST)
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.30.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 5AFBB199EC; Tue, 18 Jun 2002 22:46:11 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from plan9.cs.bell-labs.com (ampl.com [204.178.31.2])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 8E2BF199B7
	for <9fans@cse.psu.edu>; Tue, 18 Jun 2002 22:45:30 -0400 (EDT)
Message-ID: <ec59612401a4d1468d1501a5e0182c2b@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] How about some software?
From: "rob pike, esq." <rob@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-pcfljzsnflbcxkzqulxtunmlfz"
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Tue, 18 Jun 2002 22:45:28 -0400

This is a multi-part message in MIME format.
--upas-pcfljzsnflbcxkzqulxtunmlfz
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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

--upas-pcfljzsnflbcxkzqulxtunmlfz
Content-Type: message/rfc822
Content-Disposition: inline

Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Jun 18 12:57:19 EDT 2002
Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Tue Jun 18 12:57:18 EDT 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 17CA719A8E; Tue, 18 Jun 2002 12:57:11 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from gsyc.escet.urjc.es (gsyc064.dat.escet.urjc.es [193.147.71.64])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 6BCD919A92
	for <9fans@cse.psu.edu>; Tue, 18 Jun 2002 12:56:05 -0400 (EDT)
Received: from gsyc.escet.urjc.es (213-0-203-0.dialup.nuria.telefonica-data.net [213.0.203.0])
	by gsyc.escet.urjc.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA13710
	for <9fans@cse.psu.edu>; Tue, 18 Jun 2002 18:56:02 +0200
X-Authentication-Warning: gsyc.escet.urjc.es: Host 213-0-203-0.dialup.nuria.telefonica-data.net [213.0.203.0] claimed to be gsyc.escet.urjc.es
Message-ID: <3D0F674D.5992D721@gsyc.escet.urjc.es>
From: FJ Ballesteros <nemo@gsyc.escet.urjc.es>
X-Mailer: Mozilla 4.78 [es] (Win98; U)
X-Accept-Language: es
MIME-Version: 1.0
To: 9fans@cse.psu.edu
Subject: Re: [9fans] How about some software?
References: <190e9b00d20f4b751d1d7996d227757e@plan9.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Tue, 18 Jun 2002 19:01:01 +0200

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
--upas-pcfljzsnflbcxkzqulxtunmlfz--
--upas-vgpazmcnyyozejxnqjhamcqfci--