On Wed, Feb 28, 2018 at 10:00 PM, Andrey Loskutov <[email protected]> wrote:
> Get rid of GTK3 and the errirs will disappear :) > I don't know if there is a solution except fixing GTK3 or porting Eclipse > to something less buggy. > And your proposal is to use what? And I would assume that whoever proposes it provides the resources to make it reality too :P . I can't wait for someone to start the work and relief me and my team from SWT work! Please do it now! ASAP! I find such writings not only out of reality but also totally ignorant and disrespectful to the work done by various people on SWT. > GTK3 seem to create more and more errors with every new version. If you do > not use the default GTK+ theme, even more. Anyone thought that this is GTK 3.x becoming stricter and more predictable and pointing actual errors in the themes? Is it Eclipse Platform fault that buggy plugin slows the workbench because doing things in UI thread or brings down the whole JVM ? Yes there are tons of broken GTK+ themes and Eclipse plugins but the fault for these doesn't lay in the foundations they are built upon. What is the proposal here ? Reduce extensibility to disallow plugins/themes to misbehave? BTW, the exact GLib-CRITICAL Lars sees is one coming from the GTK theme not by GTK itself (g_base64_encode_step is not called in SWT directly nor reproducible with default GTK theme) but it is so convenient to blame GTK itself, right? > After transition to Eclipse 4 (and so GTK3) in our product we spend right > now most of our time in fixing various SWT regressions. And my team spent a lot of hours in actually fixing the things you found despite the tone we receive in public. Is there problems? Sure, there are and there will always be. Is there improvement? Yes, there is and improvements are ongoing. There is this group of people constantly complaining of latest demanding support for both oldest and newest and blaming people actually working on it . Well, it's time to face it - this large set of supported versions is a compromise and (not so small) part of the issues seen is because of this. A general recommendation - if you want an issue fixed see how it should be reported first in https://bugs.eclipse.org/bugs/show_bug.cgi?id=479646 . After that bugs are looked in strong order: * Crashers * Support for new versions * Mis-drawings * Console warnings This order can be influenced when some of the lower priority ones are just noticed when investigating smth else like this one. And obviously it was a single line fix that simply no one found time to look into proper. So doing the fix was not smth I don't expect any committer to be able to do after some debugging instead of spending time on hiding errors and etc. > For this concrete issue we simply start Eclipse from a shell script which > redirects standard error to a file, so that our customers aren't scared by > permanent "critical error" or "critical bug" flood. For debugging Eclipse > from Eclipse I have no solution except to redirect std.error to a file from > your own code inside Eclipse. This will however hide the rest of std.error > too :). > > Am 28. Februar 2018 20:47:04 MEZ schrieb Lars Vogel < > [email protected]>: > >Friends of SWT, > > > >is anyone aware of a Linux or GTK or SWT trick to remove the annoying > >GLib-CRITICAL messages? > > > >(Eclipse:14679): GLib-CRITICAL **: g_base64_encode_step: assertion 'in > >!= NULL' failed > > > >It makes Console output almost useful, as it is super hard to see if > >(I have to scroll a lot to find the relevant stuff). Screenshot of my > >current user experience attached. > > > >Best regards, Lars > > -- > Kind regards, > Andrey Loskutov > > http://google.com/+AndreyLoskutov > _______________________________________________ > platform-swt-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/platform-swt-dev > -- Alexander Kurtakov Red Hat Eclipse Team
_______________________________________________ platform-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/platform-dev
