Обсуждение развития MSEide + MSEgui

[debi12345]

Для каждого такого вхождения можно написать доку, причём на разных
языках. RAD могла бы давать запрос к такой базе и показывать
справку. Если вхождения нет - пользователю будет предложено дописать.

99.99% проблемы с докой - отсутствие массива доки. Будет этот массив - за день будет сгенерирован любой формат, любую БД - для этого есть сладкая компания "bash/sed/awk/perl".

[Alexander]

Так и массив тогда появится. Будет последовательно заполнятся
пользователями. Причём в такой интимный момент, когда он сам
ищет помощи по этой функции. Также нужен сервер для сбора и
раздачи доки. Или какой то не серверный вариант объединения.

Причём и на разных языках одновременно.

[Miha]

debi12345, а продолжение доки ...help/doc/MSEHELP.TXT будет?
думаю может его запихать в html(fpcdoc), заодно и прочитаю, а может уже есть такое.

Так и массив тогда появится. Будет последовательно заполнятся пользователями.
...

ИМХО, утопия. WIKI тому пример, страница есть, все про нее знают - толку 0.
Что мешает разобрался напиши в WIKI, чтоб другой грабли перешагнул?
А я отвечу: Ничего не мешает, просто человек когда работает он или код пишет или доку пишет, а мешать эти два дела сложно.

[Alexander]

WIKI тому пример,

WIKI там, а я здесь. К тому же это не контекстная справка.

А при ещё и контекстном написании справки дела пойдут.

[debi12345]

debi12345, а продолжение доки ...help/doc/MSEHELP.TXT будет?

Budet,budet-kak tol'ko svobodnoe vremya poyavitsya. Sleduyutshaya tema - reporter.

думаю может его запихать в html(fpcdoc), заодно и прочитаю, а может уже есть такое.

Problemy ne budet - tehnologiya otrabotana. Massiv davaite !

[Attid]

WIKI тому пример,

WIKI там, а я здесь. К тому же это не контекстная справка.

А при ещё и контекстном написании справки дела пойдут.

ну вот и родилась обобщеная мысль в контекстной справке выкидывать на страничку ВИКИ. если страницы нет будет написаноо "создать" =)

также из нее легко делается офлай версия.

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

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

2. Автодополнение. Да, к нему народ привык. И это действительно
нужная вещь.

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

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

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

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

[Miha]

Problemy ne budet - tehnologiya otrabotana. Massiv davaite !

Я только один массив видел - ...help/doc/MSEHELP.TXT

[Alexander]

Я только один массив видел - ...help/doc/MSEHELP.TXT

Согласен. И на Вике совсем чуть чуть.

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

Вики однозначно недостаточно.

[Alexander]

Да, ещё одна трудность документирования - проект в постоянной
разработке, всё может меняться. То что вчера было недоступно,
стало доступно. То что раньше называлось (вызывалось, делалось)
так, теперь иначе.

[debi12345]

Ну что, прекратим болтать и приступим к работе - то есть к наращиванию массива ?
Кто возьмется за сверхважный компонент TMSESQLQUERY ? ( спрашивайте, если что )

[Miha]

ну вот и родилась обобщеная мысль в контекстной справке выкидывать на страничку ВИКИ. если страницы нет будет написаноо "создать" =)

Т.е. типа так?

- Нажал Ctrl+F1
- IDE зарисовывает контекст справки (выделеное слово, имя процедуры, имя модуля - типа того)
- Конеткст справки передается дополнительной софтине (ну или части IDE) на предмет запроса справки (как вариант вернуть текст или открыть в браузере), назовем софтину эту - ХелпМанагер.
- ХеплМанагер задает уточняющий вопрос, в случае неоднозначности контекста и, в зависимости от своих настроек, открывает или локальную копию html или удаленную копию html или ВИКИ, с выбором желаемого(допустимого) языка.
- А дальше "клиент" читает или пишет, в зависимости от того что позволяет делать открытое место

Ну что, прекратим болтать ...

Не прекратим - это ж интернет
Манагер (в смысле РМ) нужен по хэлповику. Предлагаю debi123.
Я располагаю 8-ю часами в неделю, могу взятся и за TMSESQLQUERY, но мой английский придется править. Брать?

[debi12345]

Манагер (в смысле РМ) нужен по хэлповику. Предлагаю debi123.

