The reason I started on the FWT was so that I could start building some IDE components for Fan. Now that the FWT is shaping up, I'm getting ready to start the next phase.

My strategy is to build a tool called "Flux" which will be 100% written in Fan itself. Flux is just a working name, if you have better ideas please share.

Flux will be a lightweight FWT-based UI shell which is essentially a Fan Uri browser. Navigation to a Uri will be resolved to an Obj. This will likely flush out some of Fan's Uri resolution design and how we do plugin schemes via the type database.

Once an Obj is resolved, we will use the type database to find all the registered views on that object. Views are essentially the plugins for viewing/editing objects. Navigation will work pretty much like Firefox: default action replaces current view, or you can open new tabs or new windows.

All of the UI development tools which ship with the Fan developer kit will be plugins to Flux. I'll probably do a graphical version of most of the command line tools like fant, fanp, etc.

I'm going to design the plugins so that hopefully they can be reusable components in other real IDEs like Eclipse, NetBeans, VisualStudio, UNA, etc. I'm not personally going to support other IDEs directly, but rather I'm going to have to rely on external help for that that work. Eclipse has a leg up because FWT is already ported to SWT, but hopefully it will port to Swing easily too. I don't particularly want to favor or bless one IDE. More importantly I'm not really an IDE user myself, so I'll be designing Flux as my own "un-IDE" which I plan to use to replace TextPad (my current editor of choice).

Like most of Fan, expect Flux to adhere to a minimalist design philosophy. Its goal is provide simple, ready to use developer tools out of the box. But more importantly it will serve as the test bed for the components to be plugged into real IDEs.

Overall, sounds good. Here are my main concerns with browsers:

1. Backward/forward works well when browsing through related content. New applications/contexts should always be in new tabs. But I don't have a 100% recommendation of how to accomplish good default behavior.
2. Browser security is broken. We complain when our media players spy on us, but every unsigned random web page out there can do tons of spying without the browsers telling us it's really even going on. Communication even with the host server should be disallowed except after unlocking an app from the sandbox. Not sure this applies to immediate Flux needs, however.

If you are replacing TextPad, does that mean we get lightweight "mark line" features? I just love that in TextPad. I just wish TextPad had nice incremental search. (And a few other differences here and there, I guess.)

TextPad would also be nicer with hippy completion.

Anyway, concerning my prior concern with back/forward buttons, maybe the registered view handler could best decide whether to stay in tab or open a new tab (or send an "open" event to an existing tab with that kind of view, such as how desktop apps work).

New applications/contexts should always be in new tabs.

I think that is best left to the user to decide (click for in-place, ctrl-click for new tab, etc).

I think that is best left to the user to decide (click for in-place, ctrl-click for new tab, etc).

That doesn't allow for the "send open event" feature, in case that's deemed of value. Also, it adds burden to me as a user to figure out first whether or not I want it in a new tab.

But maybe I agree that adding the ability to override the built-in behavior would be nice.

I changed my mind. If you are serious enough about making UIs resource/REST-oriented, then normal browser behavior should be okay. Just that lots of the current web isn't serious about this, where instead you get URIs-as-apps. (I'd give it 50/50 maybe?)

In Eclipse, you get both views (app-ish) vs. editors (resource-oriented) as distinct concepts. I don't think that's necessary (and too much of Eclipse is too complicated), but it's an interesting alternative for reference.

A browser-style editor is an interesting idea, and may fit well with the Fan mapping to URIs. Look forward to seeing it!

Could see it in UNA, too, depending on the license and the availability of a Swing implementation of FWT.

I use a browser-style editor for my day job, and I find it be quite natural for navigation. Most editors just keep opening tabs everytime I open a file, then after about about 20 tabs, I close them all and start over - drives me nuts!

Flux will be be licensed with the AFL 3.0 just like rest of Fan, so quite friendly terms for creating collective and derivative works.

I use the file list in TextPad rather than tabs. And Eclipse and Firefox have lists (in addition to tabs). Still, even that can grow too much. But I highly recommend the tab list feature of Firefox/Eclipse.

As for more novelty, I like the idea of persistent undo/redo where manually "saving" a file becomes more of a "commit" notion. That way, if you navigate away and come back, or even if you close down, you can still find the unsaved state of your files. But you still need to manually save before it takes effect on the actual file in question. I'm not 100% sure on it, but I think it might provide more flexibility when browsing around between files while editing them.