[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Planning for 4.3
From:       "Lucas Murray" <lmurray () undefinedfire ! com>
Date:       2008-12-19 10:23:11
Message-ID: f09827650812190223k3a8b7823x3967e6733286f998 () mail ! gmail ! com
[Download RAW message or body]

On Fri, Dec 19, 2008 at 6:49 PM, Martin Gräßlin
<ubuntu@martin-graesslin.com> wrote:
> So I just put in my plans for 4.3. It's a little bit related to your library
> idea.
>
> I want to move the present window effect into the core. So to say the logic
> will be in the core and you can have present windows in a non-composited way.
> The compositing effect will only do the animation. Everything else (filtering,
> position, etc) will be handled in the core. I hope this will make it possible
> to have the present windows in other effects as well such as desktop grid or
> cube. Or what I think would be very nice to be able to expose a window group
> in taskmanager. In fact having the non-composited present windows was Lubos'
> idea :-)

It should also be possible to mix the two effects by making present
windows generate the window positions on a per-screen basis and take
in effect screen transformations. Desktop grid just needs to trigger a
custom present windows event (By an inter-plugin method) and it should
all work well.

> Lucas, I think we should discuss the possibilities in IRC some time at beginn
> of January. So that we go the same way with the library approach.

We should decide which method to take ASAP as it changes the way a lot
of things work in core.

Pros for "moving to core"/monolithic system:
- Faster/less code
- Easier to write if you understand the core (Harder for everyone else)
- More integrated
- Better fallback/customized behavior
- Better UIs as you can do whatever you want instead of being confined
to a single dialog

Pros for plugins/modular system (This included non-compositing plugins):
- More precisely defined API
- Less susceptible to bugs that affect the stability of the core
- Easier to expand
- All related code is kept together
- Less prior knowledge of KWin core required to write plugins
- No need to supply .diffs if you want to add the plugin as an official module

> And what I think is very important: we need a better plugin selection. I think
> we should get a more systemsettings-like style. That of course implies that we
> have nice looking icons for each effect. I attach a mockup of what I think it
> could look like.

I don't see any difference of using that method over what we already
have. It's still a list of effects that have a single UI dialog, just
presented slightly differently. What I would like is something like
the "window behavior" UI where multiple features are put together in
the same area/displayed at once. If you enabled the sphere effect for
example it would show more settings on the _already existing_ cube UI,
not have it's own little dialog that's nowhere near the rest of the
settings or even duplicate the dialog in its entirety.
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

[prev in list] [next in list] [prev in thread] [next in thread]