KevinKofler

Uhm no, it is NOT necessary to overwrite the system icons. And in fact it is a horrible idea to do this because that way, the changes will be lost the next time the system theme is updated by the package management (e.g. because of a bugfix update to the package containing it).

What can be necessary is deleting the relevant cache file(s) (I'm not sure which it was, but most likely the plasma-svgelements-* one) in the ~/.kde/cache-*/ folder. - Feb 19 2012

I created that file with xz-4.999.9-0.2.beta.20091007git.fc13.i686, I don't know why it's not working for you.

I may end up uploading a tar.bz2 (which in this case is just minimally larger because most of the contents are already compressed svgz files) if xz is making such trouble. - Nov 13 2010

You need to have xz installed, then Ark will extract it just fine. http://tukaani.org/xz/

It's the latest GNU/Linux compression format, based on the LZMA algorithm. If your distribution is current enough to offer you KDE/Plasma 4.5 or if you built it yourself, I'm sure getting xz shouldn't be a problem, either. :-) - Nov 13 2010

YouTube has changed some stuff again, which broke this tool. Other tools have already been updated. - Aug 29 2011

It looks like YouTube changed something, now the script always triggers HTTP 404 File Not Found errors no matter what format is picked. FYI, the authors of youtube-dl figured out the changes, so you can look at what they changed (but unfortunately their changeset contains some refactoring, so it isn't immediately obvious what the relevant change is). - Jul 23 2010

Can you please add support for downloading the WebM files where they exist? - Jun 08 2010

The Fedora package is broken, it contains a /bin/mkdir binary which conflicts with the system one. - Apr 11 2008

The KDE 4 servicemenu format is slightly different and they're in a different directory. - Apr 11 2008

Sorry for the shameless plug, but I think people using this will probably also be interested in the Oxygen-themed system tray icons for Plasma >= 4.5 (entirely based on Oxygen icons) which I uploaded:
http://kde-look.org/content/show.php?content=134914

If you theme your Plasma to look more like regular Oxygen-themed apps and to honor system colors, the monochrome icons must stick out like a sore thumb!

@Kame2: I see you have partially done system tray icons (a variation on the monochrome theme) which aren't used yet. Would you be interested in using these instead? They're under the same license as the Oxygen icon theme itself (LGPLv3+). - Nov 13 2010

> Distribution packagers are encouraged to run the converter before starting Nepomuk with the --auto parameter.

Huh? How are we to do this? We can't use RPM scriptlets as this has to run per user. And we don't start Nepomuk, your upstream autostart .desktop file does.

Why can't this code be added to the Nepomuk Server so it automatically does this on startup? - Feb 03 2010

> I will work on the bug when a qt-4.6 rpm appears in rawhide repo.

You can get Qt 4.6 Beta for Rawhide (what will be Fedora 12 soon) in the kde-redhat unstable repository. Please get it from there and test your script with it ASAP. Qt 4.6 will not show up in Rawhide until after Fedora 12 is released, which will be in 3 more weeks (and at that point you'll probably not want to run Rawhide as it'll be a big mess). - Oct 25 2009

I am using 4.2.x, 4.2.1 to be precise (we'll have 4.2.2 in Fedora soon). - Apr 05 2009

Hi,

first of all, thanks for this theme. Finally a Plasma theme which fits in pretty well with my Bluecurve/Quarticurve-themed desktop (rectangles with square corners instead of that rounded stuff, honors the system colors).

I found 2 issues with your theme though:
1. A cosmetic issue: the systray rectangle is not high enough, the systray icons overflow on the bottom by something like 3 pixels. Making the panel higher did not fix it, so it looks like an issue with the theme.
2. A pretty serious one: the shutdown dialog does not display. Your shutdown dialog theme appears to be faulty somehow. I noticed there's no object named "background" in your SVG, this may be the issue. - Mar 24 2009

> It DOES work - you just didn't read how blacklisting is implemented right.

I read it exactly and it doesn't work.
> J=`basename $I`
> if ! echo $BLACKLIST | grep $J ; then

This picks the basename of the folder or file, then checks if it's contained in the blacklist. As it searches for the basename in the blacklist and not for the blacklist entry in the basename, it will not find entries where the blacklist entry is not the exact basename (or the basename is a substring of the blacklist entry, which is the wrong way round, e.g. blacklisting xxxamarokxxx will "work" to blacklist Amarok). Searching for foobar in "bla foo baz" will fail.

> Because the settings are incompatible with kget4.

But does it actually break anything? If so, KGet should be fixed. If not, the settings do no bad there, it's OK for you to blacklist them, but it's not an argument against the Fedora setup.

> I want it to be included in kde4.2 by default

And that will be too late because people will already have migrated to KDE 4 by then, and at that point your tool can only break things.

A migration script like that is the wrong solution (it could have worked if it had been ready in time for 4.0, but not now). kconf_update is the way to handle the migration. You can count on me and other Fedora maintainers strongly opposing the inclusion of this tool into KDE, and Debian and Kubuntu will probably join us, as Debian never used .kde4 (just like us) and AFAIK Kubuntu is dropping it in Intrepid.

If applications choke on old settings, they need to be fixed, or get a kconf_update script written, not rely on being blacklisted by a migration tool which can only work as intended on some distributions and which has to be run manually.

Likewise, if kconf_update badly migrates KDE 3 kdesktop and kicker settings, then the script should be fixed, or disabled if it can't be fixed, it makes no sense to hack around it by not copying the files. All the kconf_update scripts were written for a reason, if you remove (avoid copying) files to avoid getting them processed by kconf_update, you're going against the intentions of whoever wrote that script (a developer aiming at a migration as seamless as possible).

> I'm trying to do something useful for people.

But your instructions telling people to use it on Fedora where it is not needed in the first place, by creating the problem (a separate .kde4) just so it can be solved, are not useful nor helpful.

> why exactly are you flaming my project ?

I'm not flaming your project, I'm only saying that 1. it is useless for Fedora and 2. a separate .kde4 is a bad idea and your project can only solve part of the problems it causes. And I don't disagree that it can be useful for distributions which unwisely chose to use a separate .kde4. - Aug 23 2008

It will work, but that doesn't make it useful. It will just copy the files back to where they started in the first place, what sense does that make? - Aug 23 2008

Because this script is completely useless on a distribution which does not use a separate .kde4 in the first place. - Aug 21 2008

Your blacklist contains:
* amarok: Fedora 9 still ships Amarok 1.4. If the Amarok 1.4 settings break current Amarok 2.0 prereleases, then that's a bug in Amarok, which will hopefully be fixed in Amarok 2.0 final. I know the Amarok team is interested in fixing migration issues, they're also working on a collection database migration script. And if no better solution can be found, it's easy to provide a kconf_update script which removes all the offending settings.
* mailody: Fedora never shipped any version of Mailody, so migration issues are not our problem there. (Once the KDE 4 version will get packaged, it will be a new package.) Just as for Amarok, KDE 4 Mailody is still in alpha, and if the settings from the KDE 3 version break the KDE 4 version, that has to be fixed either in Mailody or with a kconf_update script.
* kdev: That blacklist entry doesn't work at all as there's no kdevrc or /usr/share/apps/kdev. If you're trying to blacklist kdevelop settings: KDevelop 4 is far from ready, Fedora 9 still ships KDevelop 3 and Fedora 10 will likely too. It's the same as with Amarok: the migration issues will hopefully be fixed in time for the release. And in the meantime you should fix your blacklist so it actually blacklists all kdev*.
* kdesktop, kicker, ktaskbar: Those settings are completely ignored by KDE 4 anyway.
* kget: Why did you blacklist that one?

Also keep in mind that settings are only a problem if they actually break something. If they're ignored, then of course it makes sense for you to blacklist them because copying them is useless, but no special action is needed for us in Fedora, as the settings don't do any harm if they are ignored.

In short: except possibly for KGet (which you added to the blacklist in 0.0.3, in fact, it's the only addition which might make any sense at all), you're only possibly working around bugs in 3 individual applications, all of them alpha versions, and none of which affects Fedora 9. If any such issue actually affects Fedora in the future, we will provide kconf_update scripts to fix it. But we expect these issues to be fixed where they should be fixed: upstream.

As for KGet, can you please explain what the issue which prompted you to add it to the blacklist is? Is it really caused by old configuration? KGet in KDE 4.0 is broken even with a fresh .kde directory, upgrading to 4.1 fixes it (see http://bugs.kde.org/show_bug.cgi?id=161760). So someone might be mistaking a plain application bug for a configuration issue. But if there really is a configuration issue, then there too kconf_update is the proper solution. - Aug 16 2008

Why would one want to use this script with Fedora in the first place? The entire reason we don't use a separate settings directory for KDE 4 is so you don't have to copy config files around. - Jul 29 2008

Actually, as the author says below, this is already fixed in the current version in kdeartwork 4.1:
http://websvn.kde.org/branches/KDE/4.1/kdeartwork/styles/phase/phasestyle.cpp?r1=784282&r2=808184 - Jul 24 2008

Sorry, I mean "You have to check if option is not NULL." - Jul 24 2008

The backtrace from:
https://bugzilla.redhat.com/show_bug.cgi?id=456614

That's this line:
PhaseStyle::pixelMetric(QStyle::PixelMetric,
QStyleOption const*, QWidget const*) const (phasestyle.cpp:2387)

And this code:
case PM_TitleBarHeight:
return qMax(option->fontMetrics.lineSpacing(), 20);

To the author: You have to check if fontMetrics is not NULL. The documentation for pixelMetric explicitly says "Note that the option may be zero even for PixelMetrics that can make use of it." - Jul 24 2008

Why would you want to use a proprietary application you have to pay for and which you have to run in WINE when there's native GNU/Linux, Free equivalents like p7zip (which already has better KDE integration than this, such as a kioslave and native support in Krusader)?

Moreover, the RAR decompression code has licensing issues, so people will not be able to decompress the RAR archives you're creating with truly Free Software. Creating content in proprietary formats is bad. - Oct 16 2007

Should be fixed now. - Oct 15 2007

I think I found what's going wrong in the code, I'll fix this ASAP. - Oct 09 2007

Thanks for the bug report, I'll look into this. - Oct 09 2007

The color scheme settings work differently in KDE 3.91.0. Also, the readme.txt pointed to the wrong configuration file even for 3.90.1. Here's the relevant instructions for the current KDE alpha:

* For KDE 4 apps:
Best enjoyed with the following palette settings in $KDE4HOME/share/config/kdeglobals
(where $KDE4HOME defaults to ~/.kde4 in the RPMs by Rex Dieter and me at kde-redhat unstable):
[Colors:Window]
BackgroundNormal=230,230,230
ForegroundInactive=127,127,127
ForegroundActive=255,255,255
ForegroundNormal=0,0,0
[Colors:Button]
BackgroundNormal=230,230,230
ForegroundInactive=127,127,127
ForegroundActive=255,255,255
ForegroundNormal=0,0,0
[Colors:Selection]
BackgroundNormal=76,89,166
ForegroundNormal=255,255,255
[Colors:View]
BackgroundAlternate=240,240,240
BackgroundNormal=255,255,255
ForegroundLink=0,0,192
ForegroundVisited=128,0,128
ForegroundNormal=0,0,0
[KDE]
contrast=1 - Jul 04 2007

QtCurve doesn't have much to do with Bluecurve other than the name these days. Yes, it's based on Bluecurve code, but it doesn't look anything like it! And the code has also diverged a lot. This is a port of the original Bluecurve theme as found in the latest redhat-artwork packages in Fedora (5.0.12 or 7.0.0, there are no differences in the Qt and KWin themes between those versions), designed to look as much as possible as the original. - Jun 08 2007

Strigiapplet alone won't do you any good, you have to run the main Strigi daemon to use it. And sorry, but Qt 4 is not optional, you can't build Strigi with Qt 3. - Aug 04 2007