「Programming」カテゴリーアーカイブ

PyObjC Exif

よし休日だ。
今日こそ、今度こそは五条川でカワセミを見つけて撮影してやるぞ！
と昼前に遊歩道へ行って十分後。

こんなにあっさり。
わざわざ八田川まで通っていた日々は何だったんだろう。
まあいい、次は狩りの瞬間を撮りたいな。

ところで。

Fedora の場合 Exif 情報を得るには GExiv2 を使えばいい。
macOS の場合はどうすればいいんだろう、ちゃちゃっと検索。

@macosx: NSImage Exif (metadata)

CGImageSource なんてものが SDK にあるみたい。
連想配列を使うのなら PyObjC で書くとスゲェ簡単だぞ。
ImageIO SDK の Objective-c Bridge は以下にあった。

/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/Quartz

ということでエラー処理を省いて PyObjC で書き換えてみた。
メソッドの場合は引数の数だけアンダーバーが必要なのを忘れずに。

#!/usr/bin/env python3

from AppKit import *
from Quartz.ImageIO import *
import sys

def get_exif_dict(filename):
    url = NSURL.fileURLWithPath_(filename)
    source = CGImageSourceCreateWithURL(url, None)
    data = CGImageSourceCopyPropertiesAtIndex(source, 0, None)
    return data #['{Exif}']

d = get_exif_dict(sys.argv[1])
print(d)

以上。

macos_exif

dict の中に更に {ExifAux} 等の dict があって細かく情報が得られる。
CFDictionaryRef も Python の dict 同様に添字でアクセスできる。
こんなに楽チンなのに PyObjC って全然流行らないのは何故だろう。

レンズの名前まで記録しているのね、こういう情報が残っていると助かる。
野鳥撮影は楽しいよ、プログラミングの楽しさになんか似ている。

GtkDialog

GtkDialog のボタンをメッセージが長くても幅いっぱいに広げる方法が解った。
action_area って実は GtkButtonBox だった。

#!/usr/bin/env python3

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
 
dlg = Gtk.Dialog()
dlg.vbox.pack_start(Gtk.Label(label='a'*50, visible=True), False, False, 30)
dlg.add_button('_OK', Gtk.ResponseType.CLOSE)
dlg.add_button('_Cancel', Gtk.ResponseType.CLOSE)

# Expand
area = dlg.get_action_area()
area.props.layout_style = Gtk.ButtonBoxStyle.EXPAND

dlg.run()
dlg.destroy()

expand_buttons

それだけだったのか。。。。。

ついでに解った。
use-header-bar property を 1 にすれば buttons が headerbar になる。

#!/usr/bin/env python3

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
 
dlg = Gtk.Dialog(use_header_bar=1)
dlg.vbox.pack_start(Gtk.Label(label='Titlebar Buttons', visible=True), False, False, 30)
dlg.add_button('SUZUKI', Gtk.ResponseType.CLOSE)
dlg.add_button('MotorCycle', Gtk.ResponseType.CLOSE)
dlg.add_button('Cool', Gtk.ResponseType.CLOSE)

dlg.run()
dlg.destroy()

titlebar_buttons

そうだったのか。。。。。

それとタイトルバーを消す方法なんだが。
非表示の GtkTitleBar をセットすればとりあえず消すことはできると解った。
でも角が丸くならない、色々試したけど上手くいかない。
で思いついた、GtkMessageDialog のボタンを使わず add_button すればよくね？

#!/usr/bin/env python3

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
 
dlg = Gtk.MessageDialog(text='SUZUKI MotorCycle is Bery Cool!', visible=True)
dlg.add_button('_OK', Gtk.ResponseType.CLOSE)
dlg.add_button('_Yes', Gtk.ResponseType.CLOSE)
dlg.add_button('_Agree', Gtk.ResponseType.CLOSE)

dlg.run()
dlg.destroy()

no_titlebar_dialog

何故今迄気が付かなかったんだ。。。。。

てか、統一感を出そうとするなら GtkMessageDialog 継承が一番じゃん。
そんなこんなで我がアプリは結局コレに書き換え。
prev のファイル名表示を追加しようと思ったけどゴチャゴチャするのでヤメ。
Comipoli 0.4.1 公開、本サイト更新のお知らせは久々だな。

ところで、この件でソースコードを見てやろうって思ったんだが。

gtk/gtkmessagedialog.c at master ? GNOME/gtk ? GitHub

gtk_widget_add_css_class という関数を見つけたんだけど。

GtkWidget: GTK 4 Reference Manual

コレって GTK4 からの関数なんですけど。
え、もしかして次の GNOME から GTK4 なんですか？

Intl

Intl といえばもちろんスズキのイントルーダークラシックです。
ジャメリカン 400 の中では一番デカくてカッコイイよね。
ネクラはインテルくらいしかボケが思いつかないだろ、スズ菌でよかったぜ。
というボケは置いておいて。

Intl.ListFormat – JavaScript | MDN

listformat

Intl.ListFormat にはコンストラクタがありません、ってなんじゃそりゃ！

firefox

Firefox で F12 からコンソールならやはり普通に使える。
普段はまったく使っていないのが丸分かりなスクショなことは気にしない。
Gjs は同じ SpiderMonkey だけど同じ Intl を使っているんじゃないんだな。

PluralRules は ja-JP を指定すると全部 other になる、Firefox でも同じ。
Collator は日本語では無意味。
MDN では赤文字な RelativeTimeFormat にはバッチリ対応。
そんなこんなでなんとも中途半端なまとめになってしまった。

JavaScript Intl – Paepoi

これしか更新していないのに盆休みが終わってしまった。
まあいいか、この夏はカワセミに出会えたというだけでおいらは満足だ。
前回は直張りするのを忘れたね、同じのじゃツマランから別アングルのを。

Swift…

筆者は macOS に Command Line Tools を入れているんだし。
せっかくなので Swift もちょっぴりやっておこうかなって。

調べてみると CLang ではなく swiftc コマンドを使うようだ。
ソースの拡張子は swift とそのまんまにする。
gcc や CLang 同様に -o オプションで名前を付けられる。
Foundation の println を使わず print で stdout に出力可能。

// swiftc -o hoge src.swift
print("TEST")

うん、Xcode が無くてもビルドできるね。
さて Foundation を使ってみよう。

import Foundation
println("TEST")
exit(0)

というネットで見つけた最小限コードに書き換えてみたけど。
ビルドできない、いくら探してもオプション無しでビルドできると出るのに。
Objective-c と同じ -framework オプションを指定しても結果は同じ。

swiftc

手段はあると思うけど見つからない、別のビルドを試そう。
公式をよく見るとパッケージの作り方が書いてあった。

Swift.org – Getting Started

swift package init
swift build

xctest

xctest が無いんだって、xc*** ってつまり Xcode のツールだよね。
もしかして Xcode を入れたら上の swiftc コマンドも上手くいくのかも。
Swift って完全に Xcode とセットなのか？？？

もう嫌だ、言語を試す前になんでこんなに苦労しなきゃいけないんだよ！
Xcode を入れたって今度は Xcode の使い方に苦労するだけジャン。
Swift ヤメ、やっぱり Swift はスズキだけでいいよ。

Objective-c は言語もビルド方法も簡単だったのにな。
それより昔書いた C や JXA のコードがサンドボックスに引っかかるのをなんとかしてくれよ、SELinux みたくできないのか？
プログラミングするなら mac、という時代はもう終わっている。

GNU readline

前回 jxa で readline を使ったけどさ。
やっぱり C でも使いたいヤン。

GNU readline | Apribase

タブキー保管ができたり上矢印キーで履歴が辿れたり、まさに端末って感じ。
gets や scanf は非推奨なんだし、端末入力はコレに統一でいいじゃん。

Fedora では libreadline.so は最初から入っている。
でも C のヘッダは無いので以下のコマンドでヘッダを追加する必要がある。

# ncurses ヘッダも依存関係で入るけど気にしない。
sudo dnf install readline-devel

macOS では Command Line Tools の導入で readline.h も入ってくる。
GNU のものではなく互換品だったりするけど。
なので検索すると editline/readline.h と指定、なんて出てくると思う。
現在は以下にシンボリックリンクがあるので readline/readline.h のままでいい。

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/readline/readline.h

ビルドするにはどちらも -l リンカオプションは必要。

#include <stdio.h>
#include <stdlib.h> /* free() */
#include <string.h> /* strcmp() */
#include <readline/readline.h>
#include <readline/history.h>

/*
    Fedora: gcc -lreadline src.c
    macOS:  clang -lreadline src.c
*/

int main(void) {
    char *s;
    printf("usage: exit 又は Ctrl+D で終了\n");
    while (1) {
        s = readline(">> ");
        if (s == NULL) { /* Ctrl+D */
            printf("\n");
            break;
        } else if (strcmp(s, "exit") == 0) {
            free(s);
            break;
        } else if (*s == '\0')
            printf("なんか打ち込めよ！\n");
        else
            printf("%s はカッコイイ！！！\n", s);
        add_history(s);
        free(s);
    }
    return 0;
}

で。

clang_readline

Fedora, macOS 共に上矢印キーで履歴が辿れるし control+D も使える。
macOS の history.h って実は readline.h へのリンクなので不要だけど互換のために。
string.h 等の指定も省略可能だけど警告がウザいので入れたほうがいい。