On Mon, Dec 6, 2010 at 10:58 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Mon, 6 Dec 2010 12:22:00 -0200 Bruno Dilly <bdi...@profusion.mobi> said:
>
>> On Mon, Dec 6, 2010 at 11:08 AM, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>> > On Mon, 6 Dec 2010 08:46:54 -0200 Bruno Dilly <bdi...@profusion.mobi> said:
>> >
>> >> On Fri, Dec 3, 2010 at 5:58 AM, Enlightenment SVN
>> >> <no-re...@enlightenment.org> wrote:
>> >> > Log:
>> >> > From: samsung.
>> >> >
>> >> > some added features to calendar. along with fixes of those features so
>> >> > they work right.
>> >> >
>> >> >
>> >> >
>> >> > Author: raster
>> >> > Date: 2010-12-02 23:58:43 -0800 (Thu, 02 Dec 2010)
>> >> > New Revision: 55177
>> >> > Trac: http://trac.enlightenment.org/e/changeset/55177
>> >> >
>> >> > Modified:
>> >> > trunk/TMP/st/elementary/src/lib/Elementary.h.in
>> >> > trunk/TMP/st/elementary/src/lib/elm_calendar.c
>> >> >
>> >> > Modified: trunk/TMP/st/elementary/src/lib/Elementary.h.in
>> >> > ===================================================================
>> >> > --- trunk/TMP/st/elementary/src/lib/Elementary.h.in 2010-12-03
>> >> > 06:14:30 UTC (rev 55176) +++
>> >> > trunk/TMP/st/elementary/src/lib/Elementary.h.in 2010-12-03 07:58:43 UTC
>> >> > (rev 55177) @@ -2309,6 +2309,10 @@ EAPI void
>> >> > elm_calendar_marks_clear(Evas_Object *obj); EAPI const Eina_List
>> >> > *elm_calendar_marks_get(const Evas_Object *obj); EAPI void
>> >> > elm_calendar_marks_draw(Evas_Object *obj);
>> >> > + EAPI void elm_calendar_text_saturday_color_set(Evas_Object
>> >> > *obj, int pos);
>> >> > + EAPI void elm_calendar_text_sunday_color_set(Evas_Object
>> >> > *obj, int pos);
>> >> > + EAPI void elm_calendar_text_weekday_color_set(Evas_Object
>> >> > *obj, int pos); +
>> >>
>> >> Why are you adding these fugly functions on elm_calendar API ?
>> >> If you need that the calendar displays customized colors you can do
>> >> this using a theme (you could use calendar items macro CIT to create
>> >> CIT_SUN, CIT_SAT and CIT_WEEKDAY with different texts parts). If you
>> >
>> > it may want to mark days as holidays and special days based on dates etc.
>> > (public holidays marked as sundays etc.). the code emits signals to the
>> > theme to handle the state change. it's abstracted. only thing i'd do is
>> > make the color an "enum" instead of 3 calls. internally it is an enum.
>> >
>>
>> Sure, for that I've created calendar marks. You can add a holiday
>> based on dates, and it supports even repetition.
>> It doesn't use a enum, it uses strings to define the kind of holiday,
>> and it is emitted to the theme, so if you need more kinds of holidays
>> to have different representations on the theme, you can have it, not
>> touching the widget code =)
>
> they looked like they were for different purposes - marking days for events,
> as
> opposed to marking simple regular things such as weekday vs sat/sun. that
> makes
> it a bit of a pain actually :/ i can't implement compatibility api's easily.
> the mark api has its problems. why is there a marks_draw? why doesn't it just
> implement them as you go? it has to linearly walk and apply them anyway. this
Because maybe you want to add N marks, It doesn't make sense
to draw after each addition. Like you said it will linearly walk, So walking
after all of these additions is much worse than walking only once after
everything was added.
> adds an extra step than isn't needed. it also has no code to filter out the
> same mark being added multiple times to the same days (eg you mark every
> saturday as a holiday 2 times). anyway - it didn't look to be clear that marks
> were for indicating regular "days of the week". more like marking them for
> holidays, events, birthdays etc.
Indeed, I included this for indicating holidays, days of the week are indicated
by the theme. If you need to show different background images on
sunday, saturday
and weekdays, just modifying CIT (calendar item) macro on theme to use different
colors or images is enough. So you would have something like:
#define CIT(_pos, _text_color) \
blablalba
group { calendar
parts{
...
CIT(0, sunday_text_color) CIT(1, weekday_text_color) ...
But if for some reason do you need code to do that, I suppose marks
are the way to go.
>
>> I've created elm_calendar with a nice documentation compared to the
>> rest of the library, IMO. It contains even code examples, so if you
>> check it, you can see that you could add holidays easily.
>> It have some tests too covering the entire calendar API, if I remember
>> correctly.
>>
>> If some use case is not well covered, people should send an email
>> about it and we could discuss the better way to do what is needed.
>> Until now I don't even know why do you need these functions. Not even
>> a test for the calendar using this was provided, so I could try to
>> understand the need reading it. You don't even worry about explaining
>> this "new feature" in the commit msg...
>
> because i have 100,000 lines of patch to deal with that i didn't write -
> written by a dozen or more people and frankly i have 20+ other things to do
> all
> day too in addition to this. if for every feature i have it turned into a
> "well
> lets god and discuss this and turn it into a 2 day effort of sending mails
> back
> and forth" i may as well quit now. there will never be any merge. it simply
> wont happen. efl wont get released as frankly people will code features faster
> than i can do this. as such i am trying to big-bang bring 2 forked trees
> together. as long as this stays here and not in our svn peolpe cant see or
> even COMMENT on anything - the bottleneck is me and i'm the only one seeing
> both sides.
>
> they have forked over a period of like 6+ months. they are also one of our
> biggest efl users who have added 48 files to elementary (new widgets - 40,000
> lines of code, not including a module or 2) and done a lot of changes, a lot
> of
> which are very useful. we can be obstinate and a pain in the arse to deal with
> questioning every little thing and having to send patches around and turning
> an
> effort to bring 2 things together into a 12+ month drawn-out ordeal... a few
> months into which they will just say "screw it - you guys are too much of a
> pain to deal with" and we will either have a permanent fork or they will cease
> using EFL, or we can accept some pain and try and get it done and reap the
> benefits of their work. if i merge and commit it means the stuff gets at least
> looked at and commented on. if i turn each thing into a "well mail a patch and
> lets debate it" we'll have 100's of patches floating about for years. just for
> the current work.
>
> if you think for every feature, finding out why it exists and what it's meant
> to do is simple, think again. it already takes me a few hours to isolate the
> changes and read them over and clean them up just for this above kind of
> thing.
> it would turn that into many more hours finding the people involved,
> explaining
> to them what i wanted to know - if i even wanted to, so what is done in less
> than a day now takes 2-3 days, if not more of finding "why's", and sending
> mails here, debating things etc. i have 100k lines of differences to deal
> with.
> let's say thew calendar changes were 1k. instead of being done in 3 months i'm
> going to take another year. in which case theres another 200k lines of changes
> by then (as the current 100k built up over something like 6 or so months).
> hooray.
>
> i can't change what HAS happened. i'm trying to deal with it as best as
> possible. i can fix what will happen in future. i have hopefully done that by
> now with samsung now engaging e development upstream directly as they work on
> things. but fact is there is an existing mess to clean up, and i'm trying to
> do
> it and get it done. if you ever want to see efl released, that is. it's not
> getting released until at least the CHANGED code (not new features/widgets)
> are
> merged with elementary. if i spent the kind of effort you indicate for just a
> feature of calendar on everything - new widgets included, nothing will
> actually
> be finished - ever. if you have issues with the changes, say so, but i can't
> turn every change into a debate prior to doing it - i simply have no
> choices...
> well i do. i can just say "go away samsung. we don't want you". that'll be
> awesome for efl, won't it? i am trying to strike a compromise than gets
> everyone benefit. but compromise means some level of pain for everyone. i
> reduced the changes to elm calendar already AND i fixed bugs with the
> saturday/sunday/weekday thing while i was at it when i committed it. so i am
> not just taking whatever is there and blindly applying it.
Raster, I know it's not you fault if they weren't working with the
upstream since the beginning.
And I agree with you, strategically it's really good for our community
to have Samsung working with EFL.
The only thing that I suppose would be better is that if the
developers that made these patches talk to us, we could achieve a
library with more quality, and you wouldn't be a bottleneck.
But if it's the way to go, I won't spend our time discussing about it
anymore. As you said, you're the only one seeing the both sides.
>
> anyway - what i added doesn't break elm_calendar - it adds a feature in a
> different way to the marks you have. the marks you have have issues of their
> own (as above), now i review them in detail. i'm happy to deprecate these api
> calls. we need to add a lot of deprecated api calls into elm for this merge to
> work anyway. marks are also missing bi-weekly(n-weekly actually), bi-monthly
> (n-monthly), every n years (where n is 1 or more, not just annually), every n
> days, (where n is also > 1 not just daily). well since you provided a repeat
> mechanism at all... :) probably should handle "first thursday of every month"
> or other such ones too. :)
>
Yeah, I liked the idea, some more repetitions options can be included =)
>> >> need to
>> >> dynamically set colors sending a signal, ok, you can do this using
>> >> elm_object_signal_emit.
>> >
>> > then people have to hand-craft those signals and know what they are, do the
>> > printfs.. AND when theme and scale change.. re-emit them based on state.
>> > check the code in more detail. so basically that emit wouldnt work. simply
>> > put. in fact all emits will fail to retain state on theme or style change
>> > etc.
>> >
>>
>> Indeed, you can't guess what signals should be re-emitted in these cases.
>>
>> >> I honestly didn't understand why do you need this here. And would be
>> >> nice if you could split patches indenting, fixing stuff, and adding
>> >> new features, so I could revert stuff more easily.
>> >>
>> >> Instead of removing stuff like elm_label_text_color_set you're adding
>> >> more stuff that should be changed on the theme =/
>> >
>> > you have no idea how much i have to do. label text color is the least of
>> > any
>> > worry i have. it's marked as a dangerous call. i relented after much
>> > argument on it and keep it for special cases but make sure you don't get
>> > away with it without much complaining.
>>
>> I know that you have a lot to do, that you are absurdly busy, but it's
>> still a free project, involving lot of people contributing.
>>
>> When I contributed this widget I was running against the clock (as
>> usual), but I've researched how gtk and qt calendar widgets are used,
>> tried to think what use cases should be covered (not only the use
>> cases for the fridge project) and how to provide flexibility keeping
>> the smaller API I could. Now I see these functions. It makes me sad,
>> honestly.
>>
>> I still want to know what use case is this, why these functions
>> deserve to be there. It doesn't make any sense for me.
>
> i don't know. they are api's that seemingly are deemed useful or important.
> for
> whatever reason. if you wish to read the 100,000 lines of diff or 540,000
> lines
> of history, i'll gladly send them to you. i have barely even started with most
> of the changes.
I was trying to help with patches sent to the mail list.
As I'm traveling this month, probably I will be very inactive.
Regards
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
>
------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
