Club Silencio

Uni

Exams finally over, and I don’t mean for this summer, I mean for good: I passed the Last one with the capital L. It was about time. Now I’d better resume the work on the thesis.

small hacks that make me happy

JHbuild is a wonderful tool which I use daily. Sometime ago it gained the really useful feature of displaying a nifty notification icon with the state of the build. This morning I realized that one of the things I often end up doing is to look at that notification icon, realize that an error has occurred and then hunt in which workspace and in which terminal the build stopped. A whole ten minutes later I had this simple patch which raises and focuses the right terminal when the notification icon is clicked.
The patch is for zenity (which JHbuild uses for the notification support) and I am not sure if the patch is suitable for inclusion, since maybe raising the terminal isn’t what other users of zenity want… for sure it’s going to stay in my local copy.

Well, I admit this is a bit of an excuse to show up my ugly face on p.g.o, but I’ll join my voice in celebrating the EU decision against software patents. I notice that the Italian press is reporting it as an “Open Source Victory”, so I guess we should enjoy the good press, even if my feeling is that the rejection has more to do with the problems that software patents would have posed for all the small/medium european IT business.

Orph, I (obviously?) do dot agree.
Let me elaborate why.

• Let’s start with the obvious: the “features”. And no, I’m not talking about syntax highlighting, plugins, etc, I’m talking about printing, spell checking, vfs support (which finally is read and write in the new_mdi branch), etc: all these features are IMHO something that every gnome application must have.
• The attention to detail: I proudly think that gedit is one of the most compliant gnome apps to the HIG and to the accessibility requirements. The same attention to details is there under the hood: a text editor is not a matter of sticking a TextView and a Menubar in a Window, gedit takes great care in handling file save properly without screwing your data, using backups, handling different file encoding and all the small things which may not be abvious at a first look. I cannot say the same about many of the other editors I looked at.
• Reliability: gedit is probably the most tested app of the ones included in the desktop, this was quite clear to me when we switched to GtkFileChooser: I don’t have stats but a large number of the file chooser bug were reported through gedit. Fragments of gedit code are pretty much everywhere in gnome and often gedit is the reference used for “How do I do that?” and this is my opinion an indication that gedit code quality is pretty good. From my limited experience fixing the UI may be hard but fixing the code is way harder

So let’s get back to your post: It seems to me that your gripes mainly get down to:

• Tabs
• Slow start up

Tabs are a controversial issue: we get *lot* of feedback from people saying that they love tabs and they are used in similar places in many gnome apps and also in many others general purpose text editors even on Windows (UltraEdit, EditPlus, etc)… however we do see your point, and in fact we discussed it many times internally: IMHO a good trade-off would be to hide the tab when just one document is open, but that’s just me.

With regard to the slow start up, I cannot do nothing but agree… I fact I think that slow start up accounts for 90% of the perceived complexity of gedit vs leafpad. What we need to do is fix it. 2.10 is faster than 2.8, and the new_mdi branch is faster than 2.10, but any help here is appreciated.

With regard to syntax highlighting and plugins, I’ll keep it short for now: I don’t think they expose complexity to the user (you click on a simple text file and you don’t even know about SH and plugins are there to hide complexity, firefox extensions show they are a good way to do this)

Since I have the rant-mode activated, I’ll also give a larger perspective on why a default text editor for GNOME should be more similar to gedit than to leafpad.
GNOME user Vs Text Editor user: while a text editor surely has it’s place in the desktop, I don’t think that they target the same average user. Every time the average GNOME user fires up a text editor means that we failed somewhere and that we need an appropriate application (for instance Tomboy rocks for note taking and editing /etc/foo.conf should definately not be needed for a user).
It seems to me that the use case you are advocating is: “let’s have a quick and dirty text editor to edit /etc/foo I use emacs for the rest anyway”, what we want to achieve with gedit is not “gemacs”, gedit is not a programmer text editor, but a *uselful* *general purpose* text editor to do real work in it without having to learn emacs or vi, suitable for latex, for html, for simple programming (if you are not the emacs or IDE type) and for composing good old text files :)

A couple of responses…

Ankh, I wasn’t claiming that gedit is better than textedit on your computer today, what I wanted to point out is that we (gedit and gnome) definately want to work in that direction: to do so we would love to hear from you why textedit suits your needs better… a webpage and a screenshot of textedit would be a good start :)

dfenwick, I totally agree with you about avoiding adding features just for the sake of it… however once a feature is added and its considered useful (and the recent files list is one of these considered my daily use of gedit and the number of bugreports we get) I think it should be implemented in the most nicely looking way, if the eyecandy doesn’t impact usabilty and performance. In this case it caused performance problems, but this was a problem with the implementation that we managed to solve.

Ankh, we are aware that gedit startup time is not as good as we would like and during 2.9 we worked quite a bit on trying to understand what was wrong and how we could improve it.
For instance it turned out that one of the major offenders was the EggRecent code, which which is used throughout GNOME to create a list of recently used files… we found out that creating that nifty and apparently innocent dropdown menu on the toolbar was really taking up a lot of time since it hit the disc a lot of times to lookup the icons for files.
The large set of libraries is definately one of the problems and we are actively working on reducing the dependecies: the worst offender here is the eel lib which is huge and nowadays is only used by nautilus: when we started using it, it looked like a good idea to avoid code duplication… now we managed to almost completely remove it: we are down to one function call, unfortunately it’s a really important one and not something that we can easily cut and paste… that function should really go in gnome-vfs, but it has not happened in this devel cycle.

I also have to disagree with the statement that we are focusing on developers as our user target: gedit is and will remain a general purpose text editor, in fact we said a lot of “no” to requests for enanchements that we didn’t feel were useful for the generic user and we follow the HIG fairly strictly.
We also put in place a plugin system which easily allows to extend the editor with specific features, for instance uwog of abiword fame has recently hacked up a nice plugin which allows reformatting. Specific suggestions and bugreports are always welcome in bugzilla and/or on the mailing list.

gedit

I really wanted to see gnome-vfs support finally make it into gedit, so with the help of paolo I picked up some of his code and beat it into shape. This also required looking at some of the gnome-vfs internals and get a couple of patches accepted there (thanks teuf!).

If anyone thinks (like I did) that saving a darn text file is trivial, he should probably take a look at the code: it isn’t rocket science, but dealing with all the small details (create a backup, fail gracefully, symlinks, persmissions, etc) requires definately more than open(), write(), close().

Modulo some FIXMEs the code now works fine, however at the end we decided to not include it in 2.10: we were not comfortable enough with the reliability of some of the vfs methods and we didn’t investigate yet how to work out some UI and code details to integrate it in gedit. It’s much better to wait for 2.11 instead of changing such a central part of the codebase just before the feature freeze: this way it will get tested for a whole developement cycle.

Since we didn’t want to hit the feature freeze empty handed, during the night I hacked up a plugin which lets you save a copy of the file to any remote locations through gnome-vfs (saving a copy is less tricky than real save since you don’t have to care about backups). paolo instead hacked up current line highlighting in gtksourceview and added support for that and for bracket matching to gedit. Not bad if you consider we didn’t have any new feature till two days ago!

GtkMenuToolButton

Yay! I’ve just committed the GtkMenuToolButton widget to GTK+ HEAD. Thanks to the help of federico and maclas I even managed to defeat the documentation build system vodoo and commit the basic docs for the widget… the widget should be straightforward to use anyway.
Having the widget in HEAD means that it will be in gtk 2.6 and thus it is available for Gnome 2.10 (or should I say 2.A?).
Now I only need to make some various projects use it.

LinuxWorldExpo.it

With a friend I went to the italian LinuxWorldExpo.
It wasn’t particularly good: the conference is focused toward business and the few techincal workshops required expensive fees. Not so disappointing, that’s pretty much what I expected. There was also a .org section with some stands of debian, fsf etc… obviously they were relegated in a sort of basement, below the main exposition room.
The nice thing is that I finally had the chance to meet paolo and we talked a bit about gedit, choosing a few priorities that we need to attack during the next devel cycle. If time permits.

Find Dialog

clarkbw discusses ideas for a better UI design of the find dialog to use in GNOME apps. In particular in gedit, the subject has been in discussion for some time.
While I agree that the current design has problems (the most annoying to me is that often the dialog covers the results), I am not convinced that the new proposed design is the way to go.
In particular it does not cover a particular aspect of searching in an editing app: how would “serach & replace” work?
I also have some doubts about the interaction described, in particular:

• “The focus is transferred to the results window”: in an editing app I would prefer if keyboard focus was left on the text, so that I can right away type in the point I was looking for
• “finally ESC closes the results window”: while I would be totally ok with this, it seems to me that the same rules used to say that ESC should *not* close the find dialog apply. If ESC is bound with the concept of undoing the changes and thus it should not be used for the close button of the find dialog, why is ok to use it to close the output window?

Foundation

I’m now a member of the GNOME Foundation. Yay!

GNOME 2.8

GNOME 2.8 is out! Congratulations to everyone involved.
In this devel cycle we didn’t manage to work a lot on gedit, just bugfixing and maintainance work… we’ll see if we get a bit more time for it in the next months, otherwise we may get replaced by the NEW PROGRAMMING TECHNOLOGY.

I also decided to apply for for membership in the GNOME foundation… I already wanted to do it last year, but then I forgot… we’ll see if I’ll get accepted.

DropdownToolButton

I submitted a bugreport to gtk requesting a simple widget which provides a ToolButton with a dropdown menu (like the Back and Forward button of a browser) since many apps in gnome have their own implementation of such a widget (gedit, epiphany, nautilus, evolution, etc)… my secret plan was to simply submit the bug and see someone implementing it like it happened for GtkAbout, but I ended up working a bit on it myself today, we’ll see how it goes.