From 29c25cb913fde0a8320bca9b9ea2cc82fbe2ec94 Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Tue, 22 Apr 2014 14:51:57 +1000 Subject: Move most of the README's and other docs into the new docs directory. --- ClientHamr/BVJ/README | 7 - ClientHamr/GuiLua/README | 581 ----------------------------------- ClientHamr/IAE/README | 3 - ClientHamr/README | 7 - ClientHamr/XMPP/README | 4 - ClientHamr/bGod/README | 5 - ClientHamr/extantz/README | 24 -- ClientHamr/extantz/WindowSharing.txt | 84 ----- ClientHamr/libpurple/README | 4 - ClientHamr/mumble/README | 5 - ClientHamr/woMan/README | 148 --------- 11 files changed, 872 deletions(-) delete mode 100644 ClientHamr/BVJ/README delete mode 100644 ClientHamr/GuiLua/README delete mode 100644 ClientHamr/IAE/README delete mode 100644 ClientHamr/README delete mode 100644 ClientHamr/XMPP/README delete mode 100644 ClientHamr/bGod/README delete mode 100644 ClientHamr/extantz/README delete mode 100644 ClientHamr/extantz/WindowSharing.txt delete mode 100644 ClientHamr/libpurple/README delete mode 100644 ClientHamr/mumble/README delete mode 100644 ClientHamr/woMan/README (limited to 'ClientHamr') diff --git a/ClientHamr/BVJ/README b/ClientHamr/BVJ/README deleted file mode 100644 index 456154a..0000000 --- a/ClientHamr/BVJ/README +++ /dev/null @@ -1,7 +0,0 @@ -Refer to - http://www.infinitegrid.org/drupal/content/BVJ - -BVJ is extensions to the BVH animation format used by SL technology. -It's in the ClientHamr section coz on the server side, they are just -dealt with as blobs to be sent to the viewers. This may change if we -implement animating link sets, and interaction with the sim physics. - diff --git a/ClientHamr/GuiLua/README b/ClientHamr/GuiLua/README deleted file mode 100644 index f60d7b2..0000000 --- a/ClientHamr/GuiLua/README +++ /dev/null @@ -1,581 +0,0 @@ -GuiLua is basically a redo of my ancient Java based matrix-RAD system, -but using Lua and EFL. Lua is entirely different from Java, and Lua -doesn't run in web browsers, so this version has similar concepts, and -similar names, it's not exactly the same. It's more accurate to say -this is in the spirit of matrix-RAD. - -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. - -Stdin/out might be good to use. Extantz starts up "client" programs, -with a "use stdin/out" argument, the clients pass skang commands (open -this internal window with these widgets) to extantz through their -stdout, extantz passes skang commands (these values where set by these -widgets) back through their stdin. With no "use stdin/out" argument, -the programs host their own UI. Perhaps extantz can just pass the UI -skang stuff back to the client, which will mean "draw your own window", -to support the "tear off" feature. If I remember skang had suitable -serialization stuff to support this. Lua does anyway. B-) - -Naturally, like matrix-RAD, all this UI stuff can happen across a socket -as well as through stdin/out. Should be transparent to the user proggy. - -I can redesign skang to be more Lua like, to take advantage of Lua's -meta language capabilities. Since no one used skang anyway, I can get -away with this. Also should add a Lua friendly wrapper around nails, so -that addons for Extantz can be supplied entirely as Lua scripts. In -other words, LuaSL scripts. On top of all that, should also allow -access to the Edje Lua stuff I've already written, but drag it outside -of an edje file. - -This pretty much means that GuiLua should be a shared library, coz in -the ClientHamr use case, several programs are gonna be using it at once. -Should also be separate modules for development stuff like the skin -editor, which could be just another proggy using GuiLua. - -Initially GuiLua can wrap elementary / evas, with the goal of wrapping -NAWS, just like matrix-RAD was originally planned. Then I can put off -writing NAWS for another decade. lol - -Might be nice to have a wrapper that is a web server that generates -standard HTML forms. No JavaScript, no HTML5, just plain old, -compatible with everything, HTML forms. - - -Design notes ------------- - -Edje Lua does not wrap elementary widgets, and is not likely to due to -elementary being compiled after edje. Smart objects and swallows -probably can deal with that though, I'm not familiar enough with them to -know. Eo on the other hand allegedly offers introspection, which was -always the corner stone of matrix-RAD. So access to elementary widgets -via Eo might be possible. That's kinda the entire hook I'm hoping will -help to make matrix-RAD style stuff work as well as it did there. -Apparently when they promised introspection with Eo, they meant compile -time, not run time. - -Edje Lua is restricted to scripts in edje files, AND sandboxed to those -edje files as well. We want to step outside that sandbox, and run stand -alone Lua scripts, as well as GuiLua / LuaSL scripts internal to -extantz. Some merging of LuaSL and Edje Lua, leaving room for GuiLua, -would be great, but I might have to convince Raster. Note that the -socket idea wont work in sandboxed edje Lua scripts, unless the socket -is in C code, that uses edje messages as the internal transport. - -Just so it's easier to find, I'll repeat a bit from the Enlightenment -mailing list here, the result of discussions with raster and other -interested parties - - -"First step is to write edje functions for generically bundling up one -or more Lua tables into a message, sending that message, then unpacking -it again. This will be able to be done from edje, from C, and from Lua -directly. Perhaps adding that as one more edje messege type. This is -for sending Lua tables between threads. A later addition will be to -send them through the 'net, probably as eet. - -Host apps can register arbitrary functions with edje Lua, using a more -generic version of the code I already wrote for letting edje register -lua functions. These host functions are by default not thread safe. -Edje puts a wrapper function around the host app, and registers that -wrapper function with Lua. The wrapper function, when called from Lua, -does this - - -ecore_thread_main_loop_begin(); -call the host app callback(); -ecore_thread_main_loop_end(); - -The first alternative, which the host app must request, is for the -wrapper function to use the table message functions to marshal the -arguments, send it to the main thread, wait for the response (or do -something else), then unmarshal the result before sending it back to -Lua. - -The second alternative, which the host app must REALLY request, is for -the host app to say "I'm REALLY going out of my way to be threadsafe, -just call me direct". No edje wrapper function, BUT the host app still -has to use edje to register this function. - -The first two might be done this way - - -host_cb = edje_lua2_functions_add(...); -edje_lua2_function_marshal_set(host_cb, function); - -The last one could be - - -host_cb = edje_lua2_threadsafe_function_add(...); - -Note the difference between _functions_ and _function_. The first call -registers an entire metatable full of functions, in the same way that -edje does for it's functions. These are the default sort of -functions. The second call references one of those previously -registered functions, and makes it marshal arguments and results. The -third one registers a single function, but it could be added to an -existing metatable registered by the first function." - -and - - -"We are actually half way there. Anticipating that there would be way -more edje and evas stuff to add to the edje Lua API in the future, I -created generic wrapper functions to make that easier. Implementing -this would mean exposing those static functions, and writing more of -these generic wrapper stuff. - -Lua already provides a mechanism for this sort of thing, but we -currently sandbox that out. We can provide a very limited version of -the package module, that only lets the Lua script load modules that the -host app explicitly provides. This keeps edje Lua in it's strictly -sandboxed state." - -Raster also wants to thread lots of edje, likely including having edje -Lua scripts as threads, much like I'm doing with LuaSL already. Plus -LuaJIT SPEEEEED!!. B-) - - -Skang notes ------------ - -So, what will this variation of skang look like? For a start, the -syntax will have to be more Lua like, so that's a real basic change. -Can't use a space as an argument separator, Lua allows only ',' and -';'. Strings can still use single or double quotes. - -The magic "_123" system I used before to specify "position / size in -characters instead of pixels" just wont work in Lua. Using _ as a table -name with a meta table means that this syntax now becomes "_.123", which -is kinda acceptable. Note that _.123 is syntax sugar for _["123"], so -I'm not sure if using a number there works. An alternative is to just -use a string - - -foo = widget.label(0, "1", 100, 0, 'Text goes here") - -Uses as many characters, and ends up being a value instead of an index, -which is the right thing to do. While on this subject, anything less -than 1, but more than 0, can be used as a percentage, maybe combined -with "character" mode (this is a new thing) - - -foo = widget.label(0, "0.1", 0.5, 0, 'Text goes here") - -This could even allow relative placement as mentioned in the skang TODO - - -foo = widget.label(0, "otherWidget+0.1", 0.5, 0, 'Text goes here") - - -"widget" would be a table with functions for dealing with widgets. It -would include metatable stuff for widget set introspection. So -"widget.label" would introspect in our widget set for a widget type of -"label", and return a widget type table. So we could do - - -foo = widget.label(0, "0.1", 0.5, 0, 'Text goes here :") -foo:colour(255, 255, 255, 0, 0, 100, 255, 0) -foo:hide() -foo:action("skang.load(some/skang/file.skang)") - -Also allow access via table elements - - -foo.action = "skang.load('some/skang/file.skang')" -foo.colour.r = 123 -foo.look('some/edje/file/somewhere.edj') -foo.help = 'This is a widget for labelling some foo.' - -We can use the concat operator (..) to append things to widgets, like -adding choices in a drop down, rows in a grid, etc. - -Hmm, need a skang table as well - - -skang.module(Evas) -skang.module(Elementary) -skang.clear() -skang.load('some/skang/file.skang') - - -I don't think we need variable introspection as much, since in this case -Lua is both the skang and the underlaying language, the variables can -just be accessed directly. Not sure on this, need to experiment. This -is what we normally need variable introspection for - - -foo = 'bar' -- Using the metatable to override '=' to set the actual value of the widget, say the text of a label or edit widget. -bar = foo -- The reverse of the above. Though perhaps these can't be done? -foo = foo .. 'stuff' .. 'more stuff' .. 'another line of the dropdown or whatever' - -OK, first two can't be done, metatable only overides that for table elements. The third one can only be (I might be wrong there) - - -foo.value = 'stuff' .. 'more stuff' -foo.value = foo.value .. 'another line of the dropdown or whatever' - -Skang relied on the use of the set command to make sure that any -matching widgets and variables got updated. And the get command. - -foo:set('stuff') -bar = foo:get() - -On the other hand, given the module / package stuff mentioned below, and -some metatable magic, we could do - - -local other = require('otherPackageName') -other.foo = 'stuff' -bar = other.foo - -Sooo, how does that squeeze into a "skang" file? - -#!skang myApp.skang -- This is Lua, so this might not work. --- There's an implied local this = require('myApp') --- There's an implied local skang = require('skang') -local widget = require('EvasWidgets') -local other = require('otherPackageName') -skang.clear -skang.window(200, 200, "G'day planet.") -quitter = widget.button('Quit', 0.5, 0.5, 0.5, 0.5) -quitter:action('quit') -- 'quit' is looked up in ThingSpcae.commands, and translated into the Lua 'skang.quit()'. -other.foo = 'stuff' -this.bar = other.foo - - -Original Skang infrastructure ------------------------------ - -Skang starts with a Thing as the base. In Java it's a base object for -everything else, with a bunch of methods and elements. We can probably -use a Thing metatable and replicate most of it. The widget used in the -previous section is built on top of Thing. Things are stored in -ThingSpace, which is a BonsaiTree of LeafLike Things. Java's version of -multiple inheritance was used. Commands are a Thing. - -ThingSpace is per users session. classCache stores cached class -lookukps, command stores commands, module stores loaded modules, param -stores variables and their values, widget stores widgets and their value -/ state. - -Skanglet is a generated mapping between actual methods / variables in a -class, and skang. Each method or variable that ends up in the skanglet -was marked by special javadoc tags. It also included some meta data -like version and the default skang. For variables it defined - - -"Name", "Field/Method()", "Required", "Shortcut", "Default", "Help text" - -... and for methods - - -"Name", "Method", "Syntax", "Help text" - -In both cases the "Name" was the skang name, it could be different from -the Java name specified in the second field. Likely we can do away with -the need to generate these skanglet files, and just add stuff to the -Thing. Modules wrap Skanglets, and takes care of loading them into ThingSpace. - -Module are used for - - loading the Skanglet for the Thing currently running (match java class name to skang file name). - loading the AWT interface in skang files. - loading OTHER skanglet based Things - loading Squeal, StuffSkang, and Who from java when needed. - -So in Lua, we can use the package system. First require(moduleName) to -load up the skang module. Require can return a table, the Lua package -called ends with "return someTable". See LuaLSL for an example. This -package is actually run, so it can figure out what to put in the -returned table. So for instance it could use inlined methods and such - - -local skang = require('skang') -local result = {}; -result.author = 'onefang' -result.version = '0.72 alpha 2004-11-19 16:28:00' -local foo --- The first argument would be the name of a local variable / method. Which could be accessed via _G? --- Not sure if we could use a global foo, AND use it directly. -result.foo = skang.newParam('foo', "Required", "Shortcut", "Default", "Help text") -result.func = skang.newCommand('arg1_type,arg2_type', 'Help Text', function (arg1, arg2) -... -end) -return result; - - -Stuff is the base class used to track database rows and other multi -value things. Would still need to deal with variable sub things, though -that's likely just using tables. SquealStuff is the database version, -using Squeal as the database driver wrapper. Squeal could wrap -esskyuehl? - - -The pre tokenized structure thingy I had planned in the TODO just wont -work, as it uses symbols. On the other hand, we will be using Lua -tables anyway. B-) - - -NAWS ----- - -NAWS was always planned, but never actually written. Though some stuff -was kinda prototyped, especially UberMatrix stuff. I think this time -around, NAWS should be written in C, based on pure Evas + Edje. Perhaps -with direct support for introspection? After EO settles down, I might -use that to. - - -Edje_Lua notes --------------- - -Edje_Lua is sandboxed firmly inside of edje files. This makes it -unsuitable for our use, as we want to step outside that sandbox. -However, we still want to wrap Lua around EFL stuff, preferably using -the same API. Raster fought against using this new eolian stuff to -generate edje_lua2.c, and seems to be against having a "no sandbox" flag -in edje_lua2.c. For now I'll let q66 go ahead with his Edje Lua via -LuaJIT FFI conversion that uses a variation of eolian written in Lua. -Seems like much more work than my way of doing it. shrugs - -Unfortunately, this might not be ready soon enough for me, AND it might -not even be suitable. While I agree that LuaJIT FFI stuff might be a -good idea, if I read the docs correctly FFI simply wraps around C -headers and libraries directly, making it less suitable for sandboxes -and other environments where you want to wrap those library functions -differently. - -So, I might have to go ahead with my own plan anyway. On the other -hand, for skang, I want to wrap things a bit differently. Might be best -to do that wrapping C side. In other words, the skang and widget Lua -packages get written in C, and are different from edje_lua2.c. - -On the gripping hand, there might be use in including edje_lua2.c style -bindings in GuiLua as an edje package, evas package, elementary package, -etc. This could be done by going ahead with my plans to modify -edje_lua2.c to include the "no sandbox" flag, then compile it with that -flag turned on to produce a standard Lua package. Then get eolian to -produce evas_lua.c, elementary_lua.c, etc. - -Another idea worth investigating is to rewrite edje_lua2.c to use -introspection directly to figure out it's "combined set and get" style -bindings. - - -Introspected EFL notes ----------------------- - -See below for the basic EO notes, where I come to the conclusion that -the other EFL devs wont be adding introspection to EO themselves. It's -all too hard they say. Pffft - -So, I might have to do this myself, call it "entro".... - -Write a patch against eolian that outputs introspection data. That data -is C code for a hash of EO class names. Each hash points to a data -structure that includes a hash of method names for that class, and a -pointer to the class description. Each of those hashes points to a data -structure that includes an array of argument types and names. The -method ID should be in that structure to, and maybe even the doc text. -Might even include an Eo internal data structure that links Op IDs to -that method structure (I dunno what they call that). The final output -is a library of that C code, that includes functions for doing the -actual introspection. - -See? Not to hard at all, all described in a paragraph. lol - -One function we could include is a way to "compile" eo_do arguments. -That would be an array (va_list actually) of method ID's followed by the -arguments for that method. Some of those arguments might be pointers to -memory structures, so this is not suitable for storing on disk. -Instead, it could be used for "compiling" commonly used code or hot -paths to get the introspection overhead out of the way early. Could -also compile parameterized versions, with numbered place holders that -get filled in later. Certainly we need a Lua interface to eo_do of some -sort. - -In the same way that Java skang cached the results of introspection in -ThingSpace.CLASS, we could use cache introspection lookups to speed -things up. Not a great saving, one hash lookup versus two. Caching the -"class.method" string that points to the method structure for any method -we have used already. - -NAWS could use the compile function to create eo_do commands needed to -create each of it's widget types, and the window. Yes, I know, NAWS -only has two "widget types". B-) - - -For quick and dirty early testing, I'll probably write a widget package -that has hard coded mappings between some basic "label", "button", etc. -and ordinary elementary widgets. Proper introspection can come later. - - -LuaJIT FFI notes ----------------- - -LuaJIT 2.0 FFI needs to have cleaned up versions of C header files -included in the Lua scripts that use it. This is messy. Version 2.1 -(or perhaps 3.0) has on it's road map to include a C pre processor, -which should help that problem. - - -EO notes --------- - -tl;dr - eo introspection doesn't actually exist, even though it was -"promised" years ago, but looks trivial to add. On the other hand, the -other EFL devs seem to be fighting against it, so I might need to write -my own. sigh - -object = eo_add(EVAS_OBJ_LINE_CLASS, canvas); - evas_line.eo.h -> #define EVAS_OBJ_LINE_CLASS evas_obj_line_class_get() - -> const Eo_Class *evas_obj_line_class_get(void) EINA_CONST; - evas_line.eo.c -> EO_DEFINE_CLASS(evas_obj_line_class_get, &_evas_line_class_desc, EVAS_OBJ_CLASS, NULL); - Eo.h -> EO_DEFINE_CLASS is a macro that basically wraps eo_class_new(), and returns it's result. - -So Eo_Class is the type of a class, but it's A) opaque, B) deprecated! -It includes a pointor to the Eo_Class_Description, which includes the -actual name. I'm not seeing anywhere the names of the get/set -paramaters being passed into the system, or any way to look up a class -based on name. Not even a way to get to the public Eo_Class_Description -from the opaque Eo_Class. - -Eo_Class_Description is at least public. It includes -Eo_Op_Description's and Eo_Event_Description's. Eo_Op_ and Eo_Event_ -include the name and documentation of the op / event. The macro used to -generate Eo_Op_ does NOT pass the name, just the ID number as a string. -There is also Eo_Op_Func_Description, which does not include a name, it -seems to be generated in the constructor. The same Eo_Op_ ID number is -used to index it. Seems to be no direct link between Eo_Class and -Eo_Op_func_, just the same Eo_Op_ ID numbers used internally somehow. - -eo_do(obj, evas_obj_line_xy_set(200, 200, 300, 300)); - evas_line.eo.h -> #define evas_obj_line_xy_set(x1, y1, x2, y2) EVAS_OBJ_LINE_ID(EVAS_OBJ_LINE_SUB_ID_XY_SET), EO_TYPECHECK(Evas_Coord , x1), EO_TYPECHECK(Evas_Coord , y1), EO_TYPECHECK(Evas_Coord , x2), EO_TYPECHECK(Evas_Coord , y2) - #define EVAS_OBJ_LINE_ID(sub_id) (EVAS_OBJ_LINE_BASE_ID + sub_id) - extern EAPI Eo_Op EVAS_OBJ_LINE_BASE_ID; - - enum - { - EVAS_OBJ_LINE_SUB_ID_XY_SET, - EVAS_OBJ_LINE_SUB_ID_XY_GET, - EVAS_OBJ_LINE_SUB_ID_LAST - }; - evas_line.eo.c -> EAPI Eo_Op EVAS_OBJ_LINE_BASE_ID = EO_NOOP; - static void _gen_evas_line_class_constructor(Eo_Class *klass) - { - const Eo_Op_Func_Description func_desc[] = { - EO_OP_FUNC(EO_BASE_ID(EO_BASE_SUB_ID_CONSTRUCTOR), _eo_obj_evas_line_constructor), - EO_OP_FUNC(EVAS_OBJ_LINE_ID(EVAS_OBJ_LINE_SUB_ID_XY_SET), _eo_obj_evas_line_xy_set), - EO_OP_FUNC(EVAS_OBJ_LINE_ID(EVAS_OBJ_LINE_SUB_ID_XY_GET), _eo_obj_evas_line_xy_get), - EO_OP_FUNC_SENTINEL - }; - eo_class_funcs_set(klass, func_desc); - } - - static void - _eo_obj_evas_line_xy_set(Eo *obj, void *_pd, va_list *list) - { - Evas_Coord x1 = va_arg(*list, Evas_Coord); - Evas_Coord y1 = va_arg(*list, Evas_Coord); - Evas_Coord x2 = va_arg(*list, Evas_Coord); - Evas_Coord y2 = va_arg(*list, Evas_Coord); - _evas_line_xy_set(obj, _pd, x1, y1, x2, y2); - } - - void _evas_line_xy_set(Eo *obj, Evas_Line_Data *pd, Evas_Coord x1, Evas_Coord y1, Evas_Coord x2, Evas_Coord y2); - - evas_object_line.c -> EOLIAN static void _evas_line_xy_set(Eo *eo_obj, Evas_Line_Data *_pd, Evas_Coord x1, Evas_Coord y1, Evas_Coord x2, Evas_Coord y2) - - -Evas_Object_Line *o = eo_data_scope_get(obj, EVAS_OBJ_LINE_CLASS); -Evas_Object_Line *o = eo_data_ref(obj, EVAS_OBJ_LINE_CLASS); - - -.. evas_line.eo - -class Evas_Line (Evas_Object) -{ - legacy_prefix: evas_object_line; - eo_prefix: evas_obj_line; - properties { - xy { - set { - /*@ - @since 1.8 - - Sets the coordinates of the end points of the given evas line object. */ - } - get { - /*@ - Retrieves the coordinates of the end points of the given evas line object. - second end point. */ - } - values { - Evas_Coord x1; /*@ The X coordinate of the first point. */ - Evas_Coord y1; /*@ The Y coordinate of the first point. */ - Evas_Coord x2; /*@ The X coordinate of the second point. */ - Evas_Coord y2; /*@ The Y coordinate of the second point. */ - } - } - } - implements { - Eo_Base::constructor; - } - -} - -... evas_line.eo.c - -EAPI void -evas_object_line_xy_set(Evas_Object *obj, Evas_Coord x1, Evas_Coord y1, Evas_Coord x2, Evas_Coord y2) -{ - eo_do((Eo *) obj, evas_obj_line_xy_set(x1, y1, x2, y2)); - return ; -} - - -static const Eo_Class_Description _evas_line_class_desc = { - EO_VERSION, - "Evas_Line", - EO_CLASS_TYPE_REGULAR, - EO_CLASS_DESCRIPTION_OPS(&EVAS_OBJ_LINE_BASE_ID, _evas_line_op_desc, EVAS_OBJ_LINE_SUB_ID_LAST), - _evas_line_event_desc, - sizeof(Evas_Line_Data), - _gen_evas_line_class_constructor, - NULL -}; - - -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. - - -old notes ---------- - -See if it's possible to disable the Emerald/Phoenix/Firestorm LSL bridge -when connecting to OpenSim. Actually, they finally came to their senses -and support OpenSim now, so that should be sorted already. diff --git a/ClientHamr/IAE/README b/ClientHamr/IAE/README deleted file mode 100644 index 8c0e46c..0000000 --- a/ClientHamr/IAE/README +++ /dev/null @@ -1,3 +0,0 @@ -Refer to - http://www.infinitegrid.org/drupal/content/InworldAnimationEditor - -IAE is an idea to put an animation editor in world, much like the link set editor. diff --git a/ClientHamr/README b/ClientHamr/README deleted file mode 100644 index c82b1ba..0000000 --- a/ClientHamr/README +++ /dev/null @@ -1,7 +0,0 @@ -Refer to - http://www.infinitegrid.org/drupal/content/ClientHamr - -ClientHamr is the concept that we can apply the unix philosophy to the -viewer. Use individual tools that are good at their job to split off -bits of the big bad blob that is the viewer. Using standard protocals -and tools where we can. - diff --git a/ClientHamr/XMPP/README b/ClientHamr/XMPP/README deleted file mode 100644 index 53058b2..0000000 --- a/ClientHamr/XMPP/README +++ /dev/null @@ -1,4 +0,0 @@ -Viewer integration with XMPP, and using it for as many services as it can. - -XMPP / jabber is a good protocol to base presence, IM, groups, and other -related stuff on. We should do so. diff --git a/ClientHamr/bGod/README b/ClientHamr/bGod/README deleted file mode 100644 index ec48d61..0000000 --- a/ClientHamr/bGod/README +++ /dev/null @@ -1,5 +0,0 @@ -A front end to grid admin tools, though generally OS/SL specific tools. - -The name is a reference to SL's god mode, and the Men at Work song "Be -Good Johnny", which itself is a reference to Chuck Berry's "Johnny B. -Goode". diff --git a/ClientHamr/extantz/README b/ClientHamr/extantz/README deleted file mode 100644 index 5fb1d5f..0000000 --- a/ClientHamr/extantz/README +++ /dev/null @@ -1,24 +0,0 @@ -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) -projects, that has not been done to death, and thus has some reasonable -chance to turn up in google searches. It also helps if it somehow or -other reflects what the project actually is. lol - -Extant means "still existing, surviving", or the more archaic meaning, -from it's original Latin roots "standing out, be visible, exist". - -Extent means "an area or volume, the range over which a thing extends" -among other things. - -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 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/WindowSharing.txt b/ClientHamr/extantz/WindowSharing.txt deleted file mode 100644 index 1ccd3bb..0000000 --- a/ClientHamr/extantz/WindowSharing.txt +++ /dev/null @@ -1,84 +0,0 @@ -EnLichtIrrnment. B-) - -Elementary and Irrlicht don't like to share windows. - -Irrlicht can be told to create a device from a pre existing window, but this is Windows only. - Perhaps it already works for Linux, just the docs are out of date? - It works, sorta. - -IVideoDriver::getExposedVideoData() can provide a structure with raw OS level window pointers. - This implies that it's theoretically possible to create a device from things other than Windows windows. - Wont provide any valid info when using the software renderer. - -Elementary can provide an Ecore_Wl_Window or an Ecore_X_Window of one of it's windows. elm_win_wl_window_get() and elm_win_xwindow_get(). - -Ecore_evas can provide an Ecore_Window with ecore_evas_window_get(). - -Ecore_X_Window ecore_x_window_new() - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=2&t=31350&sid=0eb6d64c84ec7043fd48103f8e63e930 may help. A little. - - -"For using OpenGL with an Evas canvas, there is two possibilities in my -opinion. Either put the canvas in a texture and give it to the 3D -engine, or use EvasGL API and make the 3D engine integrate inside -Evas. It is possible to have a direct rendering path with EvasGL and -so have a fastest possible path. --- -Cedric BAIL" - - -Apparently Irrlicht's method of providing an external window actually works. Mostly. - - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=32647 -http://sourceforge.net/tracker/index.php?func=detail&aid=2655876&group_id=74339&atid=540676 - -Though seems that bug was marked as a duplicate with the duplicate having a better patch, but NO FUCKING LINK to that duplicate. What a horrid bug tracker. - - -There is also this which gives clues -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=9&t=26506 - - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=2&t=39872 -http://irrlicht.sourceforge.net/forum//viewtopic.php?t=39719 - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=9&t=35197 - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=2&t=46087 - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=9&t=42450 - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=9&t=35251 - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=5&t=15338 -http://irrlicht.sourceforge.net/forum//viewtopic.php?f=7&t=12697 - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=5&t=44599 - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=5&t=18941 I think is ancient and might just be similar to what's in there already. - ---------------------------------------------------------- - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=26141 -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=33845 -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=35984 -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=34527 - -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=38656 may be of some interest. -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=30943 -http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=46983 where the question I want is not answered. - ---------------------------------------------------------- - -I could run sed over COpenGLDriver.cpp to turn it into CEvasGLDriver.cpp, then tweak it a bit. - -evas_gl_make_current(gld->evasgl, gld->sfc, gld->ctx); -glFoo() -> glapi->glFoo() - - -Hmm, there will be some source files with random gl() calls, and I'd -need to tweak a few other things to suit. So this wont be a clean "just -drop in this source file" patch. B-( - -Probably a lot easier to just figure out what what brand of glue to use -to get Irrlicht using Evas created GL surface and context. diff --git a/ClientHamr/libpurple/README b/ClientHamr/libpurple/README deleted file mode 100644 index 4e14b9b..0000000 --- a/ClientHamr/libpurple/README +++ /dev/null @@ -1,4 +0,0 @@ -Viewer integration with libpurple, using it for generic IM services. - -Libpurple is a modular IM system, we could just add a libpurple based IM -system to the viewer, and use that for the XMPP integration. diff --git a/ClientHamr/mumble/README b/ClientHamr/mumble/README deleted file mode 100644 index 1010f18..0000000 --- a/ClientHamr/mumble/README +++ /dev/null @@ -1,5 +0,0 @@ -Viewer integration with mumble and whisper, and using it for as many -audio services as it can. - -Mumble is a voice system designed for networked 3D game usage. Sounds -perfect, just what we need. B-) diff --git a/ClientHamr/woMan/README b/ClientHamr/woMan/README deleted file mode 100644 index 1b3bbe0..0000000 --- a/ClientHamr/woMan/README +++ /dev/null @@ -1,148 +0,0 @@ -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