Графический интерфейс, реализация

Сейчас просто для себя решил попробовать сделать простой, но удобный и понятный графический интерфейс для МК на С++. Низкоуровневые вещи по заполнению экрана и отрисовке графических примитивов уже есть, вопрос в организации отдельных программных частей. Вот есть базовый абстрактный класс Widget от которого наследуют такие вещи как Button, Stydir, MsgBox, Switch и так далее. В Widget хранится информация и методы касательно размеров, положения, видимости и прочее. В остальных классах реализуются уже более специфичные вещи, зависящие от состояния. Но возник вопрос, должны ли такие классы содержать и методы, непосредственно отображающие объекты на экране? Или отрисовку правильнее возложить на отдельный класс, который будет вызывать перегруженные функции в зависимости от типа объекта? Помимо графики, если планируется сенсорный ввод, то где лучше разместить его обработку, в каждом классе или выделить для этого отдельный?

0

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

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

Вообще, общая рекомендация моя такая. Есть замечательная библиотека Qt, откуда идеи можно черпать и черпать. Есть книга по Qt за авторством господина Шлее. Она, конечно, написана с точки зрения пользователя, а не программиста, но там все весьма прозрачно, если внимательно следить, откуда берется кролик. Просто посмотрите, как ваши вопросы реализованы в Qt по части интерфейса, максимально упростите и получите профит.

0

Господа. Ну вы как всегда. Вопросы заданы конкретные, ответы - кто во что горазд... Ну сами понимаете...

0

Сообщение от Myrmyk Каждый потомок Widget должен содержать перегружать виртуальную функцию... и получите профит.

Ну и чем описанное вами отличается от того, что у меня в моем куске моей библиотеки?
Так оно и реализовано по алгоритмике. Может чуток по другому по стилю программирования, но алгоритмы те же.
Так что я считаю, что на поставленный вопрос я ответил.

0

Ваш ответ по теме. Глобально против вашего ответа я ничего не имею.

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

Но, это так... Мысли на тему.

0

Fobirki,
Подходов куча. Сейчас похожей задачей занимаюсь. Решил сделать 2 интерфейсных класса:
1. Для управления графическими объектами, строками и т.д.
2. Для управления драйвером экрана
Для тача отдельный класс. Фрейм-буффер в виде списка с объектами + тач. Вывод на экран - итерация списка.

0

Сообщение от Myrmyk Ваш ответ по теме. Глобально против вашего ответа я ничего не имею. Но, хочу заметить, с педагогической точки зрения ссылки на код крайне малоэффективны. Код может быть дополнением, а не ответом. Для того, чтобы осилить чужой код требуется определенный уровень понимания. Если вопрос о структуре, то всегда лучше словами сказать. Но, это так... Мысли на тему.

Согласен, но если чел захотел создать GUI на интерфейсах, то стоит все же думать, что у него есть этот определенный уровень понимания. А если его нет, то и описание структуры словами тоже мало чего даст.

0

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

0

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

Попытка первая
<Изображение удалено>

Пока я немного поупражнялся с реализацией и понял, что мой изначальный вариант с объявлением объектов-драйверов экрана и тача в базовом классе как статичных членов (единых для всех виджетов на экране) выглядит прямо скажем не очень и приводит к костылям уже на раннем этапе. Хотя изначально это выглядело очень заманчиво: иметь в каждом классе-наследнике простые и понятные методы для определения собственной позиции и координат касания для последующей обработки. Очевидно, их придется выносить, но сколько всего они за собой потянут, я пока плохо представляю. Может быть, тогда все-таки заодно убрать отрисовку и взаимодействие с нажатиями из отдельных классов? В конце-концов, кнопка, слайдер и окошко с текстом просто хранят свое состояние, а уж выглядеть на экране они могут десятком разных способов.

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

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

0

Да мы абстрактно беседуем.

Годная клавиатурка :).

0

Так это тот самый игровой контроллер ?

0

Сообщение от -OTS- Так это тот самый игровой контроллер ?

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

0