Re: Review Request: Ported KTimeTracker to KNotification

2009-09-28 Thread Davide Bettio 


 On 2009-09-21 13:41:29, Thorsten Staerk wrote:
  Good to see you working on my baby ktimetracker. Let's have a discussion on 
  irc.
 
 Davide Bettio wrote:
 ok. my timezone is CET. I'm on IRC in the afternoon and in the night. You 
 can find me in #plasma.
 
 Thorsten Staerk wrote:
 Did not work - most important question: What does your patch do? What 
 issues do you have? Which are fixed?
 
 Thorsten Staerk wrote:
 In bug 208099 https://bugs.kde.org/show_bug.cgi?id=208099 I recommend to 
 test your patch, but it does not build cleanly. Can you write a clean patch 
 please?

This patch replaces KSysTrayIcon (that is deprecated) with KNotificationItem. 
For more information you should read Aaaron and Notmart blogs about it.


- Davide


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1653/#review2411
---


On 2009-09-19 20:16:41, Davide Bettio wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/1653/
 ---
 
 (Updated 2009-09-19 20:16:41)
 
 
 Review request for KDE PIM and Plasma.
 
 
 Summary
 ---
 
 KTimeTracker has been ported to KNotificationItem but I still have few issues 
 that I've corrected with #if 0.
 It's not really clear to me how the notification works when KTimeTracker is a 
 KPart.
 Anyway please don't use XPM pixmaps, use icons.
 
 
 Diffs
 -
 
   /trunk/KDE/kdepim/ktimetracker/ktimetrackerpart.cpp 1024122 
   /trunk/KDE/kdepim/ktimetracker/tray.h 1024122 
   /trunk/KDE/kdepim/ktimetracker/tray.cpp 1024122 
 
 Diff: http://reviewboard.kde.org/r/1653/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Davide
 


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

Re: Ayatana notifications for Plasma

2009-09-28 Thread Aurélien Gâteau 
Sebastian Kügler wrote:
 On Thursday 24 September 2009 09:16:25 Aurélien Gâteau wrote:
 Aaron J. Seigo wrote:
 On September 23, 2009, Aurélien Gâteau wrote:
 Aaron J. Seigo a écrit :
 On September 23, 2009, Marco Martin wrote:
 every other consideration aside, i feel that it would have been -far-
  easier to mantain if the systray patch just consisted in
 notifications disabling and provide a totally separate daemon for that
 kind of notifications
 unless i'm misremembering things, this is also what i suggested to the
 people working on this when the Ayatana notifications design was first
 announced.
 My first implementation was doing exactly this. But I was told (by a
 Plasma dev) it was not a good idea.
 what i'm pretty sure i said (could be wrong, was a # of months ago) was
 that the option in the system tray could be defaulted very easily to
 off and the new style of notifications could run separate from it.
 That was how it was implemented: I splitted notify-osd into a library
 storing all the logic, and a notify-osd-gtk doing the gtk/cairo
 rendering. I then implemented a KDE version using Plasma. (You were not
 the one telling me it was not a good idea, Sebas did)
 
 Huh? I pointed out in May during UDS already that you just want to hook in an 
 applet 
 that does the notifications the Ayatana way, and default the systray 
 notifications to 
 off.

I was referring to this:

http://irclogs.ubuntu.com/2009/05/12/%23kubuntu-devel.txt

Search for a separate binary ... oh come on

 From the very beginning I knew such changes would never be 
upstreamable, that's why I thought creating a separate binary was the 
cleanest solution.

Regarding implementing it as a separate applet: I don't think it would 
have been a good idea because you would have to either add a dumb icon 
to your panel so that you could run this system, or add an invisible 
applet (not handy for the user to manipulate). Keep in mind that the 
binary is started on demand, so it does not take any memory if you are 
not using it (assuming it would automatically stop itself after a while).

The alternative of using a kded module could have been a good idea, but 
it would have required the creation of a kcm to configure the system. 
Such kcm would have had to tweak Plasma system tray settings behind its 
back, which could have been a problem to get on the fly changes. It 
would have at least needed to patch the applet to tell it to stop 
listening on dbus.

(admittedly, a separate binary would have required a kcm as well)

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

Re: Review request: Container plasma applet

2009-09-28 Thread Riccardo Iaconelli 
On Monday 28 September 2009 05:20:06 Aaron J. Seigo wrote:
 first thought i have is that if there are different svg's for different
  sizes,  let's put those different svg's in a file and use them.

Yup! I think that Marco is a bit too much optimistic too, but details follow 
in the mail answering to him. This could work by letting the air/oxygen theme 
embed the battery as pngs in the theme. It still doesn't solve the problems of 
consistency with the menu and device notifier which are themed by the icon 
theme, and the configuration of icon effects, but it's still a step forward.
 
 but i think we should stop thinking in terms of we have 16, 22, 32, 48,
  64,  128 and 256 px interfaces that is implied in this whole thread about
  using bitmaps.
 
 we have 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 250, 251, 252, 253, 
 254, 255, 256 px interfaces.

Interfaces do work at those sizes, some of them slightly less good than 
fixed sizes, but certainly better than blindly scaling svgs. png scaling 
*does* work reasonably well for most cases, for example the menu and the 
device notifier haven't ever shown me a scaling artifact in the panel.
SVGs need a lot of love to be done right, just like scalable interfaces.

or, more simply, to put it like nuno always says:
SVG is not scalable! whoever tells you that is lying!

 if the svg's only look good at certain multiples then we need to keep the 
 resizing to within those multiples.

Ok, then I think it's fair not to let the battery grow over 256x256. Even if 
it could probably be scaled a little bit more up without loosing too much 
details. :-)
 
 but really, going to pixmaps is not an option for reasons that should
 really be abundantly clear to anyone who has written a plasmoid.

So, are you suggesting that for example device notifier and the menus should 
switch over to SVG?

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

