On Sunday 07 March 2010 14:43:49 you wrote: > On Sunday 07 March 2010, Andrzej JR Hunt wrote: > > On Saturday 06 March 2010 18:52:52 Aaron J. Seigo wrote: > > > i don't think this will work very well because we will want the button > > > to overlap with the View of the containment (for visual reasons). > > > layouts prevent that kind of overlapping (that's mostly the point of > > > them :) and the position calculations in this case are not hard to do. > > > > I'm not sure if I'm understanding you corectly: are you suggesting that > > the buttons are drawn partly outside the area where the panel (i.e. > > containment) is drawn (in other words making the panel containment > > smaller than the view), and then drawing the additional background to > > make this > > there is the misunderstanding: right now the panel window -is- a view: it's > not something set on stone: the view itself can be layouted in the form > button-view-button, or more probably, the anel still being a view but with > its viewport shrinked to make room for the buttons I'm still slightly confused... Just to make sure I understand everything right: >From what I have seen the panel itself is a containment, this also does the painting of the panel, places the cashew on it, has the applet placed on it. The panelView is responsible for hiding/showing this etc: the panel is inside the view, and until now completely fills it. - Up until now I have only really added the buttons on top of the view. and have tried to get the panel (containment) to leave extra blank spaces so that the buttons have space (using setContentMargins()). This method however isn't particularly good because it places assumptions on the containment about its margins which shouldn't be made as not to break anything. (This method also doesn't work because of the cashew not moving...) - The suggested method is to make the panel containment smaller than the view, then adding the buttons in the empty space at either end of the view, and painting the background to make it one with the containment? (This would require rewriting all of the view's calls to resize the containment to leave the required space, and possibly to position it, since the containment isn't currently affected by the contents margins of the view, and the viewport margins of the view only affect the visible area, but not the actual size, of the panel containment. Alternatively the panel containment has to be made part of a layout inside the view.) - Putting the buttons as part of the containment -- but only the panel containment class, not the overall plasma:containment class -- (but leaving the hiding functions in the view) still isn't OK? (I was just thinking about this: the cashew and panel painting are all done by the containment: since the buttons themselves are a display/control issue, as opposed to the hiding which is a view issue, should they not also be dealt with by the containment?)
> > fit in? The one problem I can see there though are that I have to disable > > the rounded corners of the panel (I'll have a look to see how they are > > currently determined / set.). (The layout shouldn't make much of a > > difference in this method though, since at the moment it does exactly > > what my positioning calculations were doing.) > > you don't have to disable them, just paint -over- them, on compositing but > replacing wat that was already painted That isn't too difficult in itself, but if the cashew is showing I need to paint more of it on, since when the panel end is curved, the curve cuts off part of the cashew (it gets placed at the very end of the panel), but the panel now has the curve further away, so we need to fill in what wasn't painted with the extra parts of the cashew. Or does the compositing keep the border programaticallt separate from the contents of the panel (when drawn), so that I can somehow easily remove it? -- Andrzej JR Hunt -- andrzej (at) ahunt.org _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
