Developing graphical IDEs the UNIX way

Programming on a UNIX environment generally involves the use of command line tools: vim/emacs, git, grep, sed, screen/tmux, and so on. What is really nice about these tools is that they do only one thing, but do it well. Now, what about people not wanting to learn shell commands? And sometimes (sometimes), graphical interfaces are more convenient.

An IDE is an integrated development environment. What people think about this “environment” is generally a bloated program (*cough* eclipse *cough*). But what if the environment is not one big application, but several small programs? The small programs can interact a little together through D-Bus, if needed.

Let’s take a few examples.

Specialized text editors

To have a good user experience, the text editor should be smart enough to know the language used (C, C++, Python, Vala, LaTeX, etc.) and implement features specifically for the language. A few examples:

  • Code completion;
  • Switching between the call of a function to its definition;
  • Have an overview of the file (the list of functions, or the structure of a LaTeX document).

Having only one text editor for several types of tasks (C and LaTeX for instance) is not convenient. It works with vim or emacs, but at the cost of passing lots of time in the configuration files. If a graphical application have thousands of settings, we end up with something worse than eclipse. No, instead, there should be one text editor for each task. And one another general-purpose text editor that don’t include specialized features.

This is not just about settings. With a single text editor for all tasks, the UI must be generic enough for the plugins, but they will always be restrictions. On the other hand, with an independent application, the UI can be exactly what is needed: not too generic nor too restrictive.

The common features between all those specialized text editors can be shared in a library. A project is to make the gedit source code more reusable. It would have been a nice GSoC for me (see this draft proposal for more details), but instead I work on GtkSourceView, which is also nice.

git

Working on a git repository can be a bit difficult at the beginning. A graphical application that implements the basic features can be useful for some people. But it doesn’t need to be available in the same program as the text editor!

Creating a commit, navigating through the repository history, pull, push, changing branches, … have nothing to do in a text editor, in my opinion. There are some things that can be useful in the text editor though: if there is an integrated file browser, we can mark the modified/added/removed files. And in the margin of the text content, we can mark the modified sections.

Search and replace

The search and replace in a text editor can be limited at one file at a time. The search and replace entries can be shown in the top-right corner of the file, with a little button to show and hide the replace entry.

The search and replace in multiple files is another beast. Integrating it nicely in the text editor is a difficult task. Generally the developer choose a dialog window, because it is the best available option, but it partially hides the file contents…

Why not a small application that do only that? It would roughly select a directory, and search in all files in this directory. The text editor can have a menu item “Advanced search and replace” that would launch the small program with some parameters. The advantage of this small program is that the UI is really better, since it doesn’t have all the text editor features.

When we replace some text, sometimes we want to do small modifications afterwards. But normally, the specialized text editor features would not be needed in the small search and replace application.

The specialized text editors would already have features to edit several files at once. For example, when we change the name of a function, all the calls to the function can be renamed too, and adjusting automatically the indentation of the parameters (should be doable).

Conclusion

The general idea is to have small programs with a clean and simple UI, which don’t require lots of configuration, and that work well together. Ideally, they should Just Work™, like other GNOME applications.

