[gtk3] 1.9.0 can not be compiled with vte-2.91 api #66

Closed
tarakbumba opened this Issue Jul 4, 2014 · 37 comments

Projects

None yet

7 participants

@tarakbumba

On Mageia Cauldron install; i'm unable to compile mate-terminal-1.9.0 using "--with-gtk=3.0" configure option with vte-2.91 api. Our system provides vte-2.91 api and i must use that for proper packaging. I tried to create a patch from gnome-terminal changes but unable to do so, because lack of coding skills. This issue should be fixed before 1.10 release i think.

@infirit infirit added the unconfirmed label Jul 4, 2014
@infirit
Contributor
infirit commented Jul 4, 2014

No build log.. No other info..

@tarakbumba

I' ll add build log tomorrow.

@infirit infirit added this to the 1.10 milestone Jul 5, 2014
@infirit
Contributor
infirit commented Jul 5, 2014

So this morning I decided to have a look at the gnome-terminal git log and my eyes started to hurt 😿.
https://git.gnome.org/browse/gnome-terminal/log/?qt=grep&q=vte

@NiceandGently this will hit you in rawhide most likely soon. gnome-terminal requires it for version 3.13.

@raveit65
Member
raveit65 commented Jul 5, 2014

currently 1.9.0 release builds fine in fedora rawhide with GTK3.
vte3 version is vte3-devel-0.36.3-1.fc21.x86_64.

@stefano-k
Member

Sadly in documentation there is nothing about API breakages
https://developer.gnome.org/vte/unstable/

@tarakbumba

Sorry for the late response. Due to a breakage on Cauldron development platform, i only now can provide the output: http://pastebin.com/raw.php?i=cfrVcC7f

I have patched configure script to accept vte-2.91 pkgconfig but still get errors.

@stefano-k stefano-k changed the title from mate-terminal-1.9.0 can not be compiled with vte-2.91 api to [gtk3] 1.9.0 can not be compiled with vte-2.91 api Oct 2, 2014
@infirit infirit modified the milestone: Gtk+3, 1.10 Nov 19, 2014
@anatol
anatol commented Sep 21, 2015

I am an Arch developer who would like to see a few remaining Arch packages moved off vte 2.90.

What is the current status of this issue? Do you plan to update mate-terminal to newer vte version?

@egmontkob

API changes between 2.90 and 2.91, off the top of my head:

  • wordchars support was removed in 0.38 (the first stable series with lib version 2.91), but brought back (with a different API) in 0.40
  • setting the emulation type was dropped, there's only one hardcoded behavior
  • forking a child process has a new API: vte_terminal_spawn_sync
  • color handling APIs changed: instead of GdkColor* or GdkRGBA* (two parallel methods for each functionality) they now take a PangoColor*
  • background image support is dropped
  • transparency is done by setting a background color with an alpha channel. It's also needed to set an argb visual for the app, and to use a compositing wm
  • a few trivial minor changes in some method taking yet another new argument

None of these are a big deal, I wouldn't think porting would take more than about an hour or so.

The only regression is probably the lack of background image support. On the other hand, there were hundreds of small (and some bigger) bugfixes and improvements worth upgrading for, and new ones are continuously added. Lib version 2.90 (vte-0.36.5 being the latest release) probably won't be maintained any more, unless we find some critical bug.

Probably the biggest improvement in the 2.91 series was that the scrollback buffer is no longer stored on disk as clear text, instead it's compressed and encrypted. There were many-many other smaller ones as well.

@willysr
willysr commented Nov 9, 2015

Thanks for the heads-up. I'm also stumbled into this bug when trying to test GTK+3 build for Slackware. I will use 0.36.5 for now until this issue is resolved.

@raveit65
Member

The main prob with using gtk3 build in fedora is that vte291 ships a different
/etc/profiles.d/vte.sh
Here the command prompt is changed:

__vte_prompt_command() {
  local command=$(HISTTIMEFORMAT= history 1 | sed 's/^ *[0-9]\+ *//')
  command="${command//;/ }"
  local pwd='~'
  [ "$PWD" != "$HOME" ] && pwd=${PWD/#$HOME\//\~\/}
  printf "\033]777;notify;Command completed;%s\007\033]0;%s@%s:%s\007%s" "${command}" "${USER}" "${HOSTNAME%%.*}" "${pwd}" "$(__vte_osc7)"
}

notify;Command completed is a new feature in gnome-panel.
If you're using a command which takes a longer time, than you will noticed about finishing via a notification.
Unfortunately, this new vte.sh breaks the command promt from mate-terminal (gtk3).
I bet it is only a question of time if other distros will follow fedora's vte/gnome devs.
To implement this feature a port to vte291 is needed.

@egmontkob

Command completion notification is a Fedora patch, not part of mainstream vte/gnome-terminal.

@egmontkob

That being said, it sounds reasonable that libvte-2.90 sourcing vte.sh shipped by Fedora's modified vte-2.91 leads to that broken result. And yes, updating mate-terminal to use libvte-2.91 would make this problem disappear.

There are a gazillion of problems with the said patch, which Fedora developers were notified about in https://bugzilla.gnome.org/show_bug.cgi?id=711059. One of them is checking on the wrong VTE_VERSION.

@raveit65
Member

yes, i know that 'Command completion notification' is currently fedora only.
But i have to live with it. gnome-terminal is the only gtk3 terminal in official fedora.
I ship mate-terminal (gtk3) only in a fedora copr repo, which is a stage area where fedora devs can try out something.
So i've no arguments against their plans.
I'm wondering that it isn't possible to edit vte.sh for supporting both vte versions.

Edit:
mate-terminal depends on mate-desktop too, means not updating m-t to gtk3 breaks the whole transition to gtk3.

@egmontkob

You can edit vte.sh (branch on VTE_VERSION being >= 3800 or so). If you're not root, or afraid of being overwritten by an upgrade, just add your stuff to your .bashrc.

There's nothing mate-desktop developers could do about it, apart from upgrading to vte-2.91.

@raveit65
Member

Btw. i wanna say that we're not against to port m-t to vte291,
but we're a small team and we're are a bit overload.
So if someone can help out and have some free time......patches are welcome.

@raveit65
Member

You can edit vte.sh (branch on VTE_VERSION being >= 3800 or so). If you're not root, or afraid of being overwritten by an upgrade, just add your stuff to your .bashrc.

thx, i will try this out......but i'm looking for a solution for a pull request to vte291 in fedora.
....maybe this works. :)

@egmontkob

I tried porting your code, but I'm on Wily and mate still uses gtk2, so it's kinda hopeless without recompiling the entire stack. I did this porting and it took about half an hour or even less with Terminator. If you trust me and give me ssh access to a machine with the necessary mate and devel stuff, I'm happy to do this.

@raveit65
Member

:)
now, it's a bit late... maybe tomorrow or the next day.
i can prepare my notebook for this, fedora 22 mate-gtk3 and devel stuff for compiling m-t.
Can you login to irc freenode chanel mate-dev to meet me?
.......i don't wanna post paswords.

Btw. do you think that vte.sh doesn't break gnome-terminal 'Command completion notification' ?
origin vte.sh
https://dl.dropboxusercontent.com/u/49862637/Mate-desktop/Bugs/vte.txt
adjusted vte.sh
https://dl.dropboxusercontent.com/u/49862637/Mate-desktop/Bugs/vte-new.txt

@willysr
willysr commented Nov 11, 2015

I'm preparing for GTK+3 build for next Slackware release, so go ahead to port it to GTK+3 only

@egmontkob

Let's coordinate in e-mail (egmont at gmail).

@egmontkob

$TERM is xterm or xterm-256color, not vte3 or vte291. You should check for $VTE_VERSION which reflects the tarball version rather than the lib version, that is >= 3800 in case of vte291.

@egmontkob

Patch v1.

I wasted too much time trying to port the entire code from GdkColor to GdkRGBA, but it seems it's not supported in Gtk2, so I gave up and went for converting only when talking to vte. (I was wrong earlier. There were two parallel set of APIs before: vte_terminal_set_color_xxx (taking GdkColor) and vte_terminal_set_color_xxx_rgba (taking GdkRGBA). The first one was dropped, the second one was renamed to the first. No PangoColor in the API.)

Issues I still should fix:

  • Geometry problems (window keeps shrinking), and corresponding warning messages about the lack of "inner-border" property. It was renamed to "padding" but renaming in the code doesn't help, the API to figure out the desired widget size has changed.
  • Transparency not supported

Issues I'm not planning to address and would leave it for you:

  • Remove background image from the Profile settings UI (conditinally to vte >= 0.38).
  • Remove the wordchars support from the UI only for vte == 0.38, or make sure in configure that for Gtk3 at least vte >= 0.40 is required (or just leave as it is now: the UI setting is there but it does nothing).
  • Perhaps allow to support lib 2.90 (vte <= 0.36) and lib 2.91 (vte >= 0.38) in parallel via a configure switch (although there's not much point in it, every distro has vte-2.91 now and the point is to use the newer. However, the rest of the code still supports lib 2.90, only the configure script doesn't allow it).

mate-terminal-66-vte291-v1.patch.txt

@egmontkob

Part 2 (on top of the previous): Fix geometry issues.

mate-terminal-66-vte291-v1-part2.patch.txt

@egmontkob

Bonus part 4: Remove the background image UI setting for libvte-2.91.

mate-terminal-66-vte291-v1-part4.patch.txt

@egmontkob

"I wouldn't think porting would take more than about an hour or so" – yeah, well.... err.... :D

@raveit65
Member

whow, thank you very much :)

"I wouldn't think porting would take more than about an hour or so" – yeah, well.... err.... :D

....god needed 7 days to build the world...... :)
I've create a vte291 branch https://github.com/mate-desktop/mate-terminal/tree/vte291
Can you do a PR there, please.
Here we can do missing GdkRGBA/GdkColor for main branch, configure.ac changes and the rest.

thx again

@egmontkob

You're welcome :)

My git knowledge is best described by http://xkcd.com/1597/ and I've never done a pull request (I guess that's what you mean by PR) , so I'd rather you apply my patches and do whatever git magic you wish to.

@egmontkob

About the cleanup, if you drop gtk2 support and plan to do the GdkColor -> GdkRGBA transition:

Mostly it's a search/replace for the above, as well as gdk_color_xx() to gdk_rgba_xx() and maybe a few others.

update_color_scheme() will have problems. The explicit GdkColor -> GdkRGBA conversion (along with the helper method) is obviously to be dropped. But there'd still be problems around fg/bg/bold colors, current gnome-terminal helps figure out what to do, I'm lazy/tired to do that now.

The tricky part is I've no clue how the settings are stored, I guess currently we kinda read/write a GdkColor using some magic that automatically converts to/from some serializable representation, and I'm not sure the written value could be read back directly to GdkRGBA, maybe an extra conversion layer will be required here.

I'm not planning to work on this, I'd rather get back to vte / gnome-terminal / anything else.

@raveit65
Member

f3e72e5
387af1f
68a474c
54db8f0
@egmontkob
Thanks again, really a great job.
Compiling/install/runing with vte291 works out of box (tested with gtk3),
........and my prob with vte.sh in fedora is gone :)
Well, now i can start to fix the tons of deprecations for gtk3 ;)
Not sure if this will include for 1.12, the other guys needs to test it too....
...but i'm +1 for do this.
Hope we see you again here :)
THX

@willysr
willysr commented Nov 16, 2015

Big Thanks @egmontkob for porting it to vte291.
Since Slackware uses released tarball, i will follow upstream's decision. If it can be included in 1.12.1, then i will use that and upgrade vte3 to the latest version in my MSB and also in SBo project

@egmontkob

I'm not sure what's your policy with 1.12 vs 1.12.1 changes. Dropping vte-2.90 support is probably not nice within a given stable series. But with a little bit of configure.ac magic (I'll let you do that if you want to) you can easily support 2.90 and 2.91 at the same time, and in that case the new tarball only offers new functionality, doesn't remove the existing one. Probably forcing the upgrade from 2.90 to 2.91 belongs to a major release, i.e. 1.14.

@raveit65
Member

slider is fixed.
5ecc6d7

@raveit65 raveit65 modified the milestone: vte291, Gtk+3 Nov 17, 2015
@raveit65
Member

Probably forcing the upgrade from 2.90 to 2.91 belongs to a major release, i.e. 1.14.

Well, using vte290/291 is only for gtk3 build needed, and m-t depends on

src/terminal-window.c:28:#include <libmate-desktop/mate-aboutdialog.h>

So, swtching mate-desktop to gtk3 is necessary to build m-t with gtk3.
In result you need to compile the whole desktop with gtk3.
I'm in doubt that there is one distro who use mate gtk3 in official repos.
At the moment there are only inofficial gtk3 repos for fedora or ArchLinux which are for experimental usage.
From my side for fedora it's OK to switch to vte-291 for an inoficial repo during release cycle.

@egmontkob

Fair enough.

@raveit65
Member

vte291 branch is merged in master 1e12282
@flexiondotorg
Do you need a merge to1.12 branch for your ArchLinux gtk3 repo?
I guess this will make @anatol happy ;)

@raveit65 raveit65 closed this Nov 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment