Hi, Ernst Lippe <ernstl@xxxxxxxxx> writes: > 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. IMO the preview widget should only be the preview, nothing else. If possible it should expose two adjustments so that you can easily add scrollbars. Progress-bar, zoom-control and scrollbars don't belong to the preview widget itself. They can be added by a composite widget. > > 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. Using threads with GTK+ is a pain to get right and in almost all cases it is unnecessary. If an application has a need for threads it is desirable to code it in a way that assures that only one thread updates the GUI directly. That said, I don't think you need to worry about threads here. The solution I suggested would still be sufficiently thread-safe. > > 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. Why should a widget behave differently if changed by the user or programmatically via the API? That sounds like a broken concept. > > > 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. you will have to delegate the actual refresh to idle functions anyway so that shouldn't be a problem. Salut, Sven
