Читалка и словарь

[geometer]

Приветствую всех,

тут возник "архитектурный" вопрос в процессе написания FBReader, и я решил обратиться за советом к общественности.

Одна из явно недостающих фич – это интеграция со словарем. Тут вопроса нету, ее нужно делать. Вопрос – как делать.

Основные варианты:
1) Когда нужно – вызывать стороннюю программу – смотрелку словаря. Например, zbedic, или гипотетическую смотрелку sdictionary.
2) Встроить возможность показа словарных статей прямо в FBReader.

У обоих вариантов есть свои плюсы и минусы, хотелось бы услышать глас народа – что лучше, что хуже, и почему. И нету ли еще вариантов?

[Darkcat]

ИМХО - сделать кнопочку "перевод слова" при активации которой тап стилуса на слове вызывает диалоговое окно (от читалки) с переводом. Это быстрее и понятнее, чем вызывать другую программу.

[Mikhail Kostousov]

Сам немного ковырялся еще с justreaderom - подправлял его работу со словорем. Там был вытащен кусок от ZBedic...
Если можно, то я немного напишу своих не реализованных задумок и мыслей. Если нельзя - прошу извенить и не читать мой пост.

1) Перекидывать слово в стороннюю программу, аля ZBedic или еще что-то, берет очень много времени, по крайней мере на старых машинках с малой памятью. Потом, ZBedic - чужой. Ни кто, конечно, не мешает его править, но он адаптирован именно как просто словарь, а не как словарь для активного перевода текста... Но с другой стороны, я думал, имеет смысл связаться с автором ZBedic с просьбой разделить его библиотеку и морду-интерфейс, дабы можно было пользоваться открыто механикой ZBedic но со своими наворотами. И в тоже самое время - не переписывать половину модуля работы со словарем из-за того, что в ZBedic появилась новая приятная фича.
2) Насчет перевода внутри читалки. Если его реализовать непосредственно, то внутри можно реализовать дополнительные механизмы помогающие читателю читать быстро и удобно. Понятно, что текст состоит не из словарных слов, а в основном из их форм. Поэтому была мысль сделать механизм трансформации слов, например, на основе регулярных выражений (для английского языка).
Например, ткнули на слово которое имеет вид(регулярные выражения я не пишу здесь для большей понятности)
"XXXXXXing", если его нету, можно попробовать найти слово "XXXXXX", Или, XXXXXed->XXXXXe->XXXXX
XXXXXs->XXXXX
XXXXXer->XXXXX
Можно попробовать сделать возможность автоматических подстановок для словарей и распространять их вместе со словарями...
Я делал в JustReader просто обрубку последних букв. Так, если нет слова ABCDEFG, то пытался найти слово ABCDEF, если не нашлось такое, то ABCDE
Но обрубал не более трех букв.
Боюсь, что меня могут не совсем понять, поэтому пытаюсь сконцентрировать на деталях, которые, на мой взгляд, наиболее важны.
Так, например, по мимо предложенного варианта слова, нужна возможность быстро дополнить его (зная по правилам граматики, что это может быть форма другого слова), тоесть должена быть возможность изменения слова, плюс - автоматический вызов клавиатуры. Потом другая проблема, нажав на слово, и получив поверху диалог словаря, часто теряешь место где читал. Вот бы это слово подсветить не надолго после сворачивания словаря. Потом, в словорях очень любят писать "см то-то". Это "то-то" приходится самому набирать... А все влияет на скорость чтения, а при чтении художественной литературы, интерес теряется к произведению. Вот бы по нажатию "то-то" сново переходить по словарю...
Я прошу прощения, что столько написал коментариев по теме (а может и не по теме). Надеюсь, что ни чем не обидел автора, советуя и рассуждая.

Хочу еще поблагодарить geometr'a за чудесную читалку. И хочу предложить помощь, пусть небольшую, ввиду недостатка времени, но может быть весомую.

[jkukka]

Я за встраивание перевода, т.к. при этом можно будет оформить перевод красиво, например, в виде тултипа. Ну и по скорости это выигрышнее.

[geometer]

Я прошу прощения, что столько написал коментариев по теме (а может и не по теме). Надеюсь, что ни чем не обидел автора, советуя и рассуждая.

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

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

Про перебор форм слова -- надо бы посмотреть, наверняка ведь есть какая-нибудь стандартная техника (а то и готовая/почти готовая библиотека). Может, кто-то знает что-нибудь об этом?

[geometer]

Я за встраивание перевода, т.к. при этом можно будет оформить перевод красиво, например, в виде тултипа. Ну и по скорости это выигрышнее.

Про тултип я думал с самого начала, но тут есть проблема, что делать, если точно такого слова нет в словаре. Ну хорошо, если его удастся однозначно угадать. А если будет несколько вариантов, например? А если ни одного, тогда что делать? А если угадывание прошло неудачно -- как посмотреть в словаре близкие слова?

Я не к тому, что вариант плохой, наоборот, было бы очень здорово его таки реализовать. Но надо придумать удобные действия во всех случаях. Принимаются все идеи по этому поводу.

[zGremlin]

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

Вообще-то zbedic и так разбит на библиотеку и интерфейс...
Вот только библиока статическая, и поэтому влинковывается в исполняемый файл.

Про тултип я думал с самого начала, но тут есть проблема, что делать, если точно такого слова нет в словаре. Ну хорошо, если его удастся однозначно угадать. А если будет несколько вариантов, например? А если ни одного, тогда что делать? А если угадывание прошло неудачно -- как посмотреть в словаре близкие слова?

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

Я бы предпочел открывать полноценное окно... но в голову пришел и компромисс - отображать тултип с возможностью его свернуть или развернуть в (полноэкранное) окно, где и будут все навороты (скажем по кнопкам в тултипе или его заголовке или просто кликом на тултипе или снаружи).

[jkukka]

Про тултип я думал с самого начала, но тут есть проблема, что делать, если точно такого слова нет в словаре. Ну хорошо, если его удастся однозначно угадать. А если будет несколько вариантов, например? А если ни одного, тогда что делать? А если угадывание прошло неудачно -- как посмотреть в словаре близкие слова?

Я не к тому, что вариант плохой, наоборот, было бы очень здорово его таки реализовать. Но надо придумать удобные действия во всех случаях. Принимаются все идеи по этому поводу.

Сделать в тултипе ссылке "подробнее", по которой открывать большое окно со статьей, списком слов и теде.

[Mikhail Kostousov]

Про тултип я думал с самого начала, но тут есть проблема, что делать, если точно такого слова нет в словаре. Ну хорошо, если его удастся однозначно угадать. А если будет несколько вариантов, например? А если ни одного, тогда что делать? А если угадывание прошло неудачно -- как посмотреть в словаре близкие слова?

Я не к тому, что вариант плохой, наоборот, было бы очень здорово его таки реализовать. Но надо придумать удобные действия во всех случаях. Принимаются все идеи по этому поводу.

Сделать в тултипе ссылке "подробнее", по которой открывать большое окно со статьей, списком слов и теде.

А надо попробовать посмотреть, до какого количества слов можно добраться только с тоолтипом... Тоесть, одним кликом. Если в больше 50% случаев придется нажимать подробнее, то это получится не рационально.

А вообще, если речь идет, допустим, об английских словарях. Есть словари типа сократа, где слову на английском ставится практически один вариант слова на русском, без форм, без примеров, без слово-сочетаний. Может быть имеет смысл сделать так, что бы при нажатии на слово появлялось маленькая подсказка со словом из одного словаря, а при нажатие на "более подробно" появлялась более подробная статья из другого словаря, например словаря мюллера?

[DMych]

А по мне так лучше не париться, а вызывать внешнюю прогу. Ну не хочу я дублировать (по сути) функциональность уже стоящего словаря, к тому же не так часто он бывает нужен. А размер дистрибутива увеличится значительно (да еще словари пусть собственные будут, в збедиковском же формате, но в другом каталоге... - тут я ваще выкину такой "телевизор со встроенным тостером" нафик! ).
Как вариант - сделать набор модулей/плагинов, доставляемых отдельными ipk (ну, и для ленивых - all-in-one.ipk):

• поддержка такого-то формата (напр. мне нужны форматы Псиона и Пальма - спасибо тов. Геометру за них, а кому-то - нет, а мне вот LIT не нужен напрочь)
• поддержка gzip/bzip/...
• встроенный словарь
• (что еще можно "оторвать" от базовой читалки?)

[jkukka]

Кстати, а может сделать плугинный словарь? Если читалка решила, что пользователь выбрал "перевести это слово-фразу", вызывается у плугина translate(const string& text). Ну, а дальше на выбор -- вызов внешней программы, тултип, чего-изволите.

[Mikhail Kostousov]

Вообще-то zbedic и так разбит на библиотеку и интерфейс...

Я в курсе, но одна из проблем в том, что в библиотеке - поиск слова и получение статьи, а в интерфейсной части - форматирование статьи в удобный словарный вид, который уже отображается.

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

Я на это и сетовал про слитность zbedic'а... Если разделить zbedic но интерфейс и библиотеку, и использовать эту же самую библиотеку в FBReader - всем будет хорошо.. Проблема лишь в том, что после каждой новой версии ZBedic нужно будет его немножко резать - на интерфейс и библиотеку... Это абсолютно не сложно, и видимо в этом ключ. Но тут же появляется желание, а не использовать ли словари, которые уже дабавленны в ZBedic, тогда в библиотеку должны переместится считывание настроек расположения словарей...
P.S. Ни кто не мешает указывать FB словари из того же места, где лежат словори от ZBedic....
P.P.S. А если сделать нормальную библиотеку перевода из того-же ZBedic его можно потихоньку попытаться встроить еще куда-нибудь. Например в какую-нибудь pdf читалку. Не все же pdf-ки имеют сканированный вид. А в далеком будущем, может быть, какой-нибудь герой портирует нормальный браузер, и можно будет встроить этот браузер интерфейс к переводу...

[Mikhail Kostousov]

Как вариант - сделать набор модулей/плагинов, доставляемых отдельными ipk (ну, и для ленивых - all-in-one.ipk):

Плагинность - всегда хорошо. Во первых - можно выбрать по желанию, а во вторых - может появится куча сторонников, которые тут-же примутся писать всякие прибамбасы... Но написать хороший плагинный api, что бы плагины цеплялись, когда пользователю хочется, работали, и все прочее - это гораздо большее усилие... Тем более, когда система изначально не задумывалась как компонентная... Чаще всего плагинность ограничивается тем, что программа изначально знает, что она может иметь то-то и то-то, но если галочка не стоит в нужном месте, то она не будет пытаться найти соответствующую библиотеку и подключить ее. И все это дополнительный код, время и старания автора. Ради галочки "подключить словарь".

Это одно, а второе, не получится ли это все из пушки по воробьям? Интерфейс - "подключить библиотеку" проверить ее наличие, проверить она ли, та ли версия, подключить, добавить в панель настроек настройки библиотеки, еще куда-что добавить... И все из-за того, что бы не качать лишние 30-40кб... Хотя, я очень не уверен, что код который позволит распоряжаться функциональностью программы станет меньше, чем там желанная функциональность.

Да и ведь вопрос был в том, как построить работу со словарем.

[geometer]

Плагинность - всегда хорошо. Во первых - можно выбрать по желанию, а во вторых - может появится куча сторонников, которые тут-же примутся писать всякие прибамбасы... Но написать хороший плагинный api, что бы плагины цеплялись, когда пользователю хочется, работали, и все прочее - это гораздо большее усилие... Тем более, когда система изначально не задумывалась как компонентная...

Плагины должны появиться со временем. Во всяком случае, поддержка разных форматов давно задумана как система плагинов. Они и написаны почти под это. Но дело здорово осложняется двумя вещами.

1) FBReader задумывался как переносимая программа -- он и работает сейчас на разных платформах. Сделать одновременно кроссплатформенность и работу с плагинами -- не совсем тривиальная задача.

2) Делать плагины (для тех же форматов) имеет смысл, если предоставить желающим API для написания плагинов. Этот API должен быть ясным и не особенно меняться от версии к версии. И вот к этому я пока, увы, не готов.

Впрочем, идея сделать поддержку словаря плагинной тоже принимается с интересом. Спасибо.

[jkukka]

1) FBReader задумывался как переносимая программа -- он и работает сейчас на разных платформах. Сделать одновременно кроссплатформенность и работу с плагинами -- не совсем тривиальная задача.

Хм,
1. dlopen есть везде
2. плагин для формата не должен зависеть от платформы
3. будут кросс-платформенные плугины