Guake: Guake 3

[aichingm]

Over the last couple of days I have had the time to port guake to python3, Gtk3 and Vte 2.901. Currently I would say at least 90% of the functionality is ported and tested. But it sill is a port and not a rewrite! Since the switch to Vte 2.901 solves a lot of bugs from the issue tracker I would like to push my changes back to the project.
But how? Some ideas:

1. remove the old python2+gtk2+vte0.x stuff and let the repository evolve into the new version
2. keep the two versions on separate branches and just let them co exist. One on master and one on ether guake2 or guake3
3. since guake is already part of en organization a new 'guake3' project could be created to be the new home of the new version.

Since the new version is a massive jump, has a lot of different dependencies and is under no circumstances a drop in replacement I'm not sure that 1. would be a good idea.
Keeping two versions of a program in the same repository seems also not optimal since the issue tracker will become cluttered and hard to manage. Option 2. will also raise the question which version should be on the master branch and such...
The third option is my favorite opinion but it also has some flaws for example it could divide the community and could lead to a work overhead which usually comes with maintaining two different versions which do not even have the same code base most of the time.

Is it even the "plan" to slowly put the guake as it is now to sleep and move on to python3/Gtk3/Vte2.90? or should guake stay a it's current state?
What do you guys think? @Stibbons @pypingou @clarete @ulidtko

Some words about the port:

• For the moment both versions are on the same branch which makes it impossible to maintain the build infrastructure as it is right now (needs to be fixed)
• A lot of code is simply duplicated.
• The whole repository needs to be cleaned up (a lot of test files)
• The code should be organized differently
• And there are still a few things to port

You can find it at https://github.com/aichingm/guake, clone it, checkout the 3! branch and run ./dev-gtk3.sh

[gsemet]

Hello! This is quite a very good surprise! So first I'd like to thank you a lot for this work and will to contribute it back to the Guake community.
There have been several attempts to rewrite from scratch on gtk3, one being done by @mouseratti on the guake3 branch. Reaching the same level of features requires lot of work, at least need to get the time and commitment to do it. I have to admit I didn't worked on it as I wanted, maybe a lack of commitment from my part...

So, what next? My point of view is that the gtk2 stuff is meant to die in the short/mid term, vte is too old and too buggy and update requires to jump to gtk3, exactly the work that you've done. So, yes, let's kill Guake-gtk2 (ie, put it to sleep).

I propose the following option, that look similar to your idea 1:

• you pull your changes to a branch on the Guake project. I don't think we should have another git project, it is still guake :) Merge will be easier, tracking will be easier, and ultimately this will replace the gtk2 version. You can land your changes on a branch named "3!" like you did, or on the old "gtk3" branch (simply replace its content)
• if you agree, we can work together if work is still needed to merge it back to "master" asap.
• Meanwhile, I put the gtk2 branch to a dedicated branch, somethink like "guake-gtk2" or "guake 0.8.x". On this branch there will be only support for bug fixes and other community patches on the 0.8.x version.
• Later, we can work to integrate it with the work done on the `guake3 branch. @mouseratti, I don't want you to think your work will not be used. At the end, I want to merge both contributions. and I think rewriting parts of Guake is still needed, for example I would like to rewrite the "notebook" model to support split screen and load/save session, you have worked on the pref panels, and so.

In the beginning I wanted to have a clear jump in the version of Guake from 0.8 to 3.0, matching the jump to Gtk3 and lot of big new features. It looked cool. But I think this is a change to big to be done in one big bang change on a "small" project like guake, I simply don't have enough time to do it all at the same time.

So, I now think incremental changes is the way to go. @aichingm, I don't know if your version will be called "Guake 3" or "Guake 2" or "Guake 0.9" but it looks like it is meant to replace the master branch in the short term (I work on it this week). I'll do the change on the branches scheme, update the README, maybe release a last 0.8 version and work on your changes asap.

Thanks a lot for this work !

[egmontkob]

Hi guys,

(A VTE developer here...)

Thanks a lot to both of you for working on this!

Guake is a truly popular terminal emulator. Whether it's the actual terminal emulation behavior (VTE) or the UI around it that is more important for most people is hard to tell. Probably some combination of the two.

VTE has received tons and tons of fixes and improvements during the last couple of years. There is a point, maybe not yet at 90% but maybe at 95% or 98% or who knows, where you should probably say the improvements offered by new VTE surely outweigh the few regressions in new Guake. It's your choice, I'd only like to ask you not to aim for 100% as it'll probably never be reached.

You keep mentioning here and in README.rst that you've ported to VTE library version 2.90 (which corresponds to tarball versions up to 0.36). Luckily, by looking at the source it seems that you actually ported to 2.91 (tarballs from 0.38). This was an incompabitle change 3 years ago. The 2.90 branch, just as the gtk2 one, is no longer maintained. Furthermore, most distributions have already dropped the "middle" (2.90) version of the package, whereas they're yet to get rid of the gtk2 one.

Looking forward to a stable gtk3 release obsoleting the gtk2 one as soon as possible :-)

Feel free to ask me if you have questions related to VTE.

PS. According to my experiences, complete rewrites hardly ever work. Tons of incremental changes, trying to keep the stuff as stable as reasonable, is the way to go.

[aichingm]

Hey,
So let it be option 1., I'm fine with that. I think as long as it is not merged into master the best way is to keep it on its own branch '3!' and keep gtk3 along, just keeping it simple. I would very much like to work to together on this since I have not jet touched the build system (including documentation and translation) and there might be someone who has more experience with it.

Sounds like a good plan to me. I have a short list of things which should be done before merging it into master (I think guake should at least be buildable and run in at least most cases before I would shove it into master).

Keeping the gtk2 version on a separate branch is probably a good idea too since there are some (15+) commits which have not been "released" jet.

I was thinking the same thing, the port should only be the beginning of the gtk3 story and give developers the possibility to make small changes in certain areas of the project to bring it back to speed. I came across some nice bits of code on the gtk3 and guake3 branches which definitely should be pulled-in at some time.

@egmontkob It seems that I lost a single bit there 😉. I will update my comments and files, thanks. And also thanks for VTE 👍

[gsemet]

yes, we do not emphasis enough the crucial role of VTE. It does almost all the jobs actually, Guake is just a wrapper around it.
So, @aichingm, feel free to push your pull request on "3!" branch when you feel ready!

[egmontkob]

FYI: Remove old vte package from Ubuntu 18.04 LTS.

Looks like Guake will probably be removed from Debian and Ubuntu. I guess you may have a few days or weeks (not sure) to release a stable gtk3-based version to stop this from happening.

[gsemet]

Hello. Thanks for the notification. Port now almost work, thanks to the amazing work of @aichingm !
I have time to work on it this week, I think I can release the first version in a few days :)

time to clean, then notify maintainers :)

[shirishag75]

Cool, Look forward to it, it might actually help with guake appearing in MATE's notification area. I just realized I never shared it on guake bug tracker but had shared it on debian. Basically in few old installations where mate new version is there, guake runs but the guake box in the notification area is not seen. I had a thought/doubt that it might be as MATE WM (Window Manager) updated to gtk3 about 6 months back and there was no sign of guake being released with gtk3 yet.

This would indeed be a big news.

I do hope there is a blog post which shares about the process that lead to the new version, more crucially the actual set of dependencies that have changed so users like me who are dependent on VTE and guake can also prod maintainers on our own levels as well to have it in our repositories as well.

Looking forward to the new release.

[jbicha]

Hi, I opened the Ubuntu bug. To be a bit more precise, the new version of guake needs to get into Ubuntu (probably via Debian) by the end of February if you want to ensure it will be available in Ubuntu 18.04 LTS.

After that point, you will need to find an Ubuntu developer to help you get any smaller bugfix updates into Ubuntu.

[egmontkob]

@Stibbons Fingers crossed! I'm happy to do a few hours of testing, I guess the best time for that is after the "first version in a few days".

[gsemet]

gtk3 port done. Thanks @aichingm ! I fix a few bugs and officially release Guake 3 in a few days. Hope we don't miss the debian/ubuntu update (the debian maintainer already contacted me)

[Moritz90]

@Stibbons This is great news!

Is anyone working on packaging it for the current version of Ubuntu? I'd love to have a less buggy version of guake before the next Ubuntu release. ;)

[gsemet]

yes I have someone for debian, and ubuntu should use this package. Can you test this Guake 3 and see what features are broken so we can try to fix it asap?

[shirishag75]

I guess Daniel would be the person who would be doing the packaging for Debian. If and when he puts it on experimental, I would be happy to test and report any brokeness I see.

Also usually Ubuntu takes lots of stuff from Debian, the same might be the case with this too, IIRC the only thing that would change are the headers and maybe some sub-version numbers

Looking forward to see the new guake3 port in debian experimental/unstable/sid.

[egmontkob]

Here's how it works according to my best knowledge. I might easily be wrong, though.

In Debian, packages make it to experimental first, then unstable, then testing, then stable. I have no clue how much it takes from experimental to unstable. As far as I recall, from unstable to testing is pretty much automatic and happens in about a week unless there are known troubles with the package.

In Ubuntu, most packages (probably Guake too) are set to automatically be synced from Debian testing. For Bionic, this auto import will stop on Mar 1. After this point it's still possible to get an update, but requires a contact person who's happy to work on it.

So, ideally, the safest path is to make sure it arrives at Debian testing way before Mar 1, which probably means unstable before Feb twenty-few, which mean experimental I-don't-know-when. I guess this process should be started now with the beta release (as far as I understand Daniel already took care of it), and then hopefully there'll be time for another one (or maybe even two) updates based on feedback, in time for Bionic.

Please do _not_ rely on any of this being true!

[shirishag75]

it's a bit different. some will be in experimental, most packages usually come by unstable. The shift to testing is 'usually' 10 days or more or less depending on what the maintainer/uploader thinks of the packages. If there aren't any serious bugs then they may go to testing within 10 days.

See for e.g. usbutils

 % apt-cache policy usbutils
usbutils:
  Installed: 1:009-2
  Candidate: 1:009-2
  Version table:
 *** 1:009-2 100
          1 http://httpredir.debian.org/debian experimental/main amd64 Packages
        100 /var/lib/dpkg/status
     1:007-4+b1 900
        900 http://httpredir.debian.org/debian buster/main amd64 Packages
          1 http://httpredir.debian.org/debian unstable/main amd64 Packages

see also https://tracker.debian.org/pkg/usbutils and specifically see the dates, you will get to know what I mean.

[gsemet]

Apparently, the integration in debian is underway: https://mentors.debian.net/package/guake