Re: [GRASS-dev] Structure of links for addons, manual pages etc.

[Yann Chemin]

About the manual urls, I have an opinion:

Main manual for G7 to be linked to the SVN version (always updated).
Old manuals fixed to released versions (not maintained).

I understand how extreme it may be, but it may be very easy to maintain
(only one version)

0.02c


On 10 April 2014 07:21, Vaclav Petras  wrote:

> Hi,
>
> I think we need to rethink the structure of addresses/links to various
> things which we are putting online.
>
> The motivation are discussions "Linking Addons manual pages to core
> modules", "addons for windows", and "Addon manual pages not linked".
>
> For example, so far we were linking the trunk documentation using
> grass70/manuals but since we forked the 70 branch these links now points to
> it and not to trunk. Also all general links to GRASS documentation leads to
> grass64/manuals but this will be soon very obsolete.
>
> A lot of projects uses links such as latest, release or current (e.g.
> latest/manuals or release/manuals) which leads to the current (latest)
> release. And also links such as master, latest, trunk, nightly which leads
> to the one builds from the source code of the main branch. Alternatively,
> there is no special link for the current release which shortens URLs. I
> think something like this might be beneficial for us.
>
> So far I identified this set of things:
>
> * GRASS binaries
> * addons for MS Windows
> * addons SVN
> * manual pages
> * programming manual (or manuals)
>
> I don't have any concrete suggestion now. What are your experiences with
> this?
>
> Thanks,
> Vaclav
>
>
> http://lists.osgeo.org/pipermail/grass-dev/2014-April/068192.html
> http://lists.osgeo.org/pipermail/grass-dev/2014-April/068193.html
> http://lists.osgeo.org/pipermail/grass-web/2013-December/004587.html
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Structure of links for addons, manual pages etc.

[Vaclav Petras]

Hi,

I think we need to rethink the structure of addresses/links to various
things which we are putting online.

The motivation are discussions "Linking Addons manual pages to core
modules", "addons for windows", and "Addon manual pages not linked".

For example, so far we were linking the trunk documentation using
grass70/manuals but since we forked the 70 branch these links now points to
it and not to trunk. Also all general links to GRASS documentation leads to
grass64/manuals but this will be soon very obsolete.

A lot of projects uses links such as latest, release or current (e.g.
latest/manuals or release/manuals) which leads to the current (latest)
release. And also links such as master, latest, trunk, nightly which leads
to the one builds from the source code of the main branch. Alternatively,
there is no special link for the current release which shortens URLs. I
think something like this might be beneficial for us.

So far I identified this set of things:

* GRASS binaries
* addons for MS Windows
* addons SVN
* manual pages
* programming manual (or manuals)

I don't have any concrete suggestion now. What are your experiences with
this?

Thanks,
Vaclav


http://lists.osgeo.org/pipermail/grass-dev/2014-April/068192.html
http://lists.osgeo.org/pipermail/grass-dev/2014-April/068193.html
http://lists.osgeo.org/pipermail/grass-web/2013-December/004587.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] addons for windows

[Martin Landa]

Hi,

2014-04-09 15:48 GMT+02:00 Markus Neteler :
> On Tue, Apr 8, 2014 at 6:26 PM, Martin Landa  wrote:
> ...
>> I will change addons builds for
>> trunk to the same layout. Unfortunately it's not possible to fix it
>> for beta1 (avoiding extra builds with locally applied patch). Let's
>> wait for beta2.
>
> IMHO we should consider to tag beta2 soon.

probably yes, I will test the next build. Martin

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2059: WorldView2 relative spectral response data for i.atcorr

[GRASS GIS]

#2059: WorldView2 relative spectral response data for i.atcorr
--+-
 Reporter:  nikosa|   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Imagery   | Version:  svn-trunk
 Keywords:  i.atcorr, worldview2  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by nikosa):

 Back to this,

 QuickBird2 samples available from GLCF:
 http://glcf.umd.edu/data/quickbird/, e.g. I recently used some from
 
ftp://ftp.glcf.umd.edu/glcf/QuickBird/02NOV21044347-X2AS_R1C1-00185940_01_P001
 -India-The_Sundarbans

 WorldView2 sample image available from Apollo Mapping:
 http://apollomapping.com/image_downloads/WV2_8band_Bundle_Sydney_Australia.zip

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Glynn Clements]

Vaclav Petras wrote:

> > And this .bat file specifies the script interpreter. Looks like a good
> > solution to also select the correct Python version.
> 
> 
> I'm afraid how will work for user scripts. Typical case will be that user
> has some Python, so he or she will try to run from outside if he or she
> sets the environment correctly, running of modules (exe or bat) will be OK,
> but grass.pygrass and grass.lib might not be OK.
> 
> The other typical case (hopefully more common) is when a user writes his or
> her own GRASS Python module/script. This does not contain any environment
> settings (same as .py in scripts/ and temporal/) because it is intended to
> be run inside of GRASS session. However, it will not run because there is
> no .bat. Should user create one? Should GUI do some workaround for that
> case? But what about Python command line, wxGUI command console and
> standard Windows command line?
> 
> My point is that nobody was writing shell scripts on Windows but people are
> writing Python scripts/modules. So, this new problem to solve.

My view is that .bat files may have some value as a workaround to make
GRASS mostly functional on systems which lack a usable (or any) Python
installation. A significant advantage is that they're a lot less
invasive than having hard-coded treatment for Python scripts littered
throughout GRASS.

On systems with a suitable Python installation, neither .bat files nor
the use of a bundled Python interpreter should be forced upon the
user.

My main criterion for any workaround for Python-on-Windows "issues" is
"First, do no harm". Users who want feature-parity with Unix (and are
willing to satisfy the requirement of having Python as a "system
feature") shouldn't have to suffer in order to make the packager's job
easier.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Glynn Clements]

Markus Metz wrote:

> > In spite of wxGUI, GRASS remains fundamentally a collection of
> > command-line modules, more like a library than an application.
> 
> I make use of this property daily. On MS Windows, GRASS should by
> default behave like a stand-alone application. You can make use of the
> collection of command-line modules through the msys shell, but that is
> really only for power users.

You can use any shell. On Windows, there's no particular reason to use
MSys. It's more powerful than cmd.exe, but also has a lot of drawbacks
(MSys doesn't register it as an interpreter for the .sh extension, it
requires Unix-style pathnames, it doesn't honour file associations,
etc).

We certainly shouldn't be bundling MSys with GRASS 7. A very large
part of the reason for the switch to Python was to eliminate that
particular dependency (the remaining part being that, on any platform,
Bourne shell is simply unfit for "scripts" which need to perform
non-trivial data processing themselves, as opposed to simply gluing
other programs together).

If a script is trivial enough not to prefer using Python, it's trivial
enough for cmd.exe.

> > These are self-contained GUI applications. Which is a major
> > limitation; if I need to manipulate images, I'm more likely to use
> > NetPBM or PIL/NumPy than GIMP (on any platform). Apart from anything
> > else, the job will be over and done while GIMP would still be showing
> > the splash screen.
> >
> > If I'm likely to perform the same operation more than once, I'm *much*
> > more likely to use the scripted approach than the pointy-clicky GUI.
> 
> As an experienced *NIX user, yes. Not so Windows users, many feel
> alienated by a command line. On Windows, GRASS should behave like a
> self-contained GUI application. There were even suggestions to remove
> the command line interface completely from winGRASS because it
> confuses users.

Such suggestions are entirely misplaced. The end result would be so
watered-down as to make GRASS almost useless.

It's clear that we're never going to agree on this. You're willing to
substntially cripple GRASS in the hope that it will be usable by the
"... For Dummies" crowd, and I'm not.

And I don't even think that such a goal realistic. However much you
simplify the program, you can't simplify the underlying concepts. It
has been noted that the "For Dummies" series doesn't include
"Neurosurgery for Dummies", "Civil Aviation for Dummies", or the like.

Do we really need more users who not only don't know which projection
their data is in, but don't even know what a projection is? And,
regardless of how much the interface is simplified, is GRASS even
going to be of any use to them?

tl;dr: if you want Google Earth, you know where to find it.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Glynn Clements]

Markus Metz wrote:

> > I basically agree with user expectations you stated. But I would like to
> > note that recently, I met several users which wanted and expected that GRASS
> > script will run outside GRASS without any special environment setup in the
> > script itself.
> 
> AFAIK, GRASS scripts explicitly test if they are run inside GRASS,
> otherwise they exit with an error message saying "You must be in GRASS
> GIS to run this program." You are inside GRASS as soon as the
> environment variables for the GRASS version are set and as soon as a
> proper GRASS session has been established (location and mapset). No
> GRASS script should run outside GRASS, independent of the OS.

This is conflating "inside GRASS" with "necessary environment
variables set".

It's entirely possible to configure the system so that the environment
variables are always set.

As I've mentioned before, the only time I run the grass7 script is if
I'm testing it.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Glynn Clements]

Benjamin Ducke wrote:

> GEOS is a heavy C++ beast and difficult to compile using GCC
> on Windows (at least if you want the result to pass all
> validation tests).
> 
> I would prefer to stick to C dependencies only for the core
> modules, if only to avoid DLL hell when mixing Visual C++
> and GCC DLLs on Windows (different name mangling styles).

It's not just name mangling. There isn't an official ABI for C++ on
Windows. Even if all components are compiled with MSVC, simply using
different compiler switches can result in incompatibilities (e.g. the
layout of pointer-to-member values can vary according to the /vm*
switches used).

Different compilers use different mangling rules because their code is
inherently incompatible. Changing the name mangling just prevents
people from trying to do things which aren't going to work anyhow.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2249: handling manual pages with external links within the GUI

[GRASS GIS]

#2249: handling manual pages with external links within the GUI
-+--
 Reporter:  madi |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  manual   |Platform:  All  
  Cpu:  All  |  
-+--

Comment(by wenzeslaus):

 Replying to [comment:2 neteler]:
 > Replying to [comment:1 wenzeslaus]:
 > > I'm not sure what user would expect. But you might be right.
 > > External links are special and the HTML rendering capabilities
 > > of the used widget are (currently) very limited.
 >
 > An initial improvement could be as easy as this (if technically
 possible):
 >
 > If the link contains "http", open it with an external browser (env var
 > $GRASS_HTML_BROWSER), otherwise open page as currently in the wx-
 browser.

 As far  as I know, we are currently using "system browser" not
 `$GRASS_HTML_BROWSER` in wxGUI and I'm not sure what is correct. However,
 the difference is just few lines.

 Here is the solution [http://wxpython-users.1045709.n5.nabble.com/Open-a
 -URL-with-the-default-browser-from-an-HtmlWindow-td2326349.html Open a URL
 with the default browser from an HtmlWindow?] for your suggestion.

 They are using Python [https://docs.python.org/2/library/webbrowser.html
 webbrowser], the alternative is
 [http://docs.wxwidgets.org/2.6.3/wx_miscellany.html#wxlaunchdefaultbrowser
 wxLaunchDefaultBrowser].

 The button I was talking about might be even more simple, just call the
 browser with current URL/file.

 I would suggest to implement both.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2251: highlight selected features and zoom - display not centered over the highlighted feature

[GRASS GIS]

#2251: highlight selected features and zoom - display not centered over the
highlighted feature
--+-
 Reporter:  madi  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  table, highlight, select  |Platform:  All  
  Cpu:  All   |  
--+-
Changes (by madi):

  * component:  Vector => wxGUI
  * milestone:  7.1.0 => 7.0.0


-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] addons for windows

[Markus Neteler]

On Tue, Apr 8, 2014 at 6:26 PM, Martin Landa  wrote:
...
> I will change addons builds for
> trunk to the same layout. Unfortunately it's not possible to fix it
> for beta1 (avoiding extra builds with locally applied patch). Let's
> wait for beta2.

IMHO we should consider to tag beta2 soon.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2249: handling manual pages with external links within the GUI

[GRASS GIS]

#2249: handling manual pages with external links within the GUI
-+--
 Reporter:  madi |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  manual   |Platform:  All  
  Cpu:  All  |  
-+--

Comment(by neteler):

 Replying to [comment:1 wenzeslaus]:
 > I'm not sure what user would expect. But you might be right.
 > External links are special and the HTML rendering capabilities
 > of the used widget are (currently) very limited.

 An initial improvement could be as easy as this (if technically possible):

 If the link contains "http", open it with an external browser (env var
 $GRASS_HTML_BROWSER), otherwise open page as currently in the wx-browser.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Helmut Kudrnovsky]

>One Windows problem is that there is no package manager
>who takes the user's hand which is the reason for these large
>standalone applications on MS Windows. 
[...]
>>
>> Personally, I am a bit afraid that by going down the first route we
>> concentrate much developer time that could be spent on other (IMHO more
>> useful) things and we also risk to make GRASS less efficient for those
>> that
>> have taken the time to pass the hurdle.
>
>Changing the installer to take care of a system-wide Python
>installation that also resolves conflicts is probably far more work
>than to use the existing mechanism of GRASS6. 

I support this. this kind of installer opens a Pandora's box (e.g.
how to solve problems if another software installs another system-wide
incompatible python, ...), than it helps.

>> In other words, there are some types of users (those that don't read
>> anything provided by the developers) for whom I am sometimes tempted to
>> just
>> say "RTFM" instead of trying to find ways to make it possible for them to
>> still use GRASS. 

at least in the winGRASS-standalone installer we offers an option to open
the manuals/first time user 
pages if the installer quits.




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-PSC-too-many-branches-retirement-GRASS6-5-svn-develbranch6-tp5133400p5134122.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Vaclav Petras]

On Wed, Apr 9, 2014 at 2:16 AM, Markus Metz
wrote:

> On Wed, Apr 9, 2014 at 3:44 AM, Glynn Clements 
> wrote:
> >
> > Markus Metz wrote:
> >
> >> > All of this goes out the window if you want to provide a command-line
> >> > environment, whether an interactive shell or the ability to execute
> >> > commands via system() or CreateProcess().
> >>
> >> It works in GRASS 6 with shell scripts. I am sure the same mechanism
> >> will work just as well with python scripts.
> >
> > GRASS 6 creates a .bat file for each shell script.
>
> And this .bat file specifies the script interpreter. Looks like a good
> solution to also select the correct Python version.


I'm afraid how will work for user scripts. Typical case will be that user
has some Python, so he or she will try to run from outside if he or she
sets the environment correctly, running of modules (exe or bat) will be OK,
but grass.pygrass and grass.lib might not be OK.

The other typical case (hopefully more common) is when a user writes his or
her own GRASS Python module/script. This does not contain any environment
settings (same as .py in scripts/ and temporal/) because it is intended to
be run inside of GRASS session. However, it will not run because there is
no .bat. Should user create one? Should GUI do some workaround for that
case? But what about Python command line, wxGUI command console and
standard Windows command line?

My point is that nobody was writing shell scripts on Windows but people are
writing Python scripts/modules. So, this new problem to solve.

Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1856: wxGUI with LANG=pl_PL.utf8 throws "'ascii' codec can't decode byte"

[GRASS GIS]

#1856: wxGUI with LANG=pl_PL.utf8 throws "'ascii' codec can't decode byte"
--+-
 Reporter:  msieczka  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.4
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:  LANG, locale  |Platform:  Linux
  Cpu:  x86-64|  
--+-

Comment(by mlennert):

 Replying to [comment:1 marisn]:
 > Is this still an issue?

 I don't see it when calling the "Metadata", but other than that it pretty
 much sounds the same as #2120.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2120: wxgui: encoding errors

[GRASS GIS]

#2120: wxgui: encoding errors
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  locale encoding  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Replying to [comment:1 marisn]:
 > Is this still an issue in GRASS 7? There has been a huge progress
 related to ironing out encoding issues in WXGUI.

 I've been testing in the last days, and it seems that everything is
 working smoothly now in GRASS7. Great job !

 However, in GRASS6release I still get the same errors.

 Maybe some of what was done in grass7 should be backported to grass6?

 Moritz

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Benjamin Ducke]

Has somebody here figured out yet how to compile GEOS
using GCC on Windows (MinGW), so that it passes all of
its own validation tests? That's where I am stuck
at this point:

http://gvsigce.sourceforge.net/wiki/index.php/Compiling_the_C/C%2B%2B_support_libraries#GEOS_.28currently_disabled.29

Cheers,

Ben

On 09/04/14 12:02, Jürgen E. Fischer wrote:
> Hi Martin,
> 
> On Wed, 09. Apr 2014 at 11:52:34 +0200, Martin Landa wrote:
>>> That's why GEOS has a C API.  Doesn't GRASS use that anyway?
>  
>> of course the GRASS modules are based C-API. Martin
> 
> That's what I thought - but I didn't have to build GRASS on Windows for a
> while.  Thanks ;)
> 
> 
> Jürgen
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2252: wxGUI vector digitizer passing unescaped text to database

[GRASS GIS]

#2252: wxGUI vector digitizer passing unescaped text to database
-+--
 Reporter:  marisn   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 It seems that it is not possible to enter attribute data for a new vector
 feature that is not valid SQL due to code being unable to pass user text
 to the database as text.

 Steps to reproduce:
  * Create a new vector data set;
  * Create a new text attribute column for it;
  * Digitize a new feature;
  * Provide following text as the attribute value: '; drop database
 important_data; '
  * Observe kaBOOM! as text is parsed by database instead of being properly
 escaped/passed as prepared statement to the DB.

 {{{
 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 near ";": syntax error

 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 near ";": syntax error

 KĻŪDA: Error while executing: 'INSERT INTO remove_me (cat,nosaukums)
  VALUES (3,''; drop database important_data; '')'
 }}}

 The issue will work also with more harmless examples like: It's fun

 For better effect enter value as: '); delete from MYVECTORMAP; select '

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1681: WXGUI vector editing fails with python unicode error

[GRASS GIS]

#1681: WXGUI vector editing fails with python unicode error
-+--
 Reporter:  marisn   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--
Changes (by marisn):

  * priority:  major => blocker


Comment:

 It is still an issue with current trunk. As it prevents users from
 creating new vector data sets, I'm setting this as a blocker. Unless GRASS
 7.0 ships without wxGUI, UnicodeEncodeError needs to be eliminated in it.

 Some reading for those, who have problems with strings in Python:
 http://blog.notdot.net/2010/07/Getting-unicode-right-in-Python

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Markus Neteler]

On 4/9/14, Yann Chemin  wrote:
> I used to start my GRASS GIS courses by saying to students that this is not
> going to work if you do not read the instructions.

Not sure about this.

Was just teaching GRASS GIS 7.0.0beta1 and it worked pretty well.
I would not 'threaten' them in the beginning.

The OS used were a mixture of Windows, Mac OSX and GNU/Linux.
Most saw GRASS for the first time.
Obviously I invited the to look at the manual pages.

Cheers
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1739: Language switch on wxGUI doesn't affect all strings

[GRASS GIS]

#1739: Language switch on wxGUI doesn't affect all strings
-+--
 Reporter:  MilenaN  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Python   | Version:  unspecified  
 Keywords:   |Platform:  All  
  Cpu:  x86-32   |  
-+--

Comment(by marisn):

 It should work just fine in GRASS 7 as long as specified language has its
 supporting locale installed. If language lacks matching locale in the
 system, I'm not certain if it can be solved at all. As GRASS 6 and 7
 startup scripts are different, it is not possible to backport changes. I
 would vote for testing in 7 and closing as wontfix for 6.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1856: wxGUI with LANG=pl_PL.utf8 throws "'ascii' codec can't decode byte"

[GRASS GIS]

#1856: wxGUI with LANG=pl_PL.utf8 throws "'ascii' codec can't decode byte"
--+-
 Reporter:  msieczka  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.4
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:  LANG, locale  |Platform:  Linux
  Cpu:  x86-64|  
--+-
Changes (by marisn):

  * milestone:  6.4.3 => 6.4.4


Comment:

 Is this still an issue?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #512: i18N Translation of welcome message in terminal not possible

[GRASS GIS]

#512: i18N Translation of welcome message in terminal not possible
---+
 Reporter:  neteler|   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.4
Component:  Translations   | Version:  svn-develbranch6 
 Keywords:  init.sh, init.bat  |Platform:  All  
  Cpu:  All|  
---+

Comment(by marisn):

 Starting from r41856 and r59163 whole GRASS 7 startup is i18n friendly. I
 would vote for closing this bug.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2210: unable to start GRASS GIS 7

[GRASS GIS]

#2210: unable to start GRASS GIS 7
-+--
  Reporter:  turek   |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  reopened 
  Priority:  normal  |   Milestone:  7.0.0
 Component:  Python  | Version:  svn-trunk
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  x86-64   
-+--

