A Diumenge, 31 de gener de 2010, Hugo Pereira Da Costa va escriure: > On 01/31/2010 03:31 AM, Luigi Toscano wrote: > > Hugo Pereira Da Costa wrote: > >> On 01/30/2010 05:49 PM, Pino Toscano wrote: > >>> Alle domenica 31 gennaio 2010, Hugo Pereira Da Costa ha scritto: > >>>> To me, the plain background you get when calling autofillbackground > >>>> (using the palette.color( widget->backgroundrole() ), is a feature, > >>>> not a bug. > >>> > >>> See, color() != brush(). This Qt behaviour is basically bugging every > >>> widget which sets the autoFill and has the background role in the > >>> palette with something else than a color. > >> > >> ok, I agree with this. > >> > >> But that wont fix the issue with oxygen. its main window background is > >> not a brush, passed via the palette. > >> Maybe it could be made so (though I'm not sure about clipping), but it > >> is not at the moment. Right now its plain painting (with QPainter) in > >> re-implemented QEvent::Paint for appropriate (top level) widgets. > > > > I know that this removing the roots of the problem is the most > > complicated way, but... have you tried to talk to Oxygen (and/or Bespin) > > developers? > > As a matter of fact I've join the oxygen team about 6 month ago, based > on the success of the "nitrogen" window decoration in kde-look, and have > been the main (in terms of number of commits) developper for both the > style and the decoration since then for both implementing new features > and fixing bugs. Its a very nice group by the way. > > I have been thinking more about setting the oxygen background in the > palette and I am getting more and more convinced it might not be the > right thing to do, the main reason being that the background has to be > regenerated every time the window is resized, since it is neither > "scale", nor tiled, when one do so. This (the regeneration) is what is > being done now by re-implementing paintEvent. I'm not sure one wants to, > and even can, change the palette of all widgets of an app every time a > window is resized. Do we ? > > And besides, as Pino pointed out there is an underlying Qt bug/missing > feature behind it, that would make this change useless with current Qt. > > In any case, this is not the kind of changes I would intend to put in > the code just a few days before kde4.4 is released. I will investigate > further for kde4.5. > In the meanwhile, people should feel free to revert my 2 lines of change > in okular if they think it is too ugly of an hack. > > As a side note: I also realized yesterday that it is probably safe to > setAutoFillBackground( false ) in PrintPreviewMode (and leads to a much > nicer window). But I'm unclear if this window can be embedded in some > fancy looking background windows (apparently it cannot be in khtml, so > I'd say it cannot). Can anyone confirm/infirm ? If this is the case, I > guess I could commit a small tiny adendum to the previous patch.
PrintPreviewMode is only activated if you pass "Print/Preview" as part of the args when creating the part. This is at the moment only done in the print preview dialog. Albert > > Cheers, > > Hugo > > > Regards, > > _______________________________________________ > Okular-devel mailing list > Okular-devel@kde.org > https://mail.kde.org/mailman/listinfo/okular-devel > _______________________________________________ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
