Re: Create new bugzilla components for the dataengines??
It would be easy to create those components, i can do that. The important part is to have maintainers of those new components. Currently 80%+ of the plasma components have no maintainer. Triaging bugs into the right component only makes limited sense, since they get looked at at random anyway. So as long as there is no maintainer for those new components, i see little sense in creating them. That beeing said, its easy to be a maintainer. The amount of bugs per component is actually quite low. And if you know your code, you can quickly fix new bugs or close them as duplicates. Greetings Beat Asraniel Wolf ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bug killing
Big killing is great :) I propose an actual target. Currently plasma is the second largest kde project in terms of bugs. 1514 open bugreports (excluding wishes). kmail is third with 1340 open bugs. I think a good goal would be to beat kmail and become third :) Its only 170 bugs to close. Thats totaly doable with the amount of duplicates that exist. greets Beat Asraniel Wolf ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Bug 254092
You have sent your mail by accident to plasma-devel@kde.org but i have seen you already correctly attached the file to http://bugs.kde.org/show_bug.cgi?id=254092 to the others, there is a bugreport, the discussion should be continued there Am Donnerstag 14 Oktober 2010, um 14.55:48 schrieb Hans-Rudi Denzler: Does not work anymore. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Blocking mouse on entering non reachable areas in multi-screen setups
Am Donnerstag 23 September 2010, um 22.47:42 schrieb Martin Gräßlin: On Thursday 23 September 2010 22:35:19 todd rme wrote: There is already a tool called noenter that worked pretty well, but it won't compile. At the very least fixing that and letting people who want to compile it themselves would be nice. But, since noeneter works, it is possible to detect where invisible portions of the screen are. And, from what someone said in the other thread, it is possible to teleport mice. So the remaining question is whether it is possible to detect whether there is a screen on the other side of a blank portion. If there is, then it should be possible to handle the situation you describe. Please note: I just showed one obvious way how this can result in problems. I can think of many more. So I truly doubt that noenter worked pretty well and the fact that it doesn't compile is for me a sign that it is so broken that whoever worked on it abandoned it for good. For me it compiled very recently. But one thing i would like to mention. I doubt x.org will ever fix that. we have seen it with the tooltip hole bug that was never fixed, and now we needed to implement a workaround. Sure, we can just blame x.org for that the next 5 years, but i doubt that will benefit the users in the end. noenter worked quite well for me on my dualscreen setup (with different resolutions). Sure, it needs some improvements, but the basics are working. I might be naif, but for me such a feature doesn't sound that hard to code, in the end its just collision detection code with some special cases. And i don't think a separate programm should be needed for it to work, but that probably kwin should handel it. anyway, would be nice to see a solution :) have a nice day Beat Wolf ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: new kwin effect: roundedcorners - make corners of the desktop rounded
If it is a bug or not i don't know, but this is the behaviour. Really annoying if you have the panel on the screen with the smaller resolution, because you can go beyond the panel, breaking your workflow (you can't quickly click on kickoff by throwing your mouse to the bottom lef). Beat Wolf Am Donnerstag 23 September 2010, um 15.35:50 schrieb Sebastian Kügler: On Wednesday, September 22, 2010 19:02:14 todd rme wrote: On Tue, Sep 21, 2010 at 6:05 PM, Nuno Pinheiro n...@oxygen-icons.org wrote: A Terça, 21 de Setembro de 2010 21:41:33 Martin Gräßlin você escreveu: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5225/#review7713 --- I am still rather opposed to include this effect in a default workspace setup. I really like the work you are putting into it, but I think that this effect is hardly used by anyone and is not something that belongs into a default setup. And we should not include everything and the kitchensink because we can do it (therefore we have Compiz, see http://smspillaz.wordpress.com/2010/09/15/philosophy/ ). I am also unhappy with some of the effects we currently ship (including snow, which was written by me), so this is more a general thing. I think such effects should go to either kdeartwork, kdeplasma-addons or extragear. Till we have found a nice solution I would recommend to publish on kde-look/apps (although that is also not so nice as we tend to break the ABI). tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/roundedco rn ers .cpp http://svn.reviewboard.kde.org/r/5225/#comment7832 This check looks superfluous. In line 35 you set glTexture to 0, so for both xrender and opengl the pointer is at least 0. As deleting null pointers is save you can get rid of the if statement and I think also of the #ifdef. - Martin On 2010-09-21 18:34:04, Christoph Fritz wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5225/ --- (Updated 2010-09-21 18:34:04) Review request for kwin, Plasma, Martin Gräßlin, and Thomas Lübking. Summary --- Inspired by roundedge http://www.nongnu.org/roundedge/ this kwin effect makes corners of the desktop rounded. Older Macs and Monitors had this feature too. Diffs - tags/KDE/4.5.1/kdebase/workspace/kwin/effects/CMakeLists.txt 1170001 tags/KDE/4.5.1/kdebase/workspace/kwin/effects/configs_builtins.cp p 1170001 tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/CMakeLi s t s.txt PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/rounded c o rners.desktop PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/rounded c o rners.h PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/rounded c o rners.cpp PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/rounded c o rners_config.h PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/rounded c o rners_config.cpp PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/rounded c o rners_config.desktop PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/rounded c o rners_config.ui PRE-CREATION Diff: http://svn.reviewboard.kde.org/r/5225/diff Testing --- Screenshots --- roundedcorners_without_frame http://svn.reviewboard.kde.org/r/5225/s/498/ with_simulated_border http://svn.reviewboard.kde.org/r/5225/s/499/ Thanks, Christoph from a design prespective this efect is 1 noncence, removes the hit area on the edges of the scren. 2 not good enough, (if you would want to do it you should do it properlie via some shape distrotion mesh and some global lights and shadows) so IMO it should not be in defoult land oxygen guy, I make the pretty pictures A bit off topic, but is this able to prevent the mouse from entering certain portions of the screen? If so, then could the technique be used to prevent the mouse from entering invisible portions of the screen when using two monitors with different resolutions? Currently it is easy for the mouse to get lost there, and it makes things more difficult for unhiding panels. Although there is a valid question regarding whether rounded corners belongs in kwin, I think preventing the mouse
Re: Why rotate widgets?
For example my girlfriend has all her picture frames slightly rotated. But i can't think of a usecase for turning them totaly upside down. Beat Wolf Am Dienstag 07 September 2010, um 12.00:15 schrieb Markus Slopianka: Hi. I wonder why Plasma widgets in Plasma Desktop can be rotated. Why would anyone need individual widgets to be upside down? Isn't this one of those micro-options we once stated to get rid of? Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: rebooting the JJ Tasks page
there are currently 2 bugs in that list, they both don't have the junior-jobs tag in bugzilla, should it be added? you can get all plasma junior jobs on this page: https://bugs.kde.org/buglist.cgi?keywords=junior- jobsbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcmdtype=doitproduct=plasma geets Beat Wolf Am Freitag 06 August 2010, um 19.58:09 schrieb Aaron J. Seigo: hi :) i've started a reboot of the junior jobs tasks page here: http://community.kde.org/Plasma/Tasks when you come across easy to accomplish tasks (features or bug fixes) that you aren't going to do yourself, please add them to that page so we can build up a reasonable list. let's also try and groom it every few weeks so it doesn't get filled with dead wood :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma::Wallpaper does software scaling/copying when it isn't necessary.
from my experience i don't know a hack either, but would be interested for
animated wallpapers. currently you can't do animated wallpapers without using
like 30% of you cpu.
beat wolf
Am Sonntag 04 Juli 2010, um 00.28:31 schrieb velociraptor Genjix:
See the conversation
http://kde-look.org/content/show.php?content=112105forumpage=4 titled
Phonon video backend? I do the scaling using hardware acceleration but
Plasma::Wallpaper requires me to still copy this array with slow software
acceleration. If the format is correct then just give me the target X
surface. KDE insists on drawing it's own wallpaper on top though. So this
is a problem with plasma- is there a workaround or a hack? void
VideoWallpaper::paint(QPainter *painter, const QRectF){// ...
const QImage imag(frame-data[0], codec_ctx-width, codec_ctx-height,
frame-linesize[0], QImage::Format_RGB32);
painter-drawImage(boundingRect(), imag);// ...} It would run ALOT
faster if there was a way to disable KDE4 rendering a wallpaper or be
allowed to render directly to that wallpaper. A video wallpaper should be
as natural as an image or colour in today's world.
_
http://clk.atdmt.com/UKM/go/195013117/direct/01/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kephal or pager bug
Ok, i don't have time right now, i'm in the middle of the exams. So perhaps there is a second screen lying around at akademy, sounds like a pretty easy fix, and perhaps a few annoying multiscreen bugs get fixed by that :) have a nice day Beat Wolf Am Samstag 03 Juli 2010, um 06.13:49 schrieb Aaron J. Seigo: On July 1, 2010, Asraniel wrote: I created a stand alone qt app that uses qdesktopwidget. I could observe that the size of QApplication::desktop()-geometry(); changes when the workAreaResized() signal is emited. But when screenCountChanged() is emited, it is not. So when you get a screen added signal, the desktop size has not yet changed. For me, thats a bug.But it could just be wanted that way. So either the pager needs to be fixed to know that, or kephal changed because for me it seem unintuitive the way it is now, or qt needs to be changed. If somebody wants the stand alone test app, tell me. i suppose that technically Kephal is correct: it's emitting the signal when the number of screens has changed. however, i do agree with you that it's unintuitive that it does so when the screen hasn't actually taken effect yet. it seems that the Kephal::Screen itself is set up properly (has the right size, e.g.) but that Kephal::ScreenUtils::desktopGeometry() isn't correct? desktopGeometry is just a call to QDesktopWidget::geometry() ... so Kephal is, at that moment, in an inconsistent state. i wonder if simply delaying the emitting of the screenAdded signal in Kephal would be enough to give desktopGeometry() enough time to catch up. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kephal or pager bug
I searched a little further.
I created a stand alone qt app that uses qdesktopwidget. I could observe that
the size of QApplication::desktop()-geometry(); changes when the
workAreaResized() signal is emited. But when screenCountChanged() is emited,
it is not. So when you get a screen added signal, the desktop size has not yet
changed.
For me, thats a bug.But it could just be wanted that way. So either the pager
needs to be fixed to know that, or kephal changed because for me it seem
unintuitive the way it is now, or qt needs to be changed.
If somebody wants the stand alone test app, tell me.
Have a nice day (and akademy!)
Beat Wolf
Am Donnerstag 01 Juli 2010, um 10.15:21 schrieb Asraniel:
Hi,
i discovered yesterday that when i add or remove a screen on kde 4.5 rc1,
the aspect ratio of the pager changes. This is the wanted behaviour. BUT,
it only changes when i resize the panel at least one pixel after the
screen change. I the searched a little and thought that the pager does not
get the screen added/removed singal. But it does.
I then saw this code:
qreal ratio = (qreal)Kephal::ScreenUtils::desktopGeometry().width() /
(qreal)Kephal::ScreenUtils::desktopGeometry().height();
so, this takes the geometry of the desktop and calculates the ratio for the
pager. Sounds absolutely correct. So why does it not do it?
I then outputed the Kephal::ScreenUtils::desktopGeometry() value, and
discovered that even that we got the signal that a screen was added (or
removed), that value was actually the old value before the change.
Kephal::ScreenUtils::numScreens() on the other hand returned the correct
amount of screends.
I then changed the first code for the ration into the following:
QRect tempRect;
for(int i = 0; i Kephal::ScreenUtils::numScreens(); i++){
tempRect |= Kephal::ScreenUtils::screenGeometry(i);
}
qreal ratio = (qreal)tempRect.width() / (qreal)tempRect.height();
and everything worked perfectly.
Now, is this a kephal bug? or a qt bug? from looking at the code kephal
does little more than use qdesktopwidget and send those signals to plasma.
I suspect that this could cause some of the other multiscreen bugs.
I didn't want to patch kephal, who knows, perhaps that is the wanted
behaviour, so i could just patch the pager to work correctly.
Feedback?
have a nice day.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kephal or pager bug
I searched a little further.
I created a stand alone qt app that uses qdesktopwidget. I could observe that
the size of QApplication::desktop()-geometry(); changes when the
workAreaResized() signal is emited. But when screenCountChanged() is emited,
it is not. So when you get a screen added signal, the desktop size has not yet
changed.
For me, thats a bug.But it could just be wanted that way. So either the pager
needs to be fixed to know that, or kephal changed because for me it seem
unintuitive the way it is now, or qt needs to be changed.
If somebody wants the stand alone test app, tell me.
Have a nice day (and akademy!)
Beat Wolf
PS: sorry if this message arrives twice, but something seems to have gone
wront with the first try.
Am Donnerstag 01 Juli 2010, um 10.15:21 schrieb Asraniel:
Hi,
i discovered yesterday that when i add or remove a screen on kde 4.5 rc1,
the aspect ratio of the pager changes. This is the wanted behaviour. BUT,
it only changes when i resize the panel at least one pixel after the
screen change. I the searched a little and thought that the pager does not
get the screen added/removed singal. But it does.
I then saw this code:
qreal ratio = (qreal)Kephal::ScreenUtils::desktopGeometry().width() /
(qreal)Kephal::ScreenUtils::desktopGeometry().height();
so, this takes the geometry of the desktop and calculates the ratio for the
pager. Sounds absolutely correct. So why does it not do it?
I then outputed the Kephal::ScreenUtils::desktopGeometry() value, and
discovered that even that we got the signal that a screen was added (or
removed), that value was actually the old value before the change.
Kephal::ScreenUtils::numScreens() on the other hand returned the correct
amount of screends.
I then changed the first code for the ration into the following:
QRect tempRect;
for(int i = 0; i Kephal::ScreenUtils::numScreens(); i++){
tempRect |= Kephal::ScreenUtils::screenGeometry(i);
}
qreal ratio = (qreal)tempRect.width() / (qreal)tempRect.height();
and everything worked perfectly.
Now, is this a kephal bug? or a qt bug? from looking at the code kephal
does little more than use qdesktopwidget and send those signals to plasma.
I suspect that this could cause some of the other multiscreen bugs.
I didn't want to patch kephal, who knows, perhaps that is the wanted
behaviour, so i could just patch the pager to work correctly.
Feedback?
have a nice day.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Kephal or pager bug
Hi,
i discovered yesterday that when i add or remove a screen on kde 4.5 rc1, the
aspect ratio of the pager changes. This is the wanted behaviour. BUT, it only
changes when i resize the panel at least one pixel after the screen change.
I the searched a little and thought that the pager does not get the screen
added/removed singal. But it does.
I then saw this code:
qreal ratio = (qreal)Kephal::ScreenUtils::desktopGeometry().width() /
(qreal)Kephal::ScreenUtils::desktopGeometry().height();
so, this takes the geometry of the desktop and calculates the ratio for the
pager. Sounds absolutely correct. So why does it not do it?
I then outputed the Kephal::ScreenUtils::desktopGeometry() value, and
discovered that even that we got the signal that a screen was added (or
removed), that value was actually the old value before the change.
Kephal::ScreenUtils::numScreens() on the other hand returned the correct
amount of screends.
I then changed the first code for the ration into the following:
QRect tempRect;
for(int i = 0; i Kephal::ScreenUtils::numScreens(); i++){
tempRect |= Kephal::ScreenUtils::screenGeometry(i);
}
qreal ratio = (qreal)tempRect.width() / (qreal)tempRect.height();
and everything worked perfectly.
Now, is this a kephal bug? or a qt bug? from looking at the code kephal does
little more than use qdesktopwidget and send those signals to plasma.
I suspect that this could cause some of the other multiscreen bugs.
I didn't want to patch kephal, who knows, perhaps that is the wanted
behaviour, so i could just patch the pager to work correctly.
Feedback?
have a nice day.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
call to plasma maintainers
Hi everybody, we are getting closer to the 4.5 release (and especially the first RC), so i wanted to make a little call to all people that are maintainers of certain parts of plasma (not only the official maintainers, but everybody that actually knows well certain parts of plasma). The bug triagers did an amazing job and got the bugcount of plasma close to 500. considering that not long ago it was close to 1000, that is a great achievement. But of course triaging only closes duplicates and invalid bugreports. It is now up to you, the maintainers, to go trough the bugs of your specific plasma component and try to fix a few bugs. you can find the links to all the bugs of your component on this page: https://bugs.kde.org/component-report.cgi?product=plasma Don't hesitate to close invalid bugs you see (or already fixed ones, or ones that are actually qt bugs) and you can also add the junior-jobs tag to a bug you think is easy to fix but you just don't have the time right now (actually fixing it is always better than adding the tab by the way ;) ). so, have fun :) Beat Wolf ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bug target for 4.5
Great! now one of the next steps is to actually fix some of the most reported plasma bugs, in order to not have too many dupes in the future. You can find them here: https://bugs.kde.org/duplicates.cgi?sortby=countreverse=1maxrows=100changedsince=7openonly=1product=plasma Lets make that 4.5 release shine :) Beat Wolf Am Dienstag 08 Juni 2010, um 09.43:04 schrieb Nicolas Lécureuil: :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Feature Request] Autoconfig ext-monitor
I would like to support that request too, multiscreen support is not that great yet, but very important! I hope something can also be done to integrate the nvidia tools into the config (i heard they have a CLI interface, so it should be doable). There is a SoC project, but i haven't heard anything from it yet? anyway, seems like a big project, so i hope that not everybody just hopes for the best for the SoC project, but tries to fix stuff by himself. I sadly don't have time right now :( Beat Wolf Am Freitag 28 Mai 2010, um 10.33:37 schrieb Mohamed Ikbel Boulabiar: Yes Luca, I am interested in reducing the number of things that should be configured by the user. (Specially in conferences when all bugs raise up ! = Murphy Law ?) There isn't someone who started doing a Google SoC project this year about external monitor config. ? On Thu, May 27, 2010 at 9:02 PM, tringalinv...@libero.it tringalinv...@libero.it wrote: Good idea, it could be possible to save the configuration for every monitor plugged in so, if in the future will be plugged a monitor with the same name of one who has already been used, KDE will use the configuration assigned to that monitor name. And, maybe, if a new screen is plugged in KDE could open automatically the configuration window, like Windows does. Luca Tringali Messaggio originale Da: boulab...@gmail.com Data: 27/05/2010 15.59 A: plasma-devel@kde.org Ogg: [Feature Request] Autoconfig ext-monitor Hi, I want to propose a feature in KDE. I don't know how much time does it need to be implemented. Auto configure external monitor plugging with the default monitor setting : When I plug an external monitor, I should always configure it. But these days, using xrandr tool the default monitor resolution is always detected by a * and the current one by a + sign. Please, can you add that feature, so a user can check a config box only one time to let the system accept default configuration according to default monitor resolution and to mirror screen ? Doesn't show KDE as an intelligent system ? Do you remember this video when a developer from KDE encountered some problems configuring his external monitor ? http://www.youtube.com/watch?v=oY5GN9MQHMA What you think ? Thanks a lot, Best Regards Mohamed-Ikbel BOULABIAR Computer Engineer ENSI - Tunisie Master M2 Human-Computer Interaction, Telecom-Bretagne ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ 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
I'll just trow that randomly in here. My gf told me that it would be nice if you could not only mark apps as favorites in kickoff, but also stuff like shutdown and especialy lock computer. But i didn't look at the code to see how easely thats possible. Beat Wolf Am Samstag 22 Mai 2010, um 18.03:53 schrieb Alessandro Diaferia: 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: problem with the notification plasmoid
You should be able to choose them when you create the bug, but not afterwards Beat Wolf Am Freitag 07 Mai 2010, um 00.27:12 schrieb Markus: Am Donnerstag 06 Mai 2010, 21:21:27 schrieb Marco Martin: ah, so not actually the notifications widget. the product to choose in bugzilla is plasma and the component is widget-devicenotifier Just FYI: Normal users can't set the component manually. Only admins can. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
Hei, i would just like to add my support for that idea, because as of kde 4.4, my second screen has no more wallpaper (plasma) and if i set dragonplayer to fullscreen on it, it goes to the first screen (kwin?). this is sadly with the nvidia driver. It would be great to have a more robust multiscreen support. Even if this is probably not the scope of the project, there are quite alot of plasma bugreports about multiscreen bugs, perhaps a few might get fixed during that project? greetings beat wolf Am Donnerstag 01 April 2010 16.35:59 schrieb Detlev Casanova: Hello folks ! I'd like to work with you this summer (and even longer after that :-) ). So, there's something in KDE that I find not really nice, It's the multiscreen management. For instance, I have an extra monitor for my laptop which I use every day but I also unplug it every day. The problem is that the screen configuration is never kept and sometimes, the screen is deactivated and KRandr says the screen is configured in 1980x1200... So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. In KRandr, there should be a possibility to keep configurations depending on the plugged device : I'd like the university projector to be on the right of my laptop screen. I'd like my 26 screen to be a clone of my laptop screen. If a configuration exists for a monitor when it's plugged in, the configuration should directly be applied with the monitor entry still in the device notifier (so that it can be modified). KRandr could also be more handy : the view could be used to move screens to place them at the wanted position (like a widget is moved on the desktop). What do you think ? I already posted the idea on #plasma but had to leave before you could answer so, it might feel familiar. I know though that there are problems with xrandr and some drivers, like the NVidia driver. I'm not sure how big are the problems but interfacing with the NVidia tools is maybe possible. Cheers, Detlev. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's by desktop sorting mode
i think there is a bugreport about exactly what you describe. i can try to find it tomorrow Beat Wolf Am Dienstag 23 März 2010 23.36:43 schrieb Dmitry Suzdalev: On 2010-03-23 22:05:51, Aaron Seigo wrote: so essentially it removes any sorting within the desktop sorting. i'm fine with that change (though perhaps others will now complain ;), though i have some thoughts below. Hmm, I just realized that some people might like to keep tasks sub-sorted by name indeed. For some reason I don't care about that a bit, but otoh this constant jumping of tasks always made me eager to write this patch :) So now i'm really confused - will the majority of people be like me or the opposite? :) Usability advice needed. If i'm in the minority, then I guess I can perfectly keep these changes local On 2010-03-23 22:05:51, Aaron Seigo wrote: trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortings trategy.cpp, line 66 http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line66 so window groups will shuffle randomly when windows leave or join or anything else that may cause winIds() to shift order. seems like trading one issue for another. i wonder if it wouldn't be nicer to have a stable way to identify AbstractGroupableTasks (a QUuid? or an integer based sequence?) for such occasions. that would also make things such as leftWinIdIsValid unecessary. the winId is just as random to the user; the only downside i can see is a small amount more memory consumption. Yes, this would be better indeed. In my klipper experiments i used QUuids to identify history items. but are there some downsides of simply assigning each new task an integer id++ as it's ID? That would be lighter that quuid :) On 2010-03-23 22:05:51, Aaron Seigo wrote: trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortings trategy.cpp, line 70 http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line70 can be just else if (leftWinIdIsValid) since we know both aren't due to the initial if. yes, thanks On 2010-03-23 22:05:51, Aaron Seigo wrote: trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortings trategy.cpp, line 78 http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line78 why storing in a temp var which is returned? nice one :) will change. - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/#review4637 --- On 2010-03-23 20:48:15, Dmitry Suzdalev wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/ --- (Updated 2010-03-23 20:48:15) Review request for Plasma. Summary --- This patch fixes a sorting order for Sort by Desktop mode of taskmanager lib. Summary: When in Sort by Desktop mode, sort by_desktop+by_winId, instead of by_desktop+by_winTitle as it is now. More details: Currently in by desktop sorting mode tasks are sorted by desktop and then by name. This leads to inconvenient things, here are some examples: - I have a browser with several tabs open. Whenever I change a tab, browser changes window title. This makes task jump in a task bar from one position to another while I'm simply changing tabs. - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, title is changed, task jumps - Some other situations caused this too, don't recall, but you got the idea :) What I've done: Instead of sorting by name, i made it to sort by winId. Tasks without winId are sorted out to the end of the list and sorted by name there. Typically these are the startup-in-progress items. As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 which has the same roots: invalid sorting order due to wrong comparison of regular items with starting up items. Long description, short patch ;) This addresses bug 219528. https://bugs.kde.org/show_bug.cgi?id=219528 Diffs - trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortings trategy.cpp 1105743 Diff: http://reviewboard.kde.org/r/3375/diff Testing --- Tested on trunk. Task items retain their sort order, not reacting to title changes, charming :) It affects only task applets with sort mode set to by desktop Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: keyboard shortcut
beeing a former katapult user, i changed the shortcut to alt+space too, as did my gf. just in case you feel alone doing that ;) Am Sonntag 07 März 2010 01.55:22 schrieb Roman Shtylman: I don't know if this is the best place to bring it up...but I will since krunner is related to plasma (more or less). Has any thought been given to changing the default shortcut to alt+space? I think this was the old old katapult? shortcut... iirc Anyhow, I find it very convenient to use cause my hands are already positioned to hit alt+space quickly all the time (and thus make use of the runner alot) ... at least more so over the alt+f2 default that is there now. Not sure why alt+f2 was chosen... maybe to be like the gnome run dialog binding? Anyone else have an opinion/comment on the matter? ~Roman ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: moving wallpaper
Am Samstag 23 Januar 2010 12.00:26 schrieb andreas: hi, I am not a professional programmer and just try out a few things. As many users i am waiting for animated wallpapers for quit some time. When i read that it is easily possible to create a plasma wallpaper plugin i checked the tutorial on techbase. It actually turned out to be easy enough and i got it working on my pc. indeed, writing a animated wallpaper is quite easy (i did the virus and particles one). So what i did is simple. I took a still image, made it seamless and doubled its height. Than i needed only 20 lines of code to make it slowly move from top to bottom of my desktop. I created a timer with 10 ticks per second and called a repaint when it hit to show the wallpaper with an offset that is simply controlled by the timer. It is simple and beautiful and adds allot to the desktop experience. But i have questions about it : - is there anything like that already done or planned not that i know of - is there a better way to implement it, with less resource usage i have the proprietary amd driver installed on a 3 GHZ quadcore pc and it uses 20% cpu No.. this is a real issue currently, there is no way to do something like opengl drawing or whatever that would be faster. i have the same issue with the wallpaper plugin, but could circumvent it a little by only updating the parts of the wallpaper that really changed. but judging from your description you have to update the whole wallpaper.. thats bad - how can i get access to a wallpaper selected in the systemsetting- selectWallpaper dialog for now i am using an absolute path to the image - how can i add options in systemsettings when my wallpaper-plugin is selected to control the animation-speed for instance As aseigo said, you have to code all that yourself, sadly... thats why i took the image wallpaper plugin as the base for the virus wallpaper and deleted everything i didn't need. But thats really bad, because when there are bugfixes in the image wallpaper, you won't get them. I hope there will be a way to make that more general. thanks folks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
bugfixing
Hello, as some might have noticed i'm going trough the old plasma reports and close quite a lot. On the same time i assign the bugs to the right plasma component etc. I'm doing this that the people that wrote the code can more easely fix their code because they don't have to go trough alot of invalid bugreports. So this is my call to you, everybody that wrote some code, go and check your bugreports and try to fix them. There are really alot of bugreports that are easy to fix, if you wrote the code. For those not familiar with bugzilla, you can find the different plasma components here: https://bugs.kde.org/component-report.cgi?product=plasma I would really like to see a few of the most reported bugs fixed. It really isn't that much fun to triage bugs if each day one has to close at least 5 times duplicates of bugs like: https://bugs.kde.org/show_bug.cgi?id=199325 https://bugs.kde.org/show_bug.cgi?id=200847 etc. And if bugs are not fun for bug triagers, they are even less for users. Especialy the basic components of plasma, like: panel, taskbar, systray, kickoff really need some love. If there are bugs in a weather plasmoid users will understand, if a basic component has a bug, a little less. So if anybody needs me to triage his bugs, please tell me, it will be a pleasure to do so. have a nice day and happy bugfixing Beat Wolf ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a tooltip to battery monitor applet
Just do as sebas said. make a hidden option for the current battery plasmoid, this will most probably be accepted. If you are still motivated later, you can write a plasmoid that is dedicated to statistics about the battery. This one too will probably be accepted. The difference is, only a minority of people will probably add such a plasmoid to their desktop, but most have the battery plasmoid. So the biggest impact would probably be to work on the battery plasmoid with a hidden option Am Donnerstag 26 November 2009 11.48:59 schrieb Kåre Särs: On Thursday 26 November 2009, Chani wrote: I disagree about the usefulness of time-remaining, but since it is not my code I'll let it be. That said, would I get objections if I would fork Battery Monitor into a Battery Time and then later push it to kdeplasma-addons? I don't know if it would make it into kdeplasma-addons. you can fork whatever you like in playground, though. Well, that was the ting. Why would I spend time on it, if it still won't be accepted :) I also thought about extragear/base/plasma/applets/, but that one is empty (dead?). perhaps you could add other statistics n'stuff too, or experiment with time estimation methods... :) Would that increase the chance of being accepted? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Trashy error messages
that would be against kio/trash probably. Beat Wolf Am Sonntag 06 September 2009 17.16:13 schrieb David Baron: Obviously. Which package? For bugreports bugs.kde.org should be used. thank you and have a nice day Beat Wolf Am Sonntag 06 September 2009 16.59:54 schrieb David Baron: No, I do not mean foul language or icons in an error box. I get consistantly that the trash protocol has unexpectedly failed on each plasma startup. I had this occasionally in previous versions, most always now in 4.3.1. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Prospective costs of the 3rd Plasma meeting (Tokamak3) - part 2
indeed basel should be equaly good. You might want to check the train prices (might be slightly higher, but not much), but appart from that basel works too (i would say, beeing a swiss citizen). Beat Wolf Am Montag 27 Juli 2009 19.28:44 schrieb Rob Scheepmaker: I'm about to book my plane tickets, and discovered that it would be cheaper for me to fly to Basel instead of Zurich. It doesn't look like Basel is much further from randa then Zurich is. Since that airport isn't mentioned on the techbase page I wanted to check if it's a good idea to fly there (if there's a good train connection to randa). Let me know asap so I can buy the tickets. Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Prospective costs of the 3rd Plasma meeting (Tokamak3) - part 2
Am Freitag 24 Juli 2009 09.35:59 schrieb Mario Fux: Am Donnerstag, 23. Juli 2009 schrieb Asraniel: Good morning I might actually turn up a few days, but i don't know exactly when and how long (work etc). Ok. Bring your sleeping back and we'll find a place for you. Sounds great But since its so close to where i live (well, thats relative, still 2-3 hours of train) i kind of have to come ;-) Where do you live? Fribourg (the swiss one) I will probably do bugfixing in plasma if i come. greetings Beat Wolf griits Mario ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Prospective costs of the 3rd Plasma meeting (Tokamak3) - part 2
I might actually turn up a few days, but i don't know exactly when and how long (work etc). But since its so close to where i live (well, thats relative, still 2-3 hours of train) i kind of have to come ;-) I will probably do bugfixing in plasma if i come. greetings Beat Wolf Am Donnerstag 23 Juli 2009 16.18:53 schrieb Mario Fux: Dear e.V. board members Here following the prospective costs and important information in a cleaner form: 14 Participants (in alphabetical order): - Aaron Seigo - Alexis Menard - Ana Cecília Martins Barbosa (fresh) - Artur Souza - Chani Armitage - Davide Bettio - Diego Casella (fresh) - Ivan Čukić - Marco Martin - Mario Fux (fresh ;-) - Martin Gräßlin (fresh) - Riccardo Iaconelli - Rob Scheepmaker - Sebastian Kügler Prospective costs for the air tickets: - ~5220 EUR in Total Prospective costs for the food: - ~1890 EUR lodging (9 days * 14 people * 15 EUR) Costs for the additional appartement for 4 persons: - ~ 144 EUR (9 days * 4 people * 4 EUR) TOTAL: - ~7254 EUR When and if there are any further questions or you need more information don't hesitate to ask. Greets from the rainy Zurich Mario ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak 3 - The organization begins
you can check on sbb.ch for the train connections (there should be translations available of the site) Beat Wolf Am Montag 20 Juli 2009 19.07:58 schrieb Artur Souza (MoRpHeUz): On Monday 15 June 2009, 19:00 Mario Fux wrote: If there are any questions just ask here or in private. Maybe to get the lowest fare I would need to arrive on the 27th. Is that a problem ? Another question: do you have the timeline of the train from Zurich and also how much does it cost ? Cheers, -- Artur Duque de Souza openBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: changelog (and my poor laptop)
Random advice. Try to clean the fan, or at least blow into to. Fixed my laptop last time he began to overheat randomly beat wolf On Freitag 08 Mai 2009 08.17:25 Aaron J. Seigo wrote: hi all ... i was offline for much of the day today as my laptop has decided to start overheating randoly; it seems nepomuk+strigi indexing my disk is too much for it. not sure what to make of that, but there it is. i did get some real work done this morning, however, and then i worked a bit on the changelog for 4.3 (why do i keep writing that as 3.4?); you'll find it in kdebase/workspace/plasma/design/CHANGELOG-4.3. it has what i could find and remember, but please fill in the cracks i missed. see you all Friday... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add textbox to calendar to copy paste current date
Am Donnerstag 04 Dezember 2008 18.25:57 schrieb Aaron J. Seigo: On Thursday 04 December 2008, Beat Wolf wrote: This patch brings back the possibility to copy paste the current selected date out of the calendar. I also had to adapt the scaling, because the textbox uses vertical space, so the calendar had to use more horizontal space. If you resize the calendar really badly, you will see something like in the second screenshot. But this can't be fixed before 4.3. why can't this be fixed before 4.3? We had a discussion in irc, and it seemed like this won't really be possible, because it introduces too many changes to how the calendar is rendered. Currently the numbers are pictures, worse, the background boxes are the same image as the numbers. So this is really bad. What would be needed: changing the calendar svg theme rendering the numbers directly as text. This causes layout problems i heard, never tried myself. No new string are needed for this, and it brings back a feature which was lost since 4.1, hope this can get in even with feature freeze. unfortunately this looks fairly ugly, even if it is useful. one solution would be to bring back some other missing bits such as the go to today button and week selector (the layout at the bottom could also likely be tweaked with some spacing to make it look good on REALLY wide calendars) pinhero said he wanted to redo the whole layout, but again, for 4.3. So in the end i decided that the patch is probably a good start, since in it's current state, the calendar is really bad... and i also wanted to see if there is any interest in something like that for 4.2. But if wanted i can add the go to today button and the week selector, should be quite easy (well, the week selector needs a new string probably, but can be done without a new one, just the numbers) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
