So-net無料ブログ作成
検索選択
プログラミング ブログトップ
前の10件 | -

Swift3でアプリケーションバンドルの中の、埋め込みコマンドを探して実行する。 [プログラミング]

Macでコマンドラインアプリケーションをラップして、GUIで使いたいとか思いません? でも、配る時にコマンドラインツールをHomeBrewで入れてね、というのはスマートじゃないですよね。だからHomeBrewで入れたツールのバイナリを奪ってきて、Xcodeで作るGUIな.appの中にぶち込もうという計画。

わかっている人にはそんなに難しいことではないのだろうけど、アプリケーションバンドルって何?から始めようとするとキツい案件になる。でも、コマンドを打ちたくないから安易にできるようになった方がいいんですよねって話だし、そう考えるのはものぐさか、コマンドラインの初心者だと思うんだよね。だから、できるという状態まで持って行ってあげようというのが趣旨です。


それまでライブラリを.appの中にコピーして使ったということはあった。mailpeeper-tlsではOpenSSLの.dylibを使っていたので、そこいらのところはObjective-Cで習得済みだった。基本的にXcodeの操作なのですが、MacPortsなりHomeBrewなりで生成できるバイナリのライブラリをもってきて、実行時にリンクさせるようにするのでした。今回はリンク話の直パスということになります。

今回はSwiftで独立したバイナリのコマンドラインアプリケーションをコピーしてきて、そのバイナリを実行しようというものです。基本的に次のことができればいい。

・バイナリを.app内に取り込む。
・.app内のバイナリの位置を特定して実行する。

この二つだけで大体問題は解決します。やってみたらそんなに難しくなかった。今回は例えばgitを使いたいなと思います。そもそもGitなんて使えんのかいなということなんだけど、実際Xcodeでも使っているので問題ないと思ったのです。

Xcode.appのバンドルの中を検索してみると
/Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
にあることがわかります。別にソースごとXcodeの中に埋め込んでいるわけではなく、独立したコマンドのバイナリが入っているのですね。これには少しホッとしました。

ただリソースの場所としてはずいぶん自由な場所に入れてあるので、探すのが面倒になりそうだなと思っていたら最終的にはそんな気苦労は無用でした。そういうのを前提に関数が用意されているので、結構自由にバンドルの中に放り込むことができそうです。




さて実際にやっていきましょうか。最初にバイナリをバンドルの中に入れ込むのですが、HomeBrewから入れ込むにしろ、他のツールから入れ込むにしろ、whichコマンドで場所を特定してコピーしていきます。自分で作ったツールで./a.outして使ってたら直接でいいですなんて説明はいいですよね。とにかくプロジェクトのフォルダーにコピってきます。

そしてXcodeのProject Navigatorに突っ込んでおきます。どこでもいいです。とりあえず取り込むために登録するだけなので、gitに登録できるような状態にしておけばいいです。今回はgitコマンドなのでgitにgitを登録するような感じになりますがややこしいのは置いといて。こんな感じ。GUIでFinderからドロップするだけでもよかったかな。とにかく登録する。

pngit.png

Productsじゃないだろと言うツッコミはさておきw、実際はProductsにも入ってないノンカテゴリのフォルダなしだったりします。普通はこういう適当なことはやめておきましょうw。でもできることは確かです。


.appの中に入れるのはいくつか方法はあると思いますが、Projectの設定のBuildPhasesのCopy Bundle Resourcesに入れてしまうのが面倒がないと思います。苦労して入れたい方は他にも方法があると思うので探してやってみてください。実際Xcodeでやっているからできると思います。昔はcpコマンドとかを埋めてコピーしていた気がします。今回はとりあえずリソースとして入れこんでみることにします。

copybundle.png

実際にはこういう風にコピーされているのを確認することができる。

innnerbundle.png

まぁ探してくれはするのでどこでもいいのですが…。


さて実際のサンプルソースを見てみましょう。

ほぼ
https://gist.github.com/Seasons7/836d3676884a40c8c98a
なんですが、ちとふるいので少し改変しないと動きません(NSBundleとかがBundleになっていたり)。でもコンパイラが指事してくれるから問題ないです。

今回は前にやったディレクトリを取ってきた部分と絡めて実装する。ボタンとか押すと発動するようにしてみてください(実際そうしてる)。

@IBAction func addGit(_ sender: Any) -> Void {
	//フォルダ指定
	let openPanel = NSOpenPanel()
	openPanel.canChooseDirectories = true	// ディレクトリを選択
	openPanel.canCreateDirectories = false	// ディレクトリを作成できない
	openPanel.canChooseFiles = false		// ファイルを選択できない
	
	var path :String=""
	
	let num = openPanel.runModal()
	if num == NSFileHandlingPanelOKButton{
		for fileURL in openPanel.urls {
			let filePath = fileURL.path
			path = filePath
		}
		//下のコマンド呼んでる。実際にgitを発動しておる
		callGitCommand(path, "init")
		
	}else if num == NSFileHandlingPanelCancelButton{
		NSLog("Canceled")
		return
	}
}

func callGitCommand (_ path :String , _ param :String){
	let task = Process()
	let pipe = Pipe()
	
	task.launchPath = Bundle.main.path(forResource: "git", ofType: nil)
	task.arguments = ["-C", "\(path)", "\(param)" ]
	task.standardOutput = pipe
	task.launch()
	
	let handle = pipe.fileHandleForReading
	let data = handle.readDataToEndOfFile()
	let result_s = String(data: data, encoding: String.Encoding.utf8)
	NSLog(result_s!)
}


冗長なところとコメントはいらないから消したつもりなんだけど残ってるかな。あっても許してね、一応動くし。

http://d.hatena.ne.jp/Watson/20100324/1269427861
のように、NSTask関係では、コマンドラインは相対パスだと動かないから、
/bin/sh -c をかますといいとありますが、結局

Bundle.main.path(forResource: "git", ofType: nil)

でフルパスというか絶対パスが出てきてしまうので気にしないでいいです。パラメータに渡すパスとかも絶対パスを渡せば動作的に問題ないです。

パスのところは空白文字が入るとダメかもしれないので、ダブルクォーテーションとかで括ったほうがいいのかもしれません。そこいらへん試してないけど、一応日本語パスとかもいけたんで大丈夫かもしれません。というか、それくらいテストしろw。そういう面倒が嫌なので、そもそも空白文字のあるディレクトリは作らないようにしているんですけどね。

とにかく、.appの中に入れ込んだコマンドラインアプリケーションでも実行することができたのでした。しかし、実行環境が必要な場合もあると思うので、その場合はそれも持ってきて実行パスとかに置かないといけないのかもしれないなと思ったり。というかgitだってHomeBrewがない環境で動くかどうかって試してないから、HomeBrewのコンパイルリンクの方法が別のライブラリに頼っていた場合は、それも一緒に持ってこないとダメだよなぁ。少なくとも依存パッケージを入れられた場合は、それらは必要となるから結構面倒な話になるかもしれない。

ということを気にするとHomeBrewがない環境が必要になっちゃうじゃないか。面倒くさいなぁもう。

タグ:Swift3
コメント(0) 
共通テーマ:パソコン・インターネット

Swift3でNSOpenPanelをmodalで開く [プログラミング]

時間ねーので適当だが動くでしょう。前回はモードレスなダイアログだったので、いろいろ問題がある人はあるんでしょうから、今度はモーダル。

それにクロージャ(たぶん)の中に、処理をゴリゴリたくさん書いていくのも綺麗じゃないし、外出しするとなんかよくわかんねーエラーが出てたのでやめた。
Call to method 'なんとか' in closure requires explicit 'self.' to make capture semantics explicit
とか
Missing argument label 'file:なんとか' in call cloursure
とかな。めんどうくさいので。

以下前回。

http://miff.blog.so-net.ne.jp/2017-02-08-2

今回はAppleへの文句は垂れない予定。
以下サンプルソース。部分的だが許して。大体必要なものはあると思うし。

	let openPanel = NSOpenPanel()
	openPanel.canChooseDirectories = true	// ディレクトリを選択
	openPanel.canCreateDirectories = false	// ディレクトリを作成できない
	openPanel.canChooseFiles = false		// ファイルを選択できない
	
	let num = openPanel.runModal()
	if num == NSFileHandlingPanelOKButton{
		for fileURL in openPanel.urls {
			let filePath = fileURL.path
		}
		NSLog(filePath)
		
	}else if num == NSFileHandlingPanelCancelButton{
		NSLog("Canceled")
		return
	}

これでファイルパスは取れるでしょう。取れなかったらSo-netのアカウントとって下のコメントで聞いてくんな。わかんねーかもしれないけどな。




そんで欲しいディレクトリをほげほげしたいわけだが、
directoryHogehoge(filePath)

NSLog(filePath)
あたりに置くのだけれど、関数の宣言がちと気持ち悪い。どういう意味があるのかわからないのだけれど

func directoryHogehoge (_ path :String){
}

となぜかアンダーバーを置かないといけないみたいだ。なんだろう。ボタンとかをつなげて作ってくれる自動的にできるソースも
@IBAction internal func hogehoge(_ sender: Any)
みたいに_がついてる。

ここで登場

もっとスマートな音楽の埋め方はないのかw
IMG_4586.JPG
買っちゃいました。アマゾンは本は昔と同じ送料無料だったのね。
にしても地面がきたねーなおい。ブツ撮りは背景が綺麗じゃないと話にならないけどこの際気にしないw


この本のP.109に外部引数名と内部引数名があって、外部引数名を省略するときにアンダーバーを付ける、と。
func hoge(naibu1: Int, gaibu naibu2: Int)
ってこんな感じで。第一引数は外部も内部も兼用、かな。

呼ぶ時には
hoge(naibu1: 5, gaibu:6 )
みたいによく見かける key:value な感じの書き方になるようです。

ややこしいことに、二つ目の外部引数を付ける時は、一つ目の外部引数は省略可能。第一引数の省略を省略しないで書くと

func hoge(_ naibu1: Int, _ naibu2: Int)

と書けて
hoge(1, 2)
とできる。まぁ普通だよね。C言語っぽいよね。どうせなら第一引数も名前使った方が気持ちよかろうにと思うんだけど…。そこいらはObjective-Cに習ったんだろうか。互換性をつけるために。

下記のコードをPlayGroundとかで実行すると、まぁそうだよね、という無駄な「1+2=3」が計算できる。

//よくある第一外部引数省略バージョン
func hoge(naibu1: Int, gaibu naibu2: Int){
	print( "\(naibu1) + \(naibu2) = \(naibu1 + naibu2)" )
}

