Re: Scripted Plasmoid icon

2009-10-14 Thread Thomas Olsen 
On 14/10-2009 18:00 "Aaron J. Seigo"  wrote:
> On October 14, 2009, Thomas Olsen wrote:
> > Is this really the best way to do it?
> 
> no. :)

No I didn't really think so...

> 
> > I think that ideally you should just place your icon somewhere under
> > contents/icons, put it in the metadata.desktop file under "Icon" and it
> >  should be recognized by Plasma.
> 
> in your metadata.desktop put an Icon= entry with the path to the icon..
>  e.g. myplasmoid.png or contents/myplasmoid.svg or wherever it is in the
>  package and on installation it should magically work.
> 

And it does! Great!
Now I just have to persuade some artist to make me a couple of SVG's :-) 
Later.

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

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

Re: Scripted Plasmoid icon

2009-10-14 Thread Aaron J. Seigo 
On October 14, 2009, Thomas Olsen wrote:
> I'll see if I can wrap up something readable. Maybe just extend
> http://techbase.kde.org/Paths/Developer/Creating_plasmoids_with_scripts#Lay
> out a little?

sounds sensible; if you have further questions, just ask.

-- 
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: activities overview, take N

2009-10-14 Thread David Baron 
On Wednesday 14 October 2009 20:29:11 Aaron J. Seigo wrote:
> On October 14, 2009, David Baron wrote:
> > What is an activity in your mind? This to me and I think many others is a
> > point of much confusion.
> 
> hate to be the grinch here, but if the concepts being discussed are not
>  clear to you at this point, then this isn't a discussion you need to be a
>  part of. it's already complex enough of a topic without having to start
>  explaining all the concepts from ground zero which we've been working on
>  together for the last couple years. we really need the people who can work
>  from the abstract architecture outwards involved here. general education
>  can happen in another place ... thanks for your understanding; keeping the
>  signal high is really important to getting these topics handled via email.
> 
Ok.
Just remember that those of out there are going to want to make use of this.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Scripted Plasmoid icon

2009-10-14 Thread Thomas Olsen 
On 14/10-2009 18:01 "Aaron J. Seigo"  wrote:
> On October 14, 2009, Thomas Olsen wrote:
> > BTW: The file hierarchy of a Plasmoid isn't really well documented
> > anywhere that I can find. If anyone can explain it to me I will be happy
> > to document it on TechBase.
> 
> from http://websvn.kde.org/trunk/KDE/kdelibs/plasma/private/packages.cpp :

Great. Thanks a lot lot. Don't know how many google pages I have flipped thru 
the last days.
I'll see if I can wrap up something readable. Maybe just extend 
http://techbase.kde.org/Paths/Developer/Creating_plasmoids_with_scripts#Layout 
a little?

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

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

Re: Review Request: Allow user to select Calendar System to display in Calendar and Clock Applets

2009-10-14 Thread Aaron Seigo 

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

Ship it!


long time coming; let's get this in...

- Aaron


