9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: sirjofri <sirjofri+ml-9fans@sirjofri.de>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] Plan 9 applying to GSoC
Date: Sat, 19 Feb 2022 11:00:37 +0000 (UTC)	[thread overview]
Message-ID: <98804c9e-140d-4a3f-9446-bc5c152119ba@sirjofri.de> (raw)
In-Reply-To: <33881A44-3016-432E-AA81-54ED41E32000@9srv.net>

Good morning,

I skimmed through the ideas page as well as the mails in this thread and 
I wanted to share my thoughts and ideas.

(1) I am working on a port of 9front to the pinephone smartphone. 
Although it is still a long way to go I believe the project can be very 
interesting for UI ideas and implementations. This would also fit tbe rio 
alternatives idea. Let me quickly explain.

Plan 9 has a unique user interface built from many components. We have 
heavy use of three mouse buttons, many text-based interfaces (also 
counting acme tags, for example), system-wide plumber support, only to 
mention few of those. However, some of these aspects don't make much 
sense on a touch device due to big thumbs and the nature of touchscreens.

The idea for this would be designing an integrated, Plan 9-worthy 
touchscreen rio replacement for mobile devices. Ideally it can coexist 
with rio (i.e run inside rio windows and rio can run inside 
"this-window-manager" windows) and is fully compatible with existing 
graphical UI applications (using standard draw routines).

Although the software can currently not be tested on the pinephone (I'm 
still working on the kernel) there are some devices with rudimentary 
touchscreen support (I have a working thinkpad twist with 9front) we can 
use for testing, and some functionality can be tested inside scaled rio 
windows on common Plan 9 systems.

(2) Under similar circumstances (mobile device with touch input) another 
project might be some kinda graphical (rc) shell interface. I have an 
idea, and we also discussed ideas on the discord server.

(3) A high-level filesystem interface for UI widgets. Many modern UI 
layouts can be described as a hierarchy of containers. The UI filesystem 
would start as an empty window, which is reflected by an empty 
filesystem. The user could create widget containers (hbox, vbox) by 
creating directories and files, as well as input boxes, buttons and more 
by creating files. The hierarchy would directly reflect the drawn window. 
The user can listen to files for button interaction and write text to 
labels etc..

(4) A filesystem that filters a namespace, but the file contents and not 
the namespace.

The idea is to have a filesystem like exportfs, however, it doesn't just 
represent the files as is, but applies user-defined filters to the 
filenames/paths as well as the file contents.

Imagine you have a namespace which contains markdown files that end with 
.md. Using this overlay filesystem you can present the same namespace, 
but convert the filenames using sed (from .md to .html) and when reading, 
the file contents (from markdown syntax to html syntax).

The filesystem would be very powerful for exposing plain text data as 
html, encapsulating data into some predefined layout, and much more. It 
could essentially make any plain text filesystem available as regular 
web-friendly html files, convert troff source to postscript, convert plan 
9 images to png, and much more. You can even present device files as json 
for modern web applications.

Caching file contents can improve performance and reduce load.

(5) Ringfs. This is a very small project and also the least powerful as 
far as I can say now.

The general idea is that the filesystem presents the created files and 
when reading a file the contents point to the next file in the "ring" in 
alphabetical order.

It's probably best explained using the following shell interaction:

; touch fileA fileB fileC
; cat fileA
; cat fileB
; cat fileC

The project is very small and probably too simple for a GSoC project.

These are some ideas I thought about in the last months. Some are very 
small and I can imagine mentoring these smaller projects if it's not to 
hard. My time is rare (as for most of you I guess) and I never mentored 
any programmer, so I guess I'd ask more experienced people now and then.

Personally I like all of these ideas and would like to work on all of 
them if I had enough time.


9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M7eef49e9a147609a6fee4160
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

  parent reply	other threads:[~2022-02-19 11:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18 20:03 Anthony Sorace
2022-02-18 22:43 ` [9fans] " adventuresin9
2022-02-19  0:19   ` hiro
2022-02-19  3:56     ` adventuresin9
2022-02-19 10:21 ` [9fans] " Lucio De Re
2022-02-19 11:00 ` sirjofri [this message]
2022-02-19 16:16   ` [9fans] " cigar562hfsp952fans
2022-02-19 17:18     ` Marshall Conover
2022-02-19 18:06       ` [9fans] Omero/UI filesystem (was: Plan 9 applying to GSoC) sirjofri
2022-02-20 17:45 ` [9fans] Plan 9 applying to GSoC ori
2022-02-19 19:33 Bakul Shah
2022-02-19 20:01 ` ori

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:

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

  git send-email \
    --in-reply-to=98804c9e-140d-4a3f-9446-bc5c152119ba@sirjofri.de \
    --to=sirjofri+ml-9fans@sirjofri.de \
    --cc=9fans@9fans.net \
    --subject='Re: [9fans] Plan 9 applying to GSoC' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).