Please bring back the old rectangle selection...
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Please bring back the old rectangle selection...
I have tried to like the new one. I honestly did.
But there are some things that make life really hard when you have to work
within certain contraints.
First of all the new one doesn't save it's options. That could be remedied but
the amount of changes (I'm a C++ developer and really can't get my head
around doing the way object orientation is done in the tool, the
documentation for all the stuff that has to be done is lacking or isn't easy
located - so I can't do it myself, I tried and failed) seem excessive as the
gimprectangleoptions.c is the odd one out and uses a completely different way
of storing it's properties to all the other tools -> Bug #346683.
If that were not bad enough, the usability is partially much worse than
before. Let me explain: the old rectangle selection tool didn't have the
bells and wistles but it was more straight forward if you wanted to keep the
aspect ratio to say 3:2 when cropping. You simply entered 3 into the
x-dimension, 2 into the y dimension and ticked "fixed aspect". Now you have
to enter 1.5 into the aspect ratio box and tick the check box next to it. But
what if you want 3:2 aspect (for a vertical compositional crop)? Now you have
to enter 0.6666 into the aspect ratio, and you already are suffering a loss
of precision (it's off by a few pixels if your image is sufficiently large,
because it's not 0.6666 it's 0.6666666). Even worse - calculator on standby -
imagine you want to have 16:9 or 9:16 aspect ratio because you want to use
the image in your own DVD production. The old style was simple (took a bit
getting used to but was workable), the new style of setting the aspect ratio
is a pain in the proverbial... -> Feature request/Usability Bug #346684.
Then try to select some rectangular areas because you might want to make them
partially transparent or only sharpen the remainder of the area. Now the new
form of selection with the last selected area still visible is getting
annoying to say the least. I cannot tell how often I find myself cursing at
the new rectangle selection when selecting multiple rectangle areas to join
them into a larger compound area because the last area stays visible and
sometimes - I can't really pinpoint when - keeps me from selecting the next
area. If I could pinpoint the culprit operation then I would file a bug.
Then there are some usability issues with the way the last selected area is
shown as stippled outline when you start resizing the area, there seems to be
a random element to when the selection is supposed to be finished and what is
supposed to be visualized -> Bug #347945.
My humble (well after this rant) request would be to resurrect the old
rectangle selection tool and have the new one reworked so that the next
milestone doesn't have to be postponed because of this (for me the first one
is a true blocker, the other ones are very annoying to say the least).
regards
Karl Günter Wünsch
It's getting worse... Now I really want the old rect selection tool back!
I just stumbled across the next level in annoyance, resizing does only work
when grabbing one of the horizontal delimiter lines, using the vertical
delimiters seems to be blocked by some aspect ratio calcuations -> Bug
#348807.
regards
Karl Günter Wünsch
It's getting worse... Now I really want the old rect selection tool back!
On Wed, 2006-07-26 at 18:36 +0200, Karl Günter Wünsch wrote:
I just stumbled across the next level in annoyance, resizing does only work when grabbing one of the horizontal delimiter lines, using the vertical delimiters seems to be blocked by some aspect ratio calcuations -> Bug #348807.
Instead of repeatedly ranting "i want the old tool back" you should realize that you are using something that is explicitely labeled "unstable" and "in development". So be constructive, thus helping fixing these bugs, or use the stable 2.2 version.
ciao, --mitch
It's getting worse... Now I really want the old rect selection tool back!
On Wednesday 26 July 2006 19:21, Michael Natterer wrote:
Instead of repeatedly ranting "i want the old tool back" you should realize that you are using something that is explicitely labeled "unstable" and "in development". So be constructive, thus helping fixing these bugs, or use the stable 2.2 version.
I am constructive in reporting the bugs.
Fixing for me is impossible as the new rect selection tool is undocumented,
the interface it uses is unlike any of the other tools from where I could
take a hint or two on how to get started understanding it and on top of that
there is the complete gibberish of code which implements the object
orientation.
If code like this is unstable or "in development" it needs to be labeled
clearly as such and not simply toss out the old tried and tested. It could
easily have been implemented alongside the old tool without loosing much.
I am using (as in productive use) the development branch of GIMP because of
certain recent developments I need as a photographer to get my pictures
edited, but every time the rect selection tool is taking up more and more of
my time because it is very important in my editing and isn't very well
thought through. It's all bells and whistles (guide lines, resizing possible)
but some of the base functionality the old one had has been broken badly.
So my comment is basically one of desperation. I need the current CVS for some
of the functionality but at the same time the new rect selection is close of
driving me nuts.
regards
Karl Günter
It's getting worse... Now I really want the old rect selection tool back!
On Wed, Jul 26, 2006 at 07:35:00PM +0200, Karl Günter Wünsch wrote:
Instead of repeatedly ranting "i want the old tool back" you should realize that you are using something that is explicitely labeled "unstable" and "in development". So be constructive, thus helping fixing these bugs, or use the stable 2.2 version.
I am constructive in reporting the bugs. Fixing for me is impossible as the new rect selection tool is undocumented, the interface it uses is unlike any of the other tools from where I could take a hint or two on how to get started understanding it and on top of that there is the complete gibberish of code which implements the object orientation.
[...]
You might want to consider switching to an older revision (probably installing it besides the most recent one) where the old rect select tool is still available.
You are experiencing what happens if developers really mean "development branch" if they say "development branch". There may be times where the software is partially or totally broken and this is intended. Simply keep a last "works for me" version and use it if things get screwed up.
Tino.
It's getting worse... Now I really want the old rect selection tool back!
Karl Günter Wünsch wrote:
If code like this is unstable or "in development" it needs to be labeled clearly as such and not simply toss out the old tried and tested.
The whole 2.3 branch is unstable and in development...
It could easily have been implemented alongside the old tool without loosing much. I am using (as in productive use) the development branch of GIMP because of
^^^^^^^^^^^^^^^^^^
... that's why it is called the development branch, after all.
I need the current CVS for some of the functionality but at the same time the new rect selection is close of driving me nuts.
And this is why you did file the bug reports. One of the things I can't understand is why you do double your work by posting the same information here twice (and in a way that is very hard to read, btw - please use empty lines to split your messages into paragraphs).
HTH, Michael
It's getting worse... Now I really want the old rect selection tool back!
On Wednesday 26 July 2006 19:52, Michael Schumacher wrote:
Karl Günter Wünsch wrote:
The whole 2.3 branch is unstable and in development...
I know, but wasn't the 2.3 branch to be a short lived one, leading quickly to a stable 2.4?
And this is why you did file the bug reports. One of the things I can't understand is why you do double your work by posting the same information here twice (and in a way that is very hard to read, btw - please use empty lines to split your messages into paragraphs).
I thought a line break would be sufficient to trigger a paragraph, duly noted and will change my posts apropiately.
As to why I posted the information twice:
There are two reasons, first of all I needed a safety vent for the problems these bugs cause me.
And then please have a look at the date I posted the first bugs in my first rant, it's three weeks ago. Besides the first one being classified quickly as confirmed, nobody really looked at them. In my experience (in our company there is a similar bug reporting system) this means that noone cares, or anyone who cares overlooked the reports.
With them being given more exposure through the mailing list I can at least now converse with people about what is to be expected of the tool and if my ideas are completely off the trolley - or if they have enough merit as to be classified as true bugs. If the latter is true (as it seems by the comments I now received on the bug reports) then I can at least continue to test the features and if I stumble across something that I classify as broken I can post another bug report.
Of course I would rather fix these broken things myself (I am a seasoned
software developer in both C and C++, earning my living as a developer) but
there is no starting point in the documentation sources for the tool itself -
so there is no way for me to get my hands dirty and change anything for the
better - except for starting over with a similar but functioning tool as a
starting point and trying to carry over as much functionality as possible.
regards
Karl Günter
It's getting worse... Now I really want the old rect selection tool back!
On Wednesday 26 July 2006 20:42, Karl Günter Wünsch wrote:
On Wednesday 26 July 2006 19:52, Michael Schumacher wrote:
Karl Günter Wünsch wrote:
The whole 2.3 branch is unstable and in development...I know, but wasn't the 2.3 branch to be a short lived one, leading quickly to a stable 2.4?
The life of the 2.3 branch is as long as the life of the 2.2 branch. That's far from short.
And then please have a look at the date I posted the first bugs in my first rant, it's three weeks ago. Besides the first one being classified quickly as confirmed, nobody really looked at them. In my experience (in our company there is a similar bug reporting system) this means that noone cares, or anyone who cares overlooked the reports.
Bill and myself are the two developers that spent the most time on these new tools. We have both been on holidays for the past 3 weeks. Don't come to conclusions so fast.
Further, your bug reports are very nice, but I'm afraid you're being counter-productive with your mails. We are not working for you, and the fact that you purposedly use a development version for your production work will not make us fix anything faster - quite the contrary, your mail subject lines tend to drive me away.
Of course I would rather fix these broken things myself (I am a seasoned software developer in both C and C++, earning my living as a developer) but there is no starting point in the documentation sources for the tool itself - so there is no way for me to get my hands dirty and change anything for the better - except for starting over with a similar but functioning tool as a starting point and trying to carry over as much functionality as possible. regards
Karl Günter
Maybe you should try to join the developers IRC channel to get started, now that we are both back. We wouldn't mind a helping hand on these tools.
Karine Delvare
It's getting worse... Now I really want the old rect selection tool back!
On Wednesday 26 July 2006 22:19, Karine Delvare wrote:
The life of the 2.3 branch is as long as the life of the 2.2 branch. That's far from short.
Then I misinterpreted something there...
Bill and myself are the two developers that spent the most time on these new tools. We have both been on holidays for the past 3 weeks. Don't come to conclusions so fast.
Sorry for that, since there wasn't anyone responding I assumed - wrongly - that there isn't anyone interested or that the reports were overlooked.
Further, your bug reports are very nice, but I'm afraid you're being counter-productive with your mails.
Those mails were the result of not even an acknowledgement on the bugzilla reports and having had a hard time when editing my images.
We are not working for you, and the
fact that you purposedly use a development version for your production work will not make us fix anything faster - quite the contrary, your mail subject lines tend to drive me away.
Sorry for that, but frustration is quickly gaining if there is no response at all. I now know why there wasn't any so I can keep my frustration in check quite easily. In fact I am using the development version for two reasons. First reason is to get the benefit of a few of the new advanced features (the extract foreground tool is the most notable one, I tried the plugin for the 2.2 branch but the results weren't that good and then I got the hint that the development version is much better - which is true). The second is to catch design flaws as soon as possible and deliver as good bug reports as possible as I want the GIMP to be as useable as possible.
The problem was that the new rectangle selection on one hand looks quite nice and well thought through while on the other it's a big step backwards from what the GIMP had before if you use it in real life.
On paper (and screen) the aspect setting for example is technically correct but it's not practical in real life as aspect isn't that easily understood if you represent it as a single float. I made design errors like these often enough in my daytime job because technically correct doesn't always means logical to the end user.
Maybe you should try to join the developers IRC channel to get started, now that we are both back. We wouldn't mind a helping hand on these tools.
I'll gladly help but IRC is a problematic media for me as I live in Germany, so the time differential might mean that I can only respond with 8-12 hours skew. Direct mail contact on a smaller scale is more efficient for me most of the time.
If it's ok with you I'll resort to detailed bug reports (no rants promised :-) and testing (trying to keep my distance from the code as good as possible, if I dig in too deeply my testing might be influenced and I have the tendency to subconciously avoid problematic code when testing) and the odd small change if I find a bug easily.
regards Karl Günter
It's getting worse... Now I really want the old rect selection tool back!
Karl Günter Wünsch wrote:
I'll gladly help but IRC is a problematic media for me as I live in Germany, so the time differential might mean that I can only respond with 8-12 hours skew. Direct mail contact on a smaller scale is more efficient for me most of the time.
The difference from Germany to France and vice versa wasn't that large the last time I checked :)
HTH, Michael
It's getting worse... Now I really want the old rect selection tool back!
Karl Günter Wünsch wrote:
In the mean time, here is a preliminary patch for bug #348807.
The preferred way to submit patches is to attach them to the corresponding bug in Bugzilla. It is easier to keep track of them there, e.g. by indicating that they need work, obsoleting old ones by newly added ones etc.
See http://developer.gimp.org/ for more hints about GIMP development.
HTH, Michael
It's getting worse... Now I really want the old rect selection tool back!
On Thursday 27 July 2006 00:52, Michael Schumacher wrote:
Karl Günter Wünsch wrote:
In the mean time, here is a preliminary patch for bug #348807.
The preferred way to submit patches is to attach them to the corresponding bug in Bugzilla. It is easier to keep track of them there, e.g. by indicating that they need work, obsoleting old ones by newly added ones etc.
Sorry, but I was keeping to the HACKING text file off developer.gimp.org, may I quote: "Please submit patches to the gimp-developer@lists.xcf.berkeley.edu mailing list. It's also a good idea to file a bug-report at http://bugzilla.gnome.org/ and attach your patch to it. "
I was just attaching the patch to the bugzilla entry I made earlier today...
If you don't think that posting patches here makes sense, then you should alter the HACKING file to reflect that.
regards Karl Günter
Is there a way to update the cursor position from within a tool?
Quoting Karl Günter Wünsch :
That's why I would like to update the cursor position after all of the calculations are through to reflect the results.
Are you saying that you wish the pointer to be forced to the
calculated corner of a (aspect ratio) constrained mouse movement? If
this is what you mean then I am almost certain this is contrary to the
GNOME Human Interface Guidelines
(http://developer.gnome.org/projects/gup/hig/1.0/index.html).
Pointer movements are supposed to track mouse movements. If you are dragging the mouse along the X-axis, to have the pointer follow a Y-path that is a function of the X-position (and not determined by the mouse's Y position) breaks everything that users have ever experienced in using mice.
My apologies if I misunderstood you. If such is the case, perhaps you wouldn't mind providing a clarification.
Is there a way to update the cursor position from within a tool?
On Friday 28 July 2006 11:30, saulgoode@brickfilms.com wrote:
Quoting Karl Günter Wünsch :
That's why I would like to update the cursor position after all of the calculations are through to reflect the results.
Are you saying that you wish the pointer to be forced to the calculated corner of a (aspect ratio) constrained mouse movement? If this is what you mean then I am almost certain this is contrary to the GNOME Human Interface Guidelines
(http://developer.gnome.org/projects/gup/hig/1.0/index.html).
What is so wrong in this case to have the cursor follow the only possible path that is within the constraints. Because if you don't then you end up with a pointer position that doesn't correspond to the current selection anymore.
In this case we have a corner of an aspect constrained rectangle selected. Both x and y movements are allowed but as these two have to a strict relationship any movement by the user that doesn't follow this relationship (for every 3 pixels horizontally move 2 pixels vertically) will end up having the pointer and the corner being so far apart that the visual relationship between the pointer and the selection isn't aparent any more. I have found a partial solution to this problem yesterday evening (still some quirks to work out) but the problem basically is only reduced by the code that tries to keep the selection as close as possible to the pointer, there still are times when they end up virtually in different corners of the screen...
Is there a way to update the cursor position from within a tool?
On Fri, 2006-07-28 at 12:15 +0200, Karl Günter Wünsch wrote:
On Friday 28 July 2006 11:30, saulgoode@brickfilms.com wrote:
Quoting Karl Günter Wünsch :
That's why I would like to update the cursor position after all of the calculations are through to reflect the results.
Are you saying that you wish the pointer to be forced to the calculated corner of a (aspect ratio) constrained mouse movement? If this is what you mean then I am almost certain this is contrary to the GNOME Human Interface Guidelines
(http://developer.gnome.org/projects/gup/hig/1.0/index.html).What is so wrong in this case to have the cursor follow the only possible path that is within the constraints. Because if you don't then you end up with a pointer position that doesn't correspond to the current selection anymore.
Well we don't do that when snapping to guides and the grid either, and as said before, it's a totally non-standard way of dealing with snapping. The mouse pointer should always be driven by the user, not by the application, and until recently, gtk didn't even have an API to wrap the mouse, for just that reason.
We won't add that to GIMP.
ciao, --mitch
In this case we have a corner of an aspect constrained rectangle selected. Both x and y movements are allowed but as these two have to a strict relationship any movement by the user that doesn't follow this relationship (for every 3 pixels horizontally move 2 pixels vertically) will end up having the pointer and the corner being so far apart that the visual relationship between the pointer and the selection isn't aparent any more. I have found a partial solution to this problem yesterday evening (still some quirks to work out) but the problem basically is only reduced by the code that tries to keep the selection as close as possible to the pointer, there still are times when they end up virtually in different corners of the screen...
Is there a way to update the cursor position from within a tool?
Scripsit Karl Günter Wünsch
In this case we have a corner of an aspect constrained rectangle selected. Both x and y movements are allowed but as these two have to a strict relationship any movement by the user that doesn't follow this relationship (for every 3 pixels horizontally move 2 pixels vertically) will end up having the pointer and the corner being so far apart that the visual relationship between the pointer and the selection isn't aparent any more.
The correct way to deal with a constrained selection is to let the user control the pointer, and then draw the unique rectangle with the specified aspect for which one of the moving sides pass through the pointer. This allows one to select the rectangle by moving either the right side (and have the bottom one follow according to aspect) or moving the bottom side (and have the right one follow according to aspect).
That is how the "select square" functionality works in 2.2. It is easy and intuitive. Is there any reason to change it?
Is there a way to update the cursor position from within a tool?
On Friday 28 July 2006 12:46, Henning Makholm wrote:
The correct way to deal with a constrained selection is to let the user control the pointer, and then draw the unique rectangle with the specified aspect for which one of the moving sides pass through the pointer. This allows one to select the rectangle by moving either the right side (and have the bottom one follow according to aspect) or moving the bottom side (and have the right one follow according to aspect).
That behaviour is there and works, it's the seperate corners which are movable in both horizontal and vertical direction at the same time that pose a problem. For the times when no aspect is selected these corners are a must to allow for a fast resizing. It's those corners which are a problem when the aspect is fixed though.
That is how the "select square" functionality works in 2.2. It is easy and intuitive. Is there any reason to change it?
The new rectangle selection (see my rant - of which almost all things are now being tackled) does enhance the functionality in this department by quite a bit but there are some things that would benefit from having this set fuctionality. It's less about breaking the UI generally but if there are constraints - even if I enabled them myself - such a visual feedback that I can't reach other positions could be well worth having.
Is there a way to update the cursor position from within a tool?
Scripsit Karl Günter Wünsch
On Friday 28 July 2006 12:46, Henning Makholm wrote:
The correct way to deal with a constrained selection is to let the user control the pointer, and then draw the unique rectangle with the specified aspect for which one of the moving sides pass through the pointer. This allows one to select the rectangle by moving either the right side (and have the bottom one follow according to aspect) or moving the bottom side (and have the right one follow according to aspect).
That behaviour is there and works, it's the seperate corners which are movable in both horizontal and vertical direction at the same time that pose a problem. For the times when no aspect is selected these corners are a must to allow for a fast resizing. It's those corners which are a problem when the aspect is fixed though.
I don't see what the problem is. Is the aspect is fixed, then let the pointer position one of sides adjacent to the grabbed corner (selected on the fly just as when the rectangle is being dragged out initially, holding the opposite corner's position constant). If the aspect is _not_ fixed, then move the corner itself.
It's less about breaking the UI generally but if there are constraints - even if I enabled them myself - such a visual feedback that I can't reach other positions could be well worth having.
Isn't it visual feedback enough for you that the corner you're attempting to drag does not follow the mouse?
Is there a way to update the cursor position from within a tool?
On Fri, Jul 28, 2006 at 12:15:05PM +0200, Karl Günter Wünsch wrote:
That's why I would like to update the cursor position after all of the calculations are through to reflect the results.
Are you saying that you wish the pointer to be forced to the calculated corner of a (aspect ratio) constrained mouse movement? If this is what you mean then I am almost certain this is contrary to the GNOME Human Interface Guidelines
(http://developer.gnome.org/projects/gup/hig/1.0/index.html).
What is so wrong in this case to have the cursor follow the only possible path that is within the constraints. Because if you don't then you end up with a pointer position that doesn't correspond to the current selection anymore.
It's wrong in the sense that the mouse pointer never moves by itself, but only if the user moves the mouse. Apart from that, it would not work with certain setups like graphics tablets in absolute mode where the position on the tablet is directly mapped to the position on screen.
In this case we have a corner of an aspect constrained rectangle selected. Both x and y movements are allowed but as these two have to a strict relationship any movement by the user that doesn't follow this relationship (for every 3 pixels horizontally move 2 pixels vertically) will end up having the pointer and the corner being so far apart that the visual relationship between the pointer and the selection isn't aparent any more. I have found a partial solution to this problem yesterday evening (still some quirks to work out) but the problem basically is only reduced by the code that tries to keep the selection as close as possible to the pointer, there still are times when they end up virtually in different corners of the screen...
The mouse pointer should always be at the X or the Y border of the selection. IMO this is sufficient.
Tino.
Please bring back the old rectangle selection...
Hi,
On Tue, 2006-07-25 at 23:49 +0200, Karl Günter Wünsch wrote:
First of all the new one doesn't save it's options. That could be remedied but the amount of changes (I'm a C++ developer and really can't get my head around doing the way object orientation is done in the tool, the documentation for all the stuff that has to be done is lacking or isn't easy located - so I can't do it myself, I tried and failed) seem excessive as the gimprectangleoptions.c is the odd one out and uses a completely different way of storing it's properties to all the other tools -> Bug #346683.
Fixing this is as simple as adding the GIMP_CONFIG_PARAM_SERIALIZE flag to the registration of the interface properties. This is a simple change and it is already outlined in the bug report. Please stick to the facts, or if you don't know about the implementation details, don't make assumptions about them.
If that were not bad enough, the usability is partially much worse than before.
The new tools are not ready yet. We know that there are problems and it is nice that you took the time to point them out. But rest assured that we don't plan to release GIMP 2.4 with the selection tools in their current state.
Sven
Please bring back the old rectangle selection...
On Tuesday 08 August 2006 10:00, Sven Neumann wrote:
Fixing this is as simple as adding the GIMP_CONFIG_PARAM_SERIALIZE flag to the registration of the interface properties. This is a simple change and it is already outlined in the bug report. Please stick to the facts, or if you don't know about the implementation details, don't make assumptions about them.
And now you are making assumptions. The flag only alters the behaviour by resulting in a crash when trying to read or write the properties... This probably is the result of not using the macros every other tool uses to register it's properties.
If that were not bad enough, the usability is partially much worse than before.
The new tools are not ready yet. We know that there are problems and it is nice that you took the time to point them out. But rest assured that we don't plan to release GIMP 2.4 with the selection tools in their current state.
And if you had read the followups on this (partially in the cited bug reports) you would have noticed that I started to work with the developers to fix the problems - part of the patches originate from me. My whole rant here was the result of the lack of feedback to those bug reports, which since has been cleared as a bad timing because of the holiday season...
Please bring back the old rectangle selection...
Hi,
On Tue, 2006-08-08 at 10:17 +0200, Karl Günter Wünsch wrote:
On Tuesday 08 August 2006 10:00, Sven Neumann wrote:
Fixing this is as simple as adding the GIMP_CONFIG_PARAM_SERIALIZE flag to the registration of the interface properties. This is a simple change and it is already outlined in the bug report. Please stick to the facts, or if you don't know about the implementation details, don't make assumptions about them.
And now you are making assumptions. The flag only alters the behaviour by resulting in a crash when trying to read or write the properties... This probably is the result of not using the macros every other tool uses to register it's properties.
The other tools you are referring to aren't interfaces such as the GimpRectangleOptions. The macros are useful shortcuts for adding serializable properties to object classes, but they won't work for interfaces. And yes, there are good reasons for GimpRectangleTool and GimpRectangleOptions being interfaces. If there is indeed a crash when using the SERIALIZE flag with an interface, then we will have to investigate this and fix it.
Sven
Please bring back the old rectangle selection...
Hi,
On Tue, 2006-08-08 at 10:44 +0200, Karl Günter Wünsch wrote:
I have no doubts about this but there is a problem discerning these two by just looking at the code if you are not that much into the GTK way of doing objects. There also is little documentation whatsoever on what parameters mean.
The GObject documentation at
http://developer.gnome.org/doc/API/2.0/gobject/ is quite extensive and
should be considered a must-read if you want to understand the internals
of the GIMP core.
I debugged that down to the level of an object comparison (by name it seemed) which failed because one of the objects compared was NULL. If you'd like I can give it a try later (tonight after 8pm european summer time) and give some additional informations about this...
It doesn't crash for me, but there are critical warnings when the interface properties are being deserialized. I will have a look at gimp_config_deserialize_property(), most probably we are making the wrong assumption here that the properties owner_type is a class.
Sven
