Gtk3, GObject Introspection and Free Pascal

A while back the Gtk community started a project called GObject Introspection. In short it exports the Gtk and Glib api, as well as many others, to an easily parsed xml format.

The result is gir2pascal.

gir2pascal can create bindings to pascal from any library that supports gobject introspection in just a few moments! The result is that Gtk3 bindings have been created fairly easily for pascal and can easily be updated simply by running gir2pascal against the latest version.

Here is part of the XML code from the Gtk3.gir file relating to the caption of the button:

<class name="Button"
           c:symbol-prefix="button"
           c:type="GtkButton"
           parent="Bin"
           glib:type-name="GtkButton"
           glib:get-type="gtk_button_get_type"
           glib:type-struct="ButtonClass">      
      <implements name="Atk.ImplementorIface"/>
      <implements name="Actionable"/>
      <implements name="Activatable"/>
      <implements name="Buildable"/>
      <constructor name="new" c:identifier="gtk_button_new">
        <return-value transfer-ownership="none">
          <type name="Widget" c:type="GtkWidget*"/>
        </return-value>
      </constructor>
      <method name="get_label" c:identifier="gtk_button_get_label">
        <return-value transfer-ownership="none">
          <type name="utf8" c:type="gchar*"/>
        </return-value>
      </method>      <method name="set_label" c:identifier="gtk_button_set_label">
        <return-value transfer-ownership="none">
          <type name="none" c:type="void"/>
        </return-value>
        <parameters>
          <parameter name="label" transfer-ownership="none">
            <type name="utf8" c:type="gchar*"/>
          </parameter>
        </parameters>
      </method>
      <property name="label"                construct="1"
                transfer-ownership="none">
        <type name="utf8"/>
      </property>
 </class>

One improvement over the current (Gtk2) bindings in use is that Pascal objects (not classes) have been used in place of records. The advantage is that GObjects, a C style quasi-object, can be accessed in an object oriented way instead of the flat C functions we use currently.

Here is the corresponding generated pascal code from the XML above:

type
  TGtkButton = object(TGtkBin)
    priv3: PGtkButtonPrivate; 
    function new: PGtkButton; cdecl; inline; static;
    function get_label: Pgchar; cdecl; inline;
    procedure set_label(label_: Pgchar); cdecl; inline;
    property label_: Pgchar read get_label write set_label;
  end;

function gtk_button_new: PGtkButton; cdecl; external;
function gtk_button_get_label(AButton: PGtkButton): Pgchar; cdecl; external;
procedure gtk_button_set_label(AButton: PGtkButton; label_: Pgchar); cdecl; external;

implementation

function TGtkButton.new: PGtkButton; cdecl;
begin
  Result := Gtk3.gtk_button_new();
end;

function TGtkButton.get_label: Pgchar; cdecl;
begin
  Result := Gtk3.gtk_button_get_label(@self);
end;

procedure TGtkButton.set_label(label_: Pgchar); cdecl;
begin
  Gtk3.gtk_button_set_label(@self, label_);
end;

You can see that we are using objects instead of records, compare this to the current Gtk2 bindings:

type
  PGtkButton = ^TGtkButton;
  TGtkButton = record
    bin : TGtkBin;
    event_window : PGdkWindow;
    label_text : Pgchar;
    activate_timeout : guint;
    flag0 : word;
  end; 

function gtk_button_new:PGtkWidget; cdecl; external gtklib;
procedure gtk_button_set_label(button:PGtkButton; _label:Pgchar); cdecl; external gtklib;
function gtk_button_get_label(button:PGtkButton):Pgchar; cdecl; external gtklib;

Before, our code would look like this:

procedure Foo;
var
  Button: PGtkWidget;
begin
  Button := gtk_button_new;
  gtk_button_set_label(PGtkButton(Button), 'Hello World!');
end;

But now it's possible to use this instead:

procedure Foo;
var
  Button: PGtkButton;
begin
  Button := TGtkButton.new;
  Button^.label_ := 'Hello World!';
end;

As you see it's a bit shorter to type the second way. Although either will work since the 'flat' functions are still available to use.

Using objects instead of records it is of course possible to access inherited methods and properties with greater ease than before, especially when using the code completion feature of Lazarus (which is extremely close to 1.0 now!). Button in the example above descends from GtkWidget which has the property tooltip_text.

This can be accessed with

Button^.tooltip_text := 'Don''t click me unless you want to!';

whereas before you had to do

gtk_widget_set_tooltip_text(PGtkWidget(Button) ,'Don''t click me unless you want to!');  

Here's the HelloWorld example included with the bindings, modified to have a tooltip.

 The Pascal Gtk3 bindings are not yet well tested. There are a couple of examples in the Lazarus-ccr repository in the folder /bindings/gtk3/examples/ including an example of GtkWebkit.

Perhaps you would like to try it out :)

Preparing for Lazarus 1.0 (RC1)

Just to announce: Lazarus is preparing to go 1.0.

The first release candidate for the new Version has just been made public on sourceforge. Please test it.

You can find the announcement for the RC here: http://forum.lazarus.freepascal.org/index.php/topic,17717
And a list of what changed is here: http://wiki.lazarus.freepascal.org/Lazarus_1.0_release_notes

Pascal does a strong showing in the Linux Questions Members Choice

Of course that internet quiz is not something scientific but it is nevertheless good news. Both Pascal and Lazarus made a strong showing in the Linux Questions Annual Members Choice Awards, competing with software sponsored by huge corporations. Other software written in Lazarus also appeared in the show, such as Double Commander and LazPaint.

Let's start with Lazarus itself running against other IDEs:



And how Pascal / Object Pascal as a language fared well too (despite someone mistakenly having added it as "Free Pascal"). It is pretty hard to see because of so many multiple lines, so I added a bigger line connector, but anyone can check in the full description of the results here: http://www.linuxquestions.org/questions/linux-news-59/2011-linuxquestions-org-members-choice-award-winners-928502/



See also how Double Commander fared:



And LazPaint:



If there was a category for Accessibility probably the Virtual Magnifying Glass would appear =)

Felipe Monteiro de Carvalho

Exploring the iPhone

As all should know, since my previous post I managed to finish off all the missing bits and get a decent initial support for Android in the LCL. But of course we are not stopping there, so I started exploring the iPhone. I haven't yet done any programming, but I already found a lot of interesting thing. Many good things, but also many bad things.

So let's start with the good things:

I was expecting something similar to Android, just more expensive, but while the user interface is remarkably similar, I must say that Apple has an extremely good taste for designing things. Everything in the iPhone is just beautiful. Each small detail seams well though out to look good, while in Android everything exists in a similar shape, it just looks OK in Android while it look great in the iPhone. Sure that some manufacturer like HTC and Sony Ericsson changes radically the user interface and even UI widgetset look, but in all cases they don't come close to looking as good as the iPhone.

The available RAM in the iPhone is pretty excellent. The iPhone 4 comes with 512MB of RAM of which aprox. 300MB are free for user applications. That's a huge amount in comparison to Android devices where you might even have 300MB or RAM, but the system is already eating 250MB =( The iPhone is also free of all that crapware which manufacturers like to fill the scarce ROM memory of Android phones, and the iPhone has a huge common memory for both media files and applications, which makes it able to run bigger apps without problems.

Now some things which are different:

The start screen is nearly identical with horizontal scrolling except that the iPhone home screen is much less configurable. You cannot place those nice widgetset to turn on/off mobile network or WiFi on a single click. The iPhone is also not very intuitive to use at times, with only icons and no perceived way for me to find out what an icon does except by guessing or testing, while in Android text labels are used much more often. There are no hints either.

And now the bad:

Frankly I am appalled that I have never heard of the evil side of the iPhone before. Why is nobody commenting that?? Am I the only one deeply bothered by this!? For me this was so terrible that I will never buy an iPhone again, for sure my next smartphone will be Android again. The iPhone is just the most restricted device, the most DRM filled, the most anti-freedom, the most monopolist, the most anti file owning device I have seen in my life. Let's start with the basic. On Android you put a SDCard in the phone and then you connect it with a USB cable to the computer and voilà! It opens as a mass media device with zero drivers installation in *any* operating system. Windows, Linux, Mac, works just as great in all! Then you can copy your music there, copy APK packages, you can copy your personal documents, you can copy source code, I don't know, you can do whatever you want! Sadly Android doesn't come with a File Browser but you can easily install the "OI File Browser" and then with it you see all your files on the phone and manage them. You can install any app to read your files. You can use the phone as a pen drive, you can create a new application to open, view and modify any file extension in the world and share that application. You can share your files. That's freedom! That's general computing! The freedom that any computer should offer.

And the iPhone!? Where are the file managers? I haven't yet found a single one which will show my photos, movies and music. WTF!?!? There are some file managers which require installing extra programs in the desktop and essentially are a sort of hack around the limitations imposed by Apple. Is music just a product you consume from bigshot producers? Can you even run you own music there? Where is my freedom to run my MP3 which I generated myself from a CD I bought in Paraguay? Those guys are not in the iTunes Mr. Jobs and I don't want to restrict myself to your iWorld. Cloud storage as an extra option, OK, but ban file owning, copying and sharing!? That's the evil dream of any monopolist. I don't want to be part of that evil iWorld, I want a general computer. But that's what the iPhone certainly does not want to be.

So, well, let's say you are conformed with the iPhone having zero file owning capabilities. What's next? It only docks to your computer via the iTunes after installing a plethora of drivers and does not work at all in Linux. You cannot freely install applications which you wrote yourself without joining the Apple Developer Program and go through a complicated process. In Android you can write apps and share them easily without any of this non-sense.

And to make it worse: Apple is monopolistic. It banned 3rd party browsers. Where is the freedom? I don't want to be stuck with Safari. I already like Opera Mobile, but they banned it. Sure there is Opera Mini, but Mobile is much more what I want.

So here we are: A superb phone, the best looking GUI and design I have ever seen. Excellent quality of the touch screen. All ruined by monopolistic, anti-freedom non-sense! All ruined by a company which wants to ban people from owning files.

Felipe Monteiro de Carvalho

LCL for Android

As the maintainer of LCL-WinCE of course I was quite shocked when Microsoft dropped Windows Mobile into the limbo and announced that native applications would be restricted to a very small list of favorite partners. Because of this, since almost 1 year now I have been trying to port the LCL for Android.

My first success was in 19th January 2011 when I first built a good x86-linux -> arm-linux cross-compiler which I have been using ever since and I hosted here: http://sourceforge.net/projects/p-tools/files/Free%20Pascal%20for%20ARM/

After that I slowly started exploring Android and the SDK with many pauses. My free time floats a lot depending on the work load, my mood and my current interests. I have other hobbies which alternate as my biggest interest from time to time. The most important ones are: trains (reading news and discussing in skyscrapercity as well as travelling), politics (I'm right wing / conservative), keyboard playing and Pascal programming.

Ok, so next thing around in August I got some bounties which motivated me to make a good push. When I started we were in Android 2.2 still, and I bought a HTC Wildfire which came with 2.1 and can be upgraded only up to 2.2. At this time the perspectives for native applications were quite doomed, you had to interface with Java via the horrible JNI, I got pissed off by that and I developed an alternative system which worked by running a native executable and communicating with pipes with a Java machine. I posted about it in the android-ndk Google group and the Google guys hated my idea, they told me to buy and iPhone and try programming for that instead =D Well, I could do that, but seriously the Lazarus community is on a high mood for Android support, I don't remember yet anyone asking about iPhone support ... even requests of WebOS and Bada were heard. My hacky development strategy might sound like a bad idea, but I had many motivators for it:
1> If you can only have a library then the way LCL applications work changes dramatically =( I'm not sure yet how this will be worked around. You cannot keep the same main project file if Android requires a library and you also need changes in the project code flow.
2> FPC has a lot more bugs for library development then for executable development, specially in ARM-Linux
3> Using my method I could access the entire SDK without JNI! A true blessing. So I could quickly push some controls and get things working.
4> I also hoped that if people pushed then Google would flexibilize and support executables, but now I think I was too optimistic. At that time Android 2.3 was released and it brought a lot of improvements for native applications, but ever since there were very few changes in the NDK, so I lost my hope that Google would support native executables.

The alternative way would be creating a native library which draws all controls, and there are enourmous challanges in doing this. So, fast forwarding a bit into the future, after a bounty I got some expertise in NDK development with OpenGL so I got quite animated and I started a huge push to see how far I can push LCL-CustomDrawn until I run out of steam.

These days I feel like soldiers must have felt in the Market Garden operation, running against time to take all bridges in the way. I am not trying to consolidate the entire area, I just need to make as many breakthroughs as possible in as many key areas as possible to make sure that my development strategy works. Every time that we start doing something which was never done before, like LCL in Android you have a huge uncertainty about whether or not it will actually be possible to work, or if I will face a huge wall somewhere, like a compiler bug or a problem which needs a lot more steam then I got to solve ... so I want to clear the way and establish that my strategy indeed will work.

So far I have already taken the following bridges:

1> Lazarus Custom Drawn Controls - The first one to be tackled, it is far from complete, but I advanced it so well and so fast that it is clearly proven that we can have our own set of custom drawn controls inside Lazarus

Reference: http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls

2> Developing the major structure of LCL-CustomDrawn to allow painting with a non-native Canvas into a native surface. I already implemented this for Win32, X11 and Cocoa, so we are quite advanced here.

3> Develop a system to clip the painting of sub-controls and also clip events from sub-controls inside a form. In LCL-CustomDrawn TWinControl will be non-native, because some platforms like the Android surface do not support it. I have achieved success here too.

Now I am trying to push into a last bridge, which is resisting heavily:

4> Achieving a minimal LCL-CustomDrawn application which can run in Android and paint at least a rectangle or something.

I am facing big challanges in this task, the major ones being that when I simply include the LCL the application starts to crash, even if I don't call anything from it =( I have narrowed down to cwstrings, which is a major source of crashes, so I disabled it, but now the application crashes when clicking on it. I tryed to comment out all initialization sections in the LCL, but it didn't help. My greatest fear is a compiler bug somewhere which would reproduce only in big programs like LCL apps and stop me =( But so far it appears that I am going well, let's hope we will succeed here and clear 1 more obstacle in this difficult road.

Edit: I managed to get it working now, the second problem was introduced while debugging the cwstring issue. Now it works fine =) So we are each day closer to have LCL-CustomDrawn running in Android. From what I can see my snapshot compiler has no bug which could defeat us, so the path is ready =)

Edit2: Now it loads the application and it can draw some green stuff =D Really exciting days for LCL-CustomDrawn-Android. It still doesn't do anything useful, but the entire fact that it loads without crashing and can render something is excellent.

Remember, Remember ... The History of Debugging

Debugging your application can be an intriguing task. And analyzing what happens in your application, and what went wrong (or maybe right), often requires the developer to keep an eye on quite a lot of data.
Sometimes that means not only to look at the data as it is on the current step of execution, but also to compare it to what it was on the previous step(s).

Lazarus does now provide a history overview for watched values, locals, and call-stack. Each time your application stops, a record of this data is made and stored.
By default Watches and Locals are recorded for the current stack-frame/thread. But if you browse other frames or threads by selecting them in the stack or threads overview windows, then Lazarus will notice this and keep track of those too.

A new debug window "History" provides access to all recorded values. Currently this is up to 25 history entries. And you can even browse the history after you program terminated.
If you have a history entry selected, you can use the stack-window to change the current stack. If any data was collected for the selected frame, it will be shown. Currently data for extra stack frames is only collected if the frame was selected, while your app was running, and if the watches or locals window where open and active.

There is however a little twist to it. Collecting all the data takes some time. To avoid any slowdown of the debugger, this new feature works on idle time only. It collects data, only if the debugger has no other work. This even means that you can continue the execution of your application, without having to wait the full time it would have taken to get all the data. In this case the snapshot will be incomplete.
If you want to ensure complete snapshots, you can open the watches, locals and stack window, and observe when the information has been fully fetched, as it gets displayed to you.

This feature is available in Lazarus 0.9.31

Profiles for Build Lazarus

The dialog opens from Tools --> Configure "Build Lazarus".
It is meant for building Lazarus or parts of it, using the given parameters.
The original dialog looked about like this.



The dialog was made by the same developers that actually use it all the time. Thus the GUI is little confusing, it's main design goal was not "ease of use".

Then some people made an effort to simplify the GUI. They didn't touch the original GUI but instead added another "Quick" tab sheet to the dialog.



The original GUI was named "Advanced" tab sheet (as seen in the first picture).
A problem was that this Quick page was not very intuitive either.
There were radiobuttons for options which is OK but then also 2 settings for LCL Interface, Target and IDE. They were never both enabled at the same time. So weird. If some Lazarus user really was so "non-advanced" that he needed this simplified page, how could he understand the difference between Target and IDE LCL Interfaces?

The worst problem however was that the Quick settings modified directly the Advanced settings, but there was no visual feedback about it. It took some time to realize it. A generally accepted GUI convention is that tabs have individual separate sheets. I remember I started using the Advanced page very soon although I was not an advanced user yet. I dare to say very few people used the Quick page.

Already a year ago I created a big patch implementing Build Profiles. It kind of extended the idea of quick selections and made it configurable. It also made the GUI more intuitive. In fact the sane GUI was my main motivation, the profiles were more like an extra bonus.
It was my first substantial patch for Lazarus and I had to study lots of code for it. At the same autumn I had started evening school (although I am not young). Now I can reveal that I made the Lazarus patch partly when I should have read to my math exam. Under pressure my mind goes into a hyper-active state or something. A psychologist could maybe explain it better. Anyway, I scored well in the math exam, too, no problem.

My feature got attention and mails were written but it was not accepted. Actually I created many versions of the GUI based on feedback.
The first version had everything at the same page in 2 panes, Profiles pane and Details pane. That was intuitive but big and crowded.
The second version had a clear list of profile names and a button that opened a details form for the selected profile. That is still my favourite. It is the most intuitive GUI for such things.
It was rejected because the (hard-)core developers want to use the settings as before. The dialog has to be "settings oriented", not "profile oriented". The third version (= the current dialog) follows that idea.

For a while the patch was forgotten but I salvaged it using a local git branch. Recently, finally, it was accepted to Lazarus trunk! After that it was changed some more based on feedback. Widgetset is now selected using a combobox instead of radiobuttons. Options have more room in a multi-line memo and there is a user-configurable list of defines to select from. Etc...
The latest (for now) version looks like this:



There is another dialog for managing the profiles:



I got positive feedback especially from people who cross-compile. The GUI is still complex but it is intuitive and very usable.

A more philosophical point can be made, too. GUIs should be designed and implemented by different people. As a mind-set, GUI design is more close to graphics design than to computer programming.
If no such designers are available, at least comments from outsiders (not Lazarus user) should be listened. I noticed myself that one gets used to confusing GUIs very quickly. A month or two passed and I didn't pay attention to it myself.
Open source projects with financial backing usually concentrate more on visual appearance. And commercial SW, too, of course, but sometimes they consider visual appearance more important than code quality which is not good either.


Juha