> Ну, можно попытаться ускорить ваше приложение, используя вычисления на очень сложном и быстром Assembler'е.
Только предварительно прикинуть, покроет ли «сложный и быстрый ассемблер» затраты на P/Invoke и не создаст ли это дофига дополнительных проблем с разрядностью native-кода.
Если же рассматривать конкретно риббон, то до нормальной реализации еще как до Луны.
Не хватает таких замечательных вещей, как автоматический лейаут элементов в группах, автоматическое изменение их размера при необходимости (когда не помещаются), дроп-даун галерей, сворачивания, меню, Quick Access тулбара, etc.
На самом деле, на сайте MS есть целый мануал по проектированию ribbon-интерфейса. Так что если всерьез задумаетесь реализовывать, рекомендую ознакомиться :)
> Software as a service
А, ну все-таки веб-серсис. Это, конечно, «сетевая штучка», но по сути это просто класс, с которым умеет взаимодействовать веб-сервер.
> можно ли обеспечить взаимодействие с пользователем помимо использования Windows.Forms или нет?
Конечно можно. Консоль, WPF, сторонние вещи типа того же GTK#.
А на нормальном языке (т.е. английском) если? Ничего кроме веб-сервисов в голову не пришло, что могло вписаться в это понятие. Но уж им-то точно до лампочки браузеры… )
предположу, что оно завязано на компоненты IE и Windows так сильно, что полная реализация еще одной платформы для запуска .Net приведет только к созданию еще одного варианта Windows.
На Windows естественно завязано, иначе бы ни о какой абстракции от системы речь бы не шла.
На IE — сомнительно. Ну то есть Windows.Forms завязан (хотя бы из-за WebBrowser-а), а вот все остальное — уверен — вполне без него обойдется.
Хоть рантайм его и завязан на Windows, сам по себе .net платформо-независимый, как и java.
Mono — да, другое. Это кроссплатформенный недо-рантайм для MSIL. С кучей нереализованных методов и парой библиотек отсебятины, типа GTK#. Не будем на него отвлекаться.
Идеология .net с браузерами никак не связана.
Что такое сетевые штуки — для меня загадка, требуется помощь КО.
Пожалуй, только в названии связанность с сетью и отражена.
Что касается браузеров, то, как я уже упоминал, net-приложение может разве что хоститься в нем.
Как ActiveX (через специальный враппер) в IE и как Silverlight-приложение в любом браузере, где есть соответствующая поддержка.
Меняются разве что параметры безопасности в соответствии с зоной, в остальном приложению все равно, где и как оно выполняется (хотя технически оно и может узнать, в браузере или нет).
небыло IE небыло shlwapi появился IE появился shlwapi + shell32 свой прихватил чтобы Active Desctop был, нехорошо.
Это вывод из серии «не было ATI-шных дров, не было .NET фреймворка. Поставил дрова, поставился фреймворк. Вывод — фреймворк есть часть атишных дров» :)
То, что IE первым воспользовался shlwapi, не делает эту библиотеку частью IE.
ввод интернет адреса в проводнике в Windows 7 beta привоит не к отображению страницы внутри проводника, а к передачи управления браузеру по умолчанию
> С тех самых пор как пришёл на оси без встроенного IE из IE.
Мало ли, откуда он пришел? Он не содержит никаких завязок на IE, а вот на него завязан весь шелл, начиная с shell32.
SHDOCVW.dll — да, это обвязка к OLE-документам, в том числе и к WebBrowser. Но несмотря на то, что большинство ее экспортов являются форвардами к ieframe, explorer использует из нее только объект WinList.
Омг, какого виндовс-интерфейса через браузер?
Active Desktop, что ли? Так его уже давно нету.
Десктопные гаджеты? Ну, никто не заставляет их использовать.
Больше никакой интерфейс через браузер не рендерится.
Да хоть переход с Дос 6.0 на Дос 7.1 напомните — это никоим образом не объясняет, как в рамках одной конкретной системы наличие нескольких файлов влияет на производительность.
Неплохо бы еще добавить завязку на требуемый язык.
Ну и необходимо, чтобы эта ссылка еще и существовала на сайтах альтернативных браузеров. Это чья ответственность должна быть?
Только предварительно прикинуть, покроет ли «сложный и быстрый ассемблер» затраты на P/Invoke и не создаст ли это дофига дополнительных проблем с разрядностью native-кода.
Если же рассматривать конкретно риббон, то до нормальной реализации еще как до Луны.
Не хватает таких замечательных вещей, как автоматический лейаут элементов в группах, автоматическое изменение их размера при необходимости (когда не помещаются), дроп-даун галерей, сворачивания, меню, Quick Access тулбара, etc.
На самом деле, на сайте MS есть целый мануал по проектированию ribbon-интерфейса. Так что если всерьез задумаетесь реализовывать, рекомендую ознакомиться :)
А, ну все-таки веб-серсис. Это, конечно, «сетевая штучка», но по сути это просто класс, с которым умеет взаимодействовать веб-сервер.
> можно ли обеспечить взаимодействие с пользователем помимо использования Windows.Forms или нет?
Конечно можно. Консоль, WPF, сторонние вещи типа того же GTK#.
А на нормальном языке (т.е. английском) если? Ничего кроме веб-сервисов в голову не пришло, что могло вписаться в это понятие. Но уж им-то точно до лампочки браузеры… )
На Windows естественно завязано, иначе бы ни о какой абстракции от системы речь бы не шла.
На IE — сомнительно. Ну то есть Windows.Forms завязан (хотя бы из-за WebBrowser-а), а вот все остальное — уверен — вполне без него обойдется.
Mono — да, другое. Это кроссплатформенный недо-рантайм для MSIL. С кучей нереализованных методов и парой библиотек отсебятины, типа GTK#. Не будем на него отвлекаться.
Идеология .net с браузерами никак не связана.
Что такое сетевые штуки — для меня загадка, требуется помощь КО.
Пожалуй, только в названии связанность с сетью и отражена.
Что касается браузеров, то, как я уже упоминал, net-приложение может разве что хоститься в нем.
Как ActiveX (через специальный враппер) в IE и как Silverlight-приложение в любом браузере, где есть соответствующая поддержка.
Меняются разве что параметры безопасности в соответствии с зоной, в остальном приложению все равно, где и как оно выполняется (хотя технически оно и может узнать, в браузере или нет).
В то же время, как видно из истории версий, обновление его (как и остальных двух библиотек) на раннем этапе обусловлено в основном эволюцией IE.
Так что грань очень зыбкая, но все же к Win32 API, как и Common Control-ы.
Это вывод из серии «не было ATI-шных дров, не было .NET фреймворка. Поставил дрова, поставился фреймворк. Вывод — фреймворк есть часть атишных дров» :)
То, что IE первым воспользовался shlwapi, не делает эту библиотеку частью IE.
В Висте это было с самого начала.
Мало ли, откуда он пришел? Он не содержит никаких завязок на IE, а вот на него завязан весь шелл, начиная с shell32.
SHDOCVW.dll — да, это обвязка к OLE-документам, в том числе и к WebBrowser. Но несмотря на то, что большинство ее экспортов являются форвардами к ieframe, explorer использует из нее только объект WinList.
C:\>dumpbin -dependents c:\windows\explorer.exe Microsoft ® COFF/PE Dumper Version 9.00.30729.01 Copyright © Microsoft Corporation. All rights reserved. Dump of file c:\windows\explorer.exe File Type: EXECUTABLE IMAGE Image has the following dependencies: ADVAPI32.dll KERNEL32.dll GDI32.dll USER32.dll msvcrt.dll ntdll.dll SHLWAPI.dll SHELL32.dll ole32.dll OLEAUT32.dll SHDOCVW.dll UxTheme.dll POWRPROF.dll dwmapi.dll gdiplus.dll slc.dll RPCRT4.dll PROPSYS.dll BROWSEUI.dll Image has the following delay load dependencies: WINMM.dll SETUPAPI.dll WINSTA.dll OLEACC.dll WINBRAND.dll USERENV.dll Summary 3000 .data 9000 .pdata 1A000 .rdata 2000 .reloc 257000 .rsrc 74000 .textВ раритете типа 2000 естественно есть зависимости от ieframe — оно Active Desktop им показывает.
Ну, и для галочки: с каких это пор shlwapi стал компонентом IE?
Active Desktop, что ли? Так его уже давно нету.
Десктопные гаджеты? Ну, никто не заставляет их использовать.
Больше никакой интерфейс через браузер не рендерится.
Кстати, без гуевой подсистемы вообще он скорее всего не запустился бы, даже в режиме automation. Так что какой-никакой, а гуй нужен.
Кроме того, если сервер предполагается использовать как терминальный, то там без гуя тоже никак.
Ну и необходимо, чтобы эта ссылка еще и существовала на сайтах альтернативных браузеров. Это чья ответственность должна быть?
А глюков будет точно больше, т.к. есть доля программ, которые используют движок IE для своей работы.
Но при желании можно и включить.
Хотя, разумеется, на вкус и цвет…