Re: Review request: Container plasma applet

2009-09-28 Thread Riccardo Iaconelli 
On Sunday 27 September 2009 23:19:41 Sebastian Kügler wrote:
[...]
 The problem might be that the battery.svg has not been touched by an artist
  in two years. I've hacked an icon's SVG from lng ago into the
  battery.svg theme. I'm bad at Inkscape today, and I certainly had any
  concept of pixel alignment that time. :/ This is only part of the issue
  (bad graphics used), the other part is shortcomings in Qt and SVG sizing
  for smaller pixel sizes.

Don't worry, the svg is just the same as the one of the oxygen icons. :-)
 
   then you have right effects applied like
   icon colorizing (try to make all your icons pink and you'll know what i
   mean) which nowadays breaks for the standard panel just for the
  battery. current animation is also somewhat... not very professional, at
  least in my humble opinion, i think that fading in and out the flashlight
  would look just so much better.
 
 That's a one or two line change.

Agreed, I think we should do it, but here I was just saying that the current 
animation is not a problem. :-)
 
   and i don't think it's a showstopper anyways.
  theme appropriateness then isn't really a problem too, no other icon on
  the panel infact respects it, and i think they do the right thing here.
 
 I don't. I'd *love* to see a monochrome system tray, that's hard to do
  right now, except for the battery plasmoid because it's using plasma's
  theme support. The battery applet supports that currently without any code
  changes.

See my previous answer to marco here. I'd love a monochrome icon too, but 
users *are* going to use 3rd party applications no matter what, with icons on 
which we have no control onto. If we ever manage to split hardware/system 
icons and apps then I'm all for it. :-)

  infact
   i think it's a bad idea to make the theme able to change these icons,
   after all to the user they're all system icons, icons like systray
   icons, or the menu or the device notifier. as such we have two
   possibilities:
 
  a) make the plasma theme theme all the icons, including systray and menu
  b) leave that up to the icon theme
 
 You're still thinking of the system tray as an icon parade. ;-)
 Having things like the battery in the system tray as an icon, but I would
  rather not have this limit the rendering of it to just the sizes
  KIconLoader supports.

Well, KIcon scales pngs so that's not really a problem. Of course the scaled 
sizes don't look as well as prerendered svgs, but that always gave us good 
enough resutls until now. :-)

  From a theming point of view, themers can currently
  just grab the battery.svg and change it.
 
 Also, using KIcon would mean that we need 120 different icons (10*2 states,
  6 sizes), that sounds like an awful lot of disk I/O and clutter to me.

Hmm... we already have all those icons, I counted 10 because i tend to 
consider the sizes as implicit, but anyways, they aren't going to be shown all 
at once. I think it's reasonably fast to load pngs, and because they're all 
cached, i don't think it's any slower than what it is now with svg caching. 
:-)

  a is not really feasible though, not only because we give a lot more
  images to do to theme creator, but then we lose the ability to do cool
  effects (blur) because of the crappy svg renderer. even if we do embed
  pngs, we loose the ability of having multiple sizes pngs, discarding all
  the work done on small size icons. that only leaves b as an option.
[...]
  As I explained above, it's really not that. :-) It's borders, grid
   alignment, and other style issues.
 
 Some of those can really be fixed in the SVG file, can you have a look at
  that?

Hm, I'm not really sure, as Marco correctly explains, we can't really fix 
everything there.
It's hard to do small sizes, we have one artist (david miller) who is almost 
completely dedicated to that, if you want to have a look at how much the icons 
do change, look in the small/16x16 directory of the oxygen sources. :-)
 
 To summarize a bit what we have right now:
 - pixel alignment
 - Qt SVG rendering issues

+1

 - bad quality of battery.svg

nah, not battery.svgz, i think we can't get much better than that :-) It's 
oxygen after all! :P

 + animations
 + theming (monochrome / color, at least)
 + 'just one theme file'

+1

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

Re: Ayatana notifications for Plasma

2009-09-28 Thread Sebastian Kügler 
On Monday 28 September 2009 15:03:05 Aurélien Gâteau wrote:
 Sebastian Kügler wrote:
  On Thursday 24 September 2009 09:16:25 Aurélien Gâteau wrote:
  Aaron J. Seigo wrote:
  On September 23, 2009, Aurélien Gâteau wrote:
  Aaron J. Seigo a écrit :
  On September 23, 2009, Marco Martin wrote:
  every other consideration aside, i feel that it would have been
  -far- easier to mantain if the systray patch just consisted in
  notifications disabling and provide a totally separate daemon for
  that kind of notifications
 
  unless i'm misremembering things, this is also what i suggested to
  the people working on this when the Ayatana notifications design was
  first announced.
 
  My first implementation was doing exactly this. But I was told (by a
  Plasma dev) it was not a good idea.
 
  what i'm pretty sure i said (could be wrong, was a # of months ago) was
  that the option in the system tray could be defaulted very easily to
  off and the new style of notifications could run separate from it.
 
  That was how it was implemented: I splitted notify-osd into a library
  storing all the logic, and a notify-osd-gtk doing the gtk/cairo
  rendering. I then implemented a KDE version using Plasma. (You were not
  the one telling me it was not a good idea, Sebas did)
 
  
  Huh? I pointed out in May during UDS already that you just want to hook
  in an applet  that does the notifications the Ayatana way, and default
  the systray notifications to off.
 
 I was referring to this:
 
 http://irclogs.ubuntu.com/2009/05/12/%23kubuntu-devel.txt

Maybe the misunderstanding stems from the concept of a separate binary (I mean 
use 
an applet). Applets are binaries as well though, so I wasn't clear. Sorry. The 
context there makes it pretty clear that it should've been done as a separate 
applet, 
IMO.

As to the cleanest solution, adding a separate notification mechanism is a 
kludge 
only done to be able to test those two on the same system. Inevitably, you end 
up 
with other kludges to be able to get it in as well (choosing the notification 
system 
to be used is one such thing). So that's kind of expected...

 Search for a separate binary ... oh come on
 
  From the very beginning I knew such changes would never be 
 upstreamable, that's why I thought creating a separate binary was the 
 cleanest solution.

Fair enough. Self-fulfilling prophecies. :)

 Regarding implementing it as a separate applet: I don't think it would 
 have been a good idea because you would have to either add a dumb icon 
 to your panel so that you could run this system, or add an invisible 
 applet (not handy for the user to manipulate).

That's what you have the config option for. (it's the same in terms of 
manipulation 
right now).

 Keep in mind that the 
 binary is started on demand, so it does not take any memory if you are 
 not using it (assuming it would automatically stop itself after a while).

Same goes for applets, dataengines...

 The alternative of using a kded module could have been a good idea, but 
 it would have required the creation of a kcm to configure the system. 
 Such kcm would have had to tweak Plasma system tray settings behind its 
 back, which could have been a problem to get on the fly changes. It 
 would have at least needed to patch the applet to tell it to stop 
 listening on dbus.

You could just as well manipulate the kded module's config from the systray's 
config 
dialog.

 (admittedly, a separate binary would have required a kcm as well)

Nope, KCM != config option somewhere. And where you write out the config is 
your 
choice.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


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: Container plasma applet

2009-09-28 Thread Riccardo Iaconelli 
On Sunday 27 September 2009 23:58:56 Marco Martin wrote:
 to summarize, here there are 3 problems:
 
 i don't think good pixel alignment could be reached using just svg, no
  matter how good the renderer is (unless we will have someday something as
  crazy as the truetype hinting language, something that i don't see in the
  near future, not even desiderable, probably), oxygen icons are mostly
  redrawn from scratch or at least adapted for different resolutions,
  because they're different beasts and shapes have to be quite different
  (hopefully when we'll have 300+ dpi monitors the problem will solve itself
  :D).

+1

 however, with svg we can have an image that can look good at a certain size
 (the default systray size?) and its multiples, and could be good enough
  (now the battery svg is not that bad, the only reall bad bit is the little
  lighting that signales ac plugged in, but that's fixable).
 if it will still use svg, just one thing is important to do: now resizing
  the battery it gets stretched in funny ways. it should retain its aspect
  ratio and be painted in the largest proportioned rect contained in the
  applet contents rect. should be quite a small patch.

I think that while your analisys is correct, you're a bit too much optimistic, 
because you forgot something. ;-)
To keep a long story short, I think this works perfectly for icons 32x32, but 
for smaller sizes details have to be removed and strokes thikened, so when 
rendering the svgs at its multiples you end up with way too thick borders and 
incorrect icons. :\

 last thing, monocrome systray:
 since it's really simple probably svgs are enough in this case too, for
 plasmoids would be a bit tricky, because they should have to detect if they
 are in the systray and change their svg accordingly.
 for the new systray protocol icons, if they use icon names as opposed to
 pixmaps it is ridicolously easy: just find that name in the plasma theme,
  if not found use kicon as usual, for old icons, well, another reason to
  port it

yup, that'd rock! :-)

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

Re: Review request: Container plasma applet

2009-09-28 Thread Riccardo Iaconelli 
On Sunday 27 September 2009 21:10:44 Marco Martin wrote:
 this depends from the idea of having in the systray having only system and 
 hardware items, with all applications moved in the taskbar and maybe the 
 network ones in some kind of different area...
 otherwise yes, wouldn't look particularly good so yes, it could be
  deferred  until (and if) some more work on that direction

a huge +1

i totally agree that would be a great solution!

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

Re: Ayatana notifications for Plasma

2009-09-28 Thread Roderick B. Greening 
I wonder if it would be worthwhile for Sebastian and Aurelien to get together 
and chat offline. I see some opportunity for clarification in a one-on-one via 
irc, etc. 

I believe we had some great discussions at UDS and Sebastian was awesome at 
helping provide guidance to Aurelien at the time. However, it's possible that 
over the last 6 months we may have gotten a little off track and we have some 
opportunity to move this forward in a way desirable to all parties. Or at 
least, if we cannot make major changes for this release, we can try to 
minimize any confusion through direction from Sebastion, and look towards 
doing this differently via USD Lucid and 10.04 release in 6 months time...

Cheers,

Rod.

 On Monday 28 September 2009 15:03:05 Aurélien Gâteau wrote:
  Sebastian Kügler wrote:
   On Thursday 24 September 2009 09:16:25 Aurélien Gâteau wrote:
   Aaron J. Seigo wrote:
   On September 23, 2009, Aurélien Gâteau wrote:
   Aaron J. Seigo a écrit :
   On September 23, 2009, Marco Martin wrote:
   every other consideration aside, i feel that it would have been
   -far- easier to mantain if the systray patch just consisted in
   notifications disabling and provide a totally separate daemon for
   that kind of notifications
  
   unless i'm misremembering things, this is also what i suggested to
   the people working on this when the Ayatana notifications design
   was first announced.
  
   My first implementation was doing exactly this. But I was told (by a
   Plasma dev) it was not a good idea.
  
   what i'm pretty sure i said (could be wrong, was a # of months ago)
   was that the option in the system tray could be defaulted very easily
   to off and the new style of notifications could run separate from
   it.
  
   That was how it was implemented: I splitted notify-osd into a library
   storing all the logic, and a notify-osd-gtk doing the gtk/cairo
   rendering. I then implemented a KDE version using Plasma. (You were
   not the one telling me it was not a good idea, Sebas did)
  
   Huh? I pointed out in May during UDS already that you just want to hook
   in an applet  that does the notifications the Ayatana way, and default
   the systray notifications to off.
 
  I was referring to this:
 
  http://irclogs.ubuntu.com/2009/05/12/%23kubuntu-devel.txt
 
 Maybe the misunderstanding stems from the concept of a separate binary (I
  mean use an applet). Applets are binaries as well though, so I wasn't
  clear. Sorry. The context there makes it pretty clear that it should've
  been done as a separate applet, IMO.
 
 As to the cleanest solution, adding a separate notification mechanism is a
  kludge only done to be able to test those two on the same system.
  Inevitably, you end up with other kludges to be able to get it in as well
  (choosing the notification system to be used is one such thing). So that's
  kind of expected...
 
  Search for a separate binary ... oh come on
 
   From the very beginning I knew such changes would never be
  upstreamable, that's why I thought creating a separate binary was the
  cleanest solution.
 
 Fair enough. Self-fulfilling prophecies. :)
 
  Regarding implementing it as a separate applet: I don't think it would
  have been a good idea because you would have to either add a dumb icon
  to your panel so that you could run this system, or add an invisible
  applet (not handy for the user to manipulate).
 
 That's what you have the config option for. (it's the same in terms of
  manipulation right now).
 
  Keep in mind that the
  binary is started on demand, so it does not take any memory if you are
  not using it (assuming it would automatically stop itself after a while).
 
 Same goes for applets, dataengines...
 
  The alternative of using a kded module could have been a good idea, but
  it would have required the creation of a kcm to configure the system.
  Such kcm would have had to tweak Plasma system tray settings behind its
  back, which could have been a problem to get on the fly changes. It
  would have at least needed to patch the applet to tell it to stop
  listening on dbus.
 
 You could just as well manipulate the kded module's config from the
  systray's config dialog.
 
  (admittedly, a separate binary would have required a kcm as well)
 
 Nope, KCM != config option somewhere. And where you write out the config is
  your choice.
 


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: Container plasma applet

2009-09-28 Thread Sebastian Kügler 
On Monday 28 September 2009 16:44:09 Riccardo Iaconelli wrote:
  - bad quality of battery.svg
 
 nah, not battery.svgz, i think we can't get much better than that :-) It's 
 oxygen after all! :P

Have you actually opened the file in inkscape and looked at it? Even Nuno told 
me 
repeatedly that it's crap. Can't argue with that.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


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: About PlasMate metadata editing

2009-09-28 Thread Yuen Hoe Lim 

 Hi Diego,

 Actually my chinese given name is 'Yuen Hoe' and not just 'Yuen' :P Think
 it's easier to just call me Jason or moofang?

 Anyway the editor code was already written to include the metadata file as
 a selectable item before I stepped in - but there was a bug in the code that
 caused the metadata file item to fail to display (if you noticed, there used
 to be an invisible/unselectable item under everything else due to this!). So
 including the metadata file wasn't a decision I made - I only fixed the bug,
 and out it came :P

 I agree that the current method of editting metadata is bad, but I think
 that we should nonetheless make it possible to edit the metadata file -
 experienced developers should be able to use plasmate as well. I remember an
 idea floating around to create a customized GUI specifically for editting
 metadata fields, so I was thinking I'd just put katepart in as a stub for
 now until we get down to building that GUI.

 I'll just cc the plasma group and see what the others think about this :)

 
 Jason moofang Lim Yuen Hoe
 http://yuenhoe.co.cc/




 On Mon, Sep 28, 2009 at 8:07 PM, Diego Casella ([Po]lentino) 
 polentino...@gmail.com wrote:

 Hi Yuen,
 I see your last commit about the possibilty to show and edit manually the
 metadata.desktop file.
 In my opinion this is a bad thing, because we don't have to forget that
 our target are beginner developers, so we have to hide all the
 implementation details that are not directly involved on the programming
 side.
 By the way, this is only my opinion; maybe send an email at plasma-devel
 and hear from their opinion =)
 Have a nice day,

 Cheers !!



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

Re: Ayatana notifications for Plasma

2009-09-28 Thread Sebastian Kügler 
On Monday 28 September 2009 17:01:34 Roderick B. Greening wrote:
   I wonder if it would be worthwhile for Sebastian and Aurelien to get
  together  and chat offline. I see some opportunity for clarification in a
  one-on-one via irc, etc.

Not sure, it sounds like you see personal issues between me and Aurelien. I 
don't. 
(And I hope Aurelien doesn't either.) Not that I like the current situation 
with 
patches that won't be accepted because of different design direction, but to me 
there's a fundamental difference between Aurelien as a KDE hacker and Aurelien 
as an 
Ayatana ambassador.

 I believe we had some great discussions at UDS and Sebastian was awesome
  at  helping provide guidance to Aurelien at the time. However, it's
  possible that over the last 6 months we may have gotten a little off track
  and we have some opportunity to move this forward in a way desirable to
  all parties. Or at least, if we cannot make major changes for this
  release, we can try to minimize any confusion through direction from
  Sebastion, and look towards doing this differently via USD Lucid and 10.04
  release in 6 months time...

At UDS, we've discussed doing things in a way that KDE can benefit from work 
being 
done by Canonical. I would have hoped that this way, we get things like 
queueing, 
prioritizing of notifications and improved layout / display into Plasma 
upstream (and 
there's surely room for that). That hasn't happened yet, and I hope it still 
will.

For some points, such as actions on notifications, there doesn't seem  much 
wiggle 
room on either side. We've talked about this over and over, and it's also where 
people get annoyed. Wrong focus, IMO.

-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


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: About PlasMate metadata editing

2009-09-28 Thread Shantanu Tushar Jha 
Also, a short note to Diego, please send/CC all mails to the mailing list
itself so that everybody can share views. This is what mailing lists are
for.
Cheers !

On Mon, Sep 28, 2009 at 8:37 PM, Yuen Hoe Lim yuenho...@gmail.com wrote:

 Hi Diego,

 Actually my chinese given name is 'Yuen Hoe' and not just 'Yuen' :P Think
 it's easier to just call me Jason or moofang?

 Anyway the editor code was already written to include the metadata file as
 a selectable item before I stepped in - but there was a bug in the code that
 caused the metadata file item to fail to display (if you noticed, there used
 to be an invisible/unselectable item under everything else due to this!). So
 including the metadata file wasn't a decision I made - I only fixed the bug,
 and out it came :P

 I agree that the current method of editting metadata is bad, but I think
 that we should nonetheless make it possible to edit the metadata file -
 experienced developers should be able to use plasmate as well. I remember an
 idea floating around to create a customized GUI specifically for editting
 metadata fields, so I was thinking I'd just put katepart in as a stub for
 now until we get down to building that GUI.

 I'll just cc the plasma group and see what the others think about this :)

 
 Jason moofang Lim Yuen Hoe
 http://yuenhoe.co.cc/




 On Mon, Sep 28, 2009 at 8:07 PM, Diego Casella ([Po]lentino) 
 polentino...@gmail.com wrote:

 Hi Yuen,
 I see your last commit about the possibilty to show and edit manually the
 metadata.desktop file.
 In my opinion this is a bad thing, because we don't have to forget that
 our target are beginner developers, so we have to hide all the
 implementation details that are not directly involved on the programming
 side.
 By the way, this is only my opinion; maybe send an email at plasma-devel
 and hear from their opinion =)
 Have a nice day,

 Cheers !!




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




-- 
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Ayatana notifications for Plasma

2009-09-28 Thread Roderick B. Greening 
 On Monday 28 September 2009 17:01:34 Roderick B. Greening wrote:
I wonder if it would be worthwhile for Sebastian and Aurelien to get
   together  and chat offline. I see some opportunity for clarification in
  a one-on-one via irc, etc.
 
 Not sure, it sounds like you see personal issues between me and Aurelien. I
  don't. (And I hope Aurelien doesn't either.) Not that I like the current
  situation with patches that won't be accepted because of different design
  direction, but to me there's a fundamental difference between Aurelien as
  a KDE hacker and Aurelien as an Ayatana ambassador.

God no. I certainly wasn't implying any issues. I think the co-operation is 
awesome. I was just thinking instead of a mailing list discussion, a real time 
chat may be more productive. I apologize if I inadvertently made it sound 
otherwise :)

 
  I believe we had some great discussions at UDS and Sebastian was awesome
   at  helping provide guidance to Aurelien at the time. However, it's
   possible that over the last 6 months we may have gotten a little off
  track and we have some opportunity to move this forward in a way
  desirable to all parties. Or at least, if we cannot make major changes
  for this release, we can try to minimize any confusion through direction
  from Sebastion, and look towards doing this differently via USD Lucid and
  10.04 release in 6 months time...
 
 At UDS, we've discussed doing things in a way that KDE can benefit from
  work being done by Canonical. I would have hoped that this way, we get
  things like queueing, prioritizing of notifications and improved layout /
  display into Plasma upstream (and there's surely room for that). That
  hasn't happened yet, and I hope it still will.

Exactly the sort of discussion I believe we need to have. I'm sure everyone is 
up for that. 

 
 For some points, such as actions on notifications, there doesn't seem  much
  wiggle room on either side. We've talked about this over and over, and
  it's also where people get annoyed. Wrong focus, IMO.
 

I agree. There will be some ways in which we will differ. I see the end game 
for Kubuntu and KDE is to hopefully see this experiment and maybe take some 
ideas to help improve notifications in KDE in general. Obviously some things do 
not fit with KDE from Ayatana, but some others would definitely help if carried 
over to KDE in some fashion.


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: About PlasMate metadata editing

2009-09-28 Thread Aaron J. Seigo 
On September 28, 2009, Yuen Hoe Lim wrote:
  I agree that the current method of editting metadata is bad, but I think
  that we should nonetheless make it possible to edit the metadata file -
  experienced developers should be able to use plasmate as well. I remember
  an idea floating around to create a customized GUI specifically for
  editting metadata fields,

there already is one in plasmate/editors/metadata; it just needs to be used.

  so I was thinking I'd just put katepart in as a
  stub for now until we get down to building that GUI.

yes, sensible.

-- 
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: Review Request: Center tool tips in Plasma

2009-09-28 Thread Aaron Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1428/#review2486
---

Ship it!


:)

- Aaron


On 2009-09-27 13:18:54, Michal Dutkiewicz wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/1428/
 ---
 
 (Updated 2009-09-27 13:18:54)
 
 
 Review request for Plasma and Aaron Seigo.
 
 
 Summary
 ---
 
 This patch aims to provide centered tool tips for Plasma (aligned to edge in 
 some cases looks bad) and ability to set pop ups alignment (by default it 
 uses left alignment for compatibility).
 
 
 Diffs
 -
 
   /trunk/KDE/kdelibs/plasma/applet.h 1028190 
   /trunk/KDE/kdelibs/plasma/applet.cpp 1028190 
   /trunk/KDE/kdelibs/plasma/corona.h 1028190 
   /trunk/KDE/kdelibs/plasma/corona.cpp 1028190 
   /trunk/KDE/kdelibs/plasma/tooltipmanager.cpp 1028190 
 
 Diff: http://reviewboard.kde.org/r/1428/diff
 
 
 Testing
 ---
 
 Tested for vertical and horizontal form factors and for floating applets.
 
 
 Thanks,
 
 Michal
 


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

Re: Review Request: Allows selection of icons using the SHIFT key.

2009-09-28 Thread Shantanu Tushar Jha 
If this might be useful, please review. Thanks :)

On Thu, Sep 24, 2009 at 10:07 PM, Shantanu Tushar Jha
jhahon...@gmail.comwrote:


 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/1709/
 ---

 (Updated 2009-09-24 16:37:05.117590)


 Review request for Plasma.


 Changes
 ---

 When a key is pressed, then instead of repainting whole visible area only
 repaint the icons which were previously selected.


 Summary (updated)
 ---

 If the view is arranged (i.e. m_layoutBroken is false), the icons between
 the previous and the current click are selected linearly. If the view is
 broken, the icons which are in the rectangular region of the previous and
 currently selected icon, are selected. This is because when the view is
 broken, there is no 'linearity' as such.
 A minor change to key functionality - When a key is pressed, the icons
 which were previously selected are repainted.


 This addresses bug 189359.
https://bugs.kde.org/show_bug.cgi?id=189359


 Diffs (updated)
 -

  /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.h 1027710
  /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 1027710

 Diff: http://reviewboard.kde.org/r/1709/diff


 Testing
 ---

 Tested on current trunk build. Works fine.


 Thanks,

 Shantanu




-- 
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review request: Container plasma applet

2009-09-28 Thread Riccardo Iaconelli 
On Monday 28 September 2009 17:06:07 Sebastian Kügler wrote:
 Have you actually opened the file in inkscape and looked at it? Even Nuno
  told me  repeatedly that it's crap. Can't argue with that.
 

Maybe he was talking of something else? Like the rendering in the panel? I 
confirm that's the oxygen battery! (and infact is even pixel perfect at 64x64 
:-) )

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

Re: Review Request: Ported KTimeTracker to KNotification

2009-09-28 Thread Thorsten Staerk 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1653/#review2487
---


I dislike if libraries change, like this change from KSystemTray to 
KNotification or however this is called ...

Here is your patch as I would like to commit:

emTrayIcon( 0 )   
+  : KNotificationItem( 0 ) 
 {  
 setObjectName( Ktimetracker Tray );  
 // it is not convenient if every kpart gets an icon in the systray.
@@ -86,7 +86,7 @@   
 }  

 TrayIcon::TrayIcon()   
-  : KSystemTrayIcon( 0 )   
+  : KNotificationItem( 0 ) 
 // will display nothing at all 
 {  
 setObjectName( Ktimetracker Tray );  
@@ -103,8 +103,7 @@ 
 if ( _taskActiveTimer )
 {  
 _taskActiveTimer-start(1000); 
-setIcon( *(*icons)[_activeIcon] ); 
-show();
+setIconByPixmap( *(*icons)[_activeIcon] ); 
 }  
 kDebug(5970)  Leaving function;
 }  
@@ -115,7 +114,6 @@ 
 if ( _taskActiveTimer )
 {  
 _taskActiveTimer-stop();  
-show();
 }  
 kDebug(5970)  Leaving function;
 }  
@@ -123,14 +121,13 @@   
 void TrayIcon::advanceClock()  
 {  
 _activeIcon = (_activeIcon+1) % 8; 
-setIcon( *(*icons)[_activeIcon]);  
+setIconByPixmap( *(*icons)[_activeIcon]);  
 }  

 void TrayIcon::resetClock()
 {  
 _activeIcon = 0;   
-setIcon( *(*icons)[_activeIcon]);
-show();
+setIconByPixmap( *(*icons)[_activeIcon]);
 }

 void TrayIcon::initToolTip()
@@ -142,14 +139,14 @@
 {
 if ( activeTasks.isEmpty() )
 {
-this-setToolTip( i18n(No active tasks) );
+this-setToolTip( ktimetracker, ktimetracker, i18n(No active 
tasks) );
 return;
 }

 QFontMetrics fm( QToolTip::font() );
 const QString continued = i18n( , ... );
 const int buffer = fm.boundingRect( continued ).width();
-const int desktopWidth = 
KGlobalSettings::desktopGeometry(parentWidget()).width();
+const int desktopWidth = 
KGlobalSettings::desktopGeometry(associatedWidget()).width();
 const int maxWidth = desktopWidth - buffer;

 QString qTip;
@@ -174,7 +171,7 @@
 }
 qTip = s;
 }
-this-setToolTip( qTip );
+this-setToolTip( ktimetracker, ktimetracker, qTip );
 }

 #include tray.moc


- Thorsten


On 2009-09-19 20:16:41, Davide Bettio wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/1653/

Re: Review Request: taskmanager library: Manual Sorting Fix

2009-09-28 Thread Aaron Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1526/
---

(Updated 2009-09-28 20:26:09.228700)


Review request for Plasma, Aaron Seigo and Marco Martin.


Summary
---

this fixes the manual sorting strategy, which is broken atm if the desktop is 
changed.

Since the manual sorting strategy relies on AbstractGroupableItem pointer not 
to change, we cannot remove it from the bookkeeping in case it returns (after a 
desktop change for instance).
I don't know if this is acceptable because this results in the item never being 
removed from the itemList until the groupmanager instance is deleted (lifetime 
of the applet which created the instance).

Another option would be to identify tasks and groups by WId, which is a bit 
more complicated, but if you think it would be better/cleaner, i could supply a 
patch.


This addresses bug 200255.
https://bugs.kde.org/show_bug.cgi?id=200255


Diffs
-

  /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1018615 

Diff: http://reviewboard.kde.org/r/1526/diff


Testing
---

Tried it, works.


Thanks,

Christian

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

Re: Review Request: taskmanager library: Manual Sorting Fix

2009-09-28 Thread Aaron Seigo 


 On 2009-09-04 20:16:52, Aaron Seigo wrote:
  this results in a leak in that every window ever created will have an 
  item that stays forever, no? shouldn't it only keep track of winIds that 
  still exist, and do so in the manual grouping strategy?
 
 Christian Mollekopf wrote:
 Yes this would result in a leak (as long the groupmanager instance 
 exists).
 I just noticed that also manual grouping is broken since it also relies 
 on the pointers to remain.
 
 I will work on a new patch where manual grouping and sorting keep track 
 of the windows/groups by winIds.

any progress on this?


- Aaron


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1526/#review2247
---


