Доброго времени суток!

Сначала позволю себе небольшое вступительное слово..
Жил да был себе дизайнер для компонента в версии 1.8... Но так исторически сложилось, что в версии 2.0 он очень кардинально изменился. У него появился ряд дополнительный возможностей, внешний вид стал краше.. Но! Сделалось невозможным безболезненно его использовать пользователям старой версии дизайнера... Дизайнер выделился в отдельный модуль, формирующий exe-файл, оброс нестандартными или тяжелыми компонентами.. Получаем с одной стороны - возможности, с другой - длительная загрузка..

Что уже сделано?..
Вопрос с выделением дизайнера в отдельный exe-файл я уже решил, теперь это будет "опциональным" (позже если будет нужно выложу свои наработки). Также я сделал версию 1.8 дизайнера способной использоваться для компонента версии 2.0 (до сих пор использую старый дизайнер) (тоже если кому-то нужно могу выложить).
Остался только извечный вопрос с "компонентным" наполнением дизайнера.. Кому-то хочется, чтобы дизайнер был проще и быстрее грузился, кто-то не прочь использовать дополнительные компоненты либо просто "утяжелять" дизайнер, ну а кому-то может просто не нравится визуализация какого-то одного свойства. Вопрос: что можно сделать, чтобы всем угодить?..

Есть некоторая идея..
Почему бы не сделать дизайнер фреймовым? То есть разделить дизайнер на составные части как по панелям, так и по коду/дизайну 
Я предлагаю следующее. Есть базовая форма, которая содержит структуру панелей и основной код по их взаимодействию. Каждая панель (дерево правил, свойства выделенного правила, атрибуты выделенного правила, пример кода) представляет собой фрейм. Есть так называемый абстрактный фрейм, в котором определены методы, с помощью которых к нему сможет обращаться базовая форма. И фрейм-наследник от абстрактного фрейма, который содержит визуальное наполнение и реализацию абстрактных методов.

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

К примеру, на вскидку, я вижу такие необходимые вариации составных частей:
Дерево правил:
 • основанное на стандартном TreeView (как в дизайнере 1.8)
 • унаследованное от первого и расширенное возможностями
 • основанное на VirtualTreeView (как в дизайнере 2.0)
Свойства правил:
 • компактные визуально и ненагруженные компонентно (для быстрой загрузки дизайнера) (1.8)
 • расписанные подробно и изобилующие ComboBox'ами (как выяснилось, вследствие чего очень существенное замедление загрузки) (2.0)
Атрибуты правил:
 • самопальные панельки (1.8)
 • ColorBox'ы из компонентов Delphi7 (2.0)
 • ColorGrid как в настройках Delphi
 • любая другая более удобная реализация (тут уж можно пофантазировать)
Пример кода:
 • самый обычный, стандартный SynEdit
 • любые вариации дизайна (градиент, шрифт, нумерация и т.д. и т.п.)

Теперь такой вопрос: нужно ли делать такой механизм и будет ли он востребован?.. (хотя признаюсь, что реализацию я уже начал)
   

Это сообщение отредактировал(а) Vitalik - 24.6.2006, 17:19

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 11:27

Собственно очень тебя понимаю, ты даже статью по нему написал 
Но! Ведь во встроенном дизайнере его использовать все равно не пристало 
А делать вилки жутко не хочется 


Буду ждать с нетерпением 


Ну атрибуты - это выбор цвета и стиля шрифта для выделенного правила. 
Три варианта реализации этого механизма можно увидеть на двух версиях UniHighlighter'а (1.8 и 2.0) и на реализации этого  в самом Delphi (редактирование цветов кода в самом Delphi) 


Так это ж на то и вариации, что получается не "менять", а "выбирать". Ну, к примеру, кому-то очень (ну очень) мешает gutter на примере кода, допустим? Так что ему из-за этого вилку дизайнера делать? Нет, теперь этого можно будет не делать, просто правится маленький фрейм примера кода и потом этот фрейм можно вставлять в новые версии дизайнера 


 

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 01:56

Жду от тебя скрин 


А если не первоначально? Если ты уже порядочно работал с компонентом?  Таких же пользователей тоже не мало 
А если этого хочет (к примеру) один из авторов компонента? 


Вот как раз теперь такое менее вероятно, так как будет уже НЕСКОЛЬКО дизайнеров и можно будет уже выбирать по вкусу.  А разбираться в фреймовом дизайнере будет в несколько раз легче, чем в дизайнере состоящем из одного огромного файла 


Это несомненно надо сделать. Безусловно! НО! Это уже будет не 2.0 версия, а совершенно новая. А ведь Vit резонно заметил, что за всю историю существования компонента не было ни одной стабильной версии. Можно разрабатывать новую версию и приводить в порядок текущую (паралельно)  

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 11:28

Угу, это было бы просто замечательно 


Этим отделаться будет невозможно.. Так как ведь реализация взаимодействия с формой будет сильно различаться 


Ну чем она недееспособна? По-моему там действительно только дизайнер похрамывает, сам компонент работает довольно стабильно.. Мы ведь фичу с регэкспами решили в 2.0 не прикручивать 
Ну а так мы сделаем еще одну недееспособную версию 

Что думаешь, про написанное Vit'ом в теме "Глас вопиющего в пустыне"? Только если отвечать, то лучше в соответствующей теме   

Это сообщение отредактировал(а) Vitalik - 24.6.2006, 21:55

Лично мое мнение как пользователя вашего замечательного компонента: =)
Не надо никаких понтушек к дизайнеру прикручивать! Сколько вы встречали мега прог на компоненте весом по 20 метров? Мне кажется что в основном проги мелкие. Так что дизайнер должен обеспечивать полную функциональность в минимальном размере файла. Если юзер захочет скины в дизайнере , то он их сам прикрутит, причем в том же формате что и его прога и.т.д. 
Насчет фреймов я не профи программер, идею не понял. Почему это если я захочу что то исправить, то я не создам новую вилку? Просто надо дизайнер понятно писать, чтоб читалось легко. Сейчас там некоторые места гениально просто сделаны, а в некоторые не сразу вьезжаешь зачем вообще нужны. Если мне захочется интерфейс его на TBX или VirtualTreeView сделать, то это будет легко, если я буду наглядно видеть как писать и читать свойства.
По поводу использования VirtualTreeView под дерево - тут ничего не могу сказать. Конечно обьем увеличивает. Но зато работать легко и данные внутри себя хранит. Как решите с ним так и будет, это не главный вопрос.
Главный вопрос чтоб все работало хорошо и стабильно, разбираться легко с нуля было. Прошу побольше структурных коментариев в дизайнере. 

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


а вот это врядли, ибо аналогов на паскале нет (или есть?) и проще написать свой дизайнер чем свой хайлайтер 

вы ж не забывайте - ваши юзеры - программеры, и рюшечки, если они им надо, легко прикрутят сами.
 

Гм.. Та дело сейчас стоит не столько с "улучшением" дизайнера или добавлением к нему рюшечек..
Все гораздо печальнее. Ведь если разобраться, то дизайнер версии 1.8 еще не умеет работать с CodeFolding и MultiTokens, а версия 2.0 дизайнера жутко нестабильна (частенько встречаются Access Violation'ы).. 
Так что дееспособного дизайнера сейчас попросту нету.. 


Фрейм - это как бы маленькая форма, которая может быть внутри других форм. Хранится фрейм в отдельном файле. Работа с ним не практически не отличается от работы с формой. Также от фрейма можно наследоваться. Можно кинуть на форму и менять только некоторые свойства или внешний вид (как у обычной формы).


Вариант 1. Ты создашь вилку только для одного какого-то фрейма, а весь движок (базовая форма и остальные фреймы) останутся без изменений. Далее ты просто сможешь этот свой новый модифицированный фрейм использовать в новых версиях дизайнера.
Иначе бы тебе пришло каждый раз вносить свои изменения в новые версии дизайнера (заменяя только один этот файл) 
Вариант 2. Можно просто кинуть все фреймы на базовую форму и потом уже менять чисто косметику этих фреймов, сам же их движок будет находиться в своем старих файлах и затронут при этом не будет. В большинстве случаев (кроме каких-то критических) можно будет даже безболезненно заменять старые файлы движка фрейма на новые. Наследники это могут даже не заметить 


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


Кстати, я над этим думал. Базовая форма не будет содержать меню и панель инструментов, но будет содержать весь код. Можно очень просто унаследоваться от базовой формы и безпроблемно добавить меню и тулбар какие будет необходимо, опять же совершенно не затрагивая при этом программную архитектуру дизайнера! 


Угу.. И положительные и отрицательные стороны.. А другого способа (кроме фреймов) совместить в дизайнере использование двух вариантов (VirtualTree и TreeView) и при этом без создания вилок - я не вижу..


Тут ты, конечно, прав.. Может быть, поэтому даже отодвину разработку дизайнера на второй план, хоть меня это и очень печалит.. 


P.S. Очень бы хотелось услышать мнение Vit'а по всему этому поводу  

Привет! Прежде чем писать свое мнение про новый дизайнер хотелось бы задать несколько вопросов. 

1. Несовсем понятно какой версии дизайнер я использовал раньше. В нем нигде почему-то не указана версия. Можно только сказать что размер файла HglEditor.exe - 318 Кб.

2. Что значит выделение дазайнера в отдельный exe-файл (и его опциональность)? Он же и так уже в отдельном exe-файле находится.

3. Нащет скорости загрузки дизайнера - то даже если загрузка будет длится 1-2 секунды - то это терпимо. Я бы лучше отдал предпочтение более функциональному (и возможно более красивому) интерфейсу. Но это лично мое мнение. Тяжело конечно всем угодить. Я в таком случае брал пример с известных продуктов, которые улучшаясь увеличивались в размере и требованиях к железу. Тут ничего не поделаеш. И так как программа требует улучшений, и без потерь в скорости загрузки тут не обойтись, то тем, кому хочется минимум возможностей и максиммум скорость загрузки прийдется терпеть и привыкать. А вот улучшения в программе - это только хороше.

4. Фреймовость дизайнера. По себе знаю, что дизайнер мне приходится использовать только тогда, когда нужно отредактировать файл подсветки. Делаю я это очень редко (может быть даже 1 раз). Если есть кто-то, кому приходится запускать и редактировать подсветку чаще - интересно было бы узнать, для каких целей им нужно так часто редактировать подсветку. Другими словами, я бы не останавливался долго над разработкой фреймовости, а основное внимание обратил бы на небольшой (до мегабайта) размер exe-файла, функциональность и понятность интерфейса. А вобще, хотелось бы увидеть хоть бы скриншоты, чтобы понять что именно имеется в виду и как оно выглядит.   

Ну размер файла мне говорит меньше всего.. 
Могу предположить, что у тебя версия 1.8, а может быть даже 1.5 
Приведу несколько скриншотов для безошибочного определения версии дизайнера 

Версия 1.0
Самый первый дизайнер


Следующие три скриншота на первый взгляд очень похожи, поэтому дам некоторые пояснения 

Версия 1.5
Отличительной чертой является возможность работы со встроенными цветовыми схемами


Версия 1.8
Появилась возможность управления стилями, интерфейсные задатки мультитеговости и возможность временно отключать отдельные правила


Версия 1.8 (обновленный до использования в UniHighlighter 2.0)
Возможность работы с CodeFolding и работающая мультитеговость


Версия 2.0
Отличить я думаю можно без проблем 



Имеется в виду наоборот: возможность использования не только в качестве exe-файла  
А, например, вызывать его напрямую в исходниках 


Спасибо за оставленное мнение 


Я, например, использую редактор довольно часто 
Я даже не говорю за банальную подготовку подсветок, просто иногда бывает нужно либо функции некоторые подсветить, либо хитрые комментарии 
Да и цветовые вкусы они ведь не постоянны в конце концов 


Скриншоты чего ты имеешь в виду?  

Vitalik, спасибо, узнал, что у меня версия 1.8 (не обновленная).

Сначала хотел спросить скриншоты нового дизайнера, но получилось так, что спросил непонятно про что. Вобщем, все уже увидел.
Спасибо, будем устанавливать компоненту под билдер и пробовать новый дизайнер в дейтсвии.