Re: preview in wallpaper dialog

2010-08-12 Thread Marco Martin
On Wednesday 11 August 2010, Aaron J. Seigo wrote:
 On Wednesday, August 11, 2010, todd rme wrote:
  I would say the mandlebrot wallpaper also benefits from this, since
  you can see how the colors you select work in practice.  Although it
 
 easy enough with an in-line preview, but in practice i don't find it a
 necessity. the colours are fairly obvious and hitting apply shows me what
  the real thing is going to end up looking like.

recapping:
* for some wallpaper kinds the monitor preview is just redundant information
* in some wallpapers is easy to build previews without actually using the 
Wallpaper rendering (images, something else?)
* the live preview is quite an important information for some other wallpapers 
that change radically depending on the settings and is not possible to have a 
thumbnail grid, so to see what this is about the only way would be apply and 
then figure out how to undo if one doesn't like the result
* i find reall, really, really overkill a button that shows a fullscreen 
preview of the wallpaper

in the end, if a little live preview is needed should be up to the wallpaper 
implelentation.
the attached patch is a first quick and dirty implementation of tat:
the need of the monitor is decided by Wallpaper::setNeedsPreview(bool)
that at the moment is default off
Image would have it off, slideshow on, mandelbrot and barble on and whatever 
each individual wallpaper needs it or not.

the monitor is now put uder the plugin selection combobox giving a vertical 
layout.
as a sideeffect, user interfaces like the slideshow one that looked too empty 
and squshed together, now with the monitor look more full but at the same 
time more spaced

if the idea is good will reviewboard it

Cheers,
Marco Martin
Index: kdelibs/plasma/wallpaper.cpp
===
--- kdelibs/plasma/wallpaper.cpp	(revision 1162319)
+++ kdelibs/plasma/wallpaper.cpp	(working copy)
@@ -471,7 +471,8 @@
 initialized(false),
 needsConfig(false),
 scriptInitialized(false),
-previewing(false)
+previewing(false),
+needsPreview(false)
 {
 if (wallpaperDescription.isValid()) {
 QString api = wallpaperDescription.property(X-Plasma-API).toString();
@@ -665,6 +666,16 @@
 d-previewing = previewing;
 }
 
+bool Wallpaper::needsPreview() const
+{
+return d-needsPreview;
+}
+
+void Wallpaper::setNeedsPreview(const bool preview)
+{
+d-needsPreview = preview;
+}
+
 const Package *Wallpaper::package() const
 {
 return d-package;
Index: kdelibs/plasma/private/wallpaper_p.h
===
--- kdelibs/plasma/private/wallpaper_p.h	(revision 1162319)
+++ kdelibs/plasma/private/wallpaper_p.h	(working copy)
@@ -77,6 +77,7 @@
 bool needsConfig : 1;
 bool scriptInitialized : 1;
 bool previewing : 1;
+bool needsPreview : 1;
 };
 
 class LoadImageThread : public QObject, public QRunnable
Index: kdelibs/plasma/wallpaper.h
===
--- kdelibs/plasma/wallpaper.h	(revision 1162319)
+++ kdelibs/plasma/wallpaper.h	(working copy)
@@ -343,6 +343,9 @@
  */
 void setPreviewing(bool previewing);
 
+bool needsPreview() const;
+
+
 Q_SIGNALS:
 /**
  * This signal indicates that wallpaper needs to be repainted.
@@ -490,6 +493,8 @@
 //FIXME: KDE5, this must be moved to the dptr
 QListQAction* contextActions;
 
+void setNeedsPreview(const bool preview);
+
 private:
 Q_PRIVATE_SLOT(d, void renderCompleted(WallpaperRenderThread *renderer, int token, const QImage image,
const QString sourceImagePath, const QSize size,
Index: kdebase/workspace/libs/plasmagenericshell/backgrounddialog.cpp
===
--- kdebase/workspace/libs/plasmagenericshell/backgrounddialog.cpp	(revision 1162601)
+++ kdebase/workspace/libs/plasmagenericshell/backgrounddialog.cpp	(working copy)
@@ -28,24 +28,14 @@
 #include Plasma/View
 #include Plasma/Corona
 
+#include kworkspace/screenpreviewwidget.h
 #include kworkspace/kactivityinfo.h
 #include kworkspace/kactivitycontroller.h
 
 #include ui_BackgroundDialog.h
 #include ui_ActivityConfiguration.h
 
-struct WallpaperInfo
-{
-WallpaperInfo() {}
-
-WallpaperInfo(const QString p, const QString m)
-: plugin(p),
-  mode(m)
-{}
-
-QString plugin;
-QString mode;
-};
+typedef QPairQString, QString WallpaperInfo;
 Q_DECLARE_METATYPE(WallpaperInfo)
 
 // From kcategorizeditemsviewdelegate by Ivan Cukic
@@ -189,6 +179,7 @@
wallpaper(0),
view(v),
containment(c),
+   preview(0),
modified(false)
 {
 }
@@ -204,13 +195,14 @@
 Plasma::Wallpaper* wallpaper;
 Plasma::View* view;
 QWeakPointerPlasma::Containment containment;
+ScreenPreviewWidget* preview;
 

Re: New property proposal for StatusNotifierItem protocol: Label

2010-08-12 Thread Sebastian Kügler
On Wednesday 11 August 2010 22:01:24 Aaron J. Seigo wrote:
 On August 11, 2010, Marco Martin wrote:
  I think in some cases we could want applet not going away, like lionmail,
  even if i have kmail closed i could want lionmail continuing to notify me
  about emails
 
 true; in that case the user could just add lion mail themselves, no? (which
 would supress the addition of another one for the KSNI..) or the KSNI could
  come from akonadi itself?

I like the overall idea, but the above is not very nice as there's suddenly a 
difference between programmatically added items and manually added ones -- 
confusing to the user.

I'll let your idea sink for a bit, it does sound like a neat idea (though 
maybe not quite for the Lion Mail usecase).

That one is now in the systray just like network and battery. The icon only 
shows up when there's new email in its configured folder, and empty it's at 
~200k in mem consumption, so not that bad.

Have a nice weekend, I'm away for a festival until Sunday ...
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: QGraphicsWidget::geometryChanged problem in 4.7

2010-08-12 Thread Alexis Ménard
On Wed, Aug 11, 2010 at 8:22 PM, Aaron J. Seigo ase...@kde.org wrote:
 On August 11, 2010, Alexis Ménard wrote:
 On Wed, Aug 11, 2010 at 12:21 AM, Aaron J. Seigo ase...@kde.org wrote:
  On August 10, 2010, you wrote:
do you agree that this should get fixed in Qt?
  
   Obviously. Will do tomorrow ASAP and ask integration in 4.7.0

 Here is the report : http://bugreports.qt.nokia.com/browse/QTBUG-12813

 I already have the patch, I'm waiting for the review.

 terrific.

Pushed 3ee89bc0830f69d44f272eff5a0c886bff33c92e on its way inside the
CI. Will ask inclusion in 4.7.0.


 What about moving the signal as a protected method and the
  implementation
 call the parent?

 ooh, i love it. nasty, but it works :) go-go-Gof!

 --
 Aaron J. Seigo
 humru
  othro a kohnu se
 GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

 KDE core developer sponsored by Qt Development Frameworks


 ___
 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


Saving a Plasma Dashboard

2010-08-12 Thread Aleix Pol
Hi!
So our dashboard is mostly working (other than the last issues I already
reported), now I just have a little itch.

The thing is that the KDevelop dashboard is the central place to show
information when a project is opened, the idea is that it's going to be
shared by all the project members and it's going to be shared by versioning
it (over svn/git or any VCS it's being used) and it's quite painful that
newspaper is storing information about the screen resolution and positions
are specified depending on the resolution, the problem is, as you will
expect, that every time the dashboard is opened we will be asked to commit
the dashboard changes, even if we didn't change anything.

Do you think that would be very hard to solve?

If that's not possible, maybe I can resize the dashboard before closing, but
I'd prefer to ask you first.

Thanks,
Aleix
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: preview in wallpaper dialog

2010-08-12 Thread Aaron J. Seigo
On Thursday, August 12, 2010, Marco Martin wrote:
 recapping:

good summary.

 in the end, if a little live preview is needed should be up
 to the
 wallpaper implelentation.

yes.

 the attached patch is a first quick and dirty implementation of
 tat:
 the need of the monitor is decided by Wallpaper::setNeedsPreview(bool)
 that at the moment is default off

may setPreviewDuringConfiguration? yes, long, but also very clear :)


 Image would have it off, slideshow on, mandelbrot and barble on and
 whatever each individual wallpaper needs it or not.

again: why does slideshow need it? it just shows a random image from the mix
 you add. i don't see how it is actually useful?
 
 the monitor is now put uder the plugin selection combobox giving a
 vertical
 layout.

cool; i think this should go in... 

as an asid: i also think that the
pattern plugin should not have the preview and should instead show an
 iconview containing the various patterns.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F
 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks



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: Saving a Plasma Dashboard

2010-08-12 Thread Aaron J. Seigo
On Thursday, August 12, 2010, Marco Martin wrote:
 perhaps Newspaper::saveContents could override all geometries with dummy
 values, not sure if soething would break or not...

nothing should break; but perhaps this is a good use case for a new flag in
Containment, something like a property: bool appletsManageGeometry. when
true, they save their geometry out. when false, then it is left 100% up to
the containment, and the applets save no geometry information. the only
problem i can see there is the size of the applets wouldn't be stored in
 that case and will revert to their default sizes every time.

*thinks*

perhaps a more fine grained set of flags of what the Containment
 manages? pos, size, etc?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F
 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks



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: Saving a Plasma Dashboard

2010-08-12 Thread Marco Martin
On Thursday 12 August 2010, Aaron J. Seigo wrote:
 On Thursday, August 12, 2010, Marco Martin wrote:
  perhaps Newspaper::saveContents could override all geometries with dummy
  values, not sure if soething would break or not...
 
 nothing should break; but perhaps this is a good use case for a new flag in
 Containment, something like a property: bool appletsManageGeometry. when
 true, they save their geometry out. when false, then it is left 100% up to
 the containment, and the applets save no geometry information. the only
 problem i can see there is the size of the applets wouldn't be stored in
  that case and will revert to their default sizes every time.
 
 *thinks*

well, when the applet is created will be resized at the default size anyways.
if 

 perhaps a more fine grained set of flags of what the Containment
  manages? pos, size, etc?

would make senze, there could be pos, size, zorder and uhm, can't think about 
other stuff
immutability maybe, but i would rather not ;)

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: preview in wallpaper dialog

2010-08-12 Thread Marco Martin
On Thursday 12 August 2010, Aaron J. Seigo wrote:
 On Thursday, August 12, 2010, Marco Martin wrote:
  recapping:
 good summary.
 
  in the end, if a little live preview is needed should be up
 
  to the
 
  wallpaper implelentation.
 
 yes.
 
  the attached patch is a first quick and dirty implementation of
 
  tat:
  the need of the monitor is decided by Wallpaper::setNeedsPreview(bool)
  that at the moment is default off
 
 may setPreviewDuringConfiguration? yes, long, but also very clear :)

yes, indeed, would still prefix the getter with needs tough?

  Image would have it off, slideshow on, mandelbrot and barble on and
 
  whatever each individual wallpaper needs it or not.
 
 again: why does slideshow need it? it just shows a random image from the
 mix you add. i don't see how it is actually useful?

maybe if the image switches every 2-3 seconds could give an overview of what 
those folders contain.
not strictly necessary, bbut somewhat remotely useful

  the monitor is now put uder the plugin selection combobox giving a
 
  vertical
 
  layout.
 
 cool; i think this should go in...
 
 as an asid: i also think that the
 pattern plugin should not have the preview and should instead show an
  iconview containing the various patterns.
i have a local patch that partly implements it already :p

now the thing is:
some of the pattern images make sense painted a single time, some are very 
timy and need to be tiled several times to make sense.
so, the question is: usual problem of not being able to use Wallpaper itself 
to generate thumbnails and the tile generation have to be duplicated in the 
code just for the thumbnails?

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: preview in wallpaper dialog

2010-08-12 Thread Aaron J. Seigo
On Thursday, August 12, 2010, Marco Martin wrote:
 On Thursday 12 August 2010, Aaron J. Seigo wrote:
  On Thursday, August 12, 2010, Marco Martin wrote:
   recapping:
  good summary.
  
   in the end, if a little live preview is needed should be up
   
   to the
   
   wallpaper implelentation.
  
  yes.
  
   the attached patch is a first quick and dirty implementation of
   
   tat:
   the need of the monitor is decided by Wallpaper::setNeedsPreview(bool)
   that at the moment is default off
  
  may setPreviewDuringConfiguration? yes, long, but also very clear :)
 
 yes, indeed, would still prefix the getter with needs tough?

true...

   Image would have it off, slideshow on, mandelbrot and barble
 on and
   
   whatever each individual wallpaper needs it or not.
  
  again: why does slideshow need it? it just shows a random image from the
  mix you add. i don't see how it is actually useful?
 
 maybe if the image switches every 2-3 seconds could give an overview of
 what those folders contain.

personally i'd prefer an icon view showing all entries ... that would be
actually useful as you could see all the images in the collection. with
delayed only render what is visible like we have already in the
 SingleImage preview case it hopefully should not be a problem.

 i have a local patch that partly implements it already :p
 
 now the
 thing is:
 some of the pattern images make sense painted a single time, some are very
 timy and need to be tiled several times to make sense.
 so, the question is: usual problem of not being able to use Wallpaper
 itself to generate thumbnails and the tile generation have to be
 duplicated in the code just for the thumbnails?

it's a one-liner in QPainter to tile a pixmap, so i don't think it's a big
 deal :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F
 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks



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: preview in wallpaper dialog

2010-08-12 Thread Marco Martin
On Thursday 12 August 2010, Aaron J. Seigo wrote:
 On Thursday, August 12, 2010, Marco Martin wrote:
  On Thursday 12 August 2010, Aaron J. Seigo wrote:
   On Thursday, August 12, 2010, Marco Martin wrote:
recapping:
   good summary.
   
in the end, if a little live preview is needed should be up

to the

wallpaper implelentation.
   
   yes.
   
the attached patch is a first quick and dirty implementation of

tat:
the need of the monitor is decided by
Wallpaper::setNeedsPreview(bool) that at the moment is default off
   
   may setPreviewDuringConfiguration? yes, long, but also very clear :)
  
  yes, indeed, would still prefix the getter with needs tough?
 
 true...

okie, so the first version will go in now, then up for next modifications :)

Image would have it off, slideshow on, mandelbrot and barble
 
  on and
 
whatever each individual wallpaper needs it or not.
   
   again: why does slideshow need it? it just shows a random image from
   the mix you add. i don't see how it is actually useful?
  
  maybe if the image switches every 2-3 seconds could give an overview of
  what those folders contain.
 
 personally i'd prefer an icon view showing all entries ... that would be
 actually useful as you could see all the images in the collection. with
 delayed only render what is visible like we have already in the
  SingleImage preview case it hopefully should not be a problem.

hmm, folders could be huge, i think it could throw in too much information

  i have a local patch that partly implements it already :p
  
  now the
 
  thing is:
  some of the pattern images make sense painted a single time, some are
  very timy and need to be tiled several times to make sense.
  so, the question is: usual problem of not being able to use Wallpaper
  itself to generate thumbnails and the tile generation have to be
  duplicated in the code just for the thumbnails?
 
 it's a one-liner in QPainter to tile a pixmap, so i don't think it's a big
  deal :)
yup, in this case indeed. was thinking also on a more general point tough

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


changing the changelog

2010-08-12 Thread Aaron J. Seigo
hi plasma people! :)

we're working on so many different things and often very much heads down
in work that the changelog is getting neglected. we're also beyond the early
OMG, this feature will take 2 months and 100s of commits to be fully done,
so i can't use commit log msgs to build the changelog phase of plasmadom.
 it is now, i believe, realistic to use commit msgs to build our changelog.

i'd like to therefore request that all commits to plasma code in kdelibs,
kdebase and kdeplasma-addons that represent a new feature or a bug fix
include the appropriate keywords in the commit msg. kmail will filter them
 for me :)

features should have FEATURE in the message.

bugs should have either a
 BUG:# comment or just BUG or BUGFIX in the msg.

thanks :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B
 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks



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: changing the changelog

2010-08-12 Thread Aaron J. Seigo
On Thursday, August 12, 2010, Aaron J. Seigo wrote:
 features should have FEATURE in the message.
 
 bugs should have either a
  BUG:# comment or just BUG or BUGFIX in the msg.

erf.. and IMPROVEMENT for notable improvements that aren't bugfixes or
 features.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F
 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks



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: changing the changelog

2010-08-12 Thread Artur Souza (MoRpHeUz)
On Thu, Aug 12, 2010 at 2:48 PM, Aaron J. Seigo ase...@kde.org wrote:
 i'd like to therefore request that all commits to plasma code in kdelibs,
 kdebase and kdeplasma-addons that represent a new feature or a bug fix
 include the appropriate keywords in the commit msg. kmail will filter them
  for me :)

This will also help when we migrate to git: using git shortlog or
git log --pretty=oneline it will be much easier to generate the
Changelogs :).

So, it's *really* important that we write nice first line message
and then a nice commit message for each commit :) It will help the
maintainer's life a lot :D

Cheers,
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: changing the changelog

2010-08-12 Thread John Layt
On Thursday 12 August 2010 19:06:21 Artur Souza (MoRpHeUz) wrote:
 On Thu, Aug 12, 2010 at 2:48 PM, Aaron J. Seigo ase...@kde.org wrote:
  i'd like to therefore request that all commits to plasma code in kdelibs,
  kdebase and kdeplasma-addons that represent a new feature or a bug fix
  include the appropriate keywords in the commit msg. kmail will filter
  them for me :)
 
 This will also help when we migrate to git: using git shortlog or
 git log --pretty=oneline it will be much easier to generate the
 Changelogs :).
 
 So, it's *really* important that we write nice first line message
 and then a nice commit message for each commit :) It will help the
 maintainer's life a lot :D
 
 Cheers,

One of the things I really like about git is how easy it is to set up a commit 
message template that could include all the keywords as a memory aid (1).  
I've tried a quick google but there doesn't seem to be an easy way to do this 
using subversion?

John.

(1) For the Nokia/Qt template see 
http://qt.gitorious.org/qt/qt/blobs/4.7/.commit-template
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: changing the changelog

2010-08-12 Thread Artur Souza (MoRpHeUz)
On Thu, Aug 12, 2010 at 4:21 PM, John Layt johnl...@googlemail.com wrote:
 One of the things I really like about git is how easy it is to set up a
 commit message template that could include all the keywords as a memory aid

+1. As soon as we move to git I can create such a template for us :)
Not that it's hard, just that someone needs to step up and as I'm
already talking too much on this thread I can do that :P

Cheers,
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel