[BitPim-devel] Changes

[Simon C]

There are a couple of nagging usability issues I would like to fix.

1. Change default number type from none to cell (or other common type). Many
newer phones do not support the none type and new users don't set the type,
number does not transfer to phone and they thing bitpim is faulty.
2. Offer autodetect at first use (like help is offered once only). Could be
implemented as button on settings, a unique dialog or a new option
(controlled via settings) to always run auto detect at startup.

Comments?

Simon

[Roger Binns]

Post by Simon C
1. Change default number type from none to cell (or other common type). Many
newer phones do not support the none type and new users don't set the type,
number does not transfer to phone and they thing bitpim is faulty.

That is a good idea.

Post by Simon C
2. Offer autodetect at first use (like help is offered once only). Could be
implemented as button on settings, a unique dialog or a new option
(controlled via settings) to always run auto detect at startup.

I'd go further. Make autodetect the default and revert to "manual"
if autodetect failed to find a model. This stuff should just work.

Roger

[Joe Pham]

Post by Roger Binns

Post by Simon C
2. Offer autodetect at first use (like help is offered once only).
Could be implemented as button on settings, a unique dialog or a
new option (controlled via settings) to always run auto detect at
startup.

I'd go further. Make autodetect the default and revert to "manual"
if autodetect failed to find a model. This stuff should just work.

I'd go with the option in the Settings Dialog, similar to always start with the Today tab option.

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Simon C

Post by Roger Binns

Post by Simon C
2. Offer autodetect at first use (like help is offered once only).
Could be implemented as button on settings, a unique dialog

or a new

Post by Roger Binns

Post by Simon C
option (controlled via settings) to always run auto detect

at startup.

Post by Roger Binns
I'd go further. Make autodetect the default and revert to "manual"
if autodetect failed to find a model. This stuff should just work.

I'd go with the option in the Settings Dialog, similar to
always start with the Today tab option.

I've added auto detect to the startup. It will only run if bitpim needs
configuration, (I will add the option to always run it in the settings
dialog later).
The easiest way to see what the new feature looks like is to delete the
bitpim directory and run.
I want to get any feedback before I complete the feature.

Simon

[Joe Pham]

Post by Simon C
I've added auto detect to the startup. It will only run if bitpim
needs configuration, (I will add the option to always run it in the
settings dialog later).

How about running detect_phone in a thread similar to the way it currently works.

Not that I'm against it, but why did you add the option of auto detect phone upon device connection?

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Joe Pham
How about running detect_phone in a thread similar to the way
it currently works.

I wanted to replace the current settings dialog that pops up when bitpim
runs for the first time, that is done on the main thread before the worker
thread is running.

Post by Joe Pham
Not that I'm against it, but why did you add the option of
auto detect phone upon device connection?

I'm working on a phone that needs a reboot after sending phone data (fairly
common), after the reboot windows sends a new device found message to bitpim
(as expected), however for some reason the autodetect does not work and it
is detected as "other CDMA". Disabling the detection allows the user to work
around this. Maybe a better approach would have been to disable the detect
if we know we have rebooted the phone.

Simon

[Roger Binns]

Post by Simon C
Maybe a better approach would have been to disable the detect
if we know we have rebooted the phone.

That (disabling) is a bad idea. On Linux and Mac, rebooting
often means the phone ends up being on a different port.
(ie the phone is added as a new port before removal from
the old port completes).

It would be way better to work out why the phone can't be
accurately detected the second time. Maybe a simple heuristic
like if we were connected to a normal phone (ie not the generic
CDMA) and we fail a detect, then wait 5 seconds and try again.

Roger

[Joe Pham]

Post by Simon C
I wanted to replace the current settings dialog that pops up when
bitpim runs for the first time,

I understand what you're trying to do. However, I have 2 suggestions:
1. Use existing processing path instead of having extra one (ie, call detect_phone in the main loop in its own thread as if it was activated from the menu)
2. Having a popup display on top of the splash screen is not that attractive!

Post by Simon C
however for some reason the autodetect does not work and it is
detected as "other CDMA".

My guess is that the firmware is not quite ready to talk to the PC. I'd go with Roger's suggestion with putting in a delay before detecting it. Since this is phone's specific, the delay would be passed from the phone module (similar to the reboot request).

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Joe Pham

Post by Simon C
I wanted to replace the current settings dialog that pops up when
bitpim runs for the first time,

1. Use existing processing path instead of having extra one
(ie, call detect_phone in the main loop in its own thread as
if it was activated from the menu)

I did not want to change the current design any more than adding autodetect
as a precursor to the settings dialog being shown. If this were moved to run
as if the menu option were pressed it would not be possible to present the
settings dialog prior to the main window in the case where no phone was
detected and there was no valid configuration.

2. Having a popup display

Post by Joe Pham
on top of the splash screen is not that attractive!

I'll remove the message when the phone is detected, having to click
everytime it works is kindof annoying. If a new phone is detected it will
still ask for the name, and an error will still be displayed when no phone
is detected.

Post by Joe Pham

Post by Simon C
however for some reason the autodetect does not work and it

is detected

Post by Simon C
as "other CDMA".

My guess is that the firmware is not quite ready to talk to
the PC. I'd go with Roger's suggestion with putting in a
delay before detecting it. Since this is phone's specific,
the delay would be passed from the phone module (similar to
the reboot request).

I'll remove the new option I added, I understand the point you make. I'll
put a delay into the notification code.
I don't see how this can be phone specific as we don't know what model we
are going to be detecting and we could potentially run through all the
phones we support, we would need to pick the lowest comon denominator if it
was in the profile. I was thinking that a hidden parameter
"device_connect_detect_delay" could be added to the code.

Simon

[Joe Pham]

Post by Simon C
I did not want to change the current design any more than adding
autodetect as a precursor to the settings dialog being shown.

The Settings dialog is a one-time deal, the auto-detect process could be done for every start. IMHO, it's ok to have it done after the Settings dialog.

Post by Simon C
I don't see how this can be phone specific

In a similar manner in which a phone code requests a reboot.

I'm planning a build on Monday, please let me know if you can make these updates by then.

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Joe Pham

Post by Simon C
I did not want to change the current design any more than adding
autodetect as a precursor to the settings dialog being shown.

The Settings dialog is a one-time deal, the auto-detect
process could be done for every start. IMHO, it's ok to have
it done after the Settings dialog.

For the first time user of bitpim the settings dialog is an uninituative
introduction to the program, this is why I wanted to make the change in the
first place. It does not make sense to ask the user to configure bitpim
manually any more the first time the program is run now that we have the
phone detection feature in bitpim.

The settings dialog should be a last resort when we cannot detect the phone
automatically, I don't think the detection should be moved from where it is
now except to not run it every time when we already know what the phone is
and there is an option to configure this.

The way it is working now is that for a user with a connected phone there is
no change to the startup (I removed the "phone detected popup" at your
suggestion) the detection is silent, If there is no phone they will get a
message saying that the phone is not detected, an early warning for the user
that there may be a problem. For the advanced user that does not want the
startup detection to run it can be disabled.

Post by Joe Pham

Post by Simon C
I don't see how this can be phone specific

In a similar manner in which a phone code requests a reboot.
I'm planning a build on Monday, please let me know if you can
make these updates by then.

I wont get this last change in for Monday, however I did remove the option
to disable detection on phone connection. I put in a 3 second delay instead
(in the worker thread), I don't think this is noticable, the detection
sequence appears to run a bit faster as a result on my 8100 mitigating the
delay somewhat.

Simon

[Roger Binns]

Post by Simon C
It does not make sense to ask the user to configure bitpim
manually any more the first time the program is run now that we have the
phone detection feature in bitpim.

I heartily agree with that. We can now automatically attempt to
answer all the questions, so there is no need to ask any of them.

Roger

[Simon C]

Joe,

I noticed that you took out the change I made to eliminate the dialog today.
The user will now get presented with this settings dialog the first time
they run bitpim for the first time. This is a backward step for usability.

Why do you not want to use the detect feature to avoid this dialog being
shown?

Simon

-----Original Message-----
Of Roger Binns
Sent: Monday, February 20, 2006 12:46 AM
Subject: Re: [BitPim-devel] Phone detection changes

It does not make sense to ask the user to configure bitpim manually
any more the first time the program is run now that we have

the phone

detection feature in bitpim.

I heartily agree with that. We can now automatically attempt
to answer all the questions, so there is no need to ask any of them.
Roger
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files for problems? Stop! Download the new AJAX
search engine that makes searching your log files as easy as
surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&
dat=121642
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Joe Pham]

