in r65999 [1] I added a “graphical index”. Hopefully it is an appropriate name. Run make in man dir to get graphical_index.html.
The page itself is quite simple, just images, highlight and link title attribute (shown on hover).
The generation is quite time consuming and it won’t scale well when we add more images (which we will, right?). But if we will keep docs submitting rules [2] then it can be actually much faster.
The page itself can also to big in the future. I see three options how to solve it: lazy loading, generate thumbnails, split by some categories (probably r, v, …). Multiple approaches can be combined together to create different indexes.
There are many ways to improve it, so feel free to suggest or implement one.
Some ideas are need also for making this page more visible.
On Mon, Aug 24, 2015 at 11:16 AM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
Hi,
in r65999 [1] I added a "graphical index". Hopefully it is an appropriate
name. Run make in man dir to get graphical_index.html.
The page itself is quite simple, just images, highlight and link title
attribute (shown on hover).
The generation is quite time consuming and it won't scale well when we add
more images (which we will, right?). But if we will keep docs submitting
rules [2] then it can be actually much faster.
The page itself can also to big in the future. I see three options how to
solve it: lazy loading, generate thumbnails, split by some categories
(probably r, v, ...). Multiple approaches can be combined together to
create different indexes.
There are many ways to improve it, so feel free to suggest or implement
one.
Some ideas are need also for making this page more visible.
Next version of Graphical index is in the repository. Still experimental
but the index now links to module family/class/category list made also with
the images. The images are individually made specifically for the index.
There are some additional links, one of them is to Manual gallery which is
the original auto-generated graphical index of all images in manual pages.
To compile, go to the man directory and run make. The dependencies in the
Makefile are not yet sorted out, so you need to remove the files which
should be updated from dist.../docs/html/.
To compare, have a look at matplotlib [1] (thumbnail) gallery [2] and
screenshot page [3] as well as non-image pages such as examples and
documentation TOC [5] and how they are linked from the main page [1]. Other
example is PCL documentation [6] or Qt Widget Gallery [7].
there is no graphical modeler, even the manual contains a screenshot
Thanks for reporting that. There might be more issues like this. The search for pictures is not 100%, I’m using something more like a “heuristic” than an precise method. I used explicit search (all pictures in all HTML files) but it took forever (minutes, but more than you want to wait during compilation).
Please tell me if you hit something like this. I’ll try to fix it at some point.
wxGUI introduction points to non-existing wxguiintro.html
Similar issues (broken intro/topic/keyword links) are all over the place (not only with the new code). Sometimes we should consider some renames, sometimes the code is wrong or naming inconsistent. Ideally this would be solved by some refactoring. Case by case fixes are possible as well.
By the way, this might be an ideal topic for beginners.
On Sun, Sep 6, 2015 at 5:03 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
> 2) wxGUI introduction points to non-existing wxguiintro.html
Similar issues (broken intro/topic/keyword links) are all over the place
(not only with the new code). Sometimes we should consider some renames,
sometimes the code is wrong or naming inconsistent. Ideally this would be
solved by some refactoring. Case by case fixes are possible as well.
Seeing r66131 and considering also what I was hitting, I think we should
write some rules somewhere. The processing description should stay in the
source code but the comments for topics and keywords should go to
Submitting/Docs page. Because: which rules do we have for keywords?
