На просторах сети частенько можно наткнуться на споры про то, что же лучше - стрелочные приборы или цифровые.
Что же лучше? Предлагаю проверить на практике c помощью программы-теста, которая измеряет время, необходимое на считывание значений со стрелочного индикатора и цифрового.
В первой части были рассмотрены системные настройки масштабирования, предоставляемые встроенными утилитами, и набор возможностей отличается кардинально. Почему? Потому что в Linux нет единого API для работы с масштабированием, каждое окружение конфигурирует по своему и каждый UI-toolkit определяет их по своему, в итоге шанс того, что что-то где-то будет отображаться криво очень велик.
В этой статье мы рассмотрим то, как определить коэффициенты масштабирования для X11 приложения самостоятельно.
Дисплеи с высокой плотностью пикселей уже давно не редкость. И для того, чтобы UI не выглядел слишком мелко, применяется масштабирование. В разных системах используются разные подходы и имеются различные возможности настроек. Но одно объединяет их все - безмерное количество кривизны, костылей и глюков. Посмотрим как на сегодняшний день обстоит ситуация в лагере Linux.
Технологически в этой статье ничего нового, просто еще одно полезное применение winapi-хуков для решения специфичной проблемы.
При работе с веб-проектами в Visual Studio существует одна неприятная мелочь — при использовании в процессе разработки нескольких бранчей, каждый из которых должен использовать свою копию окружения (например базу данных, или какие то внешние сервисы), возникает проблема с конфигурационными файлами в момент отладки — IISExpress использует только основной web.config в папке проекта, где обычно всякие connection strings содержат значения по умолчанию и где нет никаких специфичных для бранча настроек, и никаких трансформаций при запуске к нему не применяется. Можно конечно принудительно либо автоматически, либо вручную, применять трансформации к web.config, но во-первых измененный файл будет постоянно висеть в pending changes, что создает риск коммита нежелательных изменений, которые потом попадут в другие бранчи, а во-вторых это создает массу неудобств при его редактировании, поскольку перед коммитом каких-либо изменений в конфигурационном файле такие трансформации придется вручную убирать.
Как известно, контрол WebBrowser это просто обертка над ActiveX компонентом Internet Explorer. Следовательно он предоставляет доступ к полноценному layout-движку со всеми современными плюшками. А раз так, то попробуем (сам не знаю правда зачем) на его основе сделать пользовательский интерфейс для обычного windows-приложения.
Можно, конечно, было бы запустить в этом же процессе мини веб-сервер (на HttpListener например) и ловить запросы через него, но это слишком просто, скучно и неспортивно. Попробуем обойтись без сетевых компонентов, just for fun.
Итак, допустим в сферическом C# проекте необходимо использовать какую-либо технологию, отсутствующую в .NET, и все что у нас есть это Windows SDK 8.1 в котором имеется лишь набор заголовочных файлов для C/С++. Придется объявлять кучу типов, проверять корректность выравнивания структур и писать различные обертки. Это большое количество рутинной работы, и риск допустить ошибку. Можно конечно написать парсер заголовочных файлов… Тут просто и понятно все кроме количества требуемых на это человекочасов. Поэтому этот вариант отбрасываем и постараемся как либо иначе свести к минимуму количество необходимых действий для взаимодействия с unmanaged кодом.
Кроме того, полученный в результате код не будет зависеть от разрядности процесса, будет сохранена строгая типизация, будет применено автоматическое тестирование.
