From: dmg <dm...@uv...> - 2006-11-23 08:47:27
|
I have a couple of questions about the windows port. 1. Do we still need to keep panoinfo (this applies to all versions). Now that tools output the version in the command line I don't see a need for panoinfo, particularly when it is outdated. 2. The windows port has many "window-isms" such as GUI output instead of stdout and stderr output. I'd like to move towards ansi C and away from windows specific code. In the past OS 9 and and Windows had many different specific code and create many maintenance problems (for example, _I hate_ the myfree and mymalloc). In essence I want to get rid of sys_win.c and sys_mac.c. Can anybody envision any problem by doing so? I would also get rid of __Win__ ifdefs wherever possible. daniel -- Daniel M. German "An intellectual is someone whose Albert Camus -> mind watches itself. " http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: yuval l. <yuv...@ya...> - 2006-11-23 19:54:22
|
--- dmg <dm...@uv...>, "Daniel M. German" <dm...@uv...> wrote: > 1. Do we still need to keep panoinfo (this applies > to all versions). Now that tools output the version > in the command line I don't see a need for panoinfo, > particularly when it is outdated. as far as I understand this, panoinfo shows the version information of the DLL conveniently in the Windows GUI. I've used it a couple of times but its presence is not critical to me. I believe PTgui and other tools using the DLL check the version w/o the need for panoinfo, which is what most mainstream users need. As a user I can live with it and I can live without it. Why would you want to remove it? > 2. The windows port has many "window-isms" such as > GUI output instead of stdout and stderr output. I'd > like to move towards ansi C and away from windows > specific code. In the past OS 9 and and Windows > had many different specific code and create many > maintenance problems (for example, _I hate_ the > myfree and mymalloc). In essence I want to get rid > of sys_win.c and sys_mac.c. Can anybody > envision any problem by doing so? I would also > get rid of __Win__ ifdefs wherever possible. If by "GUI output" you mean that little window popping up with a progress bar and memory usage information, please KILL IT! I know too little of the inner works of the code to comment about problems in getting rid of platform-specific code, but in general I think that universal code is better than platform-specific code, and anything that has to do with output formatting on the screen should be left to GUI programs. The tool should not be visible on the GUI. Standard command line output (no output on correct execution or error message on failure of whatever kind) are more than enough IMO. Yuv Is this the kind of input you are looking for? ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited |
From: Pablo d'A. <pab...@we...> - 2006-11-23 21:19:45
|
Daniel M. German schrieb: > I have a couple of questions about the windows port. > > 2. The windows port has many "window-isms" such as GUI output instead > of stdout and stderr output. I'd like to move towards ansi C and > away from windows specific code. In the past OS 9 and and Windows > had many different specific code and create many maintenance > problems (for example, _I hate_ the myfree and mymalloc). In > essence I want to get rid of sys_win.c and sys_mac.c. Can anybody > envision any problem by doing so? Are there still direct calls to windows related stuff in the library? Actually, I have added sys_common.[hc] some time ago, which is basically a switch, so that programs using the library can decide where the messages go, but I might have missed some areas. basically, one can set output and error handlers using: PT_setErrorFcn PT_setProgressFcn PT_setInfoDlgFcn By default, the old methods (GUI on Windows, console output on unix) are used. However, it would also be possible to change the windows default in sys_common.c to the functions defined in sys_ansi.c This is important functionality, please do not remove it. Otherwise programs that are not console based (for example hugin) have no way of knowing what happens, except for parsing output messages, which is VERY easily breakable and hard to do reliably in a cross platform environment. > I would also get rid of __Win__ > ifdefs wherever possible. Yes, that is a good idea. ciao Pablo |
From: Daniel M. G. <dm...@uv...> - 2006-11-23 21:37:03
|
Pablo> Daniel M. German schrieb: >> I have a couple of questions about the windows port. >> >> 2. The windows port has many "window-isms" such as GUI output instead >> of stdout and stderr output. I'd like to move towards ansi C and >> away from windows specific code. In the past OS 9 and and Windows >> had many different specific code and create many maintenance >> problems (for example, _I hate_ the myfree and mymalloc). In >> essence I want to get rid of sys_win.c and sys_mac.c. Can anybody >> envision any problem by doing so? Pablo> Are there still direct calls to windows related stuff in the library? Pablo> Actually, I have added sys_common.[hc] some time ago, which is basically a Pablo> switch, so that programs using the library can decide where the messages go, Pablo> but I might have missed some areas. Pablo> basically, one can set output and error handlers using: Pablo> PT_setErrorFcn Pablo> PT_setProgressFcn Pablo> PT_setInfoDlgFcn Pablo> By default, the old methods (GUI on Windows, console output on unix) are Pablo> used. However, it would also be possible to change the windows default in Pablo> sys_common.c to the functions defined in sys_ansi.c thanks Pablo for the explanation. I totally agree that the error handlers are the best way to deal with the inconsistencies of different operating systems. What you you need from PTmender in hugin? Hugin calls the library directly for certain tasks so you can provide your own error handlers. But what should we do for the command line? I would rather not see any GUI inside the library. It makes things more complex. But we can provide the hooks to those who want to provide them (such as hugin). >From the panotools programmers point of view it does not matter. We keep using PrintError. PrintError is supposed to deal with this. I am thinking about branching the windows version. Inadvertently Jim changes broke the main trunk. And my changes keep breaking the windows version. So if we can get a branch of windows working then we can move forward more easily. Pablo> This is important functionality, please do not remove I did not mean to remove the error handlers, but just the GUI stuff from inside the library. Pablo> it. Otherwise programs that are not console based (for example Pablo> hugin) have no way of knowing what happens, except for parsing Pablo> output messages, which is VERY easily breakable and hard to do Pablo> reliably in a cross platform environment. >> I would also get rid of __Win__ >> ifdefs wherever possible. Pablo> Yes, that is a good idea. Pablo> ciao Pablo Pablo> ------------------------------------------------------------------------- Pablo> Take Surveys. Earn Cash. Influence the Future of IT Pablo> Join SourceForge.net's Techsay panel and you'll get the chance to share your Pablo> opinions on IT & business topics through brief surveys - and earn cash Pablo> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Pablo> _______________________________________________ Pablo> PanoTools-devel mailing list Pablo> Pan...@li... Pablo> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Erik K. <eri...@gm...> - 2006-11-23 22:07:35
|
On Thursday, November 23, 2006 at 0:47, Daniel M. German wrote: > 1. Do we still need to keep panoinfo (this applies to all > versions). Now that tools output the version in the command line I > don't see a need for panoinfo, particularly when it is outdated. PTGui seems to need it. I think it reads the crop type from it. Some time ago Joost removed the hard coded fisheye types - possibly after ipix threatened him (his page was down for some days). One had to input the crop and lens types manually after that and since panoinfo is available he possibly reads them from there. All wild guesses... best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: Daniel M. G. <dm...@uv...> - 2006-11-23 22:39:19
|
Thanks Erik, It makes sense! I'll update it. I think it is useful to have some of the information (but I see little point on spitting the list of patches). dmg Erik Krause twisted the bytes to say: Erik> On Thursday, November 23, 2006 at 0:47, Daniel M. German wrote: >> 1. Do we still need to keep panoinfo (this applies to all >> versions). Now that tools output the version in the command line I >> don't see a need for panoinfo, particularly when it is outdated. Erik> PTGui seems to need it. I think it reads the crop type from it. So= me=20 Erik> time ago Joost removed the hard coded fisheye types - possibly aft= er=20 Erik> ipix threatened him (his page was down for some days). One had to=20 Erik> input the crop and lens types manually after that and since panoin= fo=20 Erik> is available he possibly reads them from there. All wild guesses..= . Erik> best regards Erik> --=20 Erik> Erik Krause Erik> Resources, not only for panorama creation:=20 Erik> http://www.erik-krause.de/ Erik> ------------------------------------------------------------------= ------- Erik> Take Surveys. Earn Cash. Influence the Future of IT Erik> Join SourceForge.net's Techsay panel and you'll get the chance to = share your Erik> opinions on IT & business topics through brief surveys - and earn = cash Erik> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge= &CID=3DDEVDEV Erik> _______________________________________________ Erik> PanoTools-devel mailing list Erik> Pan...@li... Erik> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "Cuando tengas ganas de morirte no alborotes tanto: mu=E9rete Jaime Sabines -> y ya." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . =20 |
From: Jim W. <jwa...@ph...> - 2006-11-27 16:50:19
|
Daniel M. German <dmg@...> writes: > > Thanks Erik, > > It makes sense! > > I'll update it. I think it is useful to have some of the information > (but I see little point on spitting the list of patches). > > dmg > > Erik Krause twisted the bytes to say: > > Erik> On Thursday, November 23, 2006 at 0:47, Daniel M. German wrote: > >> 1. Do we still need to keep panoinfo (this applies to all > >> versions). Now that tools output the version in the command line I > >> don't see a need for panoinfo, particularly when it is outdated. > > Erik> PTGui seems to need it. I think it reads the crop type from it. Some > Erik> time ago Joost removed the hard coded fisheye types - possibly after > Erik> ipix threatened him (his page was down for some days). One had to > Erik> input the crop and lens types manually after that and since panoinfo > Erik> is available he possibly reads them from there. All wild guesses... > > Erik> best regards > Erik> -- > Erik> Erik Krause > Erik> Resources, not only for panorama creation: > Erik> http://www.erik-krause.de/ > > Erik> I created panoinfo mainly as a proof of concept for apps to check the info that is available. and for uses for a quick way to know what version they are using. Other apps do not actualy use panoinfo, they just use the same function calls to figure out what version or options are availalbe in the pano libreary they are useing. I believe PTGui will support all input/output image formats (fisheye, cylinder, ...) that are added with out changing PTGui and they will be listed in the drop down list. I made a new version for Windows that has been on my site since end of June. It does not display a command promt anymore and the Window message is scrollable. I created this just as we switched to SVN and never got it checked into. http://photocreations.ca/panotools/index.html Jim Watters |