From 7d48bd9a65bc5fe92ede80ea7fc49e7526d07c7a Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Sat, 2 Feb 2013 21:22:58 +1000 Subject: Rearrange ClientHamr README's into better bits. --- ClientHamr/GuiLua/README | 60 ++++++++++++++++- ClientHamr/extantz/README | 160 ++------------------------------------------ ClientHamr/extantz/skin.txt | 37 ---------- ClientHamr/woMan/README | 148 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 213 insertions(+), 192 deletions(-) delete mode 100644 ClientHamr/extantz/skin.txt create mode 100644 ClientHamr/woMan/README (limited to 'ClientHamr') diff --git a/ClientHamr/GuiLua/README b/ClientHamr/GuiLua/README index 70f67b8..8c798c7 100644 --- a/ClientHamr/GuiLua/README +++ b/ClientHamr/GuiLua/README @@ -1,2 +1,58 @@ -GuiLua is basically a redo of my ancient Java based matrix-RAD system to -Lua and EFL. +GuiLua is basically a redo of my ancient Java based matrix-RAD system, +but using Lua and EFL. The ultimate goal is for the various ClientHamr +parts to be able to either host their own UI, or have it hosted in the +in world 3D window. Matrix-RAD's ability to run either server or client +side, with no change to the code, is great for this sort of thing. If I +can manage the ability to "tear off" windows, in other words, pull them +out of the 3D window to be real windows, then that's something people +have been asking for from LL forever. + + +old notes +--------- + +Might be good to allow Lua scripting. One way of dealing with viewer +prefs perhaps? Certainly think about Lua for the UI, and a built in +editor, etc. ala skang. All the fancy stuff like development and such +should be kept in some sort of module, so as not to bloat the main +proggy. See if it's possible to disable the Emerald/Phoenix/Firestorm +LSL bridge when connecting to OpenSim. See if we can do it from Lua, +with some sort of generic Lua system for munging things. + + +skang vs edje vs LL shit +------------------------ + +EDJE +Verbose, complex. +Used to place and decorate widget parts. +Can be used to place entire widgets through externals and swallows. +Basic parts relative to each other. +Signals and messages. +Embryo scripts. +Lua scripts (sandboxed). + + +SKANG +Tight, simple. +Used to place widgets, and describe actions. +Can include some really basic scripting. +Widgets in a fixed position, but included stuff for relative placement in the TODO. +Automated associations between widget name and variable (and method?) via introspection. +Actions. +Looks (could easily be extended to edje groups). +Extensible. +Can be used to pass values around. + + +LL SHIT +Verbose, even worse, XML, more crap than is needed. +Menus. +Windows with widgets relative to each other. + Basically nested rectangles. +Manual association of widgets to methods. +Can include tool tip string, enabled, visible, hover cursor, bounding rectangle?, mouse opaque?, tab groups, font (name, size, style, and alignment). + More stuff, typically hidden in the OO somewhere. sigh +Generally uses fixed image and colour names, which skins overide. +Skins can also overide the XML files. +Translations provide override XML files that need only override the text bits. diff --git a/ClientHamr/extantz/README b/ClientHamr/extantz/README index b7b4de4..5fb1d5f 100644 --- a/ClientHamr/extantz/README +++ b/ClientHamr/extantz/README @@ -1,19 +1,7 @@ -Extantz is a front end to virtual world viewers, mostly of the SL -(Second Life) variety since that's my focus. Most SL style virtual -world viewers can be invoked with options to start them logging on, and -skipping the login screen. So this project aims to be that login -screen, doing all the things that can be done from the meta-impy login -screen, plus more. Once the user hits the login button, extantz figures -out what parameters to pass to what viewer, then starts it up and gets -out of the way. Following the ClientHamr philosophy of breaking the -viewer up into modules that do simpler tasks, and do them well. So that -means that meta-impy will eventually loose it's login screen, to be -replaced by extantz. - -Also, during this experimental phase of development, this will be a test -bed for all the GUI stuff. This could end up being the front end for -the entire system, but still having the various bits split off into -separate programs. +Extantz is the main virtual world front end. Also, during this +experimental phase of development, this will be a test bed for all the +GUI stuff. Eventually lots of it will be split off to separate +programs. Extantz is a made up word. The challenge was to find a word beginning with E, is as traditional with EFL (Enlightenment Foundation Library) @@ -31,140 +19,6 @@ So I hope to invoke thoughts of a volume that exists and stands out. In other words, virtual worlds. Meh, I'm not that artsy, it needed a name. lol -Extantz starts off looking like any other viewers login screen, showing -the login page of the default, or last visited grid, a small menu at the -top with the usual functions, and the usual login buttons at the bottom. -Added to that will be a better grid manager, with proper user -management, suitable for people with more than one account per grid. -The user will have the ability to choose a virtual world viewer to be -the default, and even to associate a particular viewer with a particular -grid. This is useful, for instance, for grids that have their own -custom viewers, but the user wants to use a more generic viewer for all -the other grids. Or if the user wants to use one viewer for OpenSim -grids, but another for LL (Linden Labs) grids. Coz perhaps their chosen -viewer is not TPVP (Third Party Viewer Policy, an LL thing) compliant, -and LL are just more anal than the rest of the universe. - -The grid manager will also include some sort of search capability, as is -currently being discussed by various people in the OpenSim universe. -There might even be several search systems in place, so supporting -existing ones, and the ability to add more might be useful. Extantz -should be the only thing registered to handle hop:// and other such URLs -in whatever web browsers you are using. Though most viewers want to -register themselves, so tends to be that which ever one you started up -last, or first, gets that privilege. That's a whole can of worms, sane -policy and code should help. - -It might be useful to have extantz be able to download viewers, -including checking for updates and offering to download them. As well -as updates to common things like viewer tag definition files. - -Extantz, unlike the LL viewer code base, will be designed for relogging. -Once the viewer it starts quits (or crashes), extantz, which was still -running, can pop again and let the user relog, or log to some other -grid, or same grid as different a user, or even same grid as same user -with a different viewer. - -Viewers can be made extantz aware, like meta-impy will be (since it's -handing it's login screen functionality to extantz). A few more things -make sense to be added in this case. For instance, you might want to -have some or all of your LMs (LandMarks) be usable at the log in -screen, so you can log directly to them. The user might want the choice -when they HG (HyperGrid teleport) to actually start up a new viewer and -just login to the other grid instead (if they already have an account -there). While HGed to some new grid, the user might want to add that -grid to the extantz grid manager at a simple click of a button, perhaps -complete with an LM for their current position. The grid searching -capabilities mentioned earlier might be needed while in world. -Certainly the grid manager functions in meta-impy will be handled by -extantz, even if in world. - -In order to display the login page of a grid, which is a web page, a web -browser will be built into extantz. It could be used to display web -pages within an extantz aware viewer. Though perhaps not for MOAP -(Media On A Prim), unless extantz grows the ability to incorporate -itself into the viewers 3D landscape as part of a prim. Which is a good -idea, then meta-impy no longer needs a web browser. Though other things -in the viewer are implemented as web pages, and LL are moving more stuff -to the web. - -One of the things on the login screen is the menu option to start up the -preferences window and change the viewers preferences. Viewers use XML -files that not only store the preferences, but also a description of -them. The preferences window and it's various parts are also stored as -XML files. There is a bit missing that is in the viewer source code -that ties all of this together. So it might not be possible to do this -for all viewers. Extantz aware viewers can naturally provide the -missing bits to Extantz, even if not running, or even pass that entire -functionality to extantz, just like meta-impy will do. - -For the purposes of keeping resource usage low, it should be possible -for the user to configure extantz to go away when it starts a viewer. -Might be a good idea even for extantz aware viewers, that can start it -up again if it's functionality is needed while in world. Note this "go -away" means to stop running and free up any resources it was using; -which is different from the "gets out of the way" it usually does, still -running, just not on screen. - - -The problem with the web. -------------------------- - -At least that's the theory. In practice, a web browser takes up almost -one third of the viewer, and is only used for three things. Login -pages, simple built in browser window, and MOAP (Media On A Prim). For -the first two full blown web browsers are massive overkill. MOAP is not -supported by meta-impy yet anyway. - -WebKit is a pain to compile at the moment, for reasons I wont go into -right now. At the opposite of the spectrum is dillo, which is not quite -up to spec enough for login pages that have fancy stuff. There does not -appear to be any middle ground. So right now, I'll work on using random -web browsers as external windows. That will suffice for everything but -MOAP, which I can leave until later. Just discovered netsurf, a little -smaller than dillo, but perhaps better featured? Might be useful. - -The web is a bloated mess, so it's not surprising that a fully featured -web browser component like WebKit is also a bloated mess. - - -Design. -------- - -A thin window on the left. - -Menus across the top. -View tabs. - Grids Accounts Viewers Landmarks - -Grids tab is the grid manager, though you can also drill down / tree out -the accounts list per grid. - -Accounts shows accounts, though can drill down to grid list per account. -Also consider launching thin viewers, text only ones and such. The -account view is almost a natural for extending into a IM style thingy. - -Viewers lists the installed viewers, can install more, and allows -preferences editing. It can handle viewer installs, upgrades, even -compiling them from source. - -Landmarks manages LMs from viewers, or log in spots, or SLURLs etc. - -A user configurable web browser can open up to fill the right of the -screen. - -Might be good to allow Lua scripting. One way of dealing with viewer -prefs perhaps? Certainly think about Lua for the UI, and a built in -editor, etc. ala skang. All the fancy stuff like development and such -should be kept in some sort of module, so as not to bloat the main -proggy. See if it's possible to disable the Emerald/Phoenix/Firestorm -LSL bridge when connecting to OpenSim. See if we can do it from Lua, -with some sort of generic Lua system for munging things. - -Log file management features, including viewer stdout, check if only -Linux viewers do that. Including chat logs. - -Dillo and uzbl can insert themselves into the windows of others. Should -check that out. Netsurf is allegedly easy to port to things, might be -able to port it to EFL. - +Extantz will handle all the 3D rendering. The other parts can use nails +to control the world that is rendered, and GuiLua to present their UI +on top of the rendered world. diff --git a/ClientHamr/extantz/skin.txt b/ClientHamr/extantz/skin.txt deleted file mode 100644 index d627bb4..0000000 --- a/ClientHamr/extantz/skin.txt +++ /dev/null @@ -1,37 +0,0 @@ -skang vs edje vs LL shit. - - -EDJE -Verbose, complex. -Used to place and decorate widget parts. -Can be used to place entire widgets through externals and swallows. -Basic parts relative to each other. -Signals and messages. -Embryo scripts. -Lua scripts. - - -SKANG -Tight, simple. -Used to place widgets, and describe actions. -Can include some really basic scripting. -Widgets in a fixed position, but included stuff for relative placement in the TODO. -Automated associations between widget name and variable (and method?) via introspection. -Actions. -Looks (could easily be extended to edje groups). -Extensible. -Can be used to pass values around. - - -LL SHIT -Verbose, even worse, XML, more crap than is needed. -Menus. -Windows with widgets relative to each other. - Basically nested rectangles. -Manual association of widgets to methods. -Can include tool tip string, enabled, visible, hover cursor, bounding rectangle?, mouse opaque?, tab groups, font (name, size, style, and alignment). - More stuff, typically hidden in the OO somewhere. sigh -Generally uses fixed image and colour names, which skins overide. -Skins can also overide the XML files. -Translations provide override XML files that need only override the text bits. - diff --git a/ClientHamr/woMan/README b/ClientHamr/woMan/README new file mode 100644 index 0000000..1b3bbe0 --- /dev/null +++ b/ClientHamr/woMan/README @@ -0,0 +1,148 @@ +WoMan is a virtual world account and viewer manager, mostly of the SL +(Second Life) variety since that's my focus. Most SL style virtual +world viewers can be invoked with options to start them logging on, and +skipping the login screen. So this project aims to be that login +screen, doing all the things that can be done from the meta-impy login +screen, plus more. Once the user hits the login button, woMan figures +out what parameters to pass to what viewer, then starts it up and gets +out of the way. Following the ClientHamr philosophy of breaking the +viewer up into modules that do simpler tasks, and do them well. So that +means that meta-impy will eventually loose it's login screen, to be +replaced by woMan. + +WoMan starts off looking like any other viewers login screen, showing +the login page of the default, or last visited grid, a small menu at the +top with the usual functions, and the usual login buttons at the bottom. +Added to that will be a better grid manager, with proper user +management, suitable for people with more than one account per grid. +The user will have the ability to choose a virtual world viewer to be +the default, and even to associate a particular viewer with a particular +grid. This is useful, for instance, for grids that have their own +custom viewers, but the user wants to use a more generic viewer for all +the other grids. Or if the user wants to use one viewer for OpenSim +grids, but another for LL (Linden Labs) grids. Coz perhaps their chosen +viewer is not TPVP (Third Party Viewer Policy, an LL thing) compliant, +and LL are just more anal than the rest of the universe. + +NOTE: since I started this, LL in their *cough* infinite wisdom *cough*, +decided that support of OpenSIm was a Really Bad Thing, so their viewers +are no longer capable of dealing with other grids. LL have even gone as +far as try to get other viewers to not support other grids. As far as +woMan is concerned, this just means that LL viewers, and viewers that +drank the LL koolaid, are less functional. shrugs + +The grid manager will also include some sort of search capability, as is +currently being discussed by various people in the OpenSim universe. +There might even be several search systems in place, so supporting +existing ones, and the ability to add more might be useful. WoMan +should be the only thing registered to handle hop:// and other such URLs +in whatever web browsers you are using. Though most viewers want to +register themselves, so tends to be that which ever one you started up +last, or first, gets that privilege. That's a whole can of worms, sane +policy and code should help. + +It might be useful to have woMan be able to download viewers, +including checking for updates and offering to download them. As well +as updates to common things like viewer tag definition files. + +WoMan, unlike the LL viewer code base, will be designed for relogging. +Once the viewer it starts quits (or crashes), WoMan, which was still +running, can pop again and let the user relog, or log to some other +grid, or same grid as different a user, or even same grid as same user +with a different viewer. + +Viewers can be made woMan aware, like meta-impy will be (since it's +handing it's login screen functionality to woMan). A few more things +make sense to be added in this case. For instance, you might want to +have some or all of your LMs (LandMarks) be usable at the log in +screen, so you can log directly to them. The user might want the choice +when they HG (HyperGrid teleport) to actually start up a new viewer and +just login to the other grid instead (if they already have an account +there). While HGed to some new grid, the user might want to add that +grid to the woMan grid manager at a simple click of a button, perhaps +complete with an LM for their current position. The grid searching +capabilities mentioned earlier might be needed while in world. +Certainly the grid manager functions in meta-impy will be handled by +woMan, even if in world. + +In order to display the login page of a grid, which is a web page, a web +browser will be built into woMan. It could be used to display web +pages within an woMan aware viewer. Though perhaps not for MOAP +(Media On A Prim), unless woMan grows the ability to incorporate +itself into the viewers 3D landscape as part of a prim. Which is a good +idea, then meta-impy no longer needs a web browser. Though other things +in the viewer are implemented as web pages, and LL are moving more stuff +to the web. + +One of the things on the login screen is the menu option to start up the +preferences window and change the viewers preferences. Viewers use XML +files that not only store the preferences, but also a description of +them. The preferences window and it's various parts are also stored as +XML files. There is a bit missing that is in the viewer source code +that ties all of this together. So it might not be possible to do this +for all viewers. WoMan aware viewers can naturally provide the +missing bits to woMan, even if not running, or even pass that entire +functionality to woMan, just like meta-impy will do. + +For the purposes of keeping resource usage low, it should be possible +for the user to configure woMan to go away when it starts a viewer. +Might be a good idea even for woMan aware viewers, that can start it +up again if it's functionality is needed while in world. Note this "go +away" means to stop running and free up any resources it was using; +which is different from the "gets out of the way" it usually does, still +running, just not on screen. + + +The problem with the web. +------------------------- + +At least that's the theory. In practice, a web browser takes up almost +one third of the viewer, and is only used for three things. Login +pages, simple built in browser window, and MOAP (Media On A Prim). For +the first two full blown web browsers are massive overkill. MOAP is not +supported by meta-impy yet anyway. + +WebKit is a pain to compile at the moment, for reasons I wont go into +right now. At the opposite of the spectrum is dillo, which is not quite +up to spec enough for login pages that have fancy stuff. There does not +appear to be any middle ground. So right now, I'll work on using random +web browsers as external windows. That will suffice for everything but +MOAP, which I can leave until later. Just discovered netsurf, a little +smaller than dillo, but perhaps better featured? Might be useful. + +The web is a bloated mess, so it's not surprising that a fully featured +web browser component like WebKit is also a bloated mess. + + +Design. +------- + +A thin window on the left. + +Menus across the top. +View tabs. + Grids Accounts Viewers Landmarks + +Grids tab is the grid manager, though you can also drill down / tree out +the accounts list per grid. + +Accounts shows accounts, though can drill down to grid list per account. +Also consider launching thin viewers, text only ones and such. The +account view is almost a natural for extending into a IM style thingy. + +Viewers lists the installed viewers, can install more, and allows +preferences editing. It can handle viewer installs, upgrades, even +compiling them from source. + +Landmarks manages LMs from viewers, or log in spots, or SLURLs etc. + +A user configurable web browser can open up to fill the right of the +screen. + +Log file management features, including viewer stdout, check if only +Linux viewers do that. Including chat logs. + +Dillo and uzbl can insert themselves into the windows of others. Should +check that out. Netsurf is allegedly easy to port to things, might be +able to port it to EFL. + -- cgit v1.1