Lirusaito 47cbaeed23 XML-Driven floater feature (and documentation)
Changes:
Adds LLUICtrlFactory::getBuiltFloater() to return LLFloater* when a floater has been built.
In llviewermenu.cpp's LLShowFloater::handleEvent():
Return early if the floater_name is empty,
otherwise if no anticipated floater is found, build one,
unless one of the same name is already built, then bring it to focus.



Documentation:
In order to add simple codeless floaters, a general understanding of our XMLs is necessary...
A simple codeless floater can be a few things, perhaps not limited to: media browsers, settings controls, and holders for inventory_panels.

So how do you make them conform to the codeless standard?
For the purpose of these examples, my floater file will always be floater_name.xml
Let's start with a shortened xml menu entry:
<menu_item_call label="Name!" name="name">
  <on_click function="ShowFloater" userdata="floater_name.xml"/>
</menu_item_call>
Alright, that wasn't so hard, just remember the key in this is ShowFloater is the function and userdata is the filename.

The next part is the actual floater, which isn't so different from making a complex floater..
There are two ways to do this, depending upon desired behavior:

The first behavior is to have only one of the floater open at a time, the following short xml exemplifies this:
<floater name="floater_name.xml" title="Name!"/>
Having a floater with this behavior will cause the menu entry to bring it into focus.

The other behavior is to allow more than one of the floater open at a time:
<floater name="name" title="Name!"/>
In this case, the menu entry will spawn a new version of the floater with every click, regardless of previous ones existing.

Granted, these short <floater/>'s probably aren't but examples and will not likely stand alone.
2013-01-30 14:07:59 -05:00
2012-09-08 02:03:07 -04:00
2012-08-21 19:17:45 +02:00

00000000011111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
       ______ ___ __   _  _____ _    _       ______  _____ ___ _____ _   _
       |_____  |  | \  | |  ___ |    | |     |____| |____/  |    |    \_/  
       _____| _|_ |  \_| |____| |____| |____ |    | |   \_ _|_   |     |   
                                               _  _ _ ____ _  _ ____ ____
                                                \/  | |=== |/\| |=== |--<

Sin-gu-la-ri-ty (noun) - a distinctive feature, a uniqueness; a point at which
continuity breaks up; a point in history at which machine becomes smarter than 
humanity and/or fuses with it indivisively; or simply a cool sounding word with 
the initials S.G. in it :)
	
Singularity Viewer is a SecondLife(tm) protocol compatible client application.
It can be used to access SecondLife services as well as a number of others such
as those based upon the OpenSim platform.

Singulariy is maintained by a small group of volunteers who can be contacted
both, in-world (SingularityViewer group) as well on IRC (#SingularityViewer
@ FreeNode). Bug requests and features requests can be submitted through our
Issue Tracker (http://code.google.com/p/singularity-viewer/issues/list or from
the viewer menu: Help --> Bug Reporting --> Singularity Issue Tracker...)


As this Readme grows out of date, please refer to 

	http://www.singularityviewer.org/about


00000000011111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890

History

The Singularity viewer was started by Siana Gearz in November 2010 by forking it
from the Ascent Viewer, by Balseraph Software Group, which in turn was based upon
source code modified from the snowglobe source code released by Linden Lab.

Description
An experimental Snowglobe 1.5 based Second Life Viewer focusing on performance, but also including all the usual conveniences and RLVa.
Readme 145 MiB
Languages
C++ 84.1%
Rez 7.6%
C 2.6%
SQLPL 1.6%
GLSL 1.6%
Other 2.3%