Qt Creator 3.6.0

Плюс в Qt есть шаблоны (немного, местами, но есть), я вот затрудняюсь ответить, как к ним применять термины LGPL.

Во время нокии в лицензию добавили специальное исключение, специально для шаблонов. Я последнее время не следил, стоит проверить сохранили ли такое иссключение после нокии.

ThreadX, C++, CMake. Боюсь доооолго буду подобный опенсорсный проект искать :)

Ты знаешь, я не юрист. Обычно такие вопросы спихиваются на Legal Department - пусть мозг крутят. Гораздо проще иметь дело с BSD или MIT-подобными лицензиями и не заморачиваться с LGPL, т.к. дорожка скользкая: уменьшить размер дистрибуции за счёт статической линковки не удастся, непонятно с реверс инжинирингом, те же шаблоны (как выше упоминали - бывает дают исключения, а если в очередной версии исключения уберут?). Как результат, регулярно всплывает такое: http://www.qtcentre.org/archive/index.php/t-28342.html, да, там, вроде как, всё ок, но где гарантия, что юристы компании до чего-то не докопаются, если очень захочется?

К слову сказать, по подобному принципу мы используем LGPL версию Qt на одном проекте. Но там простая конфигурялка-обновлялка для устройства и что и как думает заказчик по поводу линцезирования... Ну это его заботы :) На другом проекте - запретили, но там Embedded и понятия динамической линковки для той платформы неприменимо.

Обычно такие вопросы спихиваются на Legal Department - пусть мозг крутят.

Потом бывают веселые повороты, когда при выпуске новой версии выясняется, что в Legal поменялись люди и теперь надо всё по другому:)

У нас сейчас для LGPL достаточно дин. линковки, а дальше воруй убивай.

Это единственная штука на онтопике, на которой можно комфортно писать на плюсах. С C тоже не замечал проблем. Пользую с Qt и без.

Потом бывают веселые повороты, когда при выпуске новой версии выясняется, что в Legal поменялись люди и теперь надо всё по другому:)

это да, это адъ :)

ну если есть «Legal Department» и они решили купить Qt, то пусть покупают - поддержат разработчиков материально, что тоже хорошо )

уменьшить размер дистрибуции за счёт статической линковки не удастся

И это хорошо. Поналинкуют тут, а ты живи потом.

Ну вот смотри, стоит у меня 32битная система 10 лет на работе(поставил когда устроился), мне теперь что, переставляться из-за этого что-ли? Система постоянно обновляется, тобишь актуальна на данный момент. Какая разница на какой системе писать код? Хоть на арме! Но вот такой геморой создали. Плюсом ко всему еще и в android sdk adb стал 64битным :(( Нафига!?

Я с вами согласен, но:

1. это нужно, когда у тебя embedded система с Linux на борту и Qt приложение одно единственное - обеспечивает интерфейс, но есть и куча другого кода, который обеспечивает основную логику. Фразу «память нынче дешёвая» пусть кричат недоумки, которые не считали экономию на больших партиях железа.
2. это сильно упрощает дистрибуцию «универсальных» бинарников для разных дистрибутивов Linux. Можно официально саппортить несколько «мейнстримовых» дистрибутивов, делать динамику там, но и не забывать про всяких «арчеводов» и «гентушников».

Ну это первое, что пришло в голову, с чем приходилось сталкиваться.

Собирай 32бит сам. Делов-то. Любое лишнее действите - это лишняя потребность в ресурсах, которые, так или иначе, стоят денег. Компания посчитала (ну, как минимум, подбила какую статистику, вы явно не в пике нормального распределения) и пришла к выводу - ей это нафиг нужно. При этом она никому ничем не обязана.

Даже так (я не знаю вашего дистрибутива): в случае Ubuntu и OpenSUSE можно воспользоваться сервисами типа Launchpad или OpenSuse Build Service, что бы греть чужие сервера, плюс делиться профитом с другими. Я так и поступил.

Второй пункт решается сборкой на мамонте чём-нибудь не очень новом. Debian stable, RHEL, что-нибудь такое.

Ну и можно просто либы рядом положить с бинарником и LD_LIBRARY_PATH.

Ну и можно просто либы рядом положить с бинарником и LD_LIBRARY_PATH.

ну вот скажи, а чем это лучше статической линковки?

1. пользуется только одно приложение
2. размер дистрибуции больше

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

LGPL не обязывает линковать динамически. Динамическая линковка — только один из способов исполнения предписаний LGPL.

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

Кстати проверил под виндой, поставил стандартным инсталлятором, собрано на Qt 5.5.1.

Внезапно - не работает. Вот это я понимаю кроссплатформенность.

Уточню: акселераторы внутри самих меню работают в любой раскладке, не работают alt- хоткеи для открытия самих менюшек.

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

А можно «steps to reproduce» как для тупых? Хочу у себя проверить.

http://clip2net.com/s/3sT4l3Z

Нажимаешь alt+A (в английской раскладке). Если меню «Файл» откроется - значит работает корректно. У меня работает только в русской раскладке, то есть если нажать Alt+Ф (та же клавиша)

В английской локали либо без локализации это меню имеет акселератор Alt+F (Alt+А русская) - обе работают

За воспроизводимость во всех дистрибутивах не ручаюсь - могли напатчить. В федоре вообще поступили хитро - там qt-creator идет без локализации.

В официальной сборке с сайта qt проблема лично у меня воспроизводится в любой ОС.

Спасибо, и правда поломано. Даже в kate (KF5) не работает.

федоре вообще поступили хитро - там qt-creator идет без локализации.

dnf install qt-creator-translations.noarch