Логично. Интегрировать все равно мне придется - потому что автор "doc_tools".

Я располагаю 8-ю часами в неделю, могу взятся и за TMSESQLQUERY, но мой английский придется править. Брать?

Подправим если что. Брать.

Новое сообщениеДобавлено: 08.10.2007 20:10:12 Заголовок сообщения: Ответить с цитатой
Attid писал(а):
ну вот и родилась обобщеная мысль в контекстной справке выкидывать на страничку ВИКИ. если страницы нет будет написаноо "создать" =)
........

Текущее состояние доки на библиотеку :

- XML-затравки генерятся специальным скриптом, по последнему контенту

- эти затравки можно подредактировать информацией из массива

- после правки, уже другой скрипт создает HTML-файлы, а также и индекcные (*.xct) файлы, которые могут быть использованы для быстрого определения нужного HTML-файла ( при нажатии [CTrl+]F1 )

- смотреть доку можно через Mozilla - она умеет загружать новый файл в прежнее окно ( не "плодить" окна )

ПС:

Мартин обещает сделать вызов смотрилки, как только будет набран контент (то есть продемонстрировано серьезное отношений со стороны пользователей )

[Alexander]

Стоит добавить, что я имел ввиду делать эту справочную систему
не только для документирования МСЕ, но и вообще для всего ФПК и
пользовательских юнитов. Полное единообразие.

!Думаю ясно что нельзя ограничиваться справочной системой
только на функции вкомпилированные в МСЕИде ?

Вопрос можно ли зацепиться за имя юнита / имя файла юнита / настройки
ФПК и далее к объекту документирования, создав хотя бы насколько то
уникальный якорь ? Или по барабану, пусть в одноимённых юнитах совпадают, только природа юнита описывается ?
На мой взгляд документация должна быть весьма независимой
от исходников. А вот каркас может быть получен из них для корректного
вызова справки (те где взять параметры функций). Те прцесс
обратный текущему. Вначале берётся исходник, парсится(fpcdoc?) и
из него получается структура например функции, создаётся
каркас справки и выдаётся писателю справки. Иначе двойная
работа. Должна быть возможность сохранять справку как для себя
так и публиковать для всех. При этом если поступает несколько
описаний от разных людей они суммируются с указанием автора
А от одного автора заменяются

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

Ещё одной проблемой может быть УДАЛЕНИЕ описания устаревших
(и удалённых) функций из общей базы. Кто (из людей !) должен отвечать за это ? Автор описания (все авторы одновременно если их несколько) ?
Или/и кто то специально ответственный ?

На себя я могу взять книжку введения.

[debi12345]

Все понятно - нужен онлайновый редактор с БД. И с логином. С функционалом "добавить-редактировать-удалить" :

1) компонент
2) описание
3) пример использования
4) properties (с описанием каждой )
5) public methods (с описанием каждого )

Ессно, с возможностью уйти в оффлайн, сделать дело, потом воссоединиться и сохраниться.

Кто силен в PHP и у кого много времени, чтобы такой сайт сделать ?

ПС:

Чем хороша БД в этом случае - тем, что в ней все априори разложено по полочкам, и SQL-командами можно сгенерировать опять-таки контент в нужном формате.

[Alexander]

В МСЕ нет системы компонентов. Я понимаю, что есть проблема у ФПК.
Но зачатки этого должны быть уже сейчас. Должен быть способ
именования компонента, зависимостей, структуры, место положения
в файловой системе итд.

Уже сейчас заметно, что IDE потихоньку растёт в размерах.
И в среде, естественно, не нужно иметь все компоненты сразу.

1) компонент
2) описание
3) пример использования
4) properties (с описанием каждой )
5) public methods (с описанием каждого )

А как же юниты функции константы ?

Юнит здесь сложозахватываемый момент.
Вероятно нужно делать якорь на:
1.имя
2.к какому проекту (те программе) он относится
3.относительный путь внутри проекта

Надо сделать вызов функции, в которую будут
отсылаться все запросы пользователя на помощь. Из текста,
из редактора свойств.

Первая мысль - сделать что то на основе СВН.

Да, ещё. Тут народ на форуме задаёт вопросы о наладонниках. МСЕ на
наладонниках (которые ВинСЕ, млин).работает ?