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

Мозг сломал, что здесь имеется ввиду?
>Fully resolution independent user interfaces (and then we can use this in Plasma instead of our own set of widgets)
То, что они собираются использовать ЭТО вместо своих наработок я понял.

А что тут непонятного? Пользовательские интерфейсы, не зависящие от разрешения (экранного). Векторная графика, наверное.

2tailgunner
Угу, как таковая векторная графика поддерживается в текущей qt4.3.
А как это должно работать вместе с пользовательским интерфейсом? Масштабироваться сможет виджет чтоли, хз.

> Масштабироваться сможет виджет чтоли

А почему нет?

>А почему нет?
Интересно как будут текстовые поля себя вести. В идеале нужен будет векторный шрифт.
Короче :-), интересно на это глянуть.

Вот и славно. Может наконец движок смены тем в чистом Qt4 допилят, а то он некошерный пока какой-то.

2dancv: слова TrueType и OpenType Вам что-нибудь говорят? :)

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

Насколько я разобрался в сигнал-слотовой можели qt, это можно будет сделать так, что практический любое из существующих приложений можно будет перетянуть на веб, переписав только QApplication на, например, QWebApplication. Формочки уже сейчас можно отрисовывать не на экран, а куда угодно. Тем самым свершится капец для facelets.

> IPC (разделяемая память, file mapping/проекция файлов в память, локальные сокеты, все это кроссплатформенное)

Вот уж наматерились наверно разработчики, пытаясь свести под одну линию красивый UNIX IPC и WinAPI, в котором нельзя даже с файлом, пайпом, и сокетом единообразно работать...

Ужас... а полной модульности и плагинности они сделать случаем не хотят? А то и без того кутя - ещё тот монстр, а будет кутя ещё и жрать "гигобайт" (ТМ), больше чем ядро и иксы с ресурсами вместе взятые.

> Если Qt5 и случится, то не ранее 2011/2012.

у меня стоит Qt4.2, и там в коде уже есть пометки про Qt5

> Интересно как будут текстовые поля себя вести. В идеале нужен будет векторный шрифт.

я такое на Tk делал -- отдельно в конфиге прописал 3 используемых в программе шрифта, и меняя их размер, менялись все размеры окон совсем, т.к. были завязаны на размер шрифтов widget'ов.

> Ужас... а полной модульности и плагинности они сделать случаем не хотят? А то и без того кутя - ещё тот монстр, а будет кутя ещё и жрать "гигобайт" (ТМ), больше чем ядро и иксы с ресурсами вместе взятые.

Ну это вы маленько опаздали, Qt в высшей степени модульный и плагинностный.

> Ужас... а полной модульности и плагинности они сделать случаем не хотят? А то и без того кутя - ещё тот монстр, а будет кутя ещё и жрать "гигобайт" (ТМ), больше чем ядро и иксы с ресурсами вместе взятые.

ну вообще-то она и сейчас разбита как минимум на подсистемы на уровне библиотек, которые в свою очередь имеют ряд динамических модулей. или вы про libQLabel.so.5.0.0? надеюсь, что это навряд ли случится.

// wbr

> ну вообще-то она и сейчас разбита как минимум на подсистемы на уровне библиотек, которые в свою очередь имеют ряд динамических модулей. или вы про libQLabel.so.5.0.0? надеюсь, что это навряд ли случится.

До идиотизма навроде бустовского дело действительно доводить не стоит, но факт существования разбивки таки порадовал.

> Ну это вы маленько опаздали, Qt в высшей степени модульный и плагинностный.

Так а с чего это бы мне вдруг переходить на новую кутю, ежели её только Кеды, по большому счёту, используют. Старую - опера, скрибус и ещё по мелочи, а 4.х.х?

> Так а с чего это бы мне вдруг переходить на новую кутю, ежели её только Кеды, по большому счёту, используют. Старую - опера, скрибус и ещё по мелочи, а 4.х.х?

Оперу сейчас тоже на qt4 переписывают. Да и весь qt-шный софт потихоньку переделывают

> Так а с чего это бы мне вдруг переходить на новую кутю, ежели её только Кеды, по большому счёту, используют. Старую - опера, скрибус и ещё по мелочи, а 4.х.х?

смысл вообще переходить на что-то, что в явном виде не используется? с точки зрения пользователя. мне, допустим, по барабану что там, как и почему используют ff или опера. работает и ладно.

// wbr

> смысл вообще переходить на что-то, что в явном виде не используется? с точки зрения пользователя. мне, допустим, по барабану что там, как и почему используют ff или опера. работает и ладно.

Года 3 назад на очень старом по тем временам компе я выбирал программы по принципу используемой граф. библиотеки, т.к. qt тормозила значительно сильнее gtk(особенно, под icewm, который, в отличие от кедов, сам qt не подгружает, ибо не пользуется)

> Года 3 назад на очень старом по тем временам компе я выбирал программы по принципу используемой граф. библиотеки, т.к. qt тормозила значительно сильнее gtk(особенно, под icewm, который, в отличие от кедов, сам qt не подгружает, ибо не пользуется)

AFAIU товарищ Гарик неровно дышит к продукции компании AMD а у них, как всем известно, с производительностью проблем никогда не было, нет и точно не будет. в отличии от того-же Intel. так что явно не его случай и уж он то точно может себе позволить роскошь не обращать внимания на подобные мелочи.

// wbr

>Fully resolution independent user interfaces (and then we can use this in Plasma instead of our own set of widgets)

скорее всего это те самые приснопамятные windowless widgets. Ой боюсь представить, через какую систему костылей это все будет интегрироваться со сторонними либами виджетов.

>Формочки уже сейчас можно отрисовывать не на экран, а куда угодно.

Где про это почитать можно? Например можно отрисовать используя nCurses?

> Где про это почитать можно? Например можно отрисовать используя nCurses?

ну скорее не столько формочку, сколько низкоуровневые графические примитивы -> нет, в ncurses очевидно нельзя. но в postscript AFAIU можно.

http://doc.trolltech.com/4.3/paintsystem.html

// wbr

А в чем идиотизм бустовского разбиения?

> Старую - опера, скрибус и ещё по мелочи, а 4.х.х?

Qt 3.3.x используется только в стабильной версии скрайбуса. Нестабильная уже полгода как на Qt4.

Когда-то слышал что они хотят отказаться от Х-сервера для вывода на экран. Вот на это хотелось бы посмотреть, особенноо если они все на opengl закрутят

>> Формочки уже сейчас можно отрисовывать не на экран, а куда угодно.

> Где про это почитать можно? Например можно отрисовать используя nCurses?

Почитай про "canvas.render()". Сейчас оно используется для принтера, в принципе, можно на любое растровое устройство отрисовать.

А чтобы рисовать буковками, можно заюзать aalib.

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

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

план хороший, душистый, но как насчёт отходняка в сфере безопасности? =)

> AFAIU товарищ Гарик неровно дышит к продукции компании AMD а у них, как всем известно, с производительностью проблем никогда не было, нет и точно не будет. в отличии от того-же Intel. так что явно не его случай и уж он то точно может себе позволить роскошь не обращать внимания на подобные мелочи.

Интель тоже местами хорош, особенно при использовании собственного же компилятора и на счётных задачах, при небольшом (<=2-4) количестве ядер на 1 материнку. Но он идёт вширь и вширь, начиная от внешних шин и заканчивая многократным дублированием и уширением исполнительных устройсв внутри процессора, тогда как уже давно ясно, что будущее таки за NUMA и нормально сделанными процессорами (x86_64 от автора + отсутствие просадки на переходе в лонг-моуд + виртуализация), поэтому и АМД. Но задач, где АМД сливает - тоже много, и даже если брать "производительность на ватт" - всё равно много.

Впрочем, противник QT я больше идейный, поскольку строить свободный десктоп на базе продукта с очень странной лицензией по меньшей мере опасно, а в перспективе (вспомним GIT) - ещё и непредвиденные обстоятельства могут вылезти (например, в виде требования отчислений и т.п.). Хорошо, когда нет зависимости.

> Qt 3.3.x используется только в стабильной версии скрайбуса. Нестабильная уже полгода как на Qt4.

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

> Впрочем, противник QT я больше идейный, поскольку строить свободный десктоп на базе продукта с очень странной лицензией по меньшей мере опасно, а в перспективе (вспомним GIT) - ещё и непредвиденные обстоятельства могут вылезти (например, в виде требования отчислений и т.п.). Хорошо, когда нет зависимости.

GPL уже причислили к лику Странных? respect :)

// wbr

> GPL уже причислили к лику Странных? respect :)

Причислено было двуличие Qt (и в текущий момент тоже), а также - причины, что побудили использовать изначально проприетарный продукт для постройки DE.

> Сам "aseigo" ссылается по этой информации на Маттиаса Еттрича (Matthias Ettrich), Trolltech.

Читается "Эттрихь" ;)

Ёпт, шома, по ссылку ходи:
Multimedia: audio and video playback. Yes, this is Phonon. =) QuickTime, DirectX and GStreamer backends are all coming.

Зачем так новость корёжить?

всегда считал что JS - язык опередивший свое время (как и Лисп впрочем). В последние годы вижу этому наглядное подтверждение - его стали использовать все шире и шире... Просто он близок к "идеалу" универсального языка программирования.

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

Догоняют .NET. Silverlight + WPF это как раз оно самое.

> Вот уж наматерились наверно разработчики, пытаясь свести под одну линию красивый UNIX IPC и WinAPI, в котором нельзя даже с файлом, пайпом, и сокетом единообразно работать...

В .NET зато можно.

если речь идет о языках, основанных на прототипах (prototype based), то io ( http://www.iolanguage.com ) мне нравится больше. язык, в котором вообще отсутствуют ключевые слова. а что касается js, то self вроде как был до него.

>> Вот уж наматерились наверно разработчики, пытаясь свести под одну линию красивый UNIX IPC и WinAPI, в котором нельзя даже с файлом, пайпом, и сокетом единообразно работать...

> В .NET зато можно.

Да-да. Только у дотнета несколько иное понятие кроссплатформенности: дотнетные программы переносимы между всеми ОС семейства windows, на всех типах интел-совместимых процессоров, а, если урезать функциональность, то заработают и на .net compact framework под windows mobile. На этом сайте принято мыслить кроссплатформенность несколько шире.

Кстати, оттого, что в дотнете сделали такую же прокладку для файлов, пайпов и сокетов, как сейчас сделано(оно уже сделано) в qt, в winAPI fwrite(), socket_write() и не_знаю_как_там_называется_pwrite() всё равно нельзя смешивать.

>> GPL уже причислили к лику Странных? respect :)

>Причислено было двуличие Qt (и в текущий момент тоже), а также - причины, что побудили использовать изначально проприетарный продукт для постройки DE.

Лучше уж из проприетарного в свободный, чем наоборот)

> всегда считал что JS - язык опередивший свое время (как и Лисп впрочем). В последние годы вижу этому наглядное подтверждение - его стали использовать все шире и шире... Просто он близок к "идеалу" универсального языка программирования.

JS - это динамический язык, со всеми достоинствами и недостатками таких языков. Динамические языки нравятся далеко не всем.

> Так а с чего это бы мне вдруг переходить на новую кутю, ежели её только Кеды, по большому счёту, используют. Старую - опера, скрибус и ещё по мелочи, а 4.х.х?

Ну так а с чего бы мне переходить на gtk2, пусть ее все и используют?
Да и в какой роли вы собираетесь осуществлять переход?

Если как разработчик, то количество проектов использующих qt не так важно. Не использовать же gtk.

>Вот уж наматерились наверно разработчики, пытаясь свести под одну линию красивый UNIX IPC и WinAPI, в котором нельзя даже с файлом, пайпом, и сокетом единообразно работать...

работа с файлами пайпами и сокетами в win32 не менее единообразна чем в *nix-ах. а изначально асинхронный ввод вывод везде и всюду (completion points) делает WinAPI на голову выше красивых UNIX-ов.

> Кстати, оттого, что в дотнете сделали такую же прокладку для файлов, пайпов и сокетов, как сейчас сделано(оно уже сделано) в qt, в winAPI fwrite(), socket_write() и не_знаю_как_там_называется_pwrite() всё равно нельзя смешивать.

Врёшь! тебе лишь бы обосрать винду. Для файлов и каналов используются одни и те же функции (CreateFile,ReadFile,WriteFile). Для сокетов другой АПИ, сходный с юниксовым, для упрощения портирования кода

Они б еще о GPL 3 подумали.

>> Вот уж наматерились наверно разработчики, пытаясь свести под одну линию красивый UNIX IPC и WinAPI, в котором нельзя даже с файлом, пайпом, и сокетом единообразно работать...

> работа с файлами пайпами и сокетами в win32 не менее единообразна чем в *nix-ах.

Наверно со времён win95 там что-то и переделали, но тогда вроде общих вызовов open()/read()/write()/close() не было. Или я оибаюсь?

> а изначально асинхронный ввод вывод везде и всюду (completion points) делает WinAPI на голову выше красивых UNIX-ов.

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

> Впрочем, противник QT я больше идейный, поскольку строить свободный десктоп на базе продукта с очень странной лицензией по меньшей мере опасно, а в перспективе (вспомним GIT) - ещё и непредвиденные обстоятельства могут вылезти (например, в виде требования отчислений и т.п.).

Лицензия, а именно двойной лицензирование - просто находка. Респект троллям за это.

> Хорошо, когда нет зависимости.

Ага, хорошо когда чувак бесплатно панисал код, выложил его в свободный доступ и умер!

Ога, ждите, любители халявы.

> Для файлов и каналов используются одни и те же функции (CreateFile,ReadFile,WriteFile). Для сокетов другой АПИ, сходный с юниксовым, для упрощения портирования кода

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

> Читается "Эттрихь" ;)

Я в норвежском не силён, но в переводе книги Бланшета и Саммерфилда именно Эттрич. А если верить разговорникам, то звук от этого слога либо "ш", либо "к".

> Не использовать же gtk.

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

> Они б еще о GPL 3 подумали.

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

> Для сокетов другой АПИ, сходный с юниксовым, для упрощения портирования кода

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

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

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

--- cut ---
Platform SDK: File Systems

The ReadFile function reads data from a file, starting at the position that the file pointer indicates. You can use this function for both synchronous and asynchronous operation.

The ReadFileEx function is for only asynchronous operation.

BOOL ReadFile(
HANDLE hFile,
LPVOID lpBuffer,
DWORD nNumberOfBytesToRead,
LPDWORD lpNumberOfBytesRead,
LPOVERLAPPED lpOverlapped
);
Parameters
hFile
[in] A handle to the file to be read.
The file handle must be created with the GENERIC_READ access right. For more information, see File Security and Access Rights.

For asynchronous read operations, hFile can be any handle that is opened with the FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket handle returned by the socket or accept function.

Windows Me/98/95: For asynchronous read operations, hFile can be a communications resource opened with the FILE_FLAG_OVERLAPPED flag by CreateFile, or a socket handle returned by socket or accept. You cannot perform asynchronous read operations on mailslots, named pipes, or disk files.
.......
--- cut ---

// wbr