2008/10/15 Aaron J. Seigo <[EMAIL PROTECTED]>:
> other than shitty drivers? ;)
>
> hm.. if the containment is the right size and so is the view ... dunno;
> usually that's a driver issue. is it just physically cut off or is it just too
> small? if you are using kwin desktop effects, does it work be
On Wednesday 15 October 2008, Guillaume Pothier wrote:
> tell it to take a snapshot of the window under the cursor). The scene
> rect is also set correctly, and the containment also. So if the view's
> size, the containment's size and the scene rect are correct, is there
> anything else that could
t; +
> +QRect warea;
> +if (desktop < workarea.size())
> +{
> +warea = workarea[ desktop ];
> +}
> +else
> +{
> +kDebug() << "No such desktop" << desktop;
> +warea = kephal::ScreenUtils::desktopGeometr
<< desktop;
+warea = kephal::ScreenUtils::desktopGeometry();
+}
+
switch (opt)
{
case MaximizeArea:
>
> --Original Message------
> From: Guillaume Pothier
> Sender:
> To: plasma-devel@kde.org
> ReplyTo: plasma-devel@kde.org
> Se
ier
Sender:
To: plasma-devel@kde.org
ReplyTo: plasma-devel@kde.org
Sent: Oct 15, 2008 11:57
Subject: Re: Status of multi-monitor support
On Wed, Oct 15, 2008 at 2:18 PM, Aike J Sommer <[EMAIL PROTECTED]> wrote:
>> > I think the problem is kwin forcing plasma onto that size... I comm
On Wed, Oct 15, 2008 at 2:18 PM, Aike J Sommer <[EMAIL PROTECTED]> wrote:
>> > I think the problem is kwin forcing plasma onto that size... I commited a
>> > patch a while back to allow one root-window per screen, but this seems to
>> > not work on resizing!
>>
>> ugh ... what is kwin doing resizin
> > I think the problem is kwin forcing plasma onto that size... I commited a
> > patch a while back to allow one root-window per screen, but this seems to
> > not work on resizing!
>
> ugh ... what is kwin doing resizing anything in the first place?
if( isDesktop())
{
-> if (ge
2008/10/15 Aaron J. Seigo <[EMAIL PROTECTED]>:
> so something is misidentifying screen 0 when setting the geometry of the view.
> look in DesktopView::adjustSize; it's either getting the wrong screen() value
> or the wrong geometry for that screen.
As far as I can tell, adjustSize gets screen ids
On Wednesday 15 October 2008, Aike J Sommer wrote:
> Am Mittwoch 15 Oktober 2008 18:15:27 schrieb Guillaume Pothier:
> > Right, I have more information now, but I need some help. The problem
> > that manifests in the screenshot I sent earlier is that one
> > DesktopView occupies the whole display (
On Wed, Oct 15, 2008 at 1:27 PM, Aike J Sommer <[EMAIL PROTECTED]> wrote:
> I think the problem is kwin forcing plasma onto that size... I commited a
> patch a while back to allow one root-window per screen, but this seems to not
> work on resizing!
Where should I have a look? And what actually is
On Wednesday 15 October 2008, Guillaume Pothier wrote:
> Right, I have more information now, but I need some help. The problem
> that manifests in the screenshot I sent earlier is that one
> DesktopView occupies the whole display (ie both screens) instead of
> just one screen. Something causes it t
Am Mittwoch 15 Oktober 2008 18:15:27 schrieb Guillaume Pothier:
> Right, I have more information now, but I need some help. The problem
> that manifests in the screenshot I sent earlier is that one
> DesktopView occupies the whole display (ie both screens) instead of
> just one screen. Something ca
Right, I have more information now, but I need some help. The problem
that manifests in the screenshot I sent earlier is that one
DesktopView occupies the whole display (ie both screens) instead of
just one screen. Something causes it to resize to 3600x1200, which is
my whole desktop's geometry.
Ho
On Monday 13 October 2008, Guillaume Pothier wrote:
> Yes, but there is something broken somewhere, not related to my patch
> as it happened before I started hacking on that. You can see the
> problem in the screenshot I sent, something gets the geometries
> swapped: the large desktop, or at least
2008/10/13 Aaron J. Seigo <[EMAIL PROTECTED]>:
> so what you need to be concerned with is the size (not location) of the
> Containment, and setting that size in response to screen changes. currently in
> the plasma desktop shell, that happens in DesktopView::adjustSize() with the
> line:
>
>con
Am Montag 13 Oktober 2008 20:48:50 schrieb Aaron J. Seigo:
> On Friday 10 October 2008, Guillaume Pothier wrote:
> > http://pastebin.ca/1225015 (kdebase)
> > http://pastebin.ca/1225017 (playground/base)
>
> things that jump out at me:
>
> Cosistency with the rest of KDE libs:
>
> * the "kephal" nam
On Friday 10 October 2008, Guillaume Pothier wrote:
> http://pastebin.ca/1225015 (kdebase)
> http://pastebin.ca/1225017 (playground/base)
things that jump out at me:
Cosistency with the rest of KDE libs:
* the "kephal" namespace shoulde be "Kephal"
* instance() should be self()
Questions;
* wh
On Monday 13 October 2008, Guillaume Pothier wrote:
> Well, actually it seems that it is only the position of the
> containment in the corona... some containments are even further to the
> right, with x coordinates of about 3800.
yes, these are coordinates *on the scene*. think "model/view" where
On Fri, Oct 10, 2008 at 8:36 PM, Guillaume Pothier <[EMAIL PROTECTED]> wrote:
> However, the "1926" still bothers me. I am missing some pieces of the
> puzzle here:
> - That 1920x1200 screen is on the right of a 1680x1050 screen, so I
> would have assumed that it should be 1686, not 1926. And actu
On Friday 10 October 2008, Guillaume Pothier wrote:
> I need help with the containments' coordinate system. Adjusting view
> sizes don't work as expected. Here is a commented log of plasma when I
> resize a screen from 1920x1200 to 1280x800 and then back to 1920x1200:
ok, so here's how it works:
On Thursday 09 October 2008, Guillaume Pothier wrote:
> Hi, I'm starting to get a better idea of how all of this works now. I
> started hacking on plasmaapp. Kephal will actually make the code
> simpler as it provides finer-grained signals (screen added, removed,
> moved, resized), so the behavior
I need help with the containments' coordinate system. Adjusting view
sizes don't work as expected. Here is a commented log of plasma when I
resize a screen from 1920x1200 to 1280x800 and then back to 1920x1200:
First resize:
plasma(18904) PlasmaApp::screenResized: 0 QSize(1920, 1200) QSize(1280,
On Fri, Oct 10, 2008 at 2:42 AM, Aike J Sommer <[EMAIL PROTECTED]> wrote:
> Kephal uses int's as ids for the screens, so i guess its best to just stick
> with using int's...
Ok, I just replaced all the uses of QDesktopWidget by kephal in the
desktop shell, keeping the ints for screen ids. There ar
Am Freitag, 10. Oktober 2008 06:49:32 schrieb Guillaume Pothier:
> Hi, I'm starting to get a better idea of how all of this works now. I
> started hacking on plasmaapp. Kephal will actually make the code
> simpler as it provides finer-grained signals (screen added, removed,
> moved, resized), so th
Hi, I'm starting to get a better idea of how all of this works now. I
started hacking on plasmaapp. Kephal will actually make the code
simpler as it provides finer-grained signals (screen added, removed,
moved, resized), so the behavior of adjustSize can actually be split
between the corresponding
2008/10/9 Aaron J. Seigo <[EMAIL PROTECTED]>:
>
> unless there's a common use case where massive rearrangement of the monitors
> is a commonplace action, i don't see the need to change the current code or
> make it more complex than it already is.
Ok, agreed. Anyway this is far from being a priori
On Thursday 09 October 2008, Guillaume Pothier wrote:
> 2008/10/9 Aaron J. Seigo <[EMAIL PROTECTED]>:
> > we store the arrangement of panels and resize the views, but we don't
> > mess with the layouts. that seems a bit overkill. if you want different
> > layouts, perhaps use different Activities.
2008/10/9 Aaron J. Seigo <[EMAIL PROTECTED]>:
>
> we store the arrangement of panels and resize the views, but we don't mess
> with the layouts. that seems a bit overkill. if you want different layouts,
> perhaps use different Activities.
Maybe there could be an automatic switching of activities b
On Thu, Oct 9, 2008 at 3:51 PM, Aike J Sommer <[EMAIL PROTECTED]> wrote:
>
> Well... I have the dbus-api wrapped in a library, which makes for a little
> easier integration and will also not cause any errors if for some reason
> kephal is not available over dbus!
Cool, so this means that the libra
Am Donnerstag 09 Oktober 2008 20:48:14 schrieb Guillaume Pothier:
> On Thu, Oct 9, 2008 at 1:42 PM, Aike J Sommer <[EMAIL PROTECTED]> wrote:
> > Im not really sure what the next steps should be. It shouldnt be that
> > much work to get kephals signals hooked into plasma, but where should i
> > star
Am Donnerstag 09 Oktober 2008 20:45:47 schrieb Aaron J. Seigo:
> On Thursday 09 October 2008, Aike J Sommer wrote:
> > Im not really sure what the next steps should be. It shouldnt be that
> > much work to get kephals signals hooked into plasma, but where should i
> > start with that? Create a copy
On Thursday 09 October 2008, Guillaume Pothier wrote:
> 2008/10/9 Aaron J. Seigo <[EMAIL PROTECTED]>:
> > how much is the applet required to make kephal useful for plasma? can
> > kephal be used as just a notifier of screen layouts, or does it also need
> > to manage them? if it can be used as just
2008/10/9 Aaron J. Seigo <[EMAIL PROTECTED]>:
> how much is the applet required to make kephal useful for plasma? can kephal
> be used as just a notifier of screen layouts, or does it also need to manage
> them? if it can be used as just a notifier (what we have now with
> QDesktopWidget, right?) t
2008/10/9 Aaron J. Seigo <[EMAIL PROTECTED]>:
>
> i guess that brings us back to the real question: is kephal going to make it
> for 4.2? if so, let's not spend our time on workarounds, but on getting kephal
> and plasma working together.
I agree, anyway the patch didn't bring much good ;-)
g
>
>
On Thu, Oct 9, 2008 at 1:42 PM, Aike J Sommer <[EMAIL PROTECTED]> wrote:
>
> Im not really sure what the next steps should be. It shouldnt be that much
> work to get kephals signals hooked into plasma, but where should i start with
> that? Create a copy of plasma(-the-app) in playground? Or only wo
On Thursday 09 October 2008, Aike J Sommer wrote:
> Im not really sure what the next steps should be. It shouldnt be that much
> work to get kephals signals hooked into plasma, but where should i start
> with that? Create a copy of plasma(-the-app) in playground? Or only work
> locally and send dif
Am Donnerstag 09 Oktober 2008 15:45:33 schrieb Guillaume Pothier:
> > BTW: Sorry for the delays, been covered in some "work-stuff"... I got
> > kephal almost as a kded module, now i only need to figure out why cmake
> > segfaults on me after rebuilding kde! Any ideas? Anybody experience the
> > sam
> > Anyway, I'll re-apply the workaround patch I sent before, to see if it
> > is still useful (it reconfigured all the screens instead of
> > reconfiguring only one when adjustSize was called). If it works, it
> > might be a good idea to include it until a kephal is moved out of
> > playground.
>
On Thursday 09 October 2008, Guillaume Pothier wrote:
> I guess the right thing to do would be to listen to kephal signals
> instead of QDesktopWidget ones?
once kephal is available, yes.
> How would communication work in that case? dbus?
i assume so, yes.
> Anyway, I'll re-apply the workaround
2008/10/8 Aaron J. Seigo <[EMAIL PROTECTED]>:
>> On the other hand, the shell does not react well to configuration
>> changes. It is necessary to restart plasma when a monitor is
>> added/removed.
>
> there is code to handle this, actually. but we've never had the signals to
> actually test it and
> BTW: Sorry for the delays, been covered in some "work-stuff"... I got kephal
> almost as a kded module, now i only need to figure out why cmake segfaults on
> me after rebuilding kde! Any ideas? Anybody experience the same when trying
> to build screenmanagement in plasmas playground?
I had the
> > Aike told me Seli is working on that.
>
> Seli is working on plasma? or just working on making kwin not interfere
> with screen change announcements?
He had plans to "iron out" a few of those problems (of plasma and kwin) for
the upcoming opensuse 11.1. Dont know what the state of that is ho
Hi all!!
> select their placement (left-of, right-of, clone, etc). I'm not sure
> about rotation (Aike?). Heavier testing and polishing is probably
Rotation is working as far as i can tell... I had a few issues when i tried
it, but those seemed to be more related to my combination of drivers!
Pl
On Wednesday 08 October 2008, Guillaume Pothier wrote:
> I am very interested in having multi-monitor support working in KDE. I
it's probably good to define what is meant by "multi-monitor".
right now we support multi-screen systems running under the same X server,
e.g. xinerama.
we do not supp
44 matches
Mail list logo