Re: [virt-tools-list] [PATCH virtio-win-pkg-scripts v3 0/2] helpers to standardize driver directory layout
On 02/08/2016 11:07 AM, Roman Kagan wrote: > On Mon, Feb 08, 2016 at 12:35:21PM +0100, Christophe Fergeau wrote: >> For what it's worth, I've had success building (did not test) qemu-ga >> with mingw using the attached spec file. > > We build it in a similar way and use it in our testing for some time. > > Are you planning to split it out of virtio-win somehow? > I think Christophe was experimenting with building qemu-ga for integration into spice-guest-tools.exe - Cole ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH virtio-win-pkg-scripts v3 0/2] helpers to standardize driver directory layout
On 02/08/2016 09:23 AM, Roman Kagan wrote: > On Sat, Feb 06, 2016 at 06:20:42PM -0500, Cole Robinson wrote: >> Sorry for the delay, been caught up in other stuff. I'll be focusing on >> virtio-win stuff this coming week though >> >> I've committed these patches now. I added a few commits on top to make my >> pylint[1] setup happy. No functional changes. > > Great, thanks. > I've accumulated a couple of fixes and enhancements in the meantime; > I'll rebase and post them soon. > So I'm full of crap and didn't actually touch virtio-win after sending that mail, except trying to page this stuff back into memory. But it's my main priority for the next bit of time. >> I'm realizing now that the input bits to make-driver-dir.py >> (virtio-win/qxl/qemu-ga windows builders from RH's internal build system) >> aren't published anywhere so there isn't any way for you to reproduce the >> full >> workflow for the public RPM. I'll work on getting those mirrored on >> fedorapeople.org > > Actually we started putting together our stuff, too, and encountered a > number of issues I'd be interested to discuss. > Can I ask what you plan to do with virtio-win RPM/ISO on your side? I'm trying to spec out in my head all the bits that need to change, so understanding what you're needs are will help my get things straight. Are you just interested in extending the RHEL RPM, or the public one as well? What types of bits are you adding? drivers, agents, etc > 1) since the drivers can only be built on a Windows machine, there's a >need to define the artifact(s) produced on a Windows machine and used >as source(s) for rpmbuild on a Linux machine (koji). > >We thought the most natural responsibility split (as applied to >kvm-guest-drivers-windows) is to collect the stuff in "Install" >subdirectories of every driver upon buildAll.bat execution in a >single zip archive and use it as that artifact; the rest will be >taken care of from under rpmbuild on a Linux machine. One benefit is >that it's going to be easy to intervene manually, e.g. when doing >signatures or whatever else. > >This differs from what's currently in virtio-win srpm where the >drivers are received in a tarball whose contents was obviously >subject to certain manipulations after building on Windows. > I'm not really familiar with the windows build process, so I'm not sure I follow all of that. But the idea of pushing some of this rework down into the kvm-guest-drivers-windows build infrastructure sounds like a good one to me, since as you say that's the root source. Regarding handling everything in rpmbuild, I'm not entirely sure how I feel. Doing all the processing at rpmbuild time is probably okay as long as the logic doesn't live entirely in the .spec file, and exists as external scripts that can be tested independently of actually triggering 'rpmbuild'. Then say virtio-win-pkg-scripts-gitXXX.tar.gz should just be about SOURCE in the spec file. That would certainly streamline the process a bit and make it more clear exactly what is going on. Though on the RHEL side that will be a bit difficult, because the shipped drivers are not composed of output from a single virtio-win build, but from _many_ virtio-win builds. For example, the latest winxp viostor WHQL submission might have used drivers from internal build virtio-win-prewhql-26, and the latest win7 vioser WHQL submission may have used bits from virtio-win-prewhql-52. Now a new internal build pops up, virtio-win-prewhql-78. It's used to feed win10 WHQL balloon submission. That build may ship have a newer winxp viostor driver and a newer win7 vioser driver. But we aren't going to ship them, because we are tied to the content that was used for the last WHQL submission. Basically we have an internal git repo that tracks all whql submissions, their associated prewhql input (which is raw kvm-guest-windows-drivers build output), and we use the mappings to create a frankenstein symlink tree that matches the driver layout you see on the virtio-win iso, or from upstream make-driver-dir.py output. The public and RHEL build process then sync's up the rest of the way. So not sure how to handle that in rpmbuild without jumping through more hoops. That said, a fix to sync up the processes a bit more is to generate a symlink tree that matches the same layout as the kvm-guest-windows-drivers build output. Then the public and RHEL build processes would be identical, except for RHEL's prep step of splicing in the WHQL output. > > 2) build scripts for kvm-guest-drivers-windows (haven't checked qxl yet) >don't adhere to the conventions assumed by the scripts I posted. >E.g. here's the relevant excerpt from Balloon/sys/packOne.bat: Snipping this since I don't know enough to comment > > > 3) current virtio-win package includes several loosely related packages: >virtio drivers, qxl, qga; we add our own, too. They have independent >release cycles an
Re: [virt-tools-list] [PATCH v5 1/3] Port to GtkApplication API's
On 02/17/2016 01:22 PM, Jonathon Jongsma wrote:
>>> I disagree, but again, I think it is basically a matter of
>>> preference.
>>
>> It is. From the macro name it is not clear for me how is different
>> "GOTO_END" from "goto end"
>
> For what it's worth, I agree with Pavel here. I think it actually obscures
> things instead of making them clearer.
>
>
Well I think that's already a part of our day-to-day coding, we are
using GObjects all over the place after all. Macros do have their value
if used correctly, and I think this one is a perfect example.
So, what do you think about this "improved" one I proposed? If you say
you don't like it, I can change it without problems.
>>
>>> Looking at it again, I could improve this macro a bit more, by moving
>>> the g_printerr() call inside and receive the message as a parameter:
>>
>> any improvements welcome
>>
>> Pavel
>>
>>>
>>> +#define ERROR_GOTO_END(x, ...) \
>>> +do { \
>>> +g_printerr(x, ## __VA_ARGS__); \
>>> +ret = TRUE; \
>>> +*status = 1; \
>>> +goto end; \
>>> + } while (FALSE)
>>> +
>>>
>>> Regards, Eduardo.
>>>
>>
>> ___
>> virt-tools-list mailing list
>> virt-tools-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/virt-tools-list
--
Eduardo de Barros Lima (Etrunko)
Software Engineer - RedHat
etru...@redhat.com
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] countless password requests
Thanks! The ssh keys setup suggested by Fabiano works fine. LK Am 16.02.2016 um 17:31 schrieb Cole Robinson: The password prompts are because each remote spice connection requires needs to open many different channels, each channel will prompt for a password if you don't have SSH keys setup. So, setup ssh keys like Fabiano suggests. It will fix your problem - Cole On 02/16/2016 11:16 AM, LK wrote: Hi Fabiano, the password is asked by virt-manager when I try to connect to the remote host. After the first request I insert the root password and I can see the list of virtual machines on the remote host. But, If I try to open one of this virtual machine, virt-manager starts asking countless time the root password. LK Am 14.02.2016 um 20:32 schrieb Fabiano Fidêncio: On Sun, Feb 14, 2016 at 11:37 AM, LK wrote: Hi, I'm trying to connect to a kvm server running on a remote Fedora 23 host from an Ubuntu 15.10 host . The connection is established well and I can see the guest machines running on the remote host. The problem happens when I try to connect to a virtual machine: virt-manager (1.3.2-0~15.10~ppa0) start asking me for a password countless times and this make the connection useless. Any ideas to solve this problem? I didn't get exactly which password you're talking about. How are you trying to connect to the virtual machine? Is it ssh? If yes, it may help you a bit: http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/ If not, please, give more details. Best Regards, -- Fabiano Fidêncio -- ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio email.it, per tutti i dettagli Clicca qui http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email_Zimbra_102014=main_footer/f Sponsor: Soluzioni di email hosting per tutte le esigenze: dalle caselle gratuite a quelle professionali su piattaforma Zimbra, da quelle su proprio dominio a quelle certificate PEC. Confronta le soluzioni Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13325&d=16-2 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list -- ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio email.it, per tutti i dettagli Clicca qui http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email_Zimbra_102014=main_footer/f Sponsor: Soluzioni di email hosting per tutte le esigenze: dalle caselle gratuite a quelle professionali su piattaforma Zimbra, da quelle su proprio dominio a quelle certificate PEC. Confronta le soluzioni Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13325&d=17-2 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH v6 virt-viewer 0/3] Port to GtkApplication API's
On Wed, 2016-02-17 at 11:01 -0200, Eduardo Lima (Etrunko) wrote:
> In this version I addressed the comments made from review of v5.
> - Rename virt_viewer_app_startup() to
> virt_viewer_app_on_application_startup()
> - Remove VIRT_VIEWER_VERSION error code and move --version option
> handler to VirtViewerApp.
> - Removed {remote,virt}_viewer_new() functions and call g_object_new()
> directly.
I actually disagree with this last change. I know that remote_viewer_new() is
just a wrapper around g_object new, but it's a standard convention in glib
libraries to privide a constructor function like this, especially when there are
properties that need to be set. In this situation, there's not much benefit
since they're only called from one location, but I still like the convention.
>
>
> Eduardo Lima (Etrunko) (3):
> Port to GtkApplication API's
> remote-viewer: Remove unused properties
> Drop old compatibility code
>
> configure.ac| 6 +-
> src/Makefile.am | 2 -
> src/ovirt-foreign-menu.c| 1 -
> src/remote-viewer-main.c| 173 ++-
> src/remote-viewer.c | 256 +--
> -
> src/remote-viewer.h | 3 -
> src/virt-glib-compat.c | 34 --
> src/virt-glib-compat.h | 83 -
> src/virt-viewer-app.c | 158 -
> src/virt-viewer-app.h | 11 +-
> src/virt-viewer-events.c| 1 -
> src/virt-viewer-file.h | 1 -
> src/virt-viewer-main.c | 113 ++
> src/virt-viewer-session-spice.c | 1 -
> src/virt-viewer-util.h | 2 +-
> src/virt-viewer.c | 120 ++-
> src/virt-viewer.h | 8 --
> src/virt-viewer.xml | 2 +-
> 18 files changed, 353 insertions(+), 622 deletions(-)
> delete mode 100644 src/virt-glib-compat.c
> delete mode 100644 src/virt-glib-compat.h
>
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH v5 1/3] Port to GtkApplication API's
On Tue, 2016-02-16 at 17:17 +0100, Pavel Grunt wrote:
> On Tue, 2016-02-16 at 13:21 -0200, Eduardo Lima (Etrunko) wrote:
> > On 02/16/2016 10:41 AM, Pavel Grunt wrote:
> > > Hi,
> > >
> > > On Mon, 2016-02-15 at 19:22 -0200, Eduardo Lima (Etrunko) wrote:
> > > > Most of this patch consists in code being shuffled around to fit
> > > > the
> > > > expected flow while using the new APIs. I tried my best to make
> > > > this
> > > > patch the less intrusive as possible. Main changes are:
> > > >
> > > > - Updated build requirements
> > > >* glib version 2.38
> > > >* gtk+ version 3.10
> > > >* gio
> > >
> > > For what we need gio ?
> >
> > GApplication code lives in gio. Although Gtk+ should already be
> > pulling
> > it anyway, I thought it should be better to have it explicit.
>
> Sure it is better to have it explicit
>
> >
> > > > diff --git a/src/remote-viewer-main.c b/src/remote-viewer-main.c
> > > > index 81cf736..b05f27b 100644
> > > > --- a/src/remote-viewer-main.c
> > > > +++ b/src/remote-viewer-main.c
> > > > @@ -22,184 +22,29 @@
> > > >
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > -#ifdef G_OS_WIN32
> > > > -#include
> > > > -#include
> > > > -#endif
> > > > -
> > > > -#ifdef HAVE_GTK_VNC
> > > > -#include
> > > > -#endif
> > > > -#ifdef HAVE_SPICE_GTK
> > > > -#include
> > > > -#endif
> > > > -#ifdef HAVE_OVIRT
> > > > -#include
> > > > -#endif
> > > >
> > > > #include "remote-viewer.h"
> > > > -#include "virt-viewer-app.h"
> > > > -#include "virt-viewer-session.h"
> > > > -
> > > > -static void
> > > > -remote_viewer_version(void)
> > > > -{
> > > > -g_print(_("remote-viewer version %s"), VERSION BUILDID);
> > > > -#ifdef REMOTE_VIEWER_OS_ID
> > > > -g_print(" (OS ID: %s)", REMOTE_VIEWER_OS_ID);
> > > > -#endif
> > > > -g_print("\n");
> > > > -exit(EXIT_SUCCESS);
> > > > -}
> > > > -
> > > > -static void
> > > > -recent_add(gchar *uri, const gchar *mime_type)
> > > > -{
> > > > -GtkRecentManager *recent;
> > > > -GtkRecentData meta = {
> > > > -.app_name = (char*)"remote-viewer",
> > > > -.app_exec = (char*)"remote-viewer %u",
> > > > -.mime_type= (char*)mime_type,
> > > > -};
> > > > -
> > > > -if (uri == NULL)
> > > > -return;
> > > > -
> > > > -recent = gtk_recent_manager_get_default();
> > > > -meta.display_name = uri;
> > > > -if (!gtk_recent_manager_add_full(recent, uri, &meta))
> > > > -g_warning("Recent item couldn't be added");
> > > > -}
> > > > -
> > > > -static void connected(VirtViewerSession *session,
> > > > - VirtViewerApp *self G_GNUC_UNUSED)
> > > > -{
> > > > -gchar *uri = virt_viewer_session_get_uri(session);
> > > > -const gchar *mime = virt_viewer_session_mime_type(session);
> > > > -
> > > > -recent_add(uri, mime);
> > > > -g_free(uri);
> > > > -}
> > > >
> > > > int
> > > > main(int argc, char **argv)
> > > > {
> > >
> > > > -GOptionContext *context;
> > > > -GError *error = NULL;
> > > > int ret = 1;
> > > > -gchar **args = NULL;
> > > > -gchar *uri = NULL;
> > > > -char *title = NULL;
> > > > RemoteViewer *viewer = NULL;
> > > > -#ifdef HAVE_SPICE_GTK
> > > > -gboolean controller = FALSE;
> > > > -#endif
> > > > -VirtViewerApp *app;
> > > > -const GOptionEntry options [] = {
> > > > -{ "version", 'V', G_OPTION_FLAG_NO_ARG,
> > > > G_OPTION_ARG_CALLBACK,
> > > > - remote_viewer_version, N_("Display version
> > > > information"),
> > > > NULL },
> > > > -{ "title", 't', 0, G_OPTION_ARG_STRING, &title,
> > > > - N_("Set window title"), NULL },
> > > > -#ifdef HAVE_SPICE_GTK
> > > > -{ "spice-controller", '\0', 0, G_OPTION_ARG_NONE,
> > > > &controller,
> > > > - N_("Open connection using Spice controller
> > > > communication"), NULL },
> > > > -#endif
> > > > -{ G_OPTION_REMAINING, '\0', 0,
> > > > G_OPTION_ARG_STRING_ARRAY,
> > > > &args,
> > > > - NULL, "URI|VV-FILE" },
> > > > -{ NULL, 0, 0, G_OPTION_ARG_NONE, NULL, NULL, NULL }
> > > > -};
> > > > -GOptionGroup *app_options = NULL;
> > > >
> > > > virt_viewer_util_init(_("Remote Viewer"));
> > > >
> > > > -/* Setup command line options */
> > > > -context = g_option_context_new (NULL);
> > > > -g_option_context_set_summary(context, _("Remote viewer
> > > > client"));
> > > > -app_options = virt_viewer_app_get_option_group();
> > > > -g_option_group_add_entries (app_options, options);
> > > > -g_option_context_set_main_group (context, app_options);
> > > > -g_option_context_add_group (context, gtk_get_option_group
> > > > (TRUE));
> > > > -#ifdef HAVE_GTK_VNC
> > > > -g_option_context_add_group (context,
> > > > vnc_display_get_option_group ());
> > > > -#endif
> > > > -#ifdef HAVE_SPICE_GTK
> > > > -g_option_con
[virt-tools-list] [PATCH v6 2/3] remote-viewer: Remove unused properties
The reason for using properties to access those members was to ensure
that they would only be set during the creation of the object. Now that
we removed that restriction, we set private members directly.
Signed-off-by: Eduardo Lima (Etrunko)
---
src/remote-viewer.c | 101 +++-
1 file changed, 4 insertions(+), 97 deletions(-)
diff --git a/src/remote-viewer.c b/src/remote-viewer.c
index 1cef19e..6b12056 100644
--- a/src/remote-viewer.c
+++ b/src/remote-viewer.c
@@ -66,15 +66,6 @@ G_DEFINE_TYPE (RemoteViewer, remote_viewer,
VIRT_VIEWER_TYPE_APP)
#define GET_PRIVATE(o)\
(G_TYPE_INSTANCE_GET_PRIVATE ((o), REMOTE_VIEWER_TYPE,
RemoteViewerPrivate))
-enum {
-PROP_0,
-#ifdef HAVE_SPICE_GTK
-PROP_CONTROLLER,
-PROP_CTRL_FOREIGN_MENU,
-#endif
-PROP_OPEN_RECENT_DIALOG
-};
-
#ifdef HAVE_OVIRT
static OvirtVm * choose_vm(GtkWindow *main_window,
char **vm_name,
@@ -121,56 +112,6 @@ remote_viewer_dispose (GObject *object)
}
static void
-remote_viewer_get_property (GObject *object, guint property_id,
-GValue *value, GParamSpec *pspec)
-{
-RemoteViewer *self = REMOTE_VIEWER(object);
-RemoteViewerPrivate *priv = self->priv;
-
-switch (property_id) {
-#ifdef HAVE_SPICE_GTK
-case PROP_CONTROLLER:
-g_value_set_object(value, priv->controller);
-break;
-case PROP_CTRL_FOREIGN_MENU:
-g_value_set_object(value, priv->ctrl_foreign_menu);
-break;
-#endif
-case PROP_OPEN_RECENT_DIALOG:
-g_value_set_boolean(value, priv->open_recent_dialog);
-break;
-default:
-G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
-}
-}
-
-static void
-remote_viewer_set_property (GObject *object, guint property_id,
-const GValue *value, GParamSpec *pspec)
-{
-RemoteViewer *self = REMOTE_VIEWER(object);
-RemoteViewerPrivate *priv = self->priv;
-
-switch (property_id) {
-#ifdef HAVE_SPICE_GTK
-case PROP_CONTROLLER:
-g_return_if_fail(priv->controller == NULL);
-priv->controller = g_value_dup_object(value);
-break;
-case PROP_CTRL_FOREIGN_MENU:
-g_return_if_fail(priv->ctrl_foreign_menu == NULL);
-priv->ctrl_foreign_menu = g_value_dup_object(value);
-break;
-#endif
-case PROP_OPEN_RECENT_DIALOG:
-priv->open_recent_dialog = g_value_get_boolean(value);
-break;
-default:
-G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
-}
-}
-
-static void
remote_viewer_deactivated(VirtViewerApp *app, gboolean connect_error)
{
RemoteViewer *self = REMOTE_VIEWER(app);
@@ -248,20 +189,14 @@ remote_viewer_local_command_line (GApplication *gapp,
if (opt_args)
ERROR_GOTO_END(_("\nError: extra arguments given while using Spice
controller\n\n"));
-SpiceCtrlController *ctrl = spice_ctrl_controller_new();
-SpiceCtrlForeignMenu *menu = spice_ctrl_foreign_menu_new();
+self->priv->controller = spice_ctrl_controller_new();
+self->priv->ctrl_foreign_menu = spice_ctrl_foreign_menu_new();
-g_object_set(self, "guest-name", "defined by Spice controller",
- "controller", ctrl,
- "foreign-menu", menu,
- NULL);
+g_object_set(self, "guest-name", "defined by Spice controller", NULL);
-g_signal_connect(menu, "notify::title",
+g_signal_connect(self->priv->ctrl_foreign_menu, "notify::title",
G_CALLBACK(foreign_menu_title_changed),
self);
-
-g_object_unref(ctrl);
-g_object_unref(menu);
}
#endif
@@ -288,8 +223,6 @@ remote_viewer_class_init (RemoteViewerClass *klass)
g_type_class_add_private (klass, sizeof (RemoteViewerPrivate));
-object_class->get_property = remote_viewer_get_property;
-object_class->set_property = remote_viewer_set_property;
object_class->dispose = remote_viewer_dispose;
g_app_class->local_command_line = remote_viewer_local_command_line;
@@ -299,36 +232,10 @@ remote_viewer_class_init (RemoteViewerClass *klass)
app_class->add_option_entries = remote_viewer_add_option_entries;
#ifdef HAVE_SPICE_GTK
app_class->activate = remote_viewer_activate;
-
gtk_app_class->window_added = remote_viewer_window_added;
-
-g_object_class_install_property(object_class,
-PROP_CONTROLLER,
-g_param_spec_object("controller",
-"Controller",
-"Spice controller",
-
SPICE_CTRL_TYPE_CONTROLLER,
-G_
[virt-tools-list] [PATCH v6 3/3] Drop old compatibility code
With glib requirements now being 2.38, these functions do not make sense
anymore.
Signed-off-by: Eduardo Lima (Etrunko)
---
src/Makefile.am | 2 -
src/ovirt-foreign-menu.c| 1 -
src/virt-glib-compat.c | 34 -
src/virt-glib-compat.h | 83 -
src/virt-viewer-events.c| 1 -
src/virt-viewer-file.h | 1 -
src/virt-viewer-session-spice.c | 1 -
7 files changed, 123 deletions(-)
delete mode 100644 src/virt-glib-compat.c
delete mode 100644 src/virt-glib-compat.h
diff --git a/src/Makefile.am b/src/Makefile.am
index 42d30fd..a4a420b 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -40,8 +40,6 @@ $(BUILT_SOURCES): %: %.etemplate $(ENUMS_FILES)
libvirt_viewer_la_SOURCES =\
$(BUILT_SOURCES)\
- virt-glib-compat.h \
- virt-glib-compat.c \
virt-viewer-util.h \
virt-viewer-util.c \
virt-viewer-auth.h \
diff --git a/src/ovirt-foreign-menu.c b/src/ovirt-foreign-menu.c
index 9b6d3b8..9859439 100644
--- a/src/ovirt-foreign-menu.c
+++ b/src/ovirt-foreign-menu.c
@@ -28,7 +28,6 @@
#include
#include "ovirt-foreign-menu.h"
-#include "virt-glib-compat.h"
#include "virt-viewer-util.h"
typedef enum {
diff --git a/src/virt-glib-compat.c b/src/virt-glib-compat.c
deleted file mode 100644
index c15ff28..000
--- a/src/virt-glib-compat.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
-/*
- This library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser General Public
- License as published by the Free Software Foundation; either
- version 2.1 of the License, or (at your option) any later version.
-
- This library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public
- License along with this library; if not, see
[virt-tools-list] [PATCH v6 virt-viewer 0/3] Port to GtkApplication API's
In this version I addressed the comments made from review of v5.
- Rename virt_viewer_app_startup() to
virt_viewer_app_on_application_startup()
- Remove VIRT_VIEWER_VERSION error code and move --version option
handler to VirtViewerApp.
- Removed {remote,virt}_viewer_new() functions and call g_object_new()
directly.
Eduardo Lima (Etrunko) (3):
Port to GtkApplication API's
remote-viewer: Remove unused properties
Drop old compatibility code
configure.ac| 6 +-
src/Makefile.am | 2 -
src/ovirt-foreign-menu.c| 1 -
src/remote-viewer-main.c| 173 ++-
src/remote-viewer.c | 256 +---
src/remote-viewer.h | 3 -
src/virt-glib-compat.c | 34 --
src/virt-glib-compat.h | 83 -
src/virt-viewer-app.c | 158 -
src/virt-viewer-app.h | 11 +-
src/virt-viewer-events.c| 1 -
src/virt-viewer-file.h | 1 -
src/virt-viewer-main.c | 113 ++
src/virt-viewer-session-spice.c | 1 -
src/virt-viewer-util.h | 2 +-
src/virt-viewer.c | 120 ++-
src/virt-viewer.h | 8 --
src/virt-viewer.xml | 2 +-
18 files changed, 353 insertions(+), 622 deletions(-)
delete mode 100644 src/virt-glib-compat.c
delete mode 100644 src/virt-glib-compat.h
--
2.5.0
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [PATCH v6 1/3] Port to GtkApplication API's
Most of this patch consists in code being shuffled around to fit the
expected flow while using the new APIs. I tried my best to make this
patch the less intrusive as possible. Main changes are:
- Updated build requirements
* glib version 2.38
* gtk+ version 3.10
* gio
- VirtViewerApp is now a subclass of GtkApplication.
Some mainloop calls were replaced:
* gtk_main() -> g_application_run()
* gtk_quit() -> g_application_quit()
- Unified command line option handling.
The logic has moved from the main functions and split in common
options, and specific ones for each application. With this, the main
functions were highly simplified, and now basically responsible for
instantiating the App object and running the main loop.
- All Window objects must be associated with the Application.
With this, there is no need to emit our own 'window-added'/'window-
removed' signals, as those will be emited by GtkApplication whenever
gtk_application_add_window() and gtk_application_remove_window() are
called. Also, 'window-removed' was not being used anywhere.
Signed-off-by: Eduardo Lima (Etrunko)
---
configure.ac | 6 +-
src/remote-viewer-main.c | 173 ++-
src/remote-viewer.c | 187 +--
src/remote-viewer.h | 3 -
src/virt-viewer-app.c| 158 +--
src/virt-viewer-app.h| 11 +--
src/virt-viewer-main.c | 113 +++-
src/virt-viewer-util.h | 2 +-
src/virt-viewer.c| 120 ++
src/virt-viewer.h| 8 --
src/virt-viewer.xml | 2 +-
11 files changed, 365 insertions(+), 418 deletions(-)
diff --git a/configure.ac b/configure.ac
index 2b979f4..5503d46 100644
--- a/configure.ac
+++ b/configure.ac
@@ -12,10 +12,10 @@ AC_CANONICAL_HOST
m4_ifndef([AM_SILENT_RULES], [m4_define([AM_SILENT_RULES],[])])
AM_SILENT_RULES([yes])
-GLIB2_REQUIRED=2.22.0
+GLIB2_REQUIRED="2.38.0"
LIBXML2_REQUIRED="2.6.0"
LIBVIRT_REQUIRED="0.10.0"
-GTK_REQUIRED="3.0"
+GTK_REQUIRED="3.10"
GTK_VNC_REQUIRED="0.4.0"
SPICE_GTK_REQUIRED="0.30"
SPICE_PROTOCOL_REQUIRED="0.12.7"
@@ -93,7 +93,7 @@ PKG_PROG_PKG_CONFIG
GLIB_MKENUMS=`$PKG_CONFIG --variable=glib_mkenums glib-2.0`
AC_SUBST(GLIB_MKENUMS)
-PKG_CHECK_MODULES(GLIB2, glib-2.0 >= $GLIB2_REQUIRED gthread-2.0
gmodule-export-2.0)
+PKG_CHECK_MODULES(GLIB2, glib-2.0 >= $GLIB2_REQUIRED gio-2.0 gthread-2.0
gmodule-export-2.0)
PKG_CHECK_MODULES(LIBXML2, libxml-2.0 >= $LIBXML2_REQUIRED)
AC_ARG_WITH([libvirt],
diff --git a/src/remote-viewer-main.c b/src/remote-viewer-main.c
index 81cf736..6871965 100644
--- a/src/remote-viewer-main.c
+++ b/src/remote-viewer-main.c
@@ -22,184 +22,27 @@
#include
#include
+#include
#include
#include
#include
-#ifdef G_OS_WIN32
-#include
-#include
-#endif
-
-#ifdef HAVE_GTK_VNC
-#include
-#endif
-#ifdef HAVE_SPICE_GTK
-#include
-#endif
-#ifdef HAVE_OVIRT
-#include
-#endif
#include "remote-viewer.h"
-#include "virt-viewer-app.h"
-#include "virt-viewer-session.h"
-
-static void
-remote_viewer_version(void)
-{
-g_print(_("remote-viewer version %s"), VERSION BUILDID);
-#ifdef REMOTE_VIEWER_OS_ID
-g_print(" (OS ID: %s)", REMOTE_VIEWER_OS_ID);
-#endif
-g_print("\n");
-exit(EXIT_SUCCESS);
-}
-
-static void
-recent_add(gchar *uri, const gchar *mime_type)
-{
-GtkRecentManager *recent;
-GtkRecentData meta = {
-.app_name = (char*)"remote-viewer",
-.app_exec = (char*)"remote-viewer %u",
-.mime_type= (char*)mime_type,
-};
-
-if (uri == NULL)
-return;
-
-recent = gtk_recent_manager_get_default();
-meta.display_name = uri;
-if (!gtk_recent_manager_add_full(recent, uri, &meta))
-g_warning("Recent item couldn't be added");
-}
-
-static void connected(VirtViewerSession *session,
- VirtViewerApp *self G_GNUC_UNUSED)
-{
-gchar *uri = virt_viewer_session_get_uri(session);
-const gchar *mime = virt_viewer_session_mime_type(session);
-
-recent_add(uri, mime);
-g_free(uri);
-}
int
main(int argc, char **argv)
{
-GOptionContext *context;
-GError *error = NULL;
int ret = 1;
-gchar **args = NULL;
-gchar *uri = NULL;
-char *title = NULL;
-RemoteViewer *viewer = NULL;
-#ifdef HAVE_SPICE_GTK
-gboolean controller = FALSE;
-#endif
-VirtViewerApp *app;
-const GOptionEntry options [] = {
-{ "version", 'V', G_OPTION_FLAG_NO_ARG, G_OPTION_ARG_CALLBACK,
- remote_viewer_version, N_("Display version information"), NULL },
-{ "title", 't', 0, G_OPTION_ARG_STRING, &title,
- N_("Set window title"), NULL },
-#ifdef HAVE_SPICE_GTK
-{ "spice-controller", '\0', 0, G_OPTION_ARG_NONE, &controller,
- N_("Open connection using Spice controller communication"), NULL },
-#endif
-{ G_OPTION_REMAINING, '\0', 0, G_OPTIO
