dino
dino copied to clipboard
dino
Windows Support
This ticket should serve as a kind of meta ticket, to track the efforts needed to bring dino to windows. I have automated the build in #304, so we can put out builds without any problems.
From my small assessment there are two high priority that needs a fix before any other work for the windows port can be done:
is_24h_formatfromhelper.valacrashes dino. From my limited knowledge of GTK, this seems to be ok to crash since there is no gnome-functionality on windows?- Notifications are broken upstream. As a possible fix, just disable the notifications on windows, till a proper backend lands in GTK?
On the chat there was a discussion if dino should look native, I think it should, but the first priority should be that it does not crash or behaves funny. Then there should be put energy into making dino look native.
I think it should be native, too. Is this only a question of GUI? Or are there other related issues if we decide for one or another? I mean, if people don't like it - fork it, do it the other way.... or?
Someone made a dummy win32 notification backend for GNotification https://bugzilla.gnome.org/show_bug.cgi?id=776583#c7 I hope this gets fixed soon
I think a "vote" for/against "native" when it hasn't been determined what "native" means just before the vote is not useful.
@LuccoJ HI, guess you are probably right. Thought it's clear - may someone help out with a good definition?
Anyway, the vote so far made clear that this is polarizing topic. That's an evaluation, too.
@enko Hi, any updates so far? If there are issues, maybe someone else could help?
Just FYI, Dino works on WSL with a vcXsrv after intalling all dependencies. At first it crashed on load, but was fixed after running "sudo dpkg-reconfigure tzdata".
@LAGonauta Thanks for your info. Any extra info we might need to know? If you can exactly document how you make it run, that would be great!
Sure: After fresh install of WSL Ubuntu 18.04
Update installation:
sudo apt update && sudo apt upgrade
Install dependencies:
sudo apt install build-essential ninja-build cmake valac libgee-0.8-dev libsqlite3-dev libgdk-pixbuf2.0-dev libgtk-3-dev libsoup2.4-dev libgpgme-dev libqrencode-dev libgcrypt20-dev dbus-x11
Clone and build:
sudo apt install git
git clone https://github.com/dino/dino/
cd dino && ./configure
make
Configure timezone data:
sudo dpkg-reconfigure tzdata
Install X server:
https://sourceforge.net/projects/vcxsrv/ After installation, run Xlaunch on multi-window mode.
Run:
Go back to WSL and run dino:
export DISPLAY=:0
export LIBGL_ALWAYS_INDIRECT=1
build/dino
Optional dependency:
sudo apt install fonts-emojione
It is not perfect as for some reason the window does not behave as a normal window on Windows (probably because of the decorations), however all the rest seems to be working fine. Definitely prettier than Gajim :P
Do you really need to build dino yourself in this case or could you just add the repository?
@LAGonauta I guess that NOT for Microsoft Windows, right?
This is what the issue is about
Yes, it is Microsoft Windows: https://docs.microsoft.com/en-us/windows/wsl/install-win10
EDIT: Of course it can't be distributed, may may help debugging.
Ahh, Win7 was my last MS system years ago, never used Win10 for all reasons ;)
@enko experienced big isses with the MS visual studio compling an .exe. Do you (or anyone else) know people with more experience with this? @LAGonauta
However, thanks for your post!
With some help from cacahuete from Dino MUC I was able to compile with MSYS2, as shown in the image above 😀 I disabled CSD as it is strange on Windows and not compatible with AeroSnap, but it is working. Current patch: (for some reason I had to instantiate those classes when compiling on MSYS2) instance.txt
Notifications are not crashing thanks to the changes in glib 👍
Current build script, based #304:
#!/bin/bash
cd dino && \
./configure --with-libsignal-in-tree && \
make -j5 && \
cd build && \
mkdir -p dist && \
cp *.exe *.dll dist && \
cd dist && \
ldd dino.exe | grep mingw64 | awk '{print "cp /mingw64/bin/"$1" ."}' | sh && \
mkdir -p ./share/icons && cp -r /mingw64/share/icons ./share/ && \
mkdir -p ./share/themes && cp -r /mingw64/share/themes ./share/ && \
mkdir -p ./share/glib-2.0/schemas && cp -r /mingw64/share/glib-2.0/schemas ./share/glib-2.0/ && \
mkdir -p ./lib/gdk-pixbuf-2.0/ && cp -r /mingw64/lib/gdk-pixbuf-2.0 ./lib/ && \
mkdir -p ./lib/gio/ && cp -r /mingw64/lib/gio ./lib/ && \
mkdir -p ./plugins/ && mv -f http-files.dll omemo.dll openpgp.dll ./plugins/ && \
find . -iname "*.dll" -exec ldd {} + | grep mingw64 | awk '{print "cp /mingw64/bin/"$1" ."}' | sh
It seems that Vala or GTK3 loads most modules dynamically, and ldd is not able to find them, thus we must copy them manually. ~There are still some libraries to be copied, as OMEMO and OpenPGP are not working.~ ~OMEMO works, but GPGME is segfaulting. (remove openpgp.dll for now from the plugin folder for Dino to work)~ Image preview, and opening links/attachments are also not working.
Since MAM might be hiding some stuff, I'll post my findings here too, with @LAGonauta build...
It can't find the plugins...
...so I create that and put those 3 files there and OMEMO and http_upload are working :tada:
Now for PGP...
...and I have the one from www.gpg4win.org installed but it's in C:\Program Files (x86)\GnuPG\bin\ I can move stuff around... put it in C:\Program Files (x86)\GNU\GnuPG\ yet
...ok copy that .exe in the Dino folder... aaaaannnd.... crash... :(
Branch with my tweaks: https://github.com/LAGonauta/dino/tree/master-windows-changes Newest install dependencies script:
#!/bin/bash
pacman -S --needed \
mingw64/mingw-w64-x86_64-gcc \
mingw64/mingw-w64-x86_64-cmake \
mingw64/mingw-w64-x86_64-ninja \
mingw64/mingw-w64-x86_64-libsoup \
mingw64/mingw-w64-x86_64-gtk3 \
mingw64/mingw-w64-x86_64-sqlite3 \
mingw64/mingw-w64-x86_64-gobject-introspection \
mingw64/mingw-w64-x86_64-glib2 \
mingw64/mingw-w64-x86_64-glib-networking \
mingw64/mingw-w64-x86_64-libgcrypt \
mingw64/mingw-w64-x86_64-libgee \
mingw64/mingw-w64-x86_64-pkg-config \
mingw64/mingw-w64-x86_64-vala \
mingw64/mingw-w64-x86_64-gsettings-desktop-schemas \
mingw64/mingw-w64-x86_64-qrencode
Newest build script:
#!/bin/bash
cd dino && \
./configure --with-libsignal-in-tree --no-debug --release && \
make -j5 && \
cd build && \
mkdir -p dist && \
strip -s dino.exe *.dll && \
cp *.exe *.dll dist && \
cd dist && \
ldd dino.exe | grep mingw64 | awk '{print "cp /mingw64/bin/"$1" ."}' | sh && \
mkdir -p ./share/icons && cp -r /mingw64/share/icons ./share/ && \
mkdir -p ./share/themes && cp -r /mingw64/share/themes ./share/ && \
mkdir -p ./share/glib-2.0/schemas && cp -r /mingw64/share/glib-2.0/schemas ./share/glib-2.0/ && \
mkdir -p ./lib/gdk-pixbuf-2.0/ && cp -r /mingw64/lib/gdk-pixbuf-2.0 ./lib/ && \
mkdir -p ./lib/gio/ && cp -r /mingw64/lib/gio ./lib/ && \
mkdir -p ./plugins/ && mv -f http-files.dll openpgp.dll omemo.dll ./plugins/ && \
find . -iname "*.dll" -exec ldd {} + | grep mingw64 | awk '{print "cp /mingw64/bin/"$1" ."}' | sh
Any chance this gets merged to upstream dino repo, so there will be zip or installer exe available for Dino on Windows?
The biggest amount of friends & family uses Windows and there is no really viable xmpp client at the moment for windows.
@LAGonauta How do you get the mingw64/... packages? It seems that I have to add some database that I don't have.
New install dependencies script, adding ntldd as ldd did not always return all dependencies:
#!/bin/bash
pacman -S --needed \
mingw64/mingw-w64-x86_64-gcc \
mingw64/mingw-w64-x86_64-cmake \
mingw64/mingw-w64-x86_64-enchant \
mingw64/mingw-w64-x86_64-ninja \
mingw64/mingw-w64-x86_64-libsoup \
mingw64/mingw-w64-x86_64-gtk3 \
mingw64/mingw-w64-x86_64-sqlite3 \
mingw64/mingw-w64-x86_64-gobject-introspection \
mingw64/mingw-w64-x86_64-glib2 \
mingw64/mingw-w64-x86_64-glib-networking \
mingw64/mingw-w64-x86_64-libgcrypt \
mingw64/mingw-w64-x86_64-libgee \
mingw64/mingw-w64-x86_64-gpgme \
mingw64/mingw-w64-x86_64-pkg-config \
mingw64/mingw-w64-x86_64-vala \
mingw64/mingw-w64-x86_64-gsettings-desktop-schemas \
mingw64/mingw-w64-x86_64-qrencode \
mingw64/mingw-w64-x86_64-libsignal-protocol-c \
mingw64/mingw-w64-x86_64-ntldd-git
New build script that uses make install to be easier to maintain:
cd dino && \
./configure --program-prefix=${PWD}/dist --no-debug --release --disable-fast-vapi && \
make -j5 && \
make install && \
cd dist && \
cp /mingw64/bin/gdbus.exe ./bin && \
cp /mingw64/bin/gspawn-win64-helper.exe ./bin && \
cp -r /mingw64/share/xml ./share && \
cp -r /mingw64/lib/enchant-2 ./lib && \
mkdir -p ./lib/gdk-pixbuf-2.0/ && cp -r /mingw64/lib/gdk-pixbuf-2.0 ./lib/ && \
mkdir -p ./lib/gio/ && cp -r /mingw64/lib/gio ./lib/ && \
mkdir -p ./share/icons && cp -r /mingw64/share/icons ./share/ && \
mkdir -p ./share/locale && cp -r /mingw64/share/locale ./share/ && \
mkdir -p ./share/glib-2.0/schemas && cp -r /mingw64/share/glib-2.0/schemas ./share/glib-2.0/ && \
rm -r ./include &&
find . -iname "*.dll.a" -exec rm {} + && \
find . -iname "*.exe" -exec ntldd {} + | grep mingw64 | awk '{print "cp /mingw64/bin/"$1" ."}' | sh && \
find . -iname "*.dll" -exec ntldd {} + | grep mingw64 | awk '{print "cp /mingw64/bin/"$1" ."}' | sh && \
find . -iname "*.exe" -exec ldd {} + | grep mingw64 | awk '{print "cp /mingw64/bin/"$1" ."}' | sh && \
find . -iname "*.dll" -exec ldd {} + | grep mingw64 | awk '{print "cp /mingw64/bin/"$1" ."}' | sh && \
find . -iname "*.exe" -exec strip -s {} + && \
find . -iname "*.dll" -exec strip -s {} + && \
mv *.dll ./bin
Anyway you could release a precompiled built for testing?
Im currently in the process of upgrading our xmpp system in our organisation (move to prosody and new client). We have a mixed environment with windows linux and mac clients but i would love to deploy a single desktop client to all users. Dino seems to be a great solution as it has all features i would like to use built in, the only problem atm is the missing windows support.
Any timeline on when this will be merged and prebuilt packages available? 0.2 Milestone?
Currently we are using pidgin but since more users want to be able to use more than one device with all messages synced this wont be a solution for much longer.
@sonicnkt better use anything than Pidgin. If the prebuilds are not gonna make it, evtl. have a look at Gajim, Converse.js or UWPX (Alpha)
Yeah i set this up a few years ago and it had a clean ui and worked for everything we needed back then. Today it wont cut it anymore.
Didnt really like gajim as well i will take a look at UWPX but im not sure this will work on all clients as we are using win10 LTSB/LTSC releases. The Sideload installer is quite huge with 300MB 😱
I know this is getting a bit off topic but how does converse handle large file transfers? we are using xmpp alot to transfer huge files p2p internally.
@langrafik Afaik the Dino devs will release windows builds once it is considered good enough.
Till this is achieved you can have a look here where someone makes Dino able to compile on Windows. If you managed to build it you can easily create an installer by using NSIS (see my proof-of-concept).
Hey everyone! For those who just wants to try out Dino on Windows, I have set up a CI based on Github actions so you don't have to: https://github.com/LAGonauta/dino/pull/3. The PR is currently a draft but it is usable (that's my main XMPP client on Windows atm). The CI outputs a Windows .exe installer for every release I perform. You can get the most fresh builds there: https://github.com/Deluvi/dino/releases (And maybe someday here: https://github.com/LAGonauta/dino/releases and eventually, with my best hope, here https://github.com/dino/dino/releases 😄) It is not an official release in any shape or form, just something I hacked over the week-end. It's more of a demo of what LAGonauta achieved in his compatibility tweaks PR: a working version of Dino on Windows!
To be clear, I am doing my PR on top of LAGonauta's PR. I don't think my PR should be merged before his PR is upstreamed on Dino in order to keep his PR scoped: I will probably rebase my CI PR on the upstream repository.
However, Dino will need a Windows CI eventually. The state of package managers on Windows requires, unfortunately, the upstream developers to ship their own Windows build unlike Linux distributions. How this build will be performed is a needed conversation with the maintainers if we wants Dino to be shipped efficiently on Windows.
As an example, Transmission[1] and Inkscape[2] both uses appveyor to automatically builds their own Windows installer. Afterwards, those installers are picked up by the packages managers (such as Chocolatey) to be installed, no builds are performed by the maintainers of the choco packages[3][4].
I am in no way expert on that field, but it seems that, according to my examples, upstream Dino's maintainers will need to provide an official Windows build if we want to support that platform. A CI build would ease the burden of the maintainers to not build themselves manually the installer for each release while accepting contributions of improvement of the Windows build and ensuring the Windows build will not break in a future version.
[1]: Link of the CI workflow file, Link of latest release build [2]: Link of the CI workflow file, Link of latest release build [3]: Link to the Transmission's choco script [4]: Link to the Inkscape's choco script
@Deluvi From my memory Dino devs explicitly said they want to officially ship Dino through official Windows Store only and that's what's keeping the lags PR from being merged (you may want to double check this with official dino channel).
