.gaim Revisited

Kevin M Stange kevin at simguy.net
Wed Mar 21 05:03:06 EDT 2007


Richard Laager wrote:
<snip>
> On Windows, the situation is less clear. After discussing this with a
> Windows-using co-worker, I'm fairly certain that logs belong in the "My
> Documents" folder. Microsoft's MSN Messenger (and now Windows Live
> Messenger) store logs under My Documents. The Messenger Plus! extension
> does as well. However, Trillian stores them in its application directory
> in C:\Program Files\...

For whatever it's worth, Trillian's behavior is WRONG by all
definitions.  Applications should never store user or application data
in "Program Files."  It would be like putting user data in /lib/gaim/ or
/bin/gaim/.  Non-administrator users do not have the right to create
files in this location (and shouldn't without being asked to escalate
their privileges for a software installation).  Failure to understand
this by application developers has caused a lot of headaches in the
process of moving away from Windows users being administrators by
default.  This was still impossible last time I tried to do it when I
last reinstalled my Windows machine.  Vista's new defaults should help
speed up the process.

> My co-worker said that the logs don't belong under Application Data
> because they aren't application data files, they are user data files and
> thus belong under My Documents. He also said that any user will know
> where "My Documents" is, whereas they wouldn't know how to find the
> Application Data folder (which is also hidden by default). These seems
> like reasonable and compelling arguments to me.

This seems to be a growing trend, and I agree that it makes sense.
Users get an easy path to My Documents from many entry points in the UI.
 Games are starting to do this as well, so that users backing up their
My Documents directory end up backing up a good amount of things they
might legitimately want to save.

> If we accept that the logs are to be in the My Documents folder, we run
> into an issue of what to name them. The log path is currently set by
> libpurple, so the first thing that comes to mind is "Purple Logs".
> That's going to be confusing to users, because they downloaded "Pidgin".
> The next thing I thought of was "Pidgin Logs". This seems perfectly
> reasonable, except it violates the core/UI split. I'd be okay with that
> on Windows, except for one reason. If we ever get a native win32 UI,
> we'll have a mess. Let's say we release such a UI and name it Robin. Do
> we then have it store logs in the "Robin Logs" folder? (This assumes
> we're not actually sharing the compiled libgaim.dll between Pidgin and
> Robin, or that we have a way for the UI to pass down its name.) If we do
> this, then we end up with logs in two places and users see their logs
> "disappear" when they switch clients (unless we check both locations).

Why not have the UI register its identity to suggest the properly place
(or at least naming convention) to store the user data (or just have it
register its proper package name and then use that to construct the
relevant paths)?  Failure to do so could fall back to "Purple" or
"libPurple."  That seems like a solution that would work well and make
more sense to end users.  Things on the backend like cache data can
certainly still go in Purple directories.

I would say that we should search both Pidgin and Purple paths for
plugins and other non-UI elements in whatever location we want to have
users install them, and only Pidgin for smiley themes, for example,
since they are only recognized by the UI.  The default could be to
install non-UI plugins along with libpurple's shared library and UI
plugins along with their appropriate UI components.

I think I might prefer calling the logs dir "Pidgin\Logs" so that if we
want to store incoming files by default in a downloads directory, we
could use "Pidgin\Downloads" which saves multiple directories in the top
level of My Documents and associates the data clearly with one application.

> 
> It seems like we should use something generic then. Messenger Plus! uses
> "My Chat Logs". Microsoft has removed the "My" everywhere in Vista, I'm
> told, so we could do "Chat Logs". But, are they chats? Do we want "IM
> Logs" or "Conversation Logs" or "Saved Conversations" or something else?
> What about translations?

While translation of the Logs directory might be nice, I think it will
make finding the logs quite impossible for us to do, unless we search
all translations, or only honor the locations specified in the current
locale.  That seems like a hassle that's not worth it.  Translating
"Downloads" is probably okay, since Pidgin would not generally need to
find these files itself later, and a more verbose term like "Received
Files" could be used.

I do not like the "My" prefix, as it is useless information.  If you
look in your "Documents" folder, do you really expect to find someone
else's documents?  If they were, I would perhaps /then/ expect them to
be labeled "Kevin's Documents" :)

I prefer the idea "Pidgin\" with subdirs containing simple terms for
different types of user data.  I don't think we need to be verbose about
what the logs are.  Hopefully the user knows what Pidgin is and doesn't
need to be told that any logs it creates are logging IMs.  I don't like
"Saved Conversations" because it suggests to me that they'd be files the
user chose proactively to save, rather than logs that were automatically
kept by the program.

> 
> An easy solution is to continue storing logs under the "Application
> Data" folder and telling users to access it via the button that's been
> added to the log viewer. I'm not opposed to this, but I don't want to
> take the easy solution because it's easy if there's a more correct
> solution available.
> 
> How does everyone feel? Is it worthwhile to follow this standard? How do
> you feel about the file locations?

Overall, I like the pros in terms of making things easier to find, but I
also strongly dislike the whole notion that I can't just grab my
.appname directory and have everything.  Is there any merit to
maintaining shortcuts/symlinks and keeping our old layout?  Windows of
course does not offer symlinks in the Unix sense, so we cannot actually
put a file in Pidgin\Logs directly if it's a shortcut to another folder.
 (Its real name would be Pidgin\Logs.lnk anyway.)

> 
> Richard
> 

Kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://pidgin.im/cgi-bin/mailman/private/cabal/attachments/20070321/47e20b54/attachment.pgp 


More information about the Cabal mailing list