From kde-panel-devel Thu Mar 13 12:58:10 2008 From: Alex Merry Date: Thu, 13 Mar 2008 12:58:10 +0000 To: kde-panel-devel Subject: Thoughts on applet layouts Message-Id: <200803131258.15859.huntedhacker () tiscali ! co ! uk> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=120541315801099 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0304865697==" --===============0304865697== Content-Type: multipart/signed; boundary="nextPart2255979.Pi6sZcJM01"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2255979.Pi6sZcJM01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I was bored on the bus home last night, and got thinking about applet layou= ts. I think the current system is overly complicated for applet developers. Mo= st=20 of the time, I have no idea what I should be implementing or how. I think = the=20 issue here is that applets are treated like widgets, when the layout requir= eme nts are much simpler. Laying out applets comes down to three cases at the moment (ignoring media center form factors) - in a row, in a column or free. Here's an idea I came up with for an applet layout system. This comes down to a few convenience methods in Applet, a virtual method layout() in Containment (that can be overridden by custom containments) and applets just have to respond to changed heights or widths in updateConstraints(). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D when an applet is added to a constrained containment (FormFactor =3D=3D Horizontal || FormFactor =3D=3D Vertical), it calls updateConstraints on the new applet, informing it of the fixed dimension (either width or height) and the form factor, and then calls layout(applets). In any case (even if the containment isn't constrained), updateConstraints is called to notify the applet of the form factor. when the containment is resized, it calls updateContraints on all the applets informing them of the new fixed width/height and then calls layout(applets). Applets should, when informed of a new fixed dimension (in updateConstraints), set their ideal and minimum sizes in the free dimension and whether they can expand indefinitely in that direction. eg: DigitalClock::updateContraints(constraint) { constraint =3D=3D fixed dimension: FormFactor =3D=3D Horizontal: // fixed dimension is height setIdealWidth(text->widthForHeight(height)) setMinimumWidth(text->widthForHeight(height)) FormFactor =3D=3D Vertical: // fixed dimension is width setIdealHeight(text->heightForWidth(width)) setMinimumHeight(text->heightForWidth(width)) } TaskBar::updateConstraints(constraint) { constraint =3D=3D fixed dimension: FormFactor =3D=3D Horizontal: // fixed dimension is height // this is simplified: doesn't account for two rows of tasks setIdealWidth(no. apps * height * 4) // 4:1 ratio, say setMinimumWidth(no. apps * height) // no smaller than square setExpands(true) FormFactor =3D=3D Vertical: // fixed dimension is width // this is simplified: doesn't account for two rows of tasks setIdealHeight(no. apps * (width / 4)) // 4:1 ratio, say setMinimumHeight(no. apps * width) // no smaller than square setExpands(true) } virtual Containment::layout(QList); Containment::layout(QList applets) { if (FormFactor =3D=3D Planar) do nothing (applet handles take care of e= verythi ng) if (FormFactor =3D=3D Horizontal) { 1. get the ideal width for each applet 2. if space left over, and the containment has fixed width, distrib= ute d the extra width between applets that can expand amount allocated should possibly be proportional to the ideal wi= dth 3. (a) if not enough space, get the minimum width for each applet (b) if there would not enough space for all applets at their minimum width, discard applets from the end until there is, or move to two rows (?) this might happen if screen resolution changes, for example (c) starting at their ideal width, take space enough space from each applet so that the total is the width of the containmen= t, making sure no applet ends up smaller than its minimum width. space taken should possibly be proportional to (ideal width) / (minimum width) 4. set sizes and place on containment in list order } if (FormFactor =3D=3D Vertical) { similar to above, but heights instead of widths } applets can notify that their minimum/ideal sizes or expanding property has changed (with a signal, say), and cause the containment to layout again. custom containments can override layout(), for example desktops can scan the list for icons, lay those out, then pass the remaining applets to the defau= lt implementation (which in this case does nothing, since it's a Planar layout= ). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Given applets have to set 2-3 values in one method, this seems to be a much simpler implementation to me. Comments? Feel free to tear to shreds and tell me it's nonsense (as long as you can tell me why...) Alex =2D-=20 KDE: http://www.kde.org Ubuntu/Kubuntu: http://www.ubuntu.org http://www.kubuntu.org --nextPart2255979.Pi6sZcJM01 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) iEYEABECAAYFAkfZJOIACgkQBRauKLutZ9A+RACgwKRzORfq7qv9J5mBxT/fV7WD L6wAn1WNHoftKqZPCUpg7HDD7rPwVxsg =4999 -----END PGP SIGNATURE----- --nextPart2255979.Pi6sZcJM01-- --===============0304865697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Panel-devel mailing list Panel-devel@kde.org https://mail.kde.org/mailman/listinfo/panel-devel --===============0304865697==--