Комментарии 26
Спасибо! Отличная работа!
На кой черт тут вообще гуйня нужна?
А если так хочется, то зачем было мучиться с культями, ведь проще сделать веб-морду!
А если так хочется, то зачем было мучиться с культями, ведь проще сделать веб-морду!
Вебморда — это не удобно, переодически обновляющийся браузер много кушает. А гуй просто показал свою полезность. Он занимает мало места в окне и не грузит лишний раз систему. К тому же, для вебморды существует Octoprint.
Вебморда — необязательно периодически обновляющаяся статика.
Взгляните на transmission-web — там всё сделано на ajax. Сам демон всего лишь принимает сигналы и рассылает уведомления по rdp. А простой шаблон + код на javascript позволяют с этими самыми сигналами/уведомлениями работать. В итоге на бэкэнд наличие веб-морды вообще не даёт никакой нагрузки.
Ну и, кстати, не совсем понял насчёт Mac OS X. Вы просто не смогли этого сделать, потому что нет мака? Или заметили какую-то принципиальную несовместимость?
Взгляните на transmission-web — там всё сделано на ajax. Сам демон всего лишь принимает сигналы и рассылает уведомления по rdp. А простой шаблон + код на javascript позволяют с этими самыми сигналами/уведомлениями работать. В итоге на бэкэнд наличие веб-морды вообще не даёт никакой нагрузки.
Ну и, кстати, не совсем понял насчёт Mac OS X. Вы просто не смогли этого сделать, потому что нет мака? Или заметили какую-то принципиальную несовместимость?
Ну тут не знаю, не знаток я веба. Я с Octoprint сравниваю разве что.
Что до OSX — все просто. Для кросс-компиляции ужасно мало тулчеинов, и большинство давно заброшено. А живой я нашел только один — osxcross. Он, да и все остальные, что я видел требуют наличия файлов, распространяющихся не свободно, получить которые реально только на OSX, раздербанив Xcode.
Что до OSX — все просто. Для кросс-компиляции ужасно мало тулчеинов, и большинство давно заброшено. А живой я нашел только один — osxcross. Он, да и все остальные, что я видел требуют наличия файлов, распространяющихся не свободно, получить которые реально только на OSX, раздербанив Xcode.
А, ну если всё упирается в отсутствие кросс-тулзов, то это всё ж не так фатально (никто не мешает прямо без всяких кросстулзов собрать на маке. Или на виртуалке с макосью).
О том и речь.
Но ни мака ни копии OSX у меня нет, и такая политика по распространению необходимых для разработки пакетов удручает.
Единственный способ собрать что-то под OSX — делать это на OSX
Но ни мака ни копии OSX у меня нет, и такая политика по распространению необходимых для разработки пакетов удручает.
Взял с гитхаба. Собрал. Пришлось закомментировать пару строк, где ui->lockbox.
Гуй запускается. И даже увидел подключенный Printrbot Simple как 'usbmodem12345'. И даже активировал интерфейс по кнопке «connect». Но вот дальше ничего не происходит — связи с принтером нет.
(для полноты картины скачал RepeiterHost. Он увидел порт с тем же именем и успешно подключился).
(Mac OS 10.10. Последние xtools. qt5-mac из macports.
Собирал из ревизии 3bb513
Гуй запускается. И даже увидел подключенный Printrbot Simple как 'usbmodem12345'. И даже активировал интерфейс по кнопке «connect». Но вот дальше ничего не происходит — связи с принтером нет.
(для полноты картины скачал RepeiterHost. Он увидел порт с тем же именем и успешно подключился).
(Mac OS 10.10. Последние xtools. qt5-mac из macports.
Собирал из ревизии 3bb513
А дайте ссылочку на «ажурную кошку»? Понравилась моделька…
Соберу-ка я это под ALT Linux. :)
Спасибо за программу.
Спасибо за программу.
Кстати, под андроид такое есть? Часто бросить рядом с принтером планшет удобнее, чем тянуть провода от компа.
Под Андроид можно собрать сабжевый проект, правда, был какой-то глюкодром с QSerialPort, но его можно пропатчить. Андроид понимает преобразователи USB-RS232 через OTG.
Ну, я когда это писал — специально не использовал никаких платформозависемых вещей, так что при небольшой модификации QSerialPort — собрать это под Android будет просто. Пока что QSerialPort из коробки Android не поддерживает.
Есть ряд замечаний:
Cлоты/сигналы — это не часть языка С++, а нововведение Qt, для которого используется специальный препроцессор — компилятор метаобъектов moc.
Вот это:
Пора бы уже включить
Разбирать строковое значение можно и регулярным выражением, и им же контролировать формат.
Вот здесь:
Cлоты/сигналы — это не часть языка С++, а нововведение Qt, для которого используется специальный препроцессор — компилятор метаобъектов moc.
Вот это:
QString extmp = "";
Пора бы уже включить
-std=c++11 и выуччить auto, чтобы не создавать монстров:QFuture<TemperatureReadings> parseThread = QtConcurrent::run(this, &MainWindow::parseStatus, data);
auto parseThread = QtConcurrent::run(this, &MainWindow::parseStatus, data);
Разбирать строковое значение можно и регулярным выражением, и им же контролировать формат.
Вот здесь:
TemperatureReadings t;
t.e = extmp.toDouble(); //Переводим строки в числа
t.b = btmp.toDouble();
return t; //Возвращаем температуру
Спасибо за замечания!
В первых версиях я использовал с++11 для прямой инициализации массивов, но это привело к падению приложения на Debian stable, а так же к очень неприятной ругани компилятора clang, так что с++11 было решено пока оставить до лучших времен. Хотя, возможно, это я не умею писать скрипты сборки, но с другой стороны за меня это делал qmake…
Я вроде и не подразумевал, что сигналы со слотами — часть С++, видимо не очень удачно сформулировал.
Каюсь, с регулярными выражениями я не очень, но к новому релизу изучу тему поподробнее.
Про инициализацию QString пустой строкой упустил, уберу.
Что до структуры — мне этот метод кажется самым удобным, и читается лучше. Есть ли выигрыш в производительности, если структуру убрать?
В первых версиях я использовал с++11 для прямой инициализации массивов, но это привело к падению приложения на Debian stable, а так же к очень неприятной ругани компилятора clang, так что с++11 было решено пока оставить до лучших времен. Хотя, возможно, это я не умею писать скрипты сборки, но с другой стороны за меня это делал qmake…
Я вроде и не подразумевал, что сигналы со слотами — часть С++, видимо не очень удачно сформулировал.
Каюсь, с регулярными выражениями я не очень, но к новому релизу изучу тему поподробнее.
Про инициализацию QString пустой строкой упустил, уберу.
Что до структуры — мне этот метод кажется самым удобным, и читается лучше. Есть ли выигрыш в производительности, если структуру убрать?
Выигрыша в производительности ожидать не стоит, однако кортеж или пара пишутся менее помпезно, а главное — не нужно делать объявление-призрак.
Да вот, если честно, для разбора такой простой строчки регулярка особо и не нужна. Ручками написанный ДКА будет скорее всего пошустрее-таки!
А вот преобразовывать из строки в число — зачем? Чтобы потом число вывести (= преобразовать снова в строку)? Просто выкусывайте из потока две подстроки — и прямо копируйте их содержимое в форму!
Заодно избавитесь от потенциальной баги. (Если я поставлю системную локаль в русскую — знаете, что будет? У нас целую и дробную части разделяет запятая, а не точка! И если в недрах Qt используется системная локаль — то toDouble попросту не сработает)
А вот преобразовывать из строки в число — зачем? Чтобы потом число вывести (= преобразовать снова в строку)? Просто выкусывайте из потока две подстроки — и прямо копируйте их содержимое в форму!
Заодно избавитесь от потенциальной баги. (Если я поставлю системную локаль в русскую — знаете, что будет? У нас целую и дробную части разделяет запятая, а не точка! И если в недрах Qt используется системная локаль — то toDouble попросту не сработает)
Локаль жестко заданая для конкретно этих боксов (все разрабатывается на русской локали), так что нет баги. А вот что до числа — LCD дисплеи, которые я использую для отображения температуры кушают число.
Чаще всего, в соревновании «Ручками написанный ДКА» против re2c или даже flex, выигрывает последний. При этом, ручками написанный автомат отнимает определенное время на отладку, тогда как для регулярных выражений есть справочники популярных вариантов и даже визуальные конструкторы.
Про выделение в отдельный поток — вообще с этого нужно было начинать. Любой софт который общается с внешним устройством по ком-порту (тем же модемом) всегда выделяет это в отдельный тред. Кстати этот тред большую часть времени просто ждёт сигнал с порта.
Это не аксиома. Под Windows можно написать аж целых два варианта (используя таймаут на чтение или асинхронный ввод-вывод) однопоточного общения с последовательным портом, совмещенного с обработкой пользовательского интерфейса.
Однопроцессорные системы все равно многопоточность могут только эмулировать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Приручаем динозавров, или как я писал свой собственный host controller для лаборатории 3D-печати