Здравствуйте, WFrag, Вы писали:
AVK>>А чего хочешь?
WF>Ну... Хочу пописать что-нибудь.
Что именно? Если все равно, то смотри что тебя (других юзеров) в текущем хоуме не устраивает и предлагай варианты как это исправить. Будем обсуждать. Вот например нужно прикрутить стили (цветовые схемы, скины).
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WFrag, Вы писали:
AVK>>>А чего хочешь?
WF>>Ну... Хочу пописать что-нибудь.
AVK>Что именно? Если все равно, то смотри что тебя (других юзеров) в текущем хоуме не устраивает и предлагай варианты как это исправить. Будем обсуждать. Вот например нужно прикрутить стили (цветовые схемы, скины).
Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
Можно, например, как и с шоркатами — помечать Color-свойства специальным аттрибутом — что-то вроде ConfigurableColorAttribute, настраиваемый цвет.
Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
Здравствуйте, WFrag, Вы писали:
WF>Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
Сначала нужно сериализацию для цветов сделать. У нашего сериализатора конфигов позгов не хватает чтобы сохранить цвета.
В общем, вся задача сводится к превращению цвета в строку и обратно.
WF>Можно, например, как и с шоркатами — помечать Color-свойства специальным аттрибутом — что-то вроде ConfigurableColorAttribute, настраиваемый цвет.
Да их и помечать не нужно. Они и так ЦВЕТ. Вот только таких свойств пока нет. Color не сохраняется.
WF>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
Ничего не надо обходить. Есть такой класс Config. Это синглтон. Доступ к экземпляру Config.Instancr. Любое его публичное свойство или переменная сохраняется в хмл. Но сохранялка кривая и именно Color сохранять не умеет. Так что для начала для каждого цвета нужно завести по свойству в конфиге и создать врапер-класс для сериализации цвета в строку и обратно.
Далее везеде где есть цвета нужно встроить доступ к этим свойствам. Ну, а сохраннение и загрузка тем — это приметивный код который отбирает свойства типа ТвойВрапер и сбрасывает/загружает их значение в отдельный хмл-файл.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WFrag, Вы писали:
WF>>Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
VD>Сначала нужно сериализацию для цветов сделать. У нашего сериализатора конфигов позгов не хватает чтобы сохранить цвета.
Это не проблема. Поиск по РСДН-у, как и говорил АВК, дал вполне определенный результат.
VD>В общем, вся задача сводится к превращению цвета в строку и обратно.
WF>>Можно, например, как и с шоркатами — помечать Color-свойства специальным аттрибутом — что-то вроде ConfigurableColorAttribute, настраиваемый цвет.
VD>Да их и помечать не нужно. Они и так ЦВЕТ. Вот только таких свойств пока нет. Color не сохраняется.
WF>>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
VD>Ничего не надо обходить. Есть такой класс Config. Это синглтон. Доступ к экземпляру Config.Instancr. Любое его публичное свойство или переменная сохраняется в хмл. Но сохранялка кривая и именно Color сохранять не умеет. Так что для начала для каждого цвета нужно завести по свойству в конфиге и создать врапер-класс для сериализации цвета в строку и обратно.
Я хотел другой способ. Не формы/контролы опрашивают конфиг о цветах, а специальный менеджер обходит формы/контролы и устанавливает в них экспортированные (посредством аттрибута) цвета в значение из конфига. Аттрибут также нужен для описания цвета. Например вот так (в ForumDummyForm.cs):
[ConfigurableColor( "Фон дерева сообщений" )]
public Color TreeGridBack
{
get
{
return this.treeGrid.BackColor;
}
set
{
this.treeGrid.BackColor = value;
}
}
Далее отдаем на съедение нужные формы/контролы менеджеру, он их пробегает, строит список настраиваемых цветов, и вставляет их каким-нибудь образом в PropertyGrid, например. Или куда-нибудь еще, короче, дает возможность их изменить. После изменения, менеджер пробегает по всем данным ему контртолам и вставляет цвета. Этот способ хорош тем, что:
1. Все что нужно — "экспортировать" цвет, пометив свойство аттрибутом. В контроле декларируются визуальные свойства, которые можно настраивать (можно не только цвета, а в принципе, любое визуальное свойство контрола) — и менеджер тем дает пользователю их настроить.
2. Если цвет изменился — менеджер его может просто изменить у контрола, не нужно контролу самому откуда-то доставать цвета, устанавливать их при их изменении.
VD>Далее везеде где есть цвета нужно встроить доступ к этим свойствам. Ну, а сохраннение и загрузка тем — это приметивный код который отбирает свойства типа ТвойВрапер и сбрасывает/загружает их значение в отдельный хмл-файл.
Здравствуйте, WFrag, Вы писали:
WF>Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
WF>Можно, например, как и с шоркатами — помечать Color-свойства специальным аттрибутом — что-то вроде ConfigurableColorAttribute, настраиваемый цвет.
WF>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
Вот только нужно не только цвета, но еще и шрифты хотя бы настраивать.
Здравствуйте, VladD2, Вы писали:
WF>>Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
VD>Сначала нужно сериализацию для цветов сделать.
Да, проблема.
VD>У нашего сериализатора конфигов позгов не хватает чтобы сохранить цвета.
Сериализатор тут не при чем. При чем Color.
VD>В общем, вся задача сводится к превращению цвета в строку и обратно.
Эта задача уже решена, называется ColorTypeConvertor.
WF>>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
VD>Ничего не надо обходить. Есть такой класс Config. Это синглтон. Доступ к экземпляру Config.Instancr.
Я думаю не стоит в конфиге хранить всю схему. Лучше только имя файла, а саму схему в отдельном файле, чтобы человек мог просто готовый файл скачать.
Здравствуйте, WFrag, Вы писали:
WF>Я хотел другой способ. Не формы/контролы опрашивают конфиг о цветах, а специальный менеджер обходит формы/контролы и устанавливает в них экспортированные (посредством аттрибута) цвета в значение из конфига.
Мысль конечно правильная, но не факт что реализуемая. Сейчас нет никакой формализуемой структуры связей экземпляров элементов гуя. Кто то один раз создается и по сути синглтон, кто то поднимается по запросу, кто то дергается при каждом обращении. В общем продумывать надо, так сразу трудно что то определенное сказать.
WF>Далее отдаем на съедение нужные формы/контролы менеджеру,
А кто это будет делать?
WF> он их пробегает, строит список настраиваемых цветов, и вставляет их каким-нибудь образом в PropertyGrid, например. Или куда-нибудь еще, короче, дает возможность их изменить. После изменения, менеджер пробегает по всем данным ему контртолам и вставляет цвета. Этот способ хорош тем, что: WF>1. Все что нужно — "экспортировать" цвет, пометив свойство аттрибутом. В контроле декларируются визуальные свойства, которые можно настраивать (можно не только цвета, а в принципе, любое визуальное свойство контрола) — и менеджер тем дает пользователю их настроить. WF>2. Если цвет изменился — менеджер его может просто изменить у контрола, не нужно контролу самому откуда-то доставать цвета, устанавливать их при их изменении.
Есть у него и недостатки — структура схемы в общем случае не определена. Стоит подумать о жестком описании в xml-файле набора свойств, управляемых стилизатором.
Здравствуйте, AndrewVK, Вы писали:
WF>>Я хотел другой способ. Не формы/контролы опрашивают конфиг о цветах, а специальный менеджер обходит формы/контролы и устанавливает в них экспортированные (посредством аттрибута) цвета в значение из конфига.
AVK>Мысль конечно правильная, но не факт что реализуемая. Сейчас нет никакой формализуемой структуры связей экземпляров элементов гуя. Кто то один раз создается и по сути синглтон, кто то поднимается по запросу, кто то дергается при каждом обращении. В общем продумывать надо, так сразу трудно что то определенное сказать.
WF>>Далее отдаем на съедение нужные формы/контролы менеджеру,
AVK>А кто это будет делать?
Да, с этим проблема.
Хотя, можно, например, в конструкторе контрола регистрироваться в менеджере (менеджер — синглтон). При этом, менеджер может держать слабые ссылки на зарегистрированные контролы (чтобы не продлевать их жизнь зря).
WF>> он их пробегает, строит список настраиваемых цветов, и вставляет их каким-нибудь образом в PropertyGrid, например. Или куда-нибудь еще, короче, дает возможность их изменить. После изменения, менеджер пробегает по всем данным ему контртолам и вставляет цвета. Этот способ хорош тем, что: WF>>1. Все что нужно — "экспортировать" цвет, пометив свойство аттрибутом. В контроле декларируются визуальные свойства, которые можно настраивать (можно не только цвета, а в принципе, любое визуальное свойство контрола) — и менеджер тем дает пользователю их настроить. WF>>2. Если цвет изменился — менеджер его может просто изменить у контрола, не нужно контролу самому откуда-то доставать цвета, устанавливать их при их изменении.
AVK>Есть у него и недостатки — структура схемы в общем случае не определена. Стоит подумать о жестком описании в xml-файле набора свойств, управляемых стилизатором.
Ну да, можно просто в неком xml задавать, какие вообще бывают настройки стиля, т.е описание, название(ключ), тип. А контрол просто просит у менеджера по заданным ключам элемент стиля.
Получаем два варианта (которые могут быть реализованны одновременно):
1. Контрол сам опрашивает менеджера стилей (при этом контролу следует подписаться на изменения стилей).
2. Менеджер стилей сам устанавливает требуемые свойства (при этом контрол должен быть зарегистрирован в менеджере и размечен аттрибутами).
Ну и нужно держать синхронизованными xml-описание схемы стиля и код, использующий ключи для доступа к параметру схемы.
Здравствуйте, WFrag, Вы писали:
WF>Ну да, можно просто в неком xml задавать, какие вообще бывают настройки стиля, т.е описание, название(ключ), тип. А контрол просто просит у менеджера по заданным ключам элемент стиля.
Подумал еще немного . Смысла делать xml с набором свойств, управляемых стилизатором, по-моему, нет. Все равно он будет сильно завязан на код, поэтому, все же, самый простой вариант будет сделать конфиг, такой же, как и Config.cs.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WFrag, Вы писали:
WF>>Короче, может стоит начать все это делать?
AVK>Ну сделай пока тестовый проектик, без януса.
Здравствуйте, AndrewVK, Вы писали:
WF>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
AVK>Вот только нужно не только цвета, но еще и шрифты хотя бы настраивать.
Да какая разница. Если задать фрифт для формы/контрола, то все цвета и шрифты которые небыли заданы вручную будут считаны с парента.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>Сначала нужно сериализацию для цветов сделать.
AVK>Да, проблема.
Да. Я вот дернулся... думал все просто. А оказалоь, что не очень.
Мне нужно в программе иметь доступ к ывету, а не к стороке (иначе будут тромоза). Да и самому броузеру свойство тоже нужен колор (он, то вотличии от кривого сериалайзера цвет понимает). А сериализовать нужно именно строку. Конвертер конечно есть, но вызывать его должен именно сериалайзер. Надо бы что-то там поправит, если публичных свойств нет, чтобы производилась попытка конвертировать в строку.
VD>У нашего сериализатора конфигов позгов не хватает чтобы сохранить цвета.
AVK>Сериализатор тут не при чем. При чем Color.
Не надо песен. Форматеры цвет сохраняют влет. Он атрибутом Serializable помечен.
VD>В общем, вся задача сводится к превращению цвета в строку и обратно.
AVK>Эта задача уже решена, называется ColorTypeConvertor.
Языком. А ты сделай чтобы твой конфиг цвета сериализовал.
AVK>Я думаю не стоит в конфиге хранить всю схему. Лучше только имя файла, а саму схему в отдельном файле, чтобы человек мог просто готовый файл скачать.
Зачем эти сложности? Ваши схемы — это не боле чем набор цветов, который просто нужно в тупую копировать поверх текущих.
Не надо делать извращений. Иначе нельзя будет поменять один цвет.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WFrag, Вы писали:
WF>Это не проблема. Поиск по РСДН-у, как и говорил АВК, дал вполне определенный результат.
Не проблема? Ну, так во и реши ее для начала. Причем так чтобы в будущем не приходилось трахаться с каждым таким свойством.
WF>Я хотел другой способ. Не формы/контролы опрашивают конфиг о цветах, а специальный менеджер обходит формы/контролы и устанавливает в них экспортированные (посредством аттрибута) цвета в значение из конфига. Аттрибут также нужен для описания цвета. Например вот так (в ForumDummyForm.cs)
Да не нужен никакой менеджер. Есть только цвет фона и текста. Которые прекрасно можно установить на основную форму. Остальные съедят его автоматом. А цвета вроде цвета подсветки ответов один фиг из конфига читать.
И вообще схема на собятиях будет надежнее обхода. Ведь если свойство не стандартное, то твой обход обламается.
WF>Далее отдаем на съедение нужные формы/контролы менеджеру, он их пробегает, строит список настраиваемых цветов, и вставляет их каким-нибудь образом в PropertyGrid,
Озверел что ли? Это будет список из 1000 посзиций.
Нужно ввести пару цветов общих и еще штуки 3-6 специальных. Не выдумывай сложностей. К тому, же теперь контролы и формы не грузатся при загрузке, а подгружаются по требованию. Так что ты просто их не увидишь.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WFrag, Вы писали:
AVK>>>Ну сделай пока тестовый проектик, без януса.
WF>>Что именно?
AVK>Ну то что ты тут расписывал.
Здравствуйте, WFrag, Вы писали:
WF>Хотя, можно, например, в конструкторе контрола регистрироваться в менеджере (менеджер — синглтон). При этом, менеджер может держать слабые ссылки на зарегистрированные контролы (чтобы не продлевать их жизнь зря).
Тогда проще уж в этом конструкторе считать цвета и устанвить.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