On 2009-09-28 20:26:09, Christian Mollekopf wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/1526/
 ---
 
 (Updated 2009-09-28 20:26:09)
 
 
 Review request for Plasma, Aaron Seigo and Marco Martin.
 
 
 Summary
 ---
 
 this fixes the manual sorting strategy, which is broken atm if the desktop is 
 changed.
 
 Since the manual sorting strategy relies on AbstractGroupableItem pointer not 
 to change, we cannot remove it from the bookkeeping in case it returns (after 
 a desktop change for instance).
 I don't know if this is acceptable because this results in the item never 
 being removed from the itemList until the groupmanager instance is deleted 
 (lifetime of the applet which created the instance).
 
 Another option would be to identify tasks and groups by WId, which is a bit 
 more complicated, but if you think it would be better/cleaner, i could supply 
 a patch.
 
 
 This addresses bug 200255.
 https://bugs.kde.org/show_bug.cgi?id=200255
 
 
 Diffs
 -
 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1018615 
 
 Diff: http://reviewboard.kde.org/r/1526/diff
 
 
 Testing
 ---
 
 Tried it, works.
 
 
 Thanks,
 
 Christian
 


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

Re: Review Request: Ported KTimeTracker to KNotification

2009-09-28 Thread Aaron Seigo 


 On 2009-09-28 19:13:17, Thorsten Staerk wrote:
  I dislike if libraries change, like this change from KSystemTray to 
  KNotification or however this is called ...
  
  Here is your patch as I would like to commit:
  
  emTrayIcon( 0 )   
  +  : KNotificationItem( 0 ) 
  
   {  
  
   setObjectName( Ktimetracker Tray );  
  
   // it is not convenient if every kpart gets an icon in the systray.
  
  @@ -86,7 +86,7 @@   
  
   }  
  
  
  
   TrayIcon::TrayIcon()   
  
  -  : KSystemTrayIcon( 0 )   
  
  +  : KNotificationItem( 0 ) 
  
   // will display nothing at all 
  
   {  
  
   setObjectName( Ktimetracker Tray );  
  
  @@ -103,8 +103,7 @@ 
  
   if ( _taskActiveTimer )
  
   {  
  
   _taskActiveTimer-start(1000); 
  
  -setIcon( *(*icons)[_activeIcon] ); 
  
  -show();
  
  +setIconByPixmap( *(*icons)[_activeIcon] ); 
  
   }  
  
   kDebug(5970)  Leaving function;
  
   }  
  
  @@ -115,7 +114,6 @@ 
  
   if ( _taskActiveTimer )
  
   {  
  
   _taskActiveTimer-stop();  
  
  -show();
  
   }  
  
   kDebug(5970)  Leaving function;
  
   }  
  
  @@ -123,14 +121,13 @@   
  
   void TrayIcon::advanceClock()  
  
   {  
  
   _activeIcon = (_activeIcon+1) % 8; 
  
  -setIcon( *(*icons)[_activeIcon]);  
  
  +setIconByPixmap( *(*icons)[_activeIcon]);  
  
   }  
  
  
  
   void TrayIcon::resetClock()
  
   {  
  
   _activeIcon = 0;   
  
  -setIcon( *(*icons)[_activeIcon]);
  -show();
  +setIconByPixmap( *(*icons)[_activeIcon]);
   }
  
   void TrayIcon::initToolTip()
  @@ -142,14 +139,14 @@
   {
   if ( activeTasks.isEmpty() )
   {
  -this-setToolTip( i18n(No active tasks) );
  +this-setToolTip( ktimetracker, ktimetracker, i18n(No active 
  tasks) );
   return;
   }
  
   QFontMetrics fm( QToolTip::font() );
   const QString continued = i18n( , ... );
   const int buffer = fm.boundingRect( continued ).width();
  -const int desktopWidth = 
  KGlobalSettings::desktopGeometry(parentWidget()).width();
  +const int desktopWidth = 
  KGlobalSettings::desktopGeometry(associatedWidget()).width();
   const int maxWidth = desktopWidth - buffer;
  
   QString qTip;
  @@ -174,7 +171,7 @@
   }
   qTip = s;
   }
  -this-setToolTip( qTip );
  +this-setToolTip( ktimetracker, ktimetracker, qTip );
   }
  
   #include tray.moc
 

I dislike if libraries change, like this change from KSystemTray to 
KNotification or however this is called

Review Request: Full Konqueror History Runner

2009-09-28 Thread Jon de Andres 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1719/
---

Review request for Plasma.


Summary
---

The browserhistory runner in kdeplasma-addons only searchs in the typed history 
in konqueror, stored in KDEDIR/share/conf/konq_history. Konqueror uses its own 
lib to use the full history with title and extra info. This runner do use the 
KonqHistoryProvider to search in this history, stored in 
KDEDIR/share/apps/konqueror/konq_history.

Probably this runner is used with the rekonq browser but we think that it could 
be useful for KDE users so it searches in the title and url as we can see in 
other browsers, firefox, chromium, etc...

In kdebase/apps/lib/konq lives the lib used by konqueror and this runner, in 
this folder there are some headers, konq_history*.h that are needed to be 
installed. So the CMakeLists.txt should be fixed.


Diffs
-

  /trunk/playground/base/plasma/runners/CMakeLists.txt 1029048 
  /trunk/playground/base/plasma/runners/konqhistory/CMakeLists.txt PRE-CREATION 
  /trunk/playground/base/plasma/runners/konqhistory/konqhistory.h PRE-CREATION 
  /trunk/playground/base/plasma/runners/konqhistory/konqhistory.cpp 
PRE-CREATION 
  
/trunk/playground/base/plasma/runners/konqhistory/plasma-konqhistoryrunner.desktop
 PRE-CREATION 

Diff: http://reviewboard.kde.org/r/1719/diff


Testing
---

I've noticed that krunner crashes sometimes, however i don't know if it's 
really a problem with this runner.


Thanks,

Jon

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

Re: 'Next wallpaper' functionality for image plugin?