On 2009-10-14 18:42:56, John Layt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1378/
> ---
> 
> (Updated 2009-10-14 18:42:56)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> [Requires kdelibs revision 1013825]
> 
> Currently the Calendar and Clock applets can only display the global locale 
> Calendar System, usually Gregorian.  However it would be useful for users to 
> be able to display Calendar applets with different Calendar Systems, for 
> example Hebrew or Hijri, similar in concept to being able to have multiple 
> Clock applets showing different Timezones.  This change enables different 
> applets to display different Calendar Systems and allows the user to 
> configure each of these.  See my blog post at 
> http://www.layt.net/john/blog/odysseus/displacement_activity for screen shots.
> 
> This is primarily achieved by moving most of the calendar configuration code 
> from ClockApplet to CalendarTable from where it can be shared by any applet 
> that embeds the CalendarTable.  The Calendar applet has been modified to use 
> the common configuration, as has the base ClockApplet class which ensures all 
> Clock applets do as well. [I've had some thoughts to move the generic code 
> from CalendarTable to a new non-gui helper class so different calendar layout 
> widgets could share it, but that's not needed yet].
> 
> The major implementation issue I have to raise is in the ClockApplet class 
> where I now create the CalendarTable in the init() instead of in 
> initExtenderExtender(), and the extender item now gets passed the already 
> existing CalendarTable which I believe it then manages.  I _think_ this is 
> safe to do as we will only ever have one calendar extender and it never 
> appears to be deleted during the life of the applet, so I don't think the 
> CalendarTable could be accidentally deleted.  This means there is always a 
> calendarWidget and calendar object so the code can be simplified in lots of 
> places to remove checks to see if it exists first.
> 
> This change does not yet address the issue in the Digital Clock applet that 
> the displayed Date format is not correctly localised, but this involves a 
> number of usability issues that I think are best addressed separately.
> 
> Changes:
> 
> ClockApplet:
>   Remove all calendar configuration code and vars, call CalendarTable 
> implementation instead
>   Add convenience method calendar() for shortcut
>   Clean-up clipboardMenu to only have localised date/time formats, add other 
> calendar system options
>   Remove unused method caseInsensitiveLessThan()
> 
> CalendarTable
>   Add all calendar configuration code and vars from ClockApplet
>   Add ability to set and save calendarType, special type of "locale" means 
> use global locale type
>   Improved validation
> 
> Calendar
>   API to pass through calendar config calls to CalendarTable
> 
> generalConfig.ui
>   Removed all calendar configuration options to new calendarConfig.ui
> 
> calendarConfig.ui
>   New, has all calendar configuration options from generalConfig.ui
>   Added combo box to select calendar system from.
> 
> Clock (digital applet)
>   Display date on clock face in correct calendar system 
> 
> CalendarApplet
>   Add d-> private class, use for variables
>   Add new shared calendar config via CalendarTable
>   Localise day number shown on Icon view
> 
> [My apologies if my over-zealous clean-up of code layout and renaming makes 
> the diff a little hard to read in places]
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/CMakeLists.txt 1035179 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.h 1035179 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.cpp 1035179 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendarConfig.ui PRE-CREATION 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.h 1035179 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1035179 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/clockapplet.h 1035179 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/clockapplet.cpp 1035179 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/generalConfig.ui 1035179 
> 
> Diff: http://reviewboard.kde.org/r/1378/diff
> 
> 
> Testing
> ---
> 
> Used plasmoidviewer to add/remove/play with lots of Calendar and Clock 
> applets.
> 
> 
> Thanks,
> 
> John
> 
>

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

Re: Review Request: Allow user to select Calendar System to display in Calendar and Clock Applets

2009-10-14 Thread John Layt 


> On 2009-08-24 12:30:42, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.h, line 53
> > 
> >
> > ' = ' (spaces)

Done


> On 2009-08-24 12:30:42, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.h, line 59
> > 
> >
> > why the change to return a bool? just correctness, or? because in this 
> > case it is really an implementation detail whether or not a matching data 
> > engine was found or not, and it's not an error that is recoverable from 
> > (nor one that causes any trouble; if the engine doesn't exist a dummy 
> > engine is returned).

Reverted.


> On 2009-08-24 12:30:42, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/plasmaclock/calendarConfig.ui, line 97
> > 
> >
> > just: "Calendar System:"?

Done.


> On 2009-08-24 12:30:42, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/plasmaclock/calendarConfig.ui, lines 
> > 140-143
> > 
> >
> > instead of this, why not just have "Holidays" (instead of "Use Holiday 
> > Region") and have as the first entry "None". "None" would be equivalent to 
> > unselecting the "Display Holidays" checkbox, dropping the usage complexity 
> > of this page quite a bit.

Done, merged from your change.


> On 2009-08-24 12:30:42, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/plasma/applets/calendar/calendar.cpp, lines 
> > 36-48
> > 
> >
> > this is not a public class in a library. there is no point to a private 
> > class other than to make backtraces harder to follow. instead, 
> > calendarWidget and theme should be members of ClockApplet and prefixed with 
> > m_ just as they were prior to your changes.

Reverted.  Habit from all that kdelibs hacking :-)


> On 2009-08-24 12:30:42, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.cpp, lines 213-281
> > 
> >
> > wouldn't the API be kept smaller and the code using this clearer if 
> > they use of Calendar just used the pointer return by calendarTable() 
> > directly? otherwise we end up with all this duplicated API and every time 
> > CalendarTable changes, this API will need to be adjusted in parallel?

I lot of that is existing code, just moved around in the file.  I would have 
thought encapsulation was better, the plasmoids embedding Calendar shouldn't 
have to know about the internal implementation using CalendarTable.  In 
particular, there are a number of get/set functions that are reimplemented 
(calendar, date) in Calendar to update the widget and the clients shouldn't 
have to figure out which variables they set in Calendar and which they set in 
CalendarTable. Same for saving the config, the client shouldn't have to know to 
manage the CalendarTable config as well as the Calendar config.  I'd prefer 
removing the calendarTable() call, but a possible alternative would be to move 
all the get/set down to CalendarTable and use signals/slots to replace the 
current reimplementations, but the config calls would have to be kept in 
Calendar I feel.  Let me know which approach you prefer.


> On 2009-08-24 12:30:42, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.h, line 69
> > 
> >
> > why is this marked as a HACK?

Don't know, that was there in the original code, only looks new as I moved it.  
Removed the word there and a couple of other places too.


- John


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


On 2009-10-14 18:42:56, John Layt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1378/
> ---
> 
> (Updated 2009-10-14 18:42:56)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> [Requires kdelibs revision 1013825]
> 
> Currently the Calendar and Clock applets can only display the global locale 
> Calendar System, usually Gregorian.  However it would be useful for users to 
> be able to display Calendar applets with different Calendar Systems, for 
> example Hebrew or Hijri, similar in concept to being able to have multiple 
> Clock applets showing different Timezones.  This change enables different 
> applets to display different Calendar Systems and allows the user to 
> configure each of these.  See my b

Re: Review Request: Allow user to select Calendar System to display in Calendar and Clock Applets

2009-10-14 Thread John Layt 

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

(Updated 2009-10-14 18:42:56.059625)


Review request for Plasma.


Changes
---

Clean-up of code based on Aarons comments, including merge of Aarons changes to 
simplify config dialog.  See responses to review comments for details, only one 
point outstanding.


Summary
---

[Requires kdelibs revision 1013825]

Currently the Calendar and Clock applets can only display the global locale 
Calendar System, usually Gregorian.  However it would be useful for users to be 
able to display Calendar applets with different Calendar Systems, for example 
Hebrew or Hijri, similar in concept to being able to have multiple Clock 
applets showing different Timezones.  This change enables different applets to 
display different Calendar Systems and allows the user to configure each of 
these.  See my blog post at 
http://www.layt.net/john/blog/odysseus/displacement_activity for screen shots.

This is primarily achieved by moving most of the calendar configuration code 
from ClockApplet to CalendarTable from where it can be shared by any applet 
that embeds the CalendarTable.  The Calendar applet has been modified to use 
the common configuration, as has the base ClockApplet class which ensures all 
Clock applets do as well. [I've had some thoughts to move the generic code from 
CalendarTable to a new non-gui helper class so different calendar layout 
widgets could share it, but that's not needed yet].

The major implementation issue I have to raise is in the ClockApplet class 
where I now create the CalendarTable in the init() instead of in 
initExtenderExtender(), and the extender item now gets passed the already 
existing CalendarTable which I believe it then manages.  I _think_ this is safe 
to do as we will only ever have one calendar extender and it never appears to 
be deleted during the life of the applet, so I don't think the CalendarTable 
could be accidentally deleted.  This means there is always a calendarWidget and 
calendar object so the code can be simplified in lots of places to remove 
checks to see if it exists first.

This change does not yet address the issue in the Digital Clock applet that the 
displayed Date format is not correctly localised, but this involves a number of 
usability issues that I think are best addressed separately.

Changes:

ClockApplet:
  Remove all calendar configuration code and vars, call CalendarTable 
implementation instead
  Add convenience method calendar() for shortcut
  Clean-up clipboardMenu to only have localised date/time formats, add other 
calendar system options
  Remove unused method caseInsensitiveLessThan()

CalendarTable
  Add all calendar configuration code and vars from ClockApplet
  Add ability to set and save calendarType, special type of "locale" means use 
global locale type
  Improved validation

Calendar
  API to pass through calendar config calls to CalendarTable

generalConfig.ui
  Removed all calendar configuration options to new calendarConfig.ui

calendarConfig.ui
  New, has all calendar configuration options from generalConfig.ui
  Added combo box to select calendar system from.

Clock (digital applet)
  Display date on clock face in correct calendar system 

CalendarApplet
  Add d-> private class, use for variables
  Add new shared calendar config via CalendarTable
  Localise day number shown on Icon view

[My apologies if my over-zealous clean-up of code layout and renaming makes the 
diff a little hard to read in places]


Diffs (updated)
-

  trunk/KDE/kdebase/workspace/libs/plasmaclock/CMakeLists.txt 1035179 
  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.h 1035179 
  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.cpp 1035179 
  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendarConfig.ui PRE-CREATION 
  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.h 1035179 
  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1035179 
  trunk/KDE/kdebase/workspace/libs/plasmaclock/clockapplet.h 1035179 
  trunk/KDE/kdebase/workspace/libs/plasmaclock/clockapplet.cpp 1035179 
  trunk/KDE/kdebase/workspace/libs/plasmaclock/generalConfig.ui 1035179 

Diff: http://reviewboard.kde.org/r/1378/diff


Testing
---

Used plasmoidviewer to add/remove/play with lots of Calendar and Clock applets.


Thanks,

John

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

Re: Transforming panels in fullscreen effects (was activities overview, take N)

2009-10-14 Thread Chani 
On October 14, 2009 09:15:34 Aaron J. Seigo wrote:
> On October 14, 2009, Martin Gräßlin wrote:
> > cc-ing kwin list. I said it before, I say it again: we need a workspace
> > mailinglist
> 
> it would be useful; the only challenge is knowing when to post here
>  (because it's only about plasma or kwin) or on the workspace list if we
>  keep plasma- devel@ and kwin@ and add a third one.
> 
> i'd be happy with folding all the lists in together, assuming that the
>  mixing of topics and increased volume wouldn't annoy people or decrease
>  the usefulness of the lists for people.

ehh... I already have to make myself ignore a lot of plasma threads. I 
unsubscribed from kwin to cut down on my mailing-list volume...

we'd probably end up with a lot of [plasma] and [kwin] in subjects so that 
people could filter stuff they don't have time for (except review requests, 
they 
don't say what project htey're for).
a separate mailing list would be easier.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.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: activities overview, take N

2009-10-14 Thread Aaron J. Seigo 
On October 14, 2009, David Baron wrote:
> What is an activity in your mind? This to me and I think many others is a
> point of much confusion.

hate to be the grinch here, but if the concepts being discussed are not clear 
to you at this point, then this isn't a discussion you need to be a part of. 
it's already complex enough of a topic without having to start explaining all 
the concepts from ground zero which we've been working on together for the 
last couple years. we really need the people who can work from the abstract 
architecture outwards involved here. general education can happen in another 
place ... thanks for your understanding; keeping the signal high is really 
important to getting these topics handled via email.

-- 
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: activities overview, take N

2009-10-14 Thread David Baron 
On Wednesday 14 October 2009 17:27:58 Chani wrote:
> On October 14, 2009 06:47:35 David Baron wrote:
> > I have been reading or glancing this thread for a while (many longer
> > posts are unreadable because of all the variations of included text being
> > answered).
> >
> > If we are not talking about a one-to-one desktop-activity relationship
> >  which might be the most straightforward to understand, in other words an
> >  activity is a group of icons, windows, tasks and not a desktop per
> > se
> 
> no, that's not what an activity is.

So, Chanale, time to fess up :-)
What is an activity in your mind? This to me and I think many others is a 
point of much confusion.
 What might it look like as PART of a desktop (why the folder-view comes to 
mind)?

> 
> > The current zoom out, set up, zoom in, find them all different on next
> > login...is hopelessly slow, incomplete and broken. I woud scrap it.
> 
> ummm... dude. we've been talking about scrapping the ZUI for a while now.
> maybe you haven't been glancing at this thread as much as you think you
>  have.

I know this. I would like to see it out still in 4.3.x but maybe expecting too 
much.

In terms of close-reading a lot of this discussion, as I said, much of it was 
unreadable. This format (from Kmail) and this length is clear. Many screens 
full of this or the '>' marking just the beginning of a multiline or 
screenfull of cited text is night impossible to follow. So maybe I did miss 
something. (In other words, folks, maybe do not automatically hit the reply 
button keeping lengthy and growing discussion because the point to be made 
just might get lossed in the forest :-))
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Transforming panels in fullscreen effects (was activities overview, take N)

