From kde-panel-devel Tue May 25 17:04:40 2010 From: "Aaron J. Seigo" Date: Tue, 25 May 2010 17:04:40 +0000 To: kde-panel-devel Subject: Re: kbstateapplet: Plasma integration directions Message-Id: <201005251004.40859.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=127480711619874 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0992271341==" --===============0992271341== Content-Type: multipart/signed; boundary="nextPart2545034.oDi7zDxXWD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2545034.oDi7zDxXWD Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 23, 2010, Sandro Giessl wrote: > What's needed to fix those two outstanding points? a rewritten plasmoid. there was a start of one made for the javascript jam= =20 competition, but it was a bit overengineered and the drawing/painting never= =20 actually got implementated (just coloured blocks). but it was at least a st= art=20 and showed that it was quite possible to do. since there is a competent data engine and all the graphics could be provid= ed=20 using SVG, there is no reason this couldn't be a small bit of javascript. the biggest problems with previous runs at this are that, for whatever reas= on,=20 people try to come up with complex code to solve a simple problem and then= =20 forget that it has to look good. use the kbstate engine, use the services it provides, use an SVG for the=20 items, use Plasma::SvgWidgets in a LinearLayout to display the results. it= =20 shouldn't be rocket science, and shouldn't be more than a 200 lines of=20 javascript, quite possibly even under 100. > - All kbstates information should (I think) be made available as plasma > data engine. There's sticky keys status, locked keys, mouse status, > AccessX status. Mouse status and most keyboard status data sources seem > to be there already. > Whould AccessX be a separate data engine, or should another data engine > (Keyboard?) be extended? personally i'd add it to the keystate engine to keep it simple. it's relate= d=20 to the keystate information and most likely to be used in concert with it. > Is there any gain in making the kbstate applet UI theme'able? the desktop theme should be enough, which means that if the UI uses an SVG= =20 then theming comes for free. > Can plasma applets be added automatically by the kaccess task, or is technically? yes. the question is how we want that to work in practice. it= =20 probably means something in plasma-desktop. > What's plasma's policy regarding when to use system tray icons vs. when > to use applets? use tray icons when there is no other option or the service must be cross- desktop. > Like KDE's systray icon for switching keyboard layouts, shouldn't the > accessibility key status be shown automatically when activated (opposed > to requiring to add a plasma applet to the panel manually)? and where, exactly, would it get auomatically added? =2D-=20 Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks --nextPart2545034.oDi7zDxXWD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEABECAAYFAkv8AygACgkQ1rcusafx20PATwCdHBu1LmBIxZSMdoECrd5gyMUb OuQAoKXiJ9fhGOniorix/OTV3w+6/Fxn =q3dN -----END PGP SIGNATURE----- --nextPart2545034.oDi7zDxXWD-- --===============0992271341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0992271341==--