GNOME Bugzilla – Bug 357818
TWAIN plug-in should skip scanner selection if there is just one scanner available
Last modified: 2018-05-24 11:59:34 UTC
The Win32 port has TWAIN support. When you choose the File->Acquire->TWAIN menu item, a dialog window opens, prompting you to select the scanner you want to use, regardless of how many scanners are available. If you have just one single scanner installed, that dialog window should not open. It should use the one single scanner there is without prompting. Other information:
There is currently no maintainer for the Twain plug-in. Maybe you want to look into this yourself?
(In reply to comment #1) > There is currently no maintainer for the Twain plug-in. Maybe you want to look > into this yourself? Sorry, I'm not a Windows programmer (although I do know a bit about user interface design, and develop software for a living, just not on/for Windows). So the issue I reported may just be an operating system "feature" (or rather another display of Microsoft ineptitute when it comes to user interface design). Should this report be closed? :-/
We can make it an enhancement request, but it will sit untouched until a Windows-gimp programmer comes along who is interested in working on it.
Even, if this issue is rather old, I will start working on it, as I've just fixed the issue (not yet released) that TWAIN doesn't work natively on Win 64 (currently I can't find this issue). But I suggest something more common: What about to select a default Scanner/Camera, that is used when acquiring TWAIN? This will lead to a new Menu item in "File" - suggestion by myself: rename File->Create->Scanner/Camera... (With DataSource select dialog) into File->Create->Selected Scanner/Camera... (Without select dialog) And add File->Select Scanner/Camera... (Only the select dialog) What's your optinion? kind regards Jens
That sounds helpful if you have more than one possible source for image acquisition. In my particular case, I had just one single source (a scanner) to choose from. And GIMP always insisted on having me select the scanner from a list of sources containing exactly one single entry. From the point of view of usability, this makes for poor design: if you do not have a choice, you should not be made to choose.
Created attachment 203720 [details] Displaying all found TWAIN data sources a separate menu item.
If you register the menu under "Acquire", like the screenshot plugin is doing it, the menu items will appear at the right place. The TWAIN plug-in is so broken, I'm willing to take any patch for it at any time, you just have to be in time for 2.8.
The are in deed a lot of smaller and bigger changes in the code. Therefore I suggest to send the sources as a ZIP file!?!
I send you an email, it returned as "Undelivered Mail Returned to Sender". How can I provide you with the changed sources?
Please not, attach a diff created by "git format-patch".
Attach to the bug, that is :) Thanks.
Created attachment 203726 [details] Change sources Thank you very much to accept the sources. Of course I want to be in time for 2.8 Unfortunately I can only test for Gimp 64 bit (!) on Win7. Jens
Please attach a *patch*, requiring reviewers to download a zip, unpack it, copy the files to the tree just to be able to see the diff... I'm not going to do that :)
Created attachment 203733 [details] [review] My changes to twain plugin sources. This patch isn't tested, as I don't know how to test it.
Wow, that patch is huge, thanks! Can you explain what this patch actually does, and why it seems to almost completely replace come files? Can you explain the changes per file perhaps.
(In reply to comment #14) > Created an attachment (id=203733) [details] [review] > My changes to twain plugin sources. > > This patch isn't tested, as I don't know how to test it. Firstly, it's amazing that you've tried to clean it up. Really appreciate the effort. It would be nice if you could attach patches in the following way. Then it'll be easy for us to review the changes. The current patch changes too much at one go. 1. Make all the whitespace changes you want as a separate patch. It should not change any existing code. Make the addition of braces as a separate patch. In fact, you can do multiple patches to make it use GIMP's coding style for the rest of the codebase. 2. Make all the macro replacements of callDSM() as a separate patch. Similarly, if you want to cleanup any more code, make them into independent patches, all of which independently apply, build and run cleanly. 3. Write the minimal code required to fix this bug as a separate patch. 4. Then make more patches to introduce any new functionality which you desire. With this approach, anyone looking at your patches won't scratch their head wondering what you're doing, and it'll be easier for Linux developers who aren't familiar with TWAIN to follow your patches too. We would really like these changes to go into the main GIMP branch. :)
Also make the twain.h update into a separate patch :)
@Mukund Sivaraman: Thank you so much for the feedback. I tried hard to get the plugin compiled with the HowTo of Partha. I read the coding style gide and thought, it would be a good idea to adapt it for all functions I will change, not aware that this will have an impact to nearly all of the files. Sorry for the huge effort these changes will mean to all of the reviewers. OK: please be patient with me and wait for the incremental patches coming up the next days.
Created attachment 203984 [details] [review] changes only spaces and CR/LF Roll back of the final changes. Lines containing changed code will not (allways) appear. - Thanks.
Created attachment 204020 [details] [review] Formatted code along style guide for white spaces. First step of rolled back sources (ref. attachment 203726 [details]). Still fighting with GIT.
Created attachment 204141 [details] Fixes bug for easy access TWAIN data sources as separate menu items. All patches in 8 steps including 1) cleaning up with spaces, tabs and CR/LF 2) cleaning up wiht braces 3) moved type defs, macros and prototypes into header and cleaned includes from headers. 4) changed logging 5) removed outdated _DEBUG sections as they don't worked. 6) separate patch for migrated twain header from 1.8 to 2.1 7) Fixed Win 64 Bit native support. 8) supporting direct access to TWAIN data source via separate menu items.
It would be a shame to let this bitrot, setting to 2.8 so we remember.
Created attachment 208874 [details] [review] [PATCH 1/8] Changed only SPACE, TAB, CR, LF.
Created attachment 208875 [details] [review] [PATCH 2/8] Added missing braces.
Created attachment 208876 [details] [review] [PATCH 3/8] Moved defines, typedefs and prototypes into headers.
Created attachment 208877 [details] [review] [PATCH 4/8] Changed logging from file to g_message.
Created attachment 208878 [details] [review] [PATCH 5/8] Removed outdated _DEBUG sections.
Created attachment 208879 [details] [review] [PATCH 6/8] Updated twain.h to 2.1
Created attachment 208880 [details] [review] [PATCH 7/8] Enabled TWAIN 64 Bit support on windows.
Created attachment 208881 [details] [review] [PATCH 8/8] fixes https://bugzilla.gnome.org/show_bug.cgi?id=357818 patches by Jens M. Plonka, from attachment #204141 [details] (patches-357818.tar.gz).
I just tested these patches (and the patch from bug 357818), but the results are mixed: - 64bit twain crashed for me, because I didn't have 64bit twaindsm.dll - after I installed twack_64 from twain-dsm, the plugin loads, but doesn't show any sources, because my scanner (HP ScanJet 5590) apparently doesn't have 64-bit twain drivers - 32-bit plugin works, but displays "twain.exe-Warning: OpenDSM failure: ``@" during GIMP startup; I don't however see my scan sources listed in File -> Create (but at least they appear when I select Scanner/Camera) - scanning multiple pages works properly now
Did anything become worse?
Well, 64-bit plugin previously just didn't work, while it now crashes if there's no 64-bit twaindsm.dll installed (and since it appears that 64-bit twain drivers are extremely rare, it's likely that everybody using the driver would see the crash). I'm slightly worried about the "OpenDSM failure: ``@" message - it comes from tw_func.c, function openDSM - somebody with more C knowledge than me should take a look at why garbage is displayed instead of an error message. The plugin still works though, and actually works better, since when scanning multiple pages in one session, pictures aren't discarded anymore. Regarding 64-bit plugin, I'll probably still ship 32-bit twain plugin, due to the lack of 64-bit twain drivers.
So let's go for these patches, they also clean up the code a lot. Dieter is on that.
Created attachment 209108 [details] [review] Fixed the problem with logging messages.
sounds confusing to me. Can you please zip the twain folder from the project and send it to me? - Thanks!
So what happened here? It seems this slipped... Jens, Dieter? I tried to apply the patches, but it's a mess that doesn't apply any longer. Does one of you guys still want to take care of this, please?
Comment on attachment 208874 [details] [review] [PATCH 1/8] Changed only SPACE, TAB, CR, LF. The TWAIN plug-in has changed, this needs a few changes to apply cleanly.
I've applied these changes to a branch based on master, bug-357818 - https://git.gnome.org/browse/gimp/log/?h=bug-357818 Initial tests have shown that the branch builds and produces a runnable plug-in, but for the lack of TWAIN devices, the tester couldn't check if it actually does anything.
Setting all patches to the needs-work state. I hope most or all of this work is done in the branch already , though.
You can install a sample TWAIN driver from <http://www.twain.org/scannerdriverdevelopers.html> - it'll present a virtual scanner to the application.
Seriously, if you made that branch and it works for you, just push, it can't get any worse.
That's the point - I don't know if it works.
Also, when do these patches query the available scanners. The result of the query cannot be cached in the form of plug-in procedures because that would mean one can only register scanners the first time GIMP is executed. Is the TWAIN query code still in run()?
(In reply to Jernej Simončič from comment #41) > You can install a sample TWAIN driver from > <http://www.twain.org/scannerdriverdevelopers.html> - it'll present a > virtual scanner to the application. This link is dead and I could not find if it has moved somewhere (and where). Would you know of a new link for this?
The new link seems to be http://www.twain.org/scanner-driver-developer
I really can't make the time to test this (which I could only in some VM). Could anyone do this if you want to see this in GIMP 2.10?
Created attachment 368769 [details] scanner interface Gimp 2.9.9
Bonjour, What is said in the report of the bug is not a defect ( Description ). Even if there is only one scanner connected there can be two interfaces to access this scanner: - the Windows scanner interface - and the scanner manufacturer interface. I think we have to leave the choice to the user. I enclose an example with Gimp 2.9.9 where only one scanner is connected ( 1_scanner_2interfaces_gimp-2.9.9.png ). :o)
Indeed. Maybe the right wording would be "one scanner interface" or "one scanner source". With this wording, it still makes sense if you have a single scanner interface. This said, it is also true that disappearing dialogs are never ideal. What if someone thinks one has 2 scanners or 2 scanner interface, but is never prompted to choose => you'd think GIMP does not let you choose through your scanners. Whereas if it prompts you to choose but there is a single choice, then you may guess that your driver installation is at fault. IMO, ideally when GIMP sees a single scanner interface, it should not prompt you at start, *but* you should still be able to access the interface selection dialog afterwards from the main GUI. No idea if that's what do the proposed patches. In any case, the real problem here is the lack of Windows developers, or even simply people to test. Sylvie, I just rebased and pushed the branch origin/bug-357818 onto the last master code. Would it be possible for you to test building this branch? Apparently it even adds support for 64-bit Twain, which would be a lot better than the mixing of versions discussed in bug 788962. So if you could build, then test the updated Twain plug-in, tell us if it works at all, and if it improves things (or the opposite), etc. this would be extremely helpful.
Created attachment 368776 [details] 2 scanners 3 interfaces @Jehan Bonjour, I do not know if it is necessary to change the GUI for this scanner. Under windows, everything depends on how the hardware is installed and the manufacturer ... For example I connected a second printer with scanner and found 3 access: 2 for the Brother and 1 for the HP. I enclose the illustration : 2_scanners_3interfaces_gimp-2.9.9.png New version 'twain' plugin : I'm compiling the latest GIT version of Gimp, I'm doing tests and I'm coming back to give results. :o)
Created attachment 368794 [details] Win 64 test git checkout origin/bug-357818 @Jehan Bonjour, I compiled this Git version with your modification : GIMP_2_9_8-593-gd21771fff2 + git checkout origin/bug-357818 Test Gimp 2.9.9 64-bit Win : - The selection window opens but the scanner (s) are not present but the window closes well. - With the 'twain plugin' standard 64-bit version nothing happens. I do not know if there is a big importance to put the plugin 'twain' in 64 bits. For example, Python is 32-bit in the stable and official version of Gimp. Merci :o)
(In reply to sylvie.alexandre from comment #52) > Created attachment 368794 [details] > Win 64 test git checkout origin/bug-357818 > > @Jehan > > Bonjour, > > I compiled this Git version with your modification : > GIMP_2_9_8-593-gd21771fff2 + git checkout origin/bug-357818 Thanks for testing! > Test Gimp 2.9.9 64-bit Win : > - The selection window opens but the scanner (s) are not present but the > window closes well. > - With the 'twain plugin' standard 64-bit version nothing happens. Not sure I understand. Basically nothing works, then? > I do not know if there is a big importance to put the plugin 'twain' in 64 > bits. > For example, Python is 32-bit in the stable and official version of Gimp. Well it's still better to have consistent 64-bit rather than relying on 32-bit compatibility layers. > Merci :o)
> > Test Gimp 2.9.9 64-bit Win : > > - The selection window opens but the scanner (s) are not present but the > > window closes well. > > - With the 'twain plugin' standard 64-bit version nothing happens. > > Not sure I understand. Basically nothing works, then? That's it, nothing works.
If the branch doesn't break the 32-bit version of the TWAIN plug-in, we should probably still consider to merge it into master to make it easier to do further improvements. Note that the patches have extended beyond the original summary of this feature request, so we should change that before resolving the bug report.
(In reply to Michael Schumacher from comment #55) > If the branch doesn't break the 32-bit version of the TWAIN plug-in, we > should probably still consider to merge it into master to make it easier to > do further improvements. Well we don't know if it doesn't break anything in 32-bit. Sylvie > Did you also try to build it in 32-bit by any chance? Does it still work? Does it improve anything there? In any case, I'm not sure we should merge it that close to 2.10 in its current state of uncertaincy. We don't have anyone to maintain it and fix bugs and apparently the new code does not deliver what it was supposed to. So we can most likely expect more problems to come, and none will be there to fix them. IMO this should be considered for a 2.10.x unless someone comes now and take care of this branch carefully. Maybe Edward E. would like to have a look? > Note that the patches have extended beyond the original summary of this > feature request, so we should change that before resolving the bug report. Indeed.
Bonjour, (In reply to Jehan from comment #56) > Sylvie > Did you also try to build it in 32-bit by any chance? Does it still > work? Does it improve anything there? Later in the day I will compile the patch 'origin/bug-357818' in 32 bits and give the result of the tests. :o)
> Sylvie > Did you also try to build it in 32-bit by any chance? Does it still > work? Does it improve anything there? Bonjour, I recompiled Gimp 2.9.9 in 32 bits with the modification 'origin/bug-357818'. My 32-bit tests are good: - No error message. - The different interfaces of my devices are recognized (WIA, TW-Brother). - I was able to scan documents with my devices. Bravo :o) ****** 64 bits modification 'origin/bug-357818': I looked a bit at the new source code. I noticed that 64 bits TWAINDSM.DLL should be present. On the computer where I compile I have two old versions of 2009 installed (32 and 64 bits). I will recompile and test with newer DLL versions of the site https://github.com/twain/twain-dsm :o)
Thanks a lot for all the tests Sylvie. Looking forward the new 64-bit tests.
(In reply to Jehan from comment #59) > Thanks a lot for all the tests Sylvie. Looking forward the new 64-bit tests. Bonjour, 'Twain' tests after Gimp 2.9.9 compilation in 64 bits Win (version origin/bug-357818) - The 64-bit tests are bad and display only the empty window without the choice of interfaces. - I found that the 64-bit version looks for TWAINDSM.dll in C:\Windows\System32 and not in C:\Windows\SysWOW64 (it may not be a problem) - The 'https://github.com/twain/twain-dsm' DLLs do not allow the plugin to work. - I watched the site http://www.twain.org/specification/ I downloaded the 'Twacker' utilities from the 'Tools' section. 'Twack-32.msi' works perfectly. 'Twack-64.msi' does not work and gives the same result as the Gimp plugin. - I did tests on my laptop with Win 10 64 bit pro: I found that by default TWAINDSM.dll is not installed. The results with 'Twacker' are identical (only the 32-bit version works). :o)
(In reply to sylvie.alexandre from comment #60) > (In reply to Jehan from comment #59) > > Thanks a lot for all the tests Sylvie. Looking forward the new 64-bit tests. Other tests in 64 bits : I downloaded the 64-bit virtual scanner from https://developer.dynamsoft.com/dwt/kb/2659 This 64-bit virtual scanner is recognized by '64-bit Twacker' but not by the 64-bit 'twain' plugin from Gimp. I have the impression that the scanners are mainly in 32 bits on Windows, It is surely because 'twain_32.dll' is present by default... :o)
> Sylvie > Did you also try to build it in 32-bit by any chance? Does it still > work? Does it improve anything there? > Bonjour, This is an update test on the original version 'origin/bug-357818'. I replaced twain.h with the latest version http://www.twain.org/wp-content/uploads/2017/04/TWAIN.H.h I compiled in 32 bits with this new version and the results are good. :o)
(In reply to sylvie.alexandre from comment #62) > > Sylvie > Did you also try to build it in 32-bit by any chance? Does it still > > work? Does it improve anything there? > > > > Bonjour, > > This is an update test on the original version 'origin/bug-357818'. > I replaced twain.h with the latest version > http://www.twain.org/wp-content/uploads/2017/04/TWAIN.H.h > I compiled in 32 bits with this new version and the results are good. > > :o) Uh! Is this file in our repository straight from the TWAIN project without us even touching its code?! Wow that sucks. Is it the recommended way to use TWAIN, rather than as common dependencies searchable at configuration time? Anyway Sylvie, I am a little lost with all your (awesome) tests. Could you tell us what are your recommendations? Does it feel like it will be possible to build the twain plug-in in 64-bit with some tweaks? What about this twaindsm.dll? Is it something which should be packaged with GIMP installer? Should it absolutely be in system paths or can it simply be with the plugin under a twain\ subdirectory, maybe? Should we just replace the twain.h by the upstream version? (In reply to sylvie.alexandre from comment #61) > This 64-bit virtual scanner is recognized by '64-bit Twacker' but not by the > 64-bit 'twain' plugin from Gimp. > > I have the impression that the scanners are mainly in 32 bits on Windows, It > is surely because 'twain_32.dll' is present by default... Are you saying that if a scanner uses a 32-bit driver, it will only be seen by 32-bit twain and if it uses a 64-bit driver, it will be seen only by 64-bit twain? If so, that's messed up. I would expect the 64-bit TWAIN to be able to load and see both 32 and 64-bit drivers on a 64-bit system. Any other recommendation of what we should do?
(In reply to Jehan from comment #63) > (In reply to sylvie.alexandre from comment #62) > Uh! Is this file in our repository straight from the TWAIN project without > us even touching its code?! Wow that sucks. I found that this file was used by many applications (LibreOffice, etc.). Each application uses a more or less recent version. It might be a good idea to use the latest version of twain.org instead of version 2.1 of 2009 (also from twain.org). > Is it the recommended way to use TWAIN, rather than as common dependencies > searchable at configuration time? It depends if the evolution of the versions involve regressions, it is necessary to interrogate the people of twain.org > Anyway Sylvie, I am a little lost with all your (awesome) tests. My tests are chronological and unfortunately they have not been pre-established according to a rational method but according to a more or less intuitive method ... Could you tell us what are your recommendations? > Does it feel like it will be possible to build the twain plug-in in 64-bit with some tweaks? > What about this twaindsm.dll? Is it something which should be packaged with GIMP installer? Should it absolutely be in system paths or can it simply be with the plugin under a twain\ subdirectory, maybe? twaindsm.dll is the 64-bit twain interface for Windows that you need to install. twain_32.dll is the 32-bit twain interface for Windows provided by default. I am to try your modification. At home, it works. To try on other O.S. > Should we just replace the twain.h by the upstream version? Try to ask the opinion of the plugin authors... It's my way of not answering :o) > (In reply to sylvie.alexandre from comment #61) > > This 64-bit virtual scanner is recognized by '64-bit Twacker' but not by the 64-bit 'twain' plugin from Gimp. > > > > I have the impression that the scanners are mainly in 32 bits on Windows, It is surely because 'twain_32.dll' is present by default... > > Are you saying that if a scanner uses a 32-bit driver, it will only be seen by 32-bit twain and if it uses a 64-bit driver, it will be seen only by 64-bit twain? If so, that's messed up. I would expect the 64-bit TWAIN to be able to load and see both 32 and 64-bit drivers on a 64-bit system. This is unfortunately what I see. This is not a problem at all because the 32-bit version still works well. For Windows it requires to make 2 compilations to have the plugin twain operational. If the plugin is only 64 bits the result will be the same as LibreOffice 64 bits: a window without interface. Merci. :o)
I think the idea is to include the twain header file(s) into your projects, as this is not commonly distributed (this isn't that uncommon for more niche libraries, especially those dating from a time before widespread distributed version-controlled code sharing platforms). Note that the 64 bit version seems to have worked at least at one point for the original patch author - see bug 601821 comment 8 That bug was my main goal for the effort to apply the existing patches, to get that multi-page scanning ability into a working state. The process of creating the currently existing branches was a painstakingly manual one, as the plug-in code had evolved somewhat since its original creation by Jens and the subsequent patch update by Dieter. Emacs' ability to handle patch chunks interactively was a tremendous help, but there are chances I introduced some errors during that process.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/213.