东八区深夜长放送(LCL P2)
所以跨平台GUI开发需要解决的问题(LCL?——答案,但散落于尘世之间)
- 给使用者提供满足他们愿望的接口,避免无意义的直接内存访问.
换句话说就是我不想看到真正的指针.
- 为了满足上述观点,中间语言(我们暂时说为IR)是必定存在的;
那么,GUI框架设计者得想方法减少IR本身抽象出的资源占用.
遗憾的是,我们都深知这二者是对立的...
但是我们还是用黄绿二色标注出来的东西审视一下现有成熟技术:
- Qt:还行,实际上用到最后...玩的是QML,C++部分是难,
但是用的很基本,反而是个人认为最好性能解决方案;
- GTK:Linux&Mac上觉得比Qt不相上下的方案;
但是放到Windows上完全是灾难....打开十分缓慢...
- React_Native:只要不用Electron就是永远的神,用了的话...
我也没办法(我不得不用啊)
但是,从JS到各大平台的现有底层渲染框架(参见LCL_P1)就意味着需要一层,
还有一层是那些平台自己的抽象...
不过后面那个忽略不计...(好像Windows除外哈哈哈哈)
我其实排斥React_Native的原因是因为搞这个东西出来...是为了解决fb他自己的问题...
那些渲染后端是他们挑选的;
真正好的东西...真有开源+大众选择 这么简单就好了....
- iced-rs:我用过最舒服的框架,但是...编译有点小慢...
而且要颅内渲染...做东西有点耗时间...
实际上...写界面最好的语言...最好不要是C/C++,哪怕他俩带GC.
Rust都比这俩写的舒服...
前端3件套不论是在他们那个时候还是现在都是最佳选择.
那么,如果从我们快速需要的角度(比如说没事干写个小GUI程序;突然间要接任务)
等等地方想问题...
在历史弥留处...一定会有人曾经做到上述这三个颜色提出的问题...
最近找到了一个:Lazarus/CodeTyphon.
写到这里我自己都觉得有点先射箭后画靶了...哈哈,但请看官勿急..
咱们先上截图
这是CT在Windows上我们可以使用的界面库,理论上都是可以用的
(CT是Lazarus一个分支,为了稳定Win下Qt是假的选项)...
没错,也就是说:
想要原生有原生,想要跨平台可以跨平台,满足多方面需求,兼容所有可能选择
再来一个让人惊讶的:
没错,整个IDE都是可以编译的...也就是说他会送源码给你qwq
这也意味着我们可以干任何事情
或者从某种程度上说:他们可以只提供源码,我们自己编自己的IDE.
用那个时候的语言来说...IDE是对RAD之类编辑器的称呼(或许不对,因为现在对IDE的要求比以往任何时候都要高;还得与那个时候的人考证考证RAD说法)
也许看到这里我得说点历史了....
还记得LCL_P1当中提到的微软抢人吗?
我把微软做的一些语言(C#/VB)留到现在说的原因是:
我擦,主界面不就是Visual Studio吗?
是的(如果你细心的话,在上一张图片中有个选项是关于Delphi的...Lazarus其实就是Delphi的开源版本)
Dephi开发者后面去了微软然后做出了...C#/Winform...
千禧年的我们没有经历那段时间...微软的J++被告侵权...Borland编译器之争...还有Delphi首席开发人员被挖到对手(MS)那边去的最后结果:
无人问津....当一个东西小众+开源,等待的也许只有人们口口声声中说出的热血到滴泪的历史.
往事不再提...
到这里,红颜色问题解决了(不要颅内渲染,直接从控件拖东西,尽可能满足开发者所有需求),我找到了我想要的工具:
真正把开发人员当用户对待的产品.
Lazaru使用的IR是Free Pascal.这个语言的唯一缺点就是啰嗦(高情商:犯错概率低一点).
我记得17年竞赛的时候还能用这个语言,现在不行了.
但是加入了面向对象,似乎也可以用继承/多态的方式定义整套界面逻辑了.
编译速度:整个Lazarus IDE 千行左右,开优化模式12500H只需30秒编译完成(没开Make 多线程呢)..
但是历史原因导致...没办法热重载...
编译中间产物:ELF 可重定位文件
Windows底下也是一样的(MingGW)
编译目标依赖(Linux/Qt6编译模式下)与纯原生Qt6依赖区别:几乎没有
左边是原生Qt,右边是Lazarus生成
但是文件大小就没办法了(上面原生,下面Lazarus(去除调试符号,不然膨胀十分离谱))
确实解决了绿色问题,那么最关键的接口....?