logo
logo

Форум accessibility

создать новую тему раскрыть все
accessibility Miha Ulanov 19/11/2002 15:53 #написать ответ
Извиняюсь за придирки, но я считаю, что программа должна корректно работать с нестандартными настройками цветов Windows.
Серьезных проблем у Cash в этом смысле нет, но тем не менее, есть пара неприятностей в списках:
1. Если в настройке цветов windows цвет текста отличается от черного, то cash рисует текст в списках странно, то черным, то системным цветом. Попробуйте поставить какой-нибудь нечерный цвет, и поперемещайте курсор по списку.
2. На мой взгляд, вообще не хорошо использовать для фона списков не системные, а свои цвета. С другой стороны, полосатость списков - тоже приятная фича.
 
Итак, я предлагаю:
Сделать в настройках опцию "использовать свои/системные цвета для списков".
Если используются свои цвета, то в списках фон полосатый (как сейчас), а цвет текста должен быть черным (системный цвет текста использовать не следует, вдруг он у кого-то, например, белый).
Если выбрана опция "использовать системные цвета", то их использовать и для фона, и для текста. Полосатостью, видимо, придется пожертвовать.
 
Да, я использую Windows 98.
Испытания рекомендую проводить на цветовой схеме "High contrast black"
 
Dervish: А это совсем не придирки, а рекомендация по-существу. На самом деле как раз сейчас переписывается "полосатый" контрол и я уже задумался насчёт выбора цветовой гаммы. Думаю, что изначально контрол будет показываться теми цветами, как сейчас, но у пользователя будет возможность изменить любой цвет из используемой гаммы. На свой вкус.
 
Осталось только решить, эти настройки должны быть индивидуальные для каждой базы данных или общие для всех баз на данном компьютере.
где хранить настройки цветов Miha Ulanov 19/11/2002 18:07 #написать ответ
По-моему, самое правильное место для хранения настроек цветов - HKCU в системном реестре. Т.е. общие для всех баз, но индивидуальные для каждого пользователя.
 
Dervish: Нет, зарёкся я работать с реестром. ini-файл мне что-то в последнее время больше нравится. А у каждого пользователя и так будет собственный файл настроек, я просто неверно выразился в ответе на прошлый пост. Конечно, имелся ввиду не "весь компьютер", а "для каждого пользователя".
Почему? Vadim 22/11/2002 03:09 #написать ответ
А вот меня как программиста интересует, почему "зарёкся я работать с реестром". В чем вы видите преимущества ini-файлов (которые есть пережиток 16-бит windows)?
 
Dervish: В общем, Вячеслав (см.сообщение ниже) меня опередил и перечислил достоинства ini-файлов. Я только хотел добавить, что хранение настроек в реестре (HKEY_CURRENT_USER) может порождать ключи, которые не будут удалены при деинсталяции программы. Если программу запускали несколько пользователей на одном компьютере, то при деинсталяции будут удалены ключи только того пользователя, который проводил деинсталяцию. Ключи других пользователей останутся.
Почему? А вот почему... Viacheslav 22/11/2002 07:23 #написать ответ
А вы вот подойдите к данному вопросу не со стороны не как программист, а как простой пользователь, и что вам будет удобнее:
1. Что легче править, ini файл или копаться в реестре? А иногда есть необходимость быстро поправить настройки ручками.
2. Я уже поднимал вопрос, что случаются варианты, когда людям приходится работать с НЕ АДМИНОВСКИМИ правами, и соответственно с ЗАПРЕТОМ внесения изменений в системный реестр. И как следствие программа отказывается работать.
3.Снимается необходимость в инсталяции, скопировал все на дискету, перенес на другую машину и все ОК! Работает, а представьте, если все данные настроек находятся в реестре? Это каждый раз  инсталировать программу нужно? Геморрой...
4.Если на то пошло, можно уменьшить трудозатраты программиста на написание допролнительных прибамбасов сохранения и изменения настроек, проще как в Опере сделано, есть ini файл и есть описание, что какой параметр значит, что нужно, можешь и сам изменить.
 
Так что, я поддерживаю Dervish-а : в данном случае, локальный файл настроек лучше чем реестр!
 
Dervish: В общем, всё верно. Только меня тут активно убеждают ini-файл хранить в Application Data, тогда не будет проблем с доступом к папке Program Files. Но тогда будет сложнее переносить программу (вместе с настройками) с дискеты на дискету.
 
Добавлено 27.11.2002:
Наверное, всё-таки придётся писать настройки в реестр. Аргументация такова: для ini-файла очень сложно выбрать место, где его располагать. Папка самой программы в "Program Files" может быть недоступна для записи (если программа запускается не-администратором под Windows`NT), папка "Application Data" вообще может отсутствовать на компьютере, да и, в общем случае, сама программа может запускаться с CD-ROM.
 
Что касательно переноса программы на другой компьютер, можно сделать так, чтобы отсутствие настроек в реестре не мешало запуску программы, чтобы программа использовала все настройки по-умолчанию.
 
Единственная проблема, которая остаётся при таком подходе проявляется, когда программа использовалась на одном компьютере разными пользователями (с разными логинами). В этом случае в реестре останутся ключи, которые не будут удалены при деинсталяции программы. Но совершенно аналогично, невозможно будет удалить все файлы настроек из всех папок "Application Data".
 
Эти мысли возникли в результате обсуждений с Артёмом Фёдоровым, за что ему огромное спасибо.
Насчет ini-файлов Artem Fedorov 22/11/2002 13:48 #написать ответ
Автор решил использовать login текущего юзера как имя для ini-файла и хранить их в папке с программой. Позволю себе не согласиться (с расположением файлов вместе с программой):
1. Как уже было сказано, пользователь может не иметь прав для запись в Program Files. Сохранять надо в $USERDIRApplication DataCash
2. Остальные недостатки несущественны
И насчет реестра Artem Fedorov 22/11/2002 14:06 #написать ответ
Для начала определю пользователя, как человека, который не может писать в реестр в раздел HKEY_LOCAL_MACHINE. В раздел HKEY_CURRENT_USER он может писать всегда. Также пользователь не может писать в папку Program Files.
А теперь касаемо пункта 2
Пользователь, как видно, *может* писать в реестр, но только в свой раздел. В данном случае информацию из этого раздела действительно удобнее хранить в ini-файле из тех соображений, что при деинсталляции инсталлятор не сможет определить (и удалить) записи из реестра других пользователей, кроме текущего. Хотя, т.к. файлы придется хранить в папке юзера, а не в Program FilesCash, то деинсталлятор не найдет их и там. Дилемма... С другой стороны, перенос программы на другой компьютер все равно проще с ini-файлами.
Почему при установке *надо* использовать реестр. При установке желательно в раздел HKLM записать путь к папке Cash. Например, при установке следующей версии, удобно, когда инсталлятор предлагает установить программу в уже существующую папку. А где ее взять, как не в реестре? А если кто-нибудь (в том числе автор) выпустит какие-нибудь дополнительные утилиты, которые должны будут работать с файлами программы, где эта утилита их найдет? Опять же, реестр, ключ HKLM.
Из этого следует, что установку (и деинсталляцию) должен проводить админ и никто другой. Это обычная практика.
 
Dervish: Не слишком ли круто, просить для установки программы учёта личных финансов права админа?
 
Ох уж эти винды! Сплошная маета!
Насчет "просить админа"... Artem Fedorov 22/11/2002 22:20 #написать ответ
В линуксе обычная процедура -- устанавливать программы под root (аналог администратора). Далее сам пользователь (даже если он и есть админ) работает с программой под другим аккаунтом, с ограниченными правами. Это обычная практика в защищенных ОС, только непривычно все это, переходя с Win98. Кстати, для установки можно просто запустить файл setup.exe с правами админа через RunAs.
 
Dervish: Кроме того, надо проверить, устанавливается программа под Windows`95 или Windows`NT, существует ли папка `Application Data` (в Windows`95, если не ошибаюсь её совсем нет?)....
 
Маета!
Маета... Надо использовать реестр! Artem Fedorov 25/11/2002 10:38 #написать ответ
Посмотрел, как все получается и решил, что.. стоит использовать реестр. Посудите сами: (1)файлы в папках Application Data никакой деинсталлятор не удалит (если их было задействовано несколько) -- как и с реестром; (2) чтобы "скопировать программу и все работало", придется надыбать все файлы из всех AppData, что не намного легче по сравнению с вырыванием куска реестра. Видимо, все-таки стОит использовать реестр -- все остальные методы ненадежны.
 
Dervish: И что делать с "потерянными" ключами в реестре? Они ведь даже при деинсталляции не удалятся!
Резюмируя... Artem Fedorov 25/11/2002 13:22 #написать ответ
Суммируя все вышесказанное:
1. Записывать файлы в Application Data ненадежно -- во-первых, под Win95 такой папки вообще нет, а во-вторых, т.к. такая папка есть у каждого пользователя, то при денисталляции файлы оттуда не удалятся (точнее удалятся из Application Data только текущего пользователя). Резюмируя: при деинсталляции точно такая же проблема, как и с реестром.
2. Записывать файлы с именами пользователей в Program Files ненадежно. В системах NT у пользователя может не быть прав на изменение этой папки.
3. Записывать файлы в Системный Реестр ненадежно -- пре деинсталляции удалятся только настройки текущего пользователя, а не всех, у кого они были созданы.
Добавлю, что хотя и можно "пробежать" все папки Application Data всех пользователей (как и все ключи реестра) при деинсталляции, но это опять же ненадежно -- в системах NT у пользователя можен не быть прав на изменение папки Application Data (участков реестра) других пользователей.
 
Из этого получается, что использовать ключи в реестре -- "наименьшее зло". Во-первых, реестр есть *везде* и раздел пользователя доступен для изменения *всегда*.
"И что делать с "потерянными" ключами в реестре?" А ничего. Уже 7 лет существует эта проблема, и решить ее всего одним движением нельзя. Все уже привыкли, что программа деинсталляции может оставить ключи в реестре. К тому же, большинство пользователей это не заботит. А кого заботит, тот не полагается на милость стандартного деинсталлятора, а использует сторонние программы-деинсталляторы. К тому же, большинство пользователей работают на своей машине одни (программа-то "Домашние финансы"), а в таких условиях проблем с удалением из реестра не будет.
 
Dervish: Такое решение, пожалуй, самое простое для меня.
Вдогонку... Artem Fedorov 25/11/2002 10:40 #написать ответ
Application Data в Win95 появляется только с IE 4.0, который в комплекте не идет.
 
Dervish: Согласно MSDN, далеко не со всеми версиями IE 4.0 идёт эта самая Application Data. Точнее, возможна ситуация, когда под Win`95 установлен IE 4.0, а Aplication Data нет.
Не согласен, по пунктам Vadim 28/11/2002 02:40 #написать ответ
>1. Что легче править, ini файл или
>копаться в реестре?
 
Это зависит от формата хранения данных. Вы видели ini-файл Cash? Не очень-то много там руками поправишь. "Обычному" пользователю привычнее исправлять параметры в реестре, пользуясь GUI, чем редактировать текст. Я должен заметить, что авторы программ специально пишут интерфейс редактирования параметров, чтобы пользователи не лазили руками куда не надо.
 
>2. случаются варианты, когда людям
>приходится работать с НЕ АДМИНОВСКИМИ
>правами, и соответственно с ЗАПРЕТОМ
>внесения изменений в системный реестр
 
Запрет на запись в определенные папки и сложность нахождения ..ApplicationData уже обсуждались. Вывод - с файлами еще хуже.
 
>3.Снимается необходимость в
>инсталяции, скопировал все на дискету,
>перенес на другую машину и все ОК!
 
Это совсем неэлегантно. А как же ярлыки в Start, деинсталляция через Control Panel и т.п. - все, к чему давно привыкли все пользователи, и что появляется после инсталляции. Кроме того, перенос ini-файла на другую машину чреват проблемами - например, разное разрешение мониторов при одинаковых координатах в ini. Чаще всего переносить нужно не *настройки*, а *данные*.
 
>4.Если на то пошло, можно уменьшить
>трудозатраты программиста
 
Не думаю, что это существенно. Все уже давным-давно написано, и не раз. Все, что нужно, есть в WinApi и почти не требует надстроек. Мы же говорим о конкретной платформе, а не об универсальных программах.
 
Dervish: Ну вот видимо поэтому я и решил всё-таки пересмотреть своё отношение и вернуться к хранию настроек в реестре.
Золотые слова! Artem Fedorov 29/11/2002 00:44 #написать ответ
> "Обычному" пользователю привычнее
> исправлять параметры в реестре,
> пользуясь GUI, чем редактировать текст.
 
Воистину! GUI написан для того, чтобы избавить пользователя от мороки -- настроейки программ самостоятельно через файлы. Кто настраивал Apache тот меня поймет )
 
Для справки: Там несколько файлов для настроек. Основной файл (который, в основном, и нужно больше всего править) весит в моем случае 40 кбайт
Поправочка... Artem Fedorov 29/11/2002 00:48 #написать ответ
По-моему автор (Vadim) имел в виду, что править *реестр* удобнее, чем ini-файлы, т.к. у реестра есть GUI. Не согласен. Править удобнее всего из GUI самой программы ), для этого GUI и существует. А лезть руками в настройки вообще никто не советует -- проблемы могут быть непредсказуемые.