ARCHIV 1999-2006

ARCHIV :: # 3703

Ehekrach zwischen Apple und KDE

Nehmen ist seliger denn geben?

Autor: flo - Datum: 12.05.2005

Wer, aus welchen Gründen auch immer, die Entwicklung der diversen Browser verfolgt, den wird es kaum verwundern, dass die Beziehung zwischen Apple und KDE, genauer dem Safari- und dem KHTML-Team, zusehends schlechter wird. Für uns anderen fasst c|net in einem ausführlichen Artikel das ganze Dilemma zusammen. Was sichtlicherweise ein sich stetig füllendes Fass zum Überlaufen brachte, sind Hyatts Bemühungen (und sein Erfolg dabei), mit Safari den Acid2-Test zu bestehen. Als einziger Browser. Schon erstaunlich, wie sehr sich sämtliche Browser an einem Smilie die Zähne ausbeißen können, sollte man unbedingt selbst einmal testen (siehe Link). Hyatt postete sämtliche dafür nötigen Patches in seinem Blog. Das führte unter anderem zu mehr als bitteren Reaktionen auf den KHTML-Developer-Seiten von Zack Rusin und später nochmal von "carewolf", was wiederum Hyatt zur Frage verleitete: "What can Apple do better?" Genau darauf antwortete wiederum Rusin in einem Beitrag mit nicht minder drastischen Aussagen: "We have absolutely no saying in the way you develop your version of KHTML and you don’t participate at all in the way we develop KHTML." Die Krone könnte dem Ganzen die von c|net erwöhnte E-Mail eines Safari-Developers aufsetzen, in dem vorgeschlagen wird, KDE solle doch einfach ihren Code-tree zugunsten Apples WebCore aufgeben. Mal eben so. Was Rusin lustigerweise in seinem Beitrag vom 28.4 schon so ähnlich befürchtete: "What’s most probably going to happen is that one of us will simply reimplement it from scratch".

Nichts in diesem Schlagabtausch klingt nach versöhnlichen Fronten. Direkte Auswirkungen dürfte das alles für uns User nicht haben, denn -- und das dürfte viel zur desolaten Stimmung der KDE-Entwickler beitragen -- Apple erfüllt scheinbar alles, was sie im Rahmen der LGPL eben leisten müssen. Nur eben nicht mehr. Dabei funktioniert Apples Zusammenarbeit in anderen ähnlichen OpenSource-Projekten gut, oder zumindest besser (GCC, Darwin), zumindest lässt sich dies aus zahlreichen Kommentaren schließen, in denen eine bessere Kommunikation gefordert wird.

Als Außenstehender liest es sich auf alle Fälle nicht besonders vorteilhaft für Apple: Desperate KDE-Entwickler, die sich nichtssagenden Anmerkungen in Bug-Reports ausgesetzt sehen und selbst NDA-Erklärungen unterschreiben würden, wenn sie nur mal ein paar Einblicke in Apple-Unterlagen gewährt bekämen. Andererseits sind alle Änderungen, die eben nicht nur KHTML, sondern auch KWQ (Qt) betreffen, wegen ihrer Plattformabhängigkeit nur schwer "zurückzuimplementieren" -- was man auch schon vorher hätte wissen können. Nun mag ja Apple (wie jedes größere kommerzielle Unternehmen) für wahre Verfechter von OpenSource eh schon kein geliebtes Kind sein, doch jeder weitere Fleck auf der Weste, wer auch immer dafür verantwortlich sein mag, wird das Verhältnis OpenSource/Kommerz nicht unbedingt vertiefen. Beiden Seiten täte aber genau das, ein gutes Verhältnis, nur gut.

Kommentare

Seeliger?

Von: Lanx | Datum: 12.05.2005 | #1
Was würde Uwe Seeler dazu sagen?

Die Welt wäre gut, wenn ...

Von: Apfelsurfer | Datum: 12.05.2005 | #2
... alle gut zueinander wären. Wenn sich allerdings die KDE-Entwickler mokieren, dass Apple genau das macht, was sie müssen - nur nicht mehr, dann fällt es mir schwer hier irgendwo Verständnis für die OS-Programmierer zu entwickeln. Wer sich mit Großunternehmen einlässt und auf deren Goodwill baut, ist mMn naiv - und es so weltbilderschütternd diese Erkenntnis auch sein mag, so bleibt doch irgendwie der Gedanke "Selbst schuld" hängen.
S

Uns Uwe

Von: Klaus Major | Datum: 12.05.2005 | #3
Vielleicht "Barbara Kuchen"? :-)


Gruß

Klaus

P.S.
"Safari 2" hat aber leider hier soeben furchtbar vergeigt beim Acid2 Test :-/

Irgendwie als Außenstehender schwer nachvollziehbar

Von: thomm | Datum: 12.05.2005 | #4
Eigentlich weiß ja jeder Programmierer, der schon einmal Source-Code von anderen Programmieren als Basis bekommen hat, dass oft selbst neu schreiben weniger Arbeit bedeutet, als sich erst in den Programmierstil des "Alten" einzugewöhnen.

Man kann ja etwas lästerhaft fragen: Weshalb schaffen denn die Programmierer von Apple es, die über längere Zeit entwickelte khtml-Engine so schnell zu verstehen, und zu verbessern aber in der anderen Richtung gibt es solche Probleme?
Schließlich passen ja beide Seiten den vorhandenen Code auf die Hardwarebasis an!! Also irgendwo ist da etwas der Wurm drin oder es sind doch nicht immer alle soooo die Supercoder wie sie meinen und bekommen es zu spüren (Kann sich jeder seine Seite aussuchen ob nun Apple oder die OSS-ser)

Aeh. Ja.

Von: Soeren Kuklau | Datum: 12.05.2005 | #5
""Safari 2" hat aber leider hier soeben furchtbar vergeigt beim Acid2 Test :-/"

Oehm, das ist richtig, sollte aber nicht ueberraschen. Safari 2 war schon laengst intern fertig, als Hyatt mit den Acid2-Patches angefangen hat. Trotzdem ist der derzeitige Dev-Stand von WebCore die bisher einzige Engine, die Acid2 darstellen kann.

Was die WebCore - KHTML-Sache betrifft: die Leute uebersehen haeufig ein ganz zentrales Problem, naemlich, dass WebCore auf Cocoa baut, und KHTML auf Qt.

Cocoa akzeptiert Objective C, und als Bridge notfalls Objective C++. Qt akzeptiert C++. Um Qt zu emulieren, verwendet WebCore eben eine solche Bridge namens "KWQ" -- K Without Qt, und die ist eben in Objective C++ geschrieben. Cocoa-spezifischer Code in WebCore is ObjC, KHTML-relevanter Code in C++, und so weiter. Das ist eine recht komplexe Sache, und Apple muesste eine Menge Zusatzarbeit leisten, um das zu KHTML vollstaendig kompatibel zu halten. Entweder also zwei Trees pflegen, oder die Performance unter OS X signifikant mindern.

Dieses "wir wuerden ja NDAs unterschreiben" klingt toll, loest aber keine Probleme.

Dass es auch anders geht, beweist Nokia: deren WebCore for GNOME, an dem sie seit einiger Zeit basteln, verwendet Apples Code und portiert diesen auf GNOME. Warum kann KDE das nicht? Weil sie zu ignorant sind, und auf ihrem C++ bestehen, waerend Apple gleichzeitig ignorant ist, und auf ObjC besteht. Apple wird seine Position diesbezueglich nicht aendern, denn Cocoa via ObjC ist seit nunmehr > 15 Jahren erprobt, und vielfach als eine ideale OOP-Umgebung gesehen. GNOME migriert von C++ auf C#. Wie waer's, KDE, wenn ihr auf ObjC migriert?

@Klaus

Von: 00101010 | Datum: 12.05.2005 | #6
Nun, den Test hat er mit seinem Privatbuild von Safari gemacht (Bestanden hat er Ihn glaub ich eh erst nach Release von Tiger). Gut möglich, dass mit 10.4.1 der Web Core geupdated wird, und man dann den Smiley endlich in voller Schönheit (na ja...) genießen kann. Ich hoffe, dass dann auch ein fieser kleiner (aber sehr gemeiner) Cachebug behoben ist, den wir ihm vor drei Wochen gemeldet hatten, beseitigt ist (der betrifft übrigens auch Safari 1.3).

Gruß
00101010

Die Acid2 - Testseite ...

Von: bodo | Datum: 12.05.2005 | #7
... ist 100% koscher (eine ernstgemeinte Frage an Wissende). Das Fehlerprotokol von iCab (ß258, V3.0.0) gibt Foldendes für die Seite http://webstandards.org/act/acid2/test.html aus:

http://webstandards.org/act/acid2/test.html
CSS-Fehler (21/64): Ungültiger Wert "transparent".
CSS-Fehler (79/92): Ungültiger Wert "transparent".
CSS-Fehler (94/79): Ungültige CSS Eigenschaft "error"
CSS-Fehler (94/96): Ungültiger Identifier ""
CSS-Fehler (94/103): Ungültiger Identifier ""
CSS-Fehler (94/104): Ungültiger CSS Selektor ""
CSS-Fehler (97/21): Ungültige CSS Eigenschaft "m
rgin"
CSS-Fehler (99/24): Ungültiger Wert "200".
CSS-Fehler (100/43): Ungültige CSS Eigenschaft "error"
CSS-Fehler (101/35): Ungültiger Wert.
[Link]
HTML-Fehler (135/82): CDATA-Abschnitt ist hier nicht erlaubt.

.

Von: Soeren Kuklau | Datum: 12.05.2005 | #8
@ binaer:
"(der betrifft übrigens auch Safari 1.3)."

Da die Engine von 1.3 und 2.0 identisch ist, Cocoa-spezifische Unterschiede ausgenommen, verwundert das nicht :-)

@ bodo:
Die Fehler sind Absicht. Teil des Tests ist, zu ueberpruefen, wie gut und korrekt eine Engine ueber Fehler hinwegsieht. So ist eine korrekte CSS-Engine verpflichtet, Unbekanntes zu *ignorieren*, statt darueber zu stolpern.

An Entwicklung des Tests war unter anderem der urspruengliche CSS-Erfinder beteiligt; dass der Test wichtig ist, bestreitet kein Browser-Hersteller. Wobei sich Microsoft noch nicht direkt dazu geaeussert hat; fuer den IE waere es auch eine komplexe Sache, da er noch nicht einmal data-URIs unterstuetzt.

Ein Check über den W3C Markup Validation Service ...

Von: bodo | Datum: 12.05.2005 | #9
... für HTML 4.01 Strict findet im HTML-Code keinen Fehler, aber ...

Um das Ganze abzuschließen ...

Von: bodo | Datum: 12.05.2005 | #10
... habe ich natürlich dann noch (Danke an @Soeren Kuklau) W3C CSS-Validator hinzugezogen.

Einfach auch, weil es mich interessiert (und weil es hier mal wieder ein handfesteres Thema gibt, über das sich evtl. gepflegt reden läßt:) ...

* Zeile: 44

Einlese-Fehler - second two]
* Zeile: 89 Kontext : .parser-container div

Ungültige Nummer : color orange ist kein color-Wert : orange
* Zeile: 95 Kontext : .parser

Die Eigenschaft error existiert nicht : }
* Zeile: 98 Kontext : .parser

Die Eigenschaft m rgin existiert nicht : 2em
* Zeile: 98

Parse error - Unrecognized : };
* Zeile: 100 Kontext : .parser

Ungültige Nummer : width nur 0 kann ein length sein. Nach der Zahl mu? eine Einheit stehen. : 200
* Zeile: 101 Kontext : .parser

Einlese-Fehler - ! error;
* Zeile: 101 Kontext : .parser

Parse error - Unrecognized : }


Und natürlich interessiert mich die Qualität des Fehlerreports in iCab - sieht doch recht gut aus.

ööhhh?

Von: fulgurdualis | Datum: 12.05.2005 | #11
Soeren Kuklau wrote:
"GNOME migriert von C++ auf C#. Wie waer's, KDE, wenn ihr auf ObjC migriert?"

Gnome basiert auf GTK+, das AFAIK in C geschrieben ist. Es gibt aber Bindings für C++, Perl, Python, C#, ... Wie kommst du darauf, dass GNOME von C++ auf C# migriert? Hab ich da was verpasst?

KDE und ObjC kannste vergessen. QT/KDE ist eine C++ Hochburg! Ist halt eine Glaubensfrage ;-)

Soeren Kuklau hat Recht

Von: Krischan | Datum: 12.05.2005 | #12
Dass der Code im Acid-Test nicht validiert, ist Absicht.

Jeder Browser muss im Alltag mit versautem Code umgehen. Und die richtige Interpretation der Fallbacks ist gerade auch Bestandteil des Tests.

@:Soeren Kuklau: Web Core (und "binaer")

Von: 00101010 | Datum: 12.05.2005 | #13
Das ist mir schon klar, ich wollte damit auch nur noch mal klarstellen, dass die Jungs und Mädels die hier noch auf 10.3.9 hocken, mit den gleichen Problem(en) zu tun haben... ;)

00101010

P.S.
Zum Namen: Machts gut und danke für den Fisch... :)

@ fulgudingis

Von: Soeren Kuklau | Datum: 12.05.2005 | #14
"Gnome basiert auf GTK+, das AFAIK in C geschrieben ist."

Sehr unreinem C. ;-)

". Es gibt aber Bindings für C++, Perl, Python, C#, ... Wie kommst du darauf, dass GNOME von C++ auf C# migriert?"

Weil neuere Programme, z.B. Beagle, Mono+Gtk# verwenden, und dies sich allmaehlich auch auf aeltere uebertraegt.

@bodo: iCab & CSS

Von: trial&error | Datum: 12.05.2005 | #15
iCab kommt nur bedingt bis gar nicht mit CSS klar. Erst Version 3.0, von der es wohl mal ein Preview für registrierte Benutzer gab (gibt?), soll CSS 2.0 unterstützen.

@ Soeren Kuklau

Von: fulgurdualis | Datum: 12.05.2005 | #16
"Weil neuere Programme, z.B. Beagle, Mono+Gtk# verwenden, und dies sich allmaehlich auch auf aeltere uebertraegt."

danke für die info! halte mich nicht mehr so auf dem laufenden was gnome betrifft. dass nur noch in der microschrott-sprache c# gecodet wird, find ich voll schade. ist ja toll, wenn man mit mono auch auf nicht ms systemen mit den .net geschichten und c# spielen kann. die ganze sache zeugt IMHO aber auch von einer gewissen unterwürfigkeit...

@trial&error ...

Von: bodo | Datum: 12.05.2005 | #17
... ich finde es immer wieder erstaunlich, wie oberflächlich hier Beiträge von Leuten gelesen werden.
Aus meinem allerersten Posting geht klar hervor, daß ich iCab 3.0 verwende!


Dein Einwand ist seit etwa 6 Monaten überholt:)

iCab ...

Von: bodo | Datum: 12.05.2005 | #18
... da ich meine iCab-Vollversion schon vor über 2 Jahren bezahlt habe, komme ich also in den Genuß der aktuellen Betas (die nun etwa im 14-tägigen Rhytmus veröffentlicht werden - Aktuell: ß261).

ups!

Von: trial&error | Datum: 12.05.2005 | #19
mea culpa ...

@42 - OT

Von: njyo | Datum: 12.05.2005 | #20
...wie kommst du bei dem Beitrag nun zum HHG2G?

etwa schon gesehen?!?!? Wenn ja, ein NDA unterschrieben, oder kannst du mir(uns) den Mund etwas wässrig machen? ;)

_W

@ fulgu

Von: Soeren Kuklau | Datum: 12.05.2005 | #21
Unter [Link] (in der Hoffnung, die URL wird korrekt gespeichert) findest du Artikel zu Gtk#, wo du die Entwicklung bzgl. GNOME, Mono und Gtk# mehr oder minder verfolgen kannst.

Zu meinem Bedauern steht es relativ fest, dass .NET immer integraler in GNOME einnisten wird, und sich die Leute erneut von Microsoft abhaengig machen lassen.

Nun ist .NET von der Natur aus nicht schlecht und daher einfach verlockend...

CSS: transparent?

Von: Haiko | Datum: 13.05.2005 | #22
Seid wann gehört eigentlich die Eigenschaft transparent zum CSS Standard? Version 2? 3? Bei SelfHTML (ansonsten sehr vollständig) kann ich das nicht finden.

komisch

Von: frank | Datum: 13.05.2005 | #23
Hier scheinen viele schreiben zu können, aber mit dem Lesen scheint es Probleme zu geben.

Bei dem Test werden absichtlich Fehler eingebaut um den Browser zu testen.

Bei Soeren Kuklau bedanke ich mich für die kompetenten Kommentare.

@ Soeren Kuklau

Von: fulgurdualis | Datum: 13.05.2005 | #24
danke!

Sturm im Wasserglas???

Von: Terrania | Datum: 13.05.2005 | #25
Unter:
[Link]

kann man mal die andere Seite hören ...

@ Haiko

Von: Soeren Kuklau | Datum: 13.05.2005 | #26
Ich nehme an, du meinst opacity. Das ist Teil der CSS3-Spec, die nicht final (und damit auch kein Standard) ist, und es auch eine Weile noch nicht sein wird. In Gecko-Browsern (z.B. Mozilla Firefox) kannst du darauf mit "-moz-opacity" zugreifen, in WebCore-Browsern (KHTML m.W. nicht) mit "-khtml-opacity".

IE hat ein aehnliches, umfangreicheres Attribute namens "filter: alpha()".

Wenn du also

-moz-opacity: 0.5;
-khtml-opacity: 0.5;
opacity: 0.5;
filter: alpha(50);

setzt, kriegst du 50% Deckkraft fuer das Element. Zu beachten ist dabei, dass opacity vererbt wird, filter:alpha jedoch nicht. Macht die Sache sehr komplex. :-)

Opacity und andere CSS3-Elemente

Von: Stefan Kremer | Datum: 13.05.2005 | #27
Moin,

zum Thema Code-Validierung: sorry to say - mein (Ex-)Lieblingsbrowser iCab ist (auch in der 3.0 Version) beim Validieren nicht das Maß der Dinge. Da werden korrekte Sachen angemotzt und falsche übersehen.

Der CSS-Jigsaw basiert auf CSS2, motzt also entsprechend 3er Elemente (wie auch die Farbe "orange") richtigerweise an. Wer sich die Begleitseite zum Acid-Test ausführlich durchliest bekommt das aber auch erläutert.

Die Theorie was die Interpretation der div. opacity-Statements angeht ist richtig, aber die Praxis sieht völlig anders aus. Im Normalfall kommt man um reichlich CSS-Hacks und/oder Browserweichen nicht drumherum um Transparenzen mal mit .png-Grafiken mal mit filter: alpha() u.ä. hinzubekommen.

Gruß Stefan

@haiko

Von: james | Datum: 13.05.2005 | #28
Ich nehme an du meinst nicht "opacity" (wie Soeren Kuklau meint, dass du meinst...) sondern den Eigenschaftswert einer Hintergrundfarbe. (Also auf gut deutsch 'background-color:transparent')

This property sets the background color of an element. Valid color values are defined in the Color Module [CSS3COLOR].

Siehe: [Link]

CSS: transparent (in SELFHTML)

Von: Tim | Datum: 14.05.2005 | #29
Haiko: Das Keywort "transparent" existiert seit CSS 1 für background-color, seit CSS 2 auch für border-color und die jeweiligen Kurznotationen. In SELFHTML ist das auch in den Beschreibungen der jeweiligen CSS-Eigenschaften erwähnt. Aber es wird überlegt, in SELFHTML 9.0 eine kurze Eigenschaft/Wert-Referenz nach dem Vorbild des HTML-Teils zu schaffen, damit man so etwas schneller findet.