Создание собственной GUI библиотеки
Как известно есть много разных GUI библиотек: Qt, wxWidgets, FLTK, CEGUI, ParaGUI, GiGi, LibUFO и так далее.
Так вот, необходимо изобрести «велосипед» с нуля. Я думаю нужно начать с разработки системы классов и за основу взять систему классов какой либо из существующих библиотек. Какие будут советы и предложения? 🙂
А почему вдруг возникла такая необходимость? Есть притензии к этим либам или ты велосипедист по сути?
Если уж велосипед, то такой как в BeOS
Да, да я ученый-велосипедист 🙂
Просто в будущем может понадобиться полностью изменить либу в связи с узко-специализированной направленностью программного продукта, т.е. нужно свое в котором я 100% разбираюсь. И читая вот разные материалы и на практике убедился, что нужна грамотная, гибкая, расширяемая система классов, нужны знания по программированию GUI.
Кто-нибудь изучал вышеперечисленные библиотеки? Как там классы устроены?
wxWidgets калька с MFC — почти близнецы по идеологии.
Qt более продвинутый тулкит — полностью объектноориентированный, плюс система сигнал — слот. что-то другое после него кажется очень неудобным.
uelkfr
пиши в аську, 3 года всякой гуйней занимался, по большей части как раз ниписанием велосипедов и юзанием чужих опыта много.
в связи со скорым повсеместным вхождением 2(4)Core и HT, мне кажется, надо реализовывать(или копать либы, которые на этом принципе) многопоточную реализацию, не основанную, на поток-окно-таблицы-идеологии. (Возможно) выглядит так: создание контролов, которые юзаются «однопоточно», но как только к ним обращаются из других потоков, заводят гварды(крит.секции, мьютексы и др).
или ГУЙ вынести в отдельный поток.
и не должно быть никаких оконных таблиц сообщений (их же надо будет опять заворачивать в ООП. зачем делать двойную работу?) и т.п.лобуды. Да, слоты, делегаты — оно гораздо удобнее. слоты и делегаты на с++ есть на rsdn.ru.
Avalon(или как его там) и многие другие из последних поддерживают сериализацию ГУЯ в ХМЛ или другой удобочитаемый формат (при этом нет никаких возражений против И бинарной сериализации).
НО вынести строки и картинки(текстуры, может быть цветовые схемы, которые зависят от народа) в локализованные файлы. т.е продумать локализацию. помимо ГУЯ оно будет использовано и для звуков и для . очень связанная с ГУЕм тема.
в 3Д-моделях и 2Д-спрайтах интегрирована анимация от времени (или «почти тоже самое» от кадра). Должна быть и анимация ГУЙовых свойств. Т.е. интерполяторы цвета, координат, альфы, текстурных координат и др.параметров.
в остальном, есть кнопки, лист-боксы, лейблы, комбо-боксы и др. контролы.
сейчас еще интегрируются Текст2Речь и РаспознавателиРечи, но пока, наверно, не стОит заморачиваться таким неГУЙовым интерфесом задания каких-либо свойств.
ориентироваться не на крутость возможностей (хотя если хочется, чтобы ВО!, то, как минимум, либа не препятсвует), а на удобство редактирования. т.е. поменять текстуру, позицию, колор, анимацию и др минимальными тело- и мысле-движениями (второе совсем хорошо, не напрягает, когда знаешь (а еще лучше просто предполагаешь), что вот так, вроде, должно заработать и оно действительно работает! кто писал или часто юзал контролы в дельфи или НЭТе или еще чем, тот уже знает, что ожидать от подобного, а MFC — ужоснах — в каждом втором сообщении собака зарыта, да и нафиг он в играх? разве что для главного окна, да и то без него несложно, разве что из-за классов-хелперов, но уж точно не как ГУЙ).
желательно схемы расположения не зависящие от разрешения экрана (что трудно для текстур, поскольку они обычно делаются под конкретное разрешение)
либо эти схемы (layouts) также являются загружаемыми в рантайме ресурсами.
желательно не зависящее от платформы и ГЛ и ДХ. но от этого пока, наверно, стоит отказаться, поскольку если будет удобоваримый ГУЙ в связке с конкретной либой, перевести его же не составит труда и в другую (или написать обертку над нижележащим уровнем). все равно эту задачу не будет выполнять рядовой программист, а тогда и не о чем пока говорить.
кто-нибудь еще чего-нибудь добавит или опротестует
cannon
Ого! а ведь реально шаришь! Респект!
Почти про все рассказал, можно многое подробнее раскрыть и еще про направление потоков данных если на гуе много информации «неизвестно откуда» нужно отображать, тоже желательно это сделать так, чтобы были минимальными телодвижения.
cannon, да добавлю (опротестую). У меня есть 2 опыта программирования графики. 1-й — необходимо было показывать видео в реальном времени, 2й — программирование 3D. И первое и второе жутко тормозит, если не программировать на уровне ядра ОС в прямом взаимодействии с железом. Собственно DirectX или OpenGL фактически решает именно эти задачи. А теперь предлагаю подумать и сделать выводы, сколько изобретали DX с Gl и сколько потребуеться, чтобы воспроизвести 10% уже созданного.
uelkfr, рекомендую досканально изучить DX или GL, изучить написание драйверов пол Windows (Windows DDK), а когда будет конкретная задача, реализовать существующими средствами, а когда не будет хватать производительности, скорее всего необходимо что-то будет дописывать на уровне ядра, а если все равно не будет хватать, то тогда скорее всего тебе придеться делать какой-то PCI-E акселератор или заказывать специфическую видеокарту.
Толпа велосипедистов.
Присоединяюсь.
KKH
Выбрать DX или GL — совет хороший, но дальше. Зачем затачиваться под конкретную видюху. Нужна ли такая производительность в, по сути, статичной системе.
На самом деле, если взять за основу достойный рендер, не надо будет особо париться с выбором DX, GL или, к примеру, сразу затачиваться под SDL (или ещё что того же уровня абстракции). Тут, как я понимаю, важней контролы удачно раскурить. И, ИМХО, не так важно качественно вкрутить туда анимацию и какие-нибудь эффекты, а хитро обставить подвешивание команд на различные события, чтоб пользователь не парился. Тут бы едитор какой надо удобный.
Вместо того, чтобы выбирать Dx или GL, лучше сделать абстрактный рендер, а потом уже писать обертку для конкретного АПИ 😉
гуи в xml это очень удобная штука. Но нада все равно ручками в коде привязывать много чего. Но это мелочи, если разделить все эт между программистом и дазийнером. Объяснить ему все как должно писаться, сделать ему тестовый «стенд» где он будет пытать гуй.
я для guichan писал XML парсер, кому нада, могу выслать =) ещё бы редаткор прикрутить, вообще сказка была бы.
Вместо того, чтобы выбирать Dx или GL, лучше сделать абстрактный рендер
С этим я согласен, но дальше, чтобы написать обертку, какие знания потребуются? Нужно будет знать, например, как данные передать в видеоадаптер. А для этого чем собираетесь пользоваться? Если DirectX, то его придетсься всё равно очень хорошо изучить. А для того, чтобы был хоть какой-то смысл от собственного абстрактного рендера, нужно будет еще и очень хорошо изучить и Open GL и прочее. Ну и зачем? Всё это GUI будет актуально до следующей версии одной из «обёрток». Зачем же такое самопожертвование? Всё же в n раз проще изучить то, что есть и пользоваться этим.
Про DDK я к чему заговорил. Такая простая задача, как передача видео с камеры через Ethernet в реальном времени, оказалась мне фактически не по зубам. Используя средства DirectX, отставание показываемого от действительного отличалось на 1 — 2 секунды, а по началу, и того больше.
KKH
>Всё же в n раз проще изучить то, что есть и пользоваться этим.
Если писать под себя, то да, можно и то тчо хорошо знаешь. А если для других ещё, то лучше уж обертку 😉
>Такая простая задача, как передача видео с камеры через Ethernet в реальном времени, оказалась мне фактически не по зубам. Используя средства DirectX, >отставание показываемого от действительного отличалось на 1 — 2 секунды, а по началу, и того больше.
Драйвер это конечно хорошо, но вот например не все пользователи могу драйвер поставить (ограничение прав в винде). + ГУИ не требует сложного рендера, вес тчо там есть (я не имею ввиду монстроидальные гуи с 3д интерфейсом) — это полигоны с текстурой.
Источник
Как создать собственную графическую библиотеку на с++?
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Как создать собственную библиотеку?
А как собственно это сделать? Я выбираю файл — шаблон проекта — библиотека классов. Создается.
Создать собственную библиотеку ввода-вывода строк и их обработки
Создать собственную библиотеку ввода-вывода строк и их обработки: gets, puts, atoi, itoa, reverse.
Как защитить собственную библиотеку?
Планируется продавать библиотеку всем, кто захоочет ее купить. Как защититься от умника, который.
Как написать графическую библиотеку?
Есть много графических библиотек(MFC, VCL, WxWidgets). А как можно создать свою(хотя-бы.
«Так есть же SFML библиотека
Зачем волосапед изобретать если он уже есть ?>»
Я хочу знать, как работает SFML, OpenGL.
Решение
«Через WinAPI и работает» — Можно пример?
«. если только вы не автор драйверов для этого самого железа.» — через язык ассемблера можно сделать?
Решение
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Как установить графическую библиотеку SFML на Dev C++?
Как установить графическую библиотеку SFML на Dev C++? http://www.sfml-dev.org/download/sfml/2.2/.
Где скачать графическую библиотеку для gfortran, и как ее установить?
Доброго времени. Подскажите где скачать графическую библиотеку для gfortran, и как ее установить.
Как внедрить графическую библиотеку SDL в Visual Studio 2012
Никогда не внедрял сторонних библиотек в Visual Studio. В инете поискал, но так ничего и не понял.
Права на графическую библиотеку
Может кто нибудь сказать какие ограничения в использовании библиотеки http://xeiam.com/xchart/ .
Посоветуйте графическую библиотеку
Господа, подскажите Python-библиотеку для создания GUI-программ, чтобы после создания скрипта его.
Посоветуйте графическую библиотеку
Привет! Не посоветует ли кто subj, которую можно поиметь безвоздмездно, т.е. — даром? Что от.
Источник
Создание графической библиотеки своими руками [закрыт]
Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы он был сосредоточен только на одной проблеме.
Закрыт 4 года назад .
Давно хотел попробовать с нуля создать свою простенькую графическую библиотеку типо OpenGL или там DirectX, исключительно из спортивного интереса(давно интересуюсь этой темой и как то писал простенький рендер трассировкой лучей на java, но сейчас хочу сделать отрисовку в реальном времени). может кто подсказать библиотеки для c++ ну или подскажите куда копать. Одной из целей является отрисовка вращающихся моделек формата obj. По сути, все что нужно от библиотеки-рисование точки заданного центра в заданных координатах, ну или формирование битмапа и его отрисовка целиком
2 ответа 2
Если не смотреть вглубь работы графических карт, не принимать в расчёт шейдера и прочие вещи, которые уже давно написаны и вылизаны до максимальной степени в графических библиотеках аля Direct3D / OpenGL, то можете попытаться писать на WinAPI, рисуя на контексте (HDC). ( Считай это наводкой ). Если хочешь ещё ниже к ядру оси, почитай про GDI и реализуй свой WinAPI.
Впрочем, нет смысла городить велосипеды, когда есть достаточно уже обкатанные рабочие либы, лучше воспользоваться ими. По опыту скажу, рисовал модели Maya ( это те самые *.obj ) и при помощи WinAPI, и при помощи OpenGL, на OpenGL это в разы быстрее.
Неясно чего вы хотите, что OpenGL что DirectX не являются библиотеками, у них есть одинаковые функции, но по существу они отличаются хотя бы тем, что первый это стандарт по котору программируется графика на разных языка и кроссплатформенно, а второй — DirectX набор библиотек от майкрософта для написания мультимедийного софта.
Одной из целей является отрисовка вращающихся моделек формата obj
Для этого будет вполне достаточно использовать OpenGL 4.x например, парсить .obj файл и применять базовые функции этого API для рисования примитивов, наряду с некоторыми базовыми матричными операциями для всяких пространственных преобразований
А написание своего OpenGL или Direct3D относится к разработке собственного рендера — грубо говоря набора низкоуровневых функций позволящих например, быстро отрисовать линию по какому-нибудь алгоритму или закрасить многоугольник каким-нибудь цветом — тоесть здесь совсем другие вещи применяются, в основном мало связанные с той типичной 3D математикой с которой сталкиваешься при непосредственном использовании OpenGL или Direct3D
Источник
Создание единой библиотеки компонентов
Дизайнер Сергей Никишкин написал на «Хабрахабре» колонку о дизайн-системе компании Acronis.
Меня зовут Сергей, я работаю старшим дизайнером в компании Acronis. В отделе дизайна продуктов для бизнеса я отвечаю за разработку и внедрение единой библиотеки компонентов.
Так как у нас много продуктов и сервисов, а дизайн в этих продуктах и сервисах сильно отличается, мы решили его унифицировать и привести к единому UI. Такой подход дает возможность оптимизировать работу отдела, сосредоточить дизайнеров на UX, ускорить процесс разработки и запуск новых продуктов, снизить нагрузку на отделы тестирования и значительно сократить количество багов на стороне фронтенд.
В этой статье я расскажу о нашем опыте, остановлюсь на инструментах и покажу, как устроена библиотека изнутри.
Долгое время роль библиотеки играл собранный в Adobe Illustrator PDF-файл с палитрой цветов, скудным набором элементов и большими планами на будущее в виде 70 пустых страниц.
Для того, чтобы найти какой-нибудь уже существующий элемент, приходилось постоянно дергать других дизайнеров или лопатить чужие исходники, а потом сверять актуальность с реализованным элементом на одном из тестовых стендов. Пик отчаяния наступал в тот момент, когда на тестовом стенде искомый элемент выглядел несколько иначе и вел себя не совсем так, как было запланировано в макетах.
Получалась достаточно стандартная ситуация: дизайнеры тянули одеяло в свою сторону, мотивируя свои решения авторитетным «хочу, чтобы было так!», а разработчики пытались прикрываться мало значимым «но ведь технические ограничения». Такой подход, закономерно, приводил к не самым лучшим результатам по обе стороны баррикад и его нужно было менять.
Забегая вперед, скажу, что сейчас большинство сложных UI-решений мы принимаем коллегиально и стараемся искать компромисс между красотой и технологичностью.
- Централизованная библиотека UI-элементов.
- Версионность файлов и контроль за изменениями.
- Единый и понятный workflow.
- Базовый набор инструментов для работы.
- Взаимодействие с разработчиками.
Первое, что предстояло сделать, это найти инструменты, которые закроют большую часть потребностей отдела. После длительного изучения различных подходов к формированию библиотек и дизайн-систем, после вороха статей на блог-платформе Medium и тестирования огромного количества приложений и сервисов, мы выстроили следующую схему:
Abstract отвечает за контроль версий и историю изменений мастер-файла библиотеки. Craft используется как библиотека для палитры цветов и замена нативному Color Inspector. Lingo отвечает за хранение, подключение и обновление компонентов библиотеки в Sketch-файлах.
Такая схема уже сейчас позволяет легко поддерживать библиотеку в актуальном состоянии, контролировать изменения и, что наиболее важно, быстро доставлять обновления дизайнерам. При этом, доступ к мастер-файлу библиотеки имеет только владелец, а остальные участники процесса получают элементы в виде символов и составных компонентов из Lingo. Для доступа к компонентам Angular мы подняли на каждой машине песочницу, чтобы дизайнеры с помощью npm-start в консоли могли быстро запустить node-server и работать с кодом.
Еще раз забегая вперед, скажу, что одна из наших основных, долгосрочных и амбициозных задач — перенести большую часть работы над дизайном из графического редактора в браузер.
Это десктопное приложение, которое позволяет контролировать историю изменений, откатываться к прошлым версиям и держать один актуальный мастер-файл, доступ к которому есть у каждого члена команды.
Для начала работы с Abstract достаточно добавить в приложение уже существующий проект или создать новый. Изменения идут в одной или нескольких параллельных ветках с последующим добавлением утвержденных кусков в мастер-файл.
Так как Abstract не дает создать новую ветку или слить ветку с мастер-файлом без комментария, история изменений появляется сама собой. Благодаря таким комментариям, значительно снижается вероятность случайных или неконтролируемых изменений. К тому же, удобно через какое-то время открыть проект и прочитать историю, посмотреть, как и зачем менялись элементы.
Если говорить о недостатках, то ключевым для некоторых команд может стать отсутствие возможности решать конфликты на уровне слоев в одном артборде, из-за чего параллельная работа над одним экраном невозможна, всегда будет конфликт версий и предложение выбрать один из двух вариантов. В нашей команде такой проблемы нет, так как мы одновременно не работаем над одним артбордом.
Остальные мелкие неровности и шероховатости нивелируются полным контролем над происходящим, больше никаких папок по датам, никаких md-файлов с описанием изменений и кучи исходников на внутреннем хранилище.
На данный момент мы используем Craft как библиотеку для цветовой палитры и замену нативному Color Inspector. Под рукой не только все цвета, но и названия переменных. Благодаря такому подходу удалось решить еще одну важную проблему. Дизайнеры перестали «пипетить», а разработчики перестали резонно негодовать, почему в двух макетах у одного и того же элемента отличаются значения цвета.
Кто работает в Sketch и использует несколько мониторов знает, что на каждом подключенном мониторе один и тот же цвет взятый пипеткой, в большинстве случаев, будет иметь разный HEX-код.
Десктопное приложение, с помощью которого мы решили все проблемы связанные с подключением актуальной библиотеки к новым файлам и обновлением компонентов в уже подключенных проектах.
Можно создать несколько библиотек, разбить библиотеку на категории, проставить теги для каждого элемента, а при импорте элементов выбрать какой элемент добавить, а какой нет. При обновлении существующего компонента в библиотеке, Lingo предложит его заменить, сделать дубликат или отказаться от изменений.
Так же в Lingo можно хранить составные компоненты в виде папок со слоями или артборды целиком. Для нас эта возможность особенно актуальна, так как мы сознательно не делаем компоненты с большим количеством оверрайдов из-за сложностей в поддержке и кастомизации.
Несмотря на то, что в Sketch 47 будут библиотеки символов, которые уже доступны в бета-версии (работают, кстати, круто), мы не спешим уходить с Lingo из-за его возможностей и большей гибкости в работе.
Централизованно мы используем три плагина:
- Shared Text Styles для работы с текстовыми стилями. Позволяет экспортить текстовые стили в формате JSON, добавлять стили в новый Sketch-документ и обновлять уже подгруженные.
- Relabel button для работы с кнопками. Одна из лучших реализаций плагинов такого рода, на мой взгляд. Достаточно правильно настроить привязки элементов внутри символа.
- Acronis data. Так как мы достаточно много работаем с таблицами и большими массивами данных, я собрал плагин, который генерирует специализированные значения для этих таблиц (offering items, agents name, schedule options, machines и так далее). Плагин работает на основе dummy data и подтягивает значения из JSON. Перед тем, как собирать кастомное решение, была неудачная попытка подружить единый JSON с Craft, но увы. Как оказалось, Craft не умеет в исходную разметку документа и показывает поля не по порядку.
Рано или поздно перед каждым дизайнером, работающим в Sketch, встает проблема повторного использования символа иконки с другим цветом. В частных случаях можно отвязать иконку от символа или держать несколько символов с разными цветами, что не очень актуально, когда иконок много.
Я решил проблему следующим образом: прямоугольники с необходимыми цветами собрал в отдельные символы, а потом эти символы в виде масок добавил к иконкам, у которых может быть несколько цветов. Таким образом изменение цвета становится доступно через overrides.
Несмотря на удобство, у этого способа есть существенный минус. При экспорте SVG в коде будет присутствовать маска. Если на стороне разработки нет способа автоматизировать процесс удаления масок, придется держать отдельную библиотеку чистых иконок.
Неважно, насколько прокачана и удобна библиотека пока она существует исключительно в виде Sketch-файла. Если в браузере компонент выглядит не так, как в макетах, библиотека уже неактуальна, а исходники устарели и не соответствуют действительности. Благодаря фронтенд-архитектору Acronis Сергею Сабурову, Кириллу Савёлову и всей команде мониторинга, наши компоненты плавно перетекают в код и работают именно так, как запланировано.
Несмотря на то, что часть новых продуктов и сервисов мы уже начали собирать с помощью текущих компонентов, еще не все фронтенд-команды готовы внедрять и использовать эти компоненты у себя. Где-то фронт написан на Ext JS, где-то используется Vue, и быстрый переход с одного фреймворка или библиотеки на другой технически невозможен по ряду причин.
У каждого компонента есть набор свойств. Свойства позволяют управлять состоянием компонента, его внешним видом и функциональностью. Так выглядит стандартный инпут в Sketch-библиотеке:
Источник