//両方とも省略して、C言語っぽい呼び方をできるバージョン
func hogehoge(_ naibu1: Int,  _ naibu2: Int){
	print( "\(naibu1) + \(naibu2) = \(naibu1 + naibu2)" )
}

//どうせなら第一引数から全部やった方が気持ちよかろうバージョン
func hogehogehoge(gaibu1 naibu1: Int, gaibu2 naibu2: Int){
	print( "\(naibu1) + \(naibu2) = \(naibu1 + naibu2)" )
}

hoge(naibu1:1, gaibu:2)

hogehoge(1,2)

hogehogehoge(gaibu1:1, gaibu2:2)

何が言いたいかと言うと、初めの引数がなんとなく気持ち悪いってこと。でも、多くの人がそう書くだろうから無駄に混乱しないようにと言う話。たぶんこれはObjective-Cのオブジェクト指向部分の書き方が悪いんだろうと思われ。Obj-C動くようにしか書いてないから、実際は違うかもしれないけど。


ありがとう、本よ! Webがあっても本で得られる滋養って違うものがあるよね。

Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

  • 作者: 石川 洋資
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/02/07
  • メディア: 単行本(ソフトカバー)


この本はかなり硬派です。すぐにSwiftでアプリを書きたいって人には向いてません。

タグ:Swift3
コメント(0) 
共通テーマ:パソコン・インターネット

Swiftのサンプルコードがさっぱり動かない(NSOpenPanel) [プログラミング]

動かないどころか、コンパイルさえ通らない。最終的には動かしたんだが…。

Swift自体とライブラリ変えすぎなんじゃない?
半年前のサンプルソースが動かないとかどうかしてるよ。アップルらしいといえばApple純正ソフトらしいけどw。


Swiftの文法に近づけようとしすぎて、CocoaとかのObjective-Cの関数などの名前からも乖離している。ちょっと頭がおかしいのではないか。

Xcodeも勝手にコンパイルしてくれるので、ガタガタして落ち着かない。すごく気持ち悪い。Obj-Cでもここまでおかしくなかったぞ。そもそもの文法が分かっていないのも問題だけど、その程度は大体はサンプルソースを見ながらだったら普通はいける。コンパイラのエラーで大体わかる。だけど何が悪いか見当がつかない。

Obj-Cではdeprecatedなものでも動いてくれはするが、Swiftではもはやコンパイルすら通してくれない。静的言語としてはこれくらいで当然なのかもしれないけど、Obj-Cよりはサクサク書けるものだと思っていた。ちょっとこれはひどくないか。他の言語を渡り歩いてきたけど、Webのサンプルソースさえ少しの手直しで動かない言語ってなかなかないぞ。

NSOpenPanel.begin(completionHandler:)
がやっと動いた。ほぼスケルトン状態にしてやっと文法的に正しくなった。
もともと、どこかから奪ってきたソースがbeginWithCompletionHandler()だったから、ちょっと変えるだけだったけど、何でこんなにも問題が起こるのかわからないくらい他のところでエラーが出て今はコメントアウトしている。


問題はXcode8でSwift3に変わっているらしいこと。
 https://developer.apple.com/swift/blog/?id=36
具体的な内容は
 http://artteknika.hatenablog.com/entry/2016/11/01/192942

「Swift側の標準ライブラリ(?)に即したような形で、ライブラリの変更が行われている」+「文法の変更、又は廃止」。廃止されると全く通らなくなるので困るね。というか、よく考えられた言語だと、バージョン間の変更も穏やかなんだけど、クソみたいにみんなが集まってきちゃうと、Python2.6, 2.7, 3系統みたいな状態になってしまうってことだろう。賢い人ばかりだといいけど、そうじゃないのが世の常。


とりあえず何もできないけど、ディレクトリ選択ダイアログだけは出るぜな状態。Swiftの文法何もわかってやしない感じw。これからこれから♪ 少なくともObjective-Cの機能は別の書き方で残っているはずだ。
	let openPanel = NSOpenPanel()
	openPanel.canChooseDirectories = true // ディレクトリを選択
	openPanel.canCreateDirectories = false // ディレクトリを作成できない
	openPanel.canChooseFiles = false // ファイルを選択できない
	
	openPanel.begin(completionHandler: { (num) -> Void in
		if num == NSModalResponseOK {
			NSLog("Open")
		} else if num == NSModalResponseCancel {
			NSLog("Canceled")
		}
	})

もしかするとXcode9ぐらいには動かなくなってるかもねw。でも、一応8.2で動くはず。というか動いている。



よし、最後までやってディレクトリを取ってみましょうか。NSLogにパス吐き出すだけですけど。NSURL関係も変わってしまっているらしいな。あぁ面倒くさぁ。

	openPanel.begin(completionHandler: { (num) -> Void in
		if num == NSModalResponseOK {
			for fileURL in openPanel.urls {
				let filePath :String! = fileURL.path
//					let decoadedPath :String! = filePath.stringByRemovingPercentEncoding  // 日本語ファイルの場合
				NSLog(filePath)
			}
		} else if num == NSModalResponseCancel {
			NSLog("Canceled")
		}
	})

元々のソースには日本語パスのデコードがあったのだけれど、最近はUTF-8とかで管理されているだろうから気にする必要がなさそうな気がするんだけどね。ともあれ、システムの日本語表示されるディレクトリは英語の代替文字があったりする。というか、日本語の方が代替文字なんでしょう。「デスクトップ」とか。

あと複数ファイルを選択してないから、for inで回す必要はないのかな。あとファイルパスはletにする必要があるのだろうか。普通に考えるとvarとかだよな。いまいちSwiftの常識がわかってない。


とりあえず、エラーの傾向はわかった。変数が使われない時はワーニングを吐く。これは最近のコンパイラの常識なのかな。昔はモノによって出たり出なかったりしてたけど。あとdeprecatedな関数はコンパイルエラーが出て、代替関数が提示されるので変えるしかなさそう。

Obj-Cとかやたら古いdeprecatedな関数でも使えたりするんだけど、そういう保証しませんという立場から、放棄するから使えませんに変わっていくのかな。まぁ変な挙動がなくなるのはいいかもしれないけど、環境を変えるごとにコンパイルエラーとかを吐かれたんじゃたまったものではない。まだワーニング程度ならまだしも。それもApple側のつまらない細かい変更に対応しろということなんだろうな。どんどんAppleの開発者のエゴが反映されていく。そんなの一般的な開発者の方は望んじゃいないんだよ。Obj-Cのライブラリの運営が今よりまともだったのは、NeXT社のエンジニアが入っていたからじゃないかなと思わせる。

ともあれ、基本的にシステムに近いAPIはdeprecatedにすべきものではないという事はMicrosoftの技術者でさえ少しはわかっている。まだライブラリのバージョンというか名称を変えてしまうぐらいのものだとしたら別に仕方ないと思うけれどそうじゃないもんなぁ。Xcodeを初期から見ているものとしては暗雲立ち込めているとしか見えないんだがw。まぁSwiftのライブラリと言語仕様が固まるまで待つしかないのかもしれない。


よく「もうObj-Cなんて古いからSwiftでしょ」なんて文句を聞くんだけど、この状況を見るとObj-C + ARCを使っている方がずっとマシなような気がする。少なくとも長期間アプリに手を入れていくことを考えるとSwiftは最適な解では決してない。そのところをわかっている人はSwiftを諸手を挙げて賞賛するわけがない。

だけど、Swift自体が悪い言語というわけではなく、単にAppleのライブラリ作成のお行儀が悪いだけ、Xcodeが無遠慮なだけという話だ。だから晴れてOSSになって、AppleごとSwiftが沈没する危険は回避されたという喜ばしい状況にはなってはいるのだから、暗いだけの話ではないのだろう。

タグ:Swift3
コメント(1) 
共通テーマ:パソコン・インターネット

今度はSwiftででもアプリを作ってみるかぁ [プログラミング]

mailpeeper-tlsのリリースも終わり、特に文句もきてないから誰も使ってないか、問題がなかったのでしょう。久々にObjective-Cをいじって、わかりやすいけど面倒臭いなというのが本音だったりする。そもそもretainしたり、releaseしたりするのが面倒なんじゃぁというところが今時ではない。まぁARCに対応した文法にすればいいのだろうけど、下手にいじって挙動を壊すのも何なので。

一応まだMacは使うつもりなので、Swiftぐらい空で書けるようにしておこうかなぁと思ったり。

Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

  • 作者: 石川 洋資
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/02/07
  • メディア: 単行本(ソフトカバー)


巷に出回るiOSに焦点を絞ったアプリ本じゃなさそうで、きっちり文法を学べそうだ。それに技評ってのもポイント高い。そういやWEB+DB PRESSとか買ってないなぁ。暇がなくて読めないし、買う余裕がないので手にもしていない。Amazonで買うぐらいなら定期購読しちゃった方がいいと思うし、そこまで体が欲していないのも事実。

今はググればアプリに必要な情報はつぎはぎにでも手に入れられるし、そもそもプラットフォームのAPIをつぎはぎにして作るのが大体のアプリだったりするので、規範となる文法書はあった方がいい。その瞬間しか役に立たないアプリ作成の本はいらんのだよ。

とりあえず、GitのGUIラッパーを作りたいなと思っている。だってgitコマンド面倒なんだもん。Xcodeみたいにお気楽にやりたいじゃん。でも、Xcode以外でgitを使おうとすると途端にチート表と首っ引きになってしまう。正直、本来のコーディングの知識だけで頭がいっぱい。だから、与えられたメニューだけでお手軽に使えてしまうものを作りたいのだった。もうすでにあるのかもしれないけど、僕が探した時にはMacでは中途半端なものしか存在しなかった。

とはいえ、ちょっと高いなぁという気はしている。売れないのを見越して高値に設定している? それともそもそも分厚さがあるとか。どちらにしても技術書としても安い部類の本ではない。やっぱりマイナーな本はそれなりに高くなっちゃうんだよね。

まだ本を売るまでに時間があるから簡単な雛形をSwiftで作ってみようかな。どうせObj-Cに毛が生えたような書き方しかできないと思うけど。

タグ:Swift3
コメント(0) 
共通テーマ:パソコン・インターネット

なぜAppleはObjective-Cを選んだのか。 [プログラミング]

会社で無理やりObjective-Cやらされてウゼェとか思っている人もいるんでしょうが、まぁSwiftとか出たからいいじゃないですか。言語としてはまだまだひよっこだけど、いろんないいところを受け継いでいるのは間違いないところで、これからOSSになってどう羽ばたくのかは未知数だったりします。

にしてもObjective-CによってAppleは結果的に救われたことになっています。途中でGC入れたり、ARCに変わったり、いろいろ変遷を経てきていますが、Swiftも加わることで使いやすくはなってきています。少なくともOSX当時のObj-Cよりかはマシにはなっているはずです。

ともあれ、何でObjective-Cなんてマイナーだった言語を使い出したのかという話です。それはそもそもOSXの元になったNeXT STEPで開発言語をObjective-Cを使っていたからだといいます。NeXTは使ったことはないのだけれど、初めのXcodeの大盤振る舞いでNeXTで使っていたのかぁと何となく思っていました。

基本的にWebObjectsとかでJavaを使っていた関係で、Obj-CとJavaが混在する形の開発環境になっていたと思う。CocoaなんかもJavaから使えた。何でJavaを捨てたかはいろいろあるんだろうけど、そもそもWebObjectsが普及しなかったということなんだろう。一時期はAppleも企業向けにアピールしていた時期があって、Xserveとかのハードウェア製品もあったのだけれど、ずいぶん前に完全撤退してしまった。サーバハードウェアの技術はMac Proに引き継がれたけれど、今は新しいCPUにもされず放置されている状態。正直、どうでもいいと思っているのでしょう。ゴミ箱同然なわけですw。

それと多分Javaのライセンスがうざかったということもあるのでしょう。Appleは今はLLVMでブイブイ言わせてますが(表現が古いw)、それもgccがウザかったからということなんだろうなと推測されます。要するにGPLがウザかったということなんでしょうね。それでLLVMにお金を投じるようになったみたいです。それと同様にSunのJava縛りが面倒でならなかったのでしょう。だからJavaのサポートを止めてしまった。それは開発の上でも動作環境としてもです。そんなリソース割いてられっかということで。

それと思ったよりか開発者がObj-Cに付いてきてくれたというのもあるんじゃないかなと思う。C++よりかは複雑怪奇になっていないし、メモリの解放さえきちんとやっていれば、C言語の建て増し(ちょっと異質感は否めないが)なのでそんなに難しいこともないわけで。オブジェクト指向としてもプレーンだったし、Xcodeの出来もそんなに悪いものではなかったのも一因だろうと思う。


AndroidではJavaの言語仕様を使ったPureじゃないJavaを使っていて、Sunの後釜のOracleから訴えられているわけですが、それも何とかならないかなぁと思ってしまいます。いつまでもJavaを離さないというのも言語としてどうかと思うのですよ。ビジネス使いとしては、一企業がサポートしてくれる安心感というのもあるのでしょうが、正直OSSが一般的な時代としてはプロプライエタリと言われても仕方ない感じはします。Oracleになってからは特に面倒臭いなぁという感じが増しています。というかオラクルが嫌いなだけだったりしますが。

で、iPhoneがメモリが少なくて済んでいるのも、ネイティブバイナリで動いてガベージコレクションを使わないObj-Cの賜物なのですよね。iOSでもJavaを使っていたら多分Androidと同じスペックじゃないと同程度の性能を発揮できなかったんだろうなと思います。そして、面倒なライセンスの回避もできたわけですし、わざわざ変態みたいにObj-Cを引っ張り出してきた意味があったわけですよね。


AppleはObj-Cを選んだというより、OSXを作るにあたって必要だったし、そのあと他の言語にマイグレーションするような状態でもなかったというだけだったりします。まぁ素のC言語よりかはマシでしょう。少なくてもオブジェクト指向万歳な世代は過ぎ去ったとはいえ、オブジェクト指向自体が当たり前になっているところもあるわけですし、これから先もAppleというメジャーマイノリティの中で使われ続けることになりそうです。今すぐにSwift代替というわけにはいきませんしね、互換性が多少あるとはいえ。


コメント(0) 
共通テーマ:パソコン・インターネット

32bit on 64bitじゃなくてその逆。 [プログラミング]

ふと32bitOSで64bitバイナリを動かせたらいいなぁとか思ってしまった。すぐにそんな高度なこと無理だと思い直したが、無理な事じゃなさそうかもなと思ったりした。

そもそも32bitバイナリと64bitバイナリってどこが違うんだろう。Win32は全部64bitに最適化されて作ってるのか、とか考えると気になる。Win64ってのもあった気がしたんだが、別に64bit以降の時にコンパイルのし直し程度以上のことをした人はいないんじゃないかと思ったり。

そもそもWOW64という仕組みがあるんだから逆もできるんじゃないかと思ったり。でもメモリを切り詰める方と伸長する方は全然違うんだろうな。動くときに64bitアドレスで動くものを32bitに制限するのは無理じゃないにしても面倒な気がする。

https://ja.wikipedia.org/wiki/WOW64

そもそも仮想化で32bitOS上で64bitのOSが動かないから面倒なのだが、おそらくはハードウェアの仮想化っていうのも、仮想ハードウェアデバイスをフィジカルなハードにつなげているだけなんじゃないかと思ったり。そう考えると大してVirtualBoxが大きくないことも理解できる。きちんとKVMとか見てソースから理解すればいいのだけれど、面倒なのでやらない。


まぁそもそもの会社のPCが32bitOSなのが悪いんじゃ。でも、バリバリ開発をしている人のマシンも32bitだって言ってたから、事務な私はなすすべもない。今はWindows10でLinuxのバイナリも動く時代だから何とかなりそうな気もするんだが、そこはシステムプログラミングは面倒なので、やってもデバドラぐらいまでになるのかな。まぁWindowsのデバドラはこの先書くことになるなんてことはないのだろうけど。もしかしたらMacとかはあるかもしれないけどね。あくまで興味的に。

妄想してないでLLVMの仕組みとか調べろよというのは確かな話で。

コメント(0) 
共通テーマ:パソコン・インターネット

mailpeeper-tls ver.1.0.8リリースを一応した。 [プログラミング]

mailpeeper-tlsはとりあえず諸々対応で、最終的にdark modeに対応できました。一応、もうGitHubにはあげてあるのだけれど、どこかに.appファイルは上げておかないとね。そのうちそのうち。問題が残ってるかもしれないし。

デバッグはボタン一発で実行できたけど、リリースするバイナリはどこにあるんだ? 別途作らないといけないんだったっけか。大体デバッグしたバイナリはいろいろ情報が入れられてたりするからなぁ。

場所は
Library/Developer/Xcode/DerivedData/
以下のわかりにくいところにある。
Xcodeでいつ頃かに変わったんだよな。アクセスするのXcodeからFinderに行かないと面倒すぎる。というか、ユーザーのお膝元のディレクトリに作って欲しいんだが、これをこの場所に置く意味とメリットってどこにあるんだろう。

DevelopmentとDeploymentがあったので、デプロイにファイルができるようにする。
メニューの「Product > Scheme > Edit Scheme」からDeploymentに変える。
少し小さめのバイナリができるので、それを提供します。

http://www010.upp.so-net.ne.jp/mihumi/softs/mailpeeper-tls.app.1.0.8.zip


リリースノートとしては、

●諸々不具合対応+機能追加 (in Jan, 2017)ver.1.0.8
El Capitanで使えなくなったという報告を受けてビルドし直す。
ついでにコンパイルのワーニングをとる(大体longからintへの暗黙キャスト)。
pop3sなGmailが取れなくなっていたけどアプリパスワードで回避(結局、何もやってない)。
Notification Centerに対応しようとしてソースに入れ込んではある。
OpenSSLを新しくしたのと、OpenSSL由来の例外がありそうなので止めておいた。
macOSのダークモード対応

という感じなんですが、本当は一番最後だけ頼まれてたんですよね。まぁ仕事しながらやってこの程度でできたから上出来かもしれない。あと動作確認したのはmacOS Sierraなので他は知りませんw。

一応対応しましたぞ。しばらくは放置します。何かとんでもない問題があれば対応するかもしれません。本気でやればGitHubからでも何とかなるなる〜♪

コメント(1) 
共通テーマ:パソコン・インターネット

macOSのダークモードでステータスバーの文字を反転させたい [プログラミング]

mailpeeper-tlsでStatus barにアイコンを表示させて、それがdark modeでも大丈夫なようになりました。

http://mackuba.eu/2015/03/04/how-to-add-icons-to-menu-bar-on-yosemite/

ここはどこから情報を取ってきているのかわからないけど、きっちり解決したのでありがたかった。やっぱり英語ソースはわりと日本のよりか信頼性あるわ。


でも、メニューバーの右側のステータスバーと言われるところにも、文字列は突っ込むことができて、大体以下のようなソースで入れ込んであった。言い方が他人事なのは自分がインプリしたわけじゃないから。抜粋&改変してあるのでそのままどこかに入れ込んでも使えないかもしれない。
  NSStatusBar *statusBar = [NSStatusBar systemStatusBar];
  NSStatusItem *statusItem = [statusBar statusItemWithLength:NSSquareStatusItemLength];
  NSMutableAttributedString *attStr = [[[NSMutableAttributedString alloc] 
			initWithString:@"hoge"]] autorelease];
  [attStr addAttribute:NSForegroundColorAttributeName 
			value:[NSColor blackColor] range:NSMakeRange(0,[attStr length])];
  statusItem.highlightMode = YES;
  [statusItem setAttributedTitle:attStr];

こんな感じで書いてある。改変したところも大丈夫だと思うが、二つのソースをコンバインして作ったのでコンパイルかけてない。多分手直しすれば大体はいいだろうけど。

そんで、これではダークモードで文字列が沈み込む。NSColorは黒だけど、highlightColorとかにしてもダメだったし、hilightModeも入れてはみたものの入れ込む文字列に反応しなかった。黒いまんま。ステータスバーの他の日付とか、バッテリー残量数とか、文字なのに反転するから根本的にはできるはずなのだが…。

気持ちの悪いことに、クリックされて展開されるメニューに関してはきちんとダークモードに対応している。なんじゃこりゃw。とにかく、ステータスバー直の文字列の色を左右する設定がうまくいっていないことは確かだ。ん〜これもアイコンイメージのダークモードを解決する時みたいに面倒だな。どこかに書いていないだろうか。Xcodeのリファレンスって見難いし、サンプルコードがあまり載っていないんだよな。特にAPI周りは。

ステータスバーのオブジェクトを作って、そのアイテムを作って、そこに文字列を叩き込む、という具合なのは、アイコンイメージと同じだろう。さっきも言ったようにNSColor hilightModeはダメ。

あ…
NSColor textColor
で通っちゃったw。きちんと反転するね。

