Вышел Lazarus 0.9.26

Эээм а разве на sdl пишут виджеты? Оно же вродь для 3д графики.

Нужная штука. Лутше уж GUI приложения на паскале чем на каких нибуть скриптовых или java... А то ищещ софт в репозитарий, а там большинсво прог бля на питоне каком нибуть написаны :(

> С другой стороны нет нормального метода сделать форму справочника, чтобы пользователь не видел объекты, помеченные на удаление. Нет возможности сделать собственный класс/объект (пользоваться можно только стандартными). Нет возможности нормальизовать представление в БД, из-за чего база на десять тысяч объектов в справочниках и двадцать тысяч документов занимает пару гигабайт.

И это в 8-ке?

> В этом смысле для учета гораздо удобней, например, Common Lisp (CLSQL позволяет делать отображение объектов на таблицы SQL. любые объекты программы можно обновлять без остановки работы). Но это пока в стадии глубокой альфы (сделал только привязку к GTK2 и каркас справочников для CLSQL)

Когда-то похожее делал на Python+Tk-биндинги. ;) Результат http://img468.imageshack.us/img468/6769/kaabh0.png

> Пожалуйста объясни мне, зачем мне писать GUI на SDL, Perl/Tk, если я могу не парясь набросать его в пределах одного языка и IDE ???????

Затем, что: 1) разные инструменты хороши для разных задач. Тоесть, можна сосредоточиться на решении задачи на том инструменте, который наилучше под нее подходит, а для пользователя выбрать, что больше по вкусу. 2) так, как это сделано в Делфи, где гуй неотрываем от логики (точнее отрываем, но тогда вся их концепция быстрой разработки идет в мусорку) это очень непрактично на хоть немного сложных проектах. За такое надо руки отрывать. По крайней мере я почти не видел кода, где вся логика не в Button1.Click.

А вообще рекомендую почитать Э. Реймонда "Искусство программирования для Unix". Ссылка на русскоязычный перевод есть даже здесь, на ЛОР-е.

Интересно. Совсем недавно была принудительная поддержка utf8 (целесообразность её использования сомнительна, т.к. в старых программах её нет) в linux и её отсутствие в win32. В итоге кроссплатформенность была испорчена. Я пытался сделать патч, позволяющий открывать файлы в разных кодировках, его частично включили, но плохо.

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

Затем и нужны LCL, VCL и прочие CL... Создание кнопки через With TButton.Create(Application) Do ... - это типа офигеть как сложно и неудобно и непрактично?

>2) так, как это сделано в Делфи, где гуй неотрываем от логики (точнее отрываем, но тогда вся их концепция быстрой разработки идет в мусорку)

Откройте для себя ActionList

>По крайней мере я почти не видел кода, где вся логика не в Button1.Click.

Поменьше ползайте по сайтам для новичков и побольше читайте умные книжки про ООП

Не понял о чем речь.

>> 2) так, как это сделано в Делфи, где гуй неотрываем от логики

> Откройте для себя ActionList

OMG. Это -- не отрыв логики от гуя. Отрыв логики от гуя -- это создание логики в отдельном модуле (не в форме), в видеЮ подлежащем модульному тестированию. А будет ли эта логика дергаться через ActionList или через Button.OnClick -- дело уже вторичное.

> Поменьше ползайте по сайтам для новичков и побольше читайте умные книжки про ООП

Ну давай, расскажешь про использование в Delphi ORM?

>>так, как это сделано в Делфи, где гуй неотрываем от логики (точнее отрываем, но тогда вся их концепция быстрой разработки идет в мусорку) это очень непрактично на хоть немного сложных проектах. За такое надо руки отрывать. По крайней мере я почти не видел кода, где вся логика не в Button1.Click.

Собственно, логика, как правило, частично "оторвана" от gui, её реализуют в отдельном(ых) модуле(ях). Модуль, которому сопоставлена форма, предназначен лишь для связывания: он обеспечивает функционирование интерфейса (всякие там исчезновения/появления кнопочек, заполнение списков уже имеющимися данными и т.п.), а для более сложных вещей вызываются процедуры и используются классы из других, "чистых" паскалевских модулей.

> Затем и нужны LCL, VCL и прочие CL...

Одними только библиотеками сыт не будешь. Потому и существуют разные языки. Касательно Делфи, так там и компонентная модель не самая удачная.

> Создание кнопки через With TButton.Create(Application) Do ... - это типа офигеть как сложно и неудобно и непрактично?

В случае делфи, по крайней мере до 7-ки включительно (последняя Д. с которой я работал), неудобно. Из-за отсутствия менеджера геометрии. Якоря не в счет. Для программного создания намного практичней Tk/Tcl или тот же Swing, даже GTK. Снова-таки, Qt-Designer и даже Glade имеют свои плюсы перед конструктором Гуя от Делфи.

> Поменьше ползайте по сайтам для новичков и побольше читайте умные книжки про ООП

Вы тоже читайте умные книжки. Не только по ООП.

ЗЫ. 5 лет стажа на делфи. И ушел с нее не начитавшись ЛОР-а, а сравнив с другими инструментами.

> Откройте для себя ActionList

Тогда уж и ActionManager. Однако это костыли. Настоящего отрыва логики от пользовательского интерфейса они не обеспечивают.

> Собственно, логика, как правило, частично "оторвана" от gui, её реализуют в отдельном(ых) модуле(ях).

1) Это нормальная практика в любом ЯП. Но, вслучае Делфи далеко не всегда. Ибо она провоцирует на написание логики по двойному щелчку на компоненте. И масса такого кода - тому подтверждение. И провоцирует не только на это.

2) А теперь попробуйте подергать этот функционал из совершенно другого ЯП или наоборот.

>Отрыв логики от гуя -- это создание логики в отдельном модуле

Или вообще в отдельном приложении.

Идиот. Это иделогия фирмы MS середины-конца 90-х - GUI на Visual Basic, ActiveX/DLL на Visual C++.

От этого пути она отказалась как от бесперпективного.

А красноглазики продолжают выдавать устаревшие идеи MS за свои новейшие.

>Одними только библиотеками сыт не будешь. Потому и существуют разные языки.

Ну да - делать сайты на VCL неудобно... Или писать скрипты на паскале ^_^

>Из-за отсутствия менеджера геометрии

Так а проектирование гуя в design-time вам зачем? Или от него мы отказывается, потому что так не отделить логику от интерфейса? Не смешно ^_^ Создавать в run-time - что ж действительно, не так удобно, правда не совсем понятно, зачем отказывать от якорей и Align'ов ^_^ С ними жить можно, особливо, если в run-time не нужно заворачивать абсолютно весь интерфейс (а RAD именно в том, что на большую часть внешнего вида сил не затрачивается практически никаких ^_^) Из знакомых мне "неразрешимых" проблем - это плохое масштабирование на различных шрифтах и подобном, но тоже легко решается теми же Align'ами и AutoSize свойствами у виджетов

>5 лет стажа на делфи

Lazarus - это уже не delphi 7 ^_^

>Однако это костыли. Настоящего отрыва логики от пользовательского интерфейса они не обеспечивают.

Хм, они позволяют сохраняя удобство разработки пользовательского интерфейса в design-time передать данные из виджетов "вниз" к обработчиков логики... Не вижу - чего тут костыльного и где теряется "RAD'ность" Lazarus'a/Delphi ^_^

> Идиот. Это иделогия фирмы MS середины-конца 90-х - GUI на Visual Basic, ActiveX/DLL на Visual C++.

1) Это Unix-way, если не знали. Которая цветет и пахнет. А реализаций может быть множество. Начиная от CLI и заканчивая многоязыковыми платформами типа .Net

2) Заметте, мы с вами на "ты" не переходили.

Там был не я ^_^

> Можно глянуть на твои "проги"?
CRM система офтальмологической клиники. тебе такое незачем.

> Вместо небольшого портинга с нуля переписывать? Среди этих "прог" сложнее хелловорда хоть есть?
у меня всё реализовано в виде тонких клиентов. Парсить XML и строить по нему гуй несложно :)

> Ну да - делать сайты на VCL неудобно... Или писать скрипты на паскале

Рад за то, что вы это прочувствовали на практике. Но кроме этих, есть еще много задач, где Delphi/Lazarus непрактичны.

> Так а проектирование гуя в design-time вам зачем?

Например, затем, что множество задач имеют декларативный характер. И интерфейс, неважно какой, удобнее генерировать по декларативному описанию.

