Здравствуйте, Константин Б., Вы писали:
F>>т.е. вообще не нарисовать свой убер-контрол?. F>>толи я чего то не понял, толи набор контролов становится ограничен тем, что предлагает Qt.. КБ>Нет. Набор контролов неограничен, но те что есть могут отличаться от стандартных контролов.
нет ли здесь опечатки?.
я не понял, объясни, пожалуйста, на пальцах..
хочу вот я контрол, который выглядит как белый квадратик, а когда я нажимаю на него в разных местах, то там внутри контрола рисуются черные кружочки.. такое возможно?.
есть там аналог OnPaint(PaintDC*) ?.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Константин Б., Вы писали:
F>>>т.е. вообще не нарисовать свой убер-контрол?. F>>>толи я чего то не понял, толи набор контролов становится ограничен тем, что предлагает Qt.. КБ>>Нет. Набор контролов неограничен, но те что есть могут отличаться от стандартных контролов.
F>нет ли здесь опечатки?.
F>я не понял, объясни, пожалуйста, на пальцах..
Ну например Qt-шный едит-бокс может оличаться по внешнему виду и поведению от стандартного виндового.
Здравствуйте, Cyberax, Вы писали:
C>>>А в чем тогда будет смысл коммерческой лицензии? Или нокия поняла, что на qt много не заработаешь и решила начать двигать его в массы? M>>Комерческая — это страховка. Они смогут сделать чисто комерческий форк Qt. C>Не смогут. Есть такая замечательная вещь — договор между Trolltech и KDE. По нему предусматривается, что QT будет перелицензирована под BSD, если Trolltech (или компания, которая её купит) перестанет её развивать.
neFormal пишет:
> т.е. вообще не нарисовать свой убер-контрол?. > толи я чего то не понял, толи набор контролов становится ограничен тем, > что предлагает Qt..
Имелось в виду видимо, что даже на винде, где есть свои контролы в
OS он тем не менее будет рисовать свои собственные, а не использовать
стандартные.
Финляндия, маленькая страна с 5-миллионным населением — второй раз спасает весь мир от давления майкрософта.
Первый раз — когда финн Линус Торвальдс осмелился написать бесплатную и открытую операционную систему, выйти против монстроидально устрашающего конкурента Microsoft Windows.
Второй раз — сейчас, финская компания Nokia купила целую фирму, чтобы сделать бесплатной для коммерческого использования самую лучшую кросс-платформенную библиотеку GUI для C++.
Таким образом, на MFC писать уже становится менее выгодно. А на .NET тем более.
Хорошо сказано древними: по плодам узнаете их. Финны — очень честный народ. Поэтому не удивительно. По индексу стран с самым низким уровнем коррупции Финляндия всегда занимала одно из первых мест. Всякое дерево доброе приносит и плоды добрые.
Здравствуйте, Anonim12, Вы писали:
A>От себя могу добавить:
A>Финляндия, маленькая страна с 5-миллионным населением — второй раз спасает весь мир от давления майкрософта.
A>Первый раз — когда финн Линус Торвальдс осмелился написать бесплатную и открытую операционную систему, выйти против монстроидально устрашающего конкурента Microsoft Windows.
A>Второй раз — сейчас, финская компания Nokia купила целую фирму, чтобы сделать бесплатной для коммерческого использования самую лучшую кросс-платформенную библиотеку GUI для C++.
A>Таким образом, на MFC писать уже становится менее выгодно. А на .NET тем более.
A>Хорошо сказано древними: по плодам узнаете их. Финны — очень честный народ. Поэтому не удивительно. По индексу стран с самым низким уровнем коррупции Финляндия всегда занимала одно из первых мест. Всякое дерево доброе приносит и плоды добрые.
Ну вот. И сюда добрались любители реконструировать историю
"Mr.Cat" <64543@users.rsdn.ru> wrote in message news:3247919@news.rsdn.ru...
>А в чем тогда будет смысл коммерческой лицензии? Или нокия поняла, что на qt много не заработаешь и решила начать двигать его в массы?
Я думаю им просто западло инсталляторы переделывать забесплатно Вот второй Карбид Нокия тоже теперь нахаляву раздает, а едишенов так три штуки и осталось — хотя в младшем, который раньше служил в качестве первой бесплатной дозы, теперь смысла точно нет никакого
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
"Qbit86" <70337@users.rsdn.ru> wrote in message news:3249605@news.rsdn.ru...
> S>Вот второй Карбид Нокия... > > «Карбид нокия» — это что-то из химии? Соль какая-то?
Да, смешно получилось IDE это такая, на базе Eclipse, для разработки под симбиан.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Qbit86, Вы писали:
A>>Таким образом, на MFC писать уже становится менее выгодно. А на .NET тем более.
Q>М? В смысле «тем более»? На WPF писать проще, чем на Qt.
WPF не то же самое, что и Qt. Помимо того, что Qt реально кроссплатформенная, есть еще такой момент:
1. Найди электронную книжку на 3-4 Мб текста.
2. Открой демо-приложения с ричэдитом на Qt, WPF, ну и еще что-нибудь — Winword, Wordpad, Sciter, textarea в IE, Firefox.
3. Вставь туда этот текст, сделай Ctrl+A и Ctrl+B (все жирным).
4. Погляди на объемы использованной памяти, закрой зависшее WPF-приложение, сними футлобку с надписью «microsoft» и отложи в долгий ящик до лучших времен.
5. Пойди загляни в глаза тому, кто говорил, что 50 Мб используемой памяти вместо 5 на MFC, это копейки, когда на компе «аж целых 2 Гб»
Здравствуйте, Кодёнок, Вы писали:
Кё>1. Найди электронную книжку на 3-4 Мб текста. Кё>2. Открой демо-приложения с ричэдитом на Qt, WPF, ну и еще что-нибудь — Winword, Wordpad, Sciter, textarea в IE, Firefox. Кё>3. Вставь туда этот текст, сделай Ctrl+A и Ctrl+B (все жирным). Кё>4. Погляди на объемы использованной памяти, закрой зависшее WPF-приложение, сними футлобку с надписью «microsoft» и отложи в долгий ящик до лучших времен. Кё>5. Пойди загляни в глаза тому, кто говорил, что 50 Мб используемой памяти вместо 5 на MFC, это копейки, когда на компе «аж целых 2 Гб»
Вообще, дельная идея, сейчас в TODO запишу. Реальных и правдоподобных сравнений производительности пока не встречал.
По своему опыту могу сказать, что рисование в WPF вполне себе быстрое, оно использует напрямую Direct3D, и НЕ использует прямо или косвенно через интероп Win32 (User32), GDI, GDI+.
Кё>есть еще такой момент:
Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Кодёнок, Вы писали:
Кё>>1. Найди электронную книжку на 3-4 Мб текста. Кё>>2. Открой демо-приложения с ричэдитом на Qt, WPF, ну и еще что-нибудь — Winword, Wordpad, Sciter, textarea в IE, Firefox. Кё>>3. Вставь туда этот текст, сделай Ctrl+A и Ctrl+B (все жирным). Кё>>4. Погляди на объемы использованной памяти, закрой зависшее WPF-приложение, сними футлобку с надписью «microsoft» и отложи в долгий ящик до лучших времен. Кё>>5. Пойди загляни в глаза тому, кто говорил, что 50 Мб используемой памяти вместо 5 на MFC, это копейки, когда на компе «аж целых 2 Гб»
Q>Вообще, дельная идея, сейчас в TODO запишу. Реальных и правдоподобных сравнений производительности пока не встречал.
Q>По своему опыту могу сказать, что рисование в WPF вполне себе быстрое, оно использует напрямую Direct3D, и НЕ использует прямо или косвенно через интероп Win32 (User32), GDI, GDI+.
Кё>>есть еще такой момент:
Q>Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо.
это преимущество имеет место быть востребованным в случае если твоя команда занимается штампованием прог аля CD-ejector (смотри простенькие) — ибо если ты таким образом налабаеш сложное приложение, состоящее из N компонентов. То можешь сам посчитать производительность каждой компоненты, умножить на N и получить рузультат
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Denys V., Вы писали:
Q>>Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо.
DV>это преимущество имеет место быть востребованным в случае если твоя команда занимается штампованием прог аля CD-ejector (смотри простенькие)
«Штампованием CD-ejector'ов» можно и на Дельфи заниматься, так что мимо кассы.
DV> — ибо если ты таким образом налабаеш сложное приложение, состоящее из N компонентов.
Что-то я с этим сложноподчинённым предложением запутался.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Denys V., Вы писали:
Q>>>Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо.
DV>>это преимущество имеет место быть востребованным в случае если твоя команда занимается штампованием прог аля CD-ejector (смотри простенькие)
Q>«Штампованием CD-ejector'ов» можно и на Дельфи заниматься, так что мимо кассы.
а я WPF туда же... в туже топку
DV>> — ибо если ты таким образом налабаеш сложное приложение, состоящее из N компонентов.
Q>Что-то я с этим сложноподчинённым предложением запутался.
Приложение = П
Компоненты = К
П = К1 + К2 + К3 + ... + КN
Возьмем к примеру такой параметр как отжирание памяти
упустим что не все компоненты могут быть активны одновременно. Будем считать что у нас все работают одновременно.
тогда Память отжираемая приложением — это сумма объемов памяти каждой из компонент.
Соответственно. если все компоненты написаны на wpf — получим один результат. если на wpf — другой.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Denys V., Вы писали:
Q>>«Штампованием CD-ejector'ов» можно и на Дельфи заниматься, так что мимо кассы.
DV>а я WPF туда же... в туже топку ;)
И Qt туда же? Или на Qt проще CD-ejector'ы писать? Или сложнее? Не запутался?
DV>Возьмем к примеру такой параметр как отжирание памяти... DV>Соответственно. если все компоненты написаны на wpf — получим один результат. если на c++ — другой.
«Другой» — какой? С памятью у C++ не всё просто, потому что стандартный аллокатор памяти (MSVC++ Runtime) работает в общем случае медленнее .NET'овского. Т. к. проходится по списку чанков, порой даже за линейное время. А в .NET выделение памяти — мгновенный инкремент (правда, для выделения очень больших кусков в CLR применяется другой алгоритм).
Здравствуйте, Denys V., Вы писали:
DV>Возьмем к примеру такой параметр как отжирание памяти
Я могу проще объяснить.
WTL-приложение кушает 6 Мб — копейки. WPF-приложение — 60 Мб, копейки (типичный аргумент про .Net — «сколько у вас памяти? 2 Гб? и, что, 60 Мб у вас вызывают проблемы?»)
Подвергаем приложение чуть большей нагрузке. Умножаем на 10. WTL-приложение — 60 Мб, копейки остались копейками. WPF — 600 Мб. Копейки превратились в околопредельную нагрузку. На практике — 600 Мб плюс долгие зависания на секунды, пока GC по этим 600 Мб прошаривается.
