todo.txt

The service registry updates...  is it causing excessive re-renders?
-WellContextMenu
-Header -> component buttons
-Header -> mode buttons

Note:
The slide well is re-building itself more than once causing extra application of the
bg to the slide drawers.  This only happens on initial load out it seems.




-Slide size: Allow changing of slide size (for full screen slides and such)
-Slide background image : allow per slide BG images
http://superhighfives.github.io/tweetflight-presentation/

-Theme editor: apply styles for h1s, h2s, etc.
	-Apply them on a per-slide basis as well?

-Text insertion: allow insertion of h1s, h2s, ps, etc.
	for use in themes

-Allow a "timeline" for inner transitions.

-Change "tablets" to be a sort of pulldown with additional options.
Pulldown will show itself whenever the mouse is close.



-Before presenting, make sure markdown content is saved.


-EditorModel will get updated when a new generator is selected
-EditorModel will check to see if that generator allows modes
-Set mode to none if not
-Enable other controls required by generator
-Other controls will behave similarly to the mode button stuff in the header?











-text writer
-destroy event
-gradient picker
other things to jquery misc?


Should have a strut.command interface...
and certain command will go into the menu...

metadata will dictate where they go..


push to back, pull to front
z-tracker!!!


vert.x and clojure for strut service?


TODO: remove jquery and use zepto -or- use jquery 2

So end result:
config.js -> list bundle names and rmap location
rmap -> map bundle names to physical locations
framework -> loads config.js and sets up require.js paths
bundles -> load own contents based on relative paths,
  load contents of other bundles based on bundle name and inner bundle paths.

TODO: how about bundles that export packages that aren't a superstring of their name?

Then config will be loaded...  bundle metadata will all be loaded...
based on bundle metadata we can come up with rules?
because bundle will export something and we know the bundle path so whatever it 
exports will be relative to the bundle path since packages
must be structured correctly within a bundle.

Packages must be separated by '/' not '.' to appease requirejs.

config.js:
return {
	rmap: 'path/to/rmap',
	bundles: [
	'com/tantaman/web/storage',
	'strut.editor',
	etc...
	]
}

rmap.js:
return {
	'com/tantaman/web/storage': 'bundles/common/com.tantaman.storage',
	'strut/editor': 'bundles/strut/editor'
}

and require.js path rules:
requirejs.config({
	path: {
		'bundle-name': 'bundle-location'
	}
});

Path structure is basically the rmap!  Can we load the rmap directly into the config then?

Or screw the rmap and have the user just make the rmap in their requirejs
configuration?

Eh, separate rmap is better so we can do tooling and build the rmap.

Later we need to handle exporting of packages from a bundle.  Packages in a bundle
should be allowed to be unqualified?  E.g.,
com.tantaman.storage/Thinger will be a part of com.tantaman.storage?
How do we then handle qualified ones? :|  Does it really make sense in a js env?

It'll later have to be handled with export pkg.  For the time being
the bundle will be considered to export a package that is the bundle name
and that'll be added to the rmap.

Eventually no bundle names, but only exported packages, will exist in the path mapping since we import packages and not bundle-name/package.

so what does that look like?

We still need the rmap for bundle-name to location but the requirejs.path will
only contain package -> location after those packages have been resolved to specific bundle.s

Bundle gets loaded based on path,
bundle metadata is returned,
exported packages are concatenated with bundle path to get full path.
path {
exported_package: bundle-location + exported_package
}




Seems like we can just modify requirejs to register anything under "exports" as
a new path.

This means package MUST be split by '/' and not '.'.

So this looks like:

manifest.js (or maybe just main.js):
bundleName: 'com/tantaman/web/storage',
exportPackage: [
	'com/tantaman/web/storage',
	'com/tantaman/web/storage/model',
	'com/tantaman/web/storage/view'
]

The exports become 'path' rules for requirejs!
The path rule would be:
	'package' => currentLocation + package.remove(bundleName)

This of course give access to everything unde the package..

Could remove exportPackage and just use "bundleName" for the re-write rule
of course this leads to uncontrolled exports (at first anyhow).

This rule looks like:
	bundleName => currentLocation

How do we know our current location?  The main.js's path...
We can use onResourceLoad https://github.com/jrburke/requirejs/wiki/Internal-API:-onResourceLoad
to figure out the url of the loaded module.  The framework can then
determine if the loaded item is a bundle initializer or not...
if so it'll set up the bundle root path.  How do we know if it is a bundle
initializer / bundle root?  We can get that from the feature / config.ini..
Instead of requiring bundles directly we can tell the framework that we want
them and then it can register their paths as bundle roots.  Well then we don't need onload?  Since we know the bundle roots from the config we can set up re-write rules immediately?  We need the bundle name for re-writing..

So 
1. bundle root will just be "metadata" the gets loaded
2. metadata.js will have to register itself with the framework
3. It'll have a bundle name that it provides in registration
4. well we never have the name and path at the same time... so we
can't associate them...

This means the feature.xml / config.ini will need to know
the path and bundle name?

Any way to just know bundle names?  We can do this by updating the build system?
Build system can look through bundle location(s) and generate the correct mappings... by going through the bundles in that location, looking at their meta and registering the mapping.

Maybe the config.ini just specifies the bundle names and then a resource map specifies their locations.  The resource map can be constructed at build time or created manually or use a ResolutionConfiguration and Resolver?

config.ini (feature.js / config.js) will hold the path to the resource map.

bundle/strut/editor

Allow plugins to be sandboxed via i-frames?

So an import later


Need to update requirejs:
-files within a bundle will refer to one another via relative paths?
-once loaded those files will define their external name(s) to be loadable
  from outside the bundle.

e.g.,

main:
define(['./Class1'], {})

Class1:
define('com.tantaman.Class1', {})

If no symbolic name is provided in the define then that class isn't exactly "exported"!  :)

-We need the storage interface to be completely generic (i.e. reusable across projects)
	-So we need to split that storage bundle into the generic storage interface
	and the strut specific storage interface.
->Re-visit all components and split them according to the above advice.
->Re-visit wrappers (e.g., storageProviderWrapper) and update to use ServiceCollection.

-Re-visit the command structure and redo/undo
-Multi select
-Re-visit keyboard shortcut handling.
-Make place component smarter
-Handle z-ordering on slides