Re: folderview as default for all users

2012-12-11 Thread Kevin Krammer
On Tuesday, 2012-12-11, adrelanos wrote:
 Kevin Krammer:
  As I already wrote on the other mailinglist there is a share/ missing in
  this path, as demonstrated by the output of kde4-config.
 
 I am sorry, I failed to understand that mail and went back to the mail
 plasma-devel@kde.org suggestion.

Ah, no problem :)

 /usr/local/share/whonix/kde/share/apps/plasma-desktop/init/00-defaultLayout
 .js
 
  Does it work if you use that?
 
 Yes. Thanks you!

Excellent!

Turns out we actually have documentation for that :)
http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting#Running_Scripts

Btw, since we are on plasma-devel already, maybe some of the developers here 
would have some ideas on how to use the JobViewServer from a sciprting 
language that has native D-Bus support.

Probably better as a new thread though.

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


Mono icons in systray

2012-12-11 Thread Jacopo De Simoi
Dear all, 
 
  I noticed how the new air theme (which is just beautiful, btw) makes the 
mono icons in systray quite low-constrast; this is especially apparent with 
compositing turned off.   
I started thinking about a sensible solution which would not require 
rebuilding all mono icons every time we change the default plasma theme; 
recalling some recent post on icon fonts, I wonder if switching to an icon 
font for monochrome plasma icons would provide us with a solution; in my 
opinion there are quite a number of advantages:

- the new air theme (and the whole design trend these days) is considerably 
“flatter” than the old ones; perhaps *really* flat mono icons could fit better 
than the current ones, with all these gradients and borders. Besides, one 
could in principle render fonts with a gradient and a border, as it is already 
done for the keyboard layout applet and the plasma digital clock. 

- hinting: fonts provide hinting informations for pixel-snapping on-screen 
rendering at small sizes (which are typically the ones used in systray). This 
does not make the icon pixel perfect, but possibly quite close to it.  
Manually hinting a font is quite painful, but after all we do not have too 
many icons to take care of…

- subpixel antialiasing:  subpixel antialiasing (for those who like it) would 
possibly make curves smoother 

- coloring: icons can be colored in such a way to optimize contrast, this 
makes borders around shapes not necessary and help saving precious pixels 

Of course there are a few disadvantages:

- things get more complicated with composite icons, (e.g. volume or battery), 
so we should cook out some reasonable way to define things such as svg groups 
for fonts

- Learn to use a new tool (e.g. fontforge) to design such icons (altough we 
could obtain some help from Vernon Adams, who is designing the Oxygen font)

My proposal is to create some sort of plasma icon service, which would create 
QIcons of the right size™ from a special font; this would be totally 
transparent to applets, exactly as it is done now with svg icons embedded in 
plasma themes. 

So I am asking, what are your opinions on this? Does this make sense to you? 
Do you think is it worth working in this direction? (I'm heading for 4.11, of 
course) 

Thanks, 
  Best

  __J

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


Re: Re: [RFC] New (QML) Desktop Containment

2012-12-11 Thread Alex Fiestas
On Tuesday 11 December 2012 01:40:04 Martin Graesslin wrote:
 On Monday 10 December 2012 13:51:02 Alex Fiestas wrote:
  Maybe we can get some feedback from the forums ?
 
 we have to be careful about that. From all I have seen over the last years I
 think that the toolbox is in the top 3 most hated features all over KDE
 software. So if we ask the question in the wrong way we only get the haters
 and not those who use it and like it (nobody is going to reply to a thread
 if he has the feeling he will be ripped apart). And forums does not reflect
 our userbase - it has only the users who are interested in KDE and do know
 that KDE exists in the first place. So overall for this particular question
 I'm rather sceptical.
Well I know all of that, but forums is the best we have.

In a few weeks we we'll have the office ready to take random people from the 
street and ask them to do some test, but even there they won't be our userbase 
because... Who is our userbase?

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


Re: Re: [RFC] New (QML) Desktop Containment

2012-12-11 Thread Alex Fiestas
On Tuesday 11 December 2012 07:49:40 Kevin Ottens wrote:
 On Monday 10 December 2012 22:10:52 Marco Martin wrote:
  On Mon, Dec 10, 2012 at 6:17 PM, Alex Fiestas afies...@kde.org wrote:
   -What was the design decision/idea/thing behind cashew? It seems to me
   like a way of showing some actions that otherwise will be hidden (in the
   context  menu), is that it?
  
  (cough, toolbox, cough) one tof the reasons is that the context menu can
  be
  removed by the user at any time, or repurposed to show something
  completely
  different
 
 Also these days, the toolbox is the main place where we show what the
 current activity is. If we ever decide to drop it we'll likely need think
 how to indicate that to the user.
Oh, very good point.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Mono icons in systray

2012-12-11 Thread Nuno Pinheiro
A Terça, 11 de Dezembro de 2012 10:06:36 você escreveu:
 Dear all,
 
   I noticed how the new air theme (which is just beautiful, btw) makes the
 mono icons in systray quite low-constrast; this is especially apparent with
 compositing turned off.

they seam about the same here ...

 I started thinking about a sensible solution which would not require
 rebuilding all mono icons every time we change the default plasma theme;
 recalling some recent post on icon fonts, I wonder if switching to an icon
 font for monochrome plasma icons would provide us with a solution; in my
 opinion there are quite a number of advantages:

Unless you are a realy good font designer that wil take care of the hinting 
instructions i dont see many...

 - the new air theme (and the whole design trend these days) is considerably
 “flatter” than the old ones; perhaps *really* flat mono icons could fit
 better than the current ones, with all these gradients and borders.

agrea to some extent that we should get rid of the iner gradient in the icons. 
the border i sthere for contrast issue againts random backgroundsNote 
fonts suck in that way and we have to make the (imo) overdone blured 
background.

 Besides, one could in principle render fonts with a gradient and a border,
 as it is already done for the keyboard layout applet and the plasma digital
 clock.




 - hinting: fonts provide hinting informations for pixel-snapping on-screen
 rendering at small sizes (which are typically the ones used in systray).
 This does not make the icon pixel perfect, but possibly quite close to it.
 Manually hinting a font is quite painful, but after all we do not have too
 many icons to take care of…

again do you know any font designer willing to do them?
and what is the adgantage work wise in relation to svg's? you can do the same 
in svg's creting multiple svg's for multiple rendering sizes


 - subpixel antialiasing:  subpixel antialiasing (for those who like it)
 would possibly make curves smoother

so mono But with color pixels on the side right

 - coloring: icons can be colored in such a way to optimize contrast, this
 makes borders around shapes not necessary and help saving precious pixels

but ofcourse the problem is that we dont have controll over the background 
color since that is tranparent


 Of course there are a few disadvantages:
 
 - things get more complicated with composite icons, (e.g. volume or
 battery), so we should cook out some reasonable way to define things such
 as svg groups for fonts


 - Learn to use a new tool (e.g. fontforge) to design such icons (altough we
 could obtain some help from Vernon Adams, who is designing the Oxygen font)

Vernon is prety bussy right now and im trying to find out a way to bring him 
back to finish the font, expect some sort of oxygen fund raysing.
 
 My proposal is to create some sort of plasma icon service, which would
 create QIcons of the right size™ from a special font; this would be totally
 transparent to applets, exactly as it is done now with svg icons embedded
 in plasma themes.
 
 So I am asking, what are your opinions on this? Does this make sense to you?
 Do you think is it worth working in this direction? (I'm heading for 4.11,
 of course)

Since it would just duplicate work, with no visible gain imo (with QT5 around 
the corner coloring an element in scenegraph is rader trivial, shaders for the 
win), I would abandon this idea.

On the making the try icons mono yeah expect that soon... 

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


Re: RFC: Application wide shortcuts in QML

2012-12-11 Thread Aaron J. Seigo
On Friday, December 7, 2012 22:39:09 Mark wrote:
 Hi,
 
 I just made this blog post [1] and would like to see if i can include
 this - quite handy - QML component in the KDE imports. I think it fits
 quite nicely in the qtextracomponents import.
 
 The syntax is as follows (in QML):
 Shortcut {
 key: Ctrl+C
 onActivated: {
 console.log(JS:  + key +  pressed.)
 }
 }

