Add template variables for pictures #3430
Conversation
desktop-widgets/templatelayout.cpp
Outdated
| static std::vector<const QString> pictureList(const dive *d) | ||
| { | ||
| std::vector<const QString> res; | ||
| res.reserve(d->pictures.nr); //FIXME |
There was a problem hiding this comment.
always love seeing FIXME comments... :(
There was a problem hiding this comment.
According to April 1st, "FIXME" is there as a reminder to remove the "FIXME" comment. (The actual thing to fix I had already fixed but of course forgot the comment).
atdotde
force-pushed
the
printpictures
branch
2 times, most recently
from
9732406
to
5495e4a
Compare
This introduces a new list the printing templates can loop
over: pictures contains the urls (local or remote) of media
associtated to the current dive. This allows constructs like
{% for pic in pictures %}
<img src="{{ pic.url }}" width=20%>
{% endfor %}
in the printing template.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
|
Yeah, these error messages were fascinating, WTF. Again, I learned I should stay away from attempting to use C++ standard library data types, they are beyond my pay scale (fixed the problem by replacing a std::vector by a QStringList). Honestly, what is the point of abstraction when you cannot use it as a black box but have to worry about the intestines? |
|
In other news, I found this to work only intermittently. Could others please test? There seems to be a race condition with downloading the actual images. This might be related to what stopped us in #3354 |
|
Here is the template I use for testing |
|
There is this very weird thing going on in our printing code where we apparently cannot wait for everything to fully "render" before things get printed. In a way I'd love to completely rethink the way we do this. Get rid of WebView and WebKit and those gigantic libraries for something that really shouldn't be that hard. There's got to be a simpler way to lay out the template and create something that we can then send to the printer routines. These don't need to be web pages. But of course that's a major project that will take time and patience and that's the thing that I am clearly lacking - as is most everyone else. Still - what we do today is a dead end - and the "obvious" switch to WebView doesn't work on Windows, so it's also not the right path. There has got to be a better way to do this. @thiagomacieira how do other Qt apps print? Do they all use WebKit / WebView? Or is there another preferred mechanism? |
|
and after my, I don't know, fifth (?) trip down this rat hole... I still have no better idea how to do this. |
|
To go back to your pull request - yes, I can make it fail fairly reliably. There must be a way to ensure that things have finished rendering before we print. We MUST be doing something wrong here. |
Poorly. QtPrintSupport has seen very little support in the last decade or so. It's been an issue for a lot of applications -- I remember KMail having the same problem. |
|
Maybe we can talk to a car manufacturer to add a printer to the car. That might add encouragement to give art printing done TLC. |
|
Next thing I will try is to ditch QWebWhatever and try if the limited html of QTextEdit might s suffice. |
This introduces a new list the printing templates can loop
over: pictures contains the urls (local or remote) of media
associtated to the current dive. This allows constructs like
in the printing template.
Signed-off-by: Robert C. Helling helling@atdotde.de
Describe the pull request:
Pull request long description:
Changes made:
Related issues:
Additional information:
Release note:
Documentation change:
Mentions: