лично я за нативное решение вопроса, как в вышеупомянутом NP++До чего же людям лень! Я именно для того и почти год назад начал делать SetCoderExt.js а сейчас на его основе, благодаря Инструктору, сделал более вылизанный history.js, что-бы каждый мог взять их, выкинуть что не нужно и вставить всё что нужно. Так сказать, костяк предоставил.
Небольшие, но неприятные недочеты
- Author
- Message
-
Offline
- Posts: 767
- Joined: Mon Sep 28, 2009 10:03 am
- Location: Minsk, Belarus
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Если есть желающие, а главное могущей поучаствовать в разработке, могу предложить следующее:
Я разработаю скрипт-хост, который будет отвечать за ГУЙ и базовые операции. Скрипт в свою очередь будет подгружать дополнительные скрипты, которые будут отвечать за загрузку и интерфейс с контретным типом проектов. Таким образом каждый желающий поработать со своими специфическими проектами.
Требования к скрипту-интерфейсу приблизительно такие:
1. Уметь делать базовые операции над проектами: Создать новый, Открыть, Сохранить. Естественно хост должен будет получить информацию о предполагаемым маскам файлов проектов и пр.
2. Желательно мочь работать с множеством проектов одновременно.
3. Должен предоставить хосту информацию о компонентах: файлах, группах файлов и прочего, что может быть загружено в редакторе. Возможно в древовидной форме.
4. Должен уметь делать некоторые тривиальные операции над компонентом проекта: добавить новый/существующий, удалить, переименовать, открыть для редактирования.
Собственно больше и ничего в принципе не нужно. Детали реализации конкретных требований будут опубликованы во время разработки хоста. Разработка хоста будет начата с условием что это кому-то нужно(читай, буду участвовать не я один).
Я разработаю скрипт-хост, который будет отвечать за ГУЙ и базовые операции. Скрипт в свою очередь будет подгружать дополнительные скрипты, которые будут отвечать за загрузку и интерфейс с контретным типом проектов. Таким образом каждый желающий поработать со своими специфическими проектами.
Требования к скрипту-интерфейсу приблизительно такие:
1. Уметь делать базовые операции над проектами: Создать новый, Открыть, Сохранить. Естественно хост должен будет получить информацию о предполагаемым маскам файлов проектов и пр.
2. Желательно мочь работать с множеством проектов одновременно.
3. Должен предоставить хосту информацию о компонентах: файлах, группах файлов и прочего, что может быть загружено в редакторе. Возможно в древовидной форме.
4. Должен уметь делать некоторые тривиальные операции над компонентом проекта: добавить новый/существующий, удалить, переименовать, открыть для редактирования.
Собственно больше и ничего в принципе не нужно. Детали реализации конкретных требований будут опубликованы во время разработки хоста. Разработка хоста будет начата с условием что это кому-то нужно(читай, буду участвовать не я один).
-
Offline
- Posts: 3217
- Joined: Wed Nov 29, 2006 1:19 pm
- Location: Киев, Русь
- Contact:
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
VladSh, ну как бы мне оно не горит(и честно говоря и не нужно, ибо в это тяжелый случай, а значит юзаю IDE - не заинтересован). Нативное решение - знаете сколько такой плагин будет занимать? Раз в 5 больше АР, ибо каждый захочет свой формат проектных файлов поддержать(т.е. каждому формату свой парсер+свой процессор) - раздуется. А так - куча мелких скриптов, скачиваемых по желанию юзера.
Да и history.js у меня есть ещё не совсем доделанный(пару фич хочу ещё прикрутить, далее брошу, ибо по-ходу никому не нужно - нету отзывов).
Да и history.js у меня есть ещё не совсем доделанный(пару фич хочу ещё прикрутить, далее брошу, ибо по-ходу никому не нужно - нету отзывов).
-
Offline
- Posts: 176
- Joined: Sat Dec 24, 2011 4:05 pm
Может, создание универсального плагина для поддержки форматов всех IDE и не самое легкое занятие, но вот поддержку простенькой XML-стуктуры, думаю, писать недолго, и уж весить оно точно много не должно... Из серии:
Но вот писать, к сожалению, я только на шарпе умею. И кстати да, для своих программ предпочитаю идешку SharpDevelop, а не подобные блокноты. Но для работы со всякими скриптами, таблицами и т.п. AP очень неплохо подходит, а проекты для них хоть какие-то тож совсем лишними бы не были... Из универсальных идешек же вспоминается только тормознутая Eclipse на яве, которая мне совершенно не понравилась >_<
В общем, панельку бы хоть сейчас написал наверн, если б мог на "родном" C#; а с С++, чую, еще повозиться придется немало, чтоб понять/вспомнить все нужные отличия (до знакоства с шарпом небольние досовские программки на Borland C++ 3.0 писал). Но пока и энтузиазма особо на это нет, и есть пара вещиц, которые сначала хотелось бы доделать.
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>
В общем, панельку бы хоть сейчас написал наверн, если б мог на "родном" C#; а с С++, чую, еще повозиться придется немало, чтоб понять/вспомнить все нужные отличия (до знакоства с шарпом небольние досовские программки на Borland C++ 3.0 писал). Но пока и энтузиазма особо на это нет, и есть пара вещиц, которые сначала хотелось бы доделать.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Спешу Вас разочаровать: простеньких XML-структур просто не существует в природе.
> создание универсального плагина для поддержки форматов всех IDE
А никто не говорит о плагине. Просто выражают хотелку. Я предложил скрипт - мощнее плагина получится.
> не самое легкое занятие
По сложности, это занятие относиться какраз к простым, если не сказать очень.
> повозиться придется немало, чтоб понять/вспомнить все нужные отличия
Не правда. Не нужно возиться, если вспомнить что отличие одно: один их них черный, второй - белый.
Писать можете и на MSIL-е, и на яве, и на чем угодно, лишь бы интерфейс поддерживало.
> тормознутая Eclipse
Вот это его единственный минус - тормознутость, благодаря которому его плюсов не видно(и даже факт что они есть не достоверен).
> создание универсального плагина для поддержки форматов всех IDE
А никто не говорит о плагине. Просто выражают хотелку. Я предложил скрипт - мощнее плагина получится.
> не самое легкое занятие
По сложности, это занятие относиться какраз к простым, если не сказать очень.
> повозиться придется немало, чтоб понять/вспомнить все нужные отличия
Не правда. Не нужно возиться, если вспомнить что отличие одно: один их них черный, второй - белый.
Писать можете и на MSIL-е, и на яве, и на чем угодно, лишь бы интерфейс поддерживало.
> тормознутая Eclipse
Вот это его единственный минус - тормознутость, благодаря которому его плюсов не видно(и даже факт что они есть не достоверен).
-
Offline
- Posts: 176
- Joined: Sat Dec 24, 2011 4:05 pm
Не понимаю тебя. Во-первых, по-моему, вышеприведенный пример довольно прост. А во-вторых, пусть в .NET XML-парсер втроен, а я не знаю, на каких библиотеках основывается AkelPad - MSVCR там или чисто апи, но даже если в "его природе" такого парсера не существует, а плодить лишние зависимости нет желания, ровно как и утяжелять редактор встраиванием возможно не очень легковесного кода — можно же по-сути вообще какой угодно свой формат придумать, который было бы и парсить несложно. Например, в данном случае, думаю, был бы довольно неплох некий гибрид XML и INI.FeyFre wrote:Спешу Вас разочаровать: простеньких XML-структур просто не существует в природе.
Ну, языки, как ни крути, все же родственные. И когда заглядываю порой в код какой-нибудь программы на С++, обычно получается его более-менее понять... Вот интерфейс я никогда не писал на чистом апи - это да. Хотя отдельные апишные вставки и юзаю.FeyFre wrote:Не правда. Не нужно возиться, если вспомнить что отличие одно: один их них черный, второй - белый.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
-
Offline
- Posts: 876
- Joined: Tue Jul 24, 2007 8:54 am
Что-то я не пойму, в чем сложность поддержки проектов. Ведь их всё равно надо собирать вручную (ну, или по маске - но это не гарантирует точности). Даже специально заточенные IDE не могут делать это автоматом: если include/use/import/... файл , он ведь не добавится в дерево проекта.сам. В итоге остаётся всего лишь типовой функционал манипуляций со структурированным списком файлов.
P.S. Или вы хотите, чтобы Акель умел обращаться непосредственно с файлами проектов, содержащими весь список файлов в проекте? Это уже в самом деле нетривиальная задачка, но едва ли именно такое применение будет сильно востребовано.
P.S. Или вы хотите, чтобы Акель умел обращаться непосредственно с файлами проектов, содержащими весь список файлов в проекте? Это уже в самом деле нетривиальная задачка, но едва ли именно такое применение будет сильно востребовано.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Fr0sT
Ну от самого акеля нужно умение редактировать текстовые файлы, больше ничего, что он прекрасно умеет. А то что мы тут хотим добавить(не важно скриптом или плагином), это только возможность этой добавкой натравится на определенный проектный файл, который эта добавка прочитает, распарсит, извлечет оттуда списки файлов и покажет где-то сбоку на панельке(или снизу, в общем в гуе); при щелчке на элемент в этой панельке дополнение попросит акель открыть его. Всё, это в принципе минимум - read-only режим. Поверх этого потом можно будет добавить операции модификации: удалить элемент с проекта, добавить элемент, передвинуть по дереву(если в формате проекта предусмотрено). Ну и совсем круто будет что-бы это дополнение умело создавать новые проекты и редактировать его не файловые опции. Но всё по порядку.
Ну от самого акеля нужно умение редактировать текстовые файлы, больше ничего, что он прекрасно умеет. А то что мы тут хотим добавить(не важно скриптом или плагином), это только возможность этой добавкой натравится на определенный проектный файл, который эта добавка прочитает, распарсит, извлечет оттуда списки файлов и покажет где-то сбоку на панельке(или снизу, в общем в гуе); при щелчке на элемент в этой панельке дополнение попросит акель открыть его. Всё, это в принципе минимум - read-only режим. Поверх этого потом можно будет добавить операции модификации: удалить элемент с проекта, добавить элемент, передвинуть по дереву(если в формате проекта предусмотрено). Ну и совсем круто будет что-бы это дополнение умело создавать новые проекты и редактировать его не файловые опции. Но всё по порядку.
-
Offline
- Posts: 876
- Joined: Tue Jul 24, 2007 8:54 am
FeyFre
дык и я о том же.
Т.е. если не делать открытие стандартных файлов проектов, а просто реализовать действия с группой файлов, дело вообще почти только за интерфейсовыми аспектами. Если же делать, то реализовывать придётся довольно приличное количество форматов. И я сомневаюсь, что возможностей скриптов тут хватит - многие проекты на xml, а в wsh такой возможности вроде бы нет.
дык и я о том же.
Т.е. если не делать открытие стандартных файлов проектов, а просто реализовать действия с группой файлов, дело вообще почти только за интерфейсовыми аспектами. Если же делать, то реализовывать придётся довольно приличное количество форматов. И я сомневаюсь, что возможностей скриптов тут хватит - многие проекты на xml, а в wsh такой возможности вроде бы нет.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Fr0sT, количество поддерживаемых форматов будет определяться исключительно пользователями. В смысле - кому какой формат понадобится, тот и кто-то реализует(кто-то - желающий это сделать. от автора АР до пользователя кому это нужно). В виде модуля: ядро будет в определенной папке искать скрипты-модули. Если хорошо поработать над архитектурой, то будет зависеть исключительно от модуля будут ли редактироваться исключительно текстовые файлы - составляющие проект, или также другие встроенные специфические свойства проекта.
А вроде бы естьмногие проекты на xml, а в wsh такой возможности вроде бы нет.
-
Offline
- Posts: 3217
- Joined: Wed Nov 29, 2006 1:19 pm
- Location: Киев, Русь
- Contact:
Наверное я не понял идеи.. Не понимаю, зачем каждый раз парсить какой-то свой формат проектных файлов? И зачем затачивать в коде какой-то определённый вариант парсинга? Как по моему, то надо в плаге было бы реализовать функционал парсинга без привязки к формату (парсить конфигурационный файл), а уж в конфиге описывать формат, если так надо.FeyFre wrote:Нативное решение - знаете сколько такой плагин будет занимать? Раз в 5 больше АР, ибо каждый захочет свой формат проектных файлов поддержать(т.е. каждому формату свой парсер+свой процессор) - раздуется.
И почему вообще списки файлов хранить где-то надо, если можно читать структуру папок, начиная от какой-то?