Хочу сделать (или найти) следующую реализацию контролов:
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 будет насмарку.
W>>Но похоже это та же причина, по которой в подобных интерфейсах постоянно повторяются одни и те же ошибки с неработающими стандартными комбинациями клавиш УП>Задолбало. Куча десктопного софта, где не работают в текстовых полях C-Ins, S-Ins, S-Del.
Абсолютно согласен!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, maks1180, Вы писали:
M>спасибо. Вы ей пользовались ? Она через DirectX рисует контролы ? Не пойму через что она в Linux будет рисовать и будет ли вообще ?
Когда-то для простого дебажного вывода использовал, для себя.
Officially maintained backends/bindings (in repository):
W>Например, люди при работа с текстом перемещаются между контролами с использованием клавиатуры, но для этого нужно сделать tab index. W>Скопировать текст ошибки из окна в буфер обмена? Стандартный диалог так умеет. А для кастомного нужно снова код писать. Или пользователю придётся вручную перенабирать текст. W>Забыли в своём коде отрисовки учесть DPI? Приложение выглядит мелко/крупно. И вообще есть проблемы с масштабированием. W>Стиль приложения может и единый, но зато в каждой ОС выглядит чужеродно. W>Адок с accessibility в широком смысле слова: например, содержимое нативных контролов ОС можно прочитать и ими можно управлять голосом. Если ты забыл написать соответствующий код, то в лучшем случае услышишь от своего приложения что-то вроде "номер вашего заказа <order.png>" W>
Ну и в копилку все стандартные контролы так или иначе доступны с клавиатуры, т.е. не только Tab, а и навигация стрелками, поиск в treeview/combobox и т.п.
Здравствуйте, maks1180, Вы писали:
M>Хочу сделать (или найти) следующую реализацию контролов: M>1) Приложение НЕ будет создавать контрол через Windows API, т.е. ОС не будет знать состав контролов этого окна M>2) вместо Windows, приложение само будет раскидывать сообщения по дочерным окнам (контролам).
M>Какие минусы у данного подхода ? M>Существуют ли такие реализации ?
В свое время у одной конторы были кастомные контролы (делали совместимость с маком). Потом на мак забили, а под винду долго перепиливали на стандартные.
Кроме уже озвученых причин, так же еще и поддержка тем: всякие контрастные, увеличенные и т.п. В основном это все актуально для слабовидящих.
Здравствуйте, maks1180, Вы писали:
M>Плюсы: M>1) потом планирую портировать приложение под Linux и Mac, думаю с таким подходом будет проще портировать M>и тестировать нужно будет только для 1 ОС полностью, а для остальных ОС только частично.
Это очень большой объем труда, если ты хочешь получить нормальный набор контролов нормального промышленного качества, а не детсадовскую поделку.
M>2) будет выглядеть и вести себя одинаково вне зависимости от ОС и версии ОС.
Это скорее недостаток, чем достоинство.
M>3) можно обойтись без тяжелых фреймворков, таких как QT
Когда-то все тяжелые фреймворки из таких примерно поделок и выросли.
M>4) ОС не будет знать состав контролов этого окна. Хакерам будет сложнее.
На нормальном дектопе можно одной настройкой поменять отрисовку всем приложениям. Например, сделать шрифт везде покрупнее. Если ты сам за себя, тебе придется или сделать это самому (причем для каждой системы), или твоя программа будет выделяться, причем не в лучшую сторону.
