Информация об изменениях

Сообщение Re[6]: GUI на системном ЯП от 13.02.2023 0:00

Изменено 13.02.2023 0:08 пффф

Re[6]: GUI на системном ЯП
Здравствуйте, CreatorCray, Вы писали:

П>>там был мега фреймворк с плагинами, своим IDL и библиотекаршами.

П>>И получается, что продуктовый код пишется хорошо если половину времени, а половина уходит на свой фрейворк. А в стороннем — всё есть и не надо самому поддерживать
CC>Видимо ты пилишь фреймворк именно как generic фреймворк, чтоб сразу работало и для других целей использования. Оттого куча кода надо для поддержки того, что реально не используется.

Ну да, это был мой всемогутор, но писалось всё по нужде — интерфейс рисовальщика, подсистема IO — хоть файл, хоть TCP/UDP сокет, хоть COM-порт или HTTP ресурс и тп по универсальному имени, XML DOM (тут внизу юзал готовый), XPath — тоже нужно, большую (и нужную) часть XPath 1.0 запилил сам (было весело), ICommand или как-то так — иерархии групп команд, которые в Win/wxWidgets/Qt в меню приложения собирались, но и отдельно могли жить и тд и тп. И всё это было нужно. Любой компонент можно было заменить при необходимости простой сменой имени компонента в конфигах, всё в плагинах было


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


Так так оно изначально и задумывается, а потом... Потом это превращается в огромный чемодан без ручки, когда нужно много нового, но пилить самому уже устал
Re[6]: GUI на системном ЯП
Здравствуйте, CreatorCray, Вы писали:

П>>там был мега фреймворк с плагинами, своим IDL и библиотекаршами.

П>>И получается, что продуктовый код пишется хорошо если половину времени, а половина уходит на свой фрейворк. А в стороннем — всё есть и не надо самому поддерживать
CC>Видимо ты пилишь фреймворк именно как generic фреймворк, чтоб сразу работало и для других целей использования. Оттого куча кода надо для поддержки того, что реально не используется.

Ну да, это был мой всемогутор, но писалось всё по нужде — интерфейс рисовальщика, подсистема IO — хоть файл, хоть TCP/UDP сокет, хоть COM-порт или HTTP ресурс и тп по универсальному имени, XML DOM (тут внизу юзал готовый), XPath — тоже нужно, большую (и нужную) часть XPath 1.0 запилил сам (было весело, это примерно 5-7 тысяч строк хардкора в .h файле вышло ), ICommand или как-то так — иерархии групп команд, которые в Win/wxWidgets/Qt в меню приложения собирались, но и отдельно могли жить и тд и тп. И всё это было нужно. Любой компонент можно было заменить при необходимости простой сменой имени компонента в конфигах, всё в плагинах было


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


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