Ubuntu 22.10 replaces Gedit with new text editor
omgubuntu.co.uk
omgubuntu.co.uk
Nothing GNOME has done since 2014 has improved gtk or their desktop environment (except for high dpi support). It's all been downhill.
Then I discovered MATE and was very happy because a) it showed me I was not the only one to feel that way about GNOME 2 and 3 respectively, and b) I could retain the comfort of GNOME 2.
I couldn't really tell if GNOME 3 is good or not, because I have not spent enough time to figure it out. Maybe I will one day, but I'm perfectly happy with MATE, so unless something changes drastically, I'll stick with it for the foreseeable future.
Something good was and is done, in a rush of crappy design ideas just to make commercial product as some manager imaging them.
The main issue unfortunately is another: lacking of proper clean and effective desktop GUIs libs aside Qt/G[TD]k witch makes newcomers feeling old systems styles when they see "alternative" WMs/DEs
And it’s still easy for medium/advanced users to sub in their preferred applications instead of the defaults.
That’s how it should be. Easy defaults for beginners and non experts and easy ways for expert users to sub in their preferred options.
Nice features:
- Session saving is built in, and it even restores unsaved files, similar to VS Code or Sublime Text. This is great if you're jotting something down and don't expect to save it anywhere and then your battery dies. It also means you get the benefits of auto save, but without it actually changing the files until you tell it to.
- Automatic editor settings via editorconfig / modelines is built in. You don't need a plugin for it.
- It has noticeably better rendering performance. Which is not an especially practical concern most of the time, but it feels nice. It's noticeable if you scroll through a file with a device that supports pixel-perfect scrolling.
- It looks pretty. Notably:
- UI is styled according to the syntax highlighting.
- Dark mode! (The syntax highlighting changes accordingly).
- Special font for the mini map, which is very useful to see patterns and find a particular block of code.
There are several gedit things that aren't in Text Editor and probably won't be, like the side panel and bottom panel and assorted plugins for those, but these days I find if I want those, I'll be happier in Builder or VS Code anyway.
"Looks cleaner" shouldn't have to be the mortal enemy of "easier to use", but it seems that too often things come down on one side or the other.
Jump used to jump, and run used to run, and that was that.
Let's use the Batman Arkham series for example. Every button seems to do something else depending on context and I can't keep track anymore.
To me the most overloading part is the pacing and degrees of freedom. Everything is moving everywhere, yet somehow they manage to feel at home and instinctively act clean while I struggle to pursue the basics. I guess it's just young brains being too good at sipping whatever is required to play, while we're having to fit our legacy views and needs.
Not to suggest that this is a good UI (highly Gnome-styled apps like this tend to have trouble getting the right elements promoted to the toolbar and leave important things buried in menus or omitted entirely), but “I can’t figure out what’s clickable” here feels like you’re being deliberately obtuse.
* I guess it's possible screen readers can see it is a link
find /usr/share/applications | xargs grep "Name=Text Editor"
This is obviously terrible, and not really "in the UI" like you asked. Maybe there's a better way but it's not obvious to me.
Cache invalidation, naming things and off by one errors.
I’m sure fedora will follow suit and I’ll have to do some googling on how to get the new and improved text editor into a functional state sometime soon.
They're shorter, but when they were released (70s for all of them), there was a 6 character limit on a lot of systems for command names.
Or do you mean why is there a space in the name? That would be annoying for launching from the terminal, I can see that.
"Vi" is not "just naming the editor what it is", it's a relatively distinct short name that doesn't actually mean anything unless you know the reason for the name (which I did not for years after being introduced to it).
At some point recently, Ubuntu stopped using "nautilus" as the name of the file manager, and now it's just called "files". Except, wait, that's some kind of alias, so the process name is still nautilus after you start it. If you don't know the relationship between the GUI name alias, and the literal process name, how are you supposed to figure it out? How are you supposed to search for info or help about "files"? It's too generic.
But "visual" is was vi is. That's its grand innovation. It took a lot of it's (non-motion) commands straight from ed, but let you see the entire page of text as you changed it. ed didn't do this because it needed to be conscious of teletype machines.
It's a direct abbreviation of ex's "visual" command (and used to just launch you into ex in visual mode), and everyone using it at the time would have known what it meant.
> If you don't know the relationship between the GUI name alias, and the literal process name, how are you supposed to figure it out?
Oh boy. If you do not appreciate doing deep lore spelunking to understand things, the unix/linux ecosystems are going to be frustrating for you. Half of our stuff still pretends it's operating on those old character based teletype machines I mentioned earlier.
> How are you supposed to search for info or help about "files"?
Do you have the same problem with the "fork" call?
For the text editor? For general help, they will probably google "gnome text editor help" or "gnome text editor docs" like I just did, which returns >80% results for the new application despite it not existing for very long.
I also tested this in a private window in case google is tailoring this to my, generally more tech heavy than normal, history. It immediately came up with this general rundown/intro to the editor: https://itsfoss.com/gnome-text-editor/ which covers installation and even how to view the list of keybindings.
For more specific features, they'd probably google something like "gnome text editor $FEATURE".
vi was originally just a command that forced ex to open in visual mode.
I don't believe I have ever used Gedit for anything. Ever.
I'm an Emacs guy. I won't be using Text Editor, either. Ever. If it accidentally opens a file, that means I need to change "Open Files of This Type With..."
So all the gnashing of teeth and wailing seems a bit overwrought
It's sad because I know there are more people that rejected linux at first because of Gnome, so if you see someone that doesn't like linux, show them a few screenshots of non-gnome desktops first.
First thing I do on every Ubuntu install is change the default editor to vim. Used to use the Gnome editor a lot, but since the introduction of vscode I rarely fire it up. The old editor (which is still shipping with LTS) is probably the best of the Gnome apps. The devs' effort to replace it is deeply disappointing, but they've made it abundantly clear they don't care what any of us think.
1. You rarely use the default text editor
2. You are very ("Nooooooo!") dismayed by the default text editor change
3. The old editor is one of the best Gnome apps, however you don't indicate whether you've tried to use the new one and what are its deficiencies
4. Just the fact that they are replacing Gedit however, is deeply disappointing
5. Obviously the devs don't care what "we" (you) think
Nice.
that's a pretty cynical take. there are definitely some individuals that work on gnome who don't care, but in general I get the sense that gnome does care. just considering it from a practical standpoint, what if they tried to do everything we asked for? there are millions of opinions that are all mutually exclusive, but even if you filtered those out it would still be utter chaos, probably each dev doing what they think is best (remember gnome is largely a volunteer org).
There are definitely things I wish gnome did differently, but I'm really glad to see the focus on making the developer experience better with different language bindings for gtk so one isn't stuck writing gui apps in C (or hacky python), and modernization of the toolkit, etc. I think that will help a lot because there will be a lot more choice.