[GRASS-dev] XDRIVER

Roger_Miller1 · April 13, 2011, 6:11pm

Devs,

I'm aware that XDRIVER is antiquated piece of software that the project does not intend to use for it's primary display or interactive tool. I have two main questions (and maybe some to follow up):

Does the project intend to retain XDRIVER in the distribution?

Are there any plans to update or upgrade XDRIVER?

As a bit of background, I use a Tcl/TK GUI for GRASS that I have been developing incrementally since roughly 1997, so not only is the GUI fairly well-developed but I'm pretty accustomed to it and I intend to keep it. The GUI uses XDRIVER as it's primary display and interactive tool and ps.map for high quality output.

I recently started developing a module that would let me interactively construct map annotations using points, lines, arrows, rectangles, polylines, polygons and text. When I started constructing the text capability I found that R_get_text_box() produced grossly incorrect results. That compounded the problem with low quality of the screen fonts -- even using FreeType2.

I remedied the problem by adding libXft to XDRIVER. That gave me high-quality, antialiased, client-side fonts and replaced all of the font-handling and rendering capabilities currently in GRASS. And it enormously simplified the code. And R_get_text_box() produces the right result.

Adding Xft changed the behavior of some text and font modules: label placement in d.vect is great, but d.font didn't work and d.paint.labels references labels incorrectly. There are probably other changes that I'll find later.

The effort it takes for me to maintain these changes could mean that I am stuck with my current GRASS version unless I rebuild all of the necessary changes into every future update. That could become a large effort, particularly if I go on to add keyboard interaction and a few other changes that I'm contemplating. Fortunately, GRASS has become pretty stable, so I don't have immediate problems. The alternative is that -- if there are enough other users interested -- the project could incorporate some of the changes in their code base. Is there enough interest to justify that?

Roger Miller

martinl · April 13, 2011, 6:28pm

Hi,

2011/4/13 <roger@spinn.net>:

I'm aware that XDRIVER is antiquated piece of software that the project does
not intend to use for it's primary display or interactive tool. I have two
main questions (and maybe some to follow up):
Does the project intend to retain XDRIVER in the distribution?
Are there any plans to update or upgrade XDRIVER?

No, XDRIVER has been removed from trunk (GRASS 7) some months ago. In
other words GRASS 7 drops Xmonitors and all related d.* modules
(d.zoom, d.pan, etc).

As a bit of background, I use a Tcl/TK GUI for GRASS that I have been
developing incrementally since roughly 1997, so not only is the GUI fairly
well-developed but I'm pretty accustomed to it and I intend to keep it. The
GUI uses XDRIVER as it's primary display and interactive tool and ps.map for
high quality output.

You mean `d.m` I guess. In GRASS 7 TCL/TK GUI has been also dropped.
There is only new wxGUI available. There are no plans to recover
TCL/TK GUI development, AFAIK.

I recently started developing a module that would let me interactively
construct map annotations using points, lines, arrows, rectangles,
polylines, polygons and text. When I started constructing the text
capability I found that R_get_text_box() produced grossly incorrect results.
That compounded the problem with low quality of the screen fonts -- even
using FreeType2.
I remedied the problem by adding libXft to XDRIVER. That gave me
high-quality, antialiased, client-side fonts and replaced all of the
font-handling and rendering capabilities currently in GRASS. And it
enormously simplified the code. And R_get_text_box() produces the right
result.
Adding Xft changed the behavior of some text and font modules: label
placement in d.vect is great, but d.font didn't work and d.paint.labels
references labels incorrectly. There are probably other changes that I'll
find later.

I am not expert here, so I am leaving comments to others. Anyway,
display architecture in GRASS 7 is primary based on Cairo library. New
development goes in that direction.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Roger_Miller1 · April 13, 2011, 7:21pm

FWIW, my GUI is not gis.m, nor is it related in any way to any other GRASS GUIs, current or historical. It is an original product. As you might guess, explaining the need for and the development of a separate GUI could become a long story.

How long will the project continue to support 6.* versions?

Roger

Martin Landa writes:

Hi,

2011/4/13 <roger@spinn.net>:

I'm aware that XDRIVER is antiquated piece of software that the project does
not intend to use for it's primary display or interactive tool. I have two
main questions (and maybe some to follow up):
Does the project intend to retain XDRIVER in the distribution?
Are there any plans to update or upgrade XDRIVER?

No, XDRIVER has been removed from trunk (GRASS 7) some months ago. In
other words GRASS 7 drops Xmonitors and all related d.* modules
(d.zoom, d.pan, etc).

As a bit of background, I use a Tcl/TK GUI for GRASS that I have been
developing incrementally since roughly 1997, so not only is the GUI fairly
well-developed but I'm pretty accustomed to it and I intend to keep it. The
GUI uses XDRIVER as it's primary display and interactive tool and ps.map for
high quality output.

You mean `d.m` I guess. In GRASS 7 TCL/TK GUI has been also dropped.
There is only new wxGUI available. There are no plans to recover
TCL/TK GUI development, AFAIK.

I recently started developing a module that would let me interactively
construct map annotations using points, lines, arrows, rectangles,
polylines, polygons and text. When I started constructing the text
capability I found that R_get_text_box() produced grossly incorrect results.
That compounded the problem with low quality of the screen fonts -- even
using FreeType2.
I remedied the problem by adding libXft to XDRIVER. That gave me
high-quality, antialiased, client-side fonts and replaced all of the
font-handling and rendering capabilities currently in GRASS. And it
enormously simplified the code. And R_get_text_box() produces the right
result.
Adding Xft changed the behavior of some text and font modules: label
placement in d.vect is great, but d.font didn't work and d.paint.labels
references labels incorrectly. There are probably other changes that I'll
find later.

I am not expert here, so I am leaving comments to others. Anyway,
display architecture in GRASS 7 is primary based on Cairo library. New
development goes in that direction.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

neteler · April 13, 2011, 9:08pm

On Wed, Apr 13, 2011 at 9:21 PM, <roger@spinn.net> wrote:
...

How long will the project continue to support 6.* versions?

For >>1 years for sure. I am sometimes even still backporting to
GRASS 6.3 (released April 2008) ...

Markus

Glynn_Clements1 · April 13, 2011, 9:10pm

roger@spinn.net wrote:

I'm aware that XDRIVER is antiquated piece of software that the project does
not intend to use for it's primary display or interactive tool. I have two
main questions (and maybe some to follow up):

Does the project intend to retain XDRIVER in the distribution?

Are there any plans to update or upgrade XDRIVER?

No. Monitors (display drivers as separate processes) have been removed
entirely (and permanently) from 7.0.

There doesn't seem to be much point in making significant changes in
6.x, given that it's a dead end. Also, monitors (all monitors, not
just XDRIVER) don't work on Windows.

I'm not sure what problems you were having with R_get_text_box(), but
if we can identify a bug, that should be fixed.

--
Glynn Clements <glynn@gclements.plus.com>

Roger_Miller1 · April 13, 2011, 9:55pm

Regarding R_get_text_box(), in all of my tests the width of the text box was wrong.

Also, main.c in d.text.new (6.4.0RC5) contains the comment

    /* TODO: get text dimension */
    /* R_get_text_box() does not work with rotation and returns a little bit
     * bigger dimension than actual text size */

I don't know the vintage of that comment. The problem isn't consistent; neither d.vect nor d.labels seems to have the same problem, so it was likely to be some detail of my implementation that I was never able to find and fix.

Roger

Glynn Clements writes:

roger@spinn.net wrote:

I'm aware that XDRIVER is antiquated piece of software that the project does not intend to use for it's primary display or interactive tool. I have two main questions (and maybe some to follow up):

Does the project intend to retain XDRIVER in the distribution?

Are there any plans to update or upgrade XDRIVER?

No. Monitors (display drivers as separate processes) have been removed
entirely (and permanently) from 7.0.

There doesn't seem to be much point in making significant changes in
6.x, given that it's a dead end. Also, monitors (all monitors, not
just XDRIVER) don't work on Windows.

I'm not sure what problems you were having with R_get_text_box(), but
if we can identify a bug, that should be fixed.

--
Glynn Clements <glynn@gclements.plus.com>

Roger_Miller1 · April 13, 2011, 11:50pm

Thanks, Markus. I appreciate that.

It looks like I will have three choices; stay with 6.4/6.5 and use a
dead-end system, move to 7.0 and a GUI that I don't want to use, or go
to a different GIS. I have 32Gbytes of data in GRASS, so the third
choice might be a hard path to take.

At least I'll have plenty of time to make my decision.

Roger

On Wed, 2011-04-13 at 23:08 +0200, Markus Neteler wrote:

On Wed, Apr 13, 2011 at 9:21 PM, <roger@spinn.net> wrote:
...
> How long will the project continue to support 6.* versions?

For >>1 years for sure. I am sometimes even still backporting to
GRASS 6.3 (released April 2008) ...

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

neteler · April 14, 2011, 8:43am

On Thu, Apr 14, 2011 at 1:50 AM, Roger Miller <roger@spinn.net> wrote:

Thanks, Markus. I appreciate that.

It looks like I will have three choices; stay with 6.4/6.5 and use a
dead-end system, move to 7.0 and a GUI that I don't want to use, or go
to a different GIS. I have 32Gbytes of data in GRASS, so the third
choice might be a hard path to take.

We would certainly appreciate if you stay with us
And for sure needed bugfixes should be done.

Markus

At least I'll have plenty of time to make my decision.

Roger

mlennert · April 14, 2011, 9:21am

On 14/04/11 01:50, Roger Miller wrote:

Thanks, Markus. I appreciate that.

It looks like I will have three choices; stay with 6.4/6.5 and use a
dead-end system, move to 7.0 and a GUI that I don't want to use,

Maybe you could tell us why the new GUI is so unacceptable and what type of GUI would suit your needs ? Not in terms of every detail you have tweaked in your own GUI, but more in terms of principles.

Moritz

Roger_Miller1 · April 14, 2011, 1:16pm

Moritz,

I initially learned GRASS through the GUI that was current at the time,
which was much more primitive than the GUI you have now. I quit using
the GUI soon after when I realized that it was faster and just as easy
to use the command line, that using the GUI required as much knowlege as
using the command line and that the command line offered help more
quickly and more easily than the GUI.

Obviously your GUI has grown since that time and the current version is
much more capable and evolved than the one I initially used. I tried
familiarizing myself with each upgraded version of the GUI but generally
found them difficult to learn. All of them, including the current form,
seemed to share the same basic design. As a result, I'm not intimately
familiar with the current GUI. I also have no reason to become familiar
with it.

I built my GUI gradually over a number of years and developed two basic
concepts for it's design. I also built it from the point of view of a
capable command-line user.

First is that the GUI should be organized and visually simple, not
confusing to the eye and it should offer only a few choices at any time.
If you're already accustomed to looking at your GUI -- I'm not -- then
you probably won't get confused by it's visual presentation.

To that end, my GUI is also a one-button GUI wherever possible. I
haven't changed things like the Tk digitizer, so that still uses three
buttons. I found that restricting myself to using one mouse button made
me think through the process more completely and organize it more
carefully.

Second is that no capability should be added to the GUI unless it can be
made simpler and/or faster than the command line operation. In the
sequence of development some things were obvious early choices for
inclusion in the GUI. It is very difficult to build and manipulate
complicated map displays from the command line, so simplifying that
process was the first purpose of the GUI. The last major addition to
the GUI was mapcalc, which is quite easy to use from a command line, so
I had a hard time inventing a graphical interface that was more
useful.

There are still capabilities I haven't added and some that I will
probably never add. I have yet to find a way of setting raster color
rules that is simpler or faster than the command line. There are many
modules that I don't plan on adding because I have no use for them.
Were I to add some of the more specialized modules they would probably
go into the background somewhere so that I would never see them unless I
asked to see them.

Roger

On Thu, 2011-04-14 at 11:21 +0200, Moritz Lennert wrote:

On 14/04/11 01:50, Roger Miller wrote:
> Thanks, Markus. I appreciate that.
>
> It looks like I will have three choices; stay with 6.4/6.5 and use a
> dead-end system, move to 7.0 and a GUI that I don't want to use,

Maybe you could tell us why the new GUI is so unacceptable and what type
of GUI would suit your needs ? Not in terms of every detail you have
tweaked in your own GUI, but more in terms of principles.

Moritz

mlennert · April 14, 2011, 4:29pm

Roger,

Thank you for the detailed explanation. I can imagine that such a long-grown home made GUI gives you a productivity which will be very difficult to reproduce quickly with any other tool.

Some tentative comments to your explanations:

On 14/04/11 15:16, Roger Miller wrote:

First is that the GUI should be organized and visually simple, not
confusing to the eye and it should offer only a few choices at any time.
If you're already accustomed to looking at your GUI -- I'm not -- then
you probably won't get confused by it's visual presentation.

Yes, this is obviously very subjective.

Second is that no capability should be added to the GUI unless it can be
made simpler and/or faster than the command line operation.

In a certain way this is the same philosophy as with the mainstream GRASS GUI: most of the GUI is just an automatically created "graphical wrapper" around the command line. Only those tools that make sense only in a graphical environment are implement directly in the GUI. The rule has (almost) always been: everything you can do in the GUI, you should be able to do in the command line, unless this doesn't make any sense. The only (in the current development trunk aka GRASS 7) exception is the display system, which you cannot really interact with from the command line, but it is foreseen to change this.

You might be able to salvage a part of your GUI by using the direct rendering option [1] of the d.* commands to render into an image that you can then display within your Tcl GUI. Also, see ximgview/wximageview [2].

[1] http://grass.osgeo.org/grass70/manuals/html70_user/cairodriver.html ("GRASS_RENDER_IMMEDIATE")
[2] http://trac.osgeo.org/grass/browser/grass/trunk/visualization

Moritz