Re: [E-devel] RFC: New Elm_Toolbar API

[Dave A. <da...@gu...>]

2010/10/28 Leandro Pereira <le...@pr...>:
> 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
> 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.

I would prefer the second option as its more extensible in future and
the api is cleaner. At this point of elm development API breaks are
not a problem, is better to break now instead of keep a bad api
around.


So I vote for having different *_item_new() and then pass the item to
the toolbar.
BUT: to be consistent you must also move item_menu_set() and
item_separator_set() to the new way,
thus:
  icon_item_new()
  multiselect_item_new()
    AND
  menu_item_new()
  separator_item_new()

The main reason i choosed the second option is for future expansion: I
would like to also have:
  slider_item_new() ex: image-viewer: for controlling the zoom
  entry_item_new() ex: browser: search box


BUT 2: In this way we will probably end with tons of *_item_add()...
did you thinked at a more general solution?

Could be something like:
toolbar_item_append(tb, char *icon, char *label, Evas_Object *custom, cb, data)

example usage:
 tb = toolbar_add(parent)
 // add a 'normal' item
 it = toolbar_item_append(tb, icon, label, NULL, NULL, NULL)

 // or add a slider
 sl = slider_add(parent)
 ... here setup the slider with properties and cbs
 it = toolbar_item_append(tb, NULL, NULL, sl, NULL,NULL)

 // or also a custom  with label & icon too
en = entry_add(parent)
it = toolbar_item_append(tb, icon, label, en, NULL, NULL)

In the function toolbar_item_append() we can then set the
style of the custom item to "something/toolbar" so that we can have different
style for widgets when they are inside a toolbar.
What do you think about this? seems more general that your
proposal

Dave

>
> 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
>