Релиз Qt 4.5 и Qt Creator 1.0

> Ну напишите же наконец хоть одно реальное толковое полезное приложение на вашем любимом лиспе/хаскеле/схеме/etc, чтобы люди смогли это оценить.

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

> Дозор-Джет, написанный на схеме

Что, он прям-таки весь на Схеме? Или Схема там в роли скриптового языка или чего-то подобного?

> предположим, что написали GIMP на Qt... и что изменилось бы?

GTK+ (Gimp ToolKit) никогда бы не появился, и не надо было бы флеймить в этой теме :)

> Что, он прям-таки весь на Схеме? Или Схема там в роли скриптового языка или чего-то подобного?

весь на схеме, за исключением некоторых биндингов на С

Крейтер рулит, удобная штука

в openSUSE в репах KDE:/Qt45 выложили пакеты qt45 и qtcreator 1.0, жду публикации kde4.2.1 и буду обновляться, надеюсь кде4.2 заработает с qt45 без бубна

Эх семён семён... Воплощение интерфейса с 12 методами на "няшном" С

#ifndef MY_MODEL_H_
#define MY_MODEL_H_

#include <glib.h>
#include <glib-object.h>

G_BEGIN_DECLS

#define MY_MODEL_TYPE (my_model_get_type())
#define MY_MODEL(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj),MY_MODEL_TYPE, MyModel))
#define MY_MODEL_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass),MY_MODEL_TYPE,MyModelClass))
#define IS_MY_MODEL(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj),MY_MODEL_TYPE))
#define IS_MY_MODEL_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass),MY_MODEL_TYPE))
#define MY_MODEL_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS((obj),MY_MODEL_TYPE,MyModelClass))

typedef struct _MyModel MyModel;
typedef struct _MyModelClass MyModelClass;

struct _MyModel
{

GObject parent;

};

struct _MyModelClass
{

GObjectClass parent_class;

};

GType my_model_get_type(void) G_GNUC_CONST;
MyModel* my_model_new(gint);

G_END_DECLS

#endif

#include <gtk/gtk.h>
#include "mymodel.h"

#define MY_MODEL_GET_PRIVATE(obj) (G_TYPE_INSTANCE_GET_PRIVATE ((obj),MY_MODEL_TYPE,MyModelPrivate))

typedef struct _MyModelPrivate MyModelPrivate;

struct _MyModelPrivate
{

gint n_rows;

};

static gboolean my_model_iter_parent(GtkTreeModel *model,GtkTreeIter *iter,GtkTreeIter *child);
static gboolean my_model_iter_nth_child(GtkTreeModel *model,GtkTreeIter *iter,GtkTreeIter *parent,gint n);
static gint my_model_iter_n_children(GtkTreeModel *model,GtkTreeIter *iter);
static gboolean my_model_iter_has_child(GtkTreeModel *model,GtkTreeIter *iter);
static gboolean my_model_iter_children(GtkTreeModel *model,GtkTreeIter *iter,GtkTreeIter *parent);
static gboolean my_model_iter_next(GtkTreeModel *model,GtkTreeIter *iter);
static void my_model_get_value(GtkTreeModel *model,GtkTreeIter *iter,gint column,GValue *value);
static GtkTreePath* my_model_get_path(GtkTreeModel *model,GtkTreeIter *iter);
static gboolean my_model_get_iter(GtkTreeModel *model,GtkTreeIter *iter,GtkTreePath *path);
static GType my_model_get_column_type(GtkTreeModel *model,gint index);
static gint my_model_get_n_columns(GtkTreeModel *model);
static GtkTreeModelFlags my_model_get_flags(GtkTreeModel *tree_model);
static void my_model_tree_model_init(GtkTreeModelIface *iface);
static void my_model_finalize(GObject *object);
static void my_model_init(MyModel *iface);
static void my_model_class_init(MyModelClass *klass);

GType my_model_get_type (void)
{

static GType my_model_type = 0;

if(!my_model_type)
{
	static const GTypeInfo my_model_info =
	{
			sizeof(MyModelClass),
			NULL,
			NULL,
			(GClassInitFunc)my_model_class_init,
			NULL,
			NULL,
			sizeof(MyModel),
			0,
			(GInstanceInitFunc) my_model_init,
	};
	static const GInterfaceInfo tree_model_info =
	{
			(GInterfaceInitFunc)my_model_tree_model_init,
			NULL,
			NULL
	};

	my_model_type = g_type_register_static(G_TYPE_OBJECT,"MyModel",&my_model_info,0);
	g_type_add_interface_static(my_model_type,GTK_TYPE_TREE_MODEL,&tree_model_info
);
}

return my_model_type;

}

static void my_model_class_init(MyModelClass *klass)
{

GObjectClass *g_object_klass = G_OBJECT_CLASS(klass);

g_type_class_add_private(klass,sizeof(MyModelPrivate));
g_object_klass->finalize=my_model_finalize;

}

static void my_model_init(MyModel *model)
{

MyModelPrivate *model_private = MY_MODEL_GET_PRIVATE(model);

}

static void my_model_finalize(GObject *object)
{

MyModel *model = MY_MODEL(object);

}

static void my_model_tree_model_init(GtkTreeModelIface *iface)
{

iface->get_flags = my_model_get_flags;
iface->get_column_type= my_model_get_column_type;
iface->get_n_columns= my_model_get_n_columns;
iface->get_iter = my_model_get_iter;
iface->get_path = my_model_get_path;
iface->get_value = my_model_get_value;
iface->iter_next = my_model_iter_next;
iface->iter_children = my_model_iter_children;
iface->iter_has_child = my_model_iter_has_child;
iface->iter_n_children = my_model_iter_n_children;
iface->iter_nth_child = my_model_iter_nth_child;
iface->iter_parent = my_model_iter_parent;

}

via:lolks.ru 

Это анальное рабство а не "няшность".

Ппц. Поглядел и понял, что в жизни под этим угребищем писать не буду.

> Это анальное рабство а не "няшность"

krasnoglazeg +1 Именно поэтому у меня никогда не возникало позывов писать что-то на GTK. И в то же время wxWidgets который поверх GTK2 в сто раз удобнее и проще, ибо на C++, так к тому же не только GUI но и другое и кроссплатформенный! А теперь еще и Qt под LGPL. При всем уважении, но на чистом GTK писать неудобно, лучше использовать надстройки над ним.

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

Если vala допилят, то будет кошерно.

Что, оно способно скрыть весь этот неадекват?

> Что, оно способно скрыть весь этот неадекват?

Совершенно верно.

> неадекват

Кстати, вполне вменяемый и адекватный код, только излишне многословный (местами). А для создания классов и интерфейсов GObject можно ещё юзать кодогенератор какой-нить.

Может бы привыкли и не видите это, но я в первый раз увидел код GTK+.

1. Убивать готов за макросы.
2. Код совершенно не понятен.
3. Просто многа букав, делающих какие-то обьявления, а полезного кода мало.

>> неадекват

> Кстати, вполне вменяемый и адекватный код, только излишне многословный (местами).

Бугага. (G_TYPE_CHECK_INSTANCE_CAST ((obj),MY_MODEL_TYPE, MyModel)) - это адекватный код? Проверки компилятором нет, на этапе выполнения - просто сообщение с возможным сегфолтом. Адекватный код, да...

Большое Вам спасибо за ссылку! Скачалось со скоростью 214-220КБ/сек.

много букф ?
ни ассилил ?

> Бугага

Расскажи, как должно быть в этом месте и на этой задаче?

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

очень здравая мысль

это ж абсолютно нечитаемое УГ. в с++ код гораздо красивее и лучше читается

> Может бы привыкли и не видите это, но я в первый раз увидел код GTK+. > > 1. Убивать готов за макросы. > 2. Код совершенно не понятен. > 3. Просто многа букав, делающих какие-то обьявления, а полезного кода мало.

Это C, великий и могучий. Чтобы добиться такого же результата в C++, понадобились метры спецификаций. А тут всё что нужно меньше чем в 100 строках кода и наборе библиотек. О, великолепный C++, помню он мне очень нравился на 1м курсе когда свою обертку для WINAPI в тысячу строк еле уложил чтоб сетевые крестики-нолики с динамическим размером поля написать... вообщем когда я узнал что есть такая штука как Gentoo, у меня язык не повернулся назвать тех кто под ней сидит красноглазиками.

svu, сколько в теме бисера насыпали перед быдлами, а результат нулевой... менять надо стратегию, или это всё тупо поржать?

А для удобной разработки PyGTK/PyQT самое то... В этот раз улучшилась Qt, ну дак поздравим ее сторонников и разработчиков! Ждем в арче!

http://www.googlefight.com/index.php?lang=en_GB&word1=qt&word2=gtk

Тред сдох?

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

> а вообще гтк наиболее практичная библиотека под линукс

Тут я улыбнулся.

> конечно всем им до того же WinForms писять и писять.

А тут я чуть не подавился. Тузек, уйди с моего лора.

> Хотите на спор за большое бабло напишу программу на С или С++, которой не хватит гига?;)

А что ее писать? Обычный sort сработает, если ему передать большое число в параметре -S и скормить большой файл.

> Чем подход С+скриптинг принципиально хуже (ну, если не говорить о традициях - чисто технически)?

Он не хуже. Но и скриптовать тоже надо учиться, так как shell-специфических подлянок (хотя бы непроверки ошибок wait'ом) тоже хватает.

> Оно и так есть. Почитай документацию к GIMP'у. Только работает не как
> куча отдельных утилиток, а одной программой (фактически это gimp
> cli).

Я читал. Я не это имел в виду. imagemagick можно легко использовать в том же вебе как набор утилит. gimp cli это по факту запуск скриптов внутри огромного скрипт-сервера, что для того же веба представляет серию проблем.

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

> Сообщения отправлять аналогом dbus.

> Эээээ О_О...

Бросьте. Сообщения вида "запустить инструмент X/сервис X с такими-то параметрами" бывают так редко что потери на dbus-like интерфейс минимальны. Сообщения вида мышь подвинулась на 5пикселей вообще не передавать таким образом. Интерактивные инструменты состоят из
а) плагина интерфеса к инструменты : .so обрабатывающего X ссобщения в внутри ГУИ, как виджеты gtk. Как вариант это и будет gtk видгет.
б) сервиса/утилиты как у неинтерактивных инструментов. Коннект через фифо/сокет/сетевой сокет.
в) некоего упрощенного способа, типа описателя модуля, позволяющего единообразно встраивать такой плагин в общую систему.

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

>> Бугага

> Расскажи, как должно быть в этом месте и на этой задаче?

...и при использовании Gtk? Ровно то же, что есть. Ничего лучше сделать нельзя, как раз в этом и проблема. Динамическая типизация и наследование "вручную", без поддержки компилятора только так коряво и получаются. При несовпадении типов нормальном динамическом языке интерпретатор бросил бы исключение, в нормальном статическом - компилятор бы ругнулся. Здесь - в stderr выведется сообщение, и прога глюкнет или рухнет. Теперь ты скажи - это так и должно быть?

> Теперь ты скажи - это так и должно быть?

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

> Да вполне нормально, елси руки не кривые

...и копипаст освоен.

P.S. Проблема как раз в том, что руки кривые. У всех, исключений нет.

Говорю же, есть надежда на vala.

> хорошо.... std::wstring? :)

Слишком костыльная вещь. И на некоторых платформах там внутри ucs-2 в который не все символы влазят. А в QString полноценный utf-16.

> И на некоторых платформах там внутри ucs-2 в который не все символы влазят.

Разве это не только в венде так? Там внутри winapi только он (ucs-2) и используется. AFAIK всё что не лезет в два байта стандартными функциями уже не обработать. Для этого в офисе, ie и прочем микрософтовском софте дополнительные костыли реализованы.

Поэтому если нужен нормальный юникод и кроссплатформенность, то wstring лучше не использовать.

> Поэтому если нужен нормальный юникод и кроссплатформенность, то wstring лучше не использовать.

А что плохого в том чтобы внутри программы использовать std::wstring/wchar_t, а в файлах хранить и передавать по сети в utf8? Тем более что алгоритм конвертирования юникодный кодировок очень прост.

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

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

Логично. Но с другой стороны, если символы не лезут в wchar_t, то с ними и сделать ничего нельзя (на экран не вывести стандартными средствами), так что логично их просто игнорировать. И тут кто-то выше постил ссылку что в c++0x есть (будет =)) wchar32_t.

> есть надежда на vala.

Надежда вообще умирает последней :) А пока что разумные люди используют PyGtk.

> Надежда вообще умирает последней :) А пока что разумные люди используют PyGtk.

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

>Нарисовать гуйню - это не основная проблема в большинстве программ, и сишный вариант вполне катит.

Смотрю на интерфейс гимпа и не соглашаюсь. В OSS далеко не все могут слепить _нормальный_ интерфейс. GIMP тому пример.
Так что это проблема.

>> Надежда вообще умирает последней :) А пока что разумные люди используют PyGtk.

> Нарисовать гуйню - это не основная проблема в большинстве программ

Интересно, много программ используют Gtk из Си? Я вот кроме GIMP ничего не могу вспомнить. А так да, есть проблемы и поважне... и конечно, если проблема не основная, настоящие мужчины не станут упрощать ее решение (это ирония).

> Интересно, много программ используют Gtk из Си?

Фигасе, сэр. Да почти весь гном (это десятки программ), transmission, pidgin, evolution, linuxdcpp, gimp - и это только из того, что пришло в голову. Очнись, подавляющее кол-во софта с мордой на гтк написано на си!

> А так да, есть проблемы и поважне... и конечно, если проблема не основная, настоящие мужчины не станут упрощать ее решение (это ирония).

Я после работы нихрена разобрать, что тут написано, не смог.

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

Если не считать времени работы ноутбуков без подзарядки. Только вот значение ноутбуков и мобильных устройств с малыми ресурсами растет.

>>Хорошо, давайте с этой точки зрения: предположим, что написали GIMP на Qt... и что изменилось бы?

>То, что на написание GUI было бы потрачено меньше времени и его можно было потратить на пресловутый CMYK.

Ну, у меня 2 вопроса:

1) Почему Вы считаете, что ушло бы меньше времени?

2) Неужели Вы думаете, что в процентном отношении на GUI было затрачено много ресурсов?

>>Это в среднем, а программисты (если конечно не клинические индусы), порой очень творческие личности со всеми вытекающими... :)

>Оно-то так, но в случае GUI никакого особого творчества нет и быть не может.

Ну, это ещё как сказать... такое иногда завернут... посмотрите вон на креативщиков от майкрософт :)

>>и обратное тоже справедливо, и что?

>дверь как бы не виновата, что некоторые суют в ее разъем свои гениталии

ещё раз я Вам задам вопрос, который Вы упорно игнорируете: И ЧТО? ;)

>> Хорошо, давайте с этой точки зрения: предположим, что написали GIMP на Qt... и что изменилось бы?

>GTK не появился бы. Все писали бы на QT.

А вот и хрен... тогда появлится бы QtK+, и стал бы большой сишной библиотекой, а ещё появился бы Gt, на котором написали КДЕ... и больше ничего не изменилось бы - ни по срокам, ни по продуктам выпущенным на основе... более того, даже срачи и холивары были бы тоже точно такие же, за исключением пары-тройки ничего не значащих букв :)

>Богатые библетоеки - это просто необходимая вещь при разработки софта,

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

>для РАД - нужно, помимо этого, ещё и маленький цикл "изменил код-запустил" и выразительность и локаничность языка. И оба не про с++.

Да ну... давайте поподробнее... что именно, по Вашему мнению, в С++ мешает реализовать вещи о которых Вы упомянули? Может Ваша некомпетентность?

>а ну... давайте поподробнее... что именно, по Вашему мнению, в С++ мешает реализовать вещи о которых Вы упомянули? Может Ваша некомпетентность?

А может ваша? Когда я пишу на питоне время "изменил-запустил" = 0 секунд. Для с++, если пользуетесь кучей бибилотек, буст, КуТэ и прочее - то это уже не "пара секунд". Так что некомпетентность тут ваша.

И краткость - это не к с++. На питоне кода зметно короче и читабельнее.

>спачибо, капитан очевидность.... возьми с полки пирАжок...

Естетвенно очевидно. ПРосто ктото сказал что это основное что нужно РАД. так что меньше умничай ;)