-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
streams page #303
Comments
The feeds plugin is currently very minimal, and can certainly be improved ;). And as the logic is very similar for the "streams page" , it should be possible to share some code between the two plugins. For instance I think the
Maybe just a server issue? Did you test with the Python server? With a "real" server you would need to configure it to send the correct mimetype.
I think you need a new template. I need to look at the "Writer" code to have a better idea of what you be done to make it more flexible.
Why not ? It seems it could be a nice feature, so I hope it will come in sigal.
How did you activate your plugin ? If it is not in sigal |
On 2018-02-21 13:43:25, Simon Conseil wrote:
The feeds plugin is currently very minimal, and can certainly be improved ;). And as the logic is very similar for the "streams page" , it should be possible to share some code between the two plugins. For instance I think the `Gallery` class could have a generator which would yield all images sorted by a given key (e.g. date).
True, although I'm not sure much deduplication would be possible,
considering not even the templates would be common...
> the feed just gets downloaded. ;)
Maybe just a server issue? Did you test with the Python server? With a "real" server you would need to configure it to send the correct mimetype.
This was with `sigal serve`. A correct mimetype was sent. I don't think
this is a big deal though: just Chromium being its usual weird.
> I blocked at the step where the Writer class expects an "Album" to write the index.html template:
I think you need a new template. I need to look at the "Writer" code to have a better idea of what you be done to make it more flexible.
The problem with "a new template" is that it affects a lot of things:
all themes need to be ported and so on... Isn't that a huge deal?
The more I think about this though, the more it seems to me that an
Album should have a (recursive) `flatten()` function that would return
an album inheriting all the properties of the album but the merged (and
sorted?) collection of media from all sub-albums.
That would neatly allow me to use the Writer elements and all templates
as is. As a bonus, it would allow per-album streams (and possibly
exclusions too, to fix that feeds privacy leak).
[...]
> `logger.info('generating streams page')`
How did you activate your plugin ? If it is not in sigal `__name__` will be different and it may not inherit the logger config.
I wrote it in ~/src/sigal/sigal/plugins/stream.py, but sigal was
installed with `pip3`, so I hacked my way through by adding ~/src/sigal
to PYTHONPATH. :) That must be why things are failing.
|
ended up writing a prototype based on the 'flatten' approach in #304. let me know what you think! |
Hi!
I've brought this idea up on IRC, but figured it would be more productive to discuss this formally here. :) I'd like to have a way to show the user all the recent images in the gallery. I know that the feeds plugin can somewhat do that, and even that many browsers will display that page somewhat cleanly. But it's really sub-optimal. In Firefox 58:
First, the summary on top is all wrong: it should be HTML formatted, and instead it's one giant blob of text. Then the most important problem: the images are not clickable, which is also a bug in the feeds plugin (one which I'll get into later i guess)...
In Chromium, it looks like this:
ie. the feed just gets downloaded. ;) There are apparently some workarounds for fixing that, but they mostly consist of trying to make Chrome fire up the right RSS feed reader rather than parsing the RSS feed itself (which is silly: RSS is just XML like HTML is, and should be parsable by chrome natively, but whatever).
So we could try to fight that silly battle of making web browsers respect standards, but I doubt we'll go anywhere with that. Which brings me to the idea of writing a "streams" plugin.
I started looking into that, and I've got to the point of writing a stub plugin to get my hands dirty with the mechanics of that. I blocked at the step where the Writer class expects an "Album" to write the
index.html
template:so here i'm looking for advice of where I should go. I can think of two possibilities:
What do you think?
Would such a plugin be merged in the first place? :)
PS: another problem I have mentioned on IRC with my plugin is that this line doesn't yield any output, I'm not sure why:
The text was updated successfully, but these errors were encountered: