The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Обсуждение выбора графического тулкита для Linux сборки Google Chrome

16.02.2009 13:46

"linux: the views situation" - дискуссия в списке рассылки разработчиков Google Chrome, касающаяся выбора графического тулкита для интерфейса пользователя в Linux версии браузера. Как и было объявлено ранее, интерфейс Linux версии Google Chrome будет построен с использованием библиотек Gtk+, Glib, Pango и Cairo, а также оригинальной системе рендеринга графики Skia (используется в Windows сборке Chrome), портированной в Linux несколько месяцев назад.

Прогресс развития Linux сборки Chrome можно наблюдать по отчетам с еженедельных встреч разработчиков.

На osnews.com представлены две заметки (часть 1, часть 2) в которых изложены основные доводы участвующих в дискуссии.

  1. Главная ссылка к новости (http://osnews.com/story/20987/...)
  2. OpenNews: Google выпустит Linux версию браузера Chrome в течение первой половины 2009 года
  3. OpenNews: Тестовая версия Google Chrome 2.0 продемонстрировала прогресс в поддержке Linux
  4. OpenNews: Завершен период тестирования web-браузера Google Chrome
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/20312-google
Ключевые слова: google, chrome, linux
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 14:10, 16/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно а почему Qt не подошла ?
     
     
  • 2.6, MaMoHT (?), 15:01, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Интересно а почему Qt не подошла ?

    Почитай коментарии там хватает объяснений:
    1. Кросплатформенность илюзорна.
    2. Некоторые вещи очень тяжело сделать на Qt, но правда они пишут что это возможно: им надо в message loop обрабатывать кучу спецефических вещей, что очень сложно сделать на Qt, и их обработка многопоточности тоже плохо ложится на Qt.
    3. Там еще проблемы с рендерингом, чтобы связать с другими библиотеками, которые они собираются использовать.

     
     
  • 3.7, Anonymous (?), 15:29, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Почитай коментарии там хватает объяснений:

    Причем здесь message loop? Гугль просто не хочет зависеть от нокии вот и все объяснение.

    >Кросплатформенность илюзорна.

    Да ну. Тот же Webkit засунули в Qt за пару месяцев, причем задействовали как можно больше частей из Qt. Просто гугль не хочет писать yet another QtWebkit browser, какие сейчас при помощи Qt 4.5 можно в 5 строк на C написать.

     
     
  • 4.21, MaMoHT (?), 18:03, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Причем здесь 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.

     
     
  • 5.29, АНОНИМУС (?), 06:11, 17/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Верите сами в написанное?
    Они сами утверждают, что для каждой системы будет свой браузер, написанный с нуля. В гугле НЕ ХОТЯТ ПИСАТЬ КРОССПЛАТФОРМЕННЫЙ БРАУЗЕР - читайте внимательней. А КуТэ слишком кроссплатформенный :)

     
  • 3.9, LXj (?), 15:37, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Не очень понимаю, в чём иллюзорность кроссплатформенности Qt.

    Гугловцы с самого начала начали делать какой-то свой тулкит, который с одной стороны сам по себе содержит много абстракций, как и те же Qt/GTK, а с другой - изначально не задумывался как кроссплатформенный. В результате у них получилась архитектура с кучей своих решений, которые теперь уже трудно портировать на другие платформы.

    Троллтехи же несколько лет работали над тем, чтобы Qt 4.5 выглядело как winapi на винде, как Cocoa на маке, и как GTK на гноме

     

  • 1.2, Аноним (2), 14:37, 16/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Потому, что KDE 4. Под него прогресс встал. Даже аналога GParted так и не сделали... ИМХО
     
     
  • 2.3, prapor (??), 14:45, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Потому, что KDE 4. Под него прогресс встал. Даже аналога GParted так
    >и не сделали... ИМХО

    И с каких это пор Qt стало KDE? Абы ляпнуть?

     
  • 2.27, r0g3r (??), 04:03, 17/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Даже аналога 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

    Таки не сделали, да?

     

  • 1.4, Georges (ok), 14:46, 16/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    сказано в блоге: потомучто кроссплатформенность qt - иллюзия, надо разговаривать с ОС на её языке
     
     
  • 2.5, . (?), 15:00, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    +1
    для qt выбран не тот путь. зачем, спрашивается, делать свою реализацию для всего?
    imho кроссплатформенный язык должен быть не прослойкой, а способом трансляции в нативные команды.
     
     
  • 3.8, LXj (?), 15:31, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Для чего именно "для всего" делается своя реализация в Qt?
     
  • 3.10, Anonymous (?), 15:54, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >зачем, спрашивается, делать свою реализацию для всего?

    О да! Использовать Cocoa, winapi, EXA, OpenGL, DirectX, установленные в системе кодеки и либы - это "своя реализация для всего", а вот костыль от гугля - это "разговор с ОС на её языке".

    >imho кроссплатформенный язык должен быть не прослойкой, а способом трансляции в нативные команды.

    Это на котором, на VBScript чтоли? xD Или Вы про mono?

     
     
  • 4.18, . (?), 16:32, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Использовать Cocoa, winapi

    вы посмотрите повнимательнее, каким образом используются cocoa, winapi ...
    если кратко: "Load('QtFramework'); MainLoop(); Exit();"

     
     
  • 5.23, Anonymous (?), 19:27, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >вы посмотрите повнимательнее, каким образом используются cocoa, winapi ...

    Тоесть Вы хотите вручную писать луп обработки сообщений, создавать "окно", создавать "перо", получать под это все хэндлы, посылать сообщения другим "окнам". Нет, спасибо, мне такой winapi не нужен, наелся им в свое время.

     
     
  • 6.24, . (?), 19:51, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Тоесть Вы хотите вручную писать луп обработки сообщений, создавать "окно", создавать "перо",
    >получать под это все хэндлы, посылать сообщения другим "окнам". Нет, спасибо,
    >мне такой winapi не нужен, наелся им в свое время.

    так глубоко закапываться необязательно, но в принципе где-то рядом.
    что делает qt? оно содержит свой диспечер, рисует свои контролы, имеет свои классы xml, network, canvas. всё это создает большой оверхед, абсолютно не нужный на системах, имеющих свой api.
    моё скромное мнение: кроссплатформенный фреймворк должен быть тонкой абстракцией или даже набором макросов для существующего api (вроде wxvidgets).
    мнение большинства: фреймворк должен реализовывать свой api.

     
     
  • 7.26, Anonymous (?), 23:01, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >всё это создает большой оверхед, абсолютно не нужный на системах, имеющих свой 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 в том, что троллтехи без фанатизма отобрали те части винды, которые можно и нужно использовать, все, что необходимо было реализовать самим - реализовали сами.

     
     
  • 8.31, MaMoHT (?), 11:36, 17/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Если вы писали более менее серьезные GUI приложения, а не просто набор комбобокс... текст свёрнут, показать
     

  • 1.11, Аноним (2), 15:56, 16/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот и хорошо, QT-программы в GTK окружении смотрятся просто ужасно, уж не знаю как наоборот.
     
     
  • 2.12, Alinaki (?), 16:03, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот и хорошо, QT-программы в GTK окружении смотрятся просто ужасно, уж не
    >знаю как наоборот.

    Есть QGTKStyle. Нормально и давно уже работает.

     
     
  • 3.14, Anonymous (?), 16:06, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Есть QGTKStyle.

    Есть Qt 4.5 и не нужно никаких костылей.

     
     
  • 4.15, Alinaki (?), 16:09, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Есть QGTKStyle.
    >
    >Есть Qt 4.5 и не нужно никаких костылей.

    Потому что в Qt 4.5 QGTKStyle уже встроен, да.

     
  • 3.19, Аноним (-), 16:38, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >QGTKStyle

    Пробовал, всё равно ужас.

    QT-приложения какие-то "замыленные", с непропорциональными (по отношению к остальным прогам) кнопками, даже шрифты как-то не так рендерятся. И всё такое круглое, блестящее, гламурное и замыленное. Кому-то нравится, но в окружении GTK это смотрится ужасно.

     
  • 2.13, Anonymous (?), 16:05, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот и хорошо, QT-программы в GTK окружении смотрятся просто ужасно, уж не
    >знаю как наоборот.

    Особенно ужасно Qt-4.5-программы смотрятся в GTK окружении, такую порнографию можно только в секс шопах продавать.

    >уж не
    >знаю как наоборот.

    Просто песня. GTK-программы везде как родные выглядят и летают.

     
     
  • 3.16, LXj (?), 16:22, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Особенно ужасно Qt-4.5-программы смотрятся в GTK окружении, такую порнографию можно только в секс шопах продавать.

    Screenshot or didn't happen

    > Просто песня. GTK-программы везде как родные выглядят и летают.

    В KDE4-окружении они выглядят не намного лучше, чем какой-нибудь Tk

     
     
  • 4.17, Anonymous (?), 16:27, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Screenshot or didn't happen

    Это стёб над толстыми троллями, которые Qt последний раз в древней федоре/убунте видели. Сам же я на Qt пишу =)

     
     
  • 5.20, V (??), 16:56, 16/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    пиши-пиши, c++ всё стерпит..
     
     
  • 6.30, deepwalker (??), 06:12, 17/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >пиши-пиши, c++ всё стерпит..

    Да и на python qt ложится достаточно хорошо. Почти питонично выглядит кодинг.

     

  • 1.22, Аноним (2), 18:03, 16/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Особенно ужасно Qt-4.5-программы смотрятся в GTK окружении, такую порнографию можно только в секс шопах продавать.

    О да :)) смотрятся точно также как и в любом другом окружении с тем же самым оформлением и теме же самыми шрифтами в отличии от gtk - или шрифт в пол экрана это нормально? :))

     
  • 1.25, Аноним (25), 21:47, 16/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Главное, что не на XUL, а там хоть motif пусть используют. Хотя мне это "хроме" вообще не надо.
     
  • 1.28, Аноним (2), 04:31, 17/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Главное, что не на XUL, а там хоть motif пусть используют. Хотя мне >это "хроме" вообще не надо.

    +1

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру