Menu
▾
▴
phpicalendar-devel — Mailing list for PHP iCalendar Developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(159) |
Nov
(123) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(11) |
Mar
(21) |
Apr
(29) |
May
(13) |
Jun
(2) |
Jul
(13) |
Aug
(5) |
Sep
(14) |
Oct
(21) |
Nov
(71) |
Dec
|
| 2004 |
Jan
(18) |
Feb
(12) |
Mar
|
Apr
(6) |
May
(29) |
Jun
(9) |
Jul
(3) |
Aug
(4) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(20) |
| 2005 |
Jan
(6) |
Feb
(27) |
Mar
(4) |
Apr
(16) |
May
(61) |
Jun
(6) |
Jul
(4) |
Aug
(18) |
Sep
(19) |
Oct
(5) |
Nov
(55) |
Dec
(30) |
| 2006 |
Jan
(11) |
Feb
(9) |
Mar
(9) |
Apr
(26) |
May
(17) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(20) |
Oct
|
Nov
(6) |
Dec
(9) |
| 2007 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(8) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(17) |
Mar
(11) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Waitman C. G. <wa...@em...> - 2002-11-09 02:18:56
|
mozilla works ok, but seems buggy. you have to download and install the latest mozilla browser (http://mozilla.org) and then go to http://mozilla.org/projects/calendar and click on the install link. you CAN edit the files by hand with a text editor, if that is what you are after. the best thing i have seen so far, with regards to operational stability, rfc compliance, and available supported features is Ximian Evolution (http://ximian.org) I use this on a daily basis and haven't noticed any trouble. sadly i don't believe this is available on windows. it may run under cygwin, not certain. Best, Waitman Gobble EMK Design Buena Park, California +1.7145222528 http://emkdesign.com On Fri, 2002-11-08 at 17:56, Jordan Miller wrote: Anyone know of a good program to edit iCal files in Windows? I'm hoping to implement phpicalendar in a mixed windows/mac environment, with windows users who need to contribute events but are afraid of using a mac... Jordan ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Phpicalendar-devel mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Jordan M. <jm...@MI...> - 2002-11-09 01:56:42
|
Anyone know of a good program to edit iCal files in Windows? I'm hoping to implement phpicalendar in a mixed windows/mac environment, with windows users who need to contribute events but are afraid of using a mac... Jordan |
|
From: Waitman C. G. <wa...@em...> - 2002-11-09 00:38:04
|
thanks bill,
and i agree. it is definitely not a priority - i don't really see it in
use.
also, modifying my parser to handle xcal was a snap. you are correct
that it is trivial.
best,
Waitman
On Fri, 2002-11-08 at 15:43, Bill Fenner wrote:
I think that:
1. xCal parsing should not be a high priority (better to improve the
iCal parser), but
2. xCal parsing should be relatively trivial since xCal is a representation
of the same exact data structure as iCal -- some of the stuff in ical_parser
(esp, the repeat stuff) could be factored out into common code.
Bill
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Phpicalendar-devel mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
|
|
From: Bill F. <fe...@re...> - 2002-11-08 23:43:58
|
I think that: 1. xCal parsing should not be a high priority (better to improve the iCal parser), but 2. xCal parsing should be relatively trivial since xCal is a representation of the same exact data structure as iCal -- some of the stuff in ical_parser (esp, the repeat stuff) could be factored out into common code. Bill |
|
From: Waitman C. G. <wa...@em...> - 2002-11-08 22:40:58
|
sure thing, i was more interested in knowing about applications that use
the format. mozilla will import (i think) and export (definitely)
however it doesn't really use it for anything as far as i know.
thanks
waitman
On Fri, 2002-11-08 at 14:21, Chad wrote:
From what I read xCal wasn't final yet, even so I only think Mozilla
currently can support it. That's a bridge I'm sure we'll have to cross
down the road, but we're quite a ways away from it.
For VTODO I just want us to continue on what was currently stated in
earlier threads. I'm hoping to start the prefs page this weekend and
well as looking at cleaning up the bottom of month a bit.
-C
On Friday, November 8, 2002, at 07:43 AM, Waitman C. Gobble wrote:
> i'll give it another go if you like.
>
> question, is there any use to support the xcal format? i am not sure if
> this format is in use anywhere.
>
> waitman
>
>
> On Thu, 2002-11-07 at 11:56, Chad wrote:
> So who was working on adding VTODO support to the parser? Now is
> the
> time to start looking at it for 0.9.
>
> -C
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Phpicalendar-devel mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
|
|
From: Chad <ch...@ch...> - 2002-11-08 22:24:23
|
From what I read xCal wasn't final yet, even so I only think Mozilla currently can support it. That's a bridge I'm sure we'll have to cross down the road, but we're quite a ways away from it. For VTODO I just want us to continue on what was currently stated in earlier threads. I'm hoping to start the prefs page this weekend and well as looking at cleaning up the bottom of month a bit. -C On Friday, November 8, 2002, at 07:43 AM, Waitman C. Gobble wrote: > i'll give it another go if you like. > > question, is there any use to support the xcal format? i am not sure if > this format is in use anywhere. > > waitman > > > On Thu, 2002-11-07 at 11:56, Chad wrote: > So who was working on adding VTODO support to the parser? Now is > the > time to start looking at it for 0.9. > > -C > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Jared <xe...@si...> - 2002-11-08 16:36:45
|
What I meant was, I thought version xCal was version 3.0 of iCal (as in, a newer version of the same spec). This doesn't seem to be the case, though. -Jared On Friday, November 8, 2002, at 10:38 AM, Waitman C. Gobble wrote: > Jared > > from what i gather the last time the ietf met was in july. the calendar > group did not attend. > > http://www.ietf.org/proceedings/02jul/index.html > > the most recent info i can find with regards to calsch > > http://www.ietf.org/proceedings/02jul/103.htm > > more information is available at > > http://www.ietf.org/proceedings/02mar/104.htm > > i believe these links are current > > http://www.ietf.org/rfc/rfc2445.txt > http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt > > i don't think the xcal draft is at level 3. > > > take care > > Waitman > > > > On Fri, 2002-11-08 at 08:18, Jared wrote: > Oh, xCal == XML iCalendar. > > I was under the impression that the XML version was 3.0. (Is there > a > 1.0 for iCalendar? is there anything past 2.0?) > > At any rate, yes, I would be interested in supporting xCal in the > future. Right now, it's in the distant future, as iCal should be > supported as fully as we can before taking on a new approach. > > However, I think PHP iCalendar is the perfect suite to support > this. > For that, I see a single file called "parser.php" which does > something > like "if iCal, include ical_parser.php, elseif xCal, include > xcal_parser.php" > > As I said, thats in the distant future. > > -Jared > > On Friday, November 8, 2002, at 10:16 AM, Waitman C. Gobble wrote: > >> hey jared! >> >> no problem. i was really curious if it was in use anywhere. >> >> fyi, the xcal format is documented at >> >> http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt >> >> IMO, this should replace the ical standard. >> >> if you guys decide to implement it in the future, i already have a >> working parser. i am just not sure if the xcal format is in use. >> >> Best >> >> Waitman >> >> >> On Fri, 2002-11-08 at 07:40, Jared wrote: >> I don't know what the xcal format is, but let's just stick to the >> RFC2445 standard right now (assuming it's not part of that >> standard). >> >> >> On Friday, November 8, 2002, at 09:43 AM, Waitman C. Gobble >> wrote: >> >>> i'll give it another go if you like. >>> >>> question, is there any use to support the xcal format? i am not sure >>> if >>> this format is in use anywhere. >>> >>> waitman >>> >>> >>> On Thu, 2002-11-07 at 11:56, Chad wrote: >>> So who was working on adding VTODO support to the parser? Now is >>> the >>> time to start looking at it for 0.9. >>> >>> -C >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by: See the NEW Palm >>> Tungsten T handheld. Power & Color in a compact size! >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >>> _______________________________________________ >>> Phpicalendar-devel mailing list >>> Php...@li... >>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by: See the NEW Palm >>> Tungsten T handheld. Power & Color in a compact size! >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >>> _______________________________________________ >>> Phpicalendar-devel mailing list >>> Php...@li... >>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm >> Tungsten T handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm >> Tungsten T handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Waitman C. G. <wa...@em...> - 2002-11-08 16:33:03
|
Jared from what i gather the last time the ietf met was in july. the calendar group did not attend. http://www.ietf.org/proceedings/02jul/index.html the most recent info i can find with regards to calsch http://www.ietf.org/proceedings/02jul/103.htm more information is available at http://www.ietf.org/proceedings/02mar/104.htm i believe these links are current http://www.ietf.org/rfc/rfc2445.txt http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt i don't think the xcal draft is at level 3. take care Waitman On Fri, 2002-11-08 at 08:18, Jared wrote: Oh, xCal == XML iCalendar. I was under the impression that the XML version was 3.0. (Is there a 1.0 for iCalendar? is there anything past 2.0?) At any rate, yes, I would be interested in supporting xCal in the future. Right now, it's in the distant future, as iCal should be supported as fully as we can before taking on a new approach. However, I think PHP iCalendar is the perfect suite to support this. For that, I see a single file called "parser.php" which does something like "if iCal, include ical_parser.php, elseif xCal, include xcal_parser.php" As I said, thats in the distant future. -Jared On Friday, November 8, 2002, at 10:16 AM, Waitman C. Gobble wrote: > hey jared! > > no problem. i was really curious if it was in use anywhere. > > fyi, the xcal format is documented at > > http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt > > IMO, this should replace the ical standard. > > if you guys decide to implement it in the future, i already have a > working parser. i am just not sure if the xcal format is in use. > > Best > > Waitman > > > On Fri, 2002-11-08 at 07:40, Jared wrote: > I don't know what the xcal format is, but let's just stick to the > RFC2445 standard right now (assuming it's not part of that > standard). > > > On Friday, November 8, 2002, at 09:43 AM, Waitman C. Gobble wrote: > >> i'll give it another go if you like. >> >> question, is there any use to support the xcal format? i am not sure >> if >> this format is in use anywhere. >> >> waitman >> >> >> On Thu, 2002-11-07 at 11:56, Chad wrote: >> So who was working on adding VTODO support to the parser? Now is >> the >> time to start looking at it for 0.9. >> >> -C >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm >> Tungsten T handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm >> Tungsten T handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Phpicalendar-devel mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Jared <xe...@si...> - 2002-11-08 16:18:57
|
Oh, xCal == XML iCalendar. I was under the impression that the XML version was 3.0. (Is there a 1.0 for iCalendar? is there anything past 2.0?) At any rate, yes, I would be interested in supporting xCal in the future. Right now, it's in the distant future, as iCal should be supported as fully as we can before taking on a new approach. However, I think PHP iCalendar is the perfect suite to support this. For that, I see a single file called "parser.php" which does something like "if iCal, include ical_parser.php, elseif xCal, include xcal_parser.php" As I said, thats in the distant future. -Jared On Friday, November 8, 2002, at 10:16 AM, Waitman C. Gobble wrote: > hey jared! > > no problem. i was really curious if it was in use anywhere. > > fyi, the xcal format is documented at > > http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt > > IMO, this should replace the ical standard. > > if you guys decide to implement it in the future, i already have a > working parser. i am just not sure if the xcal format is in use. > > Best > > Waitman > > > On Fri, 2002-11-08 at 07:40, Jared wrote: > I don't know what the xcal format is, but let's just stick to the > RFC2445 standard right now (assuming it's not part of that > standard). > > > On Friday, November 8, 2002, at 09:43 AM, Waitman C. Gobble wrote: > >> i'll give it another go if you like. >> >> question, is there any use to support the xcal format? i am not sure >> if >> this format is in use anywhere. >> >> waitman >> >> >> On Thu, 2002-11-07 at 11:56, Chad wrote: >> So who was working on adding VTODO support to the parser? Now is >> the >> time to start looking at it for 0.9. >> >> -C >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm >> Tungsten T handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm >> Tungsten T handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Waitman C. G. <wa...@em...> - 2002-11-08 16:09:57
|
hey jared! no problem. i was really curious if it was in use anywhere. fyi, the xcal format is documented at http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt IMO, this should replace the ical standard. if you guys decide to implement it in the future, i already have a working parser. i am just not sure if the xcal format is in use. Best Waitman On Fri, 2002-11-08 at 07:40, Jared wrote: I don't know what the xcal format is, but let's just stick to the RFC2445 standard right now (assuming it's not part of that standard). On Friday, November 8, 2002, at 09:43 AM, Waitman C. Gobble wrote: > i'll give it another go if you like. > > question, is there any use to support the xcal format? i am not sure if > this format is in use anywhere. > > waitman > > > On Thu, 2002-11-07 at 11:56, Chad wrote: > So who was working on adding VTODO support to the parser? Now is > the > time to start looking at it for 0.9. > > -C > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Phpicalendar-devel mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Jared <xe...@si...> - 2002-11-08 16:00:56
|
I don't know what the xcal format is, but let's just stick to the RFC2445 standard right now (assuming it's not part of that standard). On Friday, November 8, 2002, at 09:43 AM, Waitman C. Gobble wrote: > i'll give it another go if you like. > > question, is there any use to support the xcal format? i am not sure if > this format is in use anywhere. > > waitman > > > On Thu, 2002-11-07 at 11:56, Chad wrote: > So who was working on adding VTODO support to the parser? Now is > the > time to start looking at it for 0.9. > > -C > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Waitman C. G. <wa...@em...> - 2002-11-08 15:37:57
|
i'll give it another go if you like.
question, is there any use to support the xcal format? i am not sure if
this format is in use anywhere.
waitman
On Thu, 2002-11-07 at 11:56, Chad wrote:
So who was working on adding VTODO support to the parser? Now is the
time to start looking at it for 0.9.
-C
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Phpicalendar-devel mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
|
|
From: Jared <xe...@si...> - 2002-11-08 11:12:57
|
Just a heads up guys. From the sound of the e-mail, only project Admins get this but it's important info for all of us to get. Just make sure you have the most current CVS on the 16th. -Jared Begin forwarded message: > From: SourceForge.net Team <no...@so...> > Date: Thu Nov 7, 2002 5:34:51 PM US/Central > To: "" <ja...@si...> > Subject: [SourceForge] Notice of scheduled site/service outages > > Greetings, > > This message contains vital details regarding two upcoming outages > which > will affect the access of you and your developers to the > SourceForge.net > site and project resources. Please read this message carefully. > > You are receiving this message because this email address is associated > with the account of a project administrator of a project currently > hosted on SourceForge.net (https://sourceforge.net). This message has > been sent in accordance with our "Guidelines Regarding Notification for > SourceForge.net Site Changes", as found in the Site Docs collection of > SourceForge.net > > On 2002-11-14 (Thursday), the SourceForge.net site, project mailing > list services, and the primary download server (which handles the > redirects for all download requests) will be offline for a period of > two to three hours, starting at 16:00 Pacific (GMT-8). > > On 2002-11-17 (Sunday), project CVS services, project shell services, > project web services (including all VHOSTs), and project database > services will be offline for a period of up to twelve hours, starting > at 10:00 Pacific (GMT-8). Project web services will be restored first, > but will be brought up initially with read-only access to project group > directory space. Static web content will be served correctly during > this > time period, but application-driven and database-dependent content and > CGI scripts will not function correctly. Issues encountered during > this > time period SHOULD NOT be reported to SourceForge.net; they are an > expected side-effect of this outage. > > Both outages (2002-11-14 at 16:00 for 3 hours, and 2002-11-17 at 10:00 > for 12 hours) have been scheduled to permit the relocation of site > hardware by SourceForge.net staff. > > All inquiries regarding this outage, SourceForge.net, or your project > on SourceForge.net should be directed to the SourceForge.net team by > submitting a Support Request. Support IS NOT provided via email. > To submit a Support Request: > https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 > > Thank you, > > SourceForge.net staff > |
|
From: Chad <ch...@ch...> - 2002-11-07 19:59:34
|
So who was working on adding VTODO support to the parser? Now is the time to start looking at it for 0.9. -C |
|
From: Chad <ch...@ch...> - 2002-11-07 19:57:14
|
Its on the preferences page that doesn't yet exist, but is scheduled for 0.9. Im pretty sure I've gone over this already. I would like to use your chlang popup on that upcoming page. Your basically re-iterating everything I've already said in your email. Please add 'list_languages.php' to functions in CVS as well as your changes to all the pages. We will move the selection options to the new Prefs page I hope to find time to start this weekend. -C Chad wrote : > cookie takes precedence over config and lang file > config takes precedence over lang file > if neither, lang file is used How do you set the "Start week day" cookie ? Is there a pop menu "Start Day Week" ? We still have to respond to that question. |
|
From: Mike <mi...@la...> - 2002-11-07 19:43:08
|
Everyone can take a look at my version with the "View in..." pop menu... http://LaShampoo.net/iCal Basically, the prefered language is the default language set by the=20 webmaster (here it's french). Then if the visitor (you) change the=20 prefered language, the language is set in the visitor cookies. The=20 visitor can then browse the entire calendar with his prefered language.=20= The $week_start_day is set in the language file (I try to set the=20 proper $week_start_day in every language file). Chad wrote : > cookie takes precedence over config and lang file > config takes precedence over lang file > if neither, lang file is used How do you set the "Start week day" cookie ? Is there a pop menu "Start=20= Day Week" ? We still have to respond to that question. Jared wrote : > By default $week_start_day could be set to "Same as Language" and then=20= > it would use the one from the language file. Otherwise, the language=20= > file wouldn't reset that var. Would that be acceptable? Yes. That would be more acceptable. But best is to add an=20 $prefered_start_day in the config file: =AB $prefered_start_day =3D '' // If the start week day in your language=20= file don't fit your need, please do change this variable to the desired=20= day otherwise leave blank. =BB Explanations: if the visitor use the same language as the webmaster and=20= the webmaster didn't like the default settings set in the language=20 file, then $prefered_start_day is not blank and phpical will use the=20 $prefered_start_day Otherwise, if the visitor choose another=20 language, phpical will use $week_start_day set in the language file and=20= not the $prefered_start_day because is no more the same language. This=20= is more convenient for FOREIGN people because the $start_week_day is no=20= more fixed by the webmaster for HIS own language. Other option (best): to tell webmasters to change the $week_start_day=20 in THEIR language file to their needs. This way, that doesn't affect=20 other languages and they can change the 24/12 format too (some english=20= country may use 24h format). This way, visitors with other languages can still benefit the proper=20 settings of the desired language file whatever if the french language=20 file is used in a "Sunday" country for example. And YES, to respond to Matt Jarjoura, even American country will have=20 the desired settings whatever they're Sunday or Monday and 12h or 24h=20 country... Mike.=20= |
|
From: Matt J. <mj...@um...> - 2002-11-07 17:13:45
|
If you look at most OS's they give language as one choice and then your localization as another. This way I can still see dollars but see the written word in another language, maybe Spanish. I would suggest not putting the start of the week in the language files because they are unrelated completely. Sure most European countries start on Monday, but most Americans like it to start on Sunday. Furthermore, what about creating localization settings? If you want to make it easy for the user what's one more select box? Select Language as config #1 and then select localization as default config #2. On 11/7/02 5:27 AM, "Mike" <mi...@la...> wrote: > Jared wrote : > >> I disagree. It's not stuck to the language but rather the country. The >> US has the week start on Sunday. If someone in the US prefers their >> calendars to be viewed in French or German, why should the week start >> be on Monday? The calendar is still a US calendar. > > This is your point of view. But remember: start week of the day doesn't > affect the calendar results themselves! It's just for VIEWERS' > convenience, just to fit people's mind. Just like translation or 24/12. > So why stuck 24/12 in the language file and not week days ? 24h is not > part of the US calendar and someone watching your calendar with "French > view" would see 18h30: Japanese. Even if he lives in the US and is used > to 12h time format. That's the same thing. Week days are just something > everyone learn at school and are used to. So if you, Jared, come to > France, you will be a little confused to see a french week view even > with english day manes on it if you choosed the "US view". Because it's > not convient for you. > > > >> It is very common for a language to be stuck to a country as well, but >> they aren't tied as tightly together and bilingual people might want >> to choose. > > For bilingual persons it's another deal. Not a big deal, because > they're used to see both ways of displaying calendars. When french > speaking Quebec people, and they're numerous, come to our websites > hosted in France, they're used to see things the French way: 24, metric > system, Euro, monday, etc... When they surf on US website they see > thing differently. Quebec webmaster, will be able to have a custom > mixed French/12h/sunday calendar with the custom.inc.php file I > mentioned for the convenience of their Quebec visitors. It's still up > to the webmaster! > > That's a very little thing to change, and that would allow "Prefered > view language" feature. Without that change, "Prefered view language" > feature is a nonsense and is useless too. > > Mike. > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > ========================== Matt Jarjoura ========================== | UMBC | Phi-Delta 313 | ========================== |
|
From: Jared <xe...@si...> - 2002-11-07 17:08:53
|
By default $week_start_day could be set to "Same as Language" and then it would use the one from the language file. Otherwise, the language file wouldn't reset that var. Would that be acceptable? -Jared On Thursday, November 7, 2002, at 10:45 AM, Chad wrote: > There isn't any reason these cannot be three tiered. > > cookie takes precedence over config and lang file > config takes precedence over lang file > if neither, lang file is used > > I don't see why this wouldn't solve all problems. User selects a > language to view in, it falls to the start day in the file, but if > they still want they can change it with their cookie. The admin can > set what they want in the config if they want to override our > defaults. > > -C > > > On Thursday, November 7, 2002, at 02:27 AM, Mike wrote: > >> Jared wrote : >> >>> I disagree. It's not stuck to the language but rather the country. >>> The US has the week start on Sunday. If someone in the US prefers >>> their calendars to be viewed in French or German, why should the >>> week start be on Monday? The calendar is still a US calendar. >> >> This is your point of view. But remember: start week of the day >> doesn't affect the calendar results themselves! It's just for >> VIEWERS' convenience, just to fit people's mind. Just like >> translation or 24/12. So why stuck 24/12 in the language file and not >> week days ? 24h is not part of the US calendar and someone watching >> your calendar with "French view" would see 18h30: Japanese. Even if >> he lives in the US and is used to 12h time format. That's the same >> thing. Week days are just something everyone learn at school and are >> used to. So if you, Jared, come to France, you will be a little >> confused to see a french week view even with english day manes on it >> if you choosed the "US view". Because it's not convient for you. >> >> >> >>> It is very common for a language to be stuck to a country as well, >>> but they aren't tied as tightly together and bilingual people might >>> want to choose. >> >> For bilingual persons it's another deal. Not a big deal, because >> they're used to see both ways of displaying calendars. When french >> speaking Quebec people, and they're numerous, come to our websites >> hosted in France, they're used to see things the French way: 24, >> metric system, Euro, monday, etc... When they surf on US website they >> see thing differently. Quebec webmaster, will be able to have a >> custom mixed French/12h/sunday calendar with the custom.inc.php file >> I mentioned for the convenience of their Quebec visitors. It's still >> up to the webmaster! >> >> That's a very little thing to change, and that would allow "Prefered >> view language" feature. Without that change, "Prefered view language" >> feature is a nonsense and is useless too. >> >> Mike. >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm Tungsten T >> handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Chad <ch...@ch...> - 2002-11-07 16:45:45
|
There isn't any reason these cannot be three tiered. cookie takes precedence over config and lang file config takes precedence over lang file if neither, lang file is used I don't see why this wouldn't solve all problems. User selects a language to view in, it falls to the start day in the file, but if they still want they can change it with their cookie. The admin can set what they want in the config if they want to override our defaults. -C On Thursday, November 7, 2002, at 02:27 AM, Mike wrote: > Jared wrote : > >> I disagree. It's not stuck to the language but rather the country. >> The US has the week start on Sunday. If someone in the US prefers >> their calendars to be viewed in French or German, why should the week >> start be on Monday? The calendar is still a US calendar. > > This is your point of view. But remember: start week of the day > doesn't affect the calendar results themselves! It's just for VIEWERS' > convenience, just to fit people's mind. Just like translation or > 24/12. So why stuck 24/12 in the language file and not week days ? 24h > is not part of the US calendar and someone watching your calendar with > "French view" would see 18h30: Japanese. Even if he lives in the US > and is used to 12h time format. That's the same thing. Week days are > just something everyone learn at school and are used to. So if you, > Jared, come to France, you will be a little confused to see a french > week view even with english day manes on it if you choosed the "US > view". Because it's not convient for you. > > > >> It is very common for a language to be stuck to a country as well, >> but they aren't tied as tightly together and bilingual people might >> want to choose. > > For bilingual persons it's another deal. Not a big deal, because > they're used to see both ways of displaying calendars. When french > speaking Quebec people, and they're numerous, come to our websites > hosted in France, they're used to see things the French way: 24, > metric system, Euro, monday, etc... When they surf on US website they > see thing differently. Quebec webmaster, will be able to have a custom > mixed French/12h/sunday calendar with the custom.inc.php file I > mentioned for the convenience of their Quebec visitors. It's still up > to the webmaster! > > That's a very little thing to change, and that would allow "Prefered > view language" feature. Without that change, "Prefered view language" > feature is a nonsense and is useless too. > > Mike. > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Jared <xe...@si...> - 2002-11-07 16:42:40
|
Sorry to send this through the list but I tried to reply to your e-mail and it bounced. The reply was being sent to the following address: Mike <mi...@la...> Is this correct? Do you know why it might have bounced? -Jared |
|
From: Mike <mi...@la...> - 2002-11-07 10:27:29
|
Jared wrote : > I disagree. It's not stuck to the language but rather the country. The > US has the week start on Sunday. If someone in the US prefers their > calendars to be viewed in French or German, why should the week start > be on Monday? The calendar is still a US calendar. This is your point of view. But remember: start week of the day doesn't affect the calendar results themselves! It's just for VIEWERS' convenience, just to fit people's mind. Just like translation or 24/12. So why stuck 24/12 in the language file and not week days ? 24h is not part of the US calendar and someone watching your calendar with "French view" would see 18h30: Japanese. Even if he lives in the US and is used to 12h time format. That's the same thing. Week days are just something everyone learn at school and are used to. So if you, Jared, come to France, you will be a little confused to see a french week view even with english day manes on it if you choosed the "US view". Because it's not convient for you. > It is very common for a language to be stuck to a country as well, but > they aren't tied as tightly together and bilingual people might want > to choose. For bilingual persons it's another deal. Not a big deal, because they're used to see both ways of displaying calendars. When french speaking Quebec people, and they're numerous, come to our websites hosted in France, they're used to see things the French way: 24, metric system, Euro, monday, etc... When they surf on US website they see thing differently. Quebec webmaster, will be able to have a custom mixed French/12h/sunday calendar with the custom.inc.php file I mentioned for the convenience of their Quebec visitors. It's still up to the webmaster! That's a very little thing to change, and that would allow "Prefered view language" feature. Without that change, "Prefered view language" feature is a nonsense and is useless too. Mike. |
|
From: Jared <xe...@si...> - 2002-11-07 09:05:53
|
On Thursday, November 7, 2002, at 02:29 AM, Michel wrote: > NONE english country have their start day of the week other that > sunday, NONE french, german or italian speaking country have their > start day other than monday. What about Canada? They speak both French and English. There week start is on Sunday, isn't it? Even in Quebec? > It's like 24/12 format time or metric system: it's stuck to the > language. You have to know that foreign country with english as > primary language (like in africa), they adopt the same habits as in US > or OK: non metric system, 12 time format, and sunday as start day of > the week. I disagree. It's not stuck to the language but rather the country. The US has the week start on Sunday. If someone in the US prefers their calendars to be viewed in French or German, why should the week start be on Monday? The calendar is still a US calendar. It is very common for a language to be stuck to a country as well, but they aren't tied as tightly together and bilingual people might want to choose. For me, I'm learning Japanese. Neither of our solutions will affect me as Japan has a week start of Sunday too so either way it'll work. I want it to work for everyone, though. Now, your idea to have some other custom.inc.php or something might work. However, I'd rather the visitor get to choose which language to view it in and the system admin get to choose the week start. If we implement a good multi-user system, all this will be solved as each user will be able to choose their own settings. Any visitor might be able to change the language, but the start week is something fixed to the creator of the calendar, as that is the layout of the calendar to that person. I dunno, it's all very confusing, but I do want a good implementation when this is all done so we have to come up with something sound. -Jared |
|
From: Michel <mi...@la...> - 2002-11-07 08:29:49
|
Jared wrote : > This is why, despite localization, Apple has chosen iCal to have a > separate preference for the week start day. As Chad said, we could put > a default value in the language file with the option to change it in > the config file. Sorry to insist on that point because it's the only point that remain preventing us adding a language view feature in phpiCal. Apple start day of the week in iCal works in the main window doesn't work in the month calendar view on the left side. But it works very well in phpiCal. ;-) Maybe because in Apple's iCal, start day of the week is hard coded in the mainframe function. The only reason why Apple choose to put start day of the week in iCal pref is because nowhere in the main System preferences such a feature is present. The reason is because Calendar functions or programs were not present in previous system versions and iCal has been released after Jaguar. But that preference could have been already set in the Language pref. NONE english country have their start day of the week other that sunday, NONE french, german or italian speaking country have their start day other than monday. It's like 24/12 format time or metric system: it's stuck to the language. You have to know that foreign country with english as primary language (like in africa), they adopt the same habits as in US or OK: non metric system, 12 time format, and sunday as start day of the week. So forget my Australian example. That was a bad idea. There is no exception, or souldn't be. But if config.inc.php override the language pref as Chad proposed we will lost all the benefit. The best is to invite webmaster to change a " custom.inc.php " file in the language directory and set this file as prefered language in his conf.inc.php if no language file correspond to their need (if ever). So visitors will have the possibility to change their language view. And with their $_cookie_pref_language, phpical will be able to display the week days as desired. Mike. |
|
From: Chad <ch...@ch...> - 2002-11-06 22:30:19
|
If we do this both ways, it still allows simple configuration changes by the end user, plus now most languages won't have to set their option -- which is what Mike wants. So change all the languages to have their own 'default' week start, and have an option in config.inc.php to override whatever may be in the language file. True could be said for the time format. I liked the '12' or '24' option in the config. -C On Wednesday, November 6, 2002, at 12:58 PM, Jared wrote: > Most of the time, but not all the time. It would cause more problems > than it would solve, in my opinion. Any of those languages that > originate from countries where the start of the week is Monday > wouldn't work in America, for example. Whether someone wants to view a > language other than English in America shouldn't affect the importance > of Sunday being our consistent start day. > > This is why, despite localization, Apple has chosen iCal to have a > separate preference for the week start day. As Chad said, we could put > a default value in the language file with the option to change it in > the config file. > > It might be best to start doing our language files as en_US or en_UK > and things like that. After all, the wording and spelling of English > words will change. As for other languages, I'm not sure how much they > change, but English has major differences. Maybe we should just do it > for the few languages where it truly matters, by putting a > "-COUNTRYCODE" after it. Like "english-us.inc.php". Either that, or > the config file will become more cryptic for that setting. If there is > a prefs page to build the file, (or however Chad is thinking of > implementing prefs), then it wouldn't be such an issue. > > -Jared > > On Wednesday, November 6, 2002, at 02:15 PM, Michel wrote: > >> Chad wrote : >> >>> The problem I see with that is adding even more language files (like >>> AUS) for no real reason. Providing all the *most common* >>> configuration options in the config file is what I'd like to keep. >>> Having to tell someone to look in the language file for their start >>> week time seems to be a bit user-unfriendly. I'd like them to only >>> have to touch one file. You could perhaps have it in both places, >>> blank in the config but if the user sets it there, it overrides >>> whats in the language file. :-) >> >> >> Chad, most of the time, Start day and language are tied together. >> Australian was a really bad example as ALL the english speaking >> country have their week begining with monday. And I don't think there >> is any incompatibility beetween language and start day. >> >> So why including the 24/12 time format in the language pack ? We're >> speaking about the same Week/Time specification linked to the > >> language. >> >> I promised, Chad, this is a good idea. And something less to >> configure installing phpiCal... >> >> Mike. >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm Tungsten T >> handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Waitman C. G. <wa...@em...> - 2002-11-06 22:08:54
|
great.
what do you think about changing the constant BASE to a variable, and
setting it to getcwd()
?
there was a report of a bug in php 4.2.3 with apache 2.0.43 the messed
up the file_exists call. i have seen this bug in previous versions of
php, not sure why it has apparently resurfaced, but using the full path
with getcwd fixes the problem.
the change would simply prevent future incidence.
the getcwd() should be used in a single place, with a note :
in case some ISP has this function blocked in their php.ini
configuration file, the user can manually place the full path in the
$BASE variable and remove the getcwd() call.
otherwise, perhaps we could check to see if the function is available
and default to the "./" thing.
thanks!
waitman
On Wed, 2002-11-06 at 11:26, Bill Fenner wrote:
Waitman said:
>i noticed a problem with
>http://www.emkdemo.com/phpicalendar-0.8.1/rss/index.php
>
>i was getting a "WARNING: failed to include fle ./header.inc.php on line
>17" at the top of the page.
I changed this to use BASE like the include of the footer.
I also fixed the problem that descriptions weren't being included
in the rss feed.
Bill
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Phpicalendar-devel mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
|
6 messages has been excluded from this view by a project administrator.
