[p6] KDE-4.7

[zerg]

на панели задач остается приложение после его закрытия, появилось это в kde 4.7. Лечится открыванием нового приложения.

В 4.7 уже исправляли в нескольких местах, но в 4.8 все еще проявляется. А вообще это может зависеть от настроек виджета, т.е. можно попробовать поиграться с ними. Например, у меня панель вертикальная и не замечаю подобного.

[nevkon]

Пока не понял зависимости, но иногда нельзя свернуть активное окно щелкнув по кнопке приложения в панеле

[zerg]

Например, у меня панель вертикальная и не замечаю подобного.

Нарвался и на вертикальной.
Я сам вряд ли смогу исправить. Будем надеяться на авторов.
Так же это может зависеть от версии Qt. Вроде, про ее баг были комментарии в исправлениях.

[БарсSc]

Нарвался и на вертикальной.
Я сам вряд ли смогу исправить. Будем надеяться на авторов.
Так же это может зависеть от версии Qt. Вроде, про ее баг были комментарии в исправлениях.

Заметил, что в основном остаются на панели приложения занимающие много памяти, например firefox, krusader если долго им пользуешься без закрывания, как будто панель не может обновится при закрытии программ.

[БарсSc]

Появилось предположение, что обновление панели происхолит раньше, чем полностью закроется программа, из-за этого она остается. Поэтому глюк проявляется на тяжелых программах, на более быстрых процессорах такой эффект редко встречается т.к. программа успевает выгрузится до обновления. Как будто где то выстовлено через какое время должна обновляться панель при закрытии программ.

[unihorn]

Заметил, что на панели задач остается приложение после его закрытия, появилось это в kde 4.7. Лечится открыванием нового приложения. Установил icon-task manager, на нем то же самое. Причину появления пока не могу выяснить.

А проблемами с обновлениями дистра до новой версии это не может быть? Честно говоря не замечал такого...

***

У меня другое, кстати говоря...

Настройки (такие как плазма-тема, тема иконок...) некорректно применяются...

Не корректность заключается в том, что новое оформление может (так или иначе) наложится на старое (и получится этакий "микс" (выглядящий, порой, очень криво))... А, иногда, новое оформление, вообще не отображается...

Чтобы заработало надо чистить кэш Кед (папки /home/HOMEUSER/.kde4/cache-LOCALHOST.localdomain, socket-LOCALHOST.localdomain и tmp-LOCALHOST.localdomain)...

Такая штука наблюдается как минимум с 4.6.5 Kед (и не только на Альте: есть на Росе, есть на Кубунте...).

Плюс, такое ощущение, что некоторые графические стили окон (в текущей поставке Альта это oxygen, скажем) перебивают в глобальном варианте те, что стоят у пользователя (при запуске приложений от них от других пользователей)...

К примеру поставил приложениям рута стиль окон основанный на OTCurve, но при запуске рут приложений (даже от su -) запускается oxygen-oвое оформление... Пришлось подменять oxygen-овую so-шку qtcurve-шной (под именем oxygen-овой); а oxyge-новую переименовывыть в другое имя (дабы oxyge-новый стиль сохранился)...

Кстати говоря... Oxygen-овая gtk тема не дает корректно примениться otcurve-шному gtk стилю: причем у текущего пользователя (также приходится бубнить с переименованиями).

Опять же глюки с графическими стилями окон, это глюки не только Альта (в Росе c bespin-ом (полностью (а не как в Альте: основные либы) ставящимся в ней вместе с xbar...) можно намучится; да и iaora тамошняя так глючит)...

Как видно из моего поста, в Кедах пошли какие-то непонятки с процессом их настройки того или иного вида (как минимум с процессом настройки внешнего вида)... И я как не любитель дефолта давно уже эти бяки подметил...

[zerg]

новое оформление может (так или иначе) наложится на старое (и получится этакий "микс" (выглядящий, порой, очень криво))...

