|
From: Shaya P. <sp...@cs...> - 2003-04-06 21:53:25
|
Here's a unified diff as requested.
spotter@zaphod:~/cvs/gaim/src$ cvs diff -u away.c
Index: away.c
===================================================================
RCS file: /cvsroot/gaim/gaim/src/away.c,v
retrieving revision 1.93
diff -u -r1.93 away.c
--- away.c 5 Apr 2003 05:01:28 -0000 1.93
+++ away.c 6 Apr 2003 21:47:28 -0000
@@ -211,7 +211,7 @@
return;
if (!imaway) {
- GAIM_DIALOG(imaway);
+ imaway = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_role(GTK_WINDOW(imaway), "imaway");
if (strlen(a->name))
gtk_window_set_title(GTK_WINDOW(imaway), a->name);
as GAIM_DIALOG is just
#define GAIM_DIALOG(x) x = gtk_window_new(GTK_WINDOW_TOPLEVEL); \
gtk_window_set_type_hint(GTK_WINDOW(x),
GDK_WINDOW_TYPE_HINT_DIALOG)
it's not much of a change, only removing the dialog hint. The reason
for this being that metacity views dialog's as being part of the parent,
and unminimizable (is that a word?). I know I like to go "auto away" and
minimize the message out of the way, but with the current source I can't
do that.
I still want the window around (hence why the patch to make the window a
pref doesn't help me), and this hint just doesn't seem to accomplish
anything usefull (besides perhaps under some window manager forcing it
to be minimized with the parent) as most window managers (based on what
people say in #gaim) seem to ignore the hint. I don't mind the dialog
hint on things like prefs, but it seems overkill for the away window.
shaya (oh and not subscribed, so cc me)
On Sun, 2003-04-06 at 14:40, Shaya Potter wrote:
> On Sun, 2003-04-06 at 14:36, Robert Love wrote:
> > On Sun, 2003-04-06 at 04:14, Shaya Potter wrote:
> > > here's a simple patch that lets me minimize the away window, and not
> > > have it act like an always on top dialog.
> >
> > Can't we just get rid of this silly window altogether?
> >
> > There was some sentiment to this effect on GNOME Footnotes yesterday.
> > If I recall, a chap named Chris Rivera posted a patch to make the away
> > dialog an option.
>
> well, both are valid approaches I think.
>
> 1) the windows itself should be an option
> 2) the window should be an option if it's a dialog or not.
>
> though giving all these options doesn't seem very HIGy :)
|