Die Zukunft von X



  • GNU-Fan: Habe mal gesplittet, habe aber leider erst ab Mittwoch wieder Zeit was zu posten.



  • X darf doch meines Wissens nach sogar vom Usermode aus direkt auf die Hardware zugreifen, was vom Kernel aus als Ausnahme nur für X gestattet ist.



  • Das Modesetting soll ja wie gesagt in nächster Zeit in den Kernel kommen, zumindest beim Linuxport. Dann kann endlich das System schon beim Hochfahren in der gewünschten Auflösung starten und es gibt nicht jedesmal ein Flackern bei Anmelden.



  • GNU-Fan schrieb:

    DEvent schrieb:

    Ein Workaround ist es einen neue X-Session zu starten und darin das Spiel starten. Alt-Strg-F1/F12 oder Alt-Strg-Back sollte immer funktionieren.

    Eben das funktioniert nicht, wenn gegrabscht wurde ohne loszulassen. Und dass das nicht einfach zu beheben ist, das stört mich.

    Ganz dumme Frage, aber wie oft passiert Dir das in der Praxis? Ich hatte das bis dato noch nie (ehrlich). Ich sage nicht, dass das sehr schön ist, aber es ist kein Grund gegen X.



  • nman schrieb:

    Ganz dumme Frage, aber wie oft passiert Dir das in der Praxis? Ich hatte das bis dato noch nie (ehrlich). Ich sage nicht, dass das sehr schön ist, aber es ist kein Grund gegen X.

    Ich hatte das früher öfter. Meistens wenn man im Netscape Navigator (ich sag doch früher) ein Menü aufgemacht hat.



  • Mich störts insbesondere beim Zocken.
    Wenn ich mal zwischendurch was auf dem Desktop machen muss, ich habe nun mal keinen zweiten Monitor. Manche Spiele kooperieren, mal mehr, mal weniger -- viele tun es nicht.



  • nman schrieb:

    GNU-Fan schrieb:

    DEvent schrieb:

    Ein Workaround ist es einen neue X-Session zu starten und darin das Spiel starten. Alt-Strg-F1/F12 oder Alt-Strg-Back sollte immer funktionieren.

    Eben das funktioniert nicht, wenn gegrabscht wurde ohne loszulassen. Und dass das nicht einfach zu beheben ist, das stört mich.

    Ganz dumme Frage, aber wie oft passiert Dir das in der Praxis? Ich hatte das bis dato noch nie (ehrlich). Ich sage nicht, dass das sehr schön ist, aber es ist kein Grund gegen X.

    Noch nie ein Quake-3-Engine-Spiel gespielt? 😉

    Die grabschen dir sogar alles weg, wenn du das Spiel im Fenstermodus laufen lässt (was diesen irgendwie witzlos macht) und stürzen auch schon manchmal ab. War für mich kein Problem, als Xgl noch nicht so recht mit GLX wollte, weil ich dann den bereits angesprochenen zweiten X-Server benutzte, aber jetzt nervt's schon.

    Mir würde es völlig reichen, wenn man einem Programm dieses Verhalten explizit verbieten könnte. Hat jemand genug Ahnung von X um darüber eine verlässliche Aussage zu treffen?



  • .filmor schrieb:

    Noch nie ein Quake-3-Engine-Spiel gespielt? 😉

    Nein, offensichtlich nicht. Gabs davon denn so viele? (Als ich Quake 3 spielte, hatte ich noch Windows.)



  • Nativ für Linux fallen mir jetzt auf Anhieb Quake 3, Enemy Territory, World of Padman und Bid for Power ein.



  • Und noch einige andere, die hier namentlich nicht erwähnt werden möchten.

    Mir würde es völlig reichen, wenn man einem Programm dieses Verhalten explizit verbieten könnte. Hat jemand genug Ahnung von X um darüber eine verlässliche Aussage zu treffen?

    Man kann eine andere Applikation vorher grabschen und nicht loslassen lassen.
    Allerdings, aus meinem Gedächtnis, brachen dann die Spiele ab mit der Meldung, dass sie keinen Grab beim Init kriegen.



  • Hmm, läuft GLX in Xnest? Seit meinen letzten Experimenten mit uvesafb ist mein Linux ein wenig angeknackst und ich hab gerade auch keine Zeit das zu reparieren und kann es deshalb gerade nicht ausprobieren.

    Ich seh's eigentlich wie nman, dass das doch eher eine Lappalie ist, aber loswerden würd' ich's trotzdem gerne 😉



  • gibt es eigentlich noch andere X-Server Implementierungen/Projekte außer x.org? Und damit meine ich jetzt nicht xfree86.



  • Ja, z.B. für Windows und MacOSX gibt es eigene.
    Sun hat vor ein paar Jahren seinen Eigenbau aufgegeben, SGI hat ja gleich ihr ganzes Irix über Board geworfen.

    Gibt schon noch ein paar andere. Aber beliebt und verbreitet ist eben XOrg momentan am meisten.



  • nman schrieb:

    GNU-Fan schrieb:

    Sondern? Für mich stellt es sich so dar:
    Ein einfache Anwendung, z.B. ein Fullscreen-Spiel kann den Input "grabben", damit wird dann nichts weitergeleitet, nicht mal an den Windowmanager.
    Sollte sich also der Kernel darum kümmern? Oder die Software? Sie tut es oftmals nicht (z.B. ID Spiele). Jedes Multitasking-System sollte eine Möglichkeit außer dem Stromstecker haben, um unpreviligierte aber nicht-kooperierende Anwendungen zu beenden. Das gilt auch für die Benutzerschnittstelle.

    Ach so meintest Du das. Ganz ehrlich? Das ist so eine Kleinigkeit, dass ich mir darum weder Sorgen noch Gedanken mache.

    Also ich halte so etwas für essentiell wichtig.

    Es ärgert mich unter Windows XP extremst, wenn ich nicht mal kurz auf den Desktop wechseln kann und da sich kaum Entwickler darum scheren und es viel zu viele Spiele gibt, die daran nicht denken, sollte so etwas vom OS oder der grafischen Oberfläche forciert werden.

    D.h. eine Tastenkombination festschreiben, die immer geht, auch dann wenn die Entwickler des Spieles versuchen diese Tastenkombination zu umgehen.



  • rüdiger schrieb:

    Achso um mal wieder Ontopic zu sein: Das wird auch das Problem für Haiku sein, wenn die keine kompatible API haben. Wer schreibt Software für Haiku?

    Wenn Haiku fertig ist und die Features die meiner Meinung nach in Haiku noch fehlen implementiert werden, dann würde ich durchaus Software für Haiku schreiben.

    Reizen tut mich das OS nämlich schon, nur will ich nicht für etwas Entwickeln bei dem noch gar nicht absehbar ist, ob die Features die ich will, jemals implementiert werden.



  • DEvent schrieb:

    Dies ist aber ein Fehler der Spieleprogrammierer. Jedes OpenSource Spiel funktioniert einwandfrei. Ein Spiel sollte halt den Input nicht "grabben", sind wir hier zu DOS Zeiten?

    Das sollte man den Spieleprogrammierern nicht überlassen, sondern sie dazu zwingen daß es nicht anders geht als mit der Fensterumschaltung.

    Deiner Argumentation nach müßte man den Spieleprogammierer nämlich auch wieder erlauben, daß sie den Speicher selber verwalten dürfen und wenn sie was falsch machen, dann sagst du daß es ein Fehler der Spieleprogrammierer und nicht des OS sei.

    Ein Workaround ist es einen neue X-Session zu starten und darin das Spiel starten. Alt-Strg-F1/F12 oder Alt-Strg-Back sollte immer funktionieren.

    Richtig, aber das ist unsauberes Design.
    Also gefrickelt nicht ingenieursmäßig erarbeitet.

    On Topic: Hab mir die ersten 20min vom Haiku-Video angeschaut. Es hoert sich ein wenig wie Windows an: Einheitliches Look&Feel, alle Bibliotheken bereits integriert, kein Paketmanagment(?), es soll einfach zu benutzen sein. Die restlichen Features sind ja echt super.

    Schau dir mal die Sache mit den Attributen und Translator an.
    All das wird durchgehend von der Haiku eigenen API unterstützt, weswegen man
    davon ausgehen kann, das solche Attribute bei Haiku auch mal was Wert sind.
    Im gegensatz zu Windows XP, Vista usw (Stichwort ADS*), wo diese Dinge in der Regel nur aufgesetzt sind und auch noch eine Sicherheitslücke darstellen.

    * http://de.wikipedia.org/wiki/Alternate_Data_Streams



  • Besucher 2 schrieb:

    Also ich halte so etwas für essentiell wichtig.

    Klar, aber ich sehe keinen Grund, warum die Implementierung derartiger Dinge nicht eher trivial sein sollte. Das spricht weder gegen X.org noch gegen X, die Devs sind eben noch nicht dazugekommen, das zu reparieren, halte ich für verständlich und lässt mich nicht an der Zukunft des Projekts zweifeln, da es nichts ist, was nicht ins Konzept von X passen würde.

    Haiku: Kannst Du Deine Haiku-Posts bitte auf den anderen Thread beschränken? rüdiger hätte hier nichts über Haiku geschrieben, wenn das zum damaligen Zeitpunkt nicht Thema des Ursprungsthreads gewesen wäre.



  • Warum kann ich mit X-Window keine Dateien zwischen einem Dateimanger im Remotemodus und einem Dateimanager im lokalen Modus kopieren?

    Drag & Drop funktioniert da überhaupt nicht.

    Folgendes Problem:
    Ich habe 2 Rechner.
    Von Rechner A logge ich mich über "ssh -X benutzer@rechnername" in Rechner B ein.

    Damit kann ich auf Rechner A GUI Programme auf B starten und diese auf dem Desktop von Rechner a anzeigen.

    Wenn ich nun z.B. den nautilus Dateimanger von Rechner B remote starte und dann nochmal normal, also lokal auf Rechner A, dann kann ich zwischen denen per Drag & Drop keine Dateien austauschen.

    Wieso geht das nicht?
    Was bringt mir da die ganze Netzwerktransparenz von X-Window, wenn man damit nicht vernünftig mit der GUI arbeiten kann?



  • X-Window schrieb:

    Was bringt mir da die ganze Netzwerktransparenz von X-Window, wenn man damit nicht vernünftig mit der GUI arbeiten kann?

    weil es eben ein windowing system ist und kein dateimanager. irgendwo muß man ja mal grenzen bei der funktionalität setzen.


Anmelden zum Antworten