Comment(by marisn):

 Can you, please, test after r59652? I added some extra care to the cases
 when Python fails to detect default locale. Generally it indicates on some
 kind of problem with system's locale.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2120: wxgui: encoding errors

[GRASS GIS]

#2120: wxgui: encoding errors
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  locale encoding  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by marisn):

 Is this still an issue in GRASS 7? There has been a huge progress related
 to ironing out encoding issues in WXGUI.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Jürgen E . Fischer]

Hi Martin,

On Wed, 09. Apr 2014 at 11:52:34 +0200, Martin Landa wrote:
> > That's why GEOS has a C API.  Doesn't GRASS use that anyway?
 
> of course the GRASS modules are based C-API. Martin

That's what I thought - but I didn't have to build GRASS on Windows for a
while.  Thanks ;)


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
QGIS PSC member (RM)  Germany  IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #879: Add a "change language" option in GRASS GUI

[GRASS GIS]

#879: Add a "change language" option in GRASS GUI
---+
  Reporter:  antoniorocha  |   Owner:  lucadelu   
  Type:  enhancement   |  Status:  closed 
  Priority:  major |   Milestone:  7.0.0  
 Component:  Translations  | Version:  svn-releasebranch64
Resolution:  fixed |Keywords:  wxGUI, i18n
  Platform:  All   | Cpu:  All
---+
Changes (by marisn):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  6.4.4 => 7.0.0


Comment:

 Language switching is working in 7. As GRASS 6 should be feature frozen,
 moving milestone and closing as implemented. Issues with its
 implementation in GRASS 7 should be tracked in separate tickets.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Martin Landa]

Hi,

2014-04-09 8:35 GMT+02:00 Martin Landa :
> 2014-04-09 8:28 GMT+02:00 Markus Metz :
>
>> - wxGUI backport?
>
> will take a look...
>
> [...]
>
>> - v.buffer differs, but is broken in both branches. Only the
>> GEOS-enabled version in G7 works. Since this is a bugfix, I would
>> suggest to backport v.buffer from G7 to G6.
>
> agreed.

AFAIK we are close to release 6.4.4, so probably it would be better to
backport these changes after release to have time to test it for
6.4.5. Martin

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Martin Landa]

Hi,

2014-04-09 10:52 GMT+02:00 Benjamin Ducke :
> GEOS is a heavy C++ beast and difficult to compile using GCC
> on Windows (at least if you want the result to pass all
> validation tests).
>
> I would prefer to stick to C dependencies only for the core
> modules, if only to avoid DLL hell when mixing Visual C++
> and GCC DLLs on Windows (different name mangling styles).

please note that GEOS is included in OSGeo4W framework. So for G7 it's
compiled with GEOS by default. Martin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Martin Landa]

HI,

2014-04-09 11:44 GMT+02:00 Jürgen E. :

[...]

> That's why GEOS has a C API.  Doesn't GRASS use that anyway?

of course the GRASS modules are based C-API. Martin

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Jürgen E . Fischer]

Hi,

On Wed, 09. Apr 2014 at 10:52:59 +0200, Benjamin Ducke wrote:
> GEOS is a heavy C++ beast and difficult to compile using GCC
> on Windows (at least if you want the result to pass all
> validation tests).
> 
> I would prefer to stick to C dependencies only for the core
> modules, if only to avoid DLL hell when mixing Visual C++
> and GCC DLLs on Windows (different name mangling styles).

That's why GEOS has a C API.  Doesn't GRASS use that anyway?


Jürgen 

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
QGIS PSC member (RM)  Germany  IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Benjamin Ducke]

GEOS is a heavy C++ beast and difficult to compile using GCC
on Windows (at least if you want the result to pass all
validation tests).

I would prefer to stick to C dependencies only for the core
modules, if only to avoid DLL hell when mixing Visual C++
and GCC DLLs on Windows (different name mangling styles).

Ben

On 09/04/14 09:36, Moritz Lennert wrote:
> On 09/04/14 08:35, Martin Landa wrote:
>> Hi Markus,
>>
>> 2014-04-09 8:28 GMT+02:00 Markus Metz :
>>
>>> - wxGUI backport?
>>
>> will take a look...
>>
>> [...]
>>
>>> - v.buffer differs, but is broken in both branches. Only the
>>> GEOS-enabled version in G7 works. Since this is a bugfix, I would
>>> suggest to backport v.buffer from G7 to G6.
> 
> +1
> 
> If GEOS thus becomes a mandatory dependency, this will also
> automatically enable the additional operators in v.select which I think
> is a good thing.
> 
> Moritz
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Markus Metz]

