Posts tagged IDE
Posts tagged IDE
I know that Padre, the Perl IDE, is a quite ambitious project. Today I learned that it is big compared to other software projects.
Ohloh.net is a website that, among other things, does source code analysis of free software projects. There is also a page about Padre.
I was surprised to learn that Padre falls into the top 2% of free software project teams in the world regarding number of contributors, with 32 persons contributing over the last 12 months. And that does not even include the work of the Padre translators.

One of the reasons why Padre has so many developers is that the community is very friendly, open and welcoming. There is nothing in the way that keeps you from starting to contribute. It took me just a few days from my first contact with the software to the first bug fix (in between, there was some translation work).
Like the software itself, Padre developers are helpful and friendly to users, no matter whether they are beginners or very advanced Perl programmers.
If you are a Perl developer, or would like to become one, give Padre a try.
If it does not suit you, please let us know what keeps you from using it, and if you like Padre, please tell us what we can improve. Or do it yourself, we will help you along the way.
Here is how you can contact the Padre team, and how you can get involved with Padre development.
At FOSDEM and on the train ride home I finally had some time again to work for Padre, the Perl IDE. In particular, I worked on the LaTeX plugin I that I started a while ago.
I added a syntax checker:

I edit many LaTeX documents at work, so I am really looking forward to using those features in Padre.
We also have different kinds of code completion.
First of all, the normal one for commands starting with \:

Environments (the things that start with \begin{...}) are also treated nicely:

Finally, the code completion recognizes commands that refer to publications or to objects inside the document, and offers primarily those as targets:


In addition, you can visit Detexify from the plugin menu. Detexify is a nice service that tells you the LaTeX commands for symbols you draw.
I would be happy to hear from people using the plug-in what they think about, and receive complaints, suggestions, patches, translations, etc. ;-).
Of course, the LaTeX support in Padre is far from finished:
Next thing I like work on is an outline view for LaTeX documents, and a configuration dialog for additional flexibility. And because I promised to myself to document some of things that I learned so far about Padre, my next Padre-related post will be “How to Write a Padre Plugin”.
One thing that was annoying me lately (not sure whether the problem existed before) was that you never saw the complete context of the search term you just found in Padre:

In that case, it annoyed me because I wanted to find some particular translatable strings that would occur together with sprintf. Well, in the case you see here I had to manually scroll down to see the string, which is never fun, and even less fun if the search window is modal (another thing I want to see gone in the near future).
The fix for this is actually very easy: just add the line
$editor->goto_pos_centerize( $start );
right before the text gets highlighted.
This is how the result looks like:

Much nicer, isn’t it? And it is just two one-line changes.
This makes the search in Padre a bit more usable for me, and I hope for others as well. If everything goes well, this improvement will ship with Padre 0.84.
To weeks ago, I told the story of fixing a seemingly trivial bug in Padre, the Perl IDE.
It turned out that the fix was not a complete one: The mouse event handling works differently on Windows. Adam Kennedy found that out and was so kind to fix it.
Lesson learned: Next time I modify GUI code, I will check it on all platforms - or rather try to convince someone to do that, as I do not have Windows …
Big thanks to Peter Lavender, as the release manager he had quite some additional work with the new release process. 0.82 is the best release of Padre there ever was, and there are already some further improvements in trunk that wait to be released as version 0.84.
Today I want to describe how I fixed a rather simple bug in Padre. I share this experience in detail mostly because I want to motivate other people to help improving Padre’s codebase. While there is plenty to be done, starting to hack Padre can be a bit intimidating because of the rather large and complex codebase.
Warning: Perl code and some Padre internals ahead … if you are not a programmer, this post will most likely be very boring for you.
This article is inspired by an older blog post by Sewi, who also described how he debugged Padre.
First of all, for Padre development you should run the trunk version from the subversion repository.
During the testing of the upcoming release, I came across a small bug that had already been reported a while ago.

The bug was about where the input focus goes when you double click in different parts of the side panel:
My initial assumption was that there must be something in the outline code that sets the focus, which seems to be missing in the other parts. Thus my strategy to tackle this bug was to find this (hopefully tiny) piece of code and add it where it is missing.
The code for the outline view is in Padre::Wx::Outline. Searching for “focus” led me to this line in the method select_line_in_editor:
$editor->SetFocus;

First, I tried to fix this in Padre::Wx::FunctionList (hint: you can quickly access files in the same project with Ctrl-Shift-R). There I search for the statement that was preceeding SetFocus: $editor->goto_pos_centerize. I find it and add $editor->SetFocus; after it.
Then I run Padre’s dev script, which takes into account changes in the source tree without requiring a new installation, to check whether the changes really fixed the bug in the function list.
And what happens? It turns out that this fix does not work. After further playing around, and fixing other issues on the way, I realized that even the SetFocus is not necessary, because goto_pos_centerize already calls SetFocus. I fixed that in the outline code.
The outline, TODO, and function views now behave better than before, or at least have some simplified code, but we still have no progress with our initial problem …
We know that SetFocus is called, so that cannot be the problem. Next assumption: Maybe the SetFocus action is somehow undone by something that happens afterwards? As a first test of this assumption, I added a small pause to the end of goto_pos_centerize in Padre::Wx::Editor:
$self->Update; sleep 5;
This should allow us to see more clearly what happens. What we see confirms our assumption: The focus is in the editor for 5 seconds.
Now we need to find out what causes the change after the focus was already set. The WxWidgets documentation should contain all relevant information for that. The function list inherits from Wx::Panel (wxPanel in C++), and uses a Wx::ListBox (wxListBox) so this is the place to start looking. But no luck here, not much about event handling. Next stop: The description of event handling in Wx::Perl. In particular we are interested which handlers are called. As I could not find this out from the documentation, I took the event list from the Wx::Perl wiki and checked for all kinds of different events:
Wx::Event::EVT_LEFT_DCLICK(
$self,
sub {
my ( $this, $event ) = @_;
warn "Panel EVT_LEFT_DCLICK handler\n";
return;
}
);
Wx::Event::EVT_SET_FOCUS(
$self,
sub {
my ( $this, $event ) = @_;
warn "Panel EVT_SET_FOCUS handler\n";
return;
}
);
Wx::Event::EVT_KILL_FOCUS(
$self,
sub {
my ( $this, $event ) = @_;
warn "Panel EVT_KILL_FOCUS handler\n";
return;
}
);
Wx::Event::EVT_CHILD_FOCUS(
$self,
sub {
my ( $this, $event ) = @_;
warn "Panel EVT_CHILD_FOCUS handler\n";
return;
}
);
# Double click on list ...
Wx::Event::EVT_LEFT_DCLICK(
$self->{list},
sub {
my ( $this, $event ) = @_;
warn "EVT_LEFT_DCLICK handler\n";
return;
}
);
Wx::Event::EVT_SET_FOCUS(
$self->{list},
sub {
my ( $this, $event ) = @_;
warn "EVT_SET_FOCUS handler\n";
return;
}
);
Wx::Event::EVT_KILL_FOCUS(
$self->{list},
sub {
my ( $this, $event ) = @_;
warn "EVT_KILL_FOCUS handler\n";
return;
}
);
Wx::Event::EVT_CHILD_FOCUS(
$self->{list},
sub {
my ( $this, $event ) = @_;
warn "EVT_CHILD_FOCUS handler\n";
return;
}
);
OK, that is not very elegant, but in the end it did the job: I found out that the default handler EVT_LEFT_DCLICK is responsible for stealing the focus. All we need to do is to overwrite this handler:
Wx::Event::EVT_LEFT_DCLICK(
$self->{list},
sub { return; }
);
After adding this event handler to the TODO and the function lists, all that remains to do is to stress-test the new implementation a bit to check whether there are no newly introduced bugs, run ../tools/tidy_project.pl, edit the Changes file, and commit it to the Padre subversion repository:
svn commit -m "fix #967: reset focus" Changes lib/Padre/Wx/FunctionList.pm lib/Padre/Wx/TodoList.pm
Finally, I can close the corresponding ticket in Trac: “Fixed in r13759.”
Easy, wasn’t it? Although it took a little bit longer than expected, I hope you enjoyed it. As already said, there are many more small bugs looking for fixes, and it is not that hard. Plus you get to know Padre’s codebase, which will enable you to even contribute additional features.
If you have questions regarding the development of Padre, don’t hesitate to ask in our IRC channel or on the mailing list.
Debian 6.0 has been released. Another milestone in the history of that GNU/Linux distribution.
Just one figure: Over the 24 month development period, the Debian developers resolved 150,000 bug reports.
Among other things, this is the first release to contain Padre, the Perl IDE.