Debian 9.2.1 Stretch上のKDE 5の事前定義された日時形式をハックして変更したいと思います。
定義済みフォーマットは、キックオフランチャー>コンピューター>システム設定>個人設定>地域設定>フォーマットの定義済みフォーマットのリストから選択できます。
(「フォーマット設定」ダイアログのスクリーンショットについては、SuperUserサイトの https://superuser.com/q/116228 を参照してください。)
形式の効果は、[形式の設定]ダイアログ自体に表示されます。また、KDEデスクトップのDolphinファイルマネージャの詳細ビューの[日付]フィールドにも表示され、Dolphin上のファイルのプロパティにも表示されます。
残念ながら、事前定義されたフォーマットはどれも私に適していません。 en_US
( "米国-アメリカ英語")の日付時刻形式は、私の観点から特にひどいものです。一方、en_SE
( "スウェーデン語-英語")の短い日付時刻形式はISO 8601であり、希望する形式に近いです。それにもかかわらず、en_SE
でさえ私を完全には満足させません。特にその長いフォーマットは私を失望させます。
この形式設定ダイアログでは、カスタム形式を自由に作成することはできません。事前に定義されたフォーマットから選択するだけです。
したがって、私は事前定義されたフォーマットをハッキングして変更したいと思います。方法を教えてください。
ディレクトリ/usr/share/i18n/locales
にはフォーマットファイルが含まれています。ファイル名は、en_US
、en_GB
、fr_FR
などの形式名と同じです。ただし、Debian 9.2.1に付属のKDEは/usr/share/i18n/locales
のフォーマットファイルを考慮しません。これらのフォーマットファイルを変更したり、これらのファイルをすべて削除したりしても、Debian 9.2.1でのKDEの動作には影響しません。このディレクトリにはen_SE
がありませんが、それでもen_SE
が[フォーマット設定]ダイアログに表示されます。
定義済みのフォーマットがKDEでハードコーディングされているのでしょうか。
Debian 9.0 Stretchが2017-06-17にリリースされたことに注意してください。 Debian 9.2.1に付属するKDEコンポーネントのバージョンは次のとおりです。
plasmashell --version
# plasmashell 5.8.6
kf5-config --version
# Qt: 5.7.1
# KDE Frameworks: 5.28.0
# kf5-config: 1.0
TheEzekielProjectは彼の投稿で主張しています( https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/guide-to-setting-custom-date-format-in-recent- versions-of-kde-4175595458-print / )は、ディレクトリ/usr/share/i18n/locales
のフォーマットファイルを変更して、カスタム日付時刻フォーマットを作成できました。彼がテストしたシステムは、KDEプラズマ5.8.2およびKDEフレームワーク5.27.0を搭載したKali Linux 2016.2、KDEプラズマ5.7.5およびKDEフレームワーク5.26.0を搭載したKubuntu 16.10です。彼のシステムは私のものより古い。
私は彼の方法を試しました。フォーマットファイルのLC_TIME
の下で、d_t_fmt
、d_fmt
、t_fmt
およびt_fmt_ampm
を変更し、locale-gen
などを実行しました。しかし、彼の方法はDebian 9.2.1のKDEに影響を与えないことが判明しました。また、彼の投稿へのコメントは、彼の方法がネオン(プラズマ5.10)で失敗することを訴えています。
ちなみに、私の質問はSuperUserサイトのquestions/1162283/use-iso-time-and-date-format-in-kde-5
の複製ではありません。質問1162283はISO日付時刻形式を要求し、Marco Lussettiの回答、つまり、事前定義された形式のリストからen_SE
を選択するだけで満たされています。私の質問は、事前定義されたフォーマットを超えるハックを求めています。
これを(ほぼ)完全に調査するのに半日かかりましたが、私はそれを行う方法を見つけたと思います、そしてあなたはそれが好きではないでしょう...
KDEはQTのQLocale
のみを使用します。 QTのコアライブラリコードの深いqlocale_data_p.h
内でハードコーディングされたデータを使用するもの.
このデータは明らかに、QTソースコードパッケージのutil/local_database/
内のいくつかのPythonスクリプトを使用して、Unicode Consortiumの「 Common Locale Data Repository 」から手動で生成されています。それ自体は、ソースコードの一部でもではないと私は確信しています。まさしく、コンピュータ上のあらゆる種類の構成またはデータファイルを使用します。
common/main/
でXMLファイルを抽出します。app-i18n/unicode-cldr
btwというパッケージもあります。util/local_database/
のスクリプト(cldr2qlocalexml.py
やqlocalexml2cpp.py
など)を選択した言語のXMLファイルとともに使用して、静的なqlocale_data_p.h
を再生成します。そして、qlocale_data_p.h
を含む他のすべてのパッケージを再コンパイルすることを忘れないでください。
ebuild $(equery w dev-qt/qtcore:5) prepare
pushd /var/tmp/portage/dev-qt/qtcore-5*/work/ # assuming default Portage build directory
mv qtbase-opensource-src-5.9.3 a
cp -a a b
NOWは上記の変更をb
ではなくa
で行います。
mkdir -p /etc/portage/patches/dev-qt/$(basename $(dirname $(pwd))) # only for this version
#mkdir -p /etc/portage/patches/dev-qt/qtcore # for all versions
diff -ur a b > /etc/portage/patches/dev-qt/qtcore*/my-locale.patch
rm -rf a b
popd
ebuild $(equery w dev-qt/qtcore:5) clean
# Rebuild all packages that depend on it, just to be sure. May be optional.
emerge -1 dev-qt/qtcore:5 $(equery d dev-qt/qtcore:5 | sed 's/^/=/')
完全に正直に言うと、これらのPythonスクリプトが実際にXMLファイルを渡すだけで実際に機能するかどうかは確認しませんでした。その時点で、わざわざやめたくて火でそれを殺す。:)
誰かが実際に実際にそれをしたいのであれば、報告してください、そして私はこの答えを更新します。 (または、可能であれば自分で行う)
htop
を使用して、明らかなkcmshell5 formats
を含む、最近開始されたプロセスを見つけました。htop
のl
istオープンファイル機能を使用して、「フォーマット」でフィルタリングし、/usr/lib64/qt5/plugins/kcm_formats.so
を見つけました。equery belongs /usr/lib64/qt5/plugins/kcm_formats.so
を利用して、パッケージkde-plasma/plasma-desktop
を特定できました。addLocaleToCombo
がQLocale
を使用し、kcms/formats/kcmformats.cpp
も含めた<QLocale>
をすぐに見つけました。QLocale
はlocate -i QLocale
で/usr/include/qt[5]/QtCore/qlocale.h
に存在することがわかります。言語、スクリプトなどのいくつかの生成された列挙が含まれていました。equery belongs /usr/include/qt[5]/QtCore/qlocale.h
がdev-qt/qtcore/qtcore
を指し示し、後でソースファイルを解凍します…util/
を調べたところ、util/local_database/README
に「local_databaseを使用して、Common Locale Data Repository(ローカライズされた名前のデータベース(日付形式、国名など)))。cldr2qlocalexml.py
のコードはあまり役に立ちませんでした。その結果はqlocalexml2cpp.py
に使用されますが、これはsrc/corelib/tools/qlocale_data_p.h
を生成します。これにはhugehard-codedすべてのロケールデータのテーブル。そして、そのファイルはすでにソースに存在していました。だから…ええ、それは(部分的に?)ハードコードされています。qlocale_data_p.h
を使用するだけだと思います。これはオープンソースの精神ではあまりありません。しかし、上記のように、少なくとも自分でそれを行うことができます。1年後、AFAICTの状況はまったく同じです。私は、このプロセスをOpenSUSE Tumbleweedで実行して、en_USに希望する日付形式を設定しました。手順は次のとおりです。[SOMEPATH](角かっこを含む)を好みに置き換えます。これを投稿してから、CLDRのバージョン番号が35.1から変更されている場合は、CLDRのバージョン番号を更新することをお勧めします。
Sudo zypper si libqt5-qtbase
#Qt Coreのソースrpmをインストールしますcd /usr/src/packages/SPECS
Sudo rpmbuild -bp libqt5-qtbase.spec
cd [SOMEPATH]
curl http://unicode.org/Public/cldr/35.1/core.Zip --output core.Zip
unzip core.Zip
nano common/main/en.xml
#または変更する言語/地域-変更する日付形式またはローカルの他のパラメータを見つけ、心ゆくまで編集します。cd /usr/src/packages/BUILD/qtbase-everywhere-src-5.13.0/util/local_database/
./cldr2qlocalexml.py [SOMEPATH]/common/main > [SOMEPATH]/localesForQt.xml
Sudo ./qlocalexml2cpp.py [SOMEPATH]/localesForQt.xml /usr/src/packages/BUILD/qtbase-everywhere-src-5.13.0/
cd /usr/src/packages/SPECS
Sudo rpmbuild --noprep --noclean -bb libqt5-qtbase.spec
#コンピューターの速度に応じて、映画を見に行きます...Sudo zypper install *Core*
ほら、KDE / Qtの設定は面白くて便利ではありませんか? ;-)