gspell news

  • gspell is now fully hosted on gnome.org!
  • There is now a mailing list.
  • In addition to LaTeXila, gspell is now also used by gedit (5,800 lines removed, yay!).
  • The 0.1.x version has branched and is meant to be installed alongside GNOME 3.18.
  • If everything goes fine, the 1.0 version will be released at the same time as GNOME 3.20, with a stable API.

API reviews are more than welcome!

Stay tuned.

Posted in gedit, gspell | 3 Comments

Announcing gCSVedit, a simple text editor to edit CSV files

As part of my job at the Université Catholique de Louvain, one of my projects is to develop gCSVedit, a small and simple text editor to edit CSV files.

gCSVedit is now a free/libre software (GPLv3+ license) and is hosted on SourceForge.

Other delimiter-separated values (DSV) files are supported, not just comma-separated values (CSV) files, but “CSV” is more commonly used to refer to that kind of file.

Screenshot of gCSVedit

gCSVedit with the columns aligned. Note also the gray bullets to represent the spaces present in the file.

Why developing a new application for editing CSV files?

CSV files can already be opened in a spreadsheet software like LibreOffice Calc and Gnumeric. But it’s not really user-friendly. Just to open the file you need to provide tons of options:

Screenshot of opening a CSV file with LibreOffice Calc

Opening a CSV file with LibreOffice Calc

A general-purpose text editor like gedit is not the best choice either, because the columns are not aligned. There are some plugins for Eclipse or other IDEs available, but launching and using a complete IDE just to view or edit a CSV file is not user-friendly either.

The best is a specialized application, to do just one thing but do it well. With a user interface that goes straight to the point.

Spreadsheet or text editor?

With a text editor, all characters are visible, including the delimiters. We have thus a greater control. When writing a script to extract the data contained in the file, it’s important to view every character in case of problems (like an extra separator in the data but not for the column titles).

Also, some software that generate CSV files sometimes also include an header, i.e. some text before the actual CSV fields. With a text editor, the header can be shown naturally.

Future plans

Create an installer for Windows. Create an xdg-app for GNU/Linux. And implement more features of course!

Hopefully in the future it’ll be possible to re-use more code of gedit, to have a decent text editor (although gCSVedit is already completely usable).

So, nothing revolutionary here, it’s a small project. But I think it can bring a better usability. Comments, questions?

PS: to show where are the real spaces (those present in the file, not those added for the alignment), I’ve already contributed to GtkSourceView and GTK+. There will maybe be more contributions in the future, for example to implement a utility to insert virtual spaces, i.e. the text editor should behave as if the added spaces didn’t exist. Or, finally implement rectangular selection in GtkTextView.

Edit: gCSVedit was hosted on GitHub, but it is now hosted on SourceForge. So the URLs have been updated.

Posted in gCSVedit, gedit, GtkSourceView | 7 Comments

LaTeXila 3.18 + need of a graphics designer for the app icon

LaTeXila 3.18 has been released last week. There are some nice improvements:

  • New buttons in the integrated file browser (in the side panel) to open the current directory in a file manager (e.g. Nautilus) or in the terminal. Thanks to Arnaud Blouin, the developer of LaTeXDraw.
  • Better read-only mode for the default build tools. Only the personal build tools can be modified, the default build tools are read-only. Before, it was confusing because when opening a default build tool, it was possible to edit the fields (but the changes weren’t saved). Now the distinction is much clearer.
  • More modern design for the dialog windows.

Creating a new LaTeX project

But the most important news is for the spell checking, which has been significantly improved this development cycle:

  • A new library called gspell has been created. The source code comes from gedit. Read this blog post for the technical story.
  • The LaTeX commands are no longer marked as misspelled.
  • In the preferences dialog, you can change the default settings for the spell checking: the language and whether misspelled words are underlined in red in the document.
  • Via the Tools menu, the spell checking settings can be changed and are stored on a file-by-file basis.
  • There is now a spell checker dialog window, to spell check an entire file.
Spell checking in LaTeXila 3.18

Spell checking in LaTeXila 3.18

The spell checking improvements have been possible thanks to the fundraiser, so thanks a lot for your support!

Speaking about it, the fundraiser has been re-targeted. Unfortunately the €10,000 milestone has little chances to be reached. That milestone included lots of LaTeX-specific improvements to LaTeXila. Now the fundraiser focuses more on the usefulness for other text editors, not just for LaTeXila. For example gspell will be useful for a lot of other GTK+ applications where the spell checking is needed.

Need of a graphics designer for the app icon

Since several years, LaTeXila is a quite good and stable LaTeX editor for GNU/Linux. It’s a lightweight but feature-full editor, that don’t gets in the way.

LaTeXila icon

But, the application icon is still quite ugly. For the visual identity of LaTeXila, it would be better to have a better icon. Since I’m not good at graphics design, I need some help. If anyone is interested, please contact me!

Thanks in advance!

Posted in gspell, LaTeXila | Comments Off on LaTeXila 3.18 + need of a graphics designer for the app icon

Changing quickly between a final and derivable GObject class

When doing code refactorings, it is sometimes desirable to change between a final and derivable GObject class. So it is important that that operation can be done quickly, as every other small refactorings that you usually do in your code.

In fact, when refactoring some code, sometimes you want to quickly try something to see if the result is better. But if a certain refactoring task takes a lot of manual and boring steps, (1) it’s not a pleasure to do it and (2) if the result (after other refactorings) is not what you want, you’ve lost your time.

To evolve in the right direction, a code needs to be easily modifiable.

With the convention to put GObject instance variables in the Private struct for derivable types, and in the object struct for final types, changing between the two is currently quite burdensome (because there is no tools to do it quickly):

/* For a final type */
gint
my_object_get_foo (MyObject *object)
{
  return object->foo;
}

/* For a derivable type */
gint
my_object_get_foo (MyObject *object)
{
  MyObjectPrivate *priv = my_object_get_instance_private (object);

  return priv->foo;
}

Maybe in a library like GTK+, changing between a final and derivable type is not a common operation. But in an application, it can be more common. For example when you want to move a class from an application to a library (it can be an internal or external library), one way to do it is to move the re-usable code in the library and keep the app-specific code in a subclass. So in that case, the class in the library needs to be derivable!

There is, though, another convention that can be used with GObject: always use a Private struct, even for final types.

But, calling my_object_get_instance_private() in each function is quite cumbersome… With the old convention to have a 'priv' field in the object struct to access the Private struct, you don’t have that problem. For example:

/* Old convention: have a 'priv' field in the object struct. */
gint
my_object_get_foo (MyObject *object)
{
  return object->priv->foo;
}

Although for a library it’s better to not have the 'priv' field, I tend to prefer that latter code.

TL;DR: writing and refactoring GObject code in C can be quite painful, we need more tools. In the meantime, there can be a big difference just by following a different convention.

Edit: If you’ve read this blog post, you might think “just use Vala or Python or JavaScript! problem solved!”, but I still prefer the C language for GNOME development for reasons explained in this document. And to develop a library, the C language is the de facto language in GNOME.

Posted in Programming | 6 Comments

Introducing gspell, a new spell checking library

As part of the LaTeXila project and its fundraiser, I’m working on a new spell checking library called gspell.

Some background

At first I wanted to contribute to GtkSpell so that GtkSpell and GtkSourceView work well together, without a dependency on each other. GtkSourceView defines a no-spell-check region. For LaTeX, the region includes the LaTeX command’s names, for example. But GtkSpell didn’t read that region, and the region was available only through the GtkSourceView API. Adding a dependency on GtkSourceView in GtkSpell was not desirable, because many applications use GtkSpell only. Also, a library like GtkSpell could potentially add the support for GtkEntry too, so if there is a dependency on GtkSourceView, it isn’t nice for an application that wants only the spell checking for a GtkEntry. The solution was actually really simple: the no-spell-check region is a GtkTextTag. After setting a name to the tag and expose it in the API, it was possible for GtkSpell to lookup the tag and read the region.

So the patches for GtkSourceView and GtkSpell have been merged, to remark only later that there was a quite annoying text responsiveness problem on long lines (e.g. a wrapped line that takes 5 lines on the screen). And… there was exactly the same problem with the gedit spell plugin. The typed text appeared with a noticeable delay. Fixing that problem was more complicated. The text needs to be spell checked after a timeout. But adding a timeout function means that the remaining region to spell check needs to be tracked, which was not the case, neither in GtkSpell nor in gedit. And another problem is that GtkSpell anyway needed some code clean-ups. On the other hand the gedit code was in a slightly better shape and, more importantly, it had more features. For example gedit has a dialog window to spell check an entire document, one (misspelled) word at a time, whereas GtkSpell only has an “in-line” checker. An in-line checker is not convenient in the case of a very long document with very few misspelled words, in that case the dialog window is more convenient (btw it could also be an horizontal bar above or below the text, to not hide the text by the dialog window).

So, since the gedit spell plugin’s code had more features, I’ve decided to improve that code base instead. The gedit plugin code also needed some code clean-ups, but at least the code architecture was for the most part good. After those code refactorings and bug fixes, it was easier to fix the responsiveness problem. Then, after some more “spell shaking” (haha) the code was re-usable for other text editors.

Enters gspell

The gedit spell plugin’s code has then been copied into its own repository, called gspell. The library is still under construction, but I hope to get a first version available when GNOME 3.18.0 is released (September 21, according to the schedule). That first version will not have a guaranteed stable API, be warned! It is currently available on my GitHub account, but if things go well, I’ll ask during the next development cycle to get it hosted on gnome.org!

Update: gspell is now hosted on gnome.org, the links above have been updated. The project page is now at https://wiki.gnome.org/Projects/gspell.

What it means for LaTeXila

Basically, the LaTeX command’s names won’t be highlighted anymore with a red wavy underline. And there will be a dialog window to spell check an entire file. Also, on the LaTeXila side, settings will be stored on a file-by-file basis (to remember the language and whether the in-line checker is activated), and there will be settings in the preferences dialog for the default configuration.

I already have a branch in LaTeXila that uses gspell, and it works pretty well. There is still a bit of work to do, but it should be ready soon. Since it would be a pity to not have it for LaTeXila 3.18, I’ll delay the release of LaTeXila 3.18.0 for a few weeks to let translators have the time to update the translations.

Posted in gedit, gspell, GtkSourceView, LaTeXila | 5 Comments

An introduction about writing GLib/GTK+ applications in C

GNOME lacks a good and recent book about writing applications and libraries. I was motivated, some months ago, to write such a book. But this motivation has dissipated somehow, I don’t think I’m the right person.

Anyway, here is my attempt:

The GLib/GTK+ Development Platform (version 0.2)

It contains an introduction to GLib, which is mostly an updated version of the corresponding chapter in GGAD, written by Havoc Pennington (with his permission).

Even if the document is short, I think it can already be an interesting read. With the hope that the content can be reused for a real book in the future…

Posted in book | 5 Comments

Fundraiser campaign for LaTeXila

It was already possible to make a donation for LaTeXila since March 2014. There was just a link on the web site and an entry in the Help menu. But I made almost no advertising for that. Now for the 3.16 release I would like to push the accelerator one step further!

LaTeXila is already a mature and stable application, it doesn’t miss much to become a LaTeX editor of choice (if it isn’t already the case). Some features need to be a little improved, especially the spell checking. And a few features are missing (I’m looking at you, live preview).

So, if you are a LaTeX user and wants a great editor for writing your documents, don’t miss the LaTeXila fundraiser campaign!

Note that some of the planned items would be useful for other text editors as well, since the work would be done in an underlying library (GtkSourceView, GtkSpell, …).

Thanks!

Posted in LaTeXila | 9 Comments

Thoughts on live previews in LaTeXila

Several years ago I talked about some principles for the user experience of LaTeXila, a GTK+ LaTeX editor for GNU/Linux. The conclusion:

The idea of LaTeXila is to always deal directly with the LaTeX code, while simplifying as most as possible the writing of this LaTeX code. The users don’t need to be LaTeX gurus, but they should understand what happens.

In my opinion this better follows the LaTeX philosophy than programs like LyX. By writing directly the LaTeX markup, you have full control of your document. The idea of LaTeX is to concentrate on the content and the structure of the document, not its layout.

With a live preview, you see constantly the layout… so you’re less concentrated on the content. As soon as something is wrong in the layout, you’ll want to fix it. This can lead to bad practices, like proceeding by trials and errors until the layout is good. LaTeXila tries to avoid that. As in programming, you should understand what you’ve written before the compilation or execution. You must be certain that the code is correct; if you have any doubts, the best is to read the documentation, this will save you time when you’ll use the same commands in the future.

Moreover, layout polishing should be done when the content is finished. For instance, it can sometimes happen that a word exceeds the margin, because LaTeX doesn’t know where to place an hyphen to split that word. It is useless to fix this issue when the content isn’t finalized, because if you add or remove some words in the sentence, the problem will maybe be fixed by itself.

Instead of a live preview, the workflow in LaTeXila is to compile from time to time the document (e.g. when you’ve finished a section) to re-read your text and check that the result is what you expected. A handy feature in that context is the forward and backward search between LaTeXila and Evince, to switch between the *.tex file(s) and the PDF at the corresponding positions, with a simple Ctrl+click.

But there are some special cases where a live preview can be useful, i.e. when more source <-> result cycles are required:

  • A PGF/TikZ figure preview, because in that case the layout is more important.
  • When we do something difficult, like writing a long and tricky math equation. But when it becomes difficult to find our way in the code, an alternative is to improve its readability, by spacing it out, adding comments to separate the sections, etc.

If you have other specific use cases where a live preview is really useful, I would be interested to hear them. I don’t think “learning LaTeX” requires a live preview, as explained above this can result in bad practices.

So I think a live preview might be useful for editing one paragraph. A live preview of the whole document is probably less useful. In any case, a live preview should be enabled only temporarily. In LaTeXila we can imagine doing a right click on a paragraph or TikZ figure, select the live preview in the context menu and we enter in a mode where only that paragraph (or selection) is visible, with the live preview on top/right/directly injected in your brain/whatever. Then when the writing of the tricky paragraph is finished, we return to the normal mode with the whole source content.

Posted in LaTeXila, Thoughts | 8 Comments

Object-oriented design best practices

Here is another book review, this time about object-oriented design.

Programming Best Practices

We can learn by our own experience, we can use our common sense, we can learn by more experienced developers when contributing to an existing project. But to speed things up, reading a good old book is also a good idea.

For programming in general, not specifically for object-oriented design, see the blog post About code quality and maintainability.

Object-Oriented Design Heuristics

For OO design, the well-known Design Patterns book is often advised. But most of the design patterns are not often applied, or are useful only for big applications and frameworks. How often do you create an Abstract Factory or a Facade?

On the other hand, the book Object-Oriented Design Heuristics, by Arthur Riel, discusses in details more than 60 guidelines − or heuristics − that can be applied to all projects, even for a small codebase with three classes.

Example of an heuristic:
Keep related data and behavior in one place.

If a getter method is present in a class, why is the data used outside the class? The behavior implemented outside the class can maybe be implemented directly in the class, so the getter can be replaced by a higher-level method.

Other example:
Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.

By following this heuristic, god classes should be avoided. An example of a class that can be split in two is where some methods use only attributes A and B, while some other methods use only attributes C and D. In other words, if a class has non-communicating behavior, that is, methods that operate on a proper subset of the data members of the class, then the class can be split.

All the heuristics can not be followed all the time. That’s why they are called “heuristics”. But when an heuristic is violated, there should be good reasons behind that decision, and the developer should know what he or she is doing.

Event-driven programming

One missing concept in the book is event-driven programming.

With GObject, we are lucky to have a powerful signal system. It is a great way to decouple classes. When an object sends a signal, the class doesn’t know who receive it.

Conclusion

Programming best practices are useful to maintain a good code quality. Object-Oriented Design Heuristics will give you the knowledge to better write object-oriented code, either for small projects, big projects or API design in a library.

Posted in book reviews, Programming | 1 Comment

File loading and saving in GtkSourceView, finally

Last year GtkSourceView saw a new search and replace API. This year it’s the file loading and saving that has just landed! It is in the continuity of making the gedit source code more reusable for other text editors.

In short, the back-end part of the file loading and saving in gedit has been moved to GtkSourceView, with a new and more flexible API to better wrap the feature. The code has been modified to follow GIO conventions for asynchronous operations, to use GTask internally, and replace the uses of GSettings by properties, among other things.

The file loader auto-detects encodings, newline types and compression type (yes gedit can open gzip files). Invalid characters can also be displayed with their corresponding hexadecimal value, because GtkTextBuffer accepts only valid UTF-8 text. And progress information is reported during the operation.

The API is stateful: the file parameters (encoding etc) are remembered between a file loading and a file saving in a GtkSourceFile object. Unfortunately the new API is still quite low-level. The application must configure the file loader and the file saver, and some errors are returned to the application.

So the front-end and errors handling is still implemented in gedit. Errors and progress information are displayed in an info bar, above the GtkSourceView widget. For some errors, gedit proposes different actions to the user, like choosing another encoding.

API design

If you are a text editor developer, don’t hesitate to have a look at the GtkSourceFile API. The API can still change during this 3.13 development cycle. The notes about the API design are available on bugzilla (there has been four iterations). Here is a summary.

The API is a bit heavy, with the following classes: GtkSourceEncoding, GtkSourceFile, GtkSourceFileLoader and GtkSourceFileSaver. There are good reasons for having two class’ names derived from a verb (“to load” and “to save”), which is generally a hint that those classes should be replaced by a method (i.e. an action). The reasons are partly similar with the new GSubprocessLauncher in GIO: the FileLoader and FileSaver classes are there not only for launching the operation, but also for configuring it with a nicer and more extensible API than one function with a dozen parameters. With the FileLoader and FileSaver, we can add properties, functions and even signals. And the FileLoader and FileSaver classes are quite useful in gedit: when an error occurs and the user clicks on a button in the info bar, the loader or saver object is reconfigured and the operation is relaunched, without the need to keep the initial configuration around. Also, the FileLoader or FileSaver properties are applied to the GtkSourceFile object only on a successful operation, so the GtkSourceFile state is (normally) consistent with the underlying file on the disk, at least at the time of the last load or save done with GtkSourceView.

Possible follow-ups work

A possible follow-up is to make the front-end code more reusable, either by creating higher-level classes in GtkSourceView, or by creating a git submodule, like the libgd (without API stability guarantees in the latter case).

Another possible follow-up is to analyze and improve the performances, which are currently quite bad. For short files it is not visible of course, but opening a very big log file takes more time than with other popular text editors.

There are other possible improvements, like unescaping invalid characters when saving, or avoid blocking the GtkTextBuffer when (auto-)saving a short remote file on a slow network connection.

Changes for gedit plugins

Unfortunately there are some changes in the gedit API for plugins, mainly in GeditDocument. Fortunately the changes are well documented, and most plugins should still work without any modification.

Conclusion

The file loading and saving can quickly become a fairly complex beast. Now this code is available for other GTK+ text editors.

Thanks to Paolo Borelli for the reviews!

TL;DR:

  • In GtkSourceView: 29 files changed, 7909 insertions(+), 3 deletions(-)
  • In gedit: 49 files changed, 1888 insertions(+), 8819 deletions(-)
  • In gedit-plugins: 11 files changed, 22 insertions(+), 31 deletions(-)

This is a 12% code increase in GtkSourceView, and a 6% code decrease in gedit.

PS: As usual, some tests would be more than welcome before the stable version in September.

Posted in finally, gedit, GtkSourceView | 1 Comment