4

I'd like to start with saying that there are currently three ways of installing
and updating plasmoids (at least in openSUSE 11.1, I am sure it looks similar
in other distros) - for the scripts available on kde-look.org, it's
khotnewstuff, and for binaries, one can either compile them (harder, needs
manually checking the updates) or downloading from YaST2 (easier, automated
updated, but some plasmoids are REALLY outdated (e.g. Daisy))

My idea is to make this process doable in only one application, and avoid the
situation where the user if forced to either choose between up-to-date
plasmoids or compilation process (hard for newbies).



Idea 1:
I once browsed KDE4 configuration files, and AFAIR, I stumbled upon a
configuration file where the URL was stored to kde-look plasmoid scripts
database. This made me think that maybe distro devs could someday think of
their own repository with plasmoid binaries (because the kde-look one from
khotnewstuff contains only scripts, obviously) - that way it would be more user
friendly to the user, because he/she wouldn't have to use
YaST/KPackageKit/Yum/whatever to install plasmoids rpms/debs. Of course, the
plasmoids available in the future khotnewstuff binary plasmoid repo would be
rpms/debs as well.

So generally it would be just the same as now, with the difference that
plasmoids won't be installed through YaST/KPackageKit/Yum/whatever, but through
khotnewstuff.

It has some big disadvantages, though. I was really disappointed with the way
the plasmoids are handled in the KDE Community repo (I mean openSUSE 11.1,
propably similar in other distros). Most of the ones I searched for were
outdated (I understand 1 or 2 day lag between code release and rpm/deb release,
but search for the already mentioned Daisy repo version was 4.3, and 4.12 is
already available). That's what made me learn how to compile, and at the
beginning, it was really hard to understand how it all works. It is still
annoying I need to check for updates manually.

So either the KDE Community maintainers decide to pay more attention to the
plasmoids, or the users will still be left with the outdated/compilation choice
I wrote about above.



Idea 2:

It would surely require more work, but in my opinion, it is a much better
choice. The whole process will be automated, and there will be no other people
between the plasmoid devs and end users, which would result in always
up-to-date plasmoids.

My idea is generally similar to Idea 1 when it comes to khotnewstuff, but the
origin of the binary plasmoids will be different. All the plasmoids I know so
far can be compiled&installed with this script:

Code: Select all

#!/bin/bash

if [ ! -d build  ]; then
    mkdir build
fi

cd build
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..
make clean
make
if [ ! `whoami` = "root" ]; then
    echo
    echo "The installation requires root privileges. "
    echo "Authentication required - CTRL+C to cancel:"
    sudo make install
else
    make install
fi

if [ ! `whoami` = "root" ]; then
    kbuildsycoca4
fi


Credit goes to Daisy plasmoid developer, Lechio.

So khotnewstuff would just download the source code off kde-look, store it in
some hidden folder, then execute the script. Uninstalling is even easier:

Code: Select all

sudo make uninstall && make clean


The other advantage is that it would make the process distro-independent.

There is only one downside, but it's a big one, though. I mean the compile
dependencies. (in openSUSE - kernel headers, libkde4-devel and
kde4-workspace-devel, AFAIR, and other distro maintainers would need to supply
with the info about how the packages are called in their packaging system)

Some plasmoids have also prerequisites, and it would be necessary for
khotnewstuff to check the distro and download the appropriate rpms/debs with
prerequisites.

What do you think?

This script could contain list of dependencies required (and links to their sources, if they are not available). Then go though possible package managers and try to find these packages. If by suggested name it is not found, try wildcard. If found more than one candidate try to check for dependencies (the best to sort by date, newest packages on top). Install the first that does not cause conflicts. If dependencies not found install by link suggested by in dependencies list

This (global install) could even a kde wide library/port to all/any package manager, so script could call only "kinstall package1 package2" and kinstall would work as I wrote in beginning.


Only if this is technically possible

Yep, it would be great if something like that were possible

This is a duplicate of KNewStuff support for KWin styles, KStyles, Plasmoid binaries etc.