> зачем отказывать от якорей и Align'ов

А от них никто и не отказывался :). Я же вам сказал, почитайте о менеджерах геометрии.

> а RAD именно в том, что на большую часть внешнего вида сил не затрачивается практически никаких

Рисовалка формочек, причем посредственная, это никоим образом не RAD. Ведь никто не думает так называть Glade или QtDesigner. RAD - это Rapid Application Development. Тоесть быстрая разработка приложений, а гуи тут сбоку припеку. RAD - это Perl, Python, Lisp, TCL/Tk и т.д. А паскаль или с на RAD не катят, слишком они низкоуровневы, абстракции на них ложаться хуже.

>Не вижу - чего тут костыльного и где теряется "RAD'ность" Lazarus'a/Delphi

Костыль в том, что язык не _заставляет_ выносить логику из обработчиков. А "RAD'ность", как я уже писал, не в том, чтобы гуй набросать и с логикой его связать заключается.

> Костыль в том, что язык не _заставляет_ выносить логику из обработчиков.

Более того, продолжает провоцировать держать логику внутри обработчика.

>Это Unix-way, если не знали.

Нафига в 90% утилит сдалась клиент/серверные примочки с отделением логики от гуя? Ну НАФИГА? Особливо, если утилиту пишут на использовать пару раз в год. Концептуально вообще ничем отработка в OnClick не отличается от отработки в CLI по ключу из коммандной строки. И именно в этом случае легче бросить десять кнопок на форму, таймер и прогресс бар, чем писать парсер опций коммандной строки и большую доку по их использованию. Короче, CLI/Frontend фанатики идут лесом, а остальные работают в меру сил своих.

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

Нафиг такие междумордия, интерфейс должен быть удобен в использовании пользователю, а не в кодировании кодеру - это аксиома. А механистически нельзя создать удобный интерфейс. А то какую прикладу под никсом не запостишь - получаешь диалог в пропорциях 25 к 10... ну где этих горе кодеров учили эргономике??? ГДЕ??? Размер диалога должен быть в пропорциях близких к 4x3; 3x3; 5x3 - а из этого непонимания и непонимания нужд пользователей - получаем популярность системы в районе 1.5% от общего количества.

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

Ага, а особенно "легче" будет тем, кто попытается использовать ваше чудо-приложение автоматически (судя по его десяти-кнопкам, это явно не ERM).

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

>почитайте о менеджерах геометрии

Первое что сделал, как о них услышал ^_^ Первая ссылка в гугле - http://rus-linux.net/lib.php?name=MyLDP/algol/geom_manag.html И, что характерно, первый же абзац явным образом указывает, что необходимость в подобных менеджерах появляется из-за отсутствия возможсности "кнопкобросательства" ^_^ И до кучи - всё (почти что ^_^), представленное в данной статье - элементарно реализуется через панели и Align'ы ^_^ Притом быстро и наглядно...

>RAD - это Perl, Python, Lisp, TCL/Tk и т.д.

0.о Сильно... Даже очень ^_^ В общем, для меня RAD - это возможность не заморачиваться на гуй (мультиплатформенно незаморачиваться, прошу заметить ^_^), удобная навигация по классам, автодополнение, кодогенерация стандартных описаний и т.п. ^_^ Что характерно - особенности IDE, а не языков ^_^ До кучи можно приплести удобные и достаточно полные библиотеки компонент ^_^ Ну и безусловно концепции разработки, никакого отношения к языкам не имеющие, кстати сказать ^_^

>Костыль в том, что язык не _заставляет_ выносить логику из обработчиков

0.о #2 Даже пожалуй не буду комментировать ^_^

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

И дельфи тут обычно чемпион по п.2.

> А механистически нельзя создать удобный интерфейс. А то какую прикладу под никсом не запостишь - получаешь диалог в пропорциях 25 к 10... ну где этих горе кодеров учили эргономике??? ГДЕ???

1) Какой угол зрения у людей по вертикали и горизонтали?

2) Оно там растягивается, ресайзится и сохраняется.

> Размер диалога должен быть в пропорциях близких к 4x3; 3x3; 5x3

Кто сказал, кстати?

> Первое что сделал, как о них услышал ^_^

Уже по количеству смайликов тут всё ясно... :(

> В общем, для меня RAD

Кого должно волновать мнение дельфи-куна?

>Ага, а особенно "легче" будет тем, кто попытается использовать ваше чудо-приложение автоматически

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

Короче, не бывает универсальных инструментов, которые нужно делать по универсальным парадигмам. Есть задачи, в которых нужно непосредственное использование труда оператора. Мало того, есть задачи, где программа является побочным инструментом, а не основным и тратить силы на ее "православное" воплощение никто не будет.

> А если программа для проверки линий связи... провода тоже автоматически будут из разъема в разъем переключаться?

А это уже пользователи решат, не надо думать за них! Дай им инструмент, который они могут использовать по-разному. Как минимум с импортом данных вместо ручного набивания.

>Кто сказал, кстати?

Офтальмологи c биологами

>Кто сказал, кстати?

> Офтальмологи c биологами

Классические, по их мнению, кажется как раз примерно 3:2 и 16:9 (пропорции по углам зрения человека).

Когда заканчиваются аргументы (или когда замечают собственные ляпы ^_~) - начинается агрессия с переходом на личности Т_Т Фи...

> Есть задачи, в которых нужно непосредственное использование труда оператора

Это решит его начальник. А если это решает программист -- он банальный вредитель.

>Кто сказал, кстати?

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

> Какой угол зрения у людей по вертикали и горизонтали?

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

> Когда заканчиваются аргументы (или когда замечают собственные ляпы ^_~) - начинается агрессия с переходом на личности Т_Т Фи...

Какая ещё агрессия? Просто бисера жалко.

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

И причем тут разговор о пропорциях?

> Нафига в 90% утилит сдалась клиент/серверные примочки с отделением логики от гуя? Ну НАФИГА?

Где я говорил о 90% утилит и их связи с клиент/серверными технологиями? О чем я говорил в этом треде, так это о соразмерности инструментов задаче. А выбор технологии зависит от конкретной задачи.

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

1) Даже для делфи уже есть готовые библиотеки, разбирающие аргументы командной строки. 2) для простого дваразавгодичного случая, о которых вы пишите как о 90% утилит с головой может хватить просто взять аргументы по номерам. И вывести usege в одну строку.

> Короче, CLI/Frontend фанатики идут лесом

1) чем так плох CLI/Frontend подход и в каких случаях его использование является фанатизмом? 2) Читать не только умные книжки по ООП. А, например, указанного выше Реймонда. Можно еще и товарищей Кернигана и Пайка.

По-моему, я сейчас наблюдаю пагубное влияние "юникс вея", доведенного до абсурда... :) С чего вы взяли, что ГУЙ должен существовать отдельно от логики? Может, и опции командной строки от логики отделим? ГУЙ, как и командная строка, как и файл конфига - это интерфейс с пользователем, и он не может существовать отдельно от логики программы ПО ОПРЕДЕЛЕНИЮ. "Юникс вей" предполагает разделение программ по задачам, но не отделение программ от их интерфейсов...

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

Совершенно верно. И если одна из целей - быстрая разработка, то Делфи\Лазарас для этого подходят лучше других, потому что клепание интерфейса в одной проге, кодирование - в другой, а отладка - в третьей быстроте разработки не способствуют.

> По крайней мере я почти не видел кода, где вся логика не в Button1.Click.

Точно так же я почти не видел "юникс вей" кода, где вся логика не заключалась бы в каком-нибудь ключе командной строки. Чем это принципиально отличается от Button1.Click, я не вижу. Другое дело что, как тут правильно заметили, программы надо писать грамотно, и вместо того, чтобы вешать длительный процесс на единственную кнопку на форме, часто лучше вообще обойтись командной строкой.

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

Это не юниксвей. Это знают даже в MS!

> С чего вы взяли, что ГУЙ должен существовать отдельно от логики?

Не вполне ясно, что значит "отдельно", но ясно, что:

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

2) подлежит использованию из разных мест программы (грубо говоря, накладную может вбить оператор, а может она и автоматически создаваться)

3) Одна и та же логика может дергаться из 1) гуя 2) вуя 3) в пакетном режиме, например при импорте.

В теории, у дельфи радикальные проблемы только с вуем. На практике всё сильно хуже.

> Точно так же я почти не видел "юникс вей" кода, где вся логика не заключалась бы в каком-нибудь ключе командной строки. Чем это принципиально отличается от Button1.Click, я не вижу.

Button1.Click не может быть автоматически протестирована и не скриптуется. Это по мелочи.

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

1) компьютерами ("большая система")

2) фирмами ("распределенная система")

> Совершенно верно. И если одна из целей - быстрая разработка, то Делфи\Лазарас для этого подходят лучше других, потому что клепание интерфейса в одной проге, кодирование - в другой, а отладка - в третьей быстроте разработки не способствуют.

Во-первых, с чего вы это решили? Во-вторых, пассаж про отладку вызывает смутные сомнения, не путаете ли вы отладку и отладчик, и используете ли вы тестирование вообще. А так же рождает уверенность, что я зря тут бросаю бисер, лучше я его на студентов приберегу. Всего наилучшего. Накодите в Дельфях магабайта два-три сурсов -- надеюсь, поумнеете. Лично мне помгло.

> И, что характерно, первый же абзац явным образом указывает, что необходимость в подобных менеджерах появляется из-за отсутствия возможсности "кнопкобросательства"

Tkinter не самый удачный пример, на самом деле. По причине заточенности под рантайм. Граздо интересней голый тикль, для которого есть и визуальные построители. Впрочем, кроме этого есть QtDesigner, Glade, несколько построителей для Swing.

> И до кучи - всё (почти что ^_^), представленное в данной статье - элементарно реализуется через панели и Align'ы

Но не в рантайм. Так же быстро и наглядно можно набросать и в QtDesigner или Glade. Выбор инструмента зависит от задачи. Кстати, их использование не ограничено только С/С++.

> 0.о Сильно... Даже очень ^_^

1) Что сильно? Не понял. 2) Рекомендую вам прочитать 2 и, особенно, 3 главу из PCL - http://pcl.catap.ru/doku.php?id=pcl чтобы понять, что такое RAD.

> для меня RAD - это

Меня мало интересует, что для вас означает слово РАД. Я пользуюсь его более широкой значением, заложенным в расшифровке аббревиатуры.

> Что характерно - особенности IDE, а не языков

IDE тоже не надо путать с RAD. RAD - это прежде всего свойство языка быстро создавать работающие прототипы. RAD, конечно же будет мощнее, если использовать связку язык+инструментарий (который можно менять в зависимости от разных причин). А используя делфи или лазарус ты такой возможности лишен по всем статьям.

> Ну и безусловно концепции разработки, никакого отношения к языкам не имеющие, кстати сказать

Как это не имеющие? Концепцию DSL, например, в делфи попробуй протяни. Или та же концепция Буттон1Клик в куче ЯП не популярна ибо выглядит чужеродно. А прижилась для языков с перегруженным синтаксисом, типа С++/Паскаль.

> Нафига в 90% утилит сдалась клиент/серверные примочки с отделением логики от гуя? Ну НАФИГА?

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

> Короче, CLI/Frontend фанатики идут лесом, а остальные работают в меру сил своих.

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

Вот откуда такая мразь на ЛОРе берётся? Срущих "^_^" - в газенваген!

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

>Button1.Click не может быть автоматически протестирована и не скриптуется.

Бред какой-то... автоматически может быть протестировано все, что вызывается из Button1.Click, более того Button1.Click может быть вызвана автоматически, вообще без участия пользователя. У вас какие-то неправильные тараканы в голове, Button1.Click обычная функция, принимающая обычные параметры и возвращающая обычные значения.

> С чего вы взяли, что ГУЙ должен существовать отдельно от логики?

С того, что любой код должен быть реюзабельным. Фся функциональность любого приложения должна быть доступна программно, поскольку никогда программист не сможет предсказать, какие применения могут понадобиться пользователю в будущем. Это практичность, а не фанатизм. Дельфячья быдлятина же дружным строем и под барабанный бой топает в газенваген.

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

Когда захочется, тогда функциональность вынесут в "DLL/static lib", а консольное убожество с ключами пусть гики сами себе оставят.

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

> Когда захочется, тогда функциональность вынесут в "DLL/static lib",

Исходных кодов нет. Утилита проприетарная. Что делать будешь, мразь?