[Sparkle] Proposed solution

[Andy Matuschak]

On Aug 5, 2007, at 8:00 PM, Martin Redington wrote:
>> User opens an app using Sparkle for the first time. It gives a brief
>> explanation of what Sparkle is and asks if he wants to install it.
>
> I would really like to see the original behaviour supported. If the
> user chooses not to install the prefpane, I don't want update checking
> disabled for my app.

Yeah, I understand that desire, but I don't really want to duplicate  
the whole thing per-app. I think it would be confusing and stuff. I  
think if it's presented well enough, there shouldn't be any reason for  
the user to not want the prefpane over the per-app thing.

> +1. Could be nicer maybe, but its a good model.

How would you improve it?

> The always install needs a bigger warning sign.
>
> "Always install all updates automatically" (horribly long for a
> button. probably much much worse in German).

Yeah, you're right. I could do it with a check box like fully  
automatic checks in Sparkle, but I don't think that stands out as well  
as a button.

> I'm not sure this is necessary. buttons in tables generally look  
> ugly too.

This doesn't look bad at all: http://img507.imageshack.us/my.php?image=picture1uo9.png

> If I start up an app right in the middle of an update, isn't it
> possible that I'll load some objects (nibs, frameworks, whatever) from
> the pre-update version, and some from the post-update version. That
> could be very undesirable, although it would be rare.

Eh, that's kind of a pathological case. I'm not too concerned. You can  
do that for Apple's SU, too.

> I think you could easily add more functionality to the "applications"
> tab. e.g. version history, release notes access etc.

I see how this would be useful, but I sorta see a prefpane as an area  
of configuration, not an area of information retrieval. It seems weird  
for a user to be going into System Preferences to read a release note.

>> Branches. This could probably wait until after an initial  
>> implementation is
>> done, but I really would like to be able to support public/private  
>> betas
>> while concurrently updating the main feed.
>
> I'd make the appcasts separate as well.
>
> Each app is now uniquely identified by its signature, and its branch
> tag (which can be empty). Sparkle just treats these as different
> items.

Do you see separate appcasts for each branch? Then we just change the  
SUFeedURL to point to the right one?

I do want to support version checkery. The only question is UI: if an  
upgrade requires an OS update, do we show it to the user and mention  
the issue, or do we just keep silent until they're supported. I can  
see how the former could be confusing, but with the latter, you just  
think the app's dead.

On Aug 5, 2007, at 8:36 PM, David Symonds wrote:
> I've written up a bunch of stuff on the Sparkle wiki
> (http://sparkle.andymatuschak.org/wiki/Documentation/PosetVersioning),
> including a proposed branch labelling mechanism.

This is tremendously cool. Have any ideas on representation in the  
appcast? This seems very implementable yet very powerful.

Thanks again, folks.

- Andy Matuschak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andymatuschak.org/private.cgi/sparkle-andymatuschak.org/attachments/20070805/88dca64d/attachment.html