Firefox 3 - Minefield

[Kajover]

Hey. Ich habe mir vor ein paar Minuten gedacht... (nicht lachen^): "Warum ist Safari so schnell... ich wäre sonst bei Firefox geblieben" Da fiel mir ein das ich hier im Forum gelesen habe, dass Firefox irgendwann (ich glaube v3) in Cocoa erhältlich sein wird. Nach einer Googlesuche kam ich auf diese Seite (vielleich kennt ihr die noch nicht)

http://weblogs.mozillazine.org/josh/archives/2006/08/cocoa_firefox_nightly_builds_o.html

Ich kann nur eins sagen, es ist verdammt schnell und ich freue mich schon darauf Safari verstauben zu lassen^ Nur der Name "Minefield" gibt mir zu denken... NEIIIN klick da nicht hin... 1 Feld bis zur Mine. Minesweeper lässt grüßen. Na gut viel Spaß beim Testen.

 

[selcuksinan]

Wow, die Seiten laden wirklich schneller. Leider funktionieren die PlugIns mit Minefield nicht.

 

[bmonno]

ich setze den schon seit einigen Wochen regelmässig ein und bin auch sehr angetan. Abstürze habe ich noch nicht gehabt, allerdings ist manchmal eine neue Versione (zumindest an der Oberfläche) schlechter als vorhergehende. Also die funktionierenden behalten!

Ansonsten wirklich sehr schnell und keine Probleme im Netz.

 

[Kajover]

Hat jemand eine Ahnung wann der offiziell rauskommen wird - oder Firefox 2?

• Einziger Nachteil ist, dass keines der Plugins funktioniert ansonsten hatte ich bis jetzt noch keinen Absturz und es ist wirklich schnell!

 

[quomodonam]

Entschuldigung, könntet ihr kurz, aber eingängig einem DAU Näheres erklären? Was hat es mit diesem Firefox Minefield auf sich?

 

[Kajover]

Wie ich oben besoffen gepostet habe, es handelt sich hierbei um eine Firefoxversion die komplett in Cocoa geschrieben ist, demnach nativ vom System unterstützt.

 

[quomodonam]

Ähem, ich schrieb: DAU.

 

[Haro]

es fehlt noch an Unterstützung im Automator für Firefox und die Möglichkeit Widgets anzeigen zu lassen...

Dann wäre Safari wirklich absolut sinnlos!

 

[Aronnax]

Vielleicht mal eines vorweg,
es ist eine wirklich dumme Idee die Cocoa Version zu ziehen, ausser man kennt sich gut mit Firefox aus - sie liegt nicht ohne Grund im ..nightly/experimental/.. Ordner
auch kann man damit noch so gut wie nichts sehen, was wirklich so in Firefox 3.0 kommen wird - ausser vielleicht die Formularelemente im Aqua Design (die werden aber auch noch anders)
-----------
"Hat jemand eine Ahnung wann der offiziell rauskommen wird - oder Firefox 2?"
FF 2.0 Ende Oktober wahrscheinlich
-------
"es handelt sich hierbei um eine Firefoxversion die komplett in Cocoa geschrieben ist"
stimmt so nicht - das in etwa kommt:
Firefox 3.0 wird auch Cocoa benutzen, bleibt aber bei seinen XUL Lösungen.

Cocoa ist besser von Apple gepflegt, den einen oder andern Bug wird diese Umstellung quasi automatisch fixen, ansonsten ist nur diese Umstellung mehr oder weniger unwichtig. (bezogen auf aktuelle Lösungen mit Carbon)

Die wirklich wichtigen Dinge, kann man vielleicht nachvollziehen, wenn man sich vor Augen führt was Cocoa allgemein für die Programme dieser Bauart bedeutet.
Dort schreibt man eben nur ein paar Zeilen Code und dann werden umfangreiche, von Apple optimierte, Libraries angesprochen. In denen diverse Trickereien benutzt werden, um die GUI zu beschleunigen oder bestimmte OS X Fähigkeiten automatisch zur Verfügung gestellt werden z.B. Dienste, Rechtschreibprüfung in Formularfeldern u.s.w….
Auch ein Cocoa Firefox wird diese Libraries nicht benutzen, aber sie werden die gleichen Methoden einbauen, um das gleiche Ergebnis zu bekommen - insbesondere für GUI Beschleunigungen - z.B. alles in OpenL-Container um an Grafikkartenfunktionen heranzukommen. Eine Umstellung von Quickdraw auf Quartz - insbesondere wichtig für die Textdarstellung etwas Geschwindigkeit.
Cocoa macht es dann deutlich einfacher an Systemfunktionen heranzukommen - sowas wie die Dienste müssen sie trotzdem selber hinzufügen, (würde aber auch mit Carbon gehen)

Zusätzlich kommt noch Cario hinzu - sowas wie Quartz, nur Plattforumabhänig.
Ist alles noch in keiner Testversion auch nur annähernd zu sehen. Wenn es den fertig ist, sollte das Ergebnis von einer Lösung, die die Apple Cocoa Libraries benutzt, kaum zu unterscheiden sein. Insbesondere bezogen auf GUI Geschwindigkeit. Er bleiben aber alle FF Erweiterungen erhalten - wegen XUL - und mit Cario wird es dann möglich sein Plattformübergreifend diverse GUI Effekte umzusetzen . z.B. sowas ein das Dock oder die Effekte die man bei Dashboard sehen kann.
Eine Webseite z.B. die mit grafischen Effekten verkleinert, sich dreht und wendet und das dann alles mit OpenL beschleunigt, wird dann möglich sein z.B. für Tab-Erweiterung, oder was man sich sonst noch ausdenken kann.

Dann gibt es eine datenbankbasierte Bookmark/History/Feed Verwaltung - "Places" genannt - ist ja bereits in den Vorversionen drin, aber die GUI wird wohl sicher noch vollkommen anders werden - ist noch sehr unvollständig und buggy - ein Grund unter anderen, warum es nicht, wie unsprünglich geplant bereits in der 2.0 erscheint

------
zu "Leider funktionieren die PlugIns mit Minefield nicht."
du meist wohl die Erweiterungen - hebel die Versionsverwaltung aus und sie werden funzen - alle bis auf diejenigen, die auf Funktionen zugreifen die mit "Places" anders gehandhabt werden - also z.B Bookmarks
------

"Unterstützung im Automator" - wird wohl kommen
------

"die Möglichkeit Widgets anzeigen zu lassen."
wenn Dashboard Widgets gemeint sind, dann sicher nicht

-----
"könntet ihr kurz, aber eingängig einem DAU Näheres erklären?"
Neee ;-)



MfG
Aronnax

 

[max powers]

Aronnax - derber Typ.
Du hast es einfach voll drauf.

 

[Haro]

"die Möglichkeit Widgets anzeigen zu lassen."
wenn Dashboard Widgets gemeint sind, dann sicher nicht

ja, es sind Dashboard Widgets gemeint.
-> Das ist schade, denn wenn man sich selbst ein kleines Widget bastelt, dann möchte man das schon erst kurz testen bevor man das im Dashboard ausführt. Dann wäre der ein oder andere doch wieder auf Safari angewiesen.

Zum besseren Verständnis: Dashboards Widgets lassen sich auch in Safari ausführen.

Mein Ziel wäre eigentlich auf nur einen Browser angewiesen zu sein. (Safari ist davon im Gegensatz zu Firefox sehr weit entfernt)

P.S. ich dachte sogar ich hätte genau dieses Problem schon auf der Bug Liste von Firefox gesehen.

 

[Black Smurf]

Ähem, ich schrieb: DAU.

Das mysteriöse "Cocoa" ist die in OS X enthaltene Programmbibliothek für graphische Benutzeroberflächen (stell dir so ne Art Bauteilsammlung für Fenster und Steuerelemente vor). Alle Programme von Apple verwenden Cocoa, somit haben auch andere Programme, die es verwenden den gewohnten "OS X-Look". Ausserdem ist Cocoa (natürlich) sehr gut in OS X integriert und hat von daher normalerweise Geschwindigkeitsvorteile gegenüber eventuellen eigenen Bibliotheken die ein Programm (wie z.B. Firefox) mitbringt (aber da gibt es Ausnahmen wie NeoOffice: da wird Cocoa über eine ätzend langsame Schnittstelle - C++ zu Java zu Cocoa? - angesprochen, weshalb NeoOffice zwar "OS X"-mäßiger als OpenOffice aussieht aber langsamer ist).

Also müsste in der Theorie (ich hab's nicht ausprobiert) eine Firefox-Version, die Cocoa verwendet schneller (vor allem im Starten) und optisch besser in OS X integriert sein, als das "normale" Firefox.

Klar soweit?

 

[Aronnax]

P.S. ich dachte sogar ich hätte genau dieses Problem schon auf der Bug Liste von Firefox gesehen.

Für Dashboard hat sich Apple ja extra einige "propitäre" spielereien fürs Webkit ausgedacht.
So weit ich weiß, hat es Apple so entworfen, dass es theoretisch auch ein offizieller Webstandard werden könnte und an sich sollte man es auch in Gecko einbauen können.
Würde es nicht vollkommen ausschliessen wollen, aber ist doch sehr, sehr unwahrscheinlich, dass sich jemand hinsetzt und das ebenso in Gecko einbaut.
Wichtig ist es ja ganz bestimmt nicht ;-)

 

[Aronnax]

Das mysteriöse "Cocoa" ..............

"in OS X enthaltene Programmbibliothek für graphische Benutzeroberflächen" ist eine Sache von Cocoa, aber nicht nur
----
"Alle Programme von Apple verwenden Cocoa"
der Finder z.B. ist mit Carbon gemacht

---
"Ausserdem ist Cocoa (natürlich) sehr gut in OS X integriert und hat von daher normalerweise Geschwindigkeitsvorteile gegenüber eventuellen eigenen Bibliotheken die ein Programm"
was heisst schon integriert - drin ist drin -
es ist schnell oder langsam, wenn man es optimiert oder eben sein lässt

 

[Kajover]

Wie sieht es eigentlich mit Camino aus? Wird es eingestellt?

Safari: schnell, zu uninnovativ in Richtung Plugins
Firefox: langsam, innovativ ...
Camino: schnell, gecko, keine FF-Plugins - ein Safari mit Gecko sozusagen

 

[quomodonam]

Klar soweit?

Merci! (Auch an Aronnax)

 

[KAMiKAZOW]

Wie sieht es eigentlich mit Camino aus? Wird es eingestellt?

Nein. Firefox wird wohl nie das Maß an Mac-Integration aufweisen wie Camino. Und ob Automator in Firefox unterstützt wird, wage ich mal auch zu bezweifeln. Das Interface von Firefox wird auch weiterhin in XUL geschrieben sein. Das Interface von Camino ist dagegen wie ein ganz normales Mac-Programm in Cocoa programmiert.
Der Cocoa-Port von Firefox dient dazu, die Teile von Firefox, die aktuell Carbon ansprechen auf Cocoa umzubiegen. Also das, was Camino schon lange gemacht hat. Für Camino bedeutet das, dass in Zukunft (Camino 2.0 oder so) Camino noch mehr Programmcode mit Firefox teilt. Das entlastet die Camino-Programmierer, weil viele neue Mac-Verbesserungen "unter der Haube" quasi schon gratis dabei sind. Vorher musste immer Camino die Pionierarbeit leisten und Firefox (und davor Mozilla) hat diese dann übernommen. Das führte dazu, dass Camino nur sehr langsam entwickelt werden konnte. Nun leistet ein anderes Team die Pionierarbeit und die Camino-Jungs können sich mehr auf andere Sachen konzentrieren, die Firefox wahrscheinlich nie haben wird:
Aktuelle Vorab-Versionen von Camino 1.1 nutzen die Rechtschreibe-Prüfung von OSX. Im Ggs zu Firefox (und auch Thunderbird) müssen also keine Deutschen Wörterbücher nachinstalliert werden.
Für die Zeit nach Camino 1.1 ist es vorgesehen, dass die Integration des systemweiten Schlüsselbunds verbessert wird – mit dem Ergebnis, dass wahrscheinlich Safari und Camino die Passwörter teilen können, wenn man denn will.

Zu der Frage wann Firefox 3 erscheint: Frühling/Sommer 2007. Auf http://www.mozilla.org/projects/firefox/roadmap.html steht zwar 1. Quartal, aber bisher wurde noch jeder Firefox-Release der letzten Zeit nach hinten verschoben.

 

[Aronnax]

@KAMiKAZOW

Firefox stellt auf Cocoa um an viele Funktionen von System leichter ran zu kommen (mit Carbon eben sehr viel aufwendiger)
Das Problem zur Zeit ist, das sie gar keinen Cocoa Code benutzen können,
sowas wie "Vorher musste immer Camino die Pionierarbeit leisten" stimmt deshalb überhaupt nicht, weil sie Camino Lösungen schlicht nicht übernehmen können.
mal ein Beispiel dafür:
Die Rechtschreibprüfung von Firefox 2.0 wird deshalb noch eine Eigenentwickung. Im Cocoa FF 3.0 stellen sie auf die vom Mac-System um und dann greifen sie natürlich auf den fertigen Cocoa Code von Camino zu. Natürlich, schon allein deshalb, weil es in der Regel die gleichen Leute sind, die an Camino und Firefox basteln. Für welchen Browser sie es zuerst basteln ist ja auch recht egal, der entscheidene Unterschied ist das Mozilla einige Vollzeitprogrammierer an die Lösungen dransetzt. Camino ein reines Freizeitprojekt ist. Die Arbeit wird also viel einfacher für sie und Camnio wird sich durch die FF Cocoa Umstellung indirekt sehr verbessern.

Unter der Haube sind FF und Camino sowieso noch viel ähnlicher. Wenn sie Gecko von Quickdraw auf das modernere Quartz und Cairo umstellt wird Camino quasi automatisch nachziehen.

Ansonsten wir FF wohl alle möglichen Systemfunktionen bekommen, aber das sie z.B. auf das Schlüsselbund zugreifen glaube ich nicht.

Sowieso tun sie ja für das FF 2.0 Redesign alles, um den Browser zu verschandeln bzw. nicht Mac-like zu bauen. Oder wenn sie die "Places" Lösung so lassen, wie zur Zeit in den Entwickertestversionen, wird das auch nicht Mac-like.
An sich könnte die Luft für den besser an den Mac angepassten Camino sehr, sehr dünn werden. Ob das wirklich passiert ist vollkommen offen und ist mehr eine Frage wir sie bei FF die neuen Funktionen gestalten und weniger, welche Technik sie dafür benutzen.

 

[KAMiKAZOW]

Das Problem zur Zeit ist, das sie gar keinen Cocoa Code benutzen können,

Natürlich können sie das. Carbon und Cocoa kann gemischt werden. Die Wartbarkeit leidet allerdings darunter, weshalb man sich für einen kompletten Schnitt entschieden hat.

sowas wie "Vorher musste immer Camino die Pionierarbeit leisten" stimmt deshalb überhaupt nicht, weil sie Camino Lösungen schlicht nicht übernehmen können.

Wat? Dass Firefox eine Mach-O-Anwendung ist, ist der Pionierarbeit von Camino (bzw. damals noch Chimera genannt) zu verdanken und er Cocoa-Code für FF3 basiert auf dem Code von Camino.

Die Rechtschreibprüfung von Firefox 2.0 wird deshalb noch eine Eigenentwickung.

Die Prüfung stammt aus NVU, die wiederum eine erweiterte Thunderbird-Komponente ist, die wiederum auf der Prüfung von OpenOffice basiert.
So viel zur Eigenentwickung....

dann greifen sie natürlich auf den fertigen Cocoa Code von Camino zu.

Ja, wieso widersprichst Du mir dann weiter oben?

Natürlich, schon allein deshalb, weil es in der Regel die gleichen Leute sind, die an Camino und Firefox basteln.

Das stimmt nicht. Josh Aas wurde durch die Mozilla Foundation von Camino zu Firefox abkommandiert, um eben diesen FF-Port durchzuführen. Mike Pinkerton arbeitet (neben seiner Hauptbeschäftigung bei Google) dagegen nur an Camino und nicht an Firefox.

Die Arbeit wird also viel einfacher für sie und Camnio wird sich durch die FF Cocoa Umstellung indirekt sehr verbessern.

Hab ich doch geschrieben. Also wieso tust Du so als müsste man mich verbessern?

Unter der Haube sind FF und Camino sowieso noch viel ähnlicher. Wenn sie Gecko von Quickdraw auf das modernere Quartz und Cairo umstellt wird Camino quasi automatisch nachziehen.

Hab ich was anderes behauptet?

 

[Aronnax]

@ KAMiKAZOW
siehe:
http://weblogs.mozillazine.org/josh/archives/2005/12/why_cocoa_widgets.html
Why Cocoa Widgets?
First, Cocoa widgets can use both the Cocoa API and the Carbon API. Carbon widgets cannot easily use the Cocoa API.

an anderen Stellen erwähnt er, dass sie zur Zeit gar keinen Cocoa Code in FF benutzen - auch wenn es theoretisch gehen würde.

---------------

"ist der Pionierarbeit von Camino"
Was soll das eigentlich heissen?
Es sind Personen dahinter und das besondere von Camino und Firefox war ja immer (es gab und gibt ja auch diverse andere Gecko Ableger) das sie von Mozilla Entwicklern gestartet und getragen worden sind - wie willst du überhaupt sowas trennen - z.B. morgens sind sie böse Mozilla Leute und abends gute Camino Pioniere, oder wie? ;-)

übrigens
... eine Mach-O Carbon Anwendung ...
-----
"Die Prüfung .." und ist NVU etwa kein Mozilla Ableger ... sollte auch nur deutlich machen das sie für FF 2.0 nicht die Lösung von Apple benutzen und auch nichts von Cocoa Camino Code

----
Josh Aas wurde wegen seiner guten Arbeit an Camino (in seiner Freizeit) von Mozilla eingestellt. Für Firefox Kram und Camino ist weiter nur ein Freizeitprojekt. Wenn er jetzt etwas baut, das ohne Änderungen für beide funzt, um so besser ;-)

Mike Pinkerton - Es gibt ja noch andere wichtige Mozilla Entwickler die bei Google arbeiten. Nur sagen sie nie, was sie genau machen. Google ist ja noch paranoider als Apple. Soll heissen, bisher sagt niemand genau, was sie so treiben. Würde mich echt interessieren, woher du das Wissen willst?

------
"Hab ich doch geschrieben. Also wieso tust Du so als müsste man mich verbessern?"

Das meiste stimmte ja, nur die Begründungen in der Regel nicht. Auch kann man vieles gar nicht trennen und irgendeinem Projekt zuschreiben.

Sowas wie
"Vorher musste immer Camino die Pionierarbeit leisten und Firefox (und davor Mozilla) hat diese dann übernommen."
stimmt bisher einfach nicht - erst FF 3.0 wird Camino Lösungen übernehmen können