воскресенье, 18 ноября 2007 г.

Битва продолжается. The Return of the Evil Bug :о)

Работы по внедрению движка как плагина продолжаются. Как оно всегда бывает, на тестовой программе все выполняется нормально, а в боевых условиях начинают выползать баги невесть откуда. Вот и сейчас я столкнулся как минимум с тремя багами, которые пытаюсь вовсю побороть. Часть из них - мои, часть порождены библиотекой CoolSB, часть - самой системой... Ну чтож, ничто не идеально:) По крайне мере, большинство своих багов и багов CoolSB я локализовал и пытаюсь исправить. Приятная новость заключается в том, что скорее всего в ядро вкомпиливать код не прийдется, движок сможет функционировать наравне с обычными плагинами в рамках SDK. По крайней мере, я приложу к этому все усилия.

Информация разработчикам плагинов на делфи:
Готовьтесь к тому, что вам прийдется перекомпилировать ваши детища, позже я выложу модуль (здесь и на форуме), который нужно будет подключить к проекту, чтобы плагин корректно работал и не выдавал багов при взаимодействии с движком.

Информация всем разрабочикам плагинов:
Кроме того, после выхода альфы я так же выложу модуль с SkinSDK, и вы сможете управлять процессом скиннинга - перерисовывать свои собственные/нестандартные компененты/контролы; Убирать скиннинг со своих контролов/окон. И все это будет возможно сделать вызовом 5-6 функций, наподобие в MS Themes API.

З.Ы. Работа близится к завершению, это не может не радовать :о)

16 комментариев:

Shedko комментирует...

Хм, если как плагин, то соответственно ThemeAPI.dll должна лежать как минимум в папке квипа, чтоб функции были доступны из плагинов. Т.е. надо разделить функционал н 2 библиотеки, отсюда возможность использования этой themeapi.dll в сторонних программах =)

Это будет именно так? Т.е. 2 дллки.


если нужен тестер на висте - готов =)

Sega-Zero комментирует...

Нет. все будет лежать в одной dll, а доступ будет через интерфейс, причем опосредованно - доступ будет из ядра Qip через IQIPPlugin. Позже в ядро будет добавлен соответствующий интерфейс и добавлен в паблик SDK. К тому же, плагин будет жестко прошит к путям квипа и, думаю, тем, кто пожелает воспользоваться плагином в своих программах, будет очень неудобна такая структура :о)
В сторонних программах при желании смогут использовать в любом случае, но тут нас спасет лицензия и (надеюсь) внимательность наших пользователей;)

Ну а до тестинга пока дело не дошло:)

Анонимный комментирует...

Хм, вообще будет не очень приятно - если появятся плагины, которые будут требовать другой плагин (например этот), т.е. реализовать возможность отрисовки своих "кустомных" компонентов по средством themeAPI, то надо вроде как ЗАСТАВЛЯТЬ разработчиков писать интерфейс сс учетом того, что скины могут быть включены и тогда используется "квиповский" метод прорисовки, а если не включен - о тогда своими методами.

Отсюда - далеко не все будут следовать этому, банальная лень. Т.е. почти гарантия появления плагинов, которые будут зависеть от этого плагина =(

Или я не прав ?

Sega-Zero комментирует...

Напротив. Это будет опционально. Если разработчик захочет, чтобы его окна и контролы так же выглядели в едином стиле, то он слегка подправит отрисовку компонентов. Если не захочет - то останется стандартная отрисовка. Или наоборот - если разработчик вообще не хочет, чтобы применялись скины к его окнам, то он вызовет соответствующую функцию. Все это займет лишних пару строк кода.

Все вариации контролов я естественно предусмотреть не могу. Я могу лишь изменить поведение стандартных, часто встречающихся контролов. Но если будет использоваться какаой то нестандартный контрол, с нестандартным поведением, то тут уж только через SkinSDK.
Заставлять конечно же никого не будем, как MS никого не заставляет использовать темы в XP.;)

Плюс к вышесказанному смею добавить, что изменение компонента под скины в квипе будет очень легким. Я старался сделать движок по поведению максимально приближенным к MS Styles API, поэтому разработчику всего то и нужно будет, что проверить, включены ли скины и вызвать 1(!!) функцию - DrawElement с 3-4 параметрами. Если интересно как это будет примерно выглядеть - то почитайте модуль Themes в делфи. Использование тем там ну очень простое;)

Sega-Zero комментирует...

Да, и еще насчет зависимости. Посмотрите на темы в ХР. Даже написав супер пупер контрол с использованием тем он не будет работать в вин2000. Так же и тут - если плагин будет отключен или вообще будет отсутствовать, то вызов функций попросту ни к чему не приведет.

Анонимный комментирует...

а может стоит еще к плагину модуль приписать, что бы скины к винде применять, по типу WindowBlinds?

Sega-Zero комментирует...

Ну, поведение движка похоже на WindowBlinds. Только вот зачем его применять ко всей системе? Используйте WindowBlinds или StyleXP, что вам мешает?

Плагин предназначен только для квипа. точка.

Анонимный комментирует...

По поводу ?"Заставлять конечно же никого не будем, как MS никого не заставляет использовать темы в XP.;)"

Хм, но ведь все равно чтобы можно было запускать программы по полной использующей стили оформления их приходится писать с динамической загрузкой DLL и писать как минимум 2 варианта отрисовки контролов - т.е. для случаев когда темы есть и когда нет. Т.е. не написав "отрисовку" без тем и не сделав проверку на наличие/включенность тем - получим попытку вызова несуществующей функции ?

Или все таки часть кода отвечающего за темы будет в самом ядре квипа ?



Да, и еще насчет зависимости. Посмотрите на темы в ХР. Даже написав супер пупер контрол с использованием тем он не будет работать в вин2000. Так же и тут - если плагин будет отключен или вообще будет отсутствовать, то вызов функций попросту ни к чему не приведет.

Что значит ни к чему не приведет =) ? Т.е. контрол не "отрисуется" ? =)

А независимость саморисуемых контролов от тем ХР делается же динамической подгрузкой и выгрузкой библиотеки тем.


Хотя все равно, может я слишком усложняю =)

Sega-Zero комментирует...

чтобы можно было запускать программы по полной использующей стили оформления их приходится писать с динамической загрузкой DLL и писать как минимум 2 варианта отрисовки контролов - т.е. для случаев когда темы есть и когда нет. Т.е. не написав "отрисовку" без тем и не сделав проверку на наличие/включенность тем - получим попытку вызова несуществующей функции

Безусловно. Именно так запрограммированы контролы в ХР и висте - вначале проверяется, включены ли темы и дальше идет соответсвтующая отрисовка. В этом можете убедиться, почитав исходники, скажем, в делфи. Обратите внимание на обилие проверок if ThemeServices.ThemesEnabled

Отличие от ThemesAPI будет в том, что управлять загрузкой тем будет нельзя. (как например OpenThemeData - такого не будет, во всяком случае пока). Програмист может быть лишь осведомлен о том, включены скины или нет и уже идти от этого.

Что значит ни к чему не приведет =) ? Т.е. контрол не "отрисуется" ? =)
А вот это уже ложится на плечи разработчика. Будет зависеть от того, как он предусмотрит все возможные варианты. "чисто хршных" контролов же нет?

З.Ы. Не усложняйте то, что должно быть простым =) Пример использования я включу в SDK, не думаю, что с этим возникнут какие то сложности.

З.З.Ы. Так как я все таки разработчик движка и имею доступ к своим исходникам =), то всегда можно что-то изменить/поменять

Shedko комментирует...

Просто хотел выяснить по какому из вариантов работает
1. как ThemeAPI в Windows ( т.е. плагин должен использовать это апи, чтоб "оскиниться" )
2. как WindowBlinds - программа сама перерисовывает и плагин ничего не знает об этом.

Как понял - 1 вариант, в общем да, увидим пример использования - узнаем все тонкости =)

Sega-Zero комментирует...

Ну, в общем да. Первый вариант. За исключением того, что все стандартные контролы будут скиниться по умолчанию (если по аналогии - это все равно что подключить манифест к программе и все контролы, которые "понимает" windows становятся "темными").

Shedko комментирует...

И как скоро будут первые доступные RC ?

Если конечно есть такие сроки (а то кто его знает, что еще может всплыть)

Sega-Zero комментирует...

ну, надеюсь в скором времени сделать альфу. Ждите :о) Хочу успеть к концу ноября.

Shedko комментирует...

Исходя из
все будет лежать в одной dll, а доступ будет через интерфейс, причем опосредованно - доступ будет из ядра Qip через IQIPPlugin. Позже в ядро будет добавлен соответствующий интерфейс и добавлен в паблик SDK.


хм, вот так случайно мы узнали дату следующего релиза qip infium ? =)

Sega-Zero комментирует...

ну, SkinAPI я обещал не в первом релизе :о) для этого нужно еще подправить ядро :-Р

Анонимный комментирует...

Я вообще то предложил загрузчик во все программs по типу WindowBlinds тк последний денег просит, а имея готовый движок не использовать функционал глупо.