öh.. einheitliche Usability war weder das Ziel von KDE noch von GNOME... wenn überhaupt wollen sie eine höhere Interoperatibilität schaffen.. das die Programme super zusammen arbeiten auf unterer Ebene.. das sich alles gleich benutzt war nie das Ziel und wird es HOFFENTLICH nie werden, da zwei unterschiedliche Wege denke ich schon von Nöten sind... ( KDE und GNOME werden immer eigener von ihren Wegen her.. und das finde ich eine Bereicherung )..
sehe ich genauso. Wichtig ist das zusammenspiel auf "unterer Ebene", also das möglichst problemlos drag-and-drop geht oder das sich gtk Programme genauso in die "Notification Area" von kde einbinden können wie umgekehrt. Ansonsten bin ich froh, dass kde und gnome zwei verschiedene Wege gehen. Wenn beide exakt gleich wären, dann gäbe es ja keinen Grund mehr das eine oder das andere zu verwenden und letztlich auch keinen Grund mehr "zweimal das gleiche" zu entwickeln.
Also von mir ein "weiter so!" an alle gnome, kde, gtk und qt Hacker, da wird auf allen Seiten Top Arbeit geleistet!
Von Papa Schlumpf am So, 19. Dezember 2004 um 15:30 #
Vielleicht wäre es sinnvoller, Applikationen so zu schreiben, daß man wahlweise KDE/QT oder GNOME/GTK verwendet. Die eigentliche Applikation als library die von der entsprechenden GUI dann verwendet wird, also so in etwa /usr/lib/libmyapp.so /usr/kde/bin/kmyapp /usr/gnome/bin/gmyapp
libmyapp.so wäre dann aber in vielen Fällen auch mit Qt geschrieben und würde gegen die KDE-Libs linken.
Qt ist wesentlich mehr als ein GUI-Toolkit, und die Benutzung von KDE-Technologien wie z.B. den IOSlaves ist keine Sache der GUI, sondern liegt im Kern der Anwendung. Analoges dürfte gelten, wenn die Kernanwendung aus dem GNOME-Lager stammt bzw. dort gut integriert sein soll. Integration ist nichts "Oberflächliches"!
Ich fürchte, das Vorgeschlagene ist Wunschdenken und kaum realisierbar ohne auf wesentliche Stärken zu verzichten, was nicht wünschenswert ist.
Nur für einen eng eingegrenzten Aufgabenbereich lässt sich IMHO so etwas machen. Beispiele: libxml2 und libxslt. Beide kommen ohne GNOME-libs aus. Und siehe da, KDE benutzt sie auch, "obwohl" sie ursprünglich aus dem GNOME-Projekt stammen.
Du mich auch. Besser Verzeichnisse wie /usr/kde, als wenn alles in /usr rumwuselt. Das ist nämlich das reinste Chaos. Man kann natürlich auch /usr/local/kde oder /opt/kde nehmen, wenn einem /usr/kde nicht gefällt.
genau. ignorieren wir saemmtliche geltenden standards weil wirs von windows so gewohnt sind. und weil windows die dateien ja nach programm ordnet warum nicht auch auf linux? hast du mal drueber nachgedacht warum der fhs so ist wie er ist? das es z.b. darum geht die verzeichnisse uebers netzwerk zu sharen und so? da macht das so eine partitionierung schwer(er). ausserdem um ordnung in das "chaos" zu bringen habe ich ein paketsystem und du?
Tja, /usr/X11R6, /usr/games, /opt/kde und /opt/gnome gibts schon. Da macht ein /usr/kde keinen Unterscheid mehr.
Übrigens ergibt es schon weniger Sinn, KDE-Programme wie konqueror in /usr/bin abzulegen, weil es nun mal grafische Anwendungen sind, die dann doch eher sogar in /usr/X11R6/bin reingehören.
/usr/X11R6 ist ein relikt.. fd.org hat IIRC auf irgendner TODO Liste stehen den xserver direkt in /usr unterzubringen. /usr/games enthaellt nur binaries wie /usr/bin keine komplette hierachie wie es /usr/kde tut. und die /opt/ sachen naja sie widersprechen dem fhs nicht, aber sind sehr unelegant.
Da wird nur ein neues Widget für angeboten.. im Augenblick ist ein File öffnen in einem Formular nix anderes als ein normales Textfeld mit einem normalem Button daneben.. und eben das kann man jetzt ändern in ein eigenes Widget für diesen Zweck.. Allerdings müssen natürlich erst die ganzen Entwickler ihre Programme dahingehend modifzieren bevor man was davon sieht wie damals beim neuen File Selector..
Ich finde diesen neuen Dateiauswahldialog einfach nur zum kotzen. Der alte war doch wunderbar, warum haben die da so ne Wurst draus gemacht? Gibt es zufaellig eine moeglichkeit den alten Dialog zu "erzwingen"? Evtl. ueber .gtkrc-2.0?
Hm, bei Windows und KDE scrollt man rüber statt runter - das finde ich unnatürlich: Man liest von links nach rechts, dann von oben nach unten, nicht erst von oben nach unten und dann von links nach rechts. Auch Scrollräder an Mäusen sind zum nach unten Scrollen (wenn es nicht grad ne Maus mit 2 Rädern ist) Die meisten Webdesigner achten darauf, dass man ihre Webseiten nicht rüber sondern nur runter scrollen muss und Texteditoren brechen Zeilen meist um, um das Rüberscrollen zu verhindern. Die Windows- und KDE-Auswahldialoge sind hier einfach unkonventionell.
Von Torsten Rahn am So, 19. Dezember 2004 um 16:21 #
> Hm, bei Windows und KDE scrollt man > rüber statt runter - das finde ich > unnatürlich: Man liest von links nach > rechts, dann von oben nach unten, nicht > erst von oben nach unten und dann von > links nach rechts.
Nein. Sobald Deinem Gehirn die Information deutlich mehrspaltig gegliedert präsentiert wird, liest Du zunächst von oben nach unten und dann von links nach rechts. Heißt also: erste Spalte von ganz oben nach unten durchscrollen und dann zurück zu dem Ausschnitt oben, den man schon angezeigt hatte, um die zweite Spalte von oben nach unten durchzuscrollen. Um diesen Verschnitt zu vermeiden verwendet Windows das Scrollen von links nach rechts, was auf den ersten Blick unlogisch erscheint.
Wir hatten früher mal in einer KDE-Beta (1.9...) deine "natürliche" Scrollweise implementiert und dafür soviel Haue bekommen, dass wir wieder ganz schnell zurückgewechstelt haben ...
Helf mir mal schnell auf die Sprünge. ich habe zwar schon nen Moment lang kein KDE mehr in den Fingern gehabt (Gibts eigentlich so was wie Ubuntu nur mit KDE anstatt Gnome?) war war es beim KDE-Dateidialog nicht möglich die Ansicht umzustellen auf Details so das man nach unten scrollen muß?
Von Torsten Rahn am So, 19. Dezember 2004 um 20:40 #
Doch, obwohl wir das als Default herausgenommen haben, erinnere ich auch, dass sich das bis "vor kurzem" noch innerhalb des KDE-Dateidialogs über die rechte Maustaste oder das Konfigurieren-Symbol in der Werkzeugleiste umkonfigurieren ließ. Ist aber offenbar irgendwann einmal beim Frühjahrsputz obsoletiert worden
Mag sein, dass das in die eine Richtung (also vorwaerts) ganz gut geht, aber versuche es mal in die andere Richtung (also abwaerts). Das ist vor allem schwierig, da die Dialoge meistens viel breiter als hoch sind. Meistens sind die Dateien alphabetisch geordnet und wenn du nun Spalten hasst, "reisst" du die Ordnung "diagonal" auseinander und die Suche nach einer bestimmten Datei wird schwierig.
Von Manfred Tremmel am Mo, 20. Dezember 2004 um 12:24 #
Mir gefällt das nach rechts scrollen auch nicht, also stell ich die Ansicht eben um auf Detailansicht. Schon mal mit der rechten Maustaste in die Dateiübersicht geklickt?
Was mich wirklich stört ist daß man keine .-Dateien auswählen kann. An sonsten finde ich den Dialog nicht so schlecht. Würde mir aber D&D-Saving wünschen, so, wie es ROX anbietet. Das ist supereinfach und intuitiv. Im Grunde braucht kein Mensch so einen komplizierten Dialog nur zum öffnen oder schließen von Dateien - zumal man scheinbar noch nicht mal filtern kann, welche Dokumente angezeigt werden.
Tatsächlich Muß man aber erstmal drauf kommen. Es gibt auch noch die Möglichkeit Ctrl+L; da kann man Pfade eingeben. Das ist aber nicht wirklich intuitiv ... und GNUOME will das jei eigentlich gerade sein ...
bevor man sich diese frage stellt, muss man sich die frage stellen warum man überhaupt in ein verzeichnis mit einem '.' am beginn will.
der zweck dieser verzeichnisse ist es ja versteckt zu sein, der user hat im normalfall darin nichts zu suchen, darum ist es meiner meinung auch nicht wirklich notwendig einen extra button "versteckte dateien anzeigen" zu machen. macht ein programm notwendig oft versteckte dateien anzuzueigen liegt das problem wohl schon bei diesem.
mir fällt jetzt eigentlich nur eine aufgabe ein bei der es notwendig es in ein versecktes verzeichnis zu wechseln, und das ist themes zu installieren.
>macht ein Programm notwendig oft versteckte dateien anzuzueigen liegt das problem wohl schon bei diesem.
Damit sind z.B. gedit oder gvim potenzielle Problemprogramme. ;) Aber im Grunde hast Du schon recht. Früher war das einfach und man brauchte keinen solchen Button , weil man ja direkt dem Pfad eingeben konnte. Jetzt geht das mit Strg+L genauso. Es stimmt schon; es ist durchaus sinnvoll, selten genutze Funktionen in soweit auszulagern, daß man nicht ein so überladenes Interface wie das von KDE bekommt. Was mir allerdings gerade noch aufgefallen ist und was ich für einen Designfehler halte ist, daß im Dialog auf ein Objekt doppelklicken muß um es zu öffnen, auch, wenn man einfach-Klick aktiviert hat.
> [...] ein so überladenes Interface wie das von KDE Hast Du Dir den KDE-File-Dialog wirklich mal angesehen? Was ist denn daran überladen?
Du hast oben die Schnellnavigationsleiste, die ich im übrigen anfängerfreundlicher finde als das Anklicken von ".."-Listeneinträgen, links die Schnellwahlziele und rechts die Dateiliste. Punktverzeichnisse oder -dateien sind auch hier per Werkseinstellung unsichtbar, was ich ebenso als sinnvoll erachte.
Bitte erklär mir doch mal genauer, was Du also am KDE-File-Dialog überladen findest.
Ich meinte mit "überladenem Interface" das gesamte User-Interface von KDE, nicht den File-cooser. Ja, ich kenne diesen bei KDE. Ich glaube allerdings, daß Du den von Gnome nicht kennst. ..-Listeneinträge gibt es nämlich seit GNOME 2.6 nicht mehr.
> Ich glaube allerdings, daß Du den von Gnome nicht kennst. ..-Listeneinträge > gibt es nämlich seit GNOME 2.6 nicht mehr. Da muß ich Dich enttäuschen(/erfreuen?) ich kenne ihn. Die Aussage über die ..-Listeneinträge war allgemein gewählt und nicht auf die (neueren) Gnomeapplikationen bezogen - so ähnlich wie das Beispiel mit den versteckten Verzeichnissen.
Von Christian Neumair am So, 19. Dezember 2004 um 22:08 #
> Was mir allerdings gerade noch aufgefallen ist und was ich für einen > Designfehler halte ist, daß im Dialog auf ein Objekt doppelklicken muß > um es zu öffnen, auch, wenn man einfach-Klick aktiviert hat.
Ja, damit hast Du vollkommen recht. Leider hat sich noch niemand die Mühe gemacht, meinen Patch [1] einzupflegen - vermutlich, weil noch ungeklärt ist, wie das Einfachklick-Verhalten in der Lesezeichenleiste zu realisieren ist. Ich werde mir das evtl. noch mal anschauen.
> Damit sind z.B. gedit oder gvim potenzielle Problemprogramme.
also ich verwende oft gedit, musst aber glaube ich noch nie um dieses verwenden zu können eine verseckte datei editieren. wenn du mit gedit oder gvim eine versteckte datei editieren musst, dann machst du das weil irgend einem anderen programm die möglichkeit fehlt wichtige einstellungen vorzunehmen. der editor ist also nur das werkzeug, nicht das problem selbst.
ich sehe das ganze so: einfache, oft vorzunehmende funktionen gehören auch an eine leicht auffindbare stelle, dass das nicht eine versteckte datei ist sagt schon der name selbst. funktionen die der durchschnittsuser nicht braucht kann man ruhig verstecken (das macht es für alle anderen übersichtlicher), aber von usern die diese funktionen benötigen kann man auch erwarten dass sie auch mit den versteckten optionen in dem gtk dialog zurecht kommen.
> Was mir allerdings gerade noch aufgefallen ist und was ich für einen Designfehler halte ist, daß im Dialog auf > ein Objekt doppelklicken muß um es zu öffnen, auch, wenn man einfach-Klick aktiviert hat.
ich verwende den einfachklick nicht, kann das deshalb auch nicht nachvollziehen, aber ich glaube dir auch so. ;) dass der gtk dialog perfekt ist will ich auch nicht behaupten. z.b. hätte ich auch gerne über der kontext menü die möglichkeit ordner umzubenennen, ist etwas umständlich wenn man ein neues verzeichnis bei speichern anlegt, sich vertippt, und dann in den dateie manager muss um es umzubennenen.
aber ich finde es einfach falsch wenn viele leute (nicht auf dich bezogen) so argumentieren als wäre alles was anderens ist als kde auch schlecht ist, sich aber keine gedanken darüber machen warum das so ist und nur "sehen es ist anders und deshalb schlecht".
meine meinung über den gtk-dialog ist dass es durchaus verbesserungsmöglichkeiten gibt, halten den grundaufbau aber durchaus für gut.
>Denn der typische Normaluser wird ganz sicher nicht nachschlagen >ob das mit irgendeiner Tastenkombination noch geht.
Der "typische Normaluser", wie ich ihn in freier Wildbahn, beobachten konnt wird es schon deshalb nicht vermissen, weil er es garnicht braucht. Also wenn ich mich bei "Normalusern" umsehe, dann gibt es da prinzipiell alles nicht, was nicht mit ein paar Mausklicks zu erledigen ist. Da wird im Dateidialog munter durch die 1-2 Verzeichnisse geklickt und die Datei ausgewählt und fertig, ich habe noch nie einen "normaluser" gesehen, der bei einem Dateidialog das Eingabefeld benutzt hat... und wenn er sowei ist, dass er ein paar Tastendrücke für bequemer/effektiver hält als einen Mausklick, dann wird er auch Ctrl+l kennen lernen.
>Und wie willst du wissen ob er es nicht braucht, wenn du es ihm nicht anbietest und dann nachprüfst ob er es benutzt?
Weil er es auf windows, kde,... auch nie verwendet hat? Und indem Moment wo er sowas braucht oder vermisst (z.B. weil er seine Dateien wie in der Bash sauber und schnell mit tab auswählen will), da glaubst du garnicht für was man den Mund oder die Finger alles gebrauchen kann (Stichwort: Fragen) oder was man alles so nachlesen kann. Aber dann sprechen wir imho nichtmehr vom "Normaluser" um den du dir ja sorgen machst.
>Gut, dann reden wir mal vom Power User. >Warum kann der einfach nicht global einstellen, das so ein Feld standardmäßig vorhanden ist?
Ich habe nie gesagt, dass der Filedialog perfekt ist! ja, über so eine Option könnte man in gconf nachdenken. Warum es jetzt noch nicht geht? Zwei mögliche Antworten: 1. Weil der neue Filedialog noch sehr jung ist, Verbesserungen in neuen Versionen wären also alles andere als überraschend. 2. Weil du oder ein anderer diese Option noch nicht an offizieller Stelle angeregt haben oder sogar eine erste implementierung angeboten haben.
>Warum muß es unbedingt notwendig sein, das dieser erst STRG+L drücken muß?
Zum Beispiel weil du deine Kriffel eh schon an der Tastatur hast.
>IMHO ist das total umständlich.
imho vielleicht noch nicht die ideale Lösung (siehe überlegung mit Option in gconf) aber die Richtung stimmt und von strg+l ist noch niemand gestorben. Es passt ja auch gut zu den nautilus Tastenkombinationen, da wäre es übrigens nicht schlecht wenn strg+l direkt auf dem Desktop funktionieren würde (wenn wir schon bei verbesserungen sind ).
Also ich finde den neuen Dialog eigentlich im Prinzip ganz gut, nur das was mir fehlt ist die Möglichkeit per Copy&Paste oder Tastatureingabe eine Adresse eingeben zu können um dann z.b. ein paar Ebenen weiter zu springen ohne sich erst mit der Maus hindurchhangeln zu müssen. Genau das konnte der alte Dialog besonders gut.
Außerdem fehlt mir noch die Möglichkeit Ebenen durch ein Pfeilsymbol anstatt einem spezifizierten Verzeichnisnamen zu wechseln. So ist es z.B. beim neuen Dateidialog ziemlich kompliziert vom eigenen Homeverzeichnis ein Verzeichnis tiefer zu gehen. Also z.B. von /home/username nach /home
Denn das geht nicht. Die einzige Möglichkeit um dort hinzugelangen ist in dem man auf den vorgegebenen Link namens Dateisystem klickt, dann landet man in / und muß aber erstmal /home suchen.
Man benötigt beim neuen Dateidialog also immer 2 Schritte um nach /home zu gelangen.
Bei einem KDE Dateidialog benötigt man nur einen, in dem man auf das Pfeil hoch Symbol klickt.
Und mal ehrlich, es macht keinen großen Sinn einen extra Link/Lesezeichen für /home anzulegen wenn man mit einem Pfeil Hoch Button auch so dahin kommen könnte.
Von Christian Neumair am So, 19. Dezember 2004 um 22:14 #
So richtig sehe ich da leider bei der derzeitigen Dialogstruktur leider keine Abhilfe - es sei denn, man gelänge per Alt+Up automatisch nach /home. Klingt das vernünftig? :).
Mal ne naive Frage: Üblicherweise liegen in /home ja nur Unterverzeichnisse. Ist es da nicht geschickter, diese direkt zu bookmarken?
>Mal ne naive Frage: Üblicherweise liegen in /home ja nur Unterverzeichnisse. Ist es da nicht geschickter, diese direkt zu bookmarken?
Ich ergänze diese Frage noch: Überlicherweise liegen in /home nur noch home-Verzeichnisse anderer Benutzer. Wann muß ich also als Benutzer1 nach /home wechseln? In dem Verzeichnis von Benutzer2 werden wohl kaum meine Dokumente, Bilder,... liegen.
erstens dass, und zweitens ist ein Bookmark für ein gemeinsammes Datenverzeichnis sicher gut investiert. (Dann bist du sogar wieder schneller wie z.B. bei KDE, da du nichtmehr eine Ebene hoch und wieder in ein Verzeichnis rein mußt, sondern direkt über den bookmark "share" oder ähnlich in das Verzeichnis kommst.)
Denn ,wenn sie nicht in /home gehören, wo gehören sie dann hin?
Meines wissens nach gibt es keinen geeigneteren Ordner dafür als /home.
Es wurde in der FHS jedenfalls noch nichts definiert das diesen Job besser übernehmen könnte als /home. Man beachte, wir reden von Nutzdaten und nicht von Programmdaten! Und /mnt ist eher etwas für Wechselmedien,
So einen Ordner in /home anzulegen hat einen großen Vorteil, denn so kann man diesen bequem mit allen anderen Benutzerdaten auf einer extra Partition/Festplatte auslagern und einfach und bequem Backups davon erstellen bzw. diesen Bereich speziell behandeln -> Raid System für höhere Datensicherheit etc..
Es ist seltsam, dass Gtk ausgerechnet mit dem Dateiauswahldialog solche Zicken macht. Sollen sie doch lieber das KDE design übernehmen und sich auf eine angemessene Integration von Dateisuchfunktionen stürzen.
Nur leider ist das KDE Design der Dateiauswahldialoge nicht sehr intelligent. Es wird nicht ueberlegt, was wirklich rein muss, sondern frei nach dem Motto: "Lieber alles reinpacken, so kann nichts vermisst werden". Jedoch ist dies vor allem Dingen fuer Anfaenger sehr verwirrend.
Warum muss der Datei-Oeffnen-Dialog eine Option "Verzeichnis erstellen" haben? Um eine Datei zu oeffnen, brauche ich kein neues Verzeichnis erstellen. Wenn ich jedoch eine Datei abspeichern moechte, dann kann es sein, dass ich diese Datei in einem neuen Verzeichnis abspeichern moechte, also brauche ich nur da die Moeglichkeit.
Warum muessen beide Datei-Dialoge eine Option "Datei loeschen" haben? Wenn ich eine Datei oeffne oder speichere, dann muss ich keine Datei vorher loeschen (man kann sie ja ueberschreiben wenn sie schon vorhanden ist).
Wie die Namen schon sagen: es sind "Datei Oeffnen"- und "Datei Speichern"-Dialoge und keine Datei-Manager.
Hi.. nur mal kurz ein Beispiel für deine megasinnvolle Aussage: """" Es ist seltsam, dass Qt ausgerechnet mit dem Dateiauswahldialog solche Zicken macht. Sollen sie doch lieber das GNOME design übernehmen und sich auf eine angemessene Integration von Dateisuchfunktionen stürzen. """""
Merkst du was?.. sorum macht der Satz genausowenig Sinn wie andersrum... Bitte erst nachdenken dann posten..
Denn wo genau stand geschrieben das KDE auf jeden Fall immer 100% richtig liegt und GNOME sich anpassen muss?
Debian schafft es doch auch seit Jahren, unsignierte Pakete anzubieten, sogar als Securityupdate. Es scheint wohl viele Anwender zu geben, die meinen, dass FTP Server nie gehackt werden, oder denen es egal ist, ob sie sich einen neuen Trojaner installieren.
Mittlerweile sind aber die MD5-Summen der Paketlisten, in der die MD5-Summen der einzelnen Pakete stehen, mit GPG signiert und werden auch von apt bei einem update geprüft. Und die Source-Packages sind mit ihren .dsc- und .changes-Dateien signiert.
Signierte MD5s für Gnome wären trotzdem nicht schlecht. Das Linuxkernel-Archniv hats immerhin. Wer in den FTP-Server einrbicht, um Pakete zu verändern, kann sicher auch die MD5-Summen neu erstellen.
Kennt jemand einen screenshot des neuen AboutDialog? Ich weiß, eigentlich ziemlich unwichtig, aber es würde mich interessieren wie der aussieht und ob ich in Zukunft meine Eigenentwicklung wegschmeissen kann. Also, wenn jemand einen screenshot hat oder kennt...
Das ist der About-Dialog, der vorher in libgnomeui drin gewesen ist. Er hat gewissermaßen nur den Ort gewechselt, soweit mir bekannt ist.
Wenn Du also ein Programm installiert hast, das libgnomeui benutzt, kannst Du ihn Dir selbst anschauen. Beispiele wären laut `apt-cache rdepends libgnomeui-0` gnumeric, rhythmbox, firestarter, sound-juicer, drivel, anjuta, evolution, und viele mehr. Es kann natürlich sein, daß manche davon eine eigenen About-Dialog verwenden.
Also das was er bietet hört sich nicht schlecht an:
> New about dialog widget > > The GtkAboutDialog widget is a replacement for the GnomeAbout > dialog in the libgnomeui library. In addition to the features > found in the GnomeAbout dialog, it supports displaying of > license information and http: and mailto: links.
ok...Strg+L geht. aber erst mal drauf kommen. bei rechter Maustaste passiert genaugar nichts. zum sinn von .files: ich hab mein buddy icon in .gaim/icon.jpg
öh.. einheitliche Usability war weder das Ziel von KDE noch von GNOME... wenn überhaupt wollen sie eine höhere Interoperatibilität schaffen.. das die Programme super zusammen arbeiten auf unterer Ebene.. das sich alles gleich benutzt war nie das Ziel und wird es HOFFENTLICH nie werden, da zwei unterschiedliche Wege denke ich schon von Nöten sind... ( KDE und GNOME werden immer eigener von ihren Wegen her.. und das finde ich eine Bereicherung )..
Gruß
Waldgeist
Ansonsten bin ich froh, dass kde und gnome zwei verschiedene Wege gehen. Wenn beide exakt gleich wären, dann gäbe es ja keinen Grund mehr das eine oder das andere zu verwenden und letztlich auch keinen Grund mehr "zweimal das gleiche" zu entwickeln.
Also von mir ein "weiter so!" an alle gnome, kde, gtk und qt Hacker, da wird auf allen Seiten Top Arbeit geleistet!
/usr/lib/libmyapp.so
/usr/kde/bin/kmyapp
/usr/gnome/bin/gmyapp
Qt ist wesentlich mehr als ein GUI-Toolkit, und die Benutzung von KDE-Technologien wie z.B. den IOSlaves ist keine Sache der GUI, sondern liegt im Kern der Anwendung. Analoges dürfte gelten, wenn die Kernanwendung aus dem GNOME-Lager stammt bzw. dort gut integriert sein soll. Integration ist nichts "Oberflächliches"!
Ich fürchte, das Vorgeschlagene ist Wunschdenken und kaum realisierbar ohne auf wesentliche Stärken zu verzichten, was nicht wünschenswert ist.
Nur für einen eng eingegrenzten Aufgabenbereich lässt sich IMHO so etwas machen. Beispiele: libxml2 und libxslt. Beide kommen ohne GNOME-libs aus. Und siehe da, KDE benutzt sie auch, "obwohl" sie ursprünglich aus dem GNOME-Projekt stammen.
http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE18
Übrigens ergibt es schon weniger Sinn, KDE-Programme wie konqueror in /usr/bin abzulegen, weil es nun mal grafische Anwendungen sind, die dann doch eher sogar in /usr/X11R6/bin reingehören.
Da wird nur ein neues Widget für angeboten.. im Augenblick ist ein File öffnen in einem Formular nix anderes als ein normales Textfeld mit einem normalem Button daneben.. und eben das kann man jetzt ändern in ein eigenes Widget für diesen Zweck.. Allerdings müssen natürlich erst die ganzen Entwickler ihre Programme dahingehend modifzieren bevor man was davon sieht wie damals beim neuen File Selector..
Gruß
Waldgeist
Grüße
Sturmkind
"man" = "wir" ... natürlich nicht in Sprachen, wo man von rechts nach links liest.
> rüber statt runter - das finde ich
> unnatürlich: Man liest von links nach
> rechts, dann von oben nach unten, nicht
> erst von oben nach unten und dann von
> links nach rechts.
Nein. Sobald Deinem Gehirn die Information deutlich mehrspaltig gegliedert präsentiert wird, liest Du zunächst von oben nach unten und dann von links nach rechts. Heißt also: erste Spalte von ganz oben nach unten durchscrollen und dann zurück zu dem Ausschnitt oben, den man schon angezeigt hatte, um die zweite Spalte von oben nach unten durchzuscrollen. Um diesen Verschnitt zu vermeiden verwendet Windows das Scrollen von links nach rechts, was auf den ersten Blick unlogisch erscheint.
Wir hatten früher mal in einer KDE-Beta (1.9...) deine "natürliche" Scrollweise implementiert und dafür soviel Haue bekommen, dass wir wieder ganz schnell zurückgewechstelt haben ...
Grüße,
Torsten
Grüße
Sturmkind
Ist aber offenbar irgendwann einmal beim Frühjahrsputz obsoletiert worden
Grüße
Sturmkind
Grüße
Sturmkind
...Meiner Meinung nach...
Rüber? Wo rüber? Ich scrolle bei KDE nach unten durch die Liste.
Den alten aber moechte ich nur ungern weggeben...
Würde mir aber D&D-Saving wünschen, so, wie es ROX anbietet. Das ist supereinfach und intuitiv. Im Grunde braucht kein Mensch so einen komplizierten Dialog nur zum öffnen oder schließen von Dateien - zumal man scheinbar noch nicht mal filtern kann, welche Dokumente angezeigt werden.
Grüße
nidhoegg
Hm, bei mir geht das: rechte Maustaste in der Dateiauswahlliste -> Show Hidden Files -> Datei auswaehlen -> fertig
Grüße
nidhoegg
der zweck dieser verzeichnisse ist es ja versteckt zu sein, der user hat im normalfall darin nichts zu suchen, darum ist es meiner meinung auch nicht wirklich notwendig einen extra button "versteckte dateien anzeigen" zu machen.
macht ein programm notwendig oft versteckte dateien anzuzueigen liegt das problem wohl schon bei diesem.
mir fällt jetzt eigentlich nur eine aufgabe ein bei der es notwendig es in ein versecktes verzeichnis zu wechseln, und das ist themes zu installieren.
Damit sind z.B. gedit oder gvim potenzielle Problemprogramme. ;)
Aber im Grunde hast Du schon recht. Früher war das einfach und man brauchte keinen solchen Button , weil man ja direkt dem Pfad eingeben konnte. Jetzt geht das mit Strg+L genauso.
Es stimmt schon; es ist durchaus sinnvoll, selten genutze Funktionen in soweit auszulagern, daß man nicht ein so überladenes Interface wie das von KDE bekommt.
Was mir allerdings gerade noch aufgefallen ist und was ich für einen Designfehler halte ist, daß im Dialog auf ein Objekt doppelklicken muß um es zu öffnen, auch, wenn man einfach-Klick aktiviert hat.
Grüße, nidhoegg
Hast Du Dir den KDE-File-Dialog wirklich mal angesehen? Was ist denn daran überladen?
Du hast oben die Schnellnavigationsleiste, die ich im übrigen anfängerfreundlicher finde als das Anklicken von ".."-Listeneinträgen, links die Schnellwahlziele und rechts die Dateiliste. Punktverzeichnisse oder -dateien sind auch hier per Werkseinstellung unsichtbar, was ich ebenso als sinnvoll erachte.
Bitte erklär mir doch mal genauer, was Du also am KDE-File-Dialog überladen findest.
lg
Erik
Gruß, nidhoegg
> gibt es nämlich seit GNOME 2.6 nicht mehr.
Da muß ich Dich enttäuschen(/erfreuen?) ich kenne ihn. Die Aussage über die ..-Listeneinträge war allgemein gewählt und nicht auf die (neueren) Gnomeapplikationen bezogen - so ähnlich wie das Beispiel mit den versteckten Verzeichnissen.
lg
Erik
> Designfehler halte ist, daß im Dialog auf ein Objekt doppelklicken muß
> um es zu öffnen, auch, wenn man einfach-Klick aktiviert hat.
Ja, damit hast Du vollkommen recht. Leider hat sich noch niemand die Mühe gemacht, meinen Patch [1] einzupflegen - vermutlich, weil noch ungeklärt ist, wie das Einfachklick-Verhalten in der Lesezeichenleiste zu realisieren ist. Ich werde mir das evtl. noch mal anschauen.
MfG,
Chris
[1] http://bugzilla.gnome.org/show_bug.cgi?id=121113
also ich verwende oft gedit, musst aber glaube ich noch nie um dieses verwenden zu können eine verseckte datei editieren.
wenn du mit gedit oder gvim eine versteckte datei editieren musst, dann machst du das weil irgend einem anderen programm die möglichkeit fehlt wichtige einstellungen vorzunehmen. der editor ist also nur das werkzeug, nicht das problem selbst.
ich sehe das ganze so:
einfache, oft vorzunehmende funktionen gehören auch an eine leicht auffindbare stelle, dass das nicht eine versteckte datei ist sagt schon der name selbst. funktionen die der durchschnittsuser nicht braucht kann man ruhig verstecken (das macht es für alle anderen übersichtlicher), aber von usern die diese funktionen benötigen kann man auch erwarten dass sie auch mit den versteckten optionen in dem gtk dialog zurecht kommen.
> Was mir allerdings gerade noch aufgefallen ist und was ich für einen Designfehler halte ist, daß im Dialog auf
> ein Objekt doppelklicken muß um es zu öffnen, auch, wenn man einfach-Klick aktiviert hat.
ich verwende den einfachklick nicht, kann das deshalb auch nicht nachvollziehen, aber ich glaube dir auch so. ;)
dass der gtk dialog perfekt ist will ich auch nicht behaupten.
z.b. hätte ich auch gerne über der kontext menü die möglichkeit ordner umzubenennen, ist etwas umständlich wenn man ein neues verzeichnis bei speichern anlegt, sich vertippt, und dann in den dateie manager muss um es umzubennenen.
aber ich finde es einfach falsch wenn viele leute (nicht auf dich bezogen) so argumentieren als wäre alles was anderens ist als kde auch schlecht ist, sich aber keine gedanken darüber machen warum das so ist und nur "sehen es ist anders und deshalb schlecht".
meine meinung über den gtk-dialog ist dass es durchaus verbesserungsmöglichkeiten gibt, halten den grundaufbau aber durchaus für gut.
dann werte ich das so, daß diese Möglichkeit nicht vorhanden ist.
Mit anderen Worten, im GTK Dateidialog ist es nicht möglich einen Pfad einzugeben.
Ctrl+L zählt nicht.
Denn der typische Normaluser wird ganz sicher nicht nachschlagen
ob das mit irgendeiner Tastenkombination noch geht.
Hier hat man Usability mäßig einfach riesen Mist gebaut.
>ob das mit irgendeiner Tastenkombination noch geht.
Der "typische Normaluser", wie ich ihn in freier Wildbahn, beobachten konnt wird es schon deshalb nicht vermissen, weil er es garnicht braucht. Also wenn ich mich bei "Normalusern" umsehe, dann gibt es da prinzipiell alles nicht, was nicht mit ein paar Mausklicks zu erledigen ist. Da wird im Dateidialog munter durch die 1-2 Verzeichnisse geklickt und die Datei ausgewählt und fertig, ich habe noch nie einen "normaluser" gesehen, der bei einem Dateidialog das Eingabefeld benutzt hat... und wenn er sowei ist, dass er ein paar Tastendrücke für bequemer/effektiver hält als einen Mausklick, dann wird er auch Ctrl+l kennen lernen.
Weil er es auf windows, kde,... auch nie verwendet hat?
Und indem Moment wo er sowas braucht oder vermisst (z.B. weil er seine Dateien wie in der Bash sauber und schnell mit tab auswählen will), da glaubst du garnicht für was man den Mund oder die Finger alles gebrauchen kann (Stichwort: Fragen) oder was man alles so nachlesen kann. Aber dann sprechen wir imho nichtmehr vom "Normaluser" um den du dir ja sorgen machst.
Warum kann der einfach nicht global einstellen, das so ein Feld standardmäßig vorhanden ist?
Warum muß es unbedingt notwendig sein, das dieser erst STRG+L drücken muß?
IMHO ist das total umständlich.
>Warum kann der einfach nicht global einstellen, das so ein Feld standardmäßig vorhanden ist?
Ich habe nie gesagt, dass der Filedialog perfekt ist!
ja, über so eine Option könnte man in gconf nachdenken.
Warum es jetzt noch nicht geht? Zwei mögliche Antworten:
1. Weil der neue Filedialog noch sehr jung ist, Verbesserungen in neuen Versionen wären also alles andere als überraschend.
2. Weil du oder ein anderer diese Option noch nicht an offizieller Stelle angeregt haben oder sogar eine erste implementierung angeboten haben.
>Warum muß es unbedingt notwendig sein, das dieser erst STRG+L drücken muß?
Zum Beispiel weil du deine Kriffel eh schon an der Tastatur hast.
>IMHO ist das total umständlich.
imho vielleicht noch nicht die ideale Lösung (siehe überlegung mit Option in gconf) aber die Richtung stimmt und von strg+l ist noch niemand gestorben. Es passt ja auch gut zu den nautilus Tastenkombinationen, da wäre es übrigens nicht schlecht wenn strg+l direkt auf dem Desktop funktionieren würde (wenn wir schon bei verbesserungen sind
).
> Zum Beispiel weil du deine Kriffel eh schon an der Tastatur hast.
Ne, denn eigentlich wollte ich mit der Maus Copy & Pasten
nur das was mir fehlt ist die Möglichkeit per Copy&Paste oder Tastatureingabe eine Adresse eingeben zu können um dann z.b. ein paar Ebenen weiter zu springen ohne sich erst mit der Maus hindurchhangeln zu müssen.
Genau das konnte der alte Dialog besonders gut.
Außerdem fehlt mir noch die Möglichkeit Ebenen durch ein Pfeilsymbol anstatt
einem spezifizierten Verzeichnisnamen zu wechseln.
So ist es z.B. beim neuen Dateidialog ziemlich kompliziert vom eigenen Homeverzeichnis
ein Verzeichnis tiefer zu gehen.
Also z.B. von /home/username nach /home
Denn das geht nicht.
Die einzige Möglichkeit um dort hinzugelangen ist in dem man
auf den vorgegebenen Link namens Dateisystem klickt, dann landet man
in / und muß aber erstmal /home suchen.
Man benötigt beim neuen Dateidialog also immer 2 Schritte um nach /home zu gelangen.
Bei einem KDE Dateidialog benötigt man nur einen, in dem man auf das Pfeil hoch Symbol klickt.
Und mal ehrlich, es macht keinen großen Sinn einen extra Link/Lesezeichen für /home anzulegen wenn man mit einem Pfeil Hoch Button auch so dahin kommen könnte.
Ein Home gibt es da nicht mehr.
Das gibt es nur wenn ich vom Wurzelverzeichnis anfange -> 2 Schritte.
Mal ne naive Frage: Üblicherweise liegen in /home ja nur Unterverzeichnisse. Ist es da nicht geschickter, diese direkt zu bookmarken?
MfG,
Chris
Ich ergänze diese Frage noch:
Überlicherweise liegen in /home nur noch home-Verzeichnisse anderer Benutzer. Wann muß ich also als Benutzer1 nach /home wechseln? In dem Verzeichnis von Benutzer2 werden wohl kaum meine Dokumente, Bilder,... liegen.
(Man beachte, es kann viele Gruppen geben!)
erstens dass, und zweitens ist ein Bookmark für ein gemeinsammes Datenverzeichnis sicher gut investiert.
(Dann bist du sogar wieder schneller wie z.B. bei KDE, da du nichtmehr eine Ebene hoch und wieder in ein Verzeichnis rein mußt, sondern direkt über den bookmark "share" oder ähnlich in das Verzeichnis kommst.)
Denn ,wenn sie nicht in /home gehören, wo gehören sie dann hin?
Meines wissens nach gibt es keinen geeigneteren Ordner dafür als /home.
Es wurde in der FHS jedenfalls noch nichts definiert das diesen Job besser übernehmen könnte als /home.
Man beachte, wir reden von Nutzdaten und nicht von Programmdaten!
Und /mnt ist eher etwas für Wechselmedien,
So einen Ordner in /home anzulegen hat einen großen Vorteil,
denn so kann man diesen bequem mit allen anderen Benutzerdaten
auf einer extra Partition/Festplatte auslagern und einfach und bequem Backups davon erstellen bzw. diesen Bereich speziell behandeln -> Raid System für höhere Datensicherheit etc..
Warum muss der Datei-Oeffnen-Dialog eine Option "Verzeichnis erstellen" haben? Um eine Datei zu oeffnen, brauche ich kein neues Verzeichnis erstellen. Wenn ich jedoch eine Datei abspeichern moechte, dann kann es sein, dass ich diese Datei in einem neuen Verzeichnis abspeichern moechte, also brauche ich nur da die Moeglichkeit.
Warum muessen beide Datei-Dialoge eine Option "Datei loeschen" haben? Wenn ich eine Datei oeffne oder speichere, dann muss ich keine Datei vorher loeschen (man kann sie ja ueberschreiben wenn sie schon vorhanden ist).
Wie die Namen schon sagen: es sind "Datei Oeffnen"- und "Datei Speichern"-Dialoge und keine Datei-Manager.
Wenn schon besser machen, dann auch richtig.
""""
Es ist seltsam, dass Qt ausgerechnet mit dem Dateiauswahldialog solche Zicken macht. Sollen sie doch lieber das GNOME design übernehmen und sich auf eine angemessene Integration von Dateisuchfunktionen stürzen.
"""""
Merkst du was?.. sorum macht der Satz genausowenig Sinn wie andersrum...
Bitte erst nachdenken dann posten..
Denn wo genau stand geschrieben das KDE auf jeden Fall immer 100% richtig liegt und GNOME sich anpassen muss?
Gruß
Waldgeist
Signierte MD5s für Gnome wären trotzdem nicht schlecht. Das Linuxkernel-Archniv hats immerhin. Wer in den FTP-Server einrbicht, um Pakete zu verändern, kann sicher auch die MD5-Summen neu erstellen.
Ich weiß, eigentlich ziemlich unwichtig, aber es würde mich interessieren wie der aussieht und ob ich in Zukunft meine Eigenentwicklung wegschmeissen kann.
Also, wenn jemand einen screenshot hat oder kennt...
Einen Screenshot würde ich mir auch gerne anschauen.
Wenn Du also ein Programm installiert hast, das libgnomeui benutzt, kannst Du ihn Dir selbst anschauen. Beispiele wären laut `apt-cache rdepends libgnomeui-0` gnumeric, rhythmbox, firestarter, sound-juicer, drivel, anjuta, evolution, und viele mehr. Es kann natürlich sein, daß manche davon eine eigenen About-Dialog verwenden.
> New about dialog widget
>
> The GtkAboutDialog widget is a replacement for the GnomeAbout
> dialog in the libgnomeui library. In addition to the features
> found in the GnomeAbout dialog, it supports displaying of
> license information and http: and mailto: links.
Allo
Gruß, nidhoegg
aber erst mal drauf kommen.
bei rechter Maustaste passiert genaugar nichts.
zum sinn von .files:
ich hab mein buddy icon in .gaim/icon.jpg
Allo