Здравствуйте, 8bit, Вы писали:
8>Рано обрадовались-то, будет под lgpl, но не раньше марта 2009 года, с приходом QT 4.5
ага, но к марту(если релиз не перенесут) как раз можно будет что-то на ее основе сделать и выложить сразу после выхода 4.5
имхо, это должно быть что-то несложное в реализации, широко используещее гуи, нужное простым юзерам, вообщем попса, пока в идеях:
1. blogging software reader + posting (wordpess, blogger, livejornal )
2. video service(youtube & Co) uploader/downloader
3. поиск дубликатов файлов, структуризация информации на винчестерах (если никому нужно не будет, то хотябы свалку на своем винте приведу в порядок)
аналогичного софта просто тучи(как и любого другого, не сложного в реализации), но интересно попробовать сделать версии для мака и винды на основе общей базы исходников. И посмотреть как оно выплывен/утонет в море аналогичного софта
Но статически линковать не получится — только динамически:
Your application must be “re-linkable” against a modified version of the Library. In practical terms this means the application must dynamically link with the Library. If you statically link you are required to provide the object modules to your application and any re-linking tools needed to enable substitution of a modified Library3. Since most applications use dynamic linking, your application is probably already compliant with this requirement.
Вряд ли. Нокия просто живет не с продаж Qt. Они явно купили Qt потому, что она им самим нужна в качестве платформы, а не библиотеки на продажу, и не имеют ничего против того, чтобы поделиться с окружающим миром.
Здравствуйте, cencio, Вы писали:
C>ага, но к марту(если релиз не перенесут) как раз можно будет что-то на ее основе сделать и выложить сразу после выхода 4.5 C>имхо, это должно быть что-то несложное в реализации, широко используещее гуи
Я что-то подозреваю, что QT против нативного GUI выигрыша не дает.
C>аналогичного софта просто тучи(как и любого другого, не сложного в реализации), но интересно попробовать сделать версии для мака и винды на основе общей базы исходников. И посмотреть как оно выплывен/утонет в море аналогичного софта
Да аналогично выплывает или утонет. Я из плюсов общих исходников (при широком использовании GUI) вижу экономию на кодеже раза в полтора, и на тестировании может быть удастся выиграть что-нибудь (а скорее всего нет). Как-то маловато, мне представляется. Если прикинуть, что кодёж — порядка четверти от объема работ, то суммарно экономия скока? процентов десять? Не вижу особо причин прыгать от радости, по правде сказать.
S>Да аналогично выплывает или утонет. Я из плюсов общих исходников (при широком использовании GUI) вижу экономию на кодеже раза в полтора, и на тестировании может быть удастся выиграть что-нибудь (а скорее всего нет). Как-то маловато, мне представляется. Если прикинуть, что кодёж — порядка четверти от объема работ, то суммарно экономия скока? процентов десять? Не вижу особо причин прыгать от радости, по правде сказать.
под маком есть нюансы: например, С-interface Carbon отсутствует в Леопарде-64 и вполне может исчезнуть совсем в следующей версии (даже в 32 битах). Переписывать на Objective-C Cocoa -- удовольствие отдельное, из-за этой "мелкой" проблемы Adobe Photoshop 64bit существует только под виндой.
Qt же берет это на себя (по крайней мере, бета для Cocoa у них уже есть)
S>Да аналогично выплывает или утонет. Я из плюсов общих исходников (при широком использовании GUI) вижу экономию на кодеже раза в полтора, и на тестировании может быть удастся выиграть что-нибудь (а скорее всего нет). Как-то маловато, мне представляется. Если прикинуть, что кодёж — порядка четверти от объема работ, то суммарно экономия скока? процентов десять? Не вижу особо причин прыгать от радости, по правде сказать.
Да нет тут совсем другое, так ты кодишь себе под винду, а потом когда все ок и оно продается, берешь и с "минимальными" затратами портируешь на другие оси, и потом паралельно поддерживаешь (по крайней мере в теории так). А если пишешь на чем то не кроссплатформенном то надо полностью начинать с нуля, вернее начинать с того что учится программить под другую ос. Многие ли шароваршики портировали софт под мак, хотя бы успешные проекты?
А если работа по портированию — поставил мак в вмваре, попытался собрать — почти собралось, то можно уже всерьез думать про портирование — психологически легче
Здравствуйте, Sharowarsheg, Вы писали:
S>Я что-то подозреваю, что QT против нативного GUI выигрыша не дает.
C>>аналогичного софта просто тучи(как и любого другого, не сложного в реализации), но интересно попробовать сделать версии для мака и винды на основе общей базы исходников. И посмотреть как оно выплывен/утонет в море аналогичного софта
S>Да аналогично выплывает или утонет. Я из плюсов общих исходников (при широком использовании GUI) вижу экономию на кодеже раза в полтора, и на тестировании может быть удастся выиграть что-нибудь (а скорее всего нет). Как-то маловато, мне представляется. Если прикинуть, что кодёж — порядка четверти от объема работ, то суммарно экономия скока? процентов десять? Не вижу особо причин прыгать от радости, по правде сказать.
Именно, зависит от проекта сколько там того GUI. Сколько занимаюсь софтостроением — все "фишки", из-за которых продукт имеет стоимость, на GUI не завязаны вообще, либо жестко привязаны к особенностям платформы. И чтобы портировать такие продукты например под Mac, по-любому надо переписывать часть "тяжелой" базовой логики с нуля. Гуй переделать под любую нативную библиотеку не так уж сложно по сравнению с этой задачей.
Здравствуйте, Begemot_, Вы писали:
B_>Да нет тут совсем другое, так ты кодишь себе под винду, а потом когда все ок и оно продается, берешь и с "минимальными"
Представь себе лучше обычный варинат — накодили кроссплатформенную софтину, "подготовленную к портированию с минимальными затратами", а она не продается. В результате затраты на обеспечение портируемости, какие бы они ни были, выброшены на ветер.
B_> затратами портируешь на другие оси, и потом паралельно поддерживаешь (по крайней мере в теории так). А если пишешь на чем то не кроссплатформенном то надо полностью начинать с нуля, вернее начинать с того что учится программить под другую ос.
Тестировать тебе всё равно придется начинать учиться на другой оси. И маркетить тоже придется заметно другой аудитории. По сравнению с этим научиться кодить на другой оси — очень дешево.
B_> Многие ли шароваршики портировали софт под мак, хотя бы успешные проекты?
Нет, я думаю. А ты думаешь, они много денег потеряли на этом?
Здравствуйте, K13, Вы писали:
K13>Qt же берет это на себя (по крайней мере, бета для Cocoa у них уже есть)
А кстати у QT визуальное редактирование формочек (как типа в Delphi или в .NET) под виндой можно получить? Ну то есть чтобы мышой кнопок накидал на форму, кликнул и пиши обработчики?
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, cencio, Вы писали:
C>>ага, но к марту(если релиз не перенесут) как раз можно будет что-то на ее основе сделать и выложить сразу после выхода 4.5 C>>имхо, это должно быть что-то несложное в реализации, широко используещее гуи
S>Я что-то подозреваю, что QT против нативного GUI выигрыша не дает.
чем такой гуй не нравиться?
из известных продуктов он используется в Google Earth, VLC media player и Adobe Elements.
под виндой QT очень приятная замена для MFC, гуи там фактически нейтив и качественный, но основной выигрыш в этом. софт ведь по-любому писать нужно, и использую кути можно получить, как бонус, еще и вполне пригодный для портирования проект (приктически без инвестиций в кросплатформеность) на не проект который на 80% нужно переписать, как в случае мфс.
S>А кстати у QT визуальное редактирование формочек (как типа в Delphi или в .NET) под виндой можно получить? Ну то есть чтобы мышой кнопок накидал на форму, кликнул и пиши обработчики?
Qt Designer
но вот "кликнуть и писать обработчик" -- с этим сложнее.
Есть qt Visual Integration, если формочки редактировать их примочкой к студии а не внешним qt Designer то что-то подобное работает.
Я больше по старинке: ручками пишу обработчики.
Еще нужно не забывать, что при создании "формочки" вызывается вот такая штука:
Searches recursively for all child objects of the given object, and connects matching signals from them to slots of object that follow the following form:
Let's assume our object has a child object of type QPushButton with the object name button1. The slot to catch the button's clicked() signal would be: void on_button1_clicked();
Здравствуйте, Sharowarsheg, Вы писали: S>А кстати у QT визуальное редактирование формочек (как типа в Delphi или в .NET) под виндой можно получить? Ну то есть чтобы мышой кнопок накидал на форму, кликнул и пиши обработчики?
С библиотекой идет GUI Designer и вроде можно прикрутить саму Qt к студии здесь
Года три назад это все использовал под Linux с KDevelop было нормально. Библиотека развивается, так что м. б. и имеет смысл пробовать.