Re: removing dependencies from kactivitymanagerd

[Kevin Ottens]

On Tuesday 04 October 2011 18:29:33 Ivan Cukic wrote:
> Do we even need KDBusService? Just a check of
> QDBusConnectionInterface::isServiceRegistered can be used for this.

Well, you need to add the fact that you also have to verify the connection to
the bus to trigger it if necessary, register the proper service name, and also
make the various cases of error handling... then the resulting code will be
pretty much what a one liner like "KDBusService
service(KDBusService::Unique);" does.

Regards.
--
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Simplify pixmap handling for XEmbed-based systray

[Aaron J. Seigo]

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


thanks for the patch ... :)

the coding style should follow the kdelibs style, but that's a minor thing. 
mostly just the one question regarding something noted in a code comment:


plasma/generic/applets/systemtray/protocols/fdo/x11embedcontainer.cpp


when you say that the alpha channel is not preserved .. does this mean that 
icons with translucent areas (e.g. rounded icons) will end up with opaque 
backgrounds?


- Aaron J. Seigo


On Oct. 4, 2011, 3:31 p.m., Luboš Luňák wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102770/
> ---
> 
> (Updated Oct. 4, 2011, 3:31 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patches changes systemtray handling of XEmbed-based clients from various 
> Xlib code to plain Qt code. The Xlib code was presumably introduced to handle 
> non-native Qt graphics systems, but that can be somewhat more cleanly handled 
> by forcing Qt to create XPixmap-based QPixmap.
> 
> 
> Diffs
> -
> 
>   plasma/generic/applets/systemtray/protocols/fdo/x11embedcontainer.h fa47b9b 
>   plasma/generic/applets/systemtray/protocols/fdo/x11embedcontainer.cpp 
> 0aa5d96 
> 
> Diff: http://git.reviewboard.kde.org/r/102770/diff/diff
> 
> 
> Testing
> ---
> 
> Tested with plasma-desktop and licq, with and without compositing enabled, 
> seems to work the same way like without the patch.
> 
> 
> Thanks,
> 
> Luboš Luňák
> 
>

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

Re: Review Request: XTest is an optional dependency, so skip a test that requires it if it is not found

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On Oct. 4, 2011, 6:52 p.m., Ralf Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102771/
> ---
> 
> (Updated Oct. 4, 2011, 6:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Running cmake without having libxtest fails as some tests that are always 
> compiled use it unconditionally. This fixes these tests to be only compiled 
> if libxtest is found, as it is marked as optional dependency.
> 
> 
> Diffs
> -
> 
>   kcontrol/keyboard/tests/CMakeLists.txt 419d150 
> 
> Diff: http://git.reviewboard.kde.org/r/102771/diff/diff
> 
> 
> Testing
> ---
> 
> kde-workspace compiles now.
> 
> 
> Thanks,
> 
> Ralf Jung
> 
>

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

Re: Review Request: fix the problem that the text below the selected wallpaper is barely readable if the window is inactive

[Aaron J. Seigo]

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

Ship it!


small fix in code style required, otherwise, good to go.


plasma/generic/wallpapers/image/backgrounddelegate.cpp


please adhere to the style guidelines. this should be:

if (..) {
 ...
} else if (..) {

}

yes, even one liners get braces :)


- Aaron J. Seigo


On Oct. 4, 2011, 8:48 p.m., Ralf Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102772/
> ---
> 
> (Updated Oct. 4, 2011, 8:48 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch fixes the Plasma incarnation of 
> https://bugs.kde.org/show_bug.cgi?id=253022 : The custom item delegate in the 
> wallpaper selection uses incorrect colours if the window is inactive or 
> disabled.
> 
> 
> Diffs
> -
> 
>   plasma/generic/wallpapers/image/backgrounddelegate.cpp 8354d99 
> 
> Diff: http://git.reviewboard.kde.org/r/102772/diff/diff
> 
> 
> Testing
> ---
> 
> Compiled and checked whether the colours are fixed.
> 
> 
> Thanks,
> 
> Ralf Jung
> 
>

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

Re: Review Request: W7 Tab thumbnails in dolphin.

[Andrius da Costa Ribas]

> On Oct. 3, 2011, 1:15 p.m., David Faure wrote:
> > Couldn't this be done higher in the stack, e.g. in KTabWidget or in Qt?
> 
> Kevin Kofler wrote:
> Indeed, I think there should be some interface for this stuff in kdelibs, 
> so that 1. applications don't have to add such platform-specific code and 2. 
> the feature can also be implemented for our own Plasma Desktop workspace, and 
> applications will automatically benefit (whereas with the current solution, 
> they'd need more platform-specific code doing the same thing). Seeing KDE 
> applications doing more things in a foreign desktop workspace than in our own 
> doesn't look right to me. :-(
> 
> (Yet another kdelibs feature that would justify doing a 4.8 release…)
> 
> Martin Gräßlin wrote:
> if anyone wants to do the bits for Plasma, please see 
> http://community.kde.org/KWin/Browser_Integration
> 
> It just needs someone to implement and at least Mozilla already showed 
> interest in adding support if we add that.
> 
> Andrius da Costa Ribas wrote:
> My thoughts:
> - I did an first experiment with dolphin only, but yes, we all agree this 
> might be inside some sort of library.
> - I don't think KTabWidget is an appropriate place to place this either, 
> since we may want to generate previews of non tabbed interfaces (Konversation 
> and Kate don't necessarily use tabs). It would be better to bind such 
> interface into a KApplication (but not necessarily making it inside 
> KApplication)
> - (this one more kind of brainstorming) Reading Martin and Kevin's 
> comments, I think it would be good to have a single interface to window 
> managers, in the same way phonon address multimedia stuff so the app should 
> not care about whether VLC, Xine or DirectSound is being used, in the same 
> way solid address hardware stuff so the app should not care about whether WMI 
> or HAL is being used, this interface should work in a way the app should not 
> care whether KWin, Mutter or dwm.exe is being used.
> - "Seeing KDE applications doing more things in a foreign desktop 
> workspace than in our own doesn't look right to me." - To me this would not 
> look right if we were talking about GnomeShell or other X11 desktop... in 
> this case I see this more like an OS thing (given that explorer can be 
> replaced, but dwm can't). Also, I think implementing something ready for a 
> foreign desktop encourages making the "native" desktop ready for it too ;).
> 
> @Martin: I know almost nothing about x11-specific stuff to help out with 
> plasma/kwin, but according to that link, the required elements are almost the 
> same ( icon + title + thumbnail ), so I think it may be not hard to have a 
> common interface, not just for this feature but for other wm features too ( 
> I'm thinking about thumbnail toolbars on amarok and kopete, just like the 
> ones in wmp, wlm and skype ;] )
>

I'm closing this request as "discarded". By now I think the patch can be used 
in emerge scripts to help out tracking issues with this on different compilers 
and different windows boxes. I would like to know from plasma/kwin people their 
thoughts about a common interface as mentioned in my previous comment.


- Andrius da Costa


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


On Oct. 5, 2011, 12:52 a.m., Andrius da Costa Ribas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102758/
> ---
> 
> (Updated Oct. 5, 2011, 12:52 a.m.)
> 
> 
> Review request for KDE Base Apps, KDE Accessibility, kdewin, Plasma, Patrick 
> Spendrin, and Peter Penz.
> 
> 
> Description
> ---
> 
> Add Windows 7 tab thumbnails feature to dolphin.
> Mostly based on the example from 
> .
> 
> An icon representation is used instead of actual thumbnails ( please agree 
> that those microscopic previews are not useful at all ;] ). Changing an icon 
> when url changes is also easier than checking all the time whether something 
> inside the window has been changed. Using icons is a lot more KDE-ish and 
> therefore more beautiful and user-friendly than the default Windows behavior 
> ;).
> 
> "win7utils.h" and "win7utils.cpp" are from 
> 
>  with few adaptations.
> 
> 
> Diffs
> -
> 
>   dolphin/src/CMakeLists.txt 93225c5 
>   dolphin/src/dolphinapplication.h 69d07c3 
>   dolphin/src/dolphinapplication.cpp 0dc9c96 
>   dolphin/src/dolphinmainwindow.h 9fb83bf 
>   dolphin/src/dolphinmainwindow.cpp 6ca6e59 
>   dolphin/src/platform/win7utils.h PRE-C

Re: Review Request: W7 Tab thumbnails in dolphin.

[Andrius da Costa Ribas]

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

(Updated Oct. 5, 2011, 12:52 a.m.)


Review request for KDE Base Apps, KDE Accessibility, kdewin, Plasma, Patrick 
Spendrin, and Peter Penz.


Description
---

Add Windows 7 tab thumbnails feature to dolphin.
Mostly based on the example from 
.

An icon representation is used instead of actual thumbnails ( please agree that 
those microscopic previews are not useful at all ;] ). Changing an icon when 
url changes is also easier than checking all the time whether something inside 
the window has been changed. Using icons is a lot more KDE-ish and therefore 
more beautiful and user-friendly than the default Windows behavior ;).

"win7utils.h" and "win7utils.cpp" are from 
 
with few adaptations.


Diffs
-

  dolphin/src/CMakeLists.txt 93225c5 
  dolphin/src/dolphinapplication.h 69d07c3 
  dolphin/src/dolphinapplication.cpp 0dc9c96 
  dolphin/src/dolphinmainwindow.h 9fb83bf 
  dolphin/src/dolphinmainwindow.cpp 6ca6e59 
  dolphin/src/platform/win7utils.h PRE-CREATION 
  dolphin/src/platform/win7utils.cpp PRE-CREATION 

Diff: http://git.reviewboard.kde.org/r/102758/diff/diff


Testing
---

Tested using MSVC 2010 32 bit, in a Windows 7 64 bit machine.

May need testing:
- Compiling under mingw-w32 and mingw-w64
- Using Windows Vista or below to ensure there are no side-efects on a box 
without this feature.
- Using Windows 8 (I don't know much about its bugs^H^H^H^Hfeatures ;] )

Known problems:
- There is no way to know if KTabBar got a tab reordered, so the "thumbnails" 
won't be reordered, but their reference is still correct
- Undefined behavior when dolphin gets unresponsive [e.g.: because of a 
defective kioslave], most of the code assume dolphin is okay [e.g.: 
QPixmap::grabWidget won't work in a frozen window]. 


Screenshots
---

Tabs!
  http://git.reviewboard.kde.org/r/102758/s/281/
More Tabs!
  http://git.reviewboard.kde.org/r/102758/s/282/
Too many tabs!
  http://git.reviewboard.kde.org/r/102758/s/283/


Thanks,

Andrius da Costa Ribas

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

Re: Any Plasma UI experts available for some team work?

[Kevin Krammer]

On Monday, 2011-10-03, Kevin Krammer wrote:
> Hi workspace people,
> 
> part of the 4.7 changes is email becoming available as a service instead of
> being bound to specific applications.
> 
> The application previously the only master of sending and receiving mails,
> KMail, is obviously still equipped with the necessary facilties to do its
> job.
> 
> However, since this is no longer a tight coupling the other way around, it
> would IMHO greatly improve our workspace experience if we could control and
> monitor email exchange through workspace components.
> 
> I could try to implement something myself, but I am not very good at nice
> UI, yet alone fancy UI :)
> 
> So I was wondering if any person(s) with Plasma UI skills would be
> available to work as a team, i.e. me writing whatever Akonadi interaction
> code, data engine, etc. would be needed and someone else doing the user
> facing stuff.

I copied the code from my first attempt of a data engine from SVN to a git 
scratch repository: scratch/krake/akonadiagents-dataengine

Or for those using kdesrc-build:

module akonadiagents-dataengine
repository g...@git.kde.org:scratch/krake/akonadiagents-dataengine.git
end module

Call for help on UI side still stands of course.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


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: The future of Power Management - together with Activities

[Steven Sroka]

>On 2 October 2011 19:01, Dario Freddi  wrote:
> 2011/10/2 Michael Pyne :
>> On Sunday, October 02, 2011 19:52:09 Dario Freddi wrote:
>>> On Sunday 02 October 2011 19:35:15 Michael Pyne wrote:
>>> > And even assuming the user knows how to do this, if they want to change
>>> > power  management options we are saying that they need to duplicate an
>>> > existing activity, change the power management options in that new one,
>>> > and switch to that new activity to do the same thing they were doing
>>> > before. The only one doing something different now is the *computer*. This
>>> > is my point about orthogonality.
>>>
>>> But again, it does not make sense. You are failing to provide a valid use
>>> case for these situations, expect "the user might want to do that".
>>
>> I worry about that mentality. Not so much the idea that features shouldn't be
>> added without use cases in mind, but the idea that features inadvertently
>> present should be removed without "valid use cases". So many software
>> applications find use beyond what their developers initially had intended or
>> even understood was possible. I don't understand why this should be
>> concerning.
>
> Although I generally agree with this mindset, I urge you to notice we
> are in a very special case here. We are not talking about a cool
> feature in an application, but instead about an important part of the
> system the user should not even have to configure - tomorrow I´ll post
> the first version of the activity-based UI I am thinking of and my
> masterplan will be even more clear. So I think we should focus on
> covering the most widely used use cases, or better: only the ones
> which technically make sense, as it´s very likely a different use case
> could be a consequence of a misunderstanding or a misuse of the
> features additionally provided - as this thread shows, this is clearly
> the issue with profiles.
>
>>
>>> But
>>> even leaving that aside, I might say: what's the difference between
>>> creating a new activity and configure it and creating a new profile and
>>> configure it, if that's the sole purpose of the change?
>>
>> I'll admit that I've misunderstood much of your proposal, over at least the
>> first day this thread was going on. If I'm understanding correctly now, then:
>>
>> * The ability to change the currently-loaded profile will go away. The
>> currently-loaded profile will instead be based on the combination of > Activity> and .
>>
>> * It will instead be possible to inhibit all power management functions (e.g.
>> for presentation mode).
>>
>> * It will always be possible to change the screen brightness (most important
>> parameter for power savings).
>>
>> * And, it will be possible at any time to edit the power management settings
>> for the current . (This, btw, is the only thing I
>> found unclear).
>
> Yes, that´s a very good summary.
>
>>
>> If this is true then there is not a large concern, the user is still more or
>> less easily able to do what he/she was able to do before (independent of "use
>> case analysis"...) and in fact has an easier task if they use Activities.
>
> Exactly.
>
>>
>> So to answer your question, I couldn't care less about how easy it is to
>> create profiles. I've never created profiles, I've always just changed
>> whatever setting was wrong at the time or used one of the default profiles
>> that was "close enough". But the fact that you asked the question shows that
>> we were not communicating effectively, because you thought I cared at all
>> about that, and I thought you seriously intended to prevent changing the
>> profile *settings* without going through a new Activity first.
>
> It might as well be that I have been not clear enough in explaining my
> proposal, and if so, I apologize for that and for what came out of it.
> But back to the point, YES, you got it! The point is exactly that the
> average user does not care about profiles at all, and he probably does
> not even know how to/he can change them. Again, when I´ll show you my
> ideas things will be even clearer in this regard.
>
>>
>> Please let me know where I'm wrong on that. And please keep in mind that I
>> have been, as far as I know, polite and at least putting in a good-faith
>> effort to fully understand the proposal and its impact, and it would be nice
>> to have that assumption borne in mind in replies to myself. :)
>
> I know, and I am sorry I had to come to a point where I needed to be
> harsh. You also have to keep in mind I am one of the few guys who does
> the dirty job, and I mostly get flames more than anything. Usually,
> the gratification for a developer is having users saying ¨thanks, your
> app rocks¨: my gratification is usually getting no feedback at all
> because things work as they should. In addition, I get flamed
> everytime I propose a change, because people refuse to accept there
> might be better ways of working, and when it´s implemented and
> working, I get no ¨sorry,in the end you were right¨ or 

Review Request: fix the problem that the text below the selected wallpaper is barely readable if the window is inactive

[Ralf Jung]

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

Review request for Plasma.


Description
---

This patch fixes the Plasma incarnation of 
https://bugs.kde.org/show_bug.cgi?id=253022 : The custom item delegate in the 
wallpaper selection uses incorrect colours if the window is inactive or 
disabled.


Diffs
-

  plasma/generic/wallpapers/image/backgrounddelegate.cpp 8354d99 

Diff: http://git.reviewboard.kde.org/r/102772/diff/diff


Testing
---

Compiled and checked whether the colours are fixed.


Thanks,

Ralf Jung

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

Review Request: XTest is an optional dependency, so skip a test that requires it if it is not found

[Ralf Jung]

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

Review request for Plasma.


Description
---

Running cmake without having libxtest fails as some tests that are always 
compiled use it unconditionally. This fixes these tests to be only compiled if 
libxtest is found, as it is marked as optional dependency.


Diffs
-

  kcontrol/keyboard/tests/CMakeLists.txt 419d150 

Diff: http://git.reviewboard.kde.org/r/102771/diff/diff


Testing
---

kde-workspace compiles now.


Thanks,

Ralf Jung

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

Re: The case for a kdelibs 4.8

[Dirk Mueller]

On Thursday 29 September 2011, Kevin Kofler wrote:

> 2. It will be confusing to our users, and even to some packagers, to have a
> KDE SC 4.8 on kdelibs 4.7. The rule so far has always been that the kdelibs
> version must be the same as the KDE SC version. Changing this will also
> break all our Fedora KDE SC specfiles, which all have a:
> BuildRequires: kdelibs4-devel >= %{version}

We will release a kdelibs 4.8.0 tarball for this purpose (as other distros 
have the same issue). 

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

Re: removing dependencies from kactivitymanagerd

[Ivan Cukic]

> Given the low interest of other window managers to collaborate recently,
> I doubt that. But do we care, if not?

I don't know really. Sometimes I want to say "hey, this is a hard dep, 
deal with it", but then I see people who use rather quirky setups.

But, yeah, we can do it kwin only, and if we get enough bug reports, go 
for the:

> And we still can just open our own watch service to use if KWin is not
> running.

Ch

-- 
There are no such things as applied sciences, only applications of 
science.
  -- Louis Pasteur

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

Re: Replace kimpanel in kdeplasma-addons with a rewrite version

[Weng Xuetian]

在 2011年10月4日 Tuesday 17:19:40，Aaron J. Seigo 写道：
> On Monday, September 19, 2011 20:39:11 Weng Xuetian wrote:
> > So I rewrite kimpanel (Use the same dbus protocol), and use dataengine
>
> *resurrects and old thread* :)
>
> so this is now in git .. and we need to decide what we are going to do with
> it. my suggestion is this, and i'd like comments on it as it would mean some
> moderately large changes:
>
> * we remove kimpanel from kdeplasma-addons
> * the new kimpanel takes its place, and we communicate this to packagers
> * we roll a release of the kimpanel along with every SC release if there
> were changes since the last SC release
> * we roll new releases of the new kimpanel whenever justified regardless of
> SC schedule so people don't have to wait :)
>
> so far, probably nothing SHOCKING, right? :)
>
> let's fix that ... :P
>
> we have the keyboard container and the keyboard widget in two other
> repositories. the plasmoid is in addons, the container shell is in plasma-
> mobile.
>
> i propose that we take the kimpanel repository, call it
> "plasma-intputmethods" (or something similar) and put ALL of our input
> method related code there. that would include:
>
> * kimpanel
> * keyboard container shell
> * on-screen keyboard widget
> * anything else?
For me that's what I exactly want to do in the futre: try to get them merge if
necessary. And I'm also a input method developer (named fcitx, which is not a
part of KDE and only for chinese currently though, but I'm trying to drive it
to more language support.), so actually I can provides more support not only
from the UI part, like something really get implemented but not only a design.
>
> if we were to get REALLY dramatic we could put kxkb or even klipper in
> there, but i'm still debating with myself as to how far to take this new
> module. what i do know is i'd like all our input stuff in one place instead
> of spread out all over the place. these components seem to develop at their
> own pace and are related to each other topically ...
>
Keyboard layout(xkb for X11) is also something should also get here in my
mind.
> thoughts?
For desktop PC, I'm not sure what we should do for something new, but merge
the keyboard layout with kimpanel is something comes to my mind, since
keyboard layout is something that very similar to inputmethod (which get
separated with input method in x11 linux due to historical reason), but for
instance, like windows, keyboard layout is only represent as single input
method.

For tablet or something else, kimpanel maybe should merge with on-screen
keyboard like what most mobile phone does: provides input method if required.
Not sure whether the on-screen keyboard is related to the keyboard layout yet.
But also it would be great if input method want to provides it's own on screen
keyboard layout when input method get enabled.

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: Re: removing dependencies from kactivitymanagerd

[Martin Gräßlin]

On Tuesday 04 October 2011 18:29:33 Ivan Cukic wrote:
> General question - do you want to create a fw5 branch or something like 
> that?
> 
> Aaron
> > KUniqueApplication: this lives in kdeui ... just to provide a way to
> > have only one instance of the app. ugh. in Frameworks there is libkdbus
> > which has a KDBusService which provides the same capabilities. porting
> > to that proved quite simple and straightforward and let ActivityManager
> > become a QCoreApplication subclass.
> 
> Do we even need KDBusService? Just a check of 
> QDBusConnectionInterface::isServiceRegistered can be used for this.
> 
> Martin
> > Well for Wayland we need to change KWindowSystem anyway and I don't
> > want to low level protocols. So who wants to 
> 
> Is that going to be kwin-only, or we have a hope it will be picked up by 
> others?
Given the low interest of other window managers to collaborate recently, I 
doubt that. But do we care, if not?

And we still can just open our own watch service to use if KWin is not running.

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

Re: removing dependencies from kactivitymanagerd

[Ivan Cukic]

General question - do you want to create a fw5 branch or something like 
that?

Aaron
> KUniqueApplication: this lives in kdeui ... just to provide a way to
> have only one instance of the app. ugh. in Frameworks there is libkdbus
> which has a KDBusService which provides the same capabilities. porting
> to that proved quite simple and straightforward and let ActivityManager
> become a QCoreApplication subclass.

Do we even need KDBusService? Just a check of 
QDBusConnectionInterface::isServiceRegistered can be used for this.

Martin
> Well for Wayland we need to change KWindowSystem anyway and I don't
> want to low level protocols. So who wants to 

Is that going to be kwin-only, or we have a hope it will be picked up by 
others?

Cheerio


-- 
Prediction is very difficult, especially about the future.
  -- Niels Bohr

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

Review Request: Simplify pixmap handling for XEmbed-based systray

[Luboš Luňák]

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

Review request for Plasma.


Description
---

This patches changes systemtray handling of XEmbed-based clients from various 
Xlib code to plain Qt code. The Xlib code was presumably introduced to handle 
non-native Qt graphics systems, but that can be somewhat more cleanly handled 
by forcing Qt to create XPixmap-based QPixmap.


Diffs
-

  plasma/generic/applets/systemtray/protocols/fdo/x11embedcontainer.h fa47b9b 
  plasma/generic/applets/systemtray/protocols/fdo/x11embedcontainer.cpp 0aa5d96 

