А вот интересно как? Сделают зоопарк из библиотек etc.

новелл знает как. а зоопарки оставьте пионерам.

Вроде бы все сводится к тому что они напишут свой DE, "использующий лучшие идеи из KDE и Gnome". Я так сильно подозреваю, это будет некий уродец на базе гнома, прохаченный, чтобы подстраивать под себя Qt-приложения. Или, как вариант - пропатченные Qt и KDE, подстраивающиеся под гном =)

>Это хороший повод положить конец противостоянию между KDE и GNOME, решил президент Novell.
Вобще-то KDE и GNOME - независимые организации.
Так что "решать" могут только они, а не дядя там какой-то.

>Вроде бы все сводится к тому что они напишут свой DE, "использующий лучшие идеи из KDE и Gnome". Я так сильно подозреваю, это будет некий уродец на базе гнома, прохаченный, чтобы подстраивать под себя Qt-приложения. Или, как вариант - пропатченные Qt и KDE, подстраивающиеся под гном =)

Да он сам не знает, чего хочет.
Зачем было покупать Suse и Хimian, чтобы заниматься потом такой фигней?
Наверно, тему общую наваяют, на том и закончится...

Общая тема -- это уже было у RedHat. Боюсь, что этот дурак имеет в виду что-то большее. Блин, ну почему у руля компаний зачастую стоят такие твердолобые люди, которые сами не знают чего им надо :-(

На самом деле, единственный реальный способ их подружить называется freedesktop.org - и главным _принципиальным_ (не техническим) препятствием я вижу плюсовую упертость kde. Если новел даст на этот проект денег и переломает хребет плюсистам - может, чего и выйдет. Если нет - дальше общих темочек, как в РХ, дело не зайдет. Впрочем, что именно собирается делать новел - вытащить из этого маркетингового мусора, который они выдали публике, лично я не справляюсь...

Да ладно вам злобствовать-то... Сделают что нибудь -- там посмотрим.

>На самом деле, единственный реальный способ их подружить называется freedesktop.org - и главным _принципиальным_ (не техническим) препятствием я вижу плюсовую упертость kde. Если новел даст на этот проект денег и переломает хребет плюсистам - может, чего и выйдет. Если нет - дальше общих темочек, как в РХ, дело не зайдет. Впрочем, что именно собирается делать новел - вытащить из этого маркетингового мусора, который они выдали публике, лично я не справляюсь...

Не надо нам хребеты ломать)
А есть линк, чтоб почитать про "плюсовую упертость kde"?

P/S Что-то в последнее время вопрос о слиянии Гнома и КДЕ часто возникает... Тенденция...

>Общая тема -- это уже было у RedHat. Боюсь, что этот дурак имеет в виду что-то большее. Блин, ну почему у руля компаний зачастую стоят такие твердолобые люди, которые сами не знают чего им надо :-(

В RedHat просто раньше об этом уже задумывались, и поняли, что в настоящее время ничего, кроме общей темы у Гнома и КДЕ быть не может. Ну libxml еще. Но политика RedHat более последовательна, они не скупают все подряд.
Помнится, они разрабатывали С++ framework для Gtk (Gnome?).
Никто не знает, как там дела в этом направлении?

>Если новел даст на этот проект денег и переломает хребет плюсистам - может, чего и выйдет.

Да вы, я погляжу, террорист прямо какой-то :-) В 21 веке использовать чистый C -- это преступное извращение. Плюс к этому, сравните со всех сторон Gnome и KDE и, положа руку на сердце, скажите: кто из них впереди?

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

Хорошо, лично Вам хребет оставим. А остальным - "хрусть, и пополам" (с) "Мастер и Маргарита"

Например, вот тут http://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00154.html

Owen жалуется на "GFear and GLoathing":) Вообще, там забавная дискуссия получилась...

> P/S Что-то в последнее время вопрос о слиянии Гнома и КДЕ часто возникает... Тенденция...

Это я на тропу войны с плюсами часто выхожу:)

> чистый C -- это преступное извращение

Кажется, уже в 3 тредах перемолотили про С и С++. Больше не буду, подустал.

> положа руку на сердце, скажите: кто из них впереди?

_Для_меня_ гном архитектурно все-таки впереди.:Р А Вы, кстати, по какому критерию хотели сравнивать?

