! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Migrate to VTE-3
Status:
RESOLVED: FIXED
Severity:
critical
Product:
Xfce4-terminal
Component:
General

Comments

Description Pablo Lezaeta 2014-09-30 21:19:31 CEST
The near next of vte will drop all support for build vte2 common/shared thing like common files so vte2 thing wil be completelly deprecated (actually vte3 build by default without vte2 common files since vte 3.37.90 [ --enable-gnome-pty-helper]).
So now is imperantive migrate to vte3 or a different solution.

Distros like arch want drop vte2 program in the next 6 months and other will follow soon so is requiered migrate xfce4-terminal for not be droped from distros.

for the one interested this is the thread in arch (maybe you could convince for not drop or get developers): https://lists.archlinux.org/pipermail/arch-dev-public/2014-September/026657.html
[Include info about the vte changes]

Resume of bug: Migrate xfce4-terminal to vte3-oly or to a different thing
Comment 1 Steven Vanden Branden 2014-10-08 18:21:11 CEST
well i guess that we need to port to GTK3 as well then? i already made a port that works out fine, only my layout of the code should be checked.

since vte3 only has a gtk3 widget i guess we do not have many other options ?


the only problem would be , should we make it possible to use gtk2 and gtk3 or require gtk3?
Comment 2 Steven Vanden Branden 2014-10-08 18:30:35 CEST
(In reply to Steven Vanden Branden from comment #1)
> well i guess that we need to port to GTK3 as well then? i already made a
> port that works out fine, only my layout of the code should be checked.

seems like it does not compile good yet, but i see this as an exercise to try it ;) os whats are the tabs width set?
Comment 3 Steven Vanden Branden 2014-10-08 20:42:37 CEST
i compiles for the moment but i needs gtk2 because i need to replace it with vt3 also, ill upload the patch for gtk3 only now ;)
Comment 4 Steven Vanden Branden 2014-10-08 20:49:25 CEST
Created attachment 5678 
patch from master to gtk3 version (without vte3)
Comment 5 Mathias Brodala 2015-01-25 11:50:55 CET
One huge advantage of porting to VT3 is dynamic line wrapping upon window resize.
Comment 6 Steve Dodier-Lazaro editbugs 2015-02-08 20:33:38 CET
Steven, do you have a patch that ports both to vte3 and gtk3 and that is ready for testing? If so let me know!

I'm assigning the bug to you since you seem to be progressing on it.

Thanks.
Comment 7 Steven Vanden Branden 2015-02-09 19:23:00 CET
I did have One but i lost It so i will check this week , i so remember it was not that much work 
Comment 8 Landry Breuil editbugs 2015-02-09 21:05:05 CET
Yes, if you already did the work we'll gladly apply it.

As for comment 1, we dont really "care" if arch wants to drop vte2 support. 

Afaict, vte2 is tied to gtk2 (and vte3 to gtk3), and since xfce4.12 targets gtk2, we _have_ to keep supporting vte2 for now. Providing a build-time option to let the packager decide for vte2 or vte3 would be the best for now...
Comment 9 Egmont Koblinger 2015-03-01 16:09:13 CET
Vte2 is ancient, unmaintained, and unfortunately quite buggy. Vte3 has received hundreds of bugfixes since then.

There were display update fixes (temporarily wrong contents were shown), there were emulation fixes (permanently wrong contents were shown), the data could get permanently corrupted in the scrollback buffer. There were crashes caused by certain escape sequences. Many key sequences were not compatible with other emulators. Cating a large file was painfully slow, it received a >10x speed improvement. The scrollback contents were stored unencrypted on the disk. And there were many, many more similar problems.

And of course it received some cool bonus features, like rewrapping on resize, true colors etc.

Even despite a couple of ceased features (e.g. no more background image support), current Vte3 is significantly better than the Vte2 version.

I understand that unfortunately you can't drop Vte2/Gtk2 for now, but current xfce-terminal already prevents users from getting those tons of Vte fixes from the last 3.5 years, and if 4.14 will again take such a long time then eventually it'll become a 7 year old version.

I just wanted to give a huge +1 for porting to Vte3, supporting by a couple of data points.

> Afaict, vte2 is tied to gtk2 (and vte3 to gtk3)

Correct.

FYI: There was recently a small incompatible API change from vte-0.36 (lib version 2.90, distros usually call the package vte3) to vte-0.38 (lib version 2.91, package name is usually vte2.91 or similar). I recommend going for the newer one straight away. (Minor note: 0.38 dropped the word-char feature but it seems that 0.40 will bring it back.)

There were so many changes since the gtk2 version that you might want to consider maintaining two branches (two tarballs etc.) in parallel rather than one common with ifdefs all over the place.

You might take a look at https://bugs.launchpad.net/terminator/+bug/1030562 [port Terminator from gtk2 to gtk3], I don't know if the patch there will help you or not.
Comment 10 Steve Dodier-Lazaro editbugs 2015-03-01 17:29:00 CET
Hi everyone,

Given the 4.14 roadmap pretty much is "port to GTK+3", and given a port of Terminal:
- would bring in new VTE-3 feature (like 'rewrap on resize' needed for other pending Terminal patches)
- can be released independently from core

I am bumping the priority of this bug to high. If a core or third-party developer is willing to port some GTK+3 app, feel free to redirect them to this report. It's always possible to re-evaluate the priority of this bug once the 4.14 roadmap has been formalised.

Egmont, distributions will be able to use the new Terminal as soon as it is released, surely before 3.5 years from now! Let's given Steven a bit of time to see if he can re-find his initial VTE-3 port, then I'll look to rebasing and testing patches.
Comment 11 Egmont Koblinger 2015-03-01 19:10:26 CET
(In reply to Steve Dodier-Lazaro from comment #10)
> distributions will be able to use the new Terminal as soon as it is
> released, surely before 3.5 years from now!

Sounds great! :)  Let me know if you face any vte-specific trouble, I'm happy to help!
Comment 12 Steven Vanden Branden 2015-03-02 08:30:58 CET
hello all ,

im sorry but i cannot retreive the patch or files for porting totally to vte3 anymore , and i do not know if i can work on it this week but ill do my best , furthermore if anyone else wants to or has time to do the port , everyone is welcome to reassign the bug if needed,

greetings,
steven
Comment 13 Steve Dodier-Lazaro editbugs 2015-03-02 13:56:37 CET
Hey Steven,

No worries, thanks for checking. If you're interested in working on this but are a bit out of time now, no worries. Just let us know if you're convinced you won't have time to do the port in the next few months at all, and then someone else might want to go ahead.

Cheers,
Comment 14 Steven Vanden Branden 2015-03-07 13:05:00 CET
in the next few months i will be able to do the port  probably ;)
Comment 15 minus+xfce 2015-04-01 20:30:01 CEST
I continued from the Gtk3 patch with changes for vte3, nothing working yet however. I'll try to find more time to work on it next week.
https://git.mnus.de/minus/xfce4-terminal/tree/gtk3-vte3
Comment 16 Steven Vanden Branden 2015-04-05 14:45:03 CEST
i will not have the time in the couple of months to do the port so anyone working on it should take the bug if wanted.
Comment 17 Steve Dodier-Lazaro editbugs 2015-04-05 15:42:20 CEST
Thanks for your work so far Steven! Much appreciated!

Minus, should I assign this bug to you?
Comment 18 Steven Vanden Branden 2015-04-14 15:50:21 CEST
for the info , i found this github issue very much similar to what we are trying to do here? so for your info https://github.com/geany/geany/issues/336

there are a few features that have no alternative in the new version (yet),

set_word_chars does not exist,
set_emulation is gone and only xterm is supported,
background_image_file is dropped (no backgrounds possible),

and some more,

should they all be deleted then?
Comment 19 Egmont Koblinger 2015-04-14 15:56:36 CEST
(In reply to Steven Vanden Branden from comment #18)

> set_word_chars does not exist,

It's back in vte-0.40 with a slightly different API; ideally there would be a configure-check, and the option enabled if vte is recent enough.

> set_emulation is gone and only xterm is supported,

Yup.

> background_image_file is dropped (no backgrounds possible),

Yup. Just to clarify: transparency is still available (for compositing WMs, with a new API). The background color needs to contain an alpha channel, and the whole app needs to set an rgba visual (see the unofficial transparency patch in Fedora's or Ubuntu's gnome-terminal packages for an example).
Comment 20 Steven Vanden Branden 2015-04-14 16:37:49 CEST
btw if we port , should we support all versions of gtk3? by detecting the version at runtime? or should we settle with lets say version 3.14?

and how to write code so that it can use fallback functions if neccesary?
Comment 21 Landry Breuil editbugs 2015-04-14 21:35:09 CEST
Fwiw, it has been decided that for 4.14 it was okay for xfce components to depend on gtk 3.14.
Comment 22 minus+xfce 2015-04-30 00:19:39 CEST
I don't have much time to work on this either, but will try to when I can. Feel free to assign it to me, Steve.
The main work remaining is cleanly removing features that are no longer supported (like the background image), fixing (mainly deprecation) warnings and checking the behaviour. (Current state does run https://git.mnus.de/minus/xfce4-terminal/tree/gtk3-vte3)
Comment 23 Egmont Koblinger 2015-04-30 01:18:24 CEST
Looks promising, thanks! :)

Taking a quick look, this is what I found suddenly, running under Unity desktop:

- There's a giant padding both at the right and at the bottom

- Tons of flickers and often shrinks to a very small size on resize

- prints "widget class `TerminalWidget' has no property named `inner-border'" to the stderr; not sure what it is or if it's relevant, but the "-VteTerminal-inner-border" property was renamed to "padding"

- Segfault when quitting a tab via the shell (e.g. Ctrl+D), but not when clicking the X button of the tab

- Segfault when right-clicking on the tab bar

- The prefs window is basically empty (consists of an icon, label, and Help and Close buttons only, Close doing nothing). This might easily be a problem with my installation, though (some component not being registered somewhere). (I just did a ./autogen.sh; make; sudo make install.)

One more thing I forgot to mention so far:

Gnome-terminal gave up with digging into /proc in a highly OS-specific way to figure out the working directory of the current tab (to open the new tab there). You can of course keep this behavior, but it's preferred to use the vte_terminal_get_current_directory_uri() function. This returns the value set via the OSC 7 escape sequence, and typically /etc/profile.d/vte.sh configures your shell to emit this on directory change. That is: the app notifies the terminal explicitly about the directory. This has a couple of advantages, e.g. not OS-specific, any app (e.g. file manager) can decide to set the value, and - if you also set $PWD to this value - keeps symlinks in directory components. You might even decide to do what Ubuntu Vivid made with a patch of theirs to gnome-terminal: fall back to the old method if this API call returns NULL (that is, no OSC 7 was emitted yet).
Comment 24 Steven Vanden Branden 2015-05-29 15:47:07 CEST
> - There's a giant padding both at the right and at the bottom
> 
> - Tons of flickers and often shrinks to a very small size on resize

-- I dont notice this here

> - Segfault when right-clicking on the tab bar
> 
also when middle click:
fixed this in my fork repo of minnus at:

https://git.mnus.de/stevenvdb/xfce4-terminal.git

will request merge with minus
Comment 25 Steven Vanden Branden 2015-05-29 18:58:53 CEST
(In reply to Steven Vanden Branden from comment #24)
> > - There's a giant padding both at the right and at the bottom
> > 
> > - Tons of flickers and often shrinks to a very small size on resize
> 
> -- I dont notice this here
> 
> > - Segfault when right-clicking on the tab bar
> > 
> also when middle click:
> fixed this in my fork repo of minnus at:
> 
> https://git.mnus.de/stevenvdb/xfce4-terminal.git
> 
> will request merge with minus

my bad i think my 'fix' just made sure no mouse commands can be given, not even on the label, the problem lies deeper, double click on label fails too, i think..
Comment 26 Steven Vanden Branden 2015-05-29 20:05:55 CEST
this is the problem for the mouse segfaults

Gtk-CRITICAL **: gtk_widget_get_allocation: assertion 'allocation != NULL' failed
the allocation does not get set right from the widget? 


static gboolean
terminal_window_notebook_event_in_allocation (gint event_x,
				gint event_y, GtkWidget *widget)
{
	GtkAllocation *allocation;
	gtk_widget_get_allocation (widget, allocation);
..,}

anyone a clue?
Comment 27 Egmont Koblinger 2015-11-22 01:07:06 CET
Hi guys,

How is it going? Any news?

One more issue:

Increase vte's padding for debug purposes, e.g. place this in ~/.config/gtk-3.0/gtk.css

VteTerminal {
    padding: 20px;
}

Type a URL and open its right-click menu. The entries to open that URL aren't there, however, they are there if you right-click 20 pixels above it.

Dividing the event coordinate by the cell size doesn't take padding into account, and it also uses the method vte_terminal_match_check() that is obsoleted beginning with vte 0.44 (because with the brand new awesome smooth scrolling feature it doesn't make sense anymore).

vte_terminal_match_check_event() should be used instead.
Comment 28 Egmont Koblinger 2015-11-22 01:14:30 CET
Created attachment 6536 
Use match_check_event
Comment 29 Egmont Koblinger 2015-11-29 22:02:00 CET
Yet another thing: utmp support was removed from vte (https://bugzilla.gnome.org/show_bug.cgi?id=747046).

xfce-terminal should also remove the corresponding code and UI, or implement it using libutempter.
Comment 30 Egmont Koblinger 2016-05-26 20:48:05 CEST
Re background image:

Even though libvte-2.91 (vte tarball >= 0.38) no longer explicitly supports background image, it is possible to work it around with a bit of Gtk+ magic, by drawing behind a transparent (or translucent) vte widget.

See the Terminix project which has already implemented this.
Comment 31 Simon Steinbeiss editbugs 2016-06-01 00:50:27 CEST
Ok, so an update here: in order not to lose any of your work we (Landry and me) decided to push the last version of it to git master.
I also added Egmont's patch on top plus I reworked the settings dialog to get rid of most of the deprecated widgets.

Obviously the Ctrl+D segfault is still there plus there are tons of compile-time deprecation warnings that we'll have to fix.

Anyway, thanks to all of you for your hard work - it's appreciated! If you have time and want to contribute further, please feel free to do so!
Comment 32 Steve Dodier-Lazaro editbugs 2016-06-01 03:23:29 CEST
Created attachment 6685 
Ctrl+D segfault fix

The segfault likely occurs because the handler just prior to the "eof" signal has the wrong signature.

It's likely that this handler is called just before the one for "eof" and some sort of overflow causes the "eof" handler to be called with a NULL second parameter.

The attached patch fixes the segfault for me, but you probably want to test it ;-)
Comment 33 Egmont Koblinger 2016-06-01 08:02:04 CEST
In the mean time someone else also recently started porting xfce4-terminal to vte3. I think the two efforts should be merged. His branch might contain fixes that are not available here yet.

See his work at https://github.com/MidnightCommander/mc/issues/103.
Comment 34 Simon Steinbeiss editbugs 2016-06-01 08:22:15 CEST
Thanks Egmont, I've tried to get in touch.
Comment 35 Derk te Bokkel 2016-06-02 14:36:55 CEST
0.7.0git-a59cf51 version builds fine and mostly works .. noticed that the scroll bars do not work .. frozen at the top .. but shift arrow up and shift arrow down do work .. fyi
Comment 36 poma 2016-06-03 16:28:23 CEST
xfce4-terminal GTK+ 3 port works pretty ok with GTK+ 3.16,
however with GTK+ 3.20 is rather "unpleasant"
Bug 12615

For xfce4-clipman applies just the opposite,
with GTK+ 3.20 works OK, but not with with GTK+ 3.16
Bug 12619

ifdefs, here we go?
Comment 37 poma 2016-06-03 20:00:31 CEST
(In reply to poma from comment #36)
[...]
> For xfce4-clipman applies just the opposite,
> with GTK+ 3.20 works OK, but not with with GTK+ 3.16
> Bug 12619

Pardon me,
corrected conclusion
https://bugzilla.xfce.org/show_bug.cgi?id=12619#c2
Comment 38 Igor editbugs 2016-06-07 14:35:26 CEST
(In reply to Derk te Bokkel from comment #35)
> 0.7.0git-a59cf51 version builds fine and mostly works .. noticed that the
> scroll bars do not work .. frozen at the top .. but shift arrow up and shift
> arrow down do work .. fyi

I've fixed this yesterday. Thanks for the report.

PS I'm that "someone else" also working on the gtk3 port mentioned above :)
Comment 39 Igor editbugs 2016-06-30 09:32:23 CEST
The terminal has been ported to gtk3/vte3, and the current git version is usable and pretty stable.
Please file your migrating-related issues as separate bugs.

Bug #11207

Reported by:
Pablo Lezaeta
Reported on: 2014-09-30
Last modified on: 2016-06-30

People

CC List:
12 users

Version

Attachments

patch from master to gtk3 version (without vte3) (19.04 KB, patch)
2014-10-08 20:49 CEST , Steven Vanden Branden
no flags
Use match_check_event (3.05 KB, patch)
2015-11-22 01:14 CET , Egmont Koblinger
no flags
Ctrl+D segfault fix (1.58 KB, patch)
2016-06-01 03:23 CEST , Steve Dodier-Lazaro
no flags

Additional information