Maximus needs more options for window excluding/including

Bug #268494 reported by Rachel Greenham
62
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Maximus
Won't Fix
Medium
Neil J. Patel
Ubuntu Netbook Remix
Won't Fix
Undecided
Unassigned
maximus (Ubuntu)
Confirmed
Medium
Neil J. Patel

Bug Description

When pidgin is launched and opens its main chat window, it just opens as a normal window, unmaximised, although it can maximise.

When deliberately maximised it just does so in the normal way, retaining window decorations; maximus doesn't take hold of it.

While the first issue (window isn't maximised right away) has always been present, maximus used to take over when the window was maximised; that stopped working in the last maximum upgrade or so.

Revision history for this message
Bill Filler (bfiller) wrote :

To boil it down, it appears maximus doesn't undecorate windows when they are manually maximized. Is that by design or is it a bug?

Changed in netbook-remix:
assignee: nobody → njpatel
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Rachel Greenham (rachel-strangenoises) wrote : Re: [Bug 268494] Re: maximus fails to do its thing to the Pidgin main window

Bill Filler wrote:
> To boil it down, it appears maximus doesn't undecorate windows when they
> are manually maximized. Is that by design or is it a bug?
>

It used to, with pidgin, then it stopped, so it might be by design. Then
again it seems to be only affecting *pidgin* for some reason...

It seems more to the point is that most windows that have the ability to
be maximised are auto-maximsed by maximus on open. Except pidgin, for no
obvious reason.

(And whatever other applications i haven't noticed or don't use - for
all I know it's not unique to pidgin, but that's all I'm seeing it with.)

(OK, update manager shows the same behaviour.)

--
Rachel

Revision history for this message
Stefano Maggiolo (stefano.maggiolo) wrote : Re: maximus fails to do its thing to the Pidgin main window

Maximus has a "blacklist" (or is it a whitelist?) of applications that, even if it could, it doesn't maximize. If you're curious, you can reconstruct the list looking at the changelogs here:

https://code.launchpad.net/~netbook-remix-team/netbook-remix/maximus

There is pidgin, apport, gnome authorizations, gimp, skype, transmission, etc etc.

To me this seems rather ugly (since for example I liked to have pidgin maximized) - maybe maximus should remember the previous status of the applications? Is this even possible?

Revision history for this message
Stefano Maggiolo (stefano.maggiolo) wrote :

I forgot: there's something that could be done immediately and give improvements, that is: if I open a window in the blacklist and I maximize it, the decoration should be removed, as for automatically maximized windows.

Revision history for this message
Rachel Greenham (rachel-strangenoises) wrote : Re: [Bug 268494] Re: maximus fails to do its thing to the Pidgin main window

Hmm. Maybe the reason pidgin is there is to stop the *buddy* window
being maximised; and that's right, I wouldn't want *that* maximised,
just the actual chat window. I don't suppose there's any chance of that
kind of granularity of control...

By the looks of it, many of the other blacklisted apps have multi-window
layouts where some maximisable windows you wouldn't want to be
maximused. :-)

--
Rachel

Revision history for this message
Rachel Greenham (rachel-strangenoises) wrote :

Stefano Maggiolo wrote:
> I forgot: there's something that could be done immediately and give
> improvements, that is: if I open a window in the blacklist and I
> maximize it, the decoration should be removed, as for automatically
> maximized windows
That's the part that seems to have stopped working recently. It no
longer does that.

It seems, though, that there's a clear opening here: that the blacklist
should probably be complemented with a user-specific whitelist that
maximus ought to be able to manage itself: ie: in a ~/.maximus/whitelist
file or somesuch, so when a window in a blacklisted application gets
maximised manually by the user, Maximus should do its thing and record
it (with the window title maybe?) as a whitelisted exception.

--
Rachel

Revision history for this message
Rachel Greenham (rachel-strangenoises) wrote : Re: maximus fails to do its thing to the Pidgin main window

Was this just done? I just did an update and got a new maximus and now manually maximising pidgin's main chat window does get the maximus treatment. :-)

Still not auto-maximising though; presumably because of that blacklist.

How about... in similar fashion to compiz, how about if the blacklist is a list of window *titles* rather than application names. Specifically, in Pidgin's case, if it was blacklisted to prevent the buddy window being maximised, blacklist the title of that window, "Buddy List" in English, or the appropriate translation for other locales... (Is it possible to pull a different application's localised text for a given label?)

Revision history for this message
Neil J. Patel (njpatel) wrote :

I agree, we need more fine-grained control over what get's maximised. The matching of res_name and class_name would help a great deal as many applications do use both right (i.e. res_name=pidgin and class_name=buddy-list).

Changed in netbook-remix:
milestone: none → 2.0
Revision history for this message
Stefano Maggiolo (stefano.maggiolo) wrote :

If I may suggest another application that needs to be in the blacklist, it's FontForge (it has a window structure similar to GIMP).

Neil J. Patel (njpatel)
Changed in netbook-remix:
milestone: 2.0 → none
Changed in maximus:
milestone: none → 2.0
Revision history for this message
aglet (robin-aglet) wrote :

Sawfish has some flexible window matching code, see http://svn.gnome.org/viewvc/sawfish/trunk/lisp/sawfish/wm/ext/match-window.jl?view=markup

I'm actually wondering if it might be easier to emulate Maximus' behaviour with Sawfish...

Revision history for this message
AphoxemaG (xeristian) wrote :

An effective workaround for anyone who wants to override the maximus blacklist is to add an include_class key to the gconf schema that forcibly allows applications to be handled. This would keep from having to add a lot of classes to the exclude_class by default or messing with a users current schema.

Revision history for this message
Paul Larson (pwlars) wrote :

Moving to Ubuntu distribution

Changed in maximus (Ubuntu):
assignee: nobody → Neil J. Patel (njpatel)
importance: Undecided → Medium
status: New → Confirmed
Changed in netbook-remix:
status: New → Won't Fix
tags: added: ubuntu-unr
Paul Larson (pwlars)
Changed in maximus:
status: Confirmed → Won't Fix
Revision history for this message
Jakob Berg Jespersen (jakobjespersen) wrote :

If Maximus gets an option to not maximize anything by default. It will become very useful in the non remix version. I think this will be a good choice as the google chrome browser already is half a cm shorter in the heigth.

Revision history for this message
Tuomo Kohvakka (tuomo-kohvakka) wrote :

I'll attach a rough patch for an include_class setting. I'm not sure if it's the best idea, or if there should be a more fine grained control on windows, but this solved the problem for me (that is, ufraw-gimp plugin is unusable unless it's undecorated and maximized on eee).

David Futcher (bobbo)
tags: added: patch-forwarded-upstream
Revision history for this message
Spinnekopje (koen-spinnekopje) wrote :

An include_class key is not user friendly. I can create the key, but what to add to include pidgin? That isn't clear.
It would just be more logical to see pidgin in the exclude_key by default, just like that should be the case with any other application and not just certain apps.

It isn't strange to have a list of dialogs/popups that shouldn't be in the list, but I think the applications themselves should be in the exclude_class. It took me a while to understand that certain apps are just 'hard-coded' not to maximize..

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.