Server API versions < 35 do not support PA_COMMAND_SEND_OBJECT_MESSAGE
one of these is current Pipewire pulseaudio server.
Do not quit on error sending message to object, this is already handled as if
send message API is not available.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/merge_requests/57>
The end result is the same, so this isn't strictly needed - originally
this patch fixed a segfault, but that segfault got fixed in a different
way before merging this patch.
Fixes this compilation issue:
pavuapplication.cc: In function ‘int main(int, char**)’:
pavuapplication.cc:146:32: error: use of deleted function ‘PavuApplication::PavuApplication(PavuApplication&&)’
auto app = PavuApplication();
^
In file included from pavuapplication.cc:29:0:
pavuapplication.h:27:7: note: ‘PavuApplication::PavuApplication(PavuApplication&&)’ is implicitly deleted because the default definition would be ill-formed:
class PavuApplication : public Gtk::Application {
^
In file included from /usr/include/gtkmm-3.0/gtkmm/window.h:32:0,
from /usr/include/gtkmm-3.0/gtkmm/dialog.h:30,
from /usr/include/gtkmm-3.0/gtkmm/aboutdialog.h:33,
from /usr/include/gtkmm-3.0/gtkmm.h:99,
from pavucontrol.h:29,
from pavuapplication.h:24,
from pavuapplication.cc:29:
/usr/include/gtkmm-3.0/gtkmm/application.h:211:3: error: ‘Gtk::Application::Application(const Gtk::Application&)’ is private
Application(const Application&);
^
In file included from pavuapplication.cc:29:0:
pavuapplication.h:27:7: error: within this context
class PavuApplication : public Gtk::Application {
^
In file included from /usr/include/glibmm-2.4/glibmm/wrap.h:26:0,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:26,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:23,
from /usr/include/glibmm-2.4/glibmm.h:91,
from /usr/include/gtkmm-3.0/gtkmm.h:87,
from pavucontrol.h:29,
from pavuapplication.h:24,
from pavuapplication.cc:29:
/usr/include/glibmm-2.4/glibmm/objectbase.h:238:3: error: ‘Glib::ObjectBase::ObjectBase(const Glib::ObjectBase&)’ is private
ObjectBase(const ObjectBase&);
^
In file included from pavuapplication.cc:29:0:
pavuapplication.h:27:7: error: within this context
class PavuApplication : public Gtk::Application {
^
In traditional packages, including 'pavucontrol' here is redundant with
Exec. However, only the first field of Exec is used as a search key,
and in the Flatpak the first field is 'flatpak'. I often search for
'pavucontrol' and fail to find the app as a result.
All the others are terms that seem relevant to finding this app. Most of
them are borrowed from gnome-control-center's sound panel's .desktop
file.
The old logic disabled the expander always when a sink didn't have any
ports. That's bad if the sink has no ports but supports configuring
formats. That hasn't caused problems so far, but I have a patch for
module-null-sink that will enable format configuration support, and the
null sink has no ports, so it's affected by this issue.
This patch also changes things so that the expander is completely hidden
when it's disabled instead just setting it non-sensitive. I think that's
better (at least it saves some space).
The updating flag is used to determine whether a change in some UI
control state is due to a user action or an update from the server. The
flag was set to false too early when processing sink and source updates
from the server. This caused at least unnecessary "set port" commands,
because each update refreshes the port list, which generates change
events in the port list combo box, causing the portChanged callbacks to
be called.
The unnecessary "set port" commands could even confuse the automatic
port selection policies in the server. If the current port wasn't
originally explicitly chosen by the user, then the "set port" command
from pavucontrol will make the server think that the user explicitly
chose that port.
If load_icon() fails, we treat the icon name as a file path and try to
load an image from the path. In case that works, we need to ensure that
the has correct size. Previously that wasn't done, which led to too
large icons.
scale_simple() doesn't do anything if the image is already the correct
size, so we can call it unconditionally.
The exception handling was a bit weird in that the exception types
didn't match the documentation of IconTheme::load_icon() and
Image::set(). I updated the exception types (Image::set() doesn't need
exception handling any more, because now it's called with a Pixbuf
rather than a file name).
Fixes: https://gitlab.freedesktop.org/pulseaudio/pavucontrol/issues/60
pavucontrol.glade previously set the channel label width to 15
characters, with the goal of making all channel labels have the same
width. However, with some translations and font settings the configured
width wasn't enough, so sometimes a label was wider than others, and
that made the volume slider widths different too. If the volume sliders
have different widths, it's very hard to visually compare the volumes of
the channels.
This patch removes the fixed width in pavucontrol.glade and solves the
problem by finding the widest label and using that label's width with
all labels.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pavucontrol/issues/51
DeviceWidget and StreamWidget had some duplicate code to initialize
ChannelWidgets. This patch moves some of the duplicated initialization
code into ChannelWidgets to reduce repetition and to improve
encapsulation.
The channel labels ("Front Left" etc.) that are adjacent to volume
sliders used to be left-aligned, which meant that there was some empty
space (depending on the text width) between the label text and the
volume slider. Right-aligning the labels looks nicer.
The volume strings (e.g. ‘86% (-3.81dB)’) shown to the right of each
volume slider is now translatable/localisable. (The similar string
‘100% (0dB)’, centred *below* each slider, was already translatable.)
Also, the English strings now include a space between the decibel value
and the unit, e.g. ‘-3.81 dB’ instead of ‘-3.81dB’.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pavucontrol/issues/52
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.
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
pa_stream_peek can return NULL if either the buffer is empty or if it
has a hole. In either case we need to avoid derefencing the data
pointer. Additionally, if there is a hole, we need to call pa_stream_drop,
if the buffer is empty we should not call it.
BugLink: https://bugs.debian.org/735898
RoleWidget::create contains:
x->get_widget_derived("streamWidget", w);
But streamWidget is defined as following in the glade file:
<object class="GtkEventBox" id="streamWidget">
Where as RoleWidget is derived from [Minimal]StreamWidget, which is derived
from Gtk::VBox, so this is clearly wrong.
Adding:
printf("rolewidget type: %s\n", g_type_name(G_TYPE_FROM_INSTANCE(w->gobj())));
for debugging shows that this really leads to RoleWidget being instantiated
as an EventBox (yet things still work due to sheer luck).
This commit fixes this, by putting the streamWidget id at the right level of
the hierarchy in the glade file (and likewise for cardWidget and deviceWidget).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Igor V. Kovalenko