Tags: расписание

аватара

(no subject)

-zoom включает сохранение aspect ratio для драйверов, которые это не поддерживают. Кстати надо в винде посмотреть как включить заполнение "пустого места" чёрным

std::set позволяет делать забавные сравнения. И вообще забавная штука.

написал забавных пару классов. Завтра надо закончить внутренности интерфейса.
аватара

(no subject)

Для начала, будем использовать MySQL, потому что он уже у меня установлен.

Нужные кнопочки: добавить в базу фильм, добавить в базу каталог (ессесно с фильмами, заставками и прочим), добавить заказчика. Нужна ли кнопка "добавить временной период"?

Так же нужны кнопки открыть базу, открыть расписание, новое расписание.


longblob
longtext
Столбец типа blob или text с максимальной длиной 4294967295 (2^32 - 1) символов. see section 6.5.3.1
А это значит, я могу хранить в базе до 4х гигов в одной ячейке. Не знаю, не помрёт ли она с такого счастья, но я попробую хранить фильмы в базе. Надо, кстати, будет очень аккуратно их оттуда выбирать. По сети это будет забавная котовасия.


Вообще, нет, надо начать с сервера БД, с настройки основ. Выбрать сервер с бд, порт бд, далее создать интерфейс создания базы (или это делать при установке приложения?)


В базе фильмы буду хранить как:
1)название фильма
2)длительность
3)добавивший
4)заказчик
5)идентификатор табло для проигрывания
6)желаемое время проигрывания начало
7)желаемое время проигрывания конец
8)дата начала показов
9)дата конца показов
Теперь надо подумать, что ещё мне может понадобиться от этих несчастных фильмов на данном этапе.


мувики для тестов
http://heasarc.gsfc.nasa.gov/Videos/
аватара

(no subject)

хорошо бы определить ещё, как будут добавляться фильмы.Некоторые вещи, которые я хочу указатЬ, лучше, наверно хранить в базе. Соответственно надо в базе хранить и постоянно проверять актуальность списка файлов, а так же создать модулю для добавления этих самых файлов в базу.

Итого, получается, что мне нужен гуй для просмотра и наполнения библиотеки и для выборки из библиотеки в новое расписание. ну и вообще, создавалка этих самых расписаний и заданий.

Задания и расписания в каком формате в базе хранить? Я бы сделал по таблице на расписание и на задание даже. По сути дела, задание и расписание не отличаются же.

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

(no subject)

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

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

Как распределить фильмы равномерно по времени, чтобы было как можно меньше повторений?
Как затем разбить полученное расписание на задания? По времени? По повторяющимся частям?
Если возможность идти обратным путём: составлять задания, а из них собирать расписание?

несколько идей:
1)простая: выбираем самый частый фильм, составляем столько заданий, остальные фильмы раскидываем по этим заданиям. Не учитывается время показа, зато фильмы идут с наибольшим промежутком.
2)Разбить фильмы по желаемому времени показа, для каждого времени создать своё задание, в нём пойти по простому принципу.
3)были несколько уточнений для простой схемы. НА самом деле, нельзя начинать с самого редкого фильма, набирая остальные в минимум блоков, потому что тогда, я не смогу отследить повторы фильмов.



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

(no subject)

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

Программа составления расписаний идёт отдельно. Она может оперировать понятиями фильм, заставка, анимированная заставка, задание, расписание.
Для каждого фильма необходимо указать заказчика, разрешённое время показа, необходимое количество показов за временной промежуток.

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

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




Касательно интерфейса. Он должен состоять из 4х частей: двух колонок с фильмами, информации о фильме и препросмотрщика. Слева - список файлов, справа - временная шкала с пропорциональным отображением.

завтра надо вспомнить про http://www.mplayerhq.hu/DOCS/tech/ и почитать про tree что-то там.
аватара

(no subject)

Безотносительно платформы и технологии реализации. ДЛя программы нужны будут:
1)Сервер:
1.1)класс для открытия и создания списка файлов.
1.2)класс для графической компоновки файлов, отображения миниатюрок
1.3)класс для текстового отображения что за чем будет играться, согласно 1.2).
1.4)для 1.2 класс для внесения фильмов и расписаний в разные базы данных:
1.4а)текстовые (в основном для теста)
1.4б)SQL
1.4в)Что я забыл?
1.5)Сообщения с клиентом:
1.5а)изменения
1.5б)прогресс скачивания отдельных файлов.
Меню для создания отдельных заданий, расписаний из заданий, другие? какие?
2)Клиент:
2.1)интерфейс к mplayer
2.2)Интерфейс к серверу 1.5
2.3)Интерфейс к базе.

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

(no subject)

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

(no subject)

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

На текущий момент плохо себе представляю 2 вещи: как сделать программку для написания расписаний. По крайней мере графическую её часть.

Думаю над способами построения клиент серверверного взаимодействия:
1)Где хранить фильмы?
2)Соединение, наверно, лучше делать не постоянным т.е. не онлайн трансляцию, а скачивание фильма и затем его показ.
3)Как бы ко всей этой прелести приплести линух? В нём бы решились вопросы с некоторыми вещами типа лицензий и стоимости разного ПО.

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

Начинать надо с последнего, хотя хочется начать с первого)))