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.
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.
VS 2022 extensions (Windows AND Mac) are now released! Give them a try. https://github.com/picoe/Eto.DevExtensions/releases/tag/2.7.1