2009-10-14 Thread Aaron J. Seigo 
On October 14, 2009, Martin Gräßlin wrote:
> cc-ing kwin list. I said it before, I say it again: we need a workspace
> mailinglist

it would be useful; the only challenge is knowing when to post here (because 
it's only about plasma or kwin) or on the workspace list if we keep plasma-
devel@ and kwin@ and add a third one.

i'd be happy with folding all the lists in together, assuming that the mixing 
of topics and increased volume wouldn't annoy people or decrease the 
usefulness of the lists for people.

> > could the kwin devs consider make it a design guideline to not include
> >  panels in such effects but instead leave them untransformed?  it just
> >  looks/feels so much more ... nicer.
> 
> yeah I think we could make that a design guideline. Just for the fun of it
>  I tried it on two effects:
>  * desktop grid:
> http://picasaweb.google.de/lh/photo/h0wjRlQ0m3SLQWlz8XYTHA?feat=directlink
>  * flip switch:
> http://picasaweb.google.de/lh/photo/fUqlyPd2lg5XpUXFmZh3Tg?feat=directlink

nice :)

-- 
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: Scripted Plasmoid icon

2009-10-14 Thread Aaron J. Seigo 
On October 14, 2009, Thomas Olsen wrote:
> BTW: The file hierarchy of a Plasmoid isn't really well documented anywhere
> that I can find. If anyone can explain it to me I will be happy to document
>  it on TechBase.

