Presentation clock not working

[mmonaco]

I built from git recently and I can only get two copies of the wall-time. I'm sure one of these is meant to be the presentation counter.

(@dannyedel I agree with the feature request that you submitted about count-down timers being nice, I wonder if it would even be possible to use some tex magic to submit per-slide countdown metadata).

[dannyedel]

I cannot reproduce that, on my systems current git compiles and runs fine (Bottom row left-to-right is wall clock, then previews, then total and current-slide clocks).

I'm guessing you're using a different OS and/or desktop environment than me, and that I've used some platform-dependent code where it shouldn't belong : )

If it worked before: can you run a git bisect to figure out which commit changed things?

Also: What environment and Qt Version are you running this on? (Maybe there's a subtle difference in the Qt time class handling, debian wheezy has version 4.8.2)

[mmonaco]

I'm using Arch Linux. Linux 3.12.0, qt 4.8.5. Git bisect wasn't conclusive because there is intermediate breakage:

Bad . . . 5d62496 - Timers back but now incorrect . . . c853d51 - Only wall clock time works, other clocks are not shown 1b3842e - Timer only updates on keypress, but is correct . . . Good

[dannyedel]

On a freshly-updated arch amd64 VirtualBox (linux 3.12.0-1-ARCH, qt 4.8.5-6) I cannot reproduce this. However, I did get unexpected behaviour - on all the commits that you mentioned I got two black screens.

Out of curiosity, I checked out a few tags and on 1.7 and 1.8 all I got was black screens. 1.9, 1.10, v1.10.1 and master work just fine - with correct clocks aswell.

On another note: I've seen you made a build script, however I'm not sure if the cmake call is optimal. Personally I always work by creating a subdirectory build, and from there calling cmake ../ -DBLAH=FOO and make. Note that you don't need to call cmake again after source change or git pull; it works a "call cmake again" into the generated Makefile, so "make" is enough.

[mmonaco]

I updated the PKGBUILD based on your suggestions.

I actually run off of testing, so maybe it's something else. I'll try on my laptop as well. Otherwise, I'll track this down on my own, it seems it might be a problem specific to my system.

[mmonaco]

When you installed on Arch, did you use my PKGBUILD?

[dannyedel]

No I did not, I did the standard cloning, creating a builddir and cmake'ing manually.

Now I've tried the PKGBUILD and I get the exact same results as you - which seems strange. Investigating the issue, I've found the switch!

If you compile with -DCMAKE_BUILD_TYPE=Release the clocks don't work correctly, if you leave it out they work fine. I'll try fix this, at least I can reproduce it now.

[mmonaco]

Hmm. I copied that from the -git PKGBUILD on aur.archlinux.org. Is it something you recommended? I've never seen that before.

That said, I tried removing it from my PKGBUILD and still had the problem, so are you sure it's fixed?

[dannyedel]

Retest now please : )

For the original PKGBUILD and how it was created, check #2. I admit that I did not actually read it through as close as now, because there was no "something does not work" situation. I don't know how Arch does things, but it might be useful if there's only one pkgbuild in the repository.

[mmonaco]

I don't plan on publishing my PKGBUILD in the AUR, unless the current maintainer orphans it. His pkgver() is not right IMO, and also that bit about removing .git directories is not needed so I'm not sure he knows what he's doing.

For some packages you have and -git. But for a small project like this, it really only makes sense for people to build from git.

In any event, 4c2cdf8 did the trick.