On Fri, Oct 11, 2002 at 09:08:35PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> I agree that a common code style is important.
>
> My point was that automatic reformatting has to be followed
> by human inspection.
Why? indent understands enough of C not to change the semantics of the
code. Outside of string literals and preprocessor directives, all
whitespace is equal.
On Fri, Oct 11, 2002 at 09:35:15PM +0200, Bernhard Reiter wrote:
[...]
Otherwise we paralize development too much. At least this was feared.
... unfortunately (maybe not avoidable) that has already started:
we have
- NVIZ CVS version in 5.0
- upcoming contributions from Bob Covill (5.0, very welcome):
- bugfixes
- improvements
- NVIZ enhanced with 3D vectors in 5.1
As efforts have been recently started to integrate G3D into NVIZ, we should
be careful not to end up in a total mess. In my opinion we should hardly work
on the transition to 5.1.
On Sat, Oct 12, 2002 at 10:14:14PM +0200, Markus Neteler wrote:
On Fri, Oct 11, 2002 at 09:35:15PM +0200, Bernhard Reiter wrote:
[...]
> Otherwise we paralize development too much. At least this was feared.
... unfortunately (maybe not avoidable) that has already started:
This is not stopping development.
It is splitting it up.
No chance to avoid this and porting and backporting.
As efforts have been recently started to integrate G3D into NVIZ, we should
be careful not to end up in a total mess. In my opinion we should hardly work
on the transition to 5.1.
Yes, sure.
On the other hand, there probably going to be a 5.0.x
release from the current GRASS50 CVS HEAD.
(5.0.1 might come off the old release branch if Glynn can
convince me that we have bad _critical_ bugs in there.)
On Mon, Oct 14, 2002 at 08:25:06PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> I'd rather go with a better cross platform application framework.
> Thus the hottest candidate if I'd ever would approach this is wxPython.
Unfortunately, wxWindows is also C++.
right. Thats why Bernhard proposed wxPython, the Python wrapper for
wxWindows. A language like Python works quite well for gluing
functionality together for a GUI.
I wrote a small wxPython sample for automatically building GUI dialogs
from the --interface-specification of GRASS commands some time ago.
If the Windows version of GTK+ is adequate, I'd suggest using GTK+.
I also tested this and it works. However, you'll have a GTK-looking
application under Windows which looks a bit alien.
The big advantage of wxWindows is the concept of using native frameworks
for GUI building. E.g. MSFC is used if the programm is executed on a
Windows platform, GTK (or even QT) is used if you are on a GNU/Linux
system. There is also a solution for MacOS.
On Mon, Oct 14, 2002 at 08:25:06PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> I'd rather go with a better cross platform application framework.
> Thus the hottest candidate if I'd ever would approach this is wxPython.
Unfortunately, wxWindows is also C++.
True. WxPython wraps this in an okay way, though.
It seems that Microsofts libraries are mostly exposing C++ apis.
Thus there is no real way around c++ for Windows GUIs.
If the Windows version of GTK+ is adequate, I'd suggest using GTK+.
AFAIK it isn't.
Furthermore it is not an application framework.