If anyone out there who is not working on the other code is feeling energetic and/or has a bit of time on their hands, we could use having the wxPython menu updated to match all the commands and structure now in the TclTk one.
We could also use an artistic type for icon design. I already need a couple that don’t yet exist (for overlay layers and map display decorations).
Michael
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
If anyone out there who is not working on the other code is feeling
energetic and/or has a bit of time on their hands, we could use having
the wxPython menu updated to match all the commands and structure now
in the TclTk one.
On 3/29/07, Hamish <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
>
> If anyone out there who is not working on the other code is feeling
> energetic and/or has a bit of time on their hands, we could use having
> the wxPython menu updated to match all the commands and structure now
> in the TclTk one.
could a script do it?
For the most part, I think so. But in the tcl version (and also in the
python counterpart) there are some commands embedded in the
definitions. Those must be hand-tuned to each back-end.
I suggest porting the menu structure to JSON (in preference of XML)
with special markers for these actions, and use the same source for
building both tcl and python guis. That would also allow for
different menu combinations switchable at run-time depending on user
preferences. (AFAICT wxGRASS does present a different interface
according to the "user level" in which it is started.)
I could do the python part, but I'm practically illiterate in tcl.
automation is good.
Absolutely. Just as duplication is bad... in code anyway.
what about moving the GUI to XML ? this would make it possible to use
one file in many tools..
j
2007/3/30, Daniel Calvelo <dca.gis@gmail.com>:
On 3/29/07, Hamish <hamish_nospam@yahoo.com> wrote:
> Michael Barton wrote:
> >
> > If anyone out there who is not working on the other code is feeling
> > energetic and/or has a bit of time on their hands, we could use having
> > the wxPython menu updated to match all the commands and structure now
> > in the TclTk one.
>
> could a script do it?
For the most part, I think so. But in the tcl version (and also in the
python counterpart) there are some commands embedded in the
definitions. Those must be hand-tuned to each back-end.
I suggest porting the menu structure to JSON (in preference of XML)
with special markers for these actions, and use the same source for
building both tcl and python guis. That would also allow for
different menu combinations switchable at run-time depending on user
preferences. (AFAICT wxGRASS does present a different interface
according to the "user level" in which it is started.)
I could do the python part, but I'm practically illiterate in tcl.
> automation is good.
Absolutely. Just as duplication is bad... in code anyway.
what about moving the GUI to XML ? this would make it possible to use
one file in many tools..
sorry, not the "GUI", but "menus" or all common conf. parts in general
j
j
2007/3/30, Daniel Calvelo <dca.gis@gmail.com>:
> On 3/29/07, Hamish <hamish_nospam@yahoo.com> wrote:
> > Michael Barton wrote:
> > >
> > > If anyone out there who is not working on the other code is feeling
> > > energetic and/or has a bit of time on their hands, we could use having
> > > the wxPython menu updated to match all the commands and structure now
> > > in the TclTk one.
> >
> > could a script do it?
>
> For the most part, I think so. But in the tcl version (and also in the
> python counterpart) there are some commands embedded in the
> definitions. Those must be hand-tuned to each back-end.
>
> I suggest porting the menu structure to JSON (in preference of XML)
> with special markers for these actions, and use the same source for
> building both tcl and python guis. That would also allow for
> different menu combinations switchable at run-time depending on user
> preferences. (AFAICT wxGRASS does present a different interface
> according to the "user level" in which it is started.)
>
> I could do the python part, but I'm practically illiterate in tcl.
>
> > automation is good.
>
> Absolutely. Just as duplication is bad... in code anyway.
>
> Daniel.
>
> --
> -- Daniel Calvelo Aros
>
> _______________________________________________
> grassgui mailing list
> grassgui@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassgui
>
what about moving the GUI to XML ? this would make it possible to use
one file in many tools..
sorry, not the "GUI", but "menus" or all common conf. parts in general
j
j
2007/3/30, Daniel Calvelo <dca.gis@gmail.com>:
On 3/29/07, Hamish <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
If anyone out there who is not working on the other code is feeling
energetic and/or has a bit of time on their hands, we could use having
the wxPython menu updated to match all the commands and structure now
in the TclTk one.
could a script do it?
For the most part, I think so. But in the tcl version (and also in the
python counterpart) there are some commands embedded in the
definitions. Those must be hand-tuned to each back-end.
I suggest porting the menu structure to JSON (in preference of XML)
with special markers for these actions, and use the same source for
building both tcl and python guis. That would also allow for
different menu combinations switchable at run-time depending on user
preferences. (AFAICT wxGRASS does present a different interface
according to the "user level" in which it is started.)
I could do the python part, but I'm practically illiterate in tcl.
automation is good.
Absolutely. Just as duplication is bad... in code anyway.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
maybe we could just reuse the "python" syntax: use simple textfile
with indentation
j
2007/3/30, Michael Barton <michael.barton@asu.edu>:
Probably a good idea. But I don't know how to parse this in TclTk--and don't
know it that well in wxPython either.
Michael
On 3/30/07 2:30 AM, "Jachym Cepicky" <jachym.cepicky@gmail.com> wrote:
> 2007/3/30, Jachym Cepicky <jachym.cepicky@gmail.com>:
>> what about moving the GUI to XML ? this would make it possible to use
>> one file in many tools..
>
> sorry, not the "GUI", but "menus" or all common conf. parts in general
>
> j
>>
>> j
>>
>> 2007/3/30, Daniel Calvelo <dca.gis@gmail.com>:
>>> On 3/29/07, Hamish <hamish_nospam@yahoo.com> wrote:
>>>> Michael Barton wrote:
>>>>>
>>>>> If anyone out there who is not working on the other code is feeling
>>>>> energetic and/or has a bit of time on their hands, we could use having
>>>>> the wxPython menu updated to match all the commands and structure now
>>>>> in the TclTk one.
>>>>
>>>> could a script do it?
>>>
>>> For the most part, I think so. But in the tcl version (and also in the
>>> python counterpart) there are some commands embedded in the
>>> definitions. Those must be hand-tuned to each back-end.
>>>
>>> I suggest porting the menu structure to JSON (in preference of XML)
>>> with special markers for these actions, and use the same source for
>>> building both tcl and python guis. That would also allow for
>>> different menu combinations switchable at run-time depending on user
>>> preferences. (AFAICT wxGRASS does present a different interface
>>> according to the "user level" in which it is started.)
>>>
>>> I could do the python part, but I'm practically illiterate in tcl.
>>>
>>>> automation is good.
>>>
>>> Absolutely. Just as duplication is bad... in code anyway.
>>>
>>> Daniel.
>>>
>>> --
>>> -- Daniel Calvelo Aros
>>>
>>> _______________________________________________
>>> grassgui mailing list
>>> grassgui@grass.itc.it
>>> http://grass.itc.it/mailman/listinfo/grassgui
>>>
>>
>> --
>> Jachym Cepicky
>> e-mail: jachym.cepicky gmail com
>> URL: http://les-ejk.cz
>> GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
>>
>
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I'm hoping that the TclTk menus will remain reasonably stable now. It's not
hard to make a manual tweak now and then if necessary.
The best thing for the long run would be work work with the keyword section
of the interface description that Markus set up and arrange the keys so that
they could build a menu automatically. Then we wouldn't have to manually
maintain the hundreds of commands.
Michael
On 3/30/07 8:15 AM, "Jachym Cepicky" <jachym.cepicky@gmail.com> wrote:
In python this is no big problem.
I have no clue about tcl..
maybe we could just reuse the "python" syntax: use simple textfile
with indentation
j
2007/3/30, Michael Barton <michael.barton@asu.edu>:
Probably a good idea. But I don't know how to parse this in TclTk--and don't
know it that well in wxPython either.
Michael
On 3/30/07 2:30 AM, "Jachym Cepicky" <jachym.cepicky@gmail.com> wrote:
what about moving the GUI to XML ? this would make it possible to use
one file in many tools..
sorry, not the "GUI", but "menus" or all common conf. parts in general
j
j
2007/3/30, Daniel Calvelo <dca.gis@gmail.com>:
On 3/29/07, Hamish <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
If anyone out there who is not working on the other code is feeling
energetic and/or has a bit of time on their hands, we could use having
the wxPython menu updated to match all the commands and structure now
in the TclTk one.
could a script do it?
For the most part, I think so. But in the tcl version (and also in the
python counterpart) there are some commands embedded in the
definitions. Those must be hand-tuned to each back-end.
I suggest porting the menu structure to JSON (in preference of XML)
with special markers for these actions, and use the same source for
building both tcl and python guis. That would also allow for
different menu combinations switchable at run-time depending on user
preferences. (AFAICT wxGRASS does present a different interface
according to the "user level" in which it is started.)
I could do the python part, but I'm practically illiterate in tcl.
automation is good.
Absolutely. Just as duplication is bad... in code anyway.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
The best thing for the long run would be work work with the keyword
section of the interface description that Markus set up and arrange
the keys so that they could build a menu automatically. Then we
wouldn't have to manually maintain the hundreds of commands.
Keywords can help self-organize a new menu tree, but ultimately the
final cut will have to be crafted by hand.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I can help with the TclTk part. But I need to know what to do.
I am not familiar with JSON.
Michael
On 3/30/07 2:25 AM, "Daniel Calvelo" <dca.gis@gmail.com> wrote:
On 3/29/07, Hamish <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
If anyone out there who is not working on the other code is feeling
energetic and/or has a bit of time on their hands, we could use having
the wxPython menu updated to match all the commands and structure now
in the TclTk one.
could a script do it?
For the most part, I think so. But in the tcl version (and also in the
python counterpart) there are some commands embedded in the
definitions. Those must be hand-tuned to each back-end.
I suggest porting the menu structure to JSON (in preference of XML)
with special markers for these actions, and use the same source for
building both tcl and python guis. That would also allow for
different menu combinations switchable at run-time depending on user
preferences. (AFAICT wxGRASS does present a different interface
according to the "user level" in which it is started.)
I could do the python part, but I'm practically illiterate in tcl.
automation is good.
Absolutely. Just as duplication is bad... in code anyway.
Daniel.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I got the impression from the website that he might be willing to design
additional icons if needed (might be even more motivating if the project and
potential user base is big ;-).
robert
These are nice. They cover some of the potential needs, though I'm not sure
if they do all of them.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University