Text aus Dialogboxen?
Hauke Laging
bekommt man irgendwie den Text aus Dialogboxen kopiert? Für OS/2
hatte ich damals so ein geiles Programm (DragText), das Text quasi
überall rausgeholt hat (auch aus Titelleisten), obwohl das gar nicht
vorgesehen war.
Ich tippe nämlich gerade den Inhalt einer Box ab (KDE 3.5.10), und
das kann es ja wohl nicht sein...
CU
Christine Bona
> bekommt man irgendwie den Text aus Dialogboxen kopiert? Für OS/2
> hatte ich damals so ein geiles Programm (DragText), das Text quasi
> überall rausgeholt hat (auch aus Titelleisten), obwohl das gar nicht
> vorgesehen war.
>
> Ich tippe nämlich gerade den Inhalt einer Box ab (KDE 3.5.10), und
> das kann es ja wohl nicht sein...
Zumindest bei vielen Dialogen kannst du einfach mit der Maus den Text
markieren und dann wie üblich via Mittelklick einfügen (ob's immer so
geht, weiß ich nicht).
Beispiel:
You have selected to show a window without its border.
Without the border, you will not be able to enable the border again using
the mouse: use the window operations menu instead, activated using the
Window Operations Menu (Alt+F3) keyboard shortcut.
Gruß, Christine
--
VM
SYSTEM: openSUSE 11.0 (i586)
KERN: 2.6.25.20-0.5-default i686
KDE: 4.3.95 (KDE 4.3.95 (KDE 4.4 RC2)) "release 214"
Hauke Laging
> Zumindest bei vielen Dialogen kannst du einfach mit der Maus den
> Text markieren
Dass das manchmal geht, habe ich auch schon erlebt. Keine Ahnung,
wovon das abhängt. Ich würde es aber gern erzwingen können.
Christine Bona
Hauke Laging schrieb am Sonntag 31 Januar 2010 01:35:
>> Zumindest bei vielen Dialogen kannst du einfach mit der Maus den
>> Text markieren
>
> Dass das manchmal geht, habe ich auch schon erlebt. Keine Ahnung,
> wovon das abhängt.
Ich weiß das auch nicht. Eine Idee könnte sein, dass es von der
Fensterklasse bestimmt wird.
Jedenfalls habe ich festgestellt, dass die Inhalte der Fensterklasse
"kwin_rules_dialog" markierbar/kopierbar sind. Das sind Informations-
Dialogfenster - wie in dem Beispiel, das ich gestern nannte. Die
Fenstereigenschaften sehen dann so aus:
http://bona-online.de/bsp/Fensterklasse3.png
Dagegen klappt es z.B. nicht bei normalen Einrichtungsdialogen (also dem
Dialog, der sich öffnet, wenn man Dolphin/Einstellungen/Dolphin
einrichten wählt).
Die Fensterklasse fällt anders aus:
http://bona-online.de/bsp/Fensterklasse3a.png
> Ich würde es aber gern erzwingen können.
Es gab vor ca. drei Jahren dazu schon mal einen Thread hier, z.B.
Message-ID: <ersqc4-...@markus-raab.org>
Gruß, Christine
--
Kernel 2.6.27.42-0.1-pae | openSUSE 11.1
KDE 4.3.5 (KDE 4.3.5) "release 2"
Rolf Magnus
> Hallo!
>
> Hauke Laging schrieb am Sonntag 31 Januar 2010 01:35:
>
>>> Zumindest bei vielen Dialogen kannst du einfach mit der Maus den
>>> Text markieren
>>
>> Dass das manchmal geht, habe ich auch schon erlebt. Keine Ahnung,
>> wovon das abhängt.
>
> Ich weiß das auch nicht. Eine Idee könnte sein, dass es von der
> Fensterklasse bestimmt wird.
Nein. Es hängt von den darin enthaltenen Widgets ab.
> Jedenfalls habe ich festgestellt, dass die Inhalte der Fensterklasse
> "kwin_rules_dialog" markierbar/kopierbar sind. Das sind Informations-
> Dialogfenster - wie in dem Beispiel, das ich gestern nannte. Die
> Fenstereigenschaften sehen dann so aus:
>
> http://bona-online.de/bsp/Fensterklasse3.png
>
>
> Dagegen klappt es z.B. nicht bei normalen Einrichtungsdialogen (also dem
> Dialog, der sich öffnet, wenn man Dolphin/Einstellungen/Dolphin
> einrichten wählt).
> Die Fensterklasse fällt anders aus:
>
> http://bona-online.de/bsp/Fensterklasse3a.png
Da finde ich nirgends irgendwelche Labels. Nur Checkboxen, und deren Text
ist nicht kopierbar.
>> Ich würde es aber gern erzwingen können.
Dazu wird man wohl Qt patchen müssen.
Christine Bona
Rolf Magnus schrieb am Sonntag 31 Januar 2010 21:58:
>> Ich weiß das auch nicht. Eine Idee könnte sein, dass es von der
>> Fensterklasse bestimmt wird.
>
> Nein. Es hängt von den darin enthaltenen Widgets ab.
Aha. Was sind in diesem Fall "Widgets"?
>> Jedenfalls habe ich festgestellt, dass die Inhalte der Fensterklasse
>> "kwin_rules_dialog" markierbar/kopierbar sind. Das sind Informations-
>> Dialogfenster - wie in dem Beispiel, das ich gestern nannte. Die
>> Fenstereigenschaften sehen dann so aus:
>>
>> http://bona-online.de/bsp/Fensterklasse3.png
Hier sind also solche Widgets drin, richtig?
>> Dagegen klappt es z.B. nicht bei normalen Einrichtungsdialogen (also
>> dem Dialog, der sich öffnet, wenn man Dolphin/Einstellungen/Dolphin
>> einrichten wählt).
>> Die Fensterklasse fällt anders aus:
>>
>> http://bona-online.de/bsp/Fensterklasse3a.png
>
> Da finde ich nirgends irgendwelche Labels. Nur Checkboxen, und deren
> Text ist nicht kopierbar.
Ok. Aber beispielsweise müssen in einen Dialog wie diesen (Dolphin-
Einrichten) doch auch die landessprachlichen Übersetzungen rein.
Der Text muss doch insofern irgendwie austauschbar sein.
Wie geht das dann?
>>> Ich würde es aber gern erzwingen können.
>
> Dazu wird man wohl Qt patchen müssen.
Gruß, Christine
--
Kernel 2.6.27.42-0.1-pae | openSUSE 11.1
KDE 4.3.5 (KDE 4.3.5) "release 3"
Peter Köhlmann
> Hallo!
>
> Rolf Magnus schrieb am Sonntag 31 Januar 2010 21:58:
>
>
>>> Ich weiß das auch nicht. Eine Idee könnte sein, dass es von der
>>> Fensterklasse bestimmt wird.
>>
>> Nein. Es hängt von den darin enthaltenen Widgets ab.
>
> Aha. Was sind in diesem Fall "Widgets"?
>
>>> Jedenfalls habe ich festgestellt, dass die Inhalte der Fensterklasse
>>> "kwin_rules_dialog" markierbar/kopierbar sind. Das sind Informations-
>>> Dialogfenster - wie in dem Beispiel, das ich gestern nannte. Die
>>> Fenstereigenschaften sehen dann so aus:
>>>
>>> http://bona-online.de/bsp/Fensterklasse3.png
>
> Hier sind also solche Widgets drin, richtig?
>
>>> Dagegen klappt es z.B. nicht bei normalen Einrichtungsdialogen (also
>>> dem Dialog, der sich öffnet, wenn man Dolphin/Einstellungen/Dolphin
>>> einrichten wählt).
>>> Die Fensterklasse fällt anders aus:
>>>
>>> http://bona-online.de/bsp/Fensterklasse3a.png
>>
>> Da finde ich nirgends irgendwelche Labels. Nur Checkboxen, und deren
>> Text ist nicht kopierbar.
>
> Ok. Aber beispielsweise müssen in einen Dialog wie diesen (Dolphin-
> Einrichten) doch auch die landessprachlichen Übersetzungen rein.
> Der Text muss doch insofern irgendwie austauschbar sein.
> Wie geht das dann?
Das ist ein Mechanismus, den KDE von QT abgeleitet hat.
Das heisst, es steckt bei KDE-Anwendungen der QT-Mechanismus darunter,
aber erweitert von KDE-Klassen
Eine (vereinfachte) Erklärung ist:
Jedes KDE-Programm lädt beim Start einen "Translator". Das ist eine
spezielle Klasse, die bei Programmen darauf achtet, ob Texte mit dem
Zusatz "tr" oder "trUtf8" definiert wurden (das sind grob gesagt Macros
für diese Translatoren)
Wenn solch ein Text geladen (und angezeigt werden soll), dann kann der
"Translator" diesen Text gegen einen anderen austauschen, der in einem
bestimmten Format in Dateien, die zu diesem Programm mitgeliefert werden,
vorliegen. Dieses Austauschen erfolgt automatisch und ist praktisch nicht
wahrnehmbar (die Geschwindigkeit leidet kaum darunter).
Deswegen werden manchmal auch in Updates nur Sprach-Updates gemacht, ohne
dass das eigentliche Programm ausgetauscht wird. Dies ist davon ja auch
gar nicht betroffen, und es können auch später noch Sprachen nachgeliefert
werden, ohne das eigentliche Programm dazu auch nur anzurühren
>>>> Ich würde es aber gern erzwingen können.
>>
>> Dazu wird man wohl Qt patchen müssen.
>
>
> Gruß, Christine
--
There are two kinds of people in this world: the kind that divides
everybody into two kinds of people, and everybody else
Rolf Magnus
> Hallo!
>
> Rolf Magnus schrieb am Sonntag 31 Januar 2010 21:58:
>
>
>>> Ich weiß das auch nicht. Eine Idee könnte sein, dass es von der
>>> Fensterklasse bestimmt wird.
>>
>> Nein. Es hängt von den darin enthaltenen Widgets ab.
>
> Aha. Was sind in diesem Fall "Widgets"?
Ein Widget (verkürzt von "Window Gadget") ist ein Element einer graphischen
Oberfläche, z.B. eine Checkbox, wo man ein Häkchen machen kann, ein Button,
eine Combobox (die Aufklappteile, wo man zwischen verschiedenen Alternativen
wählen kann), u.s.w.
Heutzutage hat sich in der Öffentlichkeit eine Definition des Begriffs breit
gemacht, die sich davon etwas unterscheidet.
>>> Jedenfalls habe ich festgestellt, dass die Inhalte der Fensterklasse
>>> "kwin_rules_dialog" markierbar/kopierbar sind. Das sind Informations-
>>> Dialogfenster - wie in dem Beispiel, das ich gestern nannte. Die
>>> Fenstereigenschaften sehen dann so aus:
>>>
>>> http://bona-online.de/bsp/Fensterklasse3.png
>
> Hier sind also solche Widgets drin, richtig?
Ja. Die weißen Felder nennen sich bei Qt/KDE "line edit", das Häkchenfeld
inklusive dem Text danach "checkbox". Die Texte über den "line edits" sind
"labels". Ob man Text kopieren kann, hängt davon ab, ob das Widget so
programmiert ist, daß man das kann.
In den Messageboxen von KDE, also den ganz einfachen Dialogen, wo nur ein
Text steht und man dann sowas wie ja/nein/abbrechen wählen kann, ist die
Kopierbarkeit des Textes extra eingebaut worden. Deshalb geht es da.
Theoretisch könnte man Qt so ändern, daß es überall geht, aber dazu wurde
wohl nie die Notwendigkeit gesehen.
> Ok. Aber beispielsweise müssen in einen Dialog wie diesen (Dolphin-
> Einrichten) doch auch die landessprachlichen Übersetzungen rein.
> Der Text muss doch insofern irgendwie austauschbar sein.
> Wie geht das dann?
Das ist prinzipiell auch kein Problem. Das Auswählen mit der Maus ist aber
eine andere Funktion.
Christine Bona
Peter Köhlmann schrieb am Montag 01 Februar 2010 00:23:
>> Ok. Aber beispielsweise müssen in einen Dialog wie diesen (Dolphin-
>> Einrichten) doch auch die landessprachlichen Übersetzungen rein.
>> Der Text muss doch insofern irgendwie austauschbar sein.
>> Wie geht das dann?
>
> Das ist ein Mechanismus, den KDE von QT abgeleitet hat.
> Das heisst, es steckt bei KDE-Anwendungen der QT-Mechanismus darunter,
> aber erweitert von KDE-Klassen
>
> Eine (vereinfachte) Erklärung ist:
> Jedes KDE-Programm lädt beim Start einen "Translator". Das ist eine
> spezielle Klasse, die bei Programmen darauf achtet, ob Texte mit dem
> Zusatz "tr" oder "trUtf8" definiert wurden (das sind grob gesagt
> Macros für diese Translatoren)
> Wenn solch ein Text geladen (und angezeigt werden soll), dann kann der
> "Translator" diesen Text gegen einen anderen austauschen, der in einem
> bestimmten Format in Dateien, die zu diesem Programm mitgeliefert
> werden, vorliegen. Dieses Austauschen erfolgt automatisch und ist
> praktisch nicht wahrnehmbar (die Geschwindigkeit leidet kaum
> darunter).
>
> Deswegen werden manchmal auch in Updates nur Sprach-Updates gemacht,
> ohne dass das eigentliche Programm ausgetauscht wird. Dies ist davon
> ja auch gar nicht betroffen, und es können auch später noch Sprachen
> nachgeliefert werden, ohne das eigentliche Programm dazu auch nur
> anzurühren
Vielen Dank, Peter, für diese Erklärungen zu den Hintergründen.
Mit solchen Translator-Macros arbeiten dann vermutlich die KDE-
Übersetzer, so stelle ich es mir jetzt vor.
Christine Bona
Rolf Magnus schrieb am Montag 01 Februar 2010 06:47:
> Ein Widget (verkürzt von "Window Gadget") ist ein Element einer
> graphischen Oberfläche, z.B. eine Checkbox, wo man ein Häkchen machen
> kann, ein Button, eine Combobox (die Aufklappteile, wo man zwischen
> verschiedenen Alternativen wählen kann), u.s.w.
>
> Heutzutage hat sich in der Öffentlichkeit eine Definition des Begriffs
> breit gemacht, die sich davon etwas unterscheidet.
> Die weißen Felder nennen sich bei Qt/KDE "line edit", das
> Häkchenfeld inklusive dem Text danach "checkbox". Die Texte über den
> "line edits" sind "labels". Ob man Text kopieren kann, hängt davon ab,
> ob das Widget so programmiert ist, daß man das kann.
Aha.
> In den Messageboxen von KDE, also den ganz einfachen Dialogen, wo nur
> ein Text steht und man dann sowas wie ja/nein/abbrechen wählen kann,
> ist die Kopierbarkeit des Textes extra eingebaut worden. Deshalb geht
> es da. Theoretisch könnte man Qt so ändern, daß es überall geht, aber
> dazu wurde wohl nie die Notwendigkeit gesehen.
Für Autoren von Dokumentationen/Bedienungsanleitungen wäre es sicher
ganz nützlich. Aber man kann ja auch Screenshots zu Hilfe nehmen.
[Übersetzungen]
> Das ist prinzipiell auch kein Problem. Das Auswählen mit der Maus ist
> aber eine andere Funktion.
Herzlichen Dank für deine Infos!
Peter Köhlmann
Nein, nicht die Übersetzer direkt. Sondern die Programmierer.
Wenn sie in einem Programm einen String darstellen wollen, dann können sie
schreiben
QString "Dies ist eine Meldung"
Das kann dann in einem Feld dargestellt werden, ist aber *nicht*
übersetzbar.
Sie können stattdessen auch schreiben
QString trUtf8("Dies ist eine Meldung")
Das ergibt erst einmal keinen sichtbaren Unterschied, aber *das* ist
übersetzbar.
Anschließend kann man nämlich ein Programm alle zur Anwendung gehörenden
Sourcen durchsehen lassen, und es wird dann alle diese so gekennzeichneten
Zeichenstrings in eine XML-Datei schreiben, die dann mit einem Programm
von demjenigen, der die Übersetzung macht, bearbeitet werden kann.
Das Ergebnis der Bearbeitung kann man dann zusammen mit der schon fertigen
Anwendung ausliefern, und das fertige Programm kann anhand dieser
Übersetzung dann die vorhandenen Zeichenketten durch die entsprechende
Übersetzung austauschen.
Und das geht beliebig später nach der Auslieferung des fertigen Programms
immer noch.
Das Ganze ist eine sehr mächtige Möglichkeit, und sie ermöglicht es, die
Übersetzung fast völlig vom Schreiben des Programms abzutrennen
--
"Outside of a dog, a book is a man's best friend: and inside a dog,
it's too dark to read." -- Groucho Marx
Christine Bona
Peter Köhlmann schrieb am Montag 01 Februar 2010 17:43:
>> Vielen Dank, Peter, für diese Erklärungen zu den Hintergründen.
>> Mit solchen Translator-Macros arbeiten dann vermutlich die KDE-
>> Übersetzer, so stelle ich es mir jetzt vor.
>
> Nein, nicht die Übersetzer direkt. Sondern die Programmierer.
> Wenn sie in einem Programm einen String darstellen wollen, dann können
> sie schreiben
>
> QString "Dies ist eine Meldung"
>
> Das kann dann in einem Feld dargestellt werden, ist aber *nicht*
> übersetzbar.
>
> Sie können stattdessen auch schreiben
>
> QString trUtf8("Dies ist eine Meldung")
>
> Das ergibt erst einmal keinen sichtbaren Unterschied, aber *das* ist
> übersetzbar.
>
> Anschließend kann man nämlich ein Programm alle zur Anwendung
> gehörenden Sourcen durchsehen lassen, und es wird dann alle diese so
> gekennzeichneten Zeichenstrings in eine XML-Datei schreiben, die dann
> mit einem Programm von demjenigen, der die Übersetzung macht,
> bearbeitet werden kann.
Aha. Der Übersetzer muss also nicht zwangsläufig mit dem zugrunde
liegenden Programm selbst *sehr* genau vertraut sein. Andererseits wäre
das sicher nicht verkehrt angesichts der Übersetungsvarianten und
Details, die ja durchaus den Sinn des Ganzen
beeinflussen/beeinträchtigen können.
> Das Ergebnis der Bearbeitung kann man dann
> zusammen mit der schon fertigen Anwendung ausliefern, und das fertige
> Programm kann anhand dieser Übersetzung dann die vorhandenen
> Zeichenketten durch die entsprechende Übersetzung austauschen.
>
> Und das geht beliebig später nach der Auslieferung des fertigen
> Programms immer noch.
>
> Das Ganze ist eine sehr mächtige Möglichkeit, und sie ermöglicht es,
> die Übersetzung fast völlig vom Schreiben des Programms abzutrennen
Interessant. Es ist schon erstaunlich, was alles zusammenspielen muss,
damit unsere Anwendungen hier funktionieren.
Ich muss sagen, das erhöht meinen Respekt, den ich vor der Arbeit der
KDEler habe.
Peter Köhlmann
> Hallo!
>
> Peter Köhlmann schrieb am Montag 01 Februar 2010 17:43:
>
>>> Vielen Dank, Peter, für diese Erklärungen zu den Hintergründen.
>>> Mit solchen Translator-Macros arbeiten dann vermutlich die KDE-
>>> Übersetzer, so stelle ich es mir jetzt vor.
>>
>> Nein, nicht die Übersetzer direkt. Sondern die Programmierer.
>> Wenn sie in einem Programm einen String darstellen wollen, dann können
>> sie schreiben
>>
>> QString "Dies ist eine Meldung"
>>
>> Das kann dann in einem Feld dargestellt werden, ist aber *nicht*
>> übersetzbar.
>>
>> Sie können stattdessen auch schreiben
>>
>> QString trUtf8("Dies ist eine Meldung")
>>
>> Das ergibt erst einmal keinen sichtbaren Unterschied, aber *das* ist
>> übersetzbar.
>>
>> Anschließend kann man nämlich ein Programm alle zur Anwendung
>> gehörenden Sourcen durchsehen lassen, und es wird dann alle diese so
>> gekennzeichneten Zeichenstrings in eine XML-Datei schreiben, die dann
>> mit einem Programm von demjenigen, der die Übersetzung macht,
>> bearbeitet werden kann.
>
> Aha. Der Übersetzer muss also nicht zwangsläufig mit dem zugrunde
> liegenden Programm selbst *sehr* genau vertraut sein.
Eigentlich fast gar nicht. Er kann das Programm ja schließlich in der
Original-Sprache laufen lassen, die immer vorhanden ist
> Andererseits wäre
> das sicher nicht verkehrt angesichts der Übersetungsvarianten und
> Details, die ja durchaus den Sinn des Ganzen
> beeinflussen/beeinträchtigen können.
Deswegen ist es ja auch gut, wenn er das Programm selber laufen lässt. Auf
diese Art sieht er/sie den Kontext und kann die richtige Übersetzung
wählen
>> Das Ergebnis der Bearbeitung kann man dann
>> zusammen mit der schon fertigen Anwendung ausliefern, und das fertige
>> Programm kann anhand dieser Übersetzung dann die vorhandenen
>> Zeichenketten durch die entsprechende Übersetzung austauschen.
>>
>> Und das geht beliebig später nach der Auslieferung des fertigen
>> Programms immer noch.
>>
>> Das Ganze ist eine sehr mächtige Möglichkeit, und sie ermöglicht es,
>> die Übersetzung fast völlig vom Schreiben des Programms abzutrennen
>
> Interessant. Es ist schon erstaunlich, was alles zusammenspielen muss,
> damit unsere Anwendungen hier funktionieren.
Man muss als Programmierer einen geringfügig höheren Aufwand betreiben,
erhält aber zum Lohn ein Programm, das leicht in beliebige andere Sprachen
übersetzt werden kann. QT (und damit auch KDE) benutzt intern UniCode und
ist deshalb sehr flexibel mit den Zeichen. Es kann praktisch jede
existierende Sprache dargestellt werden
> Ich muss sagen, das erhöht meinen Respekt, den ich vor der Arbeit der
> KDEler habe.
>
Sie haben gute Arbeit gemacht, aber sie benutzen den wirklich sehr guten
Unterbau von QT, der dies erst leicht ermöglicht.
Der Umstieg von QT auf Version 4.x ist übrigens einer der Gründe für KDE4.
QT4 ist *erheblich* schneller als QT3 und bietet jede Menge an neuer
Funktionalität. Aber es ist nicht kompatibel mit QT3 (Programme die auf
QT3 basieren wie KDE3.x können mit QT4 nicht ohne Weiteres kompiliert
werden) und bietet für QT3-Programme Kompatibilitäts-Libraries, die die
nicht mehr vorhandenen QT3-Funktionen nachliefern/emulieren
Wenn also das abgelöste QT3 nicht mehr benutzt werden sollte, sondern das
viel bessere QT4, dann war ein Neu-Schreiben von KDE praktisch
unumgänglich geworden. Viel zu viel Funktionen waren ganz anders gelöst
und konnten nicht einfach "mal eben" umgeschrieben werden
Übrigens bietet Gnome eine ähnliche Funktionalität zum Übersetzen, und das
Ergebnis ist durchaus vergleichbar.
Dieser Ansatz ist übrigens erheblich besser als der in Windows vorhandene,
da dort die Resourcen (normalerweise) in die Datei einkompiliert werden
und deshalb für Sprachänderungen das Programm selber angefasst werden
muss.
--
I hear if you play the Windows7 CD backward you'll hear satanic
messages. But even scarier, if you play it forward it installs
Windows7 !!