|
|
db28e8525c
|
使用rust的宏来控制编译，是的可以适配本地调试环境和公司的正式环境
|
2024-09-20 08:54:02 +08:00 |
|
|
|
ed30319430
|
1. 完善发送的逻辑，使用状态机和鼠标以及pip_file一同进行管理
2. 自测已可正常发送接收
3. atime的管理使用write还是read去更新需要使用宏来控制。目前已coding完毕等待调试
|
2024-09-19 08:44:31 +08:00 |
|
|
|
3303c3b208
|
添加msg的提供者的逻辑
完成基础版本的交互逻辑已经具备同步消息的框架了。就是状态维护上有点瑕疵等待完善。
|
2024-09-06 08:38:28 +08:00 |
|
|
|
089bf1e3ac
|
1. 完成消息的接收循环的编写，现在的逻辑是：
1. 如果当前的前台程序是xxx那么就进入等待移出状态，
2. 如果当前是等待移出状态，然后切换了前台程序到其他程序那就触发一次同步
3. 同步后进入idle状态等待聚焦到xxx
2. 完成消息的发送基础步骤的准备，自动获取剪切板数据并且根据长度进行拆包进行发送。
3. 创建一个python的flask应用方便快速测试
4. 完成命令行参数的CLI化，方便直接使用，l0就是consumer，l3就是producer
5. 完成用户名的加密解密，使用机器的硬盘序列号进行加密解密
6. 保存msg的magic和cookies，方便重启使用，
但是目前来说cookies没有也是ok的。
因为没有做cookies的过期处理还。每次启动都会登录处理，并且登录期间过期的话只会异常，不会恢复，
所以这块还需要完善一下，如果登录期间发现过期了应当重新认证一下。
7. 等待完善发送的逻辑，这块本意是想要在l3的窗口鼠标移动到边缘之后保持不动就进行发送，
但是会存在一些和l0之间时序上匹配的问题。
如果l3另外启动一个用户界面用来交给用户触发交互呢，又做不到程序起初想要的无感的想法，这块还要再确认下
|
2024-08-28 08:26:23 +08:00 |
|
|
|
4d04dc2677
|
windows获取窗口相关的api搞定等待完善message的管理管理逻辑。
1. message不能重复设置多次，相同的message只设置一次
2. 鼠标在L3移出去就发送剪切板消息不行，需要换成监听windows剪切板，只有内容变动的时候并且鼠标移动到窗口外面再发送，避免发送重复的消息。
3. 鼠标在L0只要前台窗口时VM horizontal时移出窗口外就进行剪切板的同步。
4. 单个消息使用时间作为magic str，这部分需要适配一下。
|
2024-08-19 08:37:02 +08:00 |
|
|
|
041a1526d6
|
日常同步代码，未包含新增功能只有，新增一些windows窗口相关的代码，待完善
|
2024-08-13 08:50:51 +08:00 |
|
|
|
5d99d5bf46
|
1. 完善msg的处理工作。到了可以调试的步骤了
2. 准备增加屏幕和鼠标的获取相关代码，尚不能编译 通过
|
2024-08-09 08:40:04 +08:00 |
|
|
|
ef5ba10d0e
|
1. 完善code，新建线程监听ok，sub msg的格式确定。待完善code
|
2024-08-08 08:50:10 +08:00 |
|
|
|
a77a15f6b6
|
初始提交：
1. 添加登陆和验证相关code。已ok
2. 获取数据并放置到剪切板相关code 已ok
3. 定义交互的数据头，以便于长msg的切割：
${index}@${revicesize}@
index： 拆分后的数据包的编号两个字符使用ascii编码
revicesize：已接收的数据的长度，三个字符
4. 新建一个线程去持续监听：当鼠标焦点移开某应用程序窗口时触发获取
|
2024-08-07 21:11:57 +08:00 |
|
