Написание софта
 

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

1. максимально простая с минимальным количеством кнопок, с возможностью настройки необходимых опций.
2. возможность изменения внешнего вида
3. возможно, полная интеграция в windows
4. Запуск всех приложений (Word, Navigation, и т.д.) внутри данной оболочки
5. Свой интернет браузер встроенный в оболочку
6. hotkeys на все! (чтоб была возможность приклеивать к штатной бортовой системе)NEW

-Запуск всех приложений (Word, Navigation, и т.д.) внутри данной оболочки - принято к размышлению
-Очень хорошая защита от взлома программы (против пиратства) - после компиляции
-Свой интернет браузер встроенный в оболочку с кнопками управления удобными на 7" мониторе - я думаю что это относится ко всей системе в плане удобства.... свой браузер вынесем на отдельное рассмотрение, если есть возможно корячить IE- тогда не вопрос, если нет - тогда проблематично, главное движек браузера,

5 Браузер - http://www.mp3car.com/vbulletin/showthread.php?t=56384

пожелание одно - пишите под *nix систему :)

пожелание 2

в программе inCar Terminal грамотно сделаны скины
хотельсь бы программу настраеваему точно так же - указываеш кнопочку картинки к кнопочке и событие по нажатию

ОЧень хотелось бы следующие функции, на основе информации OBDII в виде единого экрана:
1. Температура за бортом ("Температура поступащего воздуха")
2. Температура мотора ("Температура охлаждающей жидкости")
3. Темеература салона (не знаю, возможно ли это)
4. Скорость и обороты (в виде нарисованных приборов)
5. Мгновенный расход
6. Вывод кодов ошибок с их декодированием
7. Очистка кодов ошибок

Теперь просто о функциях:
1. Синхронизация по Wi-Fi содержания аудио, видео, имадже-папок. То есть подъехал к дому или работе, либо открыл ноутбук, carpc написал обнаружены изменнеия, и они загрузились в carpc.
2. Управление автозапуском двигателя. То есть подключить, например, LPT к кнопке пульта сигнализации, находящейся машине, и по таймеру заводить.


Кроме того, вношу предложение. Мне кажется, лучше идти от дизайна. Может сначала скриншоты нарисовать, согласовать их и тогда уже делать?

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

>все что хотим наблюдать в новой системе:

Ориентируясь на фроду (имхо все таки лучшая), и раскатав губу..

1. "Скинабельность", разумеется. Точнее, простота как смены скинов, так и их (создания)редактирования. Чтобы не приходилось ради добавления одной кнопки лопатить несколько ini фалов.

2. gps, dvd, смотрелка картинок, etc. - разложены отдельно по своим папкам. Туда же - возможность прикручивания внешних приложений таким же образом. Создаем папку, кладем туда софтинку, и в ini пишем что нужно.

3. О настройках: в settings (условно) галочками отмечаешь только те устройства что у тя есть, gps там какой нить.. и потом в меню неиспользуемые фичи просто не отображаются. (пламенный привет sat radio).

4. Настраиваемось всего что можно :)

5. Хочу голосовое управление :)))
продолжение следует ..

6. включение зажигания - запрос пароля - ввод - запуск оболочки с кнопкой
"start/stop engine".

7. в порядке бреда :) - а что если ее (оболочку) на флеше сваять?
это конечно, мягко говоря, не слишком скинабельно, но зато красоту какую можно сделать, а? :)

зы: эк меня поперло ;)

А можно будет управлять размещением элементов на экране? Например, хочу кнопку воспроизведения в верхнем углу, а остановки - в правом? :)

с точки зрения программиста:

