Zeno's Notes

...

Posts tagged IDE

1 note

Padre, the Perl IDE: A Large and Friendly Project

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.

Filed under padre perl ide editor perl5 modern perl ohloh

1 note

LaTeX Plugin for Padre

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:

  • BibTeX syntax highlighting via the Kate plugin is very slow.
  • Syntax checking only works for complete LaTeX documents, even though many people split up their files and include them.
  • There is no spell checking feature, and only pdflatex is currently supported.

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”.

Filed under detexify editor ide latex padre pdf perl publishing tex plugin

2 notes

Padre: Improved Search Usability

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.

Filed under padre perl perl5 modern perl editor ide usability search find fix

2 notes

Addendum to ‘Fixing an “Easy” Padre Bug, Step By Step’

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 …

Filed under padre perl perl5 ide editor modernperl modern perl bug fix wx gtk event handling

7 notes

Fixing an “Easy” Padre Bug, Step By Step

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:

  • For the function and the TODO list, not only the view should change to the function definition in the file, but also the input focus should go to the editor window.
  • This works correctly if you double click on files in the project browser, but the editor loses focus if you double click on a directory.
  • The outline view behaves how it should.

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.

Filed under padre perl ide editor modern perl