docs/event_loop_simple.png | Bin 0 -> 16043 bytes docs/event_loop_simple.svg | 398 +++++++++++++++++ docs/event_loop_worker.png | Bin 0 -> 29696 bytes docs/event_loop_worker.svg | 708 +++++++++++++++++++++++++++++++ docs/internals/eventloop.html.in | 4 +- docs/meson.build | 2 + 6 files changed, 1110 insertions(+), 2 deletions(-) create mode 100644 docs/event_loop_simple.png create mode 100644 docs/event_loop_simple.svg create mode 100644 docs/event_loop_worker.png create mode 100644 docs/event_loop_worker.svg
The internals/eventloop document uses two images for
illustrative purposes, but unlike other graphics included
in the documentation these are not part of libvirt.git but
rather were added to libvirt-media.git with
commit fae5622074cf5e18d190496f8a43260c614599b2
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Mon Jun 6 17:27:50 2016 +0200
Add two event loop images
These images are going to be used in our documentation of the
event loop.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://gitlab.com/libvirt/libvirt-media/-/commit/fae5622074cf5e18d190496f8a43260c614599b2
and are requested directly from there. Specifically, the
URLs point to the libvirt.org mirror of libvirt-media.git
instead of the primary repository hosted on GitLab.
Import the images into libvirt.git so that the website
doesn't rely on external resources and can, if desired, be
browsed entirely offline from installed packages.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
Redacted to strip binary and binary-adjacent blobs.
Full patch: https://gitlab.com/abologna/libvirt/-/commit/684805e3cf65ab3bb93a92ada3b720331fae72ce
docs/event_loop_simple.png | Bin 0 -> 16043 bytes
docs/event_loop_simple.svg | 398 +++++++++++++++++
docs/event_loop_worker.png | Bin 0 -> 29696 bytes
docs/event_loop_worker.svg | 708 +++++++++++++++++++++++++++++++
docs/internals/eventloop.html.in | 4 +-
docs/meson.build | 2 +
6 files changed, 1110 insertions(+), 2 deletions(-)
create mode 100644 docs/event_loop_simple.png
create mode 100644 docs/event_loop_simple.svg
create mode 100644 docs/event_loop_worker.png
create mode 100644 docs/event_loop_worker.svg
diff --git a/docs/event_loop_simple.png b/docs/event_loop_simple.png
new file mode 100644
index 0000000000000000000000000000000000000000..daf4338a16bc1051aca0ca1c7ea13baa4e7179f1
[... PNG stuff here ...]
diff --git a/docs/event_loop_simple.svg b/docs/event_loop_simple.svg
new file mode 100644
index 0000000000..be25005002
[... SVG stuff here ...]
diff --git a/docs/event_loop_worker.png b/docs/event_loop_worker.png
new file mode 100644
index 0000000000000000000000000000000000000000..1bec1ea598b2806fea24ab25dc825c9055c76ee6
[... PNG stuff here ...]
diff --git a/docs/event_loop_worker.svg b/docs/event_loop_worker.svg
new file mode 100644
index 0000000000..d824e2d585
[... SVG stuff here ...]
diff --git a/docs/internals/eventloop.html.in b/docs/internals/eventloop.html.in
index 3e62d5ca53..aa22ba15cd 100644
--- a/docs/internals/eventloop.html.in
+++ b/docs/internals/eventloop.html.in
@@ -29,7 +29,7 @@
not waiting for direct user input and have no graphical
interface. Such as Libvirt.</p>
- <img alt="event loop" src="https://libvirt.org/git/?p=libvirt-media.git;a=blob_plain;f=png/event_loop_simple.png;hb=HEAD"/>
+ <img alt="event loop" src="../event_loop_simple.png"/>
<p>In Libvirt this approach is used in combination with
<code>poll(2)</code> as all the communication with its
@@ -70,7 +70,7 @@
acceptable for Libvirt. Therefore we have came up with the
following solution.</p>
- <img alt="event loop" src="https://libvirt.org/git/?p=libvirt-media.git;a=blob_plain;f=png/event_loop_worker.png;hb=HEAD"/>
+ <img alt="event loop" src="../event_loop_worker.png"/>
<p>The event loop does only necessary minimum and hand over
message processing to another thread. In fact, there can be
diff --git a/docs/meson.build b/docs/meson.build
index 3aabb52950..3e708acf0e 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -10,6 +10,8 @@ docs_assets = [
'android-chrome-256x256.png',
'apple-touch-icon.png',
'browserconfig.xml',
+ 'event_loop_simple.png',
+ 'event_loop_worker.png',
'favicon.ico',
'favicon-16x16.png',
'favicon-32x32.png',
--
2.31.1
On Thu, Dec 09, 2021 at 16:42:29 +0100, Andrea Bolognani wrote: > The internals/eventloop document uses two images for > illustrative purposes, but unlike other graphics included > in the documentation these are not part of libvirt.git but > rather were added to libvirt-media.git with > > commit fae5622074cf5e18d190496f8a43260c614599b2 > Author: Michal Privoznik <mprivozn@redhat.com> > Date: Mon Jun 6 17:27:50 2016 +0200 > > Add two event loop images > > These images are going to be used in our documentation of the > event loop. > > Signed-off-by: Michal Privoznik <mprivozn@redhat.com> > > https://gitlab.com/libvirt/libvirt-media/-/commit/fae5622074cf5e18d190496f8a43260c614599b2 > > and are requested directly from there. Specifically, the > URLs point to the libvirt.org mirror of libvirt-media.git > instead of the primary repository hosted on GitLab. > > Import the images into libvirt.git so that the website > doesn't rely on external resources and can, if desired, be > browsed entirely offline from installed packages. > > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > --- > Redacted to strip binary and binary-adjacent blobs. > Full patch: https://gitlab.com/abologna/libvirt/-/commit/684805e3cf65ab3bb93a92ada3b720331fae72ce > > docs/event_loop_simple.png | Bin 0 -> 16043 bytes > docs/event_loop_simple.svg | 398 +++++++++++++++++ > docs/event_loop_worker.png | Bin 0 -> 29696 bytes > docs/event_loop_worker.svg | 708 +++++++++++++++++++++++++++++++ Shouldn't these files ... > docs/internals/eventloop.html.in | 4 +- .. be inside the 'internals' directory?
On Fri, Dec 10, 2021 at 11:41:29AM +0100, Peter Krempa wrote: > > docs/event_loop_simple.png | Bin 0 -> 16043 bytes > > docs/event_loop_simple.svg | 398 +++++++++++++++++ > > docs/event_loop_worker.png | Bin 0 -> 29696 bytes > > docs/event_loop_worker.svg | 708 +++++++++++++++++++++++++++++++ > > Shouldn't these files ... > > > docs/internals/eventloop.html.in | 4 +- > > .. be inside the 'internals' directory? For that to work, I'd have to replicate the docs_assets machinery found in docs/meson.build to docs/internals/meson.build. I'm not absolutely against it, and we already have a copy in docs/logos/meson.build after all, but using relative paths seemed preferable. -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Dec 10, 2021 at 03:07:10AM -0800, Andrea Bolognani wrote: > On Fri, Dec 10, 2021 at 11:41:29AM +0100, Peter Krempa wrote: > > > docs/event_loop_simple.png | Bin 0 -> 16043 bytes > > > docs/event_loop_simple.svg | 398 +++++++++++++++++ > > > docs/event_loop_worker.png | Bin 0 -> 29696 bytes > > > docs/event_loop_worker.svg | 708 +++++++++++++++++++++++++++++++ > > > > Shouldn't these files ... > > > > > docs/internals/eventloop.html.in | 4 +- > > > > .. be inside the 'internals' directory? > > For that to work, I'd have to replicate the docs_assets machinery > found in docs/meson.build to docs/internals/meson.build. > > I'm not absolutely against it, and we already have a copy in > docs/logos/meson.build after all, but using relative paths seemed > preferable. Any further thoughts? I'd like to get this merged, be it in one shape or another :) -- Andrea Bolognani / Red Hat / Virtualization
On 12/20/21 19:45, Andrea Bolognani wrote: > On Fri, Dec 10, 2021 at 03:07:10AM -0800, Andrea Bolognani wrote: >> On Fri, Dec 10, 2021 at 11:41:29AM +0100, Peter Krempa wrote: >>>> docs/event_loop_simple.png | Bin 0 -> 16043 bytes >>>> docs/event_loop_simple.svg | 398 +++++++++++++++++ >>>> docs/event_loop_worker.png | Bin 0 -> 29696 bytes >>>> docs/event_loop_worker.svg | 708 +++++++++++++++++++++++++++++++ >>> >>> Shouldn't these files ... >>> >>>> docs/internals/eventloop.html.in | 4 +- >>> >>> .. be inside the 'internals' directory? >> >> For that to work, I'd have to replicate the docs_assets machinery >> found in docs/meson.build to docs/internals/meson.build. >> >> I'm not absolutely against it, and we already have a copy in >> docs/logos/meson.build after all, but using relative paths seemed >> preferable. > > Any further thoughts? I'd like to get this merged, be it in one shape > or another :) > I'd say it's okay. It's just a bunch of pictures. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Michal
On Tue, Dec 21, 2021 at 10:09:17AM +0100, Michal Prívozník wrote: > On 12/20/21 19:45, Andrea Bolognani wrote: > > Any further thoughts? I'd like to get this merged, be it in one shape > > or another :) > > I'd say it's okay. It's just a bunch of pictures. > > Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Thanks! I'll give Peter some time to object before pushing :) -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Dec 21, 2021 at 01:35:21 -0800, Andrea Bolognani wrote: > On Tue, Dec 21, 2021 at 10:09:17AM +0100, Michal Prívozník wrote: > > On 12/20/21 19:45, Andrea Bolognani wrote: > > > Any further thoughts? I'd like to get this merged, be it in one shape > > > or another :) > > > > I'd say it's okay. It's just a bunch of pictures. > > > > Reviewed-by: Michal Privoznik <mprivozn@redhat.com> > > Thanks! I'll give Peter some time to object before pushing :) Well, I'd prefer if the image files don't clutter the main docs directory, because it's already too many files in there. Since it's already a mess, I don't really have too much ground to stand on. I'll try to de-messify it once it irritates me enough, so go ahead regardless of the approach you choose.
On Tue, Dec 21, 2021 at 10:46:34AM +0100, Peter Krempa wrote: > Well, I'd prefer if the image files don't clutter the main docs > directory, because it's already too many files in there. Since it's > already a mess, I don't really have too much ground to stand on. > > I'll try to de-messify it once it irritates me enough, so go ahead > regardless of the approach you choose. Thanks, I've pushed the patch as is for now. I agree that the current situation is a bit messy, especially with most images having both an SVG and a PNG variant and with all the icons included to optimize for various clients. For the former we could just move everything to docs/images/, but I'm not sure if something like docs/icons/ would work for the latter: back in the Web 1.0 days, clients would look for favicon.ico at the top-level so you were pretty much forced to place the file there. Are things any better these days? Could we get away with stashing the various icons in a sub-directory? CC'ing Dan who introduced them and might know. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Dec 21, 2021 at 03:04:49AM -0800, Andrea Bolognani wrote: > I agree that the current situation is a bit messy, especially with > most images having both an SVG and a PNG variant and with all the > icons included to optimize for various clients. > > For the former we could just move everything to docs/images/, but I'm > not sure if something like docs/icons/ would work for the latter: > back in the Web 1.0 days, clients would look for favicon.ico at the > top-level so you were pretty much forced to place the file there. Are > things any better these days? Could we get away with stashing the > various icons in a sub-directory? CC'ing Dan who introduced them and > might know. I've gone ahead and implemented the ideas mentioned above. https://listman.redhat.com/archives/libvir-list/2021-December/msg00828.html -- Andrea Bolognani / Red Hat / Virtualization
© 2016 - 2024 Red Hat, Inc.