Главное - это мощная и гибкая система поддержки плагинов (как в winamp`e) если этого добиться , то программа со временем обрастет всеми выше перечисленными функциями и ещё пепельницы вытрихать будет ... :)

P.S.
На мой взгляд это основная задача , иначе проект обречен на провал ...

на счет плагинов - согласен на все 100%.. но чтобы реализовать оное надо придумать какой то API для общения между оной программой и самим плагинами... создание _универсального_ API для общения между плагинами и ПО будет далеко не простой задачей..

по функционалу:
1) эмулятор денди/сега/etc ;)

Как програмисит, делавший попытку в эту сторону, замечу, что плагинная система это удобно, но с точки зрения юзера.
Цельная программа всегда весит меньше и ест меньше ресурсов, не имеет лишнего гемора с межплагинной связь. плагинный Апи будет очень навороченный, если у меня к примеру есть ф-ция зависимости освещенности экрана от света в салоне, То основная программа, должна иметь эту ф-цию (и все плагины для совместимости даже,если она ему не нужна! ), а сколько таких будет "не стандартных" ? Здесь получится избыток лишних ф-ций. если я при цело-EXEшном варианте просто передаю значение через переменную. Объяснить сложновато, кто попробует, тот сразу увидит это дремучий лес. :)
Я считаю это не маловажной причиной для отказа от плагинов.
Хотя, у самого руки чешутся до плагинов :)

Привет All :)

Вот решился влиться в ваши ряды.
Выскажу свое мнение по этому вопросу. Ну а в скорости и свою работу(автомобильный шел под Windows XP).

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

Результаты из собственного опыта
Все системы, поддерживающие плагины можно разделить на те что поддерживают красивый интерфейс и те которые расширяют функциональность приложения.
Т.е всегда нужно найти компромисс между красотой и функциональностью.
Я всегда выбираю функциональность + использование возможностей заложенных в OC

Есть еще одно предложение. Я по долгу службы изучаю архитекутру систем NGOSS (Next Generation Operational Support System) для операторов связи. Задачи сходны - создание единой системы, позволяющей комплексное управление услугами связи, реализованными на базе разного оборудования различных производителей.

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


Как переложить это на карпутеры?
1. Предположим создаем шину, общающуюся с внешними устройствами, для которых опредяляем единый формат данных.
Например - блок данных GPS, блок данных громкости и эквалайзера, блок данных управления радио, блок данных чего-нибудь еще.
2. Пишем приложения, какие угодно. Надо чтобы просмотрщик картинок запрашивал данные о скорости движения? Из приложения вызываем функцию GetData(arrGPS, vbGPS). Надо из телевизора звучащую в данный момент времени мелодию? GetData(arrMedia, vbMedia). Надо установить новую громкость для всех приложений? SetData(arrVolume, vbVolume).
3. Откуда возьмутся данные о GPS? их получит шина по NMEA. Но! Получит один раз, не надо никаких виртуальных портов, еще чего-то. Получила, и отдала любому приложению.
4. Очень удобно делать скины и расположение элементов. Например, определяем метку: LabelSpeed=120,100,140,110,GPS.Speed,Font,FontSize ,Color. А приложение уже само вытащит нужное данное.

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

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

Хотите писать приложение на С? А я на VB? Да ради бога. Не важно какие инструментальные средства, главное у всех унифицированные блоки данных.

Главное - системно проработать блоки данных и архитекутру шины.

Может попробуем начать? Функционал CarPC мы уже определяли. Теперь под него надо определить блоки данных

Привет Stan

То что вы описали очень похоже на описание принципа функционирования сети CAN(Controller Area Network ). Т.е есть "сырые" данные а поверх них реализованы высокоуровневые протоколы передачи данных(преимущество - 5 уровневая модель ISO)

Для реализации такого канала потребуется реализация в простом случаи системной службы(или взять уже готовое решение от Microsoft), а в нормальном случае реализация специального сервера осуществляющего поддержку GUI, управление программами(данными) и расширения функциональности. [Вторым вариантом я сейчас и занимаюсь]

В конечном итоге мы получим набор взаимодействующих программ
+ свой специализированный графический UI.

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