"linux: the views situation (http://groups.google.com/group/chromium-dev/browse_thread/th...)" - дискуссия в списке рассылки разработчиков Google Chrome, касающаяся выбора графического тулкита для интерфейса пользователя в Linux версии браузера. Как и было объявлено ранее (http://www.opennet.me/opennews/art.shtml?num=19725), интерфейс Linux версии Google Chrome будет построен с использованием библиотек Gtk+, Glib, Pango и Cairo, а также оригинальной системе рендеринга графики Skia (используется в Windows сборке Chrome), портированной в Linux несколько месяцев назад.
Прогресс развития Linux сборки Chrome можно наблюдать по отчетам (http://code.google.com/p/chromium/wiki/LinuxWeeklyNotes) с еженедельных встреч разработчиков.URL: http://osnews.com/story/20980/Linux_Version_of_Chrome_To_Use...
Новость: http://www.opennet.me/opennews/art.shtml?num=20312
Интересно а почему Qt не подошла ?
>Интересно а почему Qt не подошла ?Почитай коментарии там хватает объяснений:
1. Кросплатформенность илюзорна.
2. Некоторые вещи очень тяжело сделать на Qt, но правда они пишут что это возможно: им надо в message loop обрабатывать кучу спецефических вещей, что очень сложно сделать на Qt, и их обработка многопоточности тоже плохо ложится на Qt.
3. Там еще проблемы с рендерингом, чтобы связать с другими библиотеками, которые они собираются использовать.
>Почитай коментарии там хватает объяснений:Причем здесь message loop? Гугль просто не хочет зависеть от нокии вот и все объяснение.
>Кросплатформенность илюзорна.
Да ну. Тот же Webkit засунули в Qt за пару месяцев, причем задействовали как можно больше частей из Qt. Просто гугль не хочет писать yet another QtWebkit browser, какие сейчас при помощи Qt 4.5 можно в 5 строк на C написать.
>Причем здесь message loop? Гугль просто не хочет зависеть от нокии вот
>и все объяснение.
>
>Да ну. Тот же Webkit засунули в Qt за пару месяцев, причем
>задействовали как можно больше частей из Qt. Просто гугль не хочет
>писать yet another QtWebkit browser, какие сейчас при помощи Qt 4.5
>можно в 5 строк на C написать.Давайте разложим все по полочкам, чтобы стало понятно почему не Qt:
1. Есть броузер, который они написали, и который обладает определенными характеристиками и фишками. Все это дело базируется на определенных технических решениях.
2. У людей стоит задача, чтобы портировать это дело на всеми нами любимую OS. И вот все эти технологии нужно перенести, но получается, что проще это сделать используя GTK.А вы что пишите? Что без проблем - вон QtWebkit browser написали на Qt, значит и Chrome можно точно так же написать. Неужели вы не понимаете, что просто выкинуть все то, что они написали и написать это на Qt, значит не портировать Chrome на Linux - а это значит написать другой броузер и лишить его тех фишек, которые они для него придумали?
Да они говорят, что можно перенести их технологии на Qt - но это очень трудоемко - вот и вся причина.
И не гонится никто за костылями и новыми движками - просто люди трезво оценивают ситуацию и этот путь короче, чем портировать это на Qt.
Верите сами в написанное?
Они сами утверждают, что для каждой системы будет свой браузер, написанный с нуля. В гугле НЕ ХОТЯТ ПИСАТЬ КРОССПЛАТФОРМЕННЫЙ БРАУЗЕР - читайте внимательней. А КуТэ слишком кроссплатформенный :)
Не очень понимаю, в чём иллюзорность кроссплатформенности Qt.Гугловцы с самого начала начали делать какой-то свой тулкит, который с одной стороны сам по себе содержит много абстракций, как и те же Qt/GTK, а с другой - изначально не задумывался как кроссплатформенный. В результате у них получилась архитектура с кучей своих решений, которые теперь уже трудно портировать на другие платформы.
Троллтехи же несколько лет работали над тем, чтобы Qt 4.5 выглядело как winapi на винде, как Cocoa на маке, и как GTK на гноме
Потому, что KDE 4. Под него прогресс встал. Даже аналога GParted так и не сделали... ИМХО
>Потому, что KDE 4. Под него прогресс встал. Даже аналога GParted так
>и не сделали... ИМХОИ с каких это пор Qt стало KDE? Абы ляпнуть?
> Даже аналога GParted так и не сделали... ИМХОroger@naglfar ~ $ eix parted
* sys-apps/qtparted
Available versions: 0.4.4 (~)0.4.4-r1 0.4.5 {arts debug elibc_FreeBSD gnome jfs kde ntfs reiserfs xfs xinerama}
Homepage: http://qtparted.sourceforge.net/
Description: nice Qt partition tool for LinuxТаки не сделали, да?
сказано в блоге: потомучто кроссплатформенность qt - иллюзия, надо разговаривать с ОС на её языке
+1
для qt выбран не тот путь. зачем, спрашивается, делать свою реализацию для всего?
imho кроссплатформенный язык должен быть не прослойкой, а способом трансляции в нативные команды.
Для чего именно "для всего" делается своя реализация в Qt?
>зачем, спрашивается, делать свою реализацию для всего?О да! Использовать Cocoa, winapi, EXA, OpenGL, DirectX, установленные в системе кодеки и либы - это "своя реализация для всего", а вот костыль от гугля - это "разговор с ОС на её языке".
>imho кроссплатформенный язык должен быть не прослойкой, а способом трансляции в нативные команды.
Это на котором, на VBScript чтоли? xD Или Вы про mono?
>Использовать Cocoa, winapiвы посмотрите повнимательнее, каким образом используются cocoa, winapi ...
если кратко: "Load('QtFramework'); MainLoop(); Exit();"
>вы посмотрите повнимательнее, каким образом используются cocoa, winapi ...Тоесть Вы хотите вручную писать луп обработки сообщений, создавать "окно", создавать "перо", получать под это все хэндлы, посылать сообщения другим "окнам". Нет, спасибо, мне такой winapi не нужен, наелся им в свое время.
>Тоесть Вы хотите вручную писать луп обработки сообщений, создавать "окно", создавать "перо",
>получать под это все хэндлы, посылать сообщения другим "окнам". Нет, спасибо,
>мне такой winapi не нужен, наелся им в свое время.так глубоко закапываться необязательно, но в принципе где-то рядом.
что делает qt? оно содержит свой диспечер, рисует свои контролы, имеет свои классы xml, network, canvas. всё это создает большой оверхед, абсолютно не нужный на системах, имеющих свой api.
моё скромное мнение: кроссплатформенный фреймворк должен быть тонкой абстракцией или даже набором макросов для существующего api (вроде wxvidgets).
мнение большинства: фреймворк должен реализовывать свой api.
>всё это создает большой оверхед, абсолютно не нужный на системах, имеющих свой api.Вы исходники Windows видели? Я когда-то смотрел именно те части, которые занимаются отрисовкой. Огромная часть кода - не поддерживаемый код из далеких времен Windows 3.11, другая - наспех сколоченные обращения к 2D графическим функциям ядра.
А теперь по порядку. Winapi как такового не существует - это несколько dll, входящих в поставку винды и экспортирующих разные функции. Проблема в том, что с далеких времен Windows NT 3.x эти функции не претерпели изменений, за исключением нескольких нюансов. Изменение в winapi как оказалось вносить нежелательно, т.к. старые программы откажутся работать под новыми виндами, что мы и наблюдаем регулярно. Поэтому MS выдумала сначала MFC - это уже не winapi, это как раз "оверхед, абсолютно не нужный на системах, имеющих свой api". Но проблема оказалась не решенной и изменения вносить опять таки нельзя, можно только расширять существующую функциональность. От MFC отказались в пользу COM, те же dll, только с уникальным номером. И снова "новые технологии", и снова в бой - .Net, WinForms, библиотеки классов. То есть на каждый новый чих теперь создается новая Framework, а старая программа обязана требовать старый.
>кроссплатформенный фреймворк должен быть тонкой абстракцией или даже набором макросов для существующего api
А теперь вопрос, какой такой WinApi используют любые относительно новые Win приложения? И ежу понятно winapi - старый как говно мамонта, свой предел исчерпал ещё в далеком 2000 году с выходом Windows 2000.
Огромное преимущество Qt в том, что троллтехи без фанатизма отобрали те части винды, которые можно и нужно использовать, все, что необходимо было реализовать самим - реализовали сами.
>Огромное преимущество Qt в том, что троллтехи без фанатизма отобрали те части
>винды, которые можно и нужно использовать, все, что необходимо было реализовать
>самим - реализовали сами.Если вы писали более менее серьезные GUI приложения, а не просто набор комбобоксиков и едит-контролов, то должны понимать, что заказчик зачастую просит вещи, которые невозможно реализовать, используя уже готовую библиотеку, приходится лезть на очень низкий уровень и "извращаться" там (зачастую это голимые хаки, которые еще и адаптируются под определенные версии ОС).
Поэтому Qt и годится для небольших программ, без больших изысков в интерфейсе. Если программа становится сложнее, то "универсальные" движки попросту невозможно заюзать, слишком много хаков становится, которые подстраиваются не только под ОС, но еще и под библиотеку. Программы ранга OpenOffice не напишут на Qt - не из-за идеологических причин, а потому что Qt слишком много на себя берет. Далеко за примерами ходить не нужно: посмотрите на KDE - сколько там всего понаписано поверх Qt? И при этом кеды жутко тормозная штука, при том, что программы написанные с использованием чисто Qt очень легкие и быстрые.
Вот и хорошо, QT-программы в GTK окружении смотрятся просто ужасно, уж не знаю как наоборот.
>Вот и хорошо, QT-программы в GTK окружении смотрятся просто ужасно, уж не
>знаю как наоборот.Есть QGTKStyle. Нормально и давно уже работает.
>Есть QGTKStyle.Есть Qt 4.5 и не нужно никаких костылей.
>>Есть QGTKStyle.
>
>Есть Qt 4.5 и не нужно никаких костылей.Потому что в Qt 4.5 QGTKStyle уже встроен, да.
>QGTKStyleПробовал, всё равно ужас.
QT-приложения какие-то "замыленные", с непропорциональными (по отношению к остальным прогам) кнопками, даже шрифты как-то не так рендерятся. И всё такое круглое, блестящее, гламурное и замыленное. Кому-то нравится, но в окружении GTK это смотрится ужасно.
>Вот и хорошо, QT-программы в GTK окружении смотрятся просто ужасно, уж не
>знаю как наоборот.Особенно ужасно Qt-4.5-программы смотрятся в GTK окружении, такую порнографию можно только в секс шопах продавать.
>уж не
>знаю как наоборот.Просто песня. GTK-программы везде как родные выглядят и летают.
> Особенно ужасно Qt-4.5-программы смотрятся в GTK окружении, такую порнографию можно только в секс шопах продавать.Screenshot or didn't happen
> Просто песня. GTK-программы везде как родные выглядят и летают.
В KDE4-окружении они выглядят не намного лучше, чем какой-нибудь Tk
>Screenshot or didn't happenЭто стёб над толстыми троллями, которые Qt последний раз в древней федоре/убунте видели. Сам же я на Qt пишу =)
пиши-пиши, c++ всё стерпит..
>пиши-пиши, c++ всё стерпит..Да и на python qt ложится достаточно хорошо. Почти питонично выглядит кодинг.
> Особенно ужасно Qt-4.5-программы смотрятся в GTK окружении, такую порнографию можно только в секс шопах продавать.О да :)) смотрятся точно также как и в любом другом окружении с тем же самым оформлением и теме же самыми шрифтами в отличии от gtk - или шрифт в пол экрана это нормально? :))
Главное, что не на XUL, а там хоть motif пусть используют. Хотя мне это "хроме" вообще не надо.
>Главное, что не на XUL, а там хоть motif пусть используют. Хотя мне >это "хроме" вообще не надо.+1