Firestorm Dynamic User Interface (DUI): it’s a real prototype

firestorm-logoOn April 1st, the Firestorm team released and April Fools video in the spirit of their 2013 “Firestorm Mobile” hoax.

As fun it was, there was a secret within the joke which many – including me – missed at the first watching of the video, largely because we didn’t follow the suggestion and manually type the URL at the end of the video into a web browser.

For those who may have missed things, and to provide a frame of reference, I’m including the video in this post as well.

Jessica Lyon contacted me just after I’d published a post on the Firestorm and Catznip April Fools and gave me a proper “Gotcha!” So, having taken the time to stay quiet on the matter, as Jessica requested (and in order to go wipe the egg from my face!), I’m here to say, as many Firestorm users have been poking me about over the last 24-hours, that the Firestorm Dynamic User Interface isn’t a joke. It’s here. I’m using it. What’s more the Firestorm team have now blogged to confirm it.

The viewer,Firestorm is available for download for Windows only, and will run on both Second Life and OpenSim.

It really isn't an April Fools - Firestorm really does allow you to move some floaters outside of the viewer window!
It really isn’t an April Fools – Firestorm really does allow you to move some floaters outside of the viewer window!

Now, the viewer – as Jessica and the team wish to express loud and clear – isn’t the finished article. It’s currently experimental, and as such, subject to unpredictable behaviour. It is not recommended for use as a primary viewer.

There are also some other points to note:

  • Not all of the floaters in the viewer may be capable of being pulled out of the viewer window. Those that can appear to float “above” the viewer window, rather than “in” it
  • Not all of thefloaters work smoothly at this time, and may be subject to jumping and / or, flickering, and options on menus associated with them may not be accessible as a result. There may be other issues, such as:
    • You cannot drag / drop items from the Inventory floater in-world
    • Conversations in the communications floater tabs may not scroll soothly
  • Floaters outside of the viewer window cannot be resizedYou cannot resize those floaters which can be moved outside of the viewer window
  • Torn-off menus cannot as yet be floated
The conversations floater can be pulled out of the viewer - but if you detach a specific IM tab, it will bounce back into the viewer window and cannot currently be dragged back out
The conversations floater can be pulled out of the viewer – but if you detach a specific IM tab, it will bounce back into the viewer window and cannot currently be dragged back out

Discussing the viewer with me after pointing out I’d been had with the April Fools video, Jessica said:

The intention is that we want to release this code in the hopes that ALL open-source developers out there, TPVs included, will pick it up. fix it, improve it, expand its capability and most importantly SHARE it with one another. It is my hope that this may become a catalyst to renew interest in viewer development among inactive developers and that ultimately this will open a whole new realm of possibilities for SL viewer technology moving forward.

We will not be assigning the gentleman’s agreement on this… it’s too important to make this about credit. I don’t care who releases it first as long as the code is shared equally. We will also work on improving it, but I think this should be a community effort.

Having detachable floaters like this has been one of the Holy Grails for the SL viewer, and has long, and oft been requested. However, the Lab has generally taken the view that to get something like this working would take a considerable amount of effort. The Firestorm’s team work is therefore very much pre-proof-of-concept, as their blog post on the matter indicates:

Firestorm DUI is little more than a very early proof of concept that a dynamic user interface is in fact possible with Virtual World viewers … our very own Nicky Dasmijn managed to come up with this in a relatively short amount of time, and we hope that it will translate to this functionality being available in a reasonable amount of time …

So, if you haven’t already taken it for a test-drive, and remembering the Firestorm DUI isn’t a release, and there may be issues with using it, and that it is not supported by Firestorm at this point in time. So again, when using it, please do not use it as your primary viewer.

Please don’t report any issues with the viewer here; I’m not a part of the Firestorm team, and cannot help you. As mentioned above, the DUI viewer is currently unsupported!

25 thoughts on “Firestorm Dynamic User Interface (DUI): it’s a real prototype

  1. This one’s a stand up and applaud moment.
    (Maybe the SL Viewer will take notice of this and Quick Preferences?)


    PS: So, where’s the donation jar to pay for Jess’ higher vehicle insurance premiums?


    1. It is. Admittedly, I had to wipe the egg off my face yesterday when Jess called me up and said, “Gotcha!”, but I did applaud!


    1. It really has been that has been discussed over and over down the years – hence why Jess and I both use the term “Holy Grail”.

      I got the chance to ask Esbee Linden (and other Lindens) about it during the 2011 SLCC, when there was considerable work being done on the viewer UI by the Lab, and even then the feeling was that it would be too labour-intensive and too big a code refactoring to be comfortably achieved.

      Just goes to show what can be done when will is bent on something; here’s hoping the DUI is just the start!


    1. Watch the video, it also fits with a joke within it :).

      It also sits with LL’s own past acronyms, FUI (Flexible User Interface) and CHUI (Communications Hub User Interface).

      So now, we have Foo-ee, Chew-eee and Dew-ee. Which, when pronounced like that, admittedly sound like they should be in a Donald Duck cartoon! 🙂 .


  2. Now, it’s time for LL to use this feature when it’s perfected, along with Firestorm’s smaller (and resizable) camera controls, Quick Prefs and Phototools…


  3. Soon we will have a repository set up for those who wish to start compiling this viewer to make changes and improvements to the code. It will be found in the same place as the rest of our repositories.


    1. Thanks, Tank. when it is up, let me have the link and I’ll add it here as an addendum.


  4. Can I hope that the anaglyphic stereo feature the Lab used for it’s April Fool is as real as this is?

    They’re both technologies which have been made to work in other contexts.

    I can see how this could lead to an un-cluttered view, a bit smaller than currently, with sub-windows doing what might have been possible with the sidebar idea of the past. I can see how I could use it, even with just one monitor. And a reduced-size main window, without the hassles of overlaid sub-windows, as a smaller simple rectangle, is something that could give a higher frame rate.

    But I am wondering when Oz Linden is going to snarl “Common user experience.”


    1. LL is actually interested to some extent in it, but I don’t have any details other than that.


    2. Anaglyph … I’d like to see LL follow Dave Rowe’s lead where stereo 3D is concerned.

      Shared User Experience – neither stereo viewing or fliddling with the UI come anywhere near it. Leave us not forget the vast majority of what TPVs do is to the UI and adding capabilities which do not lead to thinks like *other* people seeing you walking around with a trail of attachments hanging out of your rear end because you happen to be using viewer X – which is what the SUE was all about stopping.


  5. For PCs only — I get that since a pre – alpha test viewer of a very cool feature but wonder if this is the beginning of the end for people who use Apples in second life. Less and less support .


    1. The Apple situation is unfortunate, and hopefully the Lab is looking into ways and means of addressing Cocoa (and other) problems more head-on where and when they can, and allowing for different OS versions. But I wouldn’t point to this signifying anything other than the fact the the person who sat down and played with the code (Nicky) and provided what can be seen in this experimental version is a Windows developer.


  6. So if im right,i can have 2 (my new vga supports up to 8 ,lol) monitors and on one the chat windows and all and on another just a clean full screen view of the scenario?
    That can be really great, not for me unfortunately as i only use one monitor, just hope also Firestorm will address some bugs more important to the reg user base as well.


    1. If it can be proven to work, yes. Right now, this is very pre-proof-of-concept. There is much still to be proven in terms of getting anything which is really workable – and it may yet prove too hard to really achieve. But the code is there for people to poke at and see what works and what doesn’t, or whether it’s about as far as things can be taken without a massive overhaul of the entire viewer code.


    1. Might be worth waiting a little longer! there’s a way to go before it, um, works as required! :).


  7. Now that i have a 3 giga ram vga, if some manages to develop a viewer that allows to set up more 512mg vga use for sl , that would be my selfish (and of many that have last generation vga’s as well.) wish.


      1. Is it possible, though, for the viewer to detect how much GPU RAM you have at your disposal and set things accordingly? I know this would perhaps be lost on people whose GPUs have 512MB of RAM or less, but for people with modern, midrange or high(ish)-end GPUs that have upwards of 2GB RAM this could probably prove beneficial. Also – and this is a thorny issue… Would it be possible for the viewer, upon log-off, to somehow tell the GPU to clear its texture memory?


        1. The viewer already does all of this already. However, do to inefficiencies in the past with how the viewer can handle texture memory, it was limited to 512MB for performance reasons (back in the V1 days, and LL never updated it sense). LL is in the process of making some updates to remove the need for the cumbersome GPU table which needs to be updated whenever a new GPU is released and as part of this, they are allowing for the 4GB texture memory selection and some other improvements. The 4GB cap may change by the time the code reaches release based on crash rates or other factors.


          1. Ugh, I messed up. Anyway, next month I’m getting a computer featuring a GPU with 4GB of dedicated RAM (an Asus based on the Nvidia GTX 770) and being saddled with the 512MB cap would be undesirable.


Comments are closed.