9:52 a.m.
On Fri, 5 Sep 2014 07:21:41 -0400 (EDT)
Bastien Nocera <bnocera(a)redhat.com> wrote:
----- Original Message -----
<snip>
> What really got my interest was an idea to implement a new GNOME Shell
> search provider (https://bugzilla.gnome.org/show_bug.cgi?id=690058) that
> would integrate with Tracker to index locally installed docs (with
> the search possibly restricted to /usr/share/help/). Similarly to already
> indexed user documents in ~/Documents or personal contacts, users could
> then search for locally installed documentation, including the Release
> Notes, from within the Shell's Activities overview. This would allow for a
> far better (as in systematic) approach to finding files on the user's
> desktop, with a neat categorization in the Shell's search results as an
> added bonus.
Search providers are all backed by applications. What's the application
to read the docs in /usr/share/help? What would be in there other than the
release notes?
It could be gnome-documents as Matthias proposed if we choose to ship PDF
instead of a bunch of HTML pages.
It could be yelp as it supports transforming DocBook/Mallard XML as well as
viewing HTML pages. I just tested it and yelp works quite well:
$ yelp /usr/share/doc/fedora-release-notes/index.html
The right thing to do would probably be to move Release Notes
from /usr/share/doc/ to /usr/share/help/. Indexing /usr/share/help/ would
get users easy access to both downstream (Release Notes) as well as upstream
documentation (GNOME Help, application help, GNOME System Admin Guide,
etc.).
It would probably be better to have those docs be converted to
something Yelp
can read and integrated in the Help, at least for GNOME and for Workstation.
Yes, we could do integration in the GNOME Help. Few things would have to
be figured out, though:
* Whether we want to do this integration upstream with the help of Mallard
conditionals. We would probably need a new test token
(http://projectmallard.org/if/1.0/tokens) for that implemented in yelp.
* Alternatively, we could create a downstream patch. Maintaining this
and figuring out what to do with translations is not something I would
personally want to do. ;)
Cheers,
pk
10:53 p.m.
New subject: Release notes have a launcher - maybe we should remove that
El 05/09/2014 8:52 am, Petr Kovar escribió:
On Fri, 5 Sep 2014 07:21:41 -0400 (EDT)
Bastien Nocera <bnocera(a)redhat.com> wrote:
>
>
> ----- Original Message -----
> <snip>
> > What really got my interest was an idea to implement a new GNOME Shell
> > search provider (https://bugzilla.gnome.org/show_bug.cgi?id=690058) that
> > would integrate with Tracker to index locally installed docs (with
> > the search possibly restricted to /usr/share/help/). Similarly to already
> > indexed user documents in ~/Documents or personal contacts, users could
> > then search for locally installed documentation, including the Release
> > Notes, from within the Shell's Activities overview. This would allow for a
> > far better (as in systematic) approach to finding files on the user's
> > desktop, with a neat categorization in the Shell's search results as an
> > added bonus.
>
> Search providers are all backed by applications. What's the
> application
> to read the docs in /usr/share/help? What would be in there other than
> the
> release notes?
It could be gnome-documents as Matthias proposed if we choose to ship
PDF
instead of a bunch of HTML pages.
It could be yelp as it supports transforming DocBook/Mallard XML as
well as
viewing HTML pages. I just tested it and yelp works quite well:
$ yelp /usr/share/doc/fedora-release-notes/index.html
The right thing to do would probably be to move Release Notes
from /usr/share/doc/ to /usr/share/help/. Indexing /usr/share/help/
would
get users easy access to both downstream (Release Notes) as well as
upstream
documentation (GNOME Help, application help, GNOME System Admin Guide,
etc.).
> It would probably be better to have those docs be converted to
> something Yelp
> can read and integrated in the Help, at least for GNOME and for
> Workstation.
Yes, we could do integration in the GNOME Help. Few things would have
to
be figured out, though:
And how do we address this for the spins? A PDF file in ~/Documents
would be enough, including evince in the media (not sure about KDE-based
spins).
Eduardo
--
http://about.me/mayorgatellez
7:47 a.m.
New subject: Release notes have a launcher - maybe we should remove that
On Wed, 17 Sep 2014 21:53:29 -0600
Eduardo Mayorga Téllez <mayorga(a)fedoraproject.org> wrote:
El 05/09/2014 8:52 am, Petr Kovar escribió:
> On Fri, 5 Sep 2014 07:21:41 -0400 (EDT)
> Bastien Nocera <bnocera(a)redhat.com> wrote:
>
>>
>>
>> ----- Original Message -----
>> <snip>
>> > What really got my interest was an idea to implement a new GNOME Shell
>> > search provider (https://bugzilla.gnome.org/show_bug.cgi?id=690058) that
>> > would integrate with Tracker to index locally installed docs (with
>> > the search possibly restricted to /usr/share/help/). Similarly to already
>> > indexed user documents in ~/Documents or personal contacts, users could
>> > then search for locally installed documentation, including the Release
>> > Notes, from within the Shell's Activities overview. This would allow
for a
>> > far better (as in systematic) approach to finding files on the user's
>> > desktop, with a neat categorization in the Shell's search results as
an
>> > added bonus.
>>
>> Search providers are all backed by applications. What's the
>> application
>> to read the docs in /usr/share/help? What would be in there other than
>> the
>> release notes?
>
> It could be gnome-documents as Matthias proposed if we choose to ship
> PDF
> instead of a bunch of HTML pages.
>
> It could be yelp as it supports transforming DocBook/Mallard XML as
> well as
> viewing HTML pages. I just tested it and yelp works quite well:
>
> $ yelp /usr/share/doc/fedora-release-notes/index.html
>
> The right thing to do would probably be to move Release Notes
> from /usr/share/doc/ to /usr/share/help/. Indexing /usr/share/help/
> would
> get users easy access to both downstream (Release Notes) as well as
> upstream
> documentation (GNOME Help, application help, GNOME System Admin Guide,
> etc.).
>
>> It would probably be better to have those docs be converted to
>> something Yelp
>> can read and integrated in the Help, at least for GNOME and for
>> Workstation.
>
> Yes, we could do integration in the GNOME Help. Few things would have
> to
> be figured out, though:
And how do we address this for the spins? A PDF file in ~/Documents
would be enough, including evince in the media (not sure about KDE-based
spins).
Seems like the easiest fix for those spins having a traditional desktop menu
with a Documentation submenu would be to use OnlyShowIn in the launcher
desktop file. Fedora Workstation could also go with NotShowIn.
A PDF file in ~/Documents is another possibility.
Cheers,
pk
--
Petr Kovar
Technical Writer II | Customer Content Services
Red Hat Czech s.r.o.
Purkynova 99/71, 612 45 Brno, Czech Republic
9:09 a.m.
New subject: Release notes have a launcher - maybe we should remove that
On Sep 19, 2014 6:48 AM, "Petr Kovar" <pkovar(a)redhat.com> wrote:
On Wed, 17 Sep 2014 21:53:29 -0600
Eduardo Mayorga Téllez <mayorga(a)fedoraproject.org> wrote:
> El 05/09/2014 8:52 am, Petr Kovar escribió:
> > On Fri, 5 Sep 2014 07:21:41 -0400 (EDT)
> > Bastien Nocera <bnocera(a)redhat.com> wrote:
> >
> >>
> >>
> >> ----- Original Message -----
> >> <snip>
> >> > What really got my interest was an idea to implement a new GNOME
Shell
> >> > search provider
(https://bugzilla.gnome.org/show_bug.cgi?id=690058)
that
> >> > would integrate with Tracker to index locally
installed docs (with
> >> > the search possibly restricted to /usr/share/help/). Similarly to
already
> >> > indexed user documents in ~/Documents or personal
contacts, users
could
> >> > then search for locally installed documentation,
including the
Release
> >> > Notes, from within the Shell's Activities
overview. This would
allow for a
> >> > far better (as in systematic) approach to finding
files on the
user's
> >> > desktop, with a neat categorization in the
Shell's search results
as an
> >> > added bonus.
> >>
> >> Search providers are all backed by applications. What's the
> >> application
> >> to read the docs in /usr/share/help? What would be in there other
than
> >> the
> >> release notes?
> >
> > It could be gnome-documents as Matthias proposed if we choose to ship
> > PDF
> > instead of a bunch of HTML pages.
> >
> > It could be yelp as it supports transforming DocBook/Mallard XML as
> > well as
> > viewing HTML pages. I just tested it and yelp works quite well:
> >
> > $ yelp /usr/share/doc/fedora-release-notes/index.html
> >
> > The right thing to do would probably be to move Release Notes
> > from /usr/share/doc/ to /usr/share/help/. Indexing /usr/share/help/
> > would
> > get users easy access to both downstream (Release Notes) as well as
> > upstream
> > documentation (GNOME Help, application help, GNOME System Admin Guide,
> > etc.).
> >
> >> It would probably be better to have those docs be converted to
> >> something Yelp
> >> can read and integrated in the Help, at least for GNOME and for
> >> Workstation.
> >
> > Yes, we could do integration in the GNOME Help. Few things would have
> > to
> > be figured out, though:
>
> And how do we address this for the spins? A PDF file in ~/Documents
> would be enough, including evince in the media (not sure about KDE-based
> spins).
Seems like the easiest fix for those spins having a traditional desktop
menu
with a Documentation submenu would be to use OnlyShowIn in the
launcher
desktop file. Fedora Workstation could also go with NotShowIn.
A PDF file in ~/Documents is another possibility.
Cheers,
pk
--
Petr Kovar
This is what we have now, essentially; there's a NotShowIn=GNOME desktop
file that is otherwise the same as it has been for the last few releases.
There's also an OnlyShowIn=GNOME desktop file that launches the book in
epiphany for more native presentation, available to WS users that manually
install fedora-release-notes.
--Pete
3508
days inactive
3522
days old
3 comments
3 participants
participants (3)
-
Eduardo A. Mayorga -
Pete Travis -
Petr Kovar