Moving spellcheck runner to kdeplasma-addons

[Ryan P. Bitanga]

Does anyone have any objections to moving the spellcheck runner into
kdeplasma-addons? It hasn't been touched for a while and I don't think
it needs further development.

I only read Aaron's mail asking if we could move it to kdereview
recently (yes I know that was sent last March but the huge traffic of
the bug report e-mails buried it deep within my inbox and then my
archive.) It should've been part of KDE4.1 but I guess now it'll have
to wait for 4.2.

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

Re: Review Request: Override showOnlyCurrentDesktop for demandsAttention

[guitarist198]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/131/
---

(Updated 2008-08-18 18:33:42.206447)


Review request for Plasma.


Summary
---

This patch applies to the tasks.cpp and tasks.h files within the Tasks plasma 
applet.

It is in response to Bug 160613.  The patch allows a windowTaskItem that 
demands attention to override the showOnlyCurrentDesktop setting.  The user can 
then see that an application on a different desktop requires attention, click 
the window and be brought to the desktop.  When the window no longer requires 
attention it is no longer shown on other desktops.  This modification is 
relatively simple and only changes a few lines.  This is my first KDE patch and 
I would greatly appreciate the review.  I was unsure of the best way to bring 
forward this patch so I have submitted an attachment to the bugreport and sent 
in a request to the panel-devel mailinglist (Message is waiting on admin 
approval).  I do not mean to be too intrusive. 

I just recently discovered svn diff so the diff file found here is the most 
recent and most accurate compared to those found on the bugreport and mailing 
list. 

Thank you again. 


This addresses bug 160613.


Diffs
-

  /trunk/KDE/kdebase/workspace/plasma/applets/tasks/tasks.h
  /trunk/KDE/kdebase/workspace/plasma/applets/tasks/tasks.cpp

Diff: http://reviewboard.vidsolbach.de/r/131/diff


Testing
---


Thanks,

distortedlogic

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

Re: Review Request: Add missing "All to Desktop" submenu title to taskrmbmenu makeDesktopsMenu() function.

[guitarist198]

> On 2008-08-13 07:04:36, Alex Merry wrote:
> > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskrmbmenu.cpp, line 264
> > 
> >
> > There should be an & before the word "Desktop", as in the 
> > makeDesktopsMenu(TaskPtr) method above.
> > 
> > It might be better to follow that method in setting the title as well, 
> > by using setTitle(), rather than a constructor argument.

I have updated the patch to include the suggestions that Alex Merry made.  I am 
currently unsure about how much time I will have for hacking in the immediate 
future so I am probably going to hold off on obtaining an svn account.  If 
someone is available to commit my two verified patches, I would greatly 
appreciate it.  I will be updating the other patch as well to reduce the work 
for whoever choses to commit.


- distortedlogic


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/133/#review112
---


On 2008-08-18 18:13:34, distortedlogic wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.vidsolbach.de/r/133/
> ---
> 
> (Updated 2008-08-18 18:13:34)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> If one uses the taskrmbmenu with the TaskRMBMenu(const TaskList&, bool 
> showAll = true, QWidget *parent = 0) constructor, the "All to Desktop" 
> submenu never has its title set.  This patch makes the submenu call the 
> constructor with its title.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskrmbmenu.cpp
> 
> Diff: http://reviewboard.vidsolbach.de/r/133/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> distortedlogic
> 
>

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

Re: Review Request: Add missing "All to Desktop" submenu title to taskrmbmenu makeDesktopsMenu() function.

[guitarist198]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/133/
---

(Updated 2008-08-18 18:13:34.778758)


Review request for Plasma.


Summary
---

If one uses the taskrmbmenu with the TaskRMBMenu(const TaskList&, bool showAll 
= true, QWidget *parent = 0) constructor, the "All to Desktop" submenu never 
has its title set.  This patch makes the submenu call the constructor with its 
title.


Diffs
-

  /trunk/KDE/kdebase/workspace/libs/taskmanager/taskrmbmenu.cpp

Diff: http://reviewboard.vidsolbach.de/r/133/diff


Testing
---


Thanks,

distortedlogic

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

Re: Smarter desktop applet placement

[Ambroz Bizjak]

I have further improved my layout code. Now it can use any of the four
corners as the "static corner" instead of only top-left. This means if the
screen shrinks for example, it is not only possible to make the right
screen border push applets left, but also the left border push applets
right. And new applets are now placed in the specified corner, not always
top-left. Adding and removing applets is also handled better now.
Also, the state of the layout is now properly saved on shutdown and
restored on startup.

Attached is patch for 4.1 and trunk.

plasma-placement-layout9-kde4.1.patch.bz2
Description: Binary data


plasma-placement-layout9.patch.bz2
Description: Binary data
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

System-wide Activities

[Hari krishna Anandhan]

Hello all,

I am a newbie here ( though long-time lurker). This is my first
journey to make myself useful to KDE. I will start with a *dream* and
then the implementation (Hope it doesn't clash with plasma's vision;
or better if it is complementary to it, it would be great! )

To start with, please ignore what is called as plasma activity in
current KDE version and read this ;) I know, it clashes with the
current name of activity in plasma, but I couldn't find another good
term that conveys the exact meaning… If needed we can rename it
later...

Now, "KDreams of system-wide activities" …

Term explanation:
Activities are a "more casual" term for projects. Imagine a case where
projects / activities are handled at system level and applies to both
plasma and KDE applications equally. Now that plasma and Kwin (virtual
desktop) interaction is planned, this could be achieved by associating
an activity with a desktop, and storing that information in a shared
space.

Vision:
When I create a new activity, applications automatically prepare
themselves for the new  activity. Dolphin creates a new folder for
storing activity resource files. Kmail creates a mail folder to store
mails corresponding to the activity. Korganiser creates a tag that can
be assigned to specific contacts to associate them with the activity.

And, when I switch to a particular activity, everything changes as
well. Plasma widgets filter content appropriately.  Applications focus
their context exclusively on the activity-related items, including
changing the open/save dialog to default to the folder which
corresponds to the activity resources (So that needed files are always
just a click away!)

Now, suppose I have tons of files for the current activity and I
couldn't find the file needed. I just set the global filter as "last
90 days". Every app filters their content to show only those items
that fall in that date range. Dolphins only shows files modified
within last 90 days. Kmail filters mails accordingly, etc

Life is cool and world will be a better place ;)

Implementation:
Now, back to reality ! Bringing context-awareness to KDE !!

I am currently working on a "user context" framework (I badly need a
cool codename. Any ideas? ), which supports the different contexts
that smart applications might need to be aware of, namely
- Activities
- Locations
- User modes
- Global search filter
- Sensors (if needed)

First things first, why a new framework?
- Activities - for context to should be shared between apps and widgets
- Location - as a wrapper for geoClue
- User modes - Though IM presence can quality already, this adds a
semantic dimension to it
- Global search filter - for cases where "search with keywords" is not enough
- Sensors - for any future or device-dependant contexts

It would also serve as a single point of operation for all
applications that need context-awareness, without needing to
understand all the underlying mechanisms ...
Hope it makes sense. So, lets get moving ;)

For starters, I would like to start the implementation with
"system-wide activities" to nail down the architecture of the
framework first , as I find my way around KDE!!! (remember I am new to
KDE..!)

Before I start, I would like to know whether such a framework would be
useful and fits with the overall vision of plasma and KDE. And,
further inputs are always welcome and needed ;)

Regards,
Hari krishna Anandhan
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Quota warning dialogue

[Jan Kara]

  Hi,

On Mon 18-08-08 06:27:37, Aaron J. Seigo wrote:
> hi Jan ..
> 
> sorry for the late reply .. i'm sitting in LHR airport as i write this ...
> 
> On Wednesday 13 August 2008, Jan Kara wrote:
> > interface = "com.system.quota.warning",
> 
> unless you own the system.com domain name ;) this would be incorrect. perhaps 
> org.linux? or perhaps even better would be to merge this into HAL (or its new 
> replacement?)
  Oh, OK. Thanks for pointing that out. This is my first use of DBUS as a
programmer :). I wrote that part using some howto and it wasn't clear to me
how one should choose these names so I just picked some which looked
sensible :).
  About merging to HAL: I had the impression (and the name HAL supports it
;) that HAL takes care about hardware and notifications connected with it.
Also quota reports information through a different netlink protocol than
standard driver signals. So what I was originally thinking about it, I've
decided that HAL isn't the right place. OTOH I don't have a strong opinion
on this so if you really think merging to HAL is the right way, we can do
it.
 
> i think this signal should ultimately get routed through KNotify which would 
> result in plasma showing these warnings for free... how to get it mated with 
> KNotify would be the question, and i think the answer would be a kded module.
  OK, is there someone who'd like to write the module?

Thanks for the ideas
Honza
-- 
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: System tray rewrite ready for review

[Jason Stubbs]

Replying to myself...

Jason Stubbs wrote:
> Sebastian Kügler wrote:
>> Positioning and background seem to be messed up here. See the screenshot.
> 
> I've reproduced the positioning issue (it depends on the theme) so will 
> work on a fix for that,

There's actually two issues. I introduced a bug when rewriting some code 
to make it easier to read (now fixed) and a corner case when the size of 
two rows lies between the size of the content area with and without the 
background. Will continue to work on the latter.

> but can't reproduce the background issue. Does 
> the background work correctly in any situations at all?

I noticed after changing VTs that klipper had a white background. After 
it got a repaint, the background would go back to normal. I can't 
explain this behaviour, but directly setting klipper's background 
(rather than the window it is parented to) fixed that issue here. Does 
it fix it for you too? If so, I'll update the patch for the current 
system tray.

>> Also, when I removed the old systray, and put the new one into its place,
>> the icons wouldn't show up.

>> restarting plasma made it show up in the top left corner, logging out and
>> in again gave me the screenshot results.

Nothing further news on these two at this stage other than I can't see 
anything that might be responsible in the code...

--
Jason Stubbs

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

Re: System tray rewrite ready for review

[Sebastian Kügler]

On Monday 18 August 2008 14:02:15 Jason Stubbs wrote:
> Sebastian Kügler wrote:
> > On Sunday 17 August 2008 19:53:33 Jason Stubbs wrote:
> >> I won't be around much over the next week as I'm moving, but I should be
> >> back to my regular "squeeze in an hour or two each day" by next weekend.
>
> It seems I'll continue to squeeze in an hour or two while preparing to
> move too. ;)

heh, sorry :>

> > Positioning and background seem to be messed up here. See the screenshot.
>
> I've reproduced the positioning issue (it depends on the theme) so will
> work on a fix for that, but can't reproduce the background issue. Does
> the background work correctly in any situations at all?

Right now, the background looks OK (i.e. black). I'll attach another 
screenshot. Positioning is indeed the most important glitch right now. Maybe 
the rest will shake itself out quickly ... :)

> > Also, when I removed the old systray, and put the new one into its place,
> > the icons wouldn't show up.
>
> I can't reproduce this either. When you say "wouldn't show up", do you
> mean they were taking space but not appearing (aka the qt4.4.1 issue) or
> was the tray simply empty? There should be a fair amount of debug output
> about what's happening internally. How does that look?
>
> Hmm.. Widgets not correctly receiving paint events would explain both of
> the above issues. Can you think of anything you have locally that might
> prevent paint events from being delivered?

Not really, but I'd blame my limited imagination for that, rather than 
knowledge of how X11 works.

> > restarting plasma made it show up in the top left corner, logging out and
>  > in again gave me the screenshot results.
>
> Does "it" refer to the tray as a whole? If the icons were sitting on top
> of each other in the top left, it's a Qt issue that I have yet to even
> look at let alone understand. When discarding icons, Qt reparents them
> to the root window before unmapping them. It seems that the unmapping
> sometimes fails.

it might be that Qt issue. It doesn't seem to be pressing since it works OK 
right now. (And I won't have enough time for more thorough reports until 
somewhen mid next week (not moving, but preps for various travelling 
arrangements ..., synchs nicely with you moving :>).

> If the icons were in the top left but laid out correctly, something
> really strange is going on (which I can't reproduce) but I'll scour the
> relevant code for possible race conditions or what not...

All on top of each other (at least I saw only one icon, klipper's).

> > The hide icons option is very useful (and mandatory for people like
> > aseigo, after seeing his systray :>).
>
> That's mostly Sebastian Sauer's work - I just "ported" it. There is one
> thing that's new though. If you add a second system tray, any icons
> hidden in the first will appear in it. The interface is not really
> intuitive with regard to this feature, but the feature is there. :)

Well, both of you are on my hero list :-)
-- 
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: Quota warning dialogue

[Sebastian Kügler]

On Monday 18 August 2008 14:27:37 Aaron J. Seigo wrote:
> hi Jan ..
>
> sorry for the late reply .. i'm sitting in LHR airport as i write this ...
>
> On Wednesday 13 August 2008, Jan Kara wrote:
> > interface = "com.system.quota.warning",
>
> unless you own the system.com domain name ;) this would be incorrect.
> perhaps org.linux? or perhaps even better would be to merge this into HAL
> (or its new replacement?)
>
> i think this signal should ultimately get routed through KNotify which
> would result in plasma showing these warnings for free... how to get it
> mated with KNotify would be the question, and i think the answer would be a
> kded module.

Wasn't someone working on a diskfree kded module? This would fit in there 
perfectly...
-- 
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: System tray rewrite ready for review + portability?

[Aaron J. Seigo]

On Monday 18 August 2008, Richard Moore wrote:
> On 8/18/08, Gerhard Gappmeier <[EMAIL PROTECTED]> wrote:
> > independent from your changes I see a problem with the X11 includes.
> > KDE4 should run on any OS including Windows and this includes break
> > portability.
>
> This is probably destined to be part of the workspace/plasma rather
> than plasma libs, so there is no requirement to be portable to non-X11
> platforms.

correct; i expect there to eventually be a set of widgets specifically for 
windows (as well as for mac and unix) ... 

in any case, what you really want to do in this case is create a class for 
system tray icons on windows in the new systray widget that gets built if on 
windows. but that's really up to the windows team; most of us have no access 
to windows development systems at all..

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



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: System tray rewrite ready for review + portability?

[Jason Stubbs]

Gerhard Gappmeier wrote:
> Hi Jason,
> 
> independent from your changes I see a problem with the X11 includes.
> KDE4 should run on any OS including Windows and this includes break
> portability.
> 
> While there is no problem of making OS dependent plasmoids in general
> I think a basic one like the systray should run everywhere.
> 
> Are there any rules in plasma what should be portable and what not?

Regardless of rules, I believe that things should be portable whenever 
possible. With the rewrite, the only X11 specific code is that which 
implements the FDO system tray spec[1] and is contained wholly within 
core/fdo. It's actually a step forward with regard to portability when 
compared to the current system tray. :)

If somebody wants to add a new protocol implementation that implements 
the (undocumented!) windows spec, the rest of the applet will work just 
fine.

[1] 
http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html

--
Jason Stubbs

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

Re: System tray rewrite ready for review + portability?

[Richard Moore]

On 8/18/08, Gerhard Gappmeier <[EMAIL PROTECTED]> wrote:
> independent from your changes I see a problem with the X11 includes.
> KDE4 should run on any OS including Windows and this includes break
> portability.

This is probably destined to be part of the workspace/plasma rather
than plasma libs, so there is no requirement to be portable to non-X11
platforms.

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

Re: Quota warning dialogue

[Aaron J. Seigo]

hi Jan ..

sorry for the late reply .. i'm sitting in LHR airport as i write this ...

On Wednesday 13 August 2008, Jan Kara wrote:
> interface = "com.system.quota.warning",

unless you own the system.com domain name ;) this would be incorrect. perhaps 
org.linux? or perhaps even better would be to merge this into HAL (or its new 
replacement?)

i think this signal should ultimately get routed through KNotify which would 
result in plasma showing these warnings for free... how to get it mated with 
KNotify would be the question, and i think the answer would be a kded module.

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



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: System tray rewrite ready for review + portability?

[Gerhard Gappmeier]

Hi Jason,

independent from your changes I see a problem with the X11 includes.
KDE4 should run on any OS including Windows and this includes break
portability.

While there is no problem of making OS dependent plasmoids in general
I think a basic one like the systray should run everywhere.

Are there any rules in plasma what should be portable and what not?

regards,
Gerhard Gappmeier

Jason Stubbs schrieb:
> Hey all,
>
> I'm fairly happy with the state of the rewrite and so am requesting that 
> it be reviewed for moving into trunk/kdebase. There's not much that it 
> doesn't fix and not much work left to do, but no show stoppers as far as 
> I know.
>
> There aren't very many comments, but I believe most of the code should 
> speak for itself. If there's anything that isn't clear enough, please 
> let me know and I'll refactor/comment as appropriate.
>
> I won't be around much over the next week as I'm moving, but I should be 
> back to my regular "squeeze in an hour or two each day" by next weekend.
>
> Ok, I'll keep it short and sweet.
>
> --
> Jason Stubbs
> ___
> 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: System tray rewrite ready for review

[Jason Stubbs]

Sebastian Kügler wrote:
> On Sunday 17 August 2008 19:53:33 Jason Stubbs wrote:
>> I won't be around much over the next week as I'm moving, but I should be
>> back to my regular "squeeze in an hour or two each day" by next weekend.

It seems I'll continue to squeeze in an hour or two while preparing to 
move too. ;)

> Positioning and background seem to be messed up here. See the screenshot.

I've reproduced the positioning issue (it depends on the theme) so will 
work on a fix for that, but can't reproduce the background issue. Does 
the background work correctly in any situations at all?

> Also, when I removed the old systray, and put the new one into its place,
 > the icons wouldn't show up.

I can't reproduce this either. When you say "wouldn't show up", do you 
mean they were taking space but not appearing (aka the qt4.4.1 issue) or 
was the tray simply empty? There should be a fair amount of debug output 
about what's happening internally. How does that look?

Hmm.. Widgets not correctly receiving paint events would explain both of 
the above issues. Can you think of anything you have locally that might 
prevent paint events from being delivered?

> restarting plasma made it show up in the top left corner, logging out and
 > in again gave me the screenshot results.

Does "it" refer to the tray as a whole? If the icons were sitting on top 
of each other in the top left, it's a Qt issue that I have yet to even 
look at let alone understand. When discarding icons, Qt reparents them 
to the root window before unmapping them. It seems that the unmapping 
sometimes fails.

If the icons were in the top left but laid out correctly, something 
really strange is going on (which I can't reproduce) but I'll scour the 
relevant code for possible race conditions or what not...

> The hide icons option is very useful (and mandatory for people like aseigo, 
> after seeing his systray :>).

That's mostly Sebastian Sauer's work - I just "ported" it. There is one 
thing that's new though. If you add a second system tray, any icons 
hidden in the first will appear in it. The interface is not really 
intuitive with regard to this feature, but the feature is there. :)

--
Jason Stubbs

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

Re: System tray rewrite ready for review

[Sebastian Kügler]

On Sunday 17 August 2008 19:53:33 Jason Stubbs wrote:
> I'm fairly happy with the state of the rewrite and so am requesting that
> it be reviewed for moving into trunk/kdebase. There's not much that it
> doesn't fix and not much work left to do, but no show stoppers as far as
> I know.
>
> There aren't very many comments, but I believe most of the code should
> speak for itself. If there's anything that isn't clear enough, please
> let me know and I'll refactor/comment as appropriate.
>
> I won't be around much over the next week as I'm moving, but I should be
> back to my regular "squeeze in an hour or two each day" by next weekend.
>
> Ok, I'll keep it short and sweet.

Positioning and background seem to be messed up here. See the screenshot. 
Also, when I removed the old systray, and put the new one into its place, the 
icons wouldn't show up. restarting plasma made it show up in the top left 
corner, logging out and in again gave me the screenshot results.

The hide icons option is very useful (and mandatory for people like aseigo, 
after seeing his systray :>).
-- 
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