Update the codebase

[wdlkmpx]

mhwaveedit's codebase is too old, gtk4 is to be released this year and most of the codebase is gtk1 and deprecated gtk2 stuff.

Porting the code to gtk 2.24 is a major task.. I see @gkarsay has tried : https://github.com/gkarsay/mhwaveedit/commits/master

Maybe we can resume his work, I rebased his commits on top of upstream https://github.com/wdlkmpx/mhwaveedit/tree/gtk2

The commits can be improved, expanded and grouped into patch sets perhaps.. and pull requests can be opened...

This is what should be done:

• update the build system and remove autotools files from the tree
• remove gtk1/glib1 stuff
• replace gtk2 deprecations with newer functions (2.24+)
• replace ancient glib stuff (2.32+)
• remove support for really ancient platforms and desktop environments [audio: arts, esound, etc).

gtk 2.24 + glib 2.32 = 2011

2011 happened 9 years ago, is that old enough?.. ubuntu precise

So what do you think?

[magnush]

Hi,

I could turn the question around, what practical problems are there with the current state of the code and building with an old GTK version? What is it you can not do, is there anything that looks ugly, something that does not integrate with the rest of the desktop, etc? I'm not asking to be rude, I just wonder what your motivations are for this...

It's old but I do take some pride in that you can throw in the current version of mhwaveedit into almost any old Linux machine and it will build and play sounds. But it's personal taste of course. In my case I have an old netbook that I use to record in vinyl records...

I suppose updating the code will have to be done eventually though, maybe you might as well fork the codebase and release under a new name if you're successful with the update (if you say "based on mhwaveedit" in the credits or something like that, it's appreciated). That gives a bit more freedom to change things in whatever direction you want, and you don't have to worry so much about backward compatibility etc.

For the internal structure of the code, there is a file HACKING in the repository that gives an overview. I would recommend reading through that and the internal docs (Help/Documentation).

Some issues I can think of for modernizing the code base:

• Some objects that are not GUI-related should be changed from GtkObject to GObject (GObject didn't exist in GTK1)
• There are some places using Pixmaps and bitmaps, I'm not sure that's supported in the newer GTKs so some parts may need to be rewritten there.
• The GtkItemfactory used for menus etc is deprecated since a very long time.
• The custom main loop in mainloop.c should probably be replaced with the default GMainloop. Then also the custom main loop glue for libpulse could be replaced with it's built in Glib glue. However keep in mind the main loop has been written to give very high priority to sound processing so make sure to test changes properly so you don't get underruns.
• The inifile system, you may want to revise this, you need to decide if you want to integrate with Gnomes config system or continue with a separate system (or support both with a compile-time switch). I think internally the inifile settings could be represented in a more object-oriented way
• I'm not sure if there is a more modern way to deal with translations and i18n
• The color scheme management is very "non-standard", I guess this could be tied in with how themes work under newer versions of GTK (was it based on CSS or whatever).

[marclava]

Sorry for jumping in with an unrelated request, but I'd like to use mhwaveedit almost as is (without a gtk update), because it looks fast and usable on a Raspberry Pi, and because if it works, why "fix" it?

What I need is support for a lot more channels, minimum 20. It should a small change in the code, but I don't know where.

[magnush]

Marc: I don't know either. There are places in the code where it's hardcoded assumption of max 8 channels, like local array variables that are allocated. So one would have to find all those places, and replace them with a constant MAXCHANS, then after that you could just increase that constant. One way to find the bad spots may be to run under valgrind and see in what functions it starts doing bad things with memory, another way to find clues be to search for the constant 8 in the code.

[wdlkmpx]

Fair points actually.

Marc: Unless you're using the GTK1 user interface, you're using the GTK2 version of gtk1 widgets.. most of them deprecated, using the true GTK2 version of said widgets doesn't cause any issues and helps the project survive in the long term.

It's possible to keep the gtk2 ui for a long time, unlike the gtk1 ui, which makes updates really impossible.

Magnus: Updating gtk stuff is not something that can be done easily, it takes time

The fork to update it to gtk3 was started and aborted 3 years ago.. many updates have already happened... GtkItemFactory has already been replaced.

Gtk3 brings hidpi and wayland support.

I don't see improvements and new features being added since a long time, new contributors might not know how to handle gtk1 code. Yes, some people might be able to add new features.. if you let them.

I'm not sure, right now I'm using a distro derived from Debian stretch 2017 (different kernel and boot) in a pentium 4 pc made in 2003 1GB ram.. so newer systems do work in old hardware.

I say 2011-2012, because distros released around that time have the legacy XAA xorg acceleration before it was removed. New and old stuff supported.

The current build system might be broken in very recent distros, if this is as old and outdated as gftp, it certarinly is broken.

My intention is just to send a message, I use Audacity, and I see mhWaveEdit does work for very basic tasks and I guess it's only missing the ability to set (adjust) the waveout volume.

[marclava]

My other option could be to use the "non-daw" software (the change to support more than 10 channels was to change one number in the C code), but I don't know if it's as easy to use than mhwaveedit. An Audacity is too heavy/slow...

[wdlkmpx]

So what gtk version is Marc using.. GTK1 or GTK2?

Ideally it would be great to add gtk3 support while keeping gtk1 support.. but the code would be unreadable and unmaintainable. Gtk2 hides the real complexity, once you try to compile with gtk3 you'll see that many gtk1 widgets no longer exist and have to rewrite everything.

But slowly migrating to pure gtk2 (the last version) does the trick, gtk3 support becomes a possibility.

Gtk2 was released in 2003 I think, Gtk3 was released in 2011.

[marclava]

There's no trace of GTK1 on my system (Xubuntu 18.04). I would use mhwaveedit on recent Gnu/Linux systems with lightweight desktop managers like XCFE.There's of course other very nice GUI libraries that could be used for an upgrade of mhwaveedit (that would run well on small computers), but I believe GTK2 is still a safe choice.

[magnush]

@wdlkmpx Yes you're right that updating the code is best done in steps. First, remove GTK1 support which is a "mechanical" job (within ifdefs etc), then migrate to newer GTK2, then GTK2 to GTK3..

I'm however not interested in doing this work myself, and I think it would best be done in a fork of the code. If you provide a pull request that updates to newer GTK2/3/4 and it does not break any existing functionality or change the UI in significant ways then I will however seriously consider merging it into official mhwaveedit. If you do a fork+rename instead then you of course do whatever you want without asking me and I wish you luck in that case.

I was not aware of the existing fork/attempt at porting until today, but I took a quick look. I saw the Itemfactory was replaced with lots of manual code to create menu items, that of course 'formally' removes the deprecated interface but it feels kind of pointless and it creates messier code. You might as well just copy the itemfactory code from GTK into mhwaveedit in that case, and call it something else, or write your own itemfactory-like code. How do people actually build up menus on modern GTK nowadays? I guess there must be some automated way of doing it than creating the objects by hand.

[wdlkmpx]

GtkItemFactory was replaced by GtkUIManager (gtk2)

GtkUIManager works in gtk2.x and gtk3.x

I can convert GtkItemFactory code to GtkUIManager, I can do complex things with gtkuimanager see (see gftp pr 46)... I learned the hard way just a few days ago, but I think manual stuff may be compatible even with gtk4.. easier to fix.

GtkUIManager was deprecated in gtk3 3.10 in favor of GtkBuilder... GtkUIManager does not exist int gtk4.

I guess I can port patches from the fork in a more organized way, improve or expand some of them, and even provide some more, but it really depends, it's easier when it's text... streams and stuff.. looks a bit more complex

The projects needs a team..

[wdlkmpx]

For example the commit that updates the build system should delete the autotools files and add autogen.sh (and set minimum autoconf version to 2.68 (2010))

Probably let intltool manage the gettext stuff... let's say that only those distros that can successfully run ./autogen.sh are supported (2011+)

I verified that a release tarball created with debian stretch also works fine in a distro released in 2012 (ubuntu precise, slackware 14.0).

The path for a pure gtk2 ui is not easy, but as the project hasn't added features since a loooong time, those using really old distros will not need the new mhWaveEdit.. cause it won't have new features.. only a more recent codebase, unless a new big contributor appears in the horizon..

[wdlkmpx]

Another thing to understand is that by updating stuff things will be simpler, because all the unix and linux distros have become more posix compliant. Everything is more standard nowadays.

So all the thousands of checks no longer apply... only a few.

When it comes to audio, alsa, pulse and jack are basically the winners, and maybe SDL for portability... OSS, arts, esound are no longer used.

mhwaveedit is missing a couple of very basic features but I guess supporting many audio backends makes it impossible to implement anything that deals with audio volume or something. There are priorities, alsa is basically the only thing required for linux and extended support and features can be enabled for alsa...

Current users will not miss the updates, it will take a lot of time just to replace ancient widgets.

So let's begin..

[magnush]

@wdlkmpx what are the "very basic features" missing?

[wdlkmpx]

Ability to change the playback/waveout/pcm volume within mhwavedit.. although you can also run the mixer, I don't have xmixer

A good default Mixer utility is:

xterm -e alsamixer

alsa dominates linux since 2008-2009 probably, and the alsamixer app is always present

[magnush]

@wdlkmpx Yes ok a volume adjustment thing could be something to add. I have avoided it originally because one important design decision is that mhwaveedit avoid modifying data behind the user's back so playback data should be exactly what is in the file whenever possible. It could fool the user if the volume is 100.1% and degrade sound quality. So there needs to be thought behind it so it's clear when volume is not at the default. It needs to be handled similar to the varispeed support where 1.0 just passes through the data.

The default mixer app is reconfigurable in the configure script --with-default-mixerapp. Changing the default in the configure script is a one line change.

[magnush]

Please note that this application is a personal hobby project of mine, with my name on it. It is free software but it's not a community run project, and it will likely never be. I have the final say in what goes in and not. I don't like being "pressured" on the issue tracker into accepting things, I like to think things through. And sometimes I don't have time to work on it so things stand still for a while.

I would suggest that you work on a fork of the code, until you have a codebase thatbuilds under GTK3, or with some other noticeable improvement. At that point we can have a discussion about merging that into mhwaveedit master, or maybe it should be made into a separate project and renamed into something else.

[wdlkmpx]

That's what I wanted to hear.

I don't consider myself a developer, but a "facilitator" and if something falls on my shabby 2 hands, then it's likely that I will encourage people to do things and merge stuff, 'cause that's what I do.

As I said, I'm using a PC made in 2003 [many intel components] with a distro released in 2017. So as a user of a modern distro in a obsolete machine, I can say that I'm not really worried about old distros or unix systems.

There are also very lightweight distros, TinyCore, SLiTaz... Alpine Linux.. these distros run on very under-powered machines. Support of the latest gtk2 is guaranteed. I don't plan to remove gtk2 support in the short term, maybe in 2030?

I hope that put things into perspective.

How about gWaveEdit?

[wdlkmpx]

OK, I'll continue gkarsay's work in this repo: https://github.com/wdlkmpx/gwaveedit

The source code will be edited to change the app name.. after a massive cleanup which will happen shortly.

Compiling the code I see the toolbar doesn't look that good, it has not changed or added any feature it's only about updating the codebase, and probably some changes could have been done a bit differently but.. who knows.

So, that's it, someday it will be probably ready to be merged back.

[magnush]

gWaveEdit sounds good --> go for it!

I admire your energy, if you are successful to get a small community maintaining the codebase I will be very, very, impressed and really happy.