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
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?
(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?
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 ;)
Created attachment 5678
patch from master to gtk3 version (without vte3)
One huge advantage of porting to VT3 is dynamic line wrapping upon window resize.
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.
I did have One but i lost It so i will check this week , i so remember it was not that much work
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...
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)
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.
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.
(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!
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,
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.
in the next few months i will be able to do the port probably ;)
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.
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.
Thanks for your work so far Steven! Much appreciated!
Minus, should I assign this bug to you?
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?
(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,
> 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).
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?
Fwiw, it has been decided that for 4.14 it was okay for xfce components to depend on gtk 3.14.
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)
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).
> - 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:
will request merge with minus
(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:
> 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..
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?
terminal_window_notebook_event_in_allocation (gint event_x,
gint event_y, GtkWidget *widget)
gtk_widget_get_allocation (widget, allocation);
anyone a clue?
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
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.
Created attachment 6536
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.
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.
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!
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 ;-)
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.
Thanks Egmont, I've tried to get in touch.
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
xfce4-terminal GTK+ 3 port works pretty ok with GTK+ 3.16,
however with GTK+ 3.20 is rather "unpleasant"
For xfce4-clipman applies just the opposite,
with GTK+ 3.20 works OK, but not with with GTK+ 3.16
ifdefs, here we go?
(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
(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 :)
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.