Difference between revisions of "Talk:User Interface Roadmap"
Jump to navigation
Jump to search
m (signature) |
|||
Line 31: | Line 31: | ||
Just a heads up. | Just a heads up. [[User:Saijanai Kuhn|Saijanai]] 22:22, 4 September 2007 (PDT) |
Revision as of 22:22, 4 September 2007
prioritization of roadmap is off, I think
The VERY FIRST THING you guys need to work on is part 2 of step #4,
LLViewerApp#Phase 2
- •Clean up the client initialization, update, and render loops so that individual pieces (e.g. 3D rendering) can be de-prioritized or disabled
- •Create a sample UI only client
Until you have a simple "hello world" window available, prototyping GUI classes and GUI elements will be quite bearish, to say the least.
Certainly, it is for me, and no-one could use the SL framework for creating cross-platform tools for SL until such a thing is available and a plug-in API will be much easier to implement if the tool/plugin is using the same GUI framework as the client it is plugging into. Saijanai 12:19, 4 September 2007 (PDT)
- User:Steve Linden While we understand that this is highly desired by a lot of extrnal devs, we have to prioritize providing a better experience for the majority of the residents. This means giving greater priority to providing our UI designers with better tools for improving the UI.
- But this is open source. Some of us want to HELP you do this "improving stuff," and the best way you can help us help you, is to provide a standalone "hello world" type window along the lines of the simple floater window evoked by cmd-T at the log-in screen, but without the requirement that it reach out to the internet for that webpage. This would allow us to prototype the GUIs for our client modifications in a more timely matter, and I gotta think it would help Linden Labs developers prototype NEW modifications much faster. PLEASE rethink the priority on this. Its something that you will need to do many times as you modify the user interface, and learning to do it now, will help give insight into what needs to be changed so that each time you do it, it will be an easier task. Saijanai 20:34, 4 September 2007 (PDT)
- I found a workaround that you guys may or may not be aware of. I posted this in sldev and I'm posting it here as an FYI if you weren't already aware of it:
- OK, A trick Benjamin turned me onto is to type cmd/cntrl-t at the login screen. This evokes a floater window that is defined by floater_test.xml, which allows you to prototype GIU-related stuff without logging into the server.
- I found a workaround that you guys may or may not be aware of. I posted this in sldev and I'm posting it here as an FYI if you weren't already aware of it:
- But this is open source. Some of us want to HELP you do this "improving stuff," and the best way you can help us help you, is to provide a standalone "hello world" type window along the lines of the simple floater window evoked by cmd-T at the log-in screen, but without the requirement that it reach out to the internet for that webpage. This would allow us to prototype the GUIs for our client modifications in a more timely matter, and I gotta think it would help Linden Labs developers prototype NEW modifications much faster. PLEASE rethink the priority on this. Its something that you will need to do many times as you modify the user interface, and learning to do it now, will help give insight into what needs to be changed so that each time you do it, it will be an easier task. Saijanai 20:34, 4 September 2007 (PDT)
- One problem though: The login process still takes you out to the internet and tries to grab a web-page, which makes the turnaround for GUI testing rather slow, even still.
- I browsed around and found that if you change a 1 to a zero in this line:
- \#define LL_LIBXUL_ENABLED 0
- in llpreprocessor.h, line 56, the compiler will bypass compiling the browser code on the Mac client and eventually set mHtmlAvailable = FALSE; in the login floater.
- This is a good thing, if you're trying to shorten the cycle for compiling and testing GUI and related code, and don't need access to the browser or the client, at least in the beginning stages because it brings the login window much closer to my greatly desired hello world GUI prototyping window. The drawback is that the constant is defined in the precompiled header, so changing it requires a recompile of all sources which is itself rather slow. The best bet seems to be to define two builds, I guess. One with the constant defined as 0 for GUI testing, and one with the constant defined as 1 for full-blown client testing, including the browser. The client will run without the browser code defined, but I didn't test for stability if you try to use the browser in-world.
Just a heads up. Saijanai 22:22, 4 September 2007 (PDT)