Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » Разработка редактора с древовидной структурой

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3

Открыть новую тему     Написать ответ в эту тему

GingerFox



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
igvis
xcode
ЕХ - лучше. ЕХ может быть не только документом. Это может быть любой объект, исполняемый файл, изображение, видео, звук.
 
Насчет пиринговой базы знаний с документами - вот http://www.scribd.com/ - что-то подобное. Правда не пиринговое.
 
Насчет информации на подумать.
Это раз - http://www.kinook.com/UltraRecall/ - по мне - так почти идеал, если еще сделать, чтобы хранилище лежало в Нете, так вообще здорово, плюс сделать, чтобы функции плагинами наращивались, как в FireFox.
 
И вот - http://www.evernote.com/ - хранится все в  Сети. Клиент на десктопе, смартфоне. Тоже занятная база, правда все хранится одной лентой, но зато с тегами.
 
Если бы слить вместе UltraRecall, EverNote да к этому расширение функционала плагинами... Мечта бы реализовалась.
 
И насчет портабельности. Я неправильно выразился, имел в виду кроссплатформенность. То есть писать все надо на Java, AJAX и т.п. Чтобы не привязываться к Винде, Линуксу или чему бы то ни было. М?
 
Добавлено:
xcode
Да, и еще такая мысль. Может быть стоит, если уж все начинается с нуля, разрабатывать по другому принципу? То есть отталкиваться не от функций. Сами по себе функции не имеют значения. Программа должна решать задачи пользователя, а не просто быть скопищем функций, которые пользователь вынужден перебирать, чтобы найти нужные для себя.
Делать надо отталкиваясь от сценариев использования.
И еще мысль насчет разметки и форматирования. Надо полностью отделить содержание от оформления. Т.е. есть содержание, а есть таблицы стилей. Стили и определяют внешнее отображение информации. Т.е. так же, как это реализовано в CSS или OpenOffice. Кстати очень может быть стоит взять формат документов OpenOffice, благо он открытый, чем изобретать велосипед? В этом еще и тот плюс, что такая система будет хорошо вязаться с тем же OpenOffice, в частности документы можно будет редактировать в OO или вообще инкапсулировать его Writer, Impress, Draw и т.д. (возможно ли это?) в аутлайнер в качестве редакторов контента.
 
Со своей стороны могу принять посильное участие в разработке, правда я не программист, но ради хорошего дела можно и попробовать что-то изучить. Но опять же не думаю, что надо делать ТОЛЬКО на C++. Как минимум неплохо бы делать и что-то кроссплатформенное на той-же Яве или Руби, может быть с усечением некоторых функций, но зато обеспечивающее переносимость приложения с одной платформы на другую.

Всего записей: 319 | Зарегистр. 06-11-2003 | Отправлено: 13:58 11-11-2008 | Исправлено: GingerFox, 14:02 11-11-2008
xcode



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SFC
Смысл этой базы знаний - как раз в отказе от веба в привычном понимании этого слова. Скажем, я в пириновом режиме скачиваю пару сотен мегабайт электронной документации, затем отключаюсь от инета и она мне доступна в оффлайне. Даже при высоких скоростях интертена оффлайновая MSDN Library работает быстрее чем онлайн-версия - в том числе за счет того что все скрипты, как на стороне клиента, так и на стороне сервера, интерпретируются, а в оффлайн-версии работает оптимизированный машинный код. Ну и доступ в инет все равно никогда не будет быстрее чем доступ к HDD.
GingerFox
Про язык разработки: реально около 90% используюи винду, остальные линукс, те единицы которые используют что-то другое, как правило сами профессиональные программисты и в состоянии написать оболочку для себя, благо все открытое.
С++ - просто потому что мне так удобнее. Я реально рассматривал С++ или C#, написал на C# несложную программу для сканирования директорий и создания xml-образов... да, язык удобный - но С++ я уже знаю, есть куча готовых компонентов, а времени на изучение нового языка особо нет. А под линух можно кстати на qt написать, и под мак заодно Да и опыт такой разработки есть. Тем более, что я уже пишу код, не переписывать же на C# или Java
 
По форматам: ИМХО,  html - более чем открытый формат Я не знаю какой там формат у OpenOffice, но наверняка ведь двоичный?
По функциям: я ставил UltraRecall, ничем особенным не впечатлила. Так и пользуюсь TreePad'ом
 
2All: Пишите пожалуйста конкретно функции, которые вам нравятся в том или ином продукте! Ставить и смотреть все просто нет возможности!. Кстати, это одна из целей создания этой темы

Всего записей: 240 | Зарегистр. 25-12-2005 | Отправлено: 23:47 11-11-2008
GingerFox



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
xcode
Уже пишешь... Стадию начального планирования по-моему не стоит недооценивать, если изначально все правильно продумать, то потом и делать будет гораздо легче. Насчет языка это конечно не камень преткновения. Надо четко продумать и описать все концепции и форматы хранения и обработки информации, тогда что-то доваять, сделать на другом языке будет намного проще.
HTML в качестве формата хранения не годится, слишком много ограничений, не пойдет.
Собственно нет у OpenOffice СВОЕГО какого-то формата. OpenOffice - открытый проект с открытыми исходниками (поэтому можно и позаимствовать че-нить типа...) и использует поэтому максимально открытые форматы, а не проприетарную хренотень, как мелкософт. Для хранения документов используется стандарт ODF - Open Document Format. Он НЕ двоичный, вкратце это XML запакованный в ZIP. Вот здесь Open Document Format Wiki кое-что об этом формате можно прочитать. Есть спецификация, переведенная на русский язык. Вот. Могу и спецификацию намылить или здесь выложить.
 
Я тоже уже давно ищу подходящий инструмент для сбора, сохранения и обработки информации, так может действительно стоит его сделать, но сделать ПРАВИЛЬНО. Изначально создавать, как максимально гибкий, расширяемый, чтобы не загнать себя в жесткие рамки каких-то ограничений, которые следуют из неправильных концепций и шагов с самого начала.
 
И еще раз - НЕ НАДО упираться в функции. Если изначально будет архитектура с возможностью подключения плагинов, то ФУНКЦИИ можно наращивать до бесконечности. Пример - FireFox. Сам по себе, в голом виде он просто платформа, зато наставив расширений можно выточить его в нужном для себя направлении. Кстати один из вариантов - наваять систему на XUL, а?
Так что не функции главное, а продуманная система организации данных. Если она будет изначально правильной, то функции в программах обработки уже можно будет накручивать по потребностям. А если не продумать как следует, то будет очередная частная поделка, которая так и останется частной поделкой.

Всего записей: 319 | Зарегистр. 06-11-2003 | Отправлено: 12:40 12-11-2008 | Исправлено: GingerFox, 12:55 12-11-2008
xcode



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
GingerFox, а какие у html ограничения? нормальный формат, все что нужно для разметки и форматирования текста. Это НЕ издательская система, поэтому навороченного форматирования не нужно, а стандартный набор будет обязательно.

Цитата:
xml запакованный в zip
- ключевое слово "запакованный". zip - это уже двоичный формат, что непреемлемо для VCS. А "правильный" html - это фактически xml не запакованный ни во что. Метаданные будут храниться, естественно, в xml-файлах.
Выбор форматов обусловлен именно концепцией системы - многопользовательская и с контролем версий. Однопользовательских систем с закрытыми базами немеряно в теме "редакторы с древовидной структурой", а я как раз и занимаюсь реализацией принципиально новой концепции.
 
Никто не запрещает добавлять в html нестандартные теги и атрибуты - они просто не будут отображаться в стандартном IE редакторе, но до них можно добраться через DHTML и делать то что нужно по логике программы.
 
Стадия начального планирования уже давно идет На момент создания этой темы многие вопросы уже были рассмотрены (точнее, проект эволюционировал из стадии "а хорошо бы софтину с такими и такими возможностями" в стадию четкого понимания архитектуры и всех потенциальных возможностей). Затягивать дальше уже нельзя
 
Есть общая концепция - делать систему как можно более простой и открытой.  
 
В настоящее время я разбираюсь с навороченным деревом с CodeProject'а - с функциями перетаскивания, мультиселекта, когда разберусь - протестирую новую концепцию размещения файлов. Уже тогда можно будет сделать простейший аутлайнер - на текстовых файлах, и затем разбираться с IE HtmlEdit'ом.  
 

Всего записей: 240 | Зарегистр. 25-12-2005 | Отправлено: 14:48 12-11-2008
GingerFox



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
xcode
Пожалста, можно и не паковать, это уже не принципиально. Хотя было бы экономнее в плане объема на диске и скорости доступа. Может быть всю базу положить в упаковку, а вот внутри все сделать, как душе угодно.
 
HTML - ненененене! Дэвид Блэйн - ты демон! Лучше закладывать большие возможности, чем в какой-то момент упереться в ограничения только потому, что показалось, мол и так хватит. А чем же плохо, что можно будет любой документ взять из БД, отредактировать в OpenOffice, положить обратно и он будет сохранен со всеми изменениями? Да только благодарны будут все. Кому не надо, тот не будет пользовать возможности во всей полноте, а если понадобится, то такая возможность заложена. Ы?

Всего записей: 319 | Зарегистр. 06-11-2003 | Отправлено: 22:47 12-11-2008
hammerit



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
а какие у html ограничения? нормальный формат, все что нужно для разметки и форматирования текста.

Полностью поддерживаю.

Цитата:
HTML - ненененене!

HTML - ДаДаДа!
 
Высказываю свое имхо:
Редактор с базой на основе HTML-файлов - это то, что я искал давным давно (и давным давно писал в теме про редакторы с древовидной структурой).  
HTML - это формат, который при всей своей простоте позволяет выстраивать любые конструкции практически любой сложности. Говорю это как практикующий веб-дизайнер
К тому же, формат полностью открыт, и при желании просматривать полученные документы можно будет в любом браузере, а редактировать - в любом текстовом редакторе, хоть в "Блокноте".
Только почему-то писатели аутлайнеров об этом не думают.
Надеюсь, xcode будет первым, кто осуществит прорыв в этой области
 
От себя пожелание - предусмотреть кроссплатформенность изначально, то есть сразу делать полноценную версию не только под Windows, но и под Linux (без необходимости самостоятельной компиляции).
И еще одно пожелание - возможность экспорта отдельных веток или всей базы из ScrapBook (плагин для Firefox).

Всего записей: 371 | Зарегистр. 15-03-2006 | Отправлено: 08:48 13-11-2008 | Исправлено: hammerit, 08:49 13-11-2008
GingerFox



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
hammerit
Вам, как практикующему веб-дизайнеру, лучше многих должно быть известно, какие хитровые..нные вещи приходится накручивать кучами, и именно из-за убогости HTML. Простота его - из тех, которые хуже воровства. Нет бы сделать сразу нормальный формат хранения, не-ет, давайте будем так же геморроиться в "аутлайнере мечты", как в вебе.
xcode
А нельзя вообще сделать собственно костяк АМ (аутлайнера мечты ) таким, чтобы отображение в окне ЕХ (единицы хранения или заметки или как угодно, короче элемента дерева) делалось плагинами? А сами ЕХ были бы просто контейнерами, в которые можно закладывать что угодно - TXT, HTML, XML, DOC, RTF, OpenDoc, JPG, TIFF, GIF, RAR, ZIP, черта лысого. Тогда можно будет очень просто подключать хранение документов в любых форматах. Только РАДИ БОГА НЕ НАДО все перекосорыливать в HTML. Ну не универсален он ни фига. А если как я предлагаю, так и пожалуйста, кто хочет, все будет содить в HTML, а кому не хватит, подключит плагин и получит то, что хочет.
Вы же хотите сделать систему как можно более открытой? И это правильно. А вот как можно более простой - не надо пожаловста! Простых уже много, зачем их плодить.
А?
 
Еще разок прикинул. А ведь правда, хорошо так сделать - дерево, а отображение листов - плагинами. Тогда будет суперуниверсальная программа, любой сможет из нее сделать то, что ему надо, от файлового менеджера, до вьюера картинок. Со всеми промежуточными вариантами. Плагин отображения получает от дерева, что ему надо показать, а результат выводит в окно. Как-то вот так. Я не программист, может быть коряво выражаюсь, но идею постарался описать...

Всего записей: 319 | Зарегистр. 06-11-2003 | Отправлено: 12:48 13-11-2008 | Исправлено: GingerFox, 14:45 13-11-2008
hammerit



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Контейнеры, в которые плагинами можно загружать разные форматы хранения данных - это конечно круто, мне нравится идея.
Только вот насколько это усложнит работу и утяжелит программу?
Нужно ведь не только отображать информацию определенного формата, но еще и редактировать ее... Соответственно, плагин для редактирования doc-формата должен представлять собой MS-Word в миниатюре... И так по каждому формату. Реально ли?

Всего записей: 371 | Зарегистр. 15-03-2006 | Отправлено: 15:42 13-11-2008
xcode



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Народ, я полгода выбирал формат для основного типа документов То что он должен быть текстовый, было понятно сразу после определения идеологии (контроль версий, атвоматические слияния и т.д.). Сначала я думал найти какой-то bbcode-like редактор, затем думал использовать rtf редактор а при загрузке и сохранении использовать bbcode<->rtf преобразование... Но все гениальное просто, я увидел на CodeProject'е пример Html редактора и понял что это оно.
 
Плагин для MS-Word лично мне не нужен (точнее, нужан только читалка *.doc-документов, без редактирования, и то не сейчас а в отдаленной перспективе). Контейнеры как таковые будут - по крайней мере, после того как заработает html, я начну копать в сторону второго основного типа документов - векторных диаграмм. Это будут несложные xml-файлы, в которых будут храниться диаграммы различных типов, в основном то что нужно программисту. Разумеется, я подумаю о встраивании html в диаграммы и диаграмм в html. Что это будет - не знаю, как минимум - ссылки внутри базы и открытие связанного документа на отдельной закладке, как максимум - полноценное встраивание.
Контейнеры для "неродных" форматов - сама по себе задача значительно более сложная чем конрейтеры для родных. Трудоемкость разработки возрастает в разы, даже в десятки раз, а результат... все равно word, встроенный во что-то другое, будет глючить и тормозить, все равно все возможности офиса в плагин не запихать и вообще непонятно зачем это нужно. Так что будут внешние документы, подключенные в базу в виде гиперссылок, которые будут открываться в нормальном Ворде и там редактироваться.

Всего записей: 240 | Зарегистр. 25-12-2005 | Отправлено: 16:38 13-11-2008
Jenyay



Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Кстати, на счет кроссплатформенности. Может быть стоит посмотреть в сторону NVU - редактора HTML на движке мозилы? Тогда не будет привязки к винде.

----------
http://jenyay.net - софт, исходники и фото

Всего записей: 1788 | Зарегистр. 13-10-2001 | Отправлено: 23:23 13-11-2008
xcode



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Все равно будет привязка к винде. Я все это задумал ради интеграции с Visual Studio и создания распределенной базы знаний по программным проектам. Т.е. для того чтобы коллектив разработчиков документировал свой код
Хотя, в любом случае, я ориентируюсь на кроссплатформенность - разрабатывая отдельно движок Базы Знаний и отдельно GUI. При необходимости просто тупо создается новый GUI для другой ОС (точнее - берется что-то похожее из открытых проектов и немного переделывается), прилинковывается движок - и все готово
 
Кстати: подскажите бесплатный оконный интерфейс в стиле Visual Studio 2005/2008
основные требования:
* произвольный докинг окон
* закладки + MDI
* интерактивно настраиваемые панели инструментов и меню, т.е. чтобы можно было прямо мышью перетаскивать иконки панелей инструментов
* простота использования
* C++

Всего записей: 240 | Зарегистр. 25-12-2005 | Отправлено: 23:32 13-11-2008
Jenyay



Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Я видел для WTL - http://www.codeproject.com/KB/wtl/wtldockingwindows.aspx но сам не пользовался.

----------
http://jenyay.net - софт, исходники и фото

Всего записей: 1788 | Зарегистр. 13-10-2001 | Отправлено: 09:35 14-11-2008
hammerit



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Кстати, на счет кроссплатформенности. Может быть стоит посмотреть в сторону NVU - редактора HTML на движке мозилы? Тогда не будет привязки к винде.

 
Nvu умер давно, его преемник - KompoZer. Кстати...

Цитата:
В марте 2007 года Download.com объявила KompoZer лучшей бесплатной альтернативой Adobe CS3.[1]

Может действительно стоит глянуть на его исходники...
 

Цитата:
Все равно будет привязка к винде.

А вот это конечно очень жаль...

Цитата:
Хотя, в любом случае, я ориентируюсь на кроссплатформенность - разрабатывая отдельно движок Базы Знаний и отдельно GUI. При необходимости просто тупо создается новый GUI для другой ОС (точнее - берется что-то похожее из открытых проектов и немного переделывается), прилинковывается движок - и все готово

Если будут параллельно выпускаться версии для Винды и для других ОС (как минимум под Linux), то это нормально. А вот если будут просто выкладываться исходные коды - типа "кто хочет - переделывайте под Linux" - так думаю дело не пойдет...

Всего записей: 371 | Зарегистр. 15-03-2006 | Отправлено: 09:56 14-11-2008
GingerFox



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
hammerit
Главное сделать саму возможность такой вот контейнерной организации. А дальше вариантов уже может быть много. Для каких-то форматов достаточно будет только вьюера (например для графики, чтобы не превращать аутлайнер в фотошоп. Хотя опять, же, если у кого появится необходимость и он напишет простой или более сложный граф.редактор - почему бы и нет?). Какие-то форматы можно будет редактировать только если у пользователя установлен соответствующий пакет (тот же DOC например - т.е. плагин будет вызывать MS Word (не знаю, как это правильно называется - OLE?) в окно отображения листа).
 
Ну и наконец вариант, за который бы я голосовал - если пользователь согласен - перевод/сохранение вставляемого в окно OpenDoc и дальнейшая работа уже в этом формате.
 
А что касается усложнения работы и утяжеления программы... Не думаю, что такой механизм сильно усложнит и утяжелит прогу. Главное, чтобы он был. А дальше - понадобится, можно будет наполнить новым содержанием, нет - будет отрабатывать стандартный плагин ввод-вывод-правка HTML, если уж так хотите.
 
Что касаемо OpenDoc, я сейчас как раз вентилирую этот вопрос, как я понял, команда разработчиков OpenOffice создала и библиотеки, и платформу и SDK для работы с документами в OpenDoc формате. Как разберусь - доложу. И кстати все это богатство честно и легально бесплатное.  
 
xcode
Думайте шире! Зачем ограничивать количество сценариев использования программы только одним, который Вы привели? Если сделать универсальный расширяемый инструмент, то он может развиваться во что угодно. Сделать правильную платформу, в которую by design встроена возможность расширения. Пример - тот же Firefox. Сам по себе, без плагинов, он не лучше IE, вся его мощь и красота - в наращиваемости, в том, что из него можно выпилить что угодно, как по оформлению (скины и пр.), так и по функционалу (плагины и расширения), сделать из него хоть "IE", хоть "Оперу". Вот пример не просто программы, а платформы.
 
Господа (или товарищи) - не делайте просто KompoZer с деревом слева! Ну не стоит силы тратить. Давайте платформу сделаем, а наполнение будет.

Всего записей: 319 | Зарегистр. 06-11-2003 | Отправлено: 12:02 14-11-2008
SFC



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
А чем будущая программа отличаться от уже существующих аналогов, т.е. что в ней будет такое, чего нет в уже существующих например:
- из тех что с открытыми кодами, например: TTC http://sourceforge.net/projects/totaltext/ правда он на делфи,
- или чисто для комплексных проектов разработки ПО: DevProject Manager, http://www.gaijin.at/dldevproject.php тоже кстати бесплатный

----------
[ offline ]

Всего записей: 1671 | Зарегистр. 21-01-2003 | Отправлено: 10:43 15-11-2008 | Исправлено: SFC, 10:44 15-11-2008
xcode



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Спасибо, я конечно посмотрю на эти софтины.
А отличаться она будет интеграцией со средой разработки.
Представьте себе огромный проект (а еще лучше - solution с десятками связанных между собой проектов, разрабатываемых в течение многих лет), десятки тысяч файлов с исходниками, десятки разработчиков, которые еще и увольняются, и приходят  новые, и т.д.
Или другая задача - открытый open-source проект, который разрабатывают люди со всего мира, а вам нужно в нем быстро разобраться.
Вот тут-то и пригодится моя программа. Основная идея в том, что исходные коды программы включают в себя комментарии специального вида, являющиеся гиперссылами на базу аутлайнера. Любой человек, желающий разобраться в проекте, может пойти разными путями
* просматривать страницы аутлайнера, начиная с корня, открывая интересующие его разделы
* при необходимости переходить к исходникам проекта,  
* из исходников можно по гиперкомментариям переходить на страницы базы аутлайнера
* осуществлять поиск страниц аутлайнера по тегам, по ключевым словам и т.д.
* редактировать страницы базы знаний, добавлять их в общую базу знаний на сервере (через VCS)
 
Все эти действия можно делать как из среды разработки, так и из самого аутлайнера, который также умеет читать файлы проектов и имеет свой редактор исходников с подсветкой синтаксиса.
 
Собственно, это и есть основная идея. Как побочная идея - просто многопользовательский аутлайнер (я уже реально столкнулся с проблемой: у меня есть комп и ноут, иногда я работаю на компе, иногда на ноуте, и очень хотелось бы синхронизировать базы TreePad'а... а еще есть комп на работе, и там своя база, которую тоже хотелось бы засинхронизировать)
 
Еще очень полезной является идея различных диаграмм типа UML, я хочу объединить их с аутлайнером. Должна получиться очень мощная концепция - некоторые страницы могут быть диаграммами, из них можно переходить по гиперсылкам на другие страницы и т.д.  
 
Дальше можно копать в направлениях
* PIM, встроенная распределенная база данных
* органайзер, напоминалка
* интеграция с email, браузерами
 
но это уже на плагинах, эти функции для меня не являются актуальными.
 
 

Всего записей: 240 | Зарегистр. 25-12-2005 | Отправлено: 13:30 15-11-2008
SFC



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
огромный проект (а еще лучше - solution с десятками связанных между собой проектов, разрабатываемых в течение многих лет), десятки тысяч файлов с исходниками, десятки разработчиков, которые еще и увольняются, и приходят  новые, и т.д.  
Или другая задача - открытый open-source проект, который разрабатывают люди со всего мира, а вам нужно в нем быстро разобраться

Похоже разработчики DevProject Manager ставили перед собой аналогичную задачу, и создали инструмент для руководителя сложного проекта, но НЕ для совместной работы многих пользователей над однимпроектом. На сколько они хорошо ее реализовали - может оценить только тот кому это действительно надо.
 
Для полной реализиции и возможности совместной работы многих пользователей над проектами возможно все-таки понадобится полноценная система управления контентом. Конечно на www.sf.net есть большой выбор CMS или DMS, но они не на С++, а в основном РНР использует какие-либо базы данных.

----------
[ offline ]

Всего записей: 1671 | Зарегистр. 21-01-2003 | Отправлено: 10:28 17-11-2008
xcode



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
DevProject Manager - это обычный аутлайнер. Точнее, даже урезанный, т.к. там заложена жесткая струткура дерева. Я же разрабатываю полноценный аутлайнер, с полностью динамической структурой дерева. То что там есть - база данных фрагментов кода. Хорошая вещь, хотя особого смысла я в ней не вижу. Но сделать можно - затраты на эту фичу минимальные.
 
Для многопользовательских функций, как я уже говорил, будет использоваться система контроля версий SVN. Функции SVN будут доступны через специальный плагин. Насколько я понимаю, CMS работают по тому-же принципу, хотя точно не знаю.  
Но, например, wiki точно работает по принципу систем контроля версий, там есть функции отката страницы, отслеживания изменений для каждой страницы и т.д. Здесь будет все то же самое, но не на web-интерфейсе, а на программе-клиенте. Ничего подобного просто нет.
 
Функция интеграции со средой разработки - это вообще принципиально новая фича, аналогов ее нет в мире.
 
Также нет ни одного аутлайнера, который объединял бы текст, диаграммы разных типов и таблицы БД.
 
Сейчас я написал код для многофайлового дерева, и выяснились некоторые интересные особенности: за счет возможности многофайловой организации в дереве могут возникать циклические ссылки и ссылки из двух веток на одну ноду.Циклические я запретил сразу, т.к. дерево загружается в память целиком и циклические ссылки приведут к бесконечной рекурсии. А ссылки на одну ноду... в принципе, вполне могут быть. Но теперь возникла интересная особенность - нода одна, а ее представлений в дереве несколько, и изменение в одном месте должно приводить к изменениям во всех остальных местах
 
 

Всего записей: 240 | Зарегистр. 25-12-2005 | Отправлено: 14:08 17-11-2008
igvis

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
2 SFC

Цитата:
Я также имею определенные наработки в этой сфере и даже планирую сделать коммерчески успешный проект - интернет портал.

 
Извини, портал мне не интересен. Интересна глобальная база знаний. Типа справочника.
Вот ещё немного из ошмётков анализа.
--------------------------------------
Итак, продолжаем.  
Таким образом, после некоторой аналитики мы имеем в сухом остатке следующее.  
1. Практика форумов показывает их неэфективность в решении большинства вопросов.  
2. Любая работа (проект) сводится к совокупности индивидуальных работ той или иной направленности.  
3. Для работы индивидуумов необходима энергоположительная среда. Среда, в которой каждый индивидуум получает нечто компенсирующее его затраты на работу. В качестве таковой среды для случайных участников (стандартная ситуация на форумах) предлагается авторское право. Это право позволяет индивидууму не терять свои результаты труда и в то-же время делает их публично доступными.
4. Для повышения эффективности работы предлагается ввести "управляемость" и "структурность".  
"Управляемость" означает простоту доступа и оперирования накопленной информацией (результатов индивидуальной работы).  
"Структурность" означает формальное деление результатов индивидуальной работы на структурные элементы типа "аксиома/постулат", "ссылка на", "вывод", резерв.  
В качестве визуальной картинки для понимания "структурности" предлагается картинка возведение здания. Однажды предложенное знание/кирпич навечно остаётся в общей структуре.  
5. Дополнительно предлагается "парный" принцип позволяющий проводить фильтрацию по некоторым признакам. Принцип является важной составляющей системы.  
--------------------------------------
В общем виде, я рассматриваю данную систему как среду позволяющую неорганизованное хаотичное движение людей упорядочить в направленное движение построения базы знаний. Данная система представляет собой первую версию естественного общественного интеллекта.

Всего записей: 16 | Зарегистр. 04-02-2008 | Отправлено: 10:15 19-11-2008
usr721

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Наверно все таки xml а не html для хранения? html как бы частная реализация xml со своим определенным набором тегов. Как хотя бы в новом офисе - xml'ки  в архиве (без сжатия файлы будут большими, xml очень избыточен тк не бинарный формат). Потом выводе преобразовывать через xslt и показвать.
 
Из функция нужно одновременное открытие нескольких деревьев (или баз) в табах. Экспорт в разные форматы (pdf, chm, др). Вставка рисунков скопированных прямо из FF Работа под линуск (может qt гуи).
 
А когда появится альфа чудо-редактора?

Всего записей: 721 | Зарегистр. 10-07-2006 | Отправлено: 18:24 05-08-2009
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3

Компьютерный форум Ru.Board » Компьютеры » Программы » Разработка редактора с древовидной структурой


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2025

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru