Очень хорошая программа. Действительно работает стабильно. Даже под Windows XP
Испытывалась сборка 0.9 "со словарями" и exe'шником rev352.
Она уже настолько удобна, даже в сравнении с 0.8, что появляется множество мелких предложений по улучшению интерфейса. Не обессудьте: дальше есть и более масштабные вопросы/идеи.
Для своего и Вашего удобства все свои наблюдения и замечания пронумеровал.
1. HOYKEYS, КЛАВИШИ И СМЕНА ГРУПП
1.1. Последовательность действий: запустил программу, выбрал англ.группу, ввёл в строку слово "парень", нажал Enter, получил "ничего не найдено". Затем нажал Alt+П(G) (открылся список групп), клавишами клавы перешёл в нём на русскую группу и нажал Enter. Выбралась группа 'All'. Непонятно. Иногда работает нормально. При выборе мышью - вроде всегда нормально.
2. СЛОЖНОСТЬ В ОТКРЫТИИ НОВЫХ ВКЛАДОК
2.1. Чтобы не приходилось дважды щёлкать мышью и искать ею нужную опцию в меню - нельзя ли добавить возможность открывать ссылку в новой вкладке не через опции контекстного меню, а путём нажатия на какую-нибудь клавишу (по умолчанию Ctrl) одновременно с щелчком мышью?
2.2. Нечто сходное, возможно, имеет смысл внедрить для поиска выделенного словосочетания в новой карточке. Сейчас приходится либо использовать меню, либо открывать через Ctrl+C+C.
2.3. И для "тотального поиска" (в новой карточке), если Вы сочтёте нужным внедрить такую функцию (см.п.5).
3. НЕСТАБИЛЬНОСТЬ КАРТОЧКИ, ПОЛУЧАЕМОЙ ПО Ctrl+C+C
3.1. Она исчезает, если замешкаться и не переместить на неё мышь; если случайно увести мышь с неё (прочитана - можно убирать?); если чуть-чуть задеть колёсико мыши, перемещая указатель к ней, когда он ещё не достиг окна карточки. Может быть, стОит по умолчанию делать её "жёсткой" (хотя бы для желающих - через 'Preferences')? Или по второй комбинации hotkeys - e.g. Ctrl+Z. Сейчас нужно делать её "стабильным" с помощью мыши, и сохраняется опасность задеть колёсико. Неудобно.
3.2. А внутри неё колёсико не работает, пока её не закрепишь на экране жёстко, вместо неё проматывается страница, с которой был сделан запрос. Тоже не ахти как удобно.
4. ЛОГИКА КОНТЕКСТНОГО МЕНЮ
4.1. Понятно, что случайно выделенную фразу или слово полезно "поискать" в других словарях группы. Но опции "поиск" и "поиск в новой вкладке" предлагаются и при щелчке правой кнопкой мыши по ссылке. Зачем? При использовании на ссылке результат у "открыть" и "открыть ссылку в новой вкладке" - тот же, что у "поискать".
4.2. В опциях "поиск" и "поиск в новой вкладке" очень пригодился бы второй уровень контекстного меню, по стрелке предлагающий список групп - на случай, если я пытаюсь поискать слово другого языка.
5. ТОТАЛЬНЫЙ ПОИСК
5.1. Не помешала бы ещё и функция тотального поиска по запросу - не только в заголовках словарных статей, но и в их тексте (т.к. некоторые словосочетания обнаруживаются лишь в примерах, глубоко внутри статей). Она может иметь три разновидности - 1) по данному словарю, 2) по всем словарям в группе, 3) по всем словарям всех групп. Какую разновидность и где лучше использовать - вопрос сложный, нужно подумать. Но сама функция м.б. востребована как при поиске "из статьи" - в меню, так и при первичном поиске - из строки запроса (особенно если этот поиск неудачен).
6. НЕОБХОДИМОСТЬ ЧАСТО ВРУЧНУЮ МЕНЯТЬ РАСКЛАДКУ КЛАВЫ ИЛИ ГРУППУ
6.1. Автоматическая смена группы при смене раскладки - это логично. Мало кто будет ставить в одну группу словари столь разных направлений, что в них могут быть статьи к словам в разных алфавитах. Хотя сейчас группы формируются по случайному признаку... но, может быть, им можно присвоить НЕОБЯЗАТЕЛЬНЫЕ параметры "язык запроса" и "язык перевода" - и работать тогда по ним? В этом случае можно было бы реализовать и автозаполнение таких групп словарями (по команде пользователя), и автоматическое предложение иконки [а лучше двух] для группы. Если так не получится, нельзя ли будет организовать ручную установку "парности" конкретных групп?
6.2. Автоматическая смена раскладки при переходе в другую группу тоже была бы очень полезна, если только возможно определить прописанную для данной группы или преобладающую в ней раскладку, или её парность к прежней группе как "группы обратного перевода".
6.3. При вызове окна по Ctrl+C+C при неудачном поиске слова в текущей группе не помешал бы автопоиск наиболее подходящей группы (в которой будут ответы) и, ежели таковая(ые) найдутся, выдача ответа в ней (в той, где ответов больше?). Автопоиск можно начинать (и завершать в случае успеха) сразу с "парной" группы или "группы обратного перевода" (буде какой-то из этих вариантов будет реализован).
6.4. Если мы открыли "поиском" вкладку со словом другого языка, и не увидели перевода, мы меняем группу. При этом содержимое вкладки автоматически не меняется, что обидно. Наверное, если происходит смена группы, а в некоторых из открытых вкладок не было найдено ни одного перевода для группы, что была активной раньше, стОит произвести для них автоматически новый поиск. Хотя бы для вкладки, активной в данный момент.
6.5. Сейчас в таких ситуациях случаются иногда приятные сюрпризы, но бессистемно. Скажем, если в стандартной английской группе запросить 'whitish', а с полученной карточки Апресяна - "поискать белесоватый", ничего не будет найдено (в англ.группе). Но если уже была раньше открыта и случайно до сих пор провисела карточка с любым словом из русской группы, то в контекстном меню предложат дополнительно две опции "поискать" и в русской группе. При этом одна из опций имеет опознавательную иконку группы, а другая - "+"... Если же вкладки в нужной мне группе открыто не было, рассчитывать на такое везение не приходится, так что п.6.4 м.б. полезен. А в контекстном меню удобнее было бы сделать дефолтной текущую группу, а вторым уровнем выбора для поиска - все группы вообще (см.п.4.2).
6.6. Конечно, можно делать иначе, в режиме "умной" программы, которая сама всё знает. Скажем, "молча" помнит, что если все словари в группе имеют одно направление, то и вся группа тоже... Но это хуже: я, например, к англо-русским словарям добавляю английские толковые, а хотелось бы видеть эту группу целиком в "обратном переводе", т.е. назначать признаки языков старта и финиша группы произвольно, даже если отдельные словари в группе не таковы. "Ум" программы здесь лучше ограничить предложением скинуть в новую группу с указанным направлением все соответствующие словари. Чтобы потом можно было часть удалить или добавить совсем другие. А при отсутствии явного указания программа может НЕ пытаться вычислить направление, считать его "неопределённым". ИМХО все будут довольны.
7. ПРЕДСТАВЛЕНИЕ СЛОВАРЕЙ (И ГРУПП)
7.1. В рамке 'Dictionary information' остаётся много пустого места. Может быть, стОит выводить туда содержимое файла .ann, буде таковой найдётся (хотя бы для словарей .dsl)? Если там аннотации на разных языках - то на языке, выбранном для интерфейса программы, если только один - на нём, какой бы ни был, если их много, но ни один не совпадает с языком интерфейса - на английском / других известных и распространённых по мере убывания популярности, буде известные найдутся, иначе на первом попавшемся . Или - если их много, а соответствия языку интерфейса нет - просто выводить их все... Или можно выставить там же список языков, на которых представлены аннотации, чтобы была возможность выбора.
7.2. В списке файлов словаря почему-то не упоминается его иконка, даже если она подхвачена. Не то, чтобы это сильно мешало работать, но как-то напрягает.
7.3. К сожалению, .bmp не поддерживает прозрачных цветов. Нельзя ли внедрить поддержку ещё какого-нибудь формата для иконок словарей - .gif или .png? Или организовать искусственную поддержку прозрачного цвета, всегда определённого (e.g. лилового RGB ff00ff)? Вопрос возник, поскольку в программе значок словаря может появляться на разном фоне - белом в настройках, сером в контекстном меню основного окна (карточки)...
7.4. Соответственно, в отношении значков групп такой же вопрос пока не возникает, но было бы логично добавить поддержку формата "с прозрачностью" либо "самой прозрачности" (искусственно) и там тоже. Хотя там она, кажется, уже есть, судя по иконкам групп 'All' и 'Wikipedia'...
8. РЕДАКТИРОВАНИЕ ГРУПП И КОМПОНОВКА СЛОВАРЕЙ
8.1. Хотелось бы иметь опцию создания группы на основе другой, т.е. с копированием свойств и набора словарей уже существующей группы для последующей мелкой правки (удаления/добавления чего-либо).
8.2. Хотелось бы иметь возможность изменять порядок словарей не только через область 'Dictionary order' вкладки 'Dictionaries', но и через совершенно идентичную 'Dictionaries available' во вкладке 'Groups'. Поскольку программа всё равно не помнит порядка неактивных словарей в списке, это ничему не помешает.
8.3. Хотелось бы иметь возможность подгружать свои значки либо для конкретной группы, либо в библиотеку значков групп.
9. ТРАНСЛИТ
9.1. Не помешал бы справочный файл с описанием правил транслитерации конкретного словаря - для любопытствующих. Чтобы они могли сразу точно узнать, что для поиска слова "ежиха" нужно набирать 'ezhiha', а не, допустим, 'yezhikha' (как я пытался). Да и другие правила поглядеть, чтобы избежать в дальнейшем новых сюрпризов / творческого поиска.
9.2. Если это возможно, стОило бы устранить проблему с неполным набором слова. Если мы ищем в русской группе слово "ёж" транслитом, то при наборе 'yoz' все предложения исчезают, а при добавлении 'h' - снова появляются ('yozh'). Видимо, программа вначале преобразует транслит в кириллический текст, а затем уже ищет. Конечно, обратный процесс (преобразование всех слов в транслит и поиск среди них) вряд ли разумен. Но, может быть, возможно преобразовать строку поиска в несколько вариантов запрашиваемого слова - в предположении, что группа символов транслита может быть недописана?
10. БУКВА 'Ё'
10.1. Думаю, многим людям стало бы намного удобнее, если бы появилась возможность поиска с неверным вводом "ё" - например, слова "ёж" запросом "еж". Для тренирующихся в правильном употреблении букв алфавита можно поставить в настройках флажок снятия/включения такого сервиса.
10.2. Аналогично для транслита - хотелось бы видеть "ёж" и по запросу 'ezh'. Впрочем, если 'ezh' преобразуется в "еж", а потом уже слово "еж" ищется в словарях, то при внедрении такой фичи для кириллического "ё" в транслите всё заработает само собой...
11. СЛОЖНОСТИ С АББРЕВИАТУРАМИ И ВСПЛЫВАЮЩИМ ОКНОМ
11.1. Не совсем ясно сделано с аббревиатурами. Похоже, сейчас они работают при разрешённом всплывающем окне. А чтобы оно не мешало, можно его отключить (и не включать при старте) - аббревиатуры продолжат работать. Непонятно, почему так, находится этот вариант не сразу. Может быть, стОило бы сделать всплывающую подсказку для аббревиатур работающей всегда или регулируемой отдельно от всплывающей подсказки с переводом? Или в меню параметров как-то отразить эту тонкость всплывающим help'ом? Чтобы не нужно было долго копаться, пытаясь понять, почему аббревиатуры не работают... согласитесь, решение "нужно разрешить, но отключить всплывающее окно" придёт на ум не сразу.
12. ЗАЩИТА ОТ ДУРАКА
12.1. Пока что не внедрена защита от изобретательного дурака. Если подложить программе словарь .dsl, заархивированный не DictZip'ом, а GZip'ом (использовался 7-Zip 4.65, компрессия Ultra), и переименованный в *.dsl.dz, она обработает такой словарь неверно. Т.е. она примет его за нормальный, проиндексирует, будет выдавать варианты из него в столбце под строкой запроса, а при попытке вызвать карточку с данными из такого словаря - вылетать. Процесс при этом остаётся в памяти, и программа заново не запускается, пока его не прибьют. ИМХО лучше всего была бы пассивная защита: проверка корректности архива самим GoldenDict - .dsl.dz ему подсунули или подделку. Несколько хуже, но всё равно неплохо, работала бы активная защита - включение DictZip в пакет и возможность его вызова через GUI и запуска: ручного / автоматического при обнаружении несжатого словаря / по запросу программы и с разрешения пользователя при обнаружении несжатого словаря... Ведь DictZip, кажется, GPL-ный?
13. ЭКСПОРТ И ИМПОРТ КОНФИГУРАЦИИ ЦЕЛИКОМ И ПО ЧАСТЯМ
13.1. Пригодилась бы возможность сохранять (и подгружать) отдельно "конфигурацию групп" (всех или только некоторых - отмеченных), "конфигурацию интерфейса" и "полную конфигурацию" (сейчас очень часто приходится лезть за ней в <Documents and Settings>, чтобы потом скидывать новому пользователю), а она вдобавок не модульная, так что я делаю и держу их наготове несколько. Теперь, с появлением "порядка словарей" не только в отдельной группе, но и в списке словарей в целом, м.б. смысл сохранять и "конфигурацию словарей".
13.2. При импорте таких разборных конфигураций наверняка пригодилась бы возможность указать в окне "Открыть" сразу несколько файлов. Может быть, для облегчения жизни пользователей и самой программы стОит таким файлам экспортированных конфигураций присваивать специальное расширение, не знаю.
13.3. При подгрузке "конфигурации групп" (или словарей) может оказаться полезной возможность не только искать упоминаемые там словари среди имеющихся, но и указать программе их местонахождение по её запросу (с выбором - копировать их в один из уже прописанных каталогов со словарями, куда-либо внутрь одного из прописанных с рекурсией, либо оставить где лежат со включением нового каталога в список просто так или рекурсивно). Тогда после первого ненайденного словаря у программы будут хорошие шансы отыскать остальные без дальнейших подсказок пользователя.
14. ХРАНЕНИЕ ИНДЕКСОВ
14.1. Немного удивляет выбор места для хранения индексов. Словари изначально лежат в папке программы, что подталкивает к размещению других словарей там же. Но индексы к ним - внутри папки с личными настройками пользователя. Если словари - общие (а так бывает, не обязательно люди в настройках выставят себе непересекающиеся области поиска словарей), зачем делать для каждого из них по копии индекса? Когда на машине работает посменно шесть человек, это не ведёт к экономии места на системном диске. Файлы config - понятно. Но для индексов ИМХО стоило бы сделать единую для всех папку. Хоть в директории самой программы.
С благодарностью и глубоким уважением,
Oliver.
P.S. Чуть не забыл!
15. МИМИКРИЯ ПОД LINGVO
15.1. Для вящего удобства вконец зажравшихся пользователей пригодилась бы ещё одна опция - автоматическая смена Ctrl+C+C на Ctrl+Ins+Ins на вкладке 'Hotkeys' в случае смены 'Display style' на 'Lingvo' во вкладке 'Interface' (но не обратный процесс!). Да, это вещи, по природе своей не связанные. Но с точки зрения пользователя и то, и другое относится именно к максимальному приближению к привычному Lingvo.