Show HN: Primrose – a text editor that runs in a WebGL texture

I'm the same way, so I can relate to your pain. I've had this happen before with Chrome/Chromium with hundreds of tabs. I now use Firefox for two reasons: One, the UI is better than Chrome/Chromium with hundreds of tabs active, and two I now simply periodically clear out long term tabs when I no longer have an immediate need for them by bookmarking them.

My friends think I'm insane by keeping so many tabs open. Maybe I am. Maybe you are, too. Yet with as disorganized as it might seem to others, it works well for my particular usage patterns. (It also helps that I segregate news, work, misc. activities into different profiles, too.) The thing is that sometimes when you open something that you want to get back to at some indeterminate point in the future, you can do one of two things: Bookmark it and forget about it, possibly permanently; or keep it open and stumble upon it as you go through your tabs to categorize them and clean them out. Although these days, I mostly just dump everything into a dated but uncategorized list to go through in the future. Session Manager handles the rest in the event I do something stupid.

I imagine I'll catch some flak for sharing this, but it works well for me. My work-related browser sessions are usually better organized and important stuff gets saved more or less immediately. My "fun" generic browsing instances--not so much.

This is actually how Desktop Window Manager (aka "Aero") on Windows and Quartz Compositor on OS X actually work. They're just setup with an orthographic projection and they don't rotate the windows at all.

That was actually a bit of a surprise (though I admit it shouldn't have been) with Primrose. If I pick dimensions for the editor that fit the window's aspect ratio, and don't rotate the view at all, then the editor pane can fill the browser window and it looks very natural.

I am not positive, as I don't have the spec laying in front of me and it's been a long time since I looked, but I'm pretty sure the HTML5 Canvas API is not hardware accelerated at this time. That is how I do the actual rendering of the text, using Text API.

There is another project called fontpath[1] that can read TTF and OTF font files, and another project from the same developer called gl-sprite-text[2] that can render them as bitmaps to textures. I've been considering converting my rendering over to using it. The process would at least be good practice in decoupling the code a bit more, as I think the tokenizer and keyboard system would be useful in other projects as well.

The keyboard code pages aren't yet complete for everyone in the world right now, but I think they go a long way towards making it possible to once and for all make good keyboard interactions in JS. And by completely implementing my own end-around of the browser's own handling, sticking to more of the older primitives, I am actually able to make for more cross browser compatible. I don't know if anyone noticed, but this runs in IE perfectly fine, and I didn't really do anything special to make it so. And if you just run the Canvas on its own, without the WebGL part, it actually runs on some relatively old browsers without any trouble.

[1] https://github.com/mattdesl/fontpath

[2] https://github.com/mattdesl/gl-sprite-text

Actually, I'm hoping to be able to experiment with code layout ideas that do not strictly adhere to a window. 2D elements tend to not map well to 3D spaces. One of the problems with the text-in-a-texture method that I've done here is that there is no relief of depth to the text, and relief is actually an important part of how we make sense out of objects in 3D space. It's fine on a 2D screen because the context is so restricted that it all stays consistent. But in 3D, it's kind of disconcerting to see completely flat textures.

Like, why do we still use plain text in flat files for source code (for the most part, there are a few exceptions-that-prove-the-rule)? Why are there so many examples of graphical programming systems that have completely failed? Is it because there is something inherent to text that makes it superior for representing algorithms? Or is it because 1-dimensional text maps to our IO systems the best? I suspect there is a healthy dose of the latter, but we haven't ever had a significant "other" IO system to ever test that theory.

In a lot of ways, Primrose isn't even my goal, more like a benchmark from which to start developing other ideas in text representation in VR UIs. I don't know what they will be, but at least I now have a starting point.

This issue is actually where the idea came from to put the text on the inside of a sphere. I wanted to make a VERY big text field, so that I could fit a good amount of text on the object at a font size large enough to read the text well. At that size, the edges of a rectangular window are so much further away from the viewer that there is significant distortion. The sphere makes for a much more comfortable viewing angle.

No, I wouldn't want to write Primrose itself in Primrose, and Primrose isn't a very big project. But little experiments with the live-coding have been fun. I'm still working out the use cases in my head. I suspect there might be more use for manipulating and visualizing code in VR--at least in the early days until resolution gets better--than straight, bulk writing code.

I actually have a project in the works for something like that. I took a break from it to make this.