Sorry, I was replying to the earlier email about deleting blips. There is no connection between the undo stack and the colour picker :)
To answer your question about external controls, there is no reason in principle to avoid using them, but I would exercise caution: - External controls may have lots of their dependencies, and using just 1 external control may greatly increase the compiled code size and compile time. Please measure the before & after to see if how big the impact is (also, using SoyC is a big help) - Consider adding a runAsync split-point to avoid pulling in the extra code until the colour picker is required. In short, use your best judgement, taking into consideration the above points, as a general rule. In this specific case there's the issue of the licence, I'm not an expert but I think the GPL is not compatible with the apache licence, i.e. we'd have to convert all the wave code to GPL in order to use other GPL code (it would be different if the colour picker were LGPL). Someone correct me if I'm wrong? Dan On Tue, Jan 3, 2012 at 10:14 PM, Ben Hegarty <heg...@gmail.com> wrote: > ok, but I'm confused, what the connection between the undercurrent undo > stack and a color picker for the edit toolbar? I really just need to know > if we're allowed to use external controls within wiab.. or have I missed > the point? :) > > Ben > > On Tue, Jan 3, 2012 at 2:02 PM, Daniel Danilatos <dan...@danilatos.com>wrote: > >> A good UI principle is to make things really easy to do, but also have >> an easy way to undo them. >> >> This may end up being a large project, but: ideally I think deleting a >> blip should be as simple as hitting the delete key when the blip is >> selected; as soon as that happens, a butter bar appears at the top >> with a message such as "Blip deleted. _Undo_" (with "undo" being >> clickable). Thus it's easy to delete, but also easy to revert an >> accidental deletion. >> >> The "large project" part here is implementing wave-level undo, which >> as far as I'm aware isn't done in Undercurrent (though it's done in >> the editor). Google Wave had it implemented in a rather complex way >> that tried to avoid sending certain types of actions that were undone >> to the server, but we could probably do it fairly simply by not >> worrying about those cases for now. >> >> Conceptually, I think it's straight forward, as we're mostly just >> undoing/redoing changes to the manifest document; though in practice >> the plumbing may or may not be simple, I'm not familiar enough with >> that part of the code. >> >> I'm actually interested in this too so I'd be happy to help out if >> anyone wants to work on it. >> >> Dan >> >> On Fri, Dec 30, 2011 at 8:59 AM, Zachary “Gamer_Z.” Yaro >> <zmy...@gmail.com> wrote: >> > I think it would help even to make the delete happen onclick instead of >> > onmousedown. I have accidentally deleted blips when I just missed the >> > button I meant to click, but unlike Gwave, I cannot just drag my mouse >> away >> > before releasing the button. >> > >> > —Zachary “Gamer_Z.” Yaro >> > On Dec 29, 2011 7:00 PM, "Thomas Wrobel" <darkfl...@gmail.com> wrote: >> > >> >> How about a popup tickbox for "enable delete", so the first delete >> >> takes two clicks, but the rest only one? >> >> >> >> On 29 December 2011 23:28, Ali Lown <a...@lown.me.uk> wrote: >> >> >> There was some starter project that wasn't fully implemented - to >> add a >> >> >> verification popup when deleting a blip. >> >> > >> >> > I often end up moderating/cleaning-up the wave with my friends in. On >> >> > Google wave this require opening the drop-down menu which takes time. >> >> > I really like the way it can easily be done on WIAB and the fact the >> >> > next blip's delete button auto-aligns into the same space making it >> >> > very efficient to delete whole chains of irrelevant blips. >> >> > Opening a confirmation dialog would be a severe irritation, when I >> >> > feel the delete button is sufficiently clear as is. >> >> >> > > > > -- > blog:http://thelifeofbenhegs.blogspot.com/ > phone: +447767-322-122
