Windows11 マルチディスプレイで、ソフトを動かせない

 Windows11に移行できるパソコンは、全て、Windows10から移行しました。

残っているのは、ハードウェアの要件を満たさないものだけです。

Windows11にして、困ったこと。

ノートパソコンに外付けのモニタを繋ぎ、マルチディスプレイにしています。

外出先では、ノートパソコンのみとなります。

マルチディスプレイで、外付けのモニタ側に、ソフトを表示していると、ノートパソコンのみとなったとき、表示エリアから外れてしまい、ソフトが起動しているのに見えない状態になることがあります。

Windows10の時は、昔は、このような仕様でしたが、最近では、強制的にノートパソコン側のモニタに移動させるようになっていました。

それが、Windows11では、元に戻ってしまったようです。

Windows11では、マルチディスプレイ周りの設定が増えていますので、設定を変更すると良いのかもしれません。

このようなことになったとき、隠れてしまったソフトを、表示エリアに戻す方法は、

・下のタスクバーに表示されるソフトに、カーソルを合わせ、右クリックメニューから、「移動」を選択。カーソルで移動させる。

・下のタスクバーに表示されるソフトに、カーソルを合わせ、ソフトを選択。Shift+Win+カーソルキーの組み合わせで、動かす。

この2つの方法がありますが、これに対応していないソフトもあります。

こうなると、モニタを繋ぐ方法しか思いつきません。

OneDrive 接続に失敗 0x8004de40

 OneDriveでエラーが発生しました。

OneDriveに接続するときに問題が発生しました

インターネット接続を確認し、もう一度やり直してください。

エラーコード　0x8004de40

エラーコードは忘れましたが、こういったエラーは、しばしば発生しています。

経験的に、businessの方が、よく発生しているような気がします。

ノートパソコン（Windows10）と、デスクトップ（Windows11）で、同時発生。

今回は、デスクトップは、放置で解決。

ノートパソコンは、OSの更新で解決。

原因は謎です。

Windows10の更新 OneDriveで困った

 Windows10の更新がありました。

ダイアログで、OneDriveの項目があり、うっかり、設定を選択してしまいました。

私は、ノートパソコン、デスクトップ、仮想マシンと、複数のWindows10や、Windows11を持っています。

それぞれのデスクトップやドキュメントは、その環境に合わせた状態にしているのに、OneDriveをインストールすると、勝手に、共通にしようとしてきて困ります。

今回、Windows10の更新時に、メッセージが表示され、ブラウザの設定、Micorsoft365の購入などの画面が、次々に表示されました。

この中で、うっかり、OneDriveを持っているので、「利用する」という設定を選び、どうやら、OneDriveの設定が、初期化されてしまったようです。

デスクトップには、他の環境のアイコンが並び、OneDriveでは、競合が発生している様子。

だから、「こんな機能、デフォルトにするなよ」と、いつものように、怒りが。

OneDriveの設定変更と、競合の解決という、余計な手間が増えました。

それだけなら良かったのですが、大事なデータが消されてしまいました。

docker mysql用docker-compose.ymlの記述

 私なりのmysql用のdocker-compose.ymlの記述を決めました。

ここに至る経緯は、なかなか大変でした。

ファイル構成

docker-compose.yml

mysql/Dockerfile

mysql/mysql.env

mysql/conf/my.cnf

mysql/init/01_create_tables.sql

mysql.env

MYSQL_ROOT_HOST=%

MYSQL_ROOT_PASSWORD=パスワード

MYSQL_USER=ユーザー名

MYSQL_PASSWORD=パスワード

MYSQL_DATABASE=データベース名

docker-compose.yml

一部、抜粋

services:

  mysql:

    build:

      context: .

      dockerfile: ./mysql/Dockerfile

    container_name: コンテナ名

    env_file: ./mysql/mysql.env

    environment:

      - TZ=Asia/Tokyo

    expose: 

      - "3306"

    restart: always

    volumes:

      - mysqldata:/var/lib/mysql

Dockerfile

FROM mysql:8.0