Diff: http://git.reviewboard.kde.org/r/102770/diff/diff


Testing
---

Tested with plasma-desktop and licq, with and without compositing enabled, 
seems to work the same way like without the patch.


Thanks,

Luboš Luňák

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

Re: Replace kimpanel in kdeplasma-addons with a rewrite version

[Aaron J. Seigo]

On Monday, September 19, 2011 20:39:11 Weng Xuetian wrote:
> So I rewrite kimpanel (Use the same dbus protocol), and use dataengine

*resurrects and old thread* :)

so this is now in git .. and we need to decide what we are going to do with 
it. my suggestion is this, and i'd like comments on it as it would mean some 
moderately large changes:

* we remove kimpanel from kdeplasma-addons
* the new kimpanel takes its place, and we communicate this to packagers
* we roll a release of the kimpanel along with every SC release if there were 
changes since the last SC release
* we roll new releases of the new kimpanel whenever justified regardless of SC 
schedule so people don't have to wait :)

so far, probably nothing SHOCKING, right? :)

let's fix that ... :P

we have the keyboard container and the keyboard widget in two other 
repositories. the plasmoid is in addons, the container shell is in plasma-
mobile.

i propose that we take the kimpanel repository, call it "plasma-intputmethods" 
(or something similar) and put ALL of our input method related code there. 
that would include:

* kimpanel
* keyboard container shell
* on-screen keyboard widget
* anything else?

if we were to get REALLY dramatic we could put kxkb or even klipper in there, 
but i'm still debating with myself as to how far to take this new module. what 
i do know is i'd like all our input stuff in one place instead of spread out 
all over the place. these components seem to develop at their own pace and are 
related to each other topically ...

thoughts?

-- 
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: removing dependencies from kactivitymanagerd

[Martin Gräßlin]

On Tuesday 04 October 2011 16:33:03 Aaron J. Seigo wrote:
> hi all...
> 
> i experimented a bit this morning with cutting the fat from 
> kactivitymanagerd. 
> in particular i focussed on the following.
> 
> KUniqueApplication: this lives in kdeui ... just to provide a way to have 
> only 
> one instance of the app. ugh. in Frameworks there is libkdbus which has a 
> KDBusService which provides the same capabilities. porting to that proved 
> quite simple and straightforward and let ActivityManager become a 
> QCoreApplication subclass.
> 
> KWindowSystem: this one is more difficult. it is used only to track the 
> comings and goings of windows. no other features are used. and it ends up 
> causing a QWidget to be created, which KWindowSystem uses to filter x11 
> events. i don't have a great solution for this one .. but it would be very 
> nice to have something that doesn't pull in such a heavy set of dependencies 
> just to watch window states. i don't know if this would be general-purpose 
> enough to end up in Frameworks (my gut says "no") but writing a simple class 
> that can have a window-system-specific implementation that alerts when the 
> window focus changes and windows are closed would make a lot of sense for 
> kactivitymanagerd.
> 
> so, i have a patch for the former, but nothing for the latter. any takers? :)
Well for Wayland we need to change KWindowSystem anyway and I don't want to low 
level protocols. So who wants to 
design a D-Bus interface for broadcasting such methods and add a nice wrapper 
around it? Adding support for it in KWin 
should be simple. What do you think?

Cheers
Martin

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: Remove waste setTextBackgroundColor for internal KTextEdit in Plasma::TextEdit widget

[Commit Hook]

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


This review has been submitted with commit 
e7c0b35b7f26abf04ac7bce1ad05b17ca964866f by Alexey Chernov to branch frameworks.

- Commit Hook


On Sept. 30, 2011, 6:25 a.m., Alexey Chernov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102698/
> ---
> 
> (Updated Sept. 30, 2011, 6:25 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Removed setTextBackgroundColor() for internal KTextEdit in Plasma::TextEdit 
> widget.
> 
> It seems to be useless as it's voided by inherited QTextDocument as soon as 
> all the contents of the TextEdit is removed (even with Backspace key). The 
> problem is that it also leads to QTBUG-21522 
> (http://bugreports.qt.nokia.com/browse/QTBUG-21522) which I mentioned in 
> kde-devel mailing-list under 'Plasma::TextEdit problem because of 
> QTextEdit::toHtml() bug' subject. I've sent a patch for that bug, too, but 
> it's probably not good to have any waste functionality in Plasma itself.
> 
> If there were some serious reasons to add this string, please, note them 
> here. Otherwise, I think it's worth to be removed.
> 
> 
> Diffs
> -
> 
>   plasma/widgets/textedit.cpp 13cc6aa 
> 
> Diff: http://git.reviewboard.kde.org/r/102698/diff/diff
> 
> 
> Testing
> ---
> 
> The behavior is the same when used in plasmoids except mentioned Qt bug isn't 
> reproducible anymore.
> 
> 
> Thanks,
> 
> Alexey Chernov
> 
>

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

removing dependencies from kactivitymanagerd

[Aaron J. Seigo]

hi all...

i experimented a bit this morning with cutting the fat from kactivitymanagerd. 
in particular i focussed on the following.

KUniqueApplication: this lives in kdeui ... just to provide a way to have only 
one instance of the app. ugh. in Frameworks there is libkdbus which has a 
KDBusService which provides the same capabilities. porting to that proved 
quite simple and straightforward and let ActivityManager become a 
QCoreApplication subclass.

KWindowSystem: this one is more difficult. it is used only to track the 
comings and goings of windows. no other features are used. and it ends up 
causing a QWidget to be created, which KWindowSystem uses to filter x11 
events. i don't have a great solution for this one .. but it would be very 
nice to have something that doesn't pull in such a heavy set of dependencies 
just to watch window states. i don't know if this would be general-purpose 
enough to end up in Frameworks (my gut says "no") but writing a simple class 
that can have a window-system-specific implementation that alerts when the 
window focus changes and windows are closed would make a lot of sense for 
kactivitymanagerd.

so, i have a patch for the former, but nothing for the latter. any takers? :)

-- 
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: ScreenSaver and KDE Plasma 4.8?

[Luca Beltrame]

In data martedì 4 ottobre 2011 13:36:52, Aaron J. Seigo ha scritto:

> we know why we want to move away from the 20 year old implementation of
> screen savers, we know how we want to do it ... now let's execute on that
> plan, keep communicating to our users and partners about it and be open to

FYI, according to the poll on the forum (but low sample size: 150+ votes),
most don't really care about the change in the screensavers.

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: New to Plasma !

[Aaron J. Seigo]

Hi Adwait!

first: welcome to plasma! :)

