Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URLリンクの改善 #566

Merged
merged 6 commits into from
Nov 17, 2018

Conversation

berryzplus
Copy link
Contributor

#563

サブクラス化と同時に適切なサイズにリサイズする処理を追加

@ds14050
Copy link
Contributor

ds14050 commented Oct 19, 2018

issue の方の解説がたいへん参考になりました。ところで、今度は短すぎやしませんか?

screen_capture

@berryzplus
Copy link
Contributor Author

全体の幅が狭い件についてですが、いまは描画がはみ出さないギリギリを指定してます。

システムからボーダーの幅と高さを持ってきてマージン作ってやれば少しましになるかも知れません。

@m-tmatma
Copy link
Member

#570 を対応してみました。

サブクラス化と同時に適切なサイズにリサイズする処理を追加
@berryzplus
Copy link
Contributor Author

#569 マージしたのでリベースしました。

わがままですが #568 対応のために #578 のマージを待ちたい感じです。
#578 = デバッグ版で点が出る件の対応)

いまのPRには #578 のコミットを含んでいるので、appveyorからは最終形(のつもり)が取得できるはずです。

使わないグリフ配列のためのメモリ確保をやめる
最大幅の指定を0xFFFF→SHRT_MAXに変更
エラー処理を追加(エラーの場合はサイズ変更しない)
描画処理のリテラル2をDPI考慮した値に変更
コントロールのマージン領域を左だけでなく右にもとるように変更
コメントを追記
@berryzplus
Copy link
Contributor Author

#578の対応に疑義が出たので、このPRからは外すことにしました。

再レビューをお願いします。

@ds14050
Copy link
Contributor

ds14050 commented Oct 28, 2018

GetCharacterPlacement は求めるものに比して高機能すぎる気もしますが、動作結果には問題がありません。フォントと DPI に応じて正しい幅が得られているようです。

screen_capture

↓ MS Pゴシックも低解像度向けのビットマップフォントでなければいいものだ。

192dpi

ds14050
ds14050 previously approved these changes Nov 1, 2018
Copy link
Contributor

@ds14050 ds14050 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

待ちましたが他の方の意見が出ないので Approve してしまいます。

コードに関しては流れだけ見ました。フォントの途中変更に対応していない(コントロールのフォントではなくメンバ変数の m_hFont に依存している)のが気になりましたが、それをいうと下線を付けるという従来の処理も同じ問題を抱えているので見なかったことにします。問題が出ればまとめて対応できるでしょう。

@@ -31,8 +31,12 @@ class CUrlWnd
virtual ~CUrlWnd() { ; }
BOOL SetSubclassWindow( HWND hWnd );
HWND GetHwnd() const{ return m_hWnd; }
protected:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

protected を複数存在させているのはなぜですか?

既存のコードは、メンバ関数とメンバー変数で protected を
複数指定しているのだと思いますが、protected の指定を
足す必要はないように思います。

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

C++でのprotectedはただのラベルです。
何個あってもよいですし、なくてもいいです。

個人の傾向としてはメンバの区切りとしていれることもあります。
単に個数の話であれば、気にしなくてよいのでは?と思います。

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

何個あってもよいですし、なくてもいいです。

ないのとあるのは違います。

個人の傾向としてはメンバの区切りとしていれることもあります

どのような区別をするために入れていますか?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

外部に公開するメソッド(public)と内部で使うメソッド(protected)で分けていますね。
38行目のprotectedはstaticなディスパッチャ関数とメッセージハンドラ関数を区別するために入れてます。

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

どういう使い分けをしているのかをコメントに記載したほうがいいです。
書いた人以外には伝わらないので、誰が別の人が変更した場合
バラバラになる可能性大です。

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

メソッド毎に指定したいなら思い付きですが下記のようにするのはどうでしょうか?

#define PUBLIC public:\
  
#define PROTECTED protected:\
  
#define PRIVATE private:\
  

class DamnedWar:
{
PUBLIC    void enemy();
PROTECTED void human_shield();
PRIVATE   void military_company();
};

Copy link
Contributor

@ds14050 ds14050 Nov 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#define 無しなら私は拒絶しませんよ。あえて Java や C# に似せるために手間をかけることもなかろうと実行はしませんでしたが、考えたことはあります。

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

メソッド毎に指定したいなら

これは少し違っています。

普通に構造化した関数を書くと↓のような感じになると思うんです。

public:
公開の入り口メソッド();
protect:
内部的な準備をする部分();
内部的な実処理をする部分();
内部的な後始末をする部分();
private:
内部共通処理1();
内部共通処理2();
内部共通処理3();

このクラスについて書くと、
ウインドウを表す、というクラスの特殊性から変則的な枠組みが出てきます。
staticのプロシージャ関数とprotectedなイベントハンドラ群が追加されます。

(誤爆して違うとこに貼ったので貼り直し)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

うーん、protected のラベルをあえて増殖させる理由が分かりませんが、元の変更前のコードから既にメソッドとメンバー変数で複数 protected のラベルを使ってるんですね。そして @berryzplus さんのこのPRでは protected なメソッドでも何か区分けをしたかったのか(上のコメントに書かれていますが)更に追加をしたと。

しかし CUrlWnd ってそこから派生した class が無いんだし final 付けて、protectedprivate に変えちゃった方が変な憂いが無くなるのではと better C 的に C++ を使っている人からすると思いました。そんでもって m_hFont メンバー変数は GetFont メソッドをわざわざ用意せずに直接アクセスした方が手っ取り早いのでは、とか思いましたが、まぁ色々ひっくるめて細かい事は気にしない方が良いですね。

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

概ね beru さんに同意です。最後の一文も含めて。

public はクラス利用者への公開インタフェイス。protected はクラス継承者への公開インタフェイス。private はクラスのプライベート。public と protected の混在はそれだけで単一責任原則に違反しているので解消すべき、というどこかからの受け売りを信条にしています。

const INT nMaxExtent = SHRT_MAX; // 幅計算できる最大幅を指定

auto vxBuf = std::make_unique<INT[]>( cchText );
auto vDx = vxBuf.get();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vDx の変数名はどういう意味ですか?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vector of DXです。

DXは小学生男子のあこがれ・・・ちがう。

GDI関数のマニュアルで、横方向の論理単位を表す引数名によく使われている呼称です。
おそらく、Device Xの頭文字をとったものと思われます。
中でもDXの配列は、文字列を描画するときに使う、文字幅を保持した配列であることが多いようです。
この辺、本当のところはマイクロソフトのエロい人を小一時間ほど問い詰めてあげてください・・・

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-scrolldc

ぐぐったところ上記の ScrollDC の解説ページに辿り付きました。
引数の dx の解説を見る限り d というのは device を表している可能性が微?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

マニュアルに device unit って書いてありました。

auto vxBuf = std::make_unique<INT[]>( cchText );
auto vDx = vxBuf.get();

auto cchGlyph = ( cchText * 3 / 2 ) + 16; // エラーグリフの増分を加味したグリフ数を指定
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

この計算式のロジックを教えてください。

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

このページの解説部分を参照、です。

このため pwOutGlyphs パラメータに指定するバッファのサイズは、文字バッファの長さの 1.5 倍に、無効な文字シーケンスがあった場合などの特殊なケースのための 16 グリフ程度を加えたサイズにしておくのが適切です。

いかなるケースにも対応可能かどうかは不明ですが、そのまま実装してあります。

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ありがとうございます。
示していただいたリンクは ScriptShape に対する説明ですが、
呼び出している関数は GetCharacterPlacement です。
ScriptShape とGetCharacterPlacement はどう関係してきますか?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ScriptShape とGetCharacterPlacement はどう関係してきますか?

詳細と概要の関係です。

似た関係性としてI/O関数の低水準入出力と高水準入出力があります。
「1行読む」という処理は「1文字読む」の集まりです。

GetCharacterPlacementは、裏でuniscribeというコンポーネントを使うと以前書きました。

ScriptShapeはuniscribeの一部で、文字列からグリフ配列を生成する部分を担当します。

実際に呼出しされているかどうか検証してみたことはありませんけど 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GetCharacterPlacement の使い方を理解するところで止まっていて放置してました。
GetCharacterPlacement の使い方って API リファレンス以外で参考にしたものはありますか?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

特定のサイトではないですね。

ExtTextOutと組み合わせて使うもので、電子活版印刷という考え方があることを知るまでに少し時間がかかった気がします。「豆大福おいしい」と書かれたブログで見た日本語活版印刷に関する考察の記事が印象に残っています。

@m-tmatma
Copy link
Member

m-tmatma commented Nov 2, 2018

指摘ではないですが、
case 文のところに宣言なんて、最近のコンパイラではこんな書き方ができるのか!

case WM_PAINT:
// ウィンドウの描画
PAINTSTRUCT ps;
HFONT hFont;
HFONT hFontOld;
TCHAR szText[512];

@ds14050
Copy link
Contributor

ds14050 commented Nov 2, 2018

case 文のところに宣言

往々にして変数名が衝突するので、スコープを case 文個々の case ラベルに限定するためにカーリーブラケットを付けますね。そのインデントが break の位置と相まってまた紛争の種に……。

@beru
Copy link
Contributor

beru commented Nov 2, 2018

case 文のところに宣言

往々にして変数名が衝突するので、スコープを case 文に限定するためにカーリーブラケットを付けますね。そのインデントが break の位置と相まってまた紛争の種に……。

これは私が長年の研鑽により編み出した秘技ですが惜しまずに公開します。

#define BEGINE {
#define ENDO }

@beru
Copy link
Contributor

beru commented Nov 2, 2018

指摘ではないですが、
case 文のところに宣言なんて、最近のコンパイラではこんな書き方ができるのか!

case WM_PAINT:
// ウィンドウの描画
PAINTSTRUCT ps;
HFONT hFont;
HFONT hFontOld;
TCHAR szText[512];

言語仕様やそのBNFを理解はしていませんがぐぐったところ以下の解説が見つかりました。
https://stackoverflow.com/a/92439/4699324

case 文はラベル相当のようです。なのでスコープとしては switch 文の { } の内側のスコープに充たるのかもしれないですね。なお色々なコンパイラで試してはいません。

bRet → retSetText 標準のSetTextの戻り値
vxBuf → dxBuf DX配列保持バッファ
vDx → pDx DX配列を参照するポインタ
@berryzplus
Copy link
Contributor Author

指摘いただいた点について修正を加えました。

都合: 分かりづらいのでコメントを追加
vxBuf、vDx: より適切な名前に変更

@m-tmatma
Copy link
Member

m-tmatma commented Nov 4, 2018

指摘いただいた点について修正を加えました。

ありがとうございます。

@m-tmatma
Copy link
Member

放置していたので、PR のリビルドをかけた
https://ci.appveyor.com/project/sakuraeditor/sakura/builds/20196291

Copy link
Contributor Author

@berryzplus berryzplus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

放置されてたコメントに気付いたので投稿します。
結構前に書いたコメントなはず...

@@ -31,8 +31,12 @@ class CUrlWnd
virtual ~CUrlWnd() { ; }
BOOL SetSubclassWindow( HWND hWnd );
HWND GetHwnd() const{ return m_hWnd; }
protected:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

外部に公開するメソッド(public)と内部で使うメソッド(protected)で分けていますね。
38行目のprotectedはstaticなディスパッチャ関数とメッセージハンドラ関数を区別するために入れてます。

@berryzplus
Copy link
Contributor Author

このPRは既に障害が消えていると思っています。
再レビューをお願いしたいです。

@ds14050
Copy link
Contributor

ds14050 commented Nov 11, 2018

再レビューをお願いしたいです。

今バトンを握っているのは @m-tmatma さんです。

@berryzplus
Copy link
Contributor Author

ちょっと確認ですが、PRの可否判断にどうしても必要な情報ですか?

「何をしているか分かりません」なら回答する意味があると思います。しかしそうじゃないですよね。明らかに何が別なことを気にした質問を繰り返しているように感じています。単なる質問ならマージ後でも受け付けます。可否判断をなるべく早く下すようにお願いしたいです。

いま必要 or not ということです。

@m-tmatma
Copy link
Member

api の仕様を理解できてないので
理解するための情報がほしいだけです。

だれか他に理解されている方がいて
問題ないという話であれば、マージしてもいいです。

@berryzplus
Copy link
Contributor Author

了解しました。

いずれ必要になるので説明はしますが、いまここにgetcharacterplacementの高機能は必要ないので、利用方法が直感的で利用実績もあるdrawtextを使って書きなおすようにします。

なる早のつもりですがしばらくお待ちください。

@berryzplus
Copy link
Contributor Author

対応してみました。

GetCharacterPlacement → DrawTextです。
マニュアルを見れば分かる通り、これもかなり色々なことができる関数ですが、DT_CALCRECTだけを渡すシナリオでは指定した文字列がちょうど収まる矩形を求める単純関数になります。

りべーすしなくてもmasterの変更を取り込めるのか試してみたくて、マージしてみたんですが想像したのとちょっと違うコミットが作られていて「えええ・・・」です。マージすると消えるのかな・・・。これについては、よく分っとらんです。

@ds14050
Copy link
Contributor

ds14050 commented Nov 12, 2018

りべーすしなくてもmasterの変更を取り込めるのか試してみたくて、マージしてみたんですが想像したのとちょっと違うコミットが作られていて「えええ・・・」です。マージすると消えるのかな・・・。これについては、よく分っとらんです。

master の変更がこの PR の内容の一部であるかのようにとりこまれているが、マージする際には共通コミットとして安全に無視される、という雰囲気を感じました。結果的には問題ないものの論理的には PR に不純物が混じっているような。あくまでも雰囲気ですが。

@ds14050
Copy link
Contributor

ds14050 commented Nov 12, 2018

動作を確認しました。フォントと DPI 共に適応できています。

@m-tmatma
Copy link
Member

いずれ必要になるので説明はしますが、いまここにgetcharacterplacementの高機能は必要ないので、利用方法が直感的で利用実績もあるdrawtextを使って書きなおすようにします。

すごくわかりやすくなりました。
ありがとうございます。

一つ質問を書きました。

Copy link
Contributor

@beru beru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

動作確認しましたが問題無いと思います。
ss0

ss1

ss3 51

@m-tmatma
Copy link
Member

@berryzplus さん、マージどうぞ

@berryzplus
Copy link
Contributor Author

@beru さんのこの画像が気になっているのです。

ss3 51

よく見るとカーソルの下のCUrlWndが2つ同時に色変わってるんです。
この修正の内容には関係ないと思ってるんですが、ちょっと調べたくて逡巡しています、

@beru
Copy link
Contributor

beru commented Nov 17, 2018

よく見るとカーソルの下のCUrlWndが2つ同時に色変わってるんです。
この修正の内容には関係ないと思ってるんですが、ちょっと調べたくて逡巡しています、

そのスクリーンショットは表示のタイミングがシビアで PrintScreen キー押しでは取れませんでした。
ScreenToGif で動画を記録してその中からちょうど良く映っているコマの絵を保存しました。
同期した動作にしないと首をはねられるというわけではないので放置で良いと思います。

@berryzplus
Copy link
Contributor Author

マージします。

@berryzplus berryzplus merged commit 1d1dcbc into sakura-editor:master Nov 17, 2018
@berryzplus berryzplus deleted the feature/resize_on_bind branch November 17, 2018 10:21
@m-tmatma m-tmatma added this to the next release milestone Dec 1, 2018
HoppingTappy pushed a commit to HoppingTappy/sakura that referenced this pull request Jun 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants