Hello,
Would it be possible to create a kind of Wizard to assist
download/install of extensions with GEM?
1-locate GEM enabled extensions (http://wiki…)
2-Download in ~/tmp
3-run gem on it
Yann
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.
It would be a cool thing to have, I agree.
Ben
Yann wrote:
Hello,
Would it be possible to create a kind of Wizard to assist
download/install of extensions with GEM?1-locate GEM enabled extensions (http://wiki…)
2-Download in ~/tmp
3-run gem on itYann
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Thanks Ben,
Is there anybody that knows abit a tcltk that could add info about where it
should go coding wise?
Yann
On Monday 21 May 2007 14:31, Benjamin Ducke wrote:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.It would be a cool thing to have, I agree.
Ben
Yann wrote:
> Hello,
>
> Would it be possible to create a kind of Wizard to assist
> download/install of extensions with GEM?
>
> 1-locate GEM enabled extensions (http://wiki…)
> 2-Download in ~/tmp
> 3-run gem on it
>
> Yann
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
--
Yann Chemin
Sainte-Anne d'Auray, France
Ben,
is GEM installing "Xtns" in wxPython GUI?
Yann
On Monday 21 May 2007 14:31, Benjamin Ducke wrote:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.It would be a cool thing to have, I agree.
Ben
Yann wrote:
> Hello,
>
> Would it be possible to create a kind of Wizard to assist
> download/install of extensions with GEM?
>
> 1-locate GEM enabled extensions (http://wiki…)
> 2-Download in ~/tmp
> 3-run gem on it
>
> Yann
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
--
Yann Chemin
Sainte-Anne d'Auray, France
No, I don't have a version of GRASS that support wxPython and the new
GUI, yet. Just never had the time to get that new stuff running.
I am waiting for the wxPython stuff to stabilize and reach beta level,
before I put lots of time into doing this. Right now, it's hard for me
to judge where the new GUI is headed and what would be the best way to
integrate GEM-generated menus ...
Yann wrote:
Ben,
is GEM installing "Xtns" in wxPython GUI?
Yann
On Monday 21 May 2007 14:31, Benjamin Ducke wrote:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.It would be a cool thing to have, I agree.
Ben
Yann wrote:
Hello,
Would it be possible to create a kind of Wizard to assist
download/install of extensions with GEM?1-locate GEM enabled extensions (http://wiki…)
2-Download in ~/tmp
3-run gem on itYann
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Hi,
I'm not following GEM development and thus have two silly questions:
1) isn't possible to install additional modules via GEM into user's
home directory (as option)? Thus it could be made as easy as
installing some addons to Firefox.
2) if getting superuser support for GUI right is lot of work, could
some GUI wizard just generate some commandline expression that could
be just pasted into terminal by user as last step to run it via su or
sudo?
Just my 0.02.
Maris.
2007/5/21, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.It would be a cool thing to have, I agree.
Ben
Yann wrote:
> Hello,
>
> Would it be possible to create a kind of Wizard to assist
> download/install of extensions with GEM?
>
> 1-locate GEM enabled extensions (http://wiki…)
> 2-Download in ~/tmp
> 3-run gem on it
>
> Yann
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
GermanyTel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
A last question:
Which Extensions are GEM "certified" so far and where can we download them?
thanks
Yann
On Monday 21 May 2007 17:36, Benjamin Ducke wrote:
No, I don't have a version of GRASS that support wxPython and the new
GUI, yet. Just never had the time to get that new stuff running.
I am waiting for the wxPython stuff to stabilize and reach beta level,
before I put lots of time into doing this. Right now, it's hard for me
to judge where the new GUI is headed and what would be the best way to
integrate GEM-generated menus ...Yann wrote:
> Ben,
>
> is GEM installing "Xtns" in wxPython GUI?
>
> Yann
>
> On Monday 21 May 2007 14:31, Benjamin Ducke wrote:
>> I guess it wouldn't be too much trouble. GEM already has all that's
>> needed for this: zipped extension packages can be downloaded (using
>> wget), unzipped (to system's temp dir) and installed automatically.
>> There is just one catch: since all files are installed into system-wide
>> locations, the wizard will probably need superuser rights. So a tcl/tk
>> based install wizard needs to provide a way to get the superuser
>> password and run system commands with elevated rights.
>>
>> It would be a cool thing to have, I agree.
>>
>> Ben
>>
>> Yann wrote:
>>> Hello,
>>>
>>> Would it be possible to create a kind of Wizard to assist
>>> download/install of extensions with GEM?
>>>
>>> 1-locate GEM enabled extensions (http://wiki…)
>>> 2-Download in ~/tmp
>>> 3-run gem on it
>>>
>>> Yann
>>>
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev@grass.itc.it
>>> http://grass.itc.it/mailman/listinfo/grass-dev
--
Yann Chemin
Sainte-Anne d'Auray, France
As far as I am aware, there are only a few extensions that I have
created that actually make use of GEM, so far (sniff).
Most importantly, spatial predictive modelling (which includes a generic
Dempster-Shafer Theory framework for evidence-based modelling with
raster data) and some advanced viewshed modelling with cumulative
viewshed analysis. The newest version of GEM is already included in the
GRASS 6.3 CVS and the executable is called "gem6".
Everything can be downloaded here:
http://www.uni-kiel.de/ufg/ufg_BerDucke.htm (bottom of page).
However, I am currently hard at work migrating the code to Win32, doing
a lot of bugfixing, etc. which is all made more complicated by a number
of issues that currently exist in the Win32 version of GRASS (argh!).
So I cannot currently support these versions of my extensions, due to a
lack of time. As soon as the Win32 stuff has been smoothed out, I will
substantially update my code base, documentation etc.!
There is also a pretty flexible territorial modelling tools in the pipeline.
Best,
Benjamin
Yann wrote:
A last question:
Which Extensions are GEM "certified" so far and where can we download them?
thanks
YannOn Monday 21 May 2007 17:36, Benjamin Ducke wrote:
No, I don't have a version of GRASS that support wxPython and the new
GUI, yet. Just never had the time to get that new stuff running.
I am waiting for the wxPython stuff to stabilize and reach beta level,
before I put lots of time into doing this. Right now, it's hard for me
to judge where the new GUI is headed and what would be the best way to
integrate GEM-generated menus ...Yann wrote:
Ben,
is GEM installing "Xtns" in wxPython GUI?
Yann
On Monday 21 May 2007 14:31, Benjamin Ducke wrote:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.It would be a cool thing to have, I agree.
Ben
Yann wrote:
Hello,
Would it be possible to create a kind of Wizard to assist
download/install of extensions with GEM?1-locate GEM enabled extensions (http://wiki…)
2-Download in ~/tmp
3-run gem on itYann
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
These modeling tools seem interesting!
thanks Ben, I'll try to check that out.
Yann
On Monday 21 May 2007 18:24, Benjamin Ducke wrote:
As far as I am aware, there are only a few extensions that I have
created that actually make use of GEM, so far (sniff).
Most importantly, spatial predictive modelling (which includes a generic
Dempster-Shafer Theory framework for evidence-based modelling with
raster data) and some advanced viewshed modelling with cumulative
viewshed analysis. The newest version of GEM is already included in the
GRASS 6.3 CVS and the executable is called "gem6".Everything can be downloaded here:
http://www.uni-kiel.de/ufg/ufg_BerDucke.htm (bottom of page).However, I am currently hard at work migrating the code to Win32, doing
a lot of bugfixing, etc. which is all made more complicated by a number
of issues that currently exist in the Win32 version of GRASS (argh!).
So I cannot currently support these versions of my extensions, due to a
lack of time. As soon as the Win32 stuff has been smoothed out, I will
substantially update my code base, documentation etc.!There is also a pretty flexible territorial modelling tools in the
pipeline.Best,
Benjamin
Yann wrote:
> A last question:
>
> Which Extensions are GEM "certified" so far and where can we download
> them?
>
> thanks
> Yann
>
> On Monday 21 May 2007 17:36, Benjamin Ducke wrote:
>> No, I don't have a version of GRASS that support wxPython and the new
>> GUI, yet. Just never had the time to get that new stuff running.
>> I am waiting for the wxPython stuff to stabilize and reach beta level,
>> before I put lots of time into doing this. Right now, it's hard for me
>> to judge where the new GUI is headed and what would be the best way to
>> integrate GEM-generated menus ...
>>
>> Yann wrote:
>>> Ben,
>>>
>>> is GEM installing "Xtns" in wxPython GUI?
>>>
>>> Yann
>>>
>>> On Monday 21 May 2007 14:31, Benjamin Ducke wrote:
>>>> I guess it wouldn't be too much trouble. GEM already has all that's
>>>> needed for this: zipped extension packages can be downloaded (using
>>>> wget), unzipped (to system's temp dir) and installed automatically.
>>>> There is just one catch: since all files are installed into
>>>> system-wide locations, the wizard will probably need superuser rights.
>>>> So a tcl/tk based install wizard needs to provide a way to get the
>>>> superuser password and run system commands with elevated rights.
>>>>
>>>> It would be a cool thing to have, I agree.
>>>>
>>>> Ben
>>>>
>>>> Yann wrote:
>>>>> Hello,
>>>>>
>>>>> Would it be possible to create a kind of Wizard to assist
>>>>> download/install of extensions with GEM?
>>>>>
>>>>> 1-locate GEM enabled extensions (http://wiki…)
>>>>> 2-Download in ~/tmp
>>>>> 3-run gem on it
>>>>>
>>>>> Yann
>>>>>
>>>>> _______________________________________________
>>>>> grass-dev mailing list
>>>>> grass-dev@grass.itc.it
>>>>> http://grass.itc.it/mailman/listinfo/grass-dev
--
Yann Chemin
Sainte-Anne d'Auray, France
On 21/05/07 13:24, Benjamin Ducke wrote:
However, I am currently hard at work migrating the code to Win32, doing
a lot of bugfixing, etc. which is all made more complicated by a number
of issues that currently exist in the Win32 version of GRASS (argh!).
So I cannot currently support these versions of my extensions, due to a
lack of time. As soon as the Win32 stuff has been smoothed out, I will
substantially update my code base, documentation etc.!
Could you keep those of us working on the win port informed about your problems and your advances ? Just so that we coordinate efforts a bit.
Thanks,
Moritz
Sure,
just got back from the Windows PC lab with some new testing results.
Will post a more verbose mail in a moment ...
Benjamin
Moritz Lennert wrote:
On 21/05/07 13:24, Benjamin Ducke wrote:
However, I am currently hard at work migrating the code to Win32, doing
a lot of bugfixing, etc. which is all made more complicated by a number
of issues that currently exist in the Win32 version of GRASS (argh!).
So I cannot currently support these versions of my extensions, due to a
lack of time. As soon as the Win32 stuff has been smoothed out, I will
substantially update my code base, documentation etc.!Could you keep those of us working on the win port informed about your
problems and your advances ? Just so that we coordinate efforts a bit.Thanks,
Moritz
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
I've been meaning to ask about this root/external mod issue - is there any plan to support installation of GEM modules in a user dir? More than just a problem of HOW to run this as root in the GUI, it's also a bit of a security problem and a platform standardization issue.
On OSX, installing extras into an application binary is not the way things are done. They should be installed in a standard plugin/extension location for the application - /Library so it is globally available to users, or ~/Library to make it available only for a single user.
These locations act as extra GIS_BASEs, in effect - they have bin, lib, etc, doc... subfolders. By use of standard GRASS env vars, they are easily included into the GRASS environment, and I recently added similar env vars and functions to locate external etc/ support files for modules that need it.
For the OSX application build I've set [~]/Library/GRASS/$version/Modules as the global/user locations. For now I have a separate module build template, much like GEM, but built modules must then be manually copied to one of these locations, since I'm too lazy to figure out alternate install targets in the makefiles.
It would be nice to have GEM able to install in these locations at least, if not also arbitrary locations. We would need to figure out good standard locations for other platforms also.
On May 21, 2007, at 5:53 AM, Maris Nartiss wrote:
Hi,
I'm not following GEM development and thus have two silly questions:
1) isn't possible to install additional modules via GEM into user's
home directory (as option)? Thus it could be made as easy as
installing some addons to Firefox.
2) if getting superuser support for GUI right is lot of work, could
some GUI wizard just generate some commandline expression that could
be just pasted into terminal by user as last step to run it via su or
sudo?Just my 0.02.
Maris.2007/5/21, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."
- Hitchhiker's Guide to the Galaxy
Hi,
imho something like GRASS_ADDONS (so GRASS_GEM) path would solve this.
And it is IMHO another reason for $HOME/.grass/ configuration directory
Jachym
William Kyngesburye píše v Po 21. 05. 2007 v 15:27 -0500:
I've been meaning to ask about this root/external mod issue - is
there any plan to support installation of GEM modules in a user dir?
More than just a problem of HOW to run this as root in the GUI, it's
also a bit of a security problem and a platform standardization issue.On OSX, installing extras into an application binary is not the way
things are done. They should be installed in a standard plugin/
extension location for the application - /Library so it is globally
available to users, or ~/Library to make it available only for a
single user.These locations act as extra GIS_BASEs, in effect - they have bin,
lib, etc, doc... subfolders. By use of standard GRASS env vars, they
are easily included into the GRASS environment, and I recently added
similar env vars and functions to locate external etc/ support files
for modules that need it.For the OSX application build I've set [~]/Library/GRASS/$version/
Modules as the global/user locations. For now I have a separate
module build template, much like GEM, but built modules must then be
manually copied to one of these locations, since I'm too lazy to
figure out alternate install targets in the makefiles.It would be nice to have GEM able to install in these locations at
least, if not also arbitrary locations. We would need to figure out
good standard locations for other platforms also.On May 21, 2007, at 5:53 AM, Maris Nartiss wrote:
> Hi,
>
> I'm not following GEM development and thus have two silly questions:
> 1) isn't possible to install additional modules via GEM into user's
> home directory (as option)? Thus it could be made as easy as
> installing some addons to Firefox.
> 2) if getting superuser support for GUI right is lot of work, could
> some GUI wizard just generate some commandline expression that could
> be just pasted into terminal by user as last step to run it via su or
> sudo?
>
> Just my 0.02.
> Maris.
>
>
> 2007/5/21, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:
>> I guess it wouldn't be too much trouble. GEM already has all that's
>> needed for this: zipped extension packages can be downloaded (using
>> wget), unzipped (to system's temp dir) and installed automatically.
>> There is just one catch: since all files are installed into system-
>> wide
>> locations, the wizard will probably need superuser rights. So a
>> tcl/tk
>> based install wizard needs to provide a way to get the superuser
>> password and run system commands with elevated rights.-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/"History is an illusion caused by the passage of time, and time is an
illusion caused by the passage of history."- Hitchhiker's Guide to the Galaxy
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Jachym Cepicky
e-mail: jachym.cepicky@gmail.com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
On May 21, 2007, at 4:08 PM, Jachym Cepicky wrote:
Hi,
imho something like GRASS_ADDONS (so GRASS_GEM) path would solve this.
Right now, my etc/ find uses GRASS_ADDON_ETC. It might be nice to consolidate the various env vars. Assuming that they all always coincide with the same root.
And it is IMHO another reason for $HOME/.grass/ configuration directory
Jachym
William Kyngesburye píše v Po 21. 05. 2007 v 15:27 -0500:
I've been meaning to ask about this root/external mod issue - is
there any plan to support installation of GEM modules in a user dir?
More than just a problem of HOW to run this as root in the GUI, it's
also a bit of a security problem and a platform standardization issue.On OSX, installing extras into an application binary is not the way
things are done. They should be installed in a standard plugin/
extension location for the application - /Library so it is globally
available to users, or ~/Library to make it available only for a
single user.These locations act as extra GIS_BASEs, in effect - they have bin,
lib, etc, doc... subfolders. By use of standard GRASS env vars, they
are easily included into the GRASS environment, and I recently added
similar env vars and functions to locate external etc/ support files
for modules that need it.For the OSX application build I've set [~]/Library/GRASS/$version/
Modules as the global/user locations. For now I have a separate
module build template, much like GEM, but built modules must then be
manually copied to one of these locations, since I'm too lazy to
figure out alternate install targets in the makefiles.It would be nice to have GEM able to install in these locations at
least, if not also arbitrary locations. We would need to figure out
good standard locations for other platforms also.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
Actually, it's not much of a problem to introduce a new default and/or
optional install prefix in GEM. The real trouble lies in two different
areas, as far as I can think of right now:
1. The HTML man pages for the newly installed modules should be
integrated into main HTML index. Currently, GEM manipulates the main
HTML index in the install dir to do so. Of course, this requires
superuser rights. The ideal solution would be to have a placeholder in
the global HTML frontpage that will point to a subindex page present in
the user's local extension directory. No idea how to do that in HTML
2. Many people like to have new GUI menu entries in gis.m when they
install additional modules. This means that gis.m has to be prepared to
look for additional menu entries in the current user's extension
directory. This should not be too hard to do.
In principle, I agree that it would be much better to have locally
installed extension. This could simplify the logics behing GEM a lot,
too. It would also be possible to keep both the global and local
installation schemes side-by-side, as a system-wide extension management
would probably also have its merits.
Benjamin
William Kyngesburye wrote:
I've been meaning to ask about this root/external mod issue - is there
any plan to support installation of GEM modules in a user dir? More
than just a problem of HOW to run this as root in the GUI, it's also a
bit of a security problem and a platform standardization issue.On OSX, installing extras into an application binary is not the way
things are done. They should be installed in a standard
plugin/extension location for the application - /Library so it is
globally available to users, or ~/Library to make it available only for
a single user.These locations act as extra GIS_BASEs, in effect - they have bin, lib,
etc, doc... subfolders. By use of standard GRASS env vars, they are
easily included into the GRASS environment, and I recently added similar
env vars and functions to locate external etc/ support files for modules
that need it.For the OSX application build I've set
[~]/Library/GRASS/$version/Modules as the global/user locations. For
now I have a separate module build template, much like GEM, but built
modules must then be manually copied to one of these locations, since
I'm too lazy to figure out alternate install targets in the makefiles.It would be nice to have GEM able to install in these locations at
least, if not also arbitrary locations. We would need to figure out
good standard locations for other platforms also.On May 21, 2007, at 5:53 AM, Maris Nartiss wrote:
Hi,
I'm not following GEM development and thus have two silly questions:
1) isn't possible to install additional modules via GEM into user's
home directory (as option)? Thus it could be made as easy as
installing some addons to Firefox.
2) if getting superuser support for GUI right is lot of work, could
some GUI wizard just generate some commandline expression that could
be just pasted into terminal by user as last step to run it via su or
sudo?Just my 0.02.
Maris.2007/5/21, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/"History is an illusion caused by the passage of time, and time is an
illusion caused by the passage of history."- Hitchhiker's Guide to the Galaxy
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
You might want to take a look at what I did in the OSX app build - macosx/app/build_html_user_index.sh and build_gui_user_menu.sh. Both are run at startup. They could easily be made to work for all platforms. The nice thing about these is that less configuration needs to be done at install time, since they are dynamic.
On May 22, 2007, at 2:01 AM, Benjamin Ducke wrote:
Actually, it's not much of a problem to introduce a new default and/or
optional install prefix in GEM. The real trouble lies in two different
areas, as far as I can think of right now:1. The HTML man pages for the newly installed modules should be
integrated into main HTML index. Currently, GEM manipulates the main
HTML index in the install dir to do so. Of course, this requires
superuser rights. The ideal solution would be to have a placeholder in
the global HTML frontpage that will point to a subindex page present in
the user's local extension directory. No idea how to do that in HTML
The user html index is separate from the main index. The GUI would have to have a dynamic menu item for it so that it would have the full path to the user's home. I initially tried ~ in the <a href> and strangely it worked, but it turned out to be a Safari-only thing. The global addon index is easy eanough, since it would not change with the logged-in user.
I still need to work on g.manual and the non-GUI command dialogs (ie when run without params) - they don't see the user help files yet.
I don't think Michael has a user help menu item in the GUI yet, but the help index is still available in OSX since I have also integrated it with the system help mechanism.
2. Many people like to have new GUI menu entries in gis.m when they
install additional modules. This means that gis.m has to be prepared to
look for additional menu entries in the current user's extension
directory. This should not be too hard to do.
The script creates GEM-like menu files for the user commands. For scripts I simply test for the #% Module tag, and for compiled modules I use 'file' to check for binary executables (I assume a binary in these locations is made for GRASS).
I mentioned this to Michael, but he hasn't worked it into the TclTk GUI yet (I don't know any TclTk to try this). It should be just as simple to do for the Python GUI.
In principle, I agree that it would be much better to have locally
installed extension. This could simplify the logics behing GEM a lot,
too. It would also be possible to keep both the global and local
installation schemes side-by-side, as a system-wide extension management
would probably also have its merits.
Just to make sure we're on the same wavelength, when I say 'global', I mean a system location still external to the installed GRASS application. Global just means all users can access it.
In effect, it's just like having in the installed GRASS, but on OSX at least it's really preferable to have a separate global addon location. I don't know what that would be in Windows, but on Linux it might be something like /usr/local/share.
So, that would be 3 install location choices: application, global and user.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
All generalizations are dangerous, even this one.
On 5/22/07 12:01 AM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de>
wrote:
Actually, it's not much of a problem to introduce a new default and/or
optional install prefix in GEM. The real trouble lies in two different
areas, as far as I can think of right now:1. The HTML man pages for the newly installed modules should be
integrated into main HTML index. Currently, GEM manipulates the main
HTML index in the install dir to do so. Of course, this requires
superuser rights. The ideal solution would be to have a placeholder in
the global HTML frontpage that will point to a subindex page present in
the user's local extension directory. No idea how to do that in HTML2. Many people like to have new GUI menu entries in gis.m when they
install additional modules. This means that gis.m has to be prepared to
look for additional menu entries in the current user's extension
directory. This should not be too hard to do.In principle, I agree that it would be much better to have locally
installed extension. This could simplify the logics behing GEM a lot,
too. It would also be possible to keep both the global and local
installation schemes side-by-side, as a system-wide extension management
would probably also have its merits.Benjamin
Why not try to solve these issues one at a time. Having a simple way to
create, install, and manage extensions would be a real plus and could
stimulate use of the GEM system. IMHO, we should focus on getting this right
and worry about the help files and menus a bit later.
To make life easier, why not simply keep the html help files with the
extensions and have all extensions, by default, look for help files in the
default extensions directory? Also, people can manually look at help files
if they are in an easily accessible directory. A bit of an inconvenience,
but users will be installing extensions of their choice and will have some
idea of what they want.
I'm a big fan of GUI's and having commands listed on a menu so you don't
have to remember them. BUT, getting extensions listed on the existing GUI
menu system is a pain. To get the rest of the system in general operation,
maybe just skip this. Since any extension will be installed by a user, who
presumably will know what she/he installed, calling one or two from the
command line won't be that much of a burden.
We can then think about better ways to get extensions into the menu. The
menu system is being rethought anyway with the switch to wxPython, so we
could design it with the possibility of extensions in mind if they become
widely used and the details of how and where to install them get ironed out.
For example, the menu could simply have an empty place holder for
extensions. A menu-building function could then scan the default extensions
directory to see if a menu file exists and use it to fill in the
place-holder.
Michael
William Kyngesburye wrote:
I've been meaning to ask about this root/external mod issue - is there
any plan to support installation of GEM modules in a user dir? More
than just a problem of HOW to run this as root in the GUI, it's also a
bit of a security problem and a platform standardization issue.On OSX, installing extras into an application binary is not the way
things are done. They should be installed in a standard
plugin/extension location for the application - /Library so it is
globally available to users, or ~/Library to make it available only for
a single user.These locations act as extra GIS_BASEs, in effect - they have bin, lib,
etc, doc... subfolders. By use of standard GRASS env vars, they are
easily included into the GRASS environment, and I recently added similar
env vars and functions to locate external etc/ support files for modules
that need it.For the OSX application build I've set
[~]/Library/GRASS/$version/Modules as the global/user locations. For
now I have a separate module build template, much like GEM, but built
modules must then be manually copied to one of these locations, since
I'm too lazy to figure out alternate install targets in the makefiles.It would be nice to have GEM able to install in these locations at
least, if not also arbitrary locations. We would need to figure out
good standard locations for other platforms also.On May 21, 2007, at 5:53 AM, Maris Nartiss wrote:
Hi,
I'm not following GEM development and thus have two silly questions:
1) isn't possible to install additional modules via GEM into user's
home directory (as option)? Thus it could be made as easy as
installing some addons to Firefox.
2) if getting superuser support for GUI right is lot of work, could
some GUI wizard just generate some commandline expression that could
be just pasted into terminal by user as last step to run it via su or
sudo?Just my 0.02.
Maris.2007/5/21, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/"History is an illusion caused by the passage of time, and time is an
illusion caused by the passage of history."- Hitchhiker's Guide to the Galaxy
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Since my time to work on GEM is very limited at the moment (basically none):
As far as menu entries are concerned, I'd opt for doing from the ground
up with the new wxPython GUI and just leave it the way it is for gis.m.
The ideal solution would be a directory-based inclusion mechanism: if a
directory exists in a certain place, then it will be scanned for menu
entries to add to the extensions menu.
HTML pages: with a built-in HTML Python widget, we could easily solve
the issue of global vs. local indices. For now, I'd just skip the HTML
installation and let users locate the manpages themselves.
Now, the only remaining question is where to store all extension files
(by default). We need a directory that work cross-platform (or at least
a unified way to figure out a user home directory on all supported
platforms; possible as a new function in the C API).
Michael Barton wrote:
On 5/22/07 12:01 AM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de>
wrote:Actually, it's not much of a problem to introduce a new default and/or
optional install prefix in GEM. The real trouble lies in two different
areas, as far as I can think of right now:1. The HTML man pages for the newly installed modules should be
integrated into main HTML index. Currently, GEM manipulates the main
HTML index in the install dir to do so. Of course, this requires
superuser rights. The ideal solution would be to have a placeholder in
the global HTML frontpage that will point to a subindex page present in
the user's local extension directory. No idea how to do that in HTML2. Many people like to have new GUI menu entries in gis.m when they
install additional modules. This means that gis.m has to be prepared to
look for additional menu entries in the current user's extension
directory. This should not be too hard to do.In principle, I agree that it would be much better to have locally
installed extension. This could simplify the logics behing GEM a lot,
too. It would also be possible to keep both the global and local
installation schemes side-by-side, as a system-wide extension management
would probably also have its merits.Benjamin
Why not try to solve these issues one at a time. Having a simple way to
create, install, and manage extensions would be a real plus and could
stimulate use of the GEM system. IMHO, we should focus on getting this right
and worry about the help files and menus a bit later.To make life easier, why not simply keep the html help files with the
extensions and have all extensions, by default, look for help files in the
default extensions directory? Also, people can manually look at help files
if they are in an easily accessible directory. A bit of an inconvenience,
but users will be installing extensions of their choice and will have some
idea of what they want.I'm a big fan of GUI's and having commands listed on a menu so you don't
have to remember them. BUT, getting extensions listed on the existing GUI
menu system is a pain. To get the rest of the system in general operation,
maybe just skip this. Since any extension will be installed by a user, who
presumably will know what she/he installed, calling one or two from the
command line won't be that much of a burden.We can then think about better ways to get extensions into the menu. The
menu system is being rethought anyway with the switch to wxPython, so we
could design it with the possibility of extensions in mind if they become
widely used and the details of how and where to install them get ironed out.
For example, the menu could simply have an empty place holder for
extensions. A menu-building function could then scan the default extensions
directory to see if a menu file exists and use it to fill in the
place-holder.Michael
William Kyngesburye wrote:
I've been meaning to ask about this root/external mod issue - is there
any plan to support installation of GEM modules in a user dir? More
than just a problem of HOW to run this as root in the GUI, it's also a
bit of a security problem and a platform standardization issue.On OSX, installing extras into an application binary is not the way
things are done. They should be installed in a standard
plugin/extension location for the application - /Library so it is
globally available to users, or ~/Library to make it available only for
a single user.These locations act as extra GIS_BASEs, in effect - they have bin, lib,
etc, doc... subfolders. By use of standard GRASS env vars, they are
easily included into the GRASS environment, and I recently added similar
env vars and functions to locate external etc/ support files for modules
that need it.For the OSX application build I've set
[~]/Library/GRASS/$version/Modules as the global/user locations. For
now I have a separate module build template, much like GEM, but built
modules must then be manually copied to one of these locations, since
I'm too lazy to figure out alternate install targets in the makefiles.It would be nice to have GEM able to install in these locations at
least, if not also arbitrary locations. We would need to figure out
good standard locations for other platforms also.On May 21, 2007, at 5:53 AM, Maris Nartiss wrote:
Hi,
I'm not following GEM development and thus have two silly questions:
1) isn't possible to install additional modules via GEM into user's
home directory (as option)? Thus it could be made as easy as
installing some addons to Firefox.
2) if getting superuser support for GUI right is lot of work, could
some GUI wizard just generate some commandline expression that could
be just pasted into terminal by user as last step to run it via su or
sudo?Just my 0.02.
Maris.2007/5/21, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:
I guess it wouldn't be too much trouble. GEM already has all that's
needed for this: zipped extension packages can be downloaded (using
wget), unzipped (to system's temp dir) and installed automatically.
There is just one catch: since all files are installed into system-wide
locations, the wizard will probably need superuser rights. So a tcl/tk
based install wizard needs to provide a way to get the superuser
password and run system commands with elevated rights.-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/"History is an illusion caused by the passage of time, and time is an
illusion caused by the passage of history."- Hitchhiker's Guide to the Galaxy
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
+1
On Tuesday 22 May 2007 21:46, Michael Barton wrote:
A menu-building function could then scan the default extensions
directory to see if a menu file exists and use it to fill in the
place-holder.
--
Yann Chemin
Sainte-Anne d'Auray, France
On May 22, 2007, at 10:13 AM, Benjamin Ducke wrote:
Now, the only remaining question is where to store all extension files
(by default). We need a directory that work cross-platform (or at least
a unified way to figure out a user home directory on all supported
platforms; possible as a new function in the C API).
I'd prefer something that is appropriate for the platform. ie the /Library/GRASS and ~/Library/GRASS I'm using for the OSX app build.
The simple way to solve the choice is to use env vars, like the rest of GRASS. That way the mechanism is there and the user or packager can decide what is appropriate, and the user can add to it at runtime if needed. (I set some user dirs in the OSX app startup script, before init.sh is run, to handle this)
Note - there is a libgis function to get a user's home: G_home(). It should work on all platforms (it has a mingw special case, but maybe it doesn't work on the Win native build?). It would be handy to have a command equivalent to use in scripts, like g.home.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?
-HitchHiker's Guide to the Galaxy