|Re: [eclipse-pmc] Eclipse deliverable - food for thoughts|
But if it can be made to work then definitely something to at least use as the *actual tested and supported* mechanism.
----- Original Message -----From: "Max Rydahl Andersen" <manderse@xxxxxxxxxx> To: eclipse-pmc@xxxxxxxxxxx Sent: Thursday, 18 June, 2015 2:38:08 AM Subject: Re: [eclipse-pmc] Eclipse deliverable - food for thoughts On 17 Jun 2015, at 16:48, Aleksandar Kurtakov wrote:The official entry point is https://wiki.gnome.org/Projects/SandboxedApps . But if you want to try it out please read https://blogs.gnome.org/alexl/2015/06/17/testing-rawhide-apps-using-xdg-app/. How does shipping/generating xdg-app sounds in terms of the EclipseIDE?It sounded interesting until it states the app will have limited host processes, network and filesystem access.By default. But in the application metadata access to these can be granted. See https://wiki.gnome.org/Projects/SandboxedApps#Application_metadata .Won't that make the IDE of very little use if I can't easily use my existing projects, debug my java vm's nor access the network ?Using existing projects and network access is supposed to just work assuming correct metadata in eclipse xdg-app. If by debug you mean attacthing to already running external process (not launcher from inside eclipse) this is a bit of a grey area for me still and has to be tried. Such limitations and especially how eclipse plugins can request additional permissions as some of them would need is something we will never get the answer of if we don't try.And beyond that what does this feature provide Eclipse ? will it beeasier to install ? run on more distributions without having differentSWT bugs dependent on the host OS or ?Exactly, this should give eclipse the possibility to say e.g "runtime=org.gnome.Platform/x86_64/3.16" and have a single set of GTK/Glib/Webkit/... versions to test with no matter what the distribution is. And when projects like Gnome start shipping/creating the runtime themself there runtime should be identical (thus the bugs too) on Fedora/Suse/Ubuntu/Mint..... This is the kind of problem I'm looking for a solution for as currently there is one set of problems on latest Fedora, different on latest-1 Fedora, entirely different on latest Ubuntu and so on. With runtime definition like org.gnome.Platform/$ARCH/$VERSION Eclipse will have the freedom to jump to newer GTK version when ready not urging like now because users start getting new version on their machines. This should also free some resources as currently SWT tries to support 13 different Gtk versions with workarounds for many of them which is not feasible solution and this creates even more bugs when old workarounds s!tart to i nterfere with newer versions workflow. Alexander Kurtakov Red Hat Eclipse team/maxLet's discuss either here or on the call for anything that comes to your mind. Alexander Kurtakov Red Hat Eclipse team _______________________________________________ eclipse-pmc mailing list eclipse-pmc@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/eclipse-pmc/max http://about.me/maxandersen _______________________________________________ eclipse-pmc mailing list eclipse-pmc@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe fromthis list, visit https://dev.eclipse.org/mailman/listinfo/eclipse-pmc_______________________________________________ eclipse-pmc mailing list eclipse-pmc@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top