Das?Zitat von Mivey
Das?
Ja in Safari.
Ich bin immer dafür die neuen Sachen zu pushen. Es stört mich schon das andere Browser bestimmte Sachen so langsam implementieren aber es ist nur eine Frage der Zeit.
Edit:
Bei Firefox ist immer alles geplant xD Aber vllt wollen sie auch erstmal die JavaScript Execution verbessern. Die ist in Chrome imho am Besten.
@Deamonic
Mh, eigentlich unterstützt Chrome die volle WebAudio API. Nicht nur "teilweise". Aber es kann auch daran liegen das die ChromeDevs immer noch sagen das es "beta" ist.
--
Geändert von R.D. (11.05.2013 um 14:28 Uhr)
Bei Firefox scheint auch in "naher" Zukunft was zu kommen: https://wiki.mozilla.org/WebAudio_API_Rollout_Status
Edit: Oh, wobei, Nightly 23 ist ja schon verfügbar
--"Banjo, you're a BEAR... and I will teach you... THESE MOVES!"
Geändert von Cepanks (11.05.2013 um 14:30 Uhr)
Ah das ist doch schon mal gut. Hoffentlich machen dir nicht wieder ihr eigenes Ding wie bei der Gamepad API. Die müssten sie auch mal an den Standard anpassen, dann würde ich das auch in CrossCode einbauen.
--
Hm, wie wird es in Sachen Kompatibilität aussehen, wenn Chrome von der WebKit-Engine auf die neue Blink-Eninge wechselt?
Bei Blink geht es primär um um das Rendering (von Grafiken). Mit Audio hat das wenig zu tun, Zumal die WebAudio API ein Standard ist. Das ist nichts webkit spezifisches. Für dich als Entwickler bleibt wohl alles gleich. Es wird immer noch den Präfix webkit geben. Vllt markieren sie es auch als deprecated und man soll in Zukunft blink als Präfix verwenden. werden wir ja in den kommen Wochen sehen.
--
Es wird keinen blink-Präfix geben. Blink wird neue Features über versteckte Konfigurationsparameter stellen. Du mußt also in deinem Browser einschalten, daß er Feature XYZ verwenden soll. Sobald die Spezifikation für das Feature von W3C als fertig definiert wird und Blink diese Spezifikation voll unterstützt, wird das Feature dann standardmäßig aktiviert. (Zum Zeitpunkt des Forks bereits existierende webkit-Angaben werden allerdings weiter unterstützt.)
Mit anderen Worten: Wir kommen endlich aus der aktuellen Situation raus, wo alle möglichen Leute in ihren Webseiten Kram verwenden, der noch gar nicht fertig spezifiziert ist, aber dank webkit- in Chrome schon mehr oder weniger läuft. Bonuspunkte, wenn die finale Syntax dann abweicht. Doppelte Bonuspunkte, wenn man so geil war und für keine andere Engine Präfixe angegeben hat, weil zu dem Zeizpunkt kein anderer Browser das Feature hatte. Vendor prefixes waren für ihre Zeit eine gute Idee, aber Webkititis hat dem Web als Plattform doch eher geschadet.
Jo wie gesagt 'vllt'. Hab jetzt nicht so genau da rein gelesen. Zumal mir das eigentlich auch egal ist so lange das Feature funktioniert. Ist auch kein Problem das als Entwickler zu ändern finde ich. Das ist ne Sachen von einige Minuten. Ich hab nichts dagegen wenn Browser einheitlich namen für ihre Features haben. Dann hat man nicht mehr diese dummen abfragen in denen Vendor-Präfixe abfragt
--
Gut, du kannst einfach keine Präfixe verwenden; dann verzichtest du halt auf das Feature, bis es fertig ist. So funktioniert's in Zukunft mit Blink.
Oder du benutzt -prefix-free, dann ist das auch kein Problem.
Mein Quote of the day von David Heinemeier Hansson (Erfinder von Ruby on Rails):
--
https://jira.mongodb.org/browse/PYTHON-532
Hilfe
Bugfixchaos!
- Ich habe ein Projekt in mein privates Gitlab (Open Source Github Klon) geladen und festgestellt, dass die README.txt fehlerhaft dargestellt wird
- Ich habe das als Bug in deren Bugtracker auf Github reportet und direkt einen Tipp bekommen, woran es liegen könnte
- Ich habe das Ganze gefixt, getestet und einen Pull Request aufgemacht. Dummerweise hatte ich vom falschen Branch aus gefixt, weshalb in dem Pull Request ein paar Commits mehr waren, als geplant
- Ich habe den Fix nochmal über das Github Web Interface gemacht und einen weiteren Pull Request geschickt. Dummerweise hat Github dabei wohl irgendwas zerschossen und glaubt, ich hätte sämtliche Zeilen der Datei verändert
- Ich habe einen Bug Report an Github gesendet, mit der Bitte, sie mögen ihren online Texteditor reparieren.
Während ich also eigentlich nur meine Seminararbeit in Git verwalten wollte, habe ich mal eben Bugs in zwei verschiedenen Git Webinterfaces entdeckt.
--
Mein Fazit zu JavaFX 2.2 (im folgenden auch nur "JavaFX" genannt): Schöne Lösung um sowohl RIAs zu schreiben als auch Desktop-Anwendungen zu schreiben.
Pro:
Seit Version 2 ist das normales Java statt eine eigene Scriptsprache.
Man kann GUIs zusätzlich mit FXML- und CSS-Dateien definieren. Das ist wesentlich angenehmer als GUIs komplett im Quellcode zu schreiben.
In FXML-Dateien kann man einen Controller angeben, der beim Parsen der FXML-Datei automatisch instantiiert wird. MVC ist somit schon fast build-in.
Den Zugriff zwischen FXML und Java-Klassen läuft über Annotations beim Controller.
Lässt sich direkt in AWT/Swing und sogar SWT embedden.
In JRE 7 Update 6 wurde JavaFX integriert, NetBeans unterstützt JavaFX in neueren Versionen und für Eclipse Indigo/Juno gibt's einen Plugin namens e(fx)clipse.
Kontra:
Leider noch nicht Feature-komplett: Schönstes Beispiel ist der HTMLEditor, wo man nur mit etwas rumtricksen Buttons in der Kontroll-Leiste ausblenden kann.
Das Binding von (nicht statischen, z.B. aus einem POJO kommende) Daten an die Spalten einer Tabelle oder als Inhalt einer Liste ist ohne 3rd-Party-Library noch sehr umständlich.
Einige Layout-Panes verhalten sich im Zusammenspiel mit z.B. ScrollPanes unerwartet recht merkwürdig.
--
Ich bin eine Säbelzahnkatze *miau*
Geändert von niR-kun (09.06.2013 um 22:48 Uhr)
Schonmal so als Vorwarnung: am Wochenende ist Molyjam Deux, ein Gamejam mit aus dem Kontext gerissenen Zitaten von Peter Molyneux als Thema.
Drüber gestolpert bin ich durch einen Aushang bei uns an der Uni. Da wird wohl das ganze Wochenende über in den Rechnerräumen der Informatikfakultät gemeinsam gebastelt. Ich werd aber wohl wenn überhaupt von daheim aus teilnehmen.
--
Du meinst Molydeux, nicht Molyneux.
Die Sprüche sind dieses Jahr wohl tatsächlich vom Original. Zumindest ist jeweils eine entsprechende Quelle angegeben.
Ah, kontext-freie Sprüche von ihm. Brilliant^^
Kruze Frage: Wir sollen an der Uni den Push-Relabel-Algorithmus von Tarjan implementieren. Um die Kanten eines Knotens im Residualgraphen zu ermitteln, füge ich momentan nicht wirklich eine neue Kante in den Graphen ein, sondern betrachte alle ausgehenden und eingehenden Kanten im ursprünglichen Graphen und ermittle die freie Kapazität (u(e) - f(e) für ausgehende Kanten). Dabei muss man nur beachten, dass bei eingehenden Kanten, die Kapazität einfach nur der aktuelle Flusswert über die Kante ist ( Wert der rückläufigen Kante im Residualgraph hat genau diese Kapazität ). Kanten die voll ausgelastet sind, werden im Graphen nicht gelöscht, beim durchlaufen stelle ich einfach nur fest, ob die "freie Kapazität" größer null ist. Frage jetzt: Währe es schneller wenn ich den Graphen wirklich jedes mal manipulieren würde bzw. ändert das etwas an der Laufzeit von O(n²m)?
Einfach, weil ich es mal in der Form schreiben wollte:
Na, wer erkennt, was das tut?
--
Berechtigungen
Zitieren
