Fwd: KDE switch desktop direction
-- Forwarded message -- From: Anders Aspegren Søndergaard ander...@gmail.com Date: Mon, Jan 28, 2013 at 5:06 AM Subject: KDE switch desktop direction To: ch...@kde.org Hi When in KDE search and launch activity, scrolling up switches desktop to lower numbers and down to higher numbers. I.e. you go from Desktop n to Desktop n + 1 when scrolling down. Can this be reversed? Anders A. Søndergaard -- Chani www.chani.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Fwd: Help
-- Forwarded message -- From: Mike Vassalotti mvas...@hotmail.com Date: Mon, Nov 5, 2012 at 1:29 PM Subject: Help To: ch...@kde.org Dear Chani, I use Linux Open SUSE in Oracle Virtual Box. Everything is working fine except for one: I cannot get the mouse wheel to work for scrolling on the various windows. Using Desktop - Desktop Settings - Mouse Actions (which you developed), shown below, I was able to set the first button (Middle-Button) on the screen below to turn into Scroll a couple of times, after trying numerous times, but, then, somehow, the scroll was lost, and I am not sure how I did it when I did it. Can you please explain in simple words, perhaps by providing the key/click sequence, what to type/click to enable the mouse wheel? I know, there are tooltips when clicking/gliding on the buttons, but they are not helpful. Thanks. Regards, Mike Vassalotti Herndon, Virginia USA -- Chani www.chani.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Fwd: Switch Desktop is cool but is would be better
not sure if this is worth adding a config option, but it would be easy for someone looking for a JJ. -- Forwarded message -- From: Kurokawa Tatsuya worktheth...@gmail.com Date: Wed, Mar 21, 2012 at 7:04 PM Subject: Switch Desktop is cool but is would be better To: ch...@kde.org Hi Chani, I am new KDE user. Recently I am using your Switch Desktop function with Mouse Actions. I want to suggest that if Switch Desktop can custom the direction of virtual Desktop switing. It would be better. Currently when i Vertical-Scroll down it function like virtual desktop 2 - virtual desktop 3, mouse up it is 2-1. Actually I wish it can be reverse ordering. for example . whell down it function like virtual desktop 2 - virtual desktop 1. Just a feedback. have a nice day. -- - To live is just a feeling. Best regards, Tsai, Pei-Chen Kurokawa Tatsuya Nostrum Blackeyes -- Chani www.chani.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: adding actions to the standard menu
On June 25, 2011 00:59:01 you wrote: Hi, I'm using KDE 4.6.3 on Fedora 14. I would like to add an action to the standard menu. Specifically, I would like to run the sleep action by popping up the standard menu using the right mouse button on the desktop and then to select sleep with the left mouse button. How can I make this change? Thanks in advance Roberto hmm. the standard menu doesn't have that as an option. you'd have to add it to the code... I can't remember exactly where that plugin lives, but the plasma- devel list can tell you. :) it would just be a matter of adding another action, like the logout one, and code to carry it out. if you're not sure how to invoke sleep, I'm sure there's an example in some other applet. iirc it was *very* similar to logout. oh, and watch out for the ugly hack I did to set which actions are on by default. if you want other people to benefit from your patch too, you can either submit it to the plasma team, or put your own plugin up on kde-apps.org. -- Chani http://chani.ca signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma doesn't follow Kiosk restrictions
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5823/#review8624 --- no, I don't think this is correct. check out line 880: ImmutabilityType Applet::immutability() const that function doesn't return d-immutability, but the strongest of that and various other checks. and it suggests that Corona::immutability() should be responsible for checking kiosk things. I'm not sure what checkImmutability is supposed to be doing, but setting d-immutability isn't it ;) ...also note that, once you set SystemImmutable, you can't unset it. at least that's how the code read to me. so test that kiosk can both lock *and* unlock things ;) - Chani On 2010-11-10 16:39:31, Lubos Lunak wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5823/ --- (Updated 2010-11-10 16:39:31) Review request for Plasma and Marco Martin. Summary --- Probably as a result of r800724, Plasma doesn't seem to follow Kiosk restrictions at all (just grep the sources for where SystemImmutable is assigned to something - it isn't). This patch may possibly be a suitable fix. Diffs - trunk/KDE/kdelibs/plasma/applet.cpp 1182745 Diff: http://svn.reviewboard.kde.org/r/5823/diff Testing --- Thanks, Lubos ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdebase/workspace/plasma/desktop/shell
SVN commit 1194120 by chani:
containments with invalid ID are deleted instead of respawning
(unless the activitymanager is down, of course)
do you think I should do the same for all orphans, if a migration has
already happened?
CCMAIL:plasma-devel@kde.org
M +9 -11 desktopcorona.cpp
--- trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopcorona.cpp
#1194119:1194120
@@ -533,9 +533,8 @@
QStringList newActivities;
QString newCurrentActivity;
-QHashQString,QString invalidIds;
//migration checks:
-//-containments with an invalid id are given a new one and kept together.
+//-containments with an invalid id are deleted.
//-containments that claim they were on a screen are kept together, and
are preferred if we
//need to initialize the current activity.
//-containments that don't know where they were or who they were with just
get made into their
@@ -548,15 +547,13 @@
QString oldId = context-currentActivityId();
if (!oldId.isEmpty()) {
if (existingActivities.contains(oldId)) {
-continue;
+continue; //it's already claimed
}
kDebug() invalid id oldId;
-if (invalidIds.contains(oldId)) {
-//it belongs with one of the already-rescued ones
-context-setCurrentActivityId(invalidIds.value(oldId));
+//byebye
+cont-destroy(false);
continue;
}
-}
if (cont-screen() -1) {
//it belongs on the current activity
if (!newCurrentActivity.isEmpty()) {
@@ -572,9 +569,6 @@
QString id =
m_activityController-addActivity(context-currentActivity());
context-setCurrentActivityId(id);
newActivities id;
-if (!oldId.isEmpty()) {
-invalidIds.insert(oldId, id);
-}
if (cont-screen() -1) {
newCurrentActivity = id;
}
@@ -598,7 +592,11 @@
if (existingActivities.isEmpty()) {
if (newCurrentActivity.isEmpty()) {
if (newActivities.isEmpty()) {
-kDebug() no activities!?! can't happen!!!;
+kDebug() no activities!?! Bad activitymanager, no
cookie!;
+QString id =
m_activityController-addActivity(i18n(unnamed));
+activityAdded(id);
+m_activityController-setCurrentActivity(id);
+kDebug() created emergency activity id;
} else {
m_activityController-setCurrentActivity(newActivities.first());
}
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: activities dataengine
On 2010-10-28 18:45:00, Albert Astals Cid wrote: Which of the strings you add here will be shown to the user? none... unless some plasmoid decides to dump the raw data straight to widgets (which would be dumb in this case) or they're using plasmaengineexplorer (in which case they're a developer and probably want to know the literal strings). so maybe I shouldn't have messages.sh after all? - Chani --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5707/#review8414 --- On 2010-10-28 17:09:34, Chani Armitage wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5707/ --- (Updated 2010-10-28 17:09:34) Review request for Plasma and Albert Astals Cid. Summary --- this is a basic activities dataengine. no frills to start with, just a source for each activity. the service allows setting the current activity (other features, like setting an activity's name, can be added later). it uses KActivityController and friends internally. I'm not sure if I got the i18n right, though - I can't remember how that works for dataengines. Diffs - /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION trunk/KDE/kdebase/workspace/plasma/generic/applets/activitybar/activitybar.h 1188056 trunk/KDE/kdebase/workspace/plasma/generic/applets/activitybar/activitybar.cpp 1188056 trunk/KDE/kdebase/workspace/plasma/generic/dataengines/CMakeLists.txt 1188056 Diff: http://svn.reviewboard.kde.org/r/5707/diff Testing --- I've updated the ActivityBar plasmoid to use the engine, and it works with no regressions :) Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: activity templates
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5709/ --- Review request for Plasma. Summary --- whee! this turned out to be quite easy, actually. :) activity templates work peoprly now - an activity is created, and any containments the script makes are added to it. it also takes on the name and icon from the metadata by default. :) all that's missing is a GHNS button! I created one template to demo this - a photos activity. it's not as good as it could be (all plasmoids are in the topleft of screen 0) but it's a start :) Diffs - /dev/null PRE-CREATION /dev/null PRE-CREATION trunk/KDE/kdebase/workspace/plasma/desktop/shell/CMakeLists.txt 1188056 trunk/KDE/kdebase/workspace/plasma/desktop/shell/activitymanager/filterbar.cpp 1188056 trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.h 1188056 trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp 1188056 trunk/KDE/kdebase/workspace/plasma/generic/containmentactions/applauncher/launch.cpp 1188056 Diff: http://svn.reviewboard.kde.org/r/5709/diff Testing --- works fine on single-screen. I don't have a multiscreen setup atm, but I expect it won't cause any problems. Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: activity templates
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5709/#review8417 --- wait, why did I post this? it's so trivial.. I'll just commit :) - Chani On 2010-10-28 21:08:41, Chani Armitage wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5709/ --- (Updated 2010-10-28 21:08:41) Review request for Plasma. Summary --- whee! this turned out to be quite easy, actually. :) activity templates work peoprly now - an activity is created, and any containments the script makes are added to it. it also takes on the name and icon from the metadata by default. :) all that's missing is a GHNS button! I created one template to demo this - a photos activity. it's not as good as it could be (all plasmoids are in the topleft of screen 0) but it's a start :) Diffs - /dev/null PRE-CREATION /dev/null PRE-CREATION trunk/KDE/kdebase/workspace/plasma/desktop/shell/CMakeLists.txt 1188056 trunk/KDE/kdebase/workspace/plasma/desktop/shell/activitymanager/filterbar.cpp 1188056 trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.h 1188056 trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp 1188056 trunk/KDE/kdebase/workspace/plasma/generic/containmentactions/applauncher/launch.cpp 1188056 Diff: http://svn.reviewboard.kde.org/r/5709/diff Testing --- works fine on single-screen. I don't have a multiscreen setup atm, but I expect it won't cause any problems. Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
notification text
so... uhm... I've run into a rather compelling use case for being able to read and copy the full text of notifications: http://chani.ca/sshots/mailfail.png it seem gmail won't let me use kmail until I visit that url (at least, I *hope* visiting that url would fix it, because just logging in doesn't) -- This message brought to you by evyl bananas and the number 3. www.chani3.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Microblog: small patch so that microblog remembers the password even when kwallet is disabled
On 2010-10-21 15:39:47, Marco Martin wrote: for me is okay, even if an obscured password directly in the config file isn't great... some time ago it did already this thing, why was it removed? good question. Mohit, you should look in the svn log and see if there was a reason it was removed... but since it was still *writing* it and just not reading it, my guess would be that someone wasn't paying attention and removed it accidentally. - Chani --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5679/#review8290 --- On 2010-10-21 18:19:51, Mohit Kothari wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5679/ --- (Updated 2010-10-21 18:19:51) Review request for Plasma. Summary --- It was a bug posted on bugs.kde.org, Here is the link: https://bugs.kde.org/show_bug.cgi?id=242377 Well it did stored the password in config file but never read it. So i just added the reading feature and reloaded the history. Diffs - svn://anonsvn.kde.org/home/kde/trunk/KDE/kdeplasma-addons/applets/microblog/microblog.cpp 1188219 Diff: http://svn.reviewboard.kde.org/r/5679/diff Testing --- I tested it on kdeplasma-addons revision 1187571 Thanks, Mohit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: activity sessions in ksmserver and kwin
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5638/ --- (Updated 2010-10-18 12:20:20.183265) Review request for kwin, Plasma and Lubos Lunak. Changes --- forgot about legacy sessions (what are they?) Summary (updated) --- so, this is the activity session code. it's not 100% complete, because kwin has to fake a few things until the activities service gets its new api - but ivan's working on that. :) there won't be any UI for it until that api's in anyways. kwin handles the mapping from activity id - windows - session ids, because I had to call it anyways, and it's much easier to calculate from inside kwin. The good: it can save and restore processes and their windows' activity associations all the regular xsmp stuff seems to be working, except cancel. I've done it by merely adding a few dbus methods, no changes to xsmp itself ksmserver doesn't know or care what activities are; even the kwin code is separated out into find the clients for this activity and save a session for these clients The bad: since ksmserver doesn't tell the wm or clients that anything special is happening, it can't tell kwin save the subsession data, or tell clients close only window foo. for kwin this is actually a nice excuse to have it do the mapping work, but for clients it means we can't close anything until we're ready to close everything. Clients would have to be made context-aware either way to react to such a request; for 4.7 I might see if I can do it by extending xsmp or augmenting it with more dbus (instead of having the client do all the work after the session's closed, as I originally planned). kwrite's cancel button doesn't cancel the session-close. it works on logout, so there must be a bug in my code. session data isn't deleted when an activity is deleted (I forgot). I'd like to get this patch in ASAP though, and add simple details like that later - the patch is already quite big enough ;) there's some legacy session code, I haven't read it all and I haven't implemented support for it yet. are there any apps using it? does it matter? what *is* this legacy session thing? The ugly: there are some sync issues in here. first of all, we have a conflict between save-on-close and save-regularly. all xsmp stuff is save-on-close, whereas the activity service and plasma (and other modern apps) save quite often. If you open an activity and then X crashes, you've lost all session data for that activity. :( I'm planning to try fixing that by saving (but not quitting) the login session when an activity is opened/closed. I'm not sure how well it'd work, but it should at least keep the correct list of processes to start. the second sync issue comes from the fact that a window can be open on a closed activity. I'll probably prevent the user from adding a window to a closed activity, but windows that are already shared across activities... well, they could behave in unexpected ways. I think I'd like to do more tests before deciding how to handle that - but one thing that could help, perhaps, is storing the kwin session info in one big pool for all closed activities instead of a separate group for each activity. Diffs - trunk/KDE/kdebase/workspace/ksmserver/server.h 1186160 trunk/KDE/kdebase/workspace/ksmserver/legacy.cpp 1186160 trunk/KDE/kdebase/workspace/ksmserver/org.kde.KSMServerInterface.xml 1186160 trunk/KDE/kdebase/workspace/ksmserver/server.cpp 1186160 trunk/KDE/kdebase/workspace/ksmserver/shutdown.cpp 1186160 trunk/KDE/kdebase/workspace/ksmserver/startup.cpp 1186160 trunk/KDE/kdebase/workspace/kwin/org.kde.KWin.xml 1186160 trunk/KDE/kdebase/workspace/kwin/sm.cpp 1186160 trunk/KDE/kdebase/workspace/kwin/workspace.h 1186160 Diff: http://svn.reviewboard.kde.org/r/5638/diff Testing --- I can use dbus to save/restore an activity, like I showed in my screencast ( http://chani.wordpress.com/2010/10/04/activities-fun-with-screencast ). I haven't done much testing of multi-window processes, though, or saving and restoring multiple activities. Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: activity sessions in ksmserver and kwin
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5638/ --- Review request for kwin and Plasma. Summary --- so, this is the activity session code. it's not 100% complete, because kwin has to fake a few things until the activities service gets its new api - but ivan's working on that. :) there won't be any UI for it until that api's in anyways. kwin handles the mapping from activity id - windows - session ids, because I had to call it anyways, and it's much easier to calculate from inside kwin. The good: it can save and restore processes and their windows' activity associations all the regular xsmp stuff seems to be working, except cancel. I've done it by merely adding a few dbus methods, no changes to xsmp itself ksmserver doesn't know or care what activities are; even the kwin code is separated out into find the clients for this activity and save a session for these clients The bad: since ksmserver doesn't tell the wm or clients that anything special is happening, it can't tell kwin save the subsession data, or tell clients close only window foo. for kwin this is actually a nice excuse to have it do the mapping work, but for clients it means we can't close anything until we're ready to close everything. Clients would have to be made context-aware either way to react to such a request; for 4.7 I might see if I can do it by extending xsmp or augmenting it with more dbus (instead of having the client do all the work after the session's closed, as I originally planned). kwrite's cancel button doesn't cancel the session-close. it works on logout, so there must be a bug in my code. session data isn't deleted when an activity is deleted (I forgot). I'd like to get this patch in ASAP though, and add simple details like that later - the patch is already quite big enough ;) The ugly: there are some sync issues in here. first of all, we have a conflict between save-on-close and save-regularly. all xsmp stuff is save-on-close, whereas the activity service and plasma (and other modern apps) save quite often. If you open an activity and then X crashes, you've lost all session data for that activity. :( I'm planning to try fixing that by saving (but not quitting) the login session when an activity is opened/closed. I'm not sure how well it'd work, but it should at least keep the correct list of processes to start. the second sync issue comes from the fact that a window can be open on a closed activity. I'll probably prevent the user from adding a window to a closed activity, but windows that are already shared across activities... well, they could behave in unexpected ways. I think I'd like to do more tests before deciding how to handle that - but one thing that could help, perhaps, is storing the kwin session info in one big pool for all closed activities instead of a separate group for each activity. Diffs - trunk/KDE/kdebase/workspace/ksmserver/server.h 1186160 trunk/KDE/kdebase/workspace/ksmserver/legacy.cpp 1186160 trunk/KDE/kdebase/workspace/ksmserver/org.kde.KSMServerInterface.xml 1186160 trunk/KDE/kdebase/workspace/ksmserver/server.cpp 1186160 trunk/KDE/kdebase/workspace/ksmserver/shutdown.cpp 1186160 trunk/KDE/kdebase/workspace/ksmserver/startup.cpp 1186160 trunk/KDE/kdebase/workspace/kwin/org.kde.KWin.xml 1186160 trunk/KDE/kdebase/workspace/kwin/sm.cpp 1186160 trunk/KDE/kdebase/workspace/kwin/workspace.h 1186160 Diff: http://svn.reviewboard.kde.org/r/5638/diff Testing --- I can use dbus to save/restore an activity, like I showed in my screencast ( http://chani.wordpress.com/2010/10/04/activities-fun-with-screencast ). I haven't done much testing of multi-window processes, though, or saving and restoring multiple activities. Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Corona::exportLayout
On 2010-09-26 20:22:05, Aaron Seigo wrote: trunk/KDE/kdelibs/plasma/corona.cpp, lines 359-362 http://svn.reviewboard.kde.org/r/5451/diff/1/?file=38404#file38404line359 what does calling updateConstraints even do in this case? looking at the code in Applet, this just schedules a call to flushPendingConstraintsEvents with a timer. is it actually needed at all? iirc, it propogates the change to the applets... hmm, which wouldn't work if they were systemimmutable. so I ought to do it myself instead. On 2010-09-26 20:22:05, Aaron Seigo wrote: trunk/KDE/kdelibs/plasma/corona.cpp, line 340 http://svn.reviewboard.kde.org/r/5451/diff/1/?file=38404#file38404line340 this should probably take a KConfigGroup, since KConfigGroup can refer to the top level item, e.g. the whole config file, using the magic QString() name for the group. unfortunately, Corona::importLayout() requires a KConfigBase which would make this assymetrical. iirc that bit of the API was written before i was aware of that KConfigGroup trick (which was actually undocumented until i found out about it :). perhaps we should add an importLayout that takes a KConfigGroup, mark the importLayout which takes a KConfigBase as deprecaton and have it call the new one. then we have a nice api with symmetry? so... void Corona::exportLayout(KConfigGroup *config, QListContainment* containments) and void Corona::importLayout(KConfigGroup *config) - Chani --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5451/#review7824 --- On 2010-09-25 16:51:30, Chani Armitage wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5451/ --- (Updated 2010-09-25 16:51:30) Review request for Plasma. Summary --- this adds exportLayout to corona, which saves a group of containments to a config file and deletes them from the main config. Activity::close() becomes a lot shorter by calling it, like this: m_corona-exportLayout(external, m_containments.values()); I feel a bit out of it today though, so tell me if I've missed anything obvious... Diffs - trunk/KDE/kdelibs/plasma/corona.cpp 1177115 trunk/KDE/kdelibs/plasma/corona.h 1177115 Diff: http://svn.reviewboard.kde.org/r/5451/diff Testing --- closing an activity while locked is perfectly safe now :) Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Corona::exportLayout
On 2010-09-26 20:22:05, Aaron Seigo wrote:
trunk/KDE/kdelibs/plasma/corona.cpp, line 340
http://svn.reviewboard.kde.org/r/5451/diff/1/?file=38404#file38404line340
this should probably take a KConfigGroup, since KConfigGroup can refer
to the top level item, e.g. the whole config file, using the magic
QString() name for the group.
unfortunately, Corona::importLayout() requires a KConfigBase which
would make this assymetrical. iirc that bit of the API was written before i
was aware of that KConfigGroup trick (which was actually undocumented until
i found out about it :).
perhaps we should add an importLayout that takes a KConfigGroup, mark
the importLayout which takes a KConfigBase as deprecaton and have it call
the new one.
then we have a nice api with symmetry?
Chani Armitage wrote:
so... void Corona::exportLayout(KConfigGroup *config, QListContainment*
containments)
and void Corona::importLayout(KConfigGroup *config)
Aaron Seigo wrote:
KConfigGroup , but otherwise, yes...
I thought it was bad form to use without const...?
On 2010-09-26 20:22:05, Aaron Seigo wrote:
trunk/KDE/kdelibs/plasma/corona.cpp, lines 359-362
http://svn.reviewboard.kde.org/r/5451/diff/1/?file=38404#file38404line359
what does calling updateConstraints even do in this case? looking at
the code in Applet, this just schedules a call to
flushPendingConstraintsEvents with a timer. is it actually needed at all?
Chani Armitage wrote:
iirc, it propogates the change to the applets... hmm, which wouldn't work
if they were systemimmutable.
so I ought to do it myself instead.
Aaron Seigo wrote:
i don't think updateConstraints does anything like that since here's the
code of that method:
// Don't start up a timer if we're just starting up
// flushPendingConstraints will be called by Corona
if (started !constraintsTimer.isActive() !(c
Plasma::StartupCompletedConstraint)) {
constraintsTimer.start(0, q);
}
if (c Plasma::StartupCompletedConstraint) {
started = true;
}
pendingConstraints |= c;
which means nothing happens until the event loop is hit again. setting
the immutability makes sense, just not the call to updateConstraints.
it's in ContainmentPrivate::containmentConstraintsEvent()
but anyways, moot point now :) I'll have it iterate through the applets and
access their dptr to force it to mutable.
- Chani
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5451/#review7824
---
On 2010-09-25 16:51:30, Chani Armitage wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5451/
---
(Updated 2010-09-25 16:51:30)
Review request for Plasma.
Summary
---
this adds exportLayout to corona, which saves a group of containments to a
config file and deletes them from the main config.
Activity::close() becomes a lot shorter by calling it, like this:
m_corona-exportLayout(external, m_containments.values());
I feel a bit out of it today though, so tell me if I've missed anything
obvious...
Diffs
-
trunk/KDE/kdelibs/plasma/corona.cpp 1177115
trunk/KDE/kdelibs/plasma/corona.h 1177115
Diff: http://svn.reviewboard.kde.org/r/5451/diff
Testing
---
closing an activity while locked is perfectly safe now :)
Thanks,
Chani
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Corona::exportLayout
On 2010-09-26 20:22:05, Aaron Seigo wrote: trunk/KDE/kdelibs/plasma/corona.cpp, line 340 http://svn.reviewboard.kde.org/r/5451/diff/1/?file=38404#file38404line340 this should probably take a KConfigGroup, since KConfigGroup can refer to the top level item, e.g. the whole config file, using the magic QString() name for the group. unfortunately, Corona::importLayout() requires a KConfigBase which would make this assymetrical. iirc that bit of the API was written before i was aware of that KConfigGroup trick (which was actually undocumented until i found out about it :). perhaps we should add an importLayout that takes a KConfigGroup, mark the importLayout which takes a KConfigBase as deprecaton and have it call the new one. then we have a nice api with symmetry? Chani Armitage wrote: so... void Corona::exportLayout(KConfigGroup *config, QListContainment* containments) and void Corona::importLayout(KConfigGroup *config) Aaron Seigo wrote: KConfigGroup , but otherwise, yes... Chani Armitage wrote: I thought it was bad form to use without const...? oh, for import is would be const KConfigGroup , duhh. :) but for export, KConfigGroup* is more correct, right? - Chani --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5451/#review7824 --- On 2010-09-25 16:51:30, Chani Armitage wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5451/ --- (Updated 2010-09-25 16:51:30) Review request for Plasma. Summary --- this adds exportLayout to corona, which saves a group of containments to a config file and deletes them from the main config. Activity::close() becomes a lot shorter by calling it, like this: m_corona-exportLayout(external, m_containments.values()); I feel a bit out of it today though, so tell me if I've missed anything obvious... Diffs - trunk/KDE/kdelibs/plasma/corona.cpp 1177115 trunk/KDE/kdelibs/plasma/corona.h 1177115 Diff: http://svn.reviewboard.kde.org/r/5451/diff Testing --- closing an activity while locked is perfectly safe now :) Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Corona::exportLayout
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5451/ --- (Updated 2010-09-27 14:38:42.056313) Review request for Plasma. Changes --- updated API and fixed the immutability thing Summary --- this adds exportLayout to corona, which saves a group of containments to a config file and deletes them from the main config. Activity::close() becomes a lot shorter by calling it, like this: m_corona-exportLayout(external, m_containments.values()); I feel a bit out of it today though, so tell me if I've missed anything obvious... Diffs (updated) - trunk/KDE/kdelibs/plasma/corona.h 1179499 trunk/KDE/kdelibs/plasma/corona.cpp 1179499 Diff: http://svn.reviewboard.kde.org/r/5451/diff Testing --- closing an activity while locked is perfectly safe now :) Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Corona::exportLayout
this should probably take a KConfigGroup, since KConfigGroup can refer to the top level item, e.g. the whole config file, using the magic QString() name for the group. the magic qstring thing means it takes two lines to call exportLayout. what's the benefit? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
activity sessions
hey guys, some of you may remember me rambling about actvities and session support. :) I've actually been working on this recently and I'd like some feedback from people who know more about the technologies involved. now, in my current plan, closing an actvity will go something like this: *plasma asks actvitymanager kded to close activity Foo, and draws a pretty busy-animation for it *activitymanager figures out which session clients have windows on that activity, and asks ksmserver to save those clients under the activity's name (I'm glossing over a lot of details here btw) *ksmserver goes about saving this sub-session (it doesn't actually know that it's an activity at all) *ksmserver reports that it either cancelled, or successfully closed, that group of clients *actvitymanager reports that that activity was closed (or not) *plasma does its activity shutdown (it's both easier and prettier to do it after the windows) - unless it was cancelled in which case it just un-busies. *context-aware applications may react to the shutdown notice (eg. closing some of their resources if they're on multiple activities) and resuming the activity goes something like this: *plasma tells activitymanager to switch to the closed activity Foo, which implicitly opens it *plasma loads up its own containment stuff *activitymanager tells ksmserver to restore that group *ksmserver happily does so *kwin somehow magically figures out how to reassociate those new windows with their actvities (erm, this part is a bit fuzzy still) *context-aware applications may react by reopening things they'd closed, or telling kwin exactly which windows were on which activities now, this isn't perfect - a perfect solution doesn't exist here - but I think it's close to optimal. :) we get basic session support for all apps, instantly, regardless of whether they're context-aware (which none are, right now). it's basic in that it's at the client level, not the window level; if a process is likely to have multiple windows spread across different activities (hopefullly that's just a few, eg. konq, FF and OOo) then it'll need to manage the details itself (with the help of KActivityConsumer I'm sure). another good thing is that ksmserver doesn't need to be tied to activities; it just gets this extra little feature of subsessions (two dbus functions, that's all), and does what it's told, and maybe that could even become part of XSMP someday? now, something that's less good about this design is that it puts code into the activitymanager kded, and ivan was worried about that because apparently a crash would take down all of kded and would be Very Bad, and so these kded modules are supposed to be very small. I haven't thought of any better home for the mapping code, though; it would probably be easier to do from kwin, but then you'd need a dbus roundtrip to kwin added into the closing... the code in question I haven't written yet, but it needs to go something like this: foreach x window: if activities contains activityID: get clientID clientsToSave clientID if activities doesn't contain any other *open* activity: clientsToKill clientID ksmserver.saveSubSession(activityID, clientsToSave, clientsToKill) where do you think that belongs... kwin, activitymanager kded, or ksmserver? and btw... who maintains ksmserver? lubos? thinking a bit more, maybe kwin could restore its activity associations by tracking the clientids - but due to the silly way xsmp is designed, if it wants to behave well after a crash (or other logout failure) it'd need to do some bookkeeping when an activity is about to close (but before it closes)... maybe such session bookkeeping is better off in ksmserver, maybe it'd be better to make ksmserver activity-aware after all... or maybe I should just ignore xsmp's lack of autosave :P ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities and locking
On September 24, 2010 20:41:47 Aaron J. Seigo wrote: On Friday, September 24, 2010, Chani wrote: and while one may question whether deleting should be allowed while locked, stopping while locked makes perfect sense. so i just ran across a related issue today on b.k.o[1]: when a new desktop or a new screen comes or goes, containments will get added ... but they can't actually be removed. currently they aren't (and that causes other issues), but i think that when you remove a virtual desktop when using PVD, then the containment associated with that desktop should go away too. i'm not particularly sure how i'd like to manage that atm. need to think about it a bit more. hmm. I used to think containments should be kept around, but... you're right, it's better to delete it. removing a virtual desktop is an entirely intentional act (at least so far), not like screens which can get accidentally unplugged. :) how would this affect the do you want to delete all the extra containments? question when PVD is disabled? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/kwin
On September 24, 2010 18:24:33 Aaron J. Seigo wrote: On Friday, September 24, 2010, Chani wrote: On September 24, 2010 14:03:23 Chani Armitage wrote: SVN commit 1179043 by chani: Use an X property for activity associations the new property name is _KDE_NET_WM_ACTIVITIES, of type XA_STRING, and it's a comma-separated list of activity UUIDs. so, who's interested in upgrading libtaskmanager to read this property? :) what does libtaskmanager need to do with it? will kwin not just unmap the window in a way that removes it from the task listing, or do we really need to duplicate that filtering in the window list management library? err... kwin can do that? I don't know enough about this stuff... what I want to see is the taskbar not showing windows from other activities. the pager could probably do with a similar thing, since it shows little window outlines. it'd also be nice if right-clicking a task in the taskbar had an activities menu below the desktops one, like the titlebar's contextmenu. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/kwin
On September 25, 2010 14:41:21 Martin Gräßlin wrote: On Saturday 25 September 2010 12:20:33 Chani wrote: On September 24, 2010 18:24:33 Aaron J. Seigo wrote: On Friday, September 24, 2010, Chani wrote: On September 24, 2010 14:03:23 Chani Armitage wrote: SVN commit 1179043 by chani: Use an X property for activity associations the new property name is _KDE_NET_WM_ACTIVITIES, of type XA_STRING, and it's a comma-separated list of activity UUIDs. so, who's interested in upgrading libtaskmanager to read this property? :) what does libtaskmanager need to do with it? will kwin not just unmap the window in a way that removes it from the task listing, or do we really need to duplicate that filtering in the window list management library? err... kwin can do that? I don't know enough about this stuff... what I want to see is the taskbar not showing windows from other activities. the pager could probably do with a similar thing, since it shows little window outlines. Or to have a group by activities like group by desktop feature for taskbar. I think it will be required to adjust libtaskmanager - I cannot see what kwin can do about it. that reminds me, why is there group by desktop and not sort by desktop? :) personally, though, I'd like to see windows from other activities just plain not show up in the taskbar. *can* we do that from kwin? it'd also be nice if right-clicking a task in the taskbar had an activities menu below the desktops one, like the titlebar's contextmenu. Yep, duplicating the menu is just a bad idea. Actually we have it three times: one time in kwin, one time for the taskmanager and one time duplicated in Compiz. Could we get this menu as a shared lib? This would also be nice as we could get the window tab features into the tasks menu. ouchies. yeah, there's gotta be a way to deduplicate that code.. right? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Corona::exportLayout
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5451/ --- Review request for Plasma. Summary --- this adds exportLayout to corona, which saves a group of containments to a config file and deletes them from the main config. Activity::close() becomes a lot shorter by calling it, like this: m_corona-exportLayout(external, m_containments.values()); I feel a bit out of it today though, so tell me if I've missed anything obvious... Diffs - trunk/KDE/kdelibs/plasma/corona.cpp 1177115 trunk/KDE/kdelibs/plasma/corona.h 1177115 Diff: http://svn.reviewboard.kde.org/r/5451/diff Testing --- closing an activity while locked is perfectly safe now :) Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
activities and locking
[this is a summary of an irc discussion today...] so, I finally found out how to reproduce the elusive activity-duplication bug. :) it happens when plasma is locked: stopping the activity copies its config out to a separate file, then tries to remove it from plasma-desktop-appletsrc, but Applet::destroy() ignores attempts to delete the containment and its applets. now you've got two copies of the containment(s) - and when plasma-desktop is restarted, it finds this extra containment and helpfully creates a new activity for it so that it's accessible. it doesn't matter whether you delete the activity, it's the stopping that's the cause. and while one may question whether deleting should be allowed while locked, stopping while locked makes perfect sense. what we're going to do about this in trunk: the code for the activity stopping will be moved into Corona under a name like exportLayout (to mirror importLayout). it won't actually know about activities, it'll just know that a certain bit of config needs exporting to a certain file. it'll temporarily unlock the corona so that it can do its work in peace, and restore the old setting when it's done (this is something that can only be done within corona if SystemImmutable is on). that new API is a bit much for backporting, though, so in 4.5.2+ the UI won't allow closing or deleting while widgets are locked. aaron's gonna put in some pretty UI for that. :) note to self: wtf is Activity::save() doing there? it looks like stale code that needs deleting... and destroy()'s deletion of running containments is redundant so long as we only allow deleting stopped ones, but oh well... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdebase/workspace/kwin
SVN commit 1179043 by chani:
Use an X property for activity associations
the new property name is _KDE_NET_WM_ACTIVITIES, of type XA_STRING,
and it's a comma-separated list of activity UUIDs.
kwin should respond to other processes changing the activity list for a
window, and filter out any bogus IDs. It also caches KActivityController's
list of activities to prevent dbus deadlocks.
CCMAIL: plasma-devel@kde.org
M +3 -0 atoms.cpp
M +1 -0 atoms.h
M +40 -6 client.cpp
M +2 -0 client.h
M +2 -0 events.cpp
M +3 -0 manage.cpp
M +8 -0 workspace.cpp
M +4 -0 workspace.h
--- trunk/KDE/kdebase/workspace/kwin/atoms.cpp #1179042:1179043
@@ -38,6 +38,9 @@
atoms[n] = kwin_running;
names[n++] = (char *) KWIN_RUNNING;
+atoms[n] = activities;
+names[n++] = (char *) _KDE_NET_WM_ACTIVITIES;
+
atoms[n] = wm_protocols;
names[n++] = (char *) WM_PROTOCOLS;
--- trunk/KDE/kdebase/workspace/kwin/atoms.h #1179042:1179043
@@ -34,6 +34,7 @@
Atoms();
Atom kwin_running;
+Atom activities;
Atom wm_protocols;
Atom wm_delete_window;
--- trunk/KDE/kdebase/workspace/kwin/client.cpp #1179042:1179043
@@ -1523,13 +1523,12 @@
*/
void Client::setOnActivity( const QString activity, bool enable )
{
-if( activityList.contains(activity) == enable ) //nothing to do
+QStringList newActivitiesList = activities();
+if( newActivitiesList.contains(activity) == enable ) //nothing to do
return;
-//check whether we should set it to all activities
-QStringList newActivitiesList = activityList;
if (enable)
{
-QStringList allActivities = KActivityConsumer().availableActivities();
+QStringList allActivities = workspace()-activityList();
if( !allActivities.contains(activity) ) //bogus ID
return;
newActivitiesList.append(activity);
@@ -1544,13 +1543,19 @@
*/
void Client::setOnActivities( QStringList newActivitiesList )
{
-QStringList allActivities = KActivityConsumer().availableActivities();
+QStringList allActivities = workspace()-activityList();
if( newActivitiesList.size() == allActivities.size() ||
newActivitiesList.isEmpty() )
{
setOnAllActivities(true);
return;
}
+
+QByteArray joined = newActivitiesList.join(,).toAscii();
+char *data = joined.data();
activityList = newActivitiesList;
+XChangeProperty(display(), window(), atoms-activities, XA_STRING, 8,
+PropModeReplace, (unsigned char *)data, joined.size());
+
updateActivities( false );
}
@@ -1589,7 +1594,6 @@
* Returns the list of activities the client window is on.
* if it's on all activities, the list will be empty.
* Don't use this, use isOnActivity() and friends (from class Toplevel)
- * FIXME do I need to consider if it's not mapped yet?
*/
QStringList Client::activities() const
{
@@ -1622,6 +1626,7 @@
if( on )
{
activityList.clear();
+XDeleteProperty( display(), window(), atoms-activities );
updateActivities( true );
}
else
@@ -2216,6 +2221,35 @@
return p;
}
+void Client::checkActivities()
+{
+QStringList newActivitiesList;
+QByteArray prop = getStringProperty(window(), atoms-activities);
+if ( ! prop.isEmpty() )
+newActivitiesList = QString(prop).split(',');
+
+if (newActivitiesList == activityList)
+return; //expected change, it's ok.
+
+//otherwise, somebody else changed it. we need to validate before reacting
+QStringList allActivities = workspace()-activityList();
+if (allActivities.isEmpty())
+{
+kDebug() no activities!?!?;
+//don't touch anything, there's probably something bad going on and we
don't wanna make it worse
+return;
+}
+for ( int i = 0; i newActivitiesList.size(); ++i )
+{
+if ( ! allActivities.contains( newActivitiesList.at(i) ) )
+{
+kDebug() invalid: newActivitiesList.at(i);
+newActivitiesList.removeAt( i-- );
+}
+}
+setOnActivities( newActivitiesList );
+}
+
} // namespace
#include client.moc
--- trunk/KDE/kdebase/workspace/kwin/client.h #1179042:1179043
@@ -691,6 +691,8 @@
friend bool performTransiencyCheck();
friend class SWrapper::Client;
+
+void checkActivities();
};
/**
--- trunk/KDE/kdebase/workspace/kwin/events.cpp #1179042:1179043
@@ -942,6 +942,8 @@
getMotifHints();
else if( e-atom == atoms-net_wm_sync_request_counter )
getSyncCounter();
+else if( e-atom == atoms-activities )
+checkActivities();
break;
}
}
--- trunk/KDE/kdebase/workspace/kwin/manage.cpp #1179042:1179043
@@ -159,6 +159,8 @@
init_minimize = rules()-checkMinimize
Re: KDE/kdebase/workspace/kwin
On September 24, 2010 14:03:23 Chani Armitage wrote: SVN commit 1179043 by chani: Use an X property for activity associations the new property name is _KDE_NET_WM_ACTIVITIES, of type XA_STRING, and it's a comma-separated list of activity UUIDs. so, who's interested in upgrading libtaskmanager to read this property? :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities and locking
On September 24, 2010 14:51:54 Marco Martin wrote: On Friday 24 September 2010, Chani wrote: what we're going to do about this in trunk: the code for the activity stopping will be moved into Corona under a name like exportLayout (to mirror importLayout). it won't actually know about activities, it'll just know that a certain bit of config needs exporting to a certain file. it'll temporarily unlock the corona so that it can do its work in peace, and restore the old setting when it's done (this is something that can only be done within corona if SystemImmutable is on). that incidentlly will allow me to do what i wanted to with activities on netbook and mobile, without actually using real activities :p oh? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
* Activities - i still have to understand if i really want activities on plasma netbook/mobile or if containments are enough for the job iirc at akademy we agreed it was better... although there was some talk about getting the session stuff stable first? hrm. should've written things down. maybe we can chat about this next week? /me should really be packing, not reading mail :) oops ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: multi-screen management
...btw, anyone feel like updating the wiki page (mentioned at the start of this thread) with the conclusions we came to? :) done. http://community.kde.org/Plasma/Multiscreen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.6 dev cycle meeting
times are all UTC. actually there's a timezone chooser above the poll, and for me it autodetected vancouver. :) so do double-check what timezone it thinks you're in before filling it out. :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: multi-screen management
On September 7, 2010 10:01:57 Sebastian Kügler wrote: On Tuesday, August 31, 2010 21:37:15 Chani wrote: On August 31, 2010 04:41:11 Sebastian Kügler wrote: On Wednesday, August 18, 2010 22:27:12 Aaron J. Seigo wrote: as for thumbnails .. it's likely posible to do so for currently running containments, but much harder to do for ones that aren't running. The containment will be running at some point, so we can just screenshoot it then. I think a preview of what it really looks like is a good way to distinguish activities. beer and cookies for whoever implements that :) QWidget::pixmap() (off the top of my head). :) it's a graphicswidget, not a qwidget :/ although I guess you could snag it from its view when you get the chance... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Why rotate widgets?
Good design implies that less-used features are made less pronounced. I for one find the whole widget toolbar too intrusive. I put my widgets side-by-side on the desktop, and during normal use the toolbar on one widget will overlap the one besides it, obscuring its contents. I would be happier if the toolbar would only show on demand by clicking a toggle button (a cashew?), not by hovering over the widget. hmm, sounds like you might enjoy the newspaper layout better... it's available in 4.5 but I can't remember how stable it is. Do people really move and rotate their widgets, with the same frequency that they interact with their contents? As far as I can see, none of the use cases presented in this thread would be hurt by a configuration only mode, while it does get in the way for some of us in its current form. What was the original reasoning in having the complete direct-manipulation interface for plasmoid applets always present? Is it for the kool effect? To make it discoverable? Or is there a benefit in having the toolbar always available that I'm missing? umm, the handles go away if you lock the widgets... :) there's your configuration only mode :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Need assistance on bug #224666
I need your assistance to provide me with the question that I have written in https://bugs.kde.org/show_bug.cgi?id=224666 Let me write it again. This bug was still present in version 4.4.5-1 in Debian Squeeze. hmmm. did you try clearing /var/tmp/ ? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: mentors needed
On August 19, 2010 09:17:27 Aaron J. Seigo wrote: On Thursday, August 19, 2010, Lydia Pintscher wrote: Heya folks :) I need mentors for a GSoC-like program in Canada asap so please get back to me within the next two days. What's needed: - a mentor who can come to Toronto from October 1-3. well, i'm only 3354 km away. ;) same country though, and convenient flights. beginning of oct is still open for me schedule-wise as well. there are lots of great projects available in Plasma for varying levels of experience, expertise, time allowance, interest, etc. so we should be able to send a few options along and we should be able to provide mentorship as well. yay! :) some of the students will be from UBC and SFU, btw... the SFU co-ordinator is probably still ted kirkpatrick. great teacher. :) as for me, I'll be gone by october - but I will be back for the january semester if you guys can get the ball rolling. :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
multi-screen management
so... we had planned to have a little tool for managing the containments of multiple screens, in 4.5 - but there wasn't time. multiscreen has improvements, but also regressions - well, *a* regression - you can't access the containment of a screen that's not plugged in. the same applies to the per-desktop view stuff (they have a lot in common). anyways, jpwhiting said he might be willing to implement such a tool, and yesterday I was inspired (compelled?) and found myself writing about how such a tool may look and act: http://community.kde.org/Plasma/Multiscreen feedback would be very welcome. :) and since I know many of us hate clicking links, here's the current text copypasted: Plasma/Multiscreen With the death of the ZUI, managing multiple screens (or per-desktop views) becomes... a little trickier. A UI for managing the containments (widget groups in user-speak?) is needed. Contents [hide] 1 Manager Tool 1.1 UI 1.2 Under the Hood 2 Inactive Screens [edit]Manager Tool [edit]UI I have a few ideas here, and would like feedback. The general concept I've got is a grid of containments, with screens left to right and (if PVD was ever enabled) desktops going top to bottom. If panels are to be managed here too, they could be along the edges of the cells. Only the current activity's containments would be used (no hypercubes plskthx). There would be a visible difference between the rectangle of active views and the inactive 'outside' ones. Containments could be dragged to other cells (causing a swap with the containment they're dropped on) and ones outside the active area could be deleted. Desktop containments would not be draggable to empty cells, because that could leave a view without a containment (panels, on the other hand, might have less restrictions). Usual case mockup http://chani.ca/images/screenmanager-bestcase.png Bad case mockup (it could be worse...) http://chani.ca/images/screenmanager-worstcase.png The UI ought to be something a user only needs occasionally, but it should still be easy to use. I considered doing just screens or just desktops, and trying to follow the geometry those are displayed in in other places (pager, krandr) but when you consider there will likely be leftover containments from old screenns and desktops that gets awkward. On the other hand, if there are both panels and PVD, that's also awkward: would users understand that even if panels only appeared and were draggable within the first row, that they still show up on all desktops? perhaps panels could have their own special row in that case..? Another tricky issue: how to represent the containments? If someone can get thumbnails of containments working properly I will give them lots of beer and hugs. :) Im the meantime... well, a grid of identical icons isn't very useful. there probably ought to be something thing-like for the dragging... I'm not sure how much trouble the user will have remembering which containment they left where. if fact, if they drag one icon to another identical icon, what is there to tell them the two containments were swapped at all? I think that, assuming there are no thumbnails, live previews will be important. The user will end up dragging an inactive containment to their current screen/desktop just to remind themselves what containment it was. If they have to hit apply every time that could get rather tedious. On the other hand, it might be good to keep in mind that the *normal* case is for a user to have PDV off, disconnect their one external monitor, and then want to go check on a widget it had - or swap its containment over to the remaining screen if they don't like which one their driver thinks belongs there. The (hopefully) less common, icky case is someone who has multiple screens and lots of desktops, then turned on PVD and wants to purge all the old containments (even though they ideally would be mere config data, not actually *running*). Oh, and as for where to go to open this UI: well, it has to run in-process, but it's not common enough to warrant a toolbox entry, so I had a crazy idea: what if whatever kcm is relevant to this stuff (plasma settings + wherever the PDV setting lives?) had a button that sent a dbus signal to plasma-desktop to show the UI? TODO: clean up the above rambling into a more structured document. :) [edit]Under the Hood The UI would have to talk to plasma-desktop's current Activity (you can get them via DesktopCorona), to ensure that the containment swaps happen smoothly. Also because one or both containments involved may not be running, once that stuff's implemented, so swapContainment might not be doable at all :) [edit]Inactive Screens When a screen is disconnected (or in PDV, a desktop removed) the associated containment and view (for each running activity) should be automatically stopped - and resumed again when the screen/desktop returns. We can migrate panels, but not
Re: multi-screen management
On August 18, 2010 03:15:13 Marco Martin wrote: On Wednesday 18 August 2010, Chani wrote: so... we had planned to have a little tool for managing the containments of multiple screens, in 4.5 - but there wasn't time. multiscreen has improvements, but also regressions - well, *a* regression - you can't access the containment of a screen that's not plugged in. the same applies to the per-desktop view stuff (they have a lot in common). anyways, jpwhiting said he might be willing to implement such a tool, and yesterday I was inspired (compelled?) and found myself writing about how such a tool may look and act: http://community.kde.org/Plasma/Multiscreen feedback would be very welcome. :) and since I know many of us hate clicking links, here's the current text copypasted: Plasma/Multiscreen With the death of the ZUI, managing multiple screens (or per-desktop views) becomes... a little trickier. A UI for managing the containments (widget groups in user-speak?) is needed. needed -when- the activity manager isn't enough, but still reachable from there i think it's not about the activity manager. it's needed when people have had multiple screens or PVD. I have a few ideas here, and would like feedback. The general concept I've got is a grid of containments, with screens left to right and (if PVD was ever enabled) desktops going top to bottom. If panels are to be managed here too, they could be along the edges of the cells. Only the current activity's containments would be used (no hypercubes plskthx). There would be a visible difference between the rectangle of active views and the inactive 'outside' ones. Containments could be dragged to other cells (causing a swap with the containment they're dropped on) and ones outside the active area could be deleted. Desktop containments would not be draggable to empty cells, because that could leave a view without a containment (panels, on the other hand, might have less restrictions). Usual case mockup http://chani.ca/images/screenmanager-bestcase.png Bad case mockup (it could be worse...) http://chani.ca/images/screenmanager-worstcase.png The UI ought to be something a user only needs occasionally, but it should still be easy to use. I considered doing just screens or just desktops, and trying to follow the geometry those are displayed in in other places (pager, krandr) but when you consider there will likely be leftover containments from old screenns and desktops that gets awkward. thinking a bit about about the ui i think it should be: * display a single activity at a time *it should try to follow that geometry if possible - for monitors should be a grid, line or whatever is configured of the active screens, the inactive ones could be in a line slightly separed with the active ones - each monitor box tries to represent directly a containment, if there are containments assigned to oter desktops, they will have a layout representing the pager, also here with a second line of ones that are assigned to a desktop grids within grids? erg.. I kinda doubt that can look good. maybe draw some mockups? and consider panels too... the total number *all things should be reordered by drag and drop naturally. :) On the other hand, if there are both panels and PVD, that's also awkward: would users understand that even if panels only appeared and were draggable within the first row, that they still show up on all desktops? perhaps panels could have their own special row in that case..? Another tricky issue: how to represent the containments? If someone can get thumbnails of containments working properly I will give them lots of beer and hugs. :) Im the meantime... well, a grid of identical icons isn't very useful. there probably ought to be something thing-like for the dragging... I'm not sure how much trouble the user will have remembering which containment they left where. if fact, if they drag one icon to another identical icon, what is there to tell them the two containments were swapped at all? I think that, assuming there are no thumbnails, live previews will be important. The user will end up dragging an inactive containment to their current screen/desktop just to remind themselves what containment it was. If they have to hit apply every time that could get rather tedious. uhm, so actual qgraphicsviews? this assumes all containments are running no... previews was the wrong word there. I meant instantly applying the settings, so you drag in one of the inactive containments and on your desktop you see it immediately. of course, that's different behaviour from 90% of kde config dialogs, so it's not ideal either... On the other hand, it might be good to keep in mind that the *normal* case is for a user to have PDV off, disconnect their one external monitor, and then want to go check on a widget
Re: multi-screen management
On August 18, 2010 10:05:22 Aaron J. Seigo wrote: On Tuesday, August 17, 2010, Chani wrote: so... we had planned to have a little tool for managing the containments of multiple screens, in 4.5 - but there wasn't time. multiscreen has improvements, but also regressions - well, *a* regression - you can't access the containment of a screen that's not plugged in. the same applies to the per-desktop view stuff (they have a lot in common). is there a list of use cases that must be serviced? your email has lots of how to do X in it, but it seems to skip the why we want to do X. somewhere in there I had something not entirely unlike use cases... ;) 1) user unplugs their external monitor and takes their laptop home. at home they remember there was a note on the other monitor that they need to read, so they open up the manager tool, swap the containments, read the note, then swap back. 2) user wants their laptop screen's containment to stay where it is, but something in the multiscreen stack keeps telling plasma to move it to the external monitor. user uses this tool to swap containments every time they connect or disconnect the screen [how realistic is this?] 3) user tried out the PDV feature, but didn't like it and turned it off. now their system is slow, and someone on irc tells them it's because all those other desktops are still running. they use the tool to delete all those extra containments that aren't being used. When a screen is disconnected (or in PDV, a desktop removed) the associated containment and view (for each running activity) should be automatically stopped - and resumed again when the screen/desktop returns. We can migrate panels, but not desktops, and it doesn't make sense to leave something running and inaccessible (having to manually stop it would also be Wrong). it does make sense to leave something running if one can switch to it, though. if the switcher UI allows the user to do that, then it's probably fine. except that I'm not sure how many users will realise they might have stuff running still and check this tool. they'll just think their system got slower because it's bloated or something :P me, I plug in an external monitor (actually a tv) a couple of times a week to watch movies. I don't want the containment for it running for the rest of the week, and I don't really want to manually delete or close it every time. and the multiscreen tool would then need a feature to manually close things instead of deleting them, too. * I don't like how I ended up with two authorities on where a containment belongs: there's both the lastScreen/lastDesktop settings in the containment, and the place that running containment has in plasma-desktop's Activity class. that ought to be rethought. they are two different kinds of issues, though, and are orthoganal to each ther. it may be possible to nicely merge the two, but they would still be two different sets of data and decisions. ? what two kinds of issues? the way I see it, it's a bit of awkward design that has led to bugs, and may well lead to more bugs if it's not cleaned up before this multiscreen stuff is implemented. * Might it be easier to leave the config in plasma-desktop-appletsrc, and have the startup loading skip containments assigned to nonexistant screens/desktops? possibly, yes.. * Once this is implemented, I believe panels should behave the same way, instead of migrating. It's more consistent that way. thoughts? i think it will annoy the users who previously sent in bug reports about the panel not showing up on their laptop screen after being migrated to another screen. true. it'll annoy *some* group either way, I think. panel migration addresses a real world issue people run into regularly. there's a bug in it that i will try and track down (i actually finally ended up with hardware capable of replicating it with.. ), but otherwise i don't think much needs to be done with panels. they are already movable between screens. yeah, it's just that we've now got two different ways of addressing the issue of a screen going away :) heck, I suppose a parallel solution to the desktop side of it would be to migrate its *widgets* to the other screen... but undoing that when the screen returned could be tricky :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: multi-screen management
On August 18, 2010 11:17:53 Jeremy Whiting wrote: On Wed, Aug 18, 2010 at 11:05 AM, Aaron J. Seigo ase...@kde.org wrote: On Tuesday, August 17, 2010, Chani wrote: so... we had planned to have a little tool for managing the containments of multiple screens, in 4.5 - but there wasn't time. multiscreen has improvements, but also regressions - well, *a* regression - you can't access the containment of a screen that's not plugged in. the same applies to the per-desktop view stuff (they have a lot in common). is there a list of use cases that must be serviced? your email has lots of how to do X in it, but it seems to skip the why we want to do X. The usecase I hit last week was that I usually use two screens, but pulled one screen off my desktop to use for a separate machine for longer-than-short-term. Now my main desktop has one screen, with the panel on it, but there's a separate containment that had some widgets I'd like to remove or move to this screen. I'm not sure if they are running or whatever, but in the add widgets dialog there are checkboxes on widgets that are not on this screen or my panel. unf, that reminds me: there's no easy way to move a widget from one desktop- containment to another in 4.5. you might be able to manage it with keyboard shortcuts or via a panel, though. another issue to be solved someday. When a screen is disconnected (or in PDV, a desktop removed) the associated containment and view (for each running activity) should be automatically stopped - and resumed again when the screen/desktop returns. We can migrate panels, but not desktops, and it doesn't make sense to leave something running and inaccessible (having to manually stop it would also be Wrong). it does make sense to leave something running if one can switch to it, though. if the switcher UI allows the user to do that, then it's probably fine. Umm, is there a glossary somewhere of plasma terms? I've no clue what PDV, or such mean. ahh, sorry. community.kde.org might have some? PDV (PVD?) is the per-virtual-desktop-views setting. aka different widgets per virtual desktop or something. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: multi-screen management
On August 18, 2010 13:24:43 Aaron J. Seigo wrote: On Wednesday, August 18, 2010, Chani wrote: On August 18, 2010 10:05:22 Aaron J. Seigo wrote: On Tuesday, August 17, 2010, Chani wrote: so... we had planned to have a little tool for managing the containments of multiple screens, in 4.5 - but there wasn't time. multiscreen has improvements, but also regressions - well, *a* regression - you can't access the containment of a screen that's not plugged in. the same applies to the per-desktop view stuff (they have a lot in common). is there a list of use cases that must be serviced? your email has lots of how to do X in it, but it seems to skip the why we want to do X. somewhere in there I had something not entirely unlike use cases... ;) 1) user unplugs their external monitor and takes their laptop home. at home they remember there was a note on the other monitor that they need to read, so they open up the manager tool, swap the containments, read the note, then swap back. 2) user wants their laptop screen's containment to stay where it is, but something in the multiscreen stack keeps telling plasma to move it to the external monitor. user uses this tool to swap containments every time they connect or disconnect the screen [how realistic is this?] unfortunately, rather realistic *sigh* ok .. so given that these are use cases ... how about this as an idea: in the Activity Manager panel, if there is more than one containment in the current activity, it is shown expanded with a snapshot of each containment. so, in a two screen system, the current activity would be represented by two screenshots next to each other instead of the one icon. click on one or the other would switch the current screen to be using that containment. for screens, and assuming you make snapshots work, that might be feasible... but, what if the user has PVD and 6 VDs? :/ (at least VDs can always be re- added after they're removed) and where would you put the delete button? how would you keep it clearly separate from the stop/delete this activity button? this doesn't touch the bring that containment from Activity 1 over to Activity 3 issue, but that seems like more of an edge case, one that is harder to solve nicely and which probably requires a whole big arrange stuff around tool like in your proposal. well, my proposal doesn't even address moving anything between activities. desktops and screens are two dimensions, I didn't want to add a third. 3) user tried out the PDV feature, but didn't like it and turned it off. now their system is slow, and someone on irc tells them it's because all those other desktops are still running. they use the tool to delete all those extra containments that aren't being used. should turning off PDV just automatically remove all those other containments, or offer the option to do so when it is turned off? Per-desktop views have been turned off and there are now several unused widget layouts. Would you like them to be removed automatically for you? This can result in a significant performance improvements. Remove Unused Layouts Keep The Unused Layouts hmm... yes, assuming the annoying-popup factor is minimized this is a good idea :) hopefully users will be smart enough to realise that the 'unused' ones are all except the one from deskop #1. When a screen is disconnected (or in PDV, a desktop removed) the associated containment and view (for each running activity) should be automatically stopped - and resumed again when the screen/desktop returns. We can migrate panels, but not desktops, and it doesn't make sense to leave something running and inaccessible (having to manually stop it would also be Wrong). it does make sense to leave something running if one can switch to it, though. if the switcher UI allows the user to do that, then it's probably fine. except that I'm not sure how many users will realise they might have stuff running still and check this tool. they'll just think their system got slower because it's bloated or something :P me, I plug in an external monitor (actually a tv) a couple of times a week to watch movies. I don't want the containment for it running for the rest of the week, and I don't really want to manually delete or close it every time. and the multiscreen tool would then need a feature to manually close things instead of deleting them, too. how much weight (start up time, memory usage) does this use case incur right now? wallpapers on loaded on first-paint only, if there are no widgets then none are loaded or set up ... it might be very negligable and not work worrying about. I ought to check again. I know that in january, loading 8 activities took something like.. 20-30 seconds..? for every plasma-desktop restart. it was a very noticeable loading time. * I don't like how I ended up with two
Re: multi-screen management
On August 18, 2010 20:05:00 Aaron J. Seigo wrote: On Wednesday, August 18, 2010, Chani wrote: On August 18, 2010 13:24:43 Aaron J. Seigo wrote: On Wednesday, August 18, 2010, Chani wrote: On August 18, 2010 10:05:22 Aaron J. Seigo wrote: On Tuesday, August 17, 2010, Chani wrote: in the Activity Manager panel, if there is more than one containment in the current activity, it is shown expanded with a snapshot of each containment. so, in a two screen system, the current activity would be represented by two screenshots next to each other instead of the one icon. click on one or the other would switch the current screen to be using that containment. for screens, and assuming you make snapshots work, for running containments, it turns out that its not a big deal. :) that might be feasible... but, what if the user has PVD and 6 VDs? :/ (at least VDs can always be re- added after they're removed) have i mentioned recently how much i regret PVD? :) hehe :) we *might* have had a window to kill it in 4.5 when activities came in... but... oh well. this feature is more important for screens than VDs, though: you can be physically unable to get a screen back, but you can always re-add a VD. so maaaybe we could ignore VDs there and implement the offer to purge them you mentioned below? i don't have a good answer for this one right now; maybe we just show the screens currently visible, so when you switch desktop the snapshots show that desktop's contents? yes, if we ignore VDs we should still remember to update the snapshots. and where would you put the delete button? how would you keep it clearly separate from the stop/delete this activity button? don't need to; it would only be for the current activity and that has no buttons on it :) actually, it does have a button atm. and hopefully it'll get some sort of edit button in 4.6 so that we can drag the activity-name setting out of the containment config (somuchtodo!) and, er, hmm. right, it makes sense to do it for only the current one. so the current activity would be rendered completely differently from the others? iinteresting. I wonder how the activity manager will look then... /me still wishes they were sorted by most-recent instead of by creation-order. should turning off PDV just automatically remove all those other containments, or offer the option to do so when it is turned off? Per-desktop views have been turned off and there are now several unused widget layouts. Would you like them to be removed automatically for you? This can result in a significant performance improvements. Remove Unused Layouts Keep The Unused Layouts hmm... yes, assuming the annoying-popup factor is minimized this is a good idea :) it should only happen when the setting is turned off; which should be a rare occurance. hopefully users will be smart enough to realise that the 'unused' ones are all except the one from deskop #1. we can explain it in the text, perhaps even include a little helpful picture. :) me, I plug in an external monitor (actually a tv) a couple of times a week to watch movies. I don't want the containment for it running for the rest of the week, and I don't really want to manually delete or close it every time. and the multiscreen tool would then need a feature to manually close things instead of deleting them, too. how much weight (start up time, memory usage) does this use case incur right now? wallpapers on loaded on first-paint only, if there are no widgets then none are loaded or set up ... it might be very negligable and not work worrying about. I ought to check again. I know that in january, loading 8 activities took something like.. 20-30 seconds..? for every plasma-desktop restart. it was a very noticeable loading time. in the use case you noted, it's one extra containment, and it shouldn't even be loading its wallpaper. i also assume there aren't any widgets on it since it's a temporary thing in the described work flow. one extra containment per activity that has been used while that screen was plugged in. in *my* workflow it has no widgets... hm. yeah, I guess most of them will have no widgets. well, I'll try and find time to test it while I still have access to the TV :) er, how do I measure memory usage anyways? all I remember is Don't Use Top. ;) * I don't like how I ended up with two authorities on where a containment belongs: there's both the lastScreen/lastDesktop settings in the containment, and the place that running containment has in plasma-desktop's Activity class. that ought to be rethought. they are two different kinds of issues, though, and are orthoganal to each ther. it may be possible to nicely merge the two, but they would still be two different sets of data and decisions. ? what two kinds of issues
Re: multi-screen management
right; but that doesn't really have anything to do with the activity, per se. it does, that's the problem. :) ...and in any case, all I wanted to do was give a warning that there's bad code in there that likes to throw up nasty surprises, so this whole conversation is a bit silly :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Added feature in showdesktop widget to minimize all opened window when any file/folder is dragged from the opened window and hover over showdesktop widget icon.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5060/#review7124 --- neat :) I'd love to see the same logic applied to the show-dashboard plasmoid too :) - Chani On 2010-08-17 19:01:14, Sinny Kumari wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5060/ --- (Updated 2010-08-17 19:01:14) Review request for Plasma. Summary --- Earlier, when I was trying to drag any file/folder on desktop from an opened window , i was unable to do it because there was no option to minimize all opened window when an item is dragged. So, I added feature to minimize all opened window in showdesktop widget when any item is dragged from opened window. It's possible by hovering the mouse in dragged condition over showdesktop widget icon in panel. Diffs - trunk/KDE/kdeplasma-addons/applets/showdesktop/showdesktop.h 1162122 trunk/KDE/kdeplasma-addons/applets/showdesktop/showdesktop.cpp 1162122 Diff: http://reviewboard.kde.org/r/5060/diff Testing --- It works fine with trunk! Thanks, Sinny ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: preview in wallpaper dialog
On August 11, 2010 15:56:59 Aaron J. Seigo wrote: On Wednesday, August 11, 2010, Chani wrote: On August 11, 2010 14:42:04 Marco Martin wrote: On Wednesday 11 August 2010, Vitor Boschi wrote: We may put a preview button that displays the wallpaper fullscreen, while hiding the config dialog for a while. that's called Apply :p seriousy, i don't see much value added in that. random comment: before I found out about the wallpaper's weird async drawing, I toyed with the idea of a plasmoid that would pop up a fullscreen window showing only the wallpaper. :) sort of like plasmawallpaperviewer? sort of :) but not exactly, because that's a developer tool - I wanted more of a convenient admire my current wallpaper button, because with all these widgets and windows and compositing I hardly ever see it any more ;) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JJ: align these icons
On July 19, 2010 14:35:21 Aaron J. Seigo wrote: On July 19, 2010, Chani wrote: someone adjusted the list thingy that the add-widgets and activity-manager UIs use so that it's prettier and shows the names on top. I like it :) but they missed something: the little icons that the activity manager draws on top (and, most likely, the corresponding click area for the stop button) haven't been shifted down to match the icon. http://chani.ca/sshots/icon-over-text.png yes, needs to be fixed. my fault. i'll take a gander when i have some time... *coughs* if anyone else has time, please don't hesitate to fix this. :) the release is coming soon and it'd really suck to have such an obvious glitch in it. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities IRC meeting
aww crap, I don't have any jabber client installed. and my internet is being weird this morning. and I don't know how to get to a conference. don't move meetings at the last minute, darnit :( On Tue, Jul 20, 2010 at 8:39 AM, Ivan Čukić ivan.cu...@kde.org wrote: fine with me, if I succeed in connecting to it :) 2010/7/20 Sebastian Trüg tr...@kde.org: Any chance we can have this meeting in a jabber conference at nepo...@conference.xabber.de? My internet connection is acting up again. Cheers, Sebastian On 07/16/2010 02:46 PM, Ivan Čukić wrote: Sebastian and me are planning to hold a meeting about activities on Tuesday, 5PM UTC. It is going to be about the inner-workings rather than the UI. So, anyone willing to join is more than welcome. --- Testing out the event inserting: Activities IRC meeting /When/ Tue, 20 July, 7pm – 8pm GMT+02:00 /Who/ • Ivan Čukić • nepo...@kde.org mailto:nepo...@kde.org • plasma-devel@kde.org mailto:plasma-devel@kde.org Cheerio -- 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 -- 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 -- This message brought to you by evyl bananas and the number 3. www.chani3.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
(re-crossposting - I'm subscribed to nepomuk now, or I would've missed this :) On July 20, 2010 08:21:59 Sebastian Trüg wrote: Don't worry. Everything is in playground. er... the mandriva smart desktop stuff is in playground? where? (also.. I dunno if playground truly counts as upstream. playground is not released.) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: need help in containments development
I'd need a method or a signal *always called* and called *always after* restore, but i couldn't find any. Do you have any hint? Should it be added to Containment? I thought init came after restore... that's why you don't set default sizes in init :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Nested Panels
On July 18, 2010 23:35:39 Aaron Peterson wrote: Please check my understanding: Does panel == containment? http://techbase.kde.org/Projects/Plasma/Vocabulary Does not list panel, but it does list containment. yes. specifically, there are PanelContainment and CustomPanelContainment in the ContainmentType enum, and the Panel class (and any 3rd party panels) inherits Containment (which inherits Applet). So, a panel is not a nested, (forgive me)desktop--Corona, it is used by corona to manage widgets... yes. and we can have nested containers... neted layouts, nested graphicswidgets, but not nested Containments. if you try to put a Containment inside another Containment, it acts as a simple Applet. #2, I am also confused at how many applets show up as icons when in a panel, and show up as... a window when on the desktop... How would I embed a folder view into the panel. yes, applets respond to the FormFactor constraint, showing themselves in an appropriate manner - the easiest way to get that behaviour is to subclass PopupApplet, which automatically switches to that icon-popup mode. I don't know whether folderview has any code to handle that - never tried it myself. :) / Will any of the new containers new containers? do this? Actually, I know that the pager plasmoid is active in the panel, It would be great to toggle if I want it to be a button to open the app, or actually have the app be in the panel, so when the panel opens all of my apps are there. when the panel opens? have the app be in the panel? I don't understand what you're saying... hrrm... do you mean you want to be able to choose to have an applet act as if it were in a desktop formfactor while it's in the panel? that probably wouldn't work very well, given the size of most panels - the applets turn into icons because there's often no *room* for anything else. (although it may make sense for them to actually check how much space they've got, and whether it's enough). (I think this is related, because very little behaves as expected when put in a panel, but behaves as expected when put on desktop...I've been thinking that maybe things just can't be put in a panel) not all applets were designed with the panel's formfactor in mind, yes. They all could be adapted to work in the panel, it's just that nobody's done it. :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Nested Panels
On July 19, 2010 03:13:35 Aaron Peterson wrote: some applets give you a data that can make sense in a small horizontal (or vertical) strip, some other really can't, so an iconic representation is all can be done, and even all that makes sense (think bout the start menu, you really want it as an icon with popup when is in a small, always visible panel and nothing else) Oh boy, I didn't think panel size would have anything to do with it, I just made my panel a wee bit bigger and my device notifier turned into an actual device notifier! Thank you! Feel kinda bad that I had to be told, Now, I need to figure out a size to make the K menu fit into a panel. and I guess that tweaking device manager to not waste so much space is manageable. Should I file a bug for that? Also the information / preview icon in dolphin takes a large percentage of my screen, can they be combined to be a general bug? separate bugs in separate reports, please :) dolphin's not even part of plasma. hmm, I see what you mean about the device notifier, someone made its default size its minimum size. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
JJ: align these icons
someone adjusted the list thingy that the add-widgets and activity-manager UIs use so that it's prettier and shows the names on top. I like it :) but they missed something: the little icons that the activity manager draws on top (and, most likely, the corresponding click area for the stop button) haven't been shifted down to match the icon. http://chani.ca/sshots/icon-over-text.png anyone got time to fix that? :) everything just needs to be shifted down by however much the icon in the abstract class was shifted down. Although it does seem a bit funny to have the close button in what isn't quite the top-right corner any more... so... if anyone wants to prettify that too I'll be very happy :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On July 19, 2010 01:55:22 Ivan Čukić wrote: This is just an idea that came to me looking at some mobile GUIs (or was it websites?), but I think that could really work in order to have the common user find out our best features. What do you think? problems with those things is that users tend to find this kind of things abboying pretty uickly :( It would be good if it was a KDE-wide framework, and is done via a 'take the tour' button or something. Otherwise, it could be rather annoying. Cheerio, Ivan speaking of which... *coughs* we still don't have a Welcome Plasmoid, do we? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On July 19, 2010 11:19:31 Ivan Čukić wrote: speaking of which... *coughs* we still don't have a Welcome Plasmoid, do we? Yep :) Well, this would be nice to have in the welcome plasmoid, but it would be a *huge* thing to implement. gotta start somewhere... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
hey, I was wondering... have you guys seen this? http://doc4.mandriva.org/bin/view/labs/New+features+toward+the+task+oriented+desktop and http://doc4.mandriva.org/bin/view/labs/Mandriva_Smart_Desktop_2010-0 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Nested Panels
On July 17, 2010 17:57:03 Aaron Peterson wrote: Hello, I have a general feeling that we cannot nest panels, I am hoping that this is not true. it is true. What would it take to make a widget that is a panel? technically, all panels are widgets already - but I'm guessing that's not what you mean. go look at trunk/playground/base/plasma/containments/groupingdesktop/ for a different approach. basically, instead of trying to make containments recursive (which makes other parts of plasma much trickier), you can make a containment with a better layout strategy, using graphicswidgets (and you can put graphicswidgets in graphicswidgets as much as you like). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities IRC meeting
On July 16, 2010 05:46:22 Ivan Čukić wrote: Sebastian and me are planning to hold a meeting about activities on Tuesday, 5PM UTC. It is going to be about the inner-workings rather than the UI. So, anyone willing to join is more than welcome. cool :) 10am tuesday... yes, that works for me :) (and I doublechecked this time ;P ) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities IRC meeting
Activities IRC meeting *When* Tue, 20 July, 7pm – 8pm GMT+02:00 *Who* erm... there's no where mentioned. :) #plasma? #nepomuk? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On July 15, 2010 07:35:10 Ryan Rix wrote: On Wed 14 July 2010 10:32:19 pm Chani wrote: On July 14, 2010 10:26:49 Aaron J. Seigo wrote: On July 14, 2010, Marco Martin wrote: i think windows outside of the current activity should be hidden from the taskbar, at least by default. yes, that makes sense. and this must be done in 4.5, only if it can be done in a way that is sensible. it won't be able to be an optional thing because we can't introduce new strings in the 4.5 branch, so no configuration UI is possible. so if it is added, it needs to absolutely work because it will not only be the default ... it won't be able to be turned off. honestly, I hadn't planned to make it an option ever. :) that said, i think it may make work well since it's an active user selection to associate the window with the activity, and the window won't be shown when a different activity is shown. what will likely end up becoming a requirement, however, is a way to show windows in other activities so that a person may find that krita window i had open ... without switching to every activity manually. that sounds a bit more like something for 4.6, though. true; I tend to lose windows even just with vdesktops :) logging out properly has become far more tedious now that I need to remember to check all desktops *and* all activities for unsaved work and session-unfriendly apps. There's a runner for that, no? :p Of course I'd be interested in knowing who knows to use krunner, among 'regular' users er... a runner for what? :) a windowlist runner isn't useful because I don't remember the names of the windows. an activity-switcher runner isn't any more useful than tabbing through them. the problem here is that I *might* have some window somewhere that I've completely forgotten about having unsaved content in, like one of my konsoles or a konqueror tab with a half-writen comment, or a kmail window (rare but has happened). 'course, it'd be a slightly easier process if I could close the activities individually (including windows, I mean). then I would at least know which ones were clear. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
On July 15, 2010 17:22:24 Markus Slopianka wrote: On Thursday 15 July 2010 17:57:11 Aaron J. Seigo wrote: aaron's advocatei really dislike text-on-graphics from a design perspective. text is fine detail, and a progress bar is visually fairly complex. maybe it's time to think outside the box. e.g. maybe colourize the device icon showing what % of it is filled and provide the usage text where the current progress bar is. the pie chart solution as seen in Lancelot would likely break up the layout in visually unpleasing ways here, so i wouldn't consider that too much./aaron's advocate I guess you don't have a portable MP3 player. If you had one, you wouldn't make such ridiculous proposals. could you be a little nicer please? :P I'm tired of people snapping at each other. btw, I've only had a quick glance at what you guys are doing, but here's some food for thought: the user is most likely to care how much free space there is when there isn't much of it. (although with 1TB usb drives it becomes a bit hard to quantify not much, hmm...) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
I was doing some thinking on the bus... and I like this scoring idea. some more random thoughts: there's a temporal aspect to all this, isn't there? I mean, there are resources that were related to my activity in the past - many of which may be useful for it again in the future. and then there's resources that are related to it in the present, things I'm *actually* using right this moment (or the last moment that I was in that activity). resource associations (and I say resources not files, because #plasma is not a file) can be from any period in time (ooh ooh! timeline plasmoid for noting things that'll be associated with it in the future!). kwin, on the other hand, only really cares about the present. :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Equivalent for closeEvent?
On July 13, 2010 22:46:52 Nate C wrote: Is there any equivelent to QGraphicsWidget::closeEvent for a plasma applet. I need to shutdown a QThread on the close event, but can not figure anything out. Plasma::Applet subclasses QGraphicsWidget, so should I not get it for free? (I am using the python bindings.) you mean when the applet is removed? well, it's destroyed then, so I assume making it the parent of the qthread would ensure the qthread is also destroyed... ohhh, but Note that deleting a QThread object will not stop the execution of the thread it represents - so... in C++ I would have the applet's destructor stop the qthread (except, I can't remember if the qthread's destructor will have been called before or after that)... alternatively, there's the destroyed() signal. not sure which'd be easier in python. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
the problem is: i think windows outside of the current activity should be hidden from the taskbar, at least by default. and this must be done in 4.5, otherwise will cause another ser revolt. I agree that they should be hidden. I'm not against doing it in 4.5, if someone can do it without introducing bugs :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On July 14, 2010 05:32:18 Ivan Čukić wrote: Sebastian: once more just so this is not forgotten: there is no need for ranking - at least not on the data level - when linking the activity to the event rather than to the file. Agreed. The only problem I see is that we'll need much more complex queries when sorting the results by usage. Marco: by the way, since this information is saved, is there a way given a window id to know if it's associated on a given activity (in particulr the current one) No, currently the kwin activities part is totally separate from this system. Chani could probably tell you more. the kwin thing isn't saved at all right now. it's just stored in kwin, and lost when it restarts. I had hoped to make it persistent before 4.5 came out... but... on the other hand, I want more time to consider *how* it should be done, properly, and not rush in something that might turn out to be the wrong approach and need supporting forever. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On July 14, 2010 03:16:15 Sebastian Trüg wrote: On 07/14/2010 11:53 AM, Ivan Čukić wrote: First of all, I hope you are on plasma-devel since a lot of people didn't take me seriously concerning the cross-posting... did not find the thread in stupid thunderbird (if only kmail would work again here) So applications need to notify it about opening a doc manually? I am asking because I started implementing the exact same thing and we should Yes, the apps report the name, window id and the uri of the resource opened (be it a document, folder or some internal uri) really not duplicate code. This is in the ActivityManager kded module. I will have a look. The idea on my end is to create nuao:DesktopEvent instances which link to the opened file and the application opening it. For the latter the ontology is not stable yet. This is something we should fix as soon as possible so that we can encode applications properly. I wasn't going for anything this pedantic (was trying to limit the data and not remember every event) but it is fine with me to go that extra mile. It is worth it since then we have a lot more information to do cool things with. This is how I think it should be done: rather than linking the file directly to the activity you should link the desktop event to the activity. That way the information is exact and can later be used to suggest the link between file and activity to the user. The problem I see here is /suggesting/. The user usually opens a lot of documents, and I wouldn't really like to have to ask him/her do you want to add this to the activity for every one. That is, if you have an idea about the UI that would make this job non-irritating, I'm more than happy to hear it. From my POV, I'd rather have a system that has 90% precision which doesn't ask the user anything than to have it 100% and annoys the user constantly. (something like the best package manager - Slackware's - aka the user :) ) The suggestion thing was just an idea. You can also use the links to show related documents for the activity. However, as the documents would not be linked directly but via the event the link would automatically be marked as being added automatically and thus, less important than a manually added one. When I say suggestion I do not necessarily mean to suggest the link between file and activity but any kind of suggestion. This includes suggesting the file when showing related stuff for an activity. what's all this event stuff? are you doing.. something like zeitgeist or something? this is still something the application will have to support, I assume, so we probably want just one simple way for it to report the docuements it has open. in kwin, what I need is which activities are associated with this wid?, so that I can filter out windows that aren't on the current activity. there can be no levels here, no suggestion; either a window is shown or it is not. I mean, I have absolutely nothing against you guys using levels yourselves, it's just that kwin needs a simple yes/no when it asks. :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On July 14, 2010 10:26:49 Aaron J. Seigo wrote: On July 14, 2010, Marco Martin wrote: i think windows outside of the current activity should be hidden from the taskbar, at least by default. yes, that makes sense. and this must be done in 4.5, only if it can be done in a way that is sensible. it won't be able to be an optional thing because we can't introduce new strings in the 4.5 branch, so no configuration UI is possible. so if it is added, it needs to absolutely work because it will not only be the default ... it won't be able to be turned off. honestly, I hadn't planned to make it an option ever. :) that said, i think it may make work well since it's an active user selection to associate the window with the activity, and the window won't be shown when a different activity is shown. what will likely end up becoming a requirement, however, is a way to show windows in other activities so that a person may find that krita window i had open ... without switching to every activity manually. that sounds a bit more like something for 4.6, though. true; I tend to lose windows even just with vdesktops :) logging out properly has become far more tedious now that I need to remember to check all desktops *and* all activities for unsaved work and session-unfriendly apps. otherwise will cause another ser revolt. a user revolt because the windows are shown in the taskbar? seriously? will some people complain? sure. will some throw tomatos at us because of it? sure, but those people will do that no matter what we do: they are just looking for an excuse. (and for that reason i have ~zero interest in and respect for them.) let's make decisions that make sense on their own merit, not because the peasants are revolting!. +1 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
what's all this event stuff? are you doing.. something like zeitgeist or something? indeed. Only integrated with Nepomuk and the semantic desktop. Allows for some cool things. oh? :) point me to a blog post where I can read more! :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On 07/14/2010 07:34 PM, Aaron J. Seigo wrote: On July 14, 2010, Sebastian Trüg wrote: The idea on my end is to create nuao:DesktopEvent instances which link to the opened file and the application opening it. For the latter the that sounds very sensible, and would get rid of the false positives due to automatically associating files issue. files the user tags explicitly would be easily discernable from those that have a DesktopEvent. assuming that DesktopEvent allows for things such as counting the number of times that same event happens, it should even be possible to decrease the importance of files accessed just once or a long tme ago. +1 from me to our ontology overlords. [un-top-posting] Just for completeness: I already have a scoring algorithm that takes the desktop events and a bunch of other criteria into account to score all files and thus, guess which files are most important to the user. neat. :) I was doing some thinking on the bus... and I like this scoring idea. think of it this way: I have a bunch of plasma source folders (kdelibs/plasma, workspace/plasma, ...) that are loosely associated with plasma and kde. I have kwin source folders (workspace/kwin, ..) that are loosely associated with kwin and kde. plasma and kwin are loosely associated with kde. Now, when I open a kwin file in kwin, it's a safe bet that it applies only to kwin, and the window opening it should be associated with that activity and not bleed into others. When I open a plasma file in kwin... well, it *could* be that I forgot what activity I was in and got sidetracked, but since there's that loose association from kwin to kde to the source, then it seems more likely that I needed to read that file to help with whatever kwin thing I'm doing. So, the best assumption is to put it on that activity (and not on the plasma activity). On the other hand, if someone sends me a link to some youtube vid, that has no association with anything, so that window ought not to be put on the activity... although you could argue that it could be given a weak association, so that if it was opened from that activity a second time it'd get put there. :) and of course there's all sorts of opportunity for experimenting there :) and the more apps are activity-aware, the less often things will accidentally bleed over to the wrong activities, because the stuff (irc channels, mail folders) that's not in that activity won't be shown in the first place. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: IRC meeting: point of what was done at akademy
On July 14, 2010 21:15:23 Ryan Rix wrote: On Wed 14 July 2010 8:41:57 am Marco Martin wrote: just a reminder for everybody meeting at 9:00 am UTC tomorrow 15th So.. I'm a ... how can I put this nicely? A dork. I'm a dork. Right before sending my hey, yeah 9UTC WORKSFORME I sent a mail to another list who also had a meeting at 9UTC telling them that it was madness for me to stay up to 2am for a meeting... well, yeah, ehm :) It's 9pm, I'm still Finlag'd from waking up with the sun today (far worse than being jetlag'd), and even with a heavy serving of the coffee I put on downstairs, I don't see myself being sane for this meeting. I'll, like, catch logs, and send mails, and harass people afterwards. :) Cheers, Marco Martin Best best, Ryan I don't date -d before replying Rix yeah... metoo :/ I may or may not be awake then. if I find myself losing hte battle I'll try and send email with my thoughts. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
On July 13, 2010 06:13:15 Ivan Čukić wrote: a.s. This is a cross-post hmm, so it is. I'm only on the plasma list, and I see we've already uncrossposted the thread there :) 1. The ActivityManager (KDED module) now accepts application name/id when the application notifies it that it has opened a document (or any other type of resource that has an url) If the name is not specified, KWindowInfo is used to try and get it. The reason for this is to make it possible to keep track of recently opened resources (and all the stats/rating stuff Lukas is working on) on a per-application basis. KActivityConsumer uses QCoreApplication::applicationName() for this, so it is done 'behind a curtain'. just curious, why's he doing... whatever he's doing... on a per-application basis? does it matter whether I opened a document in kate, kwrite or okular? 2. Does anyone have objections in automatically linking a resource (that the application reports is opened) with the current activity? From my point of view, it is something that should be done. aseigo had objections at the last tokamak. me, I'm still on the fence. we should talk about this again, I guess. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
On July 13, 2010 12:57:35 Aaron J. Seigo wrote: On July 13, 2010, Ivan Čukić wrote: a.s. This is a cross-post Hi, A few notifications and questions. 1. The ActivityManager (KDED module) now accepts application name/id when the application notifies it that it has opened a document (or any other type of resource that has an url) If the name is not specified, KWindowInfo is used to try and get it. The reason for this is to make it possible to keep track of recently opened resources (and all the stats/rating stuff Lukas is working on) on a per-application basis. sounds good. 2. Does anyone have objections in automatically linking a resource (that the application reports is opened) with the current activity? this will lead to lots of false positives. a file i open from an email that gets sent to me stands a high likeliehood of having nothing to do with the activity i'm in. other examples abound. indeed (although that also suggests you've been distracted from whatever activity you were doing ;) if automatic linking is implemented, then i think we'll end up needing a simple ranking system with documents that were automatically (passively?) linked by the system just due to being open with a low ranking, information that is accessed as a result of another item associated with an activity (e.g. if i have an app or window associated with an activity, then things opened with that app / window stand a high chance of being relevant) having a higher ranking and items actively marked as having the highest. what would the ranking system be used for? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Monday, July 12, 2010 03:04:42 am Markus Slopianka wrote: On Monday 12 July 2010 11:55:50 Marco Martin wrote: unfortunately, i see that having something already done is often enough to make people not wanting to use those Maybe it should be easily discoverable what Activities actually are. Maybe I'm uninformed, but I see them as virtual desktops with individual Plasmoid setups. nope. an Activity is what you're doing at the moment: the tools and documents that you need for that work. plasmoids, windows, etc... the activity is meant to show you what you're working on and filter out things that could be a distraction. you can sorta do this with virtual desktops, but they're not as powerful as activities will be, and many people use 1 desktop for the same activity. if you want details, go read my blog posts on activities :) http://chani.wordpress.com/?s=activities Plasma in SC 4.4 had a quirky GUI for selecting activities, but at least showed thumbnails of them. In 4.5 thumbnails were replaced with random patterns and I still don't see the benefit of pattern over thumbnails. I'd love it if someone could come up with a workable way to do thumbnails in the activity manager - I'm sure I said so in the BR. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Monday, July 12, 2010 04:09:44 am Marco Martin wrote: On Monday 12 July 2010, Alessandro Diaferia wrote: Il 12/07/2010 12:54, Marco Martin ha scritto: On Monday 12 July 2010, Markus Slopianka wrote: On Monday 12 July 2010 11:47:51 Marco Martin wrote: or do you have a better idea to -magically- find an image that represent that activity without user intervention? Why would Activities be created without user intervention? not creation of activities without user intervention, but assigning a meaningful image without the user being forced to chose something Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Well, I don't completely see the point of avoiding any type of configuration to the user. IMO, when creating a new activity, the user might be prompted to choose among a set of default activities. Those activities might already have a name and a default icon together with some default plasmoids already loaded. Then the user might eventually choose to create his custom activity and in that case he would choose a name and an icon in place of a default, generic one. that could be an idea. the corresponding containment (or the first if there are more that one containment per activity) could be loaded from a javascript template with default plasmoids that have something to do with it +1, javascript template support is already halfway there, and the user can already choose containment types (desktop, folderview, etc). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Monday, July 12, 2010 04:48:39 am Ivan Čukić wrote: -in the activity configuration, there would be something that looks like a combobox to chose icons, that shows just the set of 20 good ones or an other... option Yeah, we'll need to discuss this one a bit more - whether it is good (usability-wise) to make a separate UI for icon choosing. Maybe we could add another category to the icon chooser... separate UI? wuh? the combobox would be in the activity config UI (which is currently wedged into backgrounddialog, but will need to go somewhere more sensible in 4.6). My only concern remains about auto-generated icons. I really don't see the point of them, but, again, i might be completely wrong. Having just It is a visual distinction - it is a bit subliminal, but after a while, your mind will connect a pattern to a specific activity and will find it easier. I agree that setting a generic ugly icon would /force/ users to choose custom ones, but I'm not sure that would be such a good idea ;) I'm starting to wonder if maybe it's not so bad to leave it to the user. After all, we don't try to auto-name the activity for them, new activities currently start at unnamed... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On July 12, 2010 16:27:40 Markus Slopianka wrote: On Monday 12 July 2010 23:40:42 Chani wrote: if you want details, go read my blog posts on activities :) http://chani.wordpress.com/?s=activities Yeah, I could do that, but while I'm not afraid of reading blogs, typical users won't do that. It'd be really great if by SC 4.6 it was easily discoverable for common users (and advanced users alike) what activities are and how to use them. :-) how would you suggest that be done? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Security updates in kdeplasma-addons for 4.5
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4602/#review6482 --- Ship it! - Chani On 2010-07-11 21:53:30, Ryan Rix wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4602/ --- (Updated 2010-07-11 21:53:30) Review request for Plasma. Summary --- A whole bunch of security updates for the 4.5 timeframe, they need to go out before 4.5 final is tagged, for applets which can or cannot reside on the plasma-overlay screensaver. I feel like a dork for waiting until rc2 to remember this patch, and I feel like more of a dork for sending it as an offlist mail first, but here is the reviewboard since I suffer from hate-commiting-to-code-i-didn't-write-itis :) - add proper attributes to bookmarks' desktop file - add proper attributes to opendesktop's desktop file - add proper attributes to kdeobservatory's dekstop file - add proper attributes to kimpanel's desktop file - add proper attributes to pastebin's desktop file - add proper attributes to plasmaboard's desktop file - add proper attributes to qalculate's desktop file - add proper attributes to socialnews's desktop file - add proper attributes to spellcheck's desktop file - make systemloadviewer's launchapp optional (Made a KRunner DBUS call to show system activity window) - make weatherstation's launchbrowser optional. Diffs - trunk/KDE/kdeplasma-addons/applets/bookmarks/plasma-applet-bookmarks.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/community/plasma-applet-opendesktop.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/kdeobservatory/plasma-applet-kdeobservatory.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/kimpanel/src/plasma-applet-kimpanel.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/pastebin/plasma-applet-pastebin.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/plasmaboard/plasma_applet_plasmaboard.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/qalculate/plasma-applet-qalculate.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/social-news/activitywidget.cpp 1142195 trunk/KDE/kdeplasma-addons/applets/social-news/plasma-applet-opendesktop-activities.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/spellcheck/plasma-applet-spellcheck.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/systemloadviewer/plasma-applet-systemloadviewer.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/systemloadviewer/systemloadviewer.cpp 1142195 trunk/KDE/kdeplasma-addons/applets/weatherstation/plasma-applet-weatherstation.desktop 1142195 trunk/KDE/kdeplasma-addons/applets/weatherstation/weatherstation.cpp 1142195 Diff: http://reviewboard.kde.org/r/4602/diff Testing --- it's been sitting on my system from two weeks not eating $cute_creatures Thanks, Ryan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
On Sunday, July 11, 2010 03:18:03 pm Aurélien Gâteau wrote: Hi, I have been playing a bit with the Add Widget UI on the plane back from Akademy and replaced the scroll buttons with a scrollbar. Attached patch is a first step at it, largely unfinished as I would like to know if you are interested in getting this integrated before I finish it. Screenshots: - Horizontal: http://imagebin.ca/view/NkxkAG.html - Vertical: http://imagebin.ca/view/XnBxX8vt.html What do you think? Aurélien +1 from me :) just being able to see where in the list I am makes me happier. how does it look if there aren't enough to scroll? P.S. Reviewboard Is Your Friend ;) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Sunday, July 11, 2010 03:20:39 pm Ivan Čukić wrote: Hi all, At aKademy, Nuno proposed a bit different design for identicons used for plasma activities. 1. The identicons should be showed inside a bubble with background and an overlay. they look pretty :) now, what if $plasmoid wants to use the icon (eg, activity bar)? what if $application wants to use the icon (eg. when associating something with an activity)? it'd be nice if I could see the icons when assigning windows to activities, but I dunno if that'd be possible with autogenerated ones... 2. He will make some default icons for users that want to choose specific ones instead of the automatically generated. can users still choose any arbitrary icon they like? 2. We need a list of common activities for Nuno to make icons for. Ideas? We should get at least 20 :) work fun chat school math science writing art music cooking ... really, the sort of activities the user has is likely to depend on what the user does in his/her life :) me, I'll have activities for kwin, plasma, odfkit, etc... plus various courses, and one for fun. rrix has activities for fedora, plasma, and a dozen other things I forget. activities are a rather personal thing... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: IRC meeting: point of what was done at akademy
On Saturday, July 10, 2010 03:41:47 am Marco Martin wrote: On Saturday 10 July 2010, Aaron J. Seigo wrote: On July 9, 2010, Marco Martin wrote: oh, fsck, scrap that: i remembered that 90% i'll be away 16-17-18 :/ 15th? gives ryan a day to recuperate and a day before you leave? if it's ok for other people would be perfect :) thursday the 15th? sure :) your thursday morning is vancouver's wednesday night, it should be easy for me to stay up late then. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Akademy] sunday meeting, friday schedule change
two important things if you're at akademy: plasma people: we're having a quick meeting after the closing ceremony sunday. if you're doing any sort of plasma work, please stick around for that. everyone: friday's bof session has been delayed to 10:30, so that I don't have to fork myself. :) if anyone has a problem with that (ie, plane to catch) come tell me tonight. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/desktop/shell
On Monday, June 28, 2010 02:29:41 pm Marco Martin wrote:
SVN commit 1143845 by mart:
avoid a crash in the following scenario: change the activity type of a
containment, then try to stop the activity. it still misbehaves, because
the new containment it gets created is not added to the activity and the
activity manager, that will list the activity as stopped. this should be
backported, but it has to be right before :)
CCMAIL:plasma-devel@kde.org
M +16 -0 activity.cpp
M +1 -0 activity.h
--- trunk/KDE/kdebase/workspace/plasma/desktop/shell/activity.cpp
#1143844:1143845 @@ -315,8 +315,24 @@
connect(context, SIGNAL(activityChanged(Plasma::Context*)), this,
SLOT(updateActivityName(Plasma::Context*)), Qt::UniqueConnection);
m_containments.insert(QPairint,int(screen, desktop), containment);
+connect(containment, SIGNAL(destroyed(QObject *)), this,
SLOT(containmentDestroyed(QObject *))); }
+void Activity::containmentDestroyed(QObject *object)
+{
+//safe here because we are not accessing it
+Plasma::Containment *deletedCont = static_castPlasma::Containment
*(object); +
+QHashQPairint,int, Plasma::Containment*::iterator i;
+for (i = m_containments.begin(); i != m_containments.end(); ++i) {
+Plasma::Containment *cont = i.value();
+if (cont == deletedCont) {
+m_containments.remove(i.key());
+break;
+}
+}
+}
+
hmmm. I did think there was a convenience function for removing a value from a
hash. but anyways...
double-check how the *new* containment is being added, too. it really ought to
have been replacing the old one in the hash. hmm, but iirc aaron's code didn't
do anything special and my code wasn't designed to let things be overwriten,
so...
erg, well, I can't find the code aaron added, but *iirc* it was using
insertContainment, which will refuse to overwrite, because it used to be (and
miight still be but hopefully not) possible to end up with two containments
both wanting to be on that same activity and screen and desktop. you could
either rewrite that one to reject the old containment instead of the new one,
or write a separate swapContainment function.. eh, don't make a new function,
just change the existing one, it doesn't matter which one wins when there's a
conflict on startup :)
also, maybe that hash should be using weak pointers? *shrug*
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdebase/workspace/plasma/design
SVN commit 1131048 by chani: added some explaination of activities and context in case I get hit by a bus :) I hope it makes sense 'cause I'm getting tired. the context stuff is... not 100% coherent, and probably only 80% correct. aaron, could you check that file when you get a moment please? :) CCMAIL: plasma-devel@kde.org A activities A context ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Panel icon sizing bug in 4.4
On May 23, 2010 09:53:15 Mike Kasick wrote: Hi folks, This issue was first raised on the KDE community forums [1], for which my reply is fifth in the thread. It was recommended that I post the issue here. I recommend that you search bko first next time. :) https://bugs.kde.org/show_bug.cgi?id=226039 https://bugs.kde.org/show_bug.cgi?id=201619 and both redirect to https://bugs.kde.org/show_bug.cgi?id=193756 basically, WONTFIX. 177166 looks like it's a dup too... then there's https://bugs.kde.org/show_bug.cgi?id=168579 which was the reason for this change in the first place. one of the bug reports mentioned that KDE's default icon size should be respected, although it's not clear whether that was implemented. if that setting is not followed, then you have found a bug, and patches are welcome. :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Panel icon sizing bug in 4.4
On May 23, 2010 10:27:26 Rhapsody wrote: On 23/05/10 18:08, Ivan Čukić wrote: As far as I know, it is intentional, that is, it is not a bug. From my point of view, this is something that we can make configurable (there already is a configuration page in system settings application appearance icons advanced, *but the size setting is disabled*) My exact response to the highlighted part was to scream What?!? You WHAT?!?. I went to check this and found that is it true. There is a setting there, it is set to 32 pixels, and unlike the other categories (Desktop, Toolbar, Main Toolbar, etc) is is explicitly disabled. Why would you do that? Why would you set an arbitrary size limit and then explicitly disable the option to change it, while still leaving it there to mock the user? What reason was there? sounds like a bug to me. and if it's a bug, it can be fixed (and might even be a trivial fix). it's probably worth checking whether there was a reason, though. Ivan, since you've already found the config option, do you know who put it there (or, who disabled it)? -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Panel icon sizing bug in 4.4
On May 23, 2010 11:02:33 Chani wrote: On May 23, 2010 10:27:26 Rhapsody wrote: On 23/05/10 18:08, Ivan Čukić wrote: As far as I know, it is intentional, that is, it is not a bug. From my point of view, this is something that we can make configurable (there already is a configuration page in system settings application appearance icons advanced, *but the size setting is disabled*) wait a sec... it's not greyed out for me. I can change the icon size. however, X randomly crashed before I could test whether plasma follows it. now I'm pissed off at my computer, so I'm gonna go do something else. -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Panel icon sizing bug in 4.4
On May 23, 2010 13:08:57 Marco Martin wrote: On Sunday 23 May 2010, Chani wrote: On May 23, 2010 10:27:26 Rhapsody wrote: On 23/05/10 18:08, Ivan Čukić wrote: As far as I know, it is intentional, that is, it is not a bug. From my point of view, this is something that we can make configurable (there already is a configuration page in system settings application appearance icons advanced, *but the size setting is disabled*) My exact response to the highlighted part was to scream What?!? You WHAT?!?. I went to check this and found that is it true. There is a setting there, it is set to 32 pixels, and unlike the other categories (Desktop, Toolbar, Main Toolbar, etc) is is explicitly disabled. Why would you do that? Why would you set an arbitrary size limit and then explicitly disable the option to change it, while still leaving it there to mock the user? What reason was there? sounds like a bug to me. and if it's a bug, it can be fixed (and might even be a trivial fix). it's probably worth checking whether there was a reason, though. Ivan, since you've already found the config option, do you know who put it there (or, who disabled it)? so, the reason was that vertical panels on widescreens are usually huge to fit the taskbar, if icons would be unlimited they would quite useless, like kickoff using half of the screen. now yes, it should follow that setting, no it doesn't, never followed it in kde4 and should do before 4.5 not the reason for the panel thing (that was already explained enough times) - the reason for the default icon size setting in the KCM being disabled on ivan's computer. -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: Auto-discard notification
On May 23, 2010 13:59:03 Marco Martin wrote: this has been automatically discarded, but was legit, so forwarding here please forward inline instead of encapsulated; kmail can't quote that message. makes it a bit of a PITA to reply to this. anyways.. 1) yeah, that bugs me too. it's slightly less weird than having the popup float out in nowhere without the panel, but I do wonder if there's a way to magically tie the popup position to the panel's position/state. 2)same again - but I bet it would drive me *nuts* if everything slid up when my mouse moved onto the calendar. 3) yes, we've needed a proper presentation mode in kde for ages, it was discussed at.. akademy 08 I think? but afaik nobody implemented it. patches welcome. 4) file a bug with kwin (but please *please* check for duplicates first!) 5) sounds like Yet Another Struts Problem. probably closed as upstream. (*cough*bko*cough*) 6) *reassigns to project kwin* 7) never seen it; hard to fix bugs that can't be reproduced. 8) race condition between the two results. wait half a second before hitting enter. 9) no clue what NDAS is, but the device notifier is for recently plugged in devices, not stuff that's mounted on boot. if NDAS is something you plug in like usb sticks or SD cards, file a bug on http://bugs.kde.org 10) the mouse was also different from everything else, long long ago. 11) you're using focus-follows-mouse. iirc this was already closed WONTFIX. put a longer delay on your focus-follows-mouse setting (I remember things like the cookie dialog had this problem in kde3; delayed focus changes help a lot) 12) when you can reproduce, file a bug on http://bugs.kde.org 13) file bugs against the weather applet. 14) meh :P it could be improved, but I have other priorities right now, and I don't see anybody else - besides notmart and aaron, who are even busier - trying to fix it. :( this mailing list is neither a bug database nor a user support forum; please take the bugs to http://bugs.kde.org next time (I hear we have a shiny new wizard to try out!) and remember to check for duplicates :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Fix kickof bug 231791 allowing apps dropping in the favorites view
On May 22, 2010 09:03:53 Alessandro Diaferia wrote: Hullo, it seems reviewboard cannot connect to anonsvn (at least from here) so i'm attaching the patch here as it is really small. Having a look at https://bugs.kde.org/show_bug.cgi?id=231791 you can see how easy is reproducing the bug. It seems that kickoff does not allow adding favorites via DD. DD is only used to move items in the list. This little patch allows adding favorites via DD dragging from the application view to the favorites one. I just don't know if this is considered as a new feature. It seems to me that this patch just makes kickoff behaving as it is expected to behave. Anyway the last word is yours of course, plasma-friends :) Regards. hmm. no comment on whether it's a feature.. code looks sensible, although wouldn't it be more future-proof to iterate over data-urls() instead of only taking the first? -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
bizarre multiscreen crash
so I was trying to ensure views are always created when new screens appear...
technically that was a success - but directly after creation I get this
bizarre crash from the systray. it's happening very soon after
PlasmaApp::createWaitingDesktops() returns, and *always* happens when a new
desktopview is created in response to a new screen. creating views on plasma
startup still works fine.
I didn't have this problem last week, though. o.0 I'm confused and very tired,
so I'm attaching it here and hoping magical fairies will have fixed it in the
morning ;)
oh, but the good news is - other than not always creating views, activities
and multiscreen and per-desktop-views should all get along nicely now :) if
you look at http://techbase.kde.org/Projects/Plasma/ZUI you'll see that
although there's still work to be done, most of the critical things are fixed!
:) :) me and aaron and ivan have been chipping away at the code... hmm, I
guess this means it's time for a screencast.
--
This message brought to you by eevil bananas and the number 3.
www.chani3.com
Application: Plasma Workspace (plasma-desktop), signal: Aborted
[KCrash Handler]
#7 0xb7fb6424 in __kernel_vsyscall ()
#8 0xb560c411 in raise () from /lib/libc.so.6
#9 0xb560dc12 in abort () from /lib/libc.so.6
#10 0xb65e4a87 in qt_message_output (msgType=QtFatalMsg,
buf=0xa4bc630 ASSERT failure in QWidget::mapTo(QWidget *parent, const
QPoint pos): \parent must be in parent hierarchy\, file
/home/chani/src/kde-qt/src/gui/kernel/qwidget.cpp, line 3934)
at /home/chani/src/kde-qt/src/corelib/global/qglobal.cpp:2250
#11 0xb65e4c49 in qt_message (msgType=QtFatalMsg, msg=0xb6784b04 ASSERT
failure in %s: \%s\, file %s, line %d, ap=0xbfb91634
\214\\�h\\��Y�^\017)
at /home/chani/src/kde-qt/src/corelib/global/qglobal.cpp:2296
#12 0xb65e5067 in qFatal (msg=0xb6784b04 ASSERT failure in %s: \%s\, file
%s, line %d) at /home/chani/src/kde-qt/src/corelib/global/qglobal.cpp:2479
#13 0xb65e4662 in qt_assert_x (where=0xb6265c8c QWidget::mapTo(QWidget
*parent, const QPoint pos), what=0xb6265c68 parent must be in parent
hierarchy,
file=0xb62659a0 /home/chani/src/kde-qt/src/gui/kernel/qwidget.cpp,
line=3934) at /home/chani/src/kde-qt/src/corelib/global/qglobal.cpp:2021
#14 0xb5ab6711 in QWidget::mapTo (this=0xa480038, parent=0xa125840,
p...@0xbfb917c4) at /home/chani/src/kde-qt/src/gui/kernel/qwidget.cpp:3934
#15 0xab7bc550 in SystemTray::X11EmbedPainter::performUpdates (this=0x9eb3cc0)
at
/home/chani/src/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/x11embedpainter.cpp:127
#16 0xab7bc933 in SystemTray::X11EmbedPainter::qt_metacall (this=0x9eb3cc0,
_c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfb91890)
at
/home/chani/build/kdebase/workspace/plasma/generic/applets/systemtray/x11embedpainter.moc:75
#17 0xb670dbb8 in QMetaObject::metacall (object=0x9eb3cc0,
cl=QMetaObject::InvokeMetaMethod, idx=4, argv=0xbfb91890) at
/home/chani/src/kde-qt/src/corelib/kernel/qmetaobject.cpp:237
#18 0xb6721c2a in QMetaObject::activate (sender=0x9bea714, m=0xb686b6e4,
local_signal_index=0, argv=0x0) at
/home/chani/src/kde-qt/src/corelib/kernel/qobject.cpp:3275
#19 0xb6780de3 in QTimer::timeout (this=0x9bea714) at
.moc/debug-shared/moc_qtimer.cpp:134
#20 0xb672a5d8 in QTimer::timerEvent (this=0x9bea714, e=0xbfb91ef4) at
/home/chani/src/kde-qt/src/corelib/kernel/qtimer.cpp:271
#21 0xb671dd02 in QObject::event (this=0x9bea714, e=0xbfb91ef4) at
/home/chani/src/kde-qt/src/corelib/kernel/qobject.cpp:1212
#22 0xb5a55a96 in QApplicationPrivate::notify_helper (this=0x9b1a1f8,
receiver=0x9bea714, e=0xbfb91ef4) at
/home/chani/src/kde-qt/src/gui/kernel/qapplication.cpp:4298
#23 0xb5a531d8 in QApplication::notify (this=0x9b0d448, receiver=0x9bea714,
e=0xbfb91ef4) at /home/chani/src/kde-qt/src/gui/kernel/qapplication.cpp:3702
#24 0xb6dcfeb0 in KApplication::notify (this=0x9b0d448, receiver=0x9bea714,
event=0xbfb91ef4) at /home/chani/src/kdelibs/kdeui/kernel/kapplication.cpp:302
#25 0xb6706605 in QCoreApplication::notifyInternal (this=0x9b0d448,
receiver=0x9bea714, event=0xbfb91ef4) at
/home/chani/src/kde-qt/src/corelib/kernel/qcoreapplication.cpp:704
#26 0xb670a0dd in QCoreApplication::sendEvent (receiver=0x9bea714,
event=0xbfb91ef4) at
../../include/QtCore/../../../../src/kde-qt/src/corelib/kernel/qcoreapplication.h:215
#27 0xb6740f0e in QTimerInfoList::activateTimers (this=0x9b1cf34) at
/home/chani/src/kde-qt/src/corelib/kernel/qeventdispatcher_unix.cpp:603
#28 0xb673cdf4 in timerSourceDispatch (source=0x9b1cf00) at
/home/chani/src/kde-qt/src/corelib/kernel/qeventdispatcher_glib.cpp:184
#29 0xb3954d98 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#30 0xb39583e0 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#31 0xb3958513 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#32 0xb673dfa0 in QEventDispatcherGlib::processEvents (this=0x9b19fe8, flags={i
= 36}) at
/home/chani/src/kde-qt/src
Re: dreaming...
On May 18, 2010 13:15:10 Jos Poortvliet wrote: Hi all, A question, and I'll try to keep it short. It is about a VERY immature funding *idea*. No expectations please... mmm. it kinda sounds like the 'view source key' the OLPC was supposed to have, times the internet! with an extra dose of community. and clouds! ;) I'm drooling already... -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: basic activity manager
/trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp http://reviewboard.kde.org/r/3780/#comment4681 again, not sure we want containments really associated too much with the activity manager. it should be fully self-contained and not need to know which containment it is associated with. in the case where it is embedded in an existing ControllerWindow (e.g. panel toolbox - activities), we already have one so we know where to show it and which orientation it should take. in the case where it is being called up directly via PlasmaApp::showActivityManager, i think it should just always be at the bottom of the screen as a horizontal strip. which means we don't need a containment. the corona can be gotten from PlasmaApp. the most irritating use of m_containment is to place the view on its screen and desktop. the widgetexplorer probably should still use this to be sure that doubleclicking an applet sends it to the containment expected (especially with view-per-desktop)... but this isn't so important for the activity manager. do I really need to bother setting the screen at all? or can I assume it'll magicallly go to the Right one? if I do need to set the screen, what's the best thing to set it to? the current screen (if something can tell me that)? -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: basic activity manager
On 2010-04-23 16:33:26, Aaron Seigo wrote: /trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.cpp, lines 312-314 http://reviewboard.kde.org/r/3780/diff/1/?file=24331#file24331line312 does the activity manager really need to care if we don't have a containment? we can get the corona by other means. I think it mattered for positioning the window properly... either that or it's an artifact of the widgetexplorer On 2010-04-23 16:33:26, Aaron Seigo wrote: /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.h, lines 123-131 http://reviewboard.kde.org/r/3780/diff/1/?file=24335#file24335line123 i'm on the fence as to whether these belong in PlasmaApp or not. for now, it's ok, i think. but if we end up with more complex (or just more) code related to activity management in plasma-desktop, then we're probably going to want to split it out into its own class. for now, let's just see where this takes us. ahh. yeah, I asked if it belonged in plasmaapp or desktopcorona iirc, and you didn't say anything, so I just started adding to plasmaapp. we *are* going to end up with more codde; this is the bare minimum for whats implenented so far. I also think i'll end up with a class representing a single activity, it'll make things easier On 2010-04-23 16:33:26, Aaron Seigo wrote: /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp, line 471 http://reviewboard.kde.org/r/3780/diff/1/?file=24336#file24336line471 again, not sure we want containments really associated too much with the activity manager. it should be fully self-contained and not need to know which containment it is associated with. in the case where it is embedded in an existing ControllerWindow (e.g. panel toolbox - activities), we already have one so we know where to show it and which orientation it should take. in the case where it is being called up directly via PlasmaApp::showActivityManager, i think it should just always be at the bottom of the screen as a horizontal strip. which means we don't need a containment. the corona can be gotten from PlasmaApp. hmm. I'll look into that next then, see how many contaimnent assumptions aree in the code - Chani --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3780/#review5187 --- On 2010-04-22 21:06:15, Chani Armitage wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3780/ --- (Updated 2010-04-22 21:06:15) Review request for Plasma. Summary --- this is the beginning of the activity manager. it's not very pretty yet; it doesn't have many features yet; but it's a start. switching between activities and creating new ones works. at the moment activities are still just containments; soon this will use the proper activity API instead. stuff that's not implemented yet: -responding to signals for anything other than added activities -showing a pretty thumbnail for each activity -start/stop/remove buttons -filtering Diffs - /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/desktop/shell/CMakeLists.txt 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopview.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopview.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp 1115355 Diff: http://reviewboard.kde.org/r/3780/diff Testing --- known issues: -removing a containment seems to crash ControllerWindow, because the destructor tries to use the containment's corona. I'm wondering if there's a way to fix this other than having ActivityManager store a pointer to the corona... of course it wouldn't be a problem if we could delete things off the scene without removing them first :/ -if you make the activitymanager or widgetexplorer go away without clicking the close button, its geometry is wrong the next time it's shown. not sure what's up with that. Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https
Re: Review Request: basic activity manager
On 2010-04-23 08:20:21, Ivan Cukic wrote: First, I'm getting two compilation problems - AbstractIcon and AbstractIconList are not in Plasma namespace. The other thing is that AbstractIcon and AbstractIconList don't have PLASMAGENERICSHELL_EXPORT so the linker fails as well. Did you make some patches to libs/plasmagenericshell as well? (hmm, my comment seems to have vanished) yes, forgot those patches, sorry. - Chani --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3780/#review5180 --- On 2010-04-22 21:06:15, Chani Armitage wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3780/ --- (Updated 2010-04-22 21:06:15) Review request for Plasma. Summary --- this is the beginning of the activity manager. it's not very pretty yet; it doesn't have many features yet; but it's a start. switching between activities and creating new ones works. at the moment activities are still just containments; soon this will use the proper activity API instead. stuff that's not implemented yet: -responding to signals for anything other than added activities -showing a pretty thumbnail for each activity -start/stop/remove buttons -filtering Diffs - /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/desktop/shell/CMakeLists.txt 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopview.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopview.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp 1115355 Diff: http://reviewboard.kde.org/r/3780/diff Testing --- known issues: -removing a containment seems to crash ControllerWindow, because the destructor tries to use the containment's corona. I'm wondering if there's a way to fix this other than having ActivityManager store a pointer to the corona... of course it wouldn't be a problem if we could delete things off the scene without removing them first :/ -if you make the activitymanager or widgetexplorer go away without clicking the close button, its geometry is wrong the next time it's shown. not sure what's up with that. Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: basic activity manager
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3780/ --- Review request for Plasma. Summary --- this is the beginning of the activity manager. it's not very pretty yet; it doesn't have many features yet; but it's a start. switching between activities and creating new ones works. at the moment activities are still just containments; soon this will use the proper activity API instead. stuff that's not implemented yet: -responding to signals for anything other than added activities -showing a pretty thumbnail for each activity -start/stop/remove buttons -filtering Diffs - /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /dev/null PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/desktop/shell/CMakeLists.txt 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopview.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopview.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.cpp 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.h 1115355 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp 1115355 Diff: http://reviewboard.kde.org/r/3780/diff Testing --- known issues: -removing a containment seems to crash ControllerWindow, because the destructor tries to use the containment's corona. I'm wondering if there's a way to fix this other than having ActivityManager store a pointer to the corona... of course it wouldn't be a problem if we could delete things off the scene without removing them first :/ -if you make the activitymanager or widgetexplorer go away without clicking the close button, its geometry is wrong the next time it's shown. not sure what's up with that. Thanks, Chani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
activities api in kdereview
hey, ivan wanted me to tell you guys that he's moved the nepomuk activities stuff into kdereview. :) it's the API we developed at tokamak - for letting apps query things like the current activity, and for letting workspace things (ie, plasma) manage them. -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tablet Made in Germany: The wePad, completely opensource
On April 12, 2010 23:38:31 Christophe Olinger wrote: Hey Plasma people, I just fell off my chair. Engadget today showed me the wePad. A completely opensource based tablet with software made in germany. http://www.youtube.com/watch?v=U8hARiE6fgM The activity switcher is amazing. It doesn't switch, but has a huge activity while the screen is only centered on part of it. So you just slide around. I have a feeling that this is something that the plasma people had in mind with the initial ZUI? *cough*newspaper*cough* ;) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
The window’s actions on the right are already implemented as a plasmoid and there is no need to show the minimize button: if you want to switch between applications you just do it, if you want to go to an activity you just use the panel for that and if you want to close, the button is there. In your mockup you’re duplicating the functionality: the same action can be triggered by the list of windows and in the right side of the panel. No, it's not duplication. Here's why: In my proposal the menu allows to hide the whole application = all windows at once. The Minimize button only hides the active window. If you're running only single-window apps, it does not make a difference, but if an app has multiple windows, it is a difference. while I can see this being handy for something like Qt Designer, it'd be a PITA for something like a web browser or okular. I don't care that all my .pdf files are open in something called Okular, I care about getting to the document about magical ponies :) and guess which sort of app Joe Sixpack is more likely to be using... -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dot article on activities needed, maybe more?
since I'm currently thinking about everything *except* my midterm, here's a few notes on activities from a what happened at tokamak perspective. -I met with kwin people to talk about how to show only the relevant windows -me, ivan, kwin people and some other people discussed and figured out an API for programs to ask about and control activities (this was one of the two big activities meetings). -me and lubos talked about session management stuff (and then I spent a fair bit of time alone with a whiteboard, figuring out what I actually *wanted* from sessions). I still haven't had time to check whether my theories can work, though; that's 4.6+ stuff. -we presented the activity API to the rest of tokamak, discussed and improved it -aaron and me and... design guy from the other side of canada... and probably some other people discussed the plasma activity-manager UI and drew mockups n'stuff -ivan did some hacking on the API -I started hacking on the UI there are blog posts from both me and ivan about activities, too. -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Anti (gran)parents panel removing
On April 7, 2010 12:43:12 Marco Martin wrote: On Wednesday 07 April 2010, Aaron J. Seigo wrote: add panel - Panel With Default Widgets. that would either run a small javascript or just suck in an exported appletsrc snippet; perhaps both. Which... is probably about what Alex had in mind :) it would achieve what he wants, yes. what about an action in empty panel containments as load default junk? so first create empty, then load defaults, if you want ehh. I'd really rather implement a nice template system :) that way people could make up other panel setups, too! and maybe not just panels... what I don't know is... can you just export a containment and then import it somewhere else? or does the default panel case need some scripting (eg. is the battery applet only added if a battery is detected? .. actually I wiped my plasma config last week and ended up with a batteryless panel, we may have a bug in trunk's default layout) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.5 - Activities
On March 31, 2010 11:37:51 Aaron J. Seigo wrote: On March 31, 2010, Ivan Čukić wrote: can we get together on irc soon and do a once-over of this and then get it moved into kdereview? Ok, I'll try to be online tomorrow. If not, then the weekend? sounds great; i'll be around :) hey guys, did this happen? is it in review yet? huh? huh? *bounces* I wanna play with it *now*! ;) looking at the API I think I might want a convenience function or two later... but those can always be added on once they're actually needed. let's keep it minimal right now :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.5 - Activities
btw, at this moment I am editing Plasma::Context to return some made-up activities for testing. I have a midterm tomorrow, but chances are by friday or saturday I'll be itching to put some *real* data in there... :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ideas/Mockups for Mobile System Tray (GSoC)
I think it already is (public). There is a checkbox that says make public that I made sure to check :) If anyone is unable to see the proposal though let me know and I'll copy it out somewhere. oh, is that a new feature this year? last year there was no way to let non-mentors see it. I do know that I couldn't see diego's proposal until I logged in. For SMS, I proposed that first (huge and persistent) notification because that's the way one my old phone does it, and I personally thought it was a really good idea if it was primarily a 'phone' device because it's usually in my pocket so I actually want it to make a big deal out of things that happen, so that even if I somehow didn't hear the alert or feel the vibration when I next take out the phone I immediately see ah! new SMS, and in one button-press can reply/etc. when I next take out the phone - ah, but that implies you weren't *doing* anything with the phone at the time. if you were in the middle of writing an sms, your priorities might be different. :) Was thinking a dismiss-all button could immediately free up the screen but the systray should probably start flashing or have a new flashing icon or something to say hey, you previously put away some notifications, come see it when you're free kay?. flashing is evil :) but having an icon is fine. the n900's glowy-window-switcher effect is a nice subtle reminder that something wants attention. Another thing that could probably be done is to group notifications (since we have application name and SMS's probably all come from the same app), so that if someone sends you 10 SMS's you'd see just one notification that says You have received 10 text messages and the button says Go to your inbox instead? perhaps... err... does the notification spec allow us to do that sort of thing? -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
