[BitPim-devel] Finding pvconv

[Roger Binns]

I am going to put in code that will find pvconv{.exe}. We really
don't want people to put it in the BitPim program directories
like the existing stuff since that tree could be entirely erased
on each upgrade, and is version dependent on Mac and Linux anyway.

These are the paths I was thinking of looking for under the
various operating systems. Any other suggestions?

Windows:

c:\Program Files\pvconv\pvconv.exe
c:\Program Files\Qualcomm\pvconv.exe
c:\Windows\pvconv.exe
c:\bin\pvconv.exe

(I'll get the correct location of the folders)

Linux:

/usr/local/bin/pvconv
~/pvconv
~/bin/pvconv

Mac:

no idea!

Roger

[d***@netzero.com]

These are the paths I was thinking of looking for under the various >operating systems. Any other suggestions?

I was thinking about the same line. How about asking users where they put pvconv (they could put it somewhere locally), and store the path in the user config setup. This approach could also work for future tools with similar policy (and I guess could even work on the Mac :-)

Just a thought.

-Joe Pham



______________________________________________________________________
Speed up your surfing with NetZero HiSpeed.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.netzero.com/surf to sign up today!

[Roger Binns]

Post by d***@netzero.com
I was thinking about the same line. How about asking users where they
put pvconv (they could put it somewhere locally), and store the path in
the user config setup. This approach could also work for future tools
with similar policy (and I guess could even work on the Mac :-)

That is *way* more code :-) It also raises issues for the mythical
command line only version of BitPim.

The goal is always to distribute helpers with BitPim. The only exception
will be helpers that are broadly useful, but the suppliers hate their
users.

Roger

[John P Speno]

Post by Roger Binns
These are the paths I was thinking of looking for under the
various operating systems. Any other suggestions?

On Unix systems (linux and Mac OS X included), you should look in all
directories listed in os.environ['PATH'] unless you let users set the location
of the thing you are looking for in the preferences.

In MacOS X, I think the default PATH is /usr/bin:/bin:/usr/sbin:/sbin:$HOME and
users can edit that in their ~/.MacOSX/environment.plist file. See the
MacPython FAQ on it:

http://www.pythonmac.org/wiki/FAQ#head-30475a182e1542629d526567e3799ce8463517e6

Take care.

[Roger Binns]

Post by John P Speno
On Unix systems (linux and Mac OS X included), you should look in all
directories listed in os.environ['PATH'] unless you let users set the location
of the thing you are looking for in the preferences.

I don't care enough to do that (look in all of $PATH or have preferences).
pvconv won't even work on many modern Linuxes (it was compiled with some
random version of the C++ libraries). And giving people too much choice
never solves anything. That is one of the reasons Unix/Linux is annoying
to use - you get way too many choices, and not enough sensible defaults.
So if the locations I picked aren't good enough, people can always symlink
in the actual place they picked to one of those.

Post by John P Speno
In MacOS X, I think the default PATH is /usr/bin:/bin:/usr/sbin:/sbin:$HOME and

On the Mac it is currently immaterial since there is no pvconv binary available
or even the SDK for someone to make one.

I am aiming for nice and simple here. If you want BitPim to find the pvconv
converter then place it one of the following directories: .... with a list
at most 5 items long.

This is what it looks like:

http://bitpim.org/testhelp/error-nopvconv.htm

Roger

[Derrick Hudson]

On Mon, Jan 17, 2005 at 08:49:11PM -0800, Roger Binns wrote:
| >On Unix systems (linux and Mac OS X included), you should look in all
| >directories listed in os.environ['PATH'] unless you let users set the
| >location
| >of the thing you are looking for in the preferences.
|
| I don't care enough to do that (look in all of $PATH or have preferences).

It has a better chance of working on more systems, since that is the
way applications are supposed to be found.

Anyways :

def find_file_in_PATH(fname) :
import os
for dir in os.environ['PATH'].split(os.pathsep) :
if os.path.exists(dir) and fname in os.listdir(dir) :
return os.path.join( dir, fname )

pvconv = find_file_in_PATH( 'pvconv' )

This is python, not C! 'It is quite trivial to do the search.

(PS. you can do what you want with this code; I place no restrictions
or copyright on it)

| pvconv won't even work on many modern Linuxes (it was compiled with some
| random version of the C++ libraries).

Binary-only software generally sucks precisely because of this. Isn't
there an OSS tool capable of doing the necessary conversion?

| And giving people too much choice never solves anything.

There is a such thing as "too much", but no choice at all is even
worse.

| That is one of the reasons Unix/Linux is annoying
| to use - you get way too many choices, and not enough sensible defaults.

Some applications and/or distributions have sensible defaults, some
others don't.

-D

[Roger Binns]

.. searching path ...

I deliberately chose not to search the path. Most people
don't know what their path is or how to change it, and
*shouldn't have to know*.

So when pvconv isn't found, BitPim says "put it in one
of these 3 or 4 directories". People who don't know or
care about path can do just that (it would be terrible
being a list 30 items long). People who do know about
path can ensure the right thing happens on their
machine.

Binary-only software generally sucks precisely because of
this. Isn't there an OSS tool capable of doing the necessary
conversion?

Nope, PureVoice is proprietary Qualcomm. They have documented
(in RFC 3625) the container file format, but that isn't much
use.

They also have a SDK so you could reduce the amount of
binary crud they supply but we can't use that because of
their legal terms.

Take this as a hint to pay careful attention to what your
future phones use and vote with your feet and money.

Roger

[Derrick Hudson]

On Fri, Jan 21, 2005 at 08:37:19AM -0800, Roger Binns wrote:
| >.. searching path ...
|
| I deliberately chose not to search the path. Most people
| don't know what their path is or how to change it, and
| *shouldn't have to know*.

I agree that people shouldn't need to change their path when
installing/using any given application. I only meant to suggest using
the framework that already exists to find things external to BitPim.

It certainly would suck if, for example, a "foo" package on my system
put the binary in a location on my system's default $PATH but BitPim
couldn't find it because BitPim's hard-coded choice of path doesn't
include that directory. I see from your comments below that that
isn't about to happen with pvconv, though.

Based on pvconv's proprietary nature perhaps a better policy for that
and similar components is to instruct the user to install it in a
certain BitPim directory. For example, BitPim\helpers\ on Windows and
$prefix/lib/bitpim/helpers on UNIX ($prefix would typically be
/usr/local or /usr or maybe /opt/BitPim).

I hope that my lack of familiarity with BitPim and its internals
doesn't put my thoughts too far in left field and that I'm actually
being helpful :-).

| So when pvconv isn't found, BitPim says "put it in one
| of these 3 or 4 directories". People who don't know or
| care about path can do just that (it would be terrible
| being a list 30 items long).

I certainly agree that displaying the entire path in an error message
is a bad thing. One solution is to just say "path". Another is to
append /usr/local/bin to the path and only display that directory in
the error dialog.

| >Binary-only software generally sucks precisely because of
| >this. Isn't there an OSS tool capable of doing the necessary
| >conversion?
|
| Nope, PureVoice is proprietary Qualcomm.

I see. That's what the 'pv' in 'pvconv' stands for.

| They also have a SDK so you could reduce the amount of
| binary crud they supply but we can't use that because of
| their legal terms.

Naturally =p.

| Take this as a hint to pay careful attention to what your
| future phones use and vote with your feet and money.

I agree.

-D

[Roger Binns]

Post by Derrick Hudson
Based on pvconv's proprietary nature perhaps a better policy for that
and similar components is to instruct the user to install it in a
certain BitPim directory. For example, BitPim\helpers\ on Windows and
$prefix/lib/bitpim/helpers on UNIX ($prefix would typically be
/usr/local or /usr or maybe /opt/BitPim).

The BitPim directories are version specific (ie include the version
number). That scheme will also cause grief with the installers
since they only uninstall what they install.

I am just going to leave it at the current simple scheme unless
it becomes an actual problem for people.

Roger