From discussions had recently with qt devs, this will likely be coming in Qt 
5.1. I forget the exact API decided on (or if it has been decided on), but I'd 
be Ok with it only if the API of this component was the same as the Qt5 API 
will be so we don't have to maintain this API forever.

I'm also very hestitant to encourage plasmoids to implement app-wide key 
shortcuts. Might be nice(r) to automatically require ctrl (so it would be 
just: key: C) or some other modifier or even just disabled when in a shared-
space formfactor (vertical, horizontal, planar..); these need to be able to be 
kept manageable so plasmoids don't capture the same shortcuts (easy when you 
can have more than one instance of the plasmoid :)

-- 
Aaron J. Seigo

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: RFC: Application wide shortcuts in QML

2012-12-11 Thread Mark
On Tue, Dec 11, 2012 at 3:02 PM, Aaron J. Seigo ase...@kde.org wrote:
 On Friday, December 7, 2012 22:39:09 Mark wrote:
 Hi,

 I just made this blog post [1] and would like to see if i can include
 this - quite handy - QML component in the KDE imports. I think it fits
 quite nicely in the qtextracomponents import.

 The syntax is as follows (in QML):
 Shortcut {
 key: Ctrl+C
 onActivated: {
 console.log(JS:  + key +  pressed.)
 }
 }

 From discussions had recently with qt devs, this will likely be coming in Qt
 5.1. I forget the exact API decided on (or if it has been decided on), but I'd
 be Ok with it only if the API of this component was the same as the Qt5 API
 will be so we don't have to maintain this API forever.

 I'm also very hestitant to encourage plasmoids to implement app-wide key
 shortcuts. Might be nice(r) to automatically require ctrl (so it would be
 just: key: C) or some other modifier or even just disabled when in a shared-
 space formfactor (vertical, horizontal, planar..); these need to be able to be
 kept manageable so plasmoids don't capture the same shortcuts (easy when you
 can have more than one instance of the plasmoid :)

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


Could you post a link to that Qt 5.1 api when you find it again? I did
a bit of searching, but nothing thus far.
As for limiting it's usage. In my case that would not work. I need F5
as well in my app so i'm guessing other app developers could have
the same requirement.

Perhaps it's better to just use this component as a desktop component
only? Is there any way to enforce that?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Mono icons in systray

2012-12-11 Thread Jacopo De Simoi
On Tuesday 11 December 2012 12:13:11 you wrote:
 A Terça, 11 de Dezembro de 2012 10:06:36 você escreveu:
  Dear all,
  
I noticed how the new air theme (which is just beautiful, btw) makes the
  
  mono icons in systray quite low-constrast; this is especially apparent
  with
  compositing turned off.
 
 they seam about the same here ...

I am not sure, it looks like the panel is lighter than it used to be

 agrea to some extent that we should get rid of the iner gradient in the
 icons. the border i sthere for contrast issue againts random
 backgroundsNote fonts suck in that way and we have to make the (imo)
 overdone blured background.

Yes, I understand the issue with random backgrounds, but I am referring to the 
non-composited case, where no transparency is taken into account. At least 
this case, and the composited case with the default wallpaper should be nicely 
contrasted. 

  - hinting: fonts provide hinting informations for pixel-snapping on-screen
  rendering at small sizes (which are typically the ones used in systray).
  This does not make the icon pixel perfect, but possibly quite close to it.
  Manually hinting a font is quite painful, but after all we do not have too
  many icons to take care of…
 
 again do you know any font designer willing to do them?
 and what is the adgantage work wise in relation to svg's? you can do the
 same in svg's creting multiple svg's for multiple rendering sizes

btw, why are we not using pngs in desktoptheme icons?

  - subpixel antialiasing:  subpixel antialiasing (for those who like it)
  would possibly make curves smoother
 
 so mono But with color pixels on the side right

It's a matter of taste; besides, if you see color fringing you should consider 
tweaking your subpixel filter (check out infinality) 

  - coloring: icons can be colored in such a way to optimize contrast, this
  makes borders around shapes not necessary and help saving precious pixels
 
 but ofcourse the problem is that we dont have controll over the background
 color since that is tranparent

That is why we should provide a way to set coloring of icons; after all if one 
chooses the same color for background and foreground, then his desktop is 
broken, but it is a user fault; otoh if the user cannot choose the foreground 
color… then it is not that clear. 

 Since it would just duplicate work, with no visible gain imo (with QT5
 around the corner coloring an element in scenegraph is rader trivial,
 shaders for the win)... 

That's excellent news!

 On the making the try icons mono yeah expect that soon...
\me drools
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: [RFC] New (QML) Desktop Containment

2012-12-11 Thread Marco Martin
On Monday 10 December 2012, Alex Fiestas wrote:
  (cough, toolbox, cough) one tof the reasons is that the context menu can
  be removed by the user at any time, or repurposed to show something
  completely different
 
 And of course given the windowed system we have, we need to show desktop
 to give the focus to the desktop.
 
 What are the other reasons for it? Not that it bothers me too much but
 people seem not to use it.
 
 Maybe we can get some feedback from the forums ?

btw the work on the containment done has zero to do with the toolbox, they are 
two completely separedpieces of software... just to keep each topic where is 
due :p


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


Re: Mono icons in systray

2012-12-11 Thread Marco Martin
On Tuesday 11 December 2012, Jacopo De Simoi wrote:

 Yes, I understand the issue with random backgrounds, but I am referring to
 the non-composited case, where no transparency is taken into account. At
 least this case, and the composited case with the default wallpaper should
 be nicely contrasted.

probably black icons could be re-tried, not sure anyways i can make the non 
composited background darker again

   - hinting: fonts provide hinting informations for pixel-snapping
   on-screen rendering at small sizes (which are typically the ones used
   in systray). This does not make the icon pixel perfect, but possibly
   quite close to it. Manually hinting a font is quite painful, but after
   all we do not have too many icons to take care of…
  
  again do you know any font designer willing to do them?
  and what is the adgantage work wise in relation to svg's? you can do the
  same in svg's creting multiple svg's for multiple rendering sizes
 
 btw, why are we not using pngs in desktoptheme icons?

* makes them come from the plasma theme, shouldn't have anything to do with 
the used icon theme
* being scaled are not right, but yet are not the utter catastrophe scaled png 
icons are

   - subpixel antialiasing:  subpixel antialiasing (for those who like it)
   would possibly make curves smoother
  
  so mono But with color pixels on the side right
 
 It's a matter of taste; besides, if you see color fringing you should
 consider tweaking your subpixel filter (check out infinality)

maybe, but i hate this subpixel antialiasing is one of the things i hate more 
then pretty much anything, is a BIG no go for me

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


Re: Mono icons in systray

2012-12-11 Thread Marco Martin
On Tuesday 11 December 2012, Jacopo De Simoi wrote:
 recalling some recent post on icon fonts, I wonder if switching to an icon
 font for monochrome plasma icons would provide us with a solution; in my
 opinion there are quite a number of advantages:

using a font would basically raise the entry barrier of doing a new icon to 
plus infinite or so..

having hinting there would be very cool (the shape deformation to fit the 
grid, not the horrible color bleeding antialiasing abomination)

however in reality fonts are just too hard to do, even just a copuple of 
symbols

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


Re: [RFC] New (QML) Desktop Containment

2012-12-11 Thread Marco Martin
On Monday 10 December 2012, Sebastian Kügler wrote:

 There are some tunables I would like to give you to try with, so it's
 easier to values that feel right. Those are grid size, delay, visibility
 and opacity of movement halo. I'll have a look at making these
 configurable for a test version so we have good defaults later. The idea
 tough is to just find defaults, those values won't be configurable in the
 final size.
 
 Cheers,

to make it even more condensed (since the discussion derailed a bit on other 
topics, that even tough interesting, deserve a separate thread, for 
readability), basically the points touched, and in need of feedback are:

* handles behavior: part of the global applet background, that grows on a side 
on mouseover: one visual element less if possible, makes less or more visual 
noise? has to be tested out

* repositioning of applets according to a grid: ~40px size has been tested 
seems small enough, will be made configurable (*just in the testing phase* 
will be dpi based afterwards)

* applet ghost behavior: it may be valuable information or maybe too noisy: 
also that will have tunable opacity (from 0) in test phase

* is acceptable giving behavior configuration options in testing phase and 
taking them back afterwards? *even that* should be done carefully

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


Re: Re: [RFC] New (QML) Desktop Containment

2012-12-11 Thread Alex Fiestas
On Tuesday 11 December 2012 21:11:22 Marco Martin wrote:
 On Monday 10 December 2012, Alex Fiestas wrote:
   (cough, toolbox, cough) one tof the reasons is that the context menu can
   be removed by the user at any time, or repurposed to show something
   completely different
  
  And of course given the windowed system we have, we need to show desktop
  to give the focus to the desktop.
  
  What are the other reasons for it? Not that it bothers me too much but
  people seem not to use it.
  
  Maybe we can get some feedback from the forums ?
 
 btw the work on the containment done has zero to do with the toolbox, they
 are two completely separedpieces of software... just to keep each topic
 where is due :p

Sorry, I thought the toolbox was part of it :p
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: [RFC] New (QML) Desktop Containment

2012-12-11 Thread Luca Beltrame
In data martedì 11 dicembre 2012 22:15:06, Marco Martin ha scritto:

 * is acceptable giving behavior configuration options in testing phase and
 taking them back afterwards? *even that* should be done carefully

IMO depends on who the testing public is and how it is communicated. Posters
in this ML would not complain, but outside that, I'm not sure.

--
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: 6E1A4E79


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: Revert fix compilation with debian qjson

2012-12-11 Thread Ralf Jung

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

Review request for Plasma.


Description
---

This reverts commit fix compilation with debian qjson 
(b32fefab8d258011a72a12761b3ade0b719636b1) by myself.
The issue was actually a bug in Debian, which installed incorrect qjson 
configuration files, see: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687537
The bug has been fixed in Debian testing and unstable, and it never reached 
stable. The lower-case variable names have never been used upstream.


Diffs
-

  plasma/generic/runners/bookmarks/CMakeLists.txt ad560f3 

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


Testing
---

Everything still compiles with current Debian testing, qjson is found and used.


Thanks,

Ralf Jung

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


[KDE Bugtracking System] REMINDER: current Plasma regressions

2012-12-11 Thread bugzilla_noreply
Please find below a list of the current regressions reported for Plasma. This 
is a weekly reminder.

  This search was scheduled by myr...@kde.org.


Plasma regressions
--
Bug 202336:
  https://bugs.kde.org/show_bug.cgi?id=202336
  Priority: NOR  Severity: normal  Platform: Gentoo Packages
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: KRunner should launch default email application when providing an 
email address
Bug 241685:
  https://bugs.kde.org/show_bug.cgi?id=241685
  Priority: NOR  Severity: crash  Platform: Ubuntu Packages
  Assignee: plasma-b...@kde.org
Status: REOPENED
   Summary: Random Plasma crashes [QGraphicsLayoutItem::isLayout , 
QGraphicsLayoutPrivate::activateRecursive]
Bug 282552:
  https://bugs.kde.org/show_bug.cgi?id=282552
  Priority: NOR  Severity: crash  Platform: openSUSE RPMs
  Assignee: plasma-b...@kde.org
Status: REOPENED
   Summary: plasma desktop crash on add default panel
Bug 290018:
  https://bugs.kde.org/show_bug.cgi?id=290018
  Priority: NOR  Severity: normal  Platform: Ubuntu Packages
  Assignee: plasma-b...@kde.org
Status: REOPENED
   Summary: Add Widgets strip and Activity Manager no longer slide in
Bug 301424:
  https://bugs.kde.org/show_bug.cgi?id=301424
  Priority: NOR  Severity: normal  Platform: openSUSE RPMs
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Cannot open battery monitor applet if set to hidden in systray
Bug 302310:
  https://bugs.kde.org/show_bug.cgi?id=302310
  Priority: NOR  Severity: normal  Platform: Compiled Sources
  Assignee: plasma-b...@kde.org
