За день до выхода GNOME 3.6 увидел свет стабильный релиз новой ветки многоплатформенного тулкита для создания графического интерфейса пользователя - GTK+ 3.6.0 (http://www.gtk.org/). Ветка GTK+ 3.6 полностью обратно совместима с прошлыми выпусками GTK+ серии 3.x. В состав тулкита входит полный набор виджетов, позволяющих использовать GTK+ для проектов различного уровня и размера. Код GTK+ развивается в рамках проекта GNU и распространяется под лицензией LGPL, что позволяет использовать GTK+ не только для разработки свободного ПО, но и для создания проприетарных приложений, не требуя от производителей закрытых программ выплаты роялти или покупки специальной лицензии. С тех пор, как GTK+ был разработан в рамках проекта GIMP, тулкит используется в различных проектах, например, GTK+ лежит в основе десктоп-окружений GNOME и Xfce или используется в таких продуктах, как Firefox и OpenOffice/LibreOffice.
GTK+ спроектирован для поддержки не только C/C++, но и других языков программирования, таких как Perl и Python, что в сочетании с использованием визуального построителя интерфейса Glade (http://glade.gnome.org/) позволяет существенно упростить разработку и сократить время написания графических интерфейсов. Организация вывода в GTK+ абстрагирована от типа оконных систем, например, поставляется бэкенд, обеспечивающий возможность работы поверх дисплейного сервера Wayland, а также бэкенд, позволяющий отрисовывать вывод библиотеки GTK+ в окне web-браузера (запустив Gtk-приложение на одной машине, можно открыть web-браузер на другой машине и получить доступ к интерфейсу данной программы).
Из добавленных в GTK+ 3.6.0 улучшений можно отметить:- В GtkEntry (http://developer.gnome.org/gtk3/3.6/GtkEntry.html) добавлен субкласс GtkSearchEntry (http://developer.gnome.org/gtk3/3.6/GtkSearchEntry.html), предназначенный для создания однострочных элементов ввода для организации поиска (рядом с полем отображается иконка, специфичная для поиска);
<center><img src="http://www.opennet.me/opennews/pics_base/0_1348559273.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></center>- Добавлен виджет GtkMenuButton (http://developer.gnome.org/gtk3/3.6/GtkMenuButton.html), формирующий кнопку вызова меню, которое может быть сгенерировано, например, через GMenu;
<center><img src="http://www.opennet.me/opennews/pics_base/0_1348559290.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></center>
- Добавлен виджет GtkLevelBar (http://developer.gnome.org/gtk3/3.6/GtkLevelBar.html) для отображения индикатора уровня для заданной величины;
<center><img src="http://www.opennet.me/opennews/pics_base/0_1348559301.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></center>- Кнопки ввода чисел GtkSpinButton (http://developer.gnome.org/gtk3/3.6/GtkSpinButton.html) теперь могут быть расположены вертикально;
- Формы просмотра и ввода текста могут дополнительно отображать обработчик выделения областей при использовании на устройствах с сенсорным экраном.
- Улучшение API для формирования визуальных тем, описание стиля в которых задаётся в CSS-подобном представлении с возможностью смены стиля на лету. В новой версии добавлена поддержка CSS-анимации, использования размытых теней, обеспечения постепенного перехода и плавного затенения.
Одновременно представлен (https://mail.gnome.org/archives/gnome-announce-list/2012-Sep...) релиз развиваемой синхронно с GTK+ библиотеки Glib 2.34.0, расширяющей возможности стандартной библиотеки Си. В новой версии реализация шины обмена сообщениями адаптирована для работы на платформе Windows, в классах stream добавлена поддержка свойств GSeekable и GPollable.
URL: https://mail.gnome.org/archives/gnome-announce-list/2012-Sep...
Новость: http://www.opennet.me/opennews/art.shtml?num=34927
LevelBar невыразимо прекрасен!
> LevelBar невыносимо прекрасен!//fixed.
По ссылке Глэйда:
http://glade.gnome.org/images/glade-main-page.png
непонятно зачем такие гипертрофированные кнопки.Имхо, не стоит совмещать несовместимое - мухи отдельно от котлет.
на красивых скриншотах в статье - как задумал дизайнер, на приведенном вами - как поняли программисты :)
> - как поняли программисты :)По этому поводу есть довольно старинная шутка: http://alive.by/sites/default/files/img_articles/agile_5.jpg
> Имхо, не стоит совмещать несовместимое - мухи отдельно от котлет.Именно - кнопки отдельно, стили отдельно. Все правильно.
P.S. Я не увидел на скриншоте новых (3.6) элементов на форме. В деле, так сказать. Потому ценности скриншота не понял.
Все разбежались на другие тулкиты, после выпуска этого чуда. Гном3 я имею ввиду. Поэтому и комментариев нет.
>В новой версии реализация шины обмена сообщениями адаптирована для работы на платформе WindowsЭто самое важное, чем надо было заниматься - важнее проблем конечно нет.
Действительно, зачем кроссплатформенному тулкиту улучшать свою кроссплатформенность. Лучше бы кнопок новых побольше да покрасивше добавили.
Да уж лучше бы нормальное IDE типа Qt Creator изобрели. :( Все жду, не дождусь.
Да уж, изобрести ещё один помогатор с кнопкой "Сконпелировать лабу", это важнейшая из задач.
Ага, для утилиты на 3 формы только emacs, только харкор!
> Ага, для утилиты на 3 формы только emacs, только харкор!Это не баг, это фича: быдлокодеров, которые хотят быстро налабать на коленке какую-то хрень очень эффективно отсеивает. Поэтому качая программу на GTK можно по крайней мере ожидать что с высокой вероятностью это будет не совсем уж наколенным поделием от очередного школьника.
Caveat: если в зависимостях есть питон, тогда вышесказанное - не факт.
>> Ага, для утилиты на 3 формы только emacs, только харкор!
> Это не баг, это фича: быдлокодеров, которые хотят быстро налабать на коленке
> какую-то хрень очень эффективно отсеивает. Поэтому качая программу на GTK можно
> по крайней мере ожидать что с высокой вероятностью это будет не
> совсем уж наколенным поделием от очередного школьника.1. Все когда- то были школьниками. Где гарантия что отсеяный сейчас школьник не накодил бы в будущем новый linux? Кстате, Вас никто не заставляет школьные поделия использовать.
2. IDE есть инструмент и для своей задачи он должен быть удобным. Лучше сконцентрироваться на алгоритме и качестве кода чем на написании make файла, например.
4. Да, кстате, я практически не видел наколенного говнокода на асемблере, но я же не призываю отказаться от C/C++, Java...
3. Тема GTK vs Qt сейчас, как я понял, не обсуждается.
>1. Все когда- то были школьниками. Где гарантия что отсеяный сейчас школьник не накодил бы в будущем новый linux?Ты имеешь в виду то, что Торвальдс когда-то давно представил на суд общественности? Так таких полно.
>2. IDE есть инструмент и для своей задачи он должен быть удобным. Лучше сконцентрироваться на алгоритме и качестве кода чем на написании make файла, например.
Только потом не забудь сконцентрироваться на отладке, unit-тестах, сборке на build сервере своих алгоритмов и качественного кода. Заодно подумай о распространении результата в виде разных пакетов под разные системы. И вдруг окажется, что инструменты типа cmake по приятней будут для всего этого, и git оказывается умеет куда больше чем то, что есть в настройках IDE. Я уже вдоволь намучился с любителями IDE, которые не могут сделать автоматическую сборку проекта с кучей конфигураций, и так и компеляют из неё все по очереди.
>Только потом не забудь сконцентрироваться на отладке, unit-тестах, сборке на build сервере своих алгоритмов и качественного кода.qmake? Что мешает его руками не писать? Что мешает сделать субпроект для юнит тестов и собирать это все на build сервере? Кстате, как раз сейчас на работе:
1. Qt2. Cross platform
3. Unit tests
4. Static code anlysis
5. CI (build server + unit test run + code analysis run)
Все строго и серьезно (с code review, тестингом на разных платформах, и т.д.) У всей команды QtCreator.Что мы делаем не так?
Вот зачем мне руками добавлять файлі в .pro файл? Рефактор опять какой-ни-какой, отладка...>Я уже вдоволь намучился с любителями IDE, которые не могут сделать автоматическую сборку проекта с кучей конфигураций, и так и компеляют из неё все по очереди.
Так это не проблема IDE. Проблема в головах и только. Любого вчерашнего студента нужно доучивать.
> 1. Все когда- то были школьниками.Замечательно, но это не повод позволять пакостить везде где попало.
> Где гарантия что отсеяный сейчас школьник
> не накодил бы в будущем новый linux?На яваскприпте в гламурном тулзе где можно мышкой кнопочки расставлять? Очень врядли что из этого Линус вырастет. Линус помнится программил свою систему написав самый минимум для того чтобы работал консольный редактор. После этого система перешла на самообслуживание :). А гламурное кисо разбалованное редактором с кучей наворотов никогда не сможет в 1 рыло написать kernel который осилит все его прихоти типа вывода навороченного GUI. Поэтому еще одного Торвальдса чисто технически не получится. Вот ушлепан с горящими глазами, вопящий что операционки надо писать на JS (но сам ни одной не написавший) - это запросто.
> Кстате, Вас никто не заставляет школьные поделия использовать.
Кстати, "кстати" пишется через "и". И да, меня не заставляют. Но искать среди этих вонючих отходов нормальные программы, писанные пряморукими программистами с нормальным подходом к разработке - достаточно утомительно. Вполне валидный повод не жаловать халтурщиков-рапидчиков.
> 2. IDE есть инструмент и для своей задачи он должен быть удобным.
IDE есть инструмент, а не замена мозга программиста. Торвальдс написал свою систему вообще поначалу в минимальном редакторе. Этим профессионал и отличается от дилетанта. Профессионалу много не надо. А ламерье шагу ступить не может без вон тех гламурных плюшечек. По поводу чего такие "программисты" в отрыве от своего IDE вообще нули без палочки. Ну в общем не зря придумали термин "быдлокодеры". Это примерно как если я ща все брошу и пойду в ресторан шеф-поваром. Несомненно, что-то я конечно приготовлю. Вот только я что-то совсем не уверен что вы ожидаете от шеф-повара именно такую квалификацию.
> Лучше сконцентрироваться на алгоритме и качестве кода чем на написании make
> файла, например.Красиво было на бумаге да забыли про овраги. Обычно 99.9% школьников концентрируется на возякании мышкой и расставлении кнопок в форме в результате. А если JS дать - начинает агрессивно орать что все остальные языки - вообще лишние, а уж сборка мусора - вообще мастхэв. Как это - ядро на си? Надо срочно на JS переписать! Сами они правда не горят желанием это сделать и туго представляют себе проблемы которые при этом возникнут. Налицо деструктивное влияние на мозг подобных сред - способствует отупению и обыдлению.
> 4. Да, кстате, я практически не видел наколенного гoвнокода на асемблере,
Да ладно вам, бывает и такое. Просто это неудобно. Среда не способствует. Поэтому и редкость.
Ну вот для обучения программированию лучше всего Паскаль. Он зануда, но к порядку приучает хорошо. А JS к чему школьника приучит? К раздолбайству? Да, в JS можно сравнить попугаев с апельсинами. И не будет ни ошибок компиляции, ни рантайм ошибок. А вот когда оно через полчаса навернется в совсем другом месте - будет весело.
> я же не призываю отказаться от C/C++, Java...
От последнего лучше бы отказаться. Глядя на то какой обычно на этом софт получается.
> 3. Тема GTK vs Qt сейчас, как я понял, не обсуждается.
Как вам сказать? Я считаю упрощение и обыдление тулзов потенциальным недостатком. И куть 5-й версии в этом плане вызывает опасения. Есть риск что будет написано много кривых и горбатых поделок, которые будет сложно отсевать от нормальных программ.
>[оверквотинг удален]
> перешла на самообслуживание :). А гламурное кисо разбалованное редактором с кучей
> наворотов никогда не сможет в 1 рыло написать kernel который осилит
> все его прихоти типа вывода навороченного GUI. Поэтому еще одного Торвальдса
> чисто технически не получится. Вот ушлепан с горящими глазами, вопящий что
> операционки надо писать на JS (но сам ни одной не написавший)
> - это запросто.
>> Кстате, Вас никто не заставляет школьные поделия использовать.
> Кстати, "кстати" пишется через "и". И да, меня не заставляют. Но искать
> среди этих вонючих отходов нормальные программы, писанные пряморукими программистами
> с нормальным подходом к разработке - достаточно утомительно.К сожалению, это неизбежно. Просто раньше была куча говнопрограмм на Delphi (который, кстате в купе с C++ Builder, в своей области вполне ничего). а до этого куча говнопрограмм на Turbo PAscal/Turbo basic... Сайчас куча C#,Qt и т.д. Ничего не меняется. И IDE тут не виноваты.
>> 2. IDE есть инструмент и для своей задачи он должен быть удобным.
> IDE есть инструмент, а не замена мозга программиста. Торвальдс написал свою систему
> вообще поначалу в минимальном редакторе. Этим профессионал и отличается от дилетанта.Вы родились професионалом? Я- нет. Кроме того я хочу (уже будучи професионалом) автоматизацию рутинных действий.
> Профессионалу много не надо. А ламерье шагу ступить не может без
> вон тех гламурных плюшечек. По поводу чего такие "программисты" в отрыве
> от своего IDE вообще нули без палочки.Точно такими же нулями они были бы и без IDE. Так очень многие C++ программисты понятия не имеют о низкоуровневом механизме вызова виртуальной функции. Ну не буду же я их для этого заствалять учить асемблер?
> Ну в общем не
> зря придумали термин "быдлокодеры". Это примерно как если я ща все
> брошу и пойду в ресторан шеф-поваром. Несомненно, что-то я конечно приготовлю.
> Вот только я что-то совсем не уверен что вы ожидаете от
> шеф-повара именно такую квалификацию.Так быдлокодера и не возьмут на серьезный проект (не примут быдлокодерские патчи).
>> Лучше сконцентрироваться на алгоритме и качестве кода чем на написании make
>> файла, например.
> Красиво было на бумаге да забыли про овраги. Обычно 99.9% школьников концентрируется
> на возякании мышкой и расставлении кнопок в форме в результате. А
> если JS дать - начинает агрессивно орать что все остальные языки
> - вообще лишние, а уж сборка мусора - вообще мастхэв.Вы путаете личностные качества человека и его професионализм. "Все гавно только я Дартаньян" от языка не зависит по большому. Да, согласен, там где порог вхождения ниже, там больше агресивных ламеров. И что? Тот же JS в некоторых областях неплох. Да, JS программисту будет ну очень трудно со временем привікнуть к типизации и, скажем так, куда как менее экзотичному подходу к ООП в других языках. Но это еще не начит что он "быдлокодер и вобще"...
> Надо срочно на JS переписать! Сами
> они правда не горят желанием это сделать и туго представляют себе
> проблемы которые при этом возникнут. Налицо деструктивное влияние на мозг подобных
> сред - способствует отупению и обыдлению.Воинствующее ламерье неистребимо и его популяция от наличия RAD не зависит.
>> 4. Да, кстате, я практически не видел наколенного гoвнокода на асемблере,
> Да ладно вам, бывает и такое. Просто это неудобно. Среда не способствует.
> Поэтому и редкость.Дык! Соотношения професионалов к воинствующим ламерам вобщем- то константно, ИМХО. Для того чтобы тут распинаться, например о том что Linux - насе усьо, все остальные гавно даже Ubuntu по большому счету можно не ставить.
> Ну вот для обучения программированию лучше всего Паскаль. Он зануда, но к
> порядку приучает хорошо. А JS к чему школьника приучит? К раздолбайству?Ну как сказать... Я начинал вобще с 8 битного Basic. Потом сразу assembler. А потом уже Pascal/C. И ничего, не умер.
> Да, в JS можно сравнить попугаев с апельсинами. И не будет
> ни ошибок компиляции, ни рантайм ошибок. А вот когда оно через
> полчаса навернется в совсем другом месте - будет весело.
>> я же не призываю отказаться от C/C++, Java...
> От последнего лучше бы отказаться. Глядя на то какой обычно на этом
> софт получается.Многие забывают о том что серебряной пули нет. Java, JavaScript, C++, и т.д. хороши только в своих нишах. Если на С++ будут писать серьезный (но не критически нагруженый) web сервис, согласитесь, это не есть гуд.
>> 3. Тема GTK vs Qt сейчас, как я понял, не обсуждается.
> Как вам сказать? Я считаю упрощение и обыдление тулзов потенциальным недостатком. И
> куть 5-й версии в этом плане вызывает опасения. Есть риск что
> будет написано много кривых и горбатых поделок, которые будет сложно отсевать
> от нормальных программ.В 5-1 версии Qt выпячивание QML меня тоже, честно говоря, напрягает. Учитывая то что десктопные виджеты в разметку QML не успеют добавить, соответственно появятся поделки с вырвиглазными кнопочками, входящими в диссонанс с темой рабочего стола. Но сама идея опционального полного отделения логики от UI это хорошо (пользовал в EFL).
Опять же, говнопрограммы и говнокод неистрибимы, как не прискорбно. Тут только разьяснительная работа.
Зря Вы так на мир смотрите.
1. Технология RAD еще никому не вредила. Ее как раз и предлагают для сокращения времени разработки.
2. Qt Creator - это совсем не игрушка. У меня достаточно долгая практика разработки (более 20 лет), так что я много чего перевидел и попробовал. И я Вам говорю, что для Qt Library, Qt Creator - это гуд и большой плюс.
3. Я видел многих начинающих программистов, которые отказывались от GTK+ именно ввиду сложности разработки кода и переходили на Qt или wxWidgets. Сложность программирования за последние годы возросла многократно и для начинающих в этом деле подобные продукты являются большим подспорьем.
> 1. Технология RAD еще никому не вредила.Как это никому? Рапидно налабанные программы отличаются низким качеством и вообще откровенной наколенностью по очевидным причинам.
> Ее как раз и предлагают для сокращения времени разработки.
В советское время был анекдот: Почему проигрыватель называется проигрывателем? Потому что при его использовании выигрывает кто-то один, а проигрывают все остальные. Вот и с рапидной разработкой как-то так же. Программер выигрывает. А зато всем кому этот шит надо от нормальных программ отсеивать - проигрывают. Потому что приходится тратить время и качать чтобы только осознать что программа - полный крап, тормозная, bloat-нутая, с кучей багов и вообще писана школьником на коленке. Который понятия не имеет о том как процесс разрабоки делается по уму и хочет скорей-быстрее тыр-пыр результат. К счастью, на десктопе такой шит вообще не в почете.
> 2. Qt Creator - это совсем не игрушка. У меня достаточно долгая
> практика разработки (более 20 лет), так что я много чего перевидел
> и попробовал. И я Вам говорю, что для Qt Library, Qt Creator - это гуд и большой плюс.Есть опасения что школие сможет в результате быстро лабать отходы мозговой деятельности на яваскрипте. Тормозные, монструозные, глючные, и попросту низкокачественные. Так что придется просто избегать "программ на Qt вообще" из-за высокого риска нарваться на такой вот отход мозговой деятельности если программа писана на Qt.
> 3. Я видел многих начинающих программистов, которые отказывались от GTK+ именно ввиду
> сложности разработки кода и переходили на Qt или wxWidgets.А лучше пусть сразу в дворники переходят. Если кто не готов серьезно учиться - значит ему лопаты и метлы в руки, там много учиться как раз не надо. А вот когда каждый дилетант лезет в несвойственную ему область - ничего хорошего не выходит. Вы же наверное не захотите питаться в ресторане где вместо шеф-повара будет случайно отловленный на улице дворник. Первый попавшийся.
> Сложность программирования за последние годы возросла многократно и для
> начинающих в этом деле подобные продукты являются большим подспорьем.Зато потом в этих какашках искать программу которая не тормозит, не глючит, не падает и вообще просто делает то что заявлено, не выпендривается и не требует скачать по зависимостям полинтернета - довольно утомительно. При том что ценность таких программ как правило низкая и сиюминутная. А вот срач от них - очень даже. В мире уже много программ. Даже хороших. Не надо заваливать его отходами мозговой жизнедеятельности. Копаться в них потом неприятно, знаете ли.
А не хило вы сейчас половину форума опомоили!
Только одна ваша фраза:
>Есть опасения что школие сможет в результате быстро лабать отходы мозговой деятельности на яваскрипте.
>Тормозные, монструозные, глючные, и попросту низкокачественные.
>Так что придется просто избегать "программ на Qt вообще" из-за высокого риска нарваться на такой вот отход мозговой деятельности если программа писана на Qt.Это просто жесть. -100
Что день не задался?
> А не хило вы сейчас половину форума опомоили!А я виноват что быдлокодеров генерящих жуткий шЫт вместо кода нынче много?
> Только одна ваша фраза:
> Это просто жесть. -100Неужели вы узнали в этой фразе себя? Бывает.
> Что день не задался?
Да вообще пц: с самого утра обозвали тем кем вы и являетесь. Все, настроение у быдлокодера насмарку. Ведь хочется чувствовать себя крЮтым мачо, а тут на тебе - на форуме информируют что вы всего лишь унылый быдлокодер :)
>> 1. Технология RAD еще никому не вредила.
> Как это никому? Рапидно налабанные программы отличаются низким качеством и вообще откровенной
> наколенностью по очевидным причинам.По каким это? Помоему эти причины очевидны только для Вас.
>> Ее как раз и предлагают для сокращения времени разработки.
> В советское время был анекдот: Почему проигрыватель называется проигрывателем? Потому
> что при его использовании выигрывает кто-то один, а проигрывают все остальные.
> Вот и с рапидной разработкой как-то так же. Программер выигрывает. А
> зато всем кому этот шит надо от нормальных программ отсеивать -
> проигрывают. Потому что приходится тратить время и качать чтобы только осознать
> что программа - полный крап, тормозная, bloat-нутая, с кучей багов и
> вообще писана школьником на коленке. Который понятия не имеет о том
> как процесс разрабоки делается по уму и хочет скорей-быстрее тыр-пыр результат.
> К счастью, на десктопе такой шит вообще не в почете.Я еще помню подобные дискуссии на тему C/C++ vs assembler. Сторонники последнего по Вашей же логике назвали бы Вас именно "и хочет скорей-быстрее тыр-пыр результат"...
>> 2. Qt Creator - это совсем не игрушка. У меня достаточно долгая
>> практика разработки (более 20 лет), так что я много чего перевидел
>> и попробовал. И я Вам говорю, что для Qt Library, Qt Creator - это гуд и большой плюс.
> Есть опасения что школие сможет в результате быстро лабать отходы мозговой деятельности
> на яваскрипте. Тормозные, монструозные, глючные, и попросту низкокачественные. Так что
> придется просто избегать "программ на Qt вообще" из-за высокого риска нарваться
> на такой вот отход мозговой деятельности если программа писана на Qt.Ваше право. Тогда, если я не ошибаюсь, как минимум VirtualBox и VLC не для Вас.
>> 3. Я видел многих начинающих программистов, которые отказывались от GTK+ именно ввиду
>> сложности разработки кода и переходили на Qt или wxWidgets.
> А лучше пусть сразу в дворники переходят. Если кто не готов серьезно
> учиться - значит ему лопаты и метлы в руки, там много
> учиться как раз не надо. А вот когда каждый дилетант лезет
> в несвойственную ему область - ничего хорошего не выходит. Вы же
> наверное не захотите питаться в ресторане где вместо шеф-повара будет случайно
> отловленный на улице дворник. Первый попавшийся.Правильно. И на домашних кухнях у всех кастрюли отобрать! Дабы не лезли со своими говноблюдами в кулинарию.
>> Сложность программирования за последние годы возросла многократно и для
>> начинающих в этом деле подобные продукты являются большим подспорьем.
> Зато потом в этих какашках искать программу которая не тормозит, не глючит,
> не падает и вообще просто делает то что заявлено, не выпендривается
> и не требует скачать по зависимостям полинтернета - довольно утомительно. При
> том что ценность таких программ как правило низкая и сиюминутная. А
> вот срач от них - очень даже. В мире уже много
> программ. Даже хороших. Не надо заваливать его отходами мозговой жизнедеятельности.
> Копаться в них потом неприятно, знаете ли.Так ищите нормальную с Вашей точки зрения альтернативу. Или создайте. Вполне возможен вариант что задача решается или так или никак. ИМХО уж лучше что- то чем ничего.
Наверное зря я встреваю, но VLC — тормозное корявое уродство, которое лучше mplayer2 только в том, что может играть BD и DVD диски без танцев с бубном, а от Qt там только морда, да и ту можно заменить. У них даже такой популярный декодер как h264 работает ощутимо медленнее при одинаковом способе вывода видео и одинаково отключённой постобработке (проверял на первых 5 минутах hi10 1080p Time of Eve, который из-за hi10 невозможно пустить через аппаратный декодер). Я лучше .mplayer/conf в gedit подправлю, чем ещё раз взгляну на форму настроек VLC. А ещё VLC часто не способен выводить свой же собственный интерфейс управления поверх видео при gl выводе видео если оконный композитор работает без графического ускорителя (metacity, например), а сама попытка его вывести выглядит ужасно и тормозит воспроизведение.
Так что отсутствие VLC в системе это скорее плюс.
Вы просто неумеете готовить vlc
> Вы просто неумеете готовить vlcСтранно, при этом я очень быстро и без проблем научился готовить mplayer, у которого вообще нет морды. Правильно приготовить VLC ещё сложнее? Тогда он точно не нужен.
Значит не научились готовить VLC
> Значит не научились готовить VLCДа-да, его нужно дольше и усерднее варить, а потом таки выкинуть. Я уже понял, спасибо. Два дня его мучил когда последняя версия выходила и ещё штук 5 предыдущих версий пробовал когда они выходили. Так и не приготовил ни одну. Чёрт подери, mplayer проще приготовить чем это недоразумение. Видеоплеер, который можно не суметь приготовить, ну надо же! Может мне курсы по приготовлению VLC где пройти? Наверное этому где-то учат, а я и не знал…
Да, кстати, а ещё у него откровенно плохой движок субтитров. Он, конечно, красиво рисует srt-субтитры (чисто текстовые) так-как рисует их не в видеопотоке, но когда дело доходит до ssa/ass, то ему наступает этот самый ass и он начинает лажать на трансформациях, рисуя субтитры где угодно, только не на своём месте и не под нужным углом из-за чего локализованные надписи торчат под самыми немыслимыми углами и передвигаются по совершенно непредсказуемым траекториям если им было указано передвигаться. Особенно это ярко выражено когда размер картинки не пропорционален размеру дисплея.
> Наверное зря я встреваю, но VLC — тормозное корявое уродство,Извините что встреваю, но архитектура у VLC достаточно нормальная, более того, кутевый там аж 1 плагин морды, а морд у него есть более одной. Но вон тот ламак сверху видимо не особо разбирается в архитектуре VLC и поэтому полагает что куть прибит гвоздями. Ну если б его он писал - оно бы так и было. Но к счастью в природе есть и более разумные программисты.
Вот только при всей его нормальной архитектуре оно работает медленнее mplayer и портит субтитры, а до недавних пор портил и картинку. И его стандартная морда на Qt тут вообще ни при чём, написанный чисто на Qt Clementine — очень даже удобный аудио-плеер, например. Но VLC всегда был хуже всех известных мне плееров. Лет 5 назад, когда я ещё использовал винду, я думал что он хоть в Linux лучше остальных… но нет, он и в линукс такой же. Был и остался до сих пор.
Аналогичные отношения у меня с этим vlc. Тоже на винде не понимал его. А перешёл не так давно на Linux — встал вопрос выбора: mplayer2 vs vlc. Понял, что и тут его понять мне трудно, хоть и пытался честно. Настроек море, а пользоваться не удобно.Когда же я обратился к vlc с моими любимыми аниме, я понял, что мне теперь нужно сломать голову, чтоб понять, как в нём к видео прикрутить внешнюю аудио-дорогу, ибо аниме почти никогда с вшитым переводом не идёт, да и перевод не один как правило, и все любительские, из которых выбирать надо. Когда голова таки треснула, я нашёл как это всё сделать. Сделал. Запустил видео. Выбрал прикрученную дорогу, и... И не осталось в моём лексиконе незадействованной матершины. Ибо звука я не услышал вообще. А вместо видео я стал видеть фоторамку какую-то из изредка обновляемых кадров моей любимой Лапуты.
Пробовал разные дороги, пробовал разные видео — один и тот же результат.Я наверно тоже повар плохой. Поэтому: sudo pacman -R vlc
Осталось научиться пользоваться mplayer2 без SMPlayer (вроде вы как-то умеете, если я правильно понял).
Рецепт: https://dl.dropbox.com/u/11450709/mplayer-config
Качаешь, помещаешь в папку ~/.mplayer/ под именем config.
Открываешь в gedit или что у тебя там в качестве редактора.
Подстраиваешь под себя. В частности секции Speedup, Video и Audio. Найди какое-нибудь аниме в 1080p (желательно много графического шума или экшена, Time of Eve или Madoka подойдут) и убедись, что не тормозит с выбранным vo, lavdopts и прочими настройками.Возможно тебе придётся подправить конфу для работы с внешней аудиодорожкой — я смотрю с сабами. Имя сабов и/или дороги должно совпадать с именем видео исключая расширения. Т.е. если видео называется Laputa_Castle_in_the_Sky_(1920x1038_Blu-Ray_FLAC).mkv, то аудио должно именоваться как-то вроде Laputa_Castle_in_the_Sky_(1920x1038_Blu-Ray_FLAC).mp3 или .ru.mp3 вместо mp3. Главное, чтоб имя до последней точки совпадало.
Если будет тиринг — раскомментируй double=yes. Если не поможет (кстати, иногда приводит к тормозам) — изучай как форсировать вертикальную синхронизацию на уровне системы. В том же compiz есть галочка V-Sync в настройках, в настройках закрытых видеодров тоже есть аналогичный пункт.
После этого указываешь нужным тебе файлам открываться через mplayer (в Nautilus это в свойствах файла, например). Пользуешься.
И заранее выучи основные хоткеи. :)
q = выход (если не срабатывает — у тебя русская раскладка активна, переключи)
space = играть/пауза
← и → = перемотка, есть и другие варианты перемотки
Shift+1/2 = назад/вперёд по главам (mkv)
Shift+3 = сменить аудио
Shift+J = сменить сабы
( и ) = громкость
Ого! Спасибо огромное!
Сдул это всё себе в Evernote. Буду пробовать :)
>> наколенностью по очевидным причинам.
> По каким это? Помоему эти причины очевидны только для Вас.Нет, они очевидны не только для меня. Для тех кто в танке, информирую: при нормально организованном процессе разработки кодинг может быть вообще не самой ресурсоемкой частью проекта. Хотя, конечно, господам забивающим на продумывание архитектуры и вместо этого переписывающим все по 5 раз до того как оно хоть как-то поползет это сложно понять. Потом рапидчик не менее эпично забивает на баги и отладку, что при нормальном подходе может занять еще более дофига. А возможность быстро навалить тонну кода все только усугубляет. Поскольку вывалить какой-то хлам, который вроде бы работает - это еще не синоним качественной программы.
Яркий пример: metasploit framework. Громкое название. Модный Ruby. Кода - прорва. Фич вроде много. Есть только одна незадача: этот ШИТ насквозь кривой и бажный. Он падает через раз в зависимости от пятен на солнце, глючит постоянно и срабатывает через раз. По поводу чего на него вообще нельзя полагаться например для автоматических проверок своей сети. Как максимум столь крЮтая на вид тулза годится только для долбежа скрипткидями сервака соседа по парте. Вот к чему-то такому рапидная разработка обычно и приводит. Это лишь типовой образчик, из того что недавно под руку попадалось.
"Любую задачу можно решить быстро, качественно и дешево. Выберите любые 2 из этих 3-х".
> Я еще помню подобные дискуссии на тему C/C++ vs assembler. Сторонники последнего
> по Вашей же логике назвали бы Вас именно "и хочет скорей-быстрее тыр-пыр результат"...У ассемблера есть один крупный недостаток: все наработки на оном аннулируются при смене архитектуры. Вот это - очень неприятное свойство. Тогда как си и си++ к платформе не привязаны. Тем не менее, иной раз на сгенеренный севым компилером код без слез не взглянешь. Поэтому до сих пор в критичных местах вставки на асме практикуются. И да,
> Ваше право. Тогда, если я не ошибаюсь, как минимум VirtualBox
Действительно. У меня KVM есть. Зачем мне какой-то сторонний левый виртуализатор?
> и VLC не для Вас.
VLC не является программой вокруг Qt. У него есть деление на ядро и плагины, так что UI формируется плагином. Qt-вая морда - лишь одна из возможностей. Но есть и несколько иных морд, вообще никак не завязанных на Qt. Так что если не нравится кутевая морда - ее можно и не ставить, а вместо нее поюзать иные морды. Их есть. Вот это да, нормально наархитекченная программа, где вообще ничего не прибито гвоздями и по этому поводу оно довольно кроссплатформенное и легко адаптабельное к чему угодно. Кому надо - могут хоть для EFL гуй ему писать. Если оно надо.
>> наверное не захотите питаться в ресторане где вместо шеф-повара будет случайно
>> отловленный на улице дворник. Первый попавшийся.
> Правильно. И на домашних кухнях у всех кастрюли отобрать! Дабы не лезли
> со своими гoвноблюдами в кулинарию.Так это... одно дело если дома, а другое - если вы на улицу претесь и в рестораны. Если ваши программы попадаются мне - вероятно, вы уже не у себя дома. И вы не знаете, почему это например санитарные нормы для общепита есть? :)
> Так ищите нормальную с Вашей точки зрения альтернативу. Или создайте.
Ну вот на отсев всякого д-ма уходит масса времени и сил. Почему я должен питать симпатии к тем кто это дэмо генерит?
> Вполне возможен вариант что задача решается или так или никак.
Такой расклад редок как снег в пустыне Сахара.
> ИМХО уж лучше что- то чем ничего.
Обычно такими заявами прикрывают халтуру и криворукость.
Бред несешь.
Дениска хватит тролить, коли болдженос не взлетел
Glade даст вам редактор формочек. Текстовый редактор, компилятор/интерпритатор - по вкусу.
Как пример (примитивный и далеко не лучший, но все-же)- убунтовский Quickly http://developer.ubuntu.com/get-started/
Спасибо за ссылочку. Видео посмотрю. Кстати, он только питон поддерживает или и C/C++?
>Лучше бы кнопок новых побольше да покрасивше добавили.А в других местах тулкита всё по-твоему уже допилено, да?
>>Лучше бы кнопок новых побольше да покрасивше добавили.
> А в других местах тулкита всё по-твоему уже допилено, да?Допилили бы в "других местах", забив на "эти", пришёл бы другой Аноним со своим "ненужно".
А надо сразу запиливать так, чтобы здесь ни одного праздного анонимуса не шаталось с ихним Ненужно.
Да это вообще походы сарказм был
>Лучше бы кнопок новых побольше да покрасивше добавили.Добавят! И побольше, и покрасивше. :)
> GTK+ спроектирован для поддержки не только C/C++, но и других языков программирования, таких как Perl и PythonХм, а что именно там есть, что учитывает перл/питон? Или это завуалированный gobject-introspection? Тогда не столько GTK, сколько Glib и не столько perl/python, сколько любой язык.
"других языков программирования" = "любой язык"
"таких как Perl и Python" - просто уточнение.
> "таких как Perl и Python" - просто уточнение.Лучше бы они кактус съели вместо таких уточнений.
