How can I call a class method of the object's parent class?

[dissident]

I am having a hard time with Curses::UI, for various reasons.

The module's "maintainer" has been showing no activity for about 10 years, shortly since he took over maintainership. He has apparently been ignoring *all* bug reports and proposed fixes that piled up in these years. See the long list of about 50 issues, some of them unfixed since 13 years, spread over two different bug report pages:

https://rt.cpan.org/Public/Dist/Display.html?Status=Active;Name=Curses
+-UI
https://code.google.com/archive/p/curses-ui/issues

I think I have no choice than to fork the last version, already many years old, on Github and work through all these bug reports, and implement the proposed fixes as well as those I had to add myself (which are not yet reported because it doesn't seem make sense to report, as the "maintainer" will ignore it anyway).

I urgently need a Curses::UI working fine. I cannot release my project basing on a Curses::UI in its current bugfested state. This would fall back onto me.

Is there any way to feed back the fixes to CPAN, as the "maintainers" apparently just ignore?

And, finally my biggest problem where I do not understand what is wrong. I need to set the active entry in a Curses::UI::Popupmenu.

The latter package does not have such a method, but the class Curses::UI::Listbox, which the Popupmenu class is inherited from, has a set_selection() method. However, if I try to call this method with

$objectOfClassPopupmenu->set_selection( $value);

I get the error "Can't locate object method "set_selection" via package "Curses::UI::Popupmenu".

If the error is not the way how I called the method, I could imagine it is yet another bug. I'd expect the function to be public, but it behaves like a private one?!? If I must make the function public, what is the recommended way to do this?

[haukex]

In regards to the first part of your question, looking at Curses::UI on CPAN, it does look like the maintainer is not active anymore, so I think it'd be great if you want to take over maintenance of the module. There is a prodecure for this, although it does take a little while - please see Taking over on pause.perl.org.

[dissident]

Thank you very much for the links!

The page explains the stuff very well.

I'll do the steps described there.

Meanwhile I'll work down the bug list and place the fixed files onto Github for review. This way the stuff could be uploaded to CPAN as soon as the process of maintainership change has been finished.

[dsheroh]

I took a quick look at the source on metacpan and, after a couple minutes of "that really should work!", I spotted it: There are two packages in Popupmenu.pm.

You're using Curses::UI::Popupmenu, which is the second class defined in the source file. Its only parent class is Curses::UI::Widget.

The class you want is Curses::UI::PopupmenuListbox, which has two parents, Curses::UI::Listbox and Curses::UI::Window.

[dissident]

Thank you very much for looking into this!

Yes, the thing that this class is actually two packages confused me very much.

Both have different class methods. I followed just the documentation which does not indicate anything about this mixed inheritance, and only tells about using Curses::UI::Popupmenu.

What I am still not understanding how to solve correctly is:

Using the class Curses::UI::PopupmenuListbox does not work, because this class/object is generated/used by Curses::UI::Popupmenu itself, when the dropdown box is to actually be opened/painted.

The object that the application gets with the Popupmenu->new() method is of class Popupmenu, with completely different inheritances than those of PopupmenuListbox class. Thus, if I understand correctly, I have no way to call the PopupmenuListbox methods using the object of class Popupmenu I got.

I have the impression that it is not intended that the application itself deals with the PopupmenuListbox class, which in my impression the author intended to encapsulate from the application.

Thus, thinking about it, I now ask myself whether the correct approach could maybe to implement a Popupmenu class method set_selection(), which can then encapsulate the PopupmenuListbox handling from the application?

[dissident]

Just in case somebody with the same problem finds this thread, here is the method function I added to Popupmenu.pm to solve the problem:

sub set()
{
    my $this = shift;
    my $id = shift;
    $this->{-values}->[$this->{-selected}] = $id;
}

[ikegami]

Instead of forking, have you considered taking over maintainership?

[dissident]

You are probably right.

My problem is just that I am far away from being a Perl wizard. Perl is so vast that I still feel like a beginner. Even after years and a 5-digit sloc count, I constantly discover and learn new things. For example, I am just beginning with Perl OOP. Thus I do not feel sure whether I am competent enough already to become a cpan package maintainer.

But you and haukex convinced me to at least try it. I promise I'll do my best.

[haukex]

I suggest you start small: pick one simple bug, fix it, and test, and then move on to the next. Testing really is important in this kind of situation, since you want to make sure you didn't break anything elsewhere in the code. Unfortunately, Curses::UI doesn't really have an extensive automated test suite (and AFAIK automated testing of Curses apps is nontrivial anyway), but does have fairly extensive example code, that's better than nothing. I'd strongly recommend you always add some kind of test - even if it's only a manual one - for whatever bug you are fixing. Often this will happen naturally anyway, since you'll need to reproduce the bug in the first place; the trick is to integrate that into the distribution - into the automated tests if possible, but at the very least in a file like maybe examples/rt12345.pl (including a short description of the buggy and fixed behavior as POD in that file).

Good luck, and thank you for taking this on! :-) And always feel free to ask here if you have questions.

[ikegami]

But you seem to have the will, and that's far more important. PerlMonks and StackOverflow are there to help you :)