Gedit follow-up

This post will answer the questions generated by the previous one (or at least try to).

One of the main concern is “Why use yet another search UI ?”, evince/firefox/epiphany use more or less the same approach, a bottom bar that pops-in causing no reflow of text. Gedit uses a sidebar that cause text to be “pushed” to the right, maybe causing reflow is auto-wrap is activated and the window too small

Here is what Paolo “pbor” Borelli has to say about that:

Did gedit look at the mozilla/evince/epiphany style search popup at all?
Yes, we discussed it a lot, we also discussed it at guadec, and we also tried implementing a search bar before implementing the sidebar, the reasons why a search bar doesn’t work very well for us are:

  • Fitting replace in the bar doesn’t work well
  • Ditto for the varions search options (match case, etc)
  • The search bar at the bottom doesn’t work well with the output window (bottom pane) open
  • And at the top it doesn’t work well with tabs, which I think is the reason why firefox has it at the bottom. In general I’m not very fond of search bars at the bottom… is the last place where my eyes goes
  • The last reason (even if not very important) is that for text,I value vertical space more than horizontal

However we are aware of some of the drawbacks of a side pane search, the most important being that the text is “shifted” to the right, so we decided to stop speculating and try this UI and stick with it until we get enough feedback (note that now search does also find-as-you-type), after having tried it for a while, it’s not that bad. The problem of reflow would also be fixed by having the pane on the right, but we felt that a sidepane on the right is weird.

Now some other points taken from the same IRC discussion:

“new_mdi” [the CVS branch] is almost a rewrite (apart from search, it gets rid of bonobo, has completely async file loading/saving with complete vfs support, new plugin system,etc), but we do not have enough time/manpower, so we are taking our time [This is frightening, quick they need developers, developers, developers !]

I think that our loading/saving code in new_mdi is shaping up really good, we are using xfer too for remote saving, the problem is that we also have to deal with backups which makes things really hard, especially when you have to deal with permissions and symlinks…

We also put special care in avoiding races (like testing perms before writing, which is inherently racy), local files are special cased and the saving algorithm is inspired by vim, also for loading we special cased local files and used mmap which is blazingly fast 🙂

And finally we got rid of the dialogs, dialogs suck in gedit because they block all the tabs… now you can start a slow operation in a tab and do stuff in another one:

Gedit opening a remote file

Concerning other questions:

  • What are the tabs at the bottom of the sidebar?
    It has three tabs, the first one presents a list of opened documents, the second, the search UI.
    The third is in fact added by a plugin, which can now add their tab to the sidebar, here it is the TagList plugin’s list (a list of xhtml tags for examples)
  • Is there a FileBrowser Plugin for gedit, or Project Manager ?
    Yes there will be one, but the plugin interface has been completely rewritten, so it’s not usable yet.
  • Is it possible to reorder tabs manually now? (with drag-and-drop)
    Yes !
  • I don’t see this in CVS yet, or am I missing something ?
    to see this new gedit, you have to specify the “new_mdi” CVS branch, be warned, it is experimental !
    cvs -d co -r new_mdi gedit

20 Responses to “Gedit follow-up”

  1. Ben Roe says:

    The new gEdit looks seriously good. I’m really looking forward to this getting into GNOME proper. I’ve been switching between Emacs and gedit working on SiEd( and this release looks like I should finally be able to stick with gedit permanently.

  2. Stéphan K. says:

    A bonobo-less GEdit? Awesome! I might actually be able to decypher the code now! 😉

    I will probably check this branch out soon, I don’t have much of a problem with experimental stuff.

    Great work! Thanks for answering the questions. 🙂

  3. I feel that the sidebar would be better on the right. You mentioned that this is weird, but it actually feels quite natural. There is a setting in firefox to set the sidebars like history on the right, and I always enable it. When a sidebar opens, it is far less distracting! Please consider giving the user an option (even if hidden in gconf) for having the bar appear on the right.

    You should also consider Right-to-left languages. You want to make sure that when writing in a RTL language, the sidebar is on the opposite side for consistent behavior.

  4. Mitja P. says:

    What happens to sidebar tabs when there are just to many of them to fit the sidebar width? Scrolling tabs on such small space is not a very “usable” solutions. Also there is a lack of consistency is GNOME app sidebars. Evince, Nautilus,… , have drop down selectors for sidebar contents, while EOG, Bluefish,… ,and now Gedit have tabs. Maybe there should be some decision on a common solutions/implementation.

    Anyways, keep up the good work, these new features look awsome, otherwise.

  5. Philippe L. says:


    I have a left handed comment 🙂

    side pane on the right is very interesting to me because i wright with my left hand so i’m used to wrighting on the left, reading a book on the right as i study
    so the search pane on the right is important to me.
    i understand i’m only one of the 10% people to feel like this and the default behavior should be to have the pane on the left. yet if it was possible to have either a radio buton to put the pane on top bottom left right (just like the tabs have one or had maybe) or, if by dragin the side pane to the right will leave it there and the position will be memoirized. now that would be great.

    also one more comment,having the search (perhaps not search and replace ) on the botom is marvelous, my eyes dont need to go there, i know when i press ctr+f the search has the focus so i just type and keep looking at the text
    just like in less when pressing /
    this is indeed more for an experience user than newby. and perhaps in firefox newbies are confused by not seeing the search bar pop up. but then default should be sidepan with the possibility to have a search (and search only is fine for that purpose) bar in the bottom.


  6. Bram! says:

    I think it is a good thing to think about al the alternatives for a search ui and not simply copy something without considering. Furthermore, these kind of UI things are very very (very) nice improvements.

    However, a side bar on the right does not feel strange to me on Windows. Adobe Reader does it for its Search UI (see: and so does Microsoft Word for some things (like the clipboard with multiple entries on a stack). I’m in no ways a usability expert but I’ve seen people use it comfortably.

    Tabs on the bottom of the sidepane however look strange to me. It’s done before, but I feel like they get unnoticed most of the time. I suggest the interface using a dropdown for the header of the sidepane (like Nautilus or Microsoft Word again) gives more consitency. It also solves the problem of icon-only labels since the dropdown allows giving the title of the bar.

    I personally wouldn’t object to a single-line bar at the bottom when searching and a two-line bar at the bottom when replacing text, although I don’t feel I could give strong arguments for either alternative.

  7. Calum Benson says:

    Hmm, regarding the per-tab progress indicators… you really should use the status bar for this, that’s exactly what it’s there for!

  8. Alex Roberts says:

    Wow, it’s so great to see what you guys are doing with my baby! I look forward to seeing all of this in action. =)

  9. Paolo Maggi says:

    Calum: I do not agree. We have a progress bar for each tab during long operations (e.g. loading/saving of remote files). We also need a way to cancel operations (see the Canel button near the progress bar).

  10. Yury Puzis says:

    The sidepane on the right is not weird at all. It is even implemented in new version of Totem playlist this way. Left and right issue is really a matter of getting used to, while the text reflow is an irritation that’s not going to go anywhere just by itself. I suggest to put the pane on the right by default, and add a preference to shift it left. And do it the other way around for right to left languages.

  11. Daniel Llano says:

    Is there any formal proposal to get this into the HID, making all other GNOME programs follow this GUI convention?

  12. Anonymous says:

    Does gedit have a plugin for emacs style processing of tabs?
    That is – tab causes the current line to be shifted forward according to the syntax.

  13. Bob says:

    First off, congratulations and thank you for some seriously cool work.

    Like many others, I fear the sidebar is a bad choice, and maybe this is an area where real usability testing is needed. I’ve never seen a “normal user” make good use of the sidebar in Netscape / Mozilla / Firefox, for example, in my opinion because it’s just an uncomfortable interface – the shifting makes people nervous. But in the end, I’m sure this will all shake out, and it’s not too horrible to have different Gnome and Gnome-related apps take slightly different approaches on this, because in the end we’ll be more likely to converge on the best UI.

  14. SchAmane says:

    Thanks for answer about FileManager plugin first.
    Second i will say, this mockup looks cool,but is not usable. If you open file from local space it happends too fast to inform user about loading.
    So if you donwload file, or accees it from slow gnome-vfs place it can be usefull to show user that gedit just wait for source, but not this way you will make. More correct way would be making animation “load” icon for TAB you just load file in. Like its in Epiphany and Firefox. There are animated small spiner while loading combined with showing progressbar in status space.
    This is more native and understandble for users way to show “please wait”.
    And this is simplier to implement, because every application do this. So i think this would be better choice.

  15. Phil says:

    I love being able to reorder tabs; glad to see that made it in.

    Here are some replies to some problems:

    * Fitting replace in the bar doesn’t work well
    What about having a separate command for replace? CTRL+F opens a find search bar, CTRL+else opens search & replace. Replace shows one text input at a time. It doesn’t ask for the replace term until you’ve already entered the search term. See emacs for an intuitive, simple implementation of this. (Wow, emacs and simple in the same sentence?! Unprecedented!)

    * Ditto for the varions search options (match case, etc)
    How many search options are there? Here’s an idea for match case: if the input contains capitalisation, the user probably cares about caps, so be case-sensitive. If it’s all lowercase, search case-insensitive. This does not allow for lower-case specific searches, but it’s a great way to unclutter the UI, and it seems to be in line with Havoc’s famous Metacity simplicity plea.

    Also please reconsider putting “go to line…” in the find UI. I’m not sure that’s where it belongs.

    * And at the top it doesn’t work well with tabs, which I think is the reason why firefox has it at the bottom. In general I’m not very fond of search bars at the bottom… is the last place where my eyes goes
    If it were a different colour, it would be much more noticeable. I agree that having it appear in an unobtrusive way carries with it a danger of not noticing it. However, making it a different colour would probably solve this.

    * The last reason (even if not very important) is that for text,I value vertical space more than horizontal
    Different strokes for different folks I guess. (Do you have a widescreen display?) Above all, it’s not my project, and I value the fact that you guys are putting a lot of hard work into it. I’d love it if you give my suggestions some consideration, but it’s your baby.

    Happy Hacking!

  16. […] 217;ve recently tried out some programs that I simply must mention: Leafpad Until the new Gedit is released, I recommend making this your default basic text file prog […]

  17. Philip Ganchev says:

    “* The search bar at the bottom doesn’t work well with the output window (bottom pane) open

    * The last reason (even if not very important) is that for text,I value vertical space more than horizontal”

    Then the output pane should be on the side, because it uses up much more space than a search panel.

    I agree that an Emacs-style replace dialog is better. It wastes less space, and is not confusing.

  18. Gtournie says:


    The gedit right pane plugin is out:


  19. karatedog says:

    The gedit right pane plugin throws a gazillion errors into the terminal, and doesn’t properly works yet.

  20. Toon says:

    It works ! But sometimes you have to restart gedit just after installed it…