[compiz] Metadata improvements

Sam Spilsbury smspillaz at gmail.com
Sat Jun 2 16:43:35 PDT 2007


I'd like to mention that its just an example. Having one metadata file
for plugin would be easier to manager, but maybe we should have
<function> tags in each plugin to signify which settings page it goes
to. Theres like, 50 plugins now and groups dont really help too much
anymore considering all the scrolling I have to do :/

On 6/2/07, Robert Carr <racarr at beryl-project.org> wrote:
> On 6/2/07, Sam Spilsbury <smspillaz at gmail.com> wrote:
> > I was just thinking, with the metadata files allowing us to make up
> > settings pages, there is a problem that we could address here.
> >
> > It seems ever-so-evident that developers are splitting up plugins into
> > much smaller plugins to reduce the amount of bloat. This is good
> > because it speeds things up but bad for the user in two ways
> >
> > -We've got multiple settings pages which really adress the same thing,
> > just different parts of it
> > -Users have a hard time finding the option they are after because of
> > all the trial and error navigation
> >
> > So what are some examples of this?
> >
> > A famous one is the Cube+Rotate+3D issue
> > A user is not going to know where everything is, so when they first
> > get introduced to the settings interface, they will be confused to
> > find the option they want.
> >
> > Example: John is frustrated with the edge-flip move option as he finds
> > it distracting. He knows it has something to do with the cube plugin
> > so he looks in there and cannot find it. Later, he finds it in the
> > 'Rotate' plugin, which is not where he expected it to be
> >
> > Example 2: Robert wants to know info about his windows size. Because
> > of experience with previous window managers, he looks in the 'Resize
> > window' section but cannot find it. He knows he as seen it somewhere
> >
> > So what is the solution?
> >
> > Well, we instead of having metadata files for each plugin, we can have
> > them for each function.
> >
> > <function=cube>
> >    <short>Desktop Cube</short>
> >     <enable name="cube">
> >      <short>The Cube itself</short>
> >        <default>true</default>
> >      </enable>
> >    <short>Cube Rotation</short>
> >     <enable name="rotate">
> >      <short>Ability to rotate the cube</short>
> >        <default>true</default>
> >      </enable>
> >    <short>3D window layering</short>
> >     <enable name="3d">
> >      <short>Windows have space between them and stacking can be seen</short>
> >        <default>true</default>
> >      </enable>
> >     <plugin="cube">
> >     <etc with relation>
> >         <group>
> >             <short>Cube appearance</short>
> >                <option name="inside_cube">
> >                   <short>View the cube from the inside</short>
> >                      <long>Rotate around the cube so it looks like you
> > are inside it</long>
> >                        <default>false</default>
> >                 </option>
> >           </group>
> >      <plugin=rotate>
> >          <etc with relation></relation>
> >                <group>
> >                   <short>Edge Flip</short>
> >                     <option="edge_flip_pointer">
> >                       <short>Flip viewport when the pointer bumps the
> > edge of the screen</short>
> >                         <long>When the pointer hits a screen edge,
> > rotate the desktop cube to where the pointer is going</long>
> >                     </option>
> >                </group>
> >           </plugin>
> >      <plugin=rotate>
> >          <etc with relation></relation>
> >                <group>
> >                   <short>Edge Flip</short>
> >                     <option="edge_flip_pointer">
> >                       <short>Flip viewport when the pointer bumps the
> > edge of the screen</short>
> >                         <long>When the pointer hits a screen edge,
> > rotate the desktop cube to where the pointer is going</long>
> >                             <default>false</default>
> >                     </option>
> >                </group>
> >           </plugin>
> > </function>
> >
> > This way we can still have loads of plugins and less settings pages to
> > confuse the users. The beauty of this system is that we can create
> > entirely new functions out of stuff scattered around in core and
> > plugins.
> >
> > For example, we can list Opacity from core, and brightness and
> > saturation, Negative and fakeargb under one settings page called 'Real
> > time window effects'
> >
> > We can also take the matching interface out of core.xml and add window
> > attribs to the WinRules plugin. They are there on the settings page
> > but remain in core 'physically'
> > _______________________________________________
> > compiz mailing list
> > compiz at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/compiz
> >
>
> I don't think this is the best approach, it makes sense to have one
> metadata file per plugin for obvious reasons.
>
> If you wanted to do something like this it would make more sense (I
> think) to have it as an attribute of the <plugin> tag.
>


More information about the compiz mailing list