Archive for the ‘Gnome’ Category

Statuses

Engaging developers

In Bluefish,open source,Gnome,Programming,gtk+ on March 22, 2014 by oli4444

As Bluefish developer I’m not really tightly involved with gnome and gtk development. However, it is our platform, and although we ship OSX and Windows binaries, most of our users are on Linux, many of them using Gnome. We are as much affected by a gtk bug than any other gnome part. So if we find any, we try to contribute.

However, for some reason it feels that our “outside” contributions are not so welcome. I believe this is not intentional, but still this is not a good thing. So what makes me feel that these contributions are not so welcome? The lack of feedback and results.

An example: In 2012-09-05 I filed a bugreport https://bugzilla.gnome.org/show_bug.cgi?id=683388 with a patch to improve the GList documentation. I noticed that new developers often make trivial mistakes (for example appending in a loop). I got some feedback and reworked the patch, submitted on 2012-09-12. And then nothing happened anymore. For 1 year and 4 months there was a total silence. I was originally planning to work trough all of the glib documentation to make it easier for novice programmers to work with, but this result was not really motivating me to do any more work on glib. Until on 2014-01-20 the bug was closed with “fixed”. A tiny bit of documentation was added, but the majority of the patch was not committed. Perhaps it was considered low quality, but at least tell the contributer! And tell how to improve it!

A second example: Early this year a reproducible way to crash Bluefish was reported. We realized the bug was not in Bluefish but in Gtk, GtkTreeModelFilter to be more specific. Instead of just filing a bugreport with the problem, we tracked down the problem and found how to fix it, and filed that in bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=722058 For us this is a critical bug. It makes Bluefish crash. It’s now three months later, and nothing has happened. I’m afraid that the next major gtk release will still have this bug, and Bluefish will remain a crappy application because it crashes because of this bug in gtk.

We should improve this! This is not the way to attract new developers! On the contrary, this does discourage new developers!

End note: I realize that I am not heavily involved with gtk or gnome. So there might be many valid reasons why the above two examples are completely wrong. Perhaps my complete feeling about the feedback and results is wrong. Perhaps my expectations are completely unrealistic. But if I have this feeling, there might be more occasional contributing developers that have this feeling. So we could at least then try to explain the true situation.

End note 2: I’m not a native English writer. So if my language was blunt or rude in any way to any person: this was really not intentional and I apologize. I don’t want to attack anyone. I don’t want to complain. I just want to send a signal that we can do better and should do better.

Statuses

Icons in the file tree

In Bluefish,Gnome,gtk+,open source,Programming on November 2, 2013 by oli4444

The file tree in Bluefish shows icons for the files. To do so, it has an “icon name” column in the tree model, using the special feature of the cell_renderer_pixbuf to render icons by name.

renderer = gtk_cell_renderer_pixbuf_new();
gtk_tree_view_column_set_attributes(column, renderer, "icon-name", COL_ICON_NAME,NULL);

The column COL_ICON_NAME just contains the name (as string) of the icon.

Currently, the icon name is retrieved from a GIcon. The GIcon is retrieved by asking for the property “standard::icon” in g_file_enumerate_children_async().

This means that, for every file, the code creates a GIcon object, just to get a string with the icon name. From browsing trough the glib and gio code I understand that the GIcon is searched for using the mime type, with a binary search in an array that defines all the icons.

I was wondering if I can make the Bluefish code more efficient by caching the icon names for each mime type in a hash table. This has two advantages:

  1. a GIcon object is only created once for each mime type; after we know the corresponding icon name we can do a lookup in the hash table
  2. This needs only one copy of the icon name in memory. In the treestore we can have a pointer to the string in the hash table. Currently 500 text files have 500 copies of the string “text-plain” in memory.

But does this have disdvantages? Any ideas / comments ?

Statuses

The recent menu

In Bluefish,Gnome,gtk+,open source,Programming on July 4, 2013 by oli4444

The Bluefish mailinglist currently has a discussion on the working of the recent files menu. The current recent files menu in Bluefish shows the N most recent items that are not currently opened.

So if you have 15 items in the recent list, but 10 of them are currently open, Bluefish will only show 5.

Many other programs have a different approach: show all recent files, regardless if they are open or not. In the example above, depending on N, the list would either show 15 files, and only the last 5 would be actually useful (they open a file that is not open yet), or the list would show 5 files, all of them would be open already.

In a text editor like Bluefish you usually have many files open (I consider 10 files open very normal usage). So showing only files that are already open, or showing a very long list where only the last items are useful doesn’t look like a good user interface design to me.

But what to do now? Having a different behavior makes the learning curve for new users higher. What do you think is the best design for a recent files menu?

Statuses

Written manual or video howto’s? (and how to make them)

In Bluefish,Gnome,Gnome shell,open source,Screencast,Ubuntu on November 4, 2012 by oli4444

In time, the number of features in Bluefish has grown to a very large number. More and more we receive requests for features that are somewhat superfluous: a similar feature is already present in Bluefish. Often if we explain the submitter how to use a certain existing feature he/she is quite satisfied. This means that some Bluefish features are (too) hard to find.

So what is  the best way to improve this? Is written documentation with screenshots the best way to introduce features to the users nowadays, or are video tutorials (screencasts) better?

From the community the support for our manual project has been declining over the last years (I must admit that I personally think manual writing is not the most rewarding work). Currently the Bluefish manual is mostly improved by a single volunteer, and therefore continuously behind. Is this a sign that written manuals are considered less important nowadays? At least the Bluefish screencasts on YouTube do well (194000 views, but is that high or not?).

So what do you think? Written manual or screencast?

Second subject for this post: what is the best way to create screencasts? Previously I used the built-in screen recorder in gnome-shell: excellent quality with a high compression. Merging the sound, however, always was lousy (tried Pitivi and Openshot): the quality decreased while the file size usually grew a lot. And it was a lot of work. But with the last Ubuntu release (gnome-shell 3.6) the feature seems to be missing (Ubuntu bug or Gnome-shell bug?). What is the best way to create screencasts (with sound) in Gnome-shell?

Articles

Install Gnome3 on Ubuntu 12.04

In Gnome,Gnome shell,Linux desktop,Ubuntu,Unity on June 23, 2012 by oli4444

You like the nice configuration defaults of Ubuntu but not Unity?

Add this to your /etc/apt/sources.list

deb http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu precise main 
deb-src http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu precise main
deb http://ppa.launchpad.net/webupd8team/gnome3/ubuntu precise main 
deb-src http://ppa.launchpad.net/webupd8team/gnome3/ubuntu precise main

Now run

sudo apt-get update && apt-get install gnome-shell

and you have an up-to-date gnome-shell. Even many of the pretty extensions are packaged as well.

As a bonus I found out that Gnome 3 runs much snappier than Unity on an old IBM T43 laptop (which has 6 years old Centrino technology).

Statuses

Improvements for visually impaired people

In Bluefish,Gnome,gtk+,open source,Programming on April 29, 2012 by oli4444

Last week I received an email if Bluefish could be improved for people with a visual impairment. I never occurred to me that there would be people with limited vision wanting to use Bluefish. The most requested features in the email were:

  1. Zoom in/out with ctrl+ / ctrl-
  2. Maximum screen estate
  3. Better cursor visibility

The first feature was easy. Bluefish  already has zoom with ctrl-mousewheel, so I added the accelerators (it turned out that the requester was not aware of this feature).

For the second feature I created an option that automatically hides all menu bars, status bars and toolbars on fullscreen (F11). It displays them again if you hit F11 again. This way basically every bit of the screen is used by the editor itself. The only issue I found is when LXDE is used. LXDE has bound F11 to the window-manager fullscreen, so the application fullscreen never gets called. I moved my code to the configure event handler, where I can detect both the internal fullscreen as well as a window manager fullscreen.

The third feature was the hardest bit. With some help from IRC I managed to make the cursor-aspect-ratio user defined.

In gtk2 it looks like this:

style "bluefish-cursor" {GtkWidget::cursor-aspect-ratio = %f }
class "GtkTextView" style "bluefish-cursor"

which is loaded with gtk_rc_parse_string()

In gtk3it is slightly nicer:

GtkTextView {-GtkWidget-cursor-aspect-ratio: %f;}

which is loaded with gtk_css_provider_load_from_data() and gtk_style_context_add_provider()

Next to a bigger cursor I made a setting to highlight the cursor position: it paints a differently coloured background on the character left and right of the cursor. I connected that to the mark-set insert-text and delete-range signals, the last two with g_signal_connect_after() to get the new location of the cursor and not the old location.

This code does have quite a performance impact: scrolling with the arrow keys is significantly slower with this option enabled. I used this code:

     gtk_text_buffer_get_bounds(btv->buffer, &it1, &it2);
     gtk_text_buffer_remove_tag(btv->buffer, btv->cursortag, &it1, &it2);
     it1 = *location;
     it2 = it1;
     gtk_text_iter_backward_char(&it1);
     gtk_text_iter_forward_char(&it2);
     gtk_text_buffer_apply_tag(btv->buffer, btv->cursortag, &it1, &it2);

What this code causes is an update the internal structure of the GtkTextBuffer (probably something like a balanced tree) that keeps track where each tag starts and stops – for every cursor move. After rethinking this I remembered this is much easier done in the expose event!

get the coordinates with gtk_text_view_get_iter_location(), convert them with gtk_text_view_buffer_to_window_coords() and paint with cairo_rectangle() and cairo_fill():

   gtk_text_buffer_get_iter_at_mark(buffer, &it, gtk_text_buffer_get_insert(buffer));
   gtk_text_view_get_iter_location(view,&it,&itrect);
   gtk_text_view_buffer_to_window_coords(view, GTK_TEXT_WINDOW_TEXT
            , itrect.x, itrect.y, &x2, &y2);
   cairo_rectangle(cr, (gfloat)x2-width, (gfloat)y2, (gfloat)(width*2 )
            , (gfloat)itrect.height);
   cairo_fill(cr);

The result is visible below. So now it is test time!

Statuses

The (too large) minimum width of a GtkEntry in Gtk+-3.2

In Bluefish,Gnome,open source,Programming on December 14, 2011 by oli4444

Bluefish has a side-pane in it’s main interface, which is implemented using a GtkHPaned widget. Users may drag the handle to increase or decrease the side pane. Now lets see what happens if the user makes the sidebar smaller than the widgets in there. I created a mini example application that works with both Gtk+-2 and Gtk+-3. There is a GtkEntry in the left sidebar, and a GtkTextView on the right. This is a screenshot with Gtk+-2:

Initial view of the example application

Now see what happens if you drag the handle to the left in Gtk+-2:

Gtk+-2 making the widget smallerThe widget now becomes smaller, and it is cropped on the right side, which looks natural.

Now see what happens if you drag the handle to the left in Gtk+-3.2:

What it looks like inb Gtk+-3.2The widget is cropped from the left side, which has the content, which looks awful. Also there is a huge empty space after the “Hello World” because the GtkEntry minimum width is very large.

My suggestions for improvement:

  • decrease the minimum width of the GtkEntry to 30 pixels or so
  • when cropping widgets, crop from the right if the widget is on the left side of the handle, crop from the left if the widget is on the right side of the handle. That suggests that the user drags the handle as a layer on top over the widget which feels much more natural.

b.t.w. GtkEntry is not the only widget that has a too-large minimum width. In Bluefish we also use libgucharmap, and the gucharmap widget forces an even wider sidebar in Gtk+-3.2.

Statuses

GtkTable and GtkLabel with wrap on Gtk+-3, and trying to stay compatible with Gtk+-2…

In Bluefish,Gnome,open source,Programming on November 30, 2011 by oli4444

Bluefish has several dialogs that use a GtkLabel with wrap enabled inside a GtkTable. Since the width-for-height changes in Gtk+-3.2 these GtkLabel’s take an enormous amount of vertical space. If this launchpad bug is correct it will use enough vertical space to put every word on a new line.

The suggestion in that bugreport is to switch to GtkGrid. This is a good suggestion, but is has a drawback. In Gtk+-2 there is no way to set widget specifc expand properties in a GtkGrid (in a GtkTable this is done with gtk_table_attach()). In Gtk+-3 new properties have been added to GtkWidget to control whether a widget may expand or not. We (Bluefish developers) try to remain compatible with Gtk+-2 at the moment. So what to do? GtkGrid may solve our problem in Gtk+-3 but causes problems in Gtk+-2, and GtkTable solves our problem in Gtk+-2 but causes problems in Gtk+-3 ?

Luckily I found a workaround:

#if GTK_CHECK_VERSION(3,2,0)
    gtk_label_set_width_chars(GTK_LABEL(label),50);
#endif

This fixes the problem with a GtkLabel with wrap in a GtkTable in Gtk+-3.2. So for the moment we stick with GtkTable with this workaround.

Statuses

Bluefish 2.2.0 released

In Bluefish,Gnome,Gnome shell,open source on November 27, 2011 by oli4444

Bluefish 2.2.0 is a new major release and the start for the 2.2 series. Under the hood Bluefish 2.2.0 has a massive number of changes: Bluefish now works with gtk-3 (gtk-2 is still supported), and the syntax scanner had a major overhaul to make it faster, which is especially noticeable when working on large files.

Another big change in Bluefish 2.2.0 is the new search and replace function. It has been completely redesigned: the simple search function is now integrated in the main window, and the new function supports both search and replace in files on disk (next to already opened documents). Other new features include a toggle comment function that is context-aware (add <!– –> comments in html code, use // comments in javascript code, /* */ in php code, etc. even if all of these languages are in a single file) and a select block feature that automatically selects the current context block and can be used multiple times to select the parent blocks. Another new feature of the syntax recognition is the autocompletion of user-defined functions, and a jump function that will bring you immediately the the definition of a function.

Next to all the new features many existing features have been improved and polished. Furthermore support for new languages has been added, such as Google Go, D, Vala and Ada.

I created an introduction movie using the built in screen recording option of the gnome 3 shell, which has no sound recording. I recorded my voice with audacity and tried to merge them both with pitivi. Pitivi just hanged at rendering 98% no matter what I tried. Then I switched to openshot, which crashed a few times but it did render my video. Unfortunatelythe result was bigger than the original video and sound files, with worse video quality. Anyway, you can see the result on youtube:

p.s. the 2.2.1 release of Bluefish will have a zen-coding plugin!

Statuses

Bluefish, Ubuntu or Gtk bug?

In Bluefish,Gnome,open source,Programming,Ubuntu on October 25, 2011 by oli4444

There is a weird widget scaling issue happening with Bluefish compiled on Ubuntu 11.10 with gtk-3.2.0 that I don’t see on the same Ubuntu 11.10 with Bluefish compiled with gtk-2.24.6 nor on Fedora 15 compiled with Bluefish compiled with either gtk-3.0.12 or gtk-2.24.4.

Bluefish has a GtkHPaned widget to show a sidebar (by default on the left). Inside that sidebar is a GtkNotebook, and inside that notebook is a GtkComboBox. The text string in the GtkComboBox sometimes becomes quite long. Normally this string is just shortened by gtk as can be seen below (the string is file:///home/olivier etc. etc.):

On Ubuntu 11.10 with gtk-3.2, however, this string defines the GtkComboBox minimum width, and if you try to move the GtkHPaned handle to the left it makes all of the contents inside the GtkHPaned move to the left, outside the window border (watch the left side of the GtkNoteBook, see that one of the tabs is moved outside the window? See that the contents of the GtkTreeView are moved outside the window?):

In this example there is a long string in the active entry of the GtkComboBox, but if there is a short string active and a long string only in the popup menu, the issue still appears. So the minimum width is defined by the longest string in the GtkListModel.

In the documentation I cannot find if a GtkComboBox should shrink smaller than the text that is possibly in the popup menu. But I do know that this has never been a problem before on any gtk version up to gtk-3.0 (but Fedora 16 is not yet released, so my only Gtk-3.2 box has Ubuntu 11.10), so I’m wondering if the bug is in Bluefish, Ubuntu or Gtk?

Update 1: I can reproduce this on Fedora 16 beta, so this is not an Ubuntu issue, it is either Gtk-3.2 or Bluefish

Update 2: thanks to the comment from Benjamin Otte I fixed part of the issue by setting the ellipsize property to the GtkComboBox text renderer. However it is still not really back to normal nice behavior. The GtkComboBox furthermore has weird/buggy behavior if ellipsize is disabled. If there used to be a long string in the model, but that string is gone, it still wants a very big width. I think at least this bit is buggy.

Follow

Get every new post delivered to your Inbox.