No exporting/importing necessary, you can use the. Long story, but after messing with the Darwin Calendar Server, and fighting with authentication, extended file attributes, etc., I scratched the DCS idea, and found this handy method of using. I use "file:///home/username/Calendar/calendar.ics" ics files, i.e., WebDAV server, or whatever, but the trick is that a location of "file:///.ics" also works for locally stored files. This is intended for server-based storage of. However, if you add a new Calendar, and select "On the Network", then select Format (iCalendar), then for location place a reference to where you want (or already have) an. This isn't much help outside of Lightning nor for sharing calendars between apps. If you add a new Calendar, and select "On My Computer", then your calendar entries will be stored in your profile's storage.sdb file - which is an SQLite database. ics usage in Lightning (and possibly Sunbird, I cannot answer that - I use Lightning), there is a bit of a trick in Lightning. Which is why I proposed the idea of extending the clock applet to give a universal calendar API.įor all those that are questioning the. If the user has completely eradicated evolution (creating a minimal system for example) from their system and only run TB, then good luck with this. In addition, all three options will still require development of a provider to sit inside Thunderbird and update the GNOME applet. This is the best solution, but requires potentially quite a lot of reworking to decouple Evolution and e-d-s from the clock applet. (Preferred option) Extend the current clock applet to provide an API for Evolution, Lightning, and anything else that wants to use it. This requires the least amount of development effort, but as you point out, maintains the current dependency on Evolution.ģ. Hook into the current evolution/clock applet system by using e-d-s as an interim data provider to the clock applet Lightning updates e-d-s, e-d-s updates the clock applet. Develop a new clock applet from scratch for Thunderbird (pointless duplication of effort).Ģ. To clarify my position, to my mind there are three solutions:ġ. Ok, but how exactly is this different from relying on any other application (such as the current clock panel applet) that provides an API? Good programming principles will ensure that APIs are kept consistent this is standard practice. Developers on this project will need to be familiar with both programs in that case. If developers change something in the back end of evolution, this "lightning-extention-panel" that we are proposing to develop will perhaps break, meaning it will have to change as well. You have mentioned Google Calendar and the the Internet, but if we are relying on Evolution to stay the same, isn't that just as bad? Here is my example of issues your e-d-s idea may have: So we want to minimize our dependency on other products/services. You second comment did interest me and therefore I have added it to the blueprint below: Then the user could choose Lightning, Evolution, gnome-calendar, etc. Another option is to extend the clock panel applet's API so it can accept input from any arbitrary data server. That's only useful if you want to use evolution-data-server, of course. That is, a plugin for Thunderbird which reads calendar data from Lightning and pipes it to e-d-s in the same manner as the Google provider does so for Google calendars. My suggestion was based on the fact that Thunderbird's Google provider is a good grounding for development of what you could call, for want of a better name, an evolution-data-server provider. This would be a non-starter for a number of reasons: reliance on Google, reliance on presence of an Internet connection, ownership of a Google account, etc. Please take note, I never specified the use of Google calendars. I don't use Google Cal because I keep my calendars private and I am offline many times so I'm sorry but this does not meet the stated use case.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |