LINUX.ORG.RU

Linux-версия Google Chrome будет использовать GTK+

 , ,


0

0

В почтовой рассылке Ben Goodger (разработчик интерфейса Google Chrome) объявил, что для создания интерфейса-Linux версии браузера будет использоваться инструментарий GTK+. Решение использовать различный пользовательский интерфейс на каждой платформе несколько затрудняет разработку Linux- и Mac-версий chrome'а, в результате чего выйдут они не раньше июня этого года.

>>> Подробности

★★

Проверено: Shaman007 ()

Ответ на: комментарий от Sylvia

> acid3 работает как на 4.4

41/100 (qt 4.4.3)

> с qt 4.5 умеет флэш, правда несколько нестабильно и может зависать


Ждём qt 4.6, а пока для посмотреть есть Midori

los_nikos ★★★★★
()
Ответ на: комментарий от namezys

>Вы код видели? Вообще глубокая идея, что мы напишем лучше компилятора, уже давно опровергнута,

видел, даже писал, и что???

>Объектный код, написанный на С не может работать быстрее объектного С++.

Да ну, а я всегда почему-то полагал что нативный C быстрее работает... а потом С как раз не объектно-ориентированный, это-ж Вам не Objective-C.

>Хотя к Qt есть много притензий, они не всю мощь С++ не используют

Уляля... ну, газанул так газанул - прям газзаев какой-то... ну, поясните чтоле что Вы здесь имели ввиду...

shty ★★★★★
()
Ответ на: комментарий от geek

> "lowest common denominator subset". Поэтому не ограничивать себя рамками тулкита, разрывающегося от потуг быть ващевсемнасвете - проще

Опять неправильно переводишь. Их не устраивает ограниченность той части Qt, которая одинакова на всех 3 платформах. Поэтому они хотят написать аналог WinAPI на GTK. Бог в помошь, но, боюсь, не осилят.

question4 ★★★★★
()
Ответ на: комментарий от frame

> В 21-м веке писать gui на си - удел маргиналов

так же как и на цепепе

Joe_Bishop
()
Ответ на: комментарий от question4

>Их не устраивает ограниченность той части Qt, которая одинакова на всех 3 платформах

вообще-то это и есть "ограниченность тулкита"

geek ★★★
()
Ответ на: комментарий от frame

Сильное заявление требует сильных обоснований, не считаете? Как-то уж так случилось, что позиции C для всего что можно представить в виде ПО в открытом програмном обеспечении достаточно сильны. Да, ещё сильные позиции у c++, python. Но учитывая, что на них не намного проще писать, их по вашей логике тоже легко можно обозвать маргиналами. Вот то ли дело C#, Java ну или Basic. Вообще знаете, есть такая мысль - если что-то написано и работает хорошо, функционально и не падает, то какая разница на чём оно написано? А любители статистики идут лесом, проект проекту рознь.

ixrws ★★★
()
Ответ на: комментарий от st0ke

>yandex как поисковик лучше от этого не становится

Именно как поисковик, особенно в рунете (тут Гугол, нервно курит в сторонке), да и по "инглишнету" (как это не странно), частенько, выдает более вменяемые результаты.

unihorn
()
Ответ на: комментарий от namezys

>Объектный код, написанный на С не может работать быстрее объектного С++. Хотя к Qt есть много притензий, они не всю мощь С++ не используют

Ну подобные заявления раз от раза начинают уже унывать ведь. Ну разве не понятно, что объектный код может быть разным? Вообще степень использования ООП бывает разной, бывает настолько разной, что при одной и тот же сложности проекта, выбор языка вообще не имеет никакого значения. Может если вы такой умный, объясните популярно чем C do(object) отличается по скорости от выполнения C++ object->do ? Да, если вспомнить про попытки переизобрести С++ путём написания набора функций на С, то тут можно сказать - эффективность теряется. Но всё дело в том, что когда пишут на С, обычно чистой ООП не используется, методы программирования переплетаются и получаются этакий киш миш, который может работать ничем не медленнее. Вопрос тут исключительно в квалификации кодописателя. Ну и конечно - не стоит подходы одного языка транслировать на подходы другого и говорить что оно медленно будет. Так скоро дойдём до сравнивания того насколько удобно работать со списками в лиспе и насколько неудобно в С++. Это будет феерическое сравнение.

ixrws ★★★
()
Ответ на: комментарий от Aceler

>А вот Gnome не настраивает Qt, поэтому сосет

Уже настраивет (коли стиль GTK установить), четвертую, правда, только (без стиля, только, автоматом, цвета, иконки и шрифты копирует).

unihorn
()
Ответ на: комментарий от xocolate

> иногда в жизни (годам к 30) наступает момент, что хочется простого: работать комфортно, без компиляций, прикрутов, докрутов и миллионов опций и настроек.

Купил-таки мак?

Igron ★★★★★
()
Ответ на: комментарий от Aceler

>Как там, в анабиозе-то?
а што, 4.5 уже релизнулась разве?

thevery ★★★★
()

Прекрасное решение. Я за.

jeyc
()
Ответ на: комментарий от shty

> нормально выглядит... вполне себе native look... кстати и Qt довольно таки приличные интерфейсы позволяет делать...

Вы похоже нормальный интерфейс под мак не видели

Посомтрел на скрины - ГГГГ

namezys ★★★★
()
Ответ на: комментарий от shty

> Да ну, а я всегда почему-то полагал что нативный C быстрее работает... а потом С как раз не объектно-ориентированный, это-ж Вам не Objective-C.

Компилятор хоты бы при использовании указателей на фукнции не может проводить макрооптимизацию

namezys ★★★★
()
Ответ на: комментарий от Aceler

> Да, делать не будем. Уже сделали.

Да. Но он нормально не работает.

Сказали так: хотите, пилите. Команда разработчиков КДЕ это делать не будет

namezys ★★★★
()
Ответ на: комментарий от ixrws

> объясните популярно чем C do(object) отличается по скорости от выполнения C++ object->do

Ни чем, до тех пор, пока не включается оптимизацию. Дело в том, какой объем компилятор использует для оптимизации. В С это одно, в С++ другое, он куда более сложный язык. И позволяет компилятору делать куда больше

> Это будет феерическое сравнение.

Ну хоть один адекватный ответ

namezys ★★★★
()
Ответ на: комментарий от devinull

>Хотя, может быть хоть они в GTK выпадающий список профиксят, а то зае*** уже. Кстати, кто-нибудь помнит, с какого года эта бага тянется?

ЕМНИП, с 2002 года. Причем сами гномовцы багом это не считают http://bugzilla.gnome.org/show_bug.cgi?id=129463

Кстати, там есть костыль, который решает проблему: http://bugzilla.gnome.org/show_bug.cgi?id=129463#c11



kaktyc ★★★★
()

ну что за извращенцы... я так надеялся, что будет хоть один нормальный браузер.

amix ★★★
()
Ответ на: комментарий от amix

История знает примеры, когда полуподелки становились качественными продуктами, linux kernel тому пример. Вот может быть так, и gtk будет активнее развиваться, кому от этого хуже? Кстати, вот если они добьются нормальной и быстрой работы хрома, вы его принципиально не будете использовать?:D

ixrws ★★★
()
Ответ на: комментарий от Siado

>Ждем браузер от яндекса

Они поддерживают Firefox, нафиг им еще один браузер? Рынок и так порядочно фрагментирован

X-Pilot ★★★★★
()

Лучше бы сделали как с пикасой, чтобы под wine`ом нормально работала. А это поделие на gtk фтопку. А то не одного браузера под линукс нормально выглядещего нету... Только один konqueror в kde4, тока вот он тормозит из-за своеих этих кед4х.... Санта-Барбара одним словом

aafedorov1989
()
Ответ на: комментарий от aafedorov1989

Тоньше, ну тоньше блин уже! Сколько поколений анонимусов выясняли все тонкости кутэ и гэтэка, а вы как буд-то прошли мимо эволюции. Тролизм это искусство, он должен вбирать в себя всё лучшее, достигнутое ранее.

Иначе уныло:( PS:ещё не хватало вместо большого gtk, иметь монструозный wine в зависимостях, ай да красота, ай да школота!

ixrws ★★★
()

Заявления убогих тулкитодрочеров, намекающие на превосходство одного тулкита над другим, смехотворны и по стилю аргументирования находятся на уровне детского сада, где дети выясняют, у кого машинка красивее или "пестик" громче бахает.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Если не дрочить - придётся думать, а анализ может обернуться личностной катострофой для отдельно взятого тугодума. Что тут думать, дрочить надо!

ixrws ★★★
()
Ответ на: комментарий от iZEN

>Раньше можно было — сейчас нет. Наверно из-за нестыковок версий (Epiphany 2.24 пока что не поддерживает новый webkit-gtk2 1.0.1). Порт сломан.

Только что собрал Epiphany 2.24.2.1 с вебкитом из гита. Работает

feanor ★★★
()
Ответ на: комментарий от namezys

>Вы похоже нормальный интерфейс под мак не видели

Да, в общем, я не макораст и не виставод, сижу в core ковыряюсь - мож чего и пропустил - просветите дядю, киньте линк с "нормальным" интерфейсом.

>Посомтрел на скрины - ГГГГ

Там где Maemo - тоже? Ну-ну...

Теперь ждём от Вас линков с "нормальными" скринами...

shty ★★★★★
()
Ответ на: комментарий от geek

>вообще-то там написано, почему. Выражаясь простым, доступным среднему кдешенику языком - "тулкиты всё-в-одном убоги"

C 4ки qt разбит на части.

brbr
()
Ответ на: комментарий от namezys

> объясните популярно чем C do(object) отличается по скорости от выполнения C++ object->do

>Ни чем,

здесь Ваша первая ошибка, как по содержанию так и по русскому языку :)

если бы Вы пописали на том и на другом у Вас не закралось бы ереси подобной в голову...

>до тех пор, пока не включается оптимизацию.

тааак... давайте рассмотрим как Вы себе понимаете процесс оптимизации... что же такого оптимизирует компилятор?

>Дело в том, какой объем компилятор использует для оптимизации.

а! вот оно как - компилятор работает по объёму теперь у нас...

>В С это одно, в С++ другое, он куда более сложный язык. И позволяет компилятору делать куда больше

да ну... ну что-ж жду от Вас хотя бы 5 преимуществ, которые позволяет в данном контексте делать C++'вый компилятор, конечно же с описанием того какой вклад даёт это в производительность конечной программы... а то мож уже core от линюкса пора срочно переписывать - мужики-то не знают, сидят пилят фигню всякую...

shty ★★★★★
()
Ответ на: комментарий от kaktyc

>Причем сами гномовцы багом это не считают

Интересно девки пляшут ;) Всё как всегда. "Юзеры тупые, они ничего не понимают. Как бы нам их убедить, что это не баг, а фича?"

devinull ★★
()
Ответ на: комментарий от ixrws

разрабатывать gui на си - удел маргиналов, и не может оно быть фукнкциональным (сравнивая qt и gtk для примера)

frame ★★★
()

как много троллей агрится на аббревиатуру GTK+ :)

забавнейшее зрелище.

petrosha ★★★★★
()
Ответ на: комментарий от geek

> вообще-то это и есть "ограниченность тулкита"

Которая проистекает не из большого количества фич в Qt, а строго наоборот, из его простоты :)

question4 ★★★★★
()
Ответ на: комментарий от frame

>разрабатывать gui на си - удел маргиналов, и не может оно быть фукнкциональным (сравнивая qt и gtk для примера)

А добавлять ещё один язык в проект из-за того что не можешь накидать gui на том что есть - это просто тупняк... :)

А потом, чего Вы тулкиты сравниваете? Вы сравните приложения...

shty ★★★★★
()

Я вот не пойму - а что мешало использовать Qt под линукс(только под линукс, таким же образом как например его использует opera)? Это такой же нативный тулкит для X11 как и gtk. И никаких наименьших делителей. Или они хотят сказать что Qt под линукс позволяет сделать меньше чем gtk?

eldar_insafutdinov
()
Ответ на: комментарий от eldar_insafutdinov

>Или они хотят сказать что Qt под линукс позволяет сделать меньше чем gtk?

Есть мнение, что гугеля выпендриваются малец - хотят сделать самый быстрый браузер... оне решили писать платформозависимый код, соответственно выбирают максимально близкие к платформе тулкиты, так вот - линюкс любит голый цэ, поэтому с этой точки зрения выбор gtk+ (а не Qt, который C++) вполне даже логично смотрится...

Не зря-ж они так долго пишуть хромого... там ведь не полные лохи работают.

shty ★★★★★
()
Ответ на: комментарий от AP

>http://img33.picoodle.com/img/img33/3/2/15/f_5m_5206a52.png
Киса куку
Эээ ну крута то, что разраб решил все форматы перечислить %) Ток в общем то никто не просит так это реализовывать))) А ваще постанул бы в фичлист возможность как то под кат загонять такие длинные хрени

Gorthauer ★★★★★
()
Ответ на: комментарий от kaktyc

>ЕМНИП, с 2002 года. Причем сами гномовцы багом это не считают

хахаха. гткдевы - далбаебы. это очередное подтверждение.

prizident ★★★★★
()
Ответ на: комментарий от prizident

>хахаха. гткдевы - далбаебы. это очередное подтверждение.

Далбоеб это вы -- по сылке ходили?

PS ЛОР куча тупых тролей, хвалющий QT.
KDE4 - глючиная фигня, под назвнием "хочу быть похожим на OS X'
Хотя до Quartz -- всем курить и курить.

srgaz
()
Ответ на: комментарий от kyxap

> вот еще один пункт по которому я даже пробовать не буду хром

Наверное есть неудачный опыт попробовать бром ?

ysagat
()
Ответ на: комментарий от prizident

>>ЕМНИП, с 2002 года. Причем сами гномовцы багом это не считают

>хахаха. гткдевы - далбаебы. это очередное подтверждение.

во-первых не ругайтесь - это неприлично и вообще 5.1... а во-вторых по сравнению с "радостями КДЕ" - это вообще фича... :)

shty ★★★★★
()
Ответ на: комментарий от fpga

> Сказать вам что я думаю по этому поводу?! Нет, лучше не буду, а то забанят на лоре... Вы только посмотрите на них! Это они так пишут кроссплатформенный софт! Зла на них не хватает...

http://groups.google.com/group/chromium-dev/msg/f3507e2ded99b354

> In general, we've avoided cross platform UI toolkits because while they may offer what superficially appears to be a quick path to native looking UI on a variety of target platforms, once you go a bit deeper it turns out to be a bit more problematic. As Amanda says, your app ends up "speaking with a foreign accent". > Our experience is that using these frameworks also limits what you can do to a lowest common denominator subset of what's supported by that framework on each platform.

Больше и добавить нечего. Молодцы.

cruxish ★★★★
()
Ответ на: комментарий от eldar_insafutdinov

VLC v.0.9.8 использует Qt4 4.4.3 для виджетов управления.

Вчера апгрейдил православный vlc-0.8.6 с gtk2-only до нового комбайнёрского vlc-0.9.8 с зависимостями от библиотек: Gtk, GNOME и Qt.

Итог: менюшки неполностью русифицированы, и слова, набранные английскими буквами, явно отличаются от слов, набранными русскими буквами — ШРИФФТЫ_РАЗНЫЕ!!

А как всё у VLC хорошо начиналось...

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.