Object Icon, drawterm, riox

Object Icon, drawterm, riox

[Mark van Atten]

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.

Re: [9fans] Object Icon, drawterm, riox

[Олег Бахарев]

[-- 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 --]

Re: [9fans] Object Icon, drawterm, riox

[hiro]

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

Re: [9fans] Object Icon, drawterm, riox

[Ethan Gardener]

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.

Re: [9fans] Object Icon, drawterm, riox

[Anthony Sorace]

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

Re: [9fans] Object Icon, drawterm, riox

[Rodrigo G. López]

[-- 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 --]

Re: [9fans] Object Icon, drawterm, riox

[Leonardo]

[-- 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 --]

Re: [9fans] Object Icon, drawterm, riox

[Ethan Gardener]

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.

Re: [9fans] Object Icon, drawterm, riox

[Leonardo]

[-- 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 --]