Archive for June, 2005

Gedit follow-up

Thursday, June 16th, 2005

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 :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co -r new_mdi gedit

Gedit development

Wednesday, June 15th, 2005

Gedit is the gnome text editor, you all know that, i thought i might post some screenies of the latest interface improvements (i just make PR for them, i didn’t really work on it)

Find interface

Here you have on the left, the new find/replace sidebar, allowing a far better search experience than the crappy over-the-top dialog. You can also see the context menu with interesting undo/redo labels, see next screenshot.

Edit menu, undo/redo improvements

Again, the edit menu, showing the undo/redo items, like gnumeric and i suppose other applications, it shows a more comprehensible label than just “Undo” or “Redo”, that’s what i’m working on for the moment, you can follow it in this bugzilla bug, it is implemented in gtksourceview, so anyone using it should be able to have such menu items in his own app.

Unreadable file error

Finally, they are struggling to get rid of all annoying popup messages, this is what happens when an unreadable file is opened. The print preview will also show up in the same tab as the text it previews, much more clear, unfortunatley it appears to be broken right now…

Nautilus, part 2

Saturday, June 11th, 2005

So i made a little progress, now the files being downloaded have an emblem progressively filling up. I made a movie of that, it’s a bit wacky and not fluid, but i don’t know how to do properly (format ogg/theora, 1280×800 so you may need to resize it a bit). It’s buggy (notice i don’t close any window 😉 ) and the code is really hacked-in but this is a proof of concept.

Epiphany-Nautilus integration

Friday, June 10th, 2005

Here is my latest little project, integrate epiphany downloads with nautilus. First a mockup.

Nautilus mockup

This shows the normal nautilus spatial window, but in the corner there is a little addition, a download status bar indicating how many files are being downloaded in that particular folder, as well as the global download progress.

Now, the actual screenshot of a live download in nautilus, the result is the same, but the display needs to be cleaned (showing human-readable file sizes, times, etc)

Nautilus integration

So, the concept is quite simple, forward epiphany download events to nautilus via dbus, since gnome-vfs can’t handle downloads from epiphany at the moment. In nautilus, listen for dbus events and store the various downloads. The nautilus windows that are showing a folder where a download is in progress are notified, and show the progress.

Next step is to show files being downloaded with a special emblem, indicating that they are being downloaded and showing the progress of that file, for example using a pie emblem that fills up, or a vertical bar that grows to 100%. A context menu for these files would allow to pause/cancel/resume/abort the transfer.

The final goal is to use nautilus for the actual download, and epiphany would just forward the url to download, but in the meantime this would provide a working UI. When the change is ready, just change the backend, the UI stays the same.

Now i would like to hear you comments about that..

Update: after reading the first comments, i think i must go a bit further in my explanation. This thing does not happen when you drag and drop from epiphany to nautilus, but when you click on a link in epiphany and choose to download the file. Instead of having the current download manager pop-up, the nautilus window would appear, with that ui.

This has at least 2 avantages over the current system: No pop-ups (well the nautilus folder would appear, but this is an option i don’t know if it’s better to not open it..), the download you view will be related to the folder that you are looking at. Maybe the same UI can then be used for regular file move/copy operations.