Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Eclipse Installer makes first hand experience on Linux worse


----- Original Message -----
> From: "Ed Merks" <ed.merks@xxxxxxxxx>
> To: cross-project-issues-dev@xxxxxxxxxxx
> Sent: Monday, 4 July, 2016 6:02:27 PM
> Subject: Re: [cross-project-issues-dev] Eclipse Installer makes first hand experience on Linux worse
> 
> Comments below.
> 
> 
> On 04.07.2016 10:43, Aleksandar Kurtakov wrote:
> > Hi everyone,
> >
> > Oomph runs with GTK2 by default and when you install and run your ide with
> > it (the very first time) the env variables are inherited thus in the very
> > first run users of Neon will see something broken [1] on recent Linux
> > distro (Fedora 24) and that's pretty bad initial experience.
> Yes, we noticed that.  Though often it was reported that (on Ubuntu) the
> launched IDE works only when launched by the installer.  So that problem
> is the opposite one.  On the ide-dev mailing list I suggested that
> perhaps which GTK version could be controlled by the installer:
> 
>    http://dev.eclipse.org/mhonarc/lists/ide-dev/msg01223.html

I missed that mail, would have replied if I have read it.
For the record, using GTK2 or GTK3 has a number of implications (incl swt browser widget, available *.so files in the system and etc.) thus can't be properly controlled by the installer unless the installer replicates all the SWT logic of trying to dlopen needed *.so files, call their respective functions to get the versions, check them for compatibility and react on changes in SWT to get in sync. That I think would be an overkill.
Where I think we as a community fail is trying to support too much - we should be way more restrictive and get to the narrower subset of platforms we support and really do that. The current huge range of "supported" versions really means we are acting in "hope it works" world.

> >   It is really disturbing that installer/Oomph overrides defaults and
> >   decides that it knows better what is on the user machine better than SWT
> >   managed to find on the user machine.
> It was not an intended design point, but accidental in how the
> environment is inherited by the child process.   We could certainly look
> into address that concern.
> > Upon restart of the IDE (when installer/oomph no longer defines env
> > variables) user will see the proper page [2] but the initial experience
> > would be already ruined and we might have lost the chance this user would
> > ever start it again.
> Yes, that seems not ideal.
> > Not to mention that webkitgtk (gtk2 version) is no longer installed by
> > default on latest Ubuntu/Fedora (AFAIK) unless one explicitly installs it
> > or had installed some other application that explicitly requires it. This
> > essentially breaking the Internal web browser [3], making Help center
> > opening in browser tab instead of its own applications and probably
> > others.
> The whole thing appears to be a bit of a disaster area.  Always bugs
> that happen only on Linux, that are different depending on which Linux
> and which GTK.   So this is a systemic problem.  We'd be more than happy
> if SWT just worked well in all cases, but it doesn't.

I see two options to improve the situation - either more people start contributing (I wish it) or reduce "supported" versions range and make it clear to users that the given version is not suppoted (most likely the thing to be done).

> > I understand this is just the first start but this is the most important
> > run if we want to grow the user base. Doing such changes without deeply
> > understanding the possible variations and how/when decisions are taken
> > generates too much bad mouth and ruins so much effort spent that I would
> > describe it as unacceptable.
> I noticed that when I posted to ide-dev with suggestions for how we
> might address this issue, there was no response.
> > I sincerely ask the Oomph project/installer to reconsider these practices.
> It seems to me that the GTK problem isn't so easily solved and while GTK
> 3 will make some happy, for others it will be broken, and vice versa.
> So I'm not sure there's a well established best practice. And in the
> end, there are two problem for us.  What should the installer itself
> use? 

Looking at the bug report which caused this, there is probably way simpler workaround than changing the Gtk version - "refresh"like call after creation of the window. Verified by replacing with Neon swt that content shows after search.
Please point me to the Oomph code and I'll try to come up with patch. And Oomph should rely on SWT introspection.

> What should the installation use?  

Installation should use whatever SWT manages to find on the system - period. World around us is changing at faster and faster pace not only GTK2 vs GTK3 but also WEBKIT1 vs WEBKIT2 would have to be dynamically decided for Oxygen, who knows what else may change by release time. With that pace of change - whatever one decides to hardcode - it will be always wrong for one or another group. Only viable solution is dynamically introspecting system versions and try to make use of them when we can.

> In both cases, how do we know
> either decision is a good one across all Linux variant?

Replied with previous paragraph actually.

> 
> In any case, it would definitely be best if the launched IDE didn't
> inherit the installer's choice.  I'm not sure the current
> mechanism/issue that makes it inherit the choice.
> 
> I'd suggest you open a Bugzilla to track this issue.

Here you are. https://bugs.eclipse.org/bugs/show_bug.cgi?id=497250

> >
> >
> > [1] https://akurtakov.fedorapeople.org/broken.png
> > [2] https://akurtakov.fedorapeople.org/proper.png
> > [3] https://akurtakov.fedorapeople.org/broken_browser.png
> >
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 

-- 
Alexander Kurtakov
Red Hat Eclipse team


Back to the top