We need a more compact way to get to all of wagn's functionality.
The core idea is that there will be a single, unobtrusive "doorway" to the worlds of editing and wagneering that can optionally appear in any "wrapped" view (that is, any slot that's prepped for javascript actions).
The doorway will be customizable; the default will look something like this icon from connectipedia.org:
Mousing over that icon will open up a menu that looks something like:
Clarifications:
The image is only viewable by administrators, is that on purpose?
I this related to make simple edit-alternative to double click?
--John
Is titled view "wrapped"?
--John Abbe.....Sat Jun 09 00:27:26 +0000 2012
re admin: sorta on purpose. we were using this in the demo and found a bug there (fixed but not deployed). I took that rule away.
re simple alternative: yes, related. sort of a reframe, because it's not so much a one-or-the-other thing. you can actually turn double click off now, but that's in a trial phase. not documented.
re wrapped: Yes. all the views in the upper left are wrapped.
--Ethan McCutchen.....Sat Jun 09 03:15:59 +0000 2012
Presumable this will all need to be themable and packable, so we need to do some API design in all of this. The look and UI needs to be nice for base Wagn, but it also needs to be built in such a way that a pack-builder could take and extend the settings and rules in the core Wagn, and build packs to replace any part of it.
I'm thinking we need to first spec the Views API more completely. I'm sure there are other cards that already cover parts of this.
The the question for this ticket is about what view names will be used for all the parts of a card that will implement the card menus. This is the view API for card menus. Maybe just one view name :menu, and each pack could define component views but it wouldn't need to.
--Gerry Gleason.....2012-10-12 14:31:05 +0000
I would list this as pretty urgent, so I wouldn't want to hold off on a final api to get something working, but otherwise I agree. My thought is that we will want one view (something like :menu) that handles all of this, but it will use a set manipulable menu object. I don't know how all that works yet...
--Ethan McCutchen.....2012-10-12 15:59:54 +0000
In any case, I do hear your key concern that this needs to be configurable. Definitely agree!
--Ethan McCutchen.....2012-10-12 18:30:20 +0000
Yes, I also hear you about wanting to implement a basic working something first. Spec it in tests, make a prototype work, ...
We should also think about using wagn data structures and core types in creative ways for this. The setting (rule card) for codename :menu might give a pointer card that might represent the component views. Or maybe this is a new core types to represent not an array of cards, but an array of codes. Oh wait those are still cards (a pointer card type array), just the options sets are special enumerations of codenamed cards.
As you said, we spec and write something first, then talk API.
--Gerry Gleason.....2012-10-21 13:57:37 +0000
we are still refining the menu and still need to handle the "related" stuff, but this is basically implemented (mostly as designed)
--Ethan McCutchen.....2012-12-20 22:10:10 +0000