Package: iceape-calendar
Version: 1.0.7-3
Severity: important
I appreciate that iceape-calendar is "provided for people that were
using Mozilla Calendar in the Mozilla Suite, but is not officially
part of the current Iceape Suite" and I'm grateful to those who've
worked to make this happen.
However, iceape-calendar's "handling" of remote, webDAV based does not
("remotely"!) imitate that of mozilla-calendar, and unless I'm
mistaken, is severely deficient. The iceape-calendar package
description does say "You can also use the calendar to subscribe to
these events (share your calendars) as well".
I'm surprised no-one else has noticed this, and I hope I'm missing
something - in which case, apologies, and thanks to anyone who can put
me right.
The main points are:
(1) iceape-calendar's "Reload remote calendars" context menu (or File
menu) item. I can't work out what this does, but it certainly doesn't
do what it should, and what mozilla-calendar's "Refresh remote
calendars" (same place in context menu) does, namely:
* overwrite the local copy of each remote calendar, in turn,
with the remote copy
This is the functionality that makes calendar sharing possible:
several people modify a .ics file on a server, and use a calendar
client to read it (and cache a local copy). Possibly connected with
this is:
(2) iceape-calendar has no option to "Subscribe to a remote calendar".
In mozilla-calendar, this is available in the Tools menu, but also
helpfully in the New calendar context menu (and File menu), where the
creation contains a check box for:
Publish changes automatically? For remote calendars, this will
download a new version before you add, edit or delete an event.
It will then perform your action, and upload the new file to the
server.
Again, this is a core part of sharing remote calendars. Instead,
iceape-calendar seems to have only an action to create a New calendar
file, which optionally can be remote. When I use this to try to
"subscribe" to an existing remote calendar, iceape-calendar silently
OVERWRITES any existing calendar of the same name. I lost data this
way, and fortunately my resentment is contained because I have good
backups.
Therefore, I have not found a way to make iceape subscribe to my
existing (mozilla-calendar-generated) remote .ics files; and I don't
see the point of going through a laborious "import" process if I
cannot use the result in a sharing way (with the rest of my scattered
family).
I've classified this bug as "important" because I believe it "has a
major effect on the usability of a package". I appreciate that some
people might see it as "wishlist", but in that case I think the
description of iceape-calendar as supporting "sharing of calendars"
needs to be edited out.
I've reported this bug as applying to the version of iceape-calendar
currently in etch (1.0.7-3), which is where I want to use it; but I've
checked that it all applies too to the version currently in sid
(1.0.8-3), albeit on amd64.
Happy to provide further information.
Barry Tennison
no .sig, but kudos to all those working so hard on debian
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_GB.UTF-8)
Versions of packages iceape-calendar depends on:
ii iceape-browser 1.0.7-3 Iceape Navigator (Internet browser
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-21 GCC support library
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
iceape-calendar recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
