Планируемые улучшения в KDE 4 на русском языке

> Замена KPPP менеджером подключения к сети, устанавливающим соединение с сетью по запросу любого приложения KDE

Дозвон по запросу (dial on demand) - очень спорная вещь.

> Поставка только одного просмотрщика изображений (Gwenview или Digikam?)

Существует любопытный но сыроватый просмотрщик - ksquirrel. Сравним с gqview, в хорошем смысле.

Кстати, сейчас в конквероре кодировка в меню->вид, а в kate в меню->сервис. Видимо утрясется?

>> Для справки: Kopete не входит в Kontact. Этот мальчик сам по себе. :)

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

Где же я это уже видел? :)

> Амарок сам по себе монструозный комбайн - если бы он умел искать русские тексты

Закоммитьте русские тексты на Lyrics.com

>> Поставка только одного просмотрщика изображений (Gwenview или Digikam?)

> Существует любопытный но сыроватый просмотрщик - ksquirrel. Сравним с gqview, в хорошем смысле.

Подзреваю, что vast majority будет за digiKam. Ну и правильно :)

Что касается ksquirrel, то я этих "велосипедистов" откровенно не понимаю: нафига создавать с нуля до фигищи штепселей при наличии KIPI plugins? Ну и точки зрения GUI новых свежих идей как-то не видно.

Это другая библиотека, у нее кроме названия функций и общего названия не может быть много общего. Я думаю это будет по сути отдельный проект.

Иначе просто не может быть

> Можно собрать без лирики, вики и сбора каверов, движки тоже опциональные, нагружает систему ничуть не больше xmms.

у меня есть 2 полуторачасовые записи, amarok на них загибается на всех движках, а c xmms - все в порядке

зы дома получилось - я пользуюсь xmms, т.к. привычнее, а жена amarok'ом - ей нравится все разноцветное

>Все это уже есть в Windows Media Player, жог им как-то аудио диск из плейлиста: удобно, красиво. Он вообще был бы лучшим проигрывателем если бы не тормоза, и некоторая перегруженность интерфейса. Кстати вы будете смеяться

Ты угодал, мы будем смеяться, но над другим. Разве не понятно, что каждая программа должна делать по возможности одно дело, но делать хорошо. Иначе вирусы, дыры безопастности и прочие чудеса интегрированных решений, для устранения дефектов которых надо нарасчивать новые слои ПО.

В результате дыры не исчезают а только маскируются, и появляется дырявый монстр.

:-)

> mdi признан неудобным уже по-моему всеми

я тоже так думал пока не пришлось писать программу, которая должна была запускаться в нескольких экземплярах у 1 юзера. Без mdi они сильно путались где какой экземпляр программы.

Никакому софту не пофиг, под какой ОС работать, хотя бы потому, что подавляющее большинство вызовов функций разные. И функции с разными именами должны работать совсем по разному.

В результате КДЕ под виндой будет типичной виндузячей программой, со всеми их прелестями.

>> Поставка только одного просмотрщика изображений (Gwenview или Digikam?)

> Существует любопытный но сыроватый просмотрщик - ksquirrel. Сравним с gqview, в хорошем смысле.

вообще есть хороший просмотрщий - XnView, но его разработчики 1) использовали motif 2) в последнее время забили на него.

если бы не это - он был бы лучшим, и gtk или qt, все равно что, лучше чем ублюдочный интерфейс openmotif.

ps kuickshow в kde 3.5.2 стал вешаться на больших файлах (удавалось только снимать его процесс по ssh), в 3.5.1 он на них просто сильно тормозил

> Никакому софту не пофиг, под какой ОС работать, хотя бы потому, что подавляющее большинство вызовов функций разные. И функции с разными именами должны работать совсем по разному.

> В результате КДЕ под виндой будет типичной виндузячей программой, со всеми их прелестями.

если его хорошо завяжут на Qt и его программы будут не сильно совать свой нос за kdelibs, то переносить программы будет не сложно.

Может тогда и я пересяду на kde для написания кроссплатформенных программ (пока я его только пользую)

>Никакому софту не пофиг, под какой ОС работать, хотя бы потому, что подавляющее большинство вызовов функций разные. И функции с разными именами должны работать совсем по разному. В результате КДЕ под виндой будет типичной виндузячей программой, со всеми их прелестями.

Ну ты хоть головой подумай чуть! kdelibs крутиться на Qt, а классы Qt идентичны и для винды и для X11 - kde под виндой не будет пользовать winAPI - это забота Qt!

>Кстати, сейчас в конквероре кодировка в меню->вид, а в kate в меню->сервис. Видимо утрясется?

А еще бы она не переключалась в kmail после того, как ее переключили в konqueror (какой-то дебил внес непоправимые "полезные" изменения после 3.4.х), вообще было бы здорово.

Что же это за программа такая?

>Вся надежда на развитие GNUStep.

Боюсь что GNUStep доростет до нужного уровня минимум лет через 5, максимум 3, ибо 1 -- никто не спонсирует, 2 -- четкой концепции я так и не увидел. Больше всего бесит постоянно висящее меню для приложения... вобще какой идиот посчитал, что это удобно и будет удобно для всех(с натяжкой) ? Единственный проект из GNUStep, который заслуживает внимания это WindowMaker, ну плюс от себя это gnumail.

Насчет КДЕ, мда... возможно все будет не так страшно как кажется сейчас, а вообще ждем перевода списка задач на kdelibs, вот где самое интересное. За перевод ребятам огромное спасибо!

>Другая проблема связанная с портированием - это api, интерфейс программирования. Под виндой есть и будут стандарты и интерфейсы программирования, утвержденные мелкомягкими. Неужто КДЕ надеется их переломить и сделать массово используемым свой собственный интерфейс программирования(QT), то чего не удалось даже сан и java ?

А ничего, что Qt под винду уже давно используется? ;)

Контора, где я работаю, пишет софт на Qt под винду уже года 3, если не больше (сам я 2.5 года)....

>какой смысл ставить другой Desktop Environment на виндовс, учитывая тот факт, что большинство софта будет работать _вне_ этой самой Environment?

Тот факт, что проект Aston Shell живет и развивается, говорит о том, что смысл есть.

>Никакому софту не пофиг, под какой ОС работать, хотя бы потому, что подавляющее большинство вызовов функций разные. И функции с разными именами должны работать совсем по разному.

Ты на Qt хоть раз писал?

Я просто пишу код. Не заморачиваясь вопросом, под какой системой это потом будет работать. Собираю под виндой --- прога прекрасно работает при наличии нужных dll-ек. Собираю под линухом (да хоть под Free/NetBSD!) --- тоже прекрасно работает. Я просто ради прикола приносил домой свой текущий рабочий проект на Qt4, собирал под Debian --- никаких отличий! Какие на фиг "большинство вызовов функций разные"?

>Тот факт, что проект Aston Shell живет и развивается, говорит о том, что смысл есть.

я думаю, Aston - это все-таки shell, а не DE :)

>Ну ты хоть головой подумай чуть! kdelibs крутиться на Qt, а классы Qt идентичны и для винды и для X11 - kde под виндой не будет пользовать winAPI - это забота Qt!

Если это я написал спинным мозгом, то что будет когда я последую твоему совету :ъ)

Нет уж лучше все пусть остается как есть, а то вообще друг друга не поймем :ъ)

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

Есть так же чисто архитектурные вопросы, например IPC. DCOP КДЕ-й это ведь IPC ? Что с ним будет? Заменят на СОМ ? Можно, но малой кровью не получиться.

А теперь подумай сам, теперь твоя очередь думать. Под *никсами, КДЕ по сути предоставляет самостоятельный гуи апи и всю инфраструктуру для своего проекта.

Под виндой будет использовать все видновое. Значит от КДЕ остается одна обертка, изнутри это будет винда.

Возьмем как пример мозилу, она кое что использует из родных видновых механизмов, кое в чем имеет абсолютно самостоятельный код, чтобы не использовать кривые виндовые интерфейсы и из соображений переносимости кода. Хочу сказать, что работа по портированию совсем не простая, и по сути представляет отдельный интерес для обсуждения

>DCOP КДЕ-й это ведь IPC ? Что с ним будет? Заменят на СОМ ?

на D-BUS :)

Во первых речь о том, что qt никогда не станет популярным в достаточной степени, что бы стать массовым инструментом программирования под виндой, что означает изоляцию кде как ПО, тем более что сама винда уходит с этого уровня на уровень кодирования с использованием java подобных сред, модернизировав для этой цели даже компиллятор c++. Легкость и удобство программирования, распространенность данного инструмента программирования (qt или mfc .NET) серьезный вопрос, утопивший в винде не мало фирм, предлагающих альтернативные интерфейсы.

Во вторых, насколько я знаю, в кде есть и собственная реализация механизмов IPC. Это предполагает уже уровень архитектурных изменений. Насколько я понимаю, этот уровень невозможно так просто, без серьезной работы переложить на винду.

Ты ведь сам когда то давал ссылку на документацию по D-BUS. И там внятно написано, что он не достаточно эффективен для тех целей, где используется например DCOP.

это означает, что надо как то переписать код для максимального использованиея D-BUS. Но после этого DCOP все равно останется, только будет заниматься более специфичными вопросами.

Мне напомнить, что КДЕ это не приложение, а интегрированная среда, компоненты которой каким то способом взаимодействуют друг с другом. И именно этот способ взаимодействия и есть самая важная часть, и самая тежелая для портирования.

> DCOP КДЕ-й это ведь IPC ? Что с ним будет? Заменят на СОМ

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

>во многих многопоточных программах IPC реализуется собственными средствами

ЛОЛ. КДЕ - это многопоточное приложение? :))))

>за отмазку не катит. Работу можно сменить. =)

Гик, ты дебил или только прикидываешься?

>Гик, ты дебил или только прикидываешься?

а тебя что, взяли исключительно по блату, и в другое место шансов устроиться нету по причине отсутствия квалификации?

>> Амарок сам по себе монструозный комбайн - если бы он умел искать русские тексты

>Закоммитьте русские тексты на Lyrics.com

Я не совсем об этом. Я говорил о том, что русская лирика - это единственная полезная вещь в амароке. А все эти комбайны, открытие пять минут, отжирание 5-7% процессора (xmms больше двух никогда не ел), эти списки, неотрубаемая категоризация по личным амароковским предпочтениям... От лукавого это всё. От Билли то бишь.

>Сам класс "чисто музыкальных проигрывателей с единственным плейлистом" уходит в прошлое.

Ну а мне вот как раз и нужно - чисто музыкальный проигрыватель с единственным плейлистом. Тем более что я как-то привык разделять магнитофон и телевизор - разные устройства и для разного предназначены.

PS Лучше бы он искал интернет-магазины с самым дешёвым пивом...

> Да, ради kontact'а, konqueror'а, kate'а. Хотя бы для

Аналоги evolution, firefox, gvim уже есть под виндой.

> Кстати, сейчас в конквероре кодировка в меню->вид, а в kate в меню->сервис. Видимо утрясется?

На багтраке уже есть пожелание сделать унифицированно. :)

Не совсем так.

На D-Bus будут переводить kde под всеми платформами(не imo). А d-bus реализуется поверх posix ipc(помоему сокеты) которые есть и в *nix и в windows.

>А d-bus реализуется поверх posix ipc(помоему сокеты) которые есть и в *nix и в windows.

d-bus может быть реализован и поверх NamedPipes. Это не принципиально.

А вот posix ipc в win* нету

>Однако разница в устройстве ядра и прочего не может не сказаться и на библиотеках КДЕ.

В том-то и дело, что врядли скажется. kdelibs - это механизмы kparts(не как не зависит от платформы), kio(мелкие плагины, работающие зачастую поверх posix api), kjs(интерпретатору тоже пофиг), khtml (так-же), ksvg(xml он и в африке xml).

Так-же там появится Phonon(для звука), который может выбирать разные библиотеки, в том числе и кросплатформенные. Про D-Bus см пост выше.

Пайпы там вроде есть. Может и не совсем такие-же как в posix(различий imo минимум).

Ну с тем, что перенести эти ~0.5Mb кода можно твое утверждение imo не противоречит.

>>Однако разница в устройстве ядра и прочего не может не сказаться и на библиотеках КДЕ.

>В том-то и дело, что врядли скажется. kdelibs - это механизмы kparts(не как не зависит от платформы), kio(мелкие плагины, работающие зачастую поверх posix api), kjs(интерпретатору тоже пофиг), khtml (так-же), ksvg(xml он и в африке xml).

Сомнительно это как то , особенно о posix в винде. Они никогда особенно не увлекались его поддержкой. Так же есть важная часть КДЕ, которая занимается IPC. Что бы вы не делали, какие D-BUS не использовали, это только для *никс. В винде COM и прочие чудеса.

Там файлы как-то по другому читаются, или сокеты, или пайпы?

Насчет kio я возможно даже немного наврал, в Qt есть классы для работы с сокетами, файлами и тд. и то, что qt уже несколько лет успешно работает под windows говорит о том, что если проблемы и есть то они преодолимы.

Насчет COM и D-BUS я вероятно не совсем понял вашу мысль. Ни что не мешает использовать приложениям kde использовать d-bus и не использовать com.

Нет в винде никакого D-BUS. А есть COM.

D-BUS то же надо портировать, а это наверняка большие тормаза чем при использовании СОМ.

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

Насчет тормозов ничего сейчас сказать нельзя, пока нет реализации но то, что dcop сейчас работает похожим образом(отдельный процесс-сервер общаестя с каждым приложением через системные ipc) и все весьма нормально. К тому-же dbus сейчас вроде успешно используется в gnome.

Блин, с грамотностью у меня траблы =((, sorry.

Ты ответил на мой вопрос.

>Ты ответил на мой вопрос.

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

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

И все, что вне этого ядра будет работать медленее, кушать больше ресурсов.

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

> Я не совсем об этом. Я говорил о том, что русская лирика - это единственная полезная вещь в амароке.

Ну надо же! Раз так, немедленно прекращаю пользоваться встроенным фронт-эндом к википедии! :)

у меня основной плейлист из 1-2 часовых треков состоит(ASOT), зиновским движком играется на ура. Оставляю иногда на ночь (чиллаут или психоделику если спать мало), тоже никаких проблем (в более ранних версиях амарока были)

> а жена amarok'ом - ей нравится все разноцветное

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

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

DCOP уже отрезали...

http://www.kdedevelopers.org/node/2058