IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The application uses an application-id of
"org.virt-manager.virt-viewer" (see function
remote_viewer_new in src/remote-viewer.c).
So far, there was a mismatch between this
application-id and the desktop file name,
resulting e.g. in no proper window icon being
used when running the app on KDE Plasma Wayland.
Adjust the name of the desktop and appdata
files to match the application-id as expected.
Also update the translatable strings using this
command:
ninja -C _build virt-viewer-pot
Fixes: https://gitlab.com/virt-viewer/virt-viewer/-/issues/135
Signed-off-by: Michael Weghorn <m.weghorn@posteo.de>
When using the result of find_program, meson may expand
it to include both an interpretor path and the script
path. If we then add the interpretor path too, we fail.
Using 'full_path()' ensures we get only the script path.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The positional parameter used to be treated as 'input', but since we
already set 'input' explicitly it is redundant. With latest meson
versions it now generates an error
data/meson.build:4:7: ERROR: Function does not take positional arguments.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The download site is on virt-manager.org, not virt-tools.org, so lets
use that site, with TLS too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since gettext is used to extract this file, there is no more need to
prefix the translatable tags with underscore as intltool required.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
- use the "desktop-application" component instead of the old "desktop"
- do not specify a type for the id, and remove the .desktop suffix;
it is implicit for type=desktop-application
- move the URLs of screenshots within <image> tags
- simply remove the non-standard <updatecontact>, instead of converting
it to <url type="contact">, as it is the same
- add URLs for the bug tracking, and the translation system
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
The canonical location for AppStream XML files has been changed to
/usr/share/metainfo four years ago at least, with /usr/share/appdata
left as legacy location. It is time to switch to the right location.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
The project primary git repo has moved from pagure.io to
gitlab.com/virt-viewer/virt-viewer. We want users to submit
code contributions, bug reports and support questions to the
gitlab project, not the mailing list, nor bugzilla, nor the
virt-manager.org site.
We're still using virt-manager.org for hosting downloads of
source and pagure.io for MSIs, but we'll aim to change that
too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Historically we have relied on intltool to install a standard
po/Makefile.in.in which has very limited scope for customization.
intltool is deprecated in favour of standard gettextize tools,
but these share the same disadvantages.
Writing make rules for po file management is no more difficult
than any other rules virt-viewer has, so stop using intltool
and don't use gettextize ether.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
For proper compliance with the GPL and other licenses we need to be
clear about exactly what toolchain and dependent packages we used in
order to build the MSI installer we distribute.
Historically we've done this by including a "deps.txt" file which
provides a list of all the mingw{32,64}-* RPMs on the host system.
This is not sufficient information, however, because the build system
will in fact use various native packages too from the toolchain too,
notably including any program run by "configure" which covers various
shell utilities, and pkg-config, and then of course make & msitools
itself.
Rather than try to figure out which subset of host RPMs are used,
just list every single host RPM that is installed.
A key implication of this is that formal release builds should always
be done in a pristine build root populated with the minimal content
required for the build.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
- spice+unix:// was added in spice-gtk v0.28
- spice+tls:// was added in spice-gtk v0.35
This allows launchers to start remote-viewer when they encounter a
Spice URI with +unix or +tls.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
spice controller interface is being removed from spice-gtk.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Victor Toso <victortoso@redhat.com>
Adds metadata to be used with Gnome Software.
Includes name, summary, description and a few screenshots of remote-viewer.
Signed-off-by: Lukáš Venhoda <lvenhoda@redhat.com>
Acked-by: Daniel P. Berrange <berrange@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of maintain a file which includes every single icon that we use
from adwaita-icon-theme (adwaita-icons-needed.wxi.in), let's depend on
mingw-adwaita-icon-theme directly.
It reduces considerably the maintainability and the risk to have missing
icons. Although, the size of the final binary gets increased from ~35MB
to ~50MB.
Resolves: rhbz#1301064
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The only reason for us to keep maintaining the nsis installer was the
activex plugin (spicex), which requires those nsis based installers.
As the next release of RHEV/oVirt won't use the activex plugin (spicex)
let's completely remove the nsis installer from our tree and focus on
only maintain the msi installer.
oVirt/RHEV is shipping virt-viewer based on 2.0 release and, if needed,
they can stick to 3.0 branch in a future update (in case their plan goes
wrong and they end up needing the nsis support).
Related: rhbz#1324885 and rhbz#1316560
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Since 51ce01d virt-viewer depends again on libvirt-glib.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Since 51ce01d virt-viewer depends again on libvirt-glib.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
As, in theory, file ids are stables, seems that we have been using the
wrong id for remote-viewer.exe (not sure if since forever or if the path
changed).
That's what msidump shows:
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "fil808B4A5BAB4ACD727D3823632E798743" File.idt
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "fil808B4A5BAB4ACD727D3823632E798743" Registry.idt
reg29E29C5608128A0192FB9DC3C18562A6 0
VirtViewer.vvfile\shell\open\command
"[#fil808B4A5BAB4ACD727D3823632E798743]" "%1" CProgIds
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "remote-viewer.exe" File.idt
fil610DF9E49759B1DEC646290195F96F8A cmp7677A8696936707272DCA43B1BF26760
remote-viewer.exe 855735 512 837
So, let's use the correct id (fil610DF9E49759B1DEC646290195F96F8A) from
now on.
Related: rhbz#1146016
Currently libxml2 is pulled as an indirect dependency when virt-viewer
is built with support to ovirt or libvirt (pulled by rest or libvirt,
respectively). However, {virt,remote}-viewer itself depends on libxml2
and not having it as an explicit dependency will cause errors on opening
remote-viewer when it is built without support to ovirt/libvirt.
As virt-viewer builds for Windows are using GTK3 nowadays, we can easily
drop GTK2 support and avoid maintenance effort in something that is not
used/tested anymore.
As virt-viewer builds for Windows are using GTK3 nowadays, we can easily
drop GTK2 support and avoid maintenance effort in something that is not
used/tested anymore.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1146016
Without this parameter the installer will place the start menu icon in the
Admin users path rather than the 'AllUsers'. Unprivileged users are unable
to use the menu to start the remote-viewer.
N.B. Because previous installations mixed Users and PerMachine (AllUsers)
paths, this installation will *NOT* properly upgrade them. They must be
manually uninstalled first.
It turned out that not only the current MSI broke the "component rule",
but also that our files are not versionized correctly. Windows Installer
applies some file versioning rules before replacing a file
http://msdn.microsoft.com/en-us/library/aa368599%28v=vs.85%29.aspx
Since msitools doesn't extract version from files and populate the Version
field of the File table, it "usually" keep the current file installed.
It's practically impossible to rely on version information from
files (from a quick look, only 5% of the files are versionized and even
less correctly, libgcrypt seems to do non-monotonic buildid for example)
So the rule that applies when files are not versionized is to check the
file hash, and the modified date. File hash was added recently in
msitools, but doesn't apply when the installed file itself has a
version.
In order to solve the above problems, it's simpler to just have a
different installation prefix. Windows Installer will see files with
different component guid, and won't be checking any file update rule. I
have verified the upgrade is working, not leaving any file behind and
updating registry correctly with this solution. Until the files are
correctly versionized, it looks like the only sensible thing to
do. Furthermore, this make it simpler to have several versions installed
in parallel later on (when we change productid)
Add support to build the virt-viewer's msi using GTK3.
For the GTK3 build, in order to provide all used icons for Windows
systems we have to include manually all the icons we want to or add
adwaita-icon-theme as dependency. I've decided to go with the first
approach, what can be improved when we have "foreach" support in
msitools (https://bugzilla.gnome.org/show_bug.cgi?id=741296).
