Is it possible to make some runtime dependencies on linux (e.g webkit if you use it, libappindicator etc.) Optional and to not cause a runtime crash?
It would make a few things more convenient, e.g newer Debian which changed the appindicator file would still be able to run the application, just not with all bells and whistles.
It would make a few things more convenient, e.g newer Debian which changed the appindicator file would still be able to run the application, just not with all bells and whistles.
:point_up: Edit: Is it possible to make some runtime dependencies on linux/gtk (e.g webkit if you use it, libappindicator etc.) Optional and to not cause a runtime crash?
It would make a few things more convenient, e.g newer Debian which changed the appindicator file would still be able to run the application, just not with all bells and whistles.
It would make a few things more convenient, e.g newer Debian which changed the appindicator file would still be able to run the application, just not with all bells and whistles.
We could add some detection so it doesn't add the WebViewHandler if the dependencies don't exist, so you could do something like
if (Platform.Supports<WebView>() { /* now it's safe to use WebView */ }
I just encountered that while working on some flatpak related stuff.
Did you already do any work in that department? Would like to make a possible template public for Eto programs.
Did you already do any work in that department? Would like to make a possible template public for Eto programs.
Same for the
LinuxTrayIndicatorHandler
Sorry my bad, I completely misphrased what I meant <-<
The second line was regarding whether any flatpak related stuff for Eto was done yet. In case you're not familar with them, they're a distribution mechanism for linux programs.
The second line was regarding whether any flatpak related stuff for Eto was done yet. In case you're not familar with them, they're a distribution mechanism for linux programs.
If they were trying to make sandboxing very complicated, they certainly solved that problem.
That's because Linux as a whole is complicated :)
They wanted to create a sandboxing environment which supports:
They wanted to create a sandboxing environment which supports:
- GNU stuff (i.e. glibc and their coreutils)
- non-GNU stuff (i.e. musl and busybox or other stuff)
- All kinds of init systems (i.e., systemD, runnit, openRC etc.)
- Different display protocols (i.e. X11, Wayland and any potential future ones)
- Needs proper definitions in which programs and parts of the filesystem it needs to be able to access and which not
- Needs to properly be able to invoke filepickers and such, while being sandboxed (as usually those lie outside of the sandbox)
- Needs to properly communicate with the different DEs (to know which filepicker it needs to invoke)
And probably a whole bunch of more stuff.
Oh, something that could help a bit more for that, are there any public binaries for the test suite, or do I need to self-compile?
My current test application runs fine as of right now, but it'd be a good idea to have that tested against something something that uses all features of Eto, rather than only a few
You can get all the test app binaries from the actions, such as this one for 2.7.0: https://github.com/picoe/Eto/actions/runs/2285279754#artifacts
I got a bit distracted by the testing application; it seems that a few things are broken on either GTK+Linux or Wayland.
Stuff that doesn't work (correctly), some exceptions the program catches, and some exceptions that crash the program outright.
Should I test those later on a more recent commit and submit issues for them?
As examples; the icon doesn't get displayed in either title or taskbar, the datepicker instantly closes, the "bitmap" thing produces an exception, a lot of stuff that uses the GTK/GNOME dialogs instead of current DE's, and something else related to child windows that straight up crashed the program.
(Also all non-flatpak related, this is all natively)
(Also all non-flatpak related, this is all natively)
See picoe/Eto#2115
Kde always showed them fine
afaik
To be specific it shows a program icon in both locations; which is the default Wayland icon.
Could investigate more tomorrow what exactly causes those kinds of bugs and then raise issues for them.
Datepicker not working for example is somewhat bad
Datepicker not working for example is somewhat bad
Eto doesn't reference that nuget package (directly) so I'm not sure where that would come from..
I'm still poking it to see if I can find a sequence of operations that might side-step it. It's very odd.
What version are you upgrading from? 2.7.0?
afaik.