[GRASS-dev] TOC in the manual

2014-04-11 Thread Martin Landa
Hi all,

in r59673 I introduced simple mechanism to add TOC to the manual pages. It needs
some testing, anyway it seems to work. TOC is now fixed and width of
body part is 80%, see eg. [1]. Since wxPython widget doesn't support
most of css, it's shown before DESCRIPTION and not as fixed.

Martin

[1] http://grass.osgeo.org/grass71/manuals/v.build.html

-- 
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] TOC in the manual

2014-04-11 Thread Margherita Di Leo
Hi Martin,


On Fri, Apr 11, 2014 at 10:38 AM, Martin Landa landa.mar...@gmail.comwrote:

 Hi all,

 in r59673 I introduced simple mechanism to add TOC to the manual pages. It
 needs
 some testing, anyway it seems to work. TOC is now fixed and width of
 body part is 80%, see eg. [1]. Since wxPython widget doesn't support
 most of css, it's shown before DESCRIPTION and not as fixed.


Thank you! Looks very fancy!

Talking about documentation, since GRASS has strong ties with academia,
what do you think about adding also a section cite as for the relevant
modules?

Thank you,
Madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] TOC in the manual

2014-04-11 Thread Martin Landa
Hi,

2014-04-11 10:44 GMT+02:00 Margherita Di Leo dileomargher...@gmail.com:
 Talking about documentation, since GRASS has strong ties with academia, what
 do you think about adding also a section cite as for the relevant modules?

why not, it could generated automatically by mkhtml.py. Martin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] TOC in the manual

2014-04-11 Thread Martin Landa
Hi,

2014-04-11 10:38 GMT+02:00 Martin Landa landa.mar...@gmail.com:

 body part is 80%, see eg. [1]. Since wxPython widget doesn't support
 most of css, it's shown before DESCRIPTION and not as fixed.

the question is whether to hide manual tab and just to provide button
which opens manual in the web browser. 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] Handling of Python scripts on MS Windows

2014-04-11 Thread Jürgen E . Fischer
Hi Helmut,

On Thu, 10. Apr 2014 at 14:34:04 -0700, Helmut Kudrnovsky wrote:
 although the architecture may differ, we may get some inspiration for python
 windows handling from other GIS projects like QGIS? 
 
 in QGIS python is also in heavy use, e.g. QGIS processing framework, python
 addons, integrated python shell, etc. AFAIK they're bundling python in their
 standalone winQGIS ...

Not sure if I want to participate in this thread.

I think a system installation of python is uncommon.  You'd have to deal with a
variety of possibilities (python.org, ESRI, ...), you would need to make sure
all extensions you need are available for each of them - and have them play
nice with the rest of your install.

Shipping you own python with all the extensions you need, probably saves a lot
of headaches and lifetime.   That's the approach OSGeo4W (and in turn QGIS)
takes.  I wouldn't require a system wide python install or try to use an
existing one.

You could establish (or modify a pre-existing) file association to python files
that is tied to an environment variable.   And thereby make the association use
GRASS' python within GRASS and the system-wide installation otherwise.  And
thereby avoid having special treatment for .py scripts in GRASS itself (see
http://stackoverflow.com/questions/5583024/temporary-file-association-for-single-cmd-exe-session)

That way you could use the stock sources and wouldn't have to use patches when
packaging (which would have been my pragmatic approach to solve the issue at
hand without risking that someone pulls a Glynn on it ;)).


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] TOC in the manual

2014-04-11 Thread Yann Chemin
Did not have an opinion fixed, so went back to work, opened a module,
pressed on the manual tab and did have to wait a bit because of
rendering... If it was to open in a default web browser, I could have
continued looking around the module.

+1 for button to external browser


On 11 April 2014 14:33, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2014-04-11 10:38 GMT+02:00 Martin Landa landa.mar...@gmail.com:

  body part is 80%, see eg. [1]. Since wxPython widget doesn't support
  most of css, it's shown before DESCRIPTION and not as fixed.

 the question is whether to hide manual tab and just to provide button
 which opens manual in the web browser. 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




-- 

___
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

2014-04-11 Thread Martin Landa
Hi Jurgen,

2014-04-11 12:42 GMT+02:00 Jürgen E. j...@norbit.de:

 although the architecture may differ, we may get some inspiration for python
 windows handling from other GIS projects like QGIS?

 in QGIS python is also in heavy use, e.g. QGIS processing framework, python
 addons, integrated python shell, etc. AFAIK they're bundling python in their
 standalone winQGIS ...

 Not sure if I want to participate in this thread.

you are probably not alone...

 I think a system installation of python is uncommon.  You'd have to deal with 
 a
 variety of possibilities (python.org, ESRI, ...), you would need to make sure
 all extensions you need are available for each of them - and have them play
 nice with the rest of your install.

 Shipping you own python with all the extensions you need, probably saves a lot
 of headaches and lifetime.   That's the approach OSGeo4W (and in turn QGIS)
 takes.  I wouldn't require a system wide python install or try to use an
 existing one.

if you take a look on all threads related to this topic in grass-dev
ML you will count more that 150 messages, but without real consensus.
I completely agree with you. To avoid bundled Python it would require
a lot of work, we simply do not have such man-power, resources or
fundings. All projects around us shifts their own Python for Windows,
and of course beasts like Esri installs their Python system-wide, they
simply don't care. We are in different situation, happily. So if we
want to move forward (and to release GRASS 7) we would be simply
forced to stick with the current solution (forcing Python script which
are launched within GRASS environment to use Python version provided
by the installer or by OSGeo4W framework). Or we need someone who will
invest his/her energy to implement something better, it will take
probably take not days, but weeks.
Then we will probably first project who will avoid bundled Python on
Windows, cool ;-) Just discussing this topic forever is not a solution
or real problems.

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


Re: [GRASS-dev] relbr6 - devbr6 differences

2014-04-11 Thread Benjamin Ducke
And that's why I love this mailing list:
There are insights here that are simply
impossible to get elsewhere. Thanks for
this one, Glynn!

Ben

On 09/04/14 17:18, Glynn Clements wrote:
 
 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.
 



-- 
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] Handling of Python scripts on MS Windows

2014-04-11 Thread Glynn Clements

Helmut Kudrnovsky wrote:

 although the architecture may differ, we may get some inspiration for python
 windows handling from other GIS projects like QGIS? 
 
 in QGIS python is also in heavy use, e.g. QGIS processing framework, python
 addons, integrated python shell, etc. AFAIK they're bundling python in their
 standalone winQGIS ...

QGIS is a monolithic application. GRASS is a set of command-line
programs (plus an optional GUI front-end).

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


Re: [GRASS-dev] TOC in the manual

2014-04-11 Thread Anna Petrášová
Note, that on Windows and on Ubuntu with wxPython 3, the manual page in the
tab is loaded immediately. I believe we should keep the manual in the tab,
I think people are more likely to look at the manual there than pressing
Help button. Personally I try to avoid pressing Help button in any
application, it usually takes a lot of time to start browser and load it.
WxPython 3 has some new widget for websites so eventually, it could replace
the widget we use now.

Anna




On Fri, Apr 11, 2014 at 6:49 AM, Yann Chemin yche...@gmail.com wrote:

 Did not have an opinion fixed, so went back to work, opened a module,
 pressed on the manual tab and did have to wait a bit because of
 rendering... If it was to open in a default web browser, I could have
 continued looking around the module.

 +1 for button to external browser


 On 11 April 2014 14:33, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2014-04-11 10:38 GMT+02:00 Martin Landa landa.mar...@gmail.com:

  body part is 80%, see eg. [1]. Since wxPython widget doesn't support
  most of css, it's shown before DESCRIPTION and not as fixed.

 the question is whether to hide manual tab and just to provide button
 which opens manual in the web browser. 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




 --
 

 ___
 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] TOC in the manual

2014-04-11 Thread Yann Chemin
+1


On 12 April 2014 03:57, Anna Petrášová kratocha...@gmail.com wrote:

 Note, that on Windows and on Ubuntu with wxPython 3, the manual page in
 the tab is loaded immediately. I believe we should keep the manual in the
 tab, I think people are more likely to look at the manual there than
 pressing Help button. Personally I try to avoid pressing Help button in any
 application, it usually takes a lot of time to start browser and load it.
 WxPython 3 has some new widget for websites so eventually, it could replace
 the widget we use now.

 Anna





 On Fri, Apr 11, 2014 at 6:49 AM, Yann Chemin yche...@gmail.com wrote:

 Did not have an opinion fixed, so went back to work, opened a module,
 pressed on the manual tab and did have to wait a bit because of
 rendering... If it was to open in a default web browser, I could have
 continued looking around the module.

 +1 for button to external browser


 On 11 April 2014 14:33, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2014-04-11 10:38 GMT+02:00 Martin Landa landa.mar...@gmail.com:

  body part is 80%, see eg. [1]. Since wxPython widget doesn't support
  most of css, it's shown before DESCRIPTION and not as fixed.

 the question is whether to hide manual tab and just to provide button
 which opens manual in the web browser. 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




 --
 

 ___
 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