faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Plasmoid packages
by Diederik van der Boor on Monday 18/Jun/2007, @04:38
|
| I think you should compare this with Firefox extensions. Users won't and shouldn't look for the 'firefox-webdeveloper' or 'firefox-firebug' extension in their package browser. Or a "kdelook-wallpaper-N" package. Each user has different preferences for their extensions, so this is a user-level thing, not system-wide. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Plasmoid packages
by dario on Monday 18/Jun/2007, @08:34
|
True, but bear in mind that Firefox extensions *are* available as packages in at least some distros (like Debian et al). It does make some sense to have a system-wide manner of updating them because of bugs, for example.
In any case, Firefox extensions provide a good reference point from which Plasma developers can design their packaging system. I am thinking in particular of the problems related to security (will plasmoids be authenticated somehow?).
|
[
Reply To This | View ]
|
Re: Plasmoid packages
by Aaron J. Seigo on Monday 18/Jun/2007, @10:52
|
> but bear in mind that Firefox extensions *are* available as packages
just as kicker applets are and, in the future, plasmoids will be. the concepts are parallel and don't really interact in the way you seem to be implying.
> have a system-wide manner of updating them
for ones that are installed system-wide, sure. for things that the user installs themself, maybe not so much.
we do support versioning of the packages, however, so we could offer update notifications.
> Firefox extensions provide a good reference point
what would you suggest are the strong points to learn from?
note that plasmagik packages are already quite flexible (runtime definition of expected package structure), integrate with kde's plugin metadata system and there is a GUI to step one through the creation of a package so you don't have to do it by hand. plasmoid packages themselves may also come in a few different scripting languages.
> will plasmoids be authenticated somehow?
see my other reply in this thread.
|
[
Reply To This | View ]
|
Re: Plasmoid packages
by dario on Monday 18/Jun/2007, @12:01
|
> just as kicker applets are and, in the future, plasmoids will be.
Excellent!
> what would you suggest are the strong points to learn from?
I was thinking of a) a trusted repository like the Mozilla Addons site (which Plasma will also have, as you mentioned in the other thread), b) a notification of when updates are available (which again Plasma will also have), and c) a straightforward way of installing/removing plasmoids (which I am sure is also in your plans). In fact, you seem to have everything already covered! Moving on...
> we do support versioning of the packages, however,
> so we could offer update notifications
Yeap, that would be very useful, particularly for those plasmoids that the user has privately installed, ie, those that are not system-wide.
But consider that the update mechanism will have to distinguish between packages that are installed system-wide and those that are privately installed. Just imagine the following situation:
There is a "Foo 1.0" system-wide plasmoid installed, and the user has a private installation of "Bar 1.0" (there are no dependencies between the packages). Now, a new version 2.0 is released for both Foo and Bar. The plasmoid updater will of course notify the user that the new versions are available. In the case of Bar, upgrading is straightforward, but what to do with Foo? One option would be for the plasmoid updater *not* to upgrade and instead to inform the user that they should use whatever mechanism is available in their distro to perform a system-wide upgrade. This has the disadvantage that the distro's update for the Foo plasmoid could take a while before it is available from their repositories. Another option would be for the plasmoid updater to upgrade anyway, installing version 2.0 of Foo as a private installation (which supersedes the system-wide package). But then you have the question of what happens when the system-wide package is also upgraded: will you end up with two copies of the same package, or will the plasmoid updater be smart enough to remove it when no longer needed?
|
[
Reply To This | View ]
|
Re: Plasmoid packages
by Aaron Seigo on Tuesday 19/Jun/2007, @09:48
|
i've actually thought about the issues you bring up in your last paragraph. for now, i'm punting on it but will revisit it for 4.1. it is a non-trivial problem, but we do have all the pieces we need to create a proper solution so i'm not worried. it's just doing the rather detailed work.
right now i'm concentrating on getting the Big Basics together for 4.0... the cuter stuff, like managing differences between local and system wide installs of plasmagik updatable packages, will come after that
|
[
Reply To This | View ]
|
Re: Plasmoid packages
by dario on Tuesday 19/Jun/2007, @13:15
|
> it is a non-trivial problem
Indeed. And it gets all the more non-trivial once you start taking package dependencies into account... But anyway, you are right that it is perhaps a bit too soon to be worrying too much about it.
But when that time does come, be sure to have a chat with the Debian guys about this issue; I wouldn't be surprised if they had already encountered it and given it a lot of thought...
|
[
Reply To This | View ]
|
Re: Plasmoid packages
by Aaron J. Seigo on Wednesday 20/Jun/2007, @20:39
|
dependencies are pretty much a non-issue. we're talking about leaf-node add-ons here.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
