[Pan-users] Re: Not following Gnome standard?

[Duncan]

"Yavor Doganov" <address@hidden> posted
address@hidden, excerpted below, on  Wed, 01 Nov 2006 14:43:20
+0000:

> В Wed, 01 Nov 2006 14:08:10 +0000, Leandro Guimarães Faria Corcete DUTRA
> написа:
> 
>> Em Wed, 01 Nov 2006 12:21:55 +0000, Yavor Doganov escreveu:
>> 
>>> Pan takes the settings from GNOME Control Center only for the MUA and
>>> browser.  You have to set this one from the posting window's Edit menu.
>> 
>> Ouch!  Should this be a ‘wishlist’ bug?
> 
> I don't know.  For a pure GNOME program this is preferable, but there
> are many users on KDE, Xfce and others (like me, GNUstep).

Exactly.  While pan <0.12 was a gnome-1 app, when Charles ported to 2, he
went gtk-only, so pan >0.11 is a gtk+2 app, not gnome-specific.  It
requires no gnome dependencies, only gtk+2 and etc.  From Gentoo's
pan-0.117.ebuild:

RDEPEND=">=dev-libs/glib-2.4.0
        >=x11-libs/gtk+-2.4.0
        >=dev-libs/libpcre-5.0
        >=dev-libs/gmime-2.1.0
        spell? ( >=app-text/gtkspell-2.0.7 )"

DEPEND="${RDEPEND}
        >=dev-util/intltool-0.21
        sys-devel/gettext"

As such, pan can't use/require gnome file associations directly -- that
would require linking against libgnome, which in turn would pull in many
additional gnome dependencies (bonobo, orbit, gnome-vfs, gconf, etc). 
This is undesired, to say the least, particularly when it's not required
for anything except tracking file associations.  It would also create
configuration nightmares for those who don't run gnome and haven't the
least interest in (re)learning how to configure it, just to get pan to
work "right" in terms of their preferred file associations.  I know, as
this is what pan was doing earlier in the 0.9x new-pan series.

What pan does instead is let you configure specific apps for handling
these things.  As it happens, all the major desktops
(MSWormOS/OSX/KDE/GNOME) supply a straight executable method of invoking
the system's configured browser and email client, without otherwise
knowing what it is.  Thus, pan can be configured to use this, invoking the
system's launcher to launch what is configured for it, rather that
configuring the specific app used directly.  However, all pan is doing in
those cases is simply invoking its configured executable, same as it does
in the other cases, only the configured executable itself provides a level
of indirection, in turn launching what is configured for it.

That in fact is what pan is doing when it honors the GNOME settings for
browser and email client.  It is simply invoking the GNOME executable that
in turn invokes whatever is configured for GNOME.

That's also why that method won't work for much else, including preferred
text editor.  Only the browser and email clients normally have this system
supplied level of indirection available.  To grab the desktop
environment's configured text file handler is rather more involved and
normally requires dependencies that unnecessarily restrict pan's
portability.

So, while you could bug this for pan, unless you can suggest a similar
method for determining the configured text editor at run-time without
triggering massive additional dependencies, said bug is likely to be
closed as NOTABUG or similar.

Of course, Charles has always been relatively open to patches, provided
they forward his goals for pan.  If you DO know such a run-time dependency
only method for selecting the text editor, and can supply parallel methods
for the four desktop environments mentioned above, Charles is very likely
to incorporate your ideas if you provide the patches, and even if you
don't provide patches only suggest a workable method, he'll likely follow
thru, thus making the text editor choice function much like the choices
for browser and email clients, with that level of system provided
indirection where possible without added dependencies.

>> Finally, I would like that Pan launched Emacs whenever I want
>> to follow-up, without opening its own window and then requesting me
>> to C-E.

Now this one looks more reasonable.  Once the external editor is
configured, an option to invoke it directly for followups, rather than
invoking the pan internal editor first, is somewhat reasonable and could
be doable.  I'm not sure Charles would want to "complexify" the
preferences dialog with that option, but there are already a number of
"advanced" settings exposed in preferences.xml and servers.xml when edited
directly, that aren't available as options in the pan GUI.  Particularly
if you can provide a patch accomplishing this, it's reasonably likely that
Charles will merge it.  If not, he may still be agreeable, but it'd have
to catch his interest more than the 1001 other features he could be adding
to pan instead, so implementation before "bluesky" isn't as likely.

>> Ah, and a new one I just noticed: it doesn’t accept my email
>> address as valid.

It's not clear what you are referring to here.  What is the "it" that
isn't taking your email address?  Are you referring to configuring the pan
posting profile, or to how that is transmitted to your email client when
invoked?

If the former, you'll have to post your email address in user at domain
dot tld format for me to see what's going on, as I participate on this
list thru gmane's list2news gateway, and it munges anything that looks
like a standard mail address (with the @ symbol and dots), to help
prevent spambot harvesting.  Thus, your email address comes out as a
nonsense string here, which doesn't help when trying to discern why pan
might not see it as valid.

If the latter, again, it's related to the way pan's invoking the mail
client, using the standard mailto: format.  Some mail clients don't
recognize that, and may require a wrapper script or the like.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman