У тебя смешной баттхерт) И смени уже аватарку, а то гадость на ней какая-то изображена.

Слив зовёт

Linfan, http://stoplinux.org.ru/forum/viewtopic.php?pid=74964#p74964 - слив защитан!

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

>Ждем анонс с векторной графикой и анимироваными иконками.

Ждите )))

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

Должна же быть психологическая поддержка публики )

>У тебя смешной баттхерт) И смени уже аватарку, а то гадость на ней какая-то изображена.

Осиль хотя бы регистрацию на ЛОРе. А то так и останешся неизвестным меганачальнегом ;)

> Осиль хотя бы регистрацию на ЛОРе.

Это аргумент толстых зеленых и полных задротов. Для трехзвездочных не канает.

P.S. Ушел смотреть авишку sK1-reloading.

> Должна же быть психологическая поддержка публики

У публики имеются некоторые стереотипы. И некоторые из них могут быть вполне обоснованы :)

>Это аргумент толстых зеленых и полных задротов. Для трехзвездочных не канает.

Ночальнег, изживай в себе лурковский лексикон - палишься, однако :)

> Осиль хотя бы регистрацию на ЛОРе

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

> Ночальнег, изживай в себе лурковский лексикон - палишься, однако :)

Ночальнег

*facepalm*

>У публики имеются некоторые стереотипы. И некоторые из них могут быть вполне обоснованы :)

Бывает :)

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

У всех свои недостатки :)

> Ночальнег, изживай в себе лурковский лексикон - палишься, однако :)

Ваще-то я другой анонимус. В моем лексиконе «начальник» почти отсутствует. Про лукр (или лурку) читал только на ЛОРе (или это ты про про лукмор, на который дает ссылку гугл при поиске толкования разного интернет-сленга. Так если бы в сети не было бы сраного сленга, то и лукмор был бы не нужен, а луркой я его не называю).

Ну вот и замечательно :) Прекращаем из пустого в порожнее переливать. А то просто праздник какой-то устроили :)

> Бывает :)

При этом у девелоперов также могут быть некоторые стереотипы ;) Причем некоторые из них могут быть ошибочными ;)

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

> И лопатой выгребать косяки в локалях, отличающихся от en_US.

То-то я в NetSurf (GTK) в строку поиска не могу ввести ничего, переключив раскладку на отличную от английской, а dillo3 (FLTK) не имеет с этим проблем.

> То-то я в NetSurf (GTK)

Господи, где ты это откопал вообще?

Нет ничего невозможного :)

>а то, что уже 13 лет в Линуксе нет вменяемого аналога CorelDraw - никого не волнует, никому не надо, как и Линукс...

Как известно из экономической теории, при нулевой цене на товар спрос максимален при нулевом предложении.

>Inkscape же аналог CorelDraw.

Тоже его использую и LO (OO) Draw - вполне устраивает, если не считать неприятных глюков при печати, которые видимо относятся к Линуксу в целом, а не коннкретно к этим программам.

>Это фэйл. Ждем очередной перезагрузки, когда наконец дойдет что Qt - это не только UI, но и замечательный набор качественных классов на все случаи жизни. А из GTK+ не выжать большего, чем инкскейп.

+1 :)

>С++? Это затормозит разработку - кода в несколько раз больше.

Это что-то новое! Вообще-то С++ и ООП придумывались как раз затем, чтобы ускорить разработку, особенно поддержку и расширение.

Поищите самостоятельно сравнения сложных имплементаций C++ vs Python. Код на Питоне в разы компактнее.

>Поищите самостоятельно сравнения сложных имплементаций C++ vs Python. Код на Питоне в разы компактнее.

Ну ты ж не на питоне уже пишешь. А код на Qt в разы компактнее vs GTK+ - и примеров тому полно.

>Ну ты ж не на питоне уже пишешь. А код на Qt в разы компактнее vs GTK+ - и примеров тому полно.

Ну тогда внимательно перечитай сабж, раз не в теме :)

На ЛОР-е в теме про легковесные браузеры сослались.

> Ну ты ж не на питоне уже пишешь.

~/soft/src/print-design-read-only$ ls src/pdesign
actions.py app_conf.pyc dialogs __init__.py mainwindow.pyc palette.py proxy.pyc toolbar.py widgets
actions.pyc application.py eventloop.py __init__.pyc menubar.py palette.pyc resources toolbar.pyc
api.py application.pyc eventloop.pyc inspector.py menubar.pyc presenter.py share tools.py
api.pyc clipboard.py events.py inspector.pyc modes.py presenter.pyc statusbar.py tools.pyc
app_conf.py clipboard.pyc events.pyc mainwindow.py modes.pyc proxy.py statusbar.pyc view

От оно чё!

> Прекращаем из пустого в порожнее переливать.

Ок, давайте по делу.

Посмотрел кусок презентации. То, что сменили название проекта - это клево, новое название лучше.

1. GTK - это очень плохо для вашего приложения. Поясню. PrintDesign проект для (не знаю, как точно назвать) графических дизайнеров. Т.е. людей, которые ориентируются на приличный вид готового продукта, но не только. Инструмент дизайнера тоже обязан хорошо выглядеть. А GTK программы смотрятся везде ущербно, кроме, Ubuntu и, возможно, других дистибутивов, где главный DE - Gnome. Qt программы смотрятся гораздо лучше в любых условиях. Поэтому, делать приложение для профессионалов-технарей, возможно, музыкантов, которое выглядит внешне «не очень» вполне обосновано. Но никакой дазайнер не станет использовать инструмент, при виде которого начинает тошнить (а при работе дизайнера в KDE ваш PringDesign будет полным убожеством).

Короче, GTK приложения страшные и для дизайнера это фатальный недостаток.

2. Вы сказали, что-то типа, QPainter входит в состав QtGUI, поэтому, не очень удобно, что UniConvertor будет его использовать в консольном режиме. Этого я совсем не понял. Вы переживаете, что консольная программа будет линковаться с libQtGUI.so, которая в свою очередь потянет libX.so? На десктопе они и так будут установлены. На моем сервере они тоже есть и мне на это наплевать. Я не понимаю, о чем вы тут беспокоитесь? О психической травме параноидальных админов, которым придется установить libX на сервер (где зачем-то нужен будет UniConvertor) или о времени запуска UniConvertor? По мне так наплевать на то и другое, потому что в данном случае и то и другое оправдано.

Где можно узнать, каким образом вы зарабатываете деньги на ваших опен сорс проектах? Можете вкратце рассказать?

>Ок, давайте по делу.

5!

> В векторной графике из Qt тоже много не выжмешь - это библиотека общего назначения. В этом плане пофиг на каком тулките писать.

В Qt за один только QString и аналитическую передачу объектов по ссылке, если передача прописана тупо по значению но объект не меняется, можно разработчиков в жопу расцеловать.

У меня на что на Гноме, что на Винде ГТКшные приложения смотрятся отменно, а вот КуТишные в Гноме часто отвратительны. Да и не много граф. дизайнеров сидят в Линухе, а если и сидят, то чаще всего на дефолтной Убунте. Да и ГТКшные приложения при желании в Кедах смотрятся нативно.

Внешний вид приложения зависит от темы Gtk.

На Linux дизайнер врядли установит слаку. А если и установит, то выберет нормальную, не вырвиглазную тему. Хотя скорее всего возьмет Убунту.

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

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

Касательно зависимостей - если UniConvertor будет завязан на Qt, то никого это не обрадует, а скорее наоборот. На данный момент нет завязки ни на Gtk, ни на Qt. А есть только зависимость от cairo. И это наиболее подходящий вариант. В т.ч. для той же макоси - переписать UI на нативном Cocoa вполне реально и это не потребует массы времени. Конечно если возникнет в этом такая необходимость.

>Где можно узнать, каким образом вы зарабатываете деньги на ваших опен сорс проектах? Можете вкратце рассказать?

Пардон, но финансового стриптиза никто не обещал :)

> С++? Это затормозит разработку - кода в несколько раз больше.

Поищите самостоятельно сравнения сложных имплементаций C++ vs Python. > Код на Питоне в разы компактнее.

Даже если предположить, что «в разы компактнее», чему желательно обоснование (причем статистически достоверное), то «затормозит разработку» из этого совершенно не следует :)

А пользователи пока что всё еще хотят реализацию ПО (видимо это слово Вы имели ввиду под термином «имплементация») на оптимальном по производительности языке.

>В Qt за один только QString и аналитическую передачу объектов по ссылке, если передача прописана тупо по значению но объект не меняется, можно разработчиков в жопу расцеловать.

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

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

Когда ты последний раз видел Скрайбус на винде или маке? :)

> В Qt за один только QString и аналитическую передачу объектов по ссылке... можно разработчиков в жопу расцеловать.

Ахтунг, тамплиеры в треде :)

>А пользователи пока что всё еще хотят реализацию ПО (видимо это слово Вы имели ввиду под термином «имплементация») на оптимальном по производительности языке.

Пользователи хотят _быстро стартующий_ и _шустро рисующий_ редактор. Сишные экстеншины именно это и обеспечивают. А «оптимальный по производительности язык» требуют не пользователи, а труЪ-программеры с ЛОРа ;)

Кароче, я понял.

Вы долго вели разработку sK1 в процедурном стиле. Поэтому вам ближе и понятней GTK/GTK+, чем Qt. Чуствую, на этом и был основан выбор. Потому что если бы вы использовали ООП с С++, вопроса выбора тулкита не стояло бы вообще.

Вы не сделали большого шага в развитии, побоялись, что не потяните проект на Qt и съехали на GTK. И в этом ваша ошибка. А жаль.

Прозреваю: как только появится векторный редактор на Qt, он мгновенно составит конкуренцию InkScape, а потом вытеснет его как недоразумение.

> Пользователи хотят _быстро стартующий_

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

> Прозреваю: как только появится векторный редактор на Qt, он мгновенно составит конкуренцию InkScape, а потом вытеснет его как недоразумение.

:)))))))))))))))))))))))))))))))))

>Вы долго вели разработку sK1 в процедурном стиле. Поэтому вам ближе и понятней GTK/GTK+, чем Qt. Чуствую, на этом и был основан выбор. Потому что если бы вы использовали ООП с С++, вопроса выбора тулкита не стояло бы вообще.

Прочтите все-таки статью по ссылке :) Чтобы не гадать на кофейной гуще, были написаны прототипы на Qt и на Gtk. Кути мощнее, навороченнее, но недостатки общего архитектурного плана + спорные вещи о будущем кути привели к тому, что мы выбрали Gtk. Это касается конкретно нашего приложения и не более того. Вполне возможно, что для иных целей Gtk даже не стоит рассматривать. Но в нашем случае все богатство функционала Qt не нужно, оно просто не используется.

> Пользователи хотят _быстро стартующий_ и _шустро рисующий_ редактор. Сишные экстеншины именно это и обеспечивают. А «оптимальный по производительности язык» требуют не пользователи, а труЪ-программеры с ЛОРа ;)

Си-шные экстеншны - это хорошо :) Требовать чего-либо от девелопера никто ничего не вправе :) Лично я был бы рад, если бы Вы, к примеру, писали на хаскеле (это по части труЪ программеров), если это ускорит разработку и качество продукта :) А рассмотреть варианты и произвести анализ стоило бы. По крайней мере стереотипные заявления о том, что код на С++ в разы больше и его использование вызывает объективно значимое замедление разработки выглядит шаблонно и необоснованно.

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

Спорный вопрос. Пусть его решает целевая аудитория :)

>По крайней мере стереотипные заявления о том, что код на С++ в разы больше и его использование вызывает объективно значимое замедление разработки выглядит шаблонно и необоснованно.

Замечательно! Вот на примере PrintDesign мы и проверим, насколько быстро с нуля удастся воплотить приложение в жизнь. Я же основываюсь на своем опыте и на том, что вижу в развитии Inkscape.

>А код на Qt в разы компактнее vs GTK+

Код на Qt не сильно компактнее кода на GtkMM

Идите уже код писать, ну