After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 311428 - Intrinsic support for the functionality currently provided by devilspie
Intrinsic support for the functionality currently provided by devilspie
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
2.10.x
Other All
: Normal enhancement
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2005-07-24 18:49 UTC by Ivan Yosifov
Modified: 2020-11-07 12:36 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Ivan Yosifov 2005-07-24 18:49:52 UTC
Currently devilspie ( http://www.burtonini.com/blog/computers/devilspie ) allows
the user to define sets of rules and transformations ( called flurbs in
devilspie ) and the transformations are applied to windows matching the rules. 
This allows one to say things like: all windows belonging to app X, with title
that matches the regular expression Y should be resized to size 123x456 and 
moved to desktop 5 at coordinates (20,30).

The problem is that with devilspie this causes a noticable flicker - a window is 
first drawn, then resized or maximized or moved, so the transformations need to
be applied before the window is drawn for the first time, and if my
understanding is correct, this can only happen inside the window manager.

As I see it there are two possible ways to provide this functionality.
One way is to integrate this functionality in metacity ( like kwin from KDE has
done ) and provide some way for the user to define flurbs. This can be done
either with an xml file ( like in devilspie currently ) or with a GUI dialog
with a lot of check boxes, property pickers, edit boxes like in kwin. Probably
the best option is to provide both - the xml file ( as a backend ) and a text
editor for the tech savy users and a friendly ( and simple ! ) GUI ( as a
frontend ) for the "normal" people.

The other option is define an API which lets programs manipulate other programs
windows before they appear. Something like an API for window manager plugins.
This will allow programs like devilspie to do their job smoothly.
Comment 1 Ross Burton 2005-07-24 19:09:00 UTC
As the author of Devil's Pie, I should state that I don't believe this
functionality should be in Metacity.

Sawfish is an acceptable replacement for Metacity and implements what is
required from a window manager.
Comment 2 Elijah Newren 2005-07-24 21:17:35 UTC
Agreed with Ross, and the suggestion doesn't jive with Metacity's goals.  See
the README file or http://ometer.com/free-software-ui.html or
http://ometer.com/features.html.
Comment 3 Ivan Yosifov 2005-07-25 11:22:09 UTC
Thanks for the links.

First - why is this functionality important - it is important because it allows the 
user to arrange their desktop to their working habits - increase their
productivity. 
It is a way to impose desired behaviour on apps without needing to have each of 
them designed to cooperate ( remember window positions, etc. ). Providing the user 
with a means to tell the UI how to look, using one program, is feasible, 
going after every application author convincing him that HE should go after details 
like restoring window positions instead after fixing bugs is not.

After reading the metacity README I can agree that integrating the functionality in 
metacity is against metacity's goals. However there is nothing wrong with that - 
modularity is good - let an external program ( devilspie ) do the job.

There is one problem however - flicker. To allow an external program to properly do 
the job metacity has to provide a way for it to apply the transformations to the 
window before it is drawn.

I am not very familiar with metacity internals or the X architecture - so it is
up to
you to decide if providing such an API will pose maintainership overhead. However I 
guess it will not - you already have all the code in metacity and libwnck - only
that
the wnck "window opened event" event that devilspie uses is delivered after the
window
is drawn rather than before it.

devilspie.c:

static void init_screens(void) {
  GdkDisplay *display;
  int i, num_screens;

  display = gdk_display_get_default();
  g_assert (display != NULL);
  num_screens = gdk_display_get_n_screens (display);
  for (i = 0 ; i < num_screens; ++i) {
    WnckScreen *screen;
    screen = wnck_screen_get (i);
    /* Connect a callback to the window opened event in libwnck */
    g_signal_connect (screen, "window_opened", (GCallback)window_opened_cb, NULL);
    if (apply_to_existing) wnck_screen_force_update (screen);
  }

}

Perhaps a new event "window about to be open" can be added.

The ultimate goal is to get rid of the flicker. How, in your view, is the
correct way to do this ?
Comment 4 André Klapper 2020-11-07 12:36:07 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all
old feature requests in Bugzilla which have not seen updates for many years.

If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be implemented.