Re: [нужны советы]Разработка текстового процессора для Linux, PyGTK
4. разобраться с обработкой форматов (может, для начала RTF, потом ODT, так как это уже связано с XML, а не простой разметкой) -с xml работать много проще, чем с rtf.
а использовать существующие библиотеки - по большому счету почти лишает смысла затеи.либы можно и нужно использовать.
чтобы как раз можно было сосредоточиться на том, что ты хочешь сделать - а не увизая в тонне вспомогательного кода.
написать "правильный" со своей точки зрения WYSIWYG текстовый процессор для работы с ODT и выводом в PS/HTMLЗачем? Просто поиграться?
нужны советыЯ могу название предложить: 9002nd Word Processor.
вот тебе идея.
напиши редактор, работающий с одним, наиболее простым и удобным тебе форматом X.
напиши скрипты для переконвертации из этого формата в другие и наоборот.
сделай так, чтобы программа делеле вид, что она редактирует файл формата Y, а на самом деле она редактирует файл в формате (X который получила с помощью скрипта Y2X, а после редактирования сохраняет в формате Y с помощью X2Y.
возможно, конкретно эта идея - лажа, но можно попробовать ее развить.
тогда для добавления новых форматов файлов не нужно будет читать/понимать/изменять код твоей программы, и другие люди легко смогут это сделать.
если сделаешь "универсальным форматом X" (La)TeX, то это будет вообще здорово, и с радостью буду юзать твою программу
в любом случае, такого еще никто не писал.
напиши редактор, работающий с одним, наиболее простым и удобным тебе форматом X.
напиши скрипты для переконвертации из этого формата в другие и наоборот.
сделай так, чтобы программа делеле вид, что она редактирует файл формата Y, а на самом деле она редактирует файл в формате (X который получила с помощью скрипта Y2X, а после редактирования сохраняет в формате Y с помощью X2Y.
возможно, конкретно эта идея - лажа, но можно попробовать ее развить.
тогда для добавления новых форматов файлов не нужно будет читать/понимать/изменять код твоей программы, и другие люди легко смогут это сделать.
если сделаешь "универсальным форматом X" (La)TeX, то это будет вообще здорово, и с радостью буду юзать твою программу

в любом случае, такого еще никто не писал.
Он же вроде не про идеи спрашивал.
Просто ради интереса, сколько времени ты, без опыта программирования, собираешься потратить на это? Ты представляешь, что на получение минимально работающей версии могут уйти годы, а могут уйти десятилетия?
ЗЫ: Читал старую книжку про какие-то старые паттерны, где всё это рассматривалось на примере реализации текстового редактора на SmallTalk. Названия, к сожалению, не помню.
ЗЫ: Читал старую книжку про какие-то старые паттерны, где всё это рассматривалось на примере реализации текстового редактора на SmallTalk. Названия, к сожалению, не помню.
Читал старую книжку про какие-то старые паттерны,О да!
Просто ради интереса, сколько времени ты, без опыта программирования, собираешься потратить на это? Ты представляешь, что на получение минимально работающей версии могут уйти годы, а могут уйти десятилетия?Мне не нужен полновесный текстовый процессор а-ля OpenOffice Writer. Потому мне кажется, что на то, чтобы выучить язык, научиться читать код и понимать структуру программы, понимать уже реализованные алгоритмы - полгода. К этому же времени можно будет свести подобранные или переписанные алгоритмы и методы воедино в минимально (пусть и криво) работающую программу. А уже потом эти методы заменять, переписывать на свои, добавлять функционал - на это уйдет столько, сколько мне будет актуален и интересен этот проект.
ЗЫ: Читал старую книжку про какие-то старые паттерны, где всё это рассматривалось на примере реализации текстового редактора на SmallTalk. Названия, к сожалению, не помню.
Я могу название предложить: 9002nd Word Processor.
Можете назвать предыдущие 9001? Если мы говорим о *nix, конечно. Мне на ум приходят только AbiWord, OpenOffice Writer, Ted и Kword. Ни один из них не удовлетворяет моим требованиям (Ted еще куда ни шло, но его еще нужно доводить и доводить до ума - проект был в спячке весьма и весьма долго).
вот тебе идея.
напиши редактор, работающий с одним, наиболее простым и удобным тебе форматом X.
напиши скрипты для переконвертации из этого формата в другие и наоборот.
сделай так, чтобы программа делеле вид, что она редактирует файл формата Y, а на самом деле она редактирует файл в формате (X который получила с помощью скрипта Y2X, а после редактирования сохраняет в формате Y с помощью X2Y.
возможно, конкретно эта идея - лажа, но можно попробовать ее развить.
тогда для добавления новых форматов файлов не нужно будет читать/понимать/изменять код твоей программы, и другие люди легко смогут это сделать.
если сделаешь "универсальным форматом X" (La)TeX, то это будет вообще здорово, и с радостью буду юзать твою программу
в любом случае, такого еще никто не писал.
Пока шел домой, примерно о чем-то таком и подумал. Не знаю, насколько это реализуемо, но я подумал, что WYSIWYG редактор HTML с такой заточкой (т.е. не инструмент для веб-дизайна, а просто написание статей и документов в HTML) - это возможно очень клево. Возможности по оформлению опять-таки свести до уровня возможностей средней реализации Markdown. Мне почему-то очень нравится идея, что за счет <video> и <audio> можно, например, реализовать возможность прямо в текст вставлять аудиозапись с микрофона или видео с веб-камеры. Ну, примерно как это можно было делать в Psion Word (были такие старые клевые наладонники с шикарной клавиатурой - в них был лучший в мире текстовый процессор - и в него можно было на лету вставлять запись со встроенного микрофона). Не знаю, насколько это технически возможно, но идея мне нравится. Например, студент пишет конспект и одновременно записывает лекцию с тем, чтобы потом сверить. Или журналист, который записывает интервью с тем, чтобы его потом расшифровать. Или блоггер, записывающий подкаст. Понятно, что возможности по обмену документами в таком виде своеобразны (особенно если появляются дополнительные медиафайлы но для личного пользования - очень круто. И интерфейс в духе VI. Мне кажется, что применять бьютифайеры в логике VIM (в том смысле, что можно легко и гибко определять, до какого момента применять то или иное действие - пара букв, 30 слов, до конца предложения и т.д.) - это очень удобно.
Мне не нужен полновесный текстовый процессор а-ля OpenOffice WriterЕсли бы я думал, что тебе нужно что-то вроде OpenOffice - я бы сказал про столетия; но я сказал только про десятилетия.
Зафигач мод для емакса.
Пиздани реверба!
Да, неплохая идея, для этого понадобится только два вечера и один бородач.
решил наконец реализовать свою мечту - написать "правильный" со своей точки зрения WYSIWYG текстовый процессорКаждый программист в своей жизни обяхан написать:
1) ОС, которая грузится с дискеты и потом работает в защищенном режиме с многозадачностью.
2) Текстовый редактор мечты.
Чувак, возьми уже существующий и улучши. Не делай то, что уже сделано 200 раз до тебя. Заодно заботаешь GTK.
http://www.youtube.com/watch?v=EQAd41VAXWo
Посмотри, мб тебя вдохновит.
Посмотри, мб тебя вдохновит.
неплохо, неплохо 

Круто!
А что надо, чтобы такое сделать?
Желательно ссылку на инструкцию/статью
А что надо, чтобы такое сделать?
Желательно ссылку на инструкцию/статью

Посмотри, мб тебя вдохновит.формат файла при этом какой?
формат файла при этом какой?скорее всего plain text
скорее всего plain textт.е. формулу он сам не пересчитает, при изменении чисел в таблице, или при добавлении новых строк?
Там, по-моему, нужно просто нажать некую комбинацию клавиш, чтобы обновил поля в таблице. Сам org-mode пользуюсь, только таблицы в нем не делаю 

думаю, можно чтобы и пресчитал - скрипты и ещё раз скрипты 

Там, по-моему, нужно просто нажать некую комбинацию клавиш, чтобы обновил поля в таблице. Сам org-mode пользуюсь, только таблицы в нем не делаюа как он тогда понимает, что там, например, сумма, а не среднее должно выводиться?
или надо будет еще раз сказать - что пересчитай именно как сумму?
думаю, можно чтобы и пресчитал - скрипты и ещё раз скриптымне непонятно, а где хранится знание - что в данной ячейке должна выводиться сумма, а не что-то еще.
я бы специальное сочетание клавиш поставил )
хотя признаться в текстовом режиме мне такое не нравится, хоть и впечатляет
хотя признаться в текстовом режиме мне такое не нравится, хоть и впечатляет
Оставить комментарий
Dma22
Честно говоря, решил наконец реализовать свою мечту - написать "правильный" со своей точки зрения WYSIWYG текстовый процессор для работы с ODT и выводом в PS/HTML (возможно, еще и RTF в качестве "legacy" формата). Выбор форматов на самом деле вызван не красноглазием, а прагматизмом: желания писать поддержку для плохо документированных или вообще закрытых форматов вроде DOC или DOCX у меня нет (я явно не скоро доберусь до уровня, когда смогу реализовывать столь сложные вещи лучше, чем уже есть а использовать существующие библиотеки - по большому счету почти лишает смысла затеи. Кроме того, мне нравится идея гибкости документа - вспоминаем pandoc. Собственно говоря, в плане возможностей оформления я хочу затронуть то, что поддерживается самим Markdown+основными его расширениями для поддержки таблиц, аннотаций и т.д., потому аналогия не случайна.Проблема в том, что у меня фактически нет опыта программирования. Сейчас учу Python по официальному тьюториалу+Think Like A Computer Scientist: Learning With Python+Byte Of Python (в перспективе еще возможно Dive Into Python затем буду плавно переходить на PyGTK.
Однако суть в том, что помимо знания языка и алгоритмических трюков, мне явно не хватает понимания структуры программы и того, как вообще пишутся текстовые процессоры. Первую проблему я думаю решить прочитав после всего этого еще "Linux программирование в примерах" Арнольда Роббинса и читая исходники. Вторую проблему я планирую решить читая книжку "The Craft Of Text Editing" by Craig Finseth и опять-таки читая исходники.
Грубо говоря, у меня был следующий план:
1. научиться отображать файлы с базовым оформлением (может, просмотрщик тех же Markdown-файлов)
2. реализовать простейший текстовый редактор
3. разобраться с отображением текста (я так понимаю, копать в сторону Pango+Cairo)
4. разобраться с обработкой форматов (может, для начала RTF, потом ODT, так как это уже связано с XML, а не простой разметкой) - может, для начала написать простейшую утилиту для конвертации markdown2odt или markdown2rtf
5. собственно, уже начать работать над текстовым процессором, имея реализацию (или хотя бы представление о том, как реализовать) все базовые функции с тем, чтобы получить хотя бы минимально рабочую версию.
Я параллельно начал скачивать исходники различных простейших текстовых программ на С (текстовые редакторы, конверторы файловых форматов, etc но сказать честно - с трудом могу их понять (обычно они завязаны на большом количестве системных функций и плохо документированы). Нет, может быть, если вся эта моя затея удастся, я когда-нибудь возьмусь за C, но все-таки не сейчас. Можете ли вы привести примеры полезных исходников на Python (или хотя бы сказать, где искать такие вещи)?
В общем, подводя итоги, вот мои вопросы:
1) можете ли вы посоветовать еще какую-то литературу? По Python, проектированию программ, обработке текста. Помимо книг желательны (почему-то сам я не могу найти) статьи в стиле HOWTO - например, как написать калькулятор на PyGTK. Желательно, не слишком фундаментально (вроде SICP или работ Кнута по тому же TeX-у) - я хочу максимально быстро получить те навыки, которые позволят мне реализовывать свои идеи. Криво или коряво, но все же. Ориентируясь в практическом аспекте мне (как мне кажется) будет проще воспринимать какие-либо фундаментальные идеи о дизайне программы.
2) вышеупомянутый вопрос по исходникам. Желательно на Python - просмотрщики текстовых файлов и документов с оформлением, текстовые редакторы, конвертеры форматов и т.д. Мне нужно увидеть реализацию базовых алгоритмов, без которых нельзя представить текстовый процессор
3) Что вы вообще думаете о такой стратегии?
4) Стоит ли сначала учиться реализовывать вышеупомянутые вещи на Ncurses, или же сразу учиться на GTK?