From: Bruno D. <bd...@pr...> - 2010-10-28 21:22:16
|
On Thu, Oct 28, 2010 at 7:04 PM, Leandro Pereira <le...@pr...> wrote: > Elementary-ers, > > Sorry for the long and boring mail, but this is kinda important. > > We're working on improving the Elm_Toolbar widget. Right now, to add an item > to the toolbar, we have a couple of functions, like (namespace ommitteed for > clarity): > > append_item(toolbar, icon, label, callback, data) > prepend_item(toolbar, icon, label, callback, data) > insert_before(toolbar, before, icon, label, callback, data) > insert_after(toolbar, after, icon, label, callback, data) > > While these are okay for the majority of purposes, we need to add another > kind of toolbar item: multi-state items. Examples would include a > Play/Pause button on a media player or a "view mode" button on a file > manager (Icons/List/Tree), and you could cycle (or explicitly set) the > state. State change would be animated (theme-defined, of course). > > We thought about a lot of alternatives to solve this problem. Some were > discarded right away, and two of them remained: > > The first one would work like this (if you wanted to create a multi-state > item): > > tb = toolbar_add(parent) > it = append_item(tb, NULL, NULL, NULL, NULL) > play_state = state_add(it, 'media-play', 'Play', cb_play, NULL) > stop_state = state_add(it, 'media-stop', 'Stop', cb_stop, NULL) > > Then, you would be able to cycle between the states using functions like > state_next() and state_prev(), and of course, state_set(it, state). While As I said on irc, would be better that state_next/ prev return the next state you decide if you want to set it, remove, whatever, instead of selecting the next. And so it will be consistent with our API. > this works, I find this awkward: a element is created just to be used as a > container to the states of this button. This could be a dummy element or > something else, but cycling through this button's states would not go back to > this button again (state_set(it, NULL) would have to be used to go back to > this "non-state" state. > > The other one would work like this: > > tb = toolbar_add(parent) > it = multistate_item_new() > play_state = state_add(it, 'media-play', 'Play', cb_play, NULL) > stop_state = state_add(it, 'media-stop', 'Stop', cb_stop, NULL) > append_item(tb, it) > > While this makes for less concise code, it is also prepared to accept any > kind of toolbar item we invent in the future. This looks pretty much like > the usage of the Elm_Box' API, and makes sense since a toolbar is a (smart?) > container. Keep in mind that the common approach of adding icon items would > now require two API calls instead of just one: > > it = icon_item_new('file-open', 'Open File', cb_open, NULL) > append_item(tb, it) > > Or, a shorthand: > > append_item(tb, icon_item_new('file-open', ...)) > > Or this way, if a reference to the item is needed afterwards: > > append_item(tb, it = icon_item_new('file-open', ...)) > - or - > it = append_item(tb, icon_item_new('file-open', ...)) > > Changing states here would work pretty much like the other way of doing > this, however the dummy state would be opt-in: you would have to explicitly > create one yourself. > > This would require changing the API again, however; the prototypes above > would have to be changed to something like: > > append_item(toolbar, item) > prepend_item(toolbar, item) > insert_before(toolbar, before, item) > insert_after(toolbar, after, item) > > The 'item' variable there would accept items created by icon_item_new, > multistate_item_new, and even trator_item_new (it that is proven to be > useful in the future). > > Even though we'd need to change the API (again), I'm inclined to choose this > second option. However, Bruno Dilly prefers the first option -- so which one > should we pick and implement? Or, if anyone have any suggestions on another > way this could be implemented, please shout. In fact, and let me try to explain some points that make me think the first one is better: 1) You don't need to change the API again for a corner case. Actually you could just change the icon and the label in your callback or listen to clicks on your icon theme (and animate the way you want). If you guys think multistate icons will make the people life easier, ok, but you can do this just adding some functions. 2) You don't need to create an item, and then add it to the widget, since always you'll be creating it to add to the widget and you can't add it more than once or in more than one widget. 3) You don't need to have two different kind of items. They're basically the same, and you could change between them just adding / removing states anytime. 4) With the first one you can have something to display if you are not setting a state. What will be displayed when you add a multistate_item and did not set any state? In the first case you know, it will be what you explicitely passed as argument. With the multistate_item_new will be something implicit and you won't have any way to change it. You will have a call icon_item_new(toolbar, icon, label, callback, data) and a multistate_item_new(toolbar, callback, data), but in the end, you will have dummy items anyway. Why do you think that the second is better than the first one? Because you won't need to pass 2 NULL arguments ? Regards > > Cheers, > Leandro > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North America contest > Create new apps & games for the Nokia N8 for consumers in U.S. and Canada > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > http://p.sf.net/sfu/nokia-dev2dev > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |