Re: [evolution-patches] Re: Save-calendar plugin: corrected GTK_STOCK_SAVE_AS behavior and support for comma seperated files

[Philip Van Hoof <spamfrommailing freax org>]

On Wed, 2004-11-24 at 14:45 -0500, JP Rosevear wrote:

> The person who should probably review this is away right now, but let
> me give a few comments.

Okay

> I think the the type for "Save As" should probably be set by a widget
> in the save dialog, rather than via a submenu. 

I was thinking the same thing. However, for only two target-types,
creating a new widget looked as to much userinterface-overhead to me. My
opinion is that once supporting multiple target-types like some XML-
format, CSV, icalendar, ... a "Choose the format"-dialog would indeed be
an interesting UI-option. I'd also call the popup-menuitem "Export"
rather than "Save" then.

> I also think we need to work around the ical folder saving issue,
> either by picking the folder correctly or altering the file backend to
> allow overriding of the file name used on disk (right now it uses
> either calendar.ics or tasks.ics).

Okay, I will take a look at the API-internals but am not promising
anything. For me, personally, all this is pretty new stuff ;-).

Nevertheless, you are right. At this moment it's using a "Save to file"-
dialog rather than a directory-picker. The problem with a directory-
picker, however, was that directory hat is to be picked by the user
needs to be created already. And if one picks a directory, the ics-file
would eventually be written to something like

$HOME/dest_dir/dest_dir/tasks.ics

I could hack around it by first removing the directory if and only if
it's empty, and move the directory contents to a temporary location,
creating it with the ics-file and moving the original contents back if
the picked directory was not empty. But lets be honest with each other:
Thats just ... you know .. so ugly?!

The "Save to file"-dialog is fine. But the API should allow to specify
the filename rather than a directory-name. I don't know yet, however,
whether or not this export-like functionality in the API will sometimes
write multiple files or not? In which case a directory is a good idea
indeed. And the option to export it (the directory) as a tar and/or zip
archive should be added.

> For CSV an option to insert a header row would be good and the date
> and time spacing seems borked, its using " 6" instead of "06" for
> instance. Descriptions don't seem to be written out properly either.

Indeed. I should also conform to the CSV-standards. I've just recently
found a document that describes the format in-depth. It amazed me that
it's not just only comma separated, there are actually rules to follow.

The writing to the CSV-file is a.t.m. indeed a quick-n-dirty
g_strdup_printf()-trick. Maybe I should involve some CSV-library? Not
sure about that...

Thanks for your review


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org