Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-update-dev] Investigating some alternative updatemanager

Ed:
Can I quote that little snippet from your email on the wiki page?
That is quite representative of a typical horror end user story.
Now I am not sure we would be able to address that.
Things like addressing issues with the launcher, the startup.jar and the
config.ini that you know well seesm to be in the plan in 3.3 at least.
I do not intend to solve that for now.

> IMHO the biggest problem with the update manager today is it 
> can't update everything. Just the other day I was trying to 
> help a co-worker who reported that a plug-in I wrote wasn't 
> working. It turned out she was running Eclipse 3.0 and the 
> plug-in required 3.1 or 3.2. She had no idea she was running 
> a back-level version of Eclipse. "I've always run the update 
> manager", she said, "and I assumed it would update me". I 
> told her she had to install a whole new version of Eclipse so 
> she did, and of course she unpacked it right on top of the 
> old version before I could stop her. So I had her redo it in 
> a clean directory, but then she lost all the add-ins she had 
> collected (like CodePro) and had to reinstall those. This 
> kind of thing happens all the time. I know exactly why it 
> works this way but it's very user un-friendly.

You also said:
> I wish I could help solve these problems with a code 
> contribution but all I have time for right now is to complain 
> about it and point to auto-updating programs like Firefox 
> that seem to have solved it already. 
We are trying to take the MacOS software update and the firefox theme
and extensions updates as a model for a simple UI.
Hopefully something to make you happy... yet keep expectations low.

A funny discussion we had was what should the UI look like?
- a dialog?
- a wizard?
- a view?
It looks like everyone I asked gave a different opinion.
So the only we could agree on was that would be an SWT Composite ;-)
Yet that compsite may be available either as a view or as a dialog.

What do you think?

-- 
Cheers
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com 
nexB - Open by Design (tm) - http://www.nexb.com 
http://easyeclipse.org  -  irc://irc.freenode.net/easyeclipse



> -----Original Message-----
> From: platform-update-dev-bounces@xxxxxxxxxxx 
> [mailto:platform-update-dev-bounces@xxxxxxxxxxx] On Behalf Of 
> Ed Burnette
> Sent: Thursday, September 14, 2006 8:11 AM
> To: Eclipse Platform Update component developers list.
> Subject: RE: [platform-update-dev] Investigating some 
> alternative updatemanager
> 
> 
> IMHO the biggest problem with the update manager today is it 
> can't update everything. Just the other day I was trying to 
> help a co-worker who reported that a plug-in I wrote wasn't 
> working. It turned out she was running Eclipse 3.0 and the 
> plug-in required 3.1 or 3.2. She had no idea she was running 
> a back-level version of Eclipse. "I've always run the update 
> manager", she said, "and I assumed it would update me". I 
> told her she had to install a whole new version of Eclipse so 
> she did, and of course she unpacked it right on top of the 
> old version before I could stop her. So I had her redo it in 
> a clean directory, but then she lost all the add-ins she had 
> collected (like CodePro) and had to reinstall those. This 
> kind of thing happens all the time. I know exactly why it 
> works this way but it's very user un-friendly.
> 
> The second biggest problem with the update manager today is 
> it doesn't deal with different versions of plug-ins that are 
> targetted to different versions of Eclipse. Case in point. We 
> have an internal update site for plug-ins that employees have 
> written. Recently someone wanted to upgrade an older plug-in 
> to take advantage of a new feature in Eclipse 3.2. However 
> they couldn't because users are running various versions of 
> the Eclipse SDK including 3.0, 3.1, 3.2, or 3.3. And there's 
> also the case of new Eclipse versions breaking old plug-ins 
> that rely on internals (you know you write them). The manual 
> work-around of having a different URL for each version of the 
> SDK (updates/30, updates/31, etc.) is a pain to maintain and 
> get everyone to use it consistently and doesn't scale. There 
> should be a better way.
> 
> I wish I could help solve these problems with a code 
> contribution but all I have time for right now is to complain 
> about it and point to auto-updating programs like Firefox 
> that seem to have solved it already. So if these kinds of 
> issues can be addressed with "Update manager - TNG", that 
> would be great.
> 
> --Ed
> www.pragmaticprogrammer.com/titles/ebgwt/
> _______________________________________________
> platform-update-dev mailing list
> platform-update-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-update-dev
> 



Back to the top