On Tuesday, October 4, 2011 01:13:33 Adwait Sharma wrote:
> Can someone please guide me from where should i start and how? :)

i'll ask you the same thing i always ask people who ask me this:

What interests you?

if you work on things that interest you, you are more likely to succeed and to 
keep at it longer.

that said, there are a number of things that could use more people working on 
them. there are individual plasmoids, for instance, which could use a lot more 
love. and those are a great place to start as they are small and self-
contained.

converting plasmoids to QML is another area of need.
adding features or cleaning up features that exist in Plasma Desktop or 
Netbook is also a fine place to start.

there are lots of task suggestions here:

http://community.kde.org/Plasma/Tasks

and lots of bugs on bugs.kde.org to examine as well.

but if i were you, i'd start looking around at what exists and asking 
yourself: "what would i really like to work on improving?"

then post your proposal here and we'll help you get working on it!

-- 
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: ScreenSaver and KDE Plasma 4.8?

[Aaron J. Seigo]

On Tuesday, October 4, 2011 13:06:34 Kevin Kofler wrote:
> Martin Gräßlin wrote:
> > Well if they do I promise to ship an update to kwin to ensure that
> > xscreensaver is stacked underneath the desktop shell ;-)
>
> They'll find a way around that too. "If you make something idiot-proof,
> nature builds a better idiot." ;-) (And sorry, I don't remember who
> originally came up with that citation.)

instead of trying to convince each other with increasingly clever (or whatever
other adjective one wishes to use ;) statements ... let's get back to
focussing on making great technology that matters.

we know why we want to move away from the 20 year old implementation of screen
savers, we know how we want to do it ... now let's execute on that plan, keep
communicating to our users and partners about it and be open to adaptation as
necessary as we receive real world feedback (by which i do not mean "the
loudest whingers" of course :)

--
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: Re: Re: ScreenSaver and KDE Plasma 4.8?

[Kevin Kofler]

Martin Gräßlin wrote:
> Well if they do I promise to ship an update to kwin to ensure that
> xscreensaver is stacked underneath the desktop shell ;-)

They'll find a way around that too. "If you make something idiot-proof, 
nature builds a better idiot." ;-) (And sorry, I don't remember who 
originally came up with that citation.)

Kevin Kofler

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