2009-09-28 Thread Chani 
On September 26, 2009 11:03:37 Aaron J. Seigo wrote:
 On September 26, 2009, Yuen Hoe Lim wrote:
  the wallpaper plugin doesn't have control over the right-click-desktop
  context menu, and it will be inappropriate to hack the functionality
  into the core desktop code.
 
 that's correct; but we already have a way to add context menu items from
 applets and what not. the containment is in complete control here, and the
 containment is also what knows about the wallpaper. so it could ask the
 wallpaper if it has anything to add actions to add to the context menu.
  should be easy to add some mechanism to the Wallpaper plugin API for this.
 

heck yeah. add a contextualActions function and have the default 
implementation of Containment::contextualActions call it if wallpaper exists.

con: custom desktop containments might break that unintentionally
pro: custom desktop containments can intentionally stop it if they want to.

if we don't think the containment plugin should be allowed to block wallpaper 
actions then just add a separate function in Containment, 
wallpaperContextualActions, and have the contextmenu plugin draw from that 
too. or if ContainmentActions plugins can access the containment's wallpaper 
object directly we don't need a function to forward the data. :)


-- 
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

Review Request: contextmenu on popupapplets

2009-09-28 Thread Chani 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1737/
---

Review request for Plasma.


Summary
---

when I rightclick a popupapplet, I expect to get a contextmenu, but it doesn't 
happen because the event reaches Plasma::Dialog and stops.
with this code, popupapplet grabs the event and makes sure it gets through. :) 
since everything is handled by Containment (there is no 
Applet::contextMenuEvent) I bypass the usual checks (they'd just break things 
anyways since it's not a qgraphicssceneevent) with a new function in 
Containment.
I'm wondreing if I should make that new function protected or private, though, 
and make popupapplet a friend.

there are still some big dead areas on kickoff and device notifier that just 
eat clicks; maybe I'll fix that too at some point.


Diffs
-

  /trunk/KDE/kdelibs/plasma/containment.h 1027322 
  /trunk/KDE/kdelibs/plasma/containment.cpp 1027322 
  /trunk/KDE/kdelibs/plasma/popupapplet.cpp 1027322 

Diff: http://reviewboard.kde.org/r/1737/diff


Testing
---

works on panel and desktop.


Thanks,

Chani

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

Re: About PlasMate metadata editing

2009-09-28 Thread Yuen Hoe Lim 
 there already is one in plasmate/editors/metadata; it just needs to be
 used.


Ok! Will look into it.

By the way while we're on the topic, I find the current way the editor works
(click on tree widget item, tree *disappears* to be replaced with
katepart/editor) rather unintuitive and weird. I remember Michael Rudolph
did up some simple mockups before:

http://skitch.com/michaelrudolph/ba3j9/plasmate-editor2
http://skitch.com/michaelrudolph/ba3cg/plasmate-editor-timeline

which had the tree and the editor *side by side* instead, and I think this
makes alot more sense. Should I go ahead and see if I could separate the
tree from the editor and probably make it into another dockwidget or
something? Or does someone have a better idea of how this should work? :)


Jason moofang Lim Yuen Hoe
http://yuenhoe.co.cc/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: About PlasMate metadata editing

2009-09-28 Thread Aaron J. Seigo 
On September 28, 2009, Yuen Hoe Lim wrote:
 which had the tree and the editor *side by side* instead, and I think this

that was the original idea, yes.

-- 
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: Review Request: contextmenu on popupapplets

2009-09-28 Thread Aaron Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1737/#review2494
---


yes, please make this private API, otherwise, it's good to go from my end...

- Aaron


On 2009-09-29 00:42:23, Chani wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/1737/
 ---
 
 (Updated 2009-09-29 00:42:23)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 when I rightclick a popupapplet, I expect to get a contextmenu, but it 
 doesn't happen because the event reaches Plasma::Dialog and stops.
 with this code, popupapplet grabs the event and makes sure it gets through. 
 :) since everything is handled by Containment (there is no 
 Applet::contextMenuEvent) I bypass the usual checks (they'd just break things 
 anyways since it's not a qgraphicssceneevent) with a new function in 
 Containment.
 I'm wondreing if I should make that new function protected or private, 
 though, and make popupapplet a friend.
 
 there are still some big dead areas on kickoff and device notifier that just 
 eat clicks; maybe I'll fix that too at some point.
 
 
 Diffs
 -
 
   /trunk/KDE/kdelibs/plasma/containment.h 1027322 
   /trunk/KDE/kdelibs/plasma/containment.cpp 1027322 
   /trunk/KDE/kdelibs/plasma/popupapplet.cpp 1027322 
 
 Diff: http://reviewboard.kde.org/r/1737/diff
 
 
 Testing
 ---
 
 works on panel and desktop.
 
 
 Thanks,
 
 Chani
 


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

Re: Review Request: Ported KTimeTracker to KNotification

2009-09-28 Thread Thorsten Staerk 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1653/#review2495
---

Ship it!


I committed the change, see 
http://websvn.kde.org/?view=revisionrevision=1029142. Where can I set this to 
completed?

- Thorsten


On 2009-09-19 20:16:41, Davide Bettio wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/1653/
 ---
 
 (Updated 2009-09-19 20:16:41)
 
 
 Review request for KDE PIM and Plasma.
 
 
 Summary
 ---
 
 KTimeTracker has been ported to KNotificationItem but I still have few issues 
 that I've corrected with #if 0.
 It's not really clear to me how the notification works when KTimeTracker is a 
 KPart.
 Anyway please don't use XPM pixmaps, use icons.
 
 
 Diffs
 -
 
   /trunk/KDE/kdepim/ktimetracker/ktimetrackerpart.cpp 1024122 
   /trunk/KDE/kdepim/ktimetracker/tray.h 1024122 
   /trunk/KDE/kdepim/ktimetracker/tray.cpp 1024122 
 
 Diff: http://reviewboard.kde.org/r/1653/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Davide
 


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