Bugzilla – Full Text Bug Listing
| Summary: | [GTK3] Text in Forms abbreviated | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lars Vogel <Lars.Vogel> | ||||||
| Component: | SWT | Assignee: | Alexander Kurtakov <akurtakov> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | akurtakov, arunkumar.thondapu, Lars.Vogel, malaperle, markdigitalchips, markus.kell.r, peter, snjezana.peco, sravankumarl | ||||||
| Version: | 4.5 | ||||||||
| Target Milestone: | 4.6 M4 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| See Also: |
https://git.eclipse.org/r/54397 https://git.eclipse.org/r/60884 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=eec69d54257dd905a06e43fb705f40df9326414e https://bugs.eclipse.org/bugs/show_bug.cgi?id=494565 |
||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 441566, 474628 | ||||||||
| Attachments: |
|
||||||||
|
Description
Lars Vogel
Does it really uses 3.15? 3.15.x are devel versions and should not be used in production. 3.16 is the stable release. (In reply to Alexander Kurtakov from comment #1) > Does it really uses 3.15? 3.15.x are devel versions and should not be used > in production. 3.16 is the stable release. Ups. I was quoting from memory, the real version seems to be 3.14 libgtk-3-0:amd64 3.14.12-0ubuntu2 amd64 GTK+ graphical user interface library ii libgtk-3-bin 3.14.12-0ubuntu2 amd64 rograms for the GTK+ graphical user interface library libgtk-3-common 3.14.12-0ubuntu2 all common files for the GTK+ graphical user interface library Created attachment 253142 [details]
Forms screenshot
Left is still the initial text, on the right side the result if I click on it.
Still the case for Eclipse Mars 4.5. *** Bug 468990 has been marked as a duplicate of this bug. *** This looks like problem with Text widget. On GTK3 the text draw starts one line above the widget boundary and 2 characters on the left side. This happens with Grid layout. Continuing with the investigations Here is the code snippet which is causing this problem OS.gtk_text_buffer_get_iter_at_offset (bufferHandle, position, 0); //get the iterator at 0th location from the text buffer OS.gtk_text_buffer_place_cursor (bufferHandle, position); //place the cursor at the iterator long /*int*/ mark = OS.gtk_text_buffer_get_insert (bufferHandle); //get the insert marker/location of cursor OS.gtk_text_view_scroll_mark_onscreen (handle, mark); //scroll the text view to show the marker - This is the problem in GTK3.14 this gtk_text_view_scroll_mark_onscreen is not working on GTK 3.14(works fine on GTK2). Can someone suggest what could be the problem? New Gerrit change created: https://git.eclipse.org/r/54397 (In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/54397 This change actually fixes this issue. But I am not sure this is the right thing to do. I am looking for opinion on this from Marc-Andre and Alex (In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/54397 It it a question of the layout not allocating enough space for the Text widget? I'm asking that because it could be a problem with the computeSize being cached, a bit like bug 445801. (In reply to Marc-Andre Laperle from comment #10) > (In reply to Eclipse Genie from comment #8) > > New Gerrit change created: https://git.eclipse.org/r/54397 > > It it a question of the layout not allocating enough space for the Text > widget? I'm asking that because it could be a problem with the computeSize > being cached, a bit like bug 445801. I do not think this is the problem with computeSize being cached. the call gtk_text_view_scroll_mark_onscreen is behaving erratically. for the offset of 0 the above call scrills to second line instead of first. and offset >0 it scrolls to last line. Retargetting to M2 since the change is risky (In reply to Sravan Kumar Lakkimsetti from comment #12) > Retargetting to M2 since the change is risky Did you mean 4.5.2 (or 4.6M2)? 4.5 M2 has passed. Oops I meant 4.6 M2 (In reply to Sravan Kumar Lakkimsetti from comment #11) > I do not think this is the problem with computeSize being cached. the call > gtk_text_view_scroll_mark_onscreen is behaving erratically. > > for the offset of 0 the above call scrills to second line instead of first. > and offset >0 it scrolls to last line. Thanks! I think I'll look at the GTK code to see if it's a bug there and if there is a better workaround on the SWT side. To you have a snippet for this by any chance? Created attachment 256168 [details]
Text widget snippet
Please test this in GTK3 and GTK2. in GTK 3 when the widget is made visible the visible text is from the second line. in case of GTK 2 it is first line
(In reply to Marc-Andre Laperle from comment #15) > (In reply to Sravan Kumar Lakkimsetti from comment #11) > > I do not think this is the problem with computeSize being cached. the call > > gtk_text_view_scroll_mark_onscreen is behaving erratically. > > > > for the offset of 0 the above call scrills to second line instead of first. > > and offset >0 it scrolls to last line. > > Thanks! I think I'll look at the GTK code to see if it's a bug there and if > there is a better workaround on the SWT side. To you have a snippet for this > by any chance? Hi Marc-Andre, Did you had any luck with this bug? We are approaching M3. Thanks Sravan (In reply to Sravan Kumar Lakkimsetti from comment #17) > (In reply to Marc-Andre Laperle from comment #15) > > (In reply to Sravan Kumar Lakkimsetti from comment #11) > > > I do not think this is the problem with computeSize being cached. the call > > > gtk_text_view_scroll_mark_onscreen is behaving erratically. > > > > > > for the offset of 0 the above call scrills to second line instead of first. > > > and offset >0 it scrolls to last line. > > > > Thanks! I think I'll look at the GTK code to see if it's a bug there and if > > there is a better workaround on the SWT side. To you have a snippet for this > > by any chance? > > Hi Marc-Andre, > > Did you had any luck with this bug? We are approaching M3. I just started to look at it. One thing about the snippet though, I get the same result with GTK 3.14.12 and GTK 3.10.8 so I'm not sure it's representative of the bug since I only see the bug in the workbench (like the attached screenshot) with GTK 3.14.12. I have bisected the GTK repo and found the first "bad" commit. It sounds quite interesting: commit 9d7f1caca7073cdf4af3bd85b24dbe0209abdde2 Author: Carlos Garnacho <carlosg@gnome.org> Date: Mon Jul 21 21:16:32 2014 +0200 textview: Avoid relocating adjustments on ::size-allocate while these are animating An animation may be scheduled while the textview content changed in size, so the resize queued would just unset the animation and set the adjusments with a current value, defeating gtk_text_view_scroll_to_iter(). In this case, just avoid the adjustment change, as there is a target value on the way. https://bugzilla.gnome.org/show_bug.cgi?id=733406 It looks like animation was added by this commit: https://git.gnome.org/browse/gtk+/commit/?id=6aa851149598961f7e80d204d92f1b4c74783b87 then for a few commits it still "worked" in Eclipse because of https://bugzilla.gnome.org/show_bug.cgi?id=733406, until 9d7f1caca70 was applied a few days later. I'll have to look into this a bit more to understand. Retargetting to M4 as it requires understanding of GTK code as well New Gerrit change created: https://git.eclipse.org/r/60884 Marc-Andre, Sravan, please test my patch/approach. I'm quite confident this approach would be best for us due to the minimal change while still achieving the wanted behavior. Furthermore it gives us some more detailed control if tweaking needed in the future. Gerrit change https://git.eclipse.org/r/60884 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=eec69d54257dd905a06e43fb705f40df9326414e Marking as fixed now. Could this be ported to 4.5.2? I just noticed it while testing 4.5.2RC2. (In reply to Marc-Andre Laperle from comment #25) > Could this be ported to 4.5.2? I just noticed it while testing 4.5.2RC2. It actually too late. We don't have anymore scheduled builds. If there is RC4 scheduled for any other reason we will consider this subject to PMC approval. This change most probably broke automatic scrolling in all touched methods, see bug 494565 comment 2. |