9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Object Icon, drawterm, riox
@ 2020-01-04 11:04 Mark van Atten
  2020-01-04 11:08 ` [9fans] " Олег Бахарев
  2020-01-27 21:42 ` Anthony Sorace
  0 siblings, 2 replies; 9+ messages in thread
From: Mark van Atten @ 2020-01-04 11:04 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

For whomever may find this of interest -- the Object Icon project,
mentioned on this list in passing in August 2018, also caters to Plan
9:

The Object Icon object-oriented programming language:
http://objecticon.sourceforge.net/

Of wider use may be its version of drawterm
http://objecticon.sourceforge.net/Drawterm.html
and its (much) modified rio
http://objecticon.sourceforge.net/Riox.html

Mark.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] Object Icon, drawterm, riox
  2020-01-04 11:04 Object Icon, drawterm, riox Mark van Atten
@ 2020-01-04 11:08 ` Олег Бахарев
  2020-01-05 16:13   ` hiro
  2020-01-27 21:42 ` Anthony Sorace
  1 sibling, 1 reply; 9+ messages in thread
From: Олег Бахарев @ 2020-01-04 11:08 UTC (permalink / raw)
  To: 9fans

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

under arm working?

сб, 4 янв. 2020 г., 14:05 Mark van Atten <vanattenmark@gmail.com>:

> For whomever may find this of interest -- the Object Icon project,
> mentioned on this list in passing in August 2018, also caters to Plan
> 9:
>
> The Object Icon object-oriented programming language:
> http://objecticon.sourceforge.net/
>
> Of wider use may be its version of drawterm
> http://objecticon.sourceforge.net/Drawterm.html
> and its (much) modified rio
> http://objecticon.sourceforge.net/Riox.html
>
> Mark.
>
> ------------------------------------------
> 9fans: 9fans
> Permalink:
> https://9fans.topicbox.com/groups/9fans/T888cf1c8059b63ab-M197f28290ef268b93fff0218
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

[-- Attachment #2: Type: text/html, Size: 1629 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] Object Icon, drawterm, riox
  2020-01-04 11:08 ` [9fans] " Олег Бахарев
@ 2020-01-05 16:13   ` hiro
  2020-01-07 22:39     ` Ethan Gardener
  0 siblings, 1 reply; 9+ messages in thread
From: hiro @ 2020-01-05 16:13 UTC (permalink / raw)
  To: 9fans

i object indeed. it's insulting what they did to those programs.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] Object Icon, drawterm, riox
  2020-01-05 16:13   ` hiro
@ 2020-01-07 22:39     ` Ethan Gardener
  0 siblings, 0 replies; 9+ messages in thread
From: Ethan Gardener @ 2020-01-07 22:39 UTC (permalink / raw)
  To: g_patrickb via 9fans

On Sun, Jan 5, 2020, at 4:13 PM, hiro wrote:
> i object indeed. it's insulting what they did to those programs.

Indeed! It's been a while since I felt strongly enough to close a page in disgust. "Transient windows" indeed.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] Object Icon, drawterm, riox
  2020-01-04 11:04 Object Icon, drawterm, riox Mark van Atten
  2020-01-04 11:08 ` [9fans] " Олег Бахарев
@ 2020-01-27 21:42 ` Anthony Sorace
  2020-01-27 22:03   ` Rodrigo G. López
  1 sibling, 1 reply; 9+ messages in thread
From: Anthony Sorace @ 2020-01-27 21:42 UTC (permalink / raw)
  To: 9fans

I get why someone might want those rio changes, even if they're not for me (although some I'm curious about). But can anyone help me understand why what they've done to drawterm is desirable? I can't say that resizing the window to change the scale factor has ever seemed like something I'd want. How do they use this?

> On Jan 4, 2020, at 3:04 , Mark van Atten <vanattenmark@gmail.com> wrote:
> 
> For whomever may find this of interest -- the Object Icon project,
> mentioned on this list in passing in August 2018, also caters to Plan
> 9:
> 
> The Object Icon object-oriented programming language:
> http://objecticon.sourceforge.net/
> 
> Of wider use may be its version of drawterm
> http://objecticon.sourceforge.net/Drawterm.html
> and its (much) modified rio
> http://objecticon.sourceforge.net/Riox.html
> 
> Mark.
> 
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/T888cf1c8059b63ab-M197f28290ef268b93fff0218
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] Object Icon, drawterm, riox
  2020-01-27 21:42 ` Anthony Sorace
@ 2020-01-27 22:03   ` Rodrigo G. López
  2020-08-28 18:04     ` Leonardo
  0 siblings, 1 reply; 9+ messages in thread
From: Rodrigo G. López @ 2020-01-27 22:03 UTC (permalink / raw)
  To: 9fans

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

they don't.

On Mon, Jan 27, 2020, 11:00 PM Anthony Sorace <a@9srv.net> wrote:

> I get why someone might want those rio changes, even if they're not for me
> (although some I'm curious about). But can anyone help me understand why
> what they've done to drawterm is desirable? I can't say that resizing the
> window to change the scale factor has ever seemed like something I'd want.
> How do they use this?
>
> > On Jan 4, 2020, at 3:04 , Mark van Atten <vanattenmark@gmail.com> wrote:
> >
> > For whomever may find this of interest -- the Object Icon project,
> > mentioned on this list in passing in August 2018, also caters to Plan
> > 9:
> >
> > The Object Icon object-oriented programming language:
> > http://objecticon.sourceforge.net/
> >
> > Of wider use may be its version of drawterm
> > http://objecticon.sourceforge.net/Drawterm.html
> > and its (much) modified rio
> > http://objecticon.sourceforge.net/Riox.html
> >
> > Mark.
>
> ------------------------------------------
> 9fans: 9fans
> Permalink:
> https://9fans.topicbox.com/groups/9fans/T888cf1c8059b63ab-M55c31e4cc43ac291fd03f75b
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

[-- Attachment #2: Type: text/html, Size: 2197 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] Object Icon, drawterm, riox
  2020-01-27 22:03   ` Rodrigo G. López
@ 2020-08-28 18:04     ` Leonardo
  2020-09-01 11:20       ` Ethan Gardener
  0 siblings, 1 reply; 9+ messages in thread
From: Leonardo @ 2020-08-28 18:04 UTC (permalink / raw)
  To: 9fans

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

These changes are interesting and I don't see any problem with new needs but I think these changes carry some complexities to window system that can kept outside in new programs or libraries. Rio runs in your windows a terminal as default that I think too, and I believe that is possible, to kept outside the window system and called into. (This if I want reduce the code that I known by window system). I can see the need for a window have an owner and stay on the screen only if your owner stays, but I think this feature could be put in a GUI library with a control called Window (a pseudo-window) that can have an owner (other Window). The terminal code (colors etc.) can be put in a terminal program etc. Noborder feature are a small and interesting feature to have within the window system (programs that run inside rio windows can so control entire window look).






[-- Attachment #2: Type: text/html, Size: 4323 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] Object Icon, drawterm, riox
  2020-08-28 18:04     ` Leonardo
@ 2020-09-01 11:20       ` Ethan Gardener
  2020-09-01 19:18         ` Leonardo
  0 siblings, 1 reply; 9+ messages in thread
From: Ethan Gardener @ 2020-09-01 11:20 UTC (permalink / raw)
  To: 9fans

On Fri, Aug 28, 2020, at 7:04 PM, Leonardo wrote:
> I can see the need for a window have an owner and stay on the screen only if your owner stays,

I'm not sure I'm thinking clearly today, but don't we have this? A single window normally requires at least 3 procs, (keyboard, mouse, output,) so, to quote rio(1): Deleting a window causes a `hangup' note to be sent to all processes in the window's process group (see notify(2)). Is there any reason one process group cann't have multiple windows? If not, then the default is to close all when one is closed. Now I see the clever bit would be the reverse of the problem statement: *not* closing the parent window when a child window is deleted.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] Object Icon, drawterm, riox
  2020-09-01 11:20       ` Ethan Gardener
@ 2020-09-01 19:18         ` Leonardo
  0 siblings, 0 replies; 9+ messages in thread
From: Leonardo @ 2020-09-01 19:18 UTC (permalink / raw)
  To: 9fans

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

On Tuesday, 1 September 2020, at 8:21 AM, Ethan Gardener wrote:
> Is there any reason one process group cann't have multiple windows?
By design, each window must have your own private namespace with your own /dev/* files and although these files have same names when a window write to one of them, that one is yours. If I didn't get it wrong, that's it. This seems strange because it seems that windows use the same files, but they don't. I think it's strange because I'm not familiar with the concept of namespace: in other operating systems there is always just one filesystem. I imagine that these issues of parent-window, child-window and owner-window are minor, unimportant things and, therefore, had no place in the design of the system: they were unnecessary complications.

[-- Attachment #2: Type: text/html, Size: 908 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-09-01 19:18 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-04 11:04 Object Icon, drawterm, riox Mark van Atten
2020-01-04 11:08 ` [9fans] " Олег Бахарев
2020-01-05 16:13   ` hiro
2020-01-07 22:39     ` Ethan Gardener
2020-01-27 21:42 ` Anthony Sorace
2020-01-27 22:03   ` Rodrigo G. López
2020-08-28 18:04     ` Leonardo
2020-09-01 11:20       ` Ethan Gardener
2020-09-01 19:18         ` Leonardo

9fans - fans of the OS Plan 9 from Bell Labs

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9fans

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9fans 9fans/ http://inbox.vuxu.org/9fans \
		9fans@9fans.net
	public-inbox-index 9fans

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9fans


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git