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 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. > 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. 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. :) > >> 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. -- ------------- 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
