KDE desktop environment постепенно завоевывает свое место на OS X и Windows. Помимо портирования core KDE библиотек, активно ведутся работы по портированию популярных KDE-based программ, типа Amarok и KOffice.
Бинарные сборки KDE для Windows доступны со вчерашнего дня.
amarok рулит конечно, но вот зачем в венде итд?! убей не въеду она чё глючить у кого перестала из-за кедов?! дык это не в том дело тут с травой завязывать нада
Sun-ch>> Qt - мощный мультлатформенный фреймворк под 3 основные платформы X11, OS X и венду.
Bioreactor * (*) (24.01.2008 12:36:24)> Для OS X - этот "мощный фреймворк" - как рыбе зонтик. У нас Cocoa есть.
vadiml **** (*) (24.01.2008 12:51:04)>это Cocoa ни где кроме os x нет, а я, когда пишу программы, хочу чтоб они работали под всеми системами
anonymous (*) (24.01.2008 12:44:15)> Cocoa - мультиплатформенна? И это, расскажи чтоли про пару программ которые ты наваял на "вашем" мегафреймворке
Есть, есть кроссплатформный Cocoa, успокойтесь.
История вопроса: Был NeXTSTEP со своим ObjC API; Потом вместе с Sun NeXT стандатризировал API и получился OpenSTEP (открытая спецификация); потом когда делалась эта Рапсодия и MacOSX в итоге API OpenSTEP перешло в MacOSX, дополнившись своими особенностями, получилась Какава.
Итого:
0. Есть открытые спецификации на OpenSTEP-подмножество. Спеки внятные, по этим спекам был запущены опен-сорс проекты, кроссплатформные (X, MacOSX, Windows):
1. проект GNUStep -- GNU реализация API OpenSTEP (под который есть нормальная среда разработки, Gorm (аналог Interface Builder)), DE Etoile (обещает быть интересным, но не допилено; порт под Windows имеет проблемы с GUI))
2. mgSTEP, micro gnustep. Форк одного из разработчиков GNUSTEP для emdebbed (есть версия без иксов для Zaurus).
3. Cocotron, http://www.cocotron.org . Самый актуальный проект, целью его заявляют "догнать Cocoa API". Кросс-платформная библиотека, приложения разрабатываются в MacOSX Xcode, потом Mingw-ом кросскомпилируются под Linux и Windows. Не требует отдельной установки как GNUSTEP, есть OpenGL, где-то более полная реализация API Cocoa.
То есть, писать "кроссплатформные Cocoa-приложения" на подмножестве Cocoa API вполне себе можно.
> чтобы заменить стандартный shell explorer.exe или dwm.exe на конка из KDE4. Может тогда оно тормозить перестанет Ж-))
ананимус ты гониш херню. ничего оно не заменит и работать быстрее не станет, ибо ехеплорер пользует виндовые апи, а конк пользует апи qt, которые пользуют виндовые апи.
хорошо, если под виндой весь этот монстр будет медленее всего процентов на 15, чем под линуксом.
>Мне ничего не остается сделать, кроме как посоветовать вам почитать >учебники про компиляторы, языки программирования и методы трансляции.
Рекомендую сделать то же самое в области системного программирования. Очевидно, для вас интерфейсы GNU LibC и Win32 API - суть одно. На самом деле (!) я вынужден вас огорчить тем, что любое (!!) кроссплатформенное ПО имеет платформозависимые модули, иначе бы оно просто не работало. Java-приложения обращаются к Java Runtime, python - к интерпретатору языка Python, и всё это скомпилировано под совершенно определённую программную и аппаратную архитектуру. Но если бы код той же QT взаимодействовал с операционной системой напрямую, без посредства собственных интерфейсных модулей-переходников ничуть не лучше WINE'а (а может, и тормознее), работал бы он _В_РАЗЫ_ быстрее. Я уж не говорю о том, что приложения на assembler, вовсе не использующие пресловутую GLibC, способны за то время, пока у вас грузится KDE, рассчитатьполёт на Луну как минимум.
P.S. Я предпочитаю работать под IceWM, наличие которого в системе вообще неощутимо. а функциональность его для оконногго менеджера более, чем достаточная.
Вообще "эта прослойка" - не так уж велика - вызов нескольких прокси функций и это время фигня по сравнению вызова функций рисования, омен данными с х сервером и т.д. А так вот говорить "это всё тормозит а на асме всё кртуто" может каждый. Пока не привидёте конкретные статистики из профайлера что тормозит _именна это прокси-прослойка_ можем только ответить - 4.2
> Мне кажется, что все больше людей будут писать под QT, это будет типа "дельфи 21 века". Там ведь не только графика, но и работа с сетью, принтерами и т.д.
Кстати да... Эт заставит кучу народа клепать кутэшные проги на три платформы и обеспечит большим количеством быдло (и небыдло) софта все три оси. И если под вантух прог хватает, то приток такого софта в линух не может не сказаться положительно.
anonymous> ананимус ты гониш херню. ничего оно не заменит и работать быстрее не станет, ибо ехеплорер пользует виндовые апи, а конк пользует апи qt, которые пользуют виндовые апи.
В некрософте работают пи*оры. Так что насчёт скорости - вопрос тот ещё.
Вот как раз хочу заставить работодателя купить QT4. Сам сейчас работаю в C++ Builder(недо компилятор). Кто нибудь совершал данный переход? Поделитесь впечатлениями.
>Активное портирование QT на другие платформы грозит тем, что и без того тяжёлая библиотека будет бесконечно обрастать ещё более неподъёмным кросс-платформенным кодом.
а как наличие кросс-платформенного кода влияет на быстродействие приложения, вы хотите сказать что в готовых .so есть функционал для венды?
> Вот как раз хочу заставить работодателя купить QT4. Сам сейчас работаю в C++ Builder(недо компилятор). Кто нибудь совершал данный переход? Поделитесь впечатлениями.
о_О А сменить Windows на Open Office не желаете? :)