これが本当にバグのカテゴリに属する​​かどうかはわかりません。お気に入りのテキスト エディターがワークフローを大幅に中断するような方法で変更された場合、実際にはバグではないからです。でも、他にどこに行けばいいのか分からないので、ここにします。実際は何についてなのでしょうか？

Kwrite バージョン 4:22.12.3-1 を備えた Debian bookworm KDE では、kwrite は Kate と同じようにタブを使用するようになりました。このようなものを単純なテキスト エディタに導入したときに開発者が何を考えていたのかわかりませんが、Linux コミュニティでは小さな抗議がありました。タブが必要な場合は kate を使用できるため、その背後にあるロジックは理解できます。タブのない小さくて非常に便利なエディターが必要なだけの場合は、kwrite を使用してください。いくつかのフォーラムで、この行為がワークフローを混乱させると何人かの人々が苦情を述べています。そして、それは私のワークフローを大幅に混乱させるので、私はこれに同意するしかありません。プログラムや Web サイトを作成するとき、コードの一部をコピーしたり、比較したりすることがよくあります。 2 つのウィンドウを別々に開いている場合は、それらを並べてコードを比較し、必要な部分をコピーできます。タブではウィンドウを隣り合わせに配置できないため、読み取って視覚的に比較することが非常に困難になります。

これで、この問題を開発者側とユーザー側の両方から見ることができます。開発者たちは確かに善意で、お金さえももらわず、自由時間を犠牲にしてこのような便利なプログラムを書いたのに、これほど多くの批判があることにおそらく今ではかなりイライラしていることでしょう。しかし、開発者の皆さん、反対側のことも理解する必要があります。人間は習慣の生き物なので、仕事のやり方を変えたり、普段の行動を大きく変えたりする必要があるたびにイライラします。その場合、仕事のやり方を大幅に変えなければならず、生活がさらに困難になるでしょう。そして残念ながら、この行為を止めることはできません。そこで質問です。ユーザーがどのように働きたいかを選択できるように、追加機能として大幅な変更を実装することは本当に難しいのでしょうか?私の働き方の問題点を見てみましょう。

私は、Web サイトの HTML ドキュメントと C/C++ または Qt プログラムで kwrite を使用して作業しています。小さなスニペットをコピーしたり、プログラムの一部を比較したりするために、一度に複数のファイルを開こうとすることがよくあります。これを行うには、Konqueror をファイル ブラウザとして開き、ファイルをマークして右クリックし、「kwrite で開く」を選択します。選択したすべてのファイルが kwrite で開かれます。以前の Debian bullseye の古い kwrite バージョン (kwrite 4:20.12.2-1) では、各ファイルは独自の小さなウィンドウで開かれました。 Debian bookworm の新しいバージョン (kwrite 4:22.12.3-1) では、すべてがタブで開かれます。また、これらのタブを分離して独立した kwrite ウィンドウにすることはできません。各ファイルを独自の kwrite ウィンドウで開く唯一の方法は、各ファイルを個別にクリックすることです。この場合のみ、それらは別の kwrite インスタンスで開かれます。

残念ながら、タブの数を指定するボタンがあっても、この動作をオフにすることはできません (デフォルトではタブの数は「無制限」です)。タブの数を 1 に設定してアクションを再度実行すると、タブは表示されなくなり、最後に選択したファイルのみが開かれるためです。他のすべてのファイルは開いているように見えますが、見ることはできず、実質的には見えません。 kwrite を閉じずにタブの数を再度増やすと、これに気づくでしょう。すると、選択したすべてのファイルが突然タブに再び表示されます。最初に頭に浮かんだ疑問は、これはバグなのか、それともそうあるべきなのかということでした。論理的には、複数のファイルを開いたときにファイルを表示する他に方法がなく、基本的に非表示になっている場合、タブの数を制限するのはまったくナンセンスであるためです。この動作のため、私の意見では、kwrite を設定して古い動作を復元することは不可能です。すでに書いたように、できることは各ファイルを個別にクリックすることだけですが、ファイル数が多い場合、これはクリック乱交になってしまいます。したがって、親愛なる開発者の皆さん、許してください。kwrite の新しいバージョンは、現時点では私には受け入れられません。

これらの理由から、解決策を見つける必要があり、私が最初に考えたのは、単に dpkg -i を使用して Debian bullseye から古い kwrite を再度インストールすることでした。これはこれまでのところ機能していますが、apt-get を使用してシステムを更新する場合、または新しいパッケージをインストールする場合にのみ、apt-get は次の通知を表示してインストールまたは更新を拒否します。

しかし、プログラムを更新またはインストールするたびに kwrite を現在のバージョンに更新し、古いバージョンを再度上書きするのは面倒です。残念ながら、安定版、テスト版、不安定版 (この場合は旧安定版) などの異なるブランチの混合に関する非常に制限的な Debian ポリシーは、初めてではなく大きな障害となりました。 Debian はユーザーにとって可能な限り最も安定したシステムを望んでいます。もちろん、それを達成できるのは、すべてのパッケージがテスト、チェックされ、チェック ステータスが許す限り最新である場合のみです。しかし、親愛なる Debian 開発者の皆さん、ここでも少し批判しなければなりません。他のブランチからのパッケージがシステムを不安定にしたり、システムを危険にさらす可能性があるという警告を発するだけの方法でもできますが、原理的にはそうなります。許可されており、機能します。その後、システムが不安定かどうかを確認し、以前のパッケージを再インストールできます。

解決策 1 は面倒なので、私は解決策 2 を選択しました。ブルズアイ ソース パッケージを使用して kwrite パッケージを構築します。これは、bookworm が使用するものよりも新しいバージョン番号を受け取るだけです。したがって、古い kwrite を (嫌いなタブなしで) インストールすれば、apt は満足です。追加の作業は、プログラム コードの色付けに使用されるカラー プロファイルの調整だけでした。何かが変わって、プログラム ファイルの一部が異常にピンク色に見えました...

bullseye からの古い kwrite も戻したい場合は、bookworm にインストールするために bullseye ソースからコンパイルされたバージョンを次に示します。 kwrite_22.12.3-2_amd64.deb

bookworm が使用するバージョンは 4:22.12.3-1 で、私が自分でコンパイルしたバージョンは 4:22.12.3-2 です。 bookworm の新しい kwrite バージョンがリリースされ、まだタブをオフにできない場合は、おそらくさらに高いバージョン番号で再翻訳する必要があるでしょう...