Re: [E-devel] RFC: elementary api changes, drop and unifications

[Iván B. (S. <sac...@gm...>]

I'll use the classic "I'm drunk" excuse to top-post. If you don't like
it, I have a bunch of "go fuck yourself" responses for you to choose.

>From my point of view, the EFL as it stands now has two conflicting
philosophies: That of Evas+Edje and that of Elementary.

Evas and Edje make for custom interfaces in any way the developer wants,
forgetting years and years of toolkits forcing their way into the layout of an
application.
Elementary, on the other hand, uses that power to change the look of an
application that still follows the teachings of old, but still leaving
all of the
responsibility of how the layout will be to the programmer.

These are two fundamentally different ideas that have to be taken into account
every time we pretend to decide which is the course to follow. It is
not possible
to follow the generic way of Evas+Edje with Elementary if we want the toolkit to
be an easy way for programmers to build applications, nor can we
pretend Elementary
to be easy to use if the intention is for it to be so generic that
every user can
have his own idea of how things should look by just playing with the
theme without
having to mess with a single line of code.

That's my biggest conflict with it and probably the reason why things
like hoversel and
hoverlist, toggle and magnetslider, flippicker and diskpicker, among
others exist. It's
the difference between having a base of code that lets you do
something and having
the theme decide how that option will be presented to the user, and
having a bunch of
pre-made widgets that any developer can plug anywhere so the user
always sees things
in the same way but with more or less rounded corners.

So, before getting into a big debate on what should be there and what
should not, I believe
it's important to state where each of us stands, because we risk a lot
of time getting lost
discussing things that are not just an opinion on how to do something
specific, but how to
express the idea of how that specific should be done. Lots of time has
been wasted on this
already if you go through mailing-list archives and IRC logs, and I
don't think it's worth it.

Personally, I believe there's nothing wrong with having two toolkits
available, as long as it
doesn't end in the EWL vs. ETK that we've been through already. One of
them would be the
easy to use, quick builder of simple applications that anyone new to
"the new way" of building
things can use, and another one that is a thin layer on top of Evas
and Edje to provide some
helpers, common cases and just-glue for those that don't want the
common widgets and prefer
to have everything done their way, while still getting the benefits
pre-made toolkits provide, like
config (fingersize, scale, thumbscroll) or focus mechanism. All of
this can be arguably done in
one toolkit, but we have either started with the wrong foot or proved
that that's not the case.
All in all, after so many years of development and people outside
obviously not grasping so
easily the Evas+Edje way, I guess that thing of having two toolkits
it's not something we want
to start a release with, but we can't pretend to have something that
goes both ways when
even those that are already part of the community don't still grasp the concept.
And before that last phrase starts a flamewar, go into Elementary's
code and look through
its history how different widgets were written. I'm pretty sure you'll
find my point proven
that way.

On Sat, Oct 23, 2010 at 9:05 PM, Gustavo Sverzut Barbieri
<bar...@pr...> wrote:
> Given the discussion started by Dave in the other thread, I'd like to
> check the overall opinion on the following:
>
> UNIFICATION
>    - check + toggle = toggle. just different styles. Default style is
> the best for each environment, but one can still force toggle or
> check.
>    - panel + panes = panel. make a hide action, and enable/disable
> this action. make resizeable behavior configurable.
>    - image + photo = image. refactor fill property to make it work
> with inside/outside (bool -> enum)
>    - menu + hoverlist = menu, with hoverlist-based implementation?
> menus currently lack scroll, and we're about to move sub-menus to
> their own widget anyway.
>    - diskpicker + flippicker + carousel = carousel (name) with
> implementation that manages choosing items from a collection. In an
> ideal world the theme would say how many pre/post elements it handles
> and the item would have to implement an Elm_Carousel_Item_Class with
> label_get, icon_get and del. This would enable, based on the widget
> style, presentation of icon, label and in any number (think of a music
> coverflow that the central element shows the artist and album names).
>  QUESTION: how to handle interactions? just catch some gestures and
> report them as signals, like "elm,action,swipe,left"?
>    - spinner + slider = range(?). basically they allow selecting a
> number from a range, but one allows editing while the other does not.
> spinner is particularly bad WRT usage atm.
>
>
> CHANGES
>    - rename colorpicker to colorselector (matches fileselector)
>    - hoversel to combobox or selection_box? (not really sure if
> needed, but people know it with that name)
>
>
> DROP
>    - elm_check (see unification)
>    - elm_frame (useless, same as elm_layout)
>    - elm_bubble (useless, same as elm_layout. provides useful
> automatic send of signals, but it is very specific purpose and these
> signals could be made automatic inside elm_layout, helping generally
> when parts need to behave differently whenever swallows were done).
>    - elm_notepad (quite useless as it does not export much of
> editing, just links changed signal to save the file. I'm more more
> inclined to drop it and in future releases just something else with
> toolbar to control styles, like bold, italic, font faces and so on...
> without actually saving the file, that's the simplest part of it, the
> style management is the hard part)
>    - elm_separator. yet another layout thing being moved to application.
>    - elm_list. it had a reason as we did not had elm_genlist. However
> we could have some helpers for genlist, like some canned item classes.
>
> I know I'll be bashed again by Raster, but I'd like to request
> consideration to drop the following as well:
>    -  elm_label. It's just a stupid legacy we carry from elsewhere
> and have no good purpose in EFL. The only use of it right now is to
> workaround the lack of ellipsis in Edje's TEXTBLOCK, we could just
> move this work around inside Edje until someone does the proper fix,
> that way we also get ride of complaints why Edje's part do not work.
>    - elm_table and elm_box. Also a stupid legacy we carry from
> elsewhere. Having them, and particularly using them ourselves do no
> good other then redirecting people from the correct way to do layouts:
> elm_layout. We can just have canned layouts for vertical and
> horizontal boxes, avoiding applications to set things like padding for
> themselves, doing so is bad as we all know... they would just do
> another layout and use it, with paddings being in theme and not
> application.
>
>
> I know there are some "hard" changes here, like touching elm_list and
> elm_check... but as we did not label it 1.0, we could avoid getting
> them on 1.0... or if we do, do with EINA_DEPRECATED marks and remove
> them at 1.1
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: bar...@gm...
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> ------------------------------------------------------------------------------
> 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
>