When opening pavucontrol.glade with Glade 3.22.1, this message was
shown:
pavucontrol.glade targets Gtk+ 2.16
But this version of Glade is for GTK+ 3 only.
Make sure you can run this project with Glade 3.8 with no deprecated
widgets first.
I think it's best to just drop the gtk2 support.
When opening pavucontrol.glade in Glade 3.22.1 and saving the file
without doing any manual changes, these changes are made to the file.
The changes seem harmless, so let's apply them to avoid unnecessary
clutter appearing when doing more important changes in the future.
When opening pavucontrol.glade with Glade and saving it without any
manual changes, Glade does these object rename to get rid of duplicate
IDs. None of these are referenced by the code, so the renames are
harmless.
Continuing from the previous patch, this patch renames more objects in
pavucontrol.glade to get rid of duplicate IDs. nameLabel and iconImage
actually weren't any more duplicates, because the previous patch renamed
the corresponding IDs for devices and streams, but the card related
objects were renamed nevertheless to be more descriptive and consistent
with the IDs used by the device and stream widgets.
Current Glade versions want object IDs to be unique, but currently
pavucontrol.glade shares some IDs between the top-level windows. I guess
this used to be OK in the past, and the "interface-naming-policy
toplevel-contextual" comment in the beginning of the .glade file
probably has something to do with this. I want to update the .glade file
to be easy to work with current Glade versions, so I will remove the
duplicated object IDs.
The first IDs to change are the "channelsVBox", "nameLabel",
"boldNameLabel" and "iconImage" IDs. These were used by
MinimalStreamWidget to create widgets for both devices and streams, but
now that the IDs are different for devices and streams, the widgets have
to be created by the subclasses.
MinimalStreamWidget doesn't need the Gtk::Builder in its constructor any
more, so remove that parameter to avoid warnings about an unused
variable.
It seems that without explicit initialization of the members they remain
uninitialized. The lack of initialization caused crashing, because
PavuApplication::on_activate() creates the MainWindow only if mainWindow
is NULL, and if it's some random value instead, on_activate() calls
selectTab() on a non-existent window.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pavucontrol/issues/49
This introduces a new file for clarity. Options
handling changes so that --tab changes the tab
if the window is already opened. Other options
are only used at start time.
Also remove the minimum supported PulseAudio version. The current
minimum libpulse version is 5.0, but if it's written on the page, the
information will inevitably get out of date sooner or later.
The previous translation may sound like "Lock up the channels", better
to add the "together" (insieme) in there like in the English version
which gives more the idea of aggregation.
Some fixes for strings which show up on the GUI.
In particular "Blocca entrambi i canali" (which translates back to
"Block both channels") sounded weird with devices with more than
2 channels.
Some lynx versions produce links of the form file:///..., others produce
file://localhost/..., so catch both forms.
Reported-by: Peter Mattern <matternp@arcor.de>
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
Fixes for out-of-tree build, as well as making --disable-lynx work
correctly. Note that make dist will fail if lynx support is disabled (as
it should, since README will then not be available to put in the
tarball).
Due to another bug the MIME type guessing of PNG files was broken on my
Ubuntu system. This made pavucontrol crash on startup (while loading the
necessary icons) without a helpful error message (requiring a lot of
debugging effort). Although this is not originally pavucontrol's fault,
I think that pavucontrol could be more robust about such a problem,
especially because:
A) In a complex database like the one to guess MIME types (that is populated
from hundres of different packages) this can happen from time to time and
B) pavucontrol already has some fallback options in place - they are just not
active in this specific case.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=88813
Tanu Kaskinen