Port Terminator to Python3

Rahmadani, just so I know, are you assigning this to yourself because you intend to work on it? If so, great! I'll set the bug to "In Progress". If on the other hand you didn't mean to or didn't realise what you did, let me know and I will unassign this.

I mostly created this for my self while planning future releases and what they'd contain.

Rahmadani, this project had a user who vandalised translations and changed bug assignee and status for no good reason, and refused to respond when contacted. After I had them banned, they came back and did it again under a new username, which also got banned.

I hope you are not them back again, so please just drop a quick line here confirming that you are not them. The reason I'm challenging you is that your account was created a few days after the second account got banned, and I think they also showed as Indonesian on their details page.

I'm going to put this ticket back to myself for now. Do NOT simply reassign it back to yourself. When you push a bzr/git branch into launchpad, or point me to a repository somewhere where it's obvious you are actually working on this with commits, I'll be happy (delighted!) for you to assign it back to yourself.

If you have no connection to that individual, please accept my apologies.

And just in case you do not speak English... Google Translate... which is probably wrong...

Rahmadani, proyek ini memiliki pengguna yang dirusak terjemahan dan berubah bug penerima dan status tanpa alasan yang baik, dan menolak untuk merespon ketika dihubungi. Setelah saya mereka dilarang, mereka datang kembali dan melakukannya lagi di bawah nama pengguna baru, yang juga kena banned.

Saya harap Anda tidak mereka kembali lagi, jadi silahkan saja menjatuhkan baris cepat di sini mengkonfirmasikan bahwa Anda bukan mereka. Alasan saya menantang Anda adalah bahwa akun Anda telah dibuat beberapa hari setelah akun kedua kena banned, dan saya pikir mereka juga menunjukkan sebagai Indonesia pada halaman rincian mereka.

Aku akan menempatkan tiket ini kembali ke diri saya sendiri untuk saat ini. TIDAK hanya menetapkan kembali kembali ke diri sendiri. Ketika Anda mendorong cabang bzr / git ke launchpad, atau menunjuk saya untuk repositori di suatu tempat di mana sudah jelas Anda benar-benar bekerja pada ini dengan komit, saya akan senang (senang!) Bagi Anda untuk menetapkan kembali kepada diri sendiri.

Jika Anda tidak memiliki sambungan ke individu itu, terimalah permintaan maaf saya.

Dan hanya dalam kasus Anda tidak berbicara bahasa Inggris ... Google Translate ... yang mungkin salah ...

Oh, and if you ignore me and assign the ticket back to you, I will assume you are the vandal. Then I will ask that you are banned again.

Oh, dan jika Anda mengabaikan saya dan menetapkan tiket kembali kepada Anda, saya akan menganggap Anda adalah perusak. Kemudian saya akan meminta Anda dilarang lagi.

I have a working branch using Python 3. I need to do some more testing and split the changes into nice commits, and I'll submit it for review / wider testing.

Here's my work, split in nice, small commits:

https://code.launchpad.net/~pochu/terminator/python3

I've been running it for a couple of weeks, no crashes and no exceptions. It just works flawlessly, at least for the use that I give it. There surely are bugs in codepaths that I don't use, so some wider testing would be appreciated.

There are a bunch of shebangs still pointing to python2, but we should just delete those I guess.

Hello,

Any news on getting pochu patch merged?

It seems to work fine here for me (no extensive testing though)

Ping? Can we get this reviewed / merged? I haven't experienced any issues since I posted it

Hey,
I only found a small issue while going through your branch as I ran pylint on it. There's one missed usage of cmp() in `terminatorlib/layoutlauncher.py`.

Also, if you make all shebangs point to python3 instead, `./run_tests` will fail because dicts are wrapping their values and keys you receive from the methods.

I'm adding a messy patch (this is my first time using bzr, I had a deep appreciation for git before that only grew with this experience) which fixes the tests, the cmp() use, makes all shebangs point to py3 and adds/removes pylint comments every now and then. It also removes some trailing whitespaces, I won't certainly block my IDE from doing that.

Feel free to use any of the patch freely, if you want. Generally this works, please, merge, python2 needs to die.

Hi, I'd also like to see terminator to be ported to Python 3 and since we seemingly have a working patch, I'd like to ask... Is there anything new in this matter? Are we waiting for anything particular? Thanks!

Oh, it seems that for the last two years the only commits added to terminator have been automated translation updates, am I right? I had no idea that the upstream is this not-alive. :-/

Yes, seems like developing is not so swift. I'd already tried to run this branch on my machine, but something went wrong. May be it's not a problem in project.

Huh, I've done some work on getting terminator working with python3, prompted by this Fedora (I'm one of the fedora maintainers) bug: https://bugzilla.redhat.com/show_bug.cgi?id=1737872

I'll check out pochu's branch mentioned here and see how far along it is, but I really think that the milestone needs to be moved up. v3.0 is nowhere in sight and in the 2 years since this bug was opened python2 has gone from "fall out of favour slightly" to "major linux distros are dropping support for it in the next 6 months" This cannot wait any longer.

Hi, MattRose!

Thank you for your comment! It's very good sign that people in distros take part in this work.

I've been already testing pochu's branch for one month. It works good for me, but I'm new to terminator, so I don't have any complicated terms in my configuration file and still don't use all terminator's features.

I found out that shebangs in some files still refer python2, so decided to take part in porting project to Python3. I changed all shebangs to refer to python3 and ran 2to3 on all files in project. All changes you can see in my branch: `lp:~hellodeargrandma/terminator/python3`.

I also made a PKGBUILD file for ArchLinux and now formalizing it to correspond AUR's rules for packages.

I'll branch from pochu's branch and apply the patch

My main concern is that nobody who has commit or release access seems to be concerned about this bug. We can get it all working perfectly but the work is lost if the work doesn't get merged in and released.

I just wrote to:
* Stephen Boddy
* Emilio Pozuelo Monfort
* Stanislav Laznicka

and asked them to take a look at this revived thread. I hope Stephen Boddy will help us with merging.

I just found the patch provided by Stanislav Laznicka applied it in my branch and pushed it.

Submitted a package to ArchLinux User Repository (AUR): https://aur.archlinux.org/packages/terminator-python3-bzr/

That looks really good. It works flawlessly except for one minor change (__next__ needs to be changed to next on line 85 of terminatorlib/searchbar.py).

I think it might be worth releasing a version of terminator that works only with python3.

Otherwise I would have to keep terminator in Fedora and EPEL by maintaining a big mother patch-set from the release tarball. I don't want to have to do this but It's really the only way I see things working on Fedora moving forward.

Yes, thank you for `__next__`. Fixed it.

Can you push that change back into your branch? I didn't see it there and I'd like to just keep pulling your changes rather than pushing my own branch and trying to keep it in sync :)

Whoops, nm. I just saw it. Thanks

So, we have a deadline of "mid-November" before the python2 pkgs are removed from Fedora.

I'll consult with the co-maintainer of the Fedora package and see if we want to create a package for Fedora Rawhide that somehow uses the `lp:~hellodeargrandma/terminator/python3` changes pulled in as a patch or series of patches against the released version into Rawhide and hopefully we can convince the Terminator maintainers to pull that code in and release it prior to the removal of python2 packages in Fedora.

We have first issue with this branch from AUR: https://aur.archlinux.org/packages/terminator-python3-bzr/#comment-704769

Interesting. I haven't tried using it w wayland. I know there were some issues with keybinding and wayland but this looks like it can't find the root window. I'm not sure how to debug that using wayland.

Maybe it's time to bite the bullet and actually install a full version of Fedora on my laptop.

I just came back from Gnome(wayland). Can't reproduce it on my machine. So I'm waiting for futher details from question author.

You are talking about duplicated message about parent window but I think we should look at "Gdk-CRITICAL **: 09:37:37.717: gdk_wayland_window_handle_configure_popup: assertion 'impl->transient_for' failed" first. I think it's not because of Python3 at all. It seems like some "GDK on Wayland" problem.

OK, so I was able to reproduce this ... kinda.

I ran the python3 version, and got the same error message.
I then installed the python2 version from the fedora repositories. It pulled in a few dependencies which I did not immediately note. Ran the python2 version and did not see the error message.
I then ran the python3 version again, and the error message was no more.

I think there is a python2 library still lurking somewhere.

I'll do a little investigation

Hmm.

Removed the system version of terminator and the python2 dependencies and now not getting that error message anymore.

See if he gets the error on subsequent runs, I guess. I hate debugging heisenbugs.

I just generated PPA on launchpad. There anyone can get python3-version built from my branch. I'll ask some friends to try it.

Hi,

Thanks all for looking into this. While I am no longer a user of terminator, I do think it is still quite important to get it working with python3.

I noticed a potential issue with my patch, I do think that the part which goes like

```
         self.layouttreestore.clear()
         layouts = self.config.list_layouts()
- for layout in sorted(layouts, cmp=lambda x,y: cmp(x.lower(), y.lower())):
+ for layout in sorted(l.lower() for l in layouts):
             if layout != "default":
                 self.layouttreestore.append([layout])
```

should really be
```
         self.layouttreestore.clear()
         layouts = self.config.list_layouts()
         for i, layout in enumerate(sorted(l.lower() for l in layouts)):
             if layout != "default":
                 self.layouttreestore.append([layouts[i]])
```
to keep the original casing of the layout.

Otherwise it's hopefully fine.

Good luck with the python3 port!

Just built a new revision. Debian packaging system rules are updated to use newer debianhelper and python3.
Now debianhelper runs tests so most of package dependencies added to build dependencies.

Branch become messy, so I need to clean it up with `bzr uncommit` and `bzr commit` before it can be merged.

Debs for Bionic, Disco and Eoan are available in mt PPA: https://code.launchpad.net/~hellodeargrandma/+archive/ubuntu/ppa.

I'm sorry, Stanislav, but what is the difference between

```
for layout in sorted(l.lower() for l in layouts):
    if layout != "default":
        self.layouttreestore.append([layout])
```
and
```
for i, layout in enumerate(sorted(l.lower() for l in layouts)):
    if layout != "default":
        self.layouttreestore.append([layouts[i]])
```
?

Originally, I was pickimg the layout value from a list that was modified so that all values are lower-cased. But that means if there was a layout that had upper-case characters, non-existent layout would be picked. The newer version fixes that by picking from the original list.

Oh, now I see. Thank you.

I'm sorry for holding you on this discussion, but I interested in you opinion about this approach I found:

https://stackoverflow.com/questions/10269701/case-insensitive-list-sorting-without-lowercasing-the-result#comment62761598_10269828

I like it because it lets us modify a single string in source code to get the same result.

Sure, you can use that

Ok, commited it.

Stephen Boddy still didn't answer neither to my e-mail nor to message on Launchpad. I read some threads in other bug reports and see that project looks like almost maintainerless. Do anyone know if projects on launchpad can have several maintainers?

Hi Grandma, others,

Thanks a lot for working on this!

What's your preferred way of sending bugreports?

Here's my first one, for Grandma's r1851:

Can't drag and drop terminals. Have more panes or windows, drag one at its red bar, drop it over another terminal. When dropping it says:

Traceback (most recent call last):
  File "[...]/terminatorlib/terminal.py", line 1019, in on_drag_data_get
    str(data.terminator.terminals.index(self)))
TypeError: Item 0: Must be number, not str

Cool. I think this was probably caused by one of the manual conversions that Grandma or I did. I'll see if I can code up a fix

Ugh. It looks like the API for that call has changed, and the code was mysterious to begin with, as evidenced by this docstring:

"""I have no idea what this does, drag and drop is a mystery. sorry."""

I think the function takes less arguments now, so gets confused when called. I'll take a poke at it when I get some time

Hi everyone.

If talking about bugreports, I think it's better to use this thread now.

About bug:

I found a thread (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698459) where such bug is discussed. I fixed this one and pushed as revision 1852.

I saw some places similar to this one, they looks good, but such problem can be found everywhere else in code.

Yay! r1852 fixes that problem. Thanks Grandma. That was a good catch on that.

Thanks!

Taking a look at the broader picture:

A few years ago (during the GTK3 porting) I talked to Stephen in private mail, and it happened that we hit a tiny little bit more informal/personal tone than usual in professional environments. Thanks to this, I felt that after seeing him completely disappear, I should send him a mail going like "hey, how are you doing, I hope everything is fine" and nothing more, which I did this July. I didn't get a response either.

I'm afraid we can't exclude the possibility that he won't (can't) come back to this project any more. Grandma, MattRose, others, I think you should start thinking whether you wish to take on this project. You might ask Launchpad folks to grant you access to the repository (I don't know how it goes), or contact the project's previous maintainer Chris, or fork it (maybe even moving to github/gitlab or whatever, maybe slightly rebranding e.g. as terminator3), preferably in a way that more than 1 person has admin access.

There are quite a few other pending bugs, some of them are really low-hanging fruit (fixable in a minute or two), e.g. multiple reports about feed_child() taking the wrong number of parameters, or one about GTK no longer supporting narrow vs. wide pane separators, or revealing the new features of recent VTEs. Maybe it's your turn now to decide whether you focus solely on Python3 and nothing more, or start making some fixes like these, or even do an entire takeover of the project and give it a big boost (which many people would surely welcome and appreciate).

I was going to respond to the bug, but I think it's best if we take this
private for now. This has been on my mind for a while now. I think
Terminator is a fantastic program but it is in real danger of being
bitrotted away and becoming un-useable. I have been seriously thinking
that it would be a good idea if I were to fork the repository into
github and call the new package python3-terminator. I'm very glad to
see other people have been thinking along the same lines. I'm a little
wary of taking on the maintainership myself as I don't really know the
gobject api very well, but it seems to have come to that point. I would
be eternally grateful for a little help in getting the process going and
some ongoing maintainership. I'm not sure where to start right now.

Grandma, would you be willing to take on a maintainership? The work
you've done on the python3 branch has been a life-saver and has allowed
me to continue using terminator on fedora.

Matt

-------- Original Message --------
Subject: [Bug 1662544] Re: Port Terminator to Python3
Date: 2019-10-22 04:03
 From: Egmont Koblinger <email address hidden>
To: <email address hidden>
Reply-To: Bug 1662544 <email address hidden>

Thanks!

Taking a look at the broader picture:

A few years ago (during the GTK3 porting) I talked to Stephen in private
mail, and it happened that we hit a tiny little bit more
informal/personal tone than usual in professional environments. Thanks
to this, I felt that after seeing him completely disappear, I should
send him a mail going like "hey, how are you doing, I hope everything is
fine" and nothing more, which I did this July. I didn't get a response
either.

I'm afraid we can't exclude the possibility that he won't (can't) come
back to this project any more. Grandma, MattRose, others, I think you
should start thinking whether you wish to take on this project. You
might ask Launchpad folks to grant you access to the repository (I don't
know how it goes), or contact the project's previous maintainer Chris,
or fork it (maybe even moving to github/gitlab or whatever, maybe
slightly rebranding e.g. as terminator3), preferably in a way that more
than 1 person has admin access.

There are quite a few other pending bugs, some of them are really low-
hanging fruit (fixable in a minute or two), e.g. multiple reports about
feed_child() taking the wrong number of parameters, or one about GTK no
longer supporting narrow vs. wide pane separators, or revealing the new
features of recent VTEs. Maybe it's your turn now to decide whether you
focus solely on Python3 and nothing more, or start making some fixes
like these, or even do an entire takeover of the project and give it a
big boost (which many people would surely welcome and appreciate).

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1662544

Title:
   Port Terminator to Python3

Status in Terminator:
   In Progress

Bug description:
   Python2 is starting to fall out of favour slightly (i.e. not included
   by default on some distros).

   It is time we moved away from the old version, and onto Python3.

To manage notifications ab...

This has been on my mind for a while now. I think Terminator is a fantastic program but it is in real danger of being bitrotted away and becoming un-useable.

Nitpicking: I don't fancy the name "python3-terminator". The vast majority of users don't give a damn about which programming language it is written in. IMO the name shouldn't refer to it.

Whoops. I didn't mean to send comment 44 to the bug. I don't want to take over from Stephen and Chris without their blessing, and even if I were to fork it, which is looking more and more likely, I wanted to make the heritage of the project clear. Another name I had in mind was RoboTerm, as an homage to the "Robot future of Terminals" tagline.

This is getting really meta, I'll see if I can send Grandma a message outside of the bug. We should see if we can meet in IRC or Slack or something at some point if people are willing.

I did think about fork too, but I prefer to do it openly to let others see the history.

Let's create another issue here to go somewhere from this thread and discuss what should we do and how.

Creating an issue. Trying to describe the current state of things.

Placed it here: https://bugs.launchpad.net/terminator/+bug/1849375
Just described the situation and moved there some questions we asked in this thread.

Suppose to leave this thread for python3 issue.

I've just realized that there's been a truly unfortunate lack of information flow here.

Emilio did submit his python3 port to the Debian package versioned 1.91-2 a long time (1.5 years) ago. So it's been in Debian experimental, later in unstable, and eventually in stable for quite some time.

Debian Buster (10; released in 2019-07), Ubuntu Disco (19.04) and Ubuntu Eoan (19.10) all ship python3-based terminator (numbered 1.91-4).

The exact changes (in form of patches on top of mainstream 1.91) can be found at e.g. https://packages.debian.org/buster/terminator -> terminator_1.91-4.debian.tar.xz. There are three relevant patches inside: a big one, and two tiny followup ones.

The existing work should be merged. E.g. check if the Debian/Ubuntu patches are indeed the same as Emilio's branch (at which commit). Whether Emilio's branch also contains the two tiny followup patches, and/or other commits, and if so then whether Roman's branch also contains them. If not then evaluate and merge them back to whichever other branches where development currently happens (Roman's branch I guess).

The latest Debian and Ubuntu bugreports should be interpreted knowing that they might be about Python 3:

https://bugs.launchpad.net/terminator/+bugs?orderby=-id&start=0
https://bugs.launchpad.net/ubuntu/+source/terminator/+bugs?orderby=-id&start=0
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=terminator

In particular, these two seem to need attention:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939929
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941479

The good news is that this way the python3 work has already received much wider testing than we hoped for, and apparently there aren't many problems to worry about.

MattRose, this might mean that you should perhaps just go ahead with the current python3 work for the Fedora package, rather than applying for exceptions.

1.91 tarball is revision 1749 (according to the bzr tag).

Emilio forked at 1775. Not much changed in the main repo between 1749 and 1775, it's mostly translation updates. Since 1775 the main repo received only translation updates.

Emilio's branch is currently at 1785, and the big Debian/Ubuntu patch is the same as 1775..1785 (except that it's applied on top of 1.91, that is, the 1749..1775 changes aren't included in the Debian/Ubuntu packages).

Roman forked Emilio at its current head 1785 and continued from there. Currently it's at 1852.

The first additional tiny Debian/Ubuntu patch ("Fix drag&drop for Python 3", no bug reference) isn't yet there in any of the bzr branches.

The second additional tiny Debian/Ubuntu patch ("Fix Python 3 related issues with layout selection", https://bugs.debian.org/921824) isn't there either in any of the bzr branches, except the first half of the patch where Roman accidentally came up with the same fix (in 1825 and 1848).

So, the currently known changes that are missing from Roman's 1852 are:

- Debian's python3_drag_n_drop.patch (might need to ask its author Markus for more context if it's unclear what this patch does);

- The second half of Debian's python3_layouts.patch (might need to study the Debian bug, or contact its author Markus for more context if it's unclear what this patch does);

- Automatic translation updates.

Roman, could you please look at those two tiny patches, see if you can reproduce a bug that they fix, and if so then apply to your branch?

Debian's python3_drag_n_drop.patch might be equivalent to Roman's the latest commit (1852). In that case there's nothing here to do.

New python3 bug (reincarnation of bug #1518705):

Drag-n-drop a link from Firefox. Gives this error:

    Traceback (most recent call last):
      File "/home/egmont/src/terminator-py3/terminatorlib/terminal.py", line 1102, in on_drag_data_received
        txt = txt.split('\n')[0]
    TypeError: a bytes-like object is required, not 'str'

Drag-n-drop a file from Nautilus. Gives this error:

    Traceback (most recent call last):
      File "/home/egmont/src/terminator-py3/terminatorlib/terminal.py", line 1104, in on_drag_data_received
        txt_lines = txt.split( "\r\n" )
    TypeError: a bytes-like object is required, not 'str'

This patch fixes DND. Should be tested at least from Nautilus and from Firefox (different code paths are executed in those cases).

The patch looks big, but it isn't. Most of this is indentation fix, I moved a part of the code one level deeper, to the only branch where it can be executed. It was an obvious followup of the tiny reorganization at the MOZ vs. non-MOZ branch which I had to do anyway.

feed_child() takes a bytes object instead of str, I don't know why, so I had to encode there to make other use cases, such as "Insert terminal number" work too. Also I had to switch to feed_child_binary() for other reasons, namely https://gitlab.gnome.org/GNOME/vte/issues/201, which has the lucky consequence that the bug about the wrong number of parameters being passed to feed_child() is also gone – well, gone partially, there's another place in the source where that needs to be fixed, probably using the same one-liner trick as here.

Stephen, whenever you come back to this, I recommend that you do some commit-squashing and similar bookkeeping type of work on Roman's branch, rather than merging it as-is. It's some extra work, but results in a much cleaner commit history.

It's 67 patches at this moment, most of them are super tiny. Instead, they could probably be made into about a dozen patches of reasonable size and reasonably related functional changes. E.g.:

Many patches only change the shebang line of one file. A single patch should change them all, at once.

r1825 contains a few functional changes, and tons of whitespace fixes. Whitespace fixes (if desired at all) should receive their separate change.

Many changes add another extra pair of parentheses to a "print" call, making it IMO unnecessarily harder to read. I would drop them.

Quite a few changes change back and forth between "next" and "__next__", the final desired state should be achieved in a single commit.

All changes to debian/* could probably be squashed.

In fact, IMO the few tiny actual python3 code fixes could also be squeezed into a single change.

Etc...

So, I know that I should have taken the debian fixes and applied that, but instead, I took Roman's branch, did a big diff between that and the 1.91 release tarball and submitted that to fedora Rawhide. It should, if there are no subsequent releases, land in Fedora 32, which is in time for the big python2 deprecation that is happening in F32.

Caveats: It doesn't work at all with python2. I figure python2 is not going to be available with F32 anyways, so why bother. It also doesn't have Egmont's latest DND fix, tho if I get some time I'll probably throw that in as well.

I'll take a look at the debian bugs and patches and see if there's anything in there that I can pull in as well.

On a meta note, this is a lot of duplication of effort. I'll reach out to the maintainers of the debian port to see if we can co-ordinate this a little better, as Stephen seems to have stopped responding again.

Added Egmont's DND fix to the fedora package. A fix for the first bug in the list seems fairly easy to reproduce, the other one, well, I've been meaning to look at upgrading the python vte library that terminator uses, but I haven't yet and there's some deep gtk voodoo there...

> On a meta note, this is a lot of duplication of effort. I'll reach out to the maintainers
> of the debian port to see if we can co-ordinate this a little better, as Stephen seems
> to have stopped responding again.

I'm the Debian maintainer and the one who originally ported Terminator to Python 3 (as you can see in comment 4 / 6). After having this in Debian for over a year with no major problems I'd say that we just merge it plus any additional fixes that we may have and release a new version (2.0-beta1 or whatever). I'd volunteer to do some maintainer work upstream, such as reviews, merges, releases, etc. I didn't speak earlier as I don't have a lot of time to put into this, but given the current situation I've changed my mind.

Stephen, if you're happy to give me maintainer access, that'd be great. I'm a Debian Developer, GNOME member, and was an Ubuntu developer in the past.

I would love to be able to do this, but none of us have the proper access to create releases. I've asked Stephen for maintainer access as well, but he hasn't responded that I'm aware of.

I'll take a look at your branch. I just realized it was linked in the bug.

> [Emilio] Stephen, if you're happy to give me maintainer access, that'd be great.

That would be lovely! Thanks a lot Emilio for your work so far, and volunteering to further help the project!

Also thanks Matt for updating the RH package!

It's great to see two leading distributions coordinate.

> I've been meaning to look at upgrading the python vte library that terminator uses

What problem did you run into?

GTK3 uses the GLib introspection thingy, which basically means that VTE ships a .../girepository-1.0/Vte-2.91.typelib file, and Python loads the actual library and finds the symbols via this one. In Fedora this typelib file is shipped by the main vte291 package, in Debian/Ubuntu it's a separate package.

In theory, all you need to do is install a new VTE (preferably from Fedora package), including this typelib file, overwriting the previous ones.

I think there's a few compatibility issues with running on the latest vte, but this is a good start to tracking them down. I may send you emails if I get stuck with stuff :)

There's another, independent python3 fork of terminator.

I've come across that one via, and expressed my opinion at https://bugs.archlinux.org/task/65788.

I have been using the Ubuntu terminator, that includes Egmont's python3 work, with few problems. I think having the gtk3 branch moved to python3 would make maintenance simpler. If no one has an objection I'd like to go ahead and land this work.

Python3 porting was mainly Emilio's work.

> I'd like to go ahead and land this work.

Everyone would like to, but apparently we cannot count on the current maintainer. See #1849375 for details. Last October-November he promised he would merge the current work around Christmas time. Nothing happened since then.

Don't know what by "land" this work you mean: Do you have commit access to his repo? Even if so, force-pushing to a foreign project without the owner's approval doesn't sound right. Or forking? We already have too many, but still, if you could take Roman's branch, which is a continuation of Emilio's, and continue that with a few more patches, that could be nice. Or even better: try to get in touch with the maintainer and get him finally do something. ;)

Thanks!

This issue will be addressed in the new fork of Terminator on GitHub
https://github.com/gnome-terminator/terminator/pull/6

What I meant by "land" was to commit it into the Terminator bzr repo, since I have commit access to it. However, it sounds like there's been too much divergence in forks for there to be much value in bringing the bzr tree up to date.

Unfortunately, nobody with commit access has actually updated the code or released anything in over 3 years now. This has led to a situation where distro maintainers have had a hard choice.

Either drop the package, which no-one has wanted to do because they and their distro users still find it extremely handy, or maintain their own python3 patch sets.

the truth is, nobody, not even ubuntu, is running the code directly from this bzr repo anymore. the only reason terminator is still widely available at all is because the various maintainers have put in the work to keep the code up-to-date.

Seeing that at least three of us were doing parallel work to keep terminator working on our various distros @lazyfrosch took the brave step of porting the code to somewhere where we could effectively stop duplicating our efforts, and instead work on the code together.

If you read through this bug, and https://bugs.launchpad.net/terminator/+bug/1849375 you can see that nobody wanted to do this, but frankly, it came down to either forking the project, or letting it die, and enough people wanted it not to die that a fork was deemed the only alternative.

Thanks Markus for taking that step forward and moving the project elsewhere so that we can keep maintaining it. I wanted to do that too, but since you've done it first, I'll just offer my help in maintaining it and reducing the bus factor. My github handle is @epozuelo.