Есть приложение которое висит в трее. Из UI всего лишь окно настроек. Подумал, почему бы не реализовать окно настроек в виде странички в браузере, которое приложение открывает при выборе пункта меню из трея. В связи с чем несколько вопросов:
Во-первых, как думаете, насколько это будет удобно? Особенно простым пользователям, для которых браузер ассоциируется в первую очередь с интернетом.
Второе, какие могут быть проблемы в реализации? С одной стороны вроде бы не сложно: начинаем слушать любой свободный порт, формируем страницу с учетом адреса localhost:ПОРТ для запроса, отдаем ее или через тот же порт или же сохраняем локально, открываем в браузере соответствующую страницу. После парсим запрос POST или GET и применяем новые настройки. Но может кто-то увидит не очевидные мне проблемы?
Здравствуйте, Ruzzz, Вы писали:
R>Во-первых, как думаете, насколько это будет удобно? Особенно простым пользователям, для которых браузер ассоциируется в первую очередь с интернетом. R>Второе, какие могут быть проблемы в реализации? С одной стороны вроде бы не сложно: начинаем слушать любой свободный порт, формируем страницу с учетом адреса localhost:ПОРТ для запроса, отдаем ее или через тот же порт или же сохраняем локально, открываем в браузере соответствующую страницу. После парсим запрос POST или GET и применяем новые настройки. Но может кто-то увидит не очевидные мне проблемы?
Усложнения вы добились, а вот преимуществ как-то не видно. Они есть?
Здравствуйте, Ruzzz, Вы писали:
R>Но может кто-то увидит не очевидные мне проблемы?
Web UI чрезвычайно беден и заметно отличается от общепринятого в системе. Будет глючить при отключении JavaScript и картинок. Будет удивлять на ровном месте тем, что оно в браузере. Может попасть под Parental Control, блокирующий доступ в интернет после 22:00.
Здравствуйте, Ruzzz, Вы писали:
R>Во-первых, как думаете, насколько это будет удобно? Особенно простым пользователям, для которых браузер ассоциируется в первую очередь с интернетом.
Лучше реализуй свою прогу целиком как плагин к браузеру, если такое возможно, конечно.
Если невозможно — реализуй только настройки.
Это гораздо лучше, чем какая-то левая страница.
У меня добрая половина мелких утилит была снесена и переехала в файрфокс.
Типа world clock -> FoxClocks, напоминалки/таймеры -> SimpleTimer...
Все равно браузер все время включенным висит.
Здравствуйте, Ruzzz, Вы писали:
R>Есть приложение которое висит в трее. Из UI всего лишь окно настроек. Подумал, почему бы не реализовать окно настроек в виде странички в браузере, которое приложение открывает при выборе пункта меню из трея. В связи с чем несколько вопросов: R>Во-первых, как думаете, насколько это будет удобно? Особенно простым пользователям, для которых браузер ассоциируется в первую очередь с интернетом.
Очень неудобно. Сейчас крик души будет
К примеру, на какой порт будете "вешаться"? У меня вот софт к материнке развернул так апач, а потом я не мог понять, почему IIS глучит.
К слову подобная штука была со Скайпом, у него там в нутрях была настройка "Использовать порт" и по умолчанию стояло 80. Я месяц не мог понять, почему в половине случаев загрузки компа IIS не работает. А работать то надо.
Но ладно, я то девелопер, а как пользователям быть, если скажем Скайп с другой программой порты не поделят.
Здравствуйте, Ruzzz, Вы писали:
R>Второе, какие могут быть проблемы в реализации? С одной стороны вроде бы не сложно: начинаем слушать любой свободный порт
Для передачи контента в UI, построенном на базе встроенного браузера, есть более правильный способ: Asynchronous Pluggable Protocols.
Суть в том, что в системе регистрируется handler, которому отправляются все запросы на документы с заданной схемой.
Например так реализована работа просмотрщика файлов chm: на время работы приложения hh.exe зарегистрирована схема mk, и все адреса, начинающиеся на mk: отправляются прямо в hh.exe, и он генерит контент. Т.е. TCP и порты вообще не используются, общение идет напрямую. Раньше через этот же механизм работал весь help в MSVS.
Подобным образом сделано в Outlook, когда он показывает письмо в формате html с картинками внутри текста. Эти картинки берутся прямо из самого письма, не сохраняясь во временные файлы. TFS использует этот же подход.
Кстати, если нужно простое решение в котором всего одна страничка и нет картинок, то можно сгенерить ее во временный htm файл и открыть его через ShellExecute. Если же нужны картинки (или другие статичные странички), их можно уложить в ресурсы в DLL и доставать по url с встроенной в Windows схемой res:
Здравствуйте, sergeyt4, Вы писали:
S>Для передачи контента в UI, построенном на базе встроенного браузера
Так то ж встроенный... Мы можем контролировать загрузку вообще всего что угодно, а регистрация своих протоколов — это способ быстро отличить кастомизированное содержимое от обычного. Можно отличать медленнее, без регистрации протокола, а просто смотреть каждый урл и выискивать в нём признаки.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, sergeyt4, Вы писали:
S>>Для передачи контента в UI, построенном на базе встроенного браузера
К>Так то ж встроенный... Мы можем контролировать загрузку вообще всего что угодно, а регистрация своих протоколов — это способ быстро отличить кастомизированное содержимое от обычного. Можно отличать медленнее, без регистрации протокола, а просто смотреть каждый урл и выискивать в нём признаки.
Не только встроенный. Если вы зарегистрировали обработчик для определенной схемы url, то все браузеры будут получать контент из вашего обработчика, если схема (т.е. то, что идет до двоеточия) в url совпадает с вашей.
Re[2]: Локальные приложения с UI в браузере
От:
Аноним
Дата:
18.12.11 07:00
Оценка:
Как это поможет с написанием кроссплатформенного приложения?