from http://websvn.kde.org/trunk/KDE/kdelibs/plasma/private/packages.cpp :

addDirectoryDefinition("images", "images/", i18n("Images"));
QStringList mimetypes;
mimetypes << "image/svg+xml" << "image/png" << "image/jpeg";
setMimetypes("images", mimetypes);

addDirectoryDefinition("config", "config/", i18n("Configuration 
Definitions"));
mimetypes.clear();
mimetypes << "text/xml";
setMimetypes("config", mimetypes);
setMimetypes("configui", mimetypes);

addDirectoryDefinition("ui", "ui", i18n("User Interface"));
setMimetypes("ui", mimetypes);

addDirectoryDefinition("scripts", "code", i18n("Executable Scripts"));
mimetypes.clear();
mimetypes << "text/plain";
setMimetypes("scripts", mimetypes);

addDirectoryDefinition("translations", "locale", i18n("Translations"));

addFileDefinition("mainconfigui", "ui/config.ui", i18n("Main Config UI 
File"));
addFileDefinition("mainconfigxml", "config/main.xml", i18n("Configuration 
XML file"));
addFileDefinition("mainscript", "code/main", i18n("Main Script File"));
addFileDefinition("defaultconfig", "config/default-configrc", 
i18n("Default configuration"));
setRequired("mainscript", true);


-- 
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: Scripted Plasmoid icon

2009-10-14 Thread Aaron J. Seigo 
On October 14, 2009, Thomas Olsen wrote:
> Is this really the best way to do it?

no. :)

> I think that ideally you should just place your icon somewhere under
> contents/icons, put it in the metadata.desktop file under "Icon" and it
>  should be recognized by Plasma.

in your metadata.desktop put an Icon= entry with the path to the icon.. e.g. 
myplasmoid.png or contents/myplasmoid.svg or wherever it is in the package and 
on installation it should magically work.


-- 
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: activities overview, take N

2009-10-14 Thread Chani 
On October 14, 2009 06:47:35 David Baron wrote:
> I have been reading or glancing this thread for a while (many longer posts
>  are unreadable because of all the variations of included text being
>  answered).
> 
> If we are not talking about a one-to-one desktop-activity relationship
>  which might be the most straightforward to understand, in other words an
>  activity is a group of icons, windows, tasks and not a desktop per se

no, that's not what an activity is.

> 
> The current zoom out, set up, zoom in, find them all different on next
> login...is hopelessly slow, incomplete and broken. I woud scrap it.

ummm... dude. we've been talking about scrapping the ZUI for a while now. 
maybe you haven't been glancing at this thread as much as you think you have. 
:P

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.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: activities overview, take N

2009-10-14 Thread Chani 
On October 14, 2009 08:17:49 Chani wrote:
> On October 13, 2009 21:34:11 Matthew Dawson wrote:
> > Thinking about the "a-containment-per-virtual-desktop mode", I feel like
> > I use that feature as a substitute for the missing ability of having
> > nepomuk tied activities.  I'd think once you have activities proper this
> > feature will seem (and feel) redundant.  Maybe the better option would be
> > to simply remove the "a-containment-per-virtual-desktop mode" once
> > activities are done?
> 
> well, if we do try removing them, this would be the only chance at doing so
> without being burnt to a complete crisp. ;)
> shall we try it out when the activity-bar first lands, then? and come back
>  to this before the final release to see whether it worked for the
>  per-desktop people.
> 

another thought - if we do that we'll want global kbd shortcuts for switching 
activity, I guess. then there may be complaints from the handful of people 
using active borders (switching desktops by shoving the mouse off the edge) or 
those who want a pretty kwin effect to switch with.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.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: activities overview, take N

2009-10-14 Thread Chani 
On October 13, 2009 21:34:11 Matthew Dawson wrote:

> 
> Thinking about the "a-containment-per-virtual-desktop mode", I feel like I
>  use that feature as a substitute for the missing ability of having nepomuk
>  tied activities.  I'd think once you have activities proper this feature
>  will seem (and feel) redundant.  Maybe the better option would be to
>  simply remove the "a-containment-per-virtual-desktop mode" once activities
>  are done?

well, if we do try removing them, this would be the only chance at doing so 
without being burnt to a complete crisp. ;)
shall we try it out when the activity-bar first lands, then? and come back to 
this before the final release to see whether it worked for the per-desktop 
people.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.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: Scripted Plasmoid icon

2009-10-14 Thread Thomas Olsen 
On 14/10-2009 15:50 Marco Martin  wrote:
> On Wednesday 14 October 2009, Thomas Olsen wrote:
> > Hi
> >
> > I've been googling all day to find a way to use a custom icon for your
> > Plasmoid.
> >
> > I found the following snippet in http://code.google.com/p/gmail-
> > plasmoid/source/diff?spec=svn22&r=22&format=side&path=/trunk/contents/cod
> >e/ main.py
> 
> icon to be shown in the widgets explorer, icon of te popupapplet, or..?

Actually both :-) I haven't gotten around to making it a popup applet since I 
ran into some problems.

> 
> > # Install icon if required
> > kdehome = str(KGlobal.dirs().localkdedir())
> > if not os.path.exists(kdehome+"share/icons/gmail-plasmoid.svg"):
> >   try:
> > shutil.copy(self.package().path() +
> >  "contents/icons/gmail-plasmoid.svg",
> >  kdehome+"share/icons/gmail-plasmoid.svg")
> >   except:
> > print "Problem copying icon"
> > print "Unexpected error:", sys.exc_info()[0]
> >
> > Is this really the best way to do it?
> > I think that ideally you should just place your icon somewhere under
> > contents/icons, put it in the metadata.desktop file under "Icon" and it
> >  should be recognized by Plasma.
> >
> > BTW: The file hierarchy of a Plasmoid isn't really well documented
> > anywhere that I can find. If anyone can explain it to me I will be happy
> > to document it on TechBase.
> 

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

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

Re: activities overview, take N

2009-10-14 Thread David Baron 
I have been reading or glancing this thread for a while (many longer posts are 
unreadable because of all the variations of included text being answered).

If we are not talking about a one-to-one desktop-activity relationship which 
might be the most straightforward to understand, in other words an activity is 
a group of icons, windows, tasks and not a desktop per se

The current zoom out, set up, zoom in, find them all different on next 
login...is hopelessly slow, incomplete and broken. I woud scrap it.

Activities might be connected the current desktop from a right-click, from the 
panel, dashboard and/or from an appropriate previewing plasmoid.

These activities could be containments based on the current folder view but 
could contain (additionally) plasmoids (?) and functioning .desktop files. If 
we want tasks running when the activity is brought up, we would probably want 
them started up where they left off the last session. More difficult if 
impossible for many apps. An activity and its data might be referenced or 
contained in one folder.

A trivial example is the desktop folder containment itself or an appropriately 
filtered folder-view of the desktop folder. There could, of course, be more 
than one or none on any desktop, the same activity might be on several 
desktops. There would be no implicit relationship between activities and 
configured desktops.

While a Rubic's cube of activities/desktops might be cool, I doubt it would 
really be useful. The fact the these hyper-space representations have not been 
widely adapted implies that they are not such wonderful tools. KISS.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Scripted Plasmoid icon

2009-10-14 Thread Marco Martin 
On Wednesday 14 October 2009, Thomas Olsen wrote:
> Hi
> 
> I've been googling all day to find a way to use a custom icon for your
> Plasmoid.
> 
> I found the following snippet in http://code.google.com/p/gmail-
> plasmoid/source/diff?spec=svn22&r=22&format=side&path=/trunk/contents/code/
> main.py

icon to be shown in the widgets explorer, icon of te popupapplet, or..?

> 
> # Install icon if required
> kdehome = str(KGlobal.dirs().localkdedir())
> if not os.path.exists(kdehome+"share/icons/gmail-plasmoid.svg"):
>   try:
> shutil.copy(self.package().path() +
>  "contents/icons/gmail-plasmoid.svg",
>  kdehome+"share/icons/gmail-plasmoid.svg")
>   except:
> print "Problem copying icon"
> print "Unexpected error:", sys.exc_info()[0]
> 
> Is this really the best way to do it?
> I think that ideally you should just place your icon somewhere under
> contents/icons, put it in the metadata.desktop file under "Icon" and it
>  should be recognized by Plasma.
> 
> BTW: The file hierarchy of a Plasmoid isn't really well documented anywhere
> that I can find. If anyone can explain it to me I will be happy to document
>  it on TechBase.
> 


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

Scripted Plasmoid icon

2009-10-14 Thread Thomas Olsen 
Hi

I've been googling all day to find a way to use a custom icon for your 
Plasmoid.

I found the following snippet in http://code.google.com/p/gmail-
plasmoid/source/diff?spec=svn22&r=22&format=side&path=/trunk/contents/code/main.py
 
:

# Install icon if required
kdehome = str(KGlobal.dirs().localkdedir())
if not os.path.exists(kdehome+"share/icons/gmail-plasmoid.svg"):
  try:
shutil.copy(self.package().path() + "contents/icons/gmail-plasmoid.svg", 
kdehome+"share/icons/gmail-plasmoid.svg")
  except:
print "Problem copying icon"
print "Unexpected error:", sys.exc_info()[0]

Is this really the best way to do it?
I think that ideally you should just place your icon somewhere under 
contents/icons, put it in the metadata.desktop file under "Icon" and it should 
be recognized by Plasma.

BTW: The file hierarchy of a Plasmoid isn't really well documented anywhere 
that I can find. If anyone can explain it to me I will be happy to document it 
on TechBase.

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

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

Re: Review Request: Kineticscrolling: a zero api approach

2009-10-14 Thread Marco Martin 

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

(Updated 2009-10-14 13:38:20.621815)


Review request for Plasma.


Changes
---

no more removing and adding the filter every time


Summary
---

this is just an experiment that has perhaps a too big disadvantage to be 
practical...
makes use of event filters instead of explicitly forwarding mouse events.
the advantage is that it would be super easy to use and woouldn't be needed to 
export new classes in plasma, there could just be an 
Animator::registerScrollingManager(QGraphicsWidget *) function

the big disadvantage is that is less controllable, so widgets can't decide to 
-not- make use of the kineticscrolling, thing that is quite needed in WebView.


Diffs (updated)
-

  /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 
  /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 
  /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 
  /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 
  /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 

Diff: http://reviewboard.kde.org/r/1840/diff


Testing
---


Thanks,

Marco

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

Re: Review Request: Kineticscrolling: a zero api approach

2009-10-14 Thread Marco Martin 


> On 2009-10-14 12:19:32, Adenilson Cavalcanti wrote:
> > /trunk/KDE/kdelibs/plasma/widgets/webview.cpp, line 66
> > 
> >
> > Is this still required?

nope


> On 2009-10-14 12:19:32, Adenilson Cavalcanti wrote:
> > /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp, line 357
> > 
> >
> > Maybe it pays up to inspect the return value? (from docs: "Returns 
> > false if the event was filtered or if the item is disabled. Otherwise 
> > returns the value that was returned from the event handler.")

do we need to know if it was filtered?
but yes, not scrolling if the widget is disabled is good


> On 2009-10-14 12:19:32, Adenilson Cavalcanti wrote:
> > /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp, line 355
> > 
> >
> > How expensive is to remove/set again the event filter? Is it just 2 
> > function calls or it does some black and deep magic in qt event loop?
> > 
> > My guess is that if it is cheap (not cpu bound), the advantages of the 
> > current implementation (i.e. easy of use for clients) outweigths its 
> > ugliness until we find a better way.

doesn't seem too heavy.
however the same effect can be acieved with a bool state variable that acts 
like a semaphore


- Marco


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


On 2009-10-14 09:23:44, Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1840/
> ---
> 
> (Updated 2009-10-14 09:23:44)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> this is just an experiment that has perhaps a too big disadvantage to be 
> practical...
> makes use of event filters instead of explicitly forwarding mouse events.
> the advantage is that it would be super easy to use and woouldn't be needed 
> to export new classes in plasma, there could just be an 
> Animator::registerScrollingManager(QGraphicsWidget *) function
> 
> the big disadvantage is that is less controllable, so widgets can't decide to 
> -not- make use of the kineticscrolling, thing that is quite needed in WebView.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 
>   /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 
>   /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 
>   /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 
>   /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 
> 
> Diff: http://reviewboard.kde.org/r/1840/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco
> 
>

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

Re: Review Request: Plasma + Qt Kinetic GSoC Project - Attempt 2

2009-10-14 Thread Adenilson Cavalcanti 

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



/trunk/KDE/kdelibs/plasma/animations/animation.h


There are 2 cases where the interface doesn't cover requirements for some 
more complex animations. E.g. for rotation (we need to known the rotation angle 
along with the axis and might to known what is the widget behind the animated 
one, to do the flipping correctly) and pulse (where we need a copy of the 
animated object). Those parameters should have an interface in the upper class 
if we implement a factory, so the user can set the parameters using a pointer 
to Animation instead of the derived class.



/trunk/KDE/kdelibs/plasma/animations/animation.h


See my comment bellow.



/trunk/KDE/kdelibs/plasma/animations/animation.h


It should return a QAbstractAnimation so it covers the case that the 
animation is complex and it really is a QAnimationGroup. Since later the 
::start() method will be called, it should work with both single property 
animation objects and composed animation groups (where more than just 1 
property is transformed).


- Adenilson


On 2009-10-13 15:06:04, makmanalp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1512/
> ---
> 
> (Updated 2009-10-13 15:06:04)
> 
> 
> Review request for Plasma, Aaron Seigo, Alexis Menard, and Adenilson 
> Cavalcanti.
> 
> 
> Summary
> ---
> 
> Okay, this is the "oh cr*p Alexis is leaving Tokamak" version, which means 
> I'm missing a couple of stuff but I want to get it in in time. Sorry about 
> this, but I have school now so I can't give my attention to this as much as I 
> could. What's missing is:
> 
> - Didn't dptr the private members yet because I got stuck trying to figure 
> out how I'd override render() (which would be in AnimationPrivate) in the 
> subclasses such as Grow etc. I guess I could have a function with the same 
> name in AnimationDerivedPrivate but it wouldn't exactly be overriding?
> - Didn't add factory methods for each animation type yet.
> - Didn't map the existing enums to new stuff (eg AppearAnimation etc)
> - Didn't figure out checking animation status / stop and pause etc.
> 
> Now that that's over, here's the good news:
> 
> - Oodles of general tidying up:
> - Moved everything into animations/ so it's neater.
> - Added license headers to everything.
> - Tidied up includes.
> - Split each class into its own file.
> - Added missing getters.
> - Consted as much as I can.
> - No more unnecessary this->es.
> - BaseAnimationElement is now AbstractAnimation.
> - Moved the duration variable (m_duration) down the hierarchy into Animation 
> because setting duration for groups is meaningless.
> - setObject() is called setWidget() now and is moved up the hierarchy into 
> AbstractAnimation since it was doing the same for both Animation and 
> AnimationGroup.
> - render() is no longer what it used to be, it's now a protected pure virtual 
> function in Animation that the subclasses must override. getQtAnimation() 
> does some common checking and then calls the render() of that subclass. 
> getQtAnimation() is the exposed interface.
> - getQtAnimation() takes a parent object to pass to Animations and 
> AnimationGroups to use when generating the QPropertyAnimations and 
> QAnimationGroups. When getQtAnimation() is used on AnimationGroups, the 
> generated sub-animations are now owned by the generated group.
> - The MovementDirection enum is now called AnimationDirection and is in 
> plasma.h
> 
> This is the essence of all changes. Documentation might be lagging behind, 
> I'll try to clean it up later on and comments on what's wrong are much 
> appreciated.
> 
> Thanks a lot in advance!
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1018731 
>   /trunk/KDE/kdelibs/plasma/animations/abstractanimation.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/abstractanimation.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animation.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animation.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animationgroup.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animationgroup.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/expand.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/expand.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/fade.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/fade.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/grow.h PRE-CREA

Re: Review Request: Kineticscrolling: a zero api approach

2009-10-14 Thread Adenilson Cavalcanti 

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



/trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp


How expensive is to remove/set again the event filter? Is it just 2 
function calls or it does some black and deep magic in qt event loop?

My guess is that if it is cheap (not cpu bound), the advantages of the 
current implementation (i.e. easy of use for clients) outweigths its ugliness 
until we find a better way.



/trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp


Maybe it pays up to inspect the return value? (from docs: "Returns false if 
the event was filtered or if the item is disabled. Otherwise returns the value 
that was returned from the event handler.")



/trunk/KDE/kdelibs/plasma/widgets/webview.cpp


Is this still required?


- Adenilson


On 2009-10-14 09:23:44, Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1840/
> ---
> 
> (Updated 2009-10-14 09:23:44)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> this is just an experiment that has perhaps a too big disadvantage to be 
> practical...
> makes use of event filters instead of explicitly forwarding mouse events.
> the advantage is that it would be super easy to use and woouldn't be needed 
> to export new classes in plasma, there could just be an 
> Animator::registerScrollingManager(QGraphicsWidget *) function
> 
> the big disadvantage is that is less controllable, so widgets can't decide to 
> -not- make use of the kineticscrolling, thing that is quite needed in WebView.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 
>   /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 
>   /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 
>   /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 
>   /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 
> 
> Diff: http://reviewboard.kde.org/r/1840/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco
> 
>

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

Re: Review Request: Kineticscrolling: a zero api approach

2009-10-14 Thread Marco Martin 

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

(Updated 2009-10-14 09:23:44.263181)


Review request for Plasma.


Changes
---

events protected.
parent is a qgraphicswidget


Summary
---

this is just an experiment that has perhaps a too big disadvantage to be 
practical...
makes use of event filters instead of explicitly forwarding mouse events.
the advantage is that it would be super easy to use and woouldn't be needed to 
export new classes in plasma, there could just be an 
Animator::registerScrollingManager(QGraphicsWidget *) function

the big disadvantage is that is less controllable, so widgets can't decide to 
-not- make use of the kineticscrolling, thing that is quite needed in WebView.


Diffs (updated)
-

  /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 
  /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 
  /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 
  /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 
  /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 

Diff: http://reviewboard.kde.org/r/1840/diff


Testing
---


Thanks,

Marco

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

Transforming panels in fullscreen effects (was activities overview, take N)

2009-10-14 Thread Martin Gräßlin 
cc-ing kwin list. I said it before, I say it again: we need a workspace 
mailinglist

Am Dienstag 13 Oktober 2009 22:08:37 schrieb Aaron J. Seigo:
> On October 13, 2009, Martin Gräßlin wrote:
> > Am Dienstag 13 Oktober 2009 20:19:44 schrieb Aaron J. Seigo:
> > > slightly off-topic: what would you think about making the "show windows
> > > / desktops zoomed out in some presentation" type effects not include
> > > the desktop panels?
> > >
> > > the reasons include:
> > >
> > > * the panel often has things like the tasks widget which shows all the
> > >  windows but may also show only for the "current" desktop ... which
> > > doesn't work very nicely in overview modes
> > >
> > > * if the panels stayed un-transformed, it could give a really
> > > interesting visual effect where the "desktop area" gets transformed and
> > > the panel "overlays" remain as they are
> >
> > if you want to try it: the present windows effect has an option to not
> > hide the panel and the cube desktop switch animation does not hide the
> > panels by default and that one looks really slick.
> 
> just tried both of these options, and i have to agree: it looks much
>  slicker with the panels remaining where they are.
> 
> i think the desktop cube would look nicer and more consistent with the
> switcher without the panels included as well.
fixed the switcher :-)
> 
> > > * it would make some of these effects more consistent with the alt-tab
> > > box which does not transform the panels either
> >
> > Box Switch keeps them untransformed and the more fancy effects fade them
> >  out. I think it would be possible to keep the panel in place instead of
> >  fading it out.
> 
> could the kwin devs consider make it a design guideline to not include
>  panels in such effects but instead leave them untransformed?  it just
>  looks/feels so much more ... nicer.
yeah I think we could make that a design guideline. Just for the fun of it I 
tried it on two effects:
 * desktop grid: 
http://picasaweb.google.de/lh/photo/h0wjRlQ0m3SLQWlz8XYTHA?feat=directlink
 * flip switch: 
http://picasaweb.google.de/lh/photo/fUqlyPd2lg5XpUXFmZh3Tg?feat=directlink
> 
> the only draw back would be if we ever make panels per-desktop. but then i
> guess the heuristic could be "don't transform panel windows that are also
>  on all desktops"?
That heuristic would break the desktop grid effect with the changes in the 
above screenshot. But as Plasma does not yet have that feature we don't have 
to worry about it.


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