User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en; rv:1.8.1.12) Gecko/20080208 (Debian-1.8.1.12-2) Epiphany/2.20 Build Identifier: Hey! It'd be nice if orage supported evolution ics files. (this sounds like deja vu) Attached will be a sample ics file. Reproducible: Always
Created attachment 1527 sample ics file generated by evolution
Thanks. Need to add compatibility (hacks) into import and foreign file handling.
Added to Orage 4.5.13.1 revision 26657 Note that if these are added as foreign files and updated, they will not stay in evolution compatible format.
(In reply to comment #3) > Added to Orage 4.5.13.1 revision 26657 > > Note that if these are added as foreign files and updated, they will not stay > in evolution compatible format. You mean that you edit them and change the format? I'll have to check that. Currently, the way I'm using them is to add as “foreign files” directly the .ics generated by evolution, in .evolution/calendar. If the format is changed, and the file written, I don't really know how evolution will react, nor if if it's a really good idea. Maybe there should be a way to track foreign calendar in a read-only way?
You mean that you edit them and change the format? I'll have to check that. Currently, the way I'm using them is to add as “foreign files” directly the .ics generated by evolution, in .evolution/calendar. If the format is changed, and the file written, I don't really know how evolution will react, nor if if it's a really good idea. > Orage only changes foreign files if some appointment is explicitely > updated in Orage. In that case only the format is changed to Orage native > format. Evolution probably will not like that. Updates should basically > only be done if the foreign file is coming from compatible systems (like > other Orage). Maybe there should be a way to track foreign calendar in a read-only way? > By default foreign files are read-only and you can not change them in Orage. > But you can now add foreign files also as writable, but you need to do that > explicitely.
(In reply to comment #5) > You mean that you edit them and change the format? I'll have to check that. > Currently, the way I'm using them is to add as “foreign files” directly the > .ics generated by evolution, in .evolution/calendar. If the format is changed, > and the file written, I don't really know how evolution will react, nor if if > it's a really good idea. > > > Orage only changes foreign files if some appointment is explicitely > > updated in Orage. In that case only the format is changed to Orage native > > format. Evolution probably will not like that. Updates should basically > > only be done if the foreign file is coming from compatible systems (like > > other Orage). Yeah, fair enough. If it's not touched as long as $user didn't explicitely touched it in orage, and if he knows that it'll be written, it's ok. > > > Maybe there should be a way to track foreign calendar in a read-only way? > > > By default foreign files are read-only and you can not change them in Orage. > > But you can now add foreign files also as writable, but you need to do that > > explicitely. Very nice. Maybe adding a simple note saying that other applications may not be able to read the calendar file again? That's a shame that all calendars use ics files differently. Wasn't this a standard or something? (but I guess it may be an evolution bug in this :) ) Thanks anyway ! >
Very nice. Maybe adding a simple note saying that other applications may not be able to read the calendar file again? > Good idea. Added warning into the tooltip, where you change the READ only > mode. Default is read only, so you have to go that field to change it. > In Orage version 4.5.13.2 revision 26660. That's a shame that all calendars use ics files differently. Wasn't this a standard or something? (but I guess it may be an evolution bug in this :) ) > standard allows several implementation based exceptions (X- things). > And also we miss library, which would work. libical is not properly maintained > and the latest version does not implement all features of the standard, so > all calendars have a private, modified, version of it. > Bad, I agree. But usually appointments CAN be moved; some features only > can be lost.