Diskussion:Fenster (Computer)

Speicherbereiche

"Zudem werden in der Programmierung auch Speicherbereiche als „Fenster“ oder „Frames“ bezeichnet, wenn beispielsweise nur ein Teil einer (sehr großen) Datei geöffnet und grafisch dargestellt wird." – Was ist damit denn genau gemeint? Es hat auf jeden Fall nichts mit GUI-Fenstern zu tun und sollte deswegen auch nicht in diesem Artikel stehen. -- Memset 11:00, 11. Jul 2006 (CEST)

Habe ich noch nicht gehört - keine Quelle angegeben. Außerdem passts hier nicht gut rein - zu vermischt. Gelöscht:

In der Programmierung werden auch Speicherbereiche als „Fenster“ oder „Frames“ bezeichnet, wenn beispielsweise nur ein Teil einer (sehr großen) Datei geöffnet und grafisch dargestellt wird. --Saibo (Δ) 02:45, 28. Apr. 2010 (CEST)

Vieleicht ist ja mit Speicher die Klassendefinition gemeint, die hinter dem Fenster steht. Dahinter steht i.d.R. ein grösserer Speicherbereich.--89.204.153.168 02:05, 26. Jan. 2011 (CET)

Schaltflächen in der Titelleiste

1. Es fehlt der Hinweis auf die Schaltfläche (Direkt)Hilfe in einigen Dialogfenstern unter Windows.

2. Unter der KDE ist es auch möglich, die Schaltflächenkonfiguration so anzupassen, dass man neben Schließen, Maximieren, Minimieren und Direkthilfe auch Funktionen zur Verfügung hat wie:

• Auf allen Arbeitsflächen sichtbar
• Im Vordergrund halten
• Im Hintergrund halten
• Fensterheber (Minimieren auf Titelleiste)
• Unterteilungen zum Maximieren:
  • Horizontal maximieren (rechte Maustaste)
  • Vertikal maximieren (mittlere Maustaste/Mausrad)
  • Vollständig maximieren (linke Maustaste)

oder so ähnlich.

Wäre es an dieser Stelle nicht sinnvoll, einen separaten Artikel zu diesem Thema anzufertigen und von hier auf diesen zu verweisen? Die Thematik lässt sich mit Sicherheit noch ein Wenig vertiefen, deshalb habe ich den Artikel noch nicht geändert. mfg --Corny2048 11:54, 7. Okt 2006 (CEST)

Ein interessantes Video in diesem Zusammenhang: http://www.youtube.com/watch?v=1E5uKtdQpEA --Nicor 23:35, 4. Mai 2010 (CEST)

Definition falsch bzw. von hinten durch die Brust ins Auge

Ein Fenster ist in erster Linie ein Clipping-Bereich auf dem Bildschirm, d.h. ein Bereich, in dem das Programm zeichnen kann und bei dem alles, was über die Ränder hinaussteht, automatisch abgeschnippelt wird. Dies dient in erster Linie dazu, daß mehrere Programme sich den Bildschirm teilen können, ohne sich gegenseitig zu stören. Der Nachteil ist, daß dabei die Grafikausgabe verlangsamt wird (im Vergleich zum direkten Herumschreiben im Bildschirmspeicher).

Die Fenster kann man gewöhnlich kaskadieren und auf diese Weise z.B. durch ein kleines Fenster auf ein viel größeres sehen. Auch Bedienelemente können (aber müssen nicht) als Fenster realisiert sein. Dies hat den Vorteil, daß man den Hintergrund nicht um die einzelnen Bedienelemente herumzeichnen muß.

Das Koordinatensystem ist im Normalfall relativ zur Position des Fensters, d.h. wenn das Fenster auf dem Bildschirm verschoben wird, ändert sich nicht der Inhalt des Fensters (außer wenn das Programm ausdrücklich auf absoluten Koordinaten beharrt). Dies gilt sowohl für Zeichenbefehle als auch für Mausereignisse.

Beispiel (siehe rechts): B ist ein Kind-Fenster von A. Da B viel größer ist als A, ist nur ein Teil sichtbar und der Rest abgeschnitten. In diesem Beispiel kann das Fenster B mittels der Rollbalken C verschoben werden, welche ihrerseits ebenso als eigenständige Fenster realisiert sein können. D ist das, was der Nutzer für gewöhnlich als „Fenster“ kennenlernt: ein Fenster der höchsten Ebene einschließlich Dekorationen. Ist der verwendete Window-Manager „reparenting“ (also ordnet er den Fenstern einen neuen Vorfahren zu), so ist D in der Tat ein Fenster.

Im Fenster-Artikel ist fast durchgängig von Fenster-Typ D die Rede. Mit der Ausnahme eines Absatzes:

In manchen Bereichen (insbesondere bei dem Windows-API)

...ist beim X-Window-System übrigens nicht anders...

werden alle Elemente der grafischen Benutzeroberfläche als einzelne Fenster betrachtet, also auch kleine Schaltflächen, Textfelder und so weiter.

Nein, nur wenn sie als Fenster (d.h. Clipping-Bereich) realisiert sind. Es geht auch anders. Das ist zwar ein bißchen umständlicher zu programmieren, aber verbraucht dafür hinterher weniger Ressourcen. Bei Windows 3.1 waren die Werkzeug-Buttons in Paintbrush und die Tasten im Taschenrechner vermutlich keine Fenster.

Im allgemeinen Sprachgebrauch werden aber nur die „größten“ dieser Elemente, die auch durch den Nutzer frei platziert werden können, als Fenster bezeichnet. Der technische Begriff für diese richtigen

„richtigen“ ist unsachlich.

Fenster lautet je nach API: Dialog, Frame oder Top Level Window (dt. Fenster der obersten Ebene).

...wobei unter Windows allerdings auch die MDI-Fenster frei positionierbar sind und vom User als „Fenster“ empfunden werden. Diese sind aber keine Top-Level-Fenster. Wenn ein Window-Manager nicht „reparenting“ ist, sondern die Dekorationen einfach nur ringsherum lose anpappt, ist das Gesamtgebilde kein Fenster, obwohl der User das wahrscheinlich so wahrnimmt. „Gemanagete Fenster“ scheint mir eine passende Beschreibung zu sein.

Die Windows API ist in der Begriffsbesimmung sehr eindeutig.

• Ein Dialogfenster ist ein Fenster mit kontrollemelenten, wie Button, Scrollbar, EditBox, Listbox usw.
• Ein Child-Window ist ein Fenster das einen Parent hat (unter windows gibt es nur einen Parent im (Gegensatz zu OS/2 wo es Parent und Owner gab.)
• Ein Top-Level-Window ist ein Fenster dessen Parent das Desktopwindow ist (API Funkton GetHwndDesktop() )
• Ein Frame-Window ist KEIN Rechteck sondern der Bereich eines Hauptfensters der Nicht Clientarea ist. Also Titelleiste, Systemmenü, Min-, Max- und schliessen Button, Menü(nicht bei allen Programmen) und Sizebalken(Vergrößerungsrand). Aus diesem Fenster wird die Clientarea herausgeclippt.
• Die Client-Area ist der eigentliche Programmbereich. Innerhalb dieses Bereiches können dann wieder neue Fenster definiert werden. Also auch MDI Fenster. Diese können also sehr wohl auch wieder ein Framewindow haben--89.204.137.156 03:53, 22. Jan. 2011 (CET)

Ich denke, ich sollte diesen Artikel demnächst mal schonungslos neuschreiben. -- Sloyment 21:51, 24. Aug. 2010 (CEST)

"In manchen Bereichen (insbesondere bei dem Windows-API) werden alle Elemente der grafischen Benutzeroberfläche als einzelne Fenster betrachtet, also auch kleine Schaltflächen, Textfelder und so weiter."

Diese Aussage ist falsch. Kann man relativ leicht mit folgendem Programm prüfen http://www.shareup.com/WinID-download-37124.html Mit dem Programm kann man die Windowhandle alle Bereiche unter Windows bestimmen. Bei der Überprüfung ergibt sich. Einzelne Texte sind keine Fenster. Ikonen (auf dem Desktop) sind keine Fenster. Steuerelemente im Framebereich (Systemmenü, Minimiren, Maximieren und Schliessen) sind keine Fenster. Bei der Aussage werden einige Fakten durcheinander geworfen. Diesen Ansatz, alle Bereiche als Fenster festzulegen gab es unter OS/2 aber nicht unter Windows.--89.204.137.156 03:25, 22. Jan. 2011 (CET)

Clientarea, Framewindow

"Ein Fenster besteht aus einem inneren, rechteckigem Bereich, dessen Darstellung von dem jeweiligen Programm bewerkstelligt wird, und äußeren Dekorationen, die vom Fenstermanager dargestellt werden. Zu letzteren zählen insbesondere die Fensterumrandung und der Titelbalken, der neben dem Titel im allgemeinen diverse Schaltflächen enthält." Ich kann nur für die Windows API reden. KDE muss jemand anderes was zu sagen. Das äussere Fenster heißt Framewindow. Das Innere heist Clientarea. Die Nachrichtenverarbeitung ist falsch beschrienben. ALLE Nachrichten gehen zunächst an die Anwendung und werden dann an die API weitergeleiten (DefaultWindowProc()). Dekorationen wie Skins werden nicht von der API sondern von der Anwendung gezeichnet. Wenn das Framewindow von der API gezeichnet, wird gibt es genau eine Darstellung, die Von den Einstellungen in der Systemsteuerung abhängen.--89.204.137.156 04:20, 22. Jan. 2011 (CET)