Hej! Jest jakaś w miarę dobrze udokumentowana alternatywa dla Java Media Framework (który już dawno nie był aktualizowany).
Niestety JMF pod Windows 7 nie odtwarza mp3 ani AVI :( Na Vista i XP działa bez problemów...
Z kolei połączenie Swinga + JavaFX nie jest takie proste (chyba w Java FX można odtwarzać multimedia).
Standardowa klasa Javy Clip nie posiada obsługi mp3...
Z góry dzięki za pomoc :) [soczek]
Był czas, ze sam się tym interesowałem...jedyne dojrzałe co znalazłem FMJ :
Sam jestem ciekaw co nowego powstało- i czy w ogóle powstało.
LOSMARCELOS napisał(a)
Z kolei połączenie Swinga + JavaFX nie jest takie proste (chyba w Java FX można odtwarzać multimedia).
tak da się w JavaFX odtworzyć media dla przykładu :
kasiaKasia napisał(a)
LOSMARCELOS napisał(a)
Z kolei połączenie Swinga + JavaFX nie jest takie proste (chyba w Java FX można odtwarzać multimedia).
tak da się w JavaFX odtworzyć media dla przykładu :
A da się to jakoś zintegrować z kodem Swinga ??
A da się to jakoś zintegrować z kodem Swinga ??
szczerze nic nie napisałam łącząc tak, ale da się to zrobić:
http://blogs.sun.com/javafx/entry/how_to_use_javafx_in
Korzystałam wyłącznie z javaFX, tam da się zrobić obsługę przycisków. Bez konieczności korzystania z Swinga.
Tak, tylko nie da sie wywoływać funkcji JavaFX w Swingu tzn. przynajmniej u mnie nie dziala to. Nie dziala odtwarzanie mp3 ani MIDI :/
javafx.scene.media.MediaPlayer player = new javafx.scene.media.MediaPlayer();
javafx.scene.media.Media song = new javafx.scene.media.Media();
song.$source = "file:///G:/test.mid";
player.$media = song;
player.play();
Tak, tylko nie da sie wywoływać funkcji JavaFX w Swingu
Co się nie da: http://poligloci.blogspot.com/2009/07/beauty-and-beast-javafx-12-in-netbeans.html integracja JavaFX w Swingu. A w JFX2 powinno być łatwiej.
javafx.scene.media.MediaPlayer player = new javafx.scene.media.MediaPlayer();
javafx.scene.media.Media song = new javafx.scene.media.Media();
song.$source = "file:///G:/test.mid";
player.$media = song;
player.play();
Tzn. chodzi mi o to, że kod się kompiluje tylko .... w ogóle środowisko Javy tego kodu w FX nie wykonuje...
Wstrzymajcie się z JavaFX bo sam język JavaFX Script został porzucony przez Oracla.
Na początku przyszłego roku cała funkcjonalność JavaFX powinna być dostępna jako zwykłe API w Java i zintegrowane z Swingiem.
Dzięki temu będzie można tego używać także w Groove, Scala, itp., więc w tej materii posunięcie Oracla chwali się :)
Dobra mam: http://javafx.com/roadmap/ tylko, że z tego wynika, że w końcu kod skompilowany za pomocą javafxc będzie dostępny w innych klasach na normalnych zasadach i nie będzie jazd z tworzeniem obiektów JavaFX w javie i innych językach. Obecnie klasa JFX nie może być przekazana do klasy javovwej wprost... nie wiedzieć czemu.
Ludzie przespaliście informacje z JavaOne i OpenWorld ? :P
http://java.dzone.com/articles/oracle-discontinue-javafx
poza tym w rozwoju Javy przeszedł na tzw. plan B (mniejsze updaty ale częściej) czyli Java 7 będzie wcześniej.
W Glassfish też niezłe cuda się dzieją. WebSockets, klastrowanie, wersjonowanie deploy'ów, rozwój OSGi
Nie wspomnę już że do rozwoju OpenJDK dołączył IBM (ubijając nieco Apache Harmony niestety)
Chodzi mi bardziej o ściąganie SRE, np gdy oglądamy apleta w Scali. Rozwiązaniem byłoby jakieś repozytorium a'la Google Libraries API, keszowane przez Javę lokalnie na komputerze. Nie wiem właśnie jak to jest z tym keszowaniem wspólnych elementów w przypadku apletów i Java Web Start.
Cache per aplikacja :( http://www.java.com/en/download/faq/java_webstart.xml dlatego lepiej "zmusić" użyszkodnika do zainstalowania dobie SRE.
Koziołek napisał(a)
@donkey7, scala fajny język, a wielkość SRE to rzecz pomijalna w czasach dysków 1TB w każdym domu.
W świecie gdzie coraz więcej aplikacji przechodzi do weba i ludzie przyzwyczajają się że wszystko rusza z kopyta zaraz po kliknięciu raczej jest.
To jest właśnie blokerem u moich klientów dla aplikacji klienckich w Java. Długi start JVM + średnio zrozumiałe dialogi przy starcie + ściąganie 10 MB = część potencjalnych klientów wyłączy to zanim to się skończy.
@walec 51, ale to też zależy od tego w jaki sposób dostarczasz aplikacje. Jeżeli klient chce przez JWS dostać pełnowartościowy edytor tekstu, CRM czy program do obróbki zdjęć to musi liczyć się z tym, że ugotujesz mu łącze.
Moim zdaniem klienci odzwyczaili się od tego, że kupując program muszą zwracać uwagę na wymagania sprzętowe. Szczególnie jeżeli kupują go w modelu SAS (Software As Service) lub w modelu AOS (Application On Server). Wtedy trzeba mówić jasno i wyraźnie jaka przeglądarka, jakie łącze, jakie parametry stacji klienckiej.
Kiedyś dawno temu mieliśmy klienta, który bardzo chciał nową wersje softu (CMS) z "bajerami". Jednocześnie okazało się, że IE5 jest na 90% jego komputerów, a reszta to jakieś stare wersje safari. Długo tłumaczyliśmy, że jeżeli nie chce wymienić sprzętu to nowy CMS to tylko wyrzucanie pieniędzy. W końcu daliśmy mu wymagania sprzętowe i gość postawił Debiany z FF2.
Dziś chyba tylko gry mają jeszcze takie tabelki z kompletem wymagań...
Co do wymagań sprzętowych to sprawa jasna
Koziołek napisał(a)
@walec 51, ale to też zależy od tego w jaki sposób dostarczasz aplikacje. Jeżeli klient chce przez JWS dostać pełnowartościowy edytor tekstu, CRM czy program do obróbki zdjęć to musi liczyć się z tym, że ugotujesz mu łącze.
Po pierwsze klient nie wie co to JWS, chce po prostu CRM'a.
Po drugie rozglądając się po wielu CRM'ach zauważył że większość dla MŚP jest webowa, działa z kopyta i nie gotuje łącza.
Po trzecie gdy widzi że mój jako jedyny ładuje się 10 min to wyłączy go i przejdzie to testowania 10 innych.