Re: Review Request: Added System Wallpaper and My Downloaded Wallpaper checkboxes to sildeshow config

[Jeremy Whiting]

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

(Updated 2010-10-30 22:50:25.298178)


Review request for Plasma and Davide Bettio.


Changes
---

Fixed the layout and added the curly braces where needed.
Aaron, is the wording of the tooltips ok? or should it change also somehow?


Summary
---

Prompted by bug https://bugs.kde.org/show_bug.cgi?id=253360 and my own itch at 
not having the ability to easly add ~/.kde/share/wallpaper/ to the slideshow, I 
added these two checkboxes from this wishlist bug.  Let me know if you think 
the tooltips should be reworded I just took an initial stab at them.


Diffs (updated)
-

  /trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1190748 
  /trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 
1190748 
  
/trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/slideshowconfig.ui 
1190748 

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


Testing
---

I works quite well actually.  I still think we need to disable the apply and ok 
buttons when no checkbox is checked and no paths are in the listbox, but we 
work around that by putting the system folder in the list if there are no 
folders in the kconfig.


Thanks,

Jeremy

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

Re: Re: libplasma 2

[Ivan Cukic]

> I second that. Maybe it is still a bit early but i myself have an idea about 
> a 
> change that could be done and i think a wiki page can be very useful to keep 
> track of them.

It is early to start making new designs/decisions etc. but collecting current 
problems is not something that should be left 
for the last moment.

(for example, from the small things like places where we had to use signals and 
slots instead of virtual methods 'cause of 
BC to some bigger design decisions)

Ivan

-- 
There is a better way of life and it's not so hard to find
If you live and let the people in your world speak its mind
-- Deep Purple

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

Re: libplasma 2

[Giulio Camuffo]

> If yes, what do you think about creating a wiki dump page with the stuff
> we'd like to rethink / change?
> 
> It could be in the format:
>IDEA: Blah blah
>Summary: Blah blah blah
>Link to ML discussion: mailman/something/something
> 
> (since wikis suck for discussions, we could do it here - one thread per
> idea - and use wiki as an index of items)

I second that. Maybe it is still a bit early but i myself have an idea about a 
change that could be done and i think a wiki page can be very useful to keep 
track of them.

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

libplasma 2

[Ivan Cukic]

Hi all,

Following Aaron's blog post [1] regarding QML and plasma, and breaking 
back-compatibility in the future.

So, it is the plan to (well, a necessity more than a plan) make a BIC to 
libplasma producing libplasma2. Should we take 
the opportunity to fix some mistakes we've made in libplasma1 maybe risking 
some source-incompatibilities as well?

If yes, what do you think about creating a wiki dump page with the stuff we'd 
like to rethink / change?

It could be in the format:
   IDEA: Blah blah
   Summary: Blah blah blah
   Link to ML discussion: mailman/something/something

(since wikis suck for discussions, we could do it here - one thread per idea - 
and use wiki as an index of items)

Cheerio,
Ivan



[1] http://aseigo.blogspot.com/2010/10/plasma-in-18-24-months.html



-- 
There is a better way of life and it's not so hard to find
If you live and let the people in your world speak its mind
-- Deep Purple

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

Re: KDE/kdebase/workspace/plasma/generic/applets/systemtray/core

[Aaron J. Seigo]

On Saturday, October 30, 2010, Marco Martin wrote:
> SVN commit 1191305 by mart:
> 
> don't move icons in the first position when the are notificating,
> apparently is confusing (except the notifications applet that always

where is the feedback that this was based on? is it from people who have 
multi-row system trays? vertical system trays? using apps that constantly 
juggle back and forth (e.g. an IM app that sets itself to NeedsAttention 
whenever their nick is mentioned)? OCD? ;)

problem now is that there will often be little to no visual cue as to which 
items are of elevated concern. i agree with you that this seems to be a step 
backwards, so i'm wondering what motivated the change.

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

KDE/kdebase/workspace/plasma/generic/applets/systemtray/core

[Marco Martin]

SVN commit 1191305 by mart:

don't move icons in the first position when the are notificating, apparently is 
confusing (except the notifications applet that always remain there)
i'm not completely happy about this solutions, there gota be something better :/
CCMAIL:plasma-devel@kde.org


 M  +2 -8  task.cpp  


--- trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/task.cpp 
#1191304:1191305
@@ -177,21 +177,15 @@
 
 void Task::resetHiddenStatus()
 {
-if (d->status == NeedsAttention) {
-setOrder(First);
-if (hidden() & AutoHidden) {
+//Apparently setOrder(First) when d->status == NeedsAttention seems the 
most hated feature ever :/
+if ((d->status == Active || d->status == NeedsAttention) && (hidden() & 
AutoHidden)) {
 setHidden(hidden() ^ AutoHidden);
-}
-} else {
-if (d->status == Active && (hidden() & AutoHidden)) {
-setHidden(hidden() ^ AutoHidden);
 } else if (d->status == Passive) {
 setHidden(hidden() | AutoHidden);
 }
 
 setOrder(Normal);
 }
-}
 
 }
 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Improving the searchbox applet

[Onur-Hayri Bakici]

I recently let the netbook containment on my netbook and i am really heavily 
impressed. Great job!
Moreover i discovered the searchbox applet, which pretty much belongs to my 
daily use case
However i also came accross tiny things that I am not 100%ly happy with.
I would like to extend the applet a little bit with this idea: Since all 
windows disappear when you enter text in the searchbox widget, instead i would 
like to list the searchresults underneath the textbox widget, due to 
"distractions" in the user's workflow.
Therefore it is easier for the user to return to his/her recent task. It
probably will look like spotlight from apple OS but imo
it is important not to disturb the user with maximized searchresults.

I integrated the krunnermodel into the applet, but i did not find a reasonable 
view to display the searchresults.
I tried Plasma::TreeView, however do not think that the searchresults should 
be displayed on a white background with the "plasma-themed" panel.

My question is: What is the best recommondation to display the results that 
look nice on the plasma panel, without reimplementing a view?

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

Re: Review Request: Plasma::Svg: Do not require exact match for size hinted elements.

[Manuel Mommertz]

> On 2010-10-29 20:56:15, Manuel Mommertz wrote:
> > /trunk/KDE/kdelibs/plasma/svg.cpp, line 85
> > 
> >
> > should end with:
> > -(.*)\\1");
> > this is save as setMinimal is true;
> 
> Ingomar Wesp wrote:
> Actually, I think it's a bit cleaner if we only accept size hinted 
> elements whose base id is non-empty - (\\d+)-(\\d+)-(.*) would also accept 
> "32-32-" for example. Although it does not matter in practice, because 
> findInCache checks whether the passed element is non-empty anyways.

I prefer wrong positives that are actually valid id's. Say we have a id 
"32-32-". With (.*)\\1 we get an empty match. But with (.+)\\1 the quotation 
mark gets part of .+ so we get all things up to the next quotation mark as id. 
And if the next quotation is the start of the next id (extreme unlikely but 
possible) we miss it completly.


- Manuel


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


On 2010-10-28 23:30:24, Ingomar Wesp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5689/
> ---
> 
> (Updated 2010-10-28 23:30:24)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Previously, if an SVG contained size hinted elements, they were only used 
> when the display size matched the size hint exactly. This patch tries to 
> relax this condition by searching for the smallest size hinted element that 
> is still bigger than the display size (in order for the element to be chosen, 
> it also has to have the same aspect ratio). If no such element can be found, 
> it falls back to the normal element id as passed.
> 
> In order to speed up the lookup (and because it appears to be impossible to 
> access the DOM of an already loaded SvgRenderer), all size hinted element ids 
> are stored in SharedSvgRenderer at load time.
> 
> I think it would be good to change the QRegExp based id fetching into a 
> proper DOM traversal. Are there any convenience functions in KDELibs that 
> allow easy iterating over all elements (couldn't find any) or do I have to 
> implement that myself based on Qt's DOM classes?
> 
> Please tell me what you think... Have I missed something?
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/private/svg_p.h 1190806 
>   /trunk/KDE/kdelibs/plasma/svg.cpp 1190806 
>   /trunk/KDE/kdelibs/plasma/theme.h 1190806 
>   /trunk/KDE/kdelibs/plasma/theme.cpp 1190806 
> 
> Diff: http://svn.reviewboard.kde.org/r/5689/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ingomar
> 
>

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