Guido Ostkamp wrote: > Ich erwähnte das hier nur als Hinweis, weil ich Dich so verstanden hatte, > daß Du gerne den Ansatz verfolgen würdest, "Überraschungen" beim Mergen > zweier Absätze zum Schutze von für Newbies zu vermeiden.
Es geht nicht um "Newbies" ausschließlich, es geht einfach um "Nicht-Experten". Und es geht generell um verständliches Verhalten. > Beim Hochziehen wird bei OOo das Zeichenformat aber nunmal evtl. geändert, > ergo erfolgt zwangsläufig eine solche "Überraschung". Das halte ich nicht für eine Überraschung, mit etwas Nachdenken wird jedem klar, dass es so sein muss, dass im Falle unterschiedlicher Absatzattribute/Styles ein Teil des neuen vereinigten Absatzes sich anpassen muss. Geht ja gar nicht anders. Überraschend finde ich es aber für den Nicht-Experten, dass sich BS und DEL unterschiedlich verhalten. Das sehen die "alten Hasen" sicherlich anders. Nur kann mir bisher niemand erklären, warum man diese Funktion so dringend gebraucht hat in all den Jahren, dass man dafür die negativen Überraschungseffekte für die Nicht-Experten in Kauf nehmen muss. Du siehst, ich wäge hier ab. Ein über Jahre sich als nützlich und notwendiges Feature würde ich nicht für Vereinfachungen entfernen wollen, aber das sehe ich hier nicht. Genauso plädiere ich immer gegen unnütze Features, die man *nur* aus "Kompatibilitätsgründen" einbaut. Meine nachzulesenden Kommentare zum Issue über "File-Page Setup" mögen dafür als Beleg dienen. Noch ein bischen Hintergrund, warum das unterschiedliche Verhalten schlecht ist und nebenbei darin noch durch das "Feature" übertroffen wird, dass sich BS und DEL doch gleich verhalten, wenn eine aufgespannte Selektion verwendet wird - dann zählt nämlich nur, in welcher Richtung die Selektion aufgespannt wurde, von vorne oder von hinten. Auch das gibt es im Writer seit Ewigkeiten, das macht es aber nicht automatisch sinnvoll. Am schlimmsten finde ich, dass beide "Features" nicht funkionieren, wenn Redlining an ist, auch wenn man es gar nicht anzeigen lässt. In diesem Fall gewinnt *immer* der erste Absatz. Auch bei Undo/Redo gibt es da Probleme. Das kann auch gar nicht anders sein, denn weder Redlining noch Undo/Redo wissen um diese Dinge. Da wird einfach nur eine Löschoperation aufgezeichnet. Wie vorher die Selektion vom Benutzer aufgespannt wurde oder welche Taste zum Löschen benutzt wurde, ist nicht verfügbar. Schon alleine aus diesem Grunde halte ich diese magischen Features für falsch. Es gibt auch einen Issue dafür, das abzuschalten. Momentan tendiere ich sehr stark dahin, dem Rechnung zu tragen. > Ich plädiere für klare und eindeutige Regeln und zwar ohne Sonderfälle, > also ohne Extrawürste wie etwa "bei Leerzeilen passiert aber dies" und > "bei Überschriften passiert aber das". Bei Letzterem bin ich bei dir, bei Leerzeilen nicht. Das Löschen eines leeren Absatzes ist kein "Zusammenführen" von Absätzen, es ist ein Löschen. Daher sollte es auch so behandelt werden, also der Absatz soll *samt seiner Formatierung* verschwinden. Das ist was grundsätzlich anderes, wenn beide Absätze noch Text enthalten. Klar und eindeutig muss nicht heißen "immer gleich". Es ist für mich unvorstellbar, dass man jedes Feature so implementieren kann, dass es sich in allen Situationen immer gleich verhält. Dann weiß man zwar immer, was passiert, nur wird einem das oft nicht gefallen. Allerdings sollten die Abweichungen einfach verständlich sein und immer einen erkennbaren Nutzen bringen, wie im Falle des Löschens leerer Zeilen. Es ist für mich einfach kein realer Fall denkbar, wo man möchte, dass die ja für den Benutzer noch nicht einmal sichtbare Formatierung auf den folgenden Absatz übertragen wird. Ich habe also für mich jetzt die folgende Strategie zusammengestellt: - Leere Absätze "verlieren" beim Löschen immer ihre Absatzattribute - "Harte" Einrückungen sollten auch weiter mit BS gelöscht werden können, nicht aber solche aus Styles; "indirekte" wie in Nummerierungen sind für mich noch offen. - Wenn nicht noch sehr wichtige Gründe für die Beibehaltung des unterschiedlichen Verhaltens von BS/DEL/Selektion gefunden werden, sollten wir das ausbauen. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