>Хорошо, лично Вам хребет оставим. А остальным - "хрусть, и пополам" (с) "Мастер и Маргарита"

А альтернатива какая? Ни Java, ни С# на роль такого универсального языка не годятся.

>Например, вот тут http://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00154.html
Owen жалуется на "GFear and GLoathing":) Вообще, там забавная дискуссия получилась...

Спасибо, сейчас почитаю...

>Это я на тропу войны с плюсами часто выхожу:)

Есть такая философия... Живи сам и дай жить другому)

>_Для_меня_ гном архитектурно все-таки впереди.:Р А Вы, кстати, по какому критерию хотели сравнивать?

С точки зрения "фичастости" KDE гораздо более полноценен. С точки зрения удобства UI -- на голову впереди. Почему же так выходит? Может быть, пока гномовцы ковыряются в своих сишных спагетти, команда KDE занимается чем-то более полезным? :-)

Что то здаётся мне что реклама всё это. А что в результате? А в результате ещё один десктоп. Как будто их и так мало. Хотя конечно если они хотят захватить корпоративный десктоп то выбран абсолютно правильный путь. Создать свой хороший дестоп не отдавая под ГПЛ естественно, повыкидывать из своего дистра все остальные десктопы, и потом запустить рекламную компанию самого десктопного из всех Линукса. Если к этому Новел предоставит качественную тех поддержку то народ потянется, не сильно но всё же больше чем на очередную версию сусе с лабелом Новел. Естественно я имею в виду серьёзного корпоративного клиента, на которого Новел всю жизнь и ориентировался. Хотя конечно посмотрим что у них получится может дествительно им удастся покончить с войной десктопов и тогда история десктопного Линукса получит новый виток на гораздо более высоком уровне. Я буду этому только рад.

Kid

> А альтернатива какая? Ни Java, ни С# на роль такого универсального языка не годятся.

А не надо универсальных. Нижний уровень - на С. Верхний - на скриптовых. А посередине - смесь:) "Козе - баян, попу - гармонь, икону - папуасу" (с) В.С. Высоцкий

> Есть такая философия... Живи сам и дай жить другому)

Живите, конечно, живите. Просто не претендуйте на те ниши, где С++ не годится. И не считайте, что С++ является идеальным сочетанием высокого уровня ОО и скорости С. Только за эти пункты я и воюю с плюсами.

> С точки зрения "фичастости" KDE гораздо более полноценен

С точки зрения гномовской идеи об идеальном дестктопе КДЕ перегружен фичами - поэтому простой пользователь (как его представляет гном) "тонет". Так что в этом пункте все зависит от точки зрения. Я тоже очень люблю фичи. Но осознаю, что на массовом десктопе они вторичны.

> С точки зрения удобства UI -- на голову впереди

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

> Почему же так выходит? Может быть...

Из двух, весьма спорных, посылок не стОит делать далеко идущие выводы.

>Плюс к этому, сравните со всех сторон Gnome и KDE и, положа руку на сердце, скажите: кто из них впереди?

Често не знаю. Разные это десктопы. С одной стороны КДЕ с его вообщем-то поступательном развитии, первый раз я его увидел в версии 1.0 beta2 по моему точно не помню. И всегда этот десктоп был для меня попыткой привлечь пользователей Вин. Он потехонечку улутьшался добавлялись новые фичи новые технологии но как то всё время спокойно без рывков от версии к версии он узнаваем. И Гном который всегда привлекал своей явно выраженной модульностью, очнь концептуальный и технологичный. Но блин никогда не знаешь что будет в следующей версии, то один ВМ то второй то третий. То Один базовый браузер то другой. Планы по созданию собственного офиса, потом по интеграции ОО в Гном. Потом вдруг Иказе захотелось Mono, я знаю что к Гному это отношения не имеет (пока не имеет). Ну ничего пока до конца не довели из серьёзных проектов. Ни офиса нормального, браузеры тоже раз от раза радуют:) Nautilus который изначально построен на Mozilla, который вообщем-то прекрасный браузер. Ну скажите чемих Галеон не устроил? Тем что на Мозиле сделан? Окошечки не те? Ну форкните геку переделайте окошечки под то что вам нравится и забудте о проблемме броузера. Нет мы притащим за уши епифанию а через годик когда он нас чем-то не устроит заменим на ещё что нибудь. Так что не знаю я что лучше.

Re:

> главным _принципиальным_ (не техническим) препятствием я вижу плюсовую упертость kde. Если новел даст на этот проект денег и переломает хребет плюсистам - может, чего и выйдет.

Наверное, потому что у KDE'шников _уже_ есть работающее решение ;-), а гномеры из релиза в релиз силами своих супер-идеологов всё совершенствуют и совершенствуют внутреннюю кухню. В результате, конечно, нарабатываются супертехнологии, но пользоваться гномом вплоть до 2.5.91, валяющегося у aris'а в Daedalus'е до сих пор нельзя (см. соответствующие письма в сизифовом списке). И фокус панелька зачем-то отбирает, и стабильность приложений не на высоте.

Даже Хавок вон давеча задумался, а куда нам, тьфу, им ехать дальше, то ли в яву, то ли в сишарп/mono. Хорошенький выбор, надо признать :-). С одной стороны, технология, которая за ~10 лет активного пиара так и не прижилась на десктопе, с другой - нечто без нормальной имплементации, и сомнительными легальными перспективами.

В общем, деньги деньгами, а толковое проектирование и кодирование "идеологами" делается крайне редко.

to anonymous (*) (24.03.2004 19:42:37):

>Может быть, пока гномовцы ковыряются в своих сишных спагетти, команда
>KDE занимается чем-то более полезным?

[flame on]
они наследованием глюков занимаются ;) OOP как-никак :)
[flame off]

Ведущему войну с C++

Тут вот есть кое-чего на эту тему: http://dot.kde.org/1049080057/1049095972/1049099431/1049114152/1049117313/

Самое интересное -- разница между кодом под Gtk+ и Qt для сэмпла из Gtk tutorial - http://www.gtk.org/tutorial/sec-creatingacompositewidget.html (сорри, индентация убита):

-- cut here -- #ifndef __TICTACTOE_H__ #define __TICTACTOE_H__

#include <glib.h> #include <glib-object.h> #include <gtk/gtktable.h>

G_BEGIN_DECLS

#define TICTACTOE_TYPE (tictactoe_get_type ()) #define TICTACTOE(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), TICTACTOE_TYPE, Tictactoe)) #define TICTACTOE_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), TICTACTOE_TYPE, TictactoeClass)) #define IS_TICTACTOE(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), TICTACTOE_TYPE)) #define IS_TICTACTOE_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((class), TICTACTOE_TYPE))

typedef struct _Tictactoe Tictactoe; typedef struct _TictactoeClass TictactoeClass;

struct _Tictactoe { GtkTable table;

GtkWidget *buttons[3][3]; };

struct _TictactoeClass { GtkTableClass parent_class;

void (* tictactoe) (Tictactoe *ttt); };

GType tictactoe_get_type (void); GtkWidget* tictactoe_new (void); void tictactoe_clear (Tictactoe *ttt);

G_END_DECLS

#endif /* __TICTACTOE_H__ */

----------------------------------------------------------- #include <gtk/gtksignal.h> #include <gtk/gtktable.h> #include <gtk/gtktogglebutton.h> #include "tictactoe.h"

enum { TICTACTOE_SIGNAL, LAST_SIGNAL };

static void tictactoe_class_init (TictactoeClass *klass); static void tictactoe_init (Tictactoe *ttt); static void tictactoe_toggle (GtkWidget *widget, Tictactoe *ttt);

static guint tictactoe_signals[LAST_SIGNAL] = { 0 };

GType tictactoe_get_type (void) { static GType ttt_type = 0;

if (!ttt_type) { static const GTypeInfo ttt_info = { sizeof (TictactoeClass), NULL, /* base_init */ NULL, /* base_finalize */ (GClassInitFunc) tictactoe_class_init, NULL, /* class_finalize */ NULL, /* class_data */ sizeof (Tictactoe), 0, (GInstanceInitFunc) tictactoe_init, };

ttt_type = g_type_register_static (GTK_TYPE_TABLE, "Tictactoe", &ttt_info, 0); }

return ttt_type; }

static void tictactoe_class_init (TictactoeClass *klass) {

tictactoe_signals[TICTACTOE_SIGNAL] = g_signal_new ("tictactoe", G_TYPE_FROM_CLASS (klass), G_SIGNAL_RUN_FIRST | G_SIGNAL_ACTION, G_STRUCT_OFFSET (TictactoeClass, tictactoe), NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); }

----------------------------------------

Here is the equivalent Qt code:

#ifndef __TICTACTOE_H__ #define __TICTACTOE_H__

#include <qwidget.h> #include <qpushbutton.h>

class TicTacToe : public QWidget { Q_OBJECT

public: TicTacToe( QWidget * parent = 0L ); void clear();

signals: void tictactoe();

protected slots: void toggled(bool);

protected: QPushButton *buttons[3][3]; };

#endif --------------------------------------------------

-- cut here --

Основная идея - при написании GUI на C хренова куча времени уходит на создание конструкций, которые компилятор C++ генерирует автоматически.

Ведущему войну с C++

( sorry for dupe, formatting problems )
Тут вот есть кое-чего на эту тему:
http://dot.kde.org/1049080057/1049095972/1049099431/1049114152/1049117313/

Самое интересное -- разница между кодом под Gtk+ и Qt для сэмпла из Gtk tutorial - http://www.gtk.org/tutorial/sec-creatingacompositewidget.html
(сорри, индентация убита):

-- cut here --
#ifndef __TICTACTOE_H__
#define __TICTACTOE_H__

#include <glib.h>
#include <glib-object.h>
#include <gtk/gtktable.h>


G_BEGIN_DECLS

#define TICTACTOE_TYPE (tictactoe_get_type ())
#define TICTACTOE(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), TICTACTOE_TYPE, Tictactoe))
#define TICTACTOE_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), TICTACTOE_TYPE, TictactoeClass))
#define IS_TICTACTOE(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), TICTACTOE_TYPE))
#define IS_TICTACTOE_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((class), TICTACTOE_TYPE))


typedef struct _Tictactoe Tictactoe;
typedef struct _TictactoeClass TictactoeClass;

struct _Tictactoe
{
GtkTable table;

GtkWidget *buttons[3][3];
};

struct _TictactoeClass
{
GtkTableClass parent_class;

void (* tictactoe) (Tictactoe *ttt);
};

GType tictactoe_get_type (void);
GtkWidget* tictactoe_new (void);
void tictactoe_clear (Tictactoe *ttt);

G_END_DECLS

#endif /* __TICTACTOE_H__ */

-----------------------------------------------------------
#include <gtk/gtksignal.h>
#include <gtk/gtktable.h>
#include <gtk/gtktogglebutton.h>
#include "tictactoe.h"

enum {
TICTACTOE_SIGNAL,
LAST_SIGNAL
};

static void tictactoe_class_init (TictactoeClass *klass);
static void tictactoe_init (Tictactoe *ttt);
static void tictactoe_toggle (GtkWidget *widget, Tictactoe *ttt);

static guint tictactoe_signals[LAST_SIGNAL] = { 0 };

GType
tictactoe_get_type (void)
{
static GType ttt_type = 0;

if (!ttt_type)
{
static const GTypeInfo ttt_info =
{
sizeof (TictactoeClass),
NULL, /* base_init */
NULL, /* base_finalize */
(GClassInitFunc) tictactoe_class_init,
NULL, /* class_finalize */
NULL, /* class_data */
sizeof (Tictactoe),
0,
(GInstanceInitFunc) tictactoe_init,
};

ttt_type = g_type_register_static (GTK_TYPE_TABLE, "Tictactoe", &ttt_info, 0);
}

return ttt_type;
}

static void
tictactoe_class_init (TictactoeClass *klass)
{

tictactoe_signals[TICTACTOE_SIGNAL] = g_signal_new ("tictactoe",
G_TYPE_FROM_CLASS (klass),
G_SIGNAL_RUN_FIRST | G_SIGNAL_ACTION,
G_STRUCT_OFFSET (TictactoeClass, tictactoe),
NULL,
NULL,
g_cclosure_marshal_VOID__VOID,
G_TYPE_NONE, 0);
}

----------------------------------------

Here is the equivalent Qt code:

#ifndef __TICTACTOE_H__
#define __TICTACTOE_H__

#include <qwidget.h>
#include <qpushbutton.h>

class TicTacToe : public QWidget
{
Q_OBJECT

public:
TicTacToe( QWidget * parent = 0L );
void clear();

signals:
void tictactoe();

protected slots:
void toggled(bool);

protected:
QPushButton *buttons[3][3];
};

#endif
--------------------------------------------------

-- cut here --

Основная идея - при написании GUI на C хренова куча времени уходит на создание конструкций, которые компилятор C++ генерирует автоматически.   

хоспади , неужели ? ;)

cheers , kh**s

Novell уже один раз написали GUI, просто "чудо" какое то ... в Netware начиная с 5... на Java, c X-Window, хватит не надо больше .... чур их чур от этой затеи ... а тот мало никому не покажется :)

Ссылочка по теме

Вот тут на эту же тему можно почитать:

http://www.osnews.com/story.php?news_id=3027&page=1 http://www.osnews.com/story.php?news_id=3027&page=2

Ну не так уж все плохо, на самом деле. Хотя я говорил о том, что есть компромиссы подхода писать OOP-программы на C, но есть и преимущества. Но ведь задачку облегчения жизни программиста можно порешать, ведь правда? Вот, например, обрати внимание на такой небольшой препроцессор gob. Посмотри, как выглядит программа на C в этом случае :)

>А не надо универсальных. Нижний уровень - на С. Верхний - на скриптовых. А посередине - смесь:) "Козе - баян, попу - гармонь, икону - папуасу" (с) В.С. Высоцкий

Именно универсальность С++ сделала его таким популярным: тут тебе и десктоп, и СУБД, и _библиотеки_, и ОС, и все чего хочешь.
А скриптовые языки никто не отменяет - используйте на здоровье: PyQt.
Только со всеми вышеперечисленными задачами С++ справится лучше.
А универсальность - это очень важный критерий для многих программистов при выборе языка для того или иного проекта.
Или Вы считаете, что сделать один проект на десятке языках - это будет "правильнее"?
Разве это большое достижение, что запустив гном, пользователь запустит кучу интерпретаторов для кучи скриптовых языков?
Не думаю, что его удовлетворит ответ "зато все правильно".

>Живите, конечно, живите. Просто не претендуйте на те ниши, где С++ не годится. И не считайте, что С++ является идеальным сочетанием высокого уровня ОО и скорости С. Только за эти пункты я и воюю с плюсами.

Высокий уровень ОО достигается библиотеками, а не языком. А скорость в большей степени зависит от используемого алгоритма. Иначе как объяснить, что по словам многих посетителей ЛОРа Gtk2 медленнее отрисовывает интерфейс, чем Qt3. Вот вам и скорость C vs C++.

По поводу ниш.
Для любого сколь более-менее крупного проекта С++ обычно подходит лучше С.
А с течением времени у проектов есть тенденция к росту... Что и оправдывает использование С++.

По поводу C/C++

Очень часто встречается ошибочное мнение, что если ты выбираешь GNOME - то ты выбираешь Си. Это полная чушь!

Вот аниному, который привел сравнение кода C++ и C (в стиле Glib). Никто в GNOME не заставляет писать программы на именно на C. Писать можно, на чем хочешь. Вот, например, я совсем не уверен, что есть большой смысл писать большой проект на C. Но есть нишки, в которых ООP на C кажется уместным (IMHO). Эти нишки небольшие. Но по значимости они могут быть увесистыми. Например, графический тулкит не только с возможностью иммитации наследования, системой signals и пр. OO-штучками, но также и с возможностью широкой адаптации к средствам, которые не имеют ничего общего с ОО. Тут весьма кстати оказался Gtk+.

Библиотека Glib как отдельная сущность появилась случайно, на самом деле. Просто некоторой немалой части программистов понравился подход, лежащий в основе Gtk+, т. е. создание на C объектных программ. Думаю даже, что некоторые начали писать свои программы, просто выдирая оттуда эту основу. Наверное поэтому было решено и вытащить из Gtk+ весь Glib, сделав отдельный framework для объектно-ориентированного программирования с системой сигналов, с большинством особенностей, присущих OO подходу. Кто хочет пользоваться - пишите! И пишут, как не странно. Ну вот есть любители, что поделаешь? И Nautilus так написан, и куча другого софта. По-моему, даже Sodipodi тоже написан на базе Glib (исходники не смотрел, но помню заявление каких-то архаровцев, которые решили форкнуть эту программу, что одна из задач - переписать все на C++). Итог - нечего тут спорить. Нет предмета. Есть выбор средств. Каждый пользуется тем, чем хочет. Вот.

Что касается KDE, то там вся инфраструктура десктопа смотрит в мир плюсовым интерфейсом. И тут ничего не поделаешь - пользоваться им, наверное, смогут только плюсовые программы. И вот еще что. Проблемы KDE/GNOME - это не синоним проблемы языков, но неявно это там присутсвует, когда речь заходит об интерфейсах...

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

>Очень часто встречается ошибочное мнение, что если ты выбираешь GNOME - то ты выбираешь Си. Это полная чушь!
Вот аниному, который привел сравнение кода C++ и C (в стиле Glib). Никто в GNOME не заставляет писать программы на именно на C. Писать можно, на чем хочешь.

Тот же аноним привел ссылку, где объясняется, почему Гном, кроме как на С больше ни на чем не пишется:
- привязки к другим языкам постоянно отстают. И будут отставать, потому что такова их природа.
- С более распространен, чем др. экзотические языки и потому в рамках большого проекта его выбор - как наибольшее кратное.
- все руководства с примерами на С, книги про Gtk на С, и т.д.

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

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

Одно только наследование без механизма виртуальных функций не обеспечит полноценного полиморфизма.
А как реализовано наследование на С в Gtk?

По поводу Glib.
По сути, гномовцы хотят, чтобы кдешники включили ее себе в зависимости.
Но кдешники не лезут же со своими Qt/KDElibs к ним?
Поэтому их недовольство естественно.

Но ведь многие вопросы можно решить независимо от наличия в KDE зависимостей от Glib http://lists.kde.org/?l=kde-core-devel&m=104726909731798&w=2

- registry of cut-and-paste/DND types (just a spec)
- MIME system (just a spec, though could have a small
shared/reference implementation if we wanted)
- shared configuration system (some shared implementation,
but order of 10K lines of code at most, assuming use of D-BUS,
and no shared *library* that apps link to just shared command
line tools)
- ~/Desktop, ~/Documents, etc. directories (a spec, plus some
shell scripts if we do it the way I've proposed)
- sound/multimedia framework (shared implementation)
- component/runtime system (shared implementation, but would be its
own GLib/Qt equivalent so "using" GLib/Qt doesn't make sense and
isn't an issue, and is star trek future stuff anyway)
- VFS (large/complex shared implementation, so as I said Hard)
- accessibility (could just be a spec, though not sure what's
planned right now, it does already plan to work with
Mozilla/OpenOffice/Java)
- help indexing (not something apps link to, could be either
a spec or an implementation)
- UI guidelines (spec)

Так что KDE-разработчики не тормозят интеграцию Гнома/KDE, как это хотят нам здесь представить некоторые гномовцы ;)

>Что касается KDE, то там вся инфраструктура десктопа смотрит в мир плюсовым интерфейсом. И тут ничего не поделаешь - пользоваться им, наверное, смогут только плюсовые программы.

Я же приводил пример, что это не так - см. PyQt.

>И вот еще что. Проблемы KDE/GNOME - это не синоним проблемы языков, но неявно это там присутсвует, когда речь заходит об интерфейсах...

Согласен на все 100.
Поэтому когда начинаем обсуждать вопросы интеграции KDE/Gnome, давайте не зацикливаться на языках. Потому как получается безрезультатный разговор.

>Вобще-то KDE и GNOME - независимые организации. Так что "решать" могут только они, а не дядя там какой-то.

Не знаю, как kde, а вот про gnome это точно неверно утверждается. В gnome вес имеют две компании - RedHat и Ximian, которые и задают всему "хороший" тон. Если Novell договорится с RedHat, то все у него получится.

Чтобы понять, насколько иллюзорно предствление о свободе gnome, найдите почитайте список компаний, в который работают gnome core team, у них даже правило есть - не более 4 человек из одной компании. Найдите хоть одного весомого разработчика gnome, не работающего в такой компании.

> По поводу Glib. > По сути, гномовцы хотят, чтобы кдешники включили ее себе в > зависимости. > Но кдешники не лезут же со своими Qt/KDElibs к ним? > Поэтому их недовольство естественно.

> Но ведь многие вопросы можно решить независимо от наличия в > KDE зависимостей от Glib > http://lists.kde.org/?l=kde-core-devel&m=104726909731798&w=2

Хе-хе, что же ты так их... гномовцев? Обрати внимание, кто написал это сообщение по ссылке, которую ты привел! Никто иной, как Havoc Pennington - один из идеологов GNOME, который посетил с дружественным визитом мейлинглист KDE :)...

>Хе-хе, что же ты так их... гномовцев? Обрати внимание, кто написал это сообщение по ссылке, которую ты привел! Никто иной, как Havoc Pennington - один из идеологов GNOME, который посетил с дружественным визитом мейлинглист KDE :)...

И тут я полностью с ним согласен. Но разве так думают все гномовцы?

Наследование в Gtk+

Как наследование делается в Glib? Не хотелось бы тут сейчас весь код писать, который сопровождает создание класса. Это действительно писанины больше, чем в C++. Я только идею основную.

struc GSomeClass { /* класс-предок */ GSomeParentClass *parent_class;

/* остальное описание */ };

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

Что касается пидарасеров в Си, то да - если уж писать прораммы на базе Glib, то лучше иметь некий препроцессор, но никак ни те, что ты привел. Тут именно препроцессор, ориентированный на систему Glib нужен. Указанный мной gob такой работой и занимается - разворачивает объявления классов из нормального человеческого вида в вид GObject и генерит необходимые хидеры соответсвенно. Ну что поделать - такой вот путь писать программы. :) Да я же говорю - людей не переделаешь. Если бы была на свете "правильная" идея, то все люди ездили на одном единственном автомобиле, слушали одну музыку, предпочитали одинаковую еду... :)

Сорри, parent_class без звездочки, разумеется... GParentClass parent_class надо.

>struc GSomeClass { /* класс-предок */ GSomeParentClass *parent_class;
/* остальное описание */ };

То есть для доступа к переменной из "родительского класса", надо писать:
GSomeClass.parent_class.value = 0;
Так?
А как вызов метода в этом случае будет выглядеть?

>Ну идею понимаешь, да? То есть каждый объект содержит в себе методы и свойства всех своих предков. Тут появляется, правда, одно неудобство для программиста этой системы классов (об этом не будем тут подробно), но задача наследования решена в принципе. И виртуальные функции тоже можно делать.

Создавать ручками таблицу вирт. функций?

По сути, всю эту работу выполняет компилятор С++.
Почему гномовцы предпочитают делать ее самостоятельно?
Чтобы полностью контролировать экспортируемые имена функций?

Да я же говорю - людей не переделаешь. Если бы была на свете "правильная" идея, то все люди ездили на одном единственном автомобиле, слушали одну музыку, предпочитали одинаковую еду... :)

Вот-вот. Значит то, что предложил Havoc Pennington - это утопия?
http://people.redhat.com/~hp/proposal/proposal.html

интересно, это как? gnome + kde == C + C_++ == C# ? я слияние по-другому представить себе пока не могу...

Все. Тема закрыта. Novell выбрала Qt.

Re:

> По сути, всю эту работу выполняет компилятор С++. Почему гномовцы предпочитают делать ее самостоятельно? Чтобы полностью контролировать экспортируемые имена функций?

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

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

Другое дело, что приличный ++-компилятор прослеживает при компиляции типы объектов на несколько уровней вложенности вызовов, что теоретически позволяет грамотнее раскрывать инлайны, проводить оптимизацию и все такое прочее. Если компилятор - голимый C, то вряд ли он будет заменять косвенный вызов "виртуальной" функции на инлайн, даже если внутри функции все понятно, какие объекты и как используются.

Я извиняюсь, что исчез из дискуссии, развязав ее. Был afk в течение дня.

Про то, что кол-во кода сокращается при помощи препроцессоров - уже указали. Вообще, С++ исходно был препроцессором (точнее, многие его ранние реализации просто генерили С код). Так почему же не счесть, что специально заточенный под g-разработку препроцессор gok лучше, чем препроцессор общего назначения c++?:) Да, С, не будучи ОО языком, становится очень многословным в ОО режиме, это очевидно и с этим глупо спорить. Поэтому стремление сократить исходный код при помощи препроцессоров - естественно.

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

Про PyQT. Раскройте, плиз, мне глаза - реализация этого байндинга обходится без extern "C"? Или все-таки пришлось сделать внешний интерфейс с соглашениями C?

Вообще, подходя системно, вопрос о языках - это два вопроса - про реализацию и про интерфейсы. В вопросе об интерфейсах я выступаю за то, что API для широко используемых платформ должны формулироваться в соответствие с соглашениями С. Про реализацию - вопрос для меня вторичный (как старый жаваписец, я давно считаю хороший интерфейс важнее хорошей реализации). Как хотите. так и реализовывайте. Разве что помните про все потенциальные, широкой рукой раскиданные, грабли С++ (о которых я уже говорил неоднократно и про которые кто-то выразился в смысле "страшен С++ код чайника").

Опять же, по поводу интерфейсов. Насколько я знаю, мелкомягкий интерфейс COM все-таки допускает использование через С. Да, получается очень многословно - но возможно.

Про freedesktop.org. Да, многие вопросы можно решить (и решаются) без ругани вокруг glib. Протоколы, форматы файлов - все это может быть стандартизовано и народ над этим работает. Но я не об этом говорил. Хочется иметь reference implementations - а никак. Думается, полезным было бы иметь стандарты на API некоторых библиотек - а никак.

Последний вопрос. Я еще не читал сегодняшние новости. Где новел выбрал Qt? Химиан теперь переводит evolution на Qt?

Спасибо за эту ссылку. Вторая страничка даже убедительнее того треда, на который я ссылался. Я помнил, что где-то читал про эту ругань - но не помнил, где точно. Да, это были osnews.

> Для любого сколь более-менее крупного проекта С++ обычно подходит лучше С. > А с течением времени у проектов есть тенденция к росту... Что и оправдывает использование С++.

А ничего, что ядро и иксы написаны на Сях? То, что мозилла на С++ - это тихий ужас и преступление перед мировой общественностью. Бинарники и плагины при смене версий gcc год утрясти не могли (преступление - это я не про реализацию, это я про интерфейс). Если у проекта, сколь угодно большого, есть публичный API, который будут использовать другие проекты - этот API должен выражаться в на С. Тчк. (Интерфейс на CORBA тоже подпадает под эту статью:)

> По сути, всю эту работу выполняет компилятор С++. > Почему гномовцы предпочитают делать ее самостоятельно? > Чтобы полностью контролировать экспортируемые имена функций?

Не только имена. Вы, например, знаете, как именно в памяти устроена таблица виртуальных функций и виртуальных базовых классов Вашего объекта? С точностью до байта? И она не зависит от версии и брэнда компилятора? От опций оптимизатора? Это только вопросы - вполне возможно, что на все Вы ответите "да".:)

Тут же никто не спорит с Вами - да, на С ОО код длиннее. Зато интерфейсы стабильнее и предсказуемей.

> А как вызов метода в этом случае будет выглядеть?

Просто и элегантно, как все на С:

(*gSomeClassInstance.parentClassInstance.virtMethod)(...);

:) А вообще, в gobject есть приличная система динамических вызовов по имени, так что можно методы даже по имени вызывать, через g_signal_ API.

Статья Pennington & Taylor

>Вот-вот. Значит то, что предложил Havoc Pennington - это утопия? http://people.redhat.com/~hp/proposal/proposal.html

Нет, не утопия. Каждый по-прежнему будет пользоваться тем, чем пожелает. Там речь идет о выборе слоя для взаимодействия. В данном proposal Havoc&Owen ставят проблему и приводят ее анализ, нежели дают конкретное предложение по реализации. Но чувствую я, что каждая строчка там принизана темой "это должен быть Glib" :) Все выведенные в конце свойства решения об этом говорят :)

Виртуальные функции в Glib

>То есть для доступа к переменной из "родительского класса", надо писать: GSomeClass.parent_class.value = 0; Так?

Нет, ну зачем же так? Делается это через cast. У тебя есть указатель на объект - ты его можешь привести к любому предку и вызвать свойство. То есть цепочку никакую делать не надо. Класс предка в описании структуры всегда должен идти первым (как я показал), поэтому указатель на любой объект будет одновременно указателем на всех его предков. А неудобство, о котором я говорил, - это не вызов цепочкой, а совсем другое. Неудобство в том, что программит должен помнить, от кого данное свойство унаследовано, чтобы сделать cast к нужному классу. То есть ни как в C++, где ты можешь изменить унаследованное свойство, не вспоминая откуда оно взялось... Но в принципе и эту задачу можно решить. Я даже знаю как, но это в Glib не реализовано (пока или не пока - не знаю).