Help with Share dataengine and GHNS

[Artur de Souza]

Hello everybody!

So my vacations came to an end :( but on the other hand I'm back  
hacking :) For some reason I can't properly install/uninstall  
extensions using GHNS and the Share dataengine (used through the  
Pastebin applet).

Could someone please take a look and help me out finding where is the  
bug? It properly installs but once the extension is installed, it  
can't remove anymore...

Thanks :)

Cheers,

Artur

---


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

Re: Review Request: Tasks applet: Make order independent of whether the row count is forced.

[Aaron Seigo]

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

Ship it!


looks good; thanks for the further explanation. i missed that the col/row 
counts were already being computed elsewhere in the code appropriately.

- Aaron


On 2010-11-06 20:58:47, Ingomar Wesp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5776/
> ---
> 
> (Updated 2010-11-06 20:58:47)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This should fix , but frankly I 
> don't understand why it was done this way in the first place...
> 
> 
> This addresses bug 215231.
> https://bugs.kde.org/show_bug.cgi?id=215231
> 
> 
> Diffs
> -
> 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
> 1190987 
> 
> Diff: http://svn.reviewboard.kde.org/r/5776/diff
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> 3 forced rows, 1-5 windows, trunk vs. patched
>   http://svn.reviewboard.kde.org/r/5776/s/550/
> 
> 
> Thanks,
> 
> Ingomar
> 
>

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

Re: Review Request: Tasks applet: Make order independent of whether the row count is forced.

[Steven Sroka]

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


I noticed that the fading on the 'buttons' that represent minimized windows are 
gone. Is there anyway to keep that? Or was this changed by someone else in 
another revision?

- Steven


On 2010-11-06 20:58:47, Ingomar Wesp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5776/
> ---
> 
> (Updated 2010-11-06 20:58:47)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This should fix , but frankly I 
> don't understand why it was done this way in the first place...
> 
> 
> This addresses bug 215231.
> https://bugs.kde.org/show_bug.cgi?id=215231
> 
> 
> Diffs
> -
> 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
> 1190987 
> 
> Diff: http://svn.reviewboard.kde.org/r/5776/diff
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> 3 forced rows, 1-5 windows, trunk vs. patched
>   http://svn.reviewboard.kde.org/r/5776/s/550/
> 
> 
> Thanks,
> 
> Ingomar
> 
>

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

Color issues with Applet::showMessage()

[Martin]

Hi,

it looks like there's some trouble using Plasma::Applet::showMessage() in 
Amarok.

But first some background information for you:
Amarok has it's own ContextView - which is a Containment with lots of applets 
in it.
What I'm trying to do is getting the user's attention in exactly ONE applet.
The old implementation used KMessageBox. First I thought I could reuse it, but 
that's not the case. I could only block access to either all or no applets.
So I went to #plasma and got a solution: Plasma::Applet::showMessage()

So that's where I am right now: I wrote some convenience methods around 
Plasma::Applet::showMessage().
While testing the code on my box I found out that Amarok's plasma theme (the 
colors file of the theme to name it more precisely) may be wrong.
I'm using a dark theme (called Ember - basically everything is black there).
Since I couldn't read the text from showMessage() first I decided to "fix" the 
colors file and make the text white.
I simple set ForegroundNormal=255,255,255 for [Colors:Window] (since the 
background color is 0,0,0).

It turned out that this was a bad idea.
The colors in showMessage() are fine for everyone.
But in other places it causes trouble. See here: [0] (please note the text of 
the lyrics applet - which is a Plasma::TextBrowser - also the text-color in 
some other places changed, for example in some Plasma::Label).

Now my question:
How to solve this issue? ;)
Is there a way to define a text-color for showMessage() directly?
Or are we doing some crazy things with Plasma components in Amarok (which are 
causing the described trouble)?

If you need some references to the code: feel free to have a look at Amarok's 
source code. You may also need to apply my patch from reviewboard: [1].

Feel free to ping me if you have further questions.

Regards from Germany,
Martin


[0] http://i.imgur.com/LZ4Up.jpg
[1] http://git.reviewboard.kde.org/r/100013/diff/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Tasks applet: Make order independent of whether the row count is forced.

[Ingomar Wesp]

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

(Updated 2010-11-06 20:58:47.857921)


Review request for Plasma.


Changes
---

Added screenshot showing the difference in behavior for a forced row count of 3.


Summary
---

This should fix , but frankly I 
don't understand why it was done this way in the first place...


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


Diffs
-

  /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
1190987 

Diff: http://svn.reviewboard.kde.org/r/5776/diff


Testing
---


Screenshots
---

3 forced rows, 1-5 windows, trunk vs. patched
  http://svn.reviewboard.kde.org/r/5776/s/550/


Thanks,

Ingomar

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

Re: Review Request: Tasks applet: Make order independent of whether the row count is forced.

[Ingomar Wesp]

> On 2010-11-06 14:55:24, Aaron Seigo wrote:
> > it's probably that way so that if you say "two rows" then you get two rows 
> > even there are only two buttons. otherwise you'll get a whole row of 
> > buttons that takes up just the top row before filling in the rows below, 
> > leaving a large section of the widget empty until the rows are filled in 
> > with entries.
> > 
> > [ window ]
> > [ window ]
> > 
> > vs
> > 
> > [ window ] [ window ]
> > <  empty>
> > 
> > on the other hand, trying to keep a stable # of rows while distributing 
> > between the rows would result in entries moving around quite a bit as 
> > windows are added .. which also isn't good.
> > 
> > could you take some screenshots of the tasks widget running with your patch 
> > with different numbers of rows and windows showing in it, that we can use 
> > to get some responses to?

Thanks for pointing this out, but I think this is already prevented by 
precomputing the number of rows and columns. So, if a certain number of rows 
are forced, the number of columns will always be minimal (>x only if the number 
of items is bigger than the x times the number of rows).

However - and this might be the reason for why this was implemented this way - 
with row-major ordering, not all of the rows will be filled if the number of 
columns (that you need anyways) allows you to accomodate all items with less 
rows. 

I really need more practice in explaining things in English, but maybe it's a 
bit clearer in the screenshot.


- Ingomar


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


On 2010-11-06 13:09:53, Ingomar Wesp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5776/
> ---
> 
> (Updated 2010-11-06 13:09:53)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This should fix , but frankly I 
> don't understand why it was done this way in the first place...
> 
> 
> This addresses bug 215231.
> https://bugs.kde.org/show_bug.cgi?id=215231
> 
> 
> Diffs
> -
> 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
> 1190987 
> 
> Diff: http://svn.reviewboard.kde.org/r/5776/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ingomar
> 
>

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

Re: Re: Move kdeplasma-addons to git - take 2

[Ivan Čukić]

Hi Artu(r) :)

> Good question. Maybe we could switch as soon as we have the 4.6 tag? Some
> other teams are planning like this. What do you think about this?

It would seam ok for me. The only /problem/ is how we will handle
backporting fixes, but that would be an issue no matter when we do the
switch.

>  * lancelot and lancelot-datamodels (100% ok, everything came from the
> lancelot applet. Thanks Ivan :D)

np :)

Ch!


-- 
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Move kdeplasma-addons to git - take 2

[Artur de Souza]

Hi Ivan!

Quoting Ivan Cukic :
How are we going to handle this release-wise - switching when the  
regular trunk opens for features or what?


Good question. Maybe we could switch as soon as we have the 4.6 tag?  
Some other teams are planning like this. What do you think about this?


Some update on the rules: following the list below, only two items  
were not traceable. Actually, the "playground" of one and the  
kdereview and playground of another. Here is the update:



applets:
  * bookmarks (OK)

containments:
  * groupingdesktop (OK)

dataengines:
  * kdeobservatory (OK)

libs:
  * lancelot and lancelot-datamodels (100% ok, everything came from  
the lancelot applet. Thanks Ivan :D)


runners:
  * events (OK without playground)
  character (didn't find any history besides what is in  
kdeplasma-addons - it came from kde-looks.org. maybe that's the  
reason. but I could not find anything related to it on kdereview too).


  * datetime (OK)

Branches and tags OK too.

I'm going to run the svn2git with the rules to check if everything is  
ok. You can find the rules set attached, if you're curious about it :)


Cheers,

---


kdeplasma-addons-rules
Description: Binary data
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Move kdeplasma-addons to git - take 2

[Ivan Cukic]

How are we going to handle this release-wise - switching when the regular trunk 
opens for features or what?


Ch

-- 
So remember when you're feeling very small and insecure
How amazingly unlikely is your birth
And pray that there's intelligent life somewhere up in space
Because there's bugger all down here on earth.
-- Monty Python

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

Re: Move kdeplasma-addons to git - take 2

[Artur de Souza]

Quoting Chani :
> On November 6, 2010 16:48:28 Artur de Souza wrote:
> it'd be nice-to-have, yes.
> I think we could live without it if it's a big hassle to convert, though.

I'm getting the history of those that Marco listed...

> kdereview won't be a module in git, it'll be a state of.. being. :) so
> probably a redmine page or something?

Indeed :) I forgot about this hehe, thanks for reminding :)


Cheers,

---


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

Move kdeplasma-addons to git - take 2

[Artur de Souza]

Hello :)

I'm almost back from vacations and today I found some minutes to work  
on this again. So, I'm getting the history of the items that Marco  
selected (above) from whatever they came. Question: should I get the  
history from kdereview too, or that is going to be treated as a  
different module? From my point of view we should get the history of  
what happened to the code in kdereview into kdeplasma-addons history.  
Any thoughts?

cheers!

Artur

---


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

Re: Review Request: Tasks applet: Make order independent of whether the row count is forced.

[Aaron Seigo]

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


it's probably that way so that if you say "two rows" then you get two rows even 
there are only two buttons. otherwise you'll get a whole row of buttons that 
takes up just the top row before filling in the rows below, leaving a large 
section of the widget empty until the rows are filled in with entries.

[ window ]
[ window ]

vs

[ window ] [ window ]
<  empty>

on the other hand, trying to keep a stable # of rows while distributing between 
the rows would result in entries moving around quite a bit as windows are added 
.. which also isn't good.

could you take some screenshots of the tasks widget running with your patch 
with different numbers of rows and windows showing in it, that we can use to 
get some responses to?

- Aaron


On 2010-11-06 13:09:53, Ingomar Wesp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5776/
> ---
> 
> (Updated 2010-11-06 13:09:53)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This should fix , but frankly I 
> don't understand why it was done this way in the first place...
> 
> 
> This addresses bug 215231.
> https://bugs.kde.org/show_bug.cgi?id=215231
> 
> 
> Diffs
> -
> 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
> 1190987 
> 
> Diff: http://svn.reviewboard.kde.org/r/5776/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ingomar
> 
>

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

Re: Review Request: Tasks applet: Make order independent of whether the row count is forced.

[Ingomar Wesp]

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

(Updated 2010-11-06 13:09:53.119264)


Review request for Plasma.


Changes
---

Unbreak indentation.


Summary
---

This should fix , but frankly I 
don't understand why it was done this way in the first place...


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


Diffs (updated)
-

  /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
1190987 

Diff: http://svn.reviewboard.kde.org/r/5776/diff


Testing
---


Thanks,

Ingomar

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

Review Request: Tasks applet: Make order independent of whether the row count is forced.

[Ingomar Wesp]

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

Review request for Plasma.


Summary
---

This should fix , but frankly I 
don't understand why it was done this way in the first place...


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


Diffs
-

  /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
1190987 

Diff: http://svn.reviewboard.kde.org/r/5776/diff


Testing
---


Thanks,

Ingomar

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