HHKB Professional HYBRIDを買って半年ちょっと使っている話。

イメージ
昨年の9月に購入しましたHHKB。 一時期英語配列のキーボードを使っていましたが、今回は日本語配列をチョイス。 PFU キーボード HHKB Professional HYBRID 日本語配列/墨 良かったところ タイピング時の打鍵感、音が心地良い     これがかなりデカい。直近の生成AI周りの発展のおかげで直接タイピングしてコードを書くことは以前に比べるとかなり減ったけど、それでも全然使うのでここのストレスがないことは大きい。 ただ、これも人による部分が大きいと思う部分なので事前に触れる箇所があれば触った方が良い。 HHKBの公式サイトにタッチ&トライスポット というページがあるので実際の打鍵感や音を確認したい人はそこで検索してのをおすすめします。 僕の場合、当初は HHKB Studio を買おうと思って秋葉原の遊舎工房というお店で触らせてもらいましたが、正直打鍵感と音の感じが好みではなかったのでボツ。 横に置いてあったこっちのキーボードを触ってみたらかなりしっくりきた。他にも色んなキーボード(同モデルの静音タイプとか)が置いてあったけど、長いこと使うなら手に馴染むモデルが良いと思ってそのまま購入という流れ。 あと、個人的には気にならなかったけど、色んなところのレビューを見る感じ音に敏感な人と同居してるとか赤ちゃんがいる家庭とかだと少し苦情が出るかも、なくらいの音が出るのでそこは注意すべき。多分そういった人向けに静音モデルがあると思う。 Bluetooth接続できるデバイスの数が多め これもかなりポイント。仕事用のPCにもプライベート使っているPCも両方ともクラムシェルモード(PCを折りたたんだまま外部ディスプレイに接続して使用するモード)で使っているので、仕事を始めるタイミングや終えて切り替えるタイミングで物理ケーブルの切り替えに手間が掛かるのが嫌だった。 HHKBを使用する前に使用していたMagic Keyboardなんかは複数デバイスに対応していなかったため、いけてないなと思いつつ使っていた。 今はコマンドで接続先を切り替えるだけなのでそのストレスは大きく減った。お高いキーボードであれば標準的に乗っている機能なんだろうけど、なんでMagic Keyboardはこの機能がないんだろう・・・ 良くないところ 割と頻繁な頻度で単三電池...

SwiftUIのViewModifierについて

初心者向け

の記事。

SwiftUIではViewでUIの要素を指定し、ViewModifierで要素のレイアウトを整えていく。

その書き方はそれぞれの要素に対して


//
//  ContentView.swift
//  Modifier
//
//  Created by kuehar on 2021/07/01.
//

import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .padding()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

プロジェクトを作ったときはこういう形式でコードが生成されるが、このコードの中の.padding()が実際のViewModifer。

Previewで見てみると最初はこんな感じだが、






例えば.padding(bottom)に変えてみると、


少しだけHello, World!が上に動いている。非常に分かりづらいが。

こういった形で各要素を修飾することによって要素の内容を変えていく。

開発者定義のViewModifier

同時に、開発者側で定義する再利用可能なViewModifierを作成できる。

開発者でどのビューにも適用できる再利用可能なViewModifierを作成したい場合に用いるもので、いくつかのViewModifierを組み合わせて新しいViewModifierを作成することができる、というもの。

例えばApple公式のViewModifierのドキュメントでは以下のようなViewModifierを定義し、使用しています。


//
//  ContentView.swift
//  Modifier
//
//  Created by kuehar on 2021/07/01.
//

import SwiftUI

struct BorderedCaption: ViewModifier {
    func body(content: Content) -> some View {
        content
            .font(.caption2)
            .padding(10)
            .overlay(
                RoundedRectangle(cornerRadius: 15)
                    .stroke(lineWidth: 1)
            )
            .foregroundColor(Color.blue)
    }
}

extension View {
    func borderedCaption() -> some View {
        modifier(BorderedCaption())
    }
}

struct ContentView: View {
    var body: some View {
        Image(systemName: "bus")
            .resizable()
            .frame(width:50, height:50)
        Text("Downtown Bus")
            .borderedCaption()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

Simulatorではこのようになる。


チームで開発する場合はコードの再利用で工程を削減できそうな反面、ある程度のルールを持って運用しないと可読性が低くなりそうで難しそう。

コメント

このブログの人気の投稿

【OSLog】How to log a Swift project

Principles of UX/UI Designでこんなことを学んでいるよ 第一週 User-centerd design①

Swiftで使うQueueのテンプレート