引用:

引用:

Debian 9.2.1 StretchでKDE 5の事前定義された日付と時刻の形式をハッキングして修正したいと思います。

Kickoff Launcher>コンピュータ>システム設定>パーソナライズ>地域設定>フォーマットの事前定義されたフォーマットのリストから事前定義されたフォーマットを選択できます。

(フォーマットダイアログボックスのスクリーンショットについては、以下を参照してください。https://superuser.com/q/1162283スーパーユーザーのウェブサイトから。 )

書式設定の効果は、書式設定ダイアログ自体に表示され、KDEデスクトップのDolphinファイルマネージャの詳細ビューのDateフィールドとDolphinのすべてのファイルプロパティにも表示されます。

残念ながら、事前定義された形式のどれも私には適していません。en_US私の考えでは、(「US - American English」)日付/時刻形式が特に悪いです。一方、en_SE(「Swedish-English」)の短い日付/時刻形式はISO 8601であり、私が望むものに近いです。それにもかかわらず、それは私を完全に満足させることはできませんen_SE。特に長い形式は私を失望させます。

この書式設定ダイアログでは、カスタム書式を自由に作成することはできません。事前定義された形式からのみ選択できます。

だからあらかじめ定義された形式をハッキングして修正したいと思います。どうすればいいか教えてください。

このディレクトリには/usr/share/i18n/localesフォーマットファイルが含まれています。たとえばen_US、ファイル名はフォーマット名と同じです。ただし、Debian 9.2.1に含まれているKDEは、これらのフォーマットファイルを変更したり削除したりしても、Debian 9.2.1のKDEの動作には影響しません。ディレクトリがありませんが、まだフォーマットダイアログボックスに表示されます。en_GBfr_FR/usr/share/i18n/localesen_SEen_SE

事前定義された形式がKDEにハードコードされているかどうか疑問に思います。

Debian 9.0 Stretchは2017年6月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

エゼキエルプロジェクトは彼の投稿で次のように主張した。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 ​​Plasma 5.8.2とKDE Frameworks 5.27.0を含むKali Linux 2016.2、KDE ​​Plasma 5.7.5、およびKDE Frameworks 5.26.0を含むKubuntu 16.10でした。彼のシステムは私より古い。

私は彼の方法を試しました。形式ファイルで、、、および、などをLC_TIME変更して実行しました。しかし、彼の方法は Debian 9.2.1 の KDE には何の影響も与えないことがわかった。彼の投稿へのコメントでは、彼の方法がNeon(プラズマ5.10)で失敗したと文句を言いました。d_t_fmtd_fmtt_fmtt_fmt_ampmlocale-gen

questions/1162283/use-iso-time-and-date-format-in-kde-5しかし、私の質問はスーパーユーザーサイトの質問と重複しません。質問1162283en_SEは、事前定義された形式のリストから選択するだけで、Marco Lussettiの回答ですでにカバーされているISO日付/時刻形式を尋ねます。私の質問は、あらかじめ定義された形式を超えるハッキングを必要とします。

ベストアンサー1

この問題を(ほぼ)完全に調査するのに半日かかりましたが、方法を見つけたようですが、気に入らないでしょう。

解決策:

要するに、

KDEはQTのみを使用しますQLocale。 KDE自体は、qlocale_data_p.hQTコアライブラリコード内でハードコードされたデータを使用します。

このデータは、Unicode Consortiumのデータからのものです。パブリックロケールデータストアutil/local_database/」は、QTソースコードパッケージ内で複数のPythonスクリプトを使用すること自体です。いいえソースコードの一部でも確実です。コンピュータで何らかの構成やデータファイルを使用することは言うまでもありません。

だからこれを行う唯一の方法は...

  1. 以下からCLDRファイル(パッケージ)をダウンロードしてください。http://unicode.org/Public/cldr/latest/core.zip(またはcldr-common-*.zip、どちらも同じ内容を含むようです)またはhttps://www.unicode.org/repos/cldr/trunk/をクリックし、.xmlの下にXMLファイルを抽出しますcommon/main/
    Gentooにはbtwというパッケージもありますapp-i18n/unicode-cldr
  2. たとえば、ディストリビューションリポジトリからQTコアソースコードを取得して解凍します。
  3. util/local_database/cldr2qlocalexml.py静的を再生成します。qlocalexml2cpp.pyqlocale_data_p.h
  4. 次に、パッケージを正常にコンパイルしてインストールします。

そして他のすべてのインクルードを再コンパイルすることを忘れないでくださいqlocale_data_p.h

または、Gentooで次のコマンドを使用して永続パッチを作成します。

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

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/^/=/')

最後の考え

正直なところ、XMLファイルを渡して、これらのPythonスクリプトが実際に動作していることを確認していません。なぜなら、その時点で私は気にするのをやめたかったからです。火で殺す。 :)

パトリックベイトマン斧キラー

実際にこれを実際にやりたい人がいたら報告していただければこの回答を更新します。 (または可能であれば直接作成してください。)


これが私がそこに到達した方法です:

  • タスクバーの時計を右クリックして、KDEの時間書式設定ダイアログボックスを開きました。
  • それからhtop明らかですkcmshell5 formats
  • htopistファイルを開く機能を使用してl「フォーマット」をフィルタリングします/usr/lib64/qt5/plugins/kcm_formats.so
  • Gentooの助けを借りて、equery belongs /usr/lib64/qt5/plugins/kcm_formats.so私はこのパッケージを識別することができましたkde-plasma/plasma-desktop
  • ソースファイルを解凍した後、kcms/formats/kcmformats.cppaddLocaleToCombo使用しQLocale<QLocale>含まれるファイルをすばやく見つけました。
  • QLocalelocate -i QLocaleその後、検索して常駐できます/usr/include/qt[5]/QtCore/qlocale.h。これには、生成された言語、スクリプトなどのいくつかの列挙が含まれます。
  • もう一つは、後でソースファイルを解凍するように指示equery belongs /usr/include/qt[5]/QtCore/qlocale.hします...dev-qt/qtcore/qtcore
  • ...これらすべてが一種のツールによって生成されたような直感がすでにあります。だから、調べてみると、「local_databaseが次に使用されるutil/ことがわかりました。util/local_database/READMEパブリックロケールデータストア(ローカライズされた名前データベース(日付形式、国/地域名など)。」
  • 私はこんな言葉を聞いたことがない。確認しました。、明らかに原因は次のとおりです。Unicodeコンソーシアム。ただし、このコードcldr2qlocalexml.pyはCLDRロケールを含むディレクトリパスを介して呼び出されるため、あまり役に立ちません。その結果は、以下を含むqlocalexml2cpp.pyファイルを生成するために使用されます。src/corelib/tools/qlocale_data_p.h巨大な ハードコーディングすべてのロケールデータのテーブルです。そして、そのファイルはすでにソースに存在します。だから…はい、(一部?)ハードコードされています。
    顔隠し
  • ただし、CLDR XMLファイルが見つかりません。だから私はそれが以前に準備されたものを使用していると仮定していますqlocale_data_p.h。それはオープンソースの精神に合わない。しかし、上記のように、少なくとも自分で行うことはできます。

おすすめ記事