> idea not bad, it can be a bit tricky (what if the applets have a different > size? how the handles would work? when to split again?)
That would need to be well-thought in advance. I'd still see them as separate applets, so separate handles, but only to merge the edges. > what was mentioned is some sort of jumplist, recent documents for tasks, so > slc naturally comes to mind for that I'd go for linked + high scored instead of recent. > yep. > any ui idea for that? The least we could do is the same tooltip as for the pager. The problem with the current activity switcher is that there is no space to do anything more than it already does. >> First of all, we can forget the kdelibs patch that PA uses. So, no >> automatic support of kpart-based applications. > could that instead be merged in frameworks 5 then backported? would make less > of a problem.. For me, that patch was always a fallback. Mainly because it had problems with editable kparts (or at least with kate) that it wasn't possible to get a window id from the part. And another problem was that some parts of an application would support activities that way (akregator in kontact) and other parts wouldn't (other stuff in kontact), and things would report urls like about:something (currently manually filtered in kamd). The same as it would be with accessibility - just a fallback (IMO, a whitelisted fallback) The main aim for me is patching apps individually - ResourceInstance API is quite trivial. Ch! -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
