Help Embed Firefox in SL

Bear in mind the risks - the reason people can't open web browsers comfortably when SL is running is because the Gecko engine that powers Firefox is very, very complex and uses a lot of memory/CPU time as a result. In the short term this might end up hurting performance a bit (but the gains will be well worth it).

Have you guys ever tried to lay out non-trivial HTML for a fixed size display?

HTML is really really really badly designed for the kinds of things we do in SL.

Postscript on a prim, that I could see, though even Postscript is overkill... but it's FAR better suited to the medium.
How about if you could call llXYText(string text, integer face, integer font, vector position, float size, vector color, float alpha);?

Konfabulator is a perfect example of why HTML on a prim is a bad idea.

Konfabulator doesn't use HTML. At all. Anywhere.

Dashboard does.

Dashboard is WAY more CPU-intensive than Konfabulator as a result. That's probably why Dashboard got stuck on its own pane, because you don't want to be running Dashboard widgets all the time. I have tried that, using the Amnesty Widget Browser, and my poor Mac mini was very unhappy.

Konfabulator is XML, but the XML layout is strictly coordinate driven placing of images and text. Just adding a native XYText-like tool that let you layer nicely rendered text on a prim face would pretty much close the gap between SL and Konfabulator.

Tried uBroswer the other day. It was really, really cool and stable. If pointless as a standalone app right now.

I'd be happy with just Flash support for now, to be honest.

What I want to know, is will this stuff be 'static' on the prim, a per-parcel thing, will people see the pages differently or will it be somewhat collaborative? Will I be able to carry DIGG in my pocket?

That's what I want really, really want to know

HTML will be overkill for some of the things it's going to be used for. However it should make it simpler to make applications with large backend databases, or things that are a bit too CPU intensive to run on a sim. This means that relatively(compared to most LSL scripts) CPU intensive konfabulator-like widgets could be made to run the bulk of the code on external servers. There's also lots of content on the web that could be useful in to have in SL. Instead of having to recreate many things wholly, embedded HTML gives us a layer of backward compatibility.

For now I think this has to do, there might be better ways of doing things in the future, but not likely until quite a while after HTML has been implemented, so it's good to have something in the meantime. I think it's likely that we'll have to wait until Mono has been implemented in the client to get a good alternative. Implementing Mono for client-side scripting was mentioned in this townhall. But it seems it's not planned until some time after its serverside implementation.

Will html show up on prims with a gray loading texture that lasts for two or three minutes or longer at times, or will it show up at a tolerable speed/

I suspect it'll be a bit like streaming video only interactive. I still say supporting Flash is a bad idea due to processing constraints, but if they insist on supporting it for completeness so be it.

I look forward to having Wikipedia on my HUD at all times though, and having the LSL wiki available on a prim nearby wouldn't be bad either.

Just to throw my opinion into the hat.

I'm very excited about this, I have seen this in Other MMOs (There / Croquet / Etc) its an excellent way to spread information, far better than a notecard or static image. soon we'll have truly interactice machines, think InfoNet but better. Like the person above me said as well, with tight LSL interaction, we can take a huge load off the server and put it on our own network.

If your running your own Sim, you probably already have or can handle running your own Web Server as well.

Management duties, distribution of funds and information automatically, better storefronts, heck even better games. I know I have some flash games I would like to bring in game.

I would say, take your time with it and get it working properly, it doesn't need to be perfect, nothing is, but lets start with something decent so we can all start working on it, and learning what we can do with it from the start. Then work on fixing any problems, because once its released, thats all you'll be doing anyway, additinal features aren't likely to come for a good while, thats true with any project.

I wonder if Callum gets to keep the donations made through the Contact page in spite of the fact that uBrowser is an offical Linden Lab project...

I disagree with wanting to bring Flash games into SL. What's the point of running SL at all then, when it's basically just a browser with a VERY high overhead? IRC and a web browser could give you all the chatting you want while you play the game without nearly as much system resources being lost. Flash as an extention of in game resources (better HUD displays for instance, or vastly superior dialog forms) I agree with, as they are a means of improving what's possible in game. You can make a proper HP gauge for a game, a decent looking inventory (ala Diablo or Dungeon Siege). But in the end it should be a tool for improving SL interaction not replacing it.

What would be really cool would to be have 3D objects associated with wikipedia articles, so that for example if you went to a wikipedia article about a car, you would also get a 3d model of the car. A possible way I imagine this could be done is by making a database where people could upload 3D objects in TLML format, made by the TLML exporter, that would be associated with a specific wikipedia article, and make a TLML/HTML based wikipedia HUD.

If the kind of interaction where you can figure out what stuff is loaded into a web page with LSL will exist, somehow (like reading javascript page variables, or PHP links, or more importantly (and basically) reading what URL is being loaded), then I see that kind of thing happening on a small scale via InfoNet. Loaded pages will be able to recall and spawn any object from a centralized database related to the page you're viewing.

Given my experience with the way stuff gets used far beyond its original intentions, I'd say "almost all" rather than "some".
But most of THOSE things on the web are moving away from HTML to AJAX, using a simple scripting language on the client to request and render data from the server.

And that's, again, more like having an LSL script using local direct rendering communicating with a server.

Having uBrowser for help documents, and putting HTML in notecards that would be viewed in uBrowser, sure, but for general *ML on a prim... we'd be MUCH better off with llXYText and LSL-initiated XMLRPC.

This would be about a zillion times easier for LL to implement than HTML on a prim. I'll bet that if I had access to the source I could have a version working in a month, by myself, even including getting up to speed on the SL code base. Someone like Runitai Linden could knock it out over the easter weekend.

Well, I think that would be a bit too limited. If additionaly there was something like llPutPixel(integer side, vector color, float x, float y) to draw on prims, that would mostly suffice though.

Hopefully, ubrowser will support SVG from a notecard. That would allow drawing to a prim.

I just did some testing with opening lots of windows at once with both SVG and canvas animations, and on my computer it actually performs relatively well for basic 2d animations even with more than 20 open at the same time. 3D walker gets pretty slow if I run more than one of it at once though, at least the textured version.

Anyone tried opening lots of SVGs and stuff to check performance in uBrowser? I haven't been able to myself since it constantly crashes on my computer.

All I got to say is... FireFox?? No thanks!! I know people who use it to mess up forums and other software, ruining the enjoyment of the other users.

Firefox is just a browser like any other. I could use lynx (a text only browser) to screw around on forums and make life hell for others. Firefox however has a small memory footprint compared to most other browsers (netscape, opera, IE (yes, IE is a two part system. MOST of it is loaded into windows so it seems faster, but that's because it's already loaded when windows starts up)) AND it's developed cross platform (Firefox for windows, linux, and mac. Coincidentally every platform SL is on or being worked on). Firefox itself is fast, stable, and extendable via plugins. Not to mention it's one of the few browsers out there that actually conforms to w3 regulations for tags.

[smartass]I'm sure there are people using the SL software to cause grief for others, too. I notice a distinct lack of cancelation on your account, Selene...[/smartass]

Have you any idea how slow that would be? Plus, it would require creating new texture bitmaps for updates, rather than just passing "font,color,size,position,text" down.

Not to mention, that's far beyond what HTML on a prim would give you.

Yeah, that's where client-side Mono comes in. I think doing it with client-side scripting might be fast enough. I don't think we'll see that anytime soon though. I belive both SVG and canvas will be supported on HTML-on-a-prim though, so it will already bring some capabilities for scripting textures. I'm not sure, but I'm guessing that making SVG that's read from a notecard and not updated very often, for example only when clicking on something, shouldn't be too slow if it's not overused.

Sounds like the recipe for Unicorn Stew. First, catch your Unicorn...

Look, all this stuff sounds really nifty, but just being able to open an HTML *notecard*, not HTML on a prim, would cover most people's requirements, and a Linden-supported client-side-rendered XYText would handle the rest so much more efficiently it's insane to consider HTML on a prim a good idea.

Nah, I'll just genetically engineer a horse instead. Mmm unicorn stew.

A link to the blog of DougT, one of Cory's partners in making ubrowser:
http://weblogs.mozillazine.org/dougt/archives/009715.html