Status: REOPENED
   Summary: Does not reflect insert/removal of battery
Bug 302331:
  https://bugs.kde.org/show_bug.cgi?id=302331
  Priority: NOR  Severity: normal  Platform: Ubuntu Packages
  Assignee: ignat.seme...@blue-systems.com
Status: UNCONFIRMED
   Summary: Folderview does not show any to activity linked files
Bug 307059:
  https://bugs.kde.org/show_bug.cgi?id=307059
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: tooltips in widget explorer don't show widget version anymore
Bug 309787:
  https://bugs.kde.org/show_bug.cgi?id=309787
  Priority: NOR  Severity: normal  Platform: Ubuntu Packages
  Assignee: plasma-b...@kde.org
Status: REOPENED
   Summary: Krunner does not execute program when press ENTER
Bug 310762:
  https://bugs.kde.org/show_bug.cgi?id=310762
  Priority: NOR  Severity: major  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Desktop icon plasmoid does not launch application anymore when they 
are unlocked.
Bug 311339:
  https://bugs.kde.org/show_bug.cgi?id=311339
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: notm...@gmail.com
Status: NEW
   Summary: Empty notification popup when invoking notify-send
Bug 311350:
  https://bugs.kde.org/show_bug.cgi?id=311350
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: System Tray widget has huge padding by default when added to the 
desktop
Bug 311354:
  https://bugs.kde.org/show_bug.cgi?id=311354
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: System Tray widget can't be resized to fit all icons in one row 
when added to the desktop
Bug 311491:
  https://bugs.kde.org/show_bug.cgi?id=311491
  Priority: NOR  Severity: normal  Platform: Fedora RPMs
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Battery Monitor widget disappears after one move of Screen 
Brightness slider
Bug 311502:
  https://bugs.kde.org/show_bug.cgi?id=311502
  Priority: NOR  Severity: normal  Platform: Compiled Sources
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Tooltips leave rectangle in New Air theme
Bug 311503:
  https://bugs.kde.org/show_bug.cgi?id=311503
  Priority: NOR  Severity: normal  Platform: Compiled Sources
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Scrollbar in Add Widgets almost invisible with new Air theme


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


Plasma Media Center feature free tonight!

2012-12-11 Thread Shantanu Tushar Jha
Hi!

Just a reminder, PMC goes into a feature free tonight at 23:59 hours
UTC[1]. If you have new features in a branch, or local clone, merge them
with master already.

Don't hesitate to ask if someone has a question/concern.

Cheers,

[1] http://community.kde.org/Plasma/Plasma_Media_Center/DecemberMeeting

-- 
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: Mono icons in systray

2012-12-11 Thread Jacopo De Simoi
On Tuesday 11 December 2012 21:37:13 Marco Martin wrote:
 On Tuesday 11 December 2012, Jacopo De Simoi wrote:
  recalling some recent post on icon fonts, I wonder if switching to an icon
  font for monochrome plasma icons would provide us with a solution; in my
 
  opinion there are quite a number of advantages:
 using a font would basically raise the entry barrier of doing a new icon to
 plus infinite or so..

This seems to be a very sensible objection; I believe that inkscape can 
produce svg fonts, which can then be imported in fontforge and tweaked with 
hinting infos there. 

This is indeed a considerable overhead; perhaps then one could implement 
shape-rendering:crispEdges rendering in QtSvg; actually if the svg routines 
are shared with webkit, it could be that they are already implemented…

 
 having hinting there would be very cool (the shape deformation to fit the
 grid, not the horrible color bleeding antialiasing abomination)

Allright, subpixel hinting is definitely not your favourite feature; I got 
your point :D 

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


Re: Mono icons in systray

2012-12-11 Thread Jacopo De Simoi
 This is indeed a considerable overhead; perhaps then one could implement
 shape-rendering:crispEdges rendering in QtSvg; actually if the svg routines
 are shared with webkit, it could be that they are already implemented…

ok, this might be pure nonsense; I checked out the specs of what crispEdges 
does and it is not what I was expecting…

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