关于 Next Gen 的探讨

[ludoux]

后续计划将核心代码迁移到 https://github.com/ludoux/cloudlrc 仓库并使用 go 完全重写，本仓库作为一个 Windows 版本的GUI包裹。

当下进度：目前的 cloudlrc 的第二个 commit 已经可以把 id=426881480 的单曲歌词输出了，包括日中文以及合并，效果如下：

[by:桜見]
[by:桜見]
[0:00:23.330]あぁ このまま僕たちの声が
[0:00:23.330]你我二人的呐喊
[0:00:28.770]世界の端っこまで消えることなく
[0:00:28.770]如若能就此贯穿至
[0:00:34.490]届いたりしたらいいのにな
[0:00:34.490]世界尽头 就好了呢
[0:00:39.740]そしたらねぇ 二人で
[0:00:39.740]如若成真的话 那我们会
[0:00:42.390]どんな言葉を放とう
[0:00:42.390]一起喊出怎样的话语呢
[0:00:45.140]消えることない約束を
[0:00:45.140]那就二人一起
[0:00:47.900]二人で｢せーの｣で  言おう
[0:00:47.900]定下一个永不磨灭的约定吧
[0:00:52.110]
[0:00:52.110]
[0:01:00.008]もう見れなくなったのは
[0:01:00.008]究竟是从何时起
[0:01:00.890]一体いつからだろうか
[0:01:00.890]又是为何
[0:01:01.850]あぁ｢願ったらなにがしかが叶う｣
[0:01:01.850]啊「梦想终会成真」
[0:01:05.930]その言葉の眼を
[0:01:05.930]这句话
[0:01:11.700]なにゆえだろうか
[0:01:11.700]变得再也无法直视了呢
[0:01:13.320]あぁ 雨の止むまさにその切れ間と
[0:01:13.320]云消雨散的那一瞬间
[0:01:16.390]虹の出発点 終点と
[0:01:16.390]便是彩虹生命的始终
[0:01:19.100]この命果てる場所に何かがあるって
[0:01:19.100]生命的尽头一定有些什么
[0:01:22.710]いつも言い張っていた
[0:01:22.710]总是这样坚信
[0:01:29.048]いつか行こう 全生命も未到
[0:01:29.048]总有一天 我们会到达
[0:01:32.860]未開拓の
[0:01:32.860]这前人未至的情感与时间
[0:01:34.670]感情にハイタッチして
[0:01:34.670]向这心情击掌庆贺
[0:01:37.040]時間にキスを
[0:01:37.040]与这时刻唇齿相交
[0:01:39.420]５次元にからかわれて
[0:01:39.420]即便在五次元被戏耍作弄
[0:01:41.700]それでも君をみるよ
[0:01:41.700]我也依然要注视着你
[0:01:44.410]また｢はじめまして｣の合図を
[0:01:44.410]二人一起定下下一次
[0:01:47.840]決めよう
[0:01:47.840]“初次见面”时的暗号吧
[0:01:50.380]君の名を 今追いかけるよ
[0:01:50.380]我会从现在起 追寻着「你的名字」

个人觉得一这样子可以实现跨平台（指其他平台使用 cloudlrc 命令行，Windows 有此项目作为 GUI 包裹），试试 go 的协程能力，也减轻改陈旧代码的痛苦（本项目过分依赖 regex 解析 JSON 格式文本，后续修改比较头疼）。坏处就是新项目还在缓慢推进中，且可能为了 Walkman 小屏而推出的歌词分割功能，在 cloudlrc 项目中会不再支持。
@Initial-heart-1 欢迎探讨。隔壁仓库建了两个里程碑 https://github.com/ludoux/cloudlrc/milestones

[ludoux]

如果大方向不变的话，本项目就将搁置更新，直到隔壁仓库功能基本实现后，本项目将打一个新分支，把核心代码全部移除，改成对隔壁仓库二进制文件的 GUI 包裹，界面使用 WinUI3(但是好像资料太少而且官方的设计器还没有推出……) 或 WPF

[Initial-heart-1]

对于歌词分割功能，或许更优的选择或许是打开一个 issue 征求意见，我个人偏向于这个功能主要是由你个人的需求决定。
对于跨平台，老实说，我认为这并不是这个项目最需要考虑的问题。因为它是基于网易云音乐的，而网易云音乐的大多数用户主要使用 Windows 和 Android，对于后者的用户，或许需要考虑兼容，但 go 不好解决。
我个人认为重构确实有必要，这个项目的代码太陈旧了。但是在终端这可能并不能从 go 的任何特性或性能中获益，因为我们受到网易云的 API 速率限制。当然，也许这对于你个人可以学到许多，如果你也这么想，那么当然建议你使用 go。
我个人认为如果你只是想实现协程，Python 或许是更好的选择，Python 庞大的生态和优秀的跨平台支持可以帮到你很多。而且 Python 的开发流程会比多数语言更短，也更易维护（特别是对于简单项目）。
当然，我已经看过你目前搭建的框架，继续用 go 写下去也是一个不错的选择。
我个人最擅长的语言是 CSharp，如果新项目使用 go，我可能没法给你太多帮助。
我个人不推荐使用 WPF，可以等 WinUI3。现在还在关注这个项目的人我想应该可以使用 CLI 或者愿意学习使用它。
而且其实也有其他的比现在项目更优秀的开源项目可供选用。我个人认为继续维护这个项目的最大意义或许就是让自己能有一个好用的趁手的工具，或是实践自己所学到的，又或者能够帮助一些不熟悉开源社区的人享受开源的便利。当然，基于此，我注意到你似乎另有参与网易云相关项目，或许可以考虑进行一些联动以使得项目发挥更大作用。
哦对了，不妨把这个仓库设置为存档，新开一个仓库，毕竟你也曾经为它努力过，也方便还需要这个项目的人继续使用。
新的开始很多时候并不意味着旧的结束，好比现在仍有可观的设备使用 Windows XP 系统，而现在已经是 2023 年了，XP 的支持早在 2014 年 4 月停止，现在最新的 Windows 版本已经是 Windows 11。
总之，我建议，只要你觉得需要，那就去做。如果你开发这个工具的初衷是自用，那就不应受到过多束缚，开心就好 XD

[Initial-heart-1]

方便提供 IM 联系方式吗？这或许可以更有效地交流。

[Initial-heart-1]

@ludoux

[ludoux]

计划选 go 主要是可以直接打包出二进制文件出来（上文忘记提了…），其他倒是加分项。以这个理由其实还可以选 C++ 的，不过 C++ 本身太“高大上”了，个人不太会用。个人一直不太习惯 python 这种脚本语言写一个项目。 WinUI3就是还要等，我之前看还是没有那种“所见即所得”的设计器，只能说门槛还是有一点的。不过WPF确实也年代久远了。 IM 等我后续隔壁 go 仓库开发得差不多再沟通吧，我还不知道进度如何（会鸽多久）。anyway，谢谢你 :)

…

________________________________ From: Initial-heart ***@***.***> Sent: Wednesday, February 22, 2023 8:19:19 PM To: ludoux/LrcHelper ***@***.***> Cc: Lu Chang ***@***.***>; Author ***@***.***> Subject: Re: [ludoux/LrcHelper] 关于 Next Gen 的探讨 (Issue #25) 对于歌词分割功能，或许更优的选择或许是打开一个 issue 征求意见，我个人偏向于这个功能主要是由你个人的需求决定。 对于跨平台，老实说，我认为这并不是这个项目最需要考虑的问题。因为它是基于网易云音乐的，而网易云音乐的大多数用户主要使用 Windows 和 Android，对于后者的用户，或许需要考虑兼容，但 go 不好解决。 我个人认为重构确实有必要，这个项目的代码太陈旧了。但是在终端这可能并不能从 go 的任何特性或性能中获益，因为我们受到网易云的 API 速率限制。当然，也许这对于你个人可以学到许多，如果你也这么想，那么当然建议你使用 go。 我个人认为如果你只是想实现协程，Python 或许是更好的选择，Python 庞大的生态和优秀的跨平台支持可以帮到你很多。而且 Python 的开发流程会比多数语言更短，也更易维护（特别是对于简单项目）。 当然，我已经看过你目前搭建的框架，继续用 go 写下去也是一个不错的选择。 我个人最擅长的语言是 CSharp，如果新项目使用 go， 我可能没法给你太多帮助。 我个人不推荐使用 WPF，可以等 WinUI3。现在还在关注这个项目的人我想应该可以使用 CLI 或者愿意学习使用它。 而且其实也有其他的比现在项目更优秀的开源项目可供选用。我个人认为继续维护这个项目的最大意义或许就是让自己能有一个好用的趁手的工具，或是实践自己所学到的，又或者能够帮助一些不熟悉开源社区的人享受开源的便利。当然，基于此，我注意到你似乎另有参与网易云相关项目，或许可以考虑进行一些联动以使得项目发挥更大作用。 哦对了，不妨把这个仓库设置为存档，新开一个仓库，毕竟你也曾经为它努力过，也方便还需要这个项目的人继续使用。 新的开始很多时候并不意味着旧的结束，好比现在仍有可观的设备使用 Windows XP 系统，而现在已经是 2023 年了，XP 的支持早在 2014 年 4 月停止，现在最新的 Windows 版本已经是 Windows 11。 总之，我建议，只要你觉得需要，那就去做。如果你开发这个工具的初衷是自用，那就不应受到过多束缚，开心就好 XD ― Reply to this email directly, view it on GitHub<#25 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADGWKTBOLQY42PAD2Z5QQVDWYX74PANCNFSM6AAAAAAVEDTTWU>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ludoux]

@Initial-heart-1

[Initial-heart-1]

脚本语言除了方便之外，本身确实没有什么优点了，如果你希望学到些什么而不是单纯的实现什么，当然最好不使用譬如 Python 的脚本语言。
CPP 实在不应该用在这个项目上，这太可怕了，简直是噩梦。反正如你所说，你也不知道要鸽多久，说不定鸽着鸽着 WinUI3 来了呢 XD

[ludoux]

@Initial-heart-1
FYI，技术栈是 .NET6 WPF，MVVM （不过我感觉写得好烂）。UI控件用 https://wpfui.lepo.co/ 。

逻辑基本就是用 Process 类调用 Go 版本的 cloudlrc 下载歌词。我后面等稍微完善一下就开一个新分支传代码。

以及等这个完成了我有点想改项目名字为 cloudlrc_win，因为这个本质就是对隔壁 cloudlrc 做了个套皮（主要还是 xxHelper 这个命名太烂大街了）

本来想是类似 PowerToys 那种用导航页面的，后面看了一下 demo 太麻烦了，就计划还是和旧的界面类似，采用这种单窗口的。可能会有额外一个窗口用来调整高级设置啥的。大小和布局什么没有细调，不过这个控件比旧版的大，最终窗口大小肯定比旧版大。

（那个登录状态是指网易云的）

[Initial-heart-1]

copy了，个人感觉新UI不如原来的好用，我个人是喜欢简洁紧凑的UI的，当然要是做的合理的话花里胡哨也可以接受。
PowerToys 的 UI 很好，但是对于这个项目来说太重了。这本来就是一个轻量级的工具，功能也足够简单，不需要特别复杂的 UI，那样的话对于这个项目来说反倒是画蛇添足了。
改名没必要吧，检索 repo 主要靠 about 而不是 name，且我认为 xxxHelper “烂大街”是因为它足够简明易懂，这是好的。
可以标 aka. cloudlrcWinGUI，方便理解。

[ludoux]

copy了，个人感觉新UI不如原来的好用，我个人是喜欢简洁紧凑的UI的，当然要是做的合理的话花里胡哨也可以接受。 PowerToys 的 UI 很好，但是对于这个项目来说太重了。这本来就是一个轻量级的工具，功能也足够简单，不需要特别复杂的 UI，那样的话对于这个项目来说反倒是画蛇添足了。 改名没必要吧，检索 repo 主要靠 about 而不是 name，且我认为 xxxHelper “烂大街”是因为它足够简明易懂，这是好的。 可以标 aka. cloudlrcWinGUI，方便理解。

新UI确实，因为用了那个控件库，按钮什么都变大了。不过目前我的想法是布局基本仿照旧版。

以及代码推了到了新分支 neo 下，假如感兴趣可以看看。不过目前还没成型，修改可以等我第一版出来再说

[Initial-heart-1]

copy了，个人感觉新UI不如原来的好用，我个人是喜欢简洁紧凑的UI的，当然要是做的合理的话花里胡哨也可以接受。 PowerToys 的 UI 很好，但是对于这个项目来说太重了。这本来就是一个轻量级的工具，功能也足够简单，不需要特别复杂的 UI，那样的话对于这个项目来说反倒是画蛇添足了。 改名没必要吧，检索 repo 主要靠 about 而不是 name，且我认为 xxxHelper “烂大街”是因为它足够简明易懂，这是好的。 可以标 aka. cloudlrcWinGUI，方便理解。

新UI确实，因为用了那个控件库，按钮什么都变大了。不过目前我的想法是布局基本仿照旧版。

以及代码推了到了新分支 neo 下，假如感兴趣可以看看。不过目前还没成型，修改可以等我第一版出来再说

刚闲下来，准备摆一会儿再摸码，找空看看吧。
布局的话，大小不一样了你也可以考虑改变一下，看看怎么改合理些。