Russian Qt Forum

Появился вот такой компонент-грид для Qt. Умеет сортировать без прокси-модели, группировать, создавать списки итогов, фиксировать колонки слева и справа. Грид коммерческий, но может линковаться с LGPL версией Qt.
ссылка - www.devmachines.com
Screenshot - (http://www.devmachines.com/images/qtableview.jpg)

Полный аналог гриду из DevExpress компонентов для делфи..

это, безусловно, самая лучшая реклама  :)

красивенько. хочу сорцы :)

Who-is на devmachines.com говорит, что доменное имя зарегистрировано в г. Люберцы. Если парни не сдуются - громадный им респект. Это то, "о чем так долго говорили большевики". Уже готов начинать выбивать бабки на лицензию.

Коллеги!
Подниму тему про грид и мультимедия компоненты Qtitan ибо есть повод.
Вторая бета грида и мультимедия компонентов для Qt.
Вот небольшая часть изменений, которые вошли в эту бету:
Для компонента грид
- исправили все ошибки, что прислали пользователи
- добавлена возможность вставлять Qt- виджеты в заголовки колонок грида
- в демо добавлен пример встраивания стандартного Qt-шного чарта в заголовок таблицы
- добавлена возможность вставлять в ячейки грида довольно сложные виджеты, например графическую схему
- возможность мультиселекта ячеек рубер-бандом или как обычно
Для компонента мультимедия
- Улучшена интеграция Flash в Qt приложения в Windows и Linux
- Поддержали Moonlight в Linux. Компонент знает в каких нестандартных местах Moonlight может быть установлен и подгружает его оттуда если найдёт.

Посмотреть можно тут  - http://www.devmachines.com/

И что, охотно покупают?

Уже есть несколько крупных клиентов.

Qt Ambassador - реально это дает что-нибудь?

А где цены-то на грид?

Пока ещё не ясно. Многое будет зависеть, от качества проекта и насколько он соответствует стратегии Nokia.

Ценник будет доступен для всех после релиза. Заявку можно оставить сейчас.

Не зная цены делать заявку как то странно...Хоть минимум / максиммум был бы известен...

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

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

"Чем больше заявок, тем меньше будет цена." - несогласен с таким подходом.

Цена - не только функция кол-ва заявок (а, вернее, заявок*к-во лицензий/рабочих мест в них), а и зависимость от рынка (конкурентов, спроса), усилий по продвижению и мн. др.

Как сделать заявку?

Пришлите письмо на license@devmachines.com с указанием платформы для которой планируется использовать, количества копий и что вы резидент СНГ. Можно на русском.
Ещё прошу, если это не сложно и не займёт много времени, написать какие другие компоненты могли быть вам полезны в первую очередь – грид (новые возможности которых сейчас нет), treeview, рибоны, темы для Qt, чарты и т.д. Эта информация будет использована для составления роад-мап на 2011 год.
P.S. Ещё хотел сказать, что я не всегда могу оперативно отвечать на письма, так как катастрофически не хватает времени, но тем не менее все письма анализируется и ведётся их учёт.

Проприетарщина, следовательно, не нужно. Тем более для средств разработки. Захочешь портировать программу на ещё одну платформу — а нельзя. Прекратит автор развитие программы — и всё, она пропала вместе с зависящими от неё приложениями. Тем более даже для архитектуры amd64 не удосужились собрать.

Можно же использовать схему двойного лицензирования (строгая копилефт-лицензия и проприетарная, но не влияющая на лицензию на производные работы), как раньше с Qt.

Не хочу разводиить holy wars, но целая куча контор, в т.ч. devexpress, componentone и иже с ними вполне себе не бедствуют именно с такой бизнес-моделью. Тем более, что исходники виджетов поставляются вместе с соответствующей конфигурацией - так что обвинения в проприетарности, прекращении развития и т.п. не совсем обоснованы. Хотя двойное лицензирование ДЛЯ МЕНЯ ЛИЧНО было-бы тоже полезным.

> Проприетарщина, следовательно, не нужно
где проприетарщина, где? давить её живо...

с такими заявлениями - марш на лор (либо на википукию за разъяснениями термина "проприетарщина").

Да меня в принципе в этих двух местах и научили делать такие заявления :D

Коллеги! Выпустили релиз грида - Qtitan DataGrid v1.0.
Из новшеств:
- исправление ошибок
- добавлен редактор ячейки ComboBox
- добавлен редактор ячейки Grid (в выпадающем окне показываются и редактируются табличные данные)
- Улучшен редактор ячейки позволяющий использовать стандартные делегаты в качестве редактора

Тем, кто интересовался ценами и этой темой вообще, добро пожаловать на сайт.
http://www.devmachines.com

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

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

>>А в чём собственно проблема?
странно, что это не очевидно для тебя.
"Контора "рога и копыта""@ Ильф и Петров

Контора "Рога и Копыта" это контора, которая занимается мошенничеством. Мы мошенничеством не занимаемся.

Дело не в мошенничестве, а в том, что:
а) контрол стоит денег
б) внедряется в разработку. Если что-то не так - убрать его - будет стоить хороших денег

юр. адрес - определенные гарантии.

Наилучшей гарантией в такой ситуации , с моей точки зрения, является наличие исходных кодов. А они предоставляются в полном объёме.

а коды вы предоставляете исессно после денех ;D

>>Мы мошенничеством не занимаемся.
никогда не слышал, чтобы мошенники предостерегали своих клиентов. Юр.адрес - дела ведёт фирма. Даже с ЧП никто связываться не станет.

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

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

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

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

Коллеги, вышла след. версия QtianDataGrid1.1. Релиз в основном направлен на исправление выявленных
ошибок. Из новшеств добавлен режим группировки ms – office. Переписан режим работы с relation моделями. Появилась возможность сохранить и загрузить из XML лайауат расположения колонок и бандов грида.
http://www.devmachines.com

Когда фильтрация и вложенные таблицы появятся ?

Фильтрация, со всеми диалогами, ориентировочно на февраль. Иерархические вью - март-апрель.

Фильтры будут как у DevExpress только на клиентской стороне работать?

А какие есть варианты? Что подразумевается под клиентской стороной?

У DevExpress вся фильтрация происходит только на клиентской машине, когда считываются ВСЕ данные с сервера и только часть из них (в соответствии с условиями фильтра) отображается. Для больших наборов данных это приводит как минимум к существенным тормозам и расходам памяти на клиенте (даже если условиям фильтра удовлетворяет только одна запись). Оптимальным видится преобразование условий фильтров (хотя-бы частично) в SQL выражения и, таким образом, фильтрация данных прямо на сервере. Иначе трудно бывает объяснять заказчику почему на отображении пары записей уходят все ресурсы довольно мощного компа (про тонкости реализации/смену парадигмы отображения записей он слышать не хочет). Кстати, то же самое касается и группировок. Неплохо было-бы иметь режим отображения, когда подчинённые записи запрашиваются с сервера только по мере необходимости - при раскрытии родительской.

Идея здравая, но пока не видно путей, как это можно красиво реализовать.
Грид привязывается к абстрактному QAbstractItemModel и перейти от неё к SQL достаточно проблематично. Приходится оперировать только теми методами, которые есть. Там нет ни какой зацепки, чтобы это сделать. Если у тебя есть схема, которая
позволяет реализовать то, что ты написал, пришли мне её на мыло, обсудим. Если она покажется интересной я добавлю её к реализации.

А может добавить флаг в грид SQL Data source и если он установлен то производить фильтрацию через модификацию SQL запросов (делая касты AbstractModel в SQLQueryModel), если не установлен то стандартным способом.

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

Я выходец из Delphi и как это можно было бы сделать на их DataSource примерно себе представляю. В MVC же от Qt я не чувствую себя достаточно уверенным, чтобы предлагать варианты подобных реализаций.

Напиши в термах дельфи, я пойму. Можно кратко, чтобы было несколько мнений.

Ну для начала разъясните мне, существует ли принципиальная проблема в автоматическом преобразовании "строки" фильтра в текст с синтаксисом SQL выражения "WHERE"? Если такой проблемы нет, то я бы в Delphi, например, в случае наследования DataSet от TQuery (можно проверять наличие и популярных других вариантов типа TAdoQuery, TFIBDataSet и т.п.), после формирования пользователем фильтра, преобразовывал бы его к SQL, заменял в исходном SQL тексте утверждение WHERE, запоминал текущую строку в гриде, переоткрывал запрос (ну или делал бы FullRefresh) и позиционировался на "правильную" запись.
Для группировок схема примерно такая же. Для каждой группировки формируется SQL кусок GROUP BY по полю группировки. При этом на OnExpand для узлов группировок вешаются процедуры догрузки данных из БД (c фильтром WHERE на поле группировки), а при первичном отображении грида загружаются только записи самого верхнего уровня. Остальные загрузятся сами по мере разворачивания полей группировок.
Из минусов решения вижу возможность наличия тормозов на сервере при большом объеме БД, если производится фильтрация/группировка по неиндексированному полю. Но в этом случае виноват будет не столько виджет, сколько программер/разработчик БД.

Если я правильно понял ребята пока пишут вьюв а не модель и этот вьюв не обязательно должен работать с SQL моделью. То есть источник данных может быть таким где SQL фильтрация с модификацией запросов вообще не при чем. Наверное это и является проблемой т.к. не хочется хардкодить в гриде завязку на SQL -ные модели.

Если не правильно понял поправьте...

Я тут проблем не вижу. Но по сути ты предложил то, что предлагал break постом выше. Захардкодить знания о специфичном SQL провайдере во вью. Это не кажется правильным.
Всё так.

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

Хотя лично я за использование кастомных прокси-моделей ибо фильтр подобного рода можно применить к любому представлению , фильтрацию данных в этом случае выполняет сам поставщик данных, что гораздо приятнее и избавляет от необходимости поддержки фильтрции в представлении.

В моем понимании в 90% случаев применения подобного виджета речь будет идти именно об SQL источниках. Те же DevExpress упоминают  об "unbound mode" (не SQL режиме) как об исключительном случае. МНЕ ЛИЧНО такой навороченный грид с фильтрацией и группировкой да ещё и за деньги (авторы же собираются на нём зарабатывать?) мог заинтересовать бы ИСКЛЮЧИТЕЛЬНО применительно к SQL. Существующий вариант и так требует несоизмеримо бОльшего объёма тупого ручного кодирования по сравнению с тем же DevExpress (как в Delphi, так и в .Net вариантах), поэтому любое дополнительное возлагание на пользователя однотипных механических задач, как мне кажется, бонусов авторам не принесут.

И что если даже так, надо хардкодить неправильные вещи нарушая тем самым саму парадигму модель - вьев ? И забить на 10% остальных случаев?

А это глупости - вам никто не запрещает 1 раз написать и оформить как класс или процедуру код модифицирующий SQL запрос, который будет вешаться на сигнал от грида. Конечно соответствующие утилиты могут создать и разработчики вьюва, но на мой взгляд все это не сложно и вполне можно сделать самому 1 раз и потом много раз использовать - вы ведь не считаете сложностью устанавливать на каждый экземпляр грида коннект к слоту с обработкой фильтра?

Вариант реализации с сигналом или без него одинаковы плохи. Так-как подразумевают
модификацию модели, подключенной к гриду. К этой модели могут быть подключены другие гриды или чарты. В результате установка фильтра приведёт к изменению в всех вью. Это не приемлемо.

Речь идёт не об этом, а о том, что разработчик коммерческого виджета может и должен максимально упростить жизнь большинству своих клиентов. Как он это сделает - выпустит 2 наследника одного виджета (для SQL источника и нет) или как-нибудь по-другому - это его выбор, но загрузка ВСЕГО SQL набора данных на клиент только для того, чтобы потом в результате фильтрации вывести одну (!!!) строку - это абсолютное зло.

Глупости - это заплатить 599$ за виджет и потом его допиливать напильником. Коммерческие библиотеки мною приобретаются не потому, что я сам не могу повторить их функционал, а прежде всего потому, что у меня нет времени на его реализацию.

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

Почему? На мой взгляд вполне логичное поведение.
Кстати, QtitanDataGrid1.1_vs2008_demo.zip на сайте похоже битый. Качал три раза - всё время "неожиданный конец архива".

По той причине, что в одном вью хочется фильтровать по дате, а в другом по сумме.

С трудом представляю себе такую ситуацию, чтобы на экране было одновременно несколько разных вью от одной модели с разными наборами фильтров. Что мешает при таких желаниях к двум разным вью прицепить две разных модели?

Тогда встаёт вопрос синхронизации между двумя этими моделями. В одну добавил нужно, чтобы в другую тоже.

Странно. Только что проверил, всё хорошо. Может в кеше застрял?
Попробуй по прямой ссылке - http://www.devmachines.com/downloads/QtitanDataGrid1.1_vs2008_demo.zip

По прямой скачивается нормально. По "кривым" недокачивается - причем, каждый раз одинаково.

Ну так ведь опять же при работе с БД вопрос синхронизации стоит постоянно и бесконечно: а если другой пользователь, на другом компе, с другой программы изменил запись? Для борьбы с этим как минимум кнопку refresh придумали, а уж события об изменении данных реализованы не только на уровне модели, но и даже до некоторых СУБД добрались. Что уж тут разработчик сам свои собственные модели не синхронизирует?

Я понимаю, что технически это решается. Я имел ввиду, что придётся делать два раз рефрешь с двумя моделями.
С одной моделью только один. У тебя будет два серверных вызова.

Пусть будет столько вызовов, сколько нужно - сервер на то и сервер, чтобы у него регулярно что-нибудь спрашивали. Во-первых, тут уже я сам буду контролировать необходимость обновлений и проектировать GUI клиента с учетом этих моментов. Главное, же что в случае реализации фильтрации на сервере (к каким бы тонкостям это не приводило при реализации клиента) я имею возможность строить реально тонкий клиент, а не монстроподобное приложение с диким потреблением памяти. Впрочем, тут уж разработчику самому решать на какой рынок он позиционирует свой продукт - клиент/серверных или десктопных приложений. Я бы на его месте постарался откусить и там и там.

Коллеги, выпустили очередную версию QtitanDataGrid. В этой версии выполнена поддержка Mac OS X. Кроме этого
реализован необычный эффект, который позволяет скролировать очень большие таблицы с данными без задержек.
Оценочная версия доступна на сайте http://www.devmachines.com

Коллеги, выпущен релиз QtitanDataGrid 2.0. Фокус релиза поддержка фильтрации строк. Кроме того улучшено API для создания произвольных редакторов ячеек на базе любого виджета.
Подробнее www.devmachines.com

Коллеги! Вышел очередной апдейт грида - QtitanDataGrid 2.2. В текущей версии исправлены найденные ошибки и реализован механизм Drag & Drop.
http://www.devmachines.com/products/qtitandatagrid-overview.html

какие ограничения у демо-версии ?

Работает 30 дней. Перед выгрузкой выводит окно с сообщением.
Других ограничений нет.

Коллеги, выпустили новую версию грида для Qt. В релизе исправлены известные ошибки. Реализован механизм зуминга. Теперь можно увеличивать/уменьшать размер ячеек грида, колонок, строк, фонтов горячими клавишами и колёсиком мышки как в Excel.
http://www.devmachines.com/products/qtitandatagrid-overview.html

Выпущены следующая версия грида для Qt — QtitanDataGrid 2.5.

В обновлённом QtitanDataGrid появилась поддержка системы печати и поддержка Windsows Air.
Скриншоты:
(http://www.devmachines.com/images/datagrid/grid_print_release.png)
(http://www.devmachines.com/images/datagrid/grid_air_release.png)

Кроме прочего в QtitanDataGrid добавлена возможность добавлять кнопки у ячеек без дополнительной нагрузки на редактор ячейки. Кнопки могут быть всегда видимыми на экране или появляться, когда пользователь наводит мышку на ячейку или у ячейки появляется фокусе.
 http://www.devmachines.com

Коллеги, очередная версия компонента для Qt - QtitanDataGrid была выпущена. В этой версии исправлены все выявленные ошибки. Добавлены методы setMaxWidth(), setMinWidth() у колонки, чтобы можно было контролировать эти параметры при растяжении.
Добавлена возможность перехватить события добавления новой строки, чтобы выполнить свои действия и в случае надобности заблокировать начало добавления строки. Добавлены переводы на Немецкий, Французский и Русский. Зарефакторены несколько важных внутренних механизмов и как результат очень стабильная работа.

http://www.devmachines.com

Народ, а кто-нибудь тут имеет опыт его практического использования? По демо выглядит вполне юзабельно, с самого начала появления этого компонента присматриваюсь к нему, но никак не решусь продавить покупку лицензии. Сейчас, вроде бы и надо, а жаба душит. Всё ещё используем иногда аналоги от DevExpress для Delphi, но там очень навороченные возможности по кастомизации в дизайн-тайм, тут же насколько я понял из демо-версии, можно просто разместить пустой грид на форме и на этом всё.

И что ж мы такие классные и 32-х битные.... или я для 64-х бит не нашел демухи.
Да и $519.00 - мелко, уже просили бы лимон зеленых ......

Это же демо. Или ты решил демо версию в свой продакшен запихать?

Справедливости ради - DevExpress GridPack 999,99$, с другой стороны TMS Grid Pack - 120 EUR. В целом, "порог вхождения", действительно, высоковат. Да и комьюнити не очень активно - последний пост на форуме QtitanGrid на их сайте отмечен более 4 недель назад. В общем, есть возможность приобрести за текущую цену, но не хочется брать "кота в мешке". Идеальным для нас было бы нечто, вроде trial - полнофункциональная версия с исходниками на ограниченное время.

По поводу Демо и продакшена:
Нет хотел посмотреть на 64x linux. О продакшене и демо-версии - такое подумать....
Причем не видя исходного кода... Берд

О цене:
QT professional целиком стоит $399.00. А мы тут нарисовали компоненту и толкаем ее, почти, в полтора раза дороже всей библиотеки.
На такие вещи надо менять лицензирование. Есть лицензия - закрывай исходник результирующего продукта, нет (free edition) - добро пожаловать в OpenSource....

Хорошее слово "Берд" :)

Не знаю, что такое "QT Professional", но если речь идёт о "Qt Professional Subscription", то её стоимость для Windows Desktop на одного разработчика составляет прямо сейчас 249$ в месяц (https://www.qt.io/buy-product/?pid=7200&qty=1&currency=usd&mode= (https://www.qt.io/buy-product/?pid=7200&qty=1&currency=usd&mode=)).

И что тут удивительного? Компоненту не "нарисовали", а сделали достаточно большую и сложную, справедливости ради, работу. По адекватности/неадекватности ценообразования/лицензирования я уже писал, повторяться не буду.

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