分类 折腾=-= 下的文章

设计目的是方便在H&G里打狙。顺带一提,我忘了怎么制作外挂了(也许写的出挂我就用不上这个了)。

功能要素

  1. 一个小准星,几个像素点聚集在一个点的就可以。
  2. 按键调整是否显示
  3. 按键调整准星位置
  4. 保持准星在游戏画面内稳定显示不过渡遮挡按钮

预期实现方法

python3 tkinter 像素级超小带色无边框窗口

具体实现:

from contextlib import suppress
from tkinter import *
from keyboard import *
root=Tk()
root.title("crosshair")
x = round(root.winfo_screenwidth()/2-2)
y = round(root.winfo_screenheight()/2-2)
root.geometry("4x4+{}+{}".format(x,y))
root.resizable(0,0)
root.overrideredirect(True)
root.config(bg="#7cfc00")
root.lift()
root.attributes("-topmost", True) #保持准星窗口在顶层
root.wm_attributes('-topmost', 1)
hook_key("end", root.destroy)
def autoadjust():
    x = round(root.winfo_screenwidth()/2-2)
    y = round(root.winfo_screenheight()/2-2)
    root.geometry("4x4+{}+{}".format(x, y))

hook_key("home",autoadjust)

root.mainloop()
print("hello")
unhook_all()

本文写作动机:

我在Debian Buster with Armbian Linux
5.3.0-rockchip64上配置cloudreve的持久化出现问题 nano /usr/lib/systemd/system/cloudreve.service出现如下红色报错: `Directory
'/usr/lib/systemd/system' does not exist`
当你按照cloudreve官方文档用vim会发现没有这个问题,只是有提示:[New DIRECTORY],所以进入/usr/lib/systemd看了一眼:只有这几个蓝色文件夹 boot catalog logind.conf.d user user-environment-generators user-generators user-preset 那么结合[New DIRECTORY]这一提示,其实就是没system这个文件夹,这时候又想起网友跟我说过nano有时候会碰到权限问题,但是vim就没这个问题。看起来新秀仍需打磨.......在/usr/lib/systemd/下新建system文件夹再执行就没事了。
systemd的相关东西看情况更新吧,用到了我就记上,没用到就随缘。

Systemd 目录

引用https://cloud.tencent.com/developer/article/1516125

Unit 文件按照 Systemd 约定,应该被放置指定的三个系统目录之一中。这三个目录是有优先级的,如下所示,越靠上的优先级越高。因此,在三个目录中有同名文件的时候,只有优先级最高的目录里的那个文件会被使用。

/etc/systemd/system:系统或用户自定义的配置文件
/run/systemd/system:软件运行时生成的配置文件
/usr/lib/systemd/system:系统或第三方软件安装时添加的配置文件。

CentOS 7:Unit 文件指向该目录
ubuntu 16:被移到了 /lib/systemd/system
Systemd 默认从目录 /etc/systemd/system/ 读取配置文件。但是,里面存放的大部分文件都是符号链接,指向目录 /usr/lib/systemd/system/,真正的配置文件存放在那个目录。

在Android下使用同文输入法

 前天的时候,因为一些事情让我在我的华为手机上重新开始使用同文输入法,不知道是因为什么原因输入法词库似乎出现了问题,打字出现很多不应出现的繁体字,卸载重装问题依旧。看群友说最近同文版本更新后挺稳定的,索性删干净本地配置文件,重新去github下载了最新版本安装包,然后手动下载了rimerc最新的配置文件进行配置。发现UI更改了,看上去比以前成熟了许多,输入也很舒服。

在linux mint下使用中州韵RIME输入法

 中州韵和同文输入法都是开源的中州韵输入法引擎(RIME)衍生的产物。之前一直没敢在linux下使用中州韵,但是同文在移动端的体验让我对RIME的其他平台的实现充满了信心。参照https://rime.im/download/ 的说明,我选择了fcitx-rime,因为我已经在PC上安装过基于fcitx实现的百度拼音输入法了。
安装参考fcitx-rime的github说明,linux mint是基于ubuntu的,我可以直接使用打包好的安装包。
当然,因为我很久没更新软件包了,故在此之前先通过包管理器更新了除了wine的全部软件包。随后重启PC开始安装中州韵。

sudo apt-get install fcitx-rime

等待命令执行完成后可以在右下角进入fcitx配置自己的输入法方案了,我目前在使用明月拼音,不过地球拼音也很棒啦!后者会有拼音提示的哦!

设置默认输入法方案

中州韵在linux下安装后默认方案是明月拼音(繁体),对于我一个中国大陆地区的用户来说肯定得修改成明月拼音简化字的。
用户文件目录是~/.config/fcitx/rime/,如果你用ibus路径应该也类似,很容易找到。
相关路径参照RimeWithSchemata#rime-中的數據文件分佈及作用
配置文件编写参考了rime中州韵输入法安装及配置【输入法】Rime-中州韵 基本设置 附:官方定制指南

以下操作可以参照注释手动在文件管理器里完成,不必强迫自己用命令进行。
cd /home/xfox/.config/fcitx/rime        #进入RIME的用户目录
touch default.custom.yaml               #创建自定义全局配置文件
nano default.custom.yaml                #编辑文件(随便你用什么编辑器)
不要创建default.yaml,这个文件是RIME在启动后自动动态拼接多个配置文件产生的总配置文件,直接创建并修改这一文件会在软件更新,重新部署等时刻丢失你的配置信息!
在你的自定义输入法配置文件中加入如下内容:
# default.custom.yaml
# 用户  输入法配置
patch:  
  schema_list:  # 输入方案列表
    - schema: luna_pinyin_simp  # 不使用其它输入方案, 只保留明月拼音-简化字输入方案
  menu:
    page_size: 5  # 候选词为5个

接下来重启fcitx后者点击重新部署。

这里发现一个很坑的地方,luna_pinyin_simp是指的朙月拼音-简化字,而你使用朙月拼音简化字对应生成的文件还是在luna_pinyin.userdb这个朙月拼音的文件夹里。所以,如果你想实现开机默认使用朙月拼音简化字方案,我上面引用的两个教程里,jrri这个人写了’输入法自定义方案设置为朙月拼音和自定义朙月拼音方案使用简体字‘两个自定义配置文件,就是完全错误的行为。如果你完全按照他的配置文件照抄出两个自定义配置文件然后重新启动fcitx后会出现报错,并且输入法配置错误无法正常输出汉字,只能输出英语。总而言之,你只需要设定默认输入法方案是朙月拼音-简化字就可以了,根本不需要去写朙月拼音的方案自定义内容(替你踩过坑了,不用谢我=-=)

在windows10下使用小狼毫(Weasel)输入法

 小狼毫是RIME在windows下的实现,https://rime.im/download/ 看开发日志已经很成熟了,等我下次使用windows10的时候顺便用它替换百度拼音。

 向自由软件开发者致敬!谢谢!

本篇博文全部在thinkpad上使用中州韵完成,输入体验极佳!

意外的惊喜:

我发现卸载百度拼音输入法后,linux下的原生微信2.1.1聊天框是可以正常使用中州韵输入文字的,而且正常显示。也就是说,微信输入框不显示文字的问题大概率是百度输入法的锅,万恶百度,万恶腾讯。

前段时间在我家云搭建了cloudreve,因为systemctl有问题,换用了screen,但是开机自启动一直没解决好。

脚本实现screen开机自启动并运行指定程序

参考了Zbuter前辈的开机启动screen并在后台运行其他程序
新建一个脚本文件,内容如下。

screen_name="cloudreve"                # 要建立的screen名字
screen -dmS $screen_name
cmd="/home/SATA-Data/cloudreve/cloudreve"    # 要执行的命令,要指明路径,不指明时默认是在 / 目录下
screen -x -S $screen_name -p 0 -X stuff "$cmd"    # 输入命令
screen -x -S $screen_name -p 0 -X stuff $'\n'   # 回车执行

然后把执行上述脚本的命令加入rc.local就行了,没执行权限记得chmod +x

摘自:知乎:dealiaxy(很巧,这位前辈跟我一样用的linux mint)

我经常遇到Linux下时间正常,但是Windows下时间错误(相差八小时)的问题,两个系统时间设定本来都好好的。

原因

windows默认使用硬件时钟,而linux使用网络时间

解决方案

linux下执行

timedatectl set-local-rtc 1

还可以执行后进行验证:

timedatectl

运算符描述实例
+=加法赋值运算符c += a 等效于 c = c + a
-=减法赋值运算符c -= a 等效于 c = c - a
*=乘法赋值运算符c *= a 等效于 c = c * a
/=除法赋值运算符c /= a 等效于 c = c / a
%=取模赋值运算符c %= a 等效于 c = c % a
**=幂赋值运算符c **= a 等效于 c = c ** a
//=取整除赋值运算符c //= a 等效于 c = c // a

列举部分占位符

%d整数的占位符
%f小数的占位符
%%表示百分号(因为百分号代表了占位符,所以带占位符的字符串中要表示百分号必须写成%%)

一、 使用占位符%格式化

按序罗列式 适用于python2.6前,沿用至今 延用了C语言的输出格式
a=1.1
b=2
print("有两个数,分别是浮点数a= %f 和整数b= %d" %(a,b))

这种写法,必须在后方按照顺序罗列准备用于替换占位符的变量名称,能不能在前面直接指定用于替换的变量名称呢?

二、 使用format格式化

官方推荐 python2.6新增,沿用至今
格式:str.format
a=1.1
b=2
print("有两个数,分别是浮点数a= {}和整数b= {}".format(a,b)) 
# {key}称为索引,索引为空{}时,按照顺序从后方取值,可以使用01234这样的顺序的数字作为索引进行排序。
print("有两个数,分别是浮点数a= {0}和整数b= {1}".format(a,b))
# 也可以直接使用一个特定名称作为索引。
print("有两个数,分别是浮点数a= {num_a}和整数b= {num_b}".format(num_a=a,num_b=b))
# 你也可以把变量a,b替换为一个单引号包括的字符串,如:'1.1'

以上三个print语句都输出:有两个数,分别是浮点数a= 1.1和整数b= 2

三、 f-string格式化

直接指定式 适用于Python >= 3.6
f-string是在字符串前面加上 "f",{}直接使用变量、表达式等。
a=1.1
b=2
print(f"有两个数,分别是浮点数a= {a:.1f}和整数b= {b:d}")
# 为啥加个.1而不是直接写{a:f} ?f前面的.1指的是保留小数点后一位小数,不写.1输出的就是:1.100000

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!