Как стать автором
Обновить

Комментарии 56

Вот если бы еще все либы статически «из-коробки» линковались, либо чекбоксом можно было указать без пересборки всей среды, хотя когда заказчику передаешь внушительный дистр с кучей либ, то да, выглядит посерьезнее, но все же хотелось бы. А так Кьют сильно облегчил мне программинг и изучение. что само по себе приятно.
Ну сейчас ИМХО либы не такая уж и проблема. Все собрал в инсталлер и живи спокойно. Правда под линуксом конечно проще. Там qt из дистра ставится и все ок.
В линуесе сложнее бывает. Дистрибутивы не всегда успевают за Qt, а вот изменения в qtquick бывают необходимы, что создает проблему для развертывания
Есть такой момент. Но большинство все же сидит на убунте и сусе. А там все более менее ок
Кстати для этого примера я не ставил компоненты в систему, а просто расположил их рядом с бинарником. Так что файлов стало еще больше :)
cmake fixup_bundle спасут отца русской демократии.
А применение стилей от Harmattan под Desktop возможно?
От Харматтана нет. А другие десктопные стили доступны (смена происходит также как и для приложений на QtGui, либо заданием в коде стиля для QApplication, либо через аргумент -style).
Вполне. Таким образом работает эмуль. Это тупо скомпиленный Харматтан для десктопа.
Их для этого придется с собой таскать. В дефолтной поставке Qt их нет
Компонент тоже нету.
Будут потом. Естественно, сейчас никто альфу добавлять не будет :)
Да с модульной структурой Qt смысл слова дефолтная поставка Qt теряется.
Ну это то да. Но кумль будет по сути в главном модуле. Компоненты по идее тоже
И, кстати, по умолчанию для QtGui нет стиля харматтановского (на н9 приложения запускается со стилем аля WIndows9x). Все, что написано на Harmattan использует MeegoTouch. Но тем не менее я видел некий пакет со стилями под MeeGo Harmattan. Не ставил правда, поэтому не могу ничего сказать
Он коряво работает. Но если хочется стили от Харматтана, то и юзайте meego touch framework + meego components. Они кроссплатформенные и компилируются и запускаются хоть на винде хоть в макоси хоть на андроиде.
Хм, насколько я помню meegotouch не такой уж кроссовый. По крайней мере попытки перенести компоненты на дроид традиционно начинаются с компонентов под симбиан (я в свое время делал для внутреннего проекта, плюс сейчас в necessitas-devel человек, который этим занимается, тоже пишет про симбианвские компоненты).
Ну вполне возможно там есть X11 огрызки, но в QtSDK под виндовс же есть сборка компонент рабочая, что намекает.
а кстати на винде разве не через qemu запускается? я просто ни разу не запускал, поэтому немного не в теме
Там есть версия через qemu, а есть простая версия с qml компонентами от Харматтана для десктопа. Она юзается в креаторе для визуального редактора.
НЛО прилетело и опубликовало эту надпись здесь
у меня контр-вопрос. А кто нибудь вообще юзает кумльный дизайнер? Просто ни я, ни все кого я знаю не юзают. Пишут руками. Это возможно просто осталось с тех времен, когда он был почти неюзабелен, но тем не менее.
НЛО прилетело и опубликовало эту надпись здесь
В линуксе он у меня прекрасно работает)) Он вполне юзабелен, но просто когда перестаешь быть новичком, то быстрее в коде все забить, но смотреть результаты кодинга проще в дизайнере
Я все равно не доверяю дизайнеру. Он плохо понимает мои кастомные компоненты, у которых часть визуальной логики завязана на c++-объектах. Так что проще нажать Ctrl-R :)
НЛО прилетело и опубликовало эту надпись здесь
Ну оно как то само собой получается что у меня почти все такое :) Да и Ctrl-R меня устраивает
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
ну да, с девайсом разрабатывать проще. Правда в случае девайса есть другой прикол. У н950 и н9 разные размеры экрана (физически, различие минимально, но есть). Из за этого не рекомендуется например делать в пиксель шириной линии. На одном девайсе будет ок, а на другом фигня.
Сам исправлял пару багов в компонентах, штука хорошая, а вот на QmlDesktopViewer я как-то и не обратил внимание, делая по старинке через QDeclarativeView.
С QDeclarativeView проблема в использовании Window. Он создает отдельный QDeclarativeView для каждого Window, но если qml с Window запущен на уже созданном QDeclarativeView, то все его содержимое окажется на созданном, а Window будет пустой (то есть два окна)
Еще бы оно научилось QDeclarativeEngine между окнами шарить, а то каждый Engine — это 20 мегов памяти примерно. Судя по коду, оно пока так не умеет делать.
ну я думаю это будет в итоге. Не так это и сложно, как мне кажется. Хотя в дебри десктопных компонентов не залезал, может там какие-нибудь архитектурные ограничения встретятся
Ну у меня получалось шарить движок между окошками. Не скажу, что это очень сложная была задача.
Сама по себе задача легкая, не спорю. Но можно организовать работу этих окон так, что будет почти нереально. Надо будет на досуге глянуть что у Дженса в этом направлении есть.
Просто иначе например не ясно, как например размеры окошек менять в разных window'ах и прочие эффекты делать. Ну и просто из одного окошка к компонентам другого будет не добраться без расшаренного engin'а.
это то все понятно. Но, повторюсь, сейчас это такая глубокая альфа, что еще рано думать об этом. Базовый бы функционал работал корреткно
Это да, но размер у либы крошечный, поэтому я уже не стесняюсь ее в продакшене юзать. А если что-то не работает или глючит, то я это просто беру и фикшу)
Тоже самое. Только я у себя сделал сабмодуль гитовый, Чтобы не объяснять другим, где взять компоненты и чтобы переходить на новую версию только после проверки. А то уже пару раз приходилось слегка переделывать свой код после обновления на свежий master.
Я бы тоже так сделал, но у нас svn на работе(
Сейчас например думаю, как бы ContextMenu перепилить в соответствии со спекой. А то они не работают.
На моей памяти год назад на девдеях эта альфа уже была. Лео показывал эти компоненты для десктопа. Как так вышло, что за год дело не сдвинулось?
На прошлых девдеях Лео рассказывал о компонентах вообще. То есть и о мобильных тоже (о них в большей степени). Если мне не изменяет память, то десктопные появились уже в начале этого года.
Сдвинулось, на Qt5 его портировали, еще окошки добавили, отдельно бранч для макоси пилится. Но таки да, не скажу, что дико активно разрабатывается. Но там и работы не слишком то много.
Кдешники вот с тем же самым API сделали Plasma components'ы. Правда без методов типа Window и т.д.
Но их доделать — дело не хитрое)
Как я понял его вообще пилят полтора человека. Дженс и еще кто-нибудь, когда делать нечего. Поэтому и не быстро
Да главное, чтобы API для компонент устаканилось. Запилить то свои — дело не шибко хитрое.
Ну основное API оно общее для всех компонент. Но дьявол он в мелочах да
Посмотрел исходники, да, действительно не шарит. Но особых проблем это сделать не вижу, значит будет в итоге. По крайней мере я надеюсь на это.
> Для того, чтобы показать возможности десктопных компонентов, а заодно обозначить основные проблемы
> и преимущества их использования, я создал минимальное графическое приложение на классическом QtGui
> и на компонентах.

Не нашел реализации приложения на QtGui. Добавьте для сравнения, если не трудно.
UPD: извиняюсь, не увидел. Оказывается, они как две капли воды.
Ну почти :) в этом и соль :)
Я не стал приводить здесь исходники, но внизу поста есть ссылочка на архив со всеми исходниками. Плюс на скриншотах QtGui-версия тоже присутствует
Напоминает Silverlight первых версий, когда было видно что возможностей создания интерфейса уже много и они действительно гибкие, но набор стандартных элементов очень узок и что-то большое на этом делать пока рано.
Ну чистый qml очень удобен для кастомных интерфейсов. Для стандартных как раз Qt COmponents сделали.
А так, можно встроить любой виджет из QtGui в QDeclarativeView (через прокси-класс), но это очень неудобно
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории