Здравствуйте, 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 было нормально. Библиотека развивается, так что м. б. и имеет смысл пробовать.
"8bit" <52686@users.rsdn.ru> wrote in message news:3250235@news.rsdn.ru... > Это называется слышал звон, да не знает где он.
Да, а даже если бы оно разрешало reverse engineering, разве это проблема? Или кто-то всерьез думает что строчка "this program shall not be decompiled, disassembled or otherwise reverse engineered" в EULA кого-то останавливают?
Здравствуйте, cencio, Вы писали:
C>под виндой QT очень приятная замена для MFC, гуи там фактически нейтив и качественный, но основной выигрыш в этом. софт ведь по-любому писать нужно, и использую кути можно получить, как бонус, еще и вполне пригодный для портирования проект (приктически без инвестиций в кросплатформеность) на не проект который на 80% нужно переписать, как в случае мфс.
Судя по тому, что мне тут сказали про визуальное редактирование, инвестиция в кроссплатформенность состоит в потере RAD в части GUI, то есть приходится платить временем до первой работоспособной версии.
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, cencio, Вы писали:
C>>под виндой QT очень приятная замена для MFC, гуи там фактически нейтив и качественный, но основной выигрыш в этом. софт ведь по-любому писать нужно, и использую кути можно получить, как бонус, еще и вполне пригодный для портирования проект (приктически без инвестиций в кросплатформеность) на не проект который на 80% нужно переписать, как в случае мфс.
S>Судя по тому, что мне тут сказали про визуальное редактирование, инвестиция в кроссплатформенность состоит в потере RAD в части GUI, то есть приходится платить временем до первой работоспособной версии.
инвестиция в кросплатформеность, это когда за комерческу. кути 4.4 платят 5к баксов или когда тратят +30% времени на создание кросплатформеной программы. а тут все это прямо из коробочки — развитый кросплатформеный фреймфорк, причем по юзабилити для пользователя под винтой не уступющий мфс програмкам. Относительно RAD — я не понял где он теряется, да и важен он только в проектах — наколбасим 850 формачек для нашего корпоративного заказчика.
Здравствуйте, cencio, Вы писали:
C> причем по юзабилити для пользователя под винтой не уступющий мфс програмкам.
Сорри за офтопик, но так и хочется спросить давно. Пытаюсь привыкнуть к Kvirk'у написанному на QT — в принципе нестандартные виджеты, не сильно отталкивают — но подсознательное ощущение некой кустарности, я бы даже сказал юниксовости присутвует (хотя там еще графика роль играет). Вопрос вот в чем — там есть эдит для ввода сообщения, так вот этот эдит не поддерживает не ctrl+ins (хотя понимает shift+ins), не ctrl+z — тупо рисует непечатанный символ. Сколько я уже текста потерял.. постоянно матерюсь (а многострочный эдит там вообще странный) — меня мучает вопрос это у разработчиков квирка руки кривые или это особенность самописного эдита QT ?
Здравствуйте, cencio, Вы писали:
S>>Судя по тому, что мне тут сказали про визуальное редактирование, инвестиция в кроссплатформенность состоит в потере RAD в части GUI, то есть приходится платить временем до первой работоспособной версии.
C>инвестиция в кросплатформеность, это когда за комерческу. кути 4.4 платят 5к баксов или когда тратят +30% времени на создание кросплатформеной программы.
5K баксов — это не так много, как кажется, если собираться продавать продукт. Особенно если можно их продавать больше одного.
C> а тут все это прямо из коробочки — развитый кросплатформеный фреймфорк, причем по юзабилити для пользователя под винтой не уступющий мфс програмкам. Относительно RAD — я не понял где он теряется, да и важен он только в проектах — наколбасим 850 формачек для нашего корпоративного заказчика.
Я так понял из описания, что мышкой возить не получается так, как в .NET или Delphi. Одно это — +10% к времени разработки из-за того, что начинает больше жаба душить сделать "прототип на выброс". +10% к времени разработки, скорее всего, дороже 5K баксов.
Здравствуйте, Begemot_, Вы писали:
B_>Сорри за офтопик, но так и хочется спросить давно. Пытаюсь привыкнуть к Kvirk'у написанному на QT — в принципе нестандартные виджеты, не сильно отталкивают — но подсознательное ощущение некой кустарности, я бы даже сказал юниксовости присутвует (хотя там еще графика роль играет). Вопрос вот в чем — там есть эдит для ввода сообщения, так вот этот эдит не поддерживает не ctrl+ins (хотя понимает shift+ins), не ctrl+z — тупо рисует непечатанный символ. Сколько я уже текста потерял.. постоянно матерюсь (а многострочный эдит там вообще странный) — меня мучает вопрос это у разработчиков квирка руки кривые или это особенность самописного эдита QT ?
Вот тебе кстати еще затраты на тестирование, чтобы обнаружить все такие косяки, а потом на кроссплатформенные исправления. Какой же это оффтопик
Тестировать-то придется под всеми платформами, даже если косяков не найдется
Здравствуйте, Begemot_, Вы писали:
C>> причем по юзабилити для пользователя под винтой не уступющий мфс програмкам.
B_>Сорри за офтопик, но так и хочется спросить давно. Пытаюсь привыкнуть к Kvirk'у написанному на QT — в принципе нестандартные виджеты, не сильно отталкивают — но подсознательное ощущение некой кустарности, я бы даже сказал юниксовости присутвует (хотя там еще графика роль играет). Вопрос вот в чем — там есть эдит для ввода сообщения, так вот этот эдит не поддерживает не ctrl+ins (хотя понимает shift+ins), не ctrl+z — тупо рисует непечатанный символ. Сколько я уже текста потерял.. постоянно матерюсь (а многострочный эдит там вообще странный) — меня мучает вопрос это у разработчиков квирка руки кривые или это особенность самописного эдита QT ?
Я после того, как пришлось несколько лет назад портировать продукты на Mac от QT плююсь. И не потому, что либа плохая, как раз наоборот — программировать приятно и удобно. Потому ее и выбрал ( ага, на безрыбье-то ) Но... Пользователи ее терпеть не могут. Точнее то, как при ее использовании выглядит продукт. А выглядит он нестандартно и работает тоже нестандартно. Мелочей подобных описанным выше навалом ! В итоге mac-пользователи мягко говоря разочаровываются. И высказывают это свое разочарование на форумах в духе "Ну не знаю... может где-то оно и нормально работает, но вот на mac это дерьмо дерьмом и пользоваться нормально невозможно". Ну нафиг мне такое счастье, я лучше GUI отдельно напишу, значительно дешевле выходит в итоге.
Кстати, почему-то широко распространено мнение, что Opera на QT написана. Так вот, нифига подобного! Точнее уже нифига подобного, они QT они отказались еще в 2003, бо как столкнулись с точно такими же проблемами.
Я где-то краем уха слышал что QT уже умеет использовать нативные контролы, но вроде подтверждения этого не нахожу. Если кто-то плотно работает с QT развейте сомнения.
И еще попутно вопрос, подходит ли QT для написания _маленьких быстрых_ утилит висящих в памяти все время работы, или там размер используемой памяти зашкаливает?
C>Я после того, как пришлось несколько лет назад портировать продукты на Mac от QT плююсь. И не потому, что либа плохая, как раз наоборот — программировать приятно и удобно. Потому ее и выбрал ( ага, на безрыбье-то ) Но... Пользователи ее терпеть не могут. Точнее то, как при ее использовании выглядит продукт. А выглядит он нестандартно и работает тоже нестандартно. Мелочей подобных описанным выше навалом ! В итоге mac-пользователи мягко говоря разочаровываются. И высказывают это свое разочарование на форумах в духе "Ну не знаю... может где-то оно и нормально работает, но вот на mac это дерьмо дерьмом и пользоваться нормально невозможно". Ну нафиг мне такое счастье, я лучше GUI отдельно напишу, значительно дешевле выходит в итоге.
Здравствуйте, Begemot_, Вы писали:
B_>Я где-то краем уха слышал что QT уже умеет использовать нативные контролы, но вроде подтверждения этого не нахожу. Если кто-то плотно работает с QT развейте сомнения.
Первый раз слышу. Единственный нативный контрол, которые я знаю в QT — это QMenuBar под маком. Еще QFileDialog на всех платформах, но это уже не котрол, а по сути обертка вокруг вызова одной функции. Во всех остальных случаях все эмулируется и отрисовывается вручную.
B_>И еще попутно вопрос, подходит ли QT для написания _маленьких быстрых_ утилит висящих в памяти все время работы, или там размер используемой памяти зашкаливает?
Да нет, с памятью и быстродействием все отлично. У меня претензии были только к поведению контролов.
! В итоге mac-пользователи мягко говоря разочаровываются. И высказывают это свое разочарование на форумах в духе "Ну не знаю... может где-то оно и нормально работает, но вот на mac это дерьмо дерьмом и пользоваться нормально невозможно". Ну нафиг мне такое счастье, я лучше GUI отдельно напишу, значительно дешевле выходит в итоге.
