--===============1705446561==
Content-Type: multipart/signed;
  boundary="nextPart1739859.60ZE9v6X4F";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1739859.60ZE9v6X4F
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Andreas Pakulat, 29.11.2010:
> On 29.11.10 20:20:39, Silv=E8re LESTANG wrote:
> > Hey,
> > a lot of plugins and features (Build, Run, Debug, Test and Version
> > Control) use the standardouputview for displaying what they need to
> > display. But this toolview is quite generic and doesn't correspond to
> > the needs of most of them, and thus make it difficult to users to
> > understand the UI (the previous and next buttons doesn't always do
> > something and the two buttons "Select activated item" and "Focus when
> > selecting item" are difficult to understand and irrelevant sometimes).
> > I try in the last few days to see if it was possible to improve the
> > standardouputview to full fit the needs of all plugins and features but=
 I
> > arrived to the conclusion that it's useless as every plugins have a
> > slightly different needs.
> > So I proposed to create a new toolview for each plugins or features whi=
ch
> > need one, starting by the Build feature.
> > I think we need to keep the previous and next item, remove the "Select
> > activated item" and "Focus when selecting item" buttons and replace them
> > by a warning and error buttons that we can toggle to display only
> > warnings and/or errors. I make a little mock up here:
> > http://www.kdevelop.org/mediawiki/images/b/b8/Build_toolview.png
> > What do you think about that?
>=20
> I agree with Aleix and Milian (and not just because I wrote that beast).
> The main idea is that most of the things you mentioned (except
> find-in-files these days) have much in commmon with respect to their
> "output needs". Maybe I'm oversimplifying things, but all of them output
> (huge) amounts of text-lines. Some want to enable functionality to jump
> between points-of-interest in that text (compiler errors,
> version-control errors, test failures). Some don't need that, like
> Run/Debug output from the application. The reason for doing a single
> view for all of them is that some of the problems that such output views
> impose are hard to solve and hence should be solved only once.
>=20
> That being sad, yes the actions should be disabled if they don't do
> anything. Unfortunately there is currently no way to decide that easily
> as we don't have any kind of focus-tracking in the platform. If there
> were you could enable the actions only if the focussed view is a
> standard output view and the underlying model supports the next/previous
> feature.
>=20
> The two toolbar buttons have been added when some users wanted that
> focus always moves to the item when its activated and some didn't. And a
> third group wanted it to be at least selected... So maybe there
> shouldn't be an option for all of that, but IMHO focus should never be
> moved by an application automatically (except maybe if all editors have
> been closed).

What selection? What is "it" that is activated?

> Having said all that, maybe a simple widget instead of a complete
> toolview factory would better fit the design idea. Then each plugin
> could use the widget in its toolview, populate the toolbar itself and
> decide itself wether it wants tabs or or "next/previous" buttons or
> neither.

Or add the required configuration options like I proposed.

> So IMHO thats the direction in which the coding of the
> standardoutputview should move, remove the toolview bits, leave the
> global actions and provide a widget and hooks to connect such a widget
> to the global actions.
>=20
> Andreas


=2D-=20
Milian Wolff
mail@milianw.de
http://milianw.de

--nextPart1739859.60ZE9v6X4F
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAkz0K9IACgkQDA6yEs0dE5P16wCdHv98TOhLFaEaxrtsAzV3ZrHL
sdsAnipvV/0iYs7YsGhmLRor8XXfedu6
=+L2g
-----END PGP SIGNATURE-----

--nextPart1739859.60ZE9v6X4F--


--===============1705446561==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

--===============1705446561==--