Russian Qt Forum

Доброго времени суток! Подскажите, как можно реализовать вот такой "кастомный" компонент (подобие таймлайн музыкальных редакторов)?

(https://upload.wikimedia.org/wikipedia/ro/timeline/4d052688fe7d1eda97e91c09c6477a00.png)

варианты:
1) использовать QWT, вроде там что то подобное было.
2) написать самому, рисуя картинку на QWidget
3) написать самому, рисуя картинку на openglWidget(не помню как он точно называется)
4) написать самому, рисуя картинку на QGraphicScene
5) заказать этот виджет кому то другому и не париться как он сделан :)

Я как раз рассматриваю пункты 2-4  :)
Поэтому и задал вопрос. Может кто уже реализовывал эту штуку или интересовался этим вопросом и есть какая-то информация или сорцы.

Ну выглядит не особо сложно, тут проблемы начнутся когда вы захотите масштабирование сделать, передвижение графика и так далее :)

PS Сори не заметил раздел Qt Quick. В квике я плохо разбираюсь.

Можно в принципе перенести тему в Gui. Реализация в квике это как вариант.

Когда-то давно, приходилось делать подобное. Юзал метод 2.

Никаких наработок не осталось у Вас? Был бы очень признателен)

В qwt есть эти наработки. Почему бы не их? :)

Время обсуждения уже соразмеримо с временем реализации (2), и скоро наверное превысит его

Так же и с вашей темой, Igors :D
Единственное различие вам уже всё что ток можно накидали, а тут ещё не успели :D

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

Я в свое время использовал QGraphicView, QGraphicScene, QGraphicItem.

Если не надо двигать элементы, то легко реализуется с помощью QWT, QCustomPlot, QtChart

Вот тут посмотрите - https://github.com/dinusv/qml-gantt, может быть подойдёт.

(https://github.com/dinusv/qml-gantt/raw/master/doc/screen-gantt.png)

Чего вы все на QML облизываетесь? Оно же глючное и тормозное.

Таки да :(

Зато соответствует менталитету (как бы ни хрена не делать)

Менталитет тут не причем, QML это не изобретение русских программистов.
QML это мечта, в которой реализацию GUI можно отдать дизайнеру и клиенту, выставить их из кабинета и наконец заняться делом. Возможно так и случиться.

Не понятно, что изменится для программистов. Ну накидает клиент в кумлдизайнере кривой гуй.... а логику гуя кто писать будет??

Вот на QML вся логика GUI и описывается. А программист напишет бекенды, которые из этого гуя будут вызываться.

Так а эту логику то кто писать будет? Предполагается, что клиент понятия не имеет о том, что такое QML. В чем преимущества для разработчиков?

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

Только все забывают что в гуе так же должна быть реализовано дофигища логики :) Потому как не старайся, программист будет нужен для создания нормального гуя.

PS хотя вполне возможно насыщение гуя стандартными решениями на любой вкус, на манер конструктора. Но пока оно насытится :)

QML это javascript, дофигища логики можно легко описывать на нем.

Ну то есть раньше был один программист, который знал Qt и C++. Теперь их надо два.
Вам как, это ненормальным подходом не кажется, не?
А может, пусть тогда клиент C++ учит и сразу гуй на нем и программирут, так еще лучше будет...

javascript простой как топор, после с++ покажется фигней :)

Раньше был один программист  С++ и один дизайнер, который его все время отвлекал, а с QML он может самостоятельно клепать гуй в присутствии заказчика и позволить программисту C++ выполнять свою работу.

Я так уже работал один раз. Дизайнер клеил окошечки в Qt Designer и передал мне. Ну и заодно документ на 25 страниц, описывающий "а вот эта вот кнопка мб и не кнопкой, а мб это вообще прогрессбар и работает только с такими вот типами файлов".
С qml похожая ситуация.

Ребят, подскажите идею объединения "линейки" и поля для item's? По всей вероятности будет лучше сделать это с QGraphicsScene, QGraphicsView и QGraphicsItem. В демках Qt есть пример с чипами. Строится все на выше перечисленных компонентах.

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

утопия.
гуй можно и в дизайнере наклепать и потом фотошопом подрихтовать.
зачем ему QML ?

что такое "поля для item's"?

я так и не нашел исходников... но точно помню, что делал на виджетах. через паинтэвенты и маусэвенты, по дедовски :)

Что бы результатом его работы была не красивая картинка, а готовый GUI. За это он сможет больше получать денежек. :) На самом деле не важно, это будет один человек или к дизайнеру добавится еще один QML-программист, главное что они перестанут отвлекать С++-программиста и смогут быстро делать и сопровождать GUI. :)

ну это своего рода "контейнер" в которых находятся элементы. на картинке зеленые, синие прямоугольники это элементы.

Да что значит отвлекать?? Дизайнер наклепает у себя в конторке гуй в дизигнерах-фотошопах и перешлет гуишниками, которые его заимплементируют. Честно, по моему, проблема надуманная и раздутая маркетологами до какой-то ужасной вещи, а QML это типа некий silver bullet, который позволит дизайнеру без знания языка быстро нагавнякать функциональный!!! гуй :)

Хотя да, дополнительные знания или дополнительного программиста придется еще дополнительно оплатить, на это маркетологи и рассчитывают :)

Как самый простой вариант, кстати, можно обычной таблицей сделать :) Задавать цвет фона ячеек и текст там, где они нужны. Но это если особой интерактиваности не надо (там, итемы тягать мышом). Хотя... драг-дроп тоже никто не отменял)

Это лучше, чем снимать программиста C++ по несколько раз на дню, чтобы он правил двум дадельникам (клиенту и дизайнеру) qss файлы, из-за того, что у них внезапно поменялся концепт, а сами в qss они ни хрена не понимают. :)

Я вот одного не пойму - а почему клиент с дизайнером вообще должны лезть в qss??
Пусть делают мокап концепта в фотошопе, а когда доделают - отдают гуишникам и не думают ни о каких qss.

Они сделали концепт - им написали qss, потом они решили изменить "пару цветов", им переделали qss, потом они решили, что эта панель должна плавно выезжать - им добавили панель, им показалось, что цвета "темноваты" - им переделали qss, скорость выезжания панели очень медленная - им исправили скорость выезжания, они ...    Они "работают" и им нужен кто-то, что бы эти изменения применять, а лучше было-бы что-бы они сели где нибудь и трахались сами. :)

Потому и нужен программист по интерфейсу. Который будет сидеть с дизайнером и заказчиком, давать советы по юзабилити интерфейса и возможности реализации. А потом реализовывать.

Все эти попытки спихнуть эту должность на дизайнера или программиста бессмысленны. Нужен именно дизайнер плюс программист :)

Плюсую, ибо сам время от времени занимаюсь таким вот "техническим дизайном" гуя. Вот честно - никакой дизайнер и тем более клиент не будут в состоянии редактировать css и ресурсы, а тем более "менять код выезжающих панелек" :) Каждому - свое.

Насколько я вижу, в мире UI/UX-дизайна сейчас как раз идёт именно такая тенденция. UX-дизайнеры отходят от статических макетов в сторону динамических. Вопрос только в том, что инструментов для разработки таких презентаций огромное количество и не факт, что дизайнер будет использовать именно QML. Но это уже организационный вопрос, так сказать.

Вот про это я и говорю. Называйте его как хотите: дизайнер со знанием QML или программист по интерфейсу с чувством прекрасного. Главное, что бы он занимал на себя деятельного заказчика и не отвлекал других программистов.