From kde-core-devel Fri Mar 13 15:25:51 2009 From: "Aaron J. Seigo" Date: Fri, 13 Mar 2009 15:25:51 +0000 To: kde-core-devel Subject: Re: Fullscreen interfaces Message-Id: <200903130925.52034.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=123695798902072 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1342114.NtGDGMiGz0" --nextPart1342114.NtGDGMiGz0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday 13 March 2009, Torsten Rahn wrote: > On Thursday 12 March 2009 01:17:33 Aaron J. Seigo wrote: > > seeing solutions in libplasma for this reason. still, i do agree that if > > libplasma is a hammer, not everything is a nail. ;) > > I think what people would like to see is a stricter and clearer > specification of the _scope_ of plasma. That specification should outline > what intent of use is part of plasma's development focus and what is not. fair enough. on the one hand, i understand what you're looking for and why.= =20 on the other hand, i feel we have more than enough going on to take care of= =20 (we really don't need more on our plate) and that not one single other=20 application in kde is asked to do this. so if we go and fulfill this rather extraordinary request that will not=20 actually benefit the user experience in any way, it would be brilliant if y= ou=20 could participate, utilize and help spread the results. > Currently I feel that there is the danger that plasma develops out of its > own scope and becomes a desktop-environment inside a desktop environment > due to lack of focus on the core issues it tries to solve. we have a very clear focus on the core issues we are trying to solve; that= =20 others on this list who are involved with plasma can state those issues=20 demonstrates that.=20 but let's talk in *specifics* rather than vague generalizations and sweepin= g=20 hand gestures. here's the overview: * libplasma is in kdelibs. it is there to: * provide a set of classes for applications that are doing "widgets on=20 canvases" type things (where "widget" in this case means plasmoids, google= =20 gadgets, that sort of thing). * provide a common set of classes for things like query answers, svg=20 painting, workspace theming the users of libplasma include plasma-desktop, plasma-overlay, krunner,=20 amarok, that nepomuk query app i can never remember the name of and hopeful= ly=20 in the future others (e.g. plasma-mid).=20 it is a separate library so as not to drag this stuff into applications tha= t=20 neither need to nor want to deal with such things. it is needed because Qt'= s=20 graphicsview stuff is both tedious to use in places (hello=20 QGraphicsProxyWIdget), does not offer KDE integration (e.g. kconfig) and do= es=20 not provide any sort of object model for widgets-on-canvases * plasma-desktop is in kdebase-workspace. it is a desktop shell. it provide= s=20 panels and a desktop layer. it allows for some interesting and new concepts= =20 such as multiple activities and (nearly) dialog-less workspace management * the plugins in workspace/ provide a basic "desktopy" experience * the plugins in kdeplasma-addons are neat additional things that people ar= e=20 interested in having around but which aren't core to a basic "desktop=20 experience" we also have: * plasma-overlay so people can put widgets on their screensaver * krunner for running commands and doing quick searches * plasmoidviewer and plasmaengineexplorer to help making things a bit easie= r=20 (testing wise) we are currently working on: * kwin integration points (with the kwin developers) * plasmate, a simple widget creator (emphasis on "simple" and "widget") * plasma-mid, a plasma shell for smaller devices we have started design sketching on: * plasma mediacenter, a fullscreen plasma view and accompanying containment= =20 that would be optionally available as part of the plasma-desktop shell to=20 quickly browse and play media fullscreen (just like every other modern desk= top=20 and gaming system out there has) we continue to work on desktop technologies others simply haven't been will= ing=20 to touch or pay the attention to that they deserve including: * fixing the system tray mess (we should have an improved mechanism by 4.3.= 0,=20 which will allow us to do things in the future like integrate system tray=20 entries into task bar entries where it makes sense to do so) * harmonizing visual notifications * making it realistic to use scripting languages in the desktop shell =2E. and more. > So where is the line between plasma and the desktop with its own apps i'm not sure i understand this part of the question. what do you mean by=20 "plasma", "the desktop" and "own apps" here? hm.. let me take a stab at it= =20 anyways: there is some functional overlap between some plasma widgets, such as the=20 video widget, and full apps like dragon or kaffeine. the overlap is trivial= ,=20 however: they both play video using phonon (for the kde4 versions anyways).= =20 the use cases are rather different, however: dragon is a stand alone=20 application that one might use to play some videos, kaffeine is a bigger=20 management type app that lets one handle playlists and other such more=20 advanced concepts, the plasma video support allows widgets to embed bits of= =20 video. at most, we will one day have a simple full screen media browser tha= t=20 comes with plasma; to understand the difference there look at macos and its= =20 media center app compared to the quicktime and itunes apps. there are multiple use cases for video and some of them are well serviced b= y=20 dragon and kaffeine, but not all are. for instance: a youtube plasmoid migh= t=20 be fun and interesting for people, so they can quickly view youtube videos = in=20 their desktop. so instead of seeing some sort of conflict, it would be much more accurate = and=20 useful to see that it is a way to support of a broader array of use cases.= =20 after all, it's a little silly to say "but we have dragon player!" when a u= ser=20 says "i'd like to place this video on my desktop". > and its own window management? where does this "own window management" come from, exactly? look, we have objects on a canvas. this has nothing to do, at all, with win= dow=20 management. period. if you're talking about managing things like the krunner window, panels, th= e=20 calendar that pops up when you click on the clock, we should be honest here= =20 and realize that kicker/kdesktop did exactly the same things there. > And how do they relate to each other? i don't understand this question. > I also agree that the current situation of the activities vs. virtual > desktops is really hard to understand for a user as it provides two very > similar but orthogonal concepts=20 they are not similar at all, actually. the problem is two-fold, and both=20 related to the fact that it's a new concept: a) we're still working on smoothing the user interaction elements around th= ese b) there's not enough documentation and available user education, and so ma= ny=20 are trying to figure them out on their own and failing (new concepts are no= t=20 easy to figure out without help) oh, and i'd also note that for the majority of people out there, activities= =20 are a completely non-issue as they just sit there and use their desktop sti= ll=20 without caring much about them. i hope this changes in the future, but it=20 won't until the two items above are dealt with. this particular bit of your email also borders on "let's start a general bi= tch=20 fest about anything we don't like, understand or get about plasma and any c= ode=20 around that project". if we want to talk about "what are the goals of plasm= a=20 and how does that relate to kde in general" let's do that. if we also want = to=20 talk about activities, let's take that to plasma-devel and not make this=20 thread a useless bifurcating conversation of random opinion. fair enough? > that are hard to map in the spatial memory > of many users. please don't throw around terms like "map in the spatial memory" unless you= 're=20 prepared to offer some actual evidence to the fact that we are talking abou= t=20 spatial memory, mapping, etc. iow, let's not run down random rabbit holes=20 here. =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 Software --nextPart1342114.NtGDGMiGz0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkm6ev8ACgkQ1rcusafx20OKhgCeJJGKSLCQf0xegvMWwhnTUPHN q20AnAsj7LTBx1cE3cx8ilkFvT/zfmu5 =4zzI -----END PGP SIGNATURE----- --nextPart1342114.NtGDGMiGz0--