On Wed, Apr 9, 2014 at 9:21 AM, Moritz Lennert
 wrote:
> On 09/04/14 03:17, Vaclav Petras wrote:
>>
>>
>> On Tue, Apr 8, 2014 at 9:09 PM, Glynn Clements > > wrote:
>>
>> If there's no Python installed, the installer can install it. If
>> Python is installed and the version is compatible, the installer can
>> install any required packages. Otherwise, it can at least inform the
>> user of the situation and enumerate the options.
>>
>>
>> This is a good point, the documentation must be in the installer, not a
>> separate file. For example Git installer for MS Windows list three
>> options how to install git and other command line tools with an
>> explanation. The problem is that only part of the users will read it and
>> only part of them will understand all the consequences (I mean, I was
>> not sure when I saw installing Git installation for the first time).
>
>
> I think part of this discussion boils down to the very old debate about how
> far we should go in taking the user's hand. Do we really want to compete
> with programs that "just do the work for you", thus having to think of every
> possible problem they might face, or do we decide that even though we can
> lower the entrance hurdle a bit, GRASS does demand some more involvement
> from the user than other software.

IMHO, that should be restricted to the actual usage of GRASS, not the
installation. IMHO, "just do the work for you" is fine during
installation, like e.g. apt-get install grass or yum install grass. On
Linux, these commands just do the work for you and take care of any
dependencies. One Windows problem is that there is no package manager
who takes the user's hand which is the reason for these large
standalone applications on MS Windows.

I do not suggest to change the behaviour of modules. All I suggest is
that both in the GUI and on the command line, be it msys or cmd.exe,
all GRASS commands work, even if the system-wide Python installation
is incompatible or missing.

>
> Personally, I am a bit afraid that by going down the first route we
> concentrate much developer time that could be spent on other (IMHO more
> useful) things and we also risk to make GRASS less efficient for those that
> have taken the time to pass the hurdle.

Changing the installer to take care of a system-wide Python
installation that also resolves conflicts is probably far more work
than to use the existing mechanism of GRASS6.

>
> In other words, there are some types of users (those that don't read
> anything provided by the developers) for whom I am sometimes tempted to just
> say "RTFM" instead of trying to find ways to make it possible for them to
> still use GRASS.

I think this is about installing GRASS, not using GRASS.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Yann Chemin]

 Agreeing with Moritz,

"In other words, there are some types of users (those that don't read
anything provided by the developers) for whom I am sometimes tempted to
just say "RTFM" instead of trying to find ways to make it possible for them
to still use GRASS"

I used to start my GRASS GIS courses by saying to students that this is not
going to work if you do not read the instructions. Invariably, those who
did not listen to that would come back frustrated 30 minutes later...

Cheers
Yann


On 9 April 2014 12:51, Moritz Lennert  wrote:

> On 09/04/14 03:17, Vaclav Petras wrote:
>
>>
>> On Tue, Apr 8, 2014 at 9:09 PM, Glynn Clements > > wrote:
>>
>> If there's no Python installed, the installer can install it. If
>> Python is installed and the version is compatible, the installer can
>> install any required packages. Otherwise, it can at least inform the
>> user of the situation and enumerate the options.
>>
>>
>> This is a good point, the documentation must be in the installer, not a
>> separate file. For example Git installer for MS Windows list three
>> options how to install git and other command line tools with an
>> explanation. The problem is that only part of the users will read it and
>> only part of them will understand all the consequences (I mean, I was
>> not sure when I saw installing Git installation for the first time).
>>
>
> I think part of this discussion boils down to the very old debate about
> how far we should go in taking the user's hand. Do we really want to
> compete with programs that "just do the work for you", thus having to think
> of every possible problem they might face, or do we decide that even though
> we can lower the entrance hurdle a bit, GRASS does demand some more
> involvement from the user than other software.
>
> Personally, I am a bit afraid that by going down the first route we
> concentrate much developer time that could be spent on other (IMHO more
> useful) things and we also risk to make GRASS less efficient for those that
> have taken the time to pass the hurdle.
>
> In other words, there are some types of users (those that don't read
> anything provided by the developers) for whom I am sometimes tempted to
> just say "RTFM" instead of trying to find ways to make it possible for them
> to still use GRASS.
>
> Moritz
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Moritz Lennert]

On 09/04/14 08:35, Martin Landa wrote:

Hi Markus,

2014-04-09 8:28 GMT+02:00 Markus Metz :


- wxGUI backport?


will take a look...

[...]


- v.buffer differs, but is broken in both branches. Only the
GEOS-enabled version in G7 works. Since this is a bugfix, I would
suggest to backport v.buffer from G7 to G6.


+1

If GEOS thus becomes a mandatory dependency, this will also 
automatically enable the additional operators in v.select which I think 
is a good thing.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Moritz Lennert]

On 09/04/14 08:16, Markus Metz wrote:

On Wed, Apr 9, 2014 at 3:44 AM, Glynn Clements  wrote:

[...]

In spite of wxGUI, GRASS remains fundamentally a collection of
command-line modules, more like a library than an application.


I make use of this property daily. On MS Windows, GRASS should by
default behave like a stand-alone application. You can make use of the
collection of command-line modules through the msys shell, but that is
really only for power users.


[...]


If I'm likely to perform the same operation more than once, I'm *much*
more likely to use the scripted approach than the pointy-clicky GUI.


As an experienced *NIX user, yes. Not so Windows users, many feel
alienated by a command line. On Windows, GRASS should behave like a
self-contained GUI application. There were even suggestions to remove
the command line interface completely from winGRASS because it
confuses users.



So, actually here the debate is about whether GRASS for Windows should 
be a different beast than GRASS for *nix/Mac. In my practical teaching 
experience I would strongly plead for having them as similar as 
possible. Learning on one platform should allow you to use GRASS on any 
platform.


And, in my experience, I've never seen users confused by the command 
line in Windows. They might ignore it, it might scare them a bit, but 
I've never seen it cause any problems. On the contrary, I've always 
found that with a little gentle introduction, students very quickly see 
the advantage of the command line over the GUI.



IMHO, what you say is that GRASS and MS Windows are incompatible by
principle,


Not at all. Windows does actually have a command-execution mechanism
(even the Mac has one nowadays).


Any installed Python interpreter does not know about any other
packages relying on it. The Python interpreter can change any time
(version, architecture), or disappear, without other packages knowing
about it, then there is a problem. Windows applications are by nature
stand-alone applications, they don't know about each other's
existence.


In what ways is this different from *nix ? GRASS has no knowledge or 
control over the Python interpreter. It's up to the user to install the 
correct interpreter and make sure that GRASS can find it. Luckily this 
is often taken care of by distribution packaging, but it's still 
independent of GRASS.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Moritz Lennert]

On 09/04/14 03:17, Vaclav Petras wrote:


On Tue, Apr 8, 2014 at 9:09 PM, Glynn Clements mailto:gl...@gclements.plus.com>> wrote:

If there's no Python installed, the installer can install it. If
Python is installed and the version is compatible, the installer can
install any required packages. Otherwise, it can at least inform the
user of the situation and enumerate the options.


This is a good point, the documentation must be in the installer, not a
separate file. For example Git installer for MS Windows list three
options how to install git and other command line tools with an
explanation. The problem is that only part of the users will read it and
only part of them will understand all the consequences (I mean, I was
not sure when I saw installing Git installation for the first time).


I think part of this discussion boils down to the very old debate about 
how far we should go in taking the user's hand. Do we really want to 
compete with programs that "just do the work for you", thus having to 
think of every possible problem they might face, or do we decide that 
even though we can lower the entrance hurdle a bit, GRASS does demand 
some more involvement from the user than other software.


Personally, I am a bit afraid that by going down the first route we 
concentrate much developer time that could be spent on other (IMHO more 
useful) things and we also risk to make GRASS less efficient for those 
that have taken the time to pass the hurdle.


In other words, there are some types of users (those that don't read 
anything provided by the developers) for whom I am sometimes tempted to 
just say "RTFM" instead of trying to find ways to make it possible for 
them to still use GRASS.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev