Вышел MythTV 0.22

ставил когдато давно, надо потыкать новую версию...

Красивый, но тяжелый, как по ресурсам, так и по настройкам. Для меня vdr выполняет те же самые функции.

пардон, glibc или glib???

>В Qt упор сделан на кроссплатформенность: чтобы в идеале программа, написанная с использованием Qt, собиралась без модификации исходников на всех платформах, для которых есть Qt.

Какбы цели аналогичные. Если б не нужна была кроссплатформенность, можно было бы обойтись без половины кода (навскидку) что в глибе, что в куте...

>Если с Glib + GTK можно так же (сам на данный момент не знаю, с программированием с Qt знаком на очень поверхностном уровне, с GTK - намного меньше), то я не против.

можно

Но есть одно важное отличие: глиб/гтк+ написаны на Ц и имеют туеву хучу байндингов на другие языки (в том числе с нормальным ООП, если кому надо то есть и для крестов), а кутэ написана на крестах и писать под нее на не ООП-языках в т.ч. на Ц я не смогу. Не всем нравиться ООП. ООП не всегда нужно, не всегда эффективно.

ЗЫЖ

> Да и плюс QT написанна на C++, конечно это даёт более низкую производительность (по сравнениию с С), но ты имеешь 100% ООП со всеми вытекающими.

Местами производительность, вроде, даже выше (по крайней мере однажды так было). Но тем не менее.

А что касается ООП: man glibmm/gtkmm (для крестов), pygtk, или чего-там-ещё-gtk -- во всех ООП-биндингах полноценное ООП.

QT как раз знаменито ломкой програм на ней при смене версий. 95% пофиксено - это значит 5% багов?? Это даже для пионерской поделки многовато. Я допускаю в моих законченных программах 1-2 бага в месяц. Qt явно не может этого обеспечить.

95% пофиксено - это значит 5% багов?? Это даже для пионерской поделки многовато.

Ну почему- же многовато, если их не нашли- это не значит что их нет...

Я допускаю в моих законченных программах 1-2 бага в месяц. Qt явно не может этого обеспечить.

См. выше

А кутэ написана на крестах и писать под нее на не ООП-языках в т.ч. на Ц я не смогу

Мир не стоит на месте, и C постигает судьба ASM (ведь в своё время тоже кричали: нафиг высокоуровневые языки, когда есть низкоуровневые). Ну и актуальны сейчас следующие C разработки:

1) Программинг just-for-funs

2) Драйвера и примочки к ним

3) Поддержка уже существующих и нормально работающих C проектов (linux-kernel, x-server, gcc, etc.)

В остальном C не актуален, сейчас уже PC уровня PentiumII - редкость, поэтому производительность (C vs C++) уходит на второй план. Вы сейчас можете перечислить новые (например с начала 2009 года) проекты, написанные на C (кроме драйверов и иже с ними ессно)?

>Какбы цели аналогичные. Если б не нужна была кроссплатформенность...

1) Обеспечивает ли GTK нативный look and feel ? судя по http://www.gtk.org/screenshots.html нет, "GIMP on Mac" выглядит по уродски. Под Windows, сужу по TortoiseHg, тоже не все гладко.

2) Количество поддерживаемых платформ? Qt: Windows, различные *nix'ы, Mac OS X, Win CE / Win Mobile, Symbian S60, embedded Linux. Библиотека собирается множеством компиляторов как свободных, так и коммерческих. Причем собирается все как правило просто, собственная система сборки, поддержка cmake. И вообще "все включено". Имеется средство создания справки, средство локализации. В фреймворке имеется библиотеки на все случаи жизни, помимо собственно GUI, работа с различным БД, XML, сетью, и т.д. Так что сторонние либы зачастую не нужны. Я допустим сталкивался с сетевыми сервисами написанными на Qt (система может быть развернута под Win и Linux), там вообще GUI кода нет.

3) Как насчет удобства для программиста? В Qt очень неплохая документация, полно примеров от простых, до довольно навороченных. В дизайнере довольно удобно клепаются формочки, есть неплохая интеграция с распространенными средами разработки. Есть неплохая своя среда - Qt-Creator.

> а кутэ написана на крестах и писать под нее на не ООП-языках в т.ч. на Ц я не смогу

теоретически binding к ОО либе можно сделать и для не ОО языков (пример COM/ActiveX). Но практически оно нафиг не кому не надо.

>Не всем нравиться ООП. ООП не всегда нужно, не всегда эффективно.

нравится не нравится, к делу не относится, это личные тараканы в голове.

А вот где не нужно и не эффективно? Что за задачи такие и зачем там вообще нужен GTK / Qt ?

> поэтому производительность (C vs C++) уходит на второй план

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

1) Кастрированные ОС'и не нужны, а вообще писал прогу для вантузятников на питоне под гтк+. Проблем с отображением не было.

2) Большая часть этих "платформ" также не нужна. Поддержка любой системы сборки, начиная от простейшего Мэйкфайла.

> всё включено

следует читать как "наша либа самая толстая"

> средство создания справки

вантузятскими hlp-ами попахивает

и вообще куча велосипедов, 3/4 всего перечисленного не нуждается в обёртках, а остальная 1/4 есть в глиб

Кстати, писать безгуёвые проги на глибе гораздо логичнее, чем на куте, ибо легче в стопицот раз. Кстати, таких немало...

и тоже никаких проблем с разворачиванием на кривых осях

3) Тоже есть, не жалуюсь... на счёт доков для полных ламеров: не знаю, не искал. Есть glade, но без него *легко* можно обойтись

> теоретически binding к ОО либе можно сделать

> Но практически оно нафиг не кому не надо

ню-ню... "всё, что мы не можем, нам не нужно" а вообще это редкий изврат

> нравится не нравится, к делу не относится, это личные тараканы в голове

это вопрос свободы выбора, не люблю когда мне навязывают парадигму

> А вот где не нужно и не эффективно? Что за задачи такие и зачем там вообще нужен GTK / Qt ?

Такие бывают. Это почти любая задача, где требуется лёгкость. Гтк везде может быть нужен только для гуя. (это кутэ может быть нужен хз за чем, а вот гтк -- точно для гуя, узкая заточенность, знаете ли)

ответ в стиле школьников, то не нужно, это не нужно...

деньги наверное тоже не нужны? или Вы забесплатно работаете, а может еще и не работаете? GUI софт только для линукса почти никто не делает, даже студенты. Qt обеспечивает готовое решение для всех распространенных платформ.

>Такие бывают. Это почти любая задача, где требуется лёгкость.

какая такая задача, конкретнее можно? Мне пока приходит в голову одно логичное применение С, это программирование для маломощных контроллеров, С++ компилятора возможно нет в природе, да он и не сильно нужен в силу специфики. GTK и Qt тут естественно не к чему.

> деньги наверное тоже не нужны?

программить за деньги то, что те тебе не нравится и на том, что не нравится == быдлокодинг.

> или Вы забесплатно работаете, а может еще и не работаете?

программером я не работаю, программинг -- это исключительно для себя (ну и фрилансы)

> GUI софт только для линукса почти никто не делает

следует читать как "софт только для линукса почти никто не делает"

> Qt обеспечивает готовое решение для всех распространенных платформ.

ню-ню... предел кроссплатформенной необходимости: nix+win, а если уж приспичит писать под какую-неть херню типа симбиана или wince, то тянуть туда кутю просто глупо

> какая такая задача, конкретнее можно?

Любая числодробительная.

> Мне пока приходит в голову одно логичное применение С, это программирование для маломощных контроллеров

Не только. Ц вообще эффективнее. Даже если ядер у процессора хоть жопой ешь, всё ресы экономить стоит.

> GTK и Qt тут естественно не к чему.

В glib есть, например, куча функций, для работы с динамическими строками, связными списками, деревьями... *уже хорошо написанные и оптимизированные* функции. Причём сама библиотека гораздо легче, чем лбая часть qt

Ого так и не научилось SQLite юзать? Тогда в топку!

>>Не только. Ц вообще эффективнее. Даже если ядер у процессора хоть жопой ешь, всё ресы экономить стоит.

Ассемблер ещё эффективнее, ибо любой код компилируется в ассемблер, а компилятор не может со 100% эффективностью его перевести, человек всё таки умеет пока лучше...

>>программером я не работаю, программинг -- это исключительно для себя (ну и фрилансы)

Ну вот с этого и надо было начинать... Вы не вкурсе, что проект на C пишется в несколько раз медленнее, чем на C++. И C++ в несколько раз медленне, чем на Java или Python.

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

Для свободных проектов похожая ситуация. При разработке проекта программисты исходят из того, что при выборе (пример: C++ против C ) более современной технологии он может потратить время, сэкономленное на базовом функционале, на разработку дополнительных фитч или же на отладку/багофикс (для стабильности работы). Ведь баги/дыры есть и в C ;)

Прекрасно, осталось приложить список приложений с репутацией стабильных, надежных и сроком жизни более трех лет под Linux , не для kde и изветных подобно gimp, abiword, & etc.
Ну , инструмент ведь такой мощный ? :))

> следует читать как "софт только для линукса почти никто не делает" нет, не следует. Ряд серверного софта делается только для *nix.

> ню-ню... предел кроссплатформенной необходимости: nix+win, а если уж приспичит писать под какую-неть херню типа симбиана или wince, то тянуть туда кутю просто глупо

Mac вполне актуален, если говорить о платном софте, то актуальность побольше всех остальных никсов.

насчет симбы и винце, все от задачи зависит, если сложное приложение с кучей формочек, или если есть просто перспектива в будущем портировать на мобилки и др. портативные девайсы...

> Любая числодробительная.

их вообще часто на фортране пишут (если именно математика имеется ввиду).

> Не только. Ц вообще эффективнее. Даже если ядер у процессора хоть жопой ешь, всё ресы экономить стоит.

конкретно, чем? Все фичи плюсов сделаны в угоду эффективности, за что его ругают любители Java, С# и подобного. Что именно из "плюсов" использовать зависит от кодера.

> В glib есть, например, куча функций, для работы с динамическими строками, связными списками, деревьями... *уже хорошо написанные и оптимизированные* функции. Причём сама библиотека гораздо легче, чем лбая часть qt

а glib вообще соберется на не "жирных" платформах? На офф. сайте только Unix и Windows (десктоп), не одного упоминания о тех же win ce, emmbedded lunux, симбы и тем более простых контроллерах.

> Ассемблер ещё эффективнее, ибо любой код компилируется в ассемблер, а компилятор не может со 100% эффективностью его перевести, человек всё таки умеет пока лучше...

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

>>Прекрасно, осталось приложить список приложений с репутацией стабильных, надежных и сроком жизни более трех лет под Linux , не для kde и изветных подобно gimp, abiword, & etc.

Навскидку продиктую:

OpenSource- Amarok, Transmission-QT (Работает стабильнее делюга и ресурсов ест намного меньше), MythTV :)

Proprietarity- Opera, Nero-Linux(пока только она умеет работать с BD-R)

> Ну вот с этого и надо было начинать... Вы не вкурсе, что проект на C пишется в несколько раз медленнее, чем на C++. И C++ в несколько раз медленне, чем на Java или Python.

Вот поэтому реальные проекты лучше писать на Java (если скорость некритична вообще и необходима однородность кода) или на C + (Python/Lisp/Haskell/Java/etc). Потому как для предметной области Python/Lisp/haskell гораздо выразительнее, чем С++, а тот 1% программы, что _надо_ оптимизировать, проще написать на C, потому что адекватную библиотеку на C++ для Python или ещё чего-нибудь кроме C++ (и может D) сделать нельзя.

>А чем MythTV круче Moovida Media Center?

Тем, что первый есть в портеже Gentoo, а второго - нет :)

...

А так - всё собираюсь посмотреть, но всё руки не доходят.

>>А чем MythTV круче Moovida Media Center?

А Moovida умeет декодировать видео при помощи GPU? просто сейчас с 1080p- .h264 далеко не все современные CPU справляются. A MythTV + nvidia 8xxx (VDPAU) нагрузку дают на видеократу, т.е. FullHD фильмы можно смотреть без тормозов, даже имея самый древний процессор

>А Moovida умeет декодировать видео при помощи GPU?

Moovida использует в качестве бэкенда gstreamer. Следовательно, если в gstreamer ускорение видео есть, то будет, а если нет (если не ошибаюсь, на данный момент дело обстоит именно так, но надо бы исправить) - то нет.

А вообще лучше покупать процессор, которого хватает на 1080. А невозможность воспроизведения видео без видеокарты тормозит развитие свободных форматов (до тех пор, пока видеокарты не будут их воспроизводить).