On Mon, May 18, 2015 at 4:53 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Sun, 17 May 2015 09:36:44 +0200 Davide Andreoli <d...@gurumeditation.it>
> said:
>> 2015-05-15 19:50 GMT+02:00 Cedric BAIL <moa.blueb...@gmail.com>:
>> > Le 15 mai 2015 16:26, "jiin.moon" <jiin.m...@samsung.com> a écrit :
>> > >
>> > > hermet pushed a commit to branch master.
>> >
>> > http://git.enlightenment.org/core/elementary.git/commit/?id=e707aa3efb0b4a0b7d6169755075a9943793e4f5
>> > >
>> > > commit e707aa3efb0b4a0b7d6169755075a9943793e4f5
>> > > Author: jiin.moon <jiin.m...@samsung.com>
>> > > Date:   Fri May 15 23:09:41 2015 +0900
>> > >
>> > >     elementary: Create new widget for image masking
>> > >
>> > >     Summary:
>> > >     For now, if apply image mask to smart obejct, masking does not work
>> > except to implement in edc file.
>> > >     @feature
>> > >
>> > >     Reviewers: Jaehyun_Cho, Jaehyun, jpeg, raster, cedric, Hermet
>> > >
>> > >     Subscribers: raster, jpeg, cedric
>> > >
>> > >     Projects: #elementary
>> >
>> > As per my comment during review this brash all the concept of efl, edge and
>> > elementary for no good reason. It should not have landed. If you want to
>> > implement theme in c do it properly by providing a virtual edje file that
>> > impotent a group in c.
>> >
>>
>> I totally agree with you Cedric, this widget make no sense, break the
>> themability of apps and increase the number of widgets for no good
>> reason
>
> i think this is where a disconnect is. the people DONT WANT A THEMABLE APP. 
> the
> request for this comes from developers who are given and EXACT UI design for 
> an
> app and must follow EXACTLY THAT. the app is not EVER themable. they don't 
> want
> it to be.

By people, you mean a certain class of developers. The same people who
wanted Disk Selector I am sure.

> as per my comment. forcing people to learn edc, edje etc. just to do something
> simple raises the bar and learning curve, forcing them to do something they
> don't even need or want (to make their app themable), and thus just drives
> unhappiness and complaints on "efl is so hard. i hate it.". imho edje (edC) is
> an advanced topic and developers shouldn't be FORCED into it if all they want 
> is
> to, for example, mask their images with a circle. A widget that simply does
> this for them in a simple way "point to circle image for the mask and point to
> the image to be masked by it), and that's it - saves a lot of time and
> headaches for them.

I agree with you, but logically if they need so much that mask in
there app, that means it should be part of the design of the theme
they use on that device. If that is not the case and every application
want to have a custom looking theme and they still don't want to learn
edc to do their own theme. The logical solution is for us to provide a
"virtual edje" that make it possible to implement a paint callback the
way they want in C without making elementary an inconsistent toolkit
(to say the least).

> if you want to ake your logic further, then elm shouldn't have table, or box
> objects - edje can do this. in fact it doesn't need buttons, because edje can
> do this. same with checkboxes or radio buttons, sliders. why have any widgets
> at all - we can just do it all in edje with edc files?

Yeah, pushing the logic to absurdity that a good point. Elementary is
a skinnable toolkit. Edje is used to define that skin, not the
behavior. You are just throwing a bigger insane argument just to force
us to stay silent, but that doesn't make our point wrong. With your
logic we should dump all edje code from elementary and use evas
directly, because edje is to hard. So back to the topic...

> this is just trying to force people to do something they don't need or want to
> do. it's their choice here. if they don't want it themable - then that is 
> their
> choice. in fact you are not going to change that choice. the choice is made by
> ui designers already who do not WANT things themmable. they want things to be
> pixel-for-pixel exactly as designed and not able to be changed.
>
> WE here want themable. we want flexible. we wn users to be able to re-skin
> their apps all over the place, but others do not.

I know, but until now we have tried pretty hard to address the goal of
both project correctly (Except for a few widget that should not have
entered into elementary at all, but at least they are themable). Here
you are forcing a useless widget inside Elementary that if used by any
application will make it impossible to change theme. That we will have
to maintain forever. While they could put that into one of their
specific library and ditch it like they do every 3 months. They
already have such a library to put all this "helper" in. I don't see a
good reason to take on the burden of something that is short-sighted
here. You have said it clearly, it doesn't match Elementary design and
goal at all, so it shouldn't be here.
-- 
Cedric BAIL

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to