Post by Simon C
I noticed that you took out the change I made to eliminate the
dialog today.

If you mean the Settings dialog, I just want to make sure the Auto-Detect-at-init works properly for this build. Eliminating the Settings dialog (and bringing it up if auto-detect fails) can be done in the next build.

-Joe Pham



_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Simon C

Post by Simon C
I noticed that you took out the change I made to eliminate

the dialog

Post by Simon C
today.

If you mean the Settings dialog, I just want to make sure the
Auto-Detect-at-init works properly for this build.
Eliminating the Settings dialog (and bringing it up if
auto-detect fails) can be done in the next build.

Are you going to do this? It is a little frustrating suggesting a feature,
getting positive feedback from other team members, implementing it and then
having it removed without any real discussion.

Simon

[Joe Pham]

Post by Simon C
Are you going to do this? It is a little frustrating suggesting a
feature, getting positive feedback from other team members,
implementing it and then having it removed without any real
discussion.

I think it's just a miscommunication. We did discuss it, and you stated that you weren't able to make the build, so I went ahead and worked it. Maybe I should have made it clear that I was doing it. Good lesson learned for future builds.

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Simon C

Post by Simon C
Are you going to do this? It is a little frustrating suggesting a
feature, getting positive feedback from other team members,
implementing it and then having it removed without any real

discussion.
I think it's just a miscommunication. We did discuss it, and
you stated that you weren't able to make the build, so I went
ahead and worked it. Maybe I should have made it clear that
I was doing it. Good lesson learned for future builds.

I never agreed that to change the way I implemented things. I know you
preferred to see it done a different way, but it that was a style issue,
there was nothing faulty with the way the feature was implemented there was
no reason to believe that it would not work.

The way it stands now I have no idea how to go ahead and make changes for
this feature. Adding auto detect to the first time startup will cause the
detection to run twice once as the code change you ended up making will be
triggered as the main screen starts up, fixable with more code of course.
I'm also not sure that if you don't like the way I implement it that you
won't go ahead and change it anyway as you did here.

Simon

[Joe Pham]

Post by Simon C
but it that was a style issue,

It was more than a style issue, I wouldn't have made the changes if it were.

Post by Simon C
Adding auto detect to the first time startup will cause the
detection to run twice once as the code change you ended up making
will be triggered as the main screen starts up, fixable with more
code of course.

or less.

Post by Simon C
I'm also not sure that if you don't like the way I implement it that
you won't go ahead and change it anyway as you did here.

Only as a last resort, and will inform you well ahead of time.

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Joe Pham

Post by Simon C
but it that was a style issue,

It was more than a style issue, I wouldn't have made
the changes if it were.

The main goal I had was to remove the config dialog
when bitpim ran for the first time.
I must be missing your point about the reason you did
not like the approach I took.
Can you explain where my reasoning below is flawed.

The config dialog runs and completes *before* the
worker thread has started or the main window has been
initialised. In order to get rid of the config dialog
it is necassary to run phone detection prior to the
main thread starting, this means that the existing
phone detect code path cannot be used unless we move
the first time phone detection until after the main
window has initialised. This would have to be
synchronised with the auto detection and only shown if
it failed and it was the first time bitpim was run,
this will require extra code and will mean that the
main window will be running without a valid
configuration (I not sure if this will even work?)

Given the fact that there will be a different way of
running phone detection for the first time bitpim is
run it does not really matter whether the detect at
startup feature uses this new code or the existing
version. I prefer not to use the existing one because
it pops up a message saying the phone was found,
kindof annoying, I think notification on failure is
the only thing we need to report for auto detection.

[Joe Pham]

In order to get rid of the config dialog it is necassary to run
phone detection prior to the main thread starting

You could, but you don't have to.

it pops up a message saying the phone was found, kindof annoying,
I think notification on failure is the only thing we need to report
for auto detection.

That's a different GUI question altogether. In any case, that can optionally be turned off should we want to.

My suggestion was that if you use the existing processing code and path, auto-detect at init would work just like if it were invoked from the menu.

But the main reason for the changes is that in your implementation, if BitPim loses focus while auto-detect is running and subsequently fails, the result dialog gets stuck behind the splash screen giving users the impression of BitPim being frozen or hang.

-Joe Pham



_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!