Sketching in semi-auto update for Qt GUI

[Robert Lipe-4]

This isn't in shape to commit yet, but I thought I'd through it out for discussion while it's still in the early stages.

One of the things I've long wanted in this project is a way to automatically inform users of updates.  I don't believe in installing updates automatically for software like GPSBabel, but I'd like to get the old versions out of circulation over time.    With a cross-platform GUI, since we're already paying the code size of DOM parsers and network connections anyway, this becomes way easier and much  more appealing.

My plan is to put an XML file on gpsbabel somewhere that looks something like:

<?xml version="1.0"?>

<updates>
  <update version="1.3.8" type="major"      detailsURL="http://www.gpsbabel.org/news/bestest_version_ever.html" />
  <update version="1.3.7" type="major"  />
  <update version="1.3.6" type="major"
     detailsURL="http://www.gpsbabel.org/news/20081031.html" />
  <update version="1.2.9" type="major"  />
  <update version="1.2.2-beta2007" type="beta"/>
</updates>


And then have code in the GUI that, on startup,  if it's been a week since it's last checked (and there'll eventually be  an "opt-out" box; it's not in the attached prototype)  check the current running version against the newest in that list and recommend you install a newer one.   Network errors will be silently ignored.  (Hey, I use GPSBabel in hotel rooms w/o internet, too....) No daemons will be installed for forced upgrades.  

The attached patch has some Qt weirdness going on, but it shows where I'm going.    Do any of you see holes in this plan?

RJL




------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
Gpsbabel-code@...
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

[rew]

On Sun, Jul 26, 2009 at 11:16:51PM -0500, Robert Lipe wrote:
> This isn't in shape to commit yet, but I thought I'd through it out for
> discussion while it's still in the early stages.
 
> One of the things I've long wanted in this project is a way to
> automatically inform users of updates.  I don't believe in
> installing updates automatically for software like GPSBabel, but I'd
> like to get the old versions out of circulation over time.

Some developers do not realize how old versions are still running here
or there, and are still usefull. For example, the "red bull x-alps"
race that is going on now. Fourth time since 2003 now. If they made
some software doing the live tracking, they may still be using that
old box from 6 years ago, that simply "still works". (I don't think
they do, because they've switched instruments every time, but they
could...)

> My plan is to put an XML file on gpsbabel somewhere that looks something
> like:
>
> <?xml version="1.0"?>
>
> <updates>
>   <update version="1.3.8" type="major"      detailsURL="
> http://www.gpsbabel.org/news/bestest_version_ever.html" />

Sounds like a plan!

How about the option of filtering out platforms. If say a bug is found
in the windows-gui part of the project, windows users should be told
of the update, but I'd prefer to not to hear about it on Linux.


How about instead of the opt-out, a level below which not to bother a
user? So instead of opting out in one quick blow, you can opt out of
the notifications of minor updates, but still get notified about major
updates. Other people might want to intensify the update notifier to
the level that every new SVN version (or whatever) is mentioned....
Allow checking more often especially for those tracking development?

> And then have code in the GUI that, on startup, if it's been a week
> since it's last checked (and there'll eventually be an "opt-out"
> box; it's not in the attached prototype) check the current running
> version against the newest in that list and recommend you install a
> newer one.  Network errors will be silently ignored.  (Hey, I use
> GPSBabel in hotel rooms w/o internet, too....) No daemons will be
> installed for forced upgrades.

Ok. Network errors sometimes take a long time. So a separate thread
should be used to check for the updates. If it finds one, it should
notify the main program. Or maybe it should just note the info
somewhere in a file, and wait for the next startup?

        Roger.

--
** R.E.Wolff@... ** http://www.BitWizard.nl/ ** [phone] **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

------------------------------------------------------------------------------
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
Gpsbabel-code@...
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

[Khai Mong]

I don't see any issues.   Most users would be happy with just a warning instead of a full installation even if the installation was prompted.

We should probably do this sooner than later, before the new GUI gets out in the wild without it.

I'll look at the patch tonight and see how I can help you with it. 

Khai

On Mon, Jul 27, 2009 at 12:16 AM, Robert Lipe <robertlipe@...> wrote:

This isn't in shape to commit yet, but I thought I'd through it out for discussion while it's still in the early stages.

One of the things I've long wanted in this project is a way to automatically inform users of updates.  I don't believe in installing updates automatically for software like GPSBabel, but I'd like to get the old versions out of circulation over time.    With a cross-platform GUI, since we're already paying the code size of DOM parsers and network connections anyway, this becomes way easier and much  more appealing.

My plan is to put an XML file on gpsbabel somewhere that looks something like:

<?xml version="1.0"?>

<updates>
  <update version="1.3.8" type="major"      detailsURL="http://www.gpsbabel.org/news/bestest_version_ever.html" />
  <update version="1.3.7" type="major"  />
  <update version="1.3.6" type="major"
     detailsURL="http://www.gpsbabel.org/news/20081031.html" />
  <update version="1.2.9" type="major"  />
  <update version="1.2.2-beta2007" type="beta"/>
</updates>


And then have code in the GUI that, on startup,  if it's been a week since it's last checked (and there'll eventually be  an "opt-out" box; it's not in the attached prototype)  check the current running version against the newest in that list and recommend you install a newer one.   Network errors will be silently ignored.  (Hey, I use GPSBabel in hotel rooms w/o internet, too....) No daemons will be installed for forced upgrades.  

The attached patch has some Qt weirdness going on, but it shows where I'm going.    Do any of you see holes in this plan?

RJL



------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
Gpsbabel-code@...
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
Gpsbabel-code@...
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

[Robert Lipe-4]

Khai Mong wrote:

I don't see any issues.   Most users would be happy with just a warning instead of a full installation even if the installation was prompted.

 

That's my thinking.  It's not like this is a critical piece of software like an OS update or a browser,  but notifying people that a new release seems appropriate. 

We should probably do this sooner than later, before the new GUI gets out in the wild without it.

 

I agree.   I also plan to put (optional) usage pattern reporting in before release.   Right now, we can't tell the difference between nobody using some format and there just being no reported problems with it.   How many users of ICG on Linux do we really have?

I'll look at the patch tonight and see how I can help you with it. 

OK, I'll go ahead and commit this to make that process easier.

On Mon, Jul 27, 2009 at 3:51 AM, Rogier Wolff <R.E.Wolff@...> wrote:

Some developers do not realize how old versions are still running here

or there, and are still usefull. For example, the "red bull x-alps"

There are cases where choosing to run old software forever is appropriate.  Just uncheck that box that says "don't bug me again" and don't even think about submitting bug reports or feature requests on it. :-)

How about the option of filtering out platforms. If say a bug is found
in the windows-gui part of the project, windows users should be told
of the update, but I'd prefer to not to hear about it on Linux.

I'd thought about that.  When I recalled the history of the project, I could only think of once where I've bumped one OS independently from the others.  Still, a child tag to update might be appropriate to wire in:

  <update version="1.3.7-mac-and-windows" type="major" >
     <os>Mac</os>
     <os>Windows</os>
  </update>


 

How about instead of the opt-out, a level below which not to bother a
user? So instead of opting out in one quick blow, you can opt out of

We've never had a concept of major vs. minor updates.  We've had betas and we've had releases and those are covered in that 'type' attribute.   We could add a 'minor' there if we later wanted to, but multiple versions are such a pain to create and support that I'm not fond of the idea.

 

> GPSBabel in hotel rooms w/o internet, too....) No daemons will be
> installed for forced upgrades.

Ok. Network errors sometimes take a long time. So a separate thread
should be used to check for the updates. If it finds one, it should
notify the main program. Or maybe it should just note the info
somewhere in a file, and wait for the next startup?

The threads are all asynchronous.  I've triggered the work on the completion callback, so the main thread never blocks.

RJL

------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
Gpsbabel-code@...
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code