Version: (using KDE KDE 3.4.0) Installed from: SuSE RPMs OS: Linux yes, i have configured my toolbars (why don't you make both the main toolbar and the extra toolbar fully configurable with all features from both toolbars) and ended up in a browser-typical upper toolbar and a row at the bottom with lots of helpful buttons. i'm lucky you made it configurable this way, it's handy. now the upper toolbar has icon size 32x32 and there is no matched go-button, just size 22x22. the blur of the go-button is a little unsatisfying. i wish there was a bigger go-button soon.
Created attachment 12451 [details] snapshot of konqueror, showing configured toolbars and blurred go-button
A missing icon is a bug.
What is probably needed is an SVG.
KDE 4 uses the new oxygen iconset. the bug is no more valid.
Re: Comment #4 That is a totally irrelevant comment. KDE 4 still ships the CrystalSVG icon set: http://websvn.kde.org/trunk/KDE/kdeartwork/IconThemes/crystalsvg/ so there is NOTHING invalid about this bug. Note that this icon is called: "go-jump-locationbar" in KDE 4 Please reopen the bug.
Sorry, I thought that crystalSVG wasn't ported yet. Did you have the SVG version of that icon? I've see you've already renamed the files on 16x16 and 22x22 dirs.
There was a lot of controversy about renaming the icons in KDEArtWork. So, renaming hasn't been completed yet although I started with KDEClassic. Since nobody had done it, I guess that I better get to work on it. I will fix this bug first.
SVN commit 804313 by tyrerj: BUG: 111915 32x32 icon made for "key_enter" AM cr32-key_enter.png WebSVN link: http://websvn.kde.org/?view=rev&revision=804313
Renaming the icons in crystalsvg means the iconset won't be usable for KDE 3 apps anymore! IMHO, if you're renaming the icons, you should add symlinks for the old names. Otherwise we'll have to revert to KDE 3 crystalsvg in Fedora and will never be able to ship the new one, and I think most other distros will be similarly stuck.
Re: Comment #9 No need to revert. But, yes, it is true that if you run KDE 3 apps under KDE 4 that you will need to install both the KDE 3 and KDE 4 icons (with RPM install KDE 3 first and then "install", not "Upgrade" the KDE 4 icons). There might be an issue for CrystalSVG icons since they are in KDELibs and KDEBase. But, this is a packaging issue since there is no problem installing from source (just go to the (version 3) "kde*/pics/crystalsvg/" directories and "make install" The only place where there is a problem is with Oxygen icons where I don't think that there is a complete set anywhere with KDE 3 names.
> with RPM install KDE 3 first and then "install", not "Upgrade" the KDE 4 icons Sorry, this is just plain not possible around here (Fedora). Our tools such as yum won't allow the average user to have 2 versions of a RPM installed (except for the kernel, which is special-cased). Moreover, there are some files which conflict between the KDE 3 and 4 versions, so changing the name of one of them won't solve the issue either, because RPM will error on file conflicts between 2 packages (at least in Fedora it will, unless you use --replacefiles, which is not recommended and which requires calling RPM directly rather than through our graphical tools, so it's definitely not an option!). As one of the Fedora KDE packagers, I know what I'm talking about. > But, this is a packaging issue since there is no problem installing from source That's because make install will blindly overwrite the files. When packaging, this is not an option. We can't ship packages with conflicting files. If you break the KDE 4 crystalsvg for KDE 3 apps, we can't ship it (because crystalsvg is required for KDE 3, it's the default theme).
And FWIW, IMHO the proper solution is to support _both_ sets of names in the KDE 4 version. That's what symlinks are for!
Yes, you would might need to use --replacefiles to install some KDE4 packages. But how do you leave KDE 3 libraries installed? > That's because make install will blindly overwrite the files. You need to install icons from KDE3 first and then install KDEArtWork from KDE 4. There should be no problem with overwriting files. > (because crystalsvg is required for KDE 3, it's the default theme) But you will be running the KDE 3 app in KDE 4 and Oxygen will then be the default theme. I think that this issue might be more complex than either of us realize and I suggest that we discuss it on the KDE-Devel mailing list since it is not relevant to this bug. One thing for sure, KDEArtWork for KDE 4 isn't going to include support for the old names -- the fact that it currently contains some icons with the old names is a bug. This is going to need to be a separate module which I see as a packaging issue since built from source, there is no problem (at least not one I have discovered yet -- but I do intend to research this.
> Yes, you would might need to use --replacefiles to install some KDE4 packages. Once again: official Fedora packages CANNOT require --replacefiles (and I'm sure we're not the only distro which doesn't allow packages to replace each other's files)! > But how do you leave KDE 3 libraries installed? We have a kdelibs3 package which doesn't conflict with the KDE 4 version. We had to work hard on making it work. I don't see why we should do similar workarounds for crystalsvg when it's easy to support both sets of apps from the same sources. > You need to install icons from KDE3 first and then install KDEArtWork from > KDE 4. There should be no problem with overwriting files. This doesn't work when packaging. When packaging, we do one RPM from the kdelibs 3 sources and one from the kdeartwork 4 sources, and the RPMs are not allowed to have conflicting files. In addition, this means we have 2 copies of all the renamed icons when it would be much more space-efficient to have one copy and one symlink. > But you will be running the KDE 3 app in KDE 4 and Oxygen will then be the > default theme. Not really. * If the theme is not set in kdeglobals, KDE 3 apps will still default to crystalsvg. * Even if you explicitly set your theme to Oxygen (or any other theme), the KDE 3 apps have a hardcoded fallback to crystalsvg and will use that if they can't find their icons in Oxygen (or whatever theme you picked). If (and only if) the icon isn't in crystalsvg either, the app ends up with a broken icon. * It's also possible for a distro's default icon theme to explictly inherit from both Oxygen and crystalsvg, which is what our Fedora-KDE theme does. > One thing for sure, KDEArtWork for KDE 4 isn't going to include support for the old names And why? I really don't see a valid reason not to provide compatibility symlinks. For Oxygen, there was a reason (force apps to get ported to the new names), but for crystalsvg, supporting old apps should be on the contrary a requirement.