Gitnoter 项目弃就一个坑
做一件事中是得要有始有终对不, 虽然我的标题是弃就一个坑, 单这不妨碍我对这个项目做一个称重的总结, 对就是挺沉重的
为什么要启动这个项目
印象笔记
依稀记得应该是
2016, 印象笔记更改了收费模式, 每个账号只能绑定两个设备同步数据
本来这应该是件很正常不过的事, 确实轻度用户使用影响笔记免费版实在是太爽了, 根本就没必要付费, 但是他偏偏要美其名曰的说, 绝大多数用户都只有两个设备, 这就让人很恼火了, 搞得全是用户的错, 难道设备数超过了两个, 就直接砸了吗? 想盈利就明说就是了, 根本就没必有拐着弯骂人
替代产品
当时想的是找替代品并不是要自己开发, 有几个有这个闲心情的呢, 做出来没人关注, 浪费时间
- 有道笔记: 应用不好用, 还有你广告, 而且还经常数据同步失败 丢失什么的, 总结一句话就是除了免费就是一无是处的垃圾(现在是什么情况不清楚, 这是我当前用的时候的感想)
- 蚂蚁笔记: 号称是专为程序员设计的笔记, 我看就只有这么个噱头了, 不是很好用, 而且还是订阅制, 如果是买断制的话还真会考虑讲究这用
- 为知笔记: 还算好好用, 但是还是订阅制, 不订阅只能本地使用
- Ulysses: 体验好, 但不跨平台, 而且是订阅制(这个算是黑点了)
- MWeb: 好用也是买断制, 但是还是不跨平台
我心中的完美解决方案:
- Markdown
- 云同步
- 全平台 PC/Mobile
- 买断/免费 (对于轻量用户来说, 订阅制太亏了, 这也是我要弃用印象笔记的原因)
关于技术选型
首先肯定是直接看一些开源的解决方案
存储库
我第一个想到的就是使用
git来作为存储库, 这样可以依托github来存储数据了(简直天才), 而且恰好就有一个这样的跨平台的git客户端库libgit2(简直完美)
桌面端解决方案
最开始我的打算是分平台去实现相关的业务逻辑, 就我一个人搞, 业务量巨大
该死的我又不死心的去搞挺跨平台(博主之前就是搞跨平台开发的, 从此对跨平台深恶痛绝)
最后我闲着了Qt跨平台开发, 当时我想的就是,Qt毕竟是Cpp库, 怎么滴性能也不会太差吧, 而且能支持全平台, 这个完美符合我的要求(后来事实证明我还是太年轻了, 被坑的还是不够惨, 先按下不表)
移动端解决方案
自从中了
Qt的毒后我就一心扑到Qt上了, 最后采用了v-play的移动端解决方案, 刚开始看了他们几个demo应用后还沾沾自喜, 这东西还真挺不错的, 居然还能内嵌cocos2d-x
我其中的一个方案是用cocos2d-x来做跨平台开发, 博主这时大喜, 心想如果这个不行还能使用cocos2d-x来开发呢(呵呵…天真)
关于问(S)题(B)
写作问题, 读作SB, 也就不怕别人笑话了, 奏这样了
libgit2
关于这个库折腾了还几次, 整个大概经历了一两年: https://huyaohui.com/tags/libgit2/
编译
前后经历了两次不同方式的编译, 当时我还沾沾自喜, 以为找到了正确的编译姿势
呵呵…现在看来其实两种编译方式根本没什么区别
无法使用
先声明一下, 上面我写的这些都是在放屁, 其实根本不是这么回事
原因简单的要死, 就是因为我没有开启线程, 说到底还是没有仔细阅读文档
git push
也不知道怎么原因官方 api 中没提供直接 push 的方法
尽管网上有人写了 push 功能的代码, 但是尽管尝试后, 均已失败告终(这是在当时那个时间节点的事, 在我暂停编码后, 有人开源了一些基于 libgit2 的 cpp 封装实现)
最后在 libgit2 的作者拒绝掉的 PR 中找到了某人写的示例代码, 目前使用的还是这份代码, 当你看到这份代码是别拒绝的就应该知道其实写的不是很好, 仅仅就是能用而已
就在我放弃这个项目之前, 我还尝试使用 cpp 封装的 libgit2 来解决 push 问题(尽管这份代码仍然存在问题, 但是问题已经不大了), 说再多也没啥diao用了, 弃坑了
Qt
平台表现
个个不同的平台之间的表现不同, 坑的一批
虽然应该遵循, 不同平台按照不同的表现走, 但是也不能太丑了吧, 简直可以用丑到爆炸来形容了, 特别是在 Linux 平台上
最后不得不用 QSS 来处理平台表现问题, 而且在不同平台还存在兼容性的问题, 简直没法活了
webview
由于新版本的 Qt 不再支持
webview所以只能用WebEngine
偏偏WebEngin又大的一p, 最终权衡选择了使用TextBrowser来实现
坑爹开始了, 这玩意不支持CSS,JavaScript和一些html的基本特性
当然这也不怪他, 设计出来就不是为了干这些事的
接管图片显示
由上面可知得自己来处理图片的显示
OK 一同操作后先把图片下载下来然后替换掉 src 的web image到本地图片地址
难度不算大虽然性能差点勉强算是解决了, 难道你以为这就 ojbk 了吗, 还是太年轻, 接着往下看
图片显示
由于
TextBrowser不支持相对布局属性, 比如:width="80%"这样的写法
我不得不在插入图片的时候动态去计算图片的显示范围, 否则图片很大的话就会显示非常难看, 而且会超出显示框的显示大小, 继续 ojbk 你以为又搞定了, 仍然是图样
图片大小不能使用相对大小的直接问题就是当你窗口大小改变后, 你就必须要重新计算一遍大小, 否则还是会出现之前一样的问题, 但是重新计算有会有新的问题, 如果你文档中的图片数量过多的话计算起来就会非常慢, 特别是在window平台上提别明显
随之有得在window平台上加多一个机制, 就是在拖动更改窗口大小时, 只有在松开鼠标时才重新计算, 体验略差, 但是勉强就不卡了
v-play
先来说下
v-play是个什么玩意儿, 这玩意是基于Qt Quick的一个移动端游戏解决方案, 同时还能做界面开发, 因为它实现了一些UI开发中常用的空间, 使用起来还是不错的, 当然这也是一个坑而已
为什么说这玩意是个坑呢, 性能是真的差, 别看他们demo写的是挺不错的实际你用起来之后会发现是真的卡, 如果是做一些轻量级的展示类型的项目我想还是可以用的, 如果交互性太强了, 那就垃圾吧倒吧
其实如果是轻量级的展示类型的项目那么为什么不用RN呢, 这东西连Qt官方都不怎么上心去完善(当然我指的是QtQuick,v-play做的够好了)
cocos2d-x
这里顺带一提, 期间我有段时间想用这东西来搞跨平台开发(博主之前就是用这东西混了一段时间饭吃), 现在想想还好没用, 要不然不知道又要遇到多少坑呢
说说为什么弃坑
说到为什么弃坑这就不得不说说自己的经历了, 就在我决定开发这个项目之前, 我参加并主导了一个创业项目, 当然是以失败告终的, 要不然我也不会开始这个项目的, 毕竟这个东西肯定是赚不到钱的
那么又为什么要做呢, 这就要说到我性格了, 想做的事就一定会想着去做, 就像本项目一样, 虽然16年就想做了, 但是还是等到了17年才开始做, 期间做了大量的调研和准备工作, 如果不是创业失败也许不知道什么时候会开始这个项目
搞了半天还是没有说为什么弃坑呢, 这就来了
经历过创业失败和开发该项目遇到的问题的双重打击下, 我到是想明白了很多事, 人也通透多了
任何事情都不是做了就一定要等待一个结果的, 其实人生中有很多事是没有什么所谓的结果
或许弃坑也是一种结果呢, 是吧
迈出这一步虽然不容易, 但是决定迈出去后, 反而人清爽了许多, 每个人的精力和能力都是有局限性的
没有为自己辩解的意思, 随着年龄的增长, 对事物看法逐渐的趋于平和了, 对事物的看法反而更透彻了, 不再盲目的跟风和特立独行(表面上的)了
想说的很多, 但文笔有限, 那么就这样了吧
契机
无论做什么都是要有一个契机的, 我弃坑这件事也是如此
事情是这样的, 平常我是会关注一些微博上的技术博主的, 他们经常会推荐一些比较好用的框架和应用什么的
就在前段时间(据我动手写这篇博文已经过去很久了), 看到今天我要说的这个项目
tamlok/vnote这个也是用Qt开发的先来提取几个关键字
- 项目起始时间: 2017年
- star: 4455(写到这里去看了一下, 应该比我当时看到要多出不少)
- Qt
- markdown
- WebEngine
从中看出来和我这个项目很相似, 但是选型上就有很大不同了, 我选择的是纯cpp开发, 而该作者这是完全是依托于 WebEngine
先来说说各自的优缺点
我的方案的好处就是性能高, 包体小, 缺点可用的轮子少, 集成难度大
vnote 则和我的方案恰好相反, 好处是轮子多, 集成难度小, 缺点就是性能相对略差, 包体大
其实开始我也想过使用 vnote 这样方案, 但是性能差这点实在是不能忍的虽然我的markdown preview这块的逻辑性能也比较差, 但是优化一下还是可以的, 而且我正在尝试用zserge/webview该库的解决方案来处理我这块的逻辑, 即解决的性能问题, 也解决了包体大小的问题, 但是一切都完了, 我弃坑了
能获得这么多的 star, 肯定比我牛, 我相信 vnote 的作者也是能想到我想到的这些问题的, 至于他是什么想法我到是也不想去探寻了
这里顺便一提, 为知笔记用的也是用的 Qt WebEngine
总结
如果有人说是我垃圾不会用
Qt的话, 我承认我确实用不好
好了这次就真的这样, 没什么要说的了