On Thu, Oct 30, 2008 at 2:40 AM, Rui Tiago Cação Matos
<[EMAIL PROTECTED]> wrote:
> 2. Make GTK able to draw the window frame client side. At first sight,
> this could be done in GtkWindow.
>
> Kristian Hoegsberg has a nice analysis of this at
> http://people.freedesktop.org/~krh/client-side-decor
Let's try again, there seems to be some common ground here. Even if small.
2008/10/27 Iain <[EMAIL PROTECTED]>:
> Thats a pretty large jump from what you are proposing, which is
> essentially remove the -private from the library name
> and advertise the API.
Ok, there are 2 orthogonal issues:
1.
On Tue, 2008-10-28 at 20:03 -0400, Allin Cottrell wrote:
> As I mentioned before, I can run xclock without window decorations
> just fine under Sawfish, but not under Metacity -- that's the
> relevance to this thread. (That is, if you want a functional
> desktop analog clock: forget it, if you'
On Tue, 28 Oct 2008, Thomas Thurman wrote:
> Ysgrifennodd Allin Cottrell:
> > "You are not running under a composited desktop-environment (e.g.
> > compiz). cairo-clock cannot work properly without one."
>
> I think you have compositing turned off. Do this:
>
> gconftool -s /apps/metacity/gene
Ysgrifennodd Allin Cottrell:
> "You are not running under a composited desktop-environment (e.g.
> compiz). cairo-clock cannot work properly without one."
I think you have compositing turned off. Do this:
gconftool -s /apps/metacity/general/compositing_manager -t bool true
Thomas
--
Thomas T
On Tue, 28 Oct 2008, Thomas Thurman wrote:
> Ysgrifennodd Allin Cottrell:
> > On Tue, 28 Oct 2008, Thomas Thurman wrote:
> > > Who mentioned compiz? This was about reasons not to run metacity.
> >
> > Nobody explicitly mentioned compiz, but when I followed up the
> > link to cairo-clock which I
Ysgrifennodd Allin Cottrell:
> On Tue, 28 Oct 2008, Thomas Thurman wrote:
> > Who mentioned compiz? This was about reasons not to run metacity.
>
> Nobody explicitly mentioned compiz, but when I followed up the
> link to cairo-clock which I was offered (and which I reproduced in
> my posting) i
On Tue, 28 Oct 2008, Thomas Thurman wrote:
> Ysgrifennodd Allin Cottrell:
> > On Tue, 28 Oct 2008, Xavier Bestel wrote:
> > > Did you try cairo-clock ?
> > > http://macslow.thepimp.net/?page_id=23
> >
> > Disclaimer: I'm an old fart and a grouch. But I really, really
> > don't want to have to r
On Tue, 2008-10-28 at 19:09 -0400, Allin Cottrell wrote:
> On Tue, 28 Oct 2008, Xavier Bestel wrote:
>
> > Hi Allin,
> >
> > On Mon, 2008-10-27 at 20:34 -0400, Allin Cottrell wrote:
> > > 1) I like to run an analog clock on my desktop...
> >
> > Did you try cairo-clock ?
> > http://macslow.thepi
Ysgrifennodd Allin Cottrell:
> On Tue, 28 Oct 2008, Xavier Bestel wrote:
> > Did you try cairo-clock ?
> > http://macslow.thepimp.net/?page_id=23
>
> Disclaimer: I'm an old fart and a grouch. But I really, really
> don't want to have to run compiz just to get an analog clock! I
> want my CPU cy
On Tue, 28 Oct 2008, Xavier Bestel wrote:
> Hi Allin,
>
> On Mon, 2008-10-27 at 20:34 -0400, Allin Cottrell wrote:
> > 1) I like to run an analog clock on my desktop...
>
> Did you try cairo-clock ?
> http://macslow.thepimp.net/?page_id=23
Disclaimer: I'm an old fart and a grouch. But I really
Ysgrifennodd Tim Evans:
> So in theory identifying "the same" window is a solved problem, but do many
> applications actually set the window role?
gtk_window_set_role() sets WM_WINDOW_ROLE, which is defined in ICCCM
sec. 5.1: http://tronche.com/gui/x/icccm/sec-5.html . It's supposed to
be used
Thomas Thurman wrote:
Christoph and Allin raise the question of the placement of an
application's windows on the same desktop every time the application
starts. This is known as "window matching", and there is currently no
good way to do it. The subject turns out to be on-topic for this list.
On Tue, 2008-10-28 at 08:03 +0200, Kalle Vahlman wrote:
> 2008/10/27 John Stowers <[EMAIL PROTECTED]>:
> > On Mon, 2008-10-27 at 11:44 +0100, Steve Frécinaux wrote:
> >> Ross Burton wrote:
> >>
> >> > Adding _NET_WM_CONTEXT_TOOLBAR sounds like it should be fairly simple to
> >> > do, especially wit
On Tue, Oct 28, 2008 at 4:02 AM, Christoph Burgdorf
<[EMAIL PROTECTED]> wrote:
> I would like to echo a demand fort hat in gnome. Choosing on which vDesktop
> an app would start is something I have been missing since I became familiar
> with the concept of vDesktops in Linux.
There are some plan
enstag, 28. Oktober 2008 14:04
An: Christoph Burgdorf
Cc: Thomas Thurman
Betreff: Re: Placing on desktops (was: Theme patriation)
Ysgrifennodd Christoph Burgdorf:
> unfortunately I'm not that deeply into the toolkit (yet). But maybe
> you can try to explain why it must recognise "the
Christoph and Allin raise the question of the placement of an
application's windows on the same desktop every time the application
starts. This is known as "window matching", and there is currently no
good way to do it. The subject turns out to be on-topic for this list.
What people want is f
Hi Allin,
On Mon, 2008-10-27 at 20:34 -0400, Allin Cottrell wrote:
> 1) I like to run an analog clock on my desktop. Gnome doesn't
> provide one, but xclock works fine. But xclock looks stupid with
> window decorations, you want it to blend with the background.
> Using sawfish, it's trivial
n a
normal user would understand it that way...
Bye
Christoph
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Allin Cottrell
Gesendet: Dienstag, 28. Oktober 2008 01:34
An: Iain *
Cc: gtk-devel-list@gnome.org
Betreff: Re: Theme patriation
On Mon,
2008/10/27 John Stowers <[EMAIL PROTECTED]>:
> On Mon, 2008-10-27 at 11:44 +0100, Steve Frécinaux wrote:
>> Ross Burton wrote:
>>
>> > Adding _NET_WM_CONTEXT_TOOLBAR sounds like it should be fairly simple to
>> > do, especially with a GTK+ utility function to mark a toolbar as the
>> > "main" toolb
On Mon, 27 Oct 2008, Iain * wrote:
> On Mon, Oct 27, 2008 at 1:12 PM, Rui Tiago Cação Matos
> <[EMAIL PROTECTED]> wrote:
> > 2008/10/27 Allin Cottrell <[EMAIL PROTECTED]>:
> >>> IMO decorating a window belongs in the WM, not all X applications use
> >>> GTK as rendering toolkit...
> >>
> >> And no
On Mon, 2008-10-27 at 11:44 +0100, Steve Frécinaux wrote:
> Ross Burton wrote:
>
> > Adding _NET_WM_CONTEXT_TOOLBAR sounds like it should be fairly simple to
> > do, especially with a GTK+ utility function to mark a toolbar as the
> > "main" toolbar.
>
> The same can be done for menu-bar for os-x
On Mon, Oct 27, 2008 at 1:37 PM, David Zeuthen <[EMAIL PROTECTED]> wrote:
> Yes. I think making the window decoration code available to apps is a
> Good Thing(tm);
To make it clear, I don't think this is a bad idea (and we already
have this, in the abysmally named libmetacity-private),
but this w
On Sun, 2008-10-26 at 18:38 -0400, Thomas Thurman wrote:
> Do you think this is a good plan?
Yes. I think making the window decoration code available to apps is a
Good Thing(tm); without that it's going to be hard for enterprising app
writers (e.g. those who dare to question the establishment) to
On Mon, Oct 27, 2008 at 1:12 PM, Rui Tiago Cação Matos
<[EMAIL PROTECTED]> wrote:
> 2008/10/27 Allin Cottrell <[EMAIL PROTECTED]>:
>>> IMO decorating a window belongs in the WM, not all X applications use
>>> GTK as rendering toolkit...
>>
>> And not all users of gnome use Metacity as WM.
>
> IIUC
2008/10/27 Allin Cottrell <[EMAIL PROTECTED]>:
>> IMO decorating a window belongs in the WM, not all X applications use
>> GTK as rendering toolkit...
>
> And not all users of gnome use Metacity as WM.
IIUC from Owen's post[1] and things really end up going that way, you
won't have much coice. And
On Sun, Oct 26, 2008 at 11:38 PM, Thomas Thurman <[EMAIL PROTECTED]> wrote:
> Several people have raised the idea recently that the responsibility for
> drawing window borders might better lie with the application than the
> window manager. The idea goes something like this:
>
> 1. The window bor
On Mon, 27 Oct 2008, Jacob Kroon wrote:
> On Mon, Oct 27, 2008 at 10:46 AM, Rui Tiago Cação Matos
> <[EMAIL PROTECTED]> wrote:
> > 2008/10/26 Thomas Thurman <[EMAIL PROTECTED]>:
> >> 1. The window border theme parsing and displaying code should live in a
> >> library. (It already does, but its A
On Sun, 26 Oct 2008 18:38:01 -0400
Thomas Thurman <[EMAIL PROTECTED]> wrote:
> Possibly the library could be clever enough to understand more than one
> theme format. Eventually it would probably be best to split it away
> from Metacity entirely.
>
> Do you think this is a good plan?
I don't
On Mon, Oct 27, 2008 at 10:59 AM, Steve Frécinaux <[EMAIL PROTECTED]> wrote:
> Thinking from a linux-centric viewpoint, it would make it possible for us to
> implement that sort of things:
> http://tango.freedesktop.org/Window_Experiments
I don't see anything there that would require the applicat
Jacob Kroon wrote:
IMO decorating a window belongs in the WM, not all X applications use
GTK as rendering toolkit...
And all GTK users do not use metacity. But if we always stick to that
kind of arguments, we can never go forward. I'd just say "let's keep
practical and backward compatible".
Ross Burton wrote:
Adding _NET_WM_CONTEXT_TOOLBAR sounds like it should be fairly simple to
do, especially with a GTK+ utility function to mark a toolbar as the
"main" toolbar.
The same can be done for menu-bar for os-x-likeness addicts.
By the way, this could be solved easily using a GtkAppW
2008/10/27 Iain * <[EMAIL PROTECTED]>:
> * If a program hangs, the user cannot close the window
The WM could detect this like it already does and draw a dialog over the window.
> * each program needs a copy of the theme parsed in memory, the images
> created in memory
> * theme caches (what littl
On Mon, Oct 27, 2008 at 10:46 AM, Rui Tiago Cação Matos
<[EMAIL PROTECTED]> wrote:
> 2008/10/26 Thomas Thurman <[EMAIL PROTECTED]>:
>> 1. The window border theme parsing and displaying code should live in a
>> library. (It already does, but its ABI is allegedly private, though in
>> practice Comp
2008/10/26 Thomas Thurman <[EMAIL PROTECTED]>:
> 1. The window border theme parsing and displaying code should live in a
> library. (It already does, but its ABI is allegedly private, though in
> practice Compiz binds against it anyway. For this we will need to make
> it public.)
>
> 2. When an
On Sun, 2008-10-26 at 18:38 -0400, Thomas Thurman wrote:
> This would mean that the themes could interact better with the contents
> of the window. For example, it would become easy to add a button like
> the oval button on an OS X window which hides the toolbar.
You can do this by extending th
2008/10/27 Iain * <[EMAIL PROTECTED]>:
> On Sun, Oct 26, 2008 at 10:38 PM, Thomas Thurman <[EMAIL PROTECTED]> wrote:
>>
>> Do you think this is a good plan?
>>
>
> In short: no.
Basically, I'm with Iain on this for largely the same reasons.
Also, if you ignore the reasons why the EWMH _NET_WM_WIN
On Mon, Oct 27, 2008 at 1:07 AM, Iain * <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 26, 2008 at 10:38 PM, Thomas Thurman <[EMAIL PROTECTED]> wrote:
>>
>> Do you think this is a good plan?
>>
>
> In short: no.
>
> In long(ish):
>
> * If a program hangs, the user cannot close the window
> * each program
On Sun, Oct 26, 2008 at 10:38 PM, Thomas Thurman <[EMAIL PROTECTED]> wrote:
>
> Do you think this is a good plan?
>
In short: no.
In long(ish):
* If a program hangs, the user cannot close the window
* each program needs a copy of the theme parsed in memory, the images
created in memory
* theme c
Several people have raised the idea recently that the responsibility for
drawing window borders might better lie with the application than the
window manager. The idea goes something like this:
1. The window border theme parsing and displaying code should live in a
library. (It already does,
40 matches
Mail list logo
