Новые возможности Firefox 3

нет не забыл. верту подешевели тока вот в этой верту кишки от 7210 если не хуже.

а блокировщик рекламы починили? нет? нахер оперу

+1

>> Рекоммендую Vertu базовой модели из высоколегированной стали за ~1000$. Там прошивка на базе Nokia 3310

>Один нолик забыл в цене.

Нет, базовая модель из стали AFAIK стоит около косаря. Может 1200

+2

rusxakep

За тебя никто ничего не будет делать. В ADшке в том числе... А если сам хочеш освоить это - Читай про .ADM шаблоны и научись их строить ;] дальше проблем не возникнет

а что, он когда-то был сломан? O_o

фигасе. а я и не знал… сколько уже юзаю — и не знал, что оно сломано, оказывается…

@birdie:

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

Пускай дальше развивают в этом же направлении. Быдляк и фанатики схавают, а нормальным фокс без надобности - на нем свет клином не сошелся.

> Лучше бы сделали какую-нить интеграцию с AD, а то приходится лично для FireFox указывать сетевые настройки (proxy), и пользователи могут ее отключать...

Вот поэтому в большинстве компаний используется IE. ПОтмоу что мозильские пионеры и линуксоиды еще не доросли до уровня enterprise и ниасилили итеграцию с AD и GPO.

> ФФ3 для линукса не тормозит, это радует. Но хоткеи не работают.

Да здраствует опенсорс, самый лучший опенсорс в мире. Никакая проприетарщина рядом не валялась(представляю какой бы стоял мат, если бы в IE или опере не работали бы хоткеи в русской раскладке, а PPTP VPn ронял бы систему в BSOD ак это происхдит в RHEL5).

> Отрубание прокси? А зачем? Или у тебя обычный доступ к http(s) на шлюзе открыт?

Знаешь что такое централизованное управление настройками с возможностю блокировки изменения рядовыми юзерами?

> +1 , потому что дома с compiz-fusion эта фишка ещё будет смотреться органично, а вот на работе (под оффтопом хр), наверное, отключу

Вот такое вот позиционироание у линукса - на работает винда, чтобы работать, а дома на побаловаться с поделкой с шашечками и финтифлюшками - линукс.

> сделай прозрачное проксирование на шлюзе

А по юзерам оно умеет авторизовать? А что если юзер пересядет на другой компутер?

> /usr/lib/qt4/bin/qt3to4 ? =)

>> Гениально! :)) Надо посоветовать команде разработки kde4. %)

Команды разработки KDE ниасили вот уже десять лет исправить переключалку, куда им такие высокие материи?

>Команды разработки KDE ниасили вот уже десять лет исправить переключалку, куда им такие высокие материи?

Переключалка там ипокон веков работает. Просто она не рассчитана на гномеров и виндузятников, которые слишком тупы, чтобы понять как она настраивается. Да, еще уже какую сотню лет всяких анонимов давят, а передавить все так и не могут

Хотя нет, скорее не тупы, а узколобы - так будет корректнее.

> именно прозрачный, как в IE?

Единственное, что нужно сделать, вписать прокси в настройки Firefox - затем NTLM молча работает.

Прозрачный прокси с авторизацией никогда не будет работать ;-)

лучше бы утечки памяти устранили

>> а блокировщик рекламы починили?

+1 некоторый флеш не блокирует, иногда не сохраняет настройки.

>Знаешь что такое централизованное управление настройками с возможностю блокировки изменения рядовыми юзерами?

это ты про ldap, squid и iptables? знаем, знаем…

>+1 некоторый флеш не блокирует, иногда не сохраняет настройки.

о, великие анонимусы! расскажите мне, как этого добиться! а то как не мучал — всё блокирует, что надо, и ничего, что не надо. зараза. что я делаю не так?

>>Команды разработки KDE ниасили вот уже десять лет исправить переключалку, куда им такие высокие материи?

>Переключалка там ипокон веков работает. Просто она не рассчитана на гномеров и виндузятников, которые слишком тупы, чтобы понять как она настраивается.

Ну, не только русские от нее в бешенстве, но и греки например - судя по kde'шному треку

а нахрен она вообще нужна от кед? что, xxkb запретили?

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

это в быдлоконторах такое позиционирование. В кошерных конторах, типа моей, работают в нормальных осях (линукс, макось), а венда дома стоит, чтобы загрузить на часок в неделю, поиграть ;)

Лучше бы они придумали действительно нужные фичи и поработали над самим движком браузера (нормальная работа кеша, компилированный JS/расширения, отвязались от XUL)

Вот у меня в браузере обычно открыто 100+ вкладок. При этом панель с табами становится необозримой, не понятно где новые/старые вкладки, все свалено в одну кучу. Где-то новости, блоги, где-то гугление, где-то дока и книжки с многабуквами, где-то Scrapbook.

Допустим, у нас есть "группы" табов, и правила, по которым таб открывается в нужной группе. Самы группы сделаны в разных окнах, например как табы в Ion, но при этом все группы доступны из любого окна.

Читаем вкладку, видим -- что-то полезное, даем команду "добавить таб в нужную группу". Создается правило, по которому новые странички с этого сайта будут открываться в нужной группе и знаем, где искать новые табы. Новые табы как-то подсвечиваются, чтобы было видно размер странички (длинная/короткая) и ее устаревание (сколько прочитано, как долго читается эта страничка).

Подозреваю, что подобное можно сделать расширением. Нужно уметь "отсоединять" вкладки в нужное окно-"группу", создавать автоматически правила, "в какой группе открывать вкладку", подсвечивать актуальные вкладки.

Модель расширений в FF не нравится: это интерпретируемый JS, можно установить конфликтующие расширения, ломающие отображения всего интерфейса (который на chrome=XUL+JS)

Что мешает иметь "компилируемые" расширения? Слишком "Динамический" JS, на котором расширения написаны.

Кеш и работа с памятью работают криво, ждем наверно нормального аллокатора памяти и сборщика мусора.

Частично выручает внешний SQUID (под виндой, он, зараза, какой-то итальянской сборки периодически валится из-за нехватки файлдескрипторов).

Нужен какой-то кроссбраузерный фреймворк с тестами, на качество рендеринга и работу DOM/JS.

Да, а Scrapbook по идее должен быть реализован не на уровне браузера с его DOM (хотя "захватить выделение" в ScrapBook -- полезная фича), а на уровне кеша. Типа SQUID'а, прозрачно кеширующего "вообще всё", но с уровнем хранения как дерево объектов в git, и кеш, адресуемый по содержимому (разные файлы с одинаковым контентом -- один объект), чтобы можно было дать команду SQUID'у "страничка должна застрять в кеше и не обновляться, новые обновления делают новую версию странички", и получим ScrapBook в кеше-прокси, общем для всех браузеров. То есть, Scrapbook --архив с разной глубиной хранения для разных страничек, новые версии странички с тем же URL делают новую версию, старые странички "из ScrapBooka" "застревают в кеше". И естественно, какой-нибудь tracker/beagle по содержимому Scrapbooka, архивирование/разархивирование/удаление контента старых страничек, оставив метаданные о ней в ScrapBooke (включая URL, чтобы можно было перекачать страничку заново если понадобится) .

А так пока Kestrel рулит (правда, там тоже много потрохов на JS написано, см. профиль Оперы). Еще бы они API опубликовали для создания расширений, вроде ScrapBooka.

>компилированный JS/расширения

вот тамарин допилят — и будет. %-)

>Вот у меня в браузере обычно открыто 100+ вкладок

герой. я сей подвиг могу только в Опере совершить (столько примерно и открыто). лис уже при 30–40 становится настолько глубокомысленным, что ооочень печально. (лис свежепрепарированый, расширений всего парочка — imglikeopra, adblock, tabmix+… да и всё, пожалуй).

>Читаем вкладку, видим — что-то полезное, даем команду «добавить таб в нужную группу». Создается правило, по которому новые странички с этого сайта будут открываться в нужной группе и знаем, где искать новые табы.

вот это Опере не помешало бы. detach tab не шибко удобный.

>Новые табы как-то подсвечиваются, чтобы было видно размер странички (длинная/короткая) и ее устаревание (сколько прочитано, как долго читается эта страничка).

«устаревание», вроде, есть. видел такое расширение. %-)

>правда, там тоже много потрохов на JS написано, см. профиль Оперы

ы? например? opera:config. и? больше не нашёл.

>еще бы они API опубликовали

нет, не было, и никогда не будет. пока Опера не станет опенсорц. а она не станет.

лучше бы нормальный JS debugger прикрутили и возможность рулить content blocker'ом. больше Опере ничего и не надо.

>сей подвиг могу только в Опере совершить (столько примерно и открыто). лис уже при 30–40 становится настолько

А потом еще запускаем Оперу и Firefox одновременно, например сайт потестить Ж)) и смотрим как они дерутся за своп. Хотя Опера сама по себе нормально тянет под 200 вкладок.

А под оффтопиком вообще все медленно и печально: нехватка GDI handles, из-за чего иконки становятся черными и иконки и окошки не перерисовываются. Я уже заранее знаю когда приложение на .NET или Delphi -- они жрут эти GDI handles как за себя кидают.

По идее, в Qt 4.3 сделали non-native widgets, если Опера перейдет на него, должно полегчать. Ну или compositing manager нужен вроде Берила или там Dwm в Viste. >лис свежепрепарированый, расширений всего парочка

Угу, чтобы и конфликтов между расширениями не было и интерпретировались они с пристойной скоростью. И многопоточность, если она в Лисе где-то есть, идет лесом -- все равно однопоточный интертрепатор тормозит все.

>Читаем вкладку, видим — что-то полезное, даем команду «добавить таб в нужную группу».

В смысле, идея сделать "вкладки вкладок". Чтобы браузер подсвечивал где чего изменилось и какую группу-тему читать. И обрабатывал automagically.

>>правда, там тоже много потрохов на JS написано, см. профиль Оперы

>ы? например? opera:config. и? больше не нашёл.

см. ~/.opera/browser.js, User-JS, виджеты. В Firefox'е , конечно лапши больше. С одной стороны, конечно везде RDF, модель хранения моощная и просто прикрутить какой-нибудь Semantic Web, сделать базу знаний из Firefox'а. С другой стороны, все эти *.dat в профиле Оперы похожи на "скомпилированный" RDF в binary-blob формате, эффективнее грузиццо и быстрее работает.

>>еще бы они API опубликовали

>нет, не было, и никогда не будет. пока Опера не станет опенсорц. а она не станет.

вроде для виджетов опубликовали. Но для плагинов нужно подробнее, например как плагин Obook работает? API -- ХЗ.

по идее, Mozilla служит чем-то вроде reference implementation нормального браузера. Слишком много вещей в общем виде: RDF, JS для обработки DOM/интерфейса, XUL тот же, расширения через интерпретатор. Если бы эти вещи были компилируемы во что-то более эффективное, было бы полезнее.

Например, использовать внутри Lisp и переписать XUL/JS потроха на нём. Использовать везде ленивые вычисления для кеширования, closures, естественный параллелизм. Сделать транслятор JS->Lisp, лениво кешировать эти скрипты.

Или перенацелить тот же JS на LLVM: получим готовый JIT, GC, LTO, компилируемость расширений. И кеш нормальный прикрутить.

И тесты составить с бенчмарками, которые должны работать на Mozillе и лучше работать на новом мега-браузере.

>м. ~/.Opera/browser.js, User-JS, виджеты.

это к брофзеру отношения не имеет, в отличие от функционала ff extensions. browserjs тупо правит некоторый входной жабаскрипт. а userJS — это вообще просто улучшеный greasemonkey, без которого всё работает. %-) причём ни у того, ни у другого доступа ко «внутреннему API» нет, потому что нет самого API. %-)

>вроде для виджетов опубликовали.

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

>например как плагин Obook работает?

лучше не знать. это не плугин, это хак. %-)

а API — только стандартный старый нетшкафовский. никакого другого API нет by intention.

ну сказали же — допилят тамарин и будет всем щастье.

>причём ни у того, ни у другого доступа ко «внутреннему API» нет, потому что нет самого API. %-)

в каком-то смысле это правильно -- меньше шансов что-то сломать, как конфликтующими расширениями в FF. Браузер должен быть Just Browser.

>нет там ничего особого. открой виджет как обычную страницу.

угу, и увижу обычную страничку + JS, который дергает за это "недоAPI"

>>например как плагин Obook работает?

>лучше не знать. это не плугин, это хак. %-)

оно там случайно не нажимает программно на кнопки Save as, а то такое ощущение сложилось ? :))

>ну сказали же — допилят

просто вдруг подумалось (с) что JS вообще не лучший язык для расширений. И бенчмарки на shoutout.com фиговые, то ли язык кривоват то ли реализация. Какой-нибудь простой браузер с корректно-верстачным движком и простым многопоточным встраиваемым язычком с простым понятным API зарулил бы "расширения на JavaScript".

>меньше шансов что-то сломать, как конфликтующими расширениями в FF

конфликтующие userJS ломают всё не хуже. %-)

>и увижу обычную страничку + JS, который дергает за это «недоAPI»

да. потому что нет никакого «спецAPI». есть таки да — «недо» обломок. который API назвать клава не повернётся. я ж говорю — окромя persistent storage да разрешения делать XMLHttpRequest в разные места ничего там больше и нет, в общем-то.

>оно там случайно не нажимает программно на кнопки Save as, а то такое ощущение сложилось ? :))

я тут боюсь соврать, но насколько помню, именно нечто в этом роде. вроде бы автор где-то плакался по этому поводу.

но говорю сразу — ссылок не дам. всплыло откуда-то из глубины моска без указания origin — не нужен мне этот плуг по очевидным причинам. %-)

а зачем многопоточный? async DOM manipulation? в общем и целом — не особо надо.

а JS я бы сменил на Lua, да. %-) LuaJIT — зверюка. и API настолько просто, что проще и некуда.

вся проблема в том, что нет чистого layout/rendering engine с поддержкой всего, чего надо, но без перделок. %-)

кстати, SpiderMonkey — многопоточный. %-)

>а зачем многопоточный? async DOM manipulation

чтобы не как в фоксе, пока грузится одна вкладка, остальные тормозят. подвисает скрипт на одной вкладке, подвисает и весь бровсер (с GUI на XUL+JS)

>а JS я бы сменил на Lua, да. %-) LuaJIT

Ну вот tcl/tk тоже встраивается относительно просто, хотя Lua симпатичнее :)

>вся проблема в том, что нет чистого layout/rendering engine с поддержкой всего, чего надо, но без перделок. на tcl/tk+С есть виджет TkHTML и тестовый браузер hv. Оно прошло вроде HTML4,CSS2/3частично, про Acid не помню, но что-то близко. JS там нет, как раз простой движок без перделок. DOM в каком-то виде есть, раз есть CSS2.

По настоящему круто будет, когда JS будет кешироваться сразу в откомпилированном JIT виде :)

err, появился там какой-то упрощенный EcmaScript.

ссылко: http://tkhtml.tcl.tk/hv3.html

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

в Опере тоже. грузиццо педивикия — все нервно курят. правда, со скриптами в Kestrel стало полегче: вполне можно брофзить даже на моём pIII/600, пока в другом окне ray tracer рэи трейсит. %-)

>хотя Lua симпатичнее

а также меньше и быстрее. %-)

>По настоящему круто будет, когда JS будет кешироваться сразу в откомпилированном JIT виде :)

уже есть. ActiveX называется. %-)

зыж надо собрать снапшот тамарина. посмотреть, что там буржуины натворили…

да, рейтрейсер наконец-то нормально заработал, как раз нормально видно

>зыж надо собрать снапшот тамарина. посмотреть, что там буржуины натворили…

Угу, и потестить как-то отдельно JS движки из списка в See Also: http://www.adaptive-enterprises.com.au/~d/software/see/

мерял как-то DScript из D language , как раз на рейтрейсинге, получилось что-то на уровне KJS/ Opera <=9.2

>>По настоящему круто будет, когда JS будет кешироваться сразу в откомпилированном JIT виде :)

>уже есть. ActiveX называется. %-)

Оно not safe. Его по хорошему надо в closur'ах запускать, а closur'ы запускать в многопоточных sandbox'ах.

у DScript был fatal flaw: кривые closures. как сейчас — не знаю.

а тестить лень — подожду, пока кто-нибудь другой сделает и результаты выложит. %-)

NJS тестить смысла нет — оно издохло в страшных мучениях года три-четыре назад.

KJS же собрать отдельно от всего, помнится, мне не удалось.

щаз качаю снапшот SEE. найти бы ещё хороший, не искуственный бенчмарк какой… хотя и рейтрэйсер сойдёт, в принципе. может, ночью сделаю gcc -O3, погоняю…

каждую страницу — в отдельный sandboxie, и все дела.

Err, DMDScript, не DScript. Его можно было встроить вместо JScript и померять разницу. Интересно померять Rhino (который на Java) в контексте JIT, толк ему от JITa будет?

Вообще да, не хватает нормальных, не искусственных бенчмарков. Типа DOM перебрать, AJAX/jQuery/GWT/YWT, итп. А их отдельно от браузера тоже толком не померяешь.

В принципе, в hv3 допилить нормальные кодировки, отрефакторить интерфейс с JS движками чтобы можно было просто любой движок всунуть, сделать чтобы storage у него составной был, двухуровневый 2 шт. (общий кусок у "браузера" на все "вкладки вкладок" и по одному на каждую "группу"), кеш-прокси там какой-то свой мини в составе есть, и уже можно работать :-)

WebKit тоже интересно выглядит -- storage тоже в sqlite, можно запускать несколько "групп" в разных окнах с разными базами. И detach tab/collect есть.

БашОрг правда неправильно отрисовывается ни в hv3, ни в WebKit: в WebKit (Safari 3.0.3/win) буквы налазят друг на друга, а в hv3 корректный рендер, но борода с кодировками.

DMDScript, да. который Уолтера Брайта. какая разница, насколько он быстр, если он поломаный? %-)

зыж как-то с год или два назад я наступал на hv3. выглядело плачевно. щаз глянул — заявляют на сайте много. скачать, что ли?

а вот если баш не рисуют — нафига такие брофзеры нужны? %-)

>типа DOM перебрать, AJAX/jQuery/GWT/YWT, итп

а их и нет смысла мерять отдельно. скажем, мильён s += «.» спидерманки делает у меня за секунду примерно. а сгенерить мильён дом-нодов? это уже комплексный тест — js и брофзера. сколько тут js не ускоряй — всё равно основные тормоза в layout engine.

>который Уолтера Брайта. какая разница, насколько он быстр, если он поломаный? %-)

ну в Safari тоже поломанный onLoad(), запускается до загрузки страницы и тесты непонятно что меряют, так что теперь, быстрым браузером теперь не пользоваться ? :))

А вообще нужен какой-то кроссбраузерный бенчмарк. На JS, DOM, скорость тех же AJAX/jQuery/etc., соответствие рендеринга W3C-шному, качество и количество quirks и т.п. :)) ЛОР кстати нормально отрисовывается Ж) Шрифты корявые и кодировки не настраиваются, а так вроде ничего. Фреймы где отрисовываются, где глючат.

К черту firefox с его вкладками, блин за неделю работу без выключения файера, вкладок скопилось.... щас посчитаю.... 109 открытых вкладок.
Откроешь страничку думешь ладно минут через 5 почитаю, открываешь новую вкладку через некоторое время еще, а про первые уже забываешь, одних рутубе уже штук 10 и доков с сайта оракла штук 20
а памяти то съел "скотина"
virt 453M
res 244M
shr 28796

>сколько тут js не ускоряй — всё равно основные тормоза в layout engine

насколько я понимаю pipeline: HTML разбирается в DOM, запускается JS onLoad() итп, DOM в Мозилле хранится с нодами, аннотированными RDF. Потом layout engine перебирает по нодам с нужными RDF все что влазит в окошко. То есть, тормозит как раз переборщик узлов и RDFDataSource. Еще учитывая, что до полной загрузки+запуска JS DOM толком не известен. То есть тормоза JS -- критические для pipeline.

> ilnurathome (*) (18.11.2007 22:54:44)
и при этом 24 дополнения кошмар