Sublime Forum

Onwards to 3.1

#11

Currently we use FFI to link to GTK. I’m not sure how feasible it would be to allow some way to dynamically like to 3 vs 2.

For someone who has a tangental idea of what Wayland is, what are the benefits? I was always under the impression it was a re-imagining of X, which would be utilized by something like GTK.

Unfortunately I’ve found the Linux graphical toolkit libraries tend to be extremely confusing in terms of how exactly they fit together, what the benefits of one over the other are, and what dependencies/requirements they each have. Obviously I am not talking about GTK vs QT.

2 Likes
#12

An attempt to.

Not only graphical toolkits. Most libraries attempt to provide too much flexibility resulting in chaos.

1 Like
#13

My understanding of the graphics stack is not very deep so I might be a little inaccurate, hopefully someone will correct me when I am wrong.

X server provides the Xlib library that allows apps to draw to screen, listen to events, etc. To make app development simpler, higher level libraries like cairo or widget toolkits, which itself can use Xlib or higher level libraries, appeared.

Unfortunately, X comes from the times when applications could be trusted – programs were small and you compiled everything yourself, or later, a trusted distribution packager did it for you. Nowadays, we use a lot of software from external sources, even closed-source apps like Sublime, so the threat model has changed.

There are various methods of sandboxing apps but because X allows you to do basically anything, they are useless. Unless we wanted a full virtualisation like QubesOS does, a newer, more limited API had to be devised. Wayland offers that API.

If you do not rely on Xlib and use a higher level library that supports Wayland (like GTK 3) you are good. Otherwise you will have to upgrade. While there is a XWayland, a layer allowing to run X applications, it does not benefit from the better security and there is probably some overhead.

For a better, detailed overview of the stack see http://blog.mecheye.net/2012/06/the-linux-graphics-stack/

I recommend upgrading to GTK 3 since it supports both Wayland and X protocols. The Wayland support greatly outweighs the concerns about the look of file chooser dialogue. If you use some other APIs or even Xlib directly, more work will be needed.

0 Likes
#14

What about package control being installed by default? It is a must have but it’s install process is not so user friendly.

0 Likes
#15

In 3.0 it’s available via the menu: super simple.

0 Likes
#16

Cool thanks! :slight_smile:

1 Like
#17

good point, this isn’t made clear from the PC website:

1 Like
#18

Sublime Text really should move to GTK3 in the near future. Why?

  • GTK2 is deprecated. It should not be used in in new and currently maintained applications. I should end this list at this point — because programmer should not use deprecated libraries — but I will continue.
  • GTK3 has support for scaling. It’s important for HiDPI displays users. I know that ST has its own DPI setting but it not affect to system dialogs, context menus and menu bar.
  • GTK3 has support for Wayland — the newest graphical server on Linux. There is a lot of users that moved from old Xorg to new Wayland. Applications that are not working in Wayland are run in Xwayland abstraction layer. Xwayland makes applications slower — for example windows resizing is slower. ST is very fast. Should it be made slower by using old GTK2? No! :wink:
  • Consistence of system dialogs is important. On Windows Sublime Text uses the newest file chooser dialog introduced in Windows Vista. Whould you like to use file chooser dialog from Windows XP or Windows 98 in Sublime Text (which is done by older Windows apps)? Probably not. Currently ST on Linux uses old file chooser dialog because of old GTK. It lacks of features like renaming files or accessing to unmounted network shares which is possible in GTK3’s file chooser.

Please — move to GTK3. :wink:

OFF-TOPPIC: @rhblake If you have problems with GTK3’s file chooser (which is not ideal by default but really better than in GTK2) please try to my patches: https://github.com/TomaszGasior/gtk3-mushrooms

1 Like
#19

I haven’t done the research yet on what dropping support for GTK 2 would mean for our user base. For open source projects where the project is to scratch an itch and no one is paying, dropping support for a chunk of your user base may be fine. I don’t think we’d be keen on dropping support for paying users in a minor version release, so that means we’d either have to support 2 and 3 or wait until work on (the theoretical) ST4 started.

0 Likes
#20

libgtk2 and libgtk3 can be installed in parallel, so if user does not have GTK 3 installed, she can do so without any issue. Even Mozilla is dropping GTK 2 support in Firefox – they only paused the efforts to concentrate on the ongoing rewamp.

GTK 3 has been provided by package repositories of Debian, Ubuntu, Fedora, Arch and OpenSuse for ages. An exception is RHEL (resp. CentOS), which did not receive GTK 3 until release 7.0. CentOS 6 is unfortunately still supported, meaning that simultaneous support will be necessary if Sublime is also targetting server distributions.

Edit: Found this nice table with gtk versions: https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix

4 Likes
#21

+1 for GTK3

Every day I have to edit settings to change dpi_scale: 1.0 and 2.0 back and forth, because my work setup has mixed 4K and 1080P monitors, and home setup is 4K only. I may go blind doing this :slight_smile:

0 Likes
#22

Two suggestions from a licensed user:

  1. Support Chinese input method on Linux.
  2. Better HiDPI display of texts for GUI (e.g., menus).
0 Likes
#23

bash > 3/ zsh etc. support on Mac would be great

sublime currently does not respect the ENV :sweat:

1 Like
#24

zsh is supported on macOS, but not for the exec command build system. This is on purpose and won’t change. When people write build systems, then need to know what syntax to use for the shell command. If every user ran a build system using their own preferred shell, things would break in weird ways.

Since build 3127 we execute the user’s default login shell to grab all of their ENV vars. If you aren’t getting your zsh ENV vars, perhaps you don’t have zsh set as your default shell. These env vars should trickle down into the bash subprocess launched by the exec command, so it should do what you want.

0 Likes
#25

actually I do not want to bash you in any way and I’d be more than happy to get it working the way it is so I’ll elaborate:

I am actually using bash 4.4 installed via homebrew as my default shell in terminal and Alacritty where it works just fine
Running chsh thus gives me "Shell: /usr/bin/local/bash"

nevertheless all sublime default build systems pollute the output massively by using bash3 and thus not reading my bash_profile correctly

I tried the dev version before it was released and it did not solve the issue, that is probably why it still is an issue

I do not think using bash4 on Mac is absurd/ esoteric because the bash3 will not get updated due to licensing things I think, of course not every small shell project can be supported

as I understand, the /usr/bin/bash is hardcoded into some config, so an option to set this path would probably solve this issue

thanks for your response and work

0 Likes
#26

So this forum isn’t really a bug tracker. In a day or two, or maybe a week, this topic will drop off the front page and only be seen if someone revives the thread.

If you’d like to see an enhancement made, the best place to log that is at https://github.com/SublimeTextIssues/Core/issues.

0 Likes
#27

sure enough Core/issues/1734

0 Likes
#28

And an issue for GTK 3: https://github.com/SublimeTextIssues/Core/issues/1977

0 Likes
#29

Are there any news about porting to GTK3? ST is my last app, which uses outdated and deprecated toolkit.

0 Likes
#30

Woo hoo!

Many thanks to the team!

0 Likes