OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Neil Waldhauer on March 04, 2015, 04:58:04 am

Title: qpdfview
Post by: Neil Waldhauer on March 04, 2015, 04:58:04 am
I'm trying to run qpdfview-0_4_14-GA, but when I open a pdf, I get a message box saying

could not load plug-in for type 'PDF'

I think I loaded all the prerequisites. Is there a way to find out why it could not load the plug-in?
Title: Re: qpdfview
Post by: Doug Bissett on March 04, 2015, 05:32:52 am
Try PMDLL. It will probably tell you which DLL you need. I had to put the QPDFView directory into LibPath. Just using BeginLibPath didn't cut it, for some reason.

FWIW, I updated to qpdfview-0_4_14-GA this afternoon. I needed to do some updates from the RPM ZIP files (as described). I got QPDFView to work, but AOO4.1.1 was crashing hard, when i tried to start it. It would either initiate a system dump, hang hard (no mouse movement), or just spontaneously reboot. After messing around with that for a while, I restored my boot drive, AOO, and QPDFView. Now the older versions are working. Something, somewhere, is really broken, and I don't have the time to try to sort it out.

I have decided that YUM means "DLL HELL". It may make life a little easier for those who port *NIX programs, but it is starting to make life very difficult for users.
Title: Re: qpdfview
Post by: Neil Waldhauer on March 04, 2015, 03:40:12 pm
Well, I'd hope to know which dll files, or yum commands. Because the install.os2 isn't clear on that. get some zip files from the ftp site, but what are the names of the zip files? Once you have the correct zip files, which files from the zip files are needed?

That's the information that is incomplete in install.os2. And for developers of the package; they already had the files, so they didn't experience the need to describe them fully.

I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?
Title: Re: qpdfview
Post by: Silvan Scherrer on March 04, 2015, 04:08:17 pm
Well, I'd hope to know which dll files, or yum commands. Because the install.os2 isn't clear on that. get some zip files from the ftp site, but what are the names of the zip files? Once you have the correct zip files, which files from the zip files are needed?

That's the information that is incomplete in install.os2. And for developers of the package; they already had the files, so they didn't experience the need to describe them fully.

I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?
what yum commands are not clear? Imho the install.os2 is written with the enduser in mind.

regards
Silvan
Title: Re: qpdfview
Post by: Doug Bissett on March 04, 2015, 06:04:35 pm
Quote
I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?

I agree, that you should not need to use PMDLL, but it seems to be necessary, far too often. I just start with the EXE file, and see where that takes me.

Quote
what yum commands are not clear?

Well, ALL of them if you want the correct answer. When YUM actually works, it seems to do some magic, that makes no sense to the average user. When it fails (which happens far too often), it can leave a user hung up, with little choice but to restore their system from a backup, since trouble shooting what YUM does, or doesn't do, is almost impossible for a user, that is really the only recourse that a user has.

Quote
Imho the install.os2 is written with the enduser in mind.

No it isn't (although it is better than many). It is written with the programmer in mind. If it was written for the end user, it would have a lot more detail, like proper links to the exact files, and instructions, including commands, on how to extract the proper files, and where to put them. If a guy like Neil (who is an experienced OS/2 programmer) has trouble with it, so will every average user. And don't tell me that I must use YUM. That is a non starter. I would rather spend some time sorting out ZIP files, than trying to sort out a YUM screwup (which I have been doing far too much of lately, while testing the Arca Noae Package Manager, which works great, until YUM screws up - usually indicating that there was no problem. Then the user is up the creek, without a paddle).
Title: Re: qpdfview
Post by: Doug Bissett on March 04, 2015, 06:47:41 pm
Quote
could not load plug-in for type 'PDF'

Okay, after restoring my boot drive (to get the DLLs back where they were), QPDFView, and AOO4.1.1, last night, I tried again. This time, I did not just follow the directions. I simply updated QPDFView, then tried it. It opened, and closed. Okay, POPUPLOG.OS2 mentions POPPLER, so I updated POPPLER. Now, QPDFView opens, but complains that it can't find the PDF plugin. Odd, it is in the directory with the program, and I do have the dot entry in LibPath. PMDLL shows that QPDFPDF.DLL loads properly, but QPDFView still can't find it. On a hunch, I copied the QPDFView directory to my boot drive (the DLLs are in \eCS\DLL). Now, QPDFView opens, and it can find the plugin (the plugin is still in the QPDFView directory).  This is, of course, unacceptable.

The KLIBC Pathrewriter may be a fix, if I can figure out exactly what it needs. Another possible fix, is to simply give up, and move all of the system DLLs to the drive where I install software. That, in turn, really complicates life because it means that I need to figure out how to handle having two boot systems, sharing that stuff, and it screws up almost every installer. I suppose that I could just keep the *NIX junk on the programs drive, and keep the OS/2 DLLs on the boot drive. It may also be a good idea to use the *NIX directory structure, so that programmers don't have to think about what they are, or are not, doing.
Title: Re: qpdfview
Post by: Doug Bissett on March 04, 2015, 09:58:18 pm
Okay the QPDFView install instructions point you to http://rpm.netlabs.org/release/00/zip (http://rpm.netlabs.org/release/00/zip). There, you find three versions of PTHREAD, the newest is pthread-20140814-16_oc00.zip. This is the one that is causing the hard crash with AOO4.1.1. Version pthread-20140425-15_oc00.zip does not cause the problem, and it works with QPDFView. This problem also happens when you use YUM to update PTHREAD. If you downgrade to the older version, you can fix the crash problem. Then, of course, you need to remember that you did that, and you need to try again when/if the package gets updated (which doesn't mean that it will fix the problem).

I tried moving the DLLs to the programs drive. QPDFView still can't find the PDF plugin. It seems that qpdfview-0_4_14-GA must be installed on the boot drive, or it can't find the PDF plugin (and probably the other plugins as well). Programs, like QPDFView do not belong on a boot drive.
Title: Re: qpdfview
Post by: Neil Waldhauer on March 04, 2015, 10:16:54 pm
Well, I'd hope to know which dll files, or yum commands. Because the install.os2 isn't clear on that. get some zip files from the ftp site, but what are the names of the zip files? Once you have the correct zip files, which files from the zip files are needed?

That's the information that is incomplete in install.os2. And for developers of the package; they already had the files, so they didn't experience the need to describe them fully.

I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?
what yum commands are not clear? Imho the install.os2 is written with the enduser in mind.

regards
Silvan

In install.os2, I can either use yum or not. I prefer to use yum. Where there are yum commands, they are clear. But then

djvulibre
---------

  not available as a rpm at this time of writing

cups
----

  not available as a rpm at this time of writing

ghostscript
-----------

  not available as a rpm at this time of writing


I'm not completely clear what is going on here. Come to think of it, how does qpdfview find ghostscript?

Well, so far I can't get it to work. I have 4.1.13 working, so all is not lost.

Thanks to Doug for all the ideas, but so far, none are working.

Title: Re: qpdfview
Post by: ivan on March 04, 2015, 10:49:52 pm
You would think that the qpdfview zip file would include all the required DLLs because they all appear to be dependant on each other and you have install them all for anything to work.

Since they are all required DLLs is it too difficult to adjust qpdfview.exe such that it looks in its install directory first to find what it wants in the way of support files?

Since most uses of qpdfview is to read pdf files (at least here it is) why not allow users to select what other features they want to use and give a page in the settings that allows the user to give the whereabouts of such things as ghostscript, cups and freetype/fontconfig?

Because of problems with the last few builds of qpdfview we have now standardised on the last lucide build, for both us and our clients, for reading pdf files and ghostscript for printing where necessary.
Title: Re: qpdfview
Post by: TeLLie on March 04, 2015, 10:55:15 pm
Hihi
As  readme says for zip install:


djvulibre
---------

  1. Download djvulibre from ftp://ftp.netlabs.org/pub/unixos2/djvulibre-3_5_25.zip
  2. Unpack and install djvu.dll to your libpath eg. x:\ecs\dll

cups
----

  1. Go to eCUPS wiki to see how to install eCUPS (http://svn.netlabs.org/ecups)
  2. Install eCUPS according to the above wiki

ghostscript
-----------

  1. Download ghostscript as zip from ftp://ftp.netlabs.org/pub/unixos2/gs910os2.zip
  2. Unpack and install the gsdll2.dll to your libpath eg. x:\ecs\dll
     (note this ghostscript should be compatible with P. Smedley's 9.10 port, but his ports lack
     some features needed for qpdfview)
Title: Re: qpdfview
Post by: Silvan Scherrer on March 05, 2015, 06:35:06 am
Well, I'd hope to know which dll files, or yum commands. Because the install.os2 isn't clear on that. get some zip files from the ftp site, but what are the names of the zip files? Once you have the correct zip files, which files from the zip files are needed?

That's the information that is incomplete in install.os2. And for developers of the package; they already had the files, so they didn't experience the need to describe them fully.

I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?
what yum commands are not clear? Imho the install.os2 is written with the enduser in mind.

regards
Silvan

In install.os2, I can either use yum or not. I prefer to use yum. Where there are yum commands, they are clear. But then

djvulibre
---------

  not available as a rpm at this time of writing

cups
----

  not available as a rpm at this time of writing

ghostscript
-----------

  not available as a rpm at this time of writing


I'm not completely clear what is going on here. Come to think of it, how does qpdfview find ghostscript?

Well, so far I can't get it to work. I have 4.1.13 working, so all is not lost.

Thanks to Doug for all the ideas, but so far, none are working.

I will rephrase this part, that it gets more clear.
regards
Silvan
Title: Re: qpdfview
Post by: Silvan Scherrer on March 05, 2015, 06:37:06 am
Quote
I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?

I agree, that you should not need to use PMDLL, but it seems to be necessary, far too often. I just start with the EXE file, and see where that takes me.

Quote
what yum commands are not clear?

Well, ALL of them if you want the correct answer. When YUM actually works, it seems to do some magic, that makes no sense to the average user. When it fails (which happens far too often), it can leave a user hung up, with little choice but to restore their system from a backup, since trouble shooting what YUM does, or doesn't do, is almost impossible for a user, that is really the only recourse that a user has.

Quote
Imho the install.os2 is written with the enduser in mind.

No it isn't (although it is better than many). It is written with the programmer in mind. If it was written for the end user, it would have a lot more detail, like proper links to the exact files, and instructions, including commands, on how to extract the proper files, and where to put them. If a guy like Neil (who is an experienced OS/2 programmer) has trouble with it, so will every average user. And don't tell me that I must use YUM. That is a non starter. I would rather spend some time sorting out ZIP files, than trying to sort out a YUM screwup (which I have been doing far too much of lately, while testing the Arca Noae Package Manager, which works great, until YUM screws up - usually indicating that there was no problem. Then the user is up the creek, without a paddle).
So if you think you can do it better, why don't you contribute?
Everyone is free to send readme/install text proposals.

regards
Silvan
Title: Re: qpdfview
Post by: Doug Bissett on March 05, 2015, 07:27:09 am
Quote
You would think that the qpdfview zip file would include all the required DLLs because they all appear to be dependent on each other and you have install them all for anything to work.

Yeah, but that introduces duplicate DLLs, which WILL cause a problem later, or, it introduces the possibility of breaking something else (note that updating the PTHREAD package to the latest version, breaks AOO4.1.1, and that package appears to have been around since August), or both. Who knows what has been broken, and not yet noticed, by simply updating DLLs, whether you use YUM, or not. Those who have used the AOO-4111-GA-rpm.wpi package to make AOO4.1.1 work, will eventually have DLL problems (if they don't already), simply because that package installs common DLLs, used by many programs, in the program directory, leaving what could be down level DLLs in the default DLL directory. Eventually one, or the other, will become down level, and something else won't work because of that. It could be very difficult to sort it out, because it will depend on which DLL gets loaded first, whether something will run, or fail.

The whole thing is totally out of control.

Quote
Because of problems with the last few builds of qpdfview we have now standardised on the last lucide build

Personally, I thought that the first QPDFView build was far better than the last Lucide build. It is obvious that whoever is doing QPDFView needs a lot more help with beta testing, to avoid these silly problems. Meanwhile, rather than using Lucide, I would be more inclined to stay with older versions of QPDFView (assuming that some other thing doesn't break them, which is entirely too possible).

Quote
So if you think you can do it better, why don't you contribute?

Nobody can do it better. RPM/YUM is a total disaster, and there aren't enough people using OS/2 to test each package properly to be sure that they work. I am working with the Arca Noae Package Manager (currently called Yumie). It would work well, if YUM would do things the way it was advertized to do. One of the main problems is that YUM screws up, then tells Yumie that all is well. At other times, YUM tries to update itself, and turns into a vegetable until somebody figures out what went wrong, and figures out how to fix the problem. More often, something goes wrong, and nobody knows why. Trying again about 2 days later, and it works, as if nothing happened. Now updating PTHREAD kills AOO4.1.1. It is depressing.

Personally, I do some WarpIn packages, but I will make no attempt to try to keep up with what is going on in your world, because it appears that you don't even know what is going on.
Title: Re: qpdfview
Post by: Silvan Scherrer on March 05, 2015, 08:17:59 am
Quote
You would think that the qpdfview zip file would include all the required DLLs because they all appear to be dependent on each other and you have install them all for anything to work.

Yeah, but that introduces duplicate DLLs, which WILL cause a problem later, or, it introduces the possibility of breaking something else (note that updating the PTHREAD package to the latest version, breaks AOO4.1.1, and that package appears to have been around since August), or both. Who knows what has been broken, and not yet noticed, by simply updating DLLs, whether you use YUM, or not. Those who have used the AOO-4111-GA-rpm.wpi package to make AOO4.1.1 work, will eventually have DLL problems (if they don't already), simply because that package installs common DLLs, used by many programs, in the program directory, leaving what could be down level DLLs in the default DLL directory. Eventually one, or the other, will become down level, and something else won't work because of that. It could be very difficult to sort it out, because it will depend on which DLL gets loaded first, whether something will run, or fail.

The whole thing is totally out of control.

Quote
Because of problems with the last few builds of qpdfview we have now standardised on the last lucide build

Personally, I thought that the first QPDFView build was far better than the last Lucide build. It is obvious that whoever is doing QPDFView needs a lot more help with beta testing, to avoid these silly problems. Meanwhile, rather than using Lucide, I would be more inclined to stay with older versions of QPDFView (assuming that some other thing doesn't break them, which is entirely too possible).

Quote
So if you think you can do it better, why don't you contribute?

Nobody can do it better. RPM/YUM is a total disaster, and there aren't enough people using OS/2 to test each package properly to be sure that they work. I am working with the Arca Noae Package Manager (currently called Yumie). It would work well, if YUM would do things the way it was advertized to do. One of the main problems is that YUM screws up, then tells Yumie that all is well. At other times, YUM tries to update itself, and turns into a vegetable until somebody figures out what went wrong, and figures out how to fix the problem. More often, something goes wrong, and nobody knows why. Trying again about 2 days later, and it works, as if nothing happened. Now updating PTHREAD kills AOO4.1.1. It is depressing.

Personally, I do some WarpIn packages, but I will make no attempt to try to keep up with what is going on in your world, because it appears that you don't even know what is going on.
Thanks for the nice "because it appears that you don't even know whats going on." You can be sure I KNOW WHATS GOING ON!!!!

When I read such comments I really wonder why I invest sooooooooooooo much time in porting any software for free. But so it goes.
And I didn't even say you should contribute in yum or whatever. I only mentioned the readme/install text files.

So instead of writing IMHO usless stuff about how you dislike yum, send me a changed install.os2. I personally like yum and it works like a charm here. And of course you are free to dislike yum, we don't urge anyone to use it.

regards
Silvan
Title: Re: qpdfview
Post by: guzzi on March 05, 2015, 05:30:21 pm
Quote
You would think that the qpdfview zip file would include all the required DLLs because they all appear to be dependent on each other and you have install them all for anything to work.

Yeah, but that introduces duplicate DLLs, which WILL cause a problem later, or, it introduces the possibility of breaking something else (note that updating the PTHREAD package to the latest version, breaks AOO4.1.1, and that package appears to have been around since August), or both. Who knows what has been broken, and not yet noticed, by simply updating DLLs, whether you use YUM, or not. Those who have used the AOO-4111-GA-rpm.wpi package to make AOO4.1.1 work, will eventually have DLL problems (if they don't already), simply because that package installs common DLLs, used by many programs, in the program directory, leaving what could be down level DLLs in the default DLL directory. Eventually one, or the other, will become down level, and something else won't work because of that. It could be very difficult to sort it out, because it will depend on which DLL gets loaded first, whether something will run, or fail.

The whole thing is totally out of control.

Quote
Because of problems with the last few builds of qpdfview we have now standardised on the last lucide build

Personally, I thought that the first QPDFView build was far better than the last Lucide build. It is obvious that whoever is doing QPDFView needs a lot more help with beta testing, to avoid these silly problems. Meanwhile, rather than using Lucide, I would be more inclined to stay with older versions of QPDFView (assuming that some other thing doesn't break them, which is entirely too possible).

Quote
So if you think you can do it better, why don't you contribute?

Nobody can do it better. RPM/YUM is a total disaster, and there aren't enough people using OS/2 to test each package properly to be sure that they work. I am working with the Arca Noae Package Manager (currently called Yumie). It would work well, if YUM would do things the way it was advertized to do. One of the main problems is that YUM screws up, then tells Yumie that all is well. At other times, YUM tries to update itself, and turns into a vegetable until somebody figures out what went wrong, and figures out how to fix the problem. More often, something goes wrong, and nobody knows why. Trying again about 2 days later, and it works, as if nothing happened. Now updating PTHREAD kills AOO4.1.1. It is depressing.

Personally, I do some WarpIn packages, but I will make no attempt to try to keep up with what is going on in your world, because it appears that you don't even know what is going on.

PTHREAD doesn't break AOO 4.1.1.1 here.
Installed Packages
pthread.i386                        20140814-16.oc00

QPDF works like a charm too. The last 2 versions work better than the previous ones because they don't need the 3 qpdf dll's in the path anymore for qpdfview to work in any way I choose to open it  (command line, FC/2 association, wps, firefox).

I agree that YUM isn't always very clear when something goes wrong. Then again, it doesn't go wrong all that often, and when it does it can be user error too. In general, it works well and prevents this dll hell you mentioned.

I don't want to start a flame war, but I do have to say I disagree with the way you regularly imho insult developers, this time by saying they don' know what going on. What is actually going on is that they provide us all with the software needed to keep eCS running, they fix bugs, run bug trackers and actively monitor them. Instead of flaming them a "thank you" would be more appropriate.
Title: Re: qpdfview
Post by: Michaelhz on March 05, 2015, 09:34:09 pm

Thanks for the nice "because it appears that you don't even know whats going on." You can be sure I KNOW WHATS GOING ON!!!!

When I read such comments I really wonder why I invest sooooooooooooo much time in porting any software for free. But so it goes.
And I didn't even say you should contribute in yum or whatever. I only mentioned the readme/install text files.

So instead of writing IMHO usless stuff about how you dislike yum, send me a changed install.os2. I personally like yum and it works like a charm here. And of course you are free to dislike yum, we don't urge anyone to use it.

regards
Silvan

Dear Silvan,

I think it's now time to say a big thank you to you (and all the others involved in this development)  for all your efforts.  :)
A system like rpm/yum for keeping all the depended software up to date is highly appreciated. I have always looked enviously at the Linux users. Now it is very easy to keep all my OS/2 systems (Currently 4)  up to date. Its easy just to tell the system "yum update".
Additionally it was never so easy to get an aligned build system with gcc and all the important libraries.

Looking forward to have all the remaining libs (and progs?) included into the yum-system. 

Best regards
Michael
Title: Re: qpdfview
Post by: Doug Bissett on March 06, 2015, 12:03:44 am
Quote
Thanks for the nice "because it appears that you don't even know whats going on." You can be sure I KNOW WHATS GOING ON!!!!

I hate to have to say this, but if you do actually know what is going on, you should be ashamed to admit it. I have to believe that you honestly do think you know what is going on, but I will suggest that somebody had better take a MUCH closer look at the quality of the products that are being distributed by YUM (including YUM itself). If I had performed like that, when I was working, I would have been fired.

Quote
When I read such comments I really wonder why I invest sooooooooooooo much time in porting any software for free.

I know why you do it (and my comments are not directed at you personally). What I don't understand is why you don't take a bit more time, and port things so they work like an OS/2 user expects them to work, rather than half way between *NIX and OS/2. You could leave out some of the more useless programs to free up some time. Personally, I use Firefox because that is really the only viable alternative. I use AOO4, because Lotus SmartSuite has developed far too many problems, and I suspect that a lot of them are caused by updates to make Firefox work. Now, if I try to run Firefox, and AOO4 together, one, or the other, always crashes, often messing the system up so badly, that I need to reboot. And, I use QPDFView, simply because it is better than Lucide, which seems to be the only other option (I suppose there is always GhostView, but it is also a terrible kludge). I would use CLAMAV, if CLAMD.EXE would not eat up all of my shared memory space, and using CLAMSCAN, without CLAMD.EXE takes "forever". CUPS is another, very important program, but it is also becoming such a kludge that it is very difficult to get it to work. SAMBA seems to be necessary to communicate  with anything other than OS/2, and it is finally starting to work reasonably well. RSYNC is one of the few ports that actually works well enough to depend on it. I can't think of anything else that I use.

Quote
PTHREAD doesn't break AOO 4.1.1.1 here.
Installed Packages
pthread.i386                        20140814-16.oc00

It breaks every system that I try it on, whether I install it using YUM, or manually. AOO4.1.1 either hangs, spontaneously reboots, or hard (black screen) crashes when I try to start any part of it.

Quote
QPDF works like a charm too. The last 2 versions work better than the previous ones because they don't need the 3 qpdf dll's in the path anymore for qpdfview to work in any way I choose to open it  (command line, FC/2 association, wps, firefox).

The ONLY way that I can get the latest QPDFView to work, is to install it on the boot drive. If it is not on the boot drive, it can't find the plugins. I have no idea why that is the case, but it is not acceptable. I have temporarily installed it on the boot drive, to see if it is worth putting up with that major inconvenience, but it looks like I am going to go back to the older version, which does work.

Quote
Now it is very easy to keep all my OS/2 systems (Currently 4)  up to date. Its easy just to tell the system "yum update".

Are they up to date? It took more than 4 months for LIBC066 to show up in YUM, after it was available as a WarpIn archive on HOBBES. Now, it appears that the PTHREAD package, that just recently showed up on YUM, was built last August. It also seems that GhostScript 9.10 is current on YUM, and apparently it contains something that GhostScript 9.15, from Paul Smedley, doesn't have. So what is "current"? Then, GCC1, and associated parts, suddenly showed up, and got installed, without being announced (at least I never heard about it before it was installed on my system). I haven't confirmed it, yet, but I am suspicious that GCC1 is responsible for the odd 5 second freeze, once or twice per day, that is happening on all of the systems where I have it installed (but it could be something else, and it could be more often). FWIW, you never know what is going to happen when you say "YUM UPDATE", and trying to figure out what it actually did is not as easy as it sounds. BTW, even Linux is moving away from YUM because it just doesn't work very well. The main difference is, that they have lots of people working on it.

The main Porting problem seems to be that Quality Control is minimal, product testing is minimal, problems are slipping through, and that is impacting the users. The main cause seems to be trying to do too much, with too few people. The other main problem, is that too few users are stepping forward to help out (and, they are often rejected, or ignored, by the programmers when they do step forward). The other main problem is that most programmers are so busy trying to port things, that they have forgotten how to write native OS/2 programs, or drivers. In times past, OS/2 was the source of many great programs (PMView is about the only one that is left). Now, OS/2 is limping along on other peoples work, patched together to make it run, and it shows. Of course, the same is true of the whole OS.

I don't know what the answer is. WIndows 7 seems to work pretty well, after you find a lot of the "helpful" things to turn them off.

I have been playing with Linux Mint 17.1 Cinnamon 64. That seems to work okay, after I found out how to turn off about 80% of the requests for a password (absolutely insane to ask for a password 3 times in 20 seconds). Then there is a steep learning curve that I really don't need (permissions, new commands, security, etc.). On the other hand, Linux seems to be following the lead of Windows, and it is becoming a bloated mess. Now, that is being reflected in the programs that get ported to OS/2.

I have no direct experience with Apple, but I have heard horror stories about trying to get something as basic as networking to go. Of course, windows is just as bad, or worse.

Now, I have an Android phone, that is probably capable of doing about 90% of what I use a computer for. Unfortunately, it is annoying to use, mainly because there is no real keyboard, and the screen is too small, not to mention the learning curve, and the fact that is is tied to Google (for better, or worse).

Where to next? Well, we are on a road. Nobody seems to be sure where it is going, but we are following it.
Title: Re: qpdfview
Post by: mickhead on March 06, 2015, 01:31:54 am
I think it's now time to say a big thank you to you (and all the others involved in this development)  for all your efforts.  :)
I thank also the developer of the small OS/2 community. We say keep up efforts all around.
Title: Re: qpdfview
Post by: guzzi on March 06, 2015, 02:28:25 am
Quote
Thanks for the nice "because it appears that you don't even know whats going on." You can be sure I KNOW WHATS GOING ON!!!!


I know why you do it (and my comments are not directed at you personally). What I don't understand is why you don't take a bit more time, and port things so they work like an OS/2 user expects them to work, rather than half way between *NIX and OS/2. You could leave out some of the more useless programs to free up some time. Personally, I use Firefox because that is really the only viable alternative. I use AOO4, because Lotus SmartSuite has developed far too many problems, and I suspect that a lot of them are caused by updates to make Firefox work. Now, if I try to run Firefox, and AOO4 together, one, or the other, always crashes, often messing the system up so badly, that I need to reboot. And, I use QPDFView, simply because it is better than Lucide, which seems to be the only other option (I suppose there is always GhostView, but it is also a terrible kludge). I would use CLAMAV, if CLAMD.EXE would not eat up all of my shared memory space, and using CLAMSCAN, without CLAMD.EXE takes "forever". CUPS is another, very important program, but it is also becoming such a kludge that it is very difficult to get it to work. SAMBA seems to be necessary to communicate  with anything other than OS/2, and it is finally starting to work reasonably well. RSYNC is one of the few ports that actually works well enough to depend on it. I can't think of anything else that I use.

Quote
PTHREAD doesn't break AOO 4.1.1.1 here.
Installed Packages
pthread.i386                        20140814-16.oc00

It breaks every system that I try it on, whether I install it using YUM, or manually. AOO4.1.1 either hangs, spontaneously reboots, or hard (black screen) crashes when I try to start any part of it.

Quote
QPDF works like a charm too. The last 2 versions work better than the previous ones because they don't need the 3 qpdf dll's in the path anymore for qpdfview to work in any way I choose to open it  (command line, FC/2 association, wps, firefox).

The ONLY way that I can get the latest QPDFView to work, is to install it on the boot drive. If it is not on the boot drive, it can't find the plugins. I have no idea why that is the case, but it is not acceptable. I have temporarily installed it on the boot drive, to see if it is worth putting up with that major inconvenience, but it looks like I am going to go back to the older version, which does work.

It's interesting to note that quite a lot of programs don't work on your computers. These same programs work on mine. AOO and Firefox run concurrently without problems, QPDFView runs not from the boot drive, I keep on eye on the various bug trackers and i haven't seen similar issues as you seem to be having. It could be that you have some basic thing wrong in the way you set up your system.


Quote
Now it is very easy to keep all my OS/2 systems (Currently 4)  up to date. Its easy just to tell the system "yum update".



Are they up to date? It took more than 4 months for LIBC066 to show up in YUM, after it was available as a WarpIn archive on HOBBES.

True. Then again, there were very few programs released that actually needed it in that timeframe. The real lag was more like 4 weeks.

Now, I have an Android phone, that is probably capable of doing about 90% of what I use a computer for. Unfortunately, it is annoying to use, mainly because there is no real keyboard, and the screen is too small, not to mention the learning curve, and the fact that is is tied to Google (for better, or worse).

I don't have an Android phone, nor an Apple one. Still use Symbian and like OS/2 the benefits still outweigh the disadvantages.

As for Linux stepping away from Yum, do you mean DNF? afak only Fedora is moving over. DNF btw is a fork of yum that solves quite a few problems yum seems to have and, like any new software, introduces a fair number of new ones.
Title: Re: qpdfview
Post by: Neil Waldhauer on March 06, 2015, 06:23:34 am
Is there some way to get more information about the error "could not load plug-in for type 'PDF'"?
Title: Re: qpdfview
Post by: Dave Yeo on March 06, 2015, 06:59:30 am
Perhaps open a ticket, I'd guess at QT netlabs.
Title: Re: qpdfview
Post by: Doug Bissett on March 06, 2015, 07:54:10 am
Quote
It's interesting to note that quite a lot of programs don't work on your computers. These same programs work on mine. AOO and Firefox run concurrently without problems, QPDFView runs not from the boot drive, I keep on eye on the various bug trackers and i haven't seen similar issues as you seem to be having. It could be that you have some basic thing wrong in the way you set up your system.

I have been setting up my systems pretty much the same way, for many years (long before eCS existed). I do have a number of background programs running (about 20), which tends to use up shared memory, and I have had to quit using a few of them because of that (CLAMD.EXE was the worst offender). Now, there are unexplained issues with some programs (QPDFView) being unable to locate DLLs, which should be easily found. I think there is a general lack of resource checking, when programs request memory, and they don't handle running out very well. I expect that that is because *NIX programs rarely have a problem like that, so they don't bother checking. It is also possible that whoever ported the program missed something that needs to be changed.

I will note, that I have a number of very different systems (including virtual machines), all set up very much the same, and they all have the same problems, so it isn't hardware. Most of them don't have as many background programs running, so that is not likely the cause. There is nothing unusual about my basic setup. It is pretty much the way that OS/2, or eCS, installs it (except where YUM is installed). I do clean up my INI files regularly (two weeks), but I notice that some problems get worse just before I do the cleanup.I will also note, that my system started running a little better after I installed LIBC066 (using WarpIn), but recently, it has been going down hill again.

I am open to any suggestions.
Title: Re: qpdfview
Post by: Paul Smedley on March 06, 2015, 08:36:00 am
Hey Neil,

Is there some way to get more information about the error "could not load plug-in for type 'PDF'"?

I would use pmdll or something similar to ensure all dependent DLL's are present and can be loaded. I'll wager you have a DLL missing somewhere..
Title: Re: qpdfview
Post by: Pete2 on March 06, 2015, 03:55:13 pm
Hey Neil,

Is there some way to get more information about the error "could not load plug-in for type 'PDF'"?

I would use pmdll or something similar to ensure all dependent DLL's are present and can be loaded. I'll wager you have a DLL missing somewhere..
I also get this error, but pmdll shows no missing dlls.

 Install.os2 includes the following:

"If you have tried to open a file and not all requirements have been there at this try, Qt screwed his plugin cache.
To overcome that delete %HOME%/.config/Trolltech.ini. It will be created again when a Qt app starts."

I've tried this and still get the error. Does anyone have any suggestions?
Title: Re: qpdfview
Post by: Batchheizer on March 06, 2015, 04:48:00 pm
I also get this error, but pmdll shows no missing dlls.

 Install.os2 includes the following:

"If you have tried to open a file and not all requirements have been there at this try, Qt screwed his plugin cache.
To overcome that delete %HOME%/.config/Trolltech.ini. It will be created again when a Qt app starts."

I've tried this and still get the error. Does anyone have any suggestions?
Try to delete all poppler-files in ecs/dll and install only the newest ones.
Title: Re: qpdfview
Post by: vrwp on March 06, 2015, 06:05:44 pm
Is there some way to get more information about the error "could not load plug-in for type 'PDF'"?
Had the same problem. Do you have by any chance installed epdf? In the epdf i had a tiff.dll which lead to the problem, renamed that dll an now all is working fine (tiff.dll is installed by yum)
Title: Re: qpdfview
Post by: Andi B. on March 06, 2015, 07:22:14 pm
qpdfview0.4.14 works fine here as the older versions did.

I do not have it on the boot drive and it works. But I do not have %UNIXROOT% pointing to the boot drive too. Maybe that's different to Dougs setup.

Printing works via cups. Although I would prefer if it would work via native pscript.drv it's not a big problem.

It seems qpdfpdf.dll must be in qpdfview directory (included in qpdfview-0_4_14-ga.zip anyway). That one in %UNIXROOT%\usr\lib\ is not found.

While I write this in Seamonkey qpdfview displays a 2.6MB pdf. Chatzilla and SMs email/news client is open as always. One AOO spreadsheet and one AOO text document is open. VBOX is running a XP guest at the same time. OpenFire (Java) runs in the background. PSI, ZOC, two LarsenCommander instances and a few other apps run too. Astonishing that this all is even possible with that old base OS.
Title: Re: qpdfview
Post by: Paul Smedley on March 07, 2015, 12:16:41 am
 
Quote
Thanks for the nice "because it appears that you don't even know whats going on." You can be sure I KNOW WHATS GOING ON!!!!

I hate to have to say this, but if you do actually know what is going on, you should be ashamed to admit it. I have to believe that you honestly do think you know what is going on, but I will suggest that somebody had better take a MUCH closer look at the quality of the products that are being distributed by YUM (including YUM itself). If I had performed like that, when I was working, I would have been fired.

You hate to say it, but you say it anyway? Note that Silvan isn't getting paid by anyone for doing what he's doing for yum - neither are the other guys working on it, so how can they be fired. You have a choice, if you don't like what's on offer, don't use it. There is no need to denigrate the people who are doing stuff to try and help OS/2.

OS/2 users often don't provide feedback on software, which makes it hard for developers to fix issues, or if they do provide feedback, it's along the lines of 'it doesn't work' which makes problem solving difficult. If you want to be critical about the 'quality' of ports, direct your criticism at the community - many of whom don't care enough to report issues in an appropriate manner.

The few remaining developers don't have huge resources available to extensively test things - would it be better if they simply didn't release updates?

Note that I personally aren't a huge fan of rpm - I love the concept - but feel it does contribute to DLL hell given the limitations of OS/2 8.3 file system and the clashes with EMX or whatever DLL's that are already existing on user's systems, however that doesn't mean I go around making snarky remarks about the developers working on it.
Title: Re: qpdfview
Post by: Neil Waldhauer on March 08, 2015, 03:02:21 am
Hey Neil,

Is there some way to get more information about the error "could not load plug-in for type 'PDF'"?

I would use pmdll or something similar to ensure all dependent DLL's are present and can be loaded. I'll wager you have a DLL missing somewhere..

OK, with PMDLL, running against qpdfpdf.dll, I see png16.dll is missing. I'm not sure what package gives that. I did rerun all the yum commands, but it didn't actually find png16.dll

Running PMDLL against qpdfview.exe, I see cups.dll won't load. But cups.dll is on the libpath. Running PMDLL against cups.dll shows no problems.

Any idea what to do?
Title: Re: qpdfview
Post by: Dave Yeo on March 08, 2015, 05:20:17 am
I have libpng-devel installed for png, there's also libpng-tools which might work (they conflict here). Png depends on libz.
There's been a few different releases of cups.dll, which you need...
Title: Re: qpdfview
Post by: Doug Bissett on March 08, 2015, 06:34:28 am
Quote
You have a choice, if you don't like what's on offer, don't use it.

I don't use YUM, except to test the new Arca Noae Package Manager (AKA Yumie). Yumie works great, when YUM doesn't screw up, which happens far too often. The results of that project have pretty well convinced me that YUM is definitely not the answer to the problem, and somebody has got to tell the developers that. It makes them look bad, and it makes using OS/2 impossible, for many new OS/2 users.

Quote
There is no need to denigrate the people who are doing stuff to try and help OS/2.

The problem is, that they are not exactly helping anybody, when their software doesn't work properly. YUM is well known be a major problem in the *NIX world, and many *NIX versions have moved on to something else. Denying that YUM is a problem is self defeating. It will not get any better, simply because the source code isn't good. Lets bite the bullet now, and get on with life.

Now, it seems that I have a problem with PTHREAD, that I will admit I haven't got around to reporting (sorry, life got in the way).

I will point out that nobody ever mentioned that GCC1 was in progress, and I never heard of anybody suggesting that people should test it. That is exactly the same sort of thing that caused so many problem for eCS 2.2 b1. The assumption was made that it worked on a dozen machines, so it would work on all of them. WRONG!

Enough said about that. If they have any sense, they will move on, and do it right. If not, it is just one more nail in the coffin.

Quote
I see png16.dll is missing.

I find that file in my DLL collection. I am not sure where it came from, but it is likely in an older version of libpng. The latest one seems to call it png1616.dll, for some reason.
Title: Re: qpdfview
Post by: Dave Yeo on March 08, 2015, 07:33:31 am
At this point we have yum/rpm, it seems to be the tool that the developers are used to and they're going to keep using. It's not my ideal and I've spent a fair amount of time cursing yum/rpm as it is very fragile but I don't have the energy or knowledge to take over the job and as they seem to be working for close to free and we're on a dying platform it is really not constructive to rant.
All we can do is comment on how we feel or how we find the experience and let things flow how they will. Doesn't hurt to do things to make the flow go better, testing and reporting and making whatever contributions that we can, even if it is only making the install instructions clearer.
Title: Re: qpdfview
Post by: Andi B. on March 08, 2015, 11:22:31 am
I don't use YUM,
That might be part of your problem.

Quote
The problem is, that they are not exactly helping anybody, when their software doesn't work properly.

It was proved numerous times that it's nearly impossible to help people how have spread different dlls coming from unknown sources all over their system. Especially when they ignore the fact that they have driven themselves into an inscrutable dll hell and neglect to clean it up.

Currently the only way to keep dlls which are needed for ported software in a current consistent state is yum/rpm. No one offers a better way for doing this so it makes absolutely no sense to constantly ranting about. Come up with a better solution and I'm willing to discuss the pro and cons.

What a user needs to do for cleaning up his mess would be searching all drives for duplicates of every dll in %unixroot%/usr/lib. Tools like DataSeeker, pmseek, SearchPlus can be used for this. But this is a time-consuming task of course.

Quote
I find that file in my DLL collection. I am not sure where it came from, but it is likely in an older version of libpng. The latest one seems to call it png1616.dll, for some reason.
I do not have a png16.dll in my libpath and qpdfview works. qpdfpdf.dll needs png1616.dll. Here's the dll loading tree -
Title: Re: qpdfview
Post by: Neil Waldhauer on March 08, 2015, 03:25:25 pm
I found that png16.dll was loaded by freetyp6.dll. I suppose it's useful to put timestamps or other versioning into dll files, but no one else is, so I won't, either. Anyway, a version of freetyp6.dll was in my libpath before the one in \usr\dll and it tried to load png16.dll, which wasn't present. Removing that version of freetyp6.dll allows the one in \usr\dll to load, and qpdfview works.

The tool I use to manage libpath is inadequate. I have which.exe from the EMX days. It doesn't show the DLLs well enough. Is there a newer version of which?

Usage: which <command>...
       which -d <dll>...

It's a simple, but good tool for finding things.
Title: Re: qpdfview
Post by: ivan on March 08, 2015, 03:42:11 pm
Hi Andi B,

Quote
Currently the only way to keep dlls which are needed for ported software in a current consistent state is yum/rpm. No one offers a better way for doing this so it makes absolutely no sense to constantly ranting about. Come up with a better solution and I'm willing to discuss the pro and cons.

In actual fact it isn't.  We have a policy that we have to adhere to for our clients, we can't use anything that is not approved and in the case of anything going onto the machine control computers certified.  This means that we can not use RPM/YUM as I doubt it would get approval and certainly not certification.

We get round this by having either program objects that are very specific in how they start and run a program or programs are started by command files, again with very specific parameters.

At the moment I am experimenting with using a directory directly off the root of the boot drive to hold all these extraneous DLLs that is listed in the libpath of config.sys.  This works and because I back it up before any additions are made it is very easy to go back to what was working if anything breaks (I have had to do this a couple of times).

Now back to Qpdfview.

Looking over the zip files of Qpdfview I find that v0.4.9 and v0.4.10 both have some of the required DLLs included while later versions do not.  Also reading the README from the latest source it appears there are a number of options that can be used when building, some of which would solve some of the problems we are seeing - for instance, not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?
 
Title: Re: qpdfview
Post by: Doug Bissett on March 08, 2015, 05:05:29 pm
Quote
Quote from: Doug Bissett on Today at 06:34:28 am

   
Quote
I don't use YUM,


That might be part of your problem.

No. I have the same problems on my systems that do use YUM, in fact, I could argue that I have worse problems on those systems. It appears that I am going to have to bite the bullet, and quit using one, or more, of my background programs, to free up more shared memory space. I am not sure what I am going to stop using, but something needs to be done about that problem, and using more DLLs is definitely not the answer.

Quote
The tool I use to manage libpath is inadequate. I have which.exe from the EMX days. It doesn't show the DLLs well enough. Is there a newer version of which?

Usage: which <command>...
       which -d <dll>...

It's a simple, but good tool for finding things.

One of the problems with 'which' is that you need to remember to run it from the working directory of whatever you are trying to diagnose. It needs to follow the dot entry in LibPath, which is usually very near the beginning.

Quote
At the moment I am experimenting with using a directory directly off the root of the boot drive to hold all these extraneous DLLs that is listed in the libpath of config.sys.  This works and because I back it up before any additions are made it is very easy to go back to what was working if anything breaks (I have had to do this a couple of times).

I think that I am going to start doing something like that, on one (test) system, then I will use RSYNC to keep all of my systems updated to what works on the test system (still no guarantee that updates won't cause problems, but...). I haven't tried that, yet, but I suspect that I will have to unlock all of the files to be able to update them, and a reboot may also be a good idea. If somebody has an available server, with RSYNC, everybody could update that way.

The biggest problem is to sort out which DLLs belong in a common system directory, and which ones belong in a program directory. Too many programs have been distributed with common system DLLs in their program directory, and that seems to be part of what is causing trouble. Those need to be removed, to avoid duplicates, and down level versions. Another problem is that some programs are distributed with down level files, which replace the later level files. That makes the "new" program work okay, but it can break something else. It also appears that none (or very few) of the ported DLLs have BLDLEVEL information in them, and that complicates the whole thing too.

Quote
not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?

It has been said, that all you need is CUPS.DLL, somewhere in your LibPath. I can't vouch for that because I do have CUPS installed. There is also the problem where later versions of CUPS supply one of CUPS.DLL, CUPS17.DLL, or CUPS20.DLL. QPDFView (and some other programs) don't know about the last two. Of course, if you do put CUPS.DLL somewhere in your LibPath, then install CUPS later, you are exposed to having a problem, if you forget about that.

Then, there is the major problem of installing RPM/YUM, after you have updated things in other ways. YUM puts the path to what it installs first, which works okay, but it leaves behind the old stuff. Now, depending on what gets started first, you may have a down level version being used, which will break things that need the later version. This results in "sometimes it works, and sometimes it doesn't". Those problems can become extremely difficult to fix.

I will note one other thing, that I suspect few OS/2 users know anything about. Some of these ports are using the *NIX concept of "SYMLINKS". From what I understand, that allows the program to go looking for another program, which may not actually exist, but the program name has a method to run a different program in it's place. (Confused yet?). So you never know what you are really using, and that makes trouble shooting extremely difficult, especially when you look in the file of the first program, and find a path to the second program, rather than code. (Now, you should be totally confused). Somehow, I don't see this as being a good thing.

I will also mention the tool that is part of X(e)Workplace, called 'OS/2 Kernel'. Part of this tool will list your PATH statements (LibPath, Path, DPath), and determine if there are invalid paths. It also lists duplicate files found in the paths. Of course, it has the same problem as 'which' (mentioned above), because it cannot properly follow the dot entry in LibPath. One needs to be very careful when trying to analyze these things, and understand which file will be found first, under various circumstances.
Title: Re: qpdfview
Post by: Andi B. on March 09, 2015, 09:33:04 am
Ivan -
Quote
for instance, not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?
I can only speculate on this -
- maybe the majority of users who read pdfs have sometimes the need to print part or whole pdf (like me)
- maybe the creator team of this program decided that they need to print sometimes and they decided the way to go is cups
- maybe the porter of this application does follow the above arguments or simply did not see any sense in cutting out code he ported from the qpdfview project (and increasing his own workload considerable) only to make one OS/2 user happy while distress a lot of others 

Of course you can ask on qpdfview user or developer list this topic. But for me such discussions are as useless as a hole in the head. And fear the developers of qpdfview will see it similar. They use some *nix system where cups is standard. If I should speculate again they will say that's the way it is, take it or leave it.

which is not the answer for cleaning up old dlls. 'which -lasu libc065.dll' can only find dlls in current directory and libpath. But not the ones which are loaded by some application in theirs directory regardless if you have . in libpath or not. Btw. that's the reason why I implemented in my which port a warning message about that fact. And that's why I wrote above -
Quote
What a user needs to do for cleaning up his mess would be searching all drives for duplicates of every dll in %unixroot%/usr/lib. Tools like DataSeeker, pmseek, SearchPlus can be used for this.
Problem is too many users copied some dlls into some directories all over their system and now reap what they sow. Ways to start cleaning of a system are
- run one of the above tools at least for all dlls and dependencies listed in the readme
- double check with which -lasu all these dlls (you can use pmdll to get the list of dlls but you have to repeat this step)
- check all your programs you start automatically or manually after reboot for dlls they use and where they are placed on your system

Another method would be reinstalling eCS WITHOUT manually changing libpath afterwards (I hate to suggest the Windoze way)
Title: Re: qpdfview
Post by: guzzi on March 09, 2015, 01:40:56 pm
Ivan -
Quote
for instance, not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?
I can only speculate on this -
- maybe the majority of users who read pdfs have sometimes the need to print part or whole pdf (like me)
- maybe the creator team of this program decided that they need to print sometimes and they decided the way to go is cups
- maybe the porter of this application does follow the above arguments or simply did not see any sense in cutting out code he ported from the qpdfview project (and increasing his own workload considerable) only to make one OS/2 user happy while distress a lot of others 

Of course you can ask on qpdfview user or developer list this topic. But for me such discussions are as useless as a hole in the head. And fear the developers of qpdfview will see it similar. They use some *nix system where cups is standard. If I should speculate again they will say that's the way it is, take it or leave it.

which is not the answer for cleaning up old dlls. 'which -lasu libc065.dll' can only find dlls in current directory and libpath. But not the ones which are loaded by some application in theirs directory regardless if you have . in libpath or not. Btw. that's the reason why I implemented in my which port a warning message about that fact. And that's why I wrote above -
Quote
What a user needs to do for cleaning up his mess would be searching all drives for duplicates of every dll in %unixroot%/usr/lib. Tools like DataSeeker, pmseek, SearchPlus can be used for this.

FC/2 works great for that too.

Problem is too many users copied some dlls into some directories all over their system and now reap what they sow. Ways to start cleaning of a system are
- run one of the above tools at least for all dlls and dependencies listed in the readme
- double check with which -lasu all these dlls (you can use pmdll to get the list of dlls but you have to repeat this step)
- check all your programs you start automatically or manually after reboot for dlls they use and where they are placed on your system

I'd start searching for libc first. Many programs came with a libc version that was installed in the program directory. Once these are cleaned up, many problems disappear-

Another method would be reinstalling eCS WITHOUT manually changing libpath afterwards (I hate to suggest the Windoze way)
Title: Re: qpdfview
Post by: Doug Bissett on March 11, 2015, 05:46:51 am
Quote
Now, it seems that I have a problem with PTHREAD, that I will admit I haven't got around to reporting (sorry, life got in the way).

Well, I THINK I found that one. I have CLAMAV installed, using the clamavgui package. That thing has it's own DLL library, which is down level, and never should have been there in the first place (it did contain an ols version of PTHREAD.DLL). It is not in LibPath, but it seems that if something used CLAMAV, before I tried to start AOO4, AOO4 would crash, hang, or simply reboot the system. The odd thing is, that the older version of PTHREAD didn't have the problem.

Using the OS/2 Kernel tool from X(e)Workplace, I see that there are many duplicate DLLs, and EXEs, all over the system (and that seems to only look in the paths, any others are ignored). That is made MUCH worse when a user installs RPM/YUM, because YUM keeps it's own copies of everything, but does nothing to be sure that there are no other copies anywhere.

I guess I have about two days of work, to sort that out.

QPDFView still can't find the plugin, unless it is on the boot drive.
Title: Re: qpdfview
Post by: Silvan Scherrer on March 11, 2015, 05:21:08 pm

QPDFView still can't find the plugin, unless it is on the boot drive.
Does this mean the complete qpdfview has to be on your bootdrive or only some dll?
Even I can't reproduce it here, I would be interested to iron this problem out.

Here bootdrive is c: and qpdfview is on e:\somedir and it works.
Did you try to delete %HOME%/.config/Trolltech.ini after moving the dll to another location?
Title: Re: qpdfview
Post by: Doug Bissett on March 11, 2015, 09:14:56 pm

QPDFView still can't find the plugin, unless it is on the boot drive.
Does this mean the complete qpdfview has to be on your bootdrive or only some dll?
Even I can't reproduce it here, I would be interested to iron this problem out.

Here bootdrive is c: and qpdfview is on e:\somedir and it works.
Did you try to delete %HOME%/.config/Trolltech.ini after moving the dll to another location?

I didn't move any DLLs, that I know about, except those in the QPDFVIEW directory, with the program. However, deleting %HOME%/.config/Trolltech.ini does fix the problem (I put the QPDFVIEW directory back where I want it).

This really doesn't make any sense, because the DLLs were never on the boot drive, until I moved the whole QPDFVIEW directory (including the DLLs) to the boot drive. Then, it worked, somehow (I would expect that it wouldn't, if there is something in %HOME%/.config/Trolltech.ini that needs to change when the DLLs are moved). Before I moved the directory, I had the previous version of QPDFView installed (and working), and all I did was replace the files in that same directory. Then, it couldn't find the plugin. I did put the older QPDFView back in that directory, and it worked, without messing with %HOME%/.config/Trolltech.ini.

Since there seems to be no problem with removing %HOME%/.config/Trolltech.ini, I am tempted to just delete it at every boot (perhaps every time I start QPDFView might be better). I remember having some sort of problem with that file before (probably with QPDFView), and the fix was to delete it.

Any comments?
Title: Re: qpdfview
Post by: Doug Bissett on March 11, 2015, 10:39:22 pm
Quote
Btw. that's the reason why I implemented in my which port a warning message about that fact.

I have two versions of which.exe. 2.1.5, from Michael Greene, and 2.20 from Mentore Siesto. 2.20 doesn't follow the dot, while 2.1.5 does (but only to the directory where it is started from). It looks like 2.20 came from HOBBES. I don't know where the other one came from.

So, which which do we want to use, and where does one find it?

Quote
Problem is too many users copied some dlls into some directories all over their system and now reap what they sow.

Well, that is PART of the problem. The rest appears to be caused by developers including things in their packages that are put into the wrong place. Even the recent AOO-4111-GA-rpm.wpi package puts a bunch of DLLs (some of the ones that are now causing problems) into the AOO4\program directory, when they should be in \eCS\DLL on eCS systems, or \OS2\DLL on other OS/2 systems. Of course, if you install that stuff using YUM, they go into @UNIXROOT/usr/lib (note the *NIX location, which is placed first in LibPath). YUM also fails to remove any of those things that may be in the "old" locations, aggravating the problem even more.

The bottom line is, that the only way to get it right, without doing a LOT of manual work, is to re-install eCS 2.2 b2 (or later, I would presume), selecting to include the RPM/YUM stuff (which is installed by default, and is well hidden so you can't find the setting to avoid it), then never use anything except YUM to do updates, unless YUM does not supply what you need. Then, if you do use an alternate install procedure (ZIP, WarpIn), and YUM eventually does get around to including it, you need to go back and get rid of the old install.  You also have the problem where various packages have different "features". Apparently, the Ghostscript, supplied by YUM, won't work with CUPS, but it is required for some other package that uses it. Now, it seems that the user needs to have two (perhaps more), different, copies of Ghostscript installed, and they need some way to get each program to use the proper version. I assume that LIBPATHSTRICT would allow that, but what a PITA.

I will point out that it appears that NONE of the stuff that comes from YUM has BLDLEVEL information in it. That basically means that there is no way to verify which version of a file you actually have installed. YUM keeps a database of that information, but it isn't strictly tied to the actual file. If the file gets changed, for some reason (perhaps it got restored from a backup), YUM still assumes that you have the one that it knows about. There may be some way to verify the database, but I haven't figured it out.
Title: Re: qpdfview
Post by: Alex Taylor on March 12, 2015, 01:35:14 am
whichdll.exe (http://www.altsan.org/os2/utils/#whichdll) finds DLLs which are already loaded by an application. If none is loaded, it finds whichever copy would be loaded by default.

My RXUTILEX.DLL Rexx library also includes this function (Sys2LocateDLL).
Title: Re: qpdfview
Post by: Silvan Scherrer on March 12, 2015, 08:30:41 am

QPDFView still can't find the plugin, unless it is on the boot drive.
Does this mean the complete qpdfview has to be on your bootdrive or only some dll?
Even I can't reproduce it here, I would be interested to iron this problem out.

Here bootdrive is c: and qpdfview is on e:\somedir and it works.
Did you try to delete %HOME%/.config/Trolltech.ini after moving the dll to another location?

I didn't move any DLLs, that I know about, except those in the QPDFVIEW directory, with the program. However, deleting %HOME%/.config/Trolltech.ini does fix the problem (I put the QPDFVIEW directory back where I want it).
I meant moving around qpdfview and those dll's like qpdfpdf.dll.
Qt remembers from where it loaded Qt dll's. And as qpdfview is a Qt application Qt knows from where it loaded the qpdfpdf.dll as example.
So if this dll gets moved to another location, Qt will not load it (beside it's in the bootdrive it seems).
This is a general Qt feature and has nothing to do with our port. Even we fixed/changed some stuff we think was ugly there already.

So deleting the ini file at every boot doesn't hurt, but makes the first start of a Qt app slower. And I don't think this is needed. But when you decide to have a QT app which was installed to move to another location, I would delete the file.

I hope this clears some questions here.
Title: Re: qpdfview
Post by: Doug Bissett on March 12, 2015, 04:09:11 pm
Quote
I meant moving around qpdfview and those dll's like qpdfpdf.dll.

Yes, I know that. The DLLs were in the QPDView directory, on my W: drive. The previous version of QPDFView was working, with no trouble. Then, I simply replaced the files, in that directory, with the new files (a one for one change). The new QPDFView could not find the DLL. When I moved the whole directory, including the DLLs, to the boot drive C: (just something to try), it started to work. From what you say, there must be some mechanism that notices a changed file, and doesn't recognize that it is the same file name. I have no idea why it would work when it was on the boot drive.

Quote
So deleting the ini file at every boot doesn't hurt, but makes the first start of a Qt app slower. And I don't think this is needed. But when you decide to have a QT app which was installed to move to another location, I would delete the file.

Whatever it does, I don't notice slower startup with anything. I did not move the location, until after it was broken. All I did was replace the DLLs. Perhaps the install instructions need to insist that a user should just delete the ini file (make it one of the steps, rather than an afterthought), for every QT app install (although I don't think I have had a problem with anything other than QPDFView, even after moving things). Better would be for the program to reinitialize itself, if it can't find whatever it is looking for. Unfortunately, I did not keep the INI file for comparison to the one that works. I may have it saved in a backup, somewhere, if I can find it.