22 Responses to “Developing graphical IDEs the UNIX way”

  1. Maurizio says:

    The command line provides nothing that you asked for. have you ever tried KDevelop – that has excellent support for php , c++, c, python. plugin integration for git/cvs/svn, debugger integration, cmake/makefile projects.
    Kile – that has excellent support for TeX family
    or QtCreator, that has excellent support for C/C++?

    If you are with the gtk family there’s Anjuta, but don’t be a Qt hater and try them, I know a bunch of ‘c++/kde’ haters that actually use KDevelop.

    • swilmet says:

      As a user, I use Vim to code in C, and LaTeXila for LaTeX. (LaTeXila is based on GtkSourceView, like gedit). And for all the rest: command line tools.

      But I would like to have a great C/GObject (graphical or not) IDE: for the boilerplate, indenting correctly function prototypes and parameters with the GNOME conventions, etc.

  2. MrEricSir says:

    It’s not really an IDE if there’s no graphical debugger!

    • swilmet says:

      I didn’t talk about the debugger, but it’s the same idea as for git: use another program. Nemiver for example (for a graphical debugger).

      • MrEricSir says:

        Nemiver is a nice start, but if I have to open my source code in more than one program that’s a deal breaker.

        • Simon says:

          Agreed… the debugger needs to be closely tied to the editor, so you can trace through to find the problem, then edit it immediately from within the debug mode – particularly if you have some ability to hot-deploy your code changes.

  3. Daniel Svensson says:

    While I prefer Emacs, your choice of calling Eclipse bloated is kind of misplaced. Eclipse is highly modular and it’s up to the user to make it bloated. If you think the default target platform is bloated you are free to put together a less bloated one if there are features you don’t use, that way they will not be loaded at all and will result in faster startup and smaller memory footprint. What version of eclipse you download from http://www.eclipse.org/downloads/ doesn’t really matter. Every one of them can become another one buy simply loading additional or fewer modules, it’s just that they come in one package preconfigured… one might argue that there could be one with even less features. https://en.wikipedia.org/wiki/Rich_Client_Platform is what you want to read up on… it’s a pretty nice design choice actuallt, even if it can become bloated if you decide to load half the world.

    • swilmet says:

      Eclipse is _one_ application doing lots of different things, with different modes, IIRC: editing mode, debugger mode, tutorial mode, etc. There is a plugin to use a VCS (svn, git), etc.

      Here the idea is not to have one big application, but several smaller ones. The “Rich Client Platform” is just some reusable code. A git submodule or a library is the same.

      • Daniel Svensson says:

        Yep, just like different processes in an operating system communicating with each other via a well established API. The only difference is that the “outer shell” is a virtual machine instead of a non virtual one.

      • Daniel Svensson says:

        Also, to clear out the nomenclature a bit. What you refer to as ‘modes’ here are ‘plugins’ as well that you may decide not to load (or even have to have on your file system) with your own target platform. Even the project/file explorer on the side is a completely optional component just as nautilus and the KDE equivalent is optional in Linux, both probably considered bloat by tiling wm users. Everything you see except the window borders are ‘plugins’, or rather components. Bare bone ‘Eclipse’ is just an empty house, but then I guess it’s not really Eclipse any longer. I do agree that the default Eclipse will require a machine fit for a developer, but when you utilize the same feature set in separate processes, you’re likely to reach a similar total cpu/memory footprint. Personally however, I prefer as said Emacs, together with a nice terminal and small composable utilities, but I just have to stop pointless bashing of Eclipse / Java due to misunderstanding since it’s all too common.

  4. Simon says:

    No, instead, there should be one text editor for each task. And one another general-purpose text editor that don’t include specialized features.

    Oh, hell, no. That’s a horrible idea, because you just know that every single one of those editors is going to behave slightly differently. It’s bad enough using non-core plugins on Eclipse, where you’ve no idea whether a given plugin is going to pay attention to the settings used by others – certain key bindings might not work in the Python editor, the Perl editor ignores the “show line numbers” setting used by every other editor, etc.

    Really, I want a single editing component, that’s smart enough to adapt to the content I’m dealing with – including complex cases like a page of mixed PHP and HTML, with embedded javascript. I want to just do my job, without having to worry about inconsistent editor behaviour…

    • swilmet says:

      With only one text editor that can be used for all the tasks, the settings are more complicated. You will need a profile feature, for example, to have a profile for each task. A profile would contain all the common settings of the text editor (indentation style, text wrapping, right margin, plugins enabled, etc).

      With separate applications for each task, we generally don’t need a profile feature. But all applications would behave similarly, because they would use the same libraries (GtkSourceView, libgedit).

      Currently gedit is a general-purpose text editor, with small plugins for various tasks, but also with big plugins that transform gedit as an IDE. The gedit UI must be generic enough for the plugins, but they will always be restrictions. With an independent application, the UI can be exactly what is needed: not too generic nor too restrictive.

      • Simon says:

        I don’t want all the applications to behave “similarly” – I want them to behave absolutely 100% identically, except to the extent that variation is required for different content. To that end, what you refer to as a profile is exactly what I want – a single editor, with some sort of extension mechanism to provide additional behaviour appropriate to the current content.

        Again, I repeat the example of mixed content. I don’t want separate HTML and Javascript editors – I often have both in the same file, so I want a single editor that’s smart enough to provide HTML assistance when I’m in the HTML sections, and Javascript assistance when in the Javascript sections. And that’s the simplified version, because the HTML page might actually be a JSP or PHP page, or some other kind of templating framework, requiring awareness not only of the local content, but also of functions and data structures in other files in yet other languages.

        Now, I’m not saying this is all possible in any current IDE – but to work productively, I want it to come as close as possible (Eclipse does a reasonable job of mixed-content support, for its standard languages at least). But your proposal is going in very much the opposite direction…

        • swilmet says:

          A specialized text editor can support multiple languages, if they are used together. It is one “task”. Writing a LaTeX document is one task, writing a web site in PHP/HTML/JavaScript is another task. I don’t want to use the same application for both tasks.

          Generally one task = one language. But for web development, this isn’t the case.

        • Simon says:

          Actually, XML editing would be the best example. I want consistent behaviour for all XML content, regardless of what that content is. But I also need some adaptation to the content – providing autocompletion and validation based on a declared namespace if one exists, but also recognising when the document is something more than just generic content – e.g an Ant build file, with no standard namespace, but behaviour that can be inferred from integration with Ant, or a JSF page where the value of attributes can be autocompleted and validated against Java code – and providing fast navigation from #{object.property} in the XML to the getProperty() method in a Java file. Bonus points if it’s smart enough to cope with the method actually being in a JVM language other than Java (Groovy, Scala, etc).

          This is all basic functionality for an IDE like Eclipse, even if it breaks down a little with additional language plugins that don’t integrate as well. Separating those components further could only be a backward step for me…

          • swilmet says:

            There can be some interaction between two applications, through D-Bus for example. If the interactions become too complex, it’s better to integrate the two features in the same application.

            If you often use language B when you use language A, it makes sense to support both languages in the same text editor. It is just one “task”.

            My blog post was just some thoughts. I’m sure it doesn’t work for all tasks. But I think it’s better to have different text editors for completely different languages (e.g. LaTeX and C).

          • Simon says:

            Sure… I just wanted to emphasize that while separate applications might be the traditional UNIX way, it’s not always the better way.

            The downside to building things out of loosely coupled components is that it’s often hard to get a good user experience. The limits on integration quickly become obvious to their user – that their XML editor has no awareness that the content is anything more than just XML tags, that their HTML editor is of no help in writing an onclick() handler because that’s the javascript editor’s job.

  5. Karl Napf says:

    So you are looking for a non-integrated Integrated Development Environment? Sorry, but you do sound a lot like a vim/emacs user that never worked with an IDE! Vim is *not* an IDE, neither is Emacs. Those are just really powerful text editors.

    I want to search for occurences of symbols, not strings of letters! I want to rename a certain variable ‘i’, and do not want to replace all the letters ‘i’ found in one directory. To do this you need to understand the code, which is the feature that distinguishes an IDE from a text editor.

    All editors need access to that code model to do proper syntax highlighting, refactoring features (e.g. rename this variable), etc. That is why editors tend to be built into an IDE: To get all the information from the code model. Or would you want to transport all the data over dbus?

    You should really try using an IDE for a while: It is soooo much nicer than using any text editor!

    • swilmet says:

      In the blog post, I’ve given examples about what you describe, that’s why I use the term “specialized text editor”.

      You didn’t understand the point of the blog post: the “environment” of an IDE can be something different than a bloated application. It can be several smaller applications communicating through D-Bus. I think this way can be worth exploring, and there are already small applications in GNOME for various programming tasks: gedit, Nemiver and gitg, for examples. They currently don’t communicate together AFAIK, but it would be possible with D-Bus.

      • Simon says:

        The thing is, what an IDE provides is a lot more than just “specialised text editors” – it provides a bunch of well-integrated tools.

        For whatever languages you’re using, you’ve got a good editor that’s not just syntax-aware, but hooked into the build system – so it knows what libraries and functions you’ve got access to for the purposes of autocomplete, interactive compile-checking, powerful refactoring tools. The same “editor” is used in the debugger, so you can trace through to find the problem and fix it in the same editor window, maybe even hot-deploying it without restarting the application. And that editor’s also used to integrate with the version-control system, so you can do syntax-aware comparisons, and when resolving merge conflicts, you’ve got all the same benefits of the editor, telling you whether your code compiles or not. Running unit-tests is integrated. Getting code-coverage reports is integrated.

        This really is a big deal in terms of developing productively…

      • Karl Napf says:

        You are talking about some tools that work (mostly) independent and can share some state via DBus. This implies that you have a background using vim, emacs or a similar primitive tool. Nobody else reduces an IDE to an “editor, VCS and debugger all rolled into one”:-)

        What makes an IDE is that a code model that allows it to *understand* the code you write. The code model tends to be a rather biggish (oven more that 1GiB, sometimes significantly more) and complex data structure.

        The integration part of the IDE comes (largely) from everything using this data: Text editors use it to do syntax highlighting, suggest methods and variables, etc. That is way better than what e.g. gedit does or any stand-alone text editor: Those tend to be based on very limited understanding of the code, most of the time using regexps, sometimes together with ctags or similar techniques.

        The code model allows for advanced things like refactoring code: Renaming of variables, moving functions from one file to another (adjusting #includes while doing that), etc.

        Some things like version control can indeed be “bolted on”, but e.g. in Qt Creator even the text editor for commits is connected to the code model (autocompletion of class names, etc.).

        To repeat: In my book an IDE is made up of a set of tools that share one code model and work on it. Since the code model is a big and complex data structure it does not lend itself for sharing via DBus. That makes your suggestion impractical in my understanding.

        DBus also adds complexity: You need to write a DBus spec and keep a whole lot of (standalone) apps up to that spec. That is a whole lot more complicated than writing a monolithic IDE… the monolithic Linux kernel is already here, while the more “distributed” Gnu Hurd is still a while off. I am pretty sure classic IDEs would run similar circles around your DBus-IDE.

      • Karl Napf says:

        PS: How is a set of stand-alone applications less bloated than one application with plugins, assuming both provide the same functionality?