Sublime Forum

Onwards to 3.1

#1

What improvements are planned for this release?

0 Likes
#2

Haha, generally we don’t comment on upcoming features. I have a few ideas in mind, but right now we are focused on making sure the 3.0 transition goes well, especially from an infrastructure perspective.

Keep your eyes on the dev channel for future updates!

11 Likes
#3

@wbond Can you at least confirm if you have GTK 3 support in mind?

1 Like
#4

In what way? To be honest I am not an expert in Linux toolkits. Is there a specific GTK 3 feature or integration that is missing?

0 Likes
#5

I had better integration into the system in mind, especially, the top menu bar and file dialogue. Step towards native Wayland support might be another benefit.

0 Likes
#6

Can you provide some details, since I am unaware of what is missing/different?

0 Likes
#7

GTK 3 uses a different file chooser dialogue with built-in search. The idea would be to link Sublime against libgtk3 so that the new file dialogue would be used.

0 Likes
#8

Oh please, please don’t go that route. While I understand that some people do like the GTK3 file dialog, I - and many others - think it’s absolutely horrible. Basically they’ve conflated search with navigation. Just about every file dialog other than the current GTK3 one uses type-ahead navigation. The Gnome people killed that.

For example:

Currently, I do Ctrl+O to open a file in ST. I navigate to a folder and start typing the first few letters of the file I want to open - say RE. The file README.md is selected but nothing else in the view changes. Cool.

With the new GTK3 file dialog, when I’m in the file dialog and start typing the first few letters of af the file I want to open, it clears the folder view and starts performing a recursive search for any file anywhere that starts with RE, and displays only the matches. This is considerably slower and also prone to confusion as I lose context: I’ve got plenty of READMEs in various directories, which one am I actually opening? Frustrating as hell and the reason I try to use GTK2 or QT programs over GTK3 whenever I can – type-ahead is simply superior for navigating through known files/directories, and the lack of it just slows me down too much. In fact it’s not really a question of better or worse – search simply cannot replace navigation, as they are two completely different things conceptually. Gnome folks seems to think that it’s fine, though…

(Also, for the search not to be miserably slow, Gnome’s Tracker needs to be running and indexing files in the background. Even if it were running, it still doesn’t solve the main issue.)

The Gnome people don’t want to make this optional as they’re not very fond people having options. Ubuntu always used to patch type-ahead support back in but might kill that in the upcoming release as maintaining the patch has become too much of a burden.

Plenty of arguments in these bug reports, if anyone is curious:

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016
https://bugzilla.gnome.org/show_bug.cgi?id=721968
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1666681

Sorry for the rant, but it just boggles my mind that someone thought replacing navigation with search was a good idea. It’s a nice complement, OK, but no replacement…

12 Likes
#9

Also, many other applications for some reason do not allow inserting a file’s path directly and require you to browse it in the gtk file chooser. Sublime Text does this right, but sadly I can’t even remember of a single other piece of software also doing it. Sometimes the input field shows up if you browse from the “recent files” view to your fs root, but I don’t know when this happens.

This is very annoying when you know exactly where the file is and just want to start typing, but you can’t. Also, using a file browser like ranger you cannot drag and drop files to appliations but you can copy their paths.

Just a related rant.

0 Likes
#10

Personally I don’t care about the file dialog issue. Its a minor inconvenience if you even notice that issue.

I’d much much rather have native wayland support. Hell, you could find a way to support both gtk2 and gtk3 to give those that want that old file dialog their way. To me this is my largest want for sublime.

0 Likes
#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