Где кончается одно DE и начинается другое?

В kde с этим как-то более грустно, масса kdelibs-зависимых велосипедов, не смотря на то, что чистый Qt рулит, педалит и официально одобрен Марком

Если бы в Qt были все возможности kdelibs, писали бы на Qt

Я долбанулся, или же тут все-таки писали пару месяцев назад, что kdelibs сделают модулями к Qt?

> но зачем же изобретать колесо заново
Может, потому что у велосипеда «плюсы» 101 колесо и при этом все равно проблемы с устойчивостью? А еще потому что в мире юникса приняты сишные APIs. А иначе, конечно, можно было бы перейти на objective C, smalltalk etc

>Может, потому что у велосипеда «плюсы» 101 колесо и при этом все равно проблемы с устойчивостью?

пруф?

А еще потому что в мире юникса приняты сишные APIs

ОК, счастливо оставаться в тех далеких временах. Классы, неймспейсы, манглинг - это ведь все от лукавого?

>Нормальный ОО должен быть в рантайме.

Ой, а я тут мучаюсь с кодогенерацией, чтобы побольше в компайл-тайм сделать...

> пруф?
Гугл поможет. Ключевые слова C++ sucks

ОК, счастливо оставаться в тех далеких временах.

Зачем же Вы используете линух? Он их тех самых времен.

Классы, неймспейсы, манглинг - это ведь все от лукавого?

В плюсах классы недалеко ушли от сишных structs (разве что вот vtable спрятали). Namespaces и в С вроде как вводят потихоньку. А вот манглинг точно от лукавого.

Сочувствую. Кривая реализация ОО еще не к таким мучениям может привести. Динамичнее надо, динамичнее!

DE он в головах

>Динамичнее надо, динамичнее!

Нельзя, embedded, в целевых устройствах маломощные CPU. Однако от ООП толк есть, а Qt дает готовую платформу с б. и ш.^W^W^W рефлекшеном и фреймбуферной графикой

Зачем же Вы используете линух?

ООП в ядре не нужно. К счастью, туда не тащат и GObject'ы

Ключевые слова C++ sucks

Набери GTK sucks, тоже много чего найдется

вообще, чтобы узначть что-то новое о чем-то широко используемом, надо набрать <это что-то> sucks

>А что делает этот гном именно гномом? Наличие gnome-panel? Или gnome-settings-daemon? Если я запущу в нём к примеру плазму, то он от этого превратиться в КДЕ? Где граница между различными средами?

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

DE в дословном переводе - окружение рабочего стола.
По большому счету это WM + рюшечки. DE сражаются друг с другом за обилие рюшечек. WM - за обилие и виды операций по размещению окон.

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

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

>По большому счету это WM + рюшечки.
По большому счёту функции DE и WM не пересекаются вообще. А ещё есть KDE4windows.

> Нельзя, embedded
А, ну это ж совсем другая история... Но и в статике можно использовать C. Тем более libstdc++ не нужен будет.

ООП в ядре не нужно

С добрым утром! Да в ядре полно ООП, просто оно там не так явно, как в gobject.

>Гугл поможет. Ключевые слова C++ sucks

Уважаемый svu, тут прошел слушок, что языковые срачи все происходят от недостатка ума. Как вы это прокомментируете нашему телеканалу?

> Только выглядит плюсовый код гораздо выразительнее «сишного ОО»

Чё? Открой любой исходник на этих ваших кутях - макросов обосраться просто... Я конечно понимаю, что если язык позволяет то почему бы и нет, но про выразительность... кхм кхм...

Кстати ООП в сях именно парадигменное а не лингвистически принудительное.

> По большому счёту функции DE и WM не пересекаются вообще.

Только по очень толст^W большому.

>Только по очень толст^W большому.
От установки компиза gnome/kde/xfce не становятся чем-то другим, не? WM рулит окнами, DE — прежде всего среда для приложений и пользователя, в которую (в том числе) входит и WM. Просто потому, что без WM в иксах неуютно.

> DE — прежде всего среда для приложений и пользователя, в которую (в том числе) входит и WM.

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

согласен

>чтобы они общались друг с другом чуть поближе NETWMH спеки
Тяжёлый случай. В NETWM немного другое. Общение приложений — это dbus, в тяжёлых случаях пайпы, в совсем тяжёлых 9p. В гноме, как я уже упоминал, сделали общение приложений через xmpp (хотя оно теоретически может и с другими протоколами в telepathy работать).
netwm — это разве что для панельки, которая как раз не является неотъемлимой частью DE. Хотя поддержка WM'ом, пейджером и приложениями этого бреда часто желательна.
Окошки — далеко не главная часть приложений.

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

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

man философия LXDE

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

Я к тому, что программа написанная один раз запустится и на убунте, и на арче и вообще на любом более-менее вменяемом дистрибутиве. А чтобы перенести прогу с андроида на webos надо переписать её с java на html+js+css3. Даже с айфоном нет такой херни, там Objective-C совместимый как с Си, так и с С++.

А чтобы перенести прогу с андроида на webos надо переписать её с java на html+js+css3

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

> Общение приложений — это dbus, в тяжёлых случаях пайпы

Причём тут способ общения приложений и необходимость общения приложений. Видимо мы просто друг-друга не поняли. Я имею ввиду что DE и WM очень тесно связаны, поскольку использование DE предполагает сценарий работы, читай тупо способ обработки и _отображения_ информации, при этом зачастую то или иное приложение берёт на себя функции wm (просит фулскрин/ ресайз/ декорирование/ смену z-index). При этом заточенный под это WM мог бы сделать это всё на основе одного только WM класса. Потому мысль о параллельности WM и DE как бэ скоропалительна.

> На мобилах жесткая конкуренция, им просто нет резона делать какой-то единый переносимый формат.

Никому не нужна платформа без программ. Гугл смог позволить себе сделать свою ОСь джаваонли лишь из-за того, что конкурентов андроиду на тот момент не было. Ещё гуглу нужен был свежий рынок приложений, чтобы существующий opensource софт не конкурировал с 4.99$ поделками джавакодеров.

В итоге до сих пор нет нормального Jabber-клиента, а примитивный Angry Birds и глючный порт первокваки тормозят на телефонах более мощных, чем средний компьютер середины девяностых.

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

Неоптимально использовать существующие подходы к созданию интерфейса. Но сишное (а значит «кросс-язычное») апи у системы должно быть обязательно. У Android зачатки этого API появились лишь в версии 2.3, и то, потому что на жаве с вкраплениями C (в стиле ассемблерных вставок) большие игры не напишешь.

Кстати под WebOS гораздо больше программ, чем под андроид, если брать в рассмотрение встроенный в неё эмулятор PalmOS, который запускает как ARMовые, так и m68k бинарники от старых пальмов, т.е. все программы, которые накопились за почти 15 лет существования платформы.

>при этом зачастую то или иное приложение берёт на себя функции wm (просит фулскрин/ ресайз/ декорирование/ смену z-index). При этом заточенный под это WM мог бы сделать это всё на основе одного только WM класса
Ага. Только WM и без DE это запросто сделает.

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

Не только. LXDE — не DE, а в остальных вполне определены более приземлённые вещи.

приложение берёт на себя функции wm (просит фулскрин/ ресайз/ декорирование/ смену z-index).

Приложения НИКОГДА НЕ БЕРУТ НА СЕБЯ ФУНКЦИИ WM. Это будет прямым нарушением ICCCM, которому лет как бы побольше, чем NetWM.
Они могут запросить что-либо, но WM согласно тому же ICCCM может им отказать. Вообще, дело приложения — запросить, дело WM — выполнить либо отклонить. Опять же, это абсолютно одинаково происходит в случаях
— с DE-приложением в родном WM
— с неDE-приложением в родном WM
— с DE-приложением в чужом WM
— с неDE-приложением в чужом WM.
Вообще, WM как правило не особо интегрируется в DE. Просто потому, что ему это не слишком нужно. Максимум — NetWM и интеграция с местным пейджером, дальше уже мелочи вроде «настройки в DE» + механизм обновления этих настроек через IPC DE. Ну и вывод графики через принятый в DE тулкит.

> Приложения НИКОГДА НЕ БЕРУТ НА СЕБЯ ФУНКЦИИ WM.

Тут да, я х-ню ляпнул.

NetWM и интеграция с местным пейджером, дальше уже мелочи вроде «настройки в DE» + механизм обновления этих настроек через IPC DE. Ну и вывод графики через принятый в DE тулкит.

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

> как ARMовые, так и m68k бинарники от старых пальмов,
А теперь расскажите, кому оно нужно. Я не говорю «никому» - всегда найдутся ниши, но попробуйте оценить их размер. Кто будет щаслив использовать старый палмовый софт?

> А теперь расскажите, кому оно нужно.

Если приложение есть, но только в виде пальмового *.prc, а не модного жаваскриптового слепка.

Хотя мне жаваскрипт кажется меньшим злом, чем жава андроида.

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

Тем не менее, была бы в андроиде совместимость с «нормальным линуксом», то не возникло бы проблем с im клиентами, все использовали бы pidgin. На maemo и openmoko он вполне нормально работает.

Видимо, гуглу это не нужно.
Ваш К.О.

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

> Именно так как я сказал. fd.o ориентирован на Юникс, а не на BeOS.

Люто плюсую. Нефиг загаживать юникс этим своим c++.

> DE он в головах

Согласен.

> ОК, счастливо оставаться в тех далеких временах. Классы, неймспейсы, манглинг - это ведь все от лукавого?

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

>Кстати ООП в сях именно парадигменное а не лингвистически принудительное.

В С++ тоже не принудительное

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

C - еще более низкоуровневый язык. И, в отличие от С++, высокоуровневых фреймворков для него нет, кроме GTK

>Нефиг загаживать юникс этим своим c++.

C++ со времен своего появления играет важную роль в разработке под юникс

>Открой любой исходник на этих ваших кутях - макросов обосраться просто...

Если ты про «встроенные кутишные» - это скорее метки для кодогенератора, чем реальные макросы, так как большая часть из них разворачивается в пустое место.

>Может, потому что у велосипеда «плюсы» 101 колесо

лучше пусть будет 101, чем одно. Ничто не мешает придерживаться KISS в коде приложений и одновременно юзать продвинутые фичи внутри библиотек

и при этом все равно проблемы с устойчивостью?

Так и не въехал, где у С++ проблемы с устойчивостью. Ну выпилят ключевое слово «export», которое почти нигде не реализовано, им все равно никто не пользовался :)

Есть проблемы с ABI libstdc++, но это вина гнутых, а не языка. Ждем прямую стабильную libc++ от разработчиков LLVM :)

>DE он в головах

FreeLSD?

> лучше пусть будет 101, чем одно.
Ни разу. Именно потому что KISS относится и к языкам тоже.

C - еще более низкоуровневый язык.

Высокоуровневый язык легко может воспользоваться цешной библиотекой. С крестами это прокатывает с трудом. Поэтому все стандартные либы и интерфейсы должны быть цешными.

Тогда фортран во все поля. Там ни указателей, ни прочих сложностей. А «высокоуровневые языки» реализованы либо на С, либо на С++, либо на JVM и .NET (которые на С++ написаны), поэтому не нужны

>С крестами это прокатывает с трудом.

SWIG

>С крестами это прокатывает с трудом.

А Qtшный код вообще на ура скриптуется чем угодно

Даже для извращенцев-лисперов есть: http://common-lisp.net/project/commonqt/