Content-Type: text/plain; format=flowed; charset=US-ASCII
(a) I assume other X windows apps work remotely in the same config?
(b) what happens if you run something funky on the Linux bug,
like the
glgears demo? Something that uses an accelerated window?
On Saturday, June 25, 2005, at 03:01 PM, Sean Fulton wrote:
I'm trying to run uDig remotely over ssh. uDig is running on a
linux
box. The X11 display is on a Mac OS X 10.4 machine.
I get the uDig start window which closes soon after opening. The
output is below
[sfulton@bob]: ./udig
action.remove: 'elcl16/remove_co.gif' found action.remove
action.remove: 'dlcl16/remove_co.gif' found action.remove
The program 'uDig' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 3277 error_code 3 request_code 38 minor_code 0)
(Note to programmers: normally, X errors are reported
asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error()
function.)
Any suggestions?
Thanks,
Sean
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Paul Ramsey
Refractions Research
Email: pramsey@xxxxxxxxxxxxxxx
Phone: (250) 885-0632
------------------------------
Message: 5
Date: Sun, 26 Jun 2005 00:33:52 -0700
From: Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>
Subject: [udig-devel] Scope of GeoWidgets (was gui module to
geowidgets?)
To: Chris Holmes <cholmes@xxxxxxxxxxxxx>
Cc: User-friendly Desktop Internet GIS
<udig-devel@xxxxxxxxxxxxxxxxxxxxx>, Matthias Basler
<Matthias.Basler@xxxxxxxxxxx>, geotools-devel
<geotools-devel@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <42BE5A60.8010601@xxxxxxxxxxxxxxx>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Chris Holmes wrote:
Ok, I may be off here on the intentions of geowidgets, but I'm
wondering
if we could consider moving the 'gui' module from geotools to
geowidgets. You know the one that few of us use, that we get a
bunch
of questions about why it's not in some releases (because it's in
legacy or migrate because no developers really support it). I
think it
could generate more interest for geowidgets, and would give us a
more
contained place to point people looking for gui type functionality.
There is really two things going on here. Rendering (and the
model of
Map/Layer(Data+Style) that rendering is based on. And widget
such as SWT
Container, Swing Panel or OpenGL Canvas (or GeoAPI Canvas
abstraction of
the same).
I could totally see the rendering system being broken out (and
made to
opperate against interfaces). It is more then pure view, it is pure
visualization.
The gui widget part is a bit more fun. We start to have events and
threading issues and in general it is a bit more complicated. In the
origional emails Mattias was looking to follow up his excelent
contribution to uDig (of a CRS chooser) with something a bit more
generic and reusable in SWT and Swing (and possibly even Spring/
STRUTS).
I had in mind GeoWidgets defining the a series of Models for
things like
CRS and then providing a widget that can be used to "edit" or
"choose"
the content. SLD makes for an interesting example.
Now these models are pretty *small*, the data is already defined by
geotools, the model simple adds information such as the current
"selection" and other book keeping values to to keep track of the
view
state. Any such model would have events (something that helps
when the
geotools data objects don't have a proper event system).
Here is a perfect example:
http://svn.geotools.org/udig/trunk/plugins/
net.refractions.udig.style.sld/src/net/refractions/udig/style/
sld/ simple/StrokeViewer.java
Stroke viewer "edits" a SLD Stroke.
It has a model:
boolean enabled = false;
Color color = null;
double width = Double.NaN;
double opacity = Double.NaN;
And a view:
Button on;
StolenColorEditor chooser;
Combo size;
Combo percent;
And a controler is contained in a sync() method.
I would assume the widgets project would result in three jars:
- geowidgets-model.jar
- geowidgets-swing.jar
- geowidgets-swt.jar
The idea being that any opperation code that is shared between
geoserver, udig, geovista and IanS's netbeans project can offer up
geowidget models as a way for the hosting application to control
their
state.
This was however only my understanding, the recent questions about
Map/Layer and so on point in a different direction - towards the
establishment of a neutral canvas for rendering content.
There three paths forward on the model side of things:
- GeoAPI Canvas/Graphic - not full evaulated
- uDig Map/Viewport/Layer/StyleBlackboard - flexable, offers ideal
separation, not quite what people expect
- GeoTools Map/MapLayer/Style
And three proposed targets for widgets: Java2D, SWT, OpenGL - on the
rendering side they can all be hidden behind one interface
(indeed we
render to both Java2D and SWT for udig.
Swing and SWT have a similar construct for an event thread, all it
really amounts to is that any system better be based on commands. Ie
Tools produce commands that effect the model. Of more concern is
worker
thread behavior and when/how they are allowed to update the
model. Once
again these are often best formulated as a command which the
controller
can execute in the appropriate thread.
The hard part is keeping the models as pure data (aka they
should not do
work).
Perhaps it's not the intent of geowidgets to handle the same
type of
things, but I like the idea of having geotools split up a bit
more, so
that for example people wanting to hack on the gui stuff don't
have to
build main every time. Thoughts?
GeoAPI
- specifications (such as SLD, Feature, Filter)
GeoTools
- data objects (such as SLD, Feature, Filter)
- visualization (such as renderers, Canvas)
GeoWidgets
- model (wraps data w/ events)
- controler (allows modification of model via commands)
- widgets (swt,swing,opengl)
- canvas (such as Java2D, Draw2D, OpenGL raster)
UDig
- Formal breakdown into plugins, tools, keyboard shortcuts
I know the existing gui classes had various tools defined as a
series of
callbacks for their "canvas". I would much rather see those things
defined as proper commands con the canvas controler, and leave the
registration and tool selection as an application specific concern.
Basically I know geotools did not want to be an application, I
want to
confirm that GeoWidgets does not want to be an application.
Also, Matthias - I'm sure we can find you some tools to support
your
project, if you're willing to commit to it and take a decent
lead. SVN
at refractions, confluence and jira at codehaus, downloads at
sourceforge (well, you can get sf on your own).
It is still a tricky problem :-) the data/model split.
We should also ask James what he wants to do?
As an example of the difficulty consider DataStore, it defines a
nice
data model for feature access. It also defines an event model for
driving user interfaces (and redraws).
However it took two years before the first person (Jesse) hooked
up the the event system and changed the bugs out.
Currently the SLD implementation (named Style) completly lacks event
notification.
So james, how would you like us to proceed? Should we add event
notification to the geotools classes? I know for example that
this is
one of the reasons we subclass DataStores so much in udig (so we can
figure out when the connection is broken and provide user interface
notification).
Jody
------------------------------
Message: 6
Date: Sun, 26 Jun 2005 19:57:41 +1100
From: Martin Desruisseaux <martin.desruisseaux@xxxxxxxxxxxxx>
Subject: [udig-devel] Re: [Geotools-devel] Scope of GeoWidgets (was
gui module to geowidgets?)
To: Chris Holmes <cholmes@xxxxxxxxxxxxx>
Cc: User-friendly Desktop Internet GIS
<udig-devel@xxxxxxxxxxxxxxxxxxxxx>, Matthias Basler
<Matthias.Basler@xxxxxxxxxxx>, geotools-devel
<geotools-devel@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <42BE6E05.2040303@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Chris Holmes a écrit :
http://svn.geotools.org/geotools/trunk/gt/module/migrate/src/
org/ geotools/gui/
They're in migrate, but I don't know that anyone is going to
actually do
the migrate.
They are on my todo list (at least the swing package), after
GridCoverage operations. Some of those widgets are useful as
debugging
tools, for example ImageProperties for debugging a chain of
GridCoverage
operators (the widget show an image snapshot together with some
image
informations).
They should of course live in a module separated from main, but my
intend was to provides a convenience method GridCoverage.show()
method
which display the image using those widget (using reflection for
avoiding direct dependencies of main toward GUI). I find that of
great
help for debugging.
Martin.
------------------------------
Message: 7
Date: Sun, 26 Jun 2005 04:27:48 -0400
From: Chris Holmes <cholmes@xxxxxxxxxxxxx>
Subject: [udig-devel] Re: [Geotools-devel] Scope of GeoWidgets (was
gui module to geowidgets?)
To: Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>
Cc: User-friendly Desktop Internet GIS
<udig-devel@xxxxxxxxxxxxxxxxxxxxx>, Matthias Basler
<Matthias.Basler@xxxxxxxxxxx>, geotools-devel
<geotools-devel@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <1119774468.42be6704965cb@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1
Quoting Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>:
Chris Holmes wrote:
Ok, I may be off here on the intentions of geowidgets, but I'm
wondering
if we could consider moving the 'gui' module from geotools to
geowidgets. You know the one that few of us use, that we get a
bunch
of questions about why it's not in some releases (because it's in
legacy or migrate because no developers really support it). I
think it
could generate more interest for geowidgets, and would give us a
more
contained place to point people looking for gui type
functionality.
There is really two things going on here. Rendering (and the
model of
Map/Layer(Data+Style) that rendering is based on. And widget
such as
SWT
Container, Swing Panel or OpenGL Canvas (or GeoAPI Canvas
abstraction
of
the same).
I could totally see the rendering system being broken out (and made
to
opperate against interfaces). It is more then pure view, it is pure
visualization.
Ok, this area is far from where my expertise in geotools lies.
But I
don't think I'm at advocating splitting out the rendering system (at
least not yet). All I was thinking of was these classes:
http://svn.geotools.org/geotools/trunk/gt/module/migrate/src/org/
geotools/gui/
They're in migrate, but I don't know that anyone is going to
actually do
the migrate. I'm suggesting we migrate them into geowidgets. Or
will
geowidget be a refactoring? Basically when people ask 'where did
the
gui module go?' can I say 'look at geowidgets'?
The gui widget part is a bit more fun. We start to have events and
threading issues and in general it is a bit more complicated. In
the
origional emails Mattias was looking to follow up his excelent
contribution to uDig (of a CRS chooser) with something a bit more
generic and reusable in SWT and Swing (and possibly even
Spring/STRUTS).
I had in mind GeoWidgets defining the a series of Models for things
like
CRS and then providing a widget that can be used to "edit" or
"choose"
the content. SLD makes for an interesting example.
Now these models are pretty *small*, the data is already defined by
geotools, the model simple adds information such as the current
"selection" and other book keeping values to to keep track of the
view
state. Any such model would have events (something that helps when
the
geotools data objects don't have a proper event system).
Here is a perfect example:
http://svn.geotools.org/udig/trunk/plugins/
net.refractions.udig.style.sld/src/net/refractions/udig/style/
sld/ simple/StrokeViewer.java
Stroke viewer "edits" a SLD Stroke.
It has a model:
boolean enabled = false;
Color color = null;
double width = Double.NaN;
double opacity = Double.NaN;
And a view:
Button on;
StolenColorEditor chooser;
Combo size;
Combo percent;
And a controler is contained in a sync() method.
I would assume the widgets project would result in three jars:
- geowidgets-model.jar
- geowidgets-swing.jar
- geowidgets-swt.jar
The idea being that any opperation code that is shared between
geoserver, udig, geovista and IanS's netbeans project can offer up
geowidget models as a way for the hosting application to control
their
state.
This was however only my understanding, the recent questions about
Map/Layer and so on point in a different direction - towards the
establishment of a neutral canvas for rendering content.
There three paths forward on the model side of things:
- GeoAPI Canvas/Graphic - not full evaulated
- uDig Map/Viewport/Layer/StyleBlackboard - flexable, offers ideal
separation, not quite what people expect
- GeoTools Map/MapLayer/Style
And three proposed targets for widgets: Java2D, SWT, OpenGL - on
the
rendering side they can all be hidden behind one interface
(indeed we
render to both Java2D and SWT for udig.
Swing and SWT have a similar construct for an event thread, all it
really amounts to is that any system better be based on
commands. Ie
Tools produce commands that effect the model. Of more concern is
worker
thread behavior and when/how they are allowed to update the model.
Once
again these are often best formulated as a command which the
controller
can execute in the appropriate thread.
The hard part is keeping the models as pure data (aka they
should not
do
work).
Sounds like good thoughts, again, far from where my expertise lies.
Perhaps it's not the intent of geowidgets to handle the same type
of
things, but I like the idea of having geotools split up a bit
more,
so
that for example people wanting to hack on the gui stuff don't
have
to
build main every time. Thoughts?
GeoAPI
- specifications (such as SLD, Feature, Filter)
GeoTools
- data objects (such as SLD, Feature, Filter)
- visualization (such as renderers, Canvas)
GeoWidgets
- model (wraps data w/ events)
- controler (allows modification of model via commands)
- widgets (swt,swing,opengl)
- canvas (such as Java2D, Draw2D, OpenGL raster)
UDig
- Formal breakdown into plugins, tools, keyboard shortcuts
This break down sounds good to me. Though you have canvas twice, in
geotools under visualization, and in geowidgets. Or does gt2 define
the general, and geowidgets the individual interfaces?
I know the existing gui classes had various tools defined as a
series
of
callbacks for their "canvas". I would much rather see those things
defined as proper commands con the canvas controler, and leave the
registration and tool selection as an application specific concern.
Basically I know geotools did not want to be an application, I want
to
confirm that GeoWidgets does not want to be an application.
Agreed. Though with a name like geowidgets it seems like the
intention
is not to be an application.
Also, Matthias - I'm sure we can find you some tools to support
your
project, if you're willing to commit to it and take a decent lead.
SVN
at refractions, confluence and jira at codehaus, downloads at
sourceforge (well, you can get sf on your own).
It is still a tricky problem :-) the data/model split.
We should also ask James what he wants to do?
As an example of the difficulty consider DataStore, it defines a
nice
data model for feature access. It also defines an event model for
driving user interfaces (and redraws).
However it took two years before the first person (Jesse) hooked
up the the event system and changed the bugs out.
Currently the SLD implementation (named Style) completly lacks
event
notification.
So james, how would you like us to proceed? Should we add event
notification to the geotools classes? I know for example that
this is
one of the reasons we subclass DataStores so much in udig (so we
can
figure out when the connection is broken and provide user interface
notification).
Is there a nice way to separate it out? Though I think I'm fine
with
event notification in gt2, as long as it's actually maintained
and used
- which hasn't been the case in the past.
Chris
Jody
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?
ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Geotools-devel mailing list
Geotools-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/geotools-devel
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
------------------------------
_______________________________________________
udig-devel mailing list
udig-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.refractions.net/mailman/listinfo/udig-devel
End of udig-devel Digest, Vol 14, Issue 44
******************************************
