| Summary: | Konqueror, Kate 3.5.10 toolbar items missing after KDE4 installation | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | MarisN <maris.gis> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 1i5t5.duncan, dan.dickey, esigra, it-knodel, loki_val, nbkolchin, zzam |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 245954 | ||
| Attachments: |
Konqueror-3.5.10 when logged-in as new user for first time
Konqueror-3.5.10 when logged-in as new user for first time kdeartwork-iconthemes-4.1.2.ebuild |
||
|
Description
MarisN
2008-10-13 15:08:29 UTC
ack, same issue here. I guess kiconfinder find the correct icons...? Could you make screenshot how does it look like? Does this occur if you try to login into kde3 as new user? Created attachment 168414 [details]
Konqueror-3.5.10 when logged-in as new user for first time
Created attachment 168416 [details]
Konqueror-3.5.10 when logged-in as new user for first time
same here... moving (or removing) "/usr/share/apps/konqueror/konqueror.rc", owned by kde-base/konqueror-4.1.2, and reseting toolbars to default solves the problem in kde-3.5.10. ACCEPT_KEYWORDS="~x86" USE="-kdeprefix" For some wierd reasons with strace it searches in /usr/kde/3.5 and in /usr for its .rc files. So it loads both and in the end it ends up not usable too much. You can try this behavior with strace. I was not much sucessful about forcing it looking into /usr/kde/3.5 so if anyone else wants to try... *** Bug 242900 has been marked as a duplicate of this bug. *** It sounds like adding "kdeprefix" should solve this problem. Can anybody confirm that? (In reply to comment #8) > It sounds like adding "kdeprefix" should solve this problem. Can anybody > confirm that? > Dont even try that if you dont think about it. Kdeprefix will mean that when we introduce 4.2 your 4.1 will be kept around and 4.2 will be installed as new slot... and so on. So kdeprefix is not fixer. (In reply to comment #9) > (In reply to comment #8) > > It sounds like adding "kdeprefix" should solve this problem. Can anybody > > confirm that? > > > Dont even try that if you dont think about it. Kdeprefix will mean that > when we introduce 4.2 your 4.1 will be kept around and 4.2 will be > installed as new slot... and so on. So kdeprefix is not fixer. But that's no big deal for Gentooer-KDEers who've been around for awhile, as it's always been the case. When you install a new KDE minor version (3.4 > 3.5 for instance), you still have the old one around, just in case you need it, until you're sure everything's working with the new one, after which you can remove the old one. So really, if that behavior continues for 4.1 > 4.2, no big deal, it's the same as it has always been. When you think you don't need the old one any more, you simply remove it. And that would seem less hassle than having /this/ sort of thing happen, particularly since we're already used to that, and don't have to worry about it, while this is a continuing problem we're /not/ used to yet and with no real current solution. OTOH I at least, never needed the old version anyway. Major version change (3.x to 4.x), sure, but not minor. And that's why I went -kdeprefix here. If it works, which it doesn't right now, it'd mean not having to worry about unmerging the old version, used to it as we may already be. So it's worth continuing to work on, but yeah, kdeprefix would probably solve the current problem. (What others it may bring, however, particularly as non-kde-base kde apps get upgraded to 4.x versions and installed, I'm not sure.) Duncan This bug applies to most KDE3 applications running under KDE4, not just Kate/Konqueror.
Caused by /usr/kde/4.2/share/icons/crystalsvg/index.theme file not correctly inheriting the hicolor/index.theme to be able to find the needed PNGs.
The solution is to add the following routine at the bottom of the
kde-base/kdeartwork-iconthemes-4.1.2.ebuild
src_install () {
kde4-meta_src_install
# Fix broken/missing icons for KDE3 applications in KDE4 #
if [[ -z "`grep "Inherits=hicolor" ${D}${KDEDIR}/share/icons/crystalsvg/index.theme`" ]]; then
sed -i -e '/Example=folder/i\Inherits=hicolor' ${D}${KDEDIR}/share/icons/crystalsvg/index.theme || \
die "Sed failed for ${D}${KDEDIR}/share/icons/crystalsvg/index.theme"
fi
}
Created attachment 170499 [details]
kdeartwork-iconthemes-4.1.2.ebuild
Text wrapped oddly in previous post so here is the modified ebuild.
Didn't work for me. I doubt that the problem is in theme file. Icons are correctly displayed in Toolbar Configuration Dialog. Hmm, my mistake. Looks like this bug is *only* relevant to Kate and Konqueror. My post was to do with a more generic breakage of icons in any KDE3 apps. being run in a KDE4 session (encompassing Kate and Konqueror). Another grey area is whether or not the original poster is running Kate/Konq. in a KDE3 or KDE4 session (*shrugs*). I'll file another bug with the fix elsewhere, thanks Nickolay :) (In reply to comment #14) > Another grey area is whether or not the original poster is running Kate/Konq. > in a KDE3 or KDE4 session (*shrugs*). It's not a "grey area". As can be seen from comment #4 it affects KDE 3.5.10 session. Toolbar icon/tool breakage isn't only one issue. I.e. Kolourpaint has menus from KDE4(?) -> it displays "DO NOT TRANSLATE" menu, still KDE3 doesn't have such string in POT file (and Kolourpaint from KDE3 isn't translated to Latvian language) -> menu is coming from KDE4 Kolourpaint version. This affects all kde3 apps which are installed not in $KDEPREFIX (i.e ktorrent amarok kdebluetooth k3b filelight). Those which are installed in $KDEPREFIX seem to be normal. And also this is only related to icons, but not to applications plugins. If it matters, i'm using @kde-live with USE=kdeprefix On "standard" kde-meta-3.* installation, this affects many KDE3 applications: konqueror, kopete. Even when KDE4 applications were never run under user account. Regarding the original issue in #0, does deleting (or #commenting) the line containing dir_data from /usr/kde/3.5/share/config/kdeglobals solve the problem ? Can't test it anymore, as due to this bug I unmerged all KDE4 related things. (In reply to comment #18) > Regarding the original issue in #0, does deleting (or #commenting) the line > containing dir_data from /usr/kde/3.5/share/config/kdeglobals solve the problem > ? > (In reply to comment #18) > Regarding the original issue in #0, does deleting (or #commenting) the line > containing dir_data from /usr/kde/3.5/share/config/kdeglobals solve the problem > ? > The suggested solution solved it for me. (In reply to comment #18) > Regarding the original issue in #0, does deleting (or #commenting) the line > containing dir_data from /usr/kde/3.5/share/config/kdeglobals solve the problem > ? > Works for me. fixed, after hardcoding paths in kdelibs-3.5 |
