-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically select first created CTabItem in a CTabFolder #46
Automatically select first created CTabItem in a CTabFolder #46
Comments
Thanks for the SWT test snippet. |
It was with a custom view in our own product. What I meant by "Eclipse IDE" was that is was not in a snippet or similar simple application. Sorry for the bad wording! |
I have investigated this issue further and by adding the below line, one can make 1st CTabItem become selected from user program. But the concern here is by default it should be selected without this line in user program in comparison with behavior of TabItem, so got this working with proposed change in my new pr #1044 Please share me any inputs if there might be any problems with this fix? |
@deepika-u TabFolder content looks right now, but need to improve on below:
|
Reverted fix due to failures in platform ui (eclipse-platform/eclipse.platform#1239 and https://github.com/eclipse-platform/eclipse.platform/issues/1736). |
checking on them, able to recreate 1736. Checking further. |
@deepika-u, |
I'm not sure the failures are maybe just wrong assumptions, and this PR changes the assumption. e.g. the one failing (other link give 404 error for me) it says it |
Indeed it might well be the case that the test needs to change its assumption. |
When my swt pr #1044 is in place, for the eclipse.platform.ui issue #1736 reported error. When i select this "MultiVariablePageTest.java" file's testContextActivation and run as "JUnit Plug-in Test" failing case: passing case: I then tried running the complete file "MultiVariablePageTest.java" as "JUnit Plug-in Test", all the 9 tests passed. I hope i am doing the right fix. Please confirm. |
@deepika-u : there are two different test cases failing:
What you should do is (for each test failing)
|
As a first step, eclipse-platform/eclipse.platform.ui#1736 I have further investigated and i see that this block of code needs a change. Originally the code around these lines are
Without my #1044 change, there is no CTabItem selected, so getActivePage() returns -1 as a result the above block of code gets executed(activeServiceLocator.activate() is being called). With my #1044 pr, there is already CTabItem[0] being activated as default page. So getActivePage() returns zero as a result the block is never executed(activeServiceLocator.activate() is being never called). On further investigation, this can be updated as below to accommodate my pr.
Is it ok to fix it in By the way now the UI test case is passing. I am yet to investigate on other failure(#1239). |
I have further investigated on eclipse-platform/eclipse.platform#1239 Before the SWT fix there is no tab active, so previousTabIndex has value "-1", fCurrentTabIndex will have zero when first tab needs to be activated. As a result the if condition at line 1458 fails and propagateTabActivation() is called. Now after the SWT fix, first tab is activated by default(it means selectedIndex is zero). So previousTabIndex and fCurrentTabIndex both are having zero value. As a result the if condition at 1458 returns true and it returns from there without calling propagateTabActivation(). So first tab is not getting activated via the test case, so test case fails. It means the test case assumes no tab is active so previousTabIndex and fCurrentTabIndex are never equal. Now that assumption is not valid anymore so the if condition at 1458 needs to be corrected in such a way that it fails and proceeds to call propagateTabActivation() which activates the first tab via the test case.
to
|
Add some tests to check that no unnecessary de/activation of tabs is happening and add some assertions to existing tests too. These improvements are necessary in order to guarantee that fixing eclipse-platform/eclipse.platform.swt#46 do not change the existing behavior of LaunchConfigurationTabGroupViewer. Contributes to eclipse-platform#859 Contributes to eclipse-platform/eclipse.platform.swt#46
Add some tests to check that no unnecessary de/activation of tabs is happening and add some assertions to existing tests too. These improvements are necessary in order to guarantee that fixing eclipse-platform/eclipse.platform.swt#46 do not change the existing behavior of LaunchConfigurationTabGroupViewer. Contributes to eclipse-platform#859 Contributes to eclipse-platform/eclipse.platform.swt#46
Add some tests to check that no unnecessary de/activation of tabs is happening and add some assertions to existing tests too. These improvements are necessary in order to guarantee that fixing eclipse-platform/eclipse.platform.swt#46 do not change the existing behavior of LaunchConfigurationTabGroupViewer. Contributes to #859 Contributes to eclipse-platform/eclipse.platform.swt#46
Verified this issue and works as expected on below build. Eclipse SDK |
#1164 introduces regression for clients.
Since that affects existing client code, it seem to be a breaking change. |
Another multipage editor that doesn't work is target file editor. Open any .target file in the IDE and "enjoy the silence". |
Note: 4.32 M3 contribution is planned for May 17 (this Friday) with the nightly build from the day before, so ideally the fix should be developed & merged before May 16. |
This reverts commit 49c04a7 because it introduces regressions in client code. See eclipse-platform#46 (comment)
@deepika-u : I plan to merge #1227 on this Thursday for 4.32 M3. |
Hi @iloveeclipse , Looks like this widget behavior of defaulting the index to -1(old behavior) is being used by lot of clients. When this behavior is -1 they are doing some additional initialization part. Now since that index is no more -1 and becoming zero that additional initialization is missing and that is causing the issue. So looks like they are basically dependent on the original behavior. Right now we have fixed platform issue with #1298(eclipse-platform/eclipse.platform#1298) and UI with #1346(eclipse-platform/eclipse.platform#1346). Even if we fix GIT client and once the product is released, we might get lot of other clients(users using cTabFolder widget) who may also report multiple failures in the silimar lines. Though we have tried to make consistent behavior between tabFolder(here the default index is zero) and cTabFolder(here the default index is -1), looks like this is indirectly changing the existing behavior which may not be acceptable. Later if it is really needed to be fixed, we might have to come with approach like providing a flag option provided to customer whether to work like old behavior or behave like new behavior and then proceed accordingly. @fedejeanne : If this pr #1164 (#1164) is reverted, can the other 2 prs exist or do they also need to be reverted(#1298 and #1346). Can you please confirm? Once fedejeanne confirms, then i think we can go ahead with merge of #1227(revert of #1164). |
@deepika-u thank you for the analysis. I made a quick analysis myself and reached the same conclusion: if the expected default behavior is changed then the client code needs to be changed too. I even tried making some changes in the superclasses of the involved editors but I saw that those changes may trigger a "double activation" in some (client) editors. Long story short: I couldn't find a solution for the current problem 👎
No need to revert eclipse-platform/eclipse.platform#1298 or eclipse-platform/eclipse.platform#1346, they work with or without #1164 ✔️ @iloveeclipse go ahead with #1227 🚀 |
This reverts commit 49c04a7 because it introduces regressions in client code. See #46 (comment)
Done. Thanks for looking into. |
I originally reported this on https://bugs.eclipse.org/bugs/show_bug.cgi?id=579665, but then I got the information that you likely check github issues more often than the bugzilla entries. Feel free to close either one as a duplicate...
After creating one or several o.e.swt.custom.CTabItem for a o.e.swt.custom.CTabFolder, no tab will be selected by default and thus, the content will be "blank". This is a difference to the behavior of o.e.swt.widget.TabFolder where the first created o.e.swt.widget.TabItem will be selected by default.
Is there any reason why the first CTabItem is not selected by default?
The user of the class can still override if needed...
The below snippet is based on Snippet76.java:
This is how it will be rendered on Windows 10:
The problem does not appear if "Shell#setSize(int,int)" is replaced by "Shell#pack()".
I first saw the issue in a view inside the Eclipse IDE, so I suppose it's the setSize variant that is generally used there and not the pack variant.
The text was updated successfully, but these errors were encountered: