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, то это будет вообще здорово, и с радостью буду юзать твою программу
в любом случае, такого еще никто не писал.
Он же вроде не про идеи спрашивал.
ЗЫ: Читал старую книжку про какие-то старые паттерны, где всё это рассматривалось на примере реализации текстового редактора на 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?