On Tue, 7 Dec 2010 02:19:54 -0200 Bruno Dilly <bdi...@profusion.mobi> said:
> >> 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.
efl doesnt draw after each addition. it will draw when you are done and going
idle. if you set a mark for some date weekly you can know which cells that
affects and just emit signals to those. an emit doesnt draw anything. it just
puts a message in the message queue for edje to process later. if you call the
populate call and do it at once or you set a mark on cal for all your events,
it will have the same message queue and process it the same way when it goes
idle and produce the same results. :) of course if you implement a mark add asa
"walk all cells and if cell X matches date then emit" then u may do a bit of
excess walking of 42 cells. if you implement it as "is this unique - > then
just find the cell # it affects and emit that, if its a repeat, find first cell
it affects then add the repeat interval until u are thru all 42 cells". and it
will actually be less work. :)
> > 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:
sure - i marked the saturday stuff as deprecated with appropriate mark stuff to
replace it in the docs.
> #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.
right now that's the case. i'm squeezed in between and i'm trying to bridge the
gap and get myself out of the squeeze.
> > 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 =)
cool. the every N days/weeks/months/years is easy by adding an "int n" param
for repeat interval. how to say "2nd thursday of every october" though... i'm
not sure about :)
> >> >> 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.
no problems. :) just trying to let you know with the kind of scale of the
things to deal with - this patch as such is a small drop in that ocean.
--
------------- 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
