Hi,

> We could use pthread library as it is
> more flexible to use as far as knowledge and can manipulate the main program
> so as to create threads for both the user interface components and also
</snip>

Please consider the following points:
1) The project works on an existing project with an existing code
base.
2) The code should run on all major platforms: Linux, MacOS, Win

Regarding pthread:
As the name says: POSIX threads. This does not work on windows,
because windows is using an other approach for threading. There is a
windows implementation - as James wrote. But this supports only a
subset of pthread. Also it seems to be discontinued - the last change
was in 2006. So from a windows view I dislike this approach. -> see
point 2

Furthermore Hugin is already using Boost::Thread (see point 1 above).
If you use pthread there will be different ideas/libs in different
parts of the code. This will make bug hunting more complicated than it
has to be. And then there will be 2 libs for the same task.

Also take wxWindows in account. Their wxThread implementation
resembles to pthread. This would also have the advantage for better
interaction with the GUI. And most parts of the project is fiddling
with GUI and you will need interaction with the GUI. So you have to
inform the GUI, when a image is loaded completely and the placeholder
should be exchanged with the real image. I think, this will be easier
to done with wxWidgets own implementation than with any other external
lib. Otherwise you have to consider how to access the GUI parts from
the load thread - that will need special treatment for different
system - which will not be need by using wxThread.

> This implementation is quite flexible as the implementation can be modified
> on different processors easily like ,if the importance is given to user
> interface component then threads of it can be assigned to it to function
> separately while the image loads and this can be made dynamic even in which
> user preferences can be given according to the processor architecture as
> well as the user preference.

Don't make it too complicate. The Hugin GUI is intended for the
"casual" user. He don't want to fiddle with difficult settings to run
hugin. So keep it simple from a users point of view.

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx

To unsubscribe from this group, send email to 
hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Reply via email to