看起来像是一个问题。
这个暂时先不改动了。
看起来像是一个问题。
这个暂时先不改动了。
我在 #3403 提出的的问题已经解决,但是新版本又有另外一个问题出现,如录屏所示:目前正在英语群组下查询「trill」,选中「short」,右键查询后,点击导航栏的Back按钮,然后切换到A群组,查询的单词还是「short」,不应该是「trill」吗?
简单地说,#3403 的逻辑是「右键查询」「切换群组」,新版本的问题逻辑是「右键查询」「后退」「切换群组」,中间多了一步。
个人查词习惯会在一次查询中经常用到「右键查询」「前进后退」「切换群组」的功能,常交替进行,因此希望软件能够修复前述问题,包括 #3411 提到的问题,方便一目了然地查看当前所在的群组,当然此问题不解决也不太会影响使用。
试下这个版本
could you take a look in the position of elements in the UI?
i mean, when i disable the dictionary pane or even drag it down, any sort of modification to the UI is forgotten by the program when it closes…
then i manually rearrange things in the UI when it opens again:
we could save changes in the UI in some config file, that would solve the problem
the layout state should be saved.
You can try gd-ng with a different qt version.
If you are using qt6.6 ,try with qt6.7,or vice versa.
i have a freebsd machine and i tested there as well , i dont think it’s related to the qt version, maybe it’s not saving the current UI state in the dotfile
have you exit the gd-ng normally?
i keep it always open, all the time
when it closes, it’s mostly due to a power loss here.
even so, i think that closing it is not the problem, because it keeps a background service, right?
when i use the command $ pkill goldendict
then it kills the background service, and then the UI gets a reset
in my opinion it’d be better to have a hook that saves each UI changes when they happen, instead of waiting for goldendict to “close normally” (which doesn’t seem possible in my distro)
when you close the application normally , does it restore the layout correctly?
reasonable
算是一点建议吧,也许这年头硬件啥的都过剩,硬盘也是海量,cpu也过剩,唯一有点瓶颈的,都是在显卡,但一些资源文件的,能不能都尽量统一到一个mdd里,用类似java或者python的包管理的机制,举例子来说,很多词典都有发音,往往是很多类似的甚至相同的声音文件,都一个字典一个归档的,弄得,伴随的资源文件mdd贼大,还得折腾一个字典,就得下一大坨,在字典内部,多一句话,for example, ENTIRTY:PackageName:\soundFileName.mp3,同时在导入字典的时候,手动配置一个xml一类的配置文件,可以人为的指定一下对应的mdd文件,或者mdd文件链,例如 c:\collins\collins.mdxc:\collins\collins-new.mdd,这么折腾,起码灵活点儿,而且,可以重用不少可用的资源,而不是像现在一样,默认的就是同名文件。
而且如果可能的话,最好,portable的content也是可配置的,方便不同的同源的其他类型的电子字典,也能正常的读取。感觉,对于不同的电子字典来讲,正常的指定一个本地字典文件的存放目录,就应该可以识别出来,而不是像现在这样,固定的卡死在某个安装目录下。这样的话,哪怕对于字典的开发者来说,也方便调试不同版本。省的折腾一个字典就得拷贝一堆字典源文件。
固定的卡死在某个安装目录下
portable content 也可以是软连接的,
不一定是固定卡死在某个安装目录
目前这个已经是可以配置的了。
字典文件目录确实可以配置,但对应的索引文件,好像都默认建立到c盘了,能否索引文件也手动指定生成目录?
portal模式下,应该是位于content目录,不是c盘。
我自己手动在编辑–》词典–》文件–》词典所在目录, 在这里手动指定词典源文件目录,结果生成的索引文件全指向c盘了,这年头,硬盘再大,c盘也啥时候都紧张的,搞过开发,也经历过多少次gd升级了,一般都是保留好content和 portable,剩下的直接删除原有的,拿新版本替换。但这种情况下,如果仅仅只用gd没问题,类似目前这样的,想暂时保留gd和作者的新版本的gd-ng,不想再弄出来两套字典两套索引的话,必然需要其中的一个字典手动指定另外一个字典的字典文件安装目录,倒是能正确的找到字典源文件,但对应的随后生成出来的索引文件,全折腾到c盘了。
GoldenDict-ng 明显感觉比 GoldenDict的索引文件要大得多,刚刚折腾完全文索引的,发觉居然35个g的索引文件,以往,同样的字典,GoldenDict索引文件大概不到20多g。另外不知道作者是如何解决js和css的命名空间作用域的问题的。啥啥都直接端到一个大网页上,不同字典编撰者的js和css也没啥明确的包管理机制和命名约束,弄得一不小心就得有啥牵一发动全身的事儿。
谁写的 JS,谁自己解决,欧路也是这样。
索引的大小,要么空间换时间,要么时间换空间,很难平衡,原版用的 SQLite,不是专门的全文搜索引擎。