web page on a prim is here!

with khtml2png and using the parcel media you can now get a web page on a prim!

check it out:

http://www.babysimon.co.uk/khtml2png/index.html

Now, if only we can get LL to have multiple media urls per parcel, that'd be very cool!

heh, nice find,
I finished the code of text based browser using the quicktime plugin yesterday and it even supports url clicking (well will do once we can change the parcel url in lsl)
Adam Z has done a nice LSL browser that supports text and images, aswell as urls, text boxes and menu's.
If you could mix what you found with lsl that supports those interactive functions it would rock

Your infatuation with the legacy metaverse does not cease to astound me

Could we download things off of the web pages? Because that would be ultra cool

But...do we want or need "web page on a prim"?

Didn't I already have "web page on a page minimizer" lol?

I could see it might have its advantages, and could actually get to be quite the nuisance in SL (an object can now be welded to land, somebody welds a for-sale sign with their website to the land, and it takes a while for you to unweld it and stop being dragged to the Internet every time you click on it).

But...when they did that fun thing, did they also fix that problem whereby when you minimize the page, and go to another window, and then come back, you lag really badly? There's some kind of problem where minimizing the game in a window like that causes you sometimes to freeze or lag so badly you must relog.

I have that problem currently, but when using the preview grid, I was pleasantly suprised to see that I could minimize SL, pull up Firefox, browse, and return to SL with almost no lag. Lather rinse repeat, still quick and easy. Hopefully its not due to simply being on the preview grid, and its something we can look forward to with the full-fledged release of 1.6.

I think this is just good old-fashioned memory thrashing from context switching. You see this with other really memory-intensive applications, as well -- the system takes one application out to virtual memory to swap in the other, then it takes a long time to swap it back in. I expect having a couple of GB of RAM fixes the problem, but obviously this isn't a practical solution for everyone.

I don't know that the web page-to-image thing does much for me, but I'd love to have my whole system desktop embedded in prims, at least if I had a system fast enough to make it usable. I'd love to have a virtual workspace where I could work on most anything directly inside SL so that the primary computer interface is SL, not the Windows GUI.

Having said that, I think that this is a ways off.

you remind me of me thinking "do i really want or need these laggy windows?" aren't i intelligent enough to use my computer as an effective tool without needing for it to operate two applications at a time?"

for a long time i ran windows when i needed to copy and paste or browse the web; then i'd shut it down and return to a text prompt to do the real work.

Yes! These web page on a prim implementations sound like the beginning of one of my most-wanted features (in-world web browsing)... I am very excited.

One thing I was wondering is: how hard would it be for LL to add support for "link textures" that are like symlinks or windows shortcuts, which would point toward a URL?

Something like this could allow multiple remotely-loaded textures on each parcel, and solve the parcel-chopping hack (hah) people are likely to implement to work around 1-media-link-per-parcel.

I think that displaying a Webpage On a Prim (WOP) is a step backwards... however I think enabling streaming video in SL is a step forwards. Unfortunately, the step forward allows for the step backwards.

I don't see see the gain a person gets in seeing a WOP. You will not be able to click and browse that WOP or interact with it in any way. I guess you could script individual interface prims, one for each clickable UI button on a website. Then, refresh the streamed WOP after each click. However, this would be as efficient as going out your back door to get to the mailbox next to your front door.

My opinion is that we should advance the possibilities by not displaying a simple WOP, but by displaying the information from a website in new 3D ways.

WOP will have some benefits, though limited... For instance, sales vendors could display catalog-style product pages, saving a L$10 texture upload. However, only one-per parcel. Malls would need to subdivide land into 100's of parcels, and enable land-change rights to the vendors for the purpose of changing WOPs. Not to mention, users would have to stand on the correct parcel to see the intended stream.

The solution is to not minimize SL. You can easily open your browser on top of SL. Then, use the task bar to swap between windows. This also keeps you from AFK-mode, whether good or bad, but it certainly prevents the swap slowdown.

Yeah, we really need multiple texture/media support per parcel.

But we need llSetMediaUrl first and foremost.

Excellent, blaze. Added to my sigline link on the SL Tiki.

I think we need a seperate call/ability to grab non-animated sources. While loading a hoard of mpeg4's at once on prims would drop even the most robust machines to it's knees, I think a compromise would be to have a function call like llLoadRemoteTexture(string URL). In theory, it should not take more strain to grab a texture from an external source opposed to SL's asset server (and if anything, it would decrease the load on SL's server, allowing cleaner teleports and whatnot). Heck, even restrict it to only load JPEG2000 (which I believe is SL's internal picture format). With this restricted form of offworld loading, it would allow nifty "simple" tasks like text on prims, dynamic updating pictures, etc. It shoudl be simple enough to allow multiple images to be streamed and be disconnected from being land locked.

As far as a web browser (which I did do a "simple" text based one when email started working), and the tools mentioned, please note that I don't believe they will work on most server hosts, since they are requiring access to X... Wonder if there is a solution that actual does virtual rendering....

instead of having two clients, one for SL and one for the WWW (that can have links to each other) and the option of turning one off, i can have all the functionality of both all in one client, always ready at my fingertips! browsing the web in RL is disorienting while playing SL. who am i without my avatar?

LL, please fix vehicles and ghosts first!

the simple fact is that the second life toolset doesn't afford us persistant data storage or any efficient method to search and dynamically present information. however, those types of internet-based mechanisms do exist.

it would be a collasal waste of time for ll to reproduce that technology for second life and for us to train ourselves to use it. a much more sensible approach is for them to provide a way for us to utilize existing internet tools and import the results to an inworld presentation tool.

the question boils down to whether ll will continue catering to the larger, short-term income producing game population or will spend some time catering to the smaller long-term income producing developer group. i almost typed "deveoper core" but y'alls monitors are sticky enough already. they're still convinced that they can do, and are doing, both. we'll have to wait until some competition rears its capitalistic head to know for sure.