rm -f /var/tmp/kdecache-$LOGNAME/*.kcache

Oxygen-овая gtk тема не дает корректно примениться otcurve-шному gtk стилю: причем у текущего пользователя (также приходится бубнить с переименованиями).

set| grep GTK

[unihorn]

rm -f /var/tmp/kdecache-$LOGNAME/*.kcache

И?..

Это и делается... Чистится кэш (см пост выше).

Почему Кеды это не делают сами (или почему старый кеш влияет (ибо раньше такого я не припоминаю)), правда, не понятно.

set| grep GTK

Все что касается GTK в полном порядке. Тему gtk можно включить, но она не работает (глючит). При, например, включении gtk-шной (или любой другой) темы qtcurve, oxygen-овая перебивает. Чтобы работало (и не перебивало) надо несколько "побубнить" (см пост выше): переименовать, или удалить oxygen-овую gtk тему...

И да. Я знаю как обходить эти кедовые глюки, и заставить систему работать как мне надо. :)

Речь не о том "что делать" (я и так это знаю). Речь о том, что эти глюки ПРОСТО ЕСТЬ (раз зашла речь, о глюках Кед), и глюки эти довольно противные (более того они не только в Альте: сиречь это чисто кедовые глюки, а не глюки дистра).

[zerg]

set| grep GTK

Все что касается GTK в полном порядке

Если еще где-то бубните -- не в порядке

[unihorn]

Если еще где-то бубните -- не в порядке

Только для выше названного Кислорода. Тему gtk можно применить любую: от redmond-a до pixmap-овой. Но в случае наличия Кислорода он перебивает эти изменения. Чтобы gtk темы не перебивались gtk-ейным Кислородм его надо удалить, или переименовать. "Глюки тем при установленном Кислороде", заключаются лишь в том, что какую-бы ты тему gtk не выбрал, всегда грузится лишь Кислород (сами темы, в полном порядке).

При этом "set| grep GTK" никакого эффекта в данной ситуации не несет (повторяю: с gtk в се в полном порядке): Кислород как перебивал темы (ставя вместо них себя) так и перебивает.

Но то что не впорядке именно с Кислродной темой gtk, это факт. :) Правда, сколько себя помню, gtk-ейный Кислород всегда был глючным (и опять-же, не зависимо от дистра (сиречь это не проблема Альта: это проблема Кед в целом)).

ЗЫ.

Кстати говоря, по поводe моей недавней записи в иконоkdmовом баге на багзиле ( https://bugzilla.altlinux.org/show_bug.cgi?id=26950#c27 ).

Ставили на жесткий диск (желательно реальный)? Походу, при такой установке, на хомяки ставятся права отличные от живого диска (дефолтные права при установке на (как минимум реальный (с виртуалкой не эксперементировал)) жесткач (сразу после установки, и при дефолтных политиках системы),: rwx --- -x)...

Посему, имхо, одно из двух: либо считать отличия политики хомяковых прав жесткача багом и править их; либо не считать (но тогда, данный мной паттерн, точно работает))...

[zerg]

При этом "set| grep GTK" никакого эффекта в данной ситуации не несет

Видимо, и не принесет. 3-й раз повторять смысла не вижу.

[unihorn]

Видимо, и не принесет. 3-й раз повторять смысла не вижу.

Именно!

Что выполняй сию "директиву", что не выполняй, эффект один: Кислород перебивает другие gtk темы (единственный способ это исправить удалить его, или переименовать: "директива" же просто отрабатывает в "молоко" не неся своей отработкой ничего для исправления (знаю, пробовал...)))...

Почему так, одному богу и известно...

[zerg]

Что выполняй сию "директиву", что не выполняй, эффект один:

Я уже понял, что вы не понимаете, зачем ее выполнять. Даю намек: ищите знакомые буквы.

[unihorn]

Я уже понял, что вы не понимаете, зачем ее выполнять. Даю намек: ищите знакомые буквы.

Так объсните мне, чего я не понимаю? И что делаю неправильно удаля, или, как минимум, переименовывая (хотя удаление проще и корректнее) Кислородный gtk?

Я конечно тоже понимаю, что вы не понимаете, что соответствующие переменные как ссылались на gtcrc файлы Кислородного джитикея, так и ссылаются (можете сами проверить, коли не верите, что я это делал)...

И посему эффекта от соответствующего "белого выхлопа на черном фоне" нуль (кроме как вызывания желания удалить, или переименовать соответствующую тему (как наиболее простое, и естественное решение, ибо глюки ее никому, как минимум мне, не сдались)).

Или вы предпочитаете метод не "починить дорогу", а "типа правкой скриптов, и подобным", "досочки поверх глубокой ямы положить, чтобы люди ходить могли"? :)

Меня больше это интересует:

ЗЫ.

Кстати говоря, по поводe моей недавней записи в иконоkdmовом баге на багзиле ( https://bugzilla.altlinux.org/show_bug.cgi?id=26950#c27 ).

Ставили на жесткий диск (желательно реальный)? Походу, при такой установке, на хомяки ставятся права отличные от живого диска (дефолтные права при установке на (как минимум реальный (с виртуалкой не эксперементировал)) жесткач (сразу после установки, и при дефолтных политиках системы),: rwx --- -x)...

Посему, имхо, одно из двух: либо считать отличия политики хомяковых прав жесткача багом и править их; либо не считать (но тогда, данный мной паттерн, точно работает))...

Или настолько уверены, что я несу, якобы пургу (в чем меня сложно обвинить), что не желаете даже попробовать (даже на любимой вами ВМ: хотя тестирование на рельном железе более корректны (раз в сто, согласно моему опыту))?..

И да rwx --- --x... (тире пропустил, хотя, имхо, понятно о чем я).

[zerg]

Так объсните мне, чего я не понимаю?

Разбирайтесь зачем я вам написал ту команду или заведите отдельную тему, где найдутся желающие.

И что делаю неправильно удаля, или, как минимум, переименовывая (хотя удаление проще и корректнее) Кислородный gtk?

Удаляете или, как-минимум, переименовываете.

Я конечно тоже понимаю, что вы не понимаете, что соответствующие переменные как ссылались на gtcrc файлы Кислородного джитикея, так и ссылаются (можете сами проверить, коли не верите, что я это делал)...

Я не понимаю это; я в этом уверен.

Или вы предпочитаете метод не "починить дорогу", а "типа правкой скриптов, и подобным", "досочки поверх глубокой ямы положить, чтобы люди ходить могли"? :)

Если что-то сломано -- вешайте багу. Так же между "дорогой" и "скриптами" вы забыли перечислить "настройкой конфигурационных файлов".

https://bugzilla.altlinux.org/show_bug.cgi?id=26950

Я там написал все, что необходимо.