[image]

Многооконный интерфейс программы. C++ Builder и Qt (KDE).

 

Vale

Сальсолёт

Привет.
Я тут начал заморачиваться портированием своей собственной программы, под Винды и Линухи.

Пока в планах две ветки, с C++ Builder-ом под Win32 и под Qt (в дальнейшем останется только Qt).

Макет интерфейса приложен.

Есть ли кто-нибудь, с кем можно обсудить интерфейс и детали реализации?


Основна проблема - хочу много окон с произвольным расположением. основное окно внизу-слева. в нем крутится цикл записи эксперимента. в остальных - периодически обновляется информация.
   
Это сообщение редактировалось 01.05.2015 в 10:44
+
-
edit
 

Mishka

модератор
★★★
Сергей, Рома. По ООП я могу тоже помочь. Yacc может. Можешь ВМ привлечь.
   3.0.33.0.3

Vale

Сальсолёт

Ок, вопрос первый... насколько вообще имеет смысл заморачиваться с C++ Builder?

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


Второй вопрос: как лучше организовать работу программы оцифровки данных?
Один вариант - "монолитная" программа с несколькими окнами,внтри крутится цикл оцифровки, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом. Интерфейс в этом случае обеспечивается другой отдельной программой, которая берет данные для отображения, скажем, из разделяемой памяти и отрисовывает их на экране, и занимается вообще взаимодействием с юзером. Заниматься сервер-клиентом стремно, и кажется перебором, работа по сети не требуется и не потребуется никогда.

//=======
Основной мотив писания - иметь максимально удобную программу для работы. Имеющиеся монстры производят... виндовозное впечатление.... В них на экране слишко много кнопочек, без мыши - не жить, и т.п. Хочется написать свой "Blackbox", скажем так. Благо дофига кода вылизано под DOS-ом.
   

yacc

старожил
★★☆
Vale> Ок, вопрос первый... насколько вообще имеет смысл заморачиваться с C++ Builder?
Vale> Может сразу только Qt? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
На билдере GUI ваяется быстро... что запросто приводит к тому, что постепенно дописывая народ захламляет работу. А в общем-то без разницы - грамотно написанному ядру пофиг, какое к нему прикрутят междумордие.

Vale> Как лучше организовать работу программы оцифровки данных?
Vale> Один вариант - "монолитная" программа с несколькими окнами, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом.
Разбей на задачи - отладить их можно как независимые проги ( что даже лучше ) - потом тебе будут готовые юнит-тесты для тестирования бажных мест. А вот потом лучше соберешь это в одну прогу, отправив эту функциональность в нити/потоки - так удобнее будет сделать единый диспетчер управления, не заморачиваясь на межпроцессную синхронизацию ( через тормознутые файлы или через что-либо другое ).

Vale> Интерфейс обеспечивается другой отдельной программой, которая берет даные для отображения, скажем, из разделяемой памяти и отрисовывает их на экране, и занимается вообще взаимодействием с юзером. Заниматься сервер-клиентом стремно, и кажется перебором, работа по сети не требуется.
Потребуется скорость - будешь заморачиваться на объекты синхронизации и их именование ;)
   3.0.33.0.3

Vale

Сальсолёт

Код, ответственный за отображение, уже по большей части отлажен, проблема только с обработкой изменения размера окон. Под ДОСом уже были окна, только "приклеенные".

yacc> Потребуется скорость - будешь заморачиваться на объекты синхронизации и их именование ;)

То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?
Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
   

Mishka

модератор
★★★
Vale> Ок, вопрос первый... насколько вообще имеет смысл заморачиваться с C++ Builder?
Vale> Может сразу только Qt и для виндов и для Линуха? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.

Как я бы делал. Есть блок(и) съёма данных. Есть блок(и) записи данных. Есть блок(и) обработки данных. Есть блоки(и) отображения данных. Они могут/должны сопрягаться друг с другом в цепочки вида:

съём — запись
съём — показ
съём — обработка — запись
съём — обрабока — показ
съём — обработка — обработка ... — запись и/или показ

Могут идти в параллель.

Vale> Второй вопрос: как лучше организовать работу программы оцифровки данных?
Vale> Один вариант - "монолитная" программа с несколькими окнами,

ИМХО, плохая идея. Крутиться внутри обработчиков можно только тогда, когда эти окна существенно управляют. А у тебя управление — включил/выключил. Окна отдельно. Связки для визуализации данных тоже отдельно.

Vale> внтри крутится цикл оцифровки, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом.

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

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

Да, так больше нравится. Но, я бы делал бы их стыковочными.
   3.0.33.0.3

Mishka

модератор
★★★
Vale> Код, ответственный за отображение, уже по большей части отлажен, проблема только с обработкой изменения размера окон. Под ДОСом уже были окна, только "приклеенные".

Значит надо бить на подзадачи.

Vale> То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?

В виндах и лине просто так не запросить.

Vale> Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
Ну, если будешь в параллель или пайпообразное запускать, то надо.
   3.0.33.0.3

Vale

Сальсолёт

Vale>> Код, ответственный за отображение, уже по большей части отлажен, проблема только с обработкой изменения размера окон. Под ДОСом уже были окна, только "приклеенные".
Mishka> Значит надо бить на подзадачи.

Ну я практически уже дошел до Unix Way :)

Vale>> То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?
Mishka> В виндах и лине просто так не запросить.

shm*?


Vale>> Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
Mishka> Ну, если будешь в параллель или пайпообразное запускать, то надо.

В параллель.
Модуль оцифровки, управления и сохранения, и асинхронный ГУЙ. GUI может пропускать данные, оцифровщик -не может.
   
Это сообщение редактировалось 24.10.2008 в 07:24
+
-
edit
 

Vyacheslav

опытный

Vale> Ок, вопрос первый... насколько вообще имеет смысл заморачиваться с C++ Builder?
Vale> Может сразу только Qt и для виндов и для Линуха? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
Если C++ Builder 6 и использовать не VCL, а CLX , то исходный код программы при аккуратном программировании можно будет скопилировать на Linux, используюя Kylix C++.
   2.0.0.182.0.0.18

Vale

Сальсолёт

Это тупик, проще сразу на Qt.
   
+
-
edit
 

Vyacheslav

опытный

Vale> Это тупик, проще сразу на Qt.
Ну тогда тупиком является само использование С++ Builder
   3.0.53.0.5

Vale

Сальсолёт

Да. Но при аккуратном программировании портировать легче чем писать заново.
   
+
-
edit
 

Vyacheslav

опытный

Vale> Да. Но при аккуратном программировании портировать легче чем писать заново.

VCL выбрано, как я понимаю, из-за быстроты и удобства написания UI. Использование и программирование CLX-приложения ничем не отличается от VCL приложения. Это VCL-образная обертка вокруг Qt.
Но при использовании CLX есть возможность сразу получить работающее приложение без портирования.
Во всяком случае я видел подобные досточно сложные работающие приложения , правда написанные на Delphi.
В принципе можно даже поступить наооборот: программировать на Kylix c++ , использую тот же RAD, и затем перекопилить код на С++Builder 6. И при использовании VCL и при использовании CLX одна проблема :качественно отделить функциональную часть от UI. Слишком уж легко увлечься "кликаньем"
   3.0.53.0.5

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru