Port Terminator to GTK+ 3

[David F.]

The current version of Terminator uses GTK+ 2 and therefore doesn't integrate nicely with desktop environments based on GTK+ 3 (GNOME 3, Unity).

[Chris Jones (cmsj)]

I've started a branch to work on this. It is going to take an awful lot of testing, because the patch will be extremely invasive. We have to port to GObject Introspection to get Gtk3 support, so we'll be touching every single line of GDK/GTK/VTE related code :(

[Emilio Pozuelo Monfort (pochu)]

There's a script called pygi-convert from pygobject that should do most of the porting for you with some sed magic.

[Egmont Koblinger (egmont-gmail)]

It's not just the nicer integration with the rest of the desktop. It's more importantly about using a much newer vte. After all, Terminator's main task is to emulate terminals. Currently it is stuck at using vte-0.28 which is 2+ years old.

There were plenty of fixes going into vte recently, and I have another bunch of important terminal emulation fixes and a totally cool new feature at https://github.com/egmontkob/vte-0-36-egmont which will most likely all make it into 0.36 (I'm actively in touch with the two main developers and they are supportive of my work), which in turn will hopefully be shipped by Trusty Tahr LTS, so it will be used by many people for the following 2 years. It would be really great if Terminator could catch up with these changes.

[Egmont Koblinger (egmont-gmail)]

I've looked around a bit on the homepage, roadmap, the bugs here... I really don't mean to intrude and give release instructions, but reading an announcement along the lines of "We're proud to present Terminator 1.0... Alas, it only supports quite old versions of the actual terminal emulating widget, so if you choose our software then you're quite outdated straight away" just doesn't sound right to me. I'd move this bug to milestone 1.0. Just my 2 cents.

[Jeremy A (jtheoof)]

How is the migration going Chris? Do you need help on the matter?

[Jeremy A (jtheoof)]

PS: I could not find any branch matching 'gtk'. Is there still work being done on this?

[Chris Jones (cmsj)]

Hi

Thanks for your interest in Terminator.

I have handed over maintainership of the project to Stephen Boddy.

I don't think any work is currently being done on a gtk3 port.

Cheers,
--
Chris Jones

> On 6 May 2014, at 23:36, Jeremy A <email address hidden> wrote:
>
> PS: I could not find any branch matching 'gtk'. Is there still work
> being done on this?
>
> --
> You received this bug notification because you are subscribed to
> Terminator.
> https://bugs.launchpad.net/bugs/1030562
>
> Title:
> Port Terminator to GTK+ 3
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/terminator/+bug/1030562/+subscriptions

[Stephen Boddy (stephen-j-boddy)]

Hi Jeremy, As Chris said, I have taken over maintainership. Unfortunately I simply don't have huge amounts of free time, and I suspect that the port to GTK 3 is a significant piece of work. I'm thinking that this hump is either going to need a dedicated person with the necessary Python/GTK skills and lots of free time, or maybe a GSoC'er, although obviously that would be next year seeing as how it has already begun for this year.

I don't think Chris ever pushed his initial branch anywhere public, and it has probably diverged too much to be directly used anyway. It might be useful as a demonstration of the sort of changes, but that would depend on if it is still sitting somewhere on Chris' hard drives, and if he can make it available.

[Egmont Koblinger (egmont-gmail)]

I attach a preliminary demo patch to port Terminator to Gtk3.

The patch applies on top of the source converted by pygi-convert.sh. Get https://git.gnome.org/browse/pygobject/tree/pygi-convert.sh (blob 43af662) and then do:

bzr branch lp:terminator
cd terminator
pygi-convert.sh terminator */*.py */*/*.py
patch -p1 < .../terminator-gtk3-v1.patch

You also need to have vte-0.37.2 (or current git master HEAD) installed, which internally refers to itself as vte-2.91. Vte breaks the API with the 0.37 [gnome 3.13] series, it's not compatible with the current stable 0.36 [gnome 3.12] (which internally calls itself vte-2.90). The two versions can safely coexist in parllel so it shouldn't be a problem for anyone to install new Vte (get 0.37.2 tarball; ./configure --prefix=/usr; make; sudo make install). I saw no point in trying to work up a lag of 3 years into a version that's not the newest so that then we'd have to port again.

The patch is in demo state. Many things are broken, many things are commented out in the source just because they didn't work out of the box right away and I didn't bother with them. But at least it starts up and runs okayish (assuming no ~/.config/terminator/config file), finally using a terminal widget that has received about 100-200 bugfixes since its Gtk2 version, which is a giant step.

From this point, it's a long series of very small easy fixes making it better by each step (going through the bits I commented out in the patch, the bits that don't look good on the UI, the bits that changed in Vte over the time etc.) that would eventually make it pair up with the Gtk2 version.

I might come up with a second version fixing some of the bugs, but I really don't promise. I definitely promise I will *not* be the guy making it ready to ship (due lack of time and interest) but it sounds like an easy and great learning task for anyone with little or no Gtk/Python coding practice. If anyone volunteers, I'm more than happy to help.

[Egmont Koblinger (egmont-gmail)]

Many fixes since the first version.

[Egmont Koblinger (egmont-gmail)]

This is now in pretty good state. Some problems still remain, but basically it's there and is usable and it's quite okay.

I will definitely not continue working on this. I hope you find my work useful and can finish up things from here, but it's not my project. I'm just trying to push wider adoption of new VTE and trying to get rid of its unmaintained gtk2 version.

Things I've done:

- Ported tons and tons of things to make work with Gtk+-3.x and Vte-0.37.
- Dropped "antialias", "background_image", "emulation", "alternate_screen_scroll", "word_chars" settings as these are no longer supported by VTE.
- Transparent background support remains (for compositing WMs), with a different API: the color passed to VTE as the background color needs to have an alpha channel.
- Changed the way a new terminal is opened in the same working directory, similarly to mainstream VTE's change: instead of peeking into /proc, we now rely on the OSC 7 escape sequence. It's required that your bash/zsh sources /etc/profile.d/vte.sh for this to work.

Things to do:

- Go through the patch and fix or double check every "FIXME FOR GTK3" and "VERIFY FOR GTK3" comment.
- Polish up the preferences layout, especially Profiles->General looks bad.
- Add support for VTE's new "rewrap on resize" boolean feature.
- Double check if "Use colors from system theme" works correctly, it uses different colors than gnome-terminal.
- With "Use colors from system theme" enabled, start terminator anew, the foreground is white. Just open and immediate close the prefs dialog without changing anything, the foreground becomes gray. Not sure if buggy in current terminator or I introduced this bug.
- Update remotinator, I haven't checked that or any of the ipc/dbus stuff.
- Stress-test, check all the features one by one, look for more bugs and fix them. I'd guess there are probably 20-30 small bugs remaining, each should take around 5-15 minutes to fix.

[Egmont Koblinger (egmont-gmail)]

One final minor update, to make it work with stable Vte-0.38 (from Gnome-3.14).

[Leo Iannacone (l3on)]

Hello! There are some news about this issue?

[Stephen Boddy (stephen-j-boddy)]

At the moment I'm afraid I don't have the time or motivation to do much work on Terminator. Because of this I need to say a big "thank you" to Egmont for doing the initial work on this. So...

@Egmont: THANK YOU!!!

It's appreciated that you picked this up yourself.

So there's two pain points:
1) I'm on Ubuntu 12.04, so my system is too old to run this. I can't even start it.
2) Because Egmont didn't use bzr and make small incremental commits, the patch is a bit of a monster.

So I've applied the conversion and the patch and uploaded it as a new branch - this way people can more easily branch it themselves and test it out. When I get a moment I'll create a 14.04 LTS VM, and try this out, but my daily environment is 12.04 and I'm not planning to change that at present, so this will be (for now) the red-headed step-sibling of the two streams :-) Of course anyone can volunteer to adopt it and begin fixing any outstanding issues.

[Stephen Boddy (stephen-j-boddy)]

OK, a quick step-by-step walkthrough for those that would like to test/contribute:

1) Need to ensure the following additional packages are installed on Ubuntu (tested in a clean 14.04):
        gir1.2-keybinder-0.0
        gir1.2-keybinder-3.0
        libkeybinder-3.0-0
        build-essential
        intltool
        libgtk-3-dev
        gobject-introspection
        libgirepository1.0-dev
        valac
        xmllint
        terminator
    (I install the old terminator because it puts various icons and stuff in the correct place so you can run from the bzr checkout)

2) Then get hold of the vte archive and uncompress it:
        mkdir -p ~/Development/vte
        cd ~/Development/vte
        wget http://ftp.gnome.org/pub/GNOME/sources/vte/0.38/vte-0.38.0.tar.xz
        tar xJvf vte-0.38.0.tar.xz
        cd vte-0.38.0

3) Now you can run the commands from Egmont:
        ./configure --prefix=/usr; make; sudo make install

4) Create a local copy of the gtk3 tree and you should be able to run from there:
        mkdir -p ~/Development/terminator
        cd ~/Development/terminator
        bzr branch http://bazaar.launchpad.net/~gnome-terminator/terminator/gtk3/ gtk3-myuniquename
        cd gtk3-myuniquename
        ./terminator

For myuniquename pick a name that hints what the branch is for, i.e. gtk3-fixes. It's not essential, but it'll be clearer/easier to keep gtk2 and gtk3 separate if people start sending in fixes.

At this point you should have a new Terminator window, with the only visual difference I spotted so far being the grey popup menus.

One final tip: Creating new tabs fail unless you add the /etc/profile.d/vte.sh to your ~/.bashrc as per Egmont's instructions. It probably just needs a sensible fallback if the vte.sh hasn't been sourced, as this doesn't fail for splits.

The patch *requires* Vte 0.38 which is something like 5 days old! It is not in the latest Ubuntu LTS (14.04 which has 0.34) or even yet-to-be-released Utopic (0.36). I've found no PPA providing newer versions for existing releases. This is a bit of a problem, because it means a long time before this work would be usable for everyone "out-of-the-box". i.e. Ubuntu 16.04 will be the first LTS likely to have 0.38 in the main repos. It *may* get into the 2015 interim releases.

The above procedure is not something many would mess about with just to get a terminal, especially when the existing version - whilst old - is perfectly capable, and much more easily accessible. I know it is capable because I use it every working day. I understand why Egmont preferred the newer, changed API, but it leaves an awkward situation:
A) Work on the more supported older version, risking bit-rot to Egmont's hard work.
B) Work on the newer one, allowing the original to bit-rot, but making the initial installation effort higher for everyone.
C) Somehow try to work on both, and keep them relatively synchronized.

[Egmont Koblinger (egmont-gmail)]

You're welcome guys, I hope you find my work useful :) Unfortunately the interpreted nature of python makes it very hard to test and catch bugs, you need to trigger execution of each line of code to tell that the method is indeed called with the correct parameters (which might have changed since Gtk+-2). A really thorough testing/fixing is needed. Probably there are quite some actions or config options that causes a crash or critical warning and failure the perform the required operation. But at least it's easy to start it and make progress, fix the issues one by one.

The hard, albeit more interesting problem was to make it start up at all with Gtk+-3/Vte-0.37, and then to make it reasonably okay. Unfortunately this process didn't consist of self-contained smaller changes that made sense on their own, so splitting it into a reasonable sequence of small changes would have required a significant amount of extra work, it just really wouldn't have made sense.

Thanks for the more detailed instructions on how to set up on Trusty/14.04. Note that most likely a vte2.91_0.38 package will appear at https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging/+packages in the near future, which will simplify this process. (Even though the package is targeted at Utopic/14.10, hopefully it will also work on Trusty.)

For Precise/12.04, probably you can manually compile-install a recent glib/pango/gtk3/vte038 stack in some nonstandard directory and use that with Terminator; this might take a bit more nontrivial to set up than a VM, but would probably make subsequent Terminator development more seamless.

"Creating new tabs fail unless you add the /etc/profile" -- as far as I know, Ubuntu didn't upgrade Gnome-Terminal for a while because they failed to solve this terribly hard problem of sourcing vte.sh (it shouldn't take more than 10 minutes). If they ever upgrade Gnome-Terminal to anything newer than 3.6, that'll mean that they have solved it and Terminator doesn't need to care. Until then, Terminator might decide to bring back the old OS-dependant digging into /proc as a fallback if OSC 7 wasn't seen in the given terminal.

As for which version of Vte to develop for (tl;dr version: go for 0.38 only, forget the dual 0.36/0.38 approach)

Currently Terminator is ~3 years behind with the Vte it uses. It's really not bad if users don't receive the new Terminator-Gtk3 as soon as it's declared stable but they have to wait for a few more months before that. The real bottleneck is developer resource, so we should optimize for smaller developer cost, rather than letting everyone have Terminator-Gtk3 as soon and as easily as possible.

The earliest Ubuntu in which Terminator-Gtk3 has a chance to appear is VV/15.04. There's absolutely no reason vte2.91_0.38 couldn't also appear in that very same distro - especially if Terminator-Gtk3 brings it in as a requirement.

Given that Vte-0.36 and Vte-0.38 are incompatible and can easily co-exist, it should be very easy to create a PPA containing vte2.91_0.38 and terminator-gtk3 packages for Trusty, Utopic, and any other newer distros where these two packages are not shipped by default.

Making Terminator-gtk3 ...

[Leo Iannacone (l3on)]

Please, don't stop. Terminator is a really interesting project, it is a pity discontinue it....

[Egmont Koblinger (egmont-gmail)]

Leo: I don't think the project is officially discontinued, it's just that there are no active developers at this point. If you could find someone with interest and time they could devote this project, that would be awesome. The original maintainer passed on the project to Stephen who apparently doesn't have time or motivation to work on this, and I myself don't have it either. We'd need a volunteer!

[xir (simonbennie)]

I would like to add that I've been testing this in fedora 21. Under the Wayland session terminator-gtk2 cannot make new panes or tabs. With terminator-gtk3 it works like a charm and seems very responsive.

Great work guys.

[Leo Iannacone (l3on)]

Hey guys ... news?

[MattRose (mattrose)]

All right. I've spent a day or so getting terminator working* with Centos7 and vte3.

* by "working", I mean, I stripped out anything feature that wasn't working, but, I only had to strip out a feature or two, and do some weird stuff with vte_terminal_set_colors, so, as far as I know, it only has a black on white mode.

There's a patch attached which just mostly comments out non-working functions, and fixes up various vte options where I could.

It actually works surprisingly well, given the hacky quality.

[MattRose (mattrose)]

The above patch actually works with vte-0.34

[MattRose (mattrose)]

Can anyone give me any feedback about my patch?

With a few more patches that I've been working on, I've gotten terminator to be usable. It seems to have all the features that I really want (Split term, zoom term, basic color support)

I think once we have this branch mostly working, that'll encourage more people to pick it up and try hacking on it to get their features back.

If people like the general direction of the patch, I can split it into more easily consumable chunks.

[Egmont Koblinger (egmont-gmail)]

Hi Matt,

In comments 15-16 we had a bit of discussions about which version of vte to develop against, I recommend you to read that.

If your goal is to have the current state reach as many users as possible, your work of downgrading to an older vte is more than welcome, I hope that quite a few people will find that useful.

If your goal is, however, to further improve the official Terminator and/or find people who do so, and make it finally officially support Gtk+3, then I can only repeat what I said earlier: in my opinion going backwards in time is not the ideal direction. There is already a version that uses a newer Vte and does support bg/fg colors properly. You modified it to use an older Vte and it has hardcoded colors.

In my opinion, if you'd like to help the project, the best would be if you could install vte-0.38 and develop against it. By the time we're anywhere close to release-ready, vte-0.38 will be quite widespread. vte-0.38 can safely coexist with older versions. The problem, in your case, is that your OS contains libraries that are too old to compile vte-0.38. Maybe you need to upgrade to a development version (I'm not sure if it exists, haven't ever used centos), or install a newer Glib stack into a special directory, or use another distro in a virtual machine, something like these.

If this is too cumbersome, I recommend that you make a 1st patch that is clearly solely about downgrading to vte-0.30/32/34/36 (those are pretty much identical) from the current state, without regressions (that is, figuring out how to handle colors - probably you just need to revert some bits of my patch); and do the rest of your work on top of that in subsequent changes. Then, we'll have a better and better version against vte-0.3[0246], and with a little bit of luck, all we need to do is to revert your first patch on top of all your patches, and hopefully we'll be back at 0.38 with all your fixes. I believe that the proper patch to transition between 0.38 or 0.3[0246] is fairily simple, compared to all the other issues that still need to be fixed. So even if you insist on using the older vte, if you can separate the vte downgrade patch from the rest of the fixes then your work is highly valued and appreciated, thanks!

Thanks a lot!

[MattRose (mattrose)]

Thanks Egmont, I'll split out the patches and feed them to you one by one (It's probably for the best that way anyway). Do you want each as a separate bug, or just add patches to this bug?

[MattRose (mattrose)]

I read the comments in 15-16, and I had surprisingly few issues with running it in vte-0.34

At any rate. I agree that going with the latest and greatest vte should definitely be the target, but for me personally, vte-0.34 support is important, as that is the version that Redhat has settled on, and so will be the version for Redhat/CentOS 7, forever-and-ever-amen.

It has been an interesting exercise to do this, so I hope, if I feed you nice, digestible patches that don't introduce regressions, (and actually do things a little bit better, IMO), I hope you can accept them. I've had some time to clean up the code and do things right since writing my first patch

Thanks for your response.

[Egmont Koblinger (egmont-gmail)]

Oh, don't get me wrong, I'm not the developer/maintainer of this project :) It's Stephen whose opinion should really matter. I'm not even using Terminator myself, and I can't promise I'll have time to review your patches.

Stephen pointed out that I should have also used bzr, so probably the best is if you can place your own code changes to a bzr branch. (Although I, for one, would be quite reluctant to learn yet another version control system.) Again, don't know, Stephen's opinion should matter the most.

As long as it's just about porting to Gtk+3 and eliminating the current regressions, I believe it's best to keep everything here in this ticket. Maybe if you fix a nontrivial bug that's also present in the Gtk+2 version and doesn't interfere with the rest of your work, or implement a brand new feature, then that might deserve its own ticket.

[MattRose (mattrose)]

All Right, all in this bug.

So I kinda set up bzr, I already know RCS, CVS, SVN, Git, Hg, Darcs and Perforce, what's one more?

I'll take a look at setting up a branch in launchpad to push changes to.

If I get lost or anything like that, I'll just start sending in patches.

[MattRose (mattrose)]

So there is now a branch at https://code.launchpad.net/~mattrose/+junk/terminator-gtk3-vte-0.34

[MattRose (mattrose)]

Well, I installed Fedora 21, and I pretty much came to the same conclusion that Egmont came to in comments 15 and 16. There are a *lot* of incompatible changes to the vte API between 2.90 and 2.91.

It makes me sad, because I'd like to get this packaged up for EPEL, but I just don't see how to do that, other than maintaining my own huge patchset.

I'll see how hard it is to shoehorn a vte update into CentOS7.

[Egmont Koblinger (egmont-gmail)]

MattRose: any progress? :)

vte-0.40 (part of gnome-3.16) was just released.

API-wise the only big change is that the word-chars feature, which was removed from 0.38 (and hence from Terminator by my patch) is back; Terminator should bring it back too.

Internally the biggest change is that the scrollback buffers contents used to be written on the disk as plaintext. It's now compressed and encrypted. For anyone worrying about privacy and not having an encrypted /tmp, it's definitely something worth upgrading for!

[MattRose (mattrose)]

Honestly, I got the bare minimum functionality that I need from terminator working with vte-0.34, and have been happily using that ever since. I can check that into the repo I created and mentioned in comment #29, but it's got vast areas of functionality that just don't work, but I don't care since I never use it :)

I don't really run Fedora anywhere now, so I'm not on the latest GNOME, but I may try and see if I can build it for CentOS7, so I may pick this up again.

Honestly, Egmont, What little I tried of it on Fedora worked great, and I really think you should see if you can pull it into master (or Mainline, or HEAD or whatever terminology bzr uses), and release that. Bugs will get found and fixed quickly.

[Stephen Boddy (stephen-j-boddy)]

Hi Matt, Egmont.

I think I'd like suggest the following going forward.

You may have noticed there is now the trunk series (one day will be 1.0) and a gtk3 series (one day will be 2.0). You will also see that as and when I do fixes/features, I've added them to both branches. It turns out it's not too hard to fix the other one once you figure how to fix the first, and is fairly minimal additional effort. It's actually also a backdoor way to start learning the gtk3/gi way of doing things.

So I'd suggest we keep gtk2 for now as the older fallback, and gtk3 for those who are rocking up-to-date systems. I'm curious how stable existing API's are now post 0.38? Is the API still breaking backwards compatibility, or can we rely on Terminator working in the future with newer libs without changes? I know, that's usually the 1.0 release.... right? Hey Egmont, when are you going to release 1.0? :-D

[Egmont Koblinger (egmont-gmail)]

Hi,

Unfortunately I have no information about possible further changes, or 1.0 plans.

I personally don't think 1.0 is going to happen any time soon, we have too much on our to-do list and too few developer resources.

The API changed from 0.28 to 0.30 due to the Gtk 2->3 transition (actually I'm not even sure if the API changed there, or it's just a brand new way of binding to python), and from 0.36 to 0.38. I don't think it's going to change in a backwards incompatible way more often than every 2 years or so. (We seem to be back in the normal track of a major version twice a year along with the Gnome release, that is, 0.42 expected in September, etc.).

Even if there's another backwards incompatible change, distros will ship the two versions in parallel for a while (as they do now with 3 versions), and porting to the new one will be a piece of cake compared to the current Gtk 2->3 migration, hopefully at most an hour or two of work. So you shouldn't worry about it.

[Stephen Boddy (stephen-j-boddy)]

Hey Egmont, I found an issue with the port, and I'm not sure how to fix, so was hoping for a quick consult/suggestions, as you are the resident vte expert.

In http://bazaar.launchpad.net/~gnome-terminator/terminator/gtk3/revision/1538 I rolled back the change that tries to get the cwd from the vte. On my Ubuntu 14.04 system with vte 0.38.1 get_current_directory_uri only ever returned None, which caused an exception in the GLib.filename_from_uri call. This broke tabs completely, and stopped the cwd being carried when splitting. Instead the terminal always took the cwd from startup.

I took a look at the vte code, but I'm no c dev. I tracked back to vte_sequence_handler_set_current_directory_uri, which (if I understood) is called when a sequence is seen in the console. It's not clear to me what could be causing the get_current_directory_uri to always return None. Any thoughts?

[Egmont Koblinger (egmont-gmail)]

The return value of get_current_directory_uri can be modified by emitting the OSC 7 escape sequence inside the terminal, e.g.:

echo -ne '\e]7;file://foo/usr/bin\a'

The return value is None until this escape sequence is first encountered.

Vte ships an /etc/profile.d/vte.sh which should be sourced at shell startup. This hooks up to the shell so that each time the prompt is printed, this escape sequence is emitted, notifying vte about the current directory. Ideally, this is done by every distribution, and should be done by you too.

Take a look at gnome-terminal's source, src/terminal-screen.c, terminal_screen_get_current_dir(). (No C knowledge is required to understand.)

It first calls get_current_directory_uri(), and if succeeds (that is, such escape sequence has been printed), it uses that value (stripping off the file: prefix, unescaping etc.).

If it returns null, that is, such escape sequence has not been seen in the terminal yet, then it uses the value that gnome-terminal internally remembers which is the initial working directory of the given tab.

[Egmont Koblinger (egmont-gmail)]

So, apparently what was missing from my version of the code is the check for None, and in that case use a value that was stored for the given tab when it was created (maybe terminator doesn't even remember this value right now, in this case it should).

You might be interested in https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1132700: Ubuntu developers decided to revert part of the old code: in case get_current_directory_uri() returns null, they revert to the old method of figuring out the directory. In my opinion it's an overkill and carries legacy ugly code and I wouldn't do it, but you might want to also choose this path.

[moimael (moimael)]

I worked on modernizing pref windows, which version of GTK3 is our minimum target release ? Can we use client-side decorations ?

How can I push my changes in Gtk3 branch ? Do I need to create my own branch and then you'll merge it ?

Thanks !

[Stephen Boddy (stephen-j-boddy)]

Hi moimael,

Modernizing how? The prefs for both versions just went through a whole re-layout and clean-up for 0.98. Right now they are nicely synced, so I'm not sure what you've done or whether it will get applied.

Minimum version for GTK3 is not really well defined. I jump between the two supported LTS releases of Ubuntu which I think is a pretty good minimum. 14.04 is using 3.10, but I think 12.04 is 3.6, so that would be my minimum.

On CSD, I'm going to go with no. As I understand the WM needs to support them, and only the default GNOME one (mutter?) does so. These CSD's would not work on any (or most) other WM, or would they automatically appear below as a toolbar? And what would you need put in the window titlebar anyway?

Normal procedure for contributions is to push a personal branch, and request a merge. Very few people have commit access to the main branches (trunk & gtk3).

[moimael (moimael)]

By removing all deprecated GtkHBox, GtkVBox, GtkHpaned, GtkHbutton, ... and using GtkBox, ...
Also bumping the minimum version to 3.0 in glade file (otherwise a warning is displayed by glade 3)

3.6 is ok.

By the way ctrl+r is completely buggy, making my splitted terminator to resize all the time. Same for tab based autocompletion.

Thanks !

[Stephen Boddy (stephen-j-boddy)]

Most patch review is about applying it, and double checking it has the intended effect with no obvious regressions, possibly with some personal touches sprinkled in, and then finally committing. Then there is a (usually quick) port to the other branch. Providing I can reproduce and test cases are clear, this is pretty quick and smooth. The only time I might ask for help with this is if I'm unable to reproduce, such as some of Egmont's where he is on a newer GTK3 version, or broadcast/input/composed keys which is a bit of a mine field or weird and wonderful corner cases.

I'd say updating the rpm spec file is really useful, as your expertise here is in short supply :-) I suggest you break it out as a task/bug, then if you or I have any queries we can discuss there. (Things like handling install of the still to be integrated html manual, because that was a bit messy for debian.) Just from a brief glance, the install of the manual is missing, and the dependencies are almost certainly out of date.

If you still have time/energy then look for bugs without patches that look like they should be fixed before a release, and have a go at coming up with a fix.

[Stephen Boddy (stephen-j-boddy)]

Oh, and it should go without saying that if you pick up a bug to work on, assign it to yourself. That way we don't wast time duplicating work.

[Egmont Koblinger (egmont-gmail)]

> - [outstanding patches etc.]
> - Copy/Update the manual to GTK3.
> - Get packaging for GTK3 branch updated.
> - Do a release of 0.99 and 1.99

Awesome up to this point! The next step should be getting Ubuntu pick up 1.99 for Xenial LTS.

> - Do a quick stability bug cycle
> - Do a release of 1.0 and 2.0

It's up to you. I'd wait at least for about a month. We can wait longer with the 1.0/2.0 releases if you want more people to test and come back with feedbacks. We can even have 1.99.1 etc. releases in between (or 1.100 if you're pervert :P). Or go straight ahead to 1.0/2.0, that would give more media coverage to the project and more people hooked on.

[Egmont Koblinger (egmont-gmail)]

In _my_ opinion, this is where we are right now:

Blocker for 1.99:
- Bug 1520969 [Double-click doesn't distribute area evenly] - patch available
- Bug 1522542 [Zero-sized terminals after rotate] - needs work

(I choose these two because these are regressions from the 0.9x series and potentially might be the reason for someone (or worst case: a distribution) not wanting to upgrade. Okay, the lack of background image and utmp are also regressions, but they're a different story, there you can blame vte.)

Would be nice for 1.99, blocker for 2.0:
- Bug 1520377 [Stale tab titles] - has a patch that fixes on newer gtk, breaks it further on old ones

(After the 1.99-blockers I think this is the most serious / most embarrassing bug we have and I really wouldn't release *.0 with it.)

Would be nice for 2.0:
- Some of the not-so-important low-hanging fruits randomly (there are maybe a dozen easy ones out there)

[Egmont Koblinger (egmont-gmail)]

Both of the bugs I personally find "blocker for 1.99" now have a patch available. Yay!

[MattRose (mattrose)]

Damn, now I'm gonna have to find some time to fix up the spec file.

[MattRose (mattrose)]

Not that anyone but me really cares, the gtk3 branch now works really well on CentOS/Redhat 7.2.

They finally updated to gtk 3.14 from 3.8, and it all just magically, works, and I can throw away my local branch that kinda, mostly worked with gtk 3.8

I'm gonna work up a copr package for Fedora 23 and EPEL7 with this. Hopefully today.

[MattRose (mattrose)]

I've got a "scratch" terminator gtk3 package numbered 1.99 in Fedora's copr system. mattrose/terminator if anyone wants to test it out.

I can put submit a patch for the spec file, and also, I had to pull some stuff out of the terminator.desktop.in that was ubuntu specific, and I couldn't get it to build for CentOS or Fedora. I put that in a separate patch file contained in the source rpm.

[Egmont Koblinger (egmont-gmail)]

Friendly ping... what's up with the project?

It's been stalled again for almost 3 months, even though a fairily great vte3-based version is almost ready.

Looks like Terminator is dying and soon will be obsoleted by Terminix?

[MattRose (mattrose)]

I looked at terminix, and it has some neat stuff, but is written in D, and is very crashy.

I've actually started to work on my own tiling terminal, in ruby, just because I'm more comfortable in it, and helping out here has convinced me that I only use about 10% of the features of terminator, and maintaining all the features of terminator is a huge burden with the api incompatibilities that GTK throws every major version.

I'll post something crappy when it has vey basic tiling support, if I ever get around to it.

If there's something I can help out with here, let me know.

[Stephen Boddy (stephen-j-boddy)]

@zahary1981: No idea why you felt the need to change that, but I'm changing it back.

[Egmont Koblinger (egmont-gmail)]

Gtk2-based VTE suffers at least from https://bugzilla.gnome.org/show_bug.cgi?id=664611, presumably other security issues as well which aren't and will never be fixed because the Gtk2 branch is no longer maintained.

Therefore, claiming that this bug has security implications is not a false claim.

[Stephen Boddy (stephen-j-boddy)]

Hi Egmont. Yes, the gtk*2* codebase is exposed to this issue. This "bug" is for tracking the gtk*3* port. It would be perverse (in my mind at least) to flag *this* as a security issue. Flagging a bug against gtk2 as a security issue regarding plaintext in the tmp dir I could understand. There was another person (also with zero contributions/profile/karma in Launchpad) who just up and unlinked a load of yet-to-be-released fixes from the trunk branch recently. I mailed them to ask why and have had no response. It's made me a little sensitive to unknown people making what looks like pointless and rather random changes without at least a note as to why.

[Egmont Koblinger (egmont-gmail)]

Seriously guys... what's going on here?

The gtk3 branch is almost release-ready. It needs 2-3 existing patches to be merged, a tarball released, and that's it. It won't be perfect (no software will ever be), but it'd already be significantly better than the gtk2 branch. And then we could ditch the gtk2-based version (using a terribly buggy, obsolete, unmaintained vte) for good.

Yet, development stalled again, nothing happened in the last 4 months, and we hopelessly missed the next long-term support Ubuntu release.

Can we declare that Terminator is dead, or at least it needs a new maintainer? :(

I feel like all those work that I dedicated to this project was a waste of time, I wish I had spent that on something different.

[Simon Déziel (sdeziel)]

Hi Stephen,

There's still a slight chance for a terminator-gtk3 version to land into Xenial. ATM, Terminator is really a pain to use to the very frequent crashes (see LP: #1568132). Do you have an ETA for cutting a version?

[Egmont Koblinger (egmont-gmail)]

Hi Simon,

Can you make terminator-gtk3 land in Xenial (despite all kinds of freezes)? I mean are you a qualified Ubuntu developer to do this, or have the proper contacts?

If so, I can send you the 2-3 patches I recommend to be applied on top of current bzr that would be a way better version than 0.98. Just in case Stephen is unresponsive or doesn't have time to work on it.

cheers,
egmont

[Simon Déziel (sdeziel)]

Hi Egmont,

For this to happen, we'd need:

1) a functional package (I could help testing)
2) the sources attached to the bug report
3) someone reviewing this new package
4) someone else uploading the package

I have a contact for 3) and might have another for 4).

Regards,
Simon

[Egmont Koblinger (egmont-gmail)]

Hi Simon,

As for 1, I cannot create a functional package. I can only recommend bzr gtk3 branch plus give a few patches that apply (without conflict) on top of each other, that's all. This might be as simple as applying the patches from a few aforementioned bugreports, but might require some more work if they conflict with each other, I can't tell right now which will be the case.

As for 4, since we're only 5 days from FinalFreeze, I'd like to see a clear confirmation that someone has the approval and is willing to upgrade this package, despite all kinds of freezes in effect right now. Following the spirit of comment 90, I wouldn't want to waste any more time on this (read: I don't have any time to waste. I'm willing to help only if I know for sure that my work is going make it into Xenial). "might have" is way too weak for me at this point, sorry. Please ask them for a definite answer. Please refer them to comment 88's security implications.

[Simon Déziel (sdeziel)]

Hi Ergmont,

I understand you not wanting to spend more time without strong
guaranties first. The thing is the reviewer and the uploader need to be
2 different persons and I only had the commitment of one of them.

Since there is apparently no existing packaging for this port, I think
it's too late for Xenial. That said, I still want it so I'll try to put
it in a PPA sometimes [*]. Maybe that could be of some use to you and
others.

Regards,
Simon

*: if you could share your few patches to apply on top of the bzr branch
that would be handy.

[Egmont Koblinger (egmont-gmail)]

Please apply the following patches, and please double check that they do indeed fix the corresponding bugs (I have no time to thoroughly test them right now):

- bug 1520969 comment 42
- bug 1522542 comment 11
- bug 1520377 comment 2

(These are the exact same bugs as mentioned in comment 80 here.)

Thanks!

[datakid (datakid)]

Hi. Would love to keep using Terminator but 0.98 on Xenial just died in front of my manager. He swore at me - doesn't want inconsistent systems as a result of my terminal crashing. I'm moving back to gnome terminal, but would love to see this get released. Thanks to all for the work so far.

[coffeeCola (xvalarino+launchpad)]

From Stephen's comment, about midway through:
> OK, a quick step-by-step walkthrough for those that would like to test/contribute:

Is this still the best way to install Terminator with GTK3 support?

[Luis Alberto Pabón (copong)]

Aye, terminator 0.98 on Ubuntu 16.04 randomly crashes. Perhaps terminator-gtk3 in its current state is better than old terminator? Gudging by the most recent messages, terminator-gtk3 is at least beta quality - I can definitely work with that and help test.

[Anton Kochkov (anton-kochkov)]

Any updates on the process?

[Fuujuhi (fuujuhi)]

Hello,

I build terminator/gtk3 branch on Xenial 16.04.
For what it's worth, here the clean-up recipe I used:

# Get terminator/gtk3 sources
sudo apt install bzr
bzr branch lp:terminator/gtk3
cd gtk3

# Apply latest patches
sudo apt install bzrtools
bzr patch <(wget -O - https://bugs.launchpad.net/terminator/+bug/1520377/+attachment/4526119/+files/terminator-1520377-stale-tab-title.patch)
bzr patch <(wget -O - https://bugs.launchpad.net/terminator/+bug/1522542/+attachment/4535308/+files/terminator-1522542-rotate.patch)
bzr patch <(wget -O - https://bugs.launchpad.net/terminator/+bug/1520969/+attachment/4633044/+files/terminator-1520969-distribute-evenly-v3.patch)

# Install dependencies
sudo apt build-dep terminator
sudo apt install gir1.2-keybinder-0.0 gir1.2-keybinder-3.0 libkeybinder-3.0-0 build-essential intltool libgtk-3-dev gobject-introspection libgirepository1.0-dev valac terminator
sudo apt install cdbs

# ... and quick fix for python-support
# (a better solution would be to apply https://wiki.debian.org/Python/TransitionToDHPython2)
sudo apt install dh-python
sudo ln -sf dh_python2 /usr/bin/dh_pysupport

# Change version and build
debchange --newversion 1.97~ppa3~local --distribution xenial-proposed "gtk3 branch with patches 1520377, 1522542, 1520969"
dpkg-buildpackage -rfakeroot -b -d

# Install
cd ..
sudo dpkg -i terminator_1.97~ppa3~local_all.deb

I joined the .deb in attachment.

I'm going to use this everyday from now on, in particular see how it works with latest neovim.

[Egmont Koblinger (egmont-gmail)]

Another friendly ping... (sigh...)

Stephen, seriously, what is going on here???

You had a short peak of activity about a year ago, and made the gtk3 branch pretty much release ready. Since then hardly anything happened for almost a year, although you're still here commenting on some other bugs.

terminator-gtk3 in its current shape (especially with the 3 patches mentioned above, but even without them) is way better than the gtk2 version, due to the hundreds of improvements that vte received.

Yet this much better version does not reach the users because for a year now you couldn't find a few hours to release a tarball. Users of Terminator keep using an ancient and quite crappy actual terminal emulation, and not even aware that they could get something much better.

I keep seeing tons of questions on the stackoverflow suite (askubuntu etc.) about Terminator missing this and that feature, I keep posting them how to upgrade to the gtk3 branch; or people recommending Terminator to others and myself stepping in warning them about a legacy buggy vte.

In the mean time, another tiling emulator called Terminix (I've already mentioned it here) has become awesomely stable, nice and feature rich. It has recently made it into the Debian repos, and will be shipped by Ubuntu 17.04 Zesty as well.

Distros would be more than happy to upgrade to a much newer Terminator (and get rid of vte2 for good ASAP), but they are not going to go for a bzr branch, I think it's understandable.

Stephen, I can see 3 things that can happen to Terminator in the very near future:

- either in an extremely short time period (in less than a month) you release 1.98 (or whatever) and then it'll live on as a nice choice for users (and you can find a new maintainer with no rush if you cannot carry it on);

- or if you can't find the time/motivation/energy to do that then you should urgently start actively seeking for a new maintainer and transfer the project to someone who is going to make the release preferably no later by the end of this year;

- or if you keep ignoring this bug and the project then Terminator will be a dead project in about a month or two, there'll be no reason left to use this compared to Terminix; moreover, you'll be the one to blame for its death!

Please choose one ugrently. Thanks!

(Oh, and by the way... you remember that the vast majority of the gtk3 porting was done by me, right? Had I known that this was going to be the fate of them, I definitely wouldn't have spent a minute on this. Think about this for a second, please!)

[MattRose (mattrose)]

I would like to propose a "Plan B"

Move the gtk3 branch to github, and release it under a new name.

I would rather NOT do this, but I like Terminator, and continue to use it, and have myself done a substantial amount of work on getting the gtk3 branch usable, but if there continues to be no response, then to maintain the codebase, we really have to consider forking it.

[Dominic Hopf (dmaphy)]

Greetings,

I think Plan B sounds good for me as well so far. It's no big act at all to
fork the code and push it to Github - but: the one who does that has an
obligation to maintain the code as well. Thus, I'm also out, my
Python-knowledge at all isn't that perfect. I couldn't do any more than
accepting pull requests and hope those work. :-)

Anyone around with some more knowledge about Python and willing to maintain
the stuff? ;)

Regards,
Dominic

On Mon, Nov 21, 2016 at 4:18 PM, MattRose <email address hidden>
wrote:

> I would like to propose a "Plan B"
>
> Move the gtk3 branch to github, and release it under a new name.
>
> I would rather NOT do this, but I like Terminator, and continue to use
> it, and have myself done a substantial amount of work on getting the
> gtk3 branch usable, but if there continues to be no response, then to
> maintain the codebase, we really have to consider forking it.
>
> --
> You received this bug notification because you are subscribed to
> Terminator.
> https://bugs.launchpad.net/bugs/1030562
>
> Title:
> Port Terminator to GTK+ 3
>
> Status in Terminator:
> In Progress
>
> Bug description:
> The current version of Terminator uses GTK+ 2 and therefore doesn't
> integrate nicely with desktop environments based on GTK+ 3 (GNOME 3,
> Unity).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/terminator/+bug/1030562/+subscriptions
>

--
Diese E-Mail ist nicht mit GPG signiert, da ich sie vom Webinterface aus
geschrieben habe.

This mail is not signed with GPG because I wrote it from web interface.

[Egmont Koblinger (egmont-gmail)]

Forking might be a good long term solution - if Terminator survives until then, which I seriously doubt if there's no short term solution.

Distributions that aren't willing to switch to a bzr branch are probably even less willing to switch to an unofficial fork. By the time that fork becomes widely known and recognized, it'll probably be too late for the project, at least this is what I'm afraid of.

However, if someone's giving a try, I'm sending best wishes and best of luck!

(Just for the record: I'm sorry but I cannot make any commitments, let alone maintenance of the project or a fork thereof. I'm a vte developer (kinda) and I don't even use terminator myself, I just care about vte3's fixes getting to everyone.)

[Stephen Boddy (stephen-j-boddy)]

Right. So I'm an arse. Apologies, and all that. So stick a for in it, it's done. Released. Out in the wild. Version 1.90 is running free.

I'm going to shut this bug down, as issues found in gtk3 from here forward should be raised as regular bugs.

[Egmont Koblinger (egmont-gmail)]

Hooray!

[MattRose (mattrose)]

Yay! Thank you very much!

I'll try and get Fedora and CentOS EPEL to pick up this release ASAP.

[Stephen Boddy (stephen-j-boddy)]

Matt, please be aware that someone who knows RPM packaging will probably need to properly update the terminator.spec file as the dependencies have changed. The debian/control file may give some clues, but even that might not be perfect yet on a freshly installed system. I've got so much accumulated history w.r.t. packages on my system it is not clear what packages are (probably) missing from the control file.

[MattRose (mattrose)]

I know RPM packaging really well (it's a lot of my $dayjob) and I'm a fedora package maintainer, though I'm not the package maintainer for terminator. I have a terminator.spec file that I used to build packages for fedora and CentOS here

https://copr.fedorainfracloud.org/coprs/mattrose/terminator/

They should be fairly easily picked up by the official package maintainers. I'll attach my spec here if you want to check it in

[MattRose (mattrose)]

Also attaching a patch file referenced in the spec, though I don't remember why it was necessary

[Stephen Boddy (stephen-j-boddy)]

OK Matt, so a quick side by side, and I have are a few queries.

In the original (http://bazaar.launchpad.net/~gnome-terminator/terminator/gtk3/view/head:/terminator.spec) the lines:
 1: %{!?python_sitelib: ...
12: BuildRoot: ...
Are no longer needed?

I'd rather the version was 1.90 (your spec has 1.99) just now to keep it in line with the project release number. Hopefully we can jump straight to 2.0, but just in case we need a couple of releases to settle any outstanding quirks.

The line in your spec file:
 9: Source0: http://code.launchpad.net/terminator/trunk/%{version}/+download/terminator-%{version}.tar.gz
is broken. First, the branch is gtk3, not trunk which is easy to change. The trickier bit is that Launchpad stripped the trailing zero when I created the release (first %{version}, so it is 1.9, not 1.90, although the second %{version} in the file is not tripped so is 1.90. So the working URL is:
http://code.launchpad.net/terminator/gtk3/1.9/+download/terminator-1.90.tar.gz
Not sure if the spec file can deal with this without resorting to hardcoding the values.

The patch is to remove a Unity desktop quick list entry to open a new window. Not too sure what the normal way of handling this kind of patching. Is it something that should be included as part of main release, or is it for the packagers to deal with.

No problems after that.

[Egmont Koblinger (egmont-gmail)]

For Fedora packaging terminator-1.90 see https://bugzilla.redhat.com/show_bug.cgi?id=1397825.

[Egmont Koblinger (egmont-gmail)]

And for Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807668.

[MattRose (mattrose)]

gtk3/view/head:/terminator.spec) the lines:
 1: %{!?python_sitelib: ...
12: BuildRoot: ...
Are no longer needed?

Yep. Buildroot is set by default to be relative the rest of the rpm build directory now, and the python_sitelib line was just a hack to set python_sitelib if it wasn't already set, and it's been safe to assume that this was set for a long time now.

Please set the version to whatever you want it to be. Right now we can probably set it manually to 1.90, but I'm wondering if there's a way to set it via bzr metadata instead.

I say hardcode the directory for now as well. If there's no way to tell exactly what launchpad is going to do with it, it's safer to hardcode it.

Attached spec file with the above fixes are attached.

[Dominic Hopf (dmaphy)]

Greetings,

just for the record, I actually am the Point of Contact for Fedoras
Terminator Package and I try to be fast when it comes to easy updates.
Just in case you've missed it, there is also is a Copr repository in
maintain, sometimes more regularly, sometimes not. You will find it here:

    https://copr.fedorainfracloud.org/coprs/dmaphy/Terminator/

The last build I've pushed there already was built from the GTK3 branch,
actually, and what I've pushed to Fedora now are changes
I applied from there.

I'm lucky to see there are other people also building Terminator for
Fedora, though and will be happy to join forces if you like.
Maybe maintain one Copr Repository together instead of two different ones,
maybe you also like to be a co-maintainer for the
Fedora package - just for the case I don't get around to do stuff in time
or you notice issues I didn't see so far.

I guess this also could avoid some duplicate work and probably we can get
the Fedora packages of Terminator to another level.

Feel free to contact me at: dmaphy at fedoraproject dot org if you're
interested.

Best Regards and have a nice evening!
Dominic

On Fri, Nov 25, 2016 at 12:18 AM, MattRose <email address hidden>
wrote:

> gtk3/view/head:/terminator.spec) the lines:
> 1: %{!?python_sitelib: ...
> 12: BuildRoot: ...
> Are no longer needed?
>
> Yep. Buildroot is set by default to be relative the rest of the rpm
> build directory now, and the python_sitelib line was just a hack to set
> python_sitelib if it wasn't already set, and it's been safe to assume
> that this was set for a long time now.
>
> Please set the version to whatever you want it to be. Right now we can
> probably set it manually to 1.90, but I'm wondering if there's a way to
> set it via bzr metadata instead.
>
> I say hardcode the directory for now as well. If there's no way to tell
> exactly what launchpad is going to do with it, it's safer to hardcode
> it.
>
> Attached spec file with the above fixes are attached.
>
> ** Attachment added: "terminator.spec"
> https://bugs.launchpad.net/terminator/+bug/1030562/+
> attachment/4782669/+files/terminator.spec
>
> --
> You received this bug notification because you are subscribed to
> Terminator.
> https://bugs.launchpad.net/bugs/1030562
>
> Title:
> Port Terminator to GTK+ 3
>
> Status in Terminator:
> Fix Released
>
> Bug description:
> The current version of Terminator uses GTK+ 2 and therefore doesn't
> integrate nicely with desktop environments based on GTK+ 3 (GNOME 3,
> Unity).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/terminator/+bug/1030562/+subscriptions
>

--
Diese E-Mail ist nicht mit GPG signiert, da ich sie vom Webinterface aus
geschrieben habe.

This mail is not signed with GPG because I wrote it from web interface.