Программизм

хмм.. а у меня единожды прописан профиль в настройках менкодера для этих целей.. и все отлично работает: mencoder -profile pocketpc futurama.benders.big.score.anivcd.avi -o futurama.benders.big.score.anivcd.ppc.avi

И вуаля.

Нормальный скрин.

>всех приходящих к нам с желанием устраиваться на работу непременно спрашиваю о языках, изученых for fun

Всё, что знаю, учил for fun. Ещё бы Haskell выучить...

>а у меня единожды прописан профиль в настройках менкодера для этих целей

С такими методами вендекапца можно долго ждать

> П.С. рискую нарваться на кучу грязи в свой адрес, но по-моему вид кода на питоне отвратителен :)

По сравнению с C++? Адрес дилера?^W^W Ладно, тогда используй термин "короче".

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

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

>Ещё вопросы?
>Stalwart *** (*) (22.11.2007 23:46:30)
>

Куда пропал Добер?? BSDobermann с канала irc.lv? :'(

хм. и почем купите человека знающего тикль? (вероятно единственного в рассее, умеющего писать на tcl/gtk+2 =)

Тебе бы с автором smplayer скорешиться, у него планы есть в будущем дописать свою прогу целиком использовать возможности проигрывания mplayer. А потом дополнительно написать прогу использующего все возможности mencoder.

Пиздец, да ты крут и респект тебе охуенный. Ты выучил как программировать С++ на. Ты темную силу почти-что постиг... Но лучше убейся о стену с разбегу, чтобы не смущать умы дилитантов!

> хм. и почем купите человека знающего тикль? (вероятно единственного в рассее, умеющего писать на tcl/gtk+2 =)

увы, москва от нас далеко :)

>Пишу гуёвый видеоконвертер для тех, кому лень читать man mencoder (вкл. себя любимого).

Тех, кому лень читать manы, вообще к компьютерной технике нельзя подпускать. Эти зверушки должны заниматься чем-нибудь несложным...

лень, не лень... вот ты например болванки из консоли пишешь или из k3b и т.д.?

Не трудись... уже давно есть - iriverter !!! делает тоже самое ! посмотри его http://iriverter.thestaticvoid.org/

Он на жабе написан - слишком много ресурсов жрет.

> и редакторов VIM оказался наиболее удобным

Мда...

acidrip fork? ;-)

На irc.lv давно не сижу, а Добер недавно в галерее засветился с емаксом

Мне не целиком надо, а максимально просто

>чего непонятного? lester-dev - заголовочный пользователь пользователя lester :)

/me засегфолтился

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

А нужно ли тут сообще наследование? Рисовалка графиков/диаграмм для Tk есть, и очень мощная: vtk. Ну а другого применения наследования, кроме виртуальной функции Draw() я не вижу.

>> Гуебёртки на C++ — что за наклонности? Чем вызван такой выбор?

> c++ в сочетание с qt даёт кучу возможностей + полная кроссплатформенность.

У меня psi(которая писана на qt3) на arm сегфолтится. А вот tk-шные гуеподелки работают.

Кроссплатформенность плюсов тянет за собой ещё и необходимость полных тестов на каждой платформе, в т.ч. на таких неприятных как arm и sparc, где несложно напороться на misaligned variable.

>По сравнению с C++? Адрес дилера?^W^W Ладно, тогда используй термин "короче".

Специально сравнил. Принципиальной разницы не увидел. Что там, что тут - везде куча текста. Вот только если делать на с++, то зависимостей будет явно меньше не говоря о скорости загрузки и т.п. Короче, в данном случае "красивость" языка особой роли не играет.

> У меня psi(которая писана на qt3) на arm сегфолтится. А вот tk-шные гуеподелки работают.

А что, разве psi использует только возможности qt3? Там куча других библиотек в зависимостях. Имелась ввиду программа, использующая только qt-шные классы.

>А нужно ли тут сообще наследование? Рисовалка графиков/диаграмм для Tk есть, и очень мощная: vtk. Ну а другого применения наследования, кроме виртуальной функции Draw() я не вижу.

Слишком близко смотрите. Наследование позволяет добавить новые функции, не только переопределение virtual void draw().

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

Ого!!! Тут все такие гуру программирования!!! Конечно Qt и GTK в помойку, и вообще весь гуи нафиг! Да и linux туда же, будем сидеть под DOS и писать на basic!!!

>> У меня psi(которая писана на qt3) на arm сегфолтится. А вот tk-шные гуеподелки работают.

> А что, разве psi использует только возможности qt3? Там куча других библиотек в зависимостях. Имелась ввиду программа, использующая только qt-шные классы.

Я могу на чистом C выдать misaligned variable. Типа такого(на арме точно вылетает):

char c[100]; int a=*(int*)(c+5)

> нужно - есть еще получение минимальных/максимальных/статичных размеров, генерация XML для возможного отображения через XRC, создание и обработка списка параметров для каждого компонента и т.д.

Где здесь рулит qt или c++?

Все возможность ооп есть в itcl. Вывод в xml тоже имеется. Список параметров - ну это вообще делать на плюсах геморройно, особенно если есть интерфейс с пользователем(приходится таскать qvariant, а если используются свои типы данных, то геморрой увеличивается).

в tk есть grid, просмотр html, что-то вроде wxAuiNotebook, сайзеры, такой-же набор утилитных классов как в wx и qt ( работа с архивами, изображениями, БД, FTP, HTTP, печать на принтер ), работа с гуи в отдельных потоках и т.д. и т.п.?, против языка я ничего не имею - так как не видел его, но при создании морды к программе мне проще опираться на готовые виджеты и классы, чем искать сторонние либы или рисовать все самому, если там все это есть, то на днях попробую разобраться

> в tk есть grid,
tktable

> просмотр html,
есть, http://wiki.tcl.tk/2335

> что-то вроде wxAuiNotebook,
что это?

> сайзеры,
не понял.

> такой-же набор утилитных классов как в wx и qt ( работа с архивами, изображениями, БД, FTP, HTTP, печать на принтер ),
БД есть(как минимум oratcl),
Принтер вроде есть,
ftp, http есть.
Архивы - не видел. Но заюзать родной для формата архиватор никто не мешает.

> работа с гуи в отдельных потоках и т.д. и т.п.?,
Многопоточность есть, про многопоточный гуй не знаю. Кстати, в qt гуй однопоточный.

> при создании морды к программе мне проще опираться на готовые виджеты и классы,
Гуй должен быть простым. А втягивание в него кучи левых компонент приводит только к непомерному усложнению.

> чем искать сторонние либы или рисовать все самому
Не сказал бы, что либы уж настолько сторонние, в основном всё перечислено на http://tcl.tk .

>Я могу на чистом C выдать misaligned variable. Типа такого(на арме точно вылетает):

>char c[100]; int a=*(int*)(c+5)

А можно кое-что прищемить..... Ваш пример у меня не вылетает, следовательно надо искать баг в компиляторе. Вот только приходилось решать задачи более серьёзные и не разу к такой конструкции прибегать не приходилось, а уж для написания гуишной морды - тем более.

> что это? notebook откуда можно отцеплять табы или разбивать и группировать табы

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

http://st1.risunok.net/23584/Bezymyannyy.PNG

насколько сложно такое наваять под tcl/tk? хотя вобщем заинтриговали - посмотрю

> Ваш пример у меня не вылетает

Подозреваю, что данные не совсем верны.

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

А зачем вообще для написания быдломорды использовать C, C++, Pascal, да вообще какой угодно компилируемый язык?

Я привёл пример, как легко можно наглючить, не вылезая за пределы языка даже без использования qt. И не надо говорить мне про двери и невозможность написания такого кода! Программа(psi) вылетает => какой-то подобный баг в ней есть, притом, что абсолютна та же версия без проблем работает на amd64 и i386. А гарантией отсутствия такого бага могут служить только полные тесты на всех поддерживаемых архитектурах.

>> что это?

> notebook откуда можно отцеплять табы или разбивать и группировать табы

> насколько сложно такое наваять под tcl/tk?

Точно не знаю, но возможности оперировать деревом виджетов (которая есть) вполне должно хватить.

А в вашем %%% qtconfig на выбор 6 стилей Мотиф, Мотиф, Мотиф-SGI, Windows и Platinum. Ни один даже отдаленно не напоминает требуемое. Установить новые стили невозможно, так как по зависимостям вылезает kde. Qtcurve завставляет GTK подражать кошмарному виду qt, а надо ровно наоборот: управление цветом и видом qt из GNOME, без всяких левых приблуд.

> Установить новые стили невозможно, так как по зависимостям вылезает kde.

Тулкито- и DE-фобии сейчас лечат.

Советую написать в багзиллу своего дистра, что они пи###асы и пусть отделяют qt-шные стили от того, что на них свержу навешали kde-шники. Вроде бы там надо просто файлы на 2 пакета разбить, т.к. кдешная часть - это всего лишь модули для центра настройки.

> Вроде бы там надо просто файлы на 2 пакета разбить

Вру. Для стиля lipstik я нашёл ссылку на одну кедовскую либу(libkdefx.so.4). Так что требуйте отделения её от kdelibs, и будет Вам счастье в виде тем для qt без необходимости вытягивать kde.

> А зачем вообще для написания быдломорды использовать C, C++, Pascal, да вообще какой угодно компилируемый язык?

а почему нет? Какие преимущества я получу? Конечно программисту может быть удобней, вот только тормоза для пользователя будут заметны. Т.к. время компиляции или парсинга кода в любом случае конечно, не лучше ли его затратить один раз? И если разобраться, то большая часть программ в составе того же ненавистного kde является "быдломордами".

> Я привёл пример, как легко можно наглючить, не вылезая за пределы языка даже без использования qt. И не надо говорить мне про двери и невозможность написания такого кода! Программа(psi) вылетает => какой-то подобный баг в ней есть, притом, что абсолютна та же версия без проблем работает на amd64 и i386.

При написании "быдломорды" можно обойти использование платформо-специфичных функций. А psi - это далеко не быдло-морда.

> А гарантией отсутствия такого бага могут служить только полные тесты на всех поддерживаемых архитектурах.

Правильно в любом случае, т.к. нет ни какой гарантии, что вындовая версия того же питона имеет не содержит какие-либо багофичи.

>> А зачем вообще для написания быдломорды использовать C, C++, Pascal, да вообще какой угодно компилируемый язык?

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

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

> Т.к. время компиляции или парсинга кода в любом случае конечно, не лучше ли его затратить один раз? И если разобраться, то большая часть программ в составе того же ненавистного kde является "быдломордами".

У меня стойкое ощущение, что k3b, как самая сложная морда из состава kde, только выиграет от того, что будет переписана на tk. Пропадут и сегфолты(вернее, заменятся на bgerror) и работать станет побыстрее.

Есть только несколько типов программ, для которых использование компилируемых языков для гуя оправдано: игры(кроме логических), графические редакторы(гимп) и рисовалки графиков(gnuplot).

>> А гарантией отсутствия такого бага могут служить только полные тесты на всех поддерживаемых архитектурах.

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

Но это будет уже не ошибка в моей программе, на так ли? Правда с точки зрения пользователся всё едино.

> При написании "быдломорды" можно обойти использование платформо-специфичных функций. А psi - это далеко не быдло-морда.

И в каком месте в psi используются платформенно-специфические функции? psi есть быдломорда для XMPP.

>У меня стойкое ощущение, что k3b, как самая сложная морда из состава kde, только выиграет от того, что будет переписана на tk. Пропадут и сегфолты(вернее, заменятся на bgerror) и работать станет побыстрее.

Такая штука уже есть - называется TkDVD - делает то же самое, что и K3B - только быстрее.

> Удобней программисту - удобней пользователю.

Далеко не факт. Программисту удобнее вообще не писать и баги не вылавливать, а вот пользователю сидеть с багами хреново.

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

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

> У меня стойкое ощущение, что k3b, как самая сложная морда из состава kde, только выиграет от того, что будет переписана на tk. Пропадут и сегфолты(вернее, заменятся на bgerror) и работать станет побыстрее.

Далеко не факт. В первую очередь это скажется на скорости загрузки, т.к. что бы распарсить такое количество кода надо время. И какая принципиальная разница между сегфолтом и bgerror?

> Есть только несколько типов программ, для которых использование компилируемых языков для гуя оправдано: игры(кроме логических), графические редакторы(гимп) и рисовалки графиков(gnuplot).

+ программы работающие с железом + программы, использующие библиотеки по обработке мультимедиа + программы, использующие большое количество сторонних бибилотек (на все библиотеки биндингов не напасёшься) и т.д. Короче 95% не менее.

> Но это будет уже не ошибка в моей программе, на так ли? Правда с точки зрения пользователся всё едино.

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

>Такая штука уже есть - называется TkDVD - делает то же самое, что и K3B - только быстрее.

Выставляет завышенную скорость работы?

> Принтер вроде есть

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

> И в каком месте в psi используются платформенно-специфические функции? psi есть быдломорда для XMPP.

А почему морда? Это уже не морда, т.к. линкуется с данной библиотекой. С таким успехом можно сказать, что все программы, являются мордой к glibc. А платформо-зависимые функции там есть, раз оно ведёт себя по-разному. Например та же exp10 .

>> Кстати, я не думаю, что на сегодняшний день tk-шный гуй заметно тормознее qt-шного. Даже скорей наоборот.

> Конечно, гораздо проще нарисовать квадрат, чем фигуру сложной формы. Гуй от win 3.11 тоже быстрый.

98% гуйков в сложных виджетах не нуждаются

>> У меня стойкое ощущение, что k3b, как самая сложная морда из состава kde, только выиграет от того, что будет переписана на tk. Пропадут и сегфолты(вернее, заменятся на bgerror) и работать станет побыстрее.

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

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

> И какая принципиальная разница между сегфолтом и bgerror?

В том, что bgerror ловится и обрабатывается catch-ем. Более дружелюбно к пользователю показать сообщение "ёб-с, что-то упало" и потом завершить работу, чем просто выдать в stderr(который в случае гуепрограмм обычно и не отображается) segmentation fault.

> + программы работающие с железом + программы, использующие библиотеки по обработке мультимедиа + программы, использующие большое количество сторонних бибилотек (на все библиотеки биндингов не напасёшься) и т.д. Короче 95% не менее.

Странные цифры. Мне кажется, что Вы забыли, что рассматриваются гуепрограммы, а не все программы.

> Но это будет уже не ошибка в моей программе, на так ли? Правда с точки зрения пользователся всё едино.

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

Список платформ можно сократить. Например, в случае k3b на tk можно протестировать с tk8.4 и tk8.5 на linux, window$ и solaris и поверить авторам tk и cdrecord, что в остальном в рамках одной ОС всё работает. Конечно, можно протестировать _все_ возможные варианты, но это требует огромных затрат. Именно поэтому никто из проприетарщиков не поддерживает gentoo.

>> И в каком месте в psi используются платформенно-специфические функции? psi есть быдломорда для XMPP.

> А почему морда? Это уже не морда, т.к. линкуется с данной библиотекой.

непонятно

> А платформо-зависимые функции там есть, раз оно ведёт себя по-разному. Например та же exp10.

Хм, а зачем в мессенджере exp10?

Быстрее GUI работает - запускается быстрее - вообщем самая натуральная морда для мощных консольных программ.

> 98% гуйков в сложных виджетах не нуждаются

Это как сказать, например тот же QWidget в qt не такой уж простой. А то, что вся эта сложность потрачена на обеспечение look&feel - это уже другой вопрос. Если бы сишная программа была с простым интерфейсом, то она просто летала бы.

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

Но всё равно их будет больше, чем исполнение готового бинарного кода.

> В том, что bgerror ловится и обрабатывается catch-ем. Более дружелюбно к пользователю показать сообщение "ёб-с, что-то упало" и потом завершить работу, чем просто выдать в stderr(который в случае гуепрограмм обычно и не отображается) segmentation fault.

В с++ тоже есть конструкции try{}, catch{}, assert() и отладчик, например gdb. Вот только первое не часто используются. А в Qt для отображения ошибки есть куча консольных и гуишных функций. Вот только ими тоже ни кто не пользуется, т.к. для пользователя скорость важнее. Да и тот же ненавистный k3b можно собрать с ключём --enable-warnings и посмотреть из-за чего оно упало.

>Список платформ можно сократить. Например, в случае k3b на tk можно протестировать с tk8.4 и tk8.5 на linux, window$ и solaris и поверить авторам tk и cdrecord, что в остальном в рамках одной ОС всё работает. Конечно, можно протестировать _все_ возможные варианты, но это требует огромных затрат. Именно поэтому никто из проприетарщиков не поддерживает gentoo.

В общем затраты в любом случае будут те же.