Move FormattedText from incubation to release

chrhem commented 1 year ago

Would it be possible to release FormattedText officially? We have been using it in a commercial application since 2008 and have not had any problems with it.

Just because it is still in incubation, we mirror the incubation update site to achieve a stable build process.

I could make a PR for moving it into release.

@vogella

vogella commented 1 year ago

@lcaron @wimjongman WDYT?

lcaron commented 1 year ago

I've no problem with that, if it fits your requirement.

@chrhem I'll be happy if you provide a patch. If you need help feel free to ask !

wimjongman commented 1 year ago

+1

vogella commented 1 year ago

Btw. why do we not move all incubator widgets to the regular build and adjust their manifest so that these widgets are listed as provitional API? This way the build could be simplified and the consumer of the non-released API could still see that the widget is not officially release.

wimjongman commented 1 year ago

Because the incubator widgets have no maintainers, some of them are alpha, so it will cause more stress for the team.

vogella commented 1 year ago

Because the incubator widgets have no maintainers, some of them are alpha, so it will cause more stress for the team.

+1

lcaron commented 1 year ago

Because the incubator widgets have no maintainers, some of them are alpha, so it will cause more stress for the team.

+++1

marcolopes commented 1 year ago

Hi! Been using FormattedText since 2008 also!!

The only need i had was to extend FormattedText and implement a "dispose" method to "detach" the formatter and remove the listeners (so the TEXT could be used on another FormattedText without disposing it)

and there is a small bug with IntegerFormatter since the first versions (also present in the latest 3.0.0 release) that causes this stacktrace when "deleting" the LAST CHAR of the TEXT

java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1875) at org.eclipse.jface.internal.databinding.swt.SWTVetoableValueDecorator$1.handleEvent(SWTVetoableValueDecorator.java:38) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062) at org.eclipse.swt.widgets.Text.verifyText(Text.java:2430) at org.eclipse.swt.widgets.Text.sendKeyEvent(Text.java:1794) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1521) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640) at org.eclipse.swt.widgets.Text.WM_CHAR(Text.java:2584) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4528) at org.eclipse.swt.widgets.Text.windowProc(Text.java:2570) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4976) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.projectocolibri.rcp.Application.start(Application.java:40) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

From: chrhem @. Subject: [eclipse/nebula] Move FormattedText from incubation to release (Issue #515) Date: Tuesday, May 23, 2023 at 11:26 To: eclipse/nebula @.> Cc: Subscribed @.***>

Would it be possible to release FormattedText officially? We have been using it in a commercial application since 2008 and have not had any problems with it.

Just because it is still in incubation, we mirror the incubation update site to achieve a stable build process.

I could make a PR for moving it into release.

@vogella https://github.com/vogella

— Reply to this email directly, view it on GitHub https://github.com/eclipse/nebula/issues/515, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJOEMYL6O4I7WS5T4NJKLXHSGFXANCNFSM6AAAAAAYLVQOKE. You are receiving this because you are subscribed to this thread.Message ID: @.***>

wimjongman commented 1 year ago

Bom dia, Marco! Can you create a PR for the issues you mention?

marcolopes commented 1 year ago

I will try do do that.

Also:

1) The source formatting is not consistent... and it's very ugly in the FormattedText and NumberFormatter! (a mix of SPACE indentation, TAB indentation... etc etc). I am now revising all the latest classes to include them in my repo... :\

2) I personally hate java 8 Lambda Expressions! Just hate them! I notice that nebula is using them more and more, and when adopting code i have a huge trouble removing them, so i am not up to date to the latest versions because of that (i also keep the codebase JAVA 7 compatible)

From: Wim Jongman @. Subject: [eclipse/nebula] Move FormattedText from incubation to release (Issue #515) Date: Tuesday, May 23, 2023 at 21:16 To: eclipse/nebula @.> Cc: Marco Lopes @.>, Comment @.>

Bom dia, Marco! Can you create a PR for the issues you mention?

— Reply to this email directly, view it on GitHub https://github.com/eclipse/nebula/issues/515#issuecomment-1560066355, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJOEN3DACV4MVMG2DFGKLXHULLHANCNFSM6AAAAAAYLVQOKE. You are receiving this because you commented.Message ID: @.***>

wimjongman commented 1 year ago

Yes, we have to move with the times. In some cases, it will seem worse. I have gotten used to Lambdas. I try not to use huge inline lambdas, but for some cases, notably (SWT) listeners, they are great.

marcolopes commented 1 year ago

Well, i'm still "attached" to Eclipse 3.8,because eclipse 4 broke all the compatibility with RCP components (and we have a many apps that rely on the behavior on the 3.8 code - yes, i tried to upgrade many times, but we have total control of workbench perspectives and that was completely broke on Eclipse 4). Eclipse 3.8 is bound to Java 7 (i would not mind using Java 8, mainly because of the streams API, but, it's not a major issue). The issue is that we cannot move on to the latest Java 8 and above code because of eclipse.

From: Wim Jongman @. Subject: [eclipse/nebula] Move FormattedText from incubation to release (Issue #515) Date: Tuesday, May 23, 2023 at 21:50 To: eclipse/nebula @.> Cc: Marco Lopes @.>, Comment @.>

Yes, we have to move with the times. In some cases, it will seem worse. I have gotten used to Lambdas. I try not to use huge inline lambdas, but for some cases, notably (SWT) listeners, they are great.

— Reply to this email directly, view it on GitHub https://github.com/eclipse/nebula/issues/515#issuecomment-1560106644, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJOEO7UDUJSW5KQEKQDM3XHUPIFANCNFSM6AAAAAAYLVQOKE. You are receiving this because you commented.Message ID: @.***>

vogella commented 1 year ago

1) The source formatting is not consistent...

@marcolopes it should be fine to create a PR to allign the formating of the source code. I did run a "format source" in platform on a lot of files to make them consistent. @wimjongman @lcaron is Nebula supposed to use the Eclipse formatter?

wimjongman commented 1 year ago

Yes, historically, there are no specific formatting rules since most widgets were contributed by individuals. It would be nice to have someone format the source code. However, this would also include cleanups like loop conversion and lambda conversion to get Nebula to Java 11 or 17.

lcaron commented 1 year ago

@vogella I think that there is no formatting rule. We should use the Eclipse Formatter so the source formatting will be consistent and it will simplify the integration of new request.

@marcolopes Can you please create a PR with a "clean" source formatting first. The second PR will contain the fix, without any "dummy" differences. Thanks

PS : @wimjongman I just received your message :) I will handle this.

wimjongman commented 1 year ago

Verified! Thanks for the work. Keep patches coming.

eclipse / nebula

Move FormattedText from incubation to release #515

2) I personally hate java 8 Lambda Expressions! Just hate them! I notice that nebula is using them more and more, and when adopting code i have a huge trouble removing them, so i am not up to date to the latest versions because of that (i also keep the codebase JAVA 7 compatible)