Possible Ways to Extend Browsers

We already do "extend" browsers with things like "external viewers." But there's not a very good integration with the browser. Ideally those external viewers should be rendering in-place inside the document, and be working together with the browser, be tightly integrated with the browser and other parts...

#docfs #webfs #kfc

https://web.archive.org/web/19990127141653/http://www-pcd.stanford.edu:80/workshop/slides/wei/talk.html

1/

So, a solution is what's been touted under with name "component software". The basic idea is that, rather than buildig one single monolithic application that does everythig from day one, we should be building a framework or architecture that ican be dynamic in its ability to have functionality added or deleted on the fly.

@eliotberriot
@natecull

2/

@dredmorbius @eliotberriot

We have 'component software' already, that's what COM and .NET are.

We maybe need something more?

@natecull @dredmorbius @eliotberriot
Like, theoretically, sure. But, realistically, these things are still walled gardens in terms of the apps created with them.

@enkiv2 @natecull @dredmorbius @eliotberriot and the efforts to implement this type of interface for other kinds of software (i.e. OpenDoc, CORBA, XPCOM (sort of)) haven't been particularly successful.

@a_breakin_glass
I can't tell how much of the problem is technical and how much is political.

Like, component based applications are in a sense profoundly anti-corporate-capitalist in that nobody can reasonably expect to control the 'look and feel' of a user's actual experience or cockblock their competition on the user's machine.

The unix shell does composability between totally independently developed things well, on the other hand.

@natecull @dredmorbius @eliotberriot

@eliotberriot @dredmorbius @natecull @a_breakin_glass

(The web tried to do some of this with frames early on & there were many lawsuits.)

@enkiv2 @eliotberriot @dredmorbius @natecull the reason why unix shell composability doesn't work for GUIs and we have to rely on APIs is partially, again, the result of GUIs still obeying VERY old limits

@a_breakin_glass @enkiv2 @eliotberriot @natecull Could you expand on this thought?

What are the limits?

How did / do shell tools fail in them?

What if there were, I don't know, some lightweight application-wrapper that could be tossed around shell tools?

Or does that fail to address concerns of the GUI space?

(I've never designed GUI tools, and always found the space vaguely mystifying.)

@dredmorbius @a_breakin_glass @eliotberriot @natecull
GUI toolkits aren't really designed around composability. combining bits of one widget with bits of another means rewriting both, usually. widgets can't overlap, except special frame-type ones. each window is its own little domain. applications don't by default have the ability to embed each other's components. a non-technical end user certainly can't mash up two apps.

@enkiv2 @dredmorbius @a_breakin_glass @eliotberriot

Just for speculation, would a GUI widget be more composable if it were seen as a Unix-like pipe/filter mapping a stream of input events (with initial/accumulating state) to output events?

(Doing so would require a framework where an 'event' or a 'message' is itself an object; which I think Smalltalk can do but not many other OOP systems)

Or can GUI widgets fundamentally not be implemented as a stream/filter model at all?

@natecull @dredmorbius @a_breakin_glass @eliotberriot
I'm not sure how to conceptualize widgets as filters in a general sense but I'm not willing to claim it can't be done.

@enkiv2 @natecull @a_breakin_glass @eliotberriot Maybe I need a better definition of "widget" here. Are these controls? Outputs? Both?

(I really don't do GUI dev.)

@dredmorbius @enkiv2 @a_breakin_glass @eliotberriot

a widget is any kind of object in a GUI system that has a graphical state.

Part of the complexity of GUIs is that you have to 'hook up' your widgets to receive events from others. A bit like lots of wires in a circuit board. Very brittle, hard to repurpose.

@eliotberriot @a_breakin_glass @enkiv2 @dredmorbius

So a widget, to work, needs to know the name and type of all its partners, and care about their state. Vs a Unix filter that knows nothing about what's upstream or downstream the pipe.

@natecull @eliotberriot @a_breakin_glass @enkiv2 I've been thinking about, effectively, widgets, viewers, and shells, in the context of docfs. How tightly integrated should all that be?

Check the repo for my recent edits, just pushed now.

I'd like docfs to work from any shell (including remote, no GUI, etc.). But for the full flavour, you'd want a terminal that can incorporate widgets, basically. How much of a good or bad idea /that/ is I'm not entirely sure.

But, see the tectronics term.

1/

@enkiv2 @a_breakin_glass @eliotberriot @natecull If we want interactivity (sorting or summarising data, popping up / closing asides, ToCs, etc.) then how that's handled.

Recognising that the "terminal" might be a TTS output / voice input. Or a touchscreen. a 4 cm display, or 200 cm display. Colour. eInk. Touch. Flat. Monochrome.

Anyhow: how do you build a CLI-GUI integrated concept around all of that.

5/

@dredmorbius @enkiv2 @a_breakin_glass @eliotberriot

I think Tcl/Tk widgets take a somewhat similar approach?

I don't really know, I've never used Tk, but, I think they send text strings around.

https://www.tcl.tk/man/tcl8.6/TkCmd/ttk_button.htm

And the whole Smalltalk-era MVC thing suggests we should cleanly separate model/view/control, but in practice we almost never do.

I feel like 'pipes of events' SHOULD be a good paradigm, but maybe needs a lot of 'tee' components... eg, a publish/subscribe protocol.

@eliotberriot @a_breakin_glass @enkiv2 @dredmorbius

and, eg, even Unix pipes have a lot of components that don't strictly fit the pipe model. So there's some fundamental work that hasn't been done if we need pipes to be a first class model for all-purpose data communication.

Eg: 'cat filename' puts a file's lines ON the pipe, but doesn't use a pipe to GET that data. It's not clear that there's a good pipeful mechanism for 'get a chunk of data', but a lot of GUI stuff is selecting data.

@dredmorbius @enkiv2 @a_breakin_glass @eliotberriot

So far the interface that's best managed to combine CLI and GUI interfaces is the 'file directory'.

I can take a directory, and I know it always has roughly similar semantics:

* it has a text path
* it's a list of items
* items have names, properties and contents
* A given window (text or GUI ) maps to a path and shows the contents
* I can 'navigate' around either mode

Can we use 'objects' instead of 'directories' and generalise this?

@eliotberriot @a_breakin_glass @enkiv2 @dredmorbius

We would need, perhaps, a way of creating a 'virtual directory' where some 'files' were links to other places in the tree.

Those links (symlinks in a filesystem, or object references in an objectsystem) might be functions, perhaps.

Just this one concept might get us universal pure-functional computation...?

Like what if 'clicking a button' literally transported you to another 'place in the object tree'?

Could that cover all interaction?

@natecull @eliotberriot @a_breakin_glass @enkiv2 This is where rather than fucking around with symlinks, we just kind of separate /data storage/ from /data access/. The "filesystem" is a route to viewing file-shaped shit. As with /proc or /sys.

Where, say, in /docfs, there actually /are/ serialised representations of text (or audio, images, video, etc.) those /do/ have a specific storage spot. (I've been putting my "books" in the "/stacks" conceptually). But you don't go there generally.

1/

@enkiv2 @a_breakin_glass @eliotberriot @natecull Instead, /docfs itself is your interface to works, through /title, /author, /subject, /date, /project, /group, or other "trees". Which are virtual filesystem-like interfaces to specific works.

An /interface/ but not the direct storage repo itself.

2/