On 26 Feb 2003 14:24:17 +0100 Sven Neumann <sven@xxxxxxxx> wrote: > Hi, > > Ernst Lippe <ernstl@xxxxxxxxx> writes: > > > There are two possible GUI styles: dragging in the preview and using > > scrollbars. These could also be combined. > > > > Open issue: Scrollbars make the widget visually bigger and makes its > > internal structure more complicated. The alternative of giving the > > preview widget two GtkAdjustments, that can be used by the developer to > > "wrap" the widget with scroll-bars, does not work when the preview > > widget has a visible scroll-bar and/or zoom controls. Scroll-bars > > will not be supported in the first release of the preview widget. > > I don't understand the problem here. IMO using two adjustments to > control the displayed area is very convenient and makes it perfectly > easy to add scroll-bars. I'd suggest you try to come up with an API > that uses adjustments. Perhaps you could outlines what problems you > see here. The point is the following. In the current implementation the preview widget consists of the following components from top to bottom: the image, the progress bar and the zoom controls. When scrollbars should be added the horizontal scrollbar should be located between the progress bar and the image. So it is not possible to add scrollbars by simply wrapping the entire current preview but the preview itself must be modified. Adding scrollbars makes the layout algorithm more complex. I am not a great fan of using scrollbars for the preview. They make the widget a lot bigger and scrollbars are not easy to use with small previews. When there really is an overwhelming demand for scrollbars, we will probably add them. BTW, the most recent implementation uses adjustments for the position and the scale. > > Open issue: What should the GUI look like? A commonly used approach is > > to have a "+" and "-" button and a label to show the current scale. > > Another suggestion was to use spin-buttons. Because it seems most > > desirable that the scaling factors are more or less exponential the > > standard Gtk spinbuttons are not very useful. The first release of > > the preview widget will use "+" and "-" buttons. > > please consider to use the icons provided by GTK+: > > http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-ZOOM-IN-CAPS > http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-ZOOM-OUT-CAPS OK. > > Requirement 10. The preview must emit a signal when the user has > > scrolled or zoomed the preview. > > > > This signal can be used to synchronize multiple previews (e.g. see > > Filter Pack). This signal should contain information about the new > > position and/or scale. This signal will be emitted before the preview > > attempts to update the rendered image. The signal will only be > > emitted when the preview was scrolled by the user via the GUI. The > > signal will not be emitted when scrolling or zooming through the API. > > I'd suggest not to include information about the new position and/or > scale in the signal but to provide a way to retrieve this information > from the preview widget. This is just my default multi-threading paranoia. When you have multiple variables that can be updated in a multi-threading environment, it is in general wise to use copies that are known to be consistent with one another. I don't really know how Gtk uses threading, so perhaps it is not useful to include the information. > Actually if you go for two adjustments and > expose them in your API you don't need to deal with signals at all > since it should be sufficient to connect to the "value_changed" and > "changed" signals of the two adjustments. The reason for a separate signal is that this makes it possible to distinguish between between modifications that are initiated by the user via the preview GUI and modifications that were initiated programmatically via the API. When this distinction is never important the requirement could be dropped. > > Requirement 12. The preview must support an API to scroll the preview > > and change the magnification. > > > > This functionality is needed to synchronize multiple previews. > > and again you get this all for free if you go for two adjustments. > Synchronizing two previews would boil down to synchronizing the > preview's adjustements. When you have an API call to change both coordinates at the same time, this makes it easier to avoid unnecessary refreshes, otherwise the widget might try to refresh itself between modification of the first and second coordinate. greetings, Ernst
