1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
FIXES -
LuaSL crashes
-------------
Hmmm, empty functions get no end, that's NOT legal in Lua.
Project paths
-------------
The executables currently live in ...../SledjHamr.
Test executables stay in the src directory.
Media and other data in SledjHamr/media (includes the test sim and Irrlicht examples).
External libraries are in SledjHamr/libraries (Irrlicht and lemon).
Irrlicht is statically linked, so except for it's media, we don't need it at run time.
We could probably move the Irrlicht examples we actually use (all test data anyway) to Test sim.
Lemon is only used at build time.
Builders should be able to -
put binaries in /usr/local/bin
put libraries - /usr/local/lib/SledjHamr
put media in /usr/local/share/SledjHamr
If they don't, those things should be in the build directory, where they are now.
User should be able to -
Run sims from where ever they like.
Write GuiLua modules that reference media that is where ever it is.
Normally media would come along with the module.
So on disk modules would include media in the same directory as the module.
In world modules would be in some object, and the media should be in that object to.
Client side modules from the net ... dunno yet.
Write their own skins, using their own media.
SOOOO ...
install.lua should - (doesn't exist yet)
SledjHamr binaries -> prefix .. '/bin'
SledjHamr/libraries -> prefix .. '/lib/SledjHamr'
SledjHamr/media -> prefix .. '/share/SledjHamr/media'
This should not include data that could be changable, so maybe the test sim should move elsewhere?
LuaSL at least puts compiled scripts in the test sim.
Nails will eventually make changes to the test sim during testing.
For now, we don't care, there's no actual installing going on.
SledjHamr/locale -> prefix .. '/share/SledjHamr/locale'
Irrlicht is flickering like crazy. Hmm, might be Irrlicht's fault,
mostly it flickers to black, but I've seen it flicker to the first frame
of the GL demo. On the other hand, it shows the Elm background usually.
GL viewport aspect ratio should remain stable through resizes.
FEATURES -
Er, all of them I think. B-)
Make the existing toolbar / tab thingy a bit more tab like, and have the
scroll in effect be position / direction aware. Combining window title,
menu, top level tabs, and toolbar widgets might be good. Perhaps auto
spreading across two lines (menu + tools / tabs) on window shrinkage
first before going to the "More.." thing (for both tabs and tools).
Need pie menus!
Generic scrolling text area, with time stamps, clickable URLs (including
internal links to profiles and stuff), logging to file, reading history
from file (both a few dozen lines, or the entire thing). EFL log
domains should be able to feed into these, with colours, and should be
able to split / filter bits to different areas. Two Elm_entry's, one
not editable. See "Entry 7" test.
IM tabs should show a very faded version of the others profile image/s.
IDEAS -
Internal window manager.
------------------------
Write my own, use ePhysics. Hopefully ePhysics has some sort of
magnetism / attraction thingy. See the forces demo, should be doable.
Collision restraints and impulses?
See if Evas allows detaching stuff from one canvas and adding it to
another canvas. This allows things like tearing off tabs from windows,
tearing off sub menus, and switching windows between internal and
external windows, without having to entirely recreate the UI stack
within. Hmm, think this is what swallow / unswallow is all about.
Think that only covers stuff in the same Evas though. Not sure this can
be done currently. Maybe the Elm socket and plug thingy can be used?
Some or all of the windows could be external processes anyway. The
socket seems to be some sort of server, which can share it's content to
other plugs (processes), each one sees identical stuff, including
interactions. The plugs can come and go as they please. Or perhaps
elm_object_part_content_set/get/unset or
elm_object_item_part_content_set/get/unset might work for this.
An internal window has a title bar, with a centered title, and the usual
widgets. The title part is split into three, if you grab and drag from
the middle bit, it moves as normal. If you grab and drag from the
others, it dangles from that corner as you move it. ePhysics magnetism
can be used for the usual "snap to nearby window" thingy.
Grabbing and flicking a window means it will move as a physics object,
bouncing off stuff until it looses enough energy to stick magnetically
to something, or lay on the bottom.
Minimised windows could be small transparent ePhysics buttons showing
just the title. Can be dragged, flicked, or maybe double clicked to
open. Right click for menu as usual.
Windows need title bar, close, minimize, and if they are resizable,
resize grab edges/corners, and bottom right corner resize. Some need
menus. They need to remember their size, position, minimized state,
closed state. Try to put top toolbar style widgets in the title, and /
or menus. Have the toolbar "Menu" flip down on hover. Also add the
"tear out of window" widget for making an internal window external,
again with drag and drop or widget to bring them back in again.
All tabs should be tear off? All menus are. Currently menus reattach
when you close their windows. Currently tabs re attach when you click
on their tear off button again. Hmmm, maybe should re attach both if you
drag and drop them? With some sort of quivering with anticipation
effect when they are in the drop zone? Menu window can start to shrink
towards their origin menu when dragged close. Dragging the tab button
should tear them off. Though they currently can be dragged to re
arrange them, so that will be dragging them in the other axis then I
guess? Tearing off should have some sort of rip and wobble effect,
maybe an ePhysics soft body?
Windows like the prim edit window should do like Elm toolbars when
resized too small, low priority widgets shrink down to a "More.."
button.
Optional hover focus on windows, maybe even on some widget types.
Focused windows should be not quite as transparent as unfocused ones.
Allow control over transparency levels (press on scroll wheel and wiggle it?).
Current windows use the horrid "click anywhere to focus and raise", should have an
option for proper layering. :-P
ELM -
What is -
Conformant?
Squeezes things to make room for virtual keyboards and other mobile stuff.
CTX popup?
A pop up simple list of items.
Mapbuf?
Used in the launcher tests, so that might provide a clue.
I think it just stuffs the entire container widget into a single image so that resizing and moving is faster.
A performance tweak.
Store (under helpers)?
Threaded content getter for genlist, and other widgets in future.
Basically the content of a genlist is fetched in the background, to slowly populate a genlist.
The store can do any sort of arbitrary mapping of what it fetches to genlist item content.
Currently this is file system based.
Might be useful for inventory, though we really need a tree widget, which happily genlist does.
Stored surface buffer (Launcher tests)?
Just the mapbuf thingy above I think.
|
