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 <[EMAIL PROTECTED]> wrote: > On 6/2/07, Sam Spilsbury <[EMAIL PROTECTED]> 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@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. > _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
