AkelPad

Posted: **Mon Dec 26, 2011 6:37 pm**

До чего же людям лень! Я именно для того и почти год назад начал делать SetCoderExt.js а сейчас на его основе, благодаря Инструктору, сделал более вылизанный history.js, что-бы каждый мог взять их, выкинуть что не нужно и вставить всё что нужно. Так сказать, костяк предоставил.

лично я за нативное решение вопроса, как в вышеупомянутом NP++

Posted: **Mon Dec 26, 2011 7:29 pm**

лично я за нативное решение вопроса, как в вышеупомянутом NP++

что инициатива делает с инициатором?

Posted: **Thu Dec 29, 2011 4:50 pm**

Если есть желающие, а главное могущей поучаствовать в разработке, могу предложить следующее:
Я разработаю скрипт-хост, который будет отвечать за ГУЙ и базовые операции. Скрипт в свою очередь будет подгружать дополнительные скрипты, которые будут отвечать за загрузку и интерфейс с контретным типом проектов. Таким образом каждый желающий поработать со своими специфическими проектами.
Требования к скрипту-интерфейсу приблизительно такие:
1. Уметь делать базовые операции над проектами: Создать новый, Открыть, Сохранить. Естественно хост должен будет получить информацию о предполагаемым маскам файлов проектов и пр.
2. Желательно мочь работать с множеством проектов одновременно.
3. Должен предоставить хосту информацию о компонентах: файлах, группах файлов и прочего, что может быть загружено в редакторе. Возможно в древовидной форме.
4. Должен уметь делать некоторые тривиальные операции над компонентом проекта: добавить новый/существующий, удалить, переименовать, открыть для редактирования.
Собственно больше и ничего в принципе не нужно. Детали реализации конкретных требований будут опубликованы во время разработки хоста. Разработка хоста будет начата с условием что это кому-то нужно(читай, буду участвовать не я один).

Posted: **Thu Dec 29, 2011 10:24 pm**

Я бы с удовольствием поучаствовал, только ради расширения кругозора в программинге, но считаю, что лучшим было бы нативное решение - объединение плагинов Sessions, кусок "Избранное" и "последних файлов". Да и мне срочно надо XPages+Java заниматься, а там ещё конь не валялся...

Posted: **Thu Dec 29, 2011 11:53 pm**

VladSh, ну как бы мне оно не горит(и честно говоря и не нужно, ибо в это тяжелый случай, а значит юзаю IDE - не заинтересован). Нативное решение - знаете сколько такой плагин будет занимать? Раз в 5 больше АР, ибо каждый захочет свой формат проектных файлов поддержать(т.е. каждому формату свой парсер+свой процессор) - раздуется. А так - куча мелких скриптов, скачиваемых по желанию юзера.
Да и history.js у меня есть ещё не совсем доделанный(пару фич хочу ещё прикрутить, далее брошу, ибо по-ходу никому не нужно - нету отзывов).

Posted: **Fri Dec 30, 2011 11:02 pm**

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

Code: Select all

<Preferences>
	<!-- Какие-нить специфические настройки AP, если не лень  -->
</Preferences>
<Files>
	<Group name="Группа 1" >
		<File name="C:\MyProject\MyFile.js" />
		<File name="C:\MyProject\MyFile.po" />
	</Group>
	<File name="C:\MyProject\И тут че-нить такое.xml" />
</Files>

Но вот писать, к сожалению, я только на шарпе умею. И кстати да, для своих программ предпочитаю идешку SharpDevelop, а не подобные блокноты. Но для работы со всякими скриптами, таблицами и т.п. AP очень неплохо подходит, а проекты для них хоть какие-то тож совсем лишними бы не были... Из универсальных идешек же вспоминается только тормознутая Eclipse на яве, которая мне совершенно не понравилась >_<

В общем, панельку бы хоть сейчас написал наверн, если б мог на "родном" C#; а с С++, чую, еще повозиться придется немало, чтоб понять/вспомнить все нужные отличия (до знакоства с шарпом небольние досовские программки на Borland C++ 3.0 писал). Но пока и энтузиазма особо на это нет, и есть пара вещиц, которые сначала хотелось бы доделать.

Posted: **Fri Dec 30, 2011 11:25 pm**

Спешу Вас разочаровать: простеньких XML-структур просто не существует в природе.
> создание универсального плагина для поддержки форматов всех IDE
А никто не говорит о плагине. Просто выражают хотелку. Я предложил скрипт - мощнее плагина получится.
> не самое легкое занятие
По сложности, это занятие относиться какраз к простым, если не сказать очень.
> повозиться придется немало, чтоб понять/вспомнить все нужные отличия
Не правда. Не нужно возиться, если вспомнить что отличие одно: один их них черный, второй - белый.
Писать можете и на MSIL-е, и на яве, и на чем угодно, лишь бы интерфейс поддерживало.
> тормознутая Eclipse
Вот это его единственный минус - тормознутость, благодаря которому его плюсов не видно(и даже факт что они есть не достоверен).

Posted: **Sat Dec 31, 2011 1:01 am**

FeyFre wrote:Спешу Вас разочаровать: простеньких XML-структур просто не существует в природе.

Не понимаю тебя. Во-первых, по-моему, вышеприведенный пример довольно прост. А во-вторых, пусть в .NET XML-парсер втроен, а я не знаю, на каких библиотеках основывается AkelPad - MSVCR там или чисто апи, но даже если в "его природе" такого парсера не существует, а плодить лишние зависимости нет желания, ровно как и утяжелять редактор встраиванием возможно не очень легковесного кода — можно же по-сути вообще какой угодно свой формат придумать, который было бы и парсить несложно. Например, в данном случае, думаю, был бы довольно неплох некий гибрид XML и INI.

FeyFre wrote:Не правда. Не нужно возиться, если вспомнить что отличие одно: один их них черный, второй - белый.

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

Posted: **Sat Dec 31, 2011 8:39 am**

Не понимаю тебя.

Если что-то решили хранить в XML, значит структура уже сложная, и в линейный текстовый/бинарный файл не станет.

Ну, языки, как ни крути, все же родственные.

Ничего у них общего отличного от общего с другими языками нету.

Posted: **Mon Jan 02, 2012 6:48 pm**

Что-то я не пойму, в чем сложность поддержки проектов. Ведь их всё равно надо собирать вручную (ну, или по маске - но это не гарантирует точности). Даже специально заточенные IDE не могут делать это автоматом: если include/use/import/... файл , он ведь не добавится в дерево проекта.сам. В итоге остаётся всего лишь типовой функционал манипуляций со структурированным списком файлов.
P.S. Или вы хотите, чтобы Акель умел обращаться непосредственно с файлами проектов, содержащими весь список файлов в проекте? Это уже в самом деле нетривиальная задачка, но едва ли именно такое применение будет сильно востребовано.

Posted: **Mon Jan 02, 2012 7:59 pm**

Fr0sT
Ну от самого акеля нужно умение редактировать текстовые файлы, больше ничего, что он прекрасно умеет. А то что мы тут хотим добавить(не важно скриптом или плагином), это только возможность этой добавкой натравится на определенный проектный файл, который эта добавка прочитает, распарсит, извлечет оттуда списки файлов и покажет где-то сбоку на панельке(или снизу, в общем в гуе); при щелчке на элемент в этой панельке дополнение попросит акель открыть его. Всё, это в принципе минимум - read-only режим. Поверх этого потом можно будет добавить операции модификации: удалить элемент с проекта, добавить элемент, передвинуть по дереву(если в формате проекта предусмотрено). Ну и совсем круто будет что-бы это дополнение умело создавать новые проекты и редактировать его не файловые опции. Но всё по порядку.

Posted: **Tue Jan 03, 2012 6:48 pm**

FeyFre
дык и я о том же.
Т.е. если не делать открытие стандартных файлов проектов, а просто реализовать действия с группой файлов, дело вообще почти только за интерфейсовыми аспектами. Если же делать, то реализовывать придётся довольно приличное количество форматов. И я сомневаюсь, что возможностей скриптов тут хватит - многие проекты на xml, а в wsh такой возможности вроде бы нет.

Posted: **Tue Jan 03, 2012 8:28 pm**

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

многие проекты на xml, а в wsh такой возможности вроде бы нет.

А вроде бы есть

Posted: **Sun Jan 22, 2012 6:02 pm**

FeyFre wrote:Нативное решение - знаете сколько такой плагин будет занимать? Раз в 5 больше АР, ибо каждый захочет свой формат проектных файлов поддержать(т.е. каждому формату свой парсер+свой процессор) - раздуется.

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

И почему вообще списки файлов хранить где-то надо, если можно читать структуру папок, начиная от какой-то?

Posted: **Sun Jan 22, 2012 8:52 pm**

VladSh
+1

AkelPad

Небольшие, но неприятные недочеты