Thanks for your email, I just asked yesterday morning Vincent about
the status of the dbus-based branch and this answers my questions.
William Jon McCann wrote:
I agree with that. Logout handling is broken too. The XSMP protocol
not only allows applications to be notified on logout (aka
On Wed, 2008-06-25 at 19:07 -0400, William Jon McCann wrote:
Hi,
Dan Winship and Lucas Rocha have done a nice job revamping the
gnome-session codebase. It was a meritorious task. You can read
about the design here:
http://live.gnome.org/SessionManagement/NewGnomeSession
What do you
On Thu, 2008-06-26 at 12:41 +1200, Callum McKenzie wrote:
On Thu, June 26, 2008 11:07 am, William Jon McCann wrote:
I don't think these are sufficient reasons to continue to solely rely
on XSMP. We can do these very well using D-Bus.
Can I assume from your use of the word solely that
Apropos, since we are talking about session management here: have you
guys ever thought of reuseíng upstart for managing session processes?
My thoughts exactly. We should at least talk to the upstart guys about
what code we can share.
___
I'm sorry if I missed something (I just woke up and my eyes and brain
aren't at 100% yet)...
Doing the startup in phases like that sounds to me to be suboptimal.
If we're halting the startup of a whole Desktop (or even Panel)
process just because we don't have a WM ready, it's going to add a lot
On Thu, Jun 26, 2008 at 3:43 PM, Alexander Jones [EMAIL PROTECTED] wrote:
* Currently, gnome-terminal starts up before the WM and if you run a
compositing WM, you get an RGB window unless you close it and open it
again.
That's because the gnome-terminal crew did an awesome job making sure
it
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an example. :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an example. :)
Guess Metacity's compositor needs to become much
On Thu, 2008-06-26 at 17:28 +0200, Patryk Zawadzki wrote:
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an
On Thu, Jun 26, 2008 at 5:37 PM, Jürg Billeter [EMAIL PROTECTED] wrote:
On Thu, 2008-06-26 at 17:28 +0200, Patryk Zawadzki wrote:
* replacing the current compositor with a GL-based one; or
Please don't. I really want compositing but I can't use a GL-based one
on all systems, as for example
Hi,
Jürg Billeter wrote:
I really want compositing but I can't use a GL-based one
on all systems, as for example even with some recent Intel desktop
mainboards you can't have DRI with a screen area larger than 2048x2048,
which is easily reached with two monitors.
I don't mean to be
Hi,
On Thu, 2008-06-26 at 17:55 +0200, Dave Neary wrote:
Jürg Billeter wrote:
I really want compositing but I can't use a GL-based one
on all systems, as for example even with some recent Intel desktop
mainboards you can't have DRI with a screen area larger than 2048x2048,
which is
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an example. :)
Guess Metacity's compositor needs to become much
On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens if we decide not to?
David
___
desktop-devel-list mailing list
On Thu, Jun 26, 2008 at 6:25 PM, Iain * [EMAIL PROTECTED] wrote:
If you are one of those people with a crap graphics card (or drivers)
I have been working on getting a strange hybrid compositor working
that I'm assuming should be much faster
so that you can have simple compositing to give
On Thu, 2008-06-26 at 17:25 +0100, Iain * wrote:
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an example. :)
I don't mean to be impertinent, but isn't any screen bigger than
2048x2048 a major edge case? It's like desktop apps that only work on
screens bigger than 640x480... who cares at this stage? By the time
that's anything bug an edge case, won't the hardware have caught up?
It's far from an edge
On Thu, 2008-06-26 at 20:09 +0300, Karl Lattimer wrote:
I'm assuming you've turned on the appropriate xorg configuration
options to enable the correct acceleration
and none of that helped? I forget what they are, but I'm sure someone
will chime in.
ching
Section Extensions
On Thu, 2008-06-26 at 18:57 +0100, Ross Burton wrote:
On Thu, 2008-06-26 at 20:09 +0300, Karl Lattimer wrote:
I'm assuming you've turned on the appropriate xorg configuration
options to enable the correct acceleration
and none of that helped? I forget what they are, but I'm sure someone
On 6/26/08, David Zeuthen [EMAIL PROTECTED] wrote:
On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens if we decide not to?
Tell them we are now using a better idea and that they
Am Donnerstag, den 26.06.2008, 17:55 +0200 schrieb Dave Neary:
Hi,
Jürg Billeter wrote:
I really want compositing but I can't use a GL-based one
on all systems, as for example even with some recent Intel desktop
mainboards you can't have DRI with a screen area larger than 2048x2048,
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Laptop with 1280x768 wides screen LCD plus external monitor or projector
with 1024x768 resolution gives 2304x768 pixels. This setup absolutely
doesn't look exotic for me, but requires more than 2048 horizontal
pixels. When writing this I am
On Thu, 2008-06-26 at 18:02 +0100, Alan Cox wrote:
It's far from an edge case. Any situation with two monitors side by side
of 1024 pixel width causes the problem. Thats a pretty normal setup for
anyone doing art design, engineering or similar work.
Indeed.
(And yes I agree the
Am Donnerstag, den 26.06.2008, 17:25 +0100 schrieb Iain *:
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an
On Thu, Jun 26, 2008 at 6:13 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
I'd say for me the only essential feature of a compositor is not
watching the goddamn windows redraw each time you switch apps and
workspaces.
Then you don't need a compositor
Turn it off. problem solved.
On Thu, Jun 26, 2008 at 6:09 PM, Karl Lattimer [EMAIL PROTECTED] wrote:
Have you looked at xcompmgr? it might be a good starting point. I have
somewhere a hacked up version of xcompmgr which has some extra features.
Let me know if you'd like it.
Good idea, wish I'd thought of that first...
David Zeuthen wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens if we decide not to?
Yes we do; at least I believe so. I won't complain about my xterms as
they may be considered a legacy application but modern applications
On Thu, Jun 26, 2008 at 11:41 PM, Iain * [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 6:13 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
I'd say for me the only essential feature of a compositor is not
watching the goddamn windows redraw each time you switch apps and
workspaces.
Then you
On Thu, Jun 26, 2008 at 10:49 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Nah, one thing about a compositor is that it keeps off-screen copies
of all the windows so it does not have to invalidate regions when the
stacking order changes.
To be totally honest, I've never really thought of that
On Thu, 2008-06-26 at 12:40 -0400, David Zeuthen wrote:
On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens if we decide not to?
well, we'll get tons of bug reports about KDE apps
William Jon McCann wrote:
Hi,
Dan Winship and Lucas Rocha have done a nice job revamping the
gnome-session codebase. It was a meritorious task. You can read
about the design here:
http://live.gnome.org/SessionManagement/NewGnomeSession
The new code is much cleaner. Parts of the new design
On Thu, 2008-06-26 at 23:02 +0100, Iain * wrote:
On Thu, Jun 26, 2008 at 10:49 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Nah, one thing about a compositor is that it keeps off-screen copies
of all the windows so it does not have to invalidate regions when the
stacking order changes.
On Thu, 2008-06-26 at 23:02 +0100, Iain * wrote:
On Thu, Jun 26, 2008 at 10:49 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Nah, one thing about a compositor is that it keeps off-screen copies
of all the windows so it does not have to invalidate regions when the
stacking order changes.
On Thu, 2008-06-26 at 23:46 +0200, Frederic Peters wrote:
Yes we do; at least I believe so. I won't complain about my xterms as
they may be considered a legacy application but modern applications
written for the other major free desktop should not be left in the
cold.
Do you have a concrete
On Fri, Jun 27, 2008 at 12:08 AM, Bastien Nocera [EMAIL PROTECTED] wrote:
I think Patryk was thinking more of the case where the application
hangs and doesn't redraw. Which looks really bad. Compositors fix
that.
Exactly - that's the most common scenario - app X is bound to IO and
it won't
On Thu, Jun 26, 2008 at 11:34 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Exactly - that's the most common scenario - app X is bound to IO and
it won't receive redraw requests until another app stops trashing the
disk.
I'd suggest that thats a broken application that should be fixed,
rather
On Fri, Jun 27, 2008 at 12:51 AM, Iain * [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 11:34 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Exactly - that's the most common scenario - app X is bound to IO and
it won't receive redraw requests until another app stops trashing the
disk.
I'd
David Zeuthen wrote:
Yes we do; at least I believe so. I won't complain about my xterms as
they may be considered a legacy application but modern applications
written for the other major free desktop should not be left in the
cold.
Do you have a concrete example of a modern desktop
On Thu, Jun 26, 2008 at 11:59 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Well even if you try to read just a 10k file you can get stuck if
another application is causing excessive IO (and I tend to run such
applications). It's hard to delegate each disk operation to a separate
thread just
On Fri, 2008-06-27 at 01:08 +0200, Frederic Peters wrote:
David Zeuthen wrote:
Yes we do; at least I believe so. I won't complain about my xterms as
they may be considered a legacy application but modern applications
written for the other major free desktop should not be left in the
On Fri, 2008-06-27 at 00:59 +0200, Patryk Zawadzki wrote:
Well even if you try to read just a 10k file you can get stuck if
another application is causing excessive IO (and I tend to run such
applications). It's hard to delegate each disk operation to a separate
thread just in case the
On Fri, 2008-06-27 at 00:05 +0200, Rodrigo Moya wrote:
of course, instead of supporting XSMP, we could try to get KDE use
William's new implementation
Even that will take time. They still have a lot of work to finish
porting apps to KDE4[1]. So while this is a good idea, it should be made
sure
I've been very happy with stable and trunk Metacity with compositing
enabled, but the 2-3 second pause to redraw windows when changing
workspaces is really staggering.
On Thu, 2008-06-26 at 17:43 +0200, Patryk Zawadzki wrote:
Metacity's compositor works pretty well here except for slow
43 matches
Mail list logo
