Хочу сделать (или найти) следующую реализацию контролов:
1) Приложение НЕ будет создавать контрол через Windows API, т.е. ОС не будет знать состав контролов этого окна
2) вместо Windows, приложение само будет раскидывать сообщения по дочерным окнам (контролам).
Плюсы:
1) потом планирую портировать приложение под Linux и Mac, думаю с таким подходом будет проще портировать
и тестировать нужно будет только для 1 ОС полностью, а для остальных ОС только частично.
2) будет выглядеть и вести себя одинаково вне зависимости от ОС и версии ОС.
3) можно обойтись без тяжелых фреймворков, таких как QT
4) ОС не будет знать состав контролов этого окна. Хакерам будет сложнее.
Какие минусы у данного подхода ?
Существуют ли такие реализации ?
Здравствуйте, maks1180, Вы писали:
M>Хочу сделать (или найти) следующую реализацию контролов: M>1) Приложение НЕ будет создавать контрол через Windows API, т.е. ОС не будет знать состав контролов этого окна M>2) вместо Windows, приложение само будет раскидывать сообщения по дочерным окнам (контролам).
M>Какие минусы у данного подхода ? M>Существуют ли такие реализации ?
Здравствуйте, maks1180, Вы писали:
M>Какие минусы у данного подхода ?
Вместо работы на полезными функциями будет работа над этими контролами, да которых, по сути, никому нет никакого дела — сделаны они нативно или вот так.
M>Существуют ли такие реализации ?
Можно взять любую оконную библиотеку эпохи MSDOS и портировать под нужную ОС (рисование, обработка манимуалятора типа "мышь"), выглядеть будет ээ, соотвествующе.
Здравствуйте, RonWilson, Вы писали:
M>>Существуют ли такие реализации ? RW>Можно взять любую оконную библиотеку эпохи MSDOS и портировать под нужную ОС (рисование, обработка манимуалятора типа "мышь"), выглядеть будет ээ, соотвествующе.
Здравствуйте, maks1180, Вы писали:
М>>Qt?
M>Разве он так умеет ?
Да. Плюсы — кросплатформенность малой кровью, отличная кастомизируемость стилями, минусы — не до конца нативное поведение таких контролов.
Еще есть sciter (тоже сам рисует, html, css и c++) и для ныне популярный рисующий в хромиуме (не с++) electron (js, html, css)
RW>>Можно взять любую оконную библиотеку эпохи MSDOS и портировать под нужную ОС (рисование, обработка манимуалятора типа "мышь"), выглядеть будет ээ, соотвествующе.
Z>Соотвестующе круто конечно имелось ввиду. Вот кстати нужная библиотека https://github.com/magiblot/tvision
именно. как крутое, олдскульно-душещипательное говно
M>1) ... и тестировать нужно будет только для 1 ОС полностью, а для остальных ОС только частично. M>2) будет выглядеть и вести себя одинаково вне зависимости от ОС и версии ОС. M>Какие минусы у данного подхода ?
в том, что наверняка юзеры будут плеваться от поведения этих "кроссплатформенных" контроллов, и их придётся долго и упорно допиливать на каждой поддержанной платформе, добавляя самостийные плюшки
Здравствуйте, maks1180, Вы писали:
M>Хочу сделать (или найти) следующую реализацию контролов: M>1) Приложение НЕ будет создавать контрол через Windows API, т.е. ОС не будет знать состав контролов этого окна M>2) вместо Windows, приложение само будет раскидывать сообщения по дочерным окнам (контролам).
M>Существуют ли такие реализации ?
Ага. 1сV8, например. Запусти её и посмотри винспаем её контролы...
О, как раз сейчас многие приложения обзаводятся интерфейсом на html+js (и браузерным движком чтобы всё неспешно рендрить ). Само по себе это терпимо, пока кто-то не начинает для пущей "кроссплатформенности" не использовать контролы браузера (они же не такие красивые как хочется), а самому рисовать кнопки (накладывая на условный div нужный стиль) и потом в js обрабатывать клики на них.
И действительно, не проблема нарисовать кнопку, по которой можно кликнуть мышкой.
Проблемы начинаются дальше. Оказывается, что для удобной работы с приложением этого недостаточно.
Например, люди при работа с текстом перемещаются между контролами с использованием клавиатуры, но для этого нужно сделать tab index.
Скопировать текст ошибки из окна в буфер обмена? Стандартный диалог так умеет. А для кастомного нужно снова код писать. Или пользователю придётся вручную перенабирать текст.
Забыли в своём коде отрисовки учесть DPI? Приложение выглядит мелко/крупно. И вообще есть проблемы с масштабированием.
Стиль приложения может и единый, но зато в каждой ОС выглядит чужеродно.
Адок с accessibility в широком смысле слова: например, содержимое нативных контролов ОС можно прочитать и ими можно управлять голосом. Если ты забыл написать соответствующий код, то в лучшем случае услышишь от своего приложения что-то вроде "номер вашего заказа <order.png>"
Ладно, для последнего пункта ещё можно понять почему человек без близорукости может забыть про голосовое управление — ведь он им ни разу не пользовался. Но похоже это та же причина, по которой в подобных интерфейсах постоянно повторяются одни и те же ошибки с неработающими стандартными комбинациями клавиш, — видимо автор также не знал или забыл о них. А сценарий "нажали на кнопку мышкой" отлично прошёл тестирование. Но что будет, если одновременно нажать Ctrl или использовать мультитач не проверялось — автор библиотеки так не делал, значит и пользователь хотеть не должен.
В общем, нарисовать контрол очень просто. Сложно сделать его удобным и совместимым со всеми средствами ввода и вывода.
W>Например, люди при работа с текстом перемещаются между контролами с использованием клавиатуры, но для этого нужно сделать tab index.
Нужно сделать, но это не сложно.
W>Скопировать текст ошибки из окна в буфер обмена? Стандартный диалог так умеет. А для кастомного нужно снова код писать. Или пользователю придётся вручную перенабирать текст.
Это да, нужно делать.
W>Забыли в своём коде отрисовки учесть DPI? Приложение выглядит мелко/крупно. И вообще есть проблемы с масштабированием.
Это в любом случаи нужно делать иначе, ОС сама растянет окно и будет плохо это выглядеть.
W>Стиль приложения может и единый, но зато в каждой ОС выглядит чужеродно.
Например TeamViewer — они сделали нативные контролы в MacOS, но в Windows они нарисовали такие же как в MacOS — выглядит неплохо (по моему мнению).
W>Адок с accessibility в широком смысле слова: например, содержимое нативных контролов ОС можно прочитать и ими можно управлять голосом. Если ты забыл написать соответствующий код, то в лучшем случае услышишь от своего приложения что-то вроде "номер вашего заказа <order.png>"
Вот это я НЕ учёт, спасибо
Здравствуйте, watchmaker, Вы писали:
W>Но похоже это та же причина, по которой в подобных интерфейсах постоянно повторяются одни и те же ошибки с неработающими стандартными комбинациями клавиш
Задолбало. Куча десктопного софта, где не работают в текстовых полях C-Ins, S-Ins, S-Del.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, maks1180, Вы писали:
M>4) ОС не будет знать состав контролов этого окна. Хакерам будет сложнее.
Security through obscurity? На самом нижнем слое всё равно придётся работать с системными сообщениями от мыши и клавиатуры, и obscurity будет насмарку.
