WestByte Support Forum

Posted: **06 Apr 2008, 15:27 Sun**

Да, я всегда пользуюсь классическим стилем и в висте тоже...

Я доработал "скрин" вкладки OSD "Внешний вид".

http://up.li.ru/?id=347130;OSD_3.jpg

"Очистить" - сброс приоритетов (цифры от 1 до 6) отображения закачек по состоянию.

"Конец строки" - следующую часть данных отображать с новой строки.

"По умолчанию" - сброс настроек скрипта OSD на настройки по умолчанию (полностью или 1 подсвеченный тег - выбор при раскрытии кнопки);

"Сброс" - сброс настроек скрипта OSD на настройки имеющиеся при открытии окна настроек (полностью или 1 подсвеченный тег - выбор при раскрытии кнопки). Возврат к предыдущим настройкам;

Инфо закачек:

<Все_столбцы_таблицы_закачек>
Зеркала . . . . . . . . . . . . . . . . . Список зеркал (ну или хотябы их количество);
Имя после закачки . . . . . . . . . Имя файла после закачки;
Качалось ли ранее . . . . . . . . . Качался ли файл ранее;
Логин . . . . . . . . . . . . . . . . . . . Логин для подключения к серверу;
Процент закачки . . . . . . . . . . .Процент выполнения закачки;
Ошибки . . . . . . . . . . . . . . . . . .Количество ошибок в закачке;
Переподключения . . . . . . . . . .Количество повторных попыток подключения к серверу для продолжения закачки;
Потоки . . . . . . . . . . . . . . . . . . .Количество потоков;
Реферер . . . . . . . . . . . . . . . . . .Реферер закачки;
Состояние закачки . . . . . . . . . .Статус закачки;
Таймаут . . . . . . . . . . . . . . . . . . Оставшееся время до повторного запуска закачки;

Общее инфо:

Закачки (общее) . . . . . . . . . . . Кол-во активных / всего закачек;
Ррежим скорости . . . . . . . . . . . Режим скорости
Калькулятор . . . . . . . . . . . . . . Данные калькулятора;
Категория (количество) . . . . . . Количество закачек в такой-то категории;
Категория (принадлежность) . . .Закачка принадлежит такой-то категории;
Категория (состояние) . . . . . . . .В такой-то категории столько-то закачек с такими-то (всеми имеющимися) статусами;

Ниже цвета шрифта тега, я подумал можно добавить поле "Текст добавляемый в конце тега, но подумал "Нафиг он нужен?...", и не стал, но впринципе малость смысла в этом есть...

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~

На второй вкладке:

Положение;
Размер;
Прозрачность;
Горячие клавиши;
Текст выбранных скриптов (профиль № столько-то) с возможностью выбора номера профиля, чтоб не щёлкать туда-сюда по вкладкам, если можно.

Насчёт прозрачности:

Если текст и фон отображать в разных слоях, то можно добиться отдельной настройки прозрачности для фона и текста OSD. В таком случае будет ещё 2 ползунка для настройки прозрачности текста - аналогичные фону.

Posted: **06 Apr 2008, 17:07 Sun**

Korney San wrote: Я подумал, что можно добавить генератор токена и кнопочку "Вставить токен" с интерфейсом, похожим на тот, который ты нарисовал. Со следующими изменениями:
...
2. Вид показа загрузок = выпадающий список полей
...
4. "Расположение" = два поля из выпадающих списков: "Длина меньше ограничения" - Влево, Вправо, По центру, "Длина больше ограничения" - Обрезать, Бегущая строка.
...

Генератор - это само-сабой, кнопочка "Вставить токен", а точнее "Сгенерировать токен" - нафиг не нужна, т.к его можно генерировать при нажатии "ОК", а для "Реального режима" - при нажатой кнопке "Тест" при отпускании кнопки мыши - это лучший вариант, а то интерфейс итак не "слабенький".

По поводу 2-го пункта: это что? - вместо обычного списка с выключателями и возможностью перетаскивания - обыйный набор выпадающих списков? - надеюсь это только для альфа версий...

По поводу 4-го пункта: это тоже самое, что я и предложил, но оформленное по другому, но есть "но" - интерфейс мне кажется немного сложнее для восприятия т.к в нём появляется "не линейность" ... с др. стороны она даёт в ограниченное пространство "впихнуть" множество представлений OSD, мой вариант такого не давал - это плюс.

Со временем к "Длина меньше / равна ограничению" можно добавить - "Растянуть пробелы", "Растянуть всё" и "Вспышка", а к "Длина больше ограничения" - Бегущая строка "Маятник".

"Растянуть пробелы" - растянуть за счёт межсловестных интервалов;
"Растянуть всё" - растянуть за счёт межсимвольных интервалов;
"Вспышка" - поочерёдное отображение разных тегов. Применять форматирование к отображению тега в данном виде - глупо (имхо), пожтому предлогаюпри выборе данного вида - сбрасывать "Вписать в" в значение НОЛЬ, т.е отображать как есть;
"Маятник" - бегущая строка, которая начинает двигаться в противоположную сторону при достижении конца или начала, с задержкой в количество тактов обновления;

Ещё я тут подумал, что теги с одинаковым типом отображения - "Маятник" и "Бегущяя строка", расположенные подряд, нужно прокручивать как единое целое, а не каждый сам по себе. Это зрительно расширяет границы отображения и улучшает наглядность.

Очередная доработка внешнего вида настроек OSD:
http://up.li.ru/?id=347191;OSD_5.jpg
(нумеровка верная я случайно 2 раза номер 3 приписал).

"Текст-метка" - текст, добавляемый в начало и в конце тега (актуально для "бегущей строки" и "вспышки"), разделитель текста, добавляемого в начало и в конец - "?", наврятли "?" попадётся в тегах вообще или в этом тексте-метке;
"Время, такт" - обновление отображения тега 1 раз в N тактов обновления OSD (регулировка скорости бегущей строки, вспышки и маятника);

Posted: **07 Apr 2008, 17:00 Mon**

x2088 wrote: Генератор - это само-сабой, кнопочка "Вставить токен", а точнее "Сгенерировать токен" - нафиг не нужна, т.к его можно генерировать при нажатии "ОК", а для "Реального режима" - при нажатой кнопке "Тест" при отпускании кнопки мыши - это лучший вариант, а то интерфейс итак не "слабенький".

...а для реализации кнопочки "Тест" придётся запихивать весь набор возможных данных в графическую часть и обновлять его. То же самое для реализации бегущей строки в любом виде.
Сейчас же текст для вывода генерирует по скрипту обрабатывающая часть плагина и подсовывает его графической, которая знает, как вывести строку текста...

x2088 wrote: По поводу 2-го пункта: это что? - вместо обычного списка с выключателями и возможностью перетаскивания - обыйный набор выпадающих списков? - надеюсь это только для альфа версий...

Ух, любители гуёв...

Попробовал бы ты в Turbo Vision порисовать свой интерфейс...

x2088 wrote: По поводу 4-го пункта: это тоже самое, что я и предложил, но оформленное по другому, но есть "но" - интерфейс мне кажется немного сложнее для восприятия т.к в нём появляется "не линейность" ... с др. стороны она даёт в ограниченное пространство "впихнуть" множество представлений OSD, мой вариант такого не давал - это плюс.

x2088 wrote: "Растянуть пробелы" - растянуть за счёт межсловестных интервалов;

Это сделать легко... но зачем?

x2088 wrote: "Растянуть всё" - растянуть за счёт межсимвольных интервалов;

А вот это не стоит - представь себе объём расчётов при разных шрифтах для десятка полей, которые надо впихнуть в заданный прямоугольник.

x2088 wrote: "Вспышка" - поочерёдное отображение разных тегов. Применять форматирование к отображению тега в данном виде - глупо (имхо), пожтому предлогаюпри выборе данного вида - сбрасывать "Вписать в" в значение НОЛЬ, т.е отображать как есть;

Идея интересная, но, по-моему, непрактичная.

x2088 wrote: "Маятник" - бегущая строка, которая начинает двигаться в противоположную сторону при достижении конца или начала, с задержкой в количество тактов обновления;

Те, кто видел ВинАмп любой версии, особенно пятой, особенно официальный русский, видели, что там есть "Стандартная прокрутка", она же "Бегущая строка", и "Современная прокрутка", она же "Маятник". Так что извини, ничего нового ты не сказал.

x2088 wrote: Ещё я тут подумал, что теги с одинаковым типом отображения - "Маятник" и "Бегущяя строка", расположенные подряд, нужно прокручивать как единое целое, а не каждый сам по себе. Это зрительно расширяет границы отображения и улучшает наглядность.

Сначала нужно научиться что-то отображать...

x2088 wrote: "Текст-метка" - текст, добавляемый в начало и в конце тега (актуально для "бегущей строки" и "вспышки"), разделитель текста, добавляемого в начало и в конец - "?", наврятли "?" попадётся в тегах вообще или в этом тексте-метке;

Стандартный *** тебя, значит, не устраивает?

x2088 wrote: "Время, такт" - обновление отображения тега 1 раз в N тактов обновления OSD (регулировка скорости бегущей строки, вспышки и маятника);

Мда... В общем, графическая часть будет дофига тяжёлой... помнить текст, которым мигать, сколько раз он мигнул, в течение которого времени ему гореть, сколько ещё такого текста рядом, какой шрифт, цвет, размер...

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

P.S. Хочешь быстрее - помогай писать...

P.P.S. С таким потоком требований я скоро начну выводить всё это прямо на АВК DM...

P.P.P.S. В поисках "как сделать" утонул в книжках...

Posted: **07 Apr 2008, 17:56 Mon**

Korney San wrote:Это сделать легко... но зачем?

Просто подумал, что если есть "По левому краю, "По центру", "По правому краю", то и это должно быть...

Korney San wrote:Идея интересная, но, по-моему, непрактичная.

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

Korney San wrote:Те, кто видел ВинАмп любой версии, особенно пятой, особенно официальный русский, видели, что там есть "Стандартная прокрутка", она же "Бегущая строка", и "Современная прокрутка", она же "Маятник". Так что извини, ничего нового ты не сказал.

Я не пыталя придумать что-то новое, я собрал в одном посте всё что вспомнил - все типы бегущих строк, какие вспомнил, ну кроме телетекста - он сюда не катит.

Korney San wrote:Стандартный *** тебя, значит, не устраивает?

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

Korney San wrote:Хочешь быстрее - помогай писать...

К сожелению - не умею...

Posted: **08 Apr 2008, 9:06 Tue**

Korney San wrote:...а для реализации кнопочки "Тест" придётся запихивать весь набор возможных данных в графическую часть и обновлять его. То же самое для реализации бегущей строки в любом виде.
Сейчас же текст для вывода генерирует по скрипту обрабатывающая часть плагина и подсовывает его графической, которая знает, как вывести строку текста...

Я писал:

Плагин "OSD" можно разделить на 3 части, а именно:
* управляющая (настройки плагина);
* сборо-передающая (собирает данные из DMAPI и передаёт их в приёмо-выводящую часть);
* приёмо-выводящая (принимает данные из сборо-передающей части и выводит её в информационное окно своего собственного GUI).

Др. плагинам управляющая и приёмо-выводящая части нафиг не нужны, а если вдруг будет плагин которому могут понадобиться эти данные, то он может запрашивать эти данные у сборо-передающей части ч.з т.н Plugin API. Думаю 1-ю и 3-ю чамти можно объединить в один файл.

Эээ, а по какой схеме пишется плагин? Сейчас я подумал, что надо по такой:

Code: Select all

                                                             +-------------------+
                                                             |       DMAPI       |
                                                             +-------------------+
                                                                       |
+------------------------+  +-----------------------+  +---------------|---------------+
| Файл 1                 |  | Файл 2                |  | Файл 3        V               |
| +-------------------+  |  |                       |  |  +-------------------------+  |
| | Управляющая часть |---->| Конфигурационный файл |<--->| Сборо-передающая часть  |  |
| +-------------------+  |  +-----------------------+  |  +-------------------------+  |
|                        |      ^       ^       ^      |               V               |
| +-------------------+  |      |       |       |      |  +-------------------------+  |
| |                   |<--------+       V       +-------->|   Форматирующая часть   |  |
| |  Выводящая часть  |  |         +----------+        |  |          DMOSD          |  |
| |                   |<-----------| Файл 4   |<----------|                         |  |
| +-------------------+  |         |          |        |  +-------------------------+  |
|  Имеется графический   |         | mToolTip |        |    Не имеется графического    |
|       интерфейс        |         +----------+        |          интерфейса           |
+------------------------+                             +-------------------------------+

Управляющая часть создаёт конфигурационный файл, по которому сборо-ппередающая часть "смотрит" что нужно грести из DMAPI, после чего эти данные передаются форматирующей части DMOSD (эта часть создаёт только бегущие строки, добавляет текст-метки и объединяет несколько тегов в один), которая "смотрит" что с ними сделать (способ форматирования), затем отформатированные данные передаются в mToolTip, в котором заполняются в соответствующие теги, взятые им из конфигурационного файла, в конечном итоге всё это дело передаётся выводящей части (она применяет к ним конечное форматирование - шрифт, размер цвет и т.д), которая так же берёт из конфигурационного файла свои размеры положение, коэф. прозрачности и состояние флогов.

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

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

Если проверять в конфигурационном файле допустимые диапазоны значений, а не соответствие жёсткому списку, то появится возможность редактирования параметров в наглую прямо руками, что позволит выставить те параметры, которые не доступны из GUI.

Как видно из схемы все данные хранятся в конфигурационном файле, что просто замечательно для "продвинутого" пользователя.

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~

Ещё хотелось бы к тегам параметров закачек добавить тег "ID закачки".

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~

Можно было бы вести лог закачки. некоторые хотят видеть историю закачки - как она шла, ведь это лучше чем ничего.

Выводить лог закачки.

Формат вывода лога закачки:

<Заголовок>
<Отделяющая_черта_(знаками_равенства)>
<Пустая_строка>
<Момент_времени>
<Пустая_строка>
<Список_закачек_и_их_параметры>
<Пустая_строка>
<Отделяющая_черта_(знаками_равенства)>
...
<Пустая_строка>
<Момент_времени>
<Пустая_строка>
<Список_закачек_и_их_параметры>
<Пустая_строка>
<Отделяющая_черта_(знаками_равенства)>
<Пустая_строка>
<Сообщение_о_завершении_всех_закачках_или_закрытии_программы,_или_код_ошибки>

Пример формата заголовка:

<ID файла> ||| <Имя файла> ||| <Состояние> ||| <Размер> ||| <Закачано> ||| <Осталось> <Конец_строки>
<Скорость> ||| <Время закачки> ||| <Добавлена URL> ||| <Папка> ||| <Коментарий> ||| <Зеркала> <Конец_строки>
<Имя после закачки> ||| <Качалось ли ранее> ||| <Логин> ||| <Ошибки> ||| <Переподключения> <Конец_строки>
<Потоки> ||| <Реферер> ||| <Таймаут> <Конец_строки>

Формат списка закачек и их параметров (<Список_закачек_и_их_параметры>):

<Теги_закачки_ID1_в_соответствии_с_форматом_заголовка>
<Отделяющая_черта_(знаками_дефиса)>
...
<Теги_закачки_IDn_в_соответствии_с_форматом_заголовка>

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~

Очередная доработка "скрина" GUI DMOSD:
http://up.li.ru/?id=347493;OSD_6.jpg

"Отображать заголовок при наличии закачек" - если есть закачки, то отображать формат вывода данных о них;
"Отключить OSD при пустом списке закачек" - отключение плагина при пустом списке закачек (OSDShow=0, только при событии "Все закачки завершены" + проверка списка закачек на их наличие, проверка при включении не производится, чтобы избежать невозможности принудительного ручного включения);

Posted: **08 Apr 2008, 10:17 Tue**

Кто качал вторую альфу - это только у меня через некоторое время блок закачек пропадает или у всех?

Posted: **08 Apr 2008, 12:23 Tue**

x2088 wrote:Эээ, а по какой схеме пишется плагин? Сейчас я подумал, что надо по такой:

Эх, давненько я псевдографикой не маялся...

Сейчас схема плагина построена по принципу standalone и выглядит так:

Code: Select all

+-------+ +----------------+
|DM API | | Другие функции |
+-------+ +----------------+
    |              |
+---|--------------|-------+
|   | Ядро плагина |       |
|   V              V       |
| +----------------------+ |
| |  Собирающая часть    | |
| +----------------------+ |
|            |             |
|            V             |
| +--------------------+   |   +----------------+
| | Управляющая часть  |<----->| Форма настроек |
| |                    |   |   +----------------+
| |                    |   |   +----------------+
| |                    |<----->| Файлы настроек |
| |                    |   |   +----------------+
| |                    |   |   
| |                    |   |   +----------------+
| |                    |------>|                |
| +--------------------+   |   |                |
|            |             |   |                |
|            V             |   |   Окно OSD     |
| +--------------------+   |   |                |
| | Парсер по принципу |   |   |                |  
| | mToolTip           |------>|                |
| +--------------------+   |   +----------------+
+--------------------------+

x2088 wrote: Управляющая часть создаёт конфигурационный файл, по которому сборо-ппередающая часть "смотрит" что нужно грести из DMAPI, после чего эти данные передаются форматирующей части DMOSD (эта часть создаёт только бегущие строки, добавляет текст-метки и объединяет несколько тегов в один), которая "смотрит" что с ними сделать (способ форматирования), затем отформатированные данные передаются в mToolTip, в котором заполняются в соответствующие теги, взятые им из конфигурационного файла, в конечном итоге всё это дело передаётся выводящей части (она применяет к ним конечное форматирование - шрифт, размер цвет и т.д), которая так же берёт из конфигурационного файла свои размеры положение, коэф. прозрачности и состояние флогов.

Управляющая часть через форму настроек создаёт файлы настроек, которые определяют вид выводимой информации.
Собирающая часть гребёт ВСЕ данные, какие может найти (точнее, которые в ней прописаны), и передаёт управляющей.
Управляющая часть:
а) согласно файлам настроек настраивает графические параметры окна OSD один раз
б) передаёт собранные данные и настройки их представления в парсер каждый такт обновления (сейчас это 5 сек встроенного события DM)
Парсер формирует из настроек и данных выводимую отформатированную строку текста и передаёт её окну OSD, которое обновляет выводимый текст.

В дальнейшем при переходе на принцип client-server серверу [д]останется собирающая часть и треть управляющей части, ответственная за файлы настроек. Всё оставшееся (форма настроек, парсер и окно OSD) будет в клиенте.

Преимущества текущей реализации перед изображённой тобой:
1. Настройки читаются один раз - управляющей частью (у тебя - три: сборо-передающе-форматируещей, управляющей и выводящей)
2. Напрямую вытекает из первого: данные и настройки хранятся в одном месте, в то время как у тебя нужно дублировать хранение и обработку везде.

Небольшой экскурс в программирование.
Самый простой способ реализации бегущей строки в текстовом варианте выглядит так:
Имеется строка длины m (нет, m мало, возьмём n (c) Преподаватель) и поле вывода k <m.
Для вывода бегущей строки организуется цикл по переменной, допустим, i (теоретически бесконечный), в котором в каждой итерации
выполняются следующие операции:
1. Из строки копируется часть длиной k, начиная с символа i.
2. Скопированная часть выводится куда надо.
3. i увеличивается на 1. Когда i становится больше m, i приравнивается к 1.
Как видим, для вывода только ОДНОЙ бегущей строки нужно знать и ХРАНИТЬ уже ТРИ параметра - строку, длину "окна" и текущую позицию "окна" в строке.
Маятник реализуется аналогично, только в шаге 3 меняется способ изменения i - от 1 до m-k+1 и обратно. Что не избавляет от необходимости хранить параметры.
Предлагаемая тобой "вспышка" потребует хранения ВСЕХ строк для конкретного "окна".
...и всё это барахло придётся запихивать в графическую часть.

x2088 wrote: Если проверять в конфигурационном файле допустимые диапазоны значений, а не соответствие жёсткому списку, то появится возможность редактирования параметров в наглую прямо руками, что позволит выставить те параметры, которые не доступны из GUI.

Что ты имеешь в виду под словами "допустимые диапазоны"? Жесткий список - это и есть допустимый диапазон значений, потому что остальные значения попросту не имеют реализации или существования. Расшифруй, пожалуйста, свою мысль.
Например, приведённый мной список токенов представляет собой все данные, которые умеет "добывать" собирающая часть на текущий момент. Если ты задашь другой токен (или ошибёшься регистром), ты получишь на выходе пустую строку, потому что собирающая часть не будет знать, о чём ты её спросил.

x2088 wrote: Как видно из схемы все данные хранятся в конфигурационном файле, что просто замечательно для "продвинутого" пользователя.

90% времени работы над программой уходит на написание интерфейса между программой и пользователем, особенно на то, чтобы пользователь не мог сделать чего-то недоступного программе.
Вот, например, работа с конфигурационным файлом.
Его мало считать - нужно придумать вид формы настроек, как передавать данные в эту форму и как их оттуда забирать.
Раньше мне (по-моему, и всем программирующим) приходилось писать много-много похожих процедурок, отвечащих за каждую настройку. Сделав УСН, я передаю форме массив настроек, а в форме меняю две процедуры - открытие и закрытие для синхронизации контролов с данными. Это сняло головную боль при необходимости добавить/убрать пару настроек.
Это так, выпускание пара...

x2088 wrote: Ещё хотелось бы к тегам параметров закачек добавить тег "ID закачки".

Не вопрос - это придумать n буков для обозначения, а для добывания вообще ничего (дополнительного, имеется в виду) делать не надо...

x2088 wrote: Можно было бы вести лог закачки. некоторые хотят видеть историю закачки - как она шла, ведь это лучше чем ничего.

Это к разработчикам DM. У них есть лог закачки, который можно сохранить в файл с помощью мыши, пусть добавят в DM API возможность сделать это из плагина.
Хотя бы потому, что поля <Качалось ли ранее>, <Логин>, <Ошибки>, <Переподключения>, <Потоки> и <Таймаут> из плагина сейчас не достанешь - об этом знает только ядро DM.
Всё остальное в принципе вполне реализуемо. Но это уже тянет на отдельный плагин, потому что OSD тут никаким боком. Бросай новый клич в "Заявки"...

Может, кто и подпишется...

Posted: **08 Apr 2008, 17:41 Tue**

Korney San wrote:Преимущества текущей реализации перед изображённой тобой:
1. Настройки читаются один раз - управляющей частью (у тебя - три: сборо-передающе-форматируещей, управляющей и выводящей)
2. Напрямую вытекает из первого: данные и настройки хранятся в одном месте, в то время как у тебя нужно дублировать хранение и обработку везде.

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

1) Управляющая часть генерирует конфигурационный файл, по которому происходит управление всеми частями плагина;
2) Сборо-передающая часть считывает ТОЛЬКО инфу о сборе конкретных необходимых данных (над которыми будут издеваться остальные части);
3) Форматирующая часть считывает ТОЛЬКО инфу о способе первичной обработке данных (что с чем объединить, что дописать и в каком теге вывернуть данные на изнанк - бегущая строка);
4) mToolTip ТОЛЬКО заполняет свои теги принятыми данными из форматирующей части, формат тегов, естественно берётся из конфигурационного файла;
5)Выводящая часть ТОЛЬКО создаёт "радугу" по настройкам, взятым из того же конфигурационного файла, ну и также свои основные параметры - размер, положение, цвет фона и прозрачность...

Никто, думаю, не мешает запрашивать эти данные 1 раз и то по команде "конфигурация была изменена", к томуже можно хранить всё в 3-x различных файлах конфигураций, чтобы избежать поиска и выборки только нужной части настроек, в этом случае искать ничего не надо будет вообще, просто считывать весь свой файл "от" и "до". На сколько я знаю поиск инфо в текстовом файле - операция очень медленная.

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

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

Korney San wrote:Предлагаемая тобой "вспышка" потребует хранения ВСЕХ строк для конкретного "окна".
...и всё это барахло придётся запихивать в графическую часть.

А разве для этого не надо просто зациклить счётчик тактов обновления и по достижению им нуля скажем - менять один или несколько тегов на др. тег или несколько тегов?

Korney San wrote:Что ты имеешь в виду под словами "допустимые диапазоны"?

Ну например диапазон цветов в имеющейся радуге... почему нельзя поставить цвет, к примеру #000001 (HTML-формат записи, а в плагине просто "1").

Это к разработчикам DM.Не вопрос - это придумать n буков...[/quote] Так у DM`а есть такой тег в xml-списке закачек кажется, если не ошибаюсь...

Korney San wrote:Это к разработчикам DM.

Плагин собирает многие данные о закачках, так почему их нельзя сохранять логом раз в 10 сек скажем?

Posted: **09 Apr 2008, 11:09 Wed**

x2088 wrote: Спорить не буду, но распишу какой была задумка.

А я, соответственно, прокомментирую примерный ход работы задумки в системе.

x2088 wrote: 1) Управляющая часть генерирует конфигурационный файл, по которому происходит управление всеми частями плагина;

Чтение/запись:
1. Файл настроек плагина (данные для сбора, настройки форматирования, настройки графики)
2. Файл настроек парсера (внешний вид в тегах парсера)

x2088 wrote: 2) Сборо-передающая часть считывает ТОЛЬКО инфу о сборе конкретных необходимых данных (над которыми будут издеваться остальные части);

Чтение:
1. Файл настроек плагина (данные для сбора)
2. Память (получение данных из DM и проч.)
Запись:
1. Файл данных (полученные данные)

x2088 wrote: 3) Форматирующая часть считывает ТОЛЬКО инфу о способе первичной обработке данных (что с чем объединить, что дописать и в каком теге вывернуть данные на изнанк - бегущая строка);

Чтение:
1. Файл настроек плагина (настройки форматирования)
2. Файл данных (полученные данные)
Запись:
1. Файл форматированных данных (данные для парсера)

x2088 wrote: 4) mToolTip ТОЛЬКО заполняет свои теги принятыми данными из форматирующей части, формат тегов, естественно берётся из конфигурационного файла;

Чтение:
1. Файл настроек парсера (внешний вид в тегах парсера)
2. Файл форматированных данных (данные для парсера)
Запись:
1. Файл выводимого текста

x2088 wrote: 5)Выводящая часть ТОЛЬКО создаёт "радугу" по настройкам, взятым из того же конфигурационного файла, ну и также свои основные параметры - размер, положение, цвет фона и прозрачность...

Чтение:
1. Файл настроек плагина (настройки графики)
2. Файл выводимого текста
Запись:
1. Память (вывод OSD)

Резюмируя вышеупомянутое, получается, что задействовано 5 файлов:
настроек плагина (сейчас это OSD.ini), настроек парсера (сейчас это OSD.osd), данных, форматированных данных и выводимого текста.
Теперь посчитаем обращения к файлам (в порядке упоминания):
1) 1ЧЗ1, 2Ч1, 3Ч1, 5Ч1 - редко более одного раза
2) 1ЧЗ2, 4Ч1 - редко более одного раза
3) 2З1, 3Ч2 - каждый такт
4) 3З1, 4Ч2 - каждый такт
5) 4З1, 5Ч2 - каждый такт
Файлы 3-5 можно не записывать на диск только при том условии, что форматирование, парсер и вывод находятся в одном модуле. Иначе представь, какая будет нагрузка на винчестер при уменьшении времени такта...

x2088 wrote: И в моей схеме каждый из блоков "живёт своей жизнью", его можно использовать в др. наборе файлов для др. целей, исключение - графическая часть.

Как видишь, не совсем.

x2088 wrote:
Korney San wrote:Предлагаемая тобой "вспышка" потребует хранения ВСЕХ строк для конкретного "окна".
...и всё это барахло придётся запихивать в графическую часть.
А разве для этого не надо просто зациклить счётчик тактов обновления и по достижению им нуля скажем - менять один или несколько тегов на др. тег или несколько тегов?

...и хранить где-то список этих самых тегов и порядок их следования...

x2088 wrote:
Korney San wrote:Что ты имеешь в виду под словами "допустимые диапазоны"?
Ну например диапазон цветов в имеющейся радуге... почему нельзя поставить цвет, к примеру #000001 (HTML-формат записи, а в плагине просто "1").

Можно поставить цвет от RGB(0, 0, 0) до RGB(255, 255, 255) - т.е. от #000000 до #FFFFFF. Единственное, что через форму настроек весь диапазон цвета пока недоступен (включено ограничение в списке выбора), но руками в файле настроек поставить значение можно - оно будет воспринято как правильное. Однако при открытии формы цвет сбросится на чёрный.

x2088 wrote:
Не вопрос - это придумать n буков...
Так у DM`а есть такой тег в xml-списке закачек кажется, если не ошибаюсь...

Информация о конкретной закачке получается ЧЕРЕЗ ИНТЕРФЕЙС DM ПО ID этой закачки, т.е. ID плагин получает перед тем, как получить весь остальной xml относительно этого ID... И этот ID выглядит просто как абстрактный номер закачки в общем списке.
А до распознавания xml-списка (и вообще xml) у меня руки ещё не дошли... хотя приоритет и ID прокси можно достать только оттуда...

x2088 wrote:
Korney San wrote:Это к разработчикам DM.
Плагин собирает многие данные о закачках, так почему их нельзя сохранять логом раз в 10 сек скажем?

...вот так и получаются комбайны типа ACDSee...
Единственный аргумент в твою пользу - плагин действительно БУДЕТ собирать многие (насколько ему даёт DM - вообще ВСЕ) данные о закачках (и не только), и легче для DM будет включить в плагин лог-часть (кстати, если переходить на русский, то лог - это журнал), чем нагружать DM параллельным плагином.
Но для этой части встают другие вопросы. Например, нафига в каждой строке писать реферера, зеркала, и др. постоянную информацию? Ведь от времени меняется только объём скачанного, собственно прогнозируемое время и скорость...

Posted: **10 Apr 2008, 10:53 Thu**

Я не программер и поэтому смог додуматься только до такого (моя схема) и поэтому у меня появился вопрос: "А эти данные можно записывать прямиком в ОЗУ? - зачем их записывать на винт и считывать от туда"?..

...а если сделать настраиваемые пути сохранения файлов и поставить виртуальный винт, настроив его на не сохранение данных на нём на физический винт, то физический винт не пострадает...

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

Korney San wrote:...и хранить где-то список этих самых тегов и порядок их следования...

Поэтому я предлогал хратить всё в конфигурационном файле...

Korney San wrote:Однако при открытии формы цвет сбросится на чёрный.

Отож...

Korney San wrote:Но для этой части встают другие вопросы. Например, нафига в каждой строке писать реферера, зеркала, и др. постоянную информацию? Ведь от времени меняется только объём скачанного, собственно прогнозируемое время и скорость...

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

Posted: **10 Apr 2008, 14:08 Thu**

x2088 wrote:Я не программер и поэтому смог додуматься только до такого (моя схема) и поэтому у меня появился вопрос: "А эти данные можно записывать прямиком в ОЗУ? - зачем их записывать на винт и считывать от туда"?..

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

x2088 wrote:
Korney San wrote:...и хранить где-то список этих самых тегов и порядок их следования...
Поэтому я предлогал хратить всё в конфигурационном файле...

...ушёл в раздумья по поводу реализации...

x2088 wrote:
Korney San wrote:Однако при открытии формы цвет сбросится на чёрный.
Отож...

Однако же поставить - можно, главное - форму настроек не открывать...

Уговорил, в следующей альфе выключу ограничение на "стандартные" цвета в форме настроек.

x2088 wrote:Так никто и не требует писать одно и тоже сто тысячь миллионов раз, а только то, что меняется... то что не меняется записывать 1 раз.

Разберусь с основными проблемами - займусь журналом. Наверное.

P.S. Кстати, с xml закачек я разобрался и накидал доставатель инфы из него...

P.P.S. Периодически у меня появляется ощущение, что я собираю трёхосный пятиколёсный велосипед на турбинной тяге с воздушной подушкой и обратной стреловидностью крыла...

Posted: **12 Apr 2008, 7:47 Sat**

Я нашёл вот это http://users.compaqnet.be/cn021945/RAMD ... skfree.htm идея самая бредовая использовать это, но на всякий случай сообщаю о ней.

Ещё:
http://www.speedguide.net/files/ramdisk ... k_inst.zip ( http://www.speedguide.net/read_articles.php?id=131 )
http://www.box.net/shared/htpmm1zm8e ( http://www.mydigitallife.info/2007/05/2 ... 03-server/ )

Posted: **12 Apr 2008, 12:39 Sat**

Спасибо за ссылки, но не до них, не до них...
Работа пока продвинулась так:
[*] В .ini настройки разделены по группам.
[!] Токены выключения изменены и сделаны блоком.
[+] Чтение xml-списка закачек.
[+] Токен приоритета (DM_DL_PRTDSC) заработал.
[!] Прикручен механизм добывания только использующихся данных.

Posted: **27 Apr 2008, 23:35 Sun**

x2088 wrote:И исчо такая: окно настроек, по щелчку на иконке в трэе открывается на заднем фоне - как не активное. Хотелось бы пункт в настройках: "Открывать на переднем плане".

Korney San wrote:Пункта не будет, будет однократный вывод окна на передний план при открытии.

Хотелось бы к следующей альфе... А чего в ней ещё будет?

Собранный "в кучу" "скрин" OSD (никаких доработок не было): http://up.li.ru/?id=352273;OSD_7%2B.jpg

Posted: **28 Apr 2008, 10:59 Mon**

x2088 wrote:
x2088 wrote:И исчо такая: окно настроек, по щелчку на иконке в трэе открывается на заднем фоне - как не активное. Хотелось бы пункт в настройках: "Открывать на переднем плане".

Korney San wrote:Пункта не будет, будет однократный вывод окна на передний план при открытии.

Окно настроек плагина повторяет поведение окна DM - если DM развёрнут, настройки на переднем фоне, свёрнут - на заднем.

x2088 wrote: Хотелось бы к следующей альфе... А чего в ней ещё будет?

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