AACU Challenge - QScoreBoard

@zzd10th

Great job, I test the new version of Clipgrab, and works fine, very fine. For me, the best app in the Challenge.
You are the winner.

Quote:Thank you

I ported qpdfview.



Has a few minor issues which I'm working on. One is that not all the images display, but I'm thinking that might be due to lack of memory (even though it still doesn't show them when I reduce the cache size... hmm...)

@Chris

So did I ;). Do you have scrolling problems also? About the missing images, I have no idea...

Forgot to update the QScoreBoard yesterday. It has now been done.

@alfkil

Sorry for my late anser.

I'll pass on the sugested job to fix the torrent example.

I have a project that need to be ready AmiWest, i'll concentrate on that.

René

@alfkil

No scrolling problems that I've noticed.
Just trying to get the DjVu plugin working...

And... qpdfview can now show DjVu documents.



Incidentally the DjVu format appears to be IFF.

@Chris

If you try "hand-dragging" the page with the mouse, what happens?

RibDevil and TommySammy :

Thank you, happy that this port of ClipGrab is appreciated
(RibDevil, please repeat your appreciation to the competition judges :) )


Chris and Alfkil :

Bravo for qPdfView, if it's fast like qPoppler and that it handles automatic page switching, it will replace AmiPDF for sure !

@Chris

qPDFView is really nice. It has some path problems, though. I.e. it can't find it's own help.html document and you can't use it from CLI (or you need to translate "RAM:doc.pdf" to "/RAM/doc.pdf" manually, which makes it somewhat unusable from a usual Amiga DOS script...).

@alfkil
It drags as you'd expect.

@zzd10h
There's a "continous page" option that can be enabled.

@cha05e90
Quote:

I know about those. The first I didn't see as very important (I did have a quick go at fixing it but decided not to waste much time) and the second is a consequence of being forced to use -lunix.
Hmm.. actually, is it necessary to use -lunix? I'll try it without.
edit Yes it is necessary, because the Qt libraries insist on it. Any suggestions for ways around the command line problem welcomed!

Path problem: Poppler has not been built with -lunix, and consequently the poppler demo works with amiga path names from the CLI. I would suggest adding something like the following to the qpdfview code:

extern QString qt_amiga_to_unix_path_name(QString &);

bool DocumentView::open(const QString &_filePath)
{
QString filePath = _filePath;
if(filePath.contains(":"))
filePath = qt_amiga_to_unix_path_name(_filePath);

Poppler::Document ........etc etc

EDIT: Ahem, no, a better way would be to fix the QRegExp and QFileInfo stuff in the main.cpp file. The reason qpdfview doesn\t work with amiga paths is, that the code in main.cpp uses QFileInfo::absoluteFilePath() to expand the paths submitted to it. That call will return a null string for absolute amiga paths.

Is Ascii design works for you ?

For me, no problem but a user says me that it doesn't work for him. I don't understand why...

Please, could you test it and reports me if it works or not.

Thank you

@Chris

Quote:

Hmm, curious. Are you using native or gl painting? Did you get my quickfix1.lha?

@alfkil

I'm using native painting, and have your quickfix1 installed.

I'd be interested to know if anybody else is getting the missing images problem though (I suspect it might just be me).

It's here if you want to try it: http://www.unsatisfactorysoftware.co.uk/download.php?file=qpdfview

I'll have a go at implementing a fix to qpdfview for Amiga paths as you've suggested.

@Chris

Just remove any reference to QFileInfo and set file.filePath = argument instead. Or if you really want to reference your files using absolute paths (I cant see why you would), you need to do some conversion using qt_amiga_to_unix_path_name etc.

BWHAHAHAHAHA! STOP THE COMPETITION!



Unfortunately it runs like a snail in treacle here, and has a few problems. The main problem is this:


If anybody knows how to do that a way which doesn't involve the dynamic_cast crap (which just crashes under OS4) OR if somebody knows how to stop dynamic casting crashing (I think it crashes when the cast doesn't match, rather than doing what it is supposed to) that will be most helpful.

@alfkil

Yes, that works, thanks - well with PDF it does anyway. DjVu is appending the path to the current directory for some reason, but I'm sure that won't be too difficult to fix.

edit Hmm, the PDF I just tested with caused a crash when I did grab dragging. It's one I've opened previously though and had no problems with.

edit2 I can't reproduce the drag crashing problem.

@Chris

dynamic casting has some quirks. AFAIR there is an issue with multiple inheritance classes, that could be the issue here too. I think the best solution is to track the exact inheritance tree of the input to output class and do a check for each step. Or you could just implement a ::type() virtual method, that gives you the actual type of the object in some enum-erated way.