https://www.opennet.ru/openforum/vsluhforumID3/49496.html "linux: the views situation (http://groups.google.com/group/chromium-dev/browse_thread/thread/b89ab99a0c848b89/540a3f63f7b66bab)" - дискуссия в списке рассылки разработчиков Google Chrome, касающаяся выбора графического тулкита для интерфейса пользователя в Linux версии браузера. Как и было объявлено ранее (http://www.opennet.ru/opennews/art.shtml?num=19725), интерфейс Linux версии Google Chrome будет построен с использованием библиотек Gtk+, Glib, Pango и Cairo, а также оригинальной системе рендеринга графики Skia (используется в Windows сборке Chrome), портированной в Linux несколько месяцев назад.<br><br><br>Прогресс развития Linux сборки Chrome можно наблюдать по отчетам (http://code.google.com/p/chromium/wiki/LinuxWeeklyNotes) с еженедельных встреч разработчиков.<br><br>URL: http://osnews.com/story/20980/Linux_Version_of_Chrome_To_Use_Gtk_<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=20312<br> https://www.opennet.ru/openforum/vsluhforumID3/49496.html#31 Tue, 17 Feb 2009 08:36:34 GMT &gt;Огромное преимущество Qt в том, что троллтехи без фанатизма отобрали те части <br>&gt;винды, которые можно и нужно использовать, все, что необходимо было реализовать <br>&gt;самим - реализовали сами. <br><br>Если вы писали более менее серьезные GUI приложения, а не просто набор комбобоксиков и едит-контролов, то должны понимать, что заказчик зачастую просит вещи, которые невозможно реализовать, используя уже готовую библиотеку, приходится лезть на очень низкий уровень и "извращаться" там (зачастую это голимые хаки, которые еще и адаптируются под определенные версии ОС). <br>Поэтому Qt и годится для небольших программ, без больших изысков в интерфейсе. Если программа становится сложнее, то "универсальные" движки попросту невозможно заюзать, слишком много хаков становится, которые подстраиваются не только под ОС, но еще и под библиотеку. Программы ранга OpenOffice не напишут на Qt - не из-за идеологических причин, а потому что Qt слишком много на себя берет. Далеко за примерами ходить не нужно: посмотрите на KDE - сколько там https://www.opennet.ru/openforum/vsluhforumID3/49496.html#30 Tue, 17 Feb 2009 03:12:37 GMT &gt;пиши-пиши, c++ всё стерпит.. <br><br>Да и на python qt ложится достаточно хорошо. Почти питонично выглядит кодинг.<br> https://www.opennet.ru/openforum/vsluhforumID3/49496.html#29 Tue, 17 Feb 2009 03:11:07 GMT Верите сами в написанное?<br>Они сами утверждают, что для каждой системы будет свой браузер, написанный с нуля. В гугле НЕ ХОТЯТ ПИСАТЬ КРОССПЛАТФОРМЕННЫЙ БРАУЗЕР - читайте внимательней. А КуТэ слишком кроссплатформенный :)<br><br> https://www.opennet.ru/openforum/vsluhforumID3/49496.html#28 Tue, 17 Feb 2009 01:31:03 GMT &gt;Главное, что не на XUL, а там хоть motif пусть используют. Хотя мне &gt;это "хроме" вообще не надо.<br><br>+1<br> https://www.opennet.ru/openforum/vsluhforumID3/49496.html#27 Tue, 17 Feb 2009 01:03:58 GMT &gt; Даже аналога GParted так и не сделали... ИМХО <br><br>roger@naglfar ~ $ eix parted<br><br>* sys-apps/qtparted<br> Available versions: 0.4.4 (~)0.4.4-r1 0.4.5 {arts debug elibc_FreeBSD gnome jfs kde ntfs reiserfs xfs xinerama}<br> Homepage: http://qtparted.sourceforge.net/<br> Description: nice Qt partition tool for Linux<br><br>Таки не сделали, да? <br><br> https://www.opennet.ru/openforum/vsluhforumID3/49496.html#26 Mon, 16 Feb 2009 20:01:04 GMT &gt;всё это создает большой оверхед, абсолютно не нужный на системах, имеющих свой api.<br><br>Вы исходники Windows видели? Я когда-то смотрел именно те части, которые занимаются отрисовкой. Огромная часть кода - не поддерживаемый код из далеких времен Windows 3.11, другая - наспех сколоченные обращения к 2D графическим функциям ядра.<br><br>А теперь по порядку. Winapi как такового не существует - это несколько dll, входящих в поставку винды и экспортирующих разные функции. Проблема в том, что с далеких времен Windows NT 3.x эти функции не претерпели изменений, за исключением нескольких нюансов. Изменение в winapi как оказалось вносить нежелательно, т.к. старые программы откажутся работать под новыми виндами, что мы и наблюдаем регулярно. Поэтому MS выдумала сначала MFC - это уже не winapi, это как раз "оверхед, абсолютно не нужный на системах, имеющих свой api". Но проблема оказалась не решенной и изменения вносить опять таки нельзя, можно только расширять существующую функциональность. От MFC отказались в пользу COM, т https://www.opennet.ru/openforum/vsluhforumID3/49496.html#25 Mon, 16 Feb 2009 18:47:03 GMT Главное, что не на XUL, а там хоть motif пусть используют. Хотя мне это "хроме" вообще не надо.<br> https://www.opennet.ru/openforum/vsluhforumID3/49496.html#24 Mon, 16 Feb 2009 16:51:59 GMT &gt;Тоесть Вы хотите вручную писать луп обработки сообщений, создавать "окно", создавать "перо",<br>&gt;получать под это все хэндлы, посылать сообщения другим "окнам". Нет, спасибо,<br>&gt;мне такой winapi не нужен, наелся им в свое время.<br><br>так глубоко закапываться необязательно, но в принципе где-то рядом.<br>что делает qt? оно содержит свой диспечер, рисует свои контролы, имеет свои классы xml, network, canvas. всё это создает большой оверхед, абсолютно не нужный на системах, имеющих свой api.<br>моё скромное мнение: кроссплатформенный фреймворк должен быть тонкой абстракцией или даже набором макросов для существующего api (вроде wxvidgets).<br>мнение большинства: фреймворк должен реализовывать свой api.<br> https://www.opennet.ru/openforum/vsluhforumID3/49496.html#23 Mon, 16 Feb 2009 16:27:06 GMT &gt;вы посмотрите повнимательнее, каким образом используются cocoa, winapi ...<br><br>Тоесть Вы хотите вручную писать луп обработки сообщений, создавать "окно", создавать "перо", получать под это все хэндлы, посылать сообщения другим "окнам". Нет, спасибо, мне такой winapi не нужен, наелся им в свое время.<br>