* [9fans] Re: Plan 9 applying to GSoC
2022-02-18 20:03 [9fans] Plan 9 applying to GSoC Anthony Sorace
@ 2022-02-18 22:43 ` adventuresin9
2022-02-19 0:19 ` hiro
2022-02-19 10:21 ` [9fans] " Lucio De Re
` (2 subsequent siblings)
3 siblings, 1 reply; 10+ messages in thread
From: adventuresin9 @ 2022-02-18 22:43 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]
An idea that would fall under rio and interfaces;
Replace mouse with movement. Have the usual X and Y, but also add a Z, which would be equivalent to something like pinch-zoom on a phone. And also have rotation around an axis, so that a mouse wheel would be interpreted as rotating around the X axis. Have movement accept absolute and relative inputs, so it works with touch screen and wacom tablets, or mice and joysticks. Multiple device inputs can go in, and the interface would read out 6 degrees of movement.
Than have all buttons come from a single button server. That way you can map the extra buttons on modern mice, or take input from an on-screen keyboard to be read of key presses by another process.
And have both movement and buttons listed in /srv, and let other devices import them. So you can have a tablet's touchscreen used as a pointing device at a desktop.
And with that, work could then be done on alternative graphical interfaces without being tied to the traditional keyboard and 3 button mouse.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M6cb6efb5c87fee7828a1f2e3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 1912 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] Re: Plan 9 applying to GSoC
2022-02-18 22:43 ` [9fans] " adventuresin9
@ 2022-02-19 0:19 ` hiro
2022-02-19 3:56 ` adventuresin9
0 siblings, 1 reply; 10+ messages in thread
From: hiro @ 2022-02-19 0:19 UTC (permalink / raw)
To: 9fans
6 degrees aren't enough, even 9 degrees wouldn't be enough, we need a
truly hypercubic input device IMHO. so far, mice aren't it.
On 2/18/22, adventuresin9@gmail.com <adventuresin9@gmail.com> wrote:
> An idea that would fall under rio and interfaces;
>
> Replace mouse with movement. Have the usual X and Y, but also add a Z,
> which would be equivalent to something like pinch-zoom on a phone. And also
> have rotation around an axis, so that a mouse wheel would be interpreted as
> rotating around the X axis. Have movement accept absolute and relative
> inputs, so it works with touch screen and wacom tablets, or mice and
> joysticks. Multiple device inputs can go in, and the interface would read
> out 6 degrees of movement.
>
> Than have all buttons come from a single button server. That way you can
> map the extra buttons on modern mice, or take input from an on-screen
> keyboard to be read of key presses by another process.
>
> And have both movement and buttons listed in /srv, and let other devices
> import them. So you can have a tablet's touchscreen used as a pointing
> device at a desktop.
>
> And with that, work could then be done on alternative graphical interfaces
> without being tied to the traditional keyboard and 3 button mouse.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-Mb57394aa18df4a08e0a03b62
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] Plan 9 applying to GSoC
2022-02-18 20:03 [9fans] Plan 9 applying to GSoC Anthony Sorace
2022-02-18 22:43 ` [9fans] " adventuresin9
@ 2022-02-19 10:21 ` Lucio De Re
2022-02-19 11:00 ` sirjofri
2022-02-20 17:45 ` [9fans] Plan 9 applying to GSoC ori
3 siblings, 0 replies; 10+ messages in thread
From: Lucio De Re @ 2022-02-19 10:21 UTC (permalink / raw)
To: 9fans; +Cc: inferno-os
On 2/18/22, Anthony Sorace <a@9srv.net> wrote:
> Plan 9 is applying to GSoC again!
>
> [ ... ]
I've done a bit of work on P9P's fontsrv as well as a version -
somewhat mysteriously different - "ported" to Plan 9. If we can debate
the pros and cons of effectively replacing the static availability of
fonts in Plan 9 with a networked TrueType font server (as I am largely
using presently, to some extent), I believe some work could be
dedicated in turning fontsrv into an integral part of the Plan 9
distributions.
I'll be happy to assist with mentorship in this. I'd no doubt learn
much myself in the process.
Lucio.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M23f605304b6f1f5c7288abc1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] Plan 9 applying to GSoC
2022-02-18 20:03 [9fans] Plan 9 applying to GSoC Anthony Sorace
2022-02-18 22:43 ` [9fans] " adventuresin9
2022-02-19 10:21 ` [9fans] " Lucio De Re
@ 2022-02-19 11:00 ` sirjofri
2022-02-19 16:16 ` [9fans] " cigar562hfsp952fans
2022-02-20 17:45 ` [9fans] Plan 9 applying to GSoC ori
3 siblings, 1 reply; 10+ messages in thread
From: sirjofri @ 2022-02-19 11:00 UTC (permalink / raw)
To: 9fans
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
fileB
; cat fileB
fileC
; cat fileC
fileA
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.
sirjofri
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M7eef49e9a147609a6fee4160
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* [9fans] Re: Plan 9 applying to GSoC
2022-02-19 11:00 ` sirjofri
@ 2022-02-19 16:16 ` cigar562hfsp952fans
2022-02-19 17:18 ` Marshall Conover
0 siblings, 1 reply; 10+ messages in thread
From: cigar562hfsp952fans @ 2022-02-19 16:16 UTC (permalink / raw)
To: 9fans
sirjofri <sirjofri+ml-9fans@sirjofri.de> writes:
> (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..
Ballastero(sp?) and lsub's Octopus (Omero? O-something) does something
like this. With it, you can tar/untar a Tk UI from one system to
another. IIRC, it was implemented with Inferno. Since I is similiar to
9, it probably wouldn't be too hard to port.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-Mc494dd5ad027aad6fc42c2fb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] Re: Plan 9 applying to GSoC
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
0 siblings, 1 reply; 10+ messages in thread
From: Marshall Conover @ 2022-02-19 17:18 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]
Adding a +1 for sirjofri's idea 3, which seems like it would be achievable,
has clear objectives, and a compelling result.
For idea 4, a notable utility is pipefile -
https://9p.io/magic/man2html/1/pipefile. It allows you to stitch a command
in-between the reading and/or writing of a file. It'd be worth eyeballing
and considering for the purposes you're thinking of, and may provide a
jumping-off point.
Cheers,
Marshall
On Sat, Feb 19, 2022 at 11:33 AM <cigar562hfsp952fans@icebubble.org> wrote:
> sirjofri <sirjofri+ml-9fans@sirjofri.de> writes:
>
> > (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..
>
> Ballastero(sp?) and lsub's Octopus (Omero? O-something) does something
> like this. With it, you can tar/untar a Tk UI from one system to
> another. IIRC, it was implemented with Inferno. Since I is similiar to
> 9, it probably wouldn't be too hard to port.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M709844316c73d6efec7d190b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 3169 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] Omero/UI filesystem (was: Plan 9 applying to GSoC)
2022-02-19 17:18 ` Marshall Conover
@ 2022-02-19 18:06 ` sirjofri
0 siblings, 0 replies; 10+ messages in thread
From: sirjofri @ 2022-02-19 18:06 UTC (permalink / raw)
To: 9fans
Hello you two,
yes, others in the community also pointed me towards Omero and I skimmed
through the man page about it. I don't know much about Plan B/Octopus,
but it seems the general idea is very similar to what I have in mind.
However (you can correct me if I'm wrong), it seems that it is tailored
to the Plan B UI, which looks very different to the standard devdraw/rio
way of doing UI, so I guess there's quite some work to do.
For people who are interested: I played around with the concept some time
ago, but I wasn't good at writing filesystems back then. The solution I
came up with was rcgui, which is not a full filesystem but just a
connection (as a pipe) with a textual interface.
https://git.sr.ht/~sirjofri/rcgui
In general, I believe that with solid native filesystems and solid native
programs many applications can just be shell scripting "glue" between the
(descriptive) UI layer and the backend filesystem. For more complex
applications devs might want to use the native programming language to
write this "glue" or even make it part of the native backend application.
One component-based descriptive UI filesystem would open this gate for
both approaches and UI designers can mockup their designs very easily.
Plan 9 is often about abstracting resources as filesystems, and I believe
UI shouldn't be an exception. Devdraw abstracts drawing already, but I
think the common way of making/managing/controlling UI can be abstracted,
too.
sirjofri
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T765c829f434b0f6f-Me7af5b7e4822047d9bdf27b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] Plan 9 applying to GSoC
2022-02-18 20:03 [9fans] Plan 9 applying to GSoC Anthony Sorace
` (2 preceding siblings ...)
2022-02-19 11:00 ` sirjofri
@ 2022-02-20 17:45 ` ori
3 siblings, 0 replies; 10+ messages in thread
From: ori @ 2022-02-20 17:45 UTC (permalink / raw)
To: 9fans
Quoth Anthony Sorace <a@9srv.net>:
> Plan 9 is applying to GSoC again!
>
> The application period closes on Monday, and our formal application is in. As is the case every year, the most critical part of an application is the org's ideas page[1]. We'd love additional fleshed-out contributions for that. Since we had a little confusion on this last year, please note that we're looking specifically for well-developed ideas that would be good summer-sized projects for new contributors, from folks willing to mentor those projects (rather than "it'd be neat if someone would do X"); see the existing ideas page for examples (some of which are more developed than others, certainly!).
>
> If you're interested in mentoring, please let me know! Bringing your own project idea is great, but we can also use more experienced, eager folks to pair up with new contributors on other projects.
>
> We've got an overview page[2], and all the program details are on Google's GSoC page[3], and you might be interested in the program timeline[4] in particular.
>
> One other note, for those of you who're familiar with the program, there are a few notable changes, which Google goes into in a post[5] about them. In brief, though:
>
> - The program is now open to a lot more than just formal students
> - There are two project sizes: large ("traditional") and medium (like last year's)
> - The timing of the work is more flexible.
>
> I think these are all great (even if they make a little more work for admins and mentors!) and should be nice additions to the program.
>
> Your friendly neighborhood org admin,
> Anthony
>
> [1] https://p9f.org/wiki/gsoc-2022-ideas/index.html
> [2] http://p9f.org/wiki/gsoc/index.html
> [3] https://summerofcode.withgoogle.com
> [4] https://developers.google.com/open-source/gsoc/timeline
> [5] https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html
While pdffs project that was proposed last year didn't
get accepted, the student that proposed it still made a
lot of progress, and now that code can fully extract
text from PDFs.
It may be worth trying to carry that forward.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-Mface259247e81fb72187850d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread