Ja, genauso stand es gestern auf'm Linux-Magazin ;-) Scherzhafterweise bezeichnen die Berliner DirectFB als den Tod von X. Aber dieses Toolkit ist doch wohl eher für den "embedded" Bereich gedacht oder soll das wirklich als Alternative zu X11 betrachtet werden ?
Lineo scheint übrigends die Absicht zu haben selbige Firma (Convergence) aufzukaufen.
Das ist ja wohl ein Witz dieser Kommentar. X ist steinalte rückständige Technik, Netzwerkgrafik macht man heute mit speziellen Treibern und lässt für die 95% wo lokale Grafik nötig ist, eine direkte Methode zu.
Und an alle Nörgler die X für was besseres halten, wo ist bitte schön der Multi-Threaded XServer ????
Einige Sachen würde ich sogar noch unterschreiben. Aber Rückständig ist X11 nun wirklich nicht! OK, für die heutigen Bedürfnisse eines Desktop-OS war es nicht konzipiert worden. Somit hatte der ganze "Netzwerkram" schon irgendwie seine Berechtigung gehabt. Aus heutiger Sicht würde man sicherlich eher zu einem ähnlichen von Dir beschriebenen Ansatz tendieren. Ingesamt können wir mit X11 schon ganz zufrieden sein, wenn auch durch ein grundlegendes Re-Design eine weitaus höhere Performance machbar wäre...
ich denke das die Netzwerk möglickeiten des X- Systems etwas sind, das es auf jedenfall zu schützen gilt! Daher sehe ich eigentlich alle ansätze die keine vollständige Tranzperenz ermöglichen mit sorge (IMHO ich glaube in Linuxmagazin gelesen zu haben, daß die AA unterstützung soetwas zB ist). Obwohl es schön ist das es AA- Fonts gibt!
Wozu brauche ich Netzwerktransparenz? Mal im Ernst, alle reden davon, ich weiss bis heute nicht, wofuer das wirklich gut ist. Und ob es nicht effizienter waere, dafuer spezielle Programme zu verwenden. Ist die Konsole denn auch so "Netzwerktransparent" wie X?
Die Netzwerktransparenz brauchst du, wenn du in einem Netzwerk arbeitest und die grafischen Ausgaben eines Prozesses auf dein Display umleiten willst. Ich gebe zu, daß es performanter wäre einen Client zu haben der lokal läuft und die Daten vom Server holt, aber dass ist nicht immer zu haben. Und wenn ich mich da an einige ältere Spiele erinnere, wie z.B. xblast, netmaze, xrisk oder xbattle, dann weiss ich wozu ich die netztransparenz gebraucht habe :-)
DirectFB hat seine Berechtigung, aber wenn ich direkt mit der Hardware arbeiten will und den Programmen direkten Zugriff zu allem gebe, dann kann ich auch mit WIN arbeiten.
Naja, das klingt fuer mich immer noch nicht ueberzeugend. Netzwerkspiele sollten jawohl auch ohne das Umleiten des Displays laufen. Ich sehe ja ein, dass es fuer manche Zwecke sinnvoll sein kann, aber fuer die meisten wohl eher nicht. Netzwerkrouter und andere Rechner bediene ich ueber Telnet oder aehnliche Server. Fuer das Grafiksystem halte ich eine Server fuer Overkill. Es sollte eine Moeglichkeit geben, eine derartige Funktionalitaet optional anzubieten.
> DirectFB hat seine Berechtigung, aber wenn ich direkt mit der Hardware arbeiten will und den Programmen direkten Zugriff zu allem gebe, dann kann ich auch mit WIN arbeiten.
Dann solltest du das tun, denn nichts anderes macht beispielsweise /dev/dsp oder /dev/mouse. Sollen wir demnaechst alle Geraete nur noch ueber Server ansprechen? Dass das nicht sonderlich gut fuer die Performance ist sieht man doch auch an den tollen Soundservern. Ich will nunmal nur EINEN Sound pro Kanal gleichzeitig abspielen, also brauche ich keinen Soundserver. Und ich will auch nur EIN Display verwenden (Ausnahme Dualhead), daher brauche ich auch keinen Grafikserver. Und du kannst mir nicht erzaehlen, dass Xfree stabil waere. Im Gegenteil, gerade weil das hin und wieder mal crashed oder haengt reden doch manche schon vom "stabileren Windows". Der Framebuffer macht mir einen solideren Eindruck. Und uebrigens, was du so verschmaehst, naemlich das direkte Ansprechen der Hardware ist doch EXAKT das, was Xfree macht. Der Framebuffer dagegen ist eine Abstraktion des Grafiksystems, welche dann doch viel eher in deinem Sinne liegen muesste. Nicht umsonst kann ein Fehlerhafter Xfree Server (Nvidia...) das ganze System aufhaengen. Das selbe kann vermutlich auch ein fehlerhaftes Framebuffer Device anrichten, aber wo ist da der Unterschied.
Das einzig groessere Problem, welches ich fuer den Framebuffer sehe ist die fehlende Kompatibilitaet. Was ist mit FreeBSD? Was ist mit Hurd? Werden diese kompatible Framebuffer anbieten?
weiss gar nicht was ihr habt. x funktioniert doch wunderbar. lieber etwas behäbiger als schnell und absturzfreudig. ganz egal wie gut directfb auch ist, es muss erstmal das bringen, was x schon gebracht hat.
Ich denke dass alle die hier posten, die Meldung nicht richtig gelesen habe. Es geht hier nicht darum, XFree86 durch DirectFB zu ersetzen. DirectFB zielt primär auf den Bereich hochintegrierte Systeme; also deine Armbanduhr mit integriertem Telefon und DVD-Spieler ;-) Ein Palm-like Organizer braucht kein XFree86 System das im Vergleich zu Framebuffer Devices unmengen Hauptspeicher benötigt. Im Gegenzug möchte aber auch keiner auf die Features die XF86 einem bietet nicht verzichten und eben deshalb ist es doch schön, dass DirectFB wieder ein bisschen aufgeschlossen hat.
Ich versteh' diesen ganzen Purismus nicht. Sicher, X11 ist auch meiner Meinung nach etwas in die Jahre gekommen, aber es läuft (mit 3dfx beschleunigt) super. Wass will man mehr?! Projekte wie das Berlin-Projekt und eben auch DirectFB sollte man dennoch begrüßen. Ich habe nichts dagegen, eine Fremebuffer GUI zu nutzen. Sicher, damit sind fast alle X11-Tools erstmal Tabu, bis es sowas wie einen "Konvertierungs-Layer" gibt. Aber warum sollte das nicht machbar sein?! (Frage an die Cracks hier... Die alten HP9000 Systeme hatten mit VUE so einen Ansatz...
_OT_ ...sollte jemand ein paar Tips haben, wie ich so eine Kiste wieder Fit kriege, bitte PM! _/OT_
Das ist doch das tolle an modularen Systemen: es ist *fast* alles machbar.
Nach den Screenshots zu urteilen, ist das im Grunde ein Gtk/Embedded. Ich faende es wirklich klasse, so etwas einmal fuer den Desktop verwenden zu koennen. Nicht nur wegen der Geschwindigkeit, sondern auch wegen der netten grafischen Features, z.B. echte Transparenz, direkt auf TrueType basierent und saubere Schriftenglaettung. Alles features an denen bei Xfree schon seit einer Ewigkeit gearbeitet wird und die dort immer noch nicht komplett fertig sind. Ausserdem finde ich es deprimierent, dass das Bewegen eines Fensters unter Xfree grundsaetzlich ruckelt auf meinem Athlon 750, wobei selbiges auf den 500er Rechner auf der Arbeit mit Windows NT absolut fluessig und geschmeidig funktioniert. Das Problem mit den bisherigen Framebuffer Grafikdingern ist, dass sie alle auf einem Toolkit basieren und daher sehr eingeschraenkt sind. Entweder nur Gtk (Gtk/Embedded) oder nur Qt (Qt/Embedded). Ich wuerde mich ja freuen, wenn sich das mit DirectFB aendern wuerde. Aber es sieht ja leider nach Gtk only aus. Ich werde es mir auf jeden Fall gleich mal anschaun, oder es zumindest versuchen. :) Erstmal den letzten Screenshot zuende saugen.
> Ausserdem finde ich es deprimierent, dass das Bewegen eines Fensters unter Xfree > grundsaetzlich ruckelt auf meinem Athlon 750, wobei selbiges auf den 500er > Rechner auf der Arbeit mit Windows NT absolut fluessig und geschmeidig > funktioniert.
Hmm, das hat sicher einen Grund - bei meinem Duron 600 ruckelt nämlich nichts. Aber der Prozessor ist halt nicht alles. Hast Du noch eine ISA-VGA? :)
Im Ernst: Wenn es schon beim Verschieben ruckelt (bei mir laufen sogar Filme ohne Ruckeln im bewegten Fenster weiter), dann stimmt was an der Konfiguration nicht oder Du hast eine schlecht unterstützte Grafikkarte erwischt (ich habe eine NVIDIA TNT 1, xfree 3.3.6).
Nein, von einer Nvidia Geforce erwarte ich eigentlich, dass sie schnell genug ist. ;) Ich verwende die freien nv Xfree Treiber. An der Konfiguration wird es kaum liegen. Ich benutze Linux nun schon seit ein paar Jahren und habe in der Zwischenzeit einige Grafikkarten (Matrox Millenium, Geforce, ATI irgendwas, irgendeine Noname Karte), Xfree Versionen (3.3.x, 4.x), Windowmanager (twm, blackbox, windowmaker, enlightenment, sawfish, kwm, kwin, larswm, etc) und Distributionen (SuSE, Mandrake, Debian) durchprobiert. Und auch Kernel (FreeBSD, Linux). Die Xfree Oberflaeche reagiert DEUTLICH traeger, als jede mir bekannte Windows Oberflaeche.
Also, ich habe DirectFB gerade ausprobiert (nachdem ich mir die Nacht um die Ohren geschlagen habe, um meinen Kernel Framebuffer fit zu kriegen). Aber es hat sich gelohnt. Absolut ruckelfreie Bewegungen, echte transparente Fenster, feinste Kantenglaettung und das mit einer beeindruckenden Geschwindigkeit, obwohl ich nur den Vesa Framebuffer verwenden konnte. Das ist jedenfalls sehr beeindruckend. Als naechstes werde ich nun versuchen, mir ein Gtk zu patchen, damit es DirectFB verwendet... wenn das klappt bin ich mal gespannt, welche Anwendungen schon damit laufen. Und vor allem wie schnell.
Habe das Toolkit auch getestet. Meine Matrox G400 wird zu 90% unterstützt und die Performance ist beachtlich. Allerdings soll die Funktionalität des (gepatchten)GDK nur zu einem Teil unterstützt werden - sozusagen eine light-GDK Version. Insbesondere Bitmap-Handling usw. wird damit (noch)nicht möglich sein. Leider sind die direkt unterstützten Karten sehr wenige. Mit meiner Matrox habe ich zufällig Glück - diese Karte wird sowohl vom Kernel (Framebuffer) als auch von DirectFB (Treiber) sehr gut unterstützt. 24Bit Auflösung bei 1024x768 ist damit überhaupt kein Problem...
Da kommen einem fast Gedanken an eine Desktop-Environment die komplett auf den Framebuffer aufsetzt und damit endlich mal so schnell (wenn nicht sogar schneller) als Windows ist. Leider scheint das einzige Problem die teilweise schlechte Unterstützung der meisten Karten zu sein... --- Projekte wie "Berlin" (GGI) scheinen ja überhaupt nicht weiterzukommen (auf jedenfall kommt es mir so vor)?
Das ist kein Zufall, wuerden andere Hersteller ihre Karten ebenfalls so gut dokumentieren... ich kaufe mir jedenfalls so schnell es geht eine Matrox. Was bringt mir eine Nvidia, deren Features von fast keinem Treiber richtig ausgereizt werden. Einen Framebuffer Desktop will ich unbedingt. Auch wenn dann erstmal nur ein hunderstel der Anwendungen verfuegbar sind. Das ist einfach nur geil... Benutzen kann es ja immerhin fast jeder, dank dem VESA Framebuffer. Wie schnell dafuer Grakatreiber entwickelt werden haengt natuerlich stark damit zusammen, wieviele das ueberhaupt haben wollen auf dem Desktop. Bisher wird es ja hauptsaechlich im Embedded Bereich eingesetzt und da werden wohl eher selten exotische Grafikkarten zum Zuge kommen.
Auch wenn's um DirectFB geht: seit ich Antialiased Fonts mit KDE2.1/QT2.3/XFree4.03/MatroxG400-1.2 (vorher KDE2.1/QT2.3/XFrre4.02/MatroxG400-1.0x) ist der Konqueror derartig langsam und absturzfreudig geworden. CPU: Athlon 1Ghz :-(
Gibts nicht _bald_ ein XServerfreies schnelles Grafiksystem, dass mir nicht nur sanft scrollende transparente Demofenster zeigt, wie es mir DirectFB vorführt... und dann nur mit GTK-Support *aaargh*
Sowas ähnliches wie QT-Embedded (nur schneller, die Demoproggies ruckeln schon gewaltig) mit KDE als Desktop??
Oder mach ich da bei der Qt-embedded Demo etwas falsch?? Und kann man das komplette KDE2.x X-los damit Kompilieren?
Hey moment. DirectFB ist doch im Grunde das, was du suchst. Es ist nicht so, dass DirectFB Gtk unterstuetzt (wie ich zuerst dachte) sondern umgekehrt, Gtk unterstuetzt DirectFB. Es duerfte also auch kein Problem sein, Qt darauf auszurichten. Bei der Qt Embedded Demo ruckelte Bei mir nichts, aber dafuer lief das in einem Palmtop grossen Fenster. So ein Mist. :( Aber egal, Qt ist eh haesslich, da lohnt sich das gar nicht richtig. ;) Komplett KDE wird man genauso wenig fuer den Framebuffer kompilieren koennen wie komplett Gnome. Einige Anwendungen verwenden noch die Xlib, das muesste man erst einmal alles rauswerfen. Das waere sicherlich schaffbar in nicht allzu langer Zeit, aber dann muesste man Xfree dafuer hinten an stehen lassen. Und die meisten moegen Xfree ja anscheinend.
Also wenn das so ist (GTK unterstuetzt DirectFB und nicht umgekehrt) werde ich es auf jeden Fall mal testen. Denn X war mir schon immer viel zu gross fuer den Hausgebrauch
Jup... das ganze ist einfach eine Art Library um den Framebuffer leicht anzusprechen, wenn ich das richtig verstehe. Die Beispiele kommen ja alle ohne Gtk daher. Ohne Toolkit kann man damit natuerlich nicht viel anfangen, also hoffe ich demnaechst mal Gtk dafuer kompiliert zu bekommen. Das wirklich interessante Gtk Anwendungen schon damit laufen, davon waage ich ja gar nicht zu traeumen. Aber es ist eine sehr interessante Sache zum ausprobieren. Und da wird sich sicherlich auch noch einiges tun. Auf jeden Fall kommt das meiner Vorstellung von einem modernen Desktop und Grafiksystem bedeutend naeher als X. Die Demos muss man einfach mal gesehen haben...
Scherzhafterweise bezeichnen die Berliner DirectFB als den Tod von X. Aber dieses Toolkit ist doch wohl eher für den "embedded" Bereich gedacht oder soll das wirklich als Alternative zu X11 betrachtet werden ?
Lineo scheint übrigends die Absicht zu haben selbige Firma (Convergence) aufzukaufen.
X ist steinalte rückständige Technik, Netzwerkgrafik macht man heute mit speziellen Treibern und lässt für die 95% wo lokale Grafik nötig ist, eine direkte Methode zu.
Und an alle Nörgler die X für was besseres halten, wo ist bitte schön der Multi-Threaded XServer ????
Hoffentlich killt DirectFB X sehr schnell
und jetzt geh raus zum Spielen, Kleiner.
OK, für die heutigen Bedürfnisse eines Desktop-OS war es nicht konzipiert worden. Somit hatte der ganze "Netzwerkram" schon irgendwie seine Berechtigung gehabt. Aus heutiger Sicht würde man sicherlich eher zu einem ähnlichen von Dir beschriebenen Ansatz tendieren. Ingesamt können wir mit X11 schon ganz zufrieden sein, wenn auch durch ein grundlegendes Re-Design eine weitaus höhere Performance machbar wäre...
ich denke das die Netzwerk möglickeiten des X- Systems etwas sind, das es auf jedenfall zu schützen gilt! Daher sehe ich eigentlich alle ansätze die keine vollständige Tranzperenz ermöglichen mit sorge (IMHO ich glaube in Linuxmagazin gelesen zu haben, daß die AA unterstützung soetwas zB ist).
Obwohl es schön ist das es AA- Fonts gibt!
con
Die Netzwerktransparenz brauchst du, wenn du in einem Netzwerk arbeitest und die grafischen Ausgaben eines Prozesses auf dein Display umleiten willst.
Ich gebe zu, daß es performanter wäre einen Client zu haben der lokal läuft und die Daten vom Server holt, aber dass ist nicht immer zu haben.
Und wenn ich mich da an einige ältere Spiele erinnere, wie z.B. xblast, netmaze, xrisk oder xbattle, dann weiss ich wozu ich die netztransparenz gebraucht habe :-)
DirectFB hat seine Berechtigung, aber wenn ich direkt mit der Hardware arbeiten will und den Programmen direkten Zugriff zu allem gebe, dann kann ich auch mit WIN arbeiten.
Gruß
Johanes
Ich sehe ja ein, dass es fuer manche Zwecke sinnvoll sein kann, aber fuer die meisten wohl eher nicht. Netzwerkrouter und andere Rechner bediene ich ueber Telnet oder aehnliche Server. Fuer das Grafiksystem halte ich eine Server fuer Overkill.
Es sollte eine Moeglichkeit geben, eine derartige Funktionalitaet optional anzubieten.
> DirectFB hat seine Berechtigung, aber wenn ich direkt mit der Hardware arbeiten will und den Programmen direkten Zugriff zu
allem gebe, dann kann ich auch mit WIN arbeiten.
Dann solltest du das tun, denn nichts anderes macht beispielsweise /dev/dsp oder /dev/mouse.
Sollen wir demnaechst alle Geraete nur noch ueber Server ansprechen? Dass das nicht sonderlich gut fuer die Performance ist sieht man doch auch an den tollen Soundservern. Ich will nunmal nur EINEN Sound pro Kanal gleichzeitig abspielen, also brauche ich keinen Soundserver. Und ich will auch nur EIN Display verwenden (Ausnahme Dualhead), daher brauche ich auch keinen Grafikserver.
Und du kannst mir nicht erzaehlen, dass Xfree stabil waere. Im Gegenteil, gerade weil das hin und wieder mal crashed oder haengt reden doch manche schon vom "stabileren Windows".
Der Framebuffer macht mir einen solideren Eindruck.
Und uebrigens, was du so verschmaehst, naemlich das direkte Ansprechen der Hardware ist doch EXAKT das, was Xfree macht. Der Framebuffer dagegen ist eine Abstraktion des Grafiksystems, welche dann doch viel eher in deinem Sinne liegen muesste. Nicht umsonst kann ein Fehlerhafter Xfree Server (Nvidia...) das ganze System aufhaengen. Das selbe kann vermutlich auch ein fehlerhaftes Framebuffer Device anrichten, aber wo ist da der Unterschied.
Das einzig groessere Problem, welches ich fuer den Framebuffer sehe ist die fehlende Kompatibilitaet. Was ist mit FreeBSD? Was ist mit Hurd? Werden diese kompatible Framebuffer anbieten?
weiss gar nicht was ihr habt. x funktioniert doch wunderbar. lieber etwas behäbiger als schnell und absturzfreudig. ganz egal wie gut directfb auch ist, es muss erstmal das bringen, was x schon gebracht hat.
mfg,
jens
Ein Palm-like Organizer braucht kein XFree86 System das im Vergleich zu Framebuffer Devices unmengen Hauptspeicher benötigt. Im Gegenzug möchte aber auch keiner auf die Features die XF86 einem bietet nicht verzichten und eben deshalb ist es doch schön, dass DirectFB wieder ein bisschen aufgeschlossen hat.
_OT_
...sollte jemand ein paar Tips haben, wie ich so eine Kiste wieder Fit kriege, bitte PM!
_/OT_
Das ist doch das tolle an modularen Systemen: es ist *fast* alles machbar.
lodger
Ausserdem finde ich es deprimierent, dass das Bewegen eines Fensters unter Xfree grundsaetzlich ruckelt auf meinem Athlon 750, wobei selbiges auf den 500er Rechner auf der Arbeit mit Windows NT absolut fluessig und geschmeidig funktioniert.
Das Problem mit den bisherigen Framebuffer Grafikdingern ist, dass sie alle auf einem Toolkit basieren und daher sehr eingeschraenkt sind. Entweder nur Gtk (Gtk/Embedded) oder nur Qt (Qt/Embedded). Ich wuerde mich ja freuen, wenn sich das mit DirectFB aendern wuerde. Aber es sieht ja leider nach Gtk only aus.
Ich werde es mir auf jeden Fall gleich mal anschaun, oder es zumindest versuchen. :)
Erstmal den letzten Screenshot zuende saugen.
> grundsaetzlich ruckelt auf meinem Athlon 750, wobei selbiges auf den 500er
> Rechner auf der Arbeit mit Windows NT absolut fluessig und geschmeidig
> funktioniert.
Hmm, das hat sicher einen Grund - bei meinem Duron 600 ruckelt nämlich
nichts. Aber der Prozessor ist halt nicht alles.
Hast Du noch eine ISA-VGA? :)
Im Ernst: Wenn es schon beim Verschieben ruckelt (bei mir laufen sogar
Filme ohne Ruckeln im bewegten Fenster weiter), dann stimmt was an der
Konfiguration nicht oder Du hast eine schlecht unterstützte
Grafikkarte erwischt (ich habe eine NVIDIA TNT 1, xfree 3.3.6).
Gruß,
/dev/null
Ich verwende die freien nv Xfree Treiber.
An der Konfiguration wird es kaum liegen. Ich benutze Linux nun schon seit ein paar Jahren und habe in der Zwischenzeit einige Grafikkarten (Matrox Millenium, Geforce, ATI irgendwas, irgendeine Noname Karte), Xfree Versionen (3.3.x, 4.x), Windowmanager (twm, blackbox, windowmaker, enlightenment, sawfish, kwm, kwin, larswm, etc) und Distributionen (SuSE, Mandrake, Debian) durchprobiert. Und auch Kernel (FreeBSD, Linux).
Die Xfree Oberflaeche reagiert DEUTLICH traeger, als jede mir bekannte Windows Oberflaeche.
Also, ich habe DirectFB gerade ausprobiert (nachdem ich mir die Nacht um die Ohren geschlagen habe, um meinen Kernel Framebuffer fit zu kriegen). Aber es hat sich gelohnt. Absolut ruckelfreie Bewegungen, echte transparente Fenster, feinste Kantenglaettung und das mit einer beeindruckenden Geschwindigkeit, obwohl ich nur den Vesa Framebuffer verwenden konnte.
Das ist jedenfalls sehr beeindruckend. Als naechstes werde ich nun versuchen, mir ein Gtk zu patchen, damit es DirectFB verwendet... wenn das klappt bin ich mal gespannt, welche Anwendungen schon damit laufen. Und vor allem wie schnell.
Leider sind die direkt unterstützten Karten sehr wenige. Mit meiner Matrox habe ich zufällig Glück - diese Karte wird sowohl vom Kernel (Framebuffer) als auch von DirectFB (Treiber) sehr gut unterstützt. 24Bit Auflösung bei 1024x768 ist damit überhaupt kein Problem...
Da kommen einem fast Gedanken an eine Desktop-Environment die komplett auf den Framebuffer aufsetzt und damit endlich mal so schnell (wenn nicht sogar schneller) als Windows ist. Leider scheint das einzige Problem die teilweise schlechte Unterstützung der meisten Karten zu sein...
---
Projekte wie "Berlin" (GGI) scheinen ja überhaupt nicht weiterzukommen (auf jedenfall kommt es mir so vor)?
Einen Framebuffer Desktop will ich unbedingt.
Auch wenn dann erstmal nur ein hunderstel der Anwendungen verfuegbar sind. Das ist einfach nur geil...
Benutzen kann es ja immerhin fast jeder, dank dem VESA Framebuffer. Wie schnell dafuer Grakatreiber entwickelt werden haengt natuerlich stark damit zusammen, wieviele das ueberhaupt haben wollen auf dem Desktop. Bisher wird es ja hauptsaechlich im Embedded Bereich eingesetzt und da werden wohl eher selten exotische Grafikkarten zum Zuge kommen.
eigentlich kann ich mit der Lib eh nichts anfangen. Aber trotzdem ich hoffe, dass die richtigen Leute daraus was richtig Geiles
machen :-)
Gruß
Cluso
Gibts nicht _bald_ ein XServerfreies schnelles Grafiksystem, dass mir nicht nur sanft scrollende transparente Demofenster zeigt, wie es mir DirectFB vorführt... und dann nur mit GTK-Support *aaargh*
Sowas ähnliches wie QT-Embedded (nur schneller, die Demoproggies ruckeln schon gewaltig) mit KDE als Desktop??
Oder mach ich da bei der Qt-embedded Demo etwas falsch??
Und kann man das komplette KDE2.x X-los damit Kompilieren?
Bei der Qt Embedded Demo ruckelte Bei mir nichts, aber dafuer lief das in einem Palmtop grossen Fenster. So ein Mist. :(
Aber egal, Qt ist eh haesslich, da lohnt sich das gar nicht richtig. ;)
Komplett KDE wird man genauso wenig fuer den Framebuffer kompilieren koennen wie komplett Gnome. Einige Anwendungen verwenden noch die Xlib, das muesste man erst einmal alles rauswerfen. Das waere sicherlich schaffbar in nicht allzu langer Zeit, aber dann muesste man Xfree dafuer hinten an stehen lassen. Und die meisten moegen Xfree ja anscheinend.
ich es auf jeden Fall mal testen. Denn X war mir schon immer viel zu gross fuer den Hausgebrauch
Gruss
Ohne Toolkit kann man damit natuerlich nicht viel anfangen, also hoffe ich demnaechst mal Gtk dafuer kompiliert zu bekommen.
Das wirklich interessante Gtk Anwendungen schon damit laufen, davon waage ich ja gar nicht zu traeumen. Aber es ist eine sehr interessante Sache zum ausprobieren. Und da wird sich sicherlich auch noch einiges tun. Auf jeden Fall kommt das meiner Vorstellung von einem modernen Desktop und Grafiksystem bedeutend naeher als X. Die Demos muss man einfach mal gesehen haben...