Version: HEAD (using KDE KDE 3.3.0) OS: Linux George, please attach a design plan so that work can start on this.
All graphic items, including text labels, should become view objects. There are many reasons, including: - Duplication of mouse handling code is wasteful and error prone - Inconsistency between objects is undesired - The objects can be used without plots - They can be arranged along with plots In particular, users have demanded the ability to create objects outside of plots, so it makes this design necessary. As a very nice side-effect, we will be able to remove large amounts of irrelevant code from Kst2DPlot. The framework for this is already done and works quite well, but the user-interface is severely lacking. There are additional deficiencies in our UI which should be addressed simultaneously. See is.png. This is Inkscape, and contains similar drawing tools in the toolbar on the left side. We should create a similar toolbar, but have it cascade from a single entry in the main toolbar. The 2dplot-internal graphics toolbar, for instance, takes up quite a bit of screen real-estate, most of which is typically empty. We can save this space for data if we cascade it from the main toolbar. kstempty.png has some annotations to illustrate this. Furthermore, the 2dplot zoom modes should be brought into kst2dplot, since they are specific to it, and handled entirely there. They should also be a drop- down toolbar entry since only one can be active at any given time. The biggest job, by far, is making the graphics objects usable as the user would expect in a similar vector graphics applications. The 2dplot-internal graphics system is close to what is wanted, but we should look at inkscape, corel draw, and other such applications for ideas. The user should be able to manipulate objects irrespective of their bounding box, however. This requires new cases in KstTopLevelView. It may be sensible to rework the existing code to make it more readable and understandable. Over many iterations it's become a bit complicated. Tools for the Graphics Menu --------------------------- Layout (Move, Resize) Text Line Arrow Box Ellipse (also does circle) Picture Curve (less important) Polyline (less important) Freeform (less important) Other things missing in view objects: - Ability to rotate objects - Mechanism to indicate that an object should be subject to the grid - Ability to compose objects from the UI easily
All graphic items, including text labels, should become view objects. There are many reasons, including: - Duplication of mouse handling code is wasteful and error prone - Inconsistency between objects is undesired - The objects can be used without plots - They can be arranged along with plots - In the script language they are consistent with other objects and require far less work to implement and maintain - They're much easier to manipulate in the script language - With Qt properties we can make a generic dialog for all of them quite easily In particular, users have demanded the ability to create objects outside of plots, so it makes this design necessary. As a very nice side-effect, we will be able to remove large amounts of irrelevant code from Kst2DPlot. The framework for this is already done and works quite well, but the user-interface is severely lacking. There are additional deficiencies in our UI which should be addressed simultaneously. See is.png. This is Inkscape, and contains similar drawing tools in the toolbar on the left side. We should create a similar toolbar, but have it cascade from a single entry in the main toolbar. The 2dplot-internal graphics toolbar, for instance, takes up quite a bit of screen real-estate, most of which is typically empty. We can save this space for data if we cascade it from the main toolbar. kstempty.png has some annotations to illustrate this. Furthermore, the 2dplot zoom modes should be brought into kst2dplot, since they are specific to it, and handled entirely there. They should also be a drop- down toolbar entry since only one can be active at any given time. The biggest job, by far, is making the graphics objects usable as the user would expect in a similar vector graphics applications. The 2dplot-internal graphics system is close to what is wanted, but we should look at inkscape, corel draw, and other such applications for ideas. The user should be able to manipulate objects irrespective of their bounding box, however. This requires new cases in KstTopLevelView. It may be sensible to rework the existing code to make it more readable and understandable. Over many iterations it's become a bit complicated. Tools for the Graphics Menu --------------------------- Layout (Move, Resize) Text Line Arrow Box Ellipse (also does circle) Picture Curve (less important) Polyline (less important) Freeform (less important) Other things missing in view objects: - Ability to rotate objects - Mechanism to indicate that an object should be subject to the grid - Ability to compose objects from the UI easily
As a supplement to George's description of structure changes, I have submitted a brief overvies of the UI for plots and view objects. I will include it here for good luck as well... Plot UI ToolBar There should be two pull down icon menus forming a radio pair in the tool bar: * one selects the 2d plot zoom modes, * Contains XY, X, and Y zoom icons * the other selects object manipulation modes. * Contains Select, Text, Line, Arrow, Box, Ellipse. Biezer, poly-line and polygon are optional. * The last icon selected from the list is the one which shows. Zoom Modes (XY, X and Y zoom modes) 2d plot modes which are only valid for 2d plots. The current behavior of these there modes is correct, though the toolbar icon handling will change as described above. Modes selected from the data-manipulation toolbar icon: For all of these modes, the right button menu should include: .... Select Mode: Used to move and edit any data view object. An enhancement to layout mode. * A single click on a view object pops up the objects edit dialog. (eg, PlotDialog for plot, labeldialog for labels, etc) * A drag on a view object moves the object. * If a view object is dragged to become completely contained in another view object, it becomes a child of the containing object, and then drags and scales with the containing onject. * A drag on the edge of, or the hot point of a data object changes the object's geometry. * The top-most object with pixels drawn in the mouse target area (~20% of the mouse's size) is the one which is selected. * The mouse icon will change depending on where it is * By default the mouse icon is the standard arrow * When a drag would cause a move, the mouse icon is the standard 4 arrow mouse move icon * When a drag would move a hot point, the mouse returns to an arrow icon, and the hot point box is filled. * Visual feedback as to what object will be selected will be given by showing the hotpoints or by drawing a dashed bounding box as follows: * Plots: A dashed rectangle around the outside, as currently in layout mode * Rectangles: Same as plots * Text: Dashed box around the text * Lines and poly-lines: Hot points at each end and each vertex * Ellipse: Hot point at the center and at both sides of the widest and narrowest sections. Dragging the hot points can change the scaling and orientation of the ellipse. Text Mode * Icon changes to the text | icon. * Clicking on text calls up the text edit dialog. * Otherwise, clicking calls up a text dialog for entry. Line/Arrow Line modes: * The line goes from the first click to the second click. * The line is drawn from the first click to the mouse until the 2nd click. * <Esc> cancels the line. * For arrows, the head is at the 2nd click. * An arrow is just a line with the 2nd arrow head shown by default. A line can be turned to an arrow or an arrow to a line in the dialog. PolyLine/Polygon: * Arrow Icon * First and each subsequent click adds a node. * The lines are drawn as we go. A line is drawn from the previous node to the mouse icon. * <Esc> ends the line with the last node. * Double click ends the line at the location of the double click. * For Polygons, once ended, a line is drawn from the first point to the last point. Ellipse: * Arrow Icon * First click is at centre. * Second is at radius. * The circle is drawn as the mouse is moved. * <Esc> cancels the circle. * To convert to an ellipse, Select mode must be used. Dialogs: * Line Mode and arrow mode contains: width, type, color, and arrow head properties (check box for 1st head, 2nd head, and a scale factor). * Polyline contains: width, type, color * Polygon contains width, type, line color, fill color * Ellipse contains width, type, line color, and a check box to make it a circle
Updated Plot UI spec. Also in svn as PlotUI.txt Plot UI ToolBar There should be two pull down icon menus forming a radio pair in the tool bar: * one selects the 2d plot zoom modes, * Contains XY, X, and Y zoom icons * the other selects object manipulation modes. * Contains Select, Text, Line, Arrow, Box, Ellipse. Biezer, poly-line and polygon are optional. * The last icon selected from the list is the one which shows. Zoom Modes (XY, X and Y zoom modes) 2d plot modes which are only valid for 2d plots. The current behavior of these there modes is correct, though the toolbar icon handling will change as described above. Modes selected from the data-manipulation toolbar icon: For all of these modes, the right button menu should include: * Delete (Only active if over a view object) * Edit (Only active if over a view object) * Cut (Only active if over a view object) * Copy (Only active if over a view object) * Cleanup Layout Select Mode: Used to move and edit any data view object. An enhancement to layout mode. * A single click on a view object pops up the objects edit dialog. (eg, PlotDialog for plot, labeldialog for labels, etc) * A drag on a view object moves the object. * If a view object is dragged to become completely contained in another view object, it becomes a child of the containing object, and then drags and scales with the containing onject. * A drag on the edge of, or the hot point of a data object changes the object's geometry. * The top-most object with pixels drawn in the mouse target area (~20% of the mouse's size) is the one which is selected. * The mouse icon will change depending on where it is * By default the mouse icon is the standard arrow * When a drag would cause a move, the mouse icon is the standard 4 arrow mouse move icon * When a drag would move a hot point, the mouse returns to an arrow icon, and the hot point box is filled. * Visual feedback as to what object will be selected will be given by showing the hotpoints or by drawing a dashed bounding box as follows: * Plots: A dashed rectangle around the outside, as currently in layout mode * Rectangles: Same as plots * Text: Dashed box around the text * Lines and poly-lines: Hot points at each end and each vertex * Ellipse: Hot point at the center and at both sides of the widest and narrowest sections. Dragging the hot points can change the scaling and orientation of the ellipse. OBJECT Drawing Modes: * For each of the modes below, when the mouse is over an object of the selected type, the behavior is the same as it would be in Select mode, including hot point behavior and dragging. Text Mode * Icon changes to the text | icon. * When not over a text object, clicking calls up a text dialog for entry. Line/Arrow modes: * Arrow Icon * Lines are made by draging from the 1st point to the 2nd point. * <Esc> cancels the line in the middle of a drag. * For arrows, the head is at the Mouse Release end. * An arrow is just a line with the release end's arrow head shown by default. A line can be turned to an arrow or an arrow to a line in the dialog. Box Mode: * Arror Icon * The box is drawn with a drag. * <Esc> cancels the box. PolyLine/Polygon: * Arrow Icon * First and each subsequent click adds a node. * The lines are drawn as we go. A line is drawn from the previous node to the mouse icon. * <Esc> ends the line with the last node. * Double click ends the line at the location of the double click. * For Polygons, once ended, a line is drawn from the first point to the last point. Ellipse: * Arrow Icon * A circle is drawn with a drag from the center along the major axis. * The circle is drawn as the mouse is moved. * <Esc> cancels the circle. * To convert to an ellipse, drag the minor axis Dialogs: * Line Mode contains: width, type, color, and arrow head properties (check box for 1st head, 2nd head, and a scale factor). * Polyline contains: width, type, color * Polygon contains width, type, line color, fill color * Ellipse contains width, type, line color, and a check box to make it a circle * with the exception of 2nd arrow head check box for lines and arrows, and the text in a text dialog, all entry defaults should be sticky from previous use. ----------- Cleanup Layout: (incomplete comments) Cleans up the layout, returning to a grid, as clse as is possible to the existing layout. * Plots with borders surpressed need to be smaller, so that each plot area in the window has equal area. * Only direct children of the top level view get moved or resized directly. All other objects get scaled or moved with their parents. * Only container objects (plots, boxes, ellipses) get resized in a layout cleanup.
After trying the first implementation at graphic objects, I was just about to create a bugzilla entry to change some quirks/shortcomings. From what I see, there are going to be a lot of changes anyway, so I'll just comment on Barth's ideas, which I find globally excellent. I just have a couple of (at this stage) minor remarks: - I think a rotate mode would be nice: there could be a rotation icon, and when in that mode, moving the hot points would rotate the object. Another approach would be to use inkscape's selection paradigm: objects can be unselected, selected for geometry changes (first click), or selected for rotation/skewing (next click) around a point materialized by a (movable) cross. Further clicks on the object toggle the two selected states. Moving happens in both modes by dragging the objects (in any place other than a hot point) - I find it unintuitive for ellipses to be first drawn as circles. I think the more natural approach is either separate circle and ellipse tools, or keyboard modifiers (like Ctrl+drag) to fix the horizontal/vertical ratio - the auto-attach feature described sounds nice, but I think a simple group/ungroup functionality (even with just one level) is even better, as you may want to drag compound objects together even if one does not contain the other. A minimalistic approach to this would be for the selection tool to allow drawing a rectangle around multiple objects to move all of them at once. I think inkscape has a pretty powerful user interface, but it might deviate from KDE standards, which is not advisable. Unfortunately, I don't have access to a recent koffice around here to see what e.g. kpresenter offers in this area, but the last time I looked it seemed to have pretty much all that we need... maybe a good source of "inspiration" ? As a vector drawing application, karbon is also a good candidate. We might even get gradient fills for free :-) In any case, I can't wait to see the result !
On Monday 04 July 2005 11:52, Nicolas Brisset wrote: > I just have a couple of (at this stage) minor remarks: > - I think a rotate mode would be nice: there could be a rotation icon, and This is planned.
Another thing I think should be added is image inclusion (think logo, special shapes, etc...). It is probably not too difficult either...
On Wednesday 06 July 2005 10:48, Nicolas Brisset wrote: > 16:48 ------- Another thing I think should be added is image inclusion > (think logo, special shapes, etc...). It is probably not too difficult > either... Already done. You can even set an auto-reload timer, load the image from a URL, etc.
*** Bug 96241 has been marked as a duplicate of this bug. ***
As I explain in bug #109430, it would be a good idea to implement an extra "flow around" property for view objects. That would allow to put contextual information on the sides of plots, the area in which graphs can be drawn being the internal rectangle delimited by all such objects. I think it could be left up to the user to put these objects on the sides so that the area for plots remains big enough, otherwise plot layout is going to become too complex to manage.
IMPORTANT NOTICE regarding fixed plot coordinates or data coordinates: (I know this had been discussed previously in bug #91675 but I believe it is important enough to be repeated here). As Andrew pointed out, annotating a plot in fixed data coordinates raises the issue of updates: <quote>the updating would have to be paused while annotating else whatever you're adding is liable to vanish from the plot while you're adding it (ditto for editing an already existing object)</quote> Even though Andrew continued saying that data markers provide the same functionality, I believe data markers are a bit simplistic for annotation purposes. For that reason, it would ne nice to provide an option making view objects fixed in data coordinates. I think the default could be plot coordinates. As for the update problem, it could easily be fixed by pausing updates as soon as the user switches to "annotation mode" (Graphics editor). It is very easy to reactivate updates once the annotations are done or zoom mode is activated, and no data gets lost in the process.
The main point is that the bulk of the users are requesting objects in presentation space, not data space right now. After presentation space is done, we might be able to modify Kst2DPlot to shift its children objects in data space as it scrolls, or perhaps becomes a sort of view object manager itself. I'm very afraid of the performance issues associated.
I agree that there could be performance issues and that most uses will be in presentation space. I just thought it was important to keep this in mind so that the design allows to include these features ("flow-around" and "data space") at some point.
Would it make more sense to have objects show hotpoints/outlines only when clicked on, and not lose focus unless another object is clicked on (instead of the hotpoints changing whenever the mouse moves)? This would be more consistent with other drawing applications and allow hotpoints outside of the visible area of the object (e.g. corner hotpoints for ellipses).
You can try it to see what is easier. The hot points on a ellipse can be on the ellipse itself though.... On August 9, 2005 12:05 am, Rick Chern wrote: > hotpoints/outlines only when clicked on, and not lose focus unless another > object is clicked on (instead of the hotpoints changing whenever the mouse > moves)? This would be more consistent with other drawing applications and > allow hotpoints outside of the visible area of the object (e.g. corner > hotpoints for ellipses). _______________________________________________
On Monday 08 August 2005 18:28, Barth Netterfield wrote: > You can try it to see what is easier. The hot points on a ellipse can be > on the ellipse itself though.... I agree, give it a try and see what works best. (Perhaps inform us after why you made your choice...) One thing to keep in mind is performance. There are definitely flicker issues and extra repaints in layout mode especially. A choice that will help performance-wise is probably very welcome. Once we have all of the functionality we want, I think we need to go back into "QA" mode and do lots of performance testing and testcase writing.
A basic version of graphics view objects has been implemented. Summary of features/usage (some of this is carried over from previous layout mode behaviour): - the 3 zoom modes, layout mode, and the graphics drawing modes have been combined into one drop-down menu (with separators) on the toolbar, as only one can be active at a time Drawing Modes: -------------- - 5 drawing tools have been implemented: Label, Rectangle, Line, Picture, Arrow, Ellipse - to draw any of the graphics objects, select the corresponding drawing tool and drag anywhere in a window. Hold down SHIFT while dragging to maintain a 1:1 ratio (for labels, pictures, rectangles, and ellipses) or draw at 0, 45, 90,... degrees (for lines and arrows) - in any of the drawing modes, hold down CTRL to temporarily enter Layout Mode. This allows graphics objects to be resized, deleted, moved. Release CTRL to revert back to the previous drawing mode. This is useful for making small corrections after drawing an object. Layout Mode: ------------ - to enter layout mode, select Layout Mode from the dropdown menu on the toolbar. - single-click on any object to select it - the object's hotpoints will be displayed. For rectangular/elliptical type objects, this is 8 points (4 at the corners, 4 at the midpoints). Drag a hotpoint to resize the object in that direction. Hold down SHIFT while dragging to maintain the object's aspect ratio while resizing. For lines and arrows, hotpoints are shown on the 2 endpoints of the object. Drag a hotpoint to move that endpoint. Hold down SHIFT while dragging to maintain the slope of the line/arrow while moving the endpoint. - dragging on a non-hotpoint area of an object moves the object. Objects do not need to be first selected to be moved - the cursor changes to a 4-arrow cursor whenever a drag will move an object underneath. - hold down SHIFT and single-click on objects to select/deselect multiple objects. CTRL-A selects all objects; CTRL-SHIFT-A deselects all objects. Dragging where there is no object draws a rubber band to select multiple objects as well. Dragging any selected object will move all selected objects - a silhouette of the selected objects is shown as the objects are moved. - to group selected objects, right click on any selected object and choose Group. The group will be treated as a single object and be resized/moved as a single object. To ungroup, right-click on a group and select Ungroup. - double-click on an object to display the edit dialog for the object
Continuation of layout mode features: --------------------------------------- - hit DELETE to delete all selected objects - hit ESC to cancel a move/resize Continuation of drawing mode features: --------------------------------------- - hit ESC to cancel drawing of a new object
View objects have been implemented as described. Reassigning this bug to kst for additional features/changes.
I have tried out the new drawing features, and it's an amazing piece of work. I do have some usability issues which I'm going to detail, but I think this improvement is really great and will be one of the key new features in the next version ! Thanks for implementing it :-) I have sorted the issues into 2 categories: major (really needs to be adressed IMHO) and minor (sounds like a good idea to me, but not irritating enough to drive the average user crazy). Major issues: ************* M1) focus handling is very unusual and leads to many mistakes (which is all the worse as Ctrl+Z is not yet implemented !). The idea of an intermediate focus state and focus-follows-mouse sounded good, but I actually find it very confusing. I have often found myself moving the plot while I intended to move an object, or deleting the wrong object ! Instead of detailing the way focus handling should work, I'd suggest looking at how oodraw or inkscape or kpresenter do it (click to get focus + rotate mode on second click). It will also avoid a lot of flickering when moving the mouse around ! M2) objects get the focus only when hovering over a filled pixel, not the whole selection area (e.g. for the text "Label" you must click on a text pixel, if you click between the letter L and b but just above "a" it is not selected). For an unfilled rectangle, you have to click exactly on the line (don't set it to 0 width or the object becomes impossible to select!). M3) the snap to grid feature is more than annoying as it may prevent one from putting an object just where it should go. While snap-to-grid can be helpful, there should at least be an option to disable it (default to no snap ?). M4) when back in zoom mode, opaque objects prevent from starting a zoom action (and can not even be selected/moved/edited etc) M5) the picture tool should really allow more resizing options: I have tried inserting a logo, but the rectangle I had drawn was not the right size. The picture was distorted and getting it back to the right size/ratio is close to impossible. We could add three radiobuttons to the dialog: "fit width", "fit height" or "free form" (and resizing without Shift would set it to "free form"). M6) the context menu should be available in drawing mode. There is currently nothing attached to a RMB click, while it would often be _very_ convenient to be able to call up the same context menu as in layout mode. M7) rotating an object should be possible (I think it was actually planned ?), see oodraw or M1 for a hint how to switch from move/resize mode to rotate/shear (or at least rotate). Minor issues: ************* m1) double-clicking an object in drawing mode should open the edit dialog m2) pressing Ctrl while in drawing mode has no effect until the mouse is moved; it would be better if the effect was effective even without mouse movement as this temporary layout mode idea is cool but sort of hidden right now m3) change layout mode icon to 4 arrow cursor (or simple arrow cursor ?) m4) it should be possible to set opacity with a slider to any value in a 0%-100% range (useful to not hide curves completely while making annotations readable) m5) some flickering even when plots with no objects on top are changed (zoomed etc): it seems that drawing objects are repainted a bit too often m6) arrow keys could be used for pixel-accurate positioning of objects in layout mode
And how about the "flow around" property (see comment #10) ? Are there opinions out there on whether it is a good idea or not ?
On Tuesday 13 September 2005 12:41, Nicolas Brisset wrote: > 18:41 ------- And how about the "flow around" property (see comment #10) ? > Are there opinions out there on whether it is a good idea or not ? Layout functionality would be really nice. The hard part is making sure it doesn't interfere with the traditional Kst behaviour of always doing things "the way the user expects", for the most part. It traditionally "just worked" in that plots would always line up edge-to-edge, resize appropriately, etc. These new features blur the lines quite heavily. Maybe a good start would be to create a new view object that is purely a layout item the way Qt works, such as a grid or a box.
I don't so much like the idea of such a "complex" view object. I think it is not trivial for the average user to figure out how to use this sort of layout tool (try to remember the first time you used designer without having read the manual :-) !). I don't think that the "flow-around" property requires such extensive changes. In my idea, plots would be laid out as usual, only in a rectangle potentially smaller than the window, as all view objects with that property set would be used to determine the layout "bounding box". That box would simply be the biggest rectangle fitting from the center until any of these objects.
On September 13, 2005 06:24 pm, Nicolas Brisset wrote: > M1) ... intermediate focus state and focus-follows-mouse sounded good, > but I ... find it ... confusing.... I'd suggest looking > at inkscape..... Inscape provides feedback that you are over an object by changing the mouse icon. The problem we have w/ kst is that you are always in front of something (eg, a 2d plot) so clicking will always select something. The trick is to indicate what a click would select. I suspect that if M2 is fixed, the current focus mode will work better. > ! M2) objects get the focus only when hovering over a filled pixel..... This is the most serious UI bug, but needs to be solved differently for different objects. -Text should be selected for clicks within the bounding box. -transparent line objects should be selected for clicks within 5px of the line. Also, the hot points should be selected for drags within 5px of the centre of the hot point boxes. > M4) ...opaque objects prevent from starting a zoom action Yes. Bug. > M5) the picture tool should ... allow ... resizing options: > ... add three radiobuttons to the dialog: "fit width", > "fit height" or "free form" (and resizing without Shift would set it to > "free form"). also, in the rmb menu. > M6) the context menu should be available in drawing mode. And 'cleanup layout' should be in zoom modes, as mentioned elswhere. > M7) rotating an object should be possible (I think it was actually > planned ?) Inkscape's method works very well. It will require new shapes for the hot points. > > Minor issues: > ************* > m1) double-clicking an object in drawing mode should open the edit dialog yes. > m3) change layout mode icon to 4 arrow cursor (or simple arrow > cursor ?) It is isn't it? > m4) it should be possible to set opacity with a slider to any > value in a 0%-100% range (useful to not hide curves completely while making > annotations readable) Eventually, but not soon. > m6) arrow keys could be used for pixel-accurate > positioning of objects in layout mode nice idea.
On Wednesday 14 September 2005 11:56, netterfield@astro.utoronto.ca wrote: > > m4) it should be possible to set opacity with a slider to any > > value in a 0%-100% range (useful to not hide curves completely while > > making annotations readable) > > Eventually, but not soon. Highly unlikely since we don't have low-level support for it. :-)
> Inscape provides feedback that you are over an object by > changing the mouse icon. The problem we have w/ kst is that > you are always in front of something (eg, a 2d plot) so > clicking will always select something. The trick is to > indicate what a click would select. I suspect that if M2 is > fixed, the current focus mode will work better. Then, we can do it the way oodraw works: it does not indicate what object will be selected when you next click, and it actually works very well I think and is simpler.
26 comments in and we're off on quite a tangent now. We have the view objects finally, so the feature is implemented. There are tweaks to be done and bugs exist. Let's file them individually as they are a problem.
I could spend some time creating new entries for my comments, but is it worth the overhead ? The list is here already, and at least some of the remarks can probably be fixed in less time than it takes to go through a list of bugzilla entries... So, how should we proceed ?
On Wednesday 12 October 2005 03:13, Nicolas Brisset wrote: > 09:13 ------- I could spend some time creating new entries for my comments, > but is it worth the overhead ? The list is here already, and at least some > of the remarks can probably be fixed in less time than it takes to go > through a list of bugzilla entries... So, how should we proceed ? We still have the report history. Let's get some fixing done and see what remains. After a few weeks (assuming fixing happens in that timeframe) I think we can start opening bug reports.