meld issueshttps://gitlab.gnome.org/GNOME/meld/-/issues2024-03-08T06:50:26Zhttps://gitlab.gnome.org/GNOME/meld/-/issues/307Overtly inventory all known use-cases of 3-way and 4-way merging and rebasing...2024-03-08T06:50:26ZZUERCHER, AndreasOvertly inventory all known use-cases of 3-way and 4-way merging and rebasing. Add them as modes-of-operation on opening dialog.Currently, Meld supports only a subset of the use-cases that kdiff3 and (more to the point) Araxis Merge support. For inter-branch merge of prebugfix-to-postbugfix along an origin branch to destination wavefront-of-development along ano...Currently, Meld supports only a subset of the use-cases that kdiff3 and (more to the point) Araxis Merge support. For inter-branch merge of prebugfix-to-postbugfix along an origin branch to destination wavefront-of-development along another branch where those 2 branches have a common ancestor as point of commonality of the 2 branches (hence 4-way merging to a 5th output merge-result file:
1. origin-branch prebugfix,
2. origin-branch postbugfix,
3. common ancestor,
4. destination-branch prebugfix wavefront,
5. output-only: destination-branch postbugfix as destination-branch wavefront henceforth),
both Perforce integration and git integration expect such a 4-way merge that Meld does not currently support.
A variant of the 4-way merge above is to lack the common ancestor, then infer what that common ancestor would have been from the commonality between the origin-branch prebugfix and the destination-branch prebugfix wavefront. It appears that this is what kdiff3 does to support the use-case above via only a 3-way merge.
Of course, there is the simple 3-way merge without respect to the deltaing on an origin branch being applied to the destination branch. In this use-case (which Meld already supports) the 3 peers are considered co-equal without any particular historical or progressing-wavefront relationship between them.
But there may be other use-cases too. Each needs to inventoried. Each needs to have a choice on the opening dialog of Meld. Each needs an image depicting it pictorially.https://gitlab.gnome.org/GNOME/meld/-/issues/306Add dark mode as accessibility for vision-impaired users.2019-04-03T07:24:19ZZUERCHER, AndreasAdd dark mode as accessibility for vision-impaired users.Some user's visual processing is more accommodated by inverting all colors. Because white-background-based color schemes have usually been thought out and debugged (as not causing difficult-to-see lacks of contrast or lacks of hue), acc...Some user's visual processing is more accommodated by inverting all colors. Because white-background-based color schemes have usually been thought out and debugged (as not causing difficult-to-see lacks of contrast or lacks of hue), accessibility in this topic usually XORs the RGB color (think the hexadecimal form) with 0xFFFFFF, keeping alpha channel / transparency the same, if present.
As phrased, this feature would _not_ be a grand color-scheme editor, nor even a new color scheme. It would simply be a checkbox that inverts any existing color scheme to be black-based & distance-from-black-based instead of white-based & distance-from-white-based, so to speak.https://gitlab.gnome.org/GNOME/meld/-/issues/305Unix Line Endings2019-10-10T22:42:08ZGhost UserUnix Line EndingsWhen writing, saving, merging, starting from blank comparison, Meld writes Unix line ending to my files.
Can the line endings be preserved?
I'm using Meld 3.18When writing, saving, merging, starting from blank comparison, Meld writes Unix line ending to my files.
Can the line endings be preserved?
I'm using Meld 3.18https://gitlab.gnome.org/GNOME/meld/-/issues/304ValueError: max() arg is an empty sequence2019-03-29T02:04:54ZGhost UserValueError: max() arg is an empty sequence```
File "/usr/lib/python3/dist-packages/meld/task.py", line 108, in iteration
ret = next(task)
File "/usr/lib/python3/dist-packages/meld/dirdiff.py", line 775, in _search_recursively_iter
differences |= self._update_item_sta...```
File "/usr/lib/python3/dist-packages/meld/task.py", line 108, in iteration
ret = next(task)
File "/usr/lib/python3/dist-packages/meld/dirdiff.py", line 775, in _search_recursively_iter
differences |= self._update_item_state(child)
File "/usr/lib/python3/dist-packages/meld/dirdiff.py", line 1305, in _update_item_state
newest_time = max(existing_times)
ValueError: max() arg is an empty sequence
```
- meld 3.18.0
- Python 3.6.7
- Linuxhttps://gitlab.gnome.org/GNOME/meld/-/issues/303Crash on UTF-8 SQL Files containing backslashes2019-03-29T02:07:23ZGhost UserCrash on UTF-8 SQL Files containing backslashesI use [SSDT](https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?view=sql-server-2017) for my database projects. I use Meld as my diff & merge tool. It was crashing today on specific files. I was able to narr...I use [SSDT](https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?view=sql-server-2017) for my database projects. I use Meld as my diff & merge tool. It was crashing today on specific files. I was able to narrow it down and make it reproducible. Looks like it will crash when all of the following are true:
- SQL files (_i.e._ files ending in `.sql`)
- with UTF Byte Order Markers (`ef bb bf`) at the front of the file
- the file contains a backslash
```sh
me@hostname:/tmp$ mkdir test
me@hostname:/tmp$ cd test
me@hostname:/tmp/test$ git init
Initialized empty Git repository in /tmp/test/.git/
✔ /tmp/test [master L|✔]
14:56 $ echo -e "\xef\xbb\xbf--
select foo + '\' + bar;" > foo.sql
✔ /tmp/test [master L|…1]
14:56 $ meld --version
meld 3.18.0
✔ /tmp/test [master L|…1]
14:56 $ meld foo.sql
**
GtkSourceView:ERROR:gtksourcecontextengine.c:5543:update_syntax: assertion failed: (g_slist_length (ce->priv->invalid) <= 1)
Aborted
✘-ABRT /tmp/test [master L|…1]
```https://gitlab.gnome.org/GNOME/meld/-/issues/302Meld doesn't store preferences (due to "gsettings-backend-dconf" not being in...2023-12-09T15:30:07ZGhost UserMeld doesn't store preferences (due to "gsettings-backend-dconf" not being installed)Currently, I'm using Meld 3.18.0 in openSUSE Leap 15 and it doesn't store any preferences.
Any settings changed from the "Preferences" window are not persisted after restating the application.
There's nothing related to meld in ~/.config/.Currently, I'm using Meld 3.18.0 in openSUSE Leap 15 and it doesn't store any preferences.
Any settings changed from the "Preferences" window are not persisted after restating the application.
There's nothing related to meld in ~/.config/.https://gitlab.gnome.org/GNOME/meld/-/issues/301Saving file in mounted CIFS folder failes2023-02-01T20:24:20ZGhost UserSaving file in mounted CIFS folder failesHow to reproduce:
- compare 2 folders within the mounted folder
- find a file that differs and display it in the diff window
- modify the file on the left hand side and save it
- receive the attached screenshot
- Refresh (Ctrl+R) -> modi...How to reproduce:
- compare 2 folders within the mounted folder
- find a file that differs and display it in the diff window
- modify the file on the left hand side and save it
- receive the attached screenshot
- Refresh (Ctrl+R) -> modified file got deleted
Some background to the mounting:
- CIFS mounted folder via fstab into my home directory `//build.server.corp/myuser /home/myuser/mounts/buildserver cifs credentials=/home/myuser/.smbcredentials,rw,uid=myuser,gid=myuser 0 0`
- both dir in the same mounted folder
- manual mount using sudo mount -a
- tried the same folderstructure on my local filesystem with no errors
- meld version 3.18.0
![screenshot](/uploads/c5577e9460fec0d0c882e1531ad68fb7/Screenshot_from_2019-03-19_08-13-01.png)https://gitlab.gnome.org/GNOME/meld/-/issues/300Please add an option to make instances completely independent (make DBus conn...2024-01-09T22:08:15ZyurivictPlease add an option to make instances completely independent (make DBus connectivity optional)Currently, when one instance of meld is running, I can't commit from the other instance and enter the git password. When the password is asked by git, both melds get frozen.
My suggestion: users who don't really benefit from the DBus co...Currently, when one instance of meld is running, I can't commit from the other instance and enter the git password. When the password is asked by git, both melds get frozen.
My suggestion: users who don't really benefit from the DBus connectivity, and only get affected by related bugs, should be able to run instances w/out DBus connectivity.https://gitlab.gnome.org/GNOME/meld/-/issues/299Find/replace modernisation2019-04-13T02:21:23ZKai WilladsenFind/replace modernisationFollowing up from #297.
Meld's current find bar implementation is in an old style that isn't really shared by any other applications. While we have different considerations (specifically multiple related panes), it would be be nice to t...Following up from #297.
Meld's current find bar implementation is in an old style that isn't really shared by any other applications. While we have different considerations (specifically multiple related panes), it would be be nice to try to share a design with *something* else.
Probably the closest design to something that we could use is from the Builder design page:
https://wiki.gnome.org/Apps/Builder/SearchAndReplace
However, anything like this would need some prototyping to see how we could integrate it, where the search bar could be packed, etc.https://gitlab.gnome.org/GNOME/meld/-/issues/298Titlebar changes2019-03-09T20:39:18ZmondayTitlebar changesWith retirement of app menus, meld's titlebar became headerbar. Headerbar with a single button looks weird, since Meld also has a menubar, also it consumes extra pixels from the screen. Consider adding hamburger menu as an item to menuba...With retirement of app menus, meld's titlebar became headerbar. Headerbar with a single button looks weird, since Meld also has a menubar, also it consumes extra pixels from the screen. Consider adding hamburger menu as an item to menubar and changing headerbar back to titlebar.
![meld-old](/uploads/894c8397292fb88d85e696043fc30417/meld-old.png)
![meld-new](/uploads/e60cc9eafc309b3170b210daf21448d7/meld-new.png)https://gitlab.gnome.org/GNOME/meld/-/issues/297Arrows direction on searchbar buttons2019-04-15T20:36:02ZmondayArrows direction on searchbar buttonsCurrently, prev/next buttons has icons < / > - it makes sense, but other gtk3 applications (gedit, evince, gnome-builder) uses up/down arrows for this case. I think, it will be more familiar for users to have similar direction icons in M...Currently, prev/next buttons has icons < / > - it makes sense, but other gtk3 applications (gedit, evince, gnome-builder) uses up/down arrows for this case. I think, it will be more familiar for users to have similar direction icons in Meld. In my experience, about 90% of search results are on different lines.https://gitlab.gnome.org/GNOME/meld/-/issues/296filesystem navigation cannot follow junctions2019-04-13T21:37:10ZGhost Userfilesystem navigation cannot follow junctionsOn Windows 10 (and earlier Windows NT variants) it has long been possible to create "junctions" in a directory tree. These are the logical equivalent of a symbolic link to directory on Unix/Linux systems. Most programs are blissfully ign...On Windows 10 (and earlier Windows NT variants) it has long been possible to create "junctions" in a directory tree. These are the logical equivalent of a symbolic link to directory on Unix/Linux systems. Most programs are blissfully ignorant of the fact that a directory entry is actually a junction and will treat it just like a more integral part of the directory hierarchy. Meld version 3.20.0 will not follow them. (Interestingly, the earlier released version would.) Instead, in the file-open dialog, it acts as if they are not directories (showing no folder icon) and will "open" them if told to. (That is a useless "open", resulting in an apparently empty file.)
While trying to find a work-around, I found that Meld's file-open navigation is also unwilling to descend into a lettered drive listed in the left pane if it is the target of a subst mapping. (CLI shell command: subst X: \somepath\... )
There is a semi-viable work-around. If Meld is started from a directory whose nominal path includes a junction, (making it the "current" directory), an icon for it will appear at the bottom of the file-open dialog left pane. From there downward, directories and files unreachable (by recent Meld) from the junction can be opened.
But of course it would be better if Meld could regain the pre-v3.20.0 behavior.https://gitlab.gnome.org/GNOME/meld/-/issues/295VT character causes incorrect difference highlighting2019-03-10T11:07:24ZGhost UserVT character causes incorrect difference highlightingIf text files contain the vertical tabulation (VT) character (Unicode
U+000B), meld's difference highlighting is incorrect.
Please compare the two attached files ("a" and "b").<br>
Line 1 of each file is identical, consisting of a sing...If text files contain the vertical tabulation (VT) character (Unicode
U+000B), meld's difference highlighting is incorrect.
Please compare the two attached files ("a" and "b").<br>
Line 1 of each file is identical, consisting of a single VT character.<br>
Line 2 is different.<br>
Line 3 is the same.<br>
Meld incorrectly highlights the third line as different instead of the second.<br>
This problem was discovered as I am developing a C++ program that must
apply specific processing to all Unicode characters. It therefore
includes the VT character within its source code.
It might be useful to point out that this problem does not exist in
"diffuse". I mention this merely to point out that it is possible to
handle the VT character correctly.
[a](/uploads/45e5c6d4931a9d834c2e564efe5a1d1f/a)
[b](/uploads/ad942e5095f53ab092055f9cbc1e03b8/b)https://gitlab.gnome.org/GNOME/meld/-/issues/294UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 11: ordi...2019-03-06T12:34:40ZGhost UserUnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)[Meld 3.16](https://packages.debian.org/stretch/meld) fails when comparing files or folders with non-ascii names.
Dir comparison example:
```sh
$ set | grep '^LA'
LANG=de_DE.utf8
LANGUAGE=de:en_US
mkdir /tmp/left
mkdir /tmp/right_öä...[Meld 3.16](https://packages.debian.org/stretch/meld) fails when comparing files or folders with non-ascii names.
Dir comparison example:
```sh
$ set | grep '^LA'
LANG=de_DE.utf8
LANGUAGE=de:en_US
mkdir /tmp/left
mkdir /tmp/right_öäü
meld /tmp/left/ /tmp/right_öäü/
meld /tmp/left/ /tmp/right_öäü/
Usage:
meld Beim Start kein Fenster öffnen
meld <Datei|Ordner> Versionskontrollvergleich starten
meld <Datei> <Datei> [<Datei>] Im Zwei- oder Dreiwegevergleich starten
meld <Ordner> <Ordner> [<Ordner>] Einen Zwei- oder Dreiwegevergleich starten
Fehler: 'ascii' codec can't decode byte 0xc3 in position 21: ordinal not in range(128)
LANG=C LANGUAGE=C meld /tmp/left/ /tmp/right_öäü/
Usage:
meld Start with an empty window
meld <file|folder> Start a version control comparison
meld <file> <file> [<file>] Start a 2- or 3-way file comparison
meld <folder> <folder> [<folder>] Start a 2- or 3-way folder comparison
Error: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)
```
When inserting a `raise` after line 338 in [meldapp.py](https://github.com/GNOME/meld/blob/meld-3-16/meld/meldapp.py#L338) it says:
```
LANG=C LANGUAGE=C meld /tmp/left/ /tmp/right_öäü/
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/meld/meldapp.py", line 78, in do_command_line
tab = self.parse_args(command_line)
File "/usr/lib/python2.7/dist-packages/meld/meldapp.py", line 336, in parse_args
focus=i == 0)
File "/usr/lib/python2.7/dist-packages/meld/meldapp.py", line 155, in open_files
return window.open_paths(paths, **kwargs)
File "/usr/lib/python2.7/dist-packages/meld/meldwindow.py", line 775, in open_paths
paths, auto_compare=auto_compare, auto_merge=auto_merge)
File "/usr/lib/python2.7/dist-packages/meld/meldwindow.py", line 719, in append_diff
return self.append_dirdiff(paths, auto_compare)
File "/usr/lib/python2.7/dist-packages/meld/meldwindow.py", line 683, in append_dirdiff
doc.set_locations(dirs)
File "/usr/lib/python2.7/dist-packages/meld/dirdiff.py", line 628, in set_locations
locations[i] = l.decode(sys.getfilesystemencoding())
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)
```
File comparison example (with `raise` added to line 338 in `meldapp.py`):
```
touch /tmp/left.txt /tmp/right_öäü.txt
meld /tmp/left.txt /tmp/right_öäü.txt
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/meld/meldapp.py", line 78, in do_command_line
tab = self.parse_args(command_line)
File "/usr/lib/python2.7/dist-packages/meld/meldapp.py", line 336, in parse_args
focus=i == 0)
File "/usr/lib/python2.7/dist-packages/meld/meldapp.py", line 155, in open_files
return window.open_paths(paths, **kwargs)
File "/usr/lib/python2.7/dist-packages/meld/meldwindow.py", line 777, in open_paths
recent_comparisons.add(tab)
File "/usr/lib/python2.7/dist-packages/meld/recent.py", line 104, in add
recent_path = self._write_recent_file(comp_type, paths)
File "/usr/lib/python2.7/dist-packages/meld/recent.py", line 169, in _write_recent_file
config.write(f)
File "/usr/lib/python2.7/dist-packages/configparser.py", line 955, in write
self._sections[section].items(), d)
File "/usr/lib/python2.7/dist-packages/configparser.py", line 964, in _write_section
value = delimiter + unicode(value).replace(u'\n', u'\n\t')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 25: ordinal not in range(128)
```
Removing `paths = [p.encode(sys.getfilesystemencoding()) for p in paths]` in [line 158 of `recent.py`](https://github.com/GNOME/meld/blob/meld-3-16/meld/recent.py#L158) or changing `";".join(paths)` to `";".join(paths).encode("utf-8")` in [line 168](https://github.com/GNOME/meld/blob/meld-3-16/meld/recent.py#L168) did not help. Do you have any ideas what to test else?https://gitlab.gnome.org/GNOME/meld/-/issues/293Improve visualization of infobars2019-06-22T03:52:28ZmondayImprove visualization of infobarsInfobars looks a bit wierd. Note, that infobars can be diffrent between documents and they'll have different height in that case, so full-width infobar is not an option here. Also, screenshot is no longer representing current state:
> i...Infobars looks a bit wierd. Note, that infobars can be diffrent between documents and they'll have different height in that case, so full-width infobar is not an option here. Also, screenshot is no longer representing current state:
> in current `ui-next` the rework of packing caused by using overlay scrolling has improved the alignment of these somewhat, so they're a little less weirdly-positioned
Related discussion:
> I'm not sure about this, probably, adding left, right and bottom borders to infobars can improve visuals.
> I agree, but I'm not sure what to do about it. I don't remember seeing other users of infobars use borders, but I'm not really sure. Also, in current `ui-next` the rework of packing caused by using overlay scrolling has improved the alignment of these somewhat, so they're a little less weirdly-positioned. This could still be improved however.
> You're right, infobars in gedit/nautilus doesn't have borders, adding them was a bad idea.
![mbb7](/uploads/e86b1d14011883dbb3ccaf91dcf34af3/mbb7.png)https://gitlab.gnome.org/GNOME/meld/-/issues/292Elements on searchbar lacks padding2019-04-14T20:01:22ZmondayElements on searchbar lacks paddingEntry/buttons on searchbar (Ctrl + F) needs padding. Related to https://gitlab.gnome.org/GNOME/meld/issues/289. With borders between statusbar/searchbar and searchbar/document, entry and (hovered/active) button borders will blend with st...Entry/buttons on searchbar (Ctrl + F) needs padding. Related to https://gitlab.gnome.org/GNOME/meld/issues/289. With borders between statusbar/searchbar and searchbar/document, entry and (hovered/active) button borders will blend with statusbar/findbar borders. First screenshot shows current state, second - how it will probably look with top border on status/search bars.
![mb3](/uploads/4a812e353f329fbb6b8a24f4b9ab67ee/mbb3.png)
![mb9](/uploads/b58d24f4ade7c44ba43bbfaf212fa7d8/mb9.png)https://gitlab.gnome.org/GNOME/meld/-/issues/291Menu needs adjustments, related to app menu retirement2019-03-02T03:42:10ZmondayMenu needs adjustments, related to app menu retirementSee https://gitlab.gnome.org/GNOME/Initiatives/issues/4.
App menu no longer accessible in gnome 3.31.91+, related option in dconf too. Currently, on Fedora 30/rawhide with meld 3.20 there is no way to access "meld" menu (and options it...See https://gitlab.gnome.org/GNOME/Initiatives/issues/4.
App menu no longer accessible in gnome 3.31.91+, related option in dconf too. Currently, on Fedora 30/rawhide with meld 3.20 there is no way to access "meld" menu (and options it provides, such as open a preferences window).https://gitlab.gnome.org/GNOME/meld/-/issues/290Several minor UI issues2019-03-12T20:26:45ZmondaySeveral minor UI issuesThanks for developing and maintaining this awesome application! There are some small UI issues I found:
---
1. With disabled toolbar switching between opened comparisons creates interface glitch. It looks like toolbar appears for a sec...Thanks for developing and maintaining this awesome application! There are some small UI issues I found:
---
1. With disabled toolbar switching between opened comparisons creates interface glitch. It looks like toolbar appears for a second to show loading animation (red circle on second screenshot). Switching between multiple "new comparison" tabs doesn't create issue.
![mbb61](/uploads/055af1bf97053d807c5d4b2e0e81a41e/mbb61.png)
![mbb62](/uploads/025d4479633d123e67ec6bf7b4b97eee/mbb62.png)
![mbb63](/uploads/dc1c6983fc767c9273299b0ed3539f51/mbb63.png)
---
2. Inline toolbars on Meld's preferences window ('folder comparisons', 'file filters' and 'text filters' tabs) doesn't have borders. Second screenshot show similar toolbar in gnome-control-center window, "search" tab.
![mbb51](/uploads/fab7cae5dd7715f05148042e7bdaff64/mbb51.png)
![mbb52](/uploads/6709a1084a6003dd9b34d26258053007/mbb52.png)
---
3. Entry on find bar (Ctrl + F) needs padding. Related to https://gitlab.gnome.org/GNOME/meld/issues/289. With borders between statusbar/findbar and findbar/document, entry border will blend with statusbar/findbar borders.
![mbb3](/uploads/4a812e353f329fbb6b8a24f4b9ab67ee/mbb3.png)
---
4. Entry in error state looks a bit awkward. Light text, dark icons, and entry border is blue. Second screenshot shows how it looks in gedit/gnome-builder. Link to merge request for gnome-builder's searchbar, that adds error state: https://gitlab.gnome.org/GNOME/gnome-builder/merge_requests/115.
![mbb4](/uploads/140cee1a1608e413792aae1fe8e39dd4/mbb4.png)
![gedit](https://gitlab.gnome.org/GNOME/gtk/uploads/d0d5aee155d2b9347f3e6f1c1b0d9d51/bugscrenshot.png)
---
5. Infobars looks a bit wierd, when there are are two similar infobar for each document. I'm not sure about this, probably, adding left, right and bottom borders to infobars can improve visuals. Note, that infobars can be diffrent between documents and they'll have different height in that case, so full-width infobar is definitely not an option here.
![mbb7](/uploads/e86b1d14011883dbb3ccaf91dcf34af3/mbb7.png)https://gitlab.gnome.org/GNOME/meld/-/issues/289Lack of visual separation between statusbar and documents2019-04-13T02:22:24ZmondayLack of visual separation between statusbar and documentsWith updated adwaita theme:
![mb1](/uploads/45337aabc91d0421ff79621babefd8fd/mb1.png)
Adding `statusbar { border-top: 1px solid @borders; }` to css style partially solves the issue:
![mb2](/uploads/5400f3922a514a1dba6b759326b07b71/m...With updated adwaita theme:
![mb1](/uploads/45337aabc91d0421ff79621babefd8fd/mb1.png)
Adding `statusbar { border-top: 1px solid @borders; }` to css style partially solves the issue:
![mb2](/uploads/5400f3922a514a1dba6b759326b07b71/mb2.png)
Full-width border looks better, but I dont know how to achieve this:
![mb3](/uploads/a009f1299237f093ae26ea5f3c7fb23c/mb3.png)https://gitlab.gnome.org/GNOME/meld/-/issues/288Possible python version inconsistency2019-02-22T21:31:20ZGhost UserPossible python version inconsistencyI am trying to install meld from the source code. The documentation recommends python3.3, python3.4 however I see in the code that f-strings are being used (`meld/conf.py`, line 51)
I try to use python 3.5, 3.6, 3.7 but I am facing an is...I am trying to install meld from the source code. The documentation recommends python3.3, python3.4 however I see in the code that f-strings are being used (`meld/conf.py`, line 51)
I try to use python 3.5, 3.6, 3.7 but I am facing an issue with GTK+ which cannot be imported.