Узок их круг, страшно далеки они от народа

Вот берем Qt 5.1, тащим на Mac OS X 10.7 (так сложилось, это моя девелоперская машина), собираем согласно инструкции.

Далее собираем приложение с этой Qt, деплоим его тоже по инструкции, несем на Mac OS X 10.6 и получаем, получаем... сюрприз:
Неработающее приложение!

То что пишут в mailing lists я приличными словами назвать не могу.

Но только там, в этих рассылках, удается понять, что надо ./configure -no-c++11 и собирать без вебкита (впрочем, у меня деплоится без вебкита т.е. мог бы и с ним собирать). Если же не собирать, а брать готовые библиотеки с сайта Qt, то счастья и вовсе не будет.

И ладно бы речь шла о какой-то старой и никому не нужной версии Mac OS X. Гугление нашло такой вот график:

Взято отсюда, это, конечно, Апрель-2013, но я не думаю, что за 4 месяца что-то сильно поменялось (а у фотографов, по ощущениям, доля 10.6 еще выше). И я бы даже про 10.5 бы не забывал, если бы мог...

А, да, раньше в Qt-шном ./configure был ключик -no-webkit. Как вы думаете, как сейчас собрать Qt без вебкита?

Правильно! Физически удалить qtwebkit/ из дерева сорцов. Опять мудрость из рассылки, в документации этого не нашел (и, как мне показалось, и нету).

Я к тому клоню, что Qt-шный проект как-то ощутимо стал портиться. Ну вот не было раньше такого, чтобы выпускался SDK совсем уж неработающий под важной системой.... Подождем 5.2.1, конечно, но что-то мне печально.

Comments

Стойкое ощущение, что с софтом такое сейчас повсеместно творится.

Не так давно потерял месяц (!) на разборки с техсаппортом Velleman по поводу их контроллеров для шаговых движков ( У нас все хорошо и даже замечательно, это у вас рукава к штанам пришиты ), пока не приехал осциллограф. Тогда-то все и встало на свои места. В итоге: криво задизайненный API контроллера (да еще и на Эмбаркадере), но это хотя бы можно как-то объехать, и криво задизайненная прошивка контроллера (с этим полный ахтунг), даже пришлось пересматривать концепт, т.к. ошибки в дизайне прошивки ограничивают возможности применения ШД, в зависимости от величины шага ротора. А техсаппорт и вовсе перестал отвечать на вопросы после предъявления им осциллограмм ))))

Дурацкий вопрос: а баг-то зафайлен?

Баг с вебкитом - да: https://bugreports.qt-project.org/browse/QTBUG-30487 (не мной)
Все остальное - "ну как бы все в курсе и вяло обсуждают в [development]", там не баг а "особенность"

Полагаю, что прессить надо, файлить новые баги (если такие уже не были закрыты как "won't fix"), писать комментарии, и проч.

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

У меня бага "Fullscreen не работает на Mac OS X 10.6" открыта в январе (прямо вот 01.01.2013)

Она даже assigned (и Priority P2 = important). И хоть бы одна (assigned) сука почесалась.

А сегодняшняя проблема - имеет решение (даже несколько). Лучше уж пусть фулскрин починят.

А, да, еще на маке есть проблема в 4.8.4 с QFileDialog. Если в 4.8.5 осталась - тоже буду файлить.

А что, кто-то вот совсем щастья обещал?

То, что за полгода с багой никто не почесался - меня обижает

Я бабло зарабатываю кросплатформенностью и вебо-десктопо-переносимостью.

Qt два раза рассматривал, честно. По-моему он какой-то бесполезный, особенно в свете нынешней живости CEF.

Я не знаю, что такое CEF.

А Qt - просто берет и работает, у меня #fdef __APPLE__ очень мало в проектах, хотя вот потихоньку набирается.

Другой вопрос, что на эппловские гайдлайны интерфейса я ложил.

CEF это то что ты выкинул из Qt ради сборки на 10.6 - webkit. Предлагается тебе открыть окошко с этим вебкитом и дальше программировать на HTML5.

Как человек, HTML5 проект которого уже перевалил за 8К чистых строк на кофескрипте и 5К строк HTML+CSS я могу тебе сказать что по уровню развития это примерно как виндовые тулкиты в середине 90-х годов. Очень всё, э, своеобразно и меняется буквально каждый день. Но очень интересно, опять же как в начале-середине 90-х :-)

Я даже допускаю, что гуй на HTML5 станет несколько попроще в программировании (и сильно другим на вид).

Но что мне делать с остальными 90%-ми программы? Ну хорошо, пусть даже 75%. Тоже на яваскрипте?

Вместе с тем, есть вот pics.io, даже пишут что финансирование получили, интересно....

я игрался с dcraw в бровзере, это конечно совершенно непригодно пока ни для чего. при том что быстрый рендер уже вполне есть, но вот собственно матан пока неподъемно тяжел. яваскрипт можно произвести из чего угодно, для чего есть LLVM при помощи тулзы под названием Emscripten, которая перемывает выхлоп LLVM в некоторое жутко выглядящее подмножество яваскрипта под названием Asm.js.

сделать проявку чисто на GLSL, имхо, невозможно (тогда можно было бы поселить ее в WebGL, который бежит на GPU и со скоростью у него все хорошо).

Кроме WebGL уже есть WebCL. И Гугель экспериментирует с NACL.

То есть теоретически все даже есть. Практически же - я это пока на нефритовом стержне вращал.

Не, WebGL на самом деле есть (с оговорками), а WebCL "есть" :-)

Но это одна проблема, гораздо бОльшая, имхо - это неподходящесть CSS box model (layout engine заточенный под верстку) для построения гуя. Одно дело когда мы пишем фреймворк, рассчитанный на полное отсутствие лейаута на нижнем слое (Win32 API), а совсем другое - когда надо бороться с концептуально "вражеской" системой. Там столько граблей разложено, что уй. И вот эту проблему, имхо, никто и не собирается решать.

> Я даже допускаю, что гуй на HTML5 станет несколько попроще в программировании (и сильно другим на вид).

Достаточно очевидно, что в 2013-м году по сравнению с HTML+JS любой другой UI - тотальное г-но. Как в смысле результата, так и в смысле скорости разработки.

И прикинь - у тебя получается сразу мало что кросплатформенный результат, так ещё и десктопно-вебовый.

Я задал другой вопрос: что делать с остальным кодом то?

Сам по себе UI меня не сильно напрягает. Ну UI, ну спрограммировал, это занимает время, но не требует думанья над ним.

> Я задал другой вопрос: что делать с остальным кодом то?

Я не понимаю вопроса. Обычно всё кроме UI и так кроссплатформенное, по-умолчанию. Единственная не-UI-шная библиотека, которую мне доводилось втыкать специально за кроссплатформенность, это curl. И то я его уже вроде отовсюду выкинул.

Что ты используешь из Qt кроме UI, и зачем?

> Что ты используешь из Qt кроме UI, и зачем?

Сеть (по мелочи), мультипоточность (thread pools и упрощенные версии его же в виде map-reduce и просто map), таймеры (по мелочи), хранение настроек, семафоры-мьютексы.

Использовал бы и атомарные операции, но они мне нужны на совсем нижнем уровне, который без Qt тоже должен работать.

> Если у меня UI на JS(+HTML/CSS), а логика - на C++, то придется же писать некий промежуточный уровень, который параметры из C++ вытащит в JS и наоборот? Вот, не хочу!

Этот уровень уже написан много раз, по-разному, на все вкусы и размеры, писать его заново не обязательно.

См.напр
https://code.google.com/p/chromiumembedded/

Даже чиста для виндов CEF регулярно побеждает в рабочих дискуссиях CEF vs. IWebBrowser с разными обвязками, что как бы говорит нам, что это действительно хороший инструмент.

В смысле, "написан"?

Вот у меня есть C++-ная библиотека. Объект у которого есть методы и данные.

Как мне получить этот объект "внутри" яваскрипта? Ну там скормить ему файл, подождать пока прожует, потом он выплюнет 400 мегабайт (например) RGB-битмепа, который я хочу показать пользователю. Позумить, покрутить и все такое (сейчас я это делаю OpenGL-ем).
Сгенерировать JPEG и скормить его этому CEF-у? Херня же какая-то....

Дискуссия CEF vs IWebBrowser, равно как и "вебовость" приложения меня совершенно не волнует. У меня приложение для быстрого жевания гигабайтов фоточек.

> В смысле, "написан"?

В смысле написан.

> Как мне получить этот объект "внутри" яваскрипта?

Никаки. Связка между JS и C++ примерно на уровне SQL и C++. С++ объект внутри SQL не получают.

> Ну там скормить ему файл, подождать пока прожует, потом он выплюнет 400 мегабайт (например) RGB-битмепа

JS узнаёт у юзера имя файла и передает его C++. С++ жуёт. Когда прожевал - вызывает, например, OpenGL, если хочется экстрима.

> Сгенерировать JPEG и скормить его этому CEF-у? Херня же какая-то....

И так тоже можно. Только не JPEG конечно, а loseless PNG. Я бы именно так и сделал, и всё верчение-зуменье засунул в JS, типа такого:

http://demo.leadtools.com/HTML5/ViewerDemo.htm

> У меня приложение для быстрого жевания гигабайтов фоточек.

Ну и жуй себе, внутри C++. А потом отдавай простым UI-шны средствам для показа юзеру. Мы в 21-м веке, сейчас это визуалбейсиковая задачка - показать на экране двухмерную картинку сжатым размером ну пусть даже 60 мегабайт (на самом деле небось 16, да?). Делать надо через визуалбейсик, т.е. JS, canvas и WebGL как самый максимум. WebGL уже очевидно оверкилл для показа двухмерных картинок, но если надо извращений...

Я все это прочитал и все равно не понимаю, что я выиграю (обсуждать lossless PNG, имелся в виду, вероятно, нежатый, я не хочу)?

Что потеряю - выше написано (в перечислении того, что я беру из Qt). Thread pool, Map/Reduce, общий одинаковый и работающий интерфейс к OpenGL, много всего.

> Я все это прочитал и все равно не понимаю, что я выиграю

Ты выиграешь уплывание существенной части твоего продукта в очень высококачественную живую среду (HTML и CEF) из фиговатой и умирающей (Qt).

> обсуждать lossless PNG, имелся в виду, вероятно, нежатый, я не хочу

Имелся ввиду именно lossless. PNG сжимает внутри себя deflate-ом от zip-а. Непонятно, почему именно его ты не хочешь обсуждать, отличный формат для внутреннего обмена.

> Что потеряю - выше написано (в перечислении того, что я беру из Qt). Thread pool, Map/Reduce, общий одинаковый и работающий интерфейс к OpenGL, много всего.

Как-то ты это всё очень детально обсуждаешь, я бы даже сказал серьезно. Обычно когда человеку советуют выбросить нах глюкавый M$ Виндоуз и перейти на правильный кошерный Линукс ответ бывает короче и конкретнее.

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

> Имелся ввиду именно lossless. PNG сжимает внутри себя deflate-ом от zip-а. Непонятно, почему именно его ты не хочешь обсуждать,

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

> Как-то ты это всё очень детально обсуждаешь, я бы даже сказал серьезно

Да, естественно. Потому что есть планшеты и прочие телефоны, где HTML5 - довольно натуральный путь.
Но на них эффективность еще важнее, чем на нормальном компьтере и идея кидаться внутри приложения жатыми PNG меня пугает.

> Потому что сжать, чтобы тут же, через долю секунды, разжать - просто глупо.

Если через долю секунды - то не глупо, а пофигу.

Глупо если это медленно.

> Но на них эффективность еще важнее, чем на нормальном компьтере и идея кидаться внутри приложения жатыми PNG меня пугает.

Интуиция подсказывает мне, что в 21-м веке абсолютно любые операции, которые ты проделываешь с одиночной статической картинкой фотоаппаратного размера, выполняются за нулевое время на любом процессоре, включая телефонный.

Интуиция обманывает тебя.

Типичное время обработки (распаковки, преобразования, показа) "картинки фотоаппаратного размера, но не JPEG" - 2-4 секунды.
Что невероятно много, когда этих картинок - тысячи. А JPEG - не всех устраивает (и именно в эту группу я и целюсь своим софтом).

А смешнее всего то, что почти все "производители мелкой и средней руки" (но не Adobe) пользуются для этой "распаковки, преобразования" - одним и тем же кодом.

> Полгига запаковать zip-ом - это сколько?

А вот известно сколько. Берем 229-мегабайтный нежатый Tiff и делаем:

$ time tiff2png 0.IIQ.tiff
real 0m43.362s
user 0m42.745s

43 секунды, короче. 5 мегабайт в секунду. Жмется в два раза.

Это: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz

libpng у нас в природе одна, других не носят.

Вот и ответ на вопрос "быстро ли это..."

Вдогонку.
Тут в одном закрытом чатике обсуждают проблему визуализации большого количества данных. Как раз на HTML5/js
Так вот, пишут, что 25 мегабайт json распарсить - уже проблема, кровь-кишки-распидарасило.

И я, отчего-то, не удивлен.

> Так вот, пишут, что 25 мегабайт json распарсить - уже проблема, кровь-кишки-распидарасило.

Я думаю убивать без суда и следствия надо начинать на уровне трёхкилобайтного json-а. А за 25 мегабайтный надо перед смертью пытать несколько недель.

Это примерно как сделать SQL-ную таблицу с двумя миллионами полей.

Полностью с тобой согласен!
Но за сжатие данных для передачи их в фронтенд для визуализации *внутри одного приложения* полагается ровно оно же.

Вместе с тем, если ты считаешь, что пользователю не впадлу поаплоадить полгигабайта прежде чем начать работать - я это учту. Есть у меня идея приложения за которое платить per use будут охотнее, чем покупать. Потому что нужно не каждый день.

> Но за сжатие данных для передачи их в фронтенд для визуализации *внутри одного приложения* полагается ровно оно же.

Хранить легкосжимаемые данные в сжатом виде внутри программы - нормально.
Если у меня есть огромная картинка, и я никогда не показывать от неё юзеру больше маленького кусочка, нафига она мне вся такая расжатая постоянно в памяти?

> Вместе с тем, если ты считаешь, что пользователю не впадлу поаплоадить полгигабайта прежде чем начать работать - я это учту.

Нормальный домашний юзер с видеокамерой редко снимает ролики дольше трёх минут (собственно он редко снимает ролики дольше 40 секунд), и обычно он их хочет в итоге залить на Ютуб. Go figure.

"Вход на Ютуб с редактированием" - очень разумный сценарий приложения.

> нафига она мне вся такая расжатая постоянно в памяти

Чтобы поскроллить ее и позумить быстро. Ну и память же надо куда-то девать, а то понакупили 64-битных систем...

Мне, кстати, сдается, что ты никогда до OpenGL-я не доходил. Я сам дошел где-то с год назад и до сих пор в изумлении, то что у меня в одной программе делает изрядно кода (скажем, ~1000 строк, потому что параллельно и все такое) - делает теперь (в дпугой программе) 20-строчный шейдер. Цена вопроса - чипсетные интелы с OpenGL 1.5, но таких уже крайне мало (и есть, в принципе, эмулятор на DX9)

>> нафига она мне вся такая расжатая постоянно в памяти
>
>Чтобы поскроллить ее и позумить быстро. Ну и память же надо куда-то девать, а то понакупили 64-битных систем...

Если стоит задача куда-то девать память, можно сделать PNG с нулевым сжатием.

> Я сам дошел где-то с год назад и до сих пор в изумлении, то что у меня в одной программе делает изрядно кода (скажем, ~1000 строк, потому что параллельно и все такое) - делает теперь (в дпугой программе) 20-строчный шейдер.

Теперь осталось сделать всё то же самое WebGL-ем, и будет совсем хорошо.

> Дискуссия CEF vs IWebBrowser, равно как и "вебовость" приложения меня совершенно не волнует.

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

OCR-ы вон онлайновые делают. Видеоредакторы.

Да-да, видеоредакторы. Сбросьте с вашей камеры нежатый CinemaDNG, сконвертируйте его в mpeg, залейте на сайт за недельку и потом, почти сразу, редактируйте.

Вопрос: а юзер этого безумия - кто?

> Сбросьте с вашей камеры нежатый CinemaDNG, сконвертируйте его в mpeg

Это какие-то странные слова - CinemaDNG, mpeg... Загрузите .mts, получите .flv.

А ещё лучше - получите URL на ютубе.

> залейте на сайт за недельку

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

> Вопрос: а юзер этого безумия - кто?

Кто юзер онлайновых версий программ? Да все. Вот я например.

> Загрузите .mts, получите .flv.

Ну вот полчаса в HD с приличным качеством - это сколько гигов .mts?

> Кто юзер онлайновых версий программ? Да все. Вот я например.

В смысле - ты сам, лично, без ансамбля, пользуешься онлайн-версиями своих программ?
Ну молодец, че.

> Ну вот полчаса в HD с приличным качеством - это сколько гигов .mts?

Какая разница? Мы пишем онлайновый видеоредактор не для Сергея Михалкова.

> В смысле - ты сам, лично, без ансамбля, пользуешься онлайн-версиями своих программ?

Я пользуюсь онлайновыми версиями чужих программ.

> Мы пишем онлайновый видеоредактор не для Сергея Михалкова

В этом и разница. Я то целюсь в узкий рынок, потому что а) пишу про то, в чем понимаю б) пишу и для себя тоже.

Серьёзный проект на языке без статической типизации? NO WAY. Ну или тестов должно быть в 2-3 раза больше полезного кода.
Не, серьёзно, ну писал я большие проекты без статической типизации -- любой рефакторинг превращается в ад и кровь-кишки-распидорасило.

> Я к тому клоню, что Qt-шный проект как-то ощутимо стал портиться.

Некогда им - деньги нужно зарабатывать.
А с вебкитом сейчас вообще чехарда - типа - блинкать или не блинкать: http://blog.qt.digia.com/blog/2013/06/25/experimenting-with-chromium-and...
Там некто Курт интересно высказался ;)

>Некогда им - деньги нужно зарабатывать.

Как будто в платной версии QWidget::showFulscreen() работает на 10.6

Надо порефрешить этот баг через платных кастомеров, да.

> через платных кастомеров

Гы!
Я разговаривал както с разработчиком скайпа. Он как раз занимался допиливанием Qt. Он говорил, что любая версия Qt всегда требовала существенной доработки чтобы её можно было релизить в продукте.
Когда я спросил - зачем продолжать жрать кактус, то он ответил, что кроссплатформенного ничего лучше нет.

ну это ж вопрос, что именно они там допиливают. Тот же скайп - довольно нестандартный и снаружи и внутре.

Вот у меня еще есть бага в QFileDialog - и я понял, что никаким способом не смогу ее починить, не понимаю что там внутри. Только молиться.