In X11, the program opens, but clicking 'Options' and then 'Close' makes the program crash. This does not happens with stardict 3.0.6.2
In Wayland, 3.0.7 does not open at all (3.0.6.2 works and opens in wayland, everything seems to work except for the tray icon).
I am using 3.0.6.2 since a few months (since 3.0.7 came to archlinux) because the program does not work for me in that way, and now since i am in wayland 3.0.7 would not work at all.
The problem is that 3.0.6.2 uses gtk2 and python2 as dependencies, and the stardict package will likely be dropped soon from archlinux packages (check https://archlinux.org/todo/gtk-2-eol/)
In the other hand, if this happens, archlinux users would have to compile gtk2 and python2 (because gnome-docs-utils requires it: https://aur.archlinux.org/packages/gnome-doc-utils) to make the program work as it should.
I tried to contact you via mail a few months ago, and also tried to contact via mail the former mantainer of the stardict package (archlinux package) and the actual mantainer of the package @felixonmars (Sorry but the archlinux's gitlab method is too sketchy for me).
I also noticed that there's not much people using this program and i was unable to find more issues like this one, so i do not discard some kind of issue with my archlinux setup.
I ran some commands, and i will attach them in here.
coredumpctl info /home/USER-NAME/stardict/src/stardict-3.0.7/dict/src/stardict
^This was tried both with the source code and with the compiled program obtained via the makepkg of the official stardict package in archlinux.
A few comments on compilation of source code:
It seems to work for me in archlinux, i had to install the following libraries to sort some of the errors:
gnome-common
yelp-tools
gconf ---> 'AM_GCONF_SOURCE_2' --> sed -i '/AM_GCONF_SOURCE_2/d' dict/configure.ac seems to bypass it(it has to be run inside the unzipper directory, the place in where autogen is located; ./autogen.sh should be run again).
3.0.7 will compile sucessfully after that, with:
./autogen
and then:
./configure --disable-tools --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --disable-gnome-support --disable-scrollkeeper --disable-gucharmap --disable-festival --disable-flite --disable-espeak --disable-espeak-ng
^Most plugins were disabled to reduce dependencies
then i ran:
make
For the 3.0.6.2 version, i have 2 source codes: one which i obtained in 2024-03-04 (4th march ; stardict-3.0.6-2-src.7z), and the new one, which seems to be updated today (stardict-3.0.6.2-github-3.tar.xz). The first one will complain about:
configure: error: gnome-doc-utils >= 0.3.2 not found
configure: error: ./configure failed for dict
(mentioned previously, installing the gnome-doc-utils)
sed -i '/GNOME_DOC_INIT/d' dict/configure.ac
sed -i '/gnome-doc-utils.make/d' dict/help/Makefile.am
^If ran inside the unzipped directory, gnome-doc-utils will not be needed (taken from archlinux PKGBUILD ; ./autogen.sh should be run again)
which indicates the lack of the Makefile.in inside dict/mac_dist (Makefile.am is the only makefile present)
^ This part seems to be solved by using another Makefile.in (taken from the other 3.0.6.2 package, which generates the corresponding file and lets me continue compiling). This could be indicating that the generation of that file is missing (in autogen script?)
OS: Archlinux
WM: labwc(wayland) ; xfwm4/openbox (x11)
DE: LXQt 2.0 (both cases, wayland and X11)
Update: Made some changes, i was able to compile the stardict-3.0.6.2-github-3.tar.xz by placing the other Makefile.in (check above).
Update2: I installed Gnome DE, and the problem seems to be the same: 3.0.7 does open in Xorg session(and crashes when 'Close' button is pressed, as described above) and it does not open at all in Gnome(Wayland) session.
So i would discard a DE-specific problem.
Update3
I am able to run startdict 3.0.7.2 in Wayland, by forcing it to use xwayland instead of the native wayland:
GDK_BACKEND=x11 stardict
The Coredump on clicking the "Close" button persists in this case too.
3.0.6.2 seems to be launched by default with xwayland.
Update 4 (2024-06-25)
For some reason, i tried again:
GDK_BACKEND=x11 stardict
And i realized that the "Close" button crash coredump did not happened to me anymore. I think this may be related to gtk theming because the only change i can think of is that i do not use the lxqt gtk theming now, but gtk-conf which uses another way to change gtk themes. Appearance of the apps is different, this makes me think that this could be a factor in my issue.
Since i now can say that 3.0.7 is working fine for me, i will let this open in case somebody else is having the same issue.
The program is now working via Xwayland in my system (Archlinux Labwc) but it is still not working in native wayland, so i hope the developer could see this issue.
After i restarted, the issue came back so this persists in my system.
Hello.
I am having issues with startdict 3.0.7 both compiled from source and from the archlinux repository (https://archlinux.org/packages/extra/x86_64/stardict/)
In X11, the program opens, but clicking 'Options' and then 'Close' makes the program crash. This does not happens with stardict 3.0.6.2
In Wayland, 3.0.7 does not open at all(3.0.6.2 works and opens in wayland, everything seems to work except for the tray icon).I am using 3.0.6.2 since a few months (since 3.0.7 came to archlinux) because the program does not work for me in that way, and now since i am in wayland 3.0.7 would not work at all.The problem is that 3.0.6.2 uses gtk2 and python2 as dependencies, and the stardict package will likely be dropped soon from archlinux packages (check https://archlinux.org/todo/gtk-2-eol/)
In the other hand, if this happens, archlinux users would have to compile gtk2
and python2 (because gnome-docs-utils requires it: https://aur.archlinux.org/packages/gnome-doc-utils)to make the program work as it should.I have not seen any issues from other users, in here (upstream) and into the archlinux gitlab (https://gitlab.archlinux.org/archlinux/packaging/packages/stardict/activity)
I tried to contact you via mail a few months ago, and also tried to contact via mail the former mantainer of the stardict package (archlinux package) and the actual mantainer of the package @felixonmars (Sorry but the archlinux's gitlab method is too sketchy for me).
I also noticed that there's not much people using this program and i was unable to find more issues like this one, so i do not discard some kind of issue with my archlinux setup.
I ran some commands, and i will attach them in here.
coredumpctl info /home/USER-NAME/stardict/src/stardict-3.0.7/dict/src/stardictand
coredumpctl gdb /home/USER-NAME/stardict/src/stardict-3.0.7/dict/src/stardictSome details where hidden (user name,bootID,machineID,etc).
coredump-stard-resum.txt
^This was tried both with the source code and with the compiled program obtained via the makepkg of the official stardict package in archlinux.
A few comments on compilation of source code:
It seems to work for me in archlinux, i had to install the following libraries to sort some of the errors:
gconf ---> 'AM_GCONF_SOURCE_2'-->sed -i '/AM_GCONF_SOURCE_2/d' dict/configure.acseems to bypass it(it has to be run inside the unzipper directory, the place in where autogen is located; ./autogen.sh should be run again).3.0.7 will compile sucessfully after that, with:
./autogenand then:
./configure --disable-tools --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --disable-gnome-support --disable-scrollkeeper --disable-gucharmap --disable-festival --disable-flite --disable-espeak --disable-espeak-ng^Most plugins were disabled to reduce dependenciesthen i ran:
makeFor the 3.0.6.2 version, i have 2 source codes: one which i obtained in 2024-03-04 (4th march ;
stardict-3.0.6-2-src.7z), and the new one, which seems to be updated today (stardict-3.0.6.2-github-3.tar.xz). The first one will complain about:(mentioned previously, installing thegnome-doc-utils)^If ran inside the unzipped directory,
gnome-doc-utilswill not be needed (taken from archlinux PKGBUILD ; ./autogen.sh should be run again)but the *github one has another error:
which indicates the lack of the^ This part seems to be solved by using another Makefile.in (taken from the other 3.0.6.2 package, which generates the corresponding file and lets me continue compiling). This could be indicating that the generation of that file is missing (in autogen script?)Makefile.ininsidedict/mac_dist(Makefile.amis the only makefile present)I indicate this thing because the repos were updated today (https://sourceforge.net/projects/stardict-4/files/)
info about my setup:
OS:
ArchlinuxWM:labwc(wayland) ; xfwm4/openbox (x11)DE:LXQt 2.0 (both cases, wayland and X11)Update: Made some changes, i was able to compile the
stardict-3.0.6.2-github-3.tar.xzby placing the other Makefile.in (check above).Update2: I installed Gnome DE, and the problem seems to be the same: 3.0.7 does open in Xorg session(and crashes when 'Close' button is pressed, as described above) and it does not open at all in Gnome(Wayland) session. So i would discard a DE-specific problem.
Update3
I am able to run startdict 3.0.7.2 in Wayland, by forcing it to use xwayland instead of the native wayland:
GDK_BACKEND=x11 stardictThe Coredump on clicking the "Close" button persists in this case too.
It can also be used in a .desktop with:
Exec=sh -c "GDK_BACKEND=x11 /path_to_executable/stardict"3.0.6.2seems to be launched by default with xwayland.Update 4 (2024-06-25) For some reason, i tried again:
GDK_BACKEND=x11 stardictAnd i realized that the "Close" button crash coredump did not happened to me anymore. I think this may be related to gtk theming because the only change i can think of is that i do not use the lxqt gtk theming now, but gtk-conf which uses another way to change gtk themes. Appearance of the apps is different, this makes me think that this could be a factor in my issue.Since i now can say that 3.0.7 is working fine for me, i will let this open in case somebody else is having the same issue.The program is now working via Xwayland in my system (Archlinux Labwc) but it is still not working in native wayland, so i hope the developer could see this issue.After i restarted, the issue came back so this persists in my system.