Zum Beispiel in KDE-Apps die Plugins brauchen die dynamisch während der Laufzeit geladen werden sollen. COM ist ja nichts anderes als ein binäres Schnittstellenmodell (Component Object Modell) das beschreibt wie Schnittstellen auszusehen haben und welche minimale Funktionalität sie besitzen müssen.
Die COM-API von QT ist allerdings wirklich noch nicht sehr kompackt implementiert. Hier fehlen noch sinnvolle Wrapper-Funktionen/Klassen die sich besser in das "QT-Gesamtkunstwerk" einfügen. Auch ist man mit Templates sehr sparsam umgegangen (gerade diese können COM enorm vereinfachen helfen). Gefunden habe ich in Qcom.h nur eine Templateklasse für Interface-Pointer...
Von Thorsten Schnebeck am Mi, 3. Oktober 2001 um 01:37 #
Du kannst das QCom in etwa mit dem jetzigen KPart vergleichen. Während allerdings KParts nur für KDE funtionieren muss, hat QCom das Ziel einheitliche Komponenten auf all die Systeme laufen zu lassen, für die QT angeboten wird. Wie es z.Z. ausschaut, wird also KParts noch ein Weilchen KDEs Komponenten-Modell bleiben. Für eine bessere Integration von nativen QT-Programmen gibt es aber noch eine PlugIn-Schnittstelle, die KDE3 wohl unterstützen wird. Ich fürchte, die PlugIns werden aber nicht erlauben, dass z.B. ein QT-Programm den KDE-Fileselektor oder die KDE-Druckumgebung verwendet, diese wäre möglich, wenn KDE3 solche Module als QCom-ponenten realisiert hätte.
Bye
Thorsten -- KDE3 wäre eine schöne Gelegenheit, den ganzen Fileselector-Kram rauszuschmeißen und RISC-OS-mäßiges D&D (Rox-Filer) einzuführen, muss ja mal wieder erwähnt werden
Von Daniel Molkentin am Mi, 3. Oktober 2001 um 11:58 #
@Thorsten:
KDE3 wäre eine schöne Gelegenheit, den ganzen Fileselector-Kram rauszuschmeißen und RISC-OS-mäßiges D&D (Rox-Filer) einzuführen, muss ja mal wieder erwähnt werden
Also den Fileselector werden wir schon den Windowsumsteigern zu liebe nicht tun können. Aber was genau meinst du mit "RISC-OS-mäßiges D&D"? Meinst du DND für alles und jedes wie es auch apple ziemlich konsequent durchführt?
PS: hier ist eigentlich weniger der passende Ort, um solche sachen anzuregen: besser ist kde-devel oder bugs.kde.org (bevorzugt mit patches :)
Von Thorsten Schnebeck am Mi, 3. Oktober 2001 um 13:15 #
@ Daniel
Hi Daniel!
Ja ich weiss, dass vielleicht Pro-Linux nicht der richtige Ort für so etwas ist, aber eigentlich streue ich diese Botschaft von Zeit zu Zeit in jedes Forum , vielleicht finde ich ja auch hier ein paar "Mitverschwörer". Hab' aber auch schon mit Carsten direkt drüber gesprochen. Da er es nicht kennt, ist er aber eher reserviert, wäre auch eine kleine Revolution!
Mein "Problem" ist, dass ich Windows eigentlich nie richtig kennengelernt habe, erst nach Linux! Nach der C64-Zeit bin ich auf den Acorn-Archimedes mit dem Betriebssystem RISCOS umgestiegen. Dieses System war seiner Zeit um Generationen voraus. Und wenn mach meint Apple sei der GUI-Weisheit letzter Schluss, sie hätten mal die Leichtigkeit von RISC-OS erleben sollen. Keine Menü-Zeilen sondern _nur_ kontextsensitive PopUP-Menüs mit der mittleren Maustaste. Generelle Unterstützung einer 3-Tastenmaus: Select, Menu, Adjust. Im Filer hat man mit Select z.B. einzelne Dateien oder Gruppen ausgewählt, mit Adjust hast du einzelne Dateien oder Gruppen hinzugefügt, kein Shift, kein Ctrl!
Der größste Unterschied zu allen mir bis heute bekannten Systemen:
RISCOS hat keinen Fileselektor, RISCOS hat kein Datei-öffnen-Menupunkt. Auf KDE-Verhältnisse gemünzt heisst das: Warum einen separaten Fileselektor, wenn man mit dem Konqi, das beste an Datenverwaltung hat, was Linux zu bieten weiss? Der KDE-Fileselektor hat nur begrenzte Funktionalität. Mal 'ne Frage, wie startest du üblicherweise eine Datei: Klick im Konqi Drag von Konqi auf Kicker-Botton oder startest du eine Applikation und öffnest die Datei?
Was macht RISC-OS nun beim Speichen: Nur ein kleines Fenster mit einem Icon und dem Dateinamen, handelt es sich um eine schon bearbeitete Datei: Pfad+Dateiname. Dazu noch zwei Bottons: "OK" und "Abbrechen" Also: bestehende Datei abspeichern: F3 und Return Neue Datei abspeichern: F3 + Defaultnamen editieren und Icon in den Konqi ziehen und den Pfad zu holen. DAS nenne ich dokumentenorientiertes Arbeiten und ich behaupte jeder, der das mal 'ne Woche benutzt hat, wird nie wieder anderes arbeiten wollen.
Unter Linux gibt es das ROX-Filer Projekt, das den gleichen Ansatz verfolgt.
http://rox.sourceforge.net/ http://rox.sourceforge.net/ screens/save.gif (ohne Leerzeichen!) RISCOS hatte schon 1989: -Betriebssystemmodule -AA-Fonts -auflösungsunabhängige Desktopkoordinaten -AA-Painter-Module (!!!) (OK noch nicht '89 aber später ;-) -minimalisierter postscriptkompatibler Vektor-Renderer -Systemweite Datenformate für Bitmap-Grafik, Vektor-Grafix, Text, Musik.
Zwar können die Engländer wunderbare Computer bauen, leider haben sie keine Ahnung vom Verkaufen: Acorn tot, Psion scheintot...
Thorsten Schnebeck: Ich kann deine Argumentation in Richtung warum Filemanager und -Selector trennen zwar gut nachvollziehen, aber es gibt auch Gruende fuer die derzeitige Loesung. Der Staerkste ist wohl der "Funktionalitaet sollte zu sehen sein" Grundsatz. Das heisst, das man Usern die Funktionalitaet visuell anbieten muss, damit sie wissen, dass sie existiert. Gerade unter Windows wird das sehr extrem praktiziert mit zB der Startleiste. Dies steht im Gegensatz zu Funktionalitaet, die man nicht sehen, sonder nur ausprobieren kann, wie zB Tastaturkuerzel und Drag&Drop. Drag&Drop kann IMHO nur ergaenzend angeboten werden, weil man nicht sehen kann, was man wohin ziehen kann - dies erfaehrt man nur durch Erfahrung bzw Nachlesen. Viele Anfaenger hat man bereits abgeschreckt, bevor sie es herausgefunden haben.
Von Thorsten Schnebeck am Mi, 3. Oktober 2001 um 14:31 #
@Tim:
Hi Tim!
Ist so etwas wie eine Startleiste nicht eher eine Konditionierung auf Namen und Marken?
Will ich als User einen Text bearbeiten oder will ich Word öffnen? Ich denke, nur weil Windows einen "Bedienstandard" vorgibt, den halt jeder kennt, heisst das noch lange nicht, dass dieser Standard funktionell oder intuitiv ist! Wenn man den Leuten zeigt, hier so funktioniert das hier, werden die User es so machen. Alles eine Frage des Lernens. Und Computer werden erst dann wirklich interessant, wenn sich dokumentenorientiertes Arbeiten in den GUIs dieser Welt durchsetzt.
Für KDE hieße das ja nicht eine Abkehr vom gewohnten, man könnte ja eine weitere Config-Option schaffen, ähnlich wie schon jetzt bei der Apple-Menuzeile.
Aber auch dir stelle ich die Frage: Öffnest du (so du KDE verwendest) eine Datei durch Klick im Konqueror oder erst innerhalb einer zuvor geöffneten Applikation (K-Menu)? Ich wette die Windows-Leute benutzten letztes, die Leute die RISCOS kennengelernt haben, ersteres.
ROX ist wirklich ein genialer Desktop. Alleine das installieren von Anwendungen ist ein Traum. Dokumentenorientiertes arbeiten ist sicherlich Gewohnheitssache aber das ganze mal in KDE oder auch Gnome zu integrieren wäre es sicherlich wert. Der Konqueror ist ja bereits eine art "filer" und Nautilus auch.
Thorsten Schnebeck: Vom Namen & Logo der Startleiste vielleicht, aber das Prinzip ist, das du eine Reihe wichtiger Aktionen (naemlich das STARTen von Applikationen) jederzeit vor Augen hast, im Gegensatz zom Program Manager von Win 3.1 oder vielen Window-Managern. Ebenso das Umschalten zwischen Fenstern, auch da kannst du jederzeit alle Fenster sehen und musst nur draufklicken, im Vergleich zum alten Win 3.1 oder vielen Window Managern, wo das hinter einer Maustaste verborgen ist. Fuer Ahnungslose Computerbenutzer macht das die Bedienung viel transparenter. Die Frage, wie ich eine Applikation oeffne, spielt eigentlich keine Rolle, weil ich nicht der durchschnittliche Computerbenutzer bin (fast alles ausser das Oeffnen von Texten in XEmacs mache ich eigentlich per Shell, ich habe sehr selten einen Filemanager offen). Meistens gibt es IMHO auch eine grosse Diskrepanz zwischen dem, was Computerunbedarfte wollen bzw ihnen leicht erscheint und was effizient in der regelmaessigen Benutzung ist. Siehe Tastaturkuerzel vs. Menus, Command Line vs. Filemanager, Wizards-gefuehrte Dialoge vs. Tabs...
Nebenbei bemerkt, wenn man mit dokumentenzentriertem Arbeiten wirklich konsequent sein moechte, sollte man auf das Wort "Speichern" und damit verbundene Aktionen grundsaetzlich verzichten. Man oeffnet ein Dokument, bearbeitet es und schliesst es wieder (womit logischer Weise alle Aenderungen geschrieben werden). Um die alte Funktionalitaet zu bewahren, braeuchte man hoechstens noch einen Punkt wie "alle Aenderungen rueckgaengig machen". Dies wuerde dem alten "Beenden ohne Speichern" entsprechen. Die alte Aktion "Speichern unter" wuerde ersetzt durch das Kopieren im Filemanager.
IMHO waere das ganze so logischer, weil es nicht den Unterschied gibt zwischen der Datei, die der User im Filemanager sieht, und der Datei im Editor.
OK, die dokumentenorientierte Arbeitsweise funktioniert - selbst bei mir! Ich benutze sie aber nur selten (ca. 10% der Fälle). Ansonsten öffne ich immer zuerst das Programm und dann dort die Menüpunkte "öffnen" oder "neu". Nebenbei, welches Grafikprogramm soll denn das System automatisch öffnen? Ich benutze z.Zt. je nach Aufgabe bis zu vier verschiedene Pixel-Grafikprogramme, da keines alle von mir benötigten Aufgaben gleichermaßen gut beherrscht.
Auch wenn ich an Webseiten herumbastele und neue Unterseiten erstellen will, gehe ich über "öffnen" und anschließendes "speichern unter" in der Applikation: Ich speichere dann eine schon durchgestylte Seite unter einem anderen Namen um sie dann zuerst inhaltlich zu verändern und sie anschließend ins Projekt einzubauen. Wie mache ich das ohne Fileselector?
Nebenbei: Welchen VORTEIL hätte denn nun die Abschaffung des Fileselectors?
Übrigens, zum Verwalten von Files finde ich ein Tool wie den Windowscommander oder entsprechende Tools unter Linux (z.B. Crusader) irgendwie erheblich angenehmer als der Konqerer.
- Harm - ...der zwar derzeit zumeist noch mit WIN arbeitet, die "schlechten Angewohnheiten" aber noch vom Atari hat ...Linux-Anfänger-DAU ...ich arbeite aber daran...
Von Thorsten Schnebeck am Mi, 3. Oktober 2001 um 18:51 #
Hi Harm!
Das dokumentenorientierte Arbeiten und das Abschaffen des Fileselektors sind verwandt können aber separat angegangen werden.
Wie oft hattest du schon die Situation, dass du deine Arbeit sichern wolltest und den Fileselektor abgebrochen hast, weil die Tätigkeit dort nicht durchzuführen war. Bei KDE hat das dazu geführt, dass der Fileselektor immer mächtiger wurde, immer mehr Funktionalität vom Konqueror übernommen wurde (z.B. Preview).
Trotzdem, in seiner Vielfalt und Netzwerktransparenz ist der Konqueror unerreicht (meinetwegen unerreicht bezogen auf KDE) Bookmark-Leiste, Sitebar alles nicht so kompfortabel vorhanden im Fileselektor. Also, wenn man sowieso sein Dateiverwaltungstool hat, darf ja auch der Krusader oder der Nautilus sein, warum nicht einfach das zu speichende Dokument dahinziehen. Was braucht man dafür: Nur einen Repräsentanten für das Dokument - also ein Icon. Der Unterschied ist also, du bestimmst mit welchen Programm du deine Datenverwaltung machst, lernst dort mit der Zeit alle Tricks und musst nicht die eingeschränkte Funktionalität einer System-Fileselektorbox benutzen.
Ausserdem kannst du mehrere Konqueror (=Filer) permanent offen haben: z.B. /htm/gif und /htm/tif Beim Speichern aus deinem Grafikprogramm per Fileselektor musst du jedesmal wechseln, legst dir vielleicht ein Bookmark an, den du morggen schon gar nicht mehr bräuchtest.
Diese Fenster kannst du auf einen separaten Desktop packen. Alle relevanten Ordner für deine Arbeit auf einem Blick.
Ist vielleicht schwierig das so zu beschreiben, wer das kennt, liebt es einfach.
Übrigens bietet dir der Konqueror das Zuordnen meherer Apps zu einem Mime-Type, so eingerichtet, gehst du einfach auf dein (z.B.) HTML-Dokument und hast die Auswahl "Öffnen mit: Konqi, Netscape,Quanta, Kate": Du hast ein Dokument und bestimmst wie du es bearbeitest im Gegensatz du hast eine Applikation und bearbeitest damit Dokumente. Bei Windows weiss ich häufig nie wo meine Dateien liegen, wenn ich nicht "speichern unter" benutze.
Somit auch noch mal an @Tim: Ich weiss nicht, ob man den Dokumentenbegriff soweit abstrahieren kann, wie du es oben vorschlägt. Ich glaube schon, dass ein so vielseitiges Werkzeug wie ein Computer, den Begriff von File und Folder zum Ordnen braucht.
Ist echt witzig, wie unterschiedlich diese Sichtweise ist. Ich weiss, ich kann z.B. meine Arbeit fortsezten, wenn ich KWord öffne und "kürzlich bearb. Dokument" anwähle, dann habe ich es mit 4 Klicks - mach ich nicht! Ich habe immer ein Konqi-Arbeitsfenster auf und klicke auf meine zu bearbeitende Datei.
Ist bestimmt alles nicht der Stein der Weisen, was ich hier beschreibe und jeder hat seine persönlichen Vorlieben, dennoch wer es kennt, vermisst es.
Nicht direkt, aber über die easyV24-Library kannst du auf die Schnittstelle zugreifen. Habe es vor kurzem mit einem Modem erfolgreich getestet (mit meinem Qt-Anfängerwissen).
>Auch meinte Collins, er würde sich wünschen, > dass in der Community sich mehr Leute >darüber Gedanken machen, wie man verhindern >kann, dass die > Entwicklung von Freier Software durch >unsinnige Gesetze behindert wird.
Ja, ich denke das ist in der Tat ein wichtiger Punkt, der immermehr an bedeutung gewinnen wird. Aber veleicht auch eine Change für die "dritte Welt" die auf's Copyright und Patente schei***. Vieleicht reguliet sich der Markt (b.z.w. die Gesetzgebung) selber, wenn Sie/Wir merken, das die Software woanders endsteht und die Endwicklung im eigenem Lande stillsteht.
--- quote --- Do you think that there are any areas in NM that could be at all improved? Has it improved since you took over as DPL?
NM has improved a great deal since I became DPL, but not because of me by any means. I think because of my outspokeness about changes in NM, that some people were afraid I would dismantle the process and rebuild it, but I haven't touched it one bit other than talking to the DAM every so often. --- unquote ---
Wer außer Hardcore-Debianern soll daraus schlau werden?
Bracuht QT 3.0 eigentlich noch den X Server? Ich hab mal gehört, das der die Hauptbremse bei 2D Spielen ist. Außerdem könnte man dann in KDE 3 auch so schöne Funktionen wie Alphablending und nichtrechteckige Fenster einbauen. Aber dann wird es ja wohl keine 3D beschleunigte Grafik mehr geben. Aber damit hab ich sowieso meine Probleme: Seit ich bei meinem Suse 7.1 die 3D Beschleunigung aktiviert habe, sehe ich immer schwarze Rechtecke bevor die Menüs kommen. Außerdem fillmert Opera beim scrollen. Weis jemand Rat?
Von Daniel Molkentin am Mi, 3. Oktober 2001 um 13:32 #
Bracuht QT 3.0 eigentlich noch den X Server?
Nope, es gibt auch wieder eine Version für die Framebuffer Console (Qt Embedded)
Außerdem könnte man dann in KDE 3 auch so schöne Funktionen wie Alphablending und nichtrechteckige Fenster einbauen.
Ist drinnen in Qt3. Läuft alles über die RENDER extension von X.
Aber dann wird es ja wohl keine 3D beschleunigte Grafik mehr geben.
Wieso? OpenGL hat damit nix zu tun. Das is ne ganz andere Kiste. OpenGL wird von Qt aber auch unterstützt.
OpenGL und RENDER sind nicht wirklich inkompatibel, nur antialiasing unter OpenGL muss kann natürlich nicht via RENDER gemacht werden, das sind zwei paar Socken.
Bei NVidia gab es mal das Problem, das die XFree treiber RENDER und die von NVidia nur OpenGL konnten. Das ist aber kein Problem mehr, da der Treiber von NVidia mittlerweile beides kann.
Seit ich bei meinem Suse 7.1 die 3D Beschleunigung aktiviert habe, sehe ich immer schwarze Rechtecke bevor die Menüs kommen. Außerdem fillmert Opera beim scrollen. Weis jemand Rat?
Ja, QT Embeddet läuft auf normalen PCs. Ich habe mal gehört Yast2 benutzt es. Meines wissens nach kann KDE nicht mit QT Embeddet umgehen, es wird aber wohl dran gearbeitet.
kdelibs hat zumindest mal mit Qt/Embedded gebaut. Aber das ist Unfug. Der Framebuffer ist stinkelahm, verglichen mit X-Windows und der Tatsache das XFree86 fuer weitaus mehr Chipsaetze HW-Beschleunigung unterstuetzt als der Linux Kernel Framebuffer. X rules : - )
Von Daniel Molkentin am Mi, 3. Oktober 2001 um 20:58 #
- voller XRENDER support (Anti Aliasing + Alpha Blending) - Schnellere Applikationsentwicklung mit Qt Designer 2 (90% aller kdeui widgets werden für den designer verfügbar sein => weniger manueller source code => mehr Zeit für die Implementation / Bugfixing) - Unkompliziertes Font handling - Voller Bidi Support für sprachen, in denen nach rechts nach links geschrieben wird (versuch mal "kcontrol -reverse" in der alpha1 nächste Woche :) - X konformes Copy&paste (mittlere Maustaste lässt grüßen :)
...und vieles mehr und das alles nur durch Qt selbst.
Die von KDE selbst geplanten Features kannst du noch mal unter http://developer.kde.org/ development-versions/kde-3.0-features.html hier nachlesen.
>- Schnellere Applikationsentwicklung mit Qt Designer 2 (90% aller kdeui widgets werden für den designer verfügbar sein => weniger manueller source code => mehr Zeit für die Implementation / Bugfixing)<
Schön das die Nicht Borland Welt endlich auch die Vorteile eines solchen Anwendungsentwicklung versteht
Von ex-Anonymous am Do, 4. Oktober 2001 um 12:07 #
Wie sieht das eigentlich mit ACL Unterstützung für KDE ?
Wäre schöne, wenn bei Konqueror (crusader, kcommander, ...) bei den Atrributen auch ACLS angelegt werden könnten, die dann auch gleich die effektiven BErechtigungen anzeigen.
Bei Konqueror bekomme ich nur ugw angezeigt - oder hab ich was übersehen (Compile Time ?)
Von Daniel Molkentin am Fr, 5. Oktober 2001 um 16:36 #
Darüber gab es schon zahlreiche Diskussionen auf den devel-listen.
Ergebnis: Solange der (offizielle) Linux kernel kein FS mit ACLs anbietet und noch ein riesenchaos zwischen den verschiedenen Versionen/Implementierungen herrscht, wird es wohl keinen offiziellen Support geben (nicht maintainbar).... es sei denn (wie fast immer), jemand hat da einen Patch :)
Die COM-API von QT ist allerdings wirklich noch nicht sehr kompackt implementiert. Hier fehlen noch sinnvolle Wrapper-Funktionen/Klassen die sich besser in das "QT-Gesamtkunstwerk" einfügen. Auch ist man mit Templates sehr sparsam umgegangen (gerade diese können COM enorm vereinfachen helfen). Gefunden habe ich in Qcom.h nur eine Templateklasse für Interface-Pointer...
Bye
Thorsten
--
KDE3 wäre eine schöne Gelegenheit, den ganzen Fileselector-Kram rauszuschmeißen und RISC-OS-mäßiges D&D (Rox-Filer) einzuführen, muss ja mal wieder erwähnt werden
KDE3 wäre eine schöne Gelegenheit, den ganzen Fileselector-Kram rauszuschmeißen und RISC-OS-mäßiges D&D (Rox-Filer) einzuführen, muss ja mal wieder erwähnt werden
Also den Fileselector werden wir schon den Windowsumsteigern zu liebe nicht tun können. Aber was genau meinst du mit "RISC-OS-mäßiges D&D"? Meinst du DND für alles und jedes wie es auch apple ziemlich konsequent durchführt?
PS: hier ist eigentlich weniger der passende Ort, um solche sachen anzuregen: besser ist kde-devel oder bugs.kde.org (bevorzugt mit patches :)
Gruß,
Daniel
Hi Daniel!
Ja ich weiss, dass vielleicht Pro-Linux nicht der richtige Ort für so etwas ist, aber eigentlich streue ich diese Botschaft von Zeit zu Zeit in jedes Forum
, vielleicht finde ich ja auch hier ein paar "Mitverschwörer". Hab' aber auch schon mit Carsten direkt drüber gesprochen. Da er es nicht kennt, ist er aber eher reserviert, wäre auch eine kleine Revolution!
Mein "Problem" ist, dass ich Windows eigentlich nie richtig kennengelernt habe, erst nach Linux! Nach der C64-Zeit bin ich auf den Acorn-Archimedes mit dem Betriebssystem RISCOS umgestiegen. Dieses System war seiner Zeit um Generationen voraus. Und wenn mach meint Apple sei der GUI-Weisheit letzter Schluss, sie hätten mal die Leichtigkeit von RISC-OS erleben sollen. Keine Menü-Zeilen sondern _nur_ kontextsensitive PopUP-Menüs mit der mittleren Maustaste. Generelle Unterstützung einer 3-Tastenmaus: Select, Menu, Adjust.
Im Filer hat man mit Select z.B. einzelne Dateien oder Gruppen ausgewählt, mit Adjust hast du einzelne Dateien oder Gruppen hinzugefügt, kein Shift, kein Ctrl!
Der größste Unterschied zu allen mir bis heute bekannten Systemen:
RISCOS hat keinen Fileselektor, RISCOS hat kein Datei-öffnen-Menupunkt.
Auf KDE-Verhältnisse gemünzt heisst das: Warum einen separaten Fileselektor, wenn man mit dem Konqi, das beste an Datenverwaltung hat, was Linux zu bieten weiss? Der KDE-Fileselektor hat nur begrenzte Funktionalität.
Mal 'ne Frage, wie startest du üblicherweise eine Datei:
Klick im Konqi
Drag von Konqi auf Kicker-Botton
oder startest du eine Applikation und öffnest die Datei?
Was macht RISC-OS nun beim Speichen: Nur ein kleines Fenster mit einem Icon und dem Dateinamen, handelt es sich um eine schon bearbeitete Datei: Pfad+Dateiname. Dazu noch zwei Bottons: "OK" und "Abbrechen"
Also: bestehende Datei abspeichern: F3 und Return
Neue Datei abspeichern: F3 + Defaultnamen editieren und Icon in den Konqi ziehen und den Pfad zu holen.
DAS nenne ich dokumentenorientiertes Arbeiten und ich behaupte jeder, der das mal 'ne Woche benutzt hat, wird nie wieder anderes arbeiten wollen.
Unter Linux gibt es das ROX-Filer Projekt, das den gleichen Ansatz verfolgt.
http://rox.sourceforge.net/
http://rox.sourceforge.net/ screens/save.gif
(ohne Leerzeichen!)
RISCOS hatte schon 1989:
-Betriebssystemmodule
-AA-Fonts
-auflösungsunabhängige Desktopkoordinaten
-AA-Painter-Module (!!!) (OK noch nicht '89 aber später ;-)
-minimalisierter postscriptkompatibler Vektor-Renderer
-Systemweite Datenformate für Bitmap-Grafik, Vektor-Grafix, Text, Musik.
Zwar können die Engländer wunderbare Computer bauen, leider haben sie keine Ahnung vom Verkaufen: Acorn tot, Psion scheintot...
Bye
Thorsten
Hi Tim!
Ist so etwas wie eine Startleiste nicht eher eine Konditionierung auf Namen und Marken?
Will ich als User einen Text bearbeiten oder will ich Word öffnen? Ich denke, nur weil Windows einen "Bedienstandard" vorgibt, den halt jeder kennt, heisst das noch lange nicht, dass dieser Standard funktionell oder intuitiv ist! Wenn man den Leuten zeigt, hier so funktioniert das hier, werden die User es so machen. Alles eine Frage des Lernens. Und Computer werden erst dann wirklich interessant, wenn sich dokumentenorientiertes Arbeiten in den GUIs dieser Welt durchsetzt.
Für KDE hieße das ja nicht eine Abkehr vom gewohnten, man könnte ja eine weitere Config-Option schaffen, ähnlich wie schon jetzt bei der Apple-Menuzeile.
Aber auch dir stelle ich die Frage: Öffnest du (so du KDE verwendest) eine Datei durch Klick im Konqueror oder erst innerhalb einer zuvor geöffneten Applikation (K-Menu)?
Ich wette die Windows-Leute benutzten letztes, die Leute die RISCOS kennengelernt haben, ersteres.
Bye
Thorsten
Der Konqueror ist ja bereits eine art "filer" und Nautilus auch.
Meistens gibt es IMHO auch eine grosse Diskrepanz zwischen dem, was Computerunbedarfte wollen bzw ihnen leicht erscheint und was effizient in der regelmaessigen Benutzung ist. Siehe Tastaturkuerzel vs. Menus, Command Line vs. Filemanager, Wizards-gefuehrte Dialoge vs. Tabs...
IMHO waere das ganze so logischer, weil es nicht den Unterschied gibt zwischen der Datei, die der User im Filemanager sieht, und der Datei im Editor.
OK, die dokumentenorientierte Arbeitsweise funktioniert - selbst bei mir! Ich benutze sie aber nur selten (ca. 10% der Fälle). Ansonsten öffne ich immer zuerst das Programm und dann dort die Menüpunkte "öffnen" oder "neu".
Nebenbei, welches Grafikprogramm soll denn das System automatisch öffnen? Ich benutze z.Zt. je nach Aufgabe bis zu vier verschiedene Pixel-Grafikprogramme, da keines alle von mir benötigten Aufgaben gleichermaßen gut beherrscht.
Auch wenn ich an Webseiten herumbastele und neue Unterseiten erstellen will, gehe ich über "öffnen" und anschließendes "speichern unter" in der Applikation:
Ich speichere dann eine schon durchgestylte Seite unter einem anderen Namen um sie dann zuerst inhaltlich zu verändern und sie anschließend ins Projekt einzubauen. Wie mache ich das ohne Fileselector?
Nebenbei:
Welchen VORTEIL hätte denn nun die Abschaffung des Fileselectors?
Übrigens, zum Verwalten von Files finde ich ein Tool wie den Windowscommander oder entsprechende Tools unter Linux (z.B. Crusader) irgendwie erheblich angenehmer als der Konqerer.
- Harm -
...der zwar derzeit zumeist noch mit WIN arbeitet, die "schlechten Angewohnheiten" aber noch vom Atari hat
...Linux-Anfänger-DAU
...ich arbeite aber daran...
Das dokumentenorientierte Arbeiten und das Abschaffen des Fileselektors sind verwandt können aber separat angegangen werden.
Wie oft hattest du schon die Situation, dass du deine Arbeit sichern wolltest und den Fileselektor abgebrochen hast, weil die Tätigkeit dort nicht durchzuführen war. Bei KDE hat das dazu geführt, dass der Fileselektor immer mächtiger wurde, immer mehr Funktionalität vom Konqueror übernommen wurde (z.B. Preview).
Trotzdem, in seiner Vielfalt und Netzwerktransparenz ist der Konqueror unerreicht (meinetwegen unerreicht bezogen auf KDE) Bookmark-Leiste, Sitebar alles nicht so kompfortabel vorhanden im Fileselektor. Also, wenn man sowieso sein Dateiverwaltungstool hat, darf ja auch der Krusader oder der Nautilus sein, warum nicht einfach das zu speichende Dokument dahinziehen. Was braucht man dafür: Nur einen Repräsentanten für das Dokument - also ein Icon. Der Unterschied ist also, du bestimmst mit welchen Programm du deine Datenverwaltung machst, lernst dort mit der Zeit alle Tricks und musst nicht die eingeschränkte Funktionalität einer System-Fileselektorbox benutzen.
Ausserdem kannst du mehrere Konqueror (=Filer) permanent offen haben: z.B. /htm/gif und /htm/tif Beim Speichern aus deinem Grafikprogramm per Fileselektor musst du jedesmal wechseln, legst dir vielleicht ein Bookmark an, den du morggen schon gar nicht mehr bräuchtest.
Diese Fenster kannst du auf einen separaten Desktop packen. Alle relevanten Ordner für deine Arbeit auf einem Blick.
Ist vielleicht schwierig das so zu beschreiben, wer das kennt, liebt es einfach.
Übrigens bietet dir der Konqueror das Zuordnen meherer Apps zu einem Mime-Type, so eingerichtet, gehst du einfach auf dein (z.B.) HTML-Dokument und hast die Auswahl "Öffnen mit: Konqi, Netscape,Quanta, Kate": Du hast ein Dokument und bestimmst wie du es bearbeitest im Gegensatz du hast eine Applikation und bearbeitest damit Dokumente. Bei Windows weiss ich häufig nie wo meine Dateien liegen, wenn ich nicht "speichern unter" benutze.
Somit auch noch mal an @Tim:
Ich weiss nicht, ob man den Dokumentenbegriff soweit abstrahieren kann, wie du es oben vorschlägt. Ich glaube schon, dass ein so vielseitiges Werkzeug wie ein Computer, den Begriff von File und Folder zum Ordnen braucht.
Ist echt witzig, wie unterschiedlich diese Sichtweise ist. Ich weiss, ich kann z.B. meine Arbeit fortsezten, wenn ich KWord öffne und "kürzlich bearb. Dokument" anwähle, dann habe ich es mit 4 Klicks - mach ich nicht! Ich habe immer ein Konqi-Arbeitsfenster auf und klicke auf meine zu bearbeitende Datei.
Ist bestimmt alles nicht der Stein der Weisen, was ich hier beschreibe und jeder hat seine persönlichen Vorlieben, dennoch wer es kennt, vermisst es.
Schön, dass diese Diskussion entstanden ist!
Was ist den dieses QCom und Korelib und welche vorteile soll das bringen
by Mark
Ich hatte irgendwie angenommen, dass sowiso jeder weiß, was COM ist.
Arni hat es oben ja erklärt...
Cheers,
GNU/Wolfgang
Oder ist es nur für die Grafische Ausgabe gedacht?
Nicht direkt, aber über die easyV24-Library kannst du auf die Schnittstelle zugreifen. Habe es vor kurzem mit einem Modem erfolgreich getestet (mit meinem Qt-Anfängerwissen).
http://ezv24.sourceforge.net/
Dirk
Ist nicht gerade QT pur, aber vielleicht hilft dir dieser Thread
http://lists.kde.org/?t=100067239800014&w=2&r=1
Bye
Thorsten
> dass in der Community sich mehr Leute >darüber Gedanken machen, wie man verhindern >kann, dass die
> Entwicklung von Freier Software durch >unsinnige Gesetze behindert wird.
Ja, ich denke das ist in der Tat ein wichtiger Punkt, der immermehr an bedeutung gewinnen wird. Aber veleicht auch eine Change für die "dritte Welt" die auf's Copyright und Patente schei***. Vieleicht reguliet sich der Markt (b.z.w. die Gesetzgebung) selber, wenn Sie/Wir merken, das die Software woanders endsteht und die Endwicklung im eigenem Lande stillsteht.
mfg Rübezahl
Do you think that there are any areas in NM that could be at all
improved? Has it improved since you took over as DPL?
NM has improved a great deal since I became DPL, but not because of me by any means. I think because of my outspokeness about changes in NM, that some people were afraid I would dismantle the process and rebuild it, but I haven't touched it one bit other than talking to the DAM every so often.
--- unquote ---
Wer außer Hardcore-Debianern soll daraus schlau werden?
DPL = "Debian Project Leader"
NM = "New Maintainer"
DAM = Vermutlich "Debian Account Manager"
Cheers,
GNU/Wolfgang
Aber dann wird es ja wohl keine 3D beschleunigte Grafik mehr geben. Aber damit hab ich sowieso meine Probleme: Seit ich bei meinem Suse 7.1 die 3D Beschleunigung aktiviert habe, sehe ich immer schwarze Rechtecke bevor die Menüs kommen. Außerdem fillmert Opera beim scrollen. Weis jemand Rat?
Nope, es gibt auch wieder eine Version für die Framebuffer Console (Qt Embedded)
Außerdem könnte man dann in KDE 3 auch so schöne Funktionen wie Alphablending und nichtrechteckige Fenster einbauen.
Ist drinnen in Qt3. Läuft alles über die RENDER extension von X.
Aber dann wird es ja wohl keine 3D beschleunigte Grafik mehr geben.
Wieso? OpenGL hat damit nix zu tun. Das is ne ganz andere Kiste. OpenGL wird von Qt aber auch unterstützt.
OpenGL und RENDER sind nicht wirklich inkompatibel, nur antialiasing unter OpenGL muss kann natürlich nicht via RENDER gemacht werden, das sind zwei paar Socken.
Bei NVidia gab es mal das Problem, das die XFree treiber RENDER und die von NVidia nur OpenGL konnten. Das ist aber kein Problem mehr, da der Treiber von NVidia mittlerweile beides kann.
Seit ich bei meinem Suse 7.1 die 3D Beschleunigung aktiviert habe, sehe ich immer schwarze Rechtecke bevor die Menüs kommen. Außerdem fillmert Opera beim scrollen. Weis jemand Rat?
Yup. X-Server Bug. Updaten auf XFree 4.1.x
Gruß,
Meines wissens nach kann KDE nicht mit QT Embeddet umgehen, es wird aber wohl dran gearbeitet.
- Schnellere Applikationsentwicklung mit Qt Designer 2 (90% aller kdeui widgets werden für den designer verfügbar sein => weniger manueller source code => mehr Zeit für die Implementation / Bugfixing)
- Unkompliziertes Font handling
- Voller Bidi Support für sprachen, in denen nach rechts nach links geschrieben wird (versuch mal "kcontrol -reverse" in der alpha1 nächste Woche :)
- X konformes Copy&paste (mittlere Maustaste lässt grüßen :)
...und vieles mehr und das alles nur durch Qt selbst.
Die von KDE selbst geplanten Features
kannst du noch mal unter http://developer.kde.org/ development-versions/kde-3.0-features.html
hier nachlesen.
Gruß,
Daniel
>- Schnellere Applikationsentwicklung mit Qt Designer 2 (90% aller kdeui widgets werden für den designer verfügbar sein => weniger manueller source code => mehr Zeit für die Implementation / Bugfixing)<
Schön das die Nicht Borland Welt endlich auch die Vorteile eines solchen Anwendungsentwicklung versteht
Wäre schöne, wenn bei Konqueror (crusader, kcommander, ...) bei den Atrributen auch ACLS angelegt werden könnten, die dann auch gleich die effektiven BErechtigungen anzeigen.
Bei Konqueror bekomme ich nur ugw angezeigt - oder hab ich was übersehen (Compile Time ?)
Ergebnis: Solange der (offizielle) Linux kernel kein FS mit ACLs anbietet und noch ein riesenchaos zwischen den verschiedenen Versionen/Implementierungen herrscht,
wird es wohl keinen offiziellen Support geben (nicht maintainbar).... es sei denn (wie fast immer), jemand hat da einen Patch :)
Gruß,
Daniel