On Tuesday 19 August 2008, Ambroz Bizjak wrote:
> Aaron J. Seigo wrote:
> > what was the purpose of the change to Plasma::Applet::itemChange? it
> > doesn't
> > seem to harm anything, so it's now committed, but i'm wondering what it
> > fixed
> > (if anything?) for you.
>
> My handler for the Apple
Aaron J. Seigo wrote:
> what was the purpose of the change to Plasma::Applet::itemChange? it
> doesn't
> seem to harm anything, so it's now committed, but i'm wondering what it
> fixed
> (if anything?) for you.
My handler for the Applet::geometryChanged signal didn't see the applet's
new geometry()
On Monday 18 August 2008, Ambroz Bizjak wrote:
> I have further improved my layout code. Now it can use any of the four
> corners as the "static corner" instead of only top-left. This means if the
> screen shrinks for example, it is not only possible to make the right
> screen border push applets l
I have further improved my layout code. Now it can use any of the four
corners as the "static corner" instead of only top-left. This means if the
screen shrinks for example, it is not only possible to make the right
screen border push applets left, but also the left border push applets
right. And n
Alex wrote:
> Suppose the user adds a panel, causing an applet that is in the way to be
> "temporarily repositioned" as though it had just been added. Then, three
> weeks (or some other long amount of time) later, the user changes or
> removes
> the panel. Does the applet (which the user has left
On Wednesday 13 August 2008 23:11:54 Ambroz Bizjak wrote:
> - When the screen shrinks, it pushes applets that were left outside of the
> working area (partially or fully) inside the screen. When pushing an
> applet, items in its way are also pushed to make space. If the applet
> already overlappes
Ok, I consider my patch feature-complete now. From now on, it works
properly with panels and positions proxy widgets properly as well.
To summarize what it provides:
- It keeps a working area, that is the area between panels, and only
allows applets to be in there (e.g. if a panel is added on top,
> I've written some code to do resizing better.
Now it's more complete and can handle vertical resizing as well.
There are some problems, though:
- Proxy widgets may still be badly placed, as the initial size reported is
wrong. I was thinking that could be solved by waiting for their size to
change
> Currently, when the resolution decreases, affected applets are simply
> moved so they stay visible, possibly colliding with other applets. I am
> planning to make this smarter, so that those applets will be moved as
> well.
I've written some code to do resizing better. Though I must say it's been
Hi,
I have now written some code for a QGraphicsLayout for the desktop. It
does some simple position management of the applets on the desktop. First
is the placing of new applets, which uses the same code I have written
before. Second is handling screen size changes. It works somehow similar
to th
10 matches
Mail list logo