-
![[image]](https://www.balancer.ru/cache/images/forums/logos/1358/128x128-crop/1358631-programming_oop_wallpaper_red_by_hexeno.png)
Многооконный интерфейс программы. C++ Builder и Qt (KDE).
Теги:
Vale
Привет.
Я тут начал заморачиваться портированием своей собственной программы, под Винды и Линухи.
Пока в планах две ветки, с C++ Builder-ом под Win32 и под Qt (в дальнейшем останется только Qt).
Макет интерфейса приложен.
Есть ли кто-нибудь, с кем можно обсудить интерфейс и детали реализации?
Основна проблема - хочу много окон с произвольным расположением. основное окно внизу-слева. в нем крутится цикл записи эксперимента. в остальных - периодически обновляется информация.
Я тут начал заморачиваться портированием своей собственной программы, под Винды и Линухи.
Пока в планах две ветки, с C++ Builder-ом под Win32 и под Qt (в дальнейшем останется только Qt).
Макет интерфейса приложен.
Есть ли кто-нибудь, с кем можно обсудить интерфейс и детали реализации?
Основна проблема - хочу много окон с произвольным расположением. основное окно внизу-слева. в нем крутится цикл записи эксперимента. в остальных - периодически обновляется информация.
Это сообщение редактировалось 01.05.2015 в 10:44
инфо
инструменты
Mishka
Сергей, Рома. По ООП я могу тоже помочь. Yacc может. Можешь ВМ привлечь.
Ок, вопрос первый... насколько вообще имеет смысл заморачиваться с C++ Builder?
Может сразу только Qt и для виндов и для Линуха? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
Второй вопрос: как лучше организовать работу программы оцифровки данных?
Один вариант - "монолитная" программа с несколькими окнами,внтри крутится цикл оцифровки, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом. Интерфейс в этом случае обеспечивается другой отдельной программой, которая берет данные для отображения, скажем, из разделяемой памяти и отрисовывает их на экране, и занимается вообще взаимодействием с юзером. Заниматься сервер-клиентом стремно, и кажется перебором, работа по сети не требуется и не потребуется никогда.
//=======
Основной мотив писания - иметь максимально удобную программу для работы. Имеющиеся монстры производят... виндовозное впечатление.... В них на экране слишко много кнопочек, без мыши - не жить, и т.п. Хочется написать свой "Blackbox", скажем так. Благо дофига кода вылизано под DOS-ом.
Может сразу только Qt и для виндов и для Линуха? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
Второй вопрос: как лучше организовать работу программы оцифровки данных?
Один вариант - "монолитная" программа с несколькими окнами,внтри крутится цикл оцифровки, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом. Интерфейс в этом случае обеспечивается другой отдельной программой, которая берет данные для отображения, скажем, из разделяемой памяти и отрисовывает их на экране, и занимается вообще взаимодействием с юзером. Заниматься сервер-клиентом стремно, и кажется перебором, работа по сети не требуется и не потребуется никогда.
//=======
Основной мотив писания - иметь максимально удобную программу для работы. Имеющиеся монстры производят... виндовозное впечатление.... В них на экране слишко много кнопочек, без мыши - не жить, и т.п. Хочется написать свой "Blackbox", скажем так. Благо дофига кода вылизано под DOS-ом.
yacc
Vale> Ок, вопрос первый... насколько вообще имеет смысл заморачиваться с C++ Builder?
Vale> Может сразу только Qt? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
На билдере GUI ваяется быстро... что запросто приводит к тому, что постепенно дописывая народ захламляет работу. А в общем-то без разницы - грамотно написанному ядру пофиг, какое к нему прикрутят междумордие.
Vale> Как лучше организовать работу программы оцифровки данных?
Vale> Один вариант - "монолитная" программа с несколькими окнами, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом.
Разбей на задачи - отладить их можно как независимые проги ( что даже лучше ) - потом тебе будут готовые юнит-тесты для тестирования бажных мест. А вот потом лучше соберешь это в одну прогу, отправив эту функциональность в нити/потоки - так удобнее будет сделать единый диспетчер управления, не заморачиваясь на межпроцессную синхронизацию ( через тормознутые файлы или через что-либо другое ).
Vale> Интерфейс обеспечивается другой отдельной программой, которая берет даные для отображения, скажем, из разделяемой памяти и отрисовывает их на экране, и занимается вообще взаимодействием с юзером. Заниматься сервер-клиентом стремно, и кажется перебором, работа по сети не требуется.
Потребуется скорость - будешь заморачиваться на объекты синхронизации и их именование
Vale> Может сразу только Qt? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
На билдере GUI ваяется быстро... что запросто приводит к тому, что постепенно дописывая народ захламляет работу. А в общем-то без разницы - грамотно написанному ядру пофиг, какое к нему прикрутят междумордие.
Vale> Как лучше организовать работу программы оцифровки данных?
Vale> Один вариант - "монолитная" программа с несколькими окнами, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом.
Разбей на задачи - отладить их можно как независимые проги ( что даже лучше ) - потом тебе будут готовые юнит-тесты для тестирования бажных мест. А вот потом лучше соберешь это в одну прогу, отправив эту функциональность в нити/потоки - так удобнее будет сделать единый диспетчер управления, не заморачиваясь на межпроцессную синхронизацию ( через тормознутые файлы или через что-либо другое ).
Vale> Интерфейс обеспечивается другой отдельной программой, которая берет даные для отображения, скажем, из разделяемой памяти и отрисовывает их на экране, и занимается вообще взаимодействием с юзером. Заниматься сервер-клиентом стремно, и кажется перебором, работа по сети не требуется.
Потребуется скорость - будешь заморачиваться на объекты синхронизации и их именование
Код, ответственный за отображение, уже по большей части отлажен, проблема только с обработкой изменения размера окон. Под ДОСом уже были окна, только "приклеенные".
yacc> Потребуется скорость - будешь заморачиваться на объекты синхронизации и их именование
То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?
Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
yacc> Потребуется скорость - будешь заморачиваться на объекты синхронизации и их именование
То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?
Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
Vale> Ок, вопрос первый... насколько вообще имеет смысл заморачиваться с C++ Builder?
Vale> Может сразу только Qt и для виндов и для Линуха? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
Как я бы делал. Есть блок(и) съёма данных. Есть блок(и) записи данных. Есть блок(и) обработки данных. Есть блоки(и) отображения данных. Они могут/должны сопрягаться друг с другом в цепочки вида:
съём — запись
съём — показ
съём — обработка — запись
съём — обрабока — показ
съём — обработка — обработка ... — запись и/или показ
Могут идти в параллель.
Vale> Второй вопрос: как лучше организовать работу программы оцифровки данных?
Vale> Один вариант - "монолитная" программа с несколькими окнами,
ИМХО, плохая идея. Крутиться внутри обработчиков можно только тогда, когда эти окна существенно управляют. А у тебя управление — включил/выключил. Окна отдельно. Связки для визуализации данных тоже отдельно.
Vale> внтри крутится цикл оцифровки, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом.
Это лучше. Но модуль съёмки должен пользоваться интерфейсом. За интерфейсом может быть и обработчик данных, а не только запись. Запись может быть на диск, сеть, просто в разделяемую память.
Vale> Интерфейс в этом случае обеспечивается другой отдельной программой, которая берет данные для отображения, скажем, из разделяемой памяти и отрисовывает их на экране, и занимается вообще взаимодействием с юзером. Заниматься сервер-клиентом стремно, и кажется перебором, работа по сети не требуется и не потребуется никогда.
Да, так больше нравится. Но, я бы делал бы их стыковочными.
Vale> Может сразу только Qt и для виндов и для Линуха? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
Как я бы делал. Есть блок(и) съёма данных. Есть блок(и) записи данных. Есть блок(и) обработки данных. Есть блоки(и) отображения данных. Они могут/должны сопрягаться друг с другом в цепочки вида:
съём — запись
съём — показ
съём — обработка — запись
съём — обрабока — показ
съём — обработка — обработка ... — запись и/или показ
Могут идти в параллель.
Vale> Второй вопрос: как лучше организовать работу программы оцифровки данных?
Vale> Один вариант - "монолитная" программа с несколькими окнами,
ИМХО, плохая идея. Крутиться внутри обработчиков можно только тогда, когда эти окна существенно управляют. А у тебя управление — включил/выключил. Окна отдельно. Связки для визуализации данных тоже отдельно.
Vale> внтри крутится цикл оцифровки, другой - программа управления экспериментом и записи данных на жесткий диск пишется в качестве очень компактного модуля, возможно даже и без GUI, запускаемого с высоким приоритетом.
Это лучше. Но модуль съёмки должен пользоваться интерфейсом. За интерфейсом может быть и обработчик данных, а не только запись. Запись может быть на диск, сеть, просто в разделяемую память.
Vale> Интерфейс в этом случае обеспечивается другой отдельной программой, которая берет данные для отображения, скажем, из разделяемой памяти и отрисовывает их на экране, и занимается вообще взаимодействием с юзером. Заниматься сервер-клиентом стремно, и кажется перебором, работа по сети не требуется и не потребуется никогда.
Да, так больше нравится. Но, я бы делал бы их стыковочными.
Vale> Код, ответственный за отображение, уже по большей части отлажен, проблема только с обработкой изменения размера окон. Под ДОСом уже были окна, только "приклеенные".
Значит надо бить на подзадачи.
Vale> То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?
В виндах и лине просто так не запросить.
Vale> Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
Ну, если будешь в параллель или пайпообразное запускать, то надо.
Значит надо бить на подзадачи.
Vale> То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?
В виндах и лине просто так не запросить.
Vale> Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
Ну, если будешь в параллель или пайпообразное запускать, то надо.
Vale>> Код, ответственный за отображение, уже по большей части отлажен, проблема только с обработкой изменения размера окон. Под ДОСом уже были окна, только "приклеенные".
Mishka> Значит надо бить на подзадачи.
Ну я практически уже дошел до Unix Way
Vale>> То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?
Mishka> В виндах и лине просто так не запросить.
shm*?
Vale>> Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
Mishka> Ну, если будешь в параллель или пайпообразное запускать, то надо.
В параллель.
Модуль оцифровки, управления и сохранения, и асинхронный ГУЙ. GUI может пропускать данные, оцифровщик -не может.
Mishka> Значит надо бить на подзадачи.
Ну я практически уже дошел до Unix Way
Vale>> То есть? Я не могу запросить у ОС ... не-свопируемые 64 кБайта на окно данных, куда собственно программа оцифровки будет сбрасывать данные (в определенном формате), а GUI будет лазать за ними для отображения?
Mishka> В виндах и лине просто так не запросить.
shm*?
Vale>> Синхронизировать ничего особенно не надо - частота оцифровки предполагается не выше 50 кГц (обычно не выше 10), точность отдачи команд в 100 мсек достаточна. Важно не терять данные.
Mishka> Ну, если будешь в параллель или пайпообразное запускать, то надо.
В параллель.
Модуль оцифровки, управления и сохранения, и асинхронный ГУЙ. GUI может пропускать данные, оцифровщик -не может.
Это сообщение редактировалось 24.10.2008 в 07:24
Vale> Ок, вопрос первый... насколько вообще имеет смысл заморачиваться с C++ Builder?
Vale> Может сразу только Qt и для виндов и для Линуха? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
Если C++ Builder 6 и использовать не VCL, а CLX , то исходный код программы при аккуратном программировании можно будет скопилировать на Linux, используюя Kylix C++.
Vale> Может сразу только Qt и для виндов и для Линуха? С другой стороны, при аккуратном подходе не должно быть больших проблем при переходе от одной библиотеки к другой.
Если C++ Builder 6 и использовать не VCL, а CLX , то исходный код программы при аккуратном программировании можно будет скопилировать на Linux, используюя Kylix C++.
Vale> Это тупик, проще сразу на Qt.
Ну тогда тупиком является само использование С++ Builder
Ну тогда тупиком является само использование С++ Builder
Да. Но при аккуратном программировании портировать легче чем писать заново.
Vale> Да. Но при аккуратном программировании портировать легче чем писать заново.
VCL выбрано, как я понимаю, из-за быстроты и удобства написания UI. Использование и программирование CLX-приложения ничем не отличается от VCL приложения. Это VCL-образная обертка вокруг Qt.
Но при использовании CLX есть возможность сразу получить работающее приложение без портирования.
Во всяком случае я видел подобные досточно сложные работающие приложения , правда написанные на Delphi.
В принципе можно даже поступить наооборот: программировать на Kylix c++ , использую тот же RAD, и затем перекопилить код на С++Builder 6. И при использовании VCL и при использовании CLX одна проблема :качественно отделить функциональную часть от UI. Слишком уж легко увлечься "кликаньем"
VCL выбрано, как я понимаю, из-за быстроты и удобства написания UI. Использование и программирование CLX-приложения ничем не отличается от VCL приложения. Это VCL-образная обертка вокруг Qt.
Но при использовании CLX есть возможность сразу получить работающее приложение без портирования.
Во всяком случае я видел подобные досточно сложные работающие приложения , правда написанные на Delphi.
В принципе можно даже поступить наооборот: программировать на Kylix c++ , использую тот же RAD, и затем перекопилить код на С++Builder 6. И при использовании VCL и при использовании CLX одна проблема :качественно отделить функциональную часть от UI. Слишком уж легко увлечься "кликаньем"
Copyright © Balancer 1997..2019
Создано 23.10.2008
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 23.10.2008
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
