最近、QScintillaの素晴らしいコンポーネントに関する記事（
1、2 ）がHabréに登場し始めました。
私は
Monkey Studioプロジェクトの開発者の1人であり、昨年1年半は
mksv3です。 QScintillaを5年間使用しています。 定期的にバグ報告とパッチを作成しています。 拒否することにしました。 それに費やされた年月の間、私たちは苦痛に苦しみます。
他の人が同じように起こらないように、私はこの投稿を書いています。
私の経験を共有します。 無料のユニバーサルクロスプラットフォームテキストエディタを開発しています。 私たちにとって重要なことはあなたにとって重要ではないかもしれません。 そしてその逆。 分析します。
そして、私たちの経験。 QScintillaの悪い点...
バイナリレクサー
Scintillaの用語でのレクサーは、解析、強調表示、整列などを行うクラスです。 特定のプログラミング言語。
コードを編集できるほとんどのコンポーネントでは、新しい言語の構文の説明を含むテキストファイルを作成できます。 たとえば、
katepartの場合 。 QScintillaの場合、レクサーはC ++コードのみです。 したがって：
- サポートされている言語とファイルタイプはほとんどありません（emacs、vim、kateと比較して）。 自分のレクサーを書きたい人はあまりいません。
- ほとんどのエディターでは、ユーザーはインターネットからテキストファイルをダウンロードし、エディターを再コンパイルせずに新しい言語のハイライトを取得できます。 （ここで、例えば、 vimのサポートに行きます）。 これはQScintilla専用であり、このようなファイルは見つかりません。
レクサー設定
QScintillaでは、レクサーをカスタマイズできます。 C ++では折り畳む（コード折り畳み）構造としない構造、およびPythonでレクサーが一貫性のないコード配置を強調表示するかどうかを選択できます。 ただし、各レクサーには独自のパラメーターセットがあります。 コードとレクサーの構成の両方が一意に記述される必要があります。
プログラマがYファイルの行がX文字であるかどうかを確認したい場合（たとえば、コメントではなく、コードではスペルをチェックするため）、各レクサーに対して一意のチェックを記述する必要があります。
問題は、レクサーのセットとその設定がリリースごとに変わるという事実によってさらに悪化します。 設定が変更されたという事実は、「QScintillaバージョンxxxでプロジェクトをビルドするつもりはありません」というバグレポートによって定期的に通知されます。 そして、建設はあなたにとって非常に役立つでしょう
#if QSCINTILLA_VERSION >= ...カラースキーム
人は異なり、好みも異なります。 明るい背景に暗いテキスト、暗い背景に明るいテキストが好きな人。 QScintillaでは、各構文要素（数字、行、キーワードなど）のフォントと背景をカスタマイズできます。
ここで、たとえば、Monkey Studioの設定ダイアログ（フルサイズの画像をクリック）：
ただし、特定のレクサーのみを構成できます。 スクリーンショットは、C ++構成ページを示しています。 ユーザーが独自の配色を作成する場合は、使用される各言語を順番に構成する必要があります。
プログラマーがユーザー用の配色を作成する場合、オプションは同じです。数十個の言語のそれぞれを構成する必要があり、新しい言語の出現でテーマを更新することを忘れないでください。
非常に時間がかかります。 ケイトやその他のエディターを使用すると、すべての言語を一度にカスタマイズできます。 これは簡単です。
不十分なレンダリング
QScintillaはQTextEdit + QSyntaxHighlighterを使用しませんが、QAbstractScrollAreaにすべてを独自に描画します。 自転車の場所は曲線になっています。
- 一部のプラットフォームの等幅フォントの幅は、太字であるかどうかによって異なります。
- 一部のプラットフォームのフォントは、滑らかにならず、不細工に見えません。
- 線が長く、画面の幅に収まらない場合、正しく描画されないことがあります。 カーソルが表示されている場所では編集は行われません。 ファイルを編集するには、ファイルを再検出する必要があります。 再び始まるまで......
ネイティブの正規表現構文
QScintillaはテキスト検索をサポートしています。 正常に機能し、正規表現を使用することもできます。 ただし、正規表現の構文は、一般に受け入れられているものとは一部の場所で異なります（たとえば、QRegExpなど）。 そして、ユーザーはこれらの小さな違いを好まないでしょう。 プロトタイプの場合-安定したプロジェクトの場合-いいえ。
QScintillaで検索した後、それを捨てて独自のコードを作成する必要がありました。
オープンリポジトリなし
何らかの理由で、Phil ThomsonはQScintillaリポジトリをパブリックアクセス用に開かず、アーカイブのみをアップロードします。
このため：
- バージョンYと比較してバージョンXの変更点を確認するのは不便です。
- 新しいバージョンのパッチに基づいて、旧バージョンのQScintillaのパッチを作成することは非常に困難です。
たとえば、Debian安定版で使用されているバージョンのパッチを作成する必要がある場合に、ニーズが生じます。 配布ポリシーでは、パッケージを単純にアップグレードすることはできません。
おわりに
QScintillaが気に入らない、または悪いコンポーネントだと誰も考えないことを願っています。 多くの便利な機能を備えており、多数の言語をサポートしています。ほとんどの場合、作成者はパッチやバグレポートに非常に迅速かつ適切に対応します。 コードエディターを必要とするほとんどのQtプロジェクトでは、QScintillaが最適なソリューションです。 さらに、多くの選択肢はありません。 そして、
名前空間がQScintillaに関する有用な記事を書いているのは素晴らしいことです。
ポジティブな側面についてはすでに書かれています。 そして、プロジェクトの初期段階では明らかではないことがわかった欠点について話しました。 これが全体像を構成し、コンポーネントを客観的に評価するのに役立つことを願っています。
欠陥のリストは私たちの経験です。 おそらく、私たちは何かを理解しておらず、間違っているのかもしれません。 コメント。 真実を探しましょう。
QScintillaを使用することに決めた場合、有用な例は
Eric 、
JuffEdおよび私のプロジェクトにあります。これらのリンクは冒頭にあります。
新しいIDEの作成者
それでも、もし最後まで読んでいれば、おそらくあなたは自分でテキストエディタまたはIDEを計画しているか、すでに作成し始めているでしょう。 そしておそらくこの段階で、あなたは手遅れではない。
5年間で、少なくとも数十のプロジェクトが見られました。これらのプロジェクトは、開始から数年で死にました。 著者のヒューズは枯渇しており、機能は最初の数か月の機能をはるかに超えていません。 悲しいです
新しいプロジェクトを始める価値がある場合もあります。 しかし、本当に深刻な理由がある場合のみ。 まず、既存のものを確認し、チームに参加できない理由を明確に述べて、共同作業を続けます。 10の悪いプロジェクトよりも1つの良いプロジェクト。 Qtのいくつかの価値のあるプロジェクトへのリンク。 QScintillaについては
こちら 。
頑張って