COPY ./mysql/conf/* /etc/mysql/conf.d/

COPY ./mysql/init/* /docker-entrypoint-initdb.d/

ファイルの扱い

最初、Dockerfileを用意せず、docker-compose.ymlファイルのvolumesに、my.cnfファイルなどを記述していました。

例えば、

./mysql/conf:/etc/mysql/conf.d/:ro

この場合、コンテナ起動時に、my.cnfファイルが読まれず、エラーが発生しました。

ファイルのパーミッションを変更するか、コンテナ内のmysqlユーザーのUIDを、ファイル所有者と一致させるかすれば、エラーを回避できます。

しかし、この方法は、docker-compose buildを実行する前に、ファイルパーミッションの変更作業か、ファイル所有者のUIDを.envファイルに書き込む手間が必要になります。

後者は、工夫すれば、不要かもしれません。

windowsのWSLで開発し、linuxで実行することを考え、このあたりの処理を不要にするため、コンテナ内に、ファイルをコピーする方法で回避しました。

文字コードの設定

mysqlのコンテナでは、文字コードをutf8mb4に変更する必要があります。

mysql 8.0では、デフォルトの文字コードだと思っていましたが、コンテナでは、latain1になるので、設定変更が必要でした。

この変更は、my.cnfファイルを用意するか、docker-compose.ymlのcommand項目で設定できます。

my.cnfファイルの方が見やすくなるため、こちらの方法を採用しました。

他にも、ポートの公開方法、タイムゾーンの設定など、方法が複数ある中で、上記の記述を選びました。

Docker MySQL

 MySQLのDockerコンテナを動かせました。

これまでも、動かしてはいましたが、設定に誤りがあり、正常には動いていませんでした。

my.cnfファイルのファイル名の問題。

このファイル名を、my.confと、間違っていました。

これにより、このファイルの設定は、コンテナに影響を与えない意味のない設定になっていました。

後で、分かったことですが、このファイルの記述に誤りがありました。

この影響で、my.confというファイル名の時には、設定が無視されることで、コンテナを起動できたのに、my.cnfに変えて、設定が有効になることにより、設定のミスから、コンテナを起動できませんでした。

ファイル名を間違えていたことで、動いていたという、なんともな話でした。

my.cnfの設定ミスは、下記の1行でした。

lower_case_table_names=1

過去のデータベースは、Windowsで動かしていて、Linuxへの移行中です。

Windowsのプログラムでは、テーブル名などに、大文字を使っていて、そこから、小文字へ統一しつつある過渡期です。

データベースで、大文字、小文字の区別があると、Windowsでは動くのに、Linuxでは動かないことになりますから、この設定で、大文字、小文字を区別しないのは助かる機能だと思いました。

しかし、これを設定すると、コンテナが起動しません。

この設定は、諦めることにしました。

わずか、これだけのことですが、これに気づくのに、長い時間が掛かりました。

Docker Windowsでは難しい

VMwareの仮想マシンで、開発環境を構築してきましたが、 Dockerでの開発環境に取り組んでいます。

Windowsに、WSLを導入し、dockerを使っていますが、この環境で動く、docker-compose.ymlが、ubuntuに持っていくと動きません。

原因は、主に、ファイルのパーミッションです。

docker内のユーザーと、ホストのユーザーが異なるため、アクセスできるように、設定を気をつけないと、ubuntuでは動きません。

ユーザーは、

・ホスト？側のファイルを所有するユーザー

・dockerを起動するユーザー

・コンテナ内で、サービスを起動するユーザー

この３つが関わるため、面倒でした。

ファイルの所有ユーザーと、コンテナ内のユーザーの違いについては、情報を、よく見かけますが、dockerのコンテナを起動するユーザーは盲点でした。

*.envで、環境変数（コンテナ内のデータベースのユーザー名、パスワード）を管理しますが、このファイルが、コンテナ内に反映されず、悩みました。

面倒なので、関係のあるフォルダは、下記のコマンドで読み込み権限を与えて解決しました。

$ chmod +r -R フォルダ名

セキュリティを考えれば、UIDを一致させるなどした方が良さそうですが、妥協しました。

また、mysqlでは、my.confとmy.cnfの名前の違いも考慮する必要がありました。

おそらく、ubuntu側で、dockerファイルを作成し、windowsに持っていく流れであれば問題ないと思いますが、逆は、はまりました。

HTML checkbox プログラムで値を設定できない

 HTMLのcheckbox

<input type="checkbox" id="foo" checked>

これを、プログラムで、値を設定しようとして、できませんでした。

const elements = document.getElementsById("foo");

elements.checked = false;

このような感じで、true、falseを設定すれば、通常は、チェックのオン、オフができます。

しかし、Promise内で、非同期で行ったところ、表示は変わりませんでした。内部で保持されている値は変更されるので、formで、データを送ると、変更は反映されています。

どうやら、表示だけ変わらないようです。

どの言語？か忘れましたが、画面を構成するパーツについて操作するときは、画面操作のスレッドで行わなければならなかったように思います。

Javascriptのことだっけ？と、調べてみましたが、その情報は見つかりませんでした。

内部データが、表示に反映されていないようでしたので、refresh的な、メソッドがないか調べてみましたが見つかりません。

そもそも、checkedの属性は、初期設定に使うもので、後から、プログラムで変更するのは良くない処理なのかもしれません。

属性、プロパティも調べましたが、結局、あきらめました。

プログラムで変える方法があるとすれば、create系で、DOM構造を構築すれば良いかもしれないと考えています。

今回の解決策は、サーバー側で、check状態を設定します。

OneNote for Windows10 で、ノートが開けない

 OneNote for Windows10　で、ノートが開けないで困っていましたが、解決しました。

現象としては、開くときに、リストの中に、ノート名があり、それを選択しても、

「申し訳ございません お探しのノートを開けませんでした ノートが移動または削除されたか ノートを開く権限がない可能性があります」

と表示され、開けません。

また、リストの中には、同名のノートがあり、つまり、リスト内に２つ以上の同名のノートが表示されます。

リスト内の最終アクセス日？が、今日、修正したノートなのに、古い日時になっています。別の端末で修正したため、異なる人による修正として認識されているのかもしれませんが、釈然としません。

また、同名の２つのノートの日時は異なっています。

Web版のOneNoteで、対象のノートを開き、それを、メニューのアプリで開くを選ぶことで、アプリで開くことができました。

憶測ですが、古くから、OneNoteや、OneDriveを使っているため、サービスの更新のタイミングで、ファイル管理の方法が変わり、古いなごりが残っているのではないかと考えています。

ぷららのメールが遅延する

 ぷららで、２つのメールアドレスを持っています。

２つ目のメールアドレスを企業向けに利用していますが、メールが遅れて届くので困っています。

企業サイトへの登録では、メールアドレスの確認を求められることがありますが、メールが遅延するため、メールアドレスの確認ができません。

企業サイトによっては、時間切れで、認証できないことがありますし、何より、さっさと済ませたいのに、先に進めず、イライラします。

今日は、２０分ほどメールが届くの遅れました。

対策としては、ぷららのメールを使わず、gmailを使っています。

こちらは、すぐに届くので、メール認証は問題ありません。

OneNote 競合が発生する

 OneNoteを愛用しています。

便利なソフトですが、困ったことが、ひとつ。

複数の端末から、OneNoteノートを利用すると、競合が発生します。

競合があると、メッセージが出る場合と、ページに、@日付の名前が付く場合があります。

競合の発生は、ブラウザと、アプリを使う場合に、発生しやすいように思います。

また、モバイルネットワークを利用する、外出先で使用すると、発生しやすいです。

これは、OneNoteのデータをローカルに保存する方法に問題があると思っています。

推測ですが、OneNoteのファイルは、OneDriveのファイルの扱いになり、外出先では、課金ネットワークに接続しているため、クラウドサービスに保存されないのではないかと思っています。

このような、ワンクッションをおく同期の仕組みになっているため、クラウドとの同期に、失敗することが多発するのではないかと思っています。

おそらく、解決方法としては、モバイルネットワークを、課金ネットワークとしなければ、もっと安定すると思います。

しかし、そのような設定にすると、Windowsの更新が、外出先でも発生する恐れがあり、そうなると、モバイルの契約容量を超えてしまいます。

結局、OneNoteへのアクセスは、複数の端末から行うことを禁止するしかありません。

これでは、魅力半減ですが、後々、競合の解決を行う手間を考えると、仕方ありません。

Jetson Nanoに、chromeはインストールできない

 Jetson Nanoに、Chromeをインストールしようとしました。

ＨＰから、debファイルをダウンロードしましたが、インストールできません。

悩みましたが、ＣＰＵが違うことに思い当たりました。

Chromeにこだわる必要はないので、素直に、chromiumを使うことにしました。

GUIでインストールできなかったとき、次に、dpkgを使って、コマンドラインでのインストールを試みれば、すぐに、原因が分かったのに、遠回りしました。

次に、VSCodeのインストール。

こちらは、上記の失敗を経ているので、arm64版を選び、インストールできました。

docker Node.jsの実行環境完成

 dockerを使ったNode.jsの実行環境を作りました。

実際には、データベースも含みますが、それは省略して、このようなフォルダ構成にしました。

フォルダ構成は、実行環境、開発環境により、様々な方法がありますが、VSCodeでの開発を前提にして、このようにしてみました。

MyApp

├─ .devcontainer

│   ├─ devcontainer.json

│   ├─ docker-compose.yml

│   └─ Dockerfile

├─ src

│   └─ 

├─ docker-compose.yml

├─ Dockerfile

├─ app.env

└─ .dockerignone

開発環境のdocker（.devcontainerフォルダ内）は、まだ、未完成ですから、ファイル構成のみ、書き残します。

プログラムのソースは、srcフォルダに置くことにしました。

docker-compose.yml

version: '3.8'

services:

  app:

    build:

      context: .

      args: 

        - NODE_ENV=production

    container_name: tp_app_container

    env_file: ./app.env

    environment:

      - TZ=Asia/Tokyo

    ports:

      - '80:3000'

    restart: always

    working_dir: /app

    command: npm start

Dockerfile

FROM node:14-slim

ARG NODE_ENV=production

ENV NODE_ENV $NODE_ENV

ARG PORT=3000

ENV PORT $PORT

EXPOSE $PORT

WORKDIR /app

RUN chown node:node /app

USER node

COPY --chown=node:node ./src/package*.json ./

RUN npm install

COPY --chown=node:node ./src .

.dockerignone

.git

*Dockerfile*

*docker-compose*

node_modules

狙いとしては、

・Node.jsのエラー時の再起動の管理は、dockerに任せる

・実行は、nodeユーザー

・ソースは、コンテナ内にコピーして実行する

この構成にたどり着くまでに苦労したのは、フォルダ、ファイルの権限です。

rootで実行するなら悩むことはありませんが、nodeユーザーで実行するために試行錯誤しました。

RUN chown node:node /app

がポイントです。

COPY --chown=node:node ./src/package*.json ./

の--chown=node:nodeは、この場合、不要だと思いますが、今後、Dockerfileを修正したときに忘れないように、残しておきました。

docker ファイル権限に悩む

 dockerのファイル権限に悩みました。

node.jsの実行環境を作っています。

参考にするべきは、node.jsの公式ＨＰです。

こちらに、方法が書かれているので、これが正解です。

横着しようと、google検索で調べたために、遠回りしました。

rootユーザーで実行するなら、これで終わりです。

nodeユーザーで実行しようとしたのが、今回の迷走の原因でした。

nodeユーザーで実行しようとすると、volumeのファイルの権限を意識する必要がありました。

例えば、このようなエラーが発生しました。

npm WARN checkPermissions Missing write access to

公式のＨＰのように、ソースをコンテナ内の/usr/src/appに置くなら、Dockerfileに、

RUN chmod node:node /usr/src/app

を追加することで解決しました。

これを行わないと、npm install時に、アクセス権限のないフォルダ内で、フォルダの作成を行おうとすることになり、エラーとなります。

こう書くと、単純な話ですが、これに、volumeのバインドが絡んでいたため、非常に苦労しました。

結局、volumeをバインドする必要はないと気づき、コンテナ内にファイルをコピーすること（公式ＨＰのまま）で解決しました。

プログラムの開発時は、volumeのバインドが必要になるため、もっと、ややこしいことになります。

gitの管理をコンテナの中で行うのか、外で行うのか。

gitの管理をコンテナ内で行うなら、完全に、外と分離するのか。

それとも、ローカルとのファイル共有を行うなら、競合を発生させないために、どうするべきか。

開発マシンが、linuxでもwindowsでも動くようにするには、どうするのか。

コンテナ内では、rootで実行するのか、あるいは、nodeかvscodeか。

これらを考えて、試行錯誤すると、ソースのファイル権限の関係で、エラーが発生します。

発生するのは、npm installの行ですが、他にも、WORKDIRで指定したフォルダがないというエラーが発生したりします。

buildの1回目にエラーが出て、2回目はエラーが出ないという現象にも遭遇し、頭の中は、大混乱です。

とりあえず、実行環境が完成したので、一歩前進です。

w2ui 不具合に悩む

 w2uiライブラリを使っています。

しばらく前から、奇妙な不具合に遭遇し困っていました。

データが、13行以上なら表示されるが、13行未満の場合、表示されません。

どうやら、1ページに表示できる範囲のデータの場合、表示されないようでした。

ライブラリのバージョンを、1.4から、1.5に上げることで解決しました。

WSL docker ubuntuを入れる意味

 Windows10に、WSLを入れて、dockerを使っています。

この環境で、疑問に思っていたのは、なぜ、別途、ubuntuを入れる例が多いのかでした。

WSL2を入れれば、dockerは動きます。

WSLのubuntuを、別途、導入しなくても、問題はありません。

VSCodeを使い、新たに、コンテナを起動し、その中で開発を進めれば良いだけです。

ubuntuを導入する例が多いのは、昔の名残なのかなと思っていました。

ubuntuを導入する意味が理解できたのは、Windows10で作成したdockerを、linux上で実行したときでした。

動きません。

ファイルの権限の問題で、コンテナの実行に失敗しました。

Windowsのファイル権限の仕組みと、linuxでのファイル権限の仕組みが異なるために、ソースをWindows側に置き、コンテナ内から利用する設定にしていると、windowsでは動くのに、linuxでは動かないということになります。

過去の日記

https://cikou.blogspot.com/2021/04/dockervolume.html

ここで、ubuntuを導入する意味が分かりました。

ubuntu側に、dockerのソースを置いておけば、dockerの開発時も、dockerの本番時も、同様に扱えるのだと理解できました。

このためには、dockerの設定で、「WSL INTEGRATION」から、ubuntuを有効にする必要がありました。

これで、Dockerfileは、ubuntuシステム内に置いて、ubuntu内のVSCodeを起動。

そのVSCodeを、Windowsからリモートで操作。

つまり、WindowsのVSCodeから、ubuntun内のVSCodeを操作する。

ここで、開発に使うコンテナを起動し、その中で、VSCodeを使うことができました。

Windows、ubuntu、コンテナ内と、３箇所に、VSCodeを入れる流れになりますが、後者の２つは、ほぼ、自動的に入りますから、面倒ではありません。

これで、ようやく、WSLとdockerの関係性が理解できました。

docker 少し、理解が進んだ

 dockerの理解が、少しだけ、進みました。

VSCodeのdocker向けの拡張を利用すると、開発環境の構築が簡単になります。

しかし、これが、悩みの元で、試行錯誤しました。

今、思えば、単純な話でした。

思い違いしたのは、市販の本は、開発環境の構築に、dockerを使っている例が多かったので、それを見習ったことでした。

これ自体は間違いではありません。

開発環境を構築した後、本番向けの環境を構築しようという順番に、意識が向いてしまったのが問題でした。

本番向けの環境を構築し、それを開発環境にアレンジする流れが正解でした。

VSCodeでは、本番向けのDockerfileを含んだフォルダを、reopen in containerを選ぶことで、開発環境向けのDockerfileを作ってくれました。（厳密にいうと違いますが）

この流れで良かったのです。

開発環境の構築関係の情報は、この最後に作られたDockerfileを含んだ環境を説明しているので、先に、これを作るのだと勘違いして、頭が混乱していました。

もちろん、場合によっては、開発環境を先に作っておいて、プログラムをテストしてみるという場合もありますから、逆の流れもあります。

このあたりの位置づけが理解できて、すっきりしました。

dockerに悩む volumeの権限の問題

 docker、難しいです。

希望する動作があるとして、それを実現する手段は、複数あります。

現時点で、どの手段が最適なのかを考えると、なかなか選べません。

仮想マシンであれば、仮想イメージを、windowsでもlinuxでもコピーすれば動きます。

しかし、dockerは、そうはいきません。

異なるホストOSでも動くように、dockerの環境を構築していれば問題ないのかもしれませんが、その方法は勉強しないとわかりません。まだ、その域に至っていません。

現在、はまっているのが、volumeの権限です。

ホストのファイルを、コンテナからでも利用できるようにすると、これが、ファイル権限の問題でエラーになります。

windowsなら、問題になりません。

linuxに持っていくと、エラーになります。

コンテナ内のユーザーと、ホストのユーザーが異なることが原因です。

chmod 777にするのは、今後の管理を考えるとやりたくありません。

コンテナに特権を与えるのは、なんだか怖い。

両者で共通のユーザーを作るのも、今後の管理を考えるとやりたくありません。

コンテナ内のユーザーのuid、gidを変えるのが良さそうですが、ホストのuid、gidを取得して、コンテナに与える部分を、簡単にできないか、検討中です。

VMware Player 「cannot copy files from virtual machine」

 VMware Player 15.5を使っていますが、ゲストOSの起動時に、「cannot copy files from virtual machine.」と、ダイアログ表示が出て、違和感があります。

起動時ですから、コピー操作をしていないのに、コピー操作をして失敗したというメッセージが出るのが謎です。

環境は、ホストOSが、mintの19.3あたりのバージョンに、

VMware Player 15.5.6あたりです。

ゲストOSは、Windows2000。

調べてみても、このような情報がなく、気持ち悪い感じです。

ゲストOSが古すぎて、情報が出てこないのだと思います。

懸念しているのは、古いOSだけに、ウィルスに感染していないかです。

コピーに失敗しているようですから、実害はなさそうではありますが、不安です。

dockerでの開発に悩む

 現在の開発環境は、VMware上に、仮想OS（主に、ubuntu）を導入し、そこで開発しています。

この利点は、仮想マシンのイメージをコピーすれば、他のパソコンでも、すぐに、開発を続けられることです。

この方法の不満は、

1　実行環境と、開発環境で異なる部分が出る

2　仮想マシンのイメージの容量が大きい。

3　仮想OSの大幅な更新があると、開発環境を構築し直す手間がある。

dockerの導入で解決するかもしれないのが、これらの不満点です。

特に、不満の1が解決するなら移行したいと考えています。

dockerについて調べてみましたが、dockerの使い方は、それぞれで、私の考えるような使い方と同じ活用方法を紹介してくれている情報（書籍など）が見つからず、悩んでいます。

大雑把には、dockerを導入すれば、これらの不満点は解決します。

しかし、細かな部分で、気になる点があり、そこを検討中です。

例えば、PHPでの開発では、xdebugをシステムに組み込みますが、本番環境では使いませんから、できれば、組み込みたくありません。

そうなると、厳密には、開発環境と実行環境で、微妙に差異が生じます。

dockerfileで、この違いを記述でき、build時のオプションで、開発用、実行用を変えられるなら、期待通りのことができそうです。

開発ツールには、NetBeansを使っていますが、VSCodeを使えば、dockerコンテナの管理もできて便利そうです。

node.js用、Python用のVSCodeの環境を保存し、案件毎に、切り替えることができれば、便利そうです。

開発環境と実行環境を同じにしつつ、また、異なる案件の開発環境を共通化するという、2つの課題をどう解決するか、悩んでいます。

ThinkPad E590 メモリ、SSDの増設

 ThinkPad E590。

Eシリーズは、サブのつもりで購入しましたが、次回、ThinkPadの買い替えのときは、メインで使おうと思っています。

メインは、長らく、Tシリーズを使っていて、現在、ThinkPad T480sです。

これより、Eシリーズが良い点は、

・画面が大きい。老眼にはありがたい。

・2.5インチのSSDが利用でき、SSDが、２個積める。

　ソフトRaid1で、ミラーリングができます。

気に入ったのですが、購入した物は、CPUのパワーが弱いので、今は、メインにできません。

それでも、メモリ、SSDを追加して、使いやすくしました。

メモリは、Crucialの製品を使いました。

他に、CFDも考えましたが、Curcialの方は、ThinkPadシリーズの互換性がわかるようになっていたので、こちらにしました。

メモリチェックを行い、問題がないことを確認しました。

SSDは、SAMSUNG 870 EVO 1Tです。

ThinkPadを開けると、ダミーのSSDがあり、これを外し、また、アルミシートが入っていましたので、これも使って、SSDを取り付けました。

ThinkPadの裏蓋を開けるのは、少し大変ですが、私は、ボンドに付いているヘラ（樹脂製）を使うことで、簡単に開けることができました。

Google 日本語入力

 Micorsoft IMEから、Google日本語入力に乗り換えました。

2021/2現在のWindows10のIMEでは、キーのカスタマイズができなくなりました。

カスタマイズが必要な場合、従来の古いIMEに戻す必要があります。

古いIMEに戻して使っていましたが、どうも気分が悪かったので、「Google日本語入力」をインストールして使っています。

こちらは、キーのカスタマイズに対応していて、希望通りの操作ができます。

変換効率などには、それほどこだわりがないので、これで、十分です。

というか、違いがわかりません。

マニュアルづくりなど、文章入力が大事な環境には、Atok2017を導入していますから、他の環境では、Google日本語入力で満足です。

Atokへの不満は、キーのカスタマイズで、F13など、使えないキーが多いことです。

これができれば、日本語入力を、F13に割り当てて、各パソコンのキー設定を統一しやすくなるのですが。

ThinkPad シャットダウン中にバッテリーが消費される

 ThinkPadを使っていますが、2台とも、電源を切った状態で、バッテリーが消費されるようになりました。

休止状態ではなく、シャットダウンで、切った状態でのことです。

一晩で、10％ほど消費するため、あまり使わない方の、ThinkPadは、気づくと、0%になってしまいます。

こうなると、面倒なのは、ACケーブルを繋いでも、すぐには使えません。

バッテリーが0%の場合、勝手に、休止？状態になり、ロックされてしまうのです。

しばらく、充電し、ある程度、バッテリーが回復したら、ACケーブルを繋いで作業を行うことができます。

調べてみると、

・高速スタートアップをオフにする

・USB給電をオフにする

と改善されるようです。

以前から、Windows10の高速スタートアップは、トラブルの元と思い、オフにしていますから、今度は、USBの設定を見直して、改善するかみてみます。

Windows10 20H2 画面が点滅して操作できない

 つい、うっかり、Windows10 20H2に更新してしまいました。

設定画面を開くと、画面が点滅状態になり、まともに操作できません。

ウィンドウ内が点滅して、正しい表示に変わりません。

再起動しようとしても、シャットダウン、再起動のメニューが表示されません。

これは、困りました。

Windows10 2004への怒り

 Windows 10 May 2020 Update（バージョン2004）への不満が溜まり、怒りに変わってきました。

半分は、たぶん、自分が悪いです。

更新時に、何らかのメッセージがあったのでしょう。

それを見落として、デフォルトの設定で、更新を行ってしまったのでしょう。

でも、デフォルトが、こんな最悪の設定とは思いませんでした。

これまでも、同様のことがありましたが、複数の端末（パソコン）を使っていて、OneDriveを使っていると、デスクトップの中身が、勝手に、同期され、同一の内容にしようとします。

この結果、競合が発生し、また、時には、勝手にファイルが消されてしまいます。

私の場合、デスクトップに置いているのは、リンクですし、ドキュメントフォルダや、写真フォルダには、大事な物は置かないようにしていますから、実害は、ほぼ、ありません。

しかし、ある日、突然、デスクトップのショットカットが消えてしまうのは、嫌なものです。

この迷惑なデフォルト設定は、止めてもらいたいです。

OneNote for windows10 で、複数アカウントを利用

 OneNote for windows10 で、複数アカウントを利用できるようになりました。

複数のアカウントは、既に登録済なのに、なぜか、ノートブックを開く場所に、別のアカウントのノートが表示されず、困っていました。

OneNoteのアカウントで、開けないアカウントに、「管理」という項目があったため、ここで、「Windows Hello」の設定を行うことで、開けるようになりました。

複数のパソコンを使っていますが、他のパソコンではできているのに、１台のパソコンのみ、１つのアカウントのノートは開けても、他のアカウントを開くことができませんでした。

このパソコンは、OneNote 2016を使っているため、これまで、気にしませんでしたが、昨年のWindows10の大型アップデートにより、OneNote 2016で日本語入力を行うと、クラッシュし、落ちるようになり、困っています。

そこで、本格的に、OneNote for windows10 へ移行しようとして、このトラブルに遭遇しました。