具体的には
[attStr addAttribute:NSForegroundColorAttributeName
value:[NSColor textColor] range:NSMakeRange(0,[attStr length])];
としただけ。

あ〜あっけないなぁw。こういうの一番頭にくるというか気が抜ける。実装がドキュメントに反映されてないタイプ乗って試行錯誤するしかないから、やってる時は不安で終わったら終わったでこんなのに引っかかってたんだと思ってしまう。

まぁなんにしても解決したのでいいや。mailpeeper-tlsぼちぼち新バージョンリリースします。三週間ぐらいかかっちゃったね。とりあえず、gitをcommitして、githubには上げておこう。ん〜きちんとメールアイコンを作ってからのほうがいいかな。しかし、今回は少し勉強になったな〜。というか、もうObjective-C触りたくないんですけどw。

コメント(0) 
共通テーマ:パソコン・インターネット

macOSのダークモードでステータスバー対応が面倒な感じ。 [プログラミング]

mailpeeper-tlsでいつだかに導入されたDockとメニューバーのダークモードにてこずった。ググっても全然情報が出てこないからスクラッチしようと思っていたが決着があっさりついた。

http://qiita.com/itoru257/items/445738ed0bf7fadf1ebf

これを調べる前は
macos menu bar darkとか
macos status bar darkで
調べたんだけど、全然出てこない。xcodeとかで絞っても駄目だった。

メニューバーベースのアプリケーションはそもそも少ないわけで、AppleのDeveloperなページで読んでスクラッチするしかないかと思っていた。

https://developer.apple.com/reference/appkit/nsstatusbar

これあたりかなぁと思ったり。


でも結局、一番初めに貼ったリンクの先の
[[[NSAppearance currentAppearance] name] containsString:NSAppearanceNameVibrantDark]
というところを判断材料にして適宜実装しないといけないってことらしい。

ただ、アイコンの状態変化がいくつかあるので、その度にチェックを入れてアイコンを描き直さないといけないというのは、正直だるいというかソースがあまりきれいでなくなる気がする。アイコンだけじゃなくて文字もフォントの色変えないといけないしね。

というか、AppleがUIの変更に合わせるようにアプリケーションの変更を迫るのってどうなんだ。もっと気にするべきバグとかがあるんじゃないんですかねAppleさん。


ともあれ、dark modeに手動で変更した場合の通知って、どこで受け取るんだっけ。AppControllerあたりなのかな。最初はawakeFromNibあたりで設定すればいいものの、不定期に変えられた場合はどうなるのかとかは調べてない。

status barもそうだけど、macOS独自のシステムプログラミングが慣れてない。というか調べれば終わりなんだけど、Macって使い方ばっかり出てきてどんだけ利用者をバカにしているユーザーがいるんだよってなもんで。Windowsの調べ物って結構数があって速攻でかたがつくんだけどな。


しかし、上の解決法は使えなかった。途中でダークモードに変えた場合に対応してくれないみたいなのだ。だから、途中から
[[[NSAppearance currentAppearance] name] containsString:NSAppearanceNameVibrantDark]
を発動させて変えさせることができない。何にしても面倒だ。そしていちいち変更を加えるのは煩雑過ぎてコードの中に入れ込むのはあまりうれしくない。

http://mackuba.eu/2015/03/04/how-to-add-icons-to-menu-bar-on-yosemite/

これはどうかなと思ってやってみる。どこからの情報か知らないけど面倒がなさそうでよさげだ。動けばなんでもいいんだけどさ。


あ~できた。

NSImage *icon = [NSImage imageNamed:@"icon_menu.png"];
icon.template = YES;
statusItem.image = icon;
statusItem.highlightMode = YES;

を自分のソースに適用したら白黒を勝手にいい感じにしてくれる。変な話白黒逆転していてもたぶん大丈夫。もしかしたら最初にやった方法では根本的な解決にならないんだろうな。Qiitaとか玉石混淆すぎるし、きちんとした情報じゃない場合は自分のブログにでも書けよ。


.xcassetsを導入したから、.icnsファイルともファイル名で管理ともおさらばだ。とはいえ、面倒だから全部それに変更したわけじゃないけど。assetsを使ったのは実はダークモードが解決するかと思って使ったけど、あんまり影響はないようだった。白黒のアイコンにしてあげないと似合わないので、新しくステータスバーのアイコンを変えてあげないとな。そういうのセンスがないんだけどまぁ今はフリーの素材もあることだし。


イメージは解決したから、あとは文字だな。受信件数を数字で示しているのだけれど、今のところダークモードでも普通モードでも大丈夫な設定に変えられていない。いろいろ設定を真似て見たものの、イメージの設定とはちょっと違うよう。灰色にしてどっちも見えるようにするっていう回避方法は避けたい。まぁそのうちそのうち。

コメント(0) 
共通テーマ:パソコン・インターネット

久しぶりのXcodeでの開発。 [プログラミング]

mailpeeper-tlsはコンパイラのワーニングの通りに直しているので、それが妥当かどうかはほとんど考えてない。やたらlongからintの暗黙キャストが行われていて、受け側も渡す側もlongにしておいた。まぁメモリの使用量は増えてもそんなに問題ないだろう。にしても64bitのintってlongと同じってどこかでみた気がするのだが、そもそもintってOSのbitによって違うんだよね? それともLLVMは環境に影響されずintは32bit整数とか決めちゃってるんだろうか。まぁいいや、Xcodeの実装とかかもしれないし。

正直Cocoa使うの久しぶりです。できるならARCとかにしちゃいたいけど、面倒でやってません。いちいちreleaseしないといけないのね。ともあれ、Xcodeメニュー > Edit > Convertに変換する方法があるみたいだけど、信用が置けなくて使ってません。まぁ大丈夫なんだろうけど、メモリリーク気になるしやった方がいいのかな。

人のコードを触っていると綺麗に書く人だなぁと思うコードと、お前精神状態疑うよという酷いコードが結構真っ二つに分かれる。幸いなことに私がいじくっている元のコードはきれいだった。どちらかというと私が汚染している感じw。ん〜自分が書いているコードなら、人に見せる場合はコメントを含め綺麗に書くんだけど、まぁ基本切り貼りで動かなかったら手を入れる感じのお気楽コーディングで通しています。自分で検証コードを書いてから本体に組み込むような慎重派だから、本体に粒度が低いベタベタなコーディングはしません。ただ、元からあるものを直すとかは仕方なくべったりしてしまうことも多いけど。

Xcodeは出た当時は、こんなIDEがタダで提供されるなんてApple太っ腹、と思っていましたが、今となってはEclipseもVisual StudioもIDEはタダな訳で。先鞭をつけたという意味では画期的だったかもしれない。昔はコンパイラとかすごく高かったんだよ。Borland bccがタダで配られた時は嬉しかったけど、結局Win32APIがわからんとどうしようもなかったので、ネットが今ほど整備されていなかった状況では如何ともし難かった。今と違ってネットに情報を見つけるのも一苦労だったし。Googleが検索始めたら何の問題もなくなったけど、その前は頑張ってInfoseekとかで見つけるしかなかった。

正直Xcodeはそれほど好きじゃないです。Visual Studioの方が慣れているというか、探し物がすぐに見つかる感じがしました。今はXcodeでも右クリックメニューからGoogle検索する項目が出てくるけど、できれば付属のヘルプに飛ぶ項目があればいいのだが、そこいらへんはIDEとして断絶している感じ。どこかに内蔵ヘルプに飛ぶメニューあったっけ? まぁネットの方がサンプルコードが具体的にあったりするので、ググった方が早いんじゃということなんでしょうが、そこは自分達の一次情報を見せて欲しいんだよね、見づらくても。


んで、deprecatedな関数を潰しているのだけれど、やっぱり代替する関数が全然違う動作をしていたり、扱う型が全然違かったりで、動作検証を含めて難航気味。自分でスクラッチしたわけじゃないから、元の動作の意味を考えて、GUIとの動作を勘案してやらないといけない。変えた理由はわかるんだけど、元のコードにがっつり関数依存の制御が入ってしまうと直すのがシンドい。

それにしても、どうしてこうもXcodeのプロジェクトに非互換が入りまくるのかな。Windowsでここまで変化があったら批判芬芬だろうな。MSは下位互換というか未来に行っても比較的動く方だと思う。Macとかコンパイルし直さないと動かないとか多すぎる。前にスクリーンセイバーを作っていた時も、OSが変わるごとにコンパイルし直さないといけない時期があった。アホかとか思った。エミュとかで過去の互換性を維持するかのように見せて、すぐそのサポートを打ち切るしね。まぁ企業対応が最悪という評判はそういうところから来ているのかもしれない。

なんというか、今までよくMacについてきた人がたくさんいたもんだよね。レガシー資産をすぐに切り捨てるので、ジョブズの潔さが出ているとも言えるのだが、正直横暴すぎるよね。また同じことしたらどうなることやら。わりと仕様に利益があるUSBのType-Cコネクタでさえ、iMac登場時のUSBほど暖かくは迎えられていないだろう。

僕としては、お手軽お気軽にプログラミングできればいいのだけれど、この先Apple不安だなぁ。MSではもうほとんどプログラミングしていないけれど、そのぶんHTML5とかのWebプラットフォームを気にしているから、どうしてもWindowsを離れることができなかったりする。結局、パソコンでビジネス使いするのWindowsだし。今ではスマホからアクセスすることも多くなったわけだけど、やっぱり作るのはWindowsマシンでってことになるわな。iOSを扱わない限りは仕事でMacを使うことはできないわけで。

そういう意味では使うのに腰が引けてしまっているところがある。iPhoneはすぐにAndroidでも乗り換えできそうだけど、パソコンは開発環境として使ってしまうといろいろ根深い理由ができてしまって移行するのがしんどくなる。今は熱心な人に後を押されてメンテしているけど、正直自分がこのソフトを改造したの半分忘れてたしね。今の開発の活動拠点はWebであるので、仮想化がある今、実はどこでも開発できたりはするんだけども、macOSを使って楽しい時期はとうの昔に過ぎてしまっている。

だけどUbuntuのGUIでいつも使おうなんて思えない。そこのところはWindows, Macを完全に離れることは不可能だ。かなりできることは多くなってきてはいるけれども、メーカーのサポートをきちんと得られるという状態にはなっていない。そこが非常に残念だ。


あ~Notification Centerが上手く使えない。NSNotificationCenterじゃなくNSUserNotificationCenterを使うっぽい。あとデリゲートとかなんかせんとあかんぽい。

コメント(0) 
共通テーマ:パソコン・インターネット
前の10件 | - プログラミング ブログトップ