LINUX.ORG.RU

А всё-таки KDE 4.2 должен использовать Qt 4.5. Мнение сотрудника Qt Labs

 ,


0

0

Вчерашняя новость о проблемах в KDE 4.2, вскрывающихся при переходе на новую версию Qt, вызвала много откликов по всему миру.

Тьяго Масиэйра (Thiago Macieira), сотрудник Qt Labs (бывшей Trolltech) и участник разработки KDE, заявляет в официальном блоге Qt Labs, что KDE 4.2 можно и нужно использовать с новой версией Qt.

Сокращённый перевод:

Да, разработчики плазмы не тестировали KDE 4.2.0 с Qt 4.5, у них недостаточно ресурсов на это. Да, дистрибутивам следует быть осторожными при обновлении Qt. Но в этом — проверке на отсутствие ошибок и написании врЕменных патчей — и состоит работа дистрибутивов.

Зато в Qt Software тестировали плазму с Qt 4.5. И установили, что она лучше работает с Qt 4.5, чем 4.4.3, хотя патчи qt-copy не будут бесполезны. Наконец заработал трей. Улучшилась и работа других компонентов KDE, например, отпала необходимость задавать QT_NO_SHARED_PAINTER=1 при запуске Kontact. БОльшую часть исправлений из Qt 4.5 в ветку 4.4 не переносили. В 4.5 заметно возросла производительность, в том числе при отрисовке.

Кроме того, чем раньше начнут широко использовать Qt 4.5, тем больше будет багрепортов и тем скорее его исправят. Особенно полезна обратная связь с сообществом KDE.

И вообще, релиз-кандидат Qt 4.5 гораздо стабильнее релиз-кандидата Qt 4.4 10-месячной давности.

>>> Подробности в блоге labs.trolltech.com

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от question4

>Только теперь нажатие цифрового Insert воспринимает так же, как Shift-Insert.

Боюсь никак... Разве, что только пользоваться <Shift>Insert (а не <Shift>KP_Insert)...

Shift, это типа временный Num Lock (при его нажатии, и на время его нажатия, цифровая клавиатура переходит в состояние противоположное до нажатия), т. е., в случае отрубленного Num Lock, <Shift>KP_Insert выведет 0, а так-как KP_Insert работает только при отрубленном Num Lock, а кейбиндинг <Shift>KP_Insert жесто задан для вставки (хотя, "официально" должен вывести 0), то это, имхо, и приводит к такой ситуации... Както-так...

unihorn
()
Ответ на: комментарий от unihorn

> Shift, это типа временный Num Lock

Давно отключил в xorg.conf
Option "XkbOptions" "numpad:microsoft"

Всё, что выше — именно в таком режиме.

В режиме по умолчанию XFCE видит эту комбинацию как <Shift>KP_0 при выключенном NumLock и <Shift>KP_Insert при включённом. Если прописать <Shift>KP_0 в ~/.gtkrc-2.0, в GTK-приложениях правый Insert работает как вставка из буфера, а Shift-Ins вставляет 0. Если включить NumLock, Shift-Ins будет вставлять, но Ins будет ставить 0.

Под гномом при задании через .gtkrc-2 правый Ins ведёт себя так же.

Но в режиме numpad:microsoft Ins и Shift-правый Ins нормально работают в фаерфоксе, OpenOffice и программах на Qt. То есть жёсткой привязки нет.

Есть ещё идеи, куда копать?

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

>Есть ещё идеи, куда копать?

Боюсь, на данный момент, я тебе уже не помошник... :(

Если в gtkrc, для KP_Insert прописать пустую операцию, то вставлять он не будет, но..., но и <Shift>KP_Insert, также работать не будет: ни в каком виде....

Если сделать

bind "disabled" { "numpad:microsoft" () }

Реакции на комбинации клавишь с цифровой клавы, вообще не будет (в зорге я это, правда, не отрубал).

Путь явно есть (при забивании <Shift>KP_Insert на, что-нибудь через настройки Гнома, она работает коректно), но путь этот, на сей раз, мне не известен... :(

Единственное, что могу на данный момент посоветовать, это использовать только <Shift>Insert (он работает без вопросов)...

unihorn
()
Ответ на: комментарий от question4

>и программах на Qt

Насчет чистого Qt не скажу... Но, лично у меня, 4кеды (как в третих не помню, ибо никогда не использовал цифровой Insert для подобных целей) видит цифровой Insert как обычный... (сиречь, при привязки к нему, выставляет Инсерт обычный, после чего, операция работает только с ним, а на цифровой не реагирует (скажем, сейчас, попробовал сделать для открытия меню Клиппера Ctrl+Alt+KP_Insert))...

unihorn
()
Ответ на: комментарий от unihorn

> 4кеды

На эту кривулину ориентироваться нельзя. Мало того, что в 4.0.х часть клавиш игнорировалась, так оно их все забывало через 1-4 часа или при перезагрузке. (За это и снёс.) Но чистый Qt 4.x и КДЕ 3.5.х работали приемлемо.

Жду ответа в рассылке GTK :)

question4 ★★★★★
() автор топика
Ответ на: комментарий от Alex007

>"g kde plasma" в первой же ссылке выдает:

не, читать-то я и так умею... а по делу если - что даёт плазма?

shty ★★★★★
()
Ответ на: комментарий от shty

>а по делу если - что даёт плазма?

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

Apple Dashboard и виджеты Opera, имхо, и к Супер Каррамбе приделать было можно... Концепцию "Все есть виджет", думаю, тоже...

В общем, ничего особо нового, того чего не было в Каррамбе, Плазма, имхо, не принесла...

Единственная интересная наработка четвертых Кед это Фонон. Но даже из-за него "ломать все и делать с нуля" было не нужно...

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

unihorn
()
Ответ на: комментарий от unihorn

>Концепцию "Все есть виджет", думаю, тоже...

Полезность и нужность этой концепции, правда, тоже, имхо, под большим вопросом...

unihorn
()
Ответ на: комментарий от unihorn

Re^2: А всё-таки KDE 4.2 должен использовать Qt 4.5. Мнение сотрудника Qt Labs.

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

По словам разработчиков, некоторые вещи было намного проще переписать, чем портировать. Включая код панели. пусть дольше, но - соблюдая введённые стандарты на качество кода, с возможностью лёгкой поддержки в дальнейшем.

Сам код не смотрел, не знаю. Им виднее.

krege
()

>но - соблюдая введённые стандарты на качество кода

Где эти стандарты? :) Я их, чё-то не вижу...

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

>Включая код панели

Особенно ее было сложно портировать. :) Проще, недоделаный и глюкавый виджет написать было. :)

>с возможностью лёгкой поддержки в дальнейшем.

Это можно сазать, и про третьи Кеды. :)

unihorn
()
Ответ на: комментарий от unihorn

Re^4: А всё-таки KDE 4.2 должен использовать Qt 4.5. Мнение сотрудника Qt Labs.

> Где эти стандарты? :) Я их, чё-то не вижу...

А они есть!

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


Портирование костылей посчитали делом ненужным.

> Особенно ее было сложно портировать. :) Проще, недоделаный и глюкавый виджет написать было. :)


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

>>с возможностью лёгкой поддержки в дальнейшем.


> Это можно сазать, и про третьи Кеды. :)


Сказать - можно. И всё.

krege
()

>А они есть!

Где?

Пока вижу глюкавый, а то бажный софт.

Нет, я согласен, софта без багов, глюков, или, как минимум, недостатков, нет (нигде: не в мире открытого, не в мире закрытого ПО). Но когда, фактически, ты видешь "недостатки без софта"... )

Или это стандарты такие новые (кто их, стандартописателей знает)? :)

>Портирование костылей посчитали делом ненужным.

Создание новых гораздо круче. :)

>В каком месте он глюкавый был?

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

>Сказать - можно

И сделать. :)

И, самое забавное, делали. :)

unihorn
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.