From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] How about some software? From: "rob pike, esq." MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-pcfljzsnflbcxkzqulxtunmlfz" Date: Tue, 18 Jun 2002 22:45:28 -0400 Topicbox-Message-UUID: b35e7ad2-eaca-11e9-9e20-41e7f4b1d025 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 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: 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--