Hi,

On Fri, Sep 13, 2013 at 12:23 AM, ChunEon Park <her...@naver.com> wrote:
> Particle effect: unless I get you wrong, shouldn't that be an edje theme?
>
> -> it depends on the ux/particle quality, Still you wonder, then see the link.
>
> https://www.google.co.kr/search?newwindow=1&q=particle&bav=on.2,or.r_cp.r_qf.&bvm=bv.52164340,d.aGc,pv.xjs.s.en_US.CQsooEYev9Y.O&biw=1112&bih=935&dpr=1&um=1&ie=UTF-8&hl=en&tbm=isch&source=og&sa=N&tab=wi&ei=tnMyUpLYCcfOiAfdtoDQBg#hl=en&newwindow=1&q=particle+effect&tbm=isch&um=1&facrc=_&imgdii=_&imgrc=ZgsEWgoyoZTI9M%3A%3BU2eY1pT0aJ422M%3Bhttp%253A%252F%252Fb.vimeocdn.com%252Fts%252F190%252F214%252F19021456_640.jpg%3Bhttp%253A%252F%252Fvimeo.com%252F5610625%3B640%3B480
>
>
> You are adding API without talking about it, or showing any use case.
> Real life use case. Or at least showing there is one in some secret lab.
> This way we end up with a lot of API no one uses we have to support and
> document.

From what I can remember, we do need some API like this, or at least
some way to detect the genlist item geometry. At least from my
previous experience, every time that we needed something like this, we
were doing a workaround for the problem that there was no such way to
fetch that geometry.

Adding things to the genlist item theme might work in some (most?)
situations, and should be preferred when possible. But sometimes you
just need to position some other object relative to the genlist item
position, not necessarily inside the genlist. I don't believe that
changing the genlist item theme will solve all the problems, not even
that will be the cleaner / most elegant solution. Saying that seems to
me much like arguing that using "goto" in C is bad.

On the other hand, this API might, and probably will, get abused, and
things that could be done entirely in the genlist item theme will be
done externally. So it would be good to enforce when it's case that we
really need to use it.

Regarding the API added by Hermet, I would have to try and write some
code that uses it, have bugs, etc, before having a strong opinion in
favor of or against  it, but I'm glad that this was proposed.

PS: I'm not against adding this API, or even the old (object_get) one,
I was just against the fact that it was first removed after some
discussion, and then added back again.

> -> But already i asked better solutions when we were talking about before.
> even Bluezery mentioned the requirement in the mailing list.
> I could understood the requirement at the moment as well as people may need 
> this kind of api.
>
> You should answer to him first before you argue me.
>
> I believe Gustavo was trying to get more information, in order to try
> and think of an alternative solutions or means of achieving what you are
> trying to achieve.
>
> -> Of course, we should ask if some commits seemed wrong. So I replied to him.
>
> Finally, I said,  since i managed the elm for years, I've added many apis 
> that i thought it could be.
> In this case, it's same.  If i try to add new apis to eeze, then i would ask 
> to zmike/people for agreement.
> Even this doesn't meaned that i was true, but sometimes we should belive the 
> person who manages the module.
> Otherwise, we all should have agreement  by all people whenever he try to 
> change/modify the module.

+1 to this argument. However, remember that Elementary is probably our
biggest example of library that got lots of unnecessary APIs / widgets
added, and the first thing that comes to mind when a new API is added
to it is: "Oh, is this really needed?"

> This is opensource. a few maintainers are watching the commit list.
> We can ask what the commit is pushing in (especially, if the module you are 
> managing is modified by other)
>
> If all they are missed the commit (this means they all are busy in 
> maintaining the module. )
> then I think we should believe the committer who knows the situation better 
> than any others.
> Otherwise, our opensouce will be just stagnant.
>
> ------------------------------------
> -Regards, Hermet-
>
>
> -----Original Message-----
> From: "Tom Hacohen"<tom.haco...@samsung.com>
> To: "Enlightenment developer list"<enlightenment-devel@lists.sourceforge.net>;
> Cc: "ChunEon Park"<her...@naver.com>; 
> <enlightenment-...@lists.sourceforge.net>;
> Sent: 2013-09-13 (금) 00:52:07
> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary - 
> introduces 3 apis elm_object_item_track/untrack/track_get().
>
> On 12/09/13 16:37, ChunEon Park wrote:
>> Many cases can be.
>>
>> for example,  in case of fancy application.
>> user wanna add a particle effect when a list item is selected.
>>
>> in that case, item geometry may be required.
>>
>
> Same comments as about the previous commit + more.
>
> Particle effect: unless I get you wrong, shouldn't that be an edje theme?
>
> Same comments as about the previous commit:
> You are adding API without talking about it, or showing any use case.
> Real life use case. Or at least showing there is one in some secret lab.
> This way we end up with a lot of API no one uses we have to support and
> document.
> Also, because you don't talk about them on IRC or the ML it feels like
> you are trying to sneak them under the radar.
>
> For many APIs there can be many use cases, even for APIs that do nothing
> whatsoever, but that doesn't justify them. Especially since there might
> be better solutions.
>
> I believe Gustavo was trying to get more information, in order to try
> and think of an alternative solutions or means of achieving what you are
> trying to achieve.
>
> I'm not trying to belittle your work, and I haven't read the patch
> myself. I skimmed over it when I first saw it, and decided to keep quite
> because arguing against the previous API lead to nothing. Everyone was
> against, and it's still there.
>
> --
> Tom.
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Rafael Antognolli

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to