Gtk+ 3 Roadmap

>>ini-файлы читаются/правятся вручную гораздо лучше xml

Мне нет.

OMG

Быть чипованым лучше.

Obvious fix :D

> На том же, почему я считаю героин бякой (ни разу не попробовав).

Qt не наркотик, попробовать с целью составления своего мнения (пусть даже негативного) вполне было бы можно :-D

> извините на глупый вопрос, но где это у вас хорг от глиб зависит? :)

$ uname -sr
FreeBSD 7.0-RELEASE-p5

$ pkg_info -r xorg-server-1.6.1,1 | grep glib
Dependency: glib-2.20.5
Dependency: dbus-glib-0.82

> все в gconf хорошо, только он однопоточный и libxml2, который так любит гном — до безобразия тормозной.

1. libxml2 на самом деле весьма шустрая штука. Возможно просто Вы её хмм... неоптимально применяете?

2. IIRC, gconf не использует libxml2, а опирается на парсер XML-подобной разметки из Glib (GMarkupParser)

> Почему впервые? Насколько мне известно этот факт особо не скрывают. Да и оно лучше чем KDE'шное: «Хочу быть виндой но как-то хреново получается».

если не изменяет мне мой склероз:

- 2005 или 2006 год, первые видео появились с виджето ориентированными фичами на экране от kde, при этом m$ точил и пиарил свой longhorn даже не думая (по крайней мере публично) про aerо интерфейс

-2006 или 2007 - на маемо5 активно пошли строится виджеты на экране

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

Мы с вами вдвоем спорим о том что удобнее мне? Как то странно...

> Независимость от разрешения, легкое масштабирование элементов графического интерфейса, включая шрифты и изображения

Даа, что бы за этоим не стояло, даа! Хуже чем сейчас не станет, хуже некуда!

P. S. GTK - фанбой, самописная компактная тема.

> Хуже чем сейчас не станет, хуже некуда!

Кто вам такое сказал ?)) Это линукс же ...

Хе хе))
Вы серьёзно считаете, что популярность OS зависит от числа доступных свистоперделок и возможности личной кастомизации интерфейсов «рашпилем и напильником» ?

Забейте на него. Непонятный малоинтелектуальный коммент с кучей сленга, который не очень понятен.

ну, это «скорое время» длится уже с год :) А работа даже не начата afaik

Ну это в федоре так

Судля по офф. сайту KDE, в апстриме также. И чисто по человечески я понимаю нежелание мейнтейнеров Fedora дробить апстримные пакеты и отслеживать зависимости между тем, что в результате получится.

Справедливости ради, мне самому не нравится в Fedora присутствие /usr/share/gdm/autostart/LoginWindow/metacity.desktop в пакете gdm

> Вы гоняете гигабайты через gconf? Вот это уже не здорово... Хотя если гоняете то у вас есть пруфы что gconf вызывает дискомфорт и является bottleneck?

Погугли, там пруфов немерянно. Все уже давно это признали.

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

Вы хоть видео смотрели? В чем собственно проблема? В gstack мало что есть неотделимым. unix-way.

Ты о всех фичах по видео судишь?

а, ну у вас во freebsd все не как у людей :)

хм, а что в linux xorg уже освободился от оков libc6 ? ))

> Все уже давно это признали.

Признали дискомфорт? Хз, у меня на гконфе ничего не висит. Программы просто редко его дергают. На то это и настройки.

Ты о всех фичах по видео судишь?

Вы просто сказали о какой то кривости странной. Где? Конечно это одна из первых версий. И нет десятилетнего опыта. Но это не обязательно криво.

Пардон, а какое отношение libc имеет к glib?

http://packages.debian.org/lenny/libc6

libc6 добывают путем перегона на самогонном аппарате сырцов glib ))

Он скорее об этом.

А да, верно. Я тут не прав.
Действительно странные зависимости у freebsd для xorg ))

> а, ну у вас во freebsd все не как у людей :)

Временами да, но случай с Xorg к ним не относится. :-)

Смотрим в Debian (раз уж его помянули):

xserver-xorg (http://packages.debian.org/squeeze/xserver-xorg) тянет за собой hal (http://packages.debian.org/squeeze/hal), а hal в свою очередь радостно потащит за собой Glib.

Может ещё какие пути добраться по зависимостям до Glib есть, но и этого уже достаточно.

эффекты... прозрачность.. а базовый функционал так и останется кривым.
лучше сразу закопать, вместе с Qt

> У нас в универе если не на первой паре, то на второй объяснили разницу в стабильности, надежности и безопасности между fork/pipes и pthreads.

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

Надо сразу сказать что fork/pipes - тяжелое решение. Теоретический fork должен копировать всю память приложения, удваивая размер. Практически он этого не делает из-за оптимизаций в ядре.

Для чего он тогда нужен. Ну кроме того что это способ запустить другой процесс (fork, а потом exec в дочернем потоке), это способ написать приложение - набор процессов. Этим процессам в процессе вычислений зачастую не надо синхронизироваться, так как они работают в разных адресных пространствах. Приложение поступает так: форкается на нужное количество процессов, которые закрывают все дескрипторы и всю память, которая к ним не относится и работают отдельно. Обмен данных идет через pipes. И вот чудо: при падении процесса, пусть даже самом ужасном SEGFAULT, остальные процессы просто получат ошибку взаимодействия с ним. Они смогут обработать это или даже восстановить его. Обмен данными может быть через pipes и через еще кучу разных средств. Главный выигрыш в том, что процессы очень надежно изолированы. Так работает apache2. Думаю что не все хотели бы падения всего сервера из-за ошибки в одном из них. Ошибка - не торт, но все же зачем тушить сервер.

Эта схема не всегда подходит. Много памяти, медленный обмен. Если нужно работать буквально над общими данными, которые постоянно меняются, то можно использовать потоки. Их надо синхронизировать, но имеем выигрыш в производительности обмена информации. Как бы обмен естественный - общее адресное пространство.

Существует еще одно решение. Разделяемая память. Специальные объекты могут быть созданы, которые связывают общий кусок памяти с несколькими адресными пространствами а разных процессах.

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

Пример по форкам еще один (примеров с потоками есть много). Это Chrome. Между открытыми страницами «оказывается» не так и много данных передается. Но не очень хорошая страничка может свалить весь броузер. В итоге лучше сделать каждую страничку в отдельном процессе. Профит.

В универе был расчет на большой матрице на четырехядерном процессоре Xeon с дебианом на борту.

fork работал быстро, так как куски матриц процессор кидал себе в кеш на «ура». Имеем один проц - время t, два проца - время t/8, четыре проца - t/10. Не ожидал совсем.

pthreads заполнение матриц делали параллельно обработке, процессор не рисковал играть с кешем. Плюс синхронизация. pthreads слил по скорости, но выиграл естественно по памяти.

В общем сравнивать не корректно, так как я сказал, что алгоритмы были разные. Но fork работал быстрее с заполнением матрицы всего на одном ядре! Когда pthreads как не паралелили - все равно много висел на синхронизации.

Угу, только по сравнению с виндами оно как-то не смотрится, напоминает наколенную пионерскую поделку )

А теперь ещё раз, но коротко. Что стабильнее, надёжнее и безопаснее? fork или pthreads? Особенно меня смутила фраза «в линукс это один и тот же вызов с разными параметрами». Как тогда они могут отличаться стабильностью, надёжностью и безопасностью?

> Я в OpenSUSE с репы ставил... С больши-и-им трудом нашел.

А пакет как точно называется?

fork предоставляет больше возможностей по повышению надежности.

А теперь ещё раз, но коротко

Как то я и не обязан ничего писать. Хоть бы спасибо сказали.

> Угу, только по сравнению с виндами оно как-то не смотрится, напоминает наколенную пионерскую поделку )

на вкус и цвет все фломастеры разные ;)

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

/me комментировал текущую вохможность создания действительно компактных (удобных на экране рахрешением порядка 240x240 тем gtk).

Что я там считаю по Вашей теории, я так и не понял. Не снизойдёте разъяснить мне моё же мнение?

P. S. Возможность настраивать отступ между виджетом и краем окна - свистоперделка?!

Да, действительно, какой-то специфичный метод ведения дискуссий у человека.

Я просто не понял ваш сленг. Когда ничего не понятно из-за самодельных слов, то это глупо

> Возможность настраивать отступ между виджетом и краем окна - свистоперделка?!

нет канешна ))
как пример:
очень раздражает это в заметках nautilus (если я правильно понял вас)
текст цепляет края окна без зазоров.
чот там пыхтели и даже кто-то патч как-бы придумал - все бестолку и надо что-то темах шаманить. Я сильно уже не зарывался в это.

> Не снизойдёте разъяснить мне моё же мнение?

Ладно проехали, возможно не так понял вас.

Вопрос есть более общий тогда:
Если ли возможность в sidebar nautilus настройками тем (gtkrc видимо)
добавить бордюры у виджетов окон (скажем так, устранить сиротский вид).
В темах виденных мною я этого не увидел (или я плохо искал).

дискомфорт в том, что очередь запросов к gconf'у некисло тормозит загрузку системы. Что дико неприятно.

А про клаттер, даже если у него офигенные goal'ы, то из-за того, что это первая версия, я даже несмотря, основываясь на опыте, могу сказать, что там все тормозное, ресурсожрущее и падучее, работающее в стадии «proof of concept». Все как обычно в общем.

:) я думал ты про прямые зависимости. А насчет зависимости от hal'а я думаю она совсем не прямая. Вполне себе такой опциональный. Это ментейнеры ленятся.

Я борец в обратную сторону - отступы в gtk огромны, даже их неубираемая часть.

Видимо я вас тоже совершенно не понимаю, гном не юзаю, но копать надо примерно в такую сторону:

1) задается исправленный стиль, унаследованный от обычного:

style «hack» = «default» {

xthickness = 10

ythickness = 10

}

Здесь я просто сильно увеличил все возможные отступы.

2) выясняется, каким widget'ам нужно поменять стиль (не спрашивайте меня как(

3) widget_class «*НужныйВиджет*» style «hack»

> Qt не наркотик, попробовать с целью составления своего мнения (пусть даже негативного) вполне было бы можно :-D

Попробовал, на моём ноутбке интерфейс просто искрил артефактами (рандомные пиксели, рандомный окрас контролов в разные цвета), ненажатие контролов, общее убогое состояние софта по сравнению с гткшными. Спасибо, не надо.

> Попробовал, на моём ноутбке интерфейс просто искрил артефактами (рандомные пиксели, рандомный окрас контролов в разные цвета), ненажатие контролов, общее убогое состояние софта по сравнению с гткшными.

Вот сколько я разных версий Qt на различных машинах повидал, но описываемых артефактов никогда не видел.

Спасибо, не надо.

Да пожалуйста! Нам и без вас хорошо ;-)

>> Qt не наркотик, попробовать с целью составления своего мнения (пусть даже негативного) вполне было бы можно :-D

Попробовал, на моём ноутбке интерфейс просто искрил артефактами (рандомные пиксели, рандомный окрас контролов в разные цвета), ненажатие контролов, общее убогое состояние софта по сравнению с гткшными. Спасибо, не надо.

Как больше на аппаратные проблемы смахивает... Или проблема с драйвером/модулем Xorg или ядра... Возможно Qt попыталась задействовать какую-то акселерацию, которую не использует Gtk и поэтому на подобные проблемы не наступает?

>IIRC, gconf не использует libxml2, а опирается на парсер XML-подобной разметки из Glib (GMarkupParser)

Не знаю как сейчас, но раньше он на GMarkupParser переходил только если libxml2 не было (и писалось это для порта эволюшена под оффтопик).

>> Удаление всех public полей из структур.

что-то мне это напоминает

>>IIRC, gconf не использует libxml2, а опирается на парсер XML-подобной разметки из Glib (GMarkupParser)

Не знаю как сейчас, но раньше он на GMarkupParser переходил только если libxml2 не было (и писалось это для порта эволюшена под оффтопик).

Судя по исходникам, всё ещё немного иначе: это просто два разных backend'а. libgconfbackend-oldxml.so использует libxml2, а libgconfbackend-xml.so — GMarkupParser.

> Как больше на аппаратные проблемы смахивает... Или проблема с драйвером/модулем Xorg или ядра... Возможно Qt попыталась задействовать какую-то акселерацию, которую не использует Gtk и поэтому на подобные проблемы не наступает?

Ещё бы знать, что за акселепация. Под гномом Compiz летает без сучка-без задоринки.

> И как все чудно вылизано у того же йабла.

к йаблу давно присматриваюсь, правда его мобильные девайсы не впечатлили — интерфейс вылизан, как у кота это, а функционал дохловат. Боюсь, что в плане более крупных поделок (ноутов, моноблоков) дела обстоят не лучше. Но вообще есть большое желание потестить. Боюсь, что к НГ не утерплю и таки возьму себе iMac.

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

Вы не верите что могут быть баги? Qt безгрешен и это аксиома от которой нужно отталкиваться?

У меня тоже баги в Qt в демке ихней, Elastic Nodes.Там где несколько шариков связаны и демонстрируется физика. Код нормальный, рисуют и анимацию делают не сами, а доверяют Qt стирать экран. Стирает не везде. Остаются артефакты. Пруф

http://fotohost.jampo.com.ua/images/b5d992b51efbd2771b34e9e669c15385.png

Еще у меня проблемы были в Qt Assistant. Там тоже были артефакты. Тоже артефакты. Для пруфа не смог воспроизвести. Или пофиксили или я забыл когда это случалось. Но просмотр кода рвался постояно. Просто нужно как то хитро запустить. Ну как хитро... Первый раз я случайно увидел.