[19:05] el starto! [19:05] * Sho_ is up for it [19:05] so [19:05] this meeting is about two things [19:06] a) what peple would want in plasma desktop for the 4.10 release, what they would like to work on [19:06] and what of this (or diffeent work) could impact also active post pa3 [19:06] --> dantti has joined this channel (~dantti@200.204.2.102). [19:07] i think on 4.10 we can present, by just finishing some branches of work we already started, and some small polishments here and there some quite visible improvements [19:08] on my list are a couple of things, not sure which I'll actually get to: [19:08] regarding 'a' i'd like to take the stage for a couple of minutes at an appropriate time in the meeting and talk about what i've got planned re qml taskbar rewrite, and fish for input from peoples on that :) [19:08] Sho_: yep, the meeting is exactly about that, talking about the work point one wants to do, get feedback etc :) [19:08] *nod* [19:09] Sho_: we may start with that? [19:09] I've got a few points as well, will go after Sho [19:09] alright by me, let's allow sebas to finish typing tho [19:09] ah, or that way [19:09] ok, so: [19:09] notmart: what's the second thing this meetn gis about? [19:09] (before we get into people's points .. just want to know how to sort my input :) [19:10] i've been freshly hired by Blue Systems, and pondering what there interests are and after talking to notmart about available projects in Plasma, ended up pitching the QML rewrite of our taskbars to them [19:10] aseigo: i was thinking: to see if people plan to do something for active and see if some of the features of the first point can impact or be reused for active as well [19:10] sounds good? [19:11] plural is deliberate there, because i want to support both the classic and the dock pattern - i.e. standard taskbar and icon tasks - in one codebase, to avoid scoping too narrowly and causing extra work later [19:11] i'd also like to discuss wayland a bit, although it's not a 4.10 item obviously [19:11] plus while things are early, after talking to many people and their experience with icon tasks, i have half a mind to push for some variant of the dock pattern as the default down the road [19:11] notmart: aha.. :) ok, so the "and what .." was b) .. cool [19:11] to begin with my goal is feature parity on the standard taskbar however, since i'd like to swap in the codebase without causing terrible regression [19:12] *** TomasuDlrrp is now known as Typosu. [19:12] right now what i'm doing is auditing the current plasmoids and sifting through bko to collect my scope, and starting to examine the state of the models in libtaskmanager [19:12] sreich started on a qml taskbar a while back that has some of the needed changes in the lib, too, which provides a launching-off point [19:13] --> reavertm has joined this channel (~reavertm@89-70-97-213.dynamic.chello.pl). [19:13] <-- reavertm has left this server (Changing host). [19:13] --> reavertm has joined this channel (~reavertm@gentoo/developer/reavertm). [19:13] --> kallecarl has joined this channel (~carl@kde/symons). [19:14] Sho_: sounds good, you [19:14] alright, so obviously this is my first taskbar,and for that matter my first complex qml project after some simple plasmoids - i'll need a bit to get up to speed certainly, and will benefit from any experience you have to offer as for what patterns have proven to work well in plasma [19:14] 'll probably run into interestng things just by reimplementing the current feature set in QML quite quickly already [19:14] yes, i think feature parity without too many regressions is the important first step [19:14] although much of the painful problems we were having there might well be QGraphicsView problems we'll simply won't see in QML [19:14] anything you got, throw my way :-) [19:15] the worst thing in changes is when wanted behavioral changes gets mixed with unwanted bugs caused by technology change [19:15] sebas: yes, things like the animated layouts which are still buggered will magically get fixed with the QML port [19:15] aseigo: maybe some of those ghosting problems as well? [19:15] notmart: yep. good argument for a straight reimplementation [19:16] right, i'm not sure how realistic this is for 4.10 - think you can have a "basically works well" qml taskbar in that timeframe (and prototypes probably a lot faster), but the feature matrix is huge and it's the classic last-20%-need-80%-of-the-effort project [19:16] i.e. that problem you and notmart have banged your heads against for hours, days and longer? [19:16] sebas: ghosting problems are gone afiak [19:16] ah, good [19:16] --> simgunz has joined this channel (~quassel@adsl-ull-178-137.51-151.net24.it). [19:16] i don't want us to ship a shakey taskbar, so achieving a good polish level is necessary [19:16] Sho_: if you come across non-defensibel features, propose them on the mailing list for potential removal / redesign [19:16] defensible [19:17] * notmart wonders if anyone uses the manual regrouping for instance [19:17] but his is for more in dept discussions later [19:18] aseigo: right, tho e.g. things like the manual reordering you mentioned in the query the other day happen to be personal pet features of mine, plus reordering is really necessary for the dock pattern [19:18] aseigo: so i can't/won't give up on stuff too easily either [19:18] good :) [19:19] for me features are good as long as a) have a good use case b) most important are actively maintained, so good [19:20] i have some very vague design ideas for a possible hybrid of the dock and classic patterns that tries to address some of the brain damage of the win7 taskbar when in hybrid mode, but i think that's all for after hitting feature parity [19:21] thing is though, i actually used to not like docks myself, but observing people using them i've come to realize that removing the distinction between "launching" and "switching to" removes a huge amount of mental overhead for people, and naturally goes together with maing the task items more powerful entry points into apps (jump lists, recent docs, that sort of thing) [19:21] so longer-term applying a small dose of gnomic vision and rocking the defautl taskbar boat is pretty tempting [19:21] --> bcooksley has joined this channel (~bcooksley@kde/bcooksley). [19:22] and if microsoft can get away with switching the taskbar .. [19:22] but going down that road means getting rid of this concept of docking to the sys-tray [19:22] <-- bcooksley-away has left this server (Ping timeout: 240 seconds). [19:22] which I'm all for, but means changing lots of legacy apps to behave [19:22] which is broken anyway [19:22] i tend to not dislike the concept as well and have some ideas too, a thing of concern is that i see many people really, really hate any form of grouping [19:23] yeah, and it'll have to be a community process - blogging, growing with the feedback, etc. [19:23] so must still work well with a flat list concept [19:23] notmart: i always disable it :) [19:23] to be clear tho i don't have my head in the clouds quite already, my first goal is definitely to get to a solid working implementation of what we have already, which is going to be challenging enough to begin with [19:23] rough future goals just help with having the right scope in mind for architecture decisions [19:24] yup, and i like this approach :) [19:24] +1 [19:24] now, i would go on if there are other topics... [19:24] i also have some pet annoyances that i sort of vaguely know i want to address, but have to get a handle of the details still [19:25] then when we talked about a feature, the owner should make sure to put it with his name on http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan [19:25] there are some situations in the state model of our current taskbar where it flickers wildely between theme lements that is really not nice [19:25] i have to go through what goes on there and figure out if that can be fixed somehow without becoming incorrect, by compressing events or changing the way the transitions work etc [19:26] Sho_: likely fixed just by using QML [19:26] animations in C++ are really hard to get right [19:26] probably [19:26] QML gets it right quite naturally [19:26] alrighty, i'm done for the moment :) [19:27] * sebas goes on then [19:27] I've three things on my list: owncloud sync, folderview QML, default containment for plasma desktop. I'm not sure in how far I'll get to finish any of these, but there you go: [19:27] (A) owncloud syncing client, basic stuff is quite far already, should be doable in 4.10 timeframe (does file syncing, not much more, extensible post 4.10) [19:27] (B) folderview QML port: We can reuse the models from the C++ folderview widget, but most of the UI will need to be redone. Since this widget has a lot of different options, it's not an easy task. I've got a branch which makes the files model from Folderview (KDirModel subclass/aggregate thing) usable from QML, seems quite fast with a basic delegate [19:27] (C) default desktop layout: less intrusive applet handle (-mechanism?), layout helpers (snapping), probably create a new desktop containment in QML, also needs some consideration when using together with Folderview [19:27] (I'm a very fast typist) [19:28] Here's a screenshot of owncloud client: http://wstaw.org/m/2012/09/11/plasma-desktopC15680.png [19:29] that is mirall? [19:29] hm, slider checkboxes on the desktop? [19:29] yes [19:29] (there i go honing in on details) [19:30] i'm with Sho_ there that it would be nice to keep sliders vs checkboxes consistent on different devices [19:30] * notmart still toying with the idea of making slider and chackbox looking the same, and look depending on device [19:30] we have the means [19:31] "we have the technology!" [19:31] yeah, just have to move my ass and do it ;) [19:31] or at the least, we can have different QML for device vs desktop [19:31] by the power of plasmaskull [19:31] or sth [19:31] [19:32] qml desktop containment would be great too [19:32] for switch on / off, it's quite ok I think [19:32] could be checkboxes as well [19:32] sebas: it's rather inconsistent with everything else on the desktop though; new widget language, and for what benefit? [19:32] --> Stskeeps has joined this channel (~cvm@Maemo/community/distmaster/Stskeeps). [19:33] they're more beautiful, but I'm not married to them :) [19:33] not sure a new applet handle approach is needed though.. just getting a qml desktop containment would be great [19:33] they are possible (as is the containment in active) just needs a little c++ helper for managing applets geometry that i don't like that much, but they seems reliable already [19:33] --> bogdan__ has joined this channel (~bogdan@37.160.48.60). [19:33] in unlocked mode, I see them more often when I don't want them than when I do, so [19:34] notmart: could well be a bit of glue that we eventually share between containments? [19:34] if qml is managing applets geometries it may be needed an handle done by the containment itself [19:34] unlocked is not a mode... it's the standard ;) [19:34] aseigo: yeah, they may be some components that may be intended for use in containments [19:34] right, and flickering like crazy, and the applets are only resizlbe on half of their axes [19:35] the handles have nothing to do with flickering [19:35] well. the handles appear and disappear all the time, that's what I mean by flickering [19:35] not actual graphics artifacts, just unwanted appearing [19:36] some experiments may be done.. [19:36] yes, maybe steal some ideas from Active's activityscreen [19:36] "handle should appear now" might be a strong ai problem ;) [19:36] i think with some adaptions it could work well on the desktop [19:36] i don't :) [19:37] * Sho_ gets feverish visions of sebas analyzing mouse vectors and velocity to derive user intent [19:37] but is a bit a paradigm change, so i'm not sure it would be good to become the new default [19:37] --> turgay has joined this channel (~turgay@95.13.65.185). [19:37] it's not just a paradigm chnage [19:38] probably here as well: we first need to replace the current one (including functionality) with something QML, and then can go wild [19:38] there's a strong difference not only with input devices, but attention patterns [19:38] in any case... [19:38] I think some of the interaction, dragging, resizing is nicer than plasma desktop's [19:39] mixing resources and widgets and have them nicely layout is cool as well [19:39] we have a number of existing actual rough edges that are obviously in need of improvement ... would like to fix those first before re-thinking things that are less obviously in need [19:39] yeah, +1 [19:40] one thing that may be useful is: [19:40] identify problems of the current desktop containemnts by describing some scenarios to reproduce unwanted behavious [19:41] then see if is really unwanted, if it is what can be done about it [19:41] the problems are not in the containments imho (other than being not QML :) [19:41] at least not the biggest ones [19:41] one of the main challenges revolve around activity management [19:41] * knowing which activity you are currently in [19:42] * handling applications which don't work nicely with activities (hello firefox and thunderbird :/ ) [19:42] * creating and swtiching between activities more elegantly [19:42] some of these things we've figured out a lot better for Plasma Active [19:42] --> tittiatcoke has joined this channel (~tittiatco@opensuse/member/tittiatcoke). [19:42] some are unique to the desktop (like firefox's new tab behaviour) [19:43] notmart: btw, one my todos for later today or so is to read your qml notifications stuff to get a feel for a high-complexity qml plasma thing ... anything i need to be aware of wrt the state of that? [19:43] * notmart the other night dreamed about a different paradigm for desktop and activity switching, at the moment seemed the perfection [19:43] but after a while, a bit less ;) [19:43] revisiting the add-to-activity (right now desktop only has a way to add widgets really ..) UI for the desktop would be another priority imho [19:43] something which is unique to tablets are motion sensors (accelerometer, gyrometer, magnetometer). Could be these features included into AP ? [19:44] lol .. nice :) [19:44] yeah, quite annoying dreaming nerdy stuff actually ;) [19:44] :) [19:45] bogdan__: there is a DataEngine which publishes which of these sensors are available .. actually using them in various UI areas would be nice ... if you have specific ideas, send to the active mailing list? [19:45] Sho_: it works pretty well already, the popup is still a bit broken other than that usable [19:45] s,would,could, (not sure where AP would use them right now, other than the obvious screen orientation switching we still lack) [19:45] notmart: and you're happy with the architecture, i.e. it's a good candidate to get inspired by? [19:46] theme tweaks for 4.10 would also be nice .. just keep refreshing it bit by bit [19:46] Sho_: only thing, if you boot in a session with that branch of kde-workspace it will yank the old one since thre is a kconf update script that renames it (still not decided if rename or keep the old name) [19:47] notmart: did you have some ideas for which areas of the theme to tweak? (the progress bars look universally better in 4.9 btw :) [19:47] Sho_: a difference will probably be that the notification one uses at least for now only dataengines as models, while the taskbar will have one from libtaskmanager [19:47] what i did on the weekend is to set up a nice new dev user and automate a button in kdevelop on my main user to make, install and wipe and recreate a Xephyr session .. [19:47] <-- krwk has left this server (Ping timeout: 260 seconds). [19:47] aseigo: for the desktop theme i was talking the other day with pinheiro [19:47] i like automated code-compile-test cycles [19:47] i added a --restart to konversation so it can replace itself [19:47] :) [19:48] aseigo: Sorry for interrupting, if you want I dont speak again, about changing activities, I have created a relevant plasmoid which has been published (http://kde-look.org/content/show.php/WorkFlow+Plasmoid?content=147428) I dont know if is relevant with your ideas... sorry for interrupting again... [19:48] we are developing some ideas, but in general the trend should be small simplifications that should make things look less cluttered [19:48] aseigo: pinheiro is planning to overhaul Air for 4.10 [19:49] Psifidotos: don't be sorry, good ideas are always good ideas [19:49] and when they have code... even better ;) [19:49] notmart:thanks a lot for that... :) [19:50] --> bogdan_ has joined this channel (~bogdan@37.160.16.103). [19:50] notmart: do you think fitting a data engine over libtm would be a good idea? [19:50] bogdan__: we are discussing some topics one at a time, we are still on plasma desktop, but if you want to wait a bit we can come to that shortly ;) [19:50] <-- buscher has left this channel. [19:50] Psifidotos: yes, i've actually built it and tried it.. it's a very nice power use tool. i think it's a bit beyond the general user needs (which does not make it bad, just makes it a tool for more advanced individuals) [19:50] Sho_: i'm not sure, i fear there would be quite some overhead [19:51] <-- bogdan__ has left this server (Ping timeout: 276 seconds). [19:51] notmart: ditto, afraid of latencies .. [19:51] and another thing we should pay attention (and start to actually profiling ;) is the memory usage [19:51] <-- dantti has left this server (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/). [19:52] you've got doubts re qml there? [19:52] aseigo: thanks a lot... [19:53] I'm done otherwise :) [19:53] * aseigo has one more topic whenever we're done with the current lot, just to let notmart know :) [19:53] Sho_: i think with qml one should always pay attention on how many objects is creating and find ways to create the least possible, but yeah, will probably just be a matter of paying attention [19:53] * sebas passes the soapbox on to aseigo [19:53] * notmart is done as well [19:53] just summarize: [19:54] from sebas was owncloud work + fixing interaction problems of the desktop containment? [19:54] activities workflow as well or is unclaimed? [19:54] it's unclaimed [19:55] * aseigo has been gathering requirements for that one [19:55] speaking of handing the soapbox to aseigo .. [19:55] ok, so something will have to be tought about in the future ;) [19:55] aseigo: it's fun to have you back! [19:55] :) [19:55] +1 [19:55] + [19:55] 1 [19:55] +1 [19:55] +1 [19:56] and with that comes the work ;) [19:56] <-- FL1SK has left this server (Remote host closed the connection). [19:56] so /me passes the speak token to aseigo [19:56] <-- bogdan_ has left this server (Ping timeout: 240 seconds). [19:56] so ... one of the things that fits into the activities workflow is SLC [19:56] --> Manko10 has joined this channel (~janek@i577A9124.versanet.de). [19:57] there is one components used by SLC which is written in C++: the fallback component [19:57] SLC is currently pure QML and i'm super hesitant to change that [19:57] (the plasmoid, in any case) [19:57] i could bodge it by adding the component tothe library, but i'd rather not :) [19:57] what does the fallback component do? [19:57] a couple of things may be tried to make that fallback mechanism in pure qml [19:58] so that needs a solution (and imho it really looks like something that should be in kde-runtime after being made reasonably generic ... locking it to the plasma app data dir is not good 'nuff) [19:58] may be not super pretty or performant but working [19:59] sebas: an item used to chose the delegates in plasma active and the delegates for slc, basically "give me foo.qml, bar.qml or baz.qml" [19:59] nah, i think this one method probably has a home in the plasma components [19:59] theand returns the first that actually exists on the disk, in order of priority [19:59] <-- saurabhsood91 has left this server (Read error: Connection reset by peer). [19:59] poked about looking for the best location the other day, still not happy yet, will post a patch when i am [19:59] ah [19:59] but that's a minor thing [19:59] so one can make a delegate for say images and fallback to files if not found [20:00] aye [20:00] thanks [20:00] with that sorted, we have an SLC that does not have a plasma-mobile dependency and can be used with kde-workspace only workspaces [20:00] notmart: right [20:00] after that [20:00] something that can be used for the resourcedelegates as well? [20:00] yes i would love to have slc on the desktop as well [20:00] the next thing on the list for SLC is then giving the ability to load plugins based on the workspace [20:00] e.g. having a "set as wallpaper" (heh ;) plugin but only when its the desktop [20:01] sebas: is used in active for the delegates of resources, yes [20:01] and this ultimately drags in the Uber Feature that were i to dream a dream would debut in 4.10 -> accounts [20:01] apart that small problem, the main issue of slc is probably getting apps to support it [20:01] everything else we've talked about is necessary improvements, qmlifications, etc [20:02] if we can have 1 actually 'new' feature, for me accounts is it [20:02] afiestas had some POC code apparently implementing some JS API as discussed at akademy [20:02] he lost it in a reformat though it seems [20:02] anyways, seems to show that it is possible, and without excessive effort [20:02] he couldn't attend today unfortunately [20:02] i'd like to see it similar to SLC in that it has C++ plugins as well as JS ones [20:03] (yeah, i saw that on the list. hope the demonstration is going well :) [20:03] sebas: accounts? [20:03] yeah :) [20:03] err [20:03] aseigo rather [20:03] Sho_: https://projects.kde.org/projects/playground/base/web-accounts [20:03] need to poke about it what timeframe could be [20:03] accounts -> a unified system for your online (and local) accounts [20:03] d_ed: thanks [20:03] fancy [20:04] i think os x got something like that .. [20:04] so one place to register your facebook account, adjust your local username/password, twitter account, etc. [20:04] yeah, and android and gnome to some extent [20:04] and meego [20:04] oneof the big things is a mechanism to allow applications to "connect to" a given account [20:04] where we could maye even nick plugins [20:04] yes, its called "Mail, Contacts and Calendars" [20:04] both for access control but also to remove the details of account log in / activation from the applications (since it's brittle) [20:04] how does this interact with the fd.o secrets stuff? any overlap or orthogonal? [20:05] orthogonal [20:05] aye [20:05] it will obviously store your secrets in the wallet [20:05] yeah, i wasn't sure if secrets also takes on the problem of state in some way [20:05] Sho_: its just a skin over per-app configuration, the apps still have their own account configuration panes [20:05] Sho_: that is just password storing if i uderstood correctly [20:05] but what accounts are recognized / available (facebook, twitter, kolab, etc etc), how to access them (log in via web? connect via akonadi? etc), etc. [20:05] that is all on top of wallet functionality [20:06] so i've already started poking at that part of the puzzle [20:06] and i'd like to take that for 4.10, possibly expanding to activities workflow in general if that reaches a good place sufficiently quickly (though without help i'm sceptical :) [20:07] * aseigo notes it's a little like tugging on a thread in a sweater .. activities leads to slc leads to accounts [20:08] * aseigo is done now :) [20:08] fredrikh wanted to talk about wayland [20:08] yeah [20:08] we'll see if afiestas still can on that, i'm the usual backup :p [20:08] * aseigo cheers for that [20:08] so as you may or may not know wayland 1.0 will be released in a month or two [20:08] notmart: i've been chatting with him about it .. not going to wait on him though, he has lots on his plate too [20:08] let's go with wayland now so [20:08] fredrikh: yeah, super excited about that [20:09] the design is pretty much fixed, there won't be any more protocol backwards incompatible changes unless it's to fix a major bug [20:09] s/protocol// [20:09] fredrikh: this is interesting to me because of libtaskmanager, which is both a level of abstraction of its own (it has x11 and windows backends) and sits on top of one (the x11 backend heavily calls into kwindowsystem which is abstract as well) [20:10] yeah, i'll get to that in a bit [20:10] yep [20:10] the display server, window manager and compositing manager is the same process in wayland [20:10] and the desktop shell (plasma) is an oop extension of the display server [20:11] only the display server is allowed to start plasma, and it has a special shell interface that only plasma is allowed to bind [20:11] if the user tries to start plasma manually, it will receive a permission denied error when it tries to bind this interface [20:11] you can nest compositors. So display server can be a different process, that launches and nests the kwin compositor (for exmaple). [20:11] --> bogdan_ has joined this channel (~bogdan@37.160.16.103). [20:11] so the display server is also responsible for respawning plasma if it dies for any reason [20:12] the shell interface allows plasma to do certain things, such as define the desktop background surface, the lock surface, create and position panels [20:13] and also to get information about which windows are visible on the display and their geometry and so forth [20:13] * aseigo notes that the lock surface is currently a separate process [20:13] regular clients are not allowed to do any of these things [20:13] aseigo: well, the shell interface is not a standard interface, so we define what's in it [20:13] and we can add other special interfaces for other processes [20:13] ah cool [20:14] what about ksmserver? [20:14] kwin will probably have to swallow it [20:14] not the worst of fates there [20:14] because the system compositor launches kwin, and kwin is then responsible for bringing up the reset of the desktop [20:14] rest* [20:15] so it has implications for a lot of things in kde [20:15] so compositor and session manager have to be the same process? [20:15] probably [20:15] it's something we'll have to explore [20:15] in theory i guess kwin could start the session manager [20:16] --> mgraesslin has joined this channel (~martin@HSI-KBW-134-3-136-144.hsi14.kabel-badenwuerttemberg.de). [20:16] windows are a bit different in wayland... there are basically two types of windows: regular surfaces and transient surfaces [20:16] mgraesslin: fredrikh is just talking about wayland [20:16] I'll post you the recent log in a query [20:17] <-- bogdan_ has left this server (Ping timeout: 276 seconds). [20:17] a transient surface differs from a regular surface in that the client can specify its position relative to its parent surface [20:17] --> bogdan__ has joined this channel (~bogdan@37.160.16.103). [20:17] and the idea is that a transient surface will be a menu, a tooltip, a sheet and so forth [20:17] fredrikh: is this like the old x11 concept of transients (aka dialogs?) [20:17] <-- ksinny_ has left this server (Read error: Connection reset by peer). [20:17] aha.. yes :) [20:17] it's a bit different [20:17] * aseigo is with you now [20:18] and the client is actually not allowed to position or know the position of a regular surface on the screen [20:18] <-- Psifidotos has left this server (Quit: Konversation terminated!). [20:18] a surface also has two properties; a title and the name of a .desktop file [20:18] sebas: thx [20:19] fredrikh: btw I will be at the XDC next week [20:19] the .desktop file is used for grouping, and it's also how the shell knows which icon to use for the window [20:19] mgraesslin: cool [20:20] and that's pretty much all the information the client communicates about a window right now [20:21] that's actually pretty cool ... the explicit tie to a .desktop file will make the dock pattern a lot easier with modern apps [20:21] yeah [20:21] and in general recognizing applications [20:21] the thinking is also that the client will be able to provide menu entries for the window menu [20:21] also we can then use that to map files to it [20:21] --> wstephenson has joined this channel (~wstephens@p3E9C2905.dip.t-dialin.net). [20:21] <-- wstephenson has left this server (Changing host). [20:21] --> wstephenson has joined this channel (~wstephens@kde/opensuse.member.wstephenson). [20:21] * aseigo ponders how we'll do SLC like things under wayland [20:21] so the compositor can merge those entries into its own menu, and also display it in the taskbar [20:21] *** mailson is now known as mailsoff. [20:22] (where we want to be able to associate content with the window its in ... with the application that has created that window telling us what is in it) [20:22] fredrikh: longer-term I'm interested in doing things like jump lists and recent docks in a way that allows for apps to drivethe info [20:22] ... which i guess also has some overlap with slc [20:23] ::plasma:: Plasma :: Re: Troubles wiht deleted .kde folder @ http://forum.kde.org/viewtopic.php?f=67&t=107720&p=250075#p250075 (by rlvetor) [20:24] Sho_: yep, it's rather similar [20:24] *** mailsoff is now known as mailson. [20:24] err, recent _docs_ rather [20:24] suffering muscle memory already [20:24] i'd like to encourage everyone to look at the protocol though and make sure there are no show stoppers for plasma [20:24] because if there's a problem, this is the very last chance to speak up about it [20:25] fredrikh: how ? is there a link ? [20:25] might be good to communicate those till Wednesday so that I can hand them over :-) [20:25] bogdan__: it's defined in a .xml file in the wayland repo [20:25] Sho_: via slc kactivitymanager keeps track of documents opened per window, yeah, the information should be available [20:25] --> krwk has joined this channel (~yaaic@186.29.123.199). [20:26] http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml [20:27] btw. the protocol can very easily be extended, kind of similar to what we have with X Properties (just more sane) [20:27] i think the build system can also generate nicer documentation from it [20:27] there is an xsl and css file around [20:27] <-- krwk has left this server (Read error: Connection reset by peer). [20:27] mgraesslin: yeah, even at runtime [20:27] * notmart will read [20:27] http://wayland.freedesktop.org/docs/html/ [20:27] mgraesslin: how do such extensions work? (since that sounds like what we'd want/need for e.g. slc [20:27] --> bogdan____ has joined this channel (~bogdan@37.160.16.103). [20:27] work == what work do we have to do [20:28] aseigo: sorry, too long ago that I read that part [20:28] ok :) [20:29] mgraesslin: you're off next wednesday to the conference? (so ... 1 week for now aprox) [20:29] yeah, will leave on Tuesday evening, but as it's in Germany I have Internet everywhere [20:29] * aseigo needs to go soon :/ [20:29] <-- d_ed has left this server (Ping timeout: 260 seconds). [20:29] heh... yeah, unlike here in southern france. :/ [20:29] so let's have this wrapped soon? [20:30] aseigo: :) [20:30] are we done about this/ other things to talk about? [20:30] ok, will try and look over wayland docu and note what we may need [20:30] i can't think of anything more to add at the moment [20:30] * aseigo is all done for himself [20:30] fredrikh: thanks for the update, btw.. really cool we have people keeping a finger on this particular pulse [20:30] also, some things about active, iirc bogdan__ had ideas about it? [20:30] oh one thing: we need more devs working on it, if we want it [20:30] np [20:30] mgraesslin: yeah, i actually think that's the biggest problem :) [20:31] * mgraesslin will have soon much more time for it [20:31] because it really is a huge amount of work that needs to be done [20:31] mgraesslin: direction in what needs doing is a pre-req for that i think [20:31] about the stull i'll do for 4.10 for sure the notifications applet port, work with nuno on theme refinements [20:31] *** einar77_work is now known as einar77. [20:31] notmart: I need some time to come with some proposals. [20:31] and will help on slc/whatever is needed [20:31] i imagine it will also become easier to find such devs when wayland becomes more easily tryable by the average hacker/dev [20:31] bogdan__: ok [20:31] * aseigo looks at opensuse and wonders if they have wayland plans [20:31] and meanwhile i'll break the second most used ui element on screen after the window close button, what could possibly go wrong? [20:31] aseigo: yes, in that regard the Wayland 1.0 release is important [20:32] notmart: my intention was to propose this idea of using tablet sensors [20:32] rebecca black os, muahahah :p [20:32] Sho_: nothing, obviously :) [20:32] * mgraesslin wants to push something into 4.10 which uses Wayland just to let it fall on the distro's toes [20:32] ok cool.. with that, i'm going to pack up and start back to the house.. cheers everyone.. great meeting imho and good to "see" y'all again [20:32] --> krwk has joined this channel (~yaaic@186.29.123.199). [20:32] someone can write a summary report for the mailing list? [20:32] aseigo: bon appetit [20:32] * aseigo waves... [20:33] * Sho_ wisely ate _before_ meeting ;) [20:33] bogdan__: yes, they aren't used at all right now, as usual needs someone to work on it... [20:33] we didn't put any effort right now in sensor based screen rotation since in x is quite ugly... [20:34] aseigo: seeya :) [20:34] aseigo bb :) [20:34] we'll get the log and summary on the mailing list [20:34] if there are any takers even better ;) [20:34] * notmart also remebers everybody about http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan#kde-workspace ;) [20:35] * terietor wonders why he can't copy&paste from quassel client