Четыре ZCAD`а

Как всегда годно, но давно не тестил.... ничего такого, даже draftsight не ставил. Надо бы что нить начерить в нем для теста.

ИМХО гентушника-сишника о паскале:

Я потратил 2 часа, чтобы собрать doublecmd для того лишь, чтобы посмотреть на него, в результате пришлось править половину исходников и запускается сие чудо только из под lazarus.
Собрать что-либо паскалёвое для arm вообще судя по всему не предстваляется возможным (в fpcbuild сломано всё, что можно, последний раз пришёл к выводу, что он выдаёт кривые нелинкуемые объектники).
В результате не вижу почти никаких отличий паскального СПО от проприетарщины на практике. В исходник особо не заглянешь и не поправишь (точнее, смотришь - а там ЭТО!!!) и все последствия от этого, на своей системе не соберёшь без многочасовых плясок, а то и вообще не соберёшь. Даже с hlsdk меньше возни было.
Хотя возможно другая система сборки и более хорошая организация кода fpc исправила бы проблему.

Я потратил 2 часа, чтобы собрать doublecmd для того лишь

Как тут говорят - кто то там должен страдать))

Вобще да, транковые fpc и lazarus имеют некоторые отличия от релизов и иногда приходится чтото править. Но я бы не сказал что возни больше чем с сишными исходниками - главное поставить и настроить компилятор. Про арм - хз, не сталкивался.

(точнее, смотришь - а там ЭТО!!!)

Тоже самое, вид сбоку - говнокода везде хватает, у меня в том числе. С имхом твоим несоглашусь - мне паскаль больше нравится

Согласен, язык дело привычки, например тяжело воспринимать = для сравнения и begin/end для блоков . Однако тут скорее всего ещё сказывается малая распространённость fpc, из-за чего его на x86 с первого раза не заведёшь - что уж про arm говорить.

Ты что-то очень сильно не осилил. У меня фрипаскалевые штуковины всегда собирались на порядок проще сишных, следствие политики «один фюрер^W компилятор, одна IDE» :)

первое оконо qt+OpenGL рендер, второе qt+рендер средствами qt, третье gtk+рендер средствами gtk, четвертое - привет из офтопика от вайна

Ух-ты. Как так? Отдельно писался гуй для qt, gtk и winAPI?

lazarus позволяет менять свою морду, какую морду у него соберёшь, такая и у приложения будет. Захотел Qt будет qt, захотел gtk будет gtk + насколько помню, можно ещё свой родной fpgui заюзать, ему вообще сторонние либы не нужны :)

а вы не пробовали собирать с Qt 5.x ? - там где-то в 5.3 существенно ускорили рендер средствами Qt через GL (переписали внутренний scenegraph порядком) - возможно - на таком количестве мелких объектов будет существенный прирост по сравнению с 4.8.6 ;)

respect

Нет, гуй один. LCL умеет использовать различные тулкиты, причем это не вывод чегото своего посредством qt, gtk, win32. Это реальные qt, gtk, win32 контролы

не пробовал, в лазаре пока отсутствует биндинг к Qt5, только 4

(переписали внутренний scenegraph порядком)

Это чтото позволяющее организовать «чертеж» средствами qt? Наврятли у меня получится это использовать, в зкаде он свой, а от рендерного бакэнда требуются только функции рисования элементарных примитивов на контексте

пишется на фри паскале.

мусьё знает толк в извращениях

«Безумству храбрых поем мы песню»

Искренне желаю успехов проекту и особенно автору.

а от рендерного бакэнда требуются только функции рисования элементарных примитивов на контексте

может криво выразился - но ускорили именно прорисовку массы мелких примитивов - и именно в бекэнде (ака scenegraph - Qt уже давно на нём - и были тех.изменения между 4.8.х>5.0>5.3(тут особенно)). про биндинги к freepascal - право - не знаю. лишь пытался проинформировать Вас о том, что там может быть что-то достаточно полезное ;)

Я давно жду qt4pas (или он будет qt5pas, хз) использующий плюшки qt5, но как тут уже заметили - сообщество паскалистов маловато будет, всё приходит с большим запазданием((

lazarus позволяет менять свою морду, какую морду у него соберёшь, такая и у приложения будет. Захотел Qt будет qt, захотел gtk будет gtk...

И все как на подбор будут выглядеть как «о господи, что это?!».

Нет, будет выглядеть как нативное приложение (и будет являться нативным приложением). LCL не рисует свои контролы средствами тулкита, а использует стандартные тулкитные.

Улучшил инспетор объектов — сейчас он рисуется более-менее в соответствии с темой десктопа

Очень странные улучшения для CAD.

Все остальное типа работает?

Нескажи, тоже нужно. Переодически тыкаю либрекад - ну нелязя же совсем то без инспектора((

Все остальное типа работает?

Работает то что нужно мне и пользователям. Остального тупо нет или находится в зачаточном состоянии.

Я потратил 2 часа, чтобы собрать doublecmd для того лишь, чтобы посмотреть на него, в результате пришлось править половину исходников и запускается сие чудо только из под lazarus.

Ну, это неправда. Сложности есть только для исходников требующих «нетрадиционную» версию лазаруса или его компонентов, а если всё налажено, то повторные компиляции происходят намного быстрее чем для плюсов да и жрут меньше памяти. Сложная прога на С++ может вообще не собраться и за 4 часа, если не сможешь угадать чего ей не хватает и как это установить в систему ничего не поломав. Причём компиляция лазарусного проекта отлично происходит и без лазаруса, тогда даже бинарник стрипать не нужно. Просто заходишь в проект, копируешь в скрипт опции компиляции (вместо fpcbuild используешь fpc), выбрасываешь опции отладки, добавляешь, если там нет, опции виджета (чтобы бинарник не вздумал линковаться с гтк3 вместо гтк2), прописываешь пути к либам настроенного лазаруса и исходников - готово. Просто разработчики программ на лазарусе обычно не заморачиваются с настройкой автоматизации сборки не требующей лишнего мышкотыкания.

В исходник особо не заглянешь и не поправишь (точнее, смотришь - а там ЭТО!!!)

Наоборот же - заглядываешь в исходники гимпа а там ЭТО!!!, и значит пусть их правят те, кому ЭТО!!! доставляет радость. И со многими С++ программами тоже самое, баги не правятся годами, но лучше немного потерпеть, ведь и так как-то работает, чем разбираться со всеми фичами С++

Хотя возможно другая система сборки и более хорошая организация кода fpc исправила бы проблему.

Тогда тебе дорога в Альтлинукс - там любят вместо 3 пакетов с паскалем делать ~20 чтобы для каждого указывать зависимости персонально, а система сборки, при установленных зависимостях, пишется на баше как указано выше.

насколько помню, можно ещё свой родной fpgui заюзать, ему вообще сторонние либы не нужны

Один недостаток у fpgui имеется - к нему пока картинки не прилепили, а значит приложение будет без нескучных обоев.

Расскажи немного о проекте. Как давно пилишь этот проект? Почему вообще начал? Твоя работа с этим связана?

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

Красибо речешь. Я бы тебе даже поверил, если бы скрин не видел. Там в общем-то все выглядит ненативно, но если хочется очкторого примера, то пожалуйста: то, что слев и справа от слов «Инспектор объектов» вызовет шок у пользователя любого из вышеперечисленных тулкитов.

На кнопках например вроде как картинки есть

Надо будет посмотреть, через что они они туда ставятся.

судя по скриншотам

Если у тебя браузер оттуда грузит https://yadi.sk/d/nZWxv0fhcarML то вот например пакеты - типа личного альтернативного репозитория. Пакет fpgui собран для fpc-2.6.4, если нужен для другой версии, то надо поменять константу в спеке и пересобрать пакет. Ставишь пакет, к модулям паскаля добавляется каталог с модулями fpgui и можно собирать на лазарусе гуёвины с этим тулкитом. Тулкит нормально работает, но вот объект TImage в который обычно грузят картинки, с ним не работает. Поэтому хелловорд смотрится так: ФПГУЙ, ГТК2.

Что там слева и справа? заголовок док окошек?

http://i64.fastpic.ru/big/2014/1109/cb/e34be25d70707bf1f12402f55267e1cb.png так нативней?

Да, док ненативный - чедес небывает. Контролы нативные.

Я qt-фоб, но там точно нет черной рамочки вокруг тулбара и т.п.

По работе я проетировщик КИПиА и тесно связан с автокадом, меня всегда интересовало как оно устроено внутри и по природной лени было большое желание автоматизировать рутинную работу)) Первые потуги в програмировании начались лет 15 назад - генерация всяких рабочих отчетов по выполненым в автокаде чертежам. Пытался освоить автолисп и arx - с первым несложилось изза его убогости, со вторым изза отсутствия документации и человеческого интернета в то время

Кад начал писать году в 2007, сначала в delphi на vcl, потом перевел на winapi. Паралельно стал интересоваться Линуксом и помыкавшись с винапи решил свалить на lcl lazarus чтоб иметь возможность компилять под линукс. Первый комит зкада появился в гдето в 2010. Сейчас гдето в районе 100000 строк кода.

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

Я не програмист и опыта в создании кадов неимею((. Поэтому если нужна какаято фича - тупо ее делаю и по приходу понимания как эта фича должна работать, возможно переделываю красивее\правильнее. Соответственно всё довольно часто кардинально меняется.

Пишу в одиночку, поэтому грязно и без коментариев. Желание начать оформлять почеловечески есть, но побороть лень неможет((

Да, вопреки мнению что в лазаре восновном формошлепают - в зкаде поактически нет формошлепства, интерфейс полностью настраиваемый из конфигов

то что ее там нет незначит что ее нельзя там сделать... Ну сделал я рамку вокруг верхнего тулбара (извиняйте, думал будет красивее) - перестало быть нативней?

то что ее там нет незначит что ее нельзя там сделать

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

Пооткрывай другие программы из состава DE и посравнивай сам.

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

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

Я вот думаю, может мело смысл сделать инспектор объектов обычным деревом с белым цветом фона(или с любым другим светлым)? Интерфейс смотрелся бы более легковесным, менее перегруженным и симпатишным :)

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

Два чая этому господину.

Кстати да, пишу с десктопа на ARM-e. У паскакаля с кросплатформенностью пока беда...

Я не програмист и опыта в создании кадов неимею((.

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

Ну наконец-то скриншот про что-то дельное.

появится в генте попробую

не вижу почти никаких отличий паскального СПО от проприетарщины на практике. В исходник особо не заглянешь и не поправишь (точнее, смотришь - а там ЭТО!!!) и все последствия от этого, на своей системе не соберёшь без многочасовых плясок, а то и вообще не соберёшь.

Моё любимое развлечение с программами на C++ - это собрать программу другим компилятором, не тем, которым у автора. Или просто другой версией компилятора и стандартной библиотеки. Причём никаких извращений типа MFC в этих программах нет. В основном, обычная Qt. Просто есть необходимость собирать программы под несколько принципиально разных платформ.

Так вот, если в каждый файл не включены ВСЕ необходимые ему *.h (а полностью они редко у кого включены), то в зависимости от фазы Луны программа может собраться или не собраться. Ну нет в C++ модульности как элемента языка. А есть только раздельная компиляция и костыли для имитации модульности (тот же #include, в частности). И если один заголовочник прямо или косвенно включает другой, халява может пройти. Если не включает - не пройдёт.

В этом плане современный паскаль с его uses куда дисциплинированнее плюсов. Да и работу линкеру здорово облегчает, ибо после компиляции уже понятно, что откуда брать. Правда, паскаль проигрывает в других вещах...

Так что где больше плясок - можно поспорить. Хотя я последние 5 лет на паскале ничего не писал. У связки Qt/C++ переносимость всё же сильно выше.

Я не говорил, что qt c плюси хорош. Хорош только Си.

Вообще-то, дефект с отсутствием модульности C++ унаследовал именно от Си. Причём в плюсах хоть пространства имён появились.

А классический Си в стиле K&R, где можно было не объявлять прототипы функций - это вообще была сказка в плане труднообнаруживаемых ошибок...

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

а чем оно лучше либрекада, например?

В разы быстрее, чуток фичастей. Фичастей естественно в узких, нужных мне областях, типа наличия трассировок, инспектора объектов, местами более совместим с dxf. В общем и целом водиночку за фичами не угонишся