Да видим, обаче, дали и на практика ще се получи нещо добро...

[Отговори на този коментар]

Смятах да пускам новина за това, но Н. Ангелов успя да ме изправи, затова просто ще го допълня:
Има прототипи използващи и двата комплекта от графични обекти - GTK+ и QT, които работят в рамките на един процес, с един основен цикъл на работа (за неразбралите - main loop).
1. Сайтът на начинанието http://gparts.blogspot.com/ - това е имплементация на KParts за Gnome с подробно обяснение на различните термини. Така ще можете да си вградите компонент на bonobo в KDE или растеризиращия модул на Konqueror в Nautilus.
2. Прототип на общия цикъл: http://lists.freedesktop.org/archives/x...
3. Писмото на Дмитри Шатров, който обявява проекта: http://lists.freedesktop.org/archives/p...
4. Обяснение на K/G/XParts, Bonobo и комуникацията между и рамките на процес: http://www.scheinwelt.at/~dmitrys/
5. СНИМКИИИИИ и пачове: http://www.scheinwelt.at/~norbertf/comm...
6. Откъде откраднах линкчетата: http://pvanhoof.be/blog/index.php/2005/...

7. И най-накрая - не бързайте още толкова много. Това са супер ранни прототипи, на нивото "глей кво моа на Си". Тенденцията не е лоша и може кокошчицата да снесе златните яйчица. Но няма да е утре ;-)

Редактиран на: 8-12-2005@13:08

[Отговори на този коментар]

Още по-дебели дистрибуции ни очакват. Ха аман от кой е по-по-най.

[Отговори на този коментар]

Към: Още по-дебели
От: Overclocker
На: 9-12-2005@6:58 GMT+2
Оценка: 1/Неутрален

Wnmen казваш "Ха аман от кой е по-по-най."
ам това му викат конкуренция и е нещо добро мисля аз то и това е целта , да изплуват по-по-най нещата най отгоре ;-)

[Отговори на този коментар]

---

Сега ако се напънат здраво да пребазират GNOME върху GParts -> GTK+ и да ползват bonobo само за компоненти на външни процеси, може и да видим по-лек и бърз Гном с приличен файлов мениджър, базиран на системните компоненти, а също и някакъв свестен Kate-подобен текстов редактор. $subject.

[Отговори на този коментар]

Ще ми е по-интересно да видя съгласие за възприемането на managed code api базирано на mono или на java. Просто имам чувството, че религиозните войни водят до чувствително изоставане в тази насока.

[Отговори на този коментар]

Към: бягане около проблема
От: Георги Чорбаджийски <georgi< at >unixsol __точка__ org>
На: 9-12-2005@10:46 GMT+2
Оценка: 1/Неутрален

"възприемането на managed code api базирано на
mono или на java"

Айде нема нужда :) KDE е над 6 милиона и половина реда C++ код, как го виждаш това да се препише на buzzworldoftheday language?

[Отговори на този коментар]

---

Към: Към: бягане около проблема
От: growchie <growchie (a) yahoo[ точка ]com>
На: 9-12-2005@12:22 GMT+2
Оценка: 1/Неутрален

Май нещо не си в час или не си разбрал какво искам да кажа. Никой не е такъв лунатик, че да иска пренаписване на KDE на моно (те в момента го пренаписват за qt4 така че сам се опровергаваш с тези 6 милиона). Просто да се пише на managed code си има и своите предимства - на първо място сигурност. Не е зле да помислят и за по-сериозно интегриране на такива технологии със съответните байдинги за QT и GTK в средите. Така ще си решат купища проблеми точно около деплойването на проектите и ще улеснят девелоперите да си драскат на езика на който си искат, било то питон или друга екзотика. Не виждам причина gaim или kopete или нещо друго да бъде пренаписано по този начин. Линукс има нужда от managed code.

[Отговори на този коментар]

---

Към: Към: Към: бягане около проблема
От: v_badev <v_badev (a) mail[ точка ]bg>
На: 9-12-2005@14:51 GMT+2
Оценка: 1/Неутрален

Всичко което си написал в момента го има, който иска може да си пише програмите на Java, Python Mono, Ruby и т.н. Даже има доста популярни такива програми.

[Отговори на този коментар]

---

Към: Към: Към: Към: бягане около проблема
От: abstractone
На: 9-12-2005@15:35 GMT+2
Оценка: 1/Неутрален

Това, за което говориш са bindings за отделните  toolkits.Става въпрос за друго. Например, представи си интеграция на beagle в konqueror, интеграция на management конзолата на Fedora Directory Server (java Swing) в Nautilus. Eдинични изпълнения биха били възможни, но поддръжката ще е трудна, а разработчиците ще трябва да изживяват поредния ад.

[Отговори на този коментар]

---

Към: Към: Към: бягане около проблема
От: Pesho® <ppetrov< at >ppetrov__dot__com>
На: 9-12-2005@15:48 GMT+2
Оценка: 1/Неутрален

Хм, не бих нарекъл преминаването от Qt3 към Qt4 "пренаписване".

[Отговори на този коментар]

---

Към: Към: Към: Към: бягане около проблема
От: abstractone
На: 9-12-2005@16:03 GMT+2
Оценка: 1/Неутрален

Преминаването към qt4 e pain in the ass. Не знам дали си пробвал да го правиш. Ако не, то се поразрови малко из мейлинг листовете на kde и ще разбереш.. повечето програмисти са навити да пренапишат приложенията си, вместо да се цапат със заобиколен код. Един кратък цитат обобщаващ казанато:

"1. KDE is going to make some really large changes in their API which
means, that large parts of kdelibs for example get rewritten

2. KDE4 is _at least_ one year from a usable state..."

http://lists.trolltech.com/qt-interest/...

[Отговори на този коментар]