Здравствуйте!

Вопрос опять по архитектуре, но так как всё про плюсы, напишу сюда.

Вот у меня есть какая-то своя библиотека контролов.

У контролов есть два основных аспекта: реакция на пользовательский ввод и отрисовка. Реакцию на пользовательский ввод я пока выделять особо не хочу, пусть будет зашита, а вот отрисовку — хочу выделить отдельно.

Цель простая — дать пользователю возможность создавать свои "темы", без необходимости ковыряться в кишках либы или делать своих наследников и переопределять им методы рисования.

Во всех случаях у нас есть какая-то IControlPainterFactory, которая один раз в начале задаётся. А вот далее возникают вопросы, как лучше сделать

Какие я вижу альтернативы.

1) У нас есть

IControlPainter IControlPainterFactory::getPainter(IControl *pControl)

Там dynamic_cast'ами определять, для какого конкретно типа вызван getPainter, и возвращать соответствующую реализацию.

Или, можно сделать

enum ControlType {PushButton, RadioButton, CheckBox, ListView, TrieView, ...}

и

IControlPainter IControlPainterFactory::getPainter(ControlType controlType)

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

Вопрос такой — как быть в том случае, если пользователь создал свой тип контрола, и сопоставил ему какой-то свой ControlType, дополняющий исходное определение? Тут будут грязные касты, насколько это фу? И, кстати, а как поведут себя плюсовые компиляторы различных стандартов, если будет что-то такое:

const int MyCoolControlType = 1111;
//...
case (ControlType)MyCoolControlType:
//...

А то последнее время гайки с enum'ами в switch стали подзакручивать. Хотя, можно и без switch обойтись, варианты есть.

2) Собственно, сам IControlPainter.

2.а Можно сделать

void IControlPainter::paintControl(ICanvas *pCanvas, IControl *pControl)

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

2.б Можно сделать каст в хосте

IControlPainter* pBasePainter = pControlPainterFactory->getPainter(...)
IPushButtonPainter* pPainter = dynamic_cast<IPushButtonPainter>(pBasePainter);
pPainter->paintPushButton(pCanvas, this);

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

2.в
Можно сделать с одним интерфейсом IControlPainter, а тип и состояние передавать enum/int'ами

enum ControlStatesPushButton{ Pushed, Unpushed };
enum ControlStatesCheckBox{ Checked, Unchecked };
enum ControlStatesCheckBox3State{ Checked, Unchecked, Third };

void IControlPainter::paintControl(ICanvas *pCanvas, IControl *pControl, ControlType controlType, int controlState)

Тут уже суровый кастинг в int. Хотя, в принципе: I) все эти состояния кнопок можно объединить в один enum с тремя состояниями, в ButtonBase сделать флаг — она 2State или 3State, но это просто недостаток моего примера; II) Отдельно можно не передавать int controlState, а просто у базового контрола будет метод int getControlState() — но это те же яйца, только в профиль

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

Какие ещё недостатки есть в описанных мной сценариях?

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

Здравствуйте, Marty, Вы писали:

M>Цель простая — дать пользователю возможность создавать свои "темы", без необходимости ковыряться в кишках либы или делать своих наследников и переопределять им методы рисования.
CSS ?

M>Какие ещё недостатки есть в описанных мной сценариях?
Каких только нет

M>как и (а) сделать отрисовку разных типов контролов в одном типе пайнтера
Очень просто ваш рисователь должен предоставлять отрисовку всех базовых элементов контролов.
Но помимо отрисовки есть еще и размещение и вообще этот айсберг таит много сюрпризов.

M>Какие ещё есть варианты реализации подобного, с учетом того, что:
M>а) хотелось бы получить бинарную совместимость между разными компиляторами;
M>б) я буду это запихивать в скрипт-движок, и он близок скорее к сишечке;
M>в) я хочу дать пользователю возможность самому делать ссвои контролы как в отдельных DLL, так и в скрипте

Удачи. Будет еще один html, но с блекджеком и поэтессами.

Здравствуйте, kov_serg, Вы писали:

M>>Цель простая — дать пользователю возможность создавать свои "темы", без необходимости ковыряться в кишках либы или делать своих наследников и переопределять им методы рисования.
_>CSS ?

Никаких V8, только niht
Ну и, в итоге, конечно, потом можно будет сделать реализацию IPainterFactory, которая будет на базе CSS. Но пока это не нужно


M>>Какие ещё недостатки есть в описанных мной сценариях?
_>Каких только нет

Давай, жги


M>>как и (а) сделать отрисовку разных типов контролов в одном типе пайнтера
_>Очень просто ваш рисователь должен предоставлять отрисовку всех базовых элементов контролов.
_>Но помимо отрисовки есть еще и размещение и вообще этот айсберг таит много сюрпризов.

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


_>Удачи. Будет еще один html, но с блекджеком и поэтессами.

Не, до такого я точно не скачусь

Здравствуйте, Marty, Вы писали:

M>Какие ещё недостатки есть в описанных мной сценариях?

Посмотрите на CSS. Где (при адекватном форматировании кода) ваше решение требует меньше одной строчки — записывайте себе в плюс, где больше 1 строчки — в минус.

Здравствуйте, rosencrantz, Вы писали:

M>>Какие ещё недостатки есть в описанных мной сценариях?

R>Посмотрите на CSS. Где (при адекватном форматировании кода) ваше решение требует меньше одной строчки — записывайте себе в плюс, где больше 1 строчки — в минус.

Я же сказал, что не надо мне ваших CSS

Здравствуйте, Marty, Вы писали:

M>Я же сказал, что не надо мне ваших CSS

Так я вам отвечаю — надо, вы занимаетесь ерундой. Сначала посмотрите на CSS, потом программируйте свои абстрактные фабрики кнопок. Ну серьёзно, стандарт индустрии. Проще вас закидать камнями, чем объяснять где вы неправы

Здравствуйте, rosencrantz, Вы писали:

M>>Я же сказал, что не надо мне ваших CSS

R>Так я вам отвечаю — надо, вы занимаетесь ерундой. Сначала посмотрите на CSS, потом программируйте свои абстрактные фабрики кнопок. Ну серьёзно, стандарт индустрии. Проще вас закидать камнями, чем объяснять где вы неправы

Да видел я ваш CSS. В микроконтроллер, например, его не запихнёшь

Здравствуйте, rosencrantz, Вы писали:

R>Посмотрите на CSS. Где (при адекватном форматировании кода) ваше решение требует меньше одной строчки — записывайте себе в плюс, где больше 1 строчки — в минус.
И сколько надо строк кода чтоб css превратился в пихели на экране?

Здравствуйте, CreatorCray, Вы писали:

R>>Посмотрите на CSS. Где (при адекватном форматировании кода) ваше решение требует меньше одной строчки — записывайте себе в плюс, где больше 1 строчки — в минус.
CC>И сколько надо строк кода чтоб css превратился в пихели на экране?

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

Здравствуйте, Marty, Вы писали:

M>Здравствуйте, rosencrantz, Вы писали:

M>Да видел я ваш CSS. В микроконтроллер, например, его не запихнёшь

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

Здравствуйте, rosencrantz, Вы писали:

M>>Да видел я ваш CSS. В микроконтроллер, например, его не запихнёшь

R>Да бросьте — наоборот интересная задача по-моему. Со всеми этими вашими александрескувскими метрапрограммированиями — можно хоть академ на год брать

Мне не надо на год, мне на неделю хватит

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, rosencrantz, Вы писали:

R>>Посмотрите на CSS. Где (при адекватном форматировании кода) ваше решение требует меньше одной строчки — записывайте себе в плюс, где больше 1 строчки — в минус.
CC>И сколько надо строк кода чтоб css превратился в пихели на экране?

Слушайте, ну я бы прочитал статью полностью, если бы кто-то взялся. Базовая часть не так интересует. Интересует, в основном, сравнение HTML/CSS vs C++/eDSL.

Здравствуйте, Marty, Вы писали:

M>Здравствуйте, CreatorCray, Вы писали:

R>>>Посмотрите на CSS. Где (при адекватном форматировании кода) ваше решение требует меньше одной строчки — записывайте себе в плюс, где больше 1 строчки — в минус.
CC>>И сколько надо строк кода чтоб css превратился в пихели на экране?

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

Не предполагается. Имелось в виду, что возьмите основные идеи, возьмите какое-то минимальное подмножество из 1937 года — и получится что-то осмысленное. Любой дизайн предполагает, что библиотека хорошо решает какие-то задачи (задачИ — больше одной). Вы не можете просто сесть и понаписать чего-то хорошее без понимания какие проблемы вообще решаем. В 2024 году по CSS накопилось уже достаточно много "истории", чтобы сделать выводы.

Здравствуйте, rosencrantz, Вы писали:

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

R>Не предполагается. Имелось в виду, что возьмите основные идеи, возьмите какое-то минимальное подмножество из 1937 года — и получится что-то осмысленное. Любой дизайн предполагает, что библиотека хорошо решает какие-то задачи (задачИ — больше одной). Вы не можете просто сесть и понаписать чего-то хорошее без понимания какие проблемы вообще решаем. В 2024 году по CSS накопилось уже достаточно много "истории", чтобы сделать выводы.

Писать самому разбор и использование CSS? Даже версию 1937 года? Хм, я хотел до пенсии закончить проект, а не оставлять его по наследству

Здравствуйте, Marty, Вы писали:

M>Писать самому разбор и использование CSS? Даже версию 1937 года? Хм, я хотел до пенсии закончить проект, а не оставлять его по наследству

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

Здравствуйте, rosencrantz, Вы писали:

M>>Писать самому разбор и использование CSS? Даже версию 1937 года? Хм, я хотел до пенсии закончить проект, а не оставлять его по наследству

R>Слушай, если осталось меньше 10 дней, просто нейтрально отвечай на письма и улыбайся, когда кто-то смотрит

Зачем улыбаться всем, кто пишет хрень?

Здравствуйте, Marty, Вы писали:

M>>>Цель простая — дать пользователю возможность создавать свои "темы", без необходимости ковыряться в кишках либы или делать своих наследников и переопределять им методы рисования.
_>>CSS ?

M>Никаких V8, только niht
...
Вы видимо не поняли. Я не про сам CSS а по идею в нём заложенную: CSS это селектор (который описывает где) и модификатор (который описывает как изменить)
То есть для внесения изменений это минимальный набор без которого изменения тем превратиться в еб%%.

M>Давай, жги
Пока не вижу в этом смысла.

M>С размещением пока нет проблем, не вижу острой необходимости выносить
Очень зря, как вы собираетесь менять тему не имея возможности изменять размеры и положения представлений контролов?

_>>Удачи. Будет еще один html, но с блекджеком и поэтессами.
M>Не, до такого я точно не скачусь

Здравствуйте, kov_serg, Вы писали:

_>Вы видимо не поняли.

Видимо не поняли


_>Я не про сам CSS а по идею в нём заложенную: CSS это селектор (который описывает где) и модификатор (который описывает как изменить)
_>То есть для внесения изменений это минимальный набор без которого изменения тем превратиться в еб%%.

Только темы сделать просто, а даже жалкое подобие CSS — это надолго. Опять же, имея API поддержки тем, можно потом будет сделать реализацию темы, которая настройки будет читать из "CSS".


M>>С размещением пока нет проблем, не вижу острой необходимости выносить
_>Очень зря, как вы собираетесь менять тему не имея возможности изменять размеры и положения представлений контролов?

Элементарно. Тема — это про оформление, а не про положение контролов. А сами контролы на формах будут располагаться ручками, возможно, чуть позже добавлю автоматические лейауты. А сами "формы" будут браться из шаблонов, где будут задаваться размеры и расположение контролов. Поэтому отдельного подАПИ делать не требуется


_>>>Удачи. Будет еще один html, но с блекджеком и поэтессами.
M>>Не, до такого я точно не скачусь

_>Image: 170402353511524833.jpg

Спасибо, я соломку уже разложил