I heard Gordon Tyler said: > So these other subwidgets stay still while this one other widget > needs to scroll? I feel cross-eyed already ;)
Yes. I'm trying to see how cleanly I could implement that nifty feature in KMuddy, split-screen on scrollback, that splits the viewport when the users scrolls back to let him keep an eye on what is going on in the game while he searches his history. Their implementation works, but seems a bit kludgy -- for instance, when it is shown, the bottom text area's frame covers the edge of the scrollbar. So I'm trying to come up with something cleaner. > So why don't you just wrap this one subwidget in a scrollview? Because the bottom text area will or will not be shown depending on whether the user is currently scrolling back or not. The scrollbar must thus cover /both/ text areas. If you make it cover only the upper text area, the one that is scrolling back, then that scrollbar will be suddenly resized under the user's pointer when the bottom text area is shown. Not good. > If your scrolling subwidget has a custom paintEvent handler, then > maybe you can tie the scrollbar's value to a y-offset that's applied > to all the drawing operations in the paintEvent handler? Could be an idea. Maybe I'll also read the source code of Kompare, which does some real nifty scrollbar magic. -- S. _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde