План развития Qt

> Бугогагага, причина звучит совершенно феерически :) Особенно с учётом того, что передрали они это всё из BSD =)

вообще-то, AFAIU BSD layer был натянут на нативный WSA API. для тех, кому очень хочется.

// wbr

>> То есть всё же нельзя работать с сокетом так же, как и с файлом? Что и требовалось доказать.

> все-таки незнание MSDN не избавляет от ответственности...

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

Анонимус вот сказал, что файловое и сокетное апи различны.

> Я в этих буковках не разбираюсь и этих страшных типов данных не знаю. Скажите коротко, там можно писать в пайп, сокет и файл одной функцией, желательно названной write() ?

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

// wbr

>WebKit - слияние вебтехнологий и настольных приложений (поддержка в JS слотов/сигналов, расширение DOM дерева под эти 'настольные приложения')

Это как?

>> Я в этих буковках не разбираюсь и этих страшных типов данных не знаю. Скажите коротко, там можно писать в пайп, сокет и файл одной функцией, желательно названной write() ?

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

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

Но объясните мне, ничтожному, кто прав: анонимус, вещавщий про различие в API или Вы, ткнувшие мне носом в MSDN?

> Я в норвежском не силён, но в переводе книги Бланшета и Саммерфилда именно Эттрич.

!@$%@#^!!!

Он НЕМЕЦ! Понимаете? Немец. Не англичанин, не норвежец. Маттиас Эттрих. Или Эттрихь, если уж очень хочется, чтобы читающий совсем правильно произносил мягкую "х".

>>WebKit - слияние вебтехнологий и настольных приложений (поддержка в JS слотов/сигналов, расширение DOM дерева под эти 'настольные приложения')

>Это как?

Под апач будет mod_c++ или mod_qt так? ;)

> Ви таки случайно не оголтелый фанатик проприетарщины? А то LGPL что даётся на GTK+ (замечу, "+", а то какие-то совсем странные ассоциации возникают) не вызывает абсолютно никаких проблем, в отличие от.

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

Ну а если я не собираюсь зарабатывать денег на продукте, и код закрывать не буду - GPL к вашим услугам. Троллтеки не против.

А вот кривая архитектура и неудобство в использовании - это действительно серьезно.

> Но объясните мне, ничтожному, кто прав: анонимус, вещавщий про различие в API или Вы, ткнувшие мне носом в MSDN?

hm.. по всей видимости MSDN? аргументы против приветствуются.

// wbr

> Под апач будет mod_c++ или mod_qt так? ;)

скорее, в Qt появится плагин apache ;)

// wbr

>В 4.3.1 подумали. Она совместима для использования в GPLv3-проектах, около месяца назад была такая новость на ЛОРе.

А можно прямую ссылку вроде этих

http://trolltech.com/products/qt/licenses/licensing/opensource

http://trolltech.com/products/qt/gplexception

или адрес дилера

> кыш в постель! время уже позднее завтра на стройку рано вставать.

Совсем плохо с головой?

>В 4.3.1 подумали. Она совместима для использования в GPLv3-проектах, около месяца назад была такая новость на ЛОРе.

> А можно прямую ссылку вроде этих <skipped /> или адрес дилера

Вот мой ньюсдилер :) http://www.linux.org.ru/jump-message.jsp?msgid=2077346

>Ээээ, не узнал в гриме, что это за вещь?

это completion ports. пардон за описку. асинхронный i/o, причем не только в файл.

Проблема в том, что QT - ОЧЕНЬ дорогая. Моей начинающей компании из 5 человек придется потратить примерно $10000 только на лицензию. Причем еще ее и обновлять надо.

Одинокому девелоперу надо будет потратить что-то около $3000 на лицензию. Да, и с каждым релизом лицензия на QT становится все дороже.

Так что имеем тот же vendor lock-in, что и с Microsoft. Но Microsoft хотя бы не просит СТОЛЬКО денег за базовые инструменты разработки.

>> Но объясните мне, ничтожному, кто прав: анонимус, вещавщий про различие в API или Вы, ткнувшие мне носом в MSDN?

> hm.. по всей видимости MSDN? аргументы против приветствуются.

Вот тут я нашёл строчки, которые с MSDN немного не вяжутся: http://en.wikibooks.org/wiki/Windows_Programming/Winsock

Sockets as Handles

It has been said that unlike UNIX, Win32 does not allow sockets to be read/written using the file I/O functions. This is only partially true. Sockets may not be accessed using the standard-library functions such as fread, fwrite, fprintf, etc. However, if we cast our SOCKET structures to HANDLE structures, we can use the Win32 File I/O API to interface with the sockets. For instance, we can now use ReadFile and WriteFile to write to sockets, and any routines that we have written around these APIs can be used when writing to the network.

Under Win32, do not attempt to cast a SOCKET to a FILE type, and use the stdio.h file functions. This will result in some sort of error (most likely a bad error).

-------

То есть тут написано, что не стоит смешивать файловые и сокетные операции. Ы?

> Проблема в том, что QT - ОЧЕНЬ дорогая. Моей начинающей компании из 5 человек придется потратить примерно $10000 только на лицензию. Причем еще ее и обновлять надо.

hm... на эти деньги можно купить разве что дюже поюзанную машинку...

> Одинокому девелоперу надо будет потратить что-то около $3000 на лицензию. Да, и с каждым релизом лицензия на QT становится все дороже.

...или неплохой игровой контупер...

> Так что имеем тот же vendor lock-in, что и с Microsoft. Но Microsoft хотя бы не просит СТОЛЬКО денег за базовые инструменты разработки.

вы помните, сколько стоит MSDN? да да, это те две сумочки полностью набитые компакт-дисками... ;)

// wbr

>Вот мой ньюсдилер :) http://www.linux.org.ru/jump-message.jsp?msgid=2077346

я же сказал что нужен именно дилер иначе, а то я лично про GPL 3 ничего там не вижу.

>> Вот мой ньюсдилер :) http://www.linux.org.ru/jump-message.jsp?msgid=2077346

> я же сказал что нужен именно дилер иначе, а то я лично про GPL 3 ничего там не вижу.

Пардон, ошибся, приняв желаемое за действительное. Адрес дилера: Нижегородская область, Борский район, деревня Большое Пикино. Ну а там спросите :)

>Проблема в том, что QT - ОЧЕНЬ дорогая. Моей начинающей компании из 5 человек придется потратить примерно $10000 только на лицензию. Причем еще ее и обновлять надо. Одинокому девелоперу надо будет потратить что-то около $3000 на лицензию. Да, и с каждым релизом лицензия на QT становится все дороже.

3.14здеть не надо! Вот вам начинающим скидка: ~ 65% скидывают: http://trolltech.com/products/qt/licenses/licensing/smallbusiness http://trolltech.com/pdf/SmallBusinessProgramDescription.pdf

С учетом скорости и качества разработки в конечном итоге получается не так уж и дорого. С учетом скидки в 75% для стартапов - почти бесплатно.

>> Ээээ, не узнал в гриме, что это за вещь?

> это completion ports. пардон за описку. асинхронный i/o, причем не только в файл.

А что оно умеет из того, что в UNIX делается хуже? Тупо интересно.

Поверьте, $10000 для стартапа - это очень много. У меня меньше денег ушло на покупку компьютеров, мебели и аренду помещения на несколько месяцев.

>вы помните, сколько стоит MSDN? да да, это те две сумочки полностью набитые компакт-дисками... ;)
Максимальная подписка (Universal) - тоже что-то около $10000, вот только _максимальная_ подписка не особо-то и нужна. Лицензии на MSVS2005 на эти 5 компьютеров, с MS Office+Win XP стоили мне что-то около $2500.

Причем в случае MS еще можно и обойтись бесплатной MS VS Express на первое время. Или всякими SharpDevelop'ами - оно вообще OpenSource.

Вообще, у меня из альтернатив есть GTK (на Винде выглядит уродливо), wxWidgets - кривоватый. Ну и все, в общем. Больше нормальных вариантов нет (всякие Fox Toolkit - даже не вспоминаю).

Есть еще Java - но отдельный разговор.

>3.14здеть не надо! Вот вам начинающим скидка: ~ 65% скидывают: http://trolltech.com/products/qt/licenses/licensing/smallbusiness http://trolltech.com/pdf/SmallBusinessProgramDescription.pdf

Читать учимся: "of up to three Qt licenses". У меня пять разработчиков (ну и еще я шестой).

Я разговаривал с маркетингом у Trolltech - они предлагали максимум 10% скидку, что совсем несерьезно.

> С учетом скорости и качества разработки в конечном итоге получается не так уж и дорого.

Я не ослышался, КАЧЕСТВА? Вы сами-то этот MSDN читали? Куча примеров, не применимых ни к чему и отсутствие какой-либо логической структуры: просто сваленные в одну кучу статьи.

Qt Assistant, содержит много меньше инфы, но полезность у него гораздо выше.

>Извините, сэр, но как всякий правильный гентушник я не могу позволить себе использовать нестабильный софт ;)

Сыр прославленный г^W Гентушнег не осилил man portage, на предмет package.keywords и package.unmask? ;)

> То есть тут написано, что не стоит смешивать файловые и сокетные операции. Ы?

> Sockets may not be accessed using the standard-library functions such as fread, fwrite, fprintf, etc.

верно

> However, if we cast our SOCKET structures to HANDLE structures, we can use the Win32 File I/O API to interface with the sockets.

то-же верно.

> For instance, we can now use ReadFile and WriteFile to write to sockets, and any routines that we have written around these APIs can be used when writing to the network.

о чем и речь: операции с хэндлами однородны будь то регулярный файл, пайп, сокет или кто-то другой. и их так-же можно читать и писать используя generic Win32 API функции.

ну а то, что файловые дескрипторы из *NIX API не работают с Win32 API - ну что тут попишешь. не работают. ну и что? они и с нативным асинхронным Win32 IO не работают и с ожиданием события на наборе объектов то-же не работают и тд и тп.

API изначально был разный и присутствие read/write в RTL - скорее минимальный и очень куцый portability layer которым все равно IMHO никто не пользуется. так, для галочки.

// wbr

>>Under Win32, do not attempt to cast a SOCKET to a FILE type, and use the stdio.h file functions. This will result in some sort of error (most likely a bad error).

>То есть тут написано, что не стоит смешивать файловые и сокетные операции. Ы?

Идентификатор полученный от connect() или accept() (int) можно скастовать к типу HANDLE (указатель на незавершенный тип, тоже 32 бита) и использовать в Win32 API вызовах типа ReadFile & WriteFile. Но <stdio.h> работает на Win32 отдельно от POSIX, так что SOCKET к FILE скастовать действительно не получится. Возможно, MS LIBC из MSVC++ можно поменять на что-либо более другое.

>Я разговаривал с маркетингом у Trolltech - они предлагали максимум 10% скидку, что совсем несерьезно.

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

> о чем и речь: операции с хэндлами однородны будь то регулярный файл, пайп, сокет или кто-то другой. и их так-же можно читать и писать используя generic Win32 API функции.

Я вот _хочу_ пользовать именно open()/read()/write()/close(), а не писать для каждой системы свой #ifdef, в котором расписывать отдельно для win32 и *nix.

> ну а то, что файловые дескрипторы из *NIX API не работают с Win32 API - ну что тут попишешь. не работают. ну и что? они и с нативным асинхронным Win32 IO не работают и с ожиданием события на наборе объектов то-же не работают и тд и тп.

> API изначально был разный и присутствие read/write в RTL - скорее минимальный и очень куцый portability layer которым все равно IMHO никто не пользуется. так, для галочки.

А этот куцый portability layer случайно не POSIX-ом называется?

>Блин, вот проблемы у людей надуманные: начинаешь разработку под OpenSource версией, показываешь заказчику готовое, он тебе платит - покупаешь коммерческую версию, собираешь и порядок! :)

Во-первых, это не разрешено _коммерческой_ лицензией на QT (у них в FAQ такой вопрос был).
Во-вторых, мы производим коробочный продукт, так что этот вариант не подходит.

Да, полностью под лицензией GPL мы выпустить продукт тоже не можем - конкуренты съедят и не подавятся.

В общем, QT - мастдай! :)

> Я вот _хочу_ пользовать именно open()/read()/write()/close(), а не писать для каждой системы свой #ifdef, в котором расписывать отдельно для win32 и *nix.

так просто у вас этого не получится.

> А этот куцый portability layer случайно не POSIX-ом называется?

нет, не POSIX.

POSIX - это http://www.opengroup.org/onlinepubs/009695399/toc.htm
Win32 API - это совершенно другое. и не нужно их смешивать.

ps: с таким же успехом можно удивляться невозможности работать напрямую с дисками посредством старого доброго int13 в Linux. DOS - это DOS, Win32 - это Win32, а Linux - это Linux.

// wbr

>> Блин, вот проблемы у людей надуманные: начинаешь разработку под OpenSource версией, показываешь заказчику готовое, он тебе платит - покупаешь коммерческую версию, собираешь и порядок! :)

> Во-первых, это не разрешено _коммерческой_ лицензией на QT (у них в FAQ такой вопрос был). Во-вторых, мы производим коробочный продукт, так что этот вариант не подходит.

У них ещё есть evaluation лицензии. А на рекламу своего коробочного софта, рабочее место, компутер, электричество и т.д. вы явно больше потратите, чем на пару лицензий.

>Во-первых, это не разрешено _коммерческой_ лицензией на QT (у них в FAQ такой вопрос был).

А ты им обязательно расскажешь, что разрабатывал под OpenSource версией?! Не смешите мои тапки! :) Купил, они бабло получили, собрал и спи спокойно. "Лицензия НЕ РАЗРЕШАЕТ" - смех, ты человек или раб?! Слушаешь себя или подчиняешься лицензиям?!

Нельзя так.

11. Можно ли использовать Open Source Edition для разработки не-opensource приложения, а потом приобрести коммерческую лицензию, когда мы начнём продавать приложение?

Нет. Наши Соглашения о Коммерческом лицензировании применимы только к програмному обеспечению, которое было разработано с помощью Qt под Соглашением о коммерческой лицензировании. Соглашение не применымы к коду, который был разработан с помощью Qt Open Source Edition до заключения соглашения. Любое програмное обеспечение, разработанное с помощью Qt без Соглашения о Коммерческом Лицензировании должно быть выпущено как "открытое ПО".

>> Я вот _хочу_ пользовать именно open()/read()/write()/close(), а не писать для каждой системы свой #ifdef, в котором расписывать отдельно для win32 и *nix.

> так просто у вас этого не получится.

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

>> А этот куцый portability layer случайно не POSIX-ом называется?

> нет, не POSIX. POSIX - это http://www.opengroup.org/onlinepubs/009695399/toc.htm

Я нашёл по ссылке функции для работы с сокетами. А виндовс, насколько помню, имеет статус POSIX-совместимой, так что я имею право пользоваться посиксными функциями и надеяться, что они сработают.

> Так что имеем тот же vendor lock-in, что и с Microsoft. Но Microsoft хотя бы не просит СТОЛЬКО денег за базовые инструменты разработки.

А если подумать головой и сделать по-нормальному? Почему под GPL нельзя?

2 turist_ua & AP
>Эттрих
Таки да ... немец (wiki). Следовательно - Эттрих.
В книжонке по Qt был Эттрич, я поэтому и не заморачивался.

2 krum
>Зачем так новость корёжить?
Это не шаман, а я. А фигли?
Поддержка Phonon-a в Qt, что не так?

> слова TrueType и OpenType Вам что-нибудь говорят? :)
2 AP
Говорящие слова? :-)
Угу.
Только с отображением шрифтов и щас проблем немало, если ничего не патчить.
А какие проблемы возникнут у троллей, я даже боюсь предполагать.
всё это ИМХО, "могу быть неправ, часто" (с)

> Так что имеем тот же vendor lock-in, что и с Microsoft. Но Microsoft хотя бы не просит СТОЛЬКО денег за базовые инструменты разработки.

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

>anonymous (*) (09.10.2007 16:48:51)

Пардон, ошибся, действительно 65%. Хотя ты видимо, разговаривал не с тем маркетологом. Мне сразу сбросили 65% и еще одаривали маечками, чтобы я купил лицензию. Так что не пиздеж, а умение вести переговоры.

> Он НЕМЕЦ! Понимаете? Немец. Маттиас Эттрих

Entschuldigen Sie, bitte! Почему-то думал, что он норвежец.

> А если подумать головой и сделать по-нормальному? Почему под GPL нельзя?

Потому, что моя компания конкурирует с компаниями с сотнями разработчиков. Они могут просто взять версию под GPL и улучшить ее, сами продавая поддержку. Я с ними конкурировать по качеству поддержки просто не смогу - ну нет у меня штата индусов, бодро говорящих на английском.

Ну и деньги-то откуда-то получать мне все равно надо, даже с GPL. Про деньги только за поддержку - см. предыдущий пункт.

И это, вообще говоря, стандартная ситуация во многих компаниях :(

Собственно, я бы даже заплатил, если бы QT предоставляла совсем гигантские преимущества. Но максимум что она мне может дать - это еще 5% рынка под Линуксом/Mac OS X. То есть, смысла просто нет ее брать.

ты наверное имел ввиду "completion ports"? - Реализовано это крайне х**во, проще добавить в прогу новый поток (работать, кстати, тоже быстрее будет).

> Собственно, я бы даже заплатил, если бы QT предоставляла совсем гигантские преимущества. Но максимум что она мне может дать - это еще 5% рынка под Линуксом/Mac OS X. То есть, смысла просто нет ее брать.

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

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

Нельзя так делать - почитайте лицензию внимательно. Такое произведение будет однозначно считаться "derived work".

Думаете, я не думал про методы обхода GPL? :)

А так и должно быть. У кого поддержка лучше, тот и рулит.

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

ну если вспомнить, что Win32 лет примерно столько же, сколько и POSIX-у и в момент разработки первого второй был в таком убожеском состоянии, что мама не горюй (POSIX.1). тем более, что даже в 2007м году и POSIX-а есть масса глюков и неувязок и на его фоне работа с потоками в Win32 выглядит отнюдь не так плохо, хотя была разработан дюже давно и с тех пор особо не менялся.

> Я нашёл по ссылке функции для работы с сокетами. А виндовс, насколько помню, имеет статус POSIX-совместимой, так что я имею право пользоваться посиксными функциями и надеяться, что они сработают.

"POSIX compatibility" в Win32 то-же для галки. на том куцем подмножестве POSIX API, который есть в RTL, что-то сложнее hello world написать весьма проблематично.

// wbr

>Пардон, ошибся, действительно 65%. Хотя ты видимо, разговаривал не с тем маркетологом. Мне сразу сбросили 65% и еще одаривали маечками, чтобы я купил лицензию. Так что не пиздеж, а умение вести переговоры.

Может быть. Хотя не я лично разговаривал - у меня не так много маркетинговых таланта.

Однако, тут проблема в том, что эти 65% мне могут в любой момент отменить. Например, когда я еще пару человек на работу приму. Зависеть от неофициальных договоренностей - очень неприятно, однако.

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

> Нельзя так делать - почитайте лицензию внимательно. Такое произведение будет однозначно считаться "derived work".

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

Кстати, раз гуй не особо важен, может использовать что-то даже не сишное? Допустим, Tk.

> Потому, что моя компания конкурирует с компаниями с сотнями разработчиков. Они могут просто взять версию под GPL и улучшить ее, сами продавая поддержку. Я с ними конкурировать по качеству поддержки просто не смогу - ну нет у меня штата индусов, бодро говорящих на английском.

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