D22223: Seek to end as mpris next action

[Markus Ebner]

seijikun planned changes to this revision.
seijikun added a comment.


  Oh, I'm sorry. I had a look in this list here 
 and 
thought, that all methods without a warning triangle are good to go.
  I guess this one 
 
would be the way to go, then?
  
  > Also, you never announce that we can go next (and I don't think we can 
tell), so this shouldn't even work, but that it does is a bug.
  
  I noticed, that the Next-Button worked, even though the GUI-buttons in the 
MPRIS tray are disabled, but I couldn't find out how to announce that it's 
supported.
  
  > A website should provide a nexttrack callback if it supports changing 
tracks, which YouTube does while watching playlists.
  
  Is that what lines 217 to 226 are for, because that does not seem to work for 
me in Firefox? Neither with normal videos, nor in playlists.

REPOSITORY
  R856 Plasma Browser Integration

REVISION DETAIL
  https://phabricator.kde.org/D3

To: seijikun, broulik
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D22223: Seek to end as mpris next action

[Markus Ebner]

seijikun created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
seijikun requested review of this revision.

REVISION SUMMARY
  Most pages where the mpris functionality is used will probably have an 
auto-continue feature for when the end of a media is reached.
  Now, if mpris sends the next-signal, seeking to the end of the video is 
probably the most reliable way of continuing to the next in line.
  Works like a charm on YouTube.
  
  Sorry if anything is wrong, this is my first contribution.

REPOSITORY
  R856 Plasma Browser Integration

REVISION DETAIL
  https://phabricator.kde.org/D3

AFFECTED FILES
  extension/content-script.js

To: seijikun
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

Calculator

[Markus Döbele]

Hy Plasma Team,

I use the calculator mini program and I would like to suggest an
improvement.
It would be nice if I could copy numbers from e.g. a website to the
calculator input field
then make a calculation and afterwards copy the resulting number form the
calculator to e.g. an editor.

Thanks,
Markus

[Differential] [Commented On] D2983: Support solid colour and image backgrounds with a configurable background colour in the SDDM theme

[markuss (Markus Slopianka)]

markuss added a comment.


  This patch modifies an existing file. Removing the original copyright is 
illégal.

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D2983

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: bgupta, davidedmundson
Cc: markuss, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

[Powerdevil] [Bug 350365] Battery monitor in tray randomly shows there is no battery

[Markus via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=350365

--- Comment #4 from Markus <darkvis...@gmx.eu> ---
I just upgraded to Kernel 4.6final... and still have that issue. Still unsure
if this is a kernel or KDE issue. Any help to solve this issue is welcome. I
really don't want to logoff/login just to fix the battery indicator.

No comment from the devs at all?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Powerdevil] [Bug 350365] Battery monitor in tray randomly shows there is no battery

[Markus via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=350365

--- Comment #3 from Markus <darkvis...@gmx.eu> ---
I can confirm this problem on a Lenovo Thinkpad Yoga12 with Slackware64-Linux
14.2/-current and KDE Framework 5.21/Plasma 5.6.3 and Application 16.04.0.
UPower is at version 0.9.23. Kernel is 4.6rc6.

Here is my output from upower --dump:

This is the output when the battery is not detected directly after i booted
into Plasma5:

Device: /org/freedesktop/UPower/devices/line_power_ACAD
  native-path:  ACAD
  power supply: yes
  updated:  Sa 07 Mai 2016 05:41:04 CEST (28 seconds ago)
  has history:  no
  has statistics:   no
  line-power
online: no

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:  BAT0
  vendor:   SMP
  model:45N1707
  serial:   1583
  power supply: yes
  updated:  Sa 07 Mai 2016 05:41:10 CEST (22 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
energy:  42,23 Wh
energy-empty:0 Wh
energy-full: 49,7 Wh
energy-full-design:  47,06 Wh
energy-rate: 9,361 W
voltage: 15,681 V
time to empty:   4,5 hours
percentage:  84%
capacity:100%
technology:  lithium-polymer
  History (charge):
146259246984,000discharging
146259246685,000discharging
14625924640,000unknown
  History (rate):
14625924699,361discharging
14625924668,570discharging
14625924640,000unknown

Daemon:
  daemon-version:  0.9.23
  can-suspend: yes
  can-hibernate:   yes
  on-battery:  yes
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:   no


This is the output when the battery is detected after logging out and back in:

Device: /org/freedesktop/UPower/devices/line_power_ACAD
  native-path:  ACAD
  power supply: yes
  updated:  Sa 07 Mai 2016 05:31:23 CEST (517 seconds ago)
  has history:  no
  has statistics:   no
  line-power
online: no

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:  BAT0
  vendor:   SMP
  model:45N1707
  serial:   1583
  power supply: yes
  updated:  Sa 07 Mai 2016 05:39:59 CEST (1 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
energy:  42,4 Wh
energy-empty:0 Wh
energy-full: 49,7 Wh
energy-full-design:  47,06 Wh
energy-rate: 8,216 W
voltage: 15,832 V
time to empty:   5,2 hours
percentage:  85%
capacity:100%
technology:  lithium-polymer
  History (rate):
14625923998,216discharging
14625923698,435discharging
14625923398,787discharging
14625923097,930discharging

Daemon:
  daemon-version:  0.9.23
  can-suspend: yes
  can-hibernate:   yes
  on-battery:  yes
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:   no


This is the output when the battery is not detected and i plugin the power
cable. The icon does not show "Charging"!:

Device: /org/freedesktop/UPower/devices/line_power_ACAD
  native-path:  ACAD
  power supply: yes
  updated:  Sa 07 Mai 2016 05:41:42 CEST (11 seconds ago)
  has history:  no
  has statistics:   no
  line-power
online: yes

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:  BAT0
  vendor:   SMP
  model:45N1707
  serial:   1583
  power supply: yes
  updated:  Sa 07 Mai 2016 05:41:48 CEST (5 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   charging
energy:  42,14 Wh
energy-empty:0 Wh
energy-full: 49,7 Wh
energy-full-design:  47,06 Wh
energy-rate: 9,196 W
voltage: 16,051 V
time to full:49,3 minutes
percentage:  84%
capacity:100%
technology:  lithium-polymer
  History (charge):
146259246984,000dischargin

[Breeze] [Bug 350434] SDDM theme does not use Breeze user icons

[Markus S .]

https://bugs.kde.org/show_bug.cgi?id=350434

--- Comment #3 from Markus S. kamika...@web.de ---
(In reply to David Edmundson from comment #2)

 This path overridable in sddm.conf

Why not then make the KCM change the path on theme change?
Would this also fix displaying custom per-user icons set in System Settings?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Breeze] [Bug 350434] New: SDDM theme does not use Breeze user icons

[Markus S .]

https://bugs.kde.org/show_bug.cgi?id=350434

Bug ID: 350434
   Summary: SDDM theme does not use Breeze user icons
   Product: Breeze
   Version: 5.3.2
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: kamika...@web.de

Compare
http://static.davidedmundson.co.uk/blog/display_managers_finale/breeze_login_screen.png
to
http://i1-news.softpedia-static.com/images/news2/KDE-Plasma-5-1-0-Brings-Back-Some-Old-Features-462226-6.jpg

The user image in the first screenshot is not the Breeze one.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Breeze] [Bug 350434] SDDM theme does not use Breeze user icons

[Markus S .]

https://bugs.kde.org/show_bug.cgi?id=350434

Markus S. kamika...@web.de changed:

   What|Removed |Added

 CC||kamika...@web.de,
   ||k...@davidedmundson.co.uk

--- Comment #1 from Markus S. kamika...@web.de ---
CC'ing David as he's listed as the author.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [kde-promo] Plasma Next Naming

[Markus Slopianka]

Am Donnerstag, 23. Januar 2014, 11:36:12 schrieb Martin Klapetek:

 Given that we're dropping the name KDE from the working desktop almost
 completely and changing it for Plasma (so you'll no longer run KDE on
 your PC but you'll run Plasma) I hope this will prevent that.

Nothing will be prevented if the Plasma maintainers actually opt for August 
2014 Update of the May 2014 release of Plasma by KDE.


 If they
 call it Plasma 2 in the media, I don't care that much as long as it's clear
 what it actually is and that it has a clear relation to KDE.

Just yesterday I saw this blog post by our own KDE guys at Fedora and I quote:

If you install kde5-workspace package, you can also have a sneak peek at what 
Plasma guys are doing for Plasma 2! Your display manager should have “KDE 
Plasma Workspace 2” entry in session types list, which will log you into 
Plasma 2 session.
http://www.progdan.cz/2014/01/kde-frameworks-5-and-plasma-2-on-fedora/

KDE5 Workspace, Plasma Worspace 2, and Plasma 2 all mixed in a single 
paragraph. Oh, and no word about these things just being tentative names.

Apparently our own guys are confused by the whole situation and that's even 
before any public announcement of throwing even more confusing date-based 
version numbers into the mix.

The media, btw, also reads Planet KDE. Therefore any informal developer 
slang is adopted by them as well.
August 2014 Update of the May 2014 release of Plasma by KDE is NOT sane 
marketing.

Oh, and btw: The plasma2 package has the version number 4.90.1 over there at 
Fedora. Plasma 2 version 4.90.1 ... so unconfusing and by no means a road to 
KDE5...

Markus

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

Re: [kde-promo] Plasma Next Naming

[Markus Slopianka]

Am Mittwoch, 22. Januar 2014, 18:24:08 schrieb Martin Klapetek:

 Let me give a different example from the same area - do you remember
 Windows Longhorn? Everyone was talking about Longhorn always and how
 revolutionary and new it will be...and then, Windows Vista came out. From
 the very same company, Windows Vienna turned into Windows 7. And many
 others could be found.

And Microsoft also had the MSN Messenger. Later .NET Messenger, later Windows 
Live Messenger, Microsoft Messenger, and Windows Messenger.
Everybody kept calling it MSN Messenger, just as almost everybody today STILL 
says KDE4. Even within our very own community KDE4 is still used and some 
even use KDE5:
https://projects.kde.org/projects/kde/kdebindings/python/pykde5

Oh, and btw: Microsoft went back to version numbers (7, 8, 8.1,...) because 
they are not confusing. Plasma 2.0.3 is easy (people using computing devices 
encounter such version numbers all the time). August 2014 Update of the May 
2014 release of Plasma by KDE is not easy.
All you achieve with such a hard to comprehend version number is that people 
will call it KDE5.

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

Re: [kde-promo] Plasma Next Naming

[Markus Slopianka]

Am Freitag, 17. Januar 2014, 18:37:27 schrieb Ivan Čukić:

 It seems we mostly agree on the Plasma Year Month, and Plasma by KDE*
 naming, at least in principle. Which is awesome.

Considering that we already released official announcements de facto using
Plasma (Workspaces) 2 as branding for almost one year[1], I cannot see any 
positive thing about changing version numbering once again.

In addition there were countless blog posts published also through our
Planet KDE aggregator using Plasma (Workspaces) 2.

You may rightfully argue that Plasma2 is just a codename but since the Dot 
stories did not write Next generation workspaces, tentatively called Plasma2 
in the first sentence of every single article touching that topic, the 
de facto branding already exists.

Using an entirely new versioning is just grist to the mill of all the people 
who actually believe that following our upstream branding makes no sense in 
the first place because it'll be changed a few months down the road anyway 
(a few of them write about FOSS stuff on heise.de).

I suggest you guys just use Plasma 2.0, Plasma 2.1, ...
People have no problems understanding version numbers as long as they are 
coherent.

Markus

[1]
http://dot.kde.org/2013/04/24/plasma-pow-wow-produces-detailed-plans-workspace-convergence
http://dot.kde.org/2013/09/04/kde-release-structure-evolves
http://dot.kde.org/2013/12/09/early-kde-plasma-2-images-now-available
http://dot.kde.org/2013/12/20/plasma-2-technology-preview

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

Re: Media Query: KDE's Support For Android Tablets

[Markus Slopianka]

As far as I'm aware, existing MTP access methods (DigiKam, Amarok) were seen as 
good 
enough, so nobody so far found the need to write a MTP KIO Slave to mount MTP 
devices in 
Dolphin. (Well, not exactly true: In 2007 a 3rd party wrote it but it died in 
alpha stage:
http://kde-apps.org/content/show.php/kio_mtp?content=55618 )
I don't have an MTP device so I can't tell how good Amarok and DigiKam in that 
respect.

Markus

On Dienstag 22 November 2011 11:44:38 Swapnil Bhartiya wrote:
 Hi Aaron,
 
 I have been trying to reach you but just can't get hold of you at all.
 Thus posting it here.
 
 I represent Muktware.com and I am working on a story about Android
 support in Linux. While Gnome can detect and mount the Android 3.x +
 tablets, allowing users to drag/drop content to the tablets and crate
 folders (it can't see content inside folders). So, at least a user can
 copy content -- movie/music to the tablet.
 
 On the contrary KDE mounts it as a Camera and can't see content on the
 tablet, can create folders and can't drag/drop or paste content in the
 tablet which makes it hard for a user to use KDE to manage tablets.
 
 What is the reason KDE can't mounts Android Honeycomb tablets which use
 MTP? With increasing use of tablets, what is the KDE team doing to fix
 this problem?
 
 Best
 Sapnil Bhartiya
 ___
 Plasma-devel mailing list
 Plasma-devel@kde.org
 https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: ScreenSaver and KDE Plasma 4.8?

[Markus Slopianka]

On Samstag 01 Oktober 2011 10:52:04 Marco Martin wrote:
 that's what the support of plamoids on screensaver is for ;)

I already understood that but as a screensaver (you know: to actually save 
screens from 
damage, incl. LCDs) a few additional features are required. At the very least, 
plasmoids 
would need to move.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: ScreenSaver and KDE Plasma 4.8?

[Markus Slopianka]

On Samstag 01 Oktober 2011 12:36:12 Aaron J. Seigo wrote:

 we should also stress that if things like OpenGL screensavers are important
 enough to people, that support for things to draw moving things on screen
 when locked can be created anew.

We already have KWin effects – even gimmicky ones like Snow. Apart from some (I 
imagine 
relatively simple to implement) call “stop effect XY on any input” isn't that 
enough?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: ScreenSaver and KDE Plasma 4.8?

[Markus Slopianka]

On Samstag 01 Oktober 2011 14:10:39 Marco Martin wrote:

 for saving from damage, there is a thing called power saving :p

Doesn't help the people who want a huge clock as screensaver without damaging 
their 
displays. It has to move.
A Plasma containment whose widgets can float and bounce from another (like soap 
bubbles) 
should be enough.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The case for a kdelibs 4.8

[Markus Slopianka]

On Donnerstag 29 September 2011 18:11:12 Kevin Kofler wrote:

 Wait and see the chaos that will come up when users open their Help/About
 in Konqueror and it tells them that they're using Konqueror 4.8.0 under
 KDE 4.7.6. (And yes, it still says only KDE in 4.6.5, I haven't checked
 4.7 or 4.8 for whether that's fixed there.)

True but only in one line ans the explanation that the Dev Platform is meant, 
is written 
in About KDE.
That said, I'm toying with ideas about a complete redesign of the About window 
for KF5. 
When/If I come up with a somewhat presentable mock-up, I'll post it and 
hopefully a 
programmer implements something based on that.
A completely new About window will also fix legacy issues like that string.


  and strangely shipping Kontact 4.4.11 with SC 4.5+ was also not confusing
  to most users.
 
 Actually, that was (and still is) quite confusing to many users. Look at
 the mailing lists and forums.

I really don't think it was the majority and the Kontact case is user-visible 
software 
unlike Frameworks/Platform which normal users usually do not care about.
MS Office 2003 also ran on Windows 2000 and the majority of users had no 
problems 
understanding that. ;-)

And we better continue to educate our users that Platform version and Workspace 
version 
does not need to match.
I have yet to see any ideas for KDE Plasma Desktop 5.0 which means that maybe
KPD 4.9 in summer 2012 will require KF 5.0. So unless someone completely 
rewrites KPD for 
the summer release (maybe basing it on Plasma Active) and therefore justifying 
a major 
version jump to 5.0, as a promo person I'd rather educate our users now before 
we see 
people (at worst: reviewers) complaining that KDE 5 looks just like KDE 4.8.

(As a side note I also think that KDE Applications should completely lose their 
version 
number and get date-based versioning because any application can get major new 
features at 
any time – see Dolphin 2.0 in SC 4.8.)


 Fedora 15 actually has KDE SC 4.6.x, not 4.7.

Just a few days ago someone on your mailing list claimed otherwise but 
whatever... that's 
not the main topic here.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: ScreenSaver and KDE Plasma 4.8?

[Markus Slopianka]

Is anybody aware of empiric studies for what (if at all) people use 
screensavers these 
days?
Personally I'd expect clock, news headlines, and photo slideshows to be the top 
answers.
QML replacements should be available for the top uses once the xscreensaver 
code is 
dropped. (IMHO at least.)

On Donnerstag 29 September 2011 22:14:59 Martin Gräßlin wrote:
 Hi all,
 
 the work on the new screen locker implementation is nearly done (I can
 unlock again :-) and that brings me to an issue where I wanted to have
 more opinions: screensaver.
 
 What's important to see: screen locker and screen saver are two different
 things mixed together for historic reasons. The screen locker implements
 the security aspect of preventing someone else to use the screen. The
 screen saver shows an animation so that the hardware is not damaged. For
 some reasons those two things come together and also the old
 implementation is together.
 
 The new implementation is about screen locking and not saving. My idea is
 to improve the screen locking experience which kind of looks like 1995.
 Let's reuse the background of the splash screen and show a nice QML-ified
 dialog for unlocking. Instead of showing the unlock dialog only when
 someone moves the mouse, it would always be present. If the screen has
 been locked for long time DPMS kicks in and disables the screen (yeah for
 energy saving).
 
 This means there is no more place for screen savers. It would just not be
 visible. This also means we don't have the Plasma Screensaver any more
 (this might be fixable by using a Plasma containment as the screen locker
 in the first place).
 
 But when compositing is turned off, you currently get the plain old
 implementation including screen savers. And I don't want to change that
 code.
 
 So there are some solutions:
 * drop screensaver support altogether, probably would create some troubles
 as evil KDE removed screensavers * add Plasma widget support to new screen
 locker implementation but drop screensaver support (same problems as first
 option)
 * add a fallback to legacy mode if a screen saver is configured. Means same
 security problems are present again which were the reason for moving the
 screen locker to KWin in the first place
 
 Personally I would prefer option 1 with a later implementation of option 2
 (if time allows even for 4.8). Option 2 needs support from Plasma hackers
 who are all currently fixing up a tablet ;-)
 
 A possible solution for the user issue could be to clearly advertise that
 security reasons are responsible for removing screensaver support. Also an
 improved login process I have in my mind: with only one user configured do
 not stop at KDM but log in directly with screen locked. The unlock dialog
 would then be shown after the complete session has been loaded, so instant
 usage after typing in the password.
 
 So looking forward to your comments on the subject.
 
 Cheers
 Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The case for a kdelibs 4.8

[Markus Slopianka]

On Donnerstag 29 September 2011 14:01:50 Kevin Kofler wrote:

 2. It will be confusing to our users, and even to some packagers, to have a
 KDE SC 4.8 on kdelibs 4.7.

Since almost exactly 2 years we (esp. the promo team) are communicating that 
Platform/Frameworks, Applications and Workspaces are three separate products 
that just 
happen to be shipped on the same date.

One of the reasons why the rebranding still didn't get to everybody is that 
some 
distributions (mostly Fedora!) still spread the wrong message about some “KDE 
4.7” to its 
users. (see eg. 
https://fedoraproject.org/wiki/SIGs/KDE/KDE47Packaging#KDE_4.7_Packaging )

Users of other distributions do not have such problems and strangely shipping
Kontact 4.4.11 with SC 4.5+ was also not confusing to most users.


 The rule so far has always been that the kdelibs
 version must be the same as the KDE SC version.

There is no rule – at most a common practise and that was broken as well after 
Fedora 15 
has packages for SC 4.7 with Kontact 4.4.


 Changing this will also break all our Fedora KDE SC specfiles

Then fix your specfiles. AFAIK Fedora is also the last big distribution that 
still has 
monolithic packages like kdemultimedia, kdenetwork, and so on.
Take the opportunity to fix that as well.

openSUSE doesn't seem to have problems packaging 4.8 already:
https://build.opensuse.org/project/show?project=KDE%3AUnstable%3ASC


 And what will kde4-config --kdeversion output? The version of kdelibs?
Of course. What else? Want to see the Plasma version, enter plasma-desktop 
--version
If you want the version of Dolphin, enter dolphin --version and so on.

 Users are going to be confused: Hey, I installed KDE SC 4.8, why does it
 say 4.7?

Then you refer them to Wikipedia which holds that info since quite some time:
https://secure.wikimedia.org/wikipedia/en/wiki/KDE_Software_Compilation_4#KDE_Plasma_Workspaces_and_Applications_4.8


 you will break Fedora packages even further.
Then – again – fix Fedora.

 The main reason that
 was given for dropping kdelibs 4.8 is that this means one less branch to
 worry about for the people working on kdelibs, but the people who'd work
 on 4.8 and 5.0 are NOT the same people!

Do you hereby declare that Red Hat will provide resources to create KDE 
Platform 4.8 and 
an cherrypick useful developments from the frameworks branch to Platform 4.8?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Menubar in Workspace 4.8

[Markus Slopianka]

On Sonntag 25 September 2011 18:24:40 Marco Martin wrote:

 i'm quite against the panel, it promotes the menubar to an importance it
 lost since ages, while i'm really in favor of burying it into a menu under
 the windeco, since this decreases its importance ;)

There are no window decorations in Plasma Netbook.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Menubar in Workspace 4.8

[Markus Slopianka]

On Sonntag 25 September 2011 17:58:18 Martin Gräßlin wrote:

 * license of required Canonical library is incompatible with license used by 
 decoration
 API (GPLv3-only + Copyright Assignment (personal notice: I rather reinvent 
 the wheel
 in chinese wall style than contributing to a GPLv3 only + CA library) vs BSD)

Not that different from how Qt was licensed for years and even with open 
governance Qt 
contributions will require giving Nokia the exclusive right to relicense (as 
opposed to 
LGPL or Apache License for everyone).


 * It needs Qt 4.8. Currently we still depend on Qt 4.7
 and I don't know whether Qt 4.8 will become a requirement for KDE 4.8.

Canonical maintains the patch for the Qt 4.7 series. It can be applied to 
qt-copy and 
declared mandatory for KR 4.8, therefore distributions would have to ship it in 
order to 
have a compliant KR 4.8.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Menubar in Workspace 4.8

[Markus Slopianka]

On Montag 26 September 2011 14:27:19 Martin Gräßlin wrote:

  qt-copy is dead and because of that no option.
Quite frankly, I wouldn't be surprised if we'll see a LibreOffice-like fork of 
Qt in the 
future because of Nokia's CLA for Qt contributions...


  Btw what is KR?

Short version of the term KDE Releases the promo team came up with a year or 
so ago 
(usually in headlines as KDE ships 4.6 releases of Workspaces, Platform, and 
Applications or something like that). The openSUSE-KDE community uses the KR 
abbreviation 
even longer because the releases are published in the KDE:/Release/4x 
repositories.
At lest in openSUSE mailing lists everyone uses KR as opposed to eg. SC 4.6 
which is the 
reason I didn't even think about the term when I typed my mail. It just came 
naturally.
Sorry for the confusion.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: Remove Opacity from Alt+F3 menu

[Markus Slopianka]

On Donnerstag 18 August 2011 19:20:08 Martin Gräßlin wrote:
 Hi all,
 
 just an idea I had today: do we really need the opacity menu in the Alt+F3
 menu?

Don't know if you need it, I use it regularly. Wouldn't mind moving it into the 
Advanced 
sub-menu, though.

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

Re: Setting a plasmoid on desktop border

[Markus Slopianka]

I don't get the problem. If you want a contact list integrated into Plasma 
Desktop, add a 
panel and drop the list onto it, like it's already possible since ages with 
Lancelot's 
contacts IM plasmoid.
With a panel you can set size, visibility, etc.
That has also the advantage that you can set how windows react to it. Eg it can 
act as 
edge of the workspace, meaning that maximized windows don't overlap it.

Markus

Am Freitag 01 Juli 2011, 16:49:48 schrieb Francesco Nwokeka:
 Hi devs.
   As suggested today by sebas, I'm writing to the ML to ask info about a
 problem I have and what you suggest would be the best way to solve this.
 The effect I want to achieve is the same as the cashew icon. That is being
 attached to the desktop borders or being able to know the desktop
 boundaries.
 I was told that to be able to achieve this, I would have to add my plasmoid
 to the KDE desktop containment and then set my plasmoid to stay on the
 edge.
 Another option given to me was that I were to write my own containment. But
 so would this involve writing code for the Plasma desktop.
 
 Do you guys have any proposals?
 
 P.S - Attached to the mail is one of my mockups so you can get the idea I
 have in mind.
 
 Thanks,
   Francesco

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

(Mockup) Re: [RFC] Enforcing Compositing

[Markus Slopianka]

Am Montag 21 Februar 2011, 07:24:33 schrieb Martin Gräßlin:

 I don't want to remove the workaround, I only do not longer want to expose
 it in the UI. That's a big difference. And I really like Markus' idea with
 the None compositing backend.

I took a few minutes of time to squeeze out a mockup:
http://kamikazow.files.wordpress.com/2011/02/kwin-mockup.png

To my own surprise it reduces clutter to a greater degree than I thought it 
would while 
also not losing any features.

As a side note: In the All effects tab the categories are sorted 
alphabetically.
While in theory that sounds good, seeing Tools above Window Management 
makes no sense.
Tools is probably no used by anyone besides a handful of people who develop 
KWin and 
benchmarking geeks.

I'd also merge a few effect entries that are mutually exclusive: There are at 
least two 
Minimize effects which could be merged into one entry with Normal or Genie 
as radio 
buttons in the effect's config window.
Same for closing windows, magnification lens, etc.

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

Re: [RFC] Enforcing Compositing

[Markus Slopianka]

 Since 4.2 we have enabled OpenGL based compositing by default and I was
 wondering if in 4.7 we should go the next step: disabling the possibility
 to turn compositing off if supported.
 
 With Mesa 7.10 it seems that the driver problems (Mesa 7.8) which hit us in
 4.5 are finally gone
 (...)
 What do you think about this idea?

Well, it's hard to predict the future. Drivers could get regressions again.

I think the problem is less the ability to turn off compositing, it's the 
wording.
IMO the Enable desktop effects checkbox should only apply to the actual 
effects but not 
the compositing support. I've seen people in forums who are not interested in 
shadows, 
transparent windows etc. They dislike eye candy. What they don't get in some 
cases is 
that enabled compositing and all effects turned off should be better in most 
situations 
(unless the driver is broken).

For disabling compositing, people could use the Advanced tab with the new 
option None 
added to the Compositing type drop down menu.

 I would keep
 * the shortcut to suspend compositing
 * the dbus call to toggle compositing (might be useful for games and so on)

Could the shortcut call dbus? What I experienced when occasionally turning off 
composite 
support manually is that the shortcut does not flip the composite switch 
plasmoid and 
the shortcut always overrules the plasmoid which means that I can't turn it on 
again using 
the plasmoid.

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

Plasma desktop scripting examples

[Liebe Markus (RtP2/TEF72)]

Hi there,

I just tried to have a look at the desktop-scripting examples which are 
referenced from the techbase article on scripting 
(http://techbase.kde.org/KDE_System_Administration/PlasmaDestkopScripting)

It seems to me that the given link 
http://websvn.kde.org/trunk/KDE/kdeexamples/plasma/javascript/plasma-shell-scripting/
 is not valid anymore.
Do you have another link where the examples are viewable?

Regards,
Markus

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

Re: Featurlets for 4.7

[Markus Slopianka]

Am Sonntag 13 Februar 2011, 20:21:56 schrieb Aaron J. Seigo:

  2. Have a custom wallpaper position option.  This would let you set
  the position and scaling in both horizontal and vertical dimensions,
  either to presets like align top or bottom, or to custom values in
  pixels.  This is useful for people who want to have one wallpaper span
  multiple desktops, they can set the same image but show different
  parts of that image.
 
 -1; there are better ways of acheiving that, e.g. actually dividing up the
 image in a proper, competent image editor.

One of the advantages of using many different operating systems is to getting 
to know some 
nifty tricks for certain features.
BeOS had a move (not scale) wallpaper feature and it was solved very well:
In the fake monitor thumbnail (Plasma had this until 4.4 or 4.5) one could 
simply drag and 
drop the image to move its position.
I don't know how many people used that feature (I didn't) but how it was 
implemented was 
unobtrusive.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Problems with getting Krunner tutorial from techbase right

[Liebe Markus (RtP2/TEF72)]

Hi there,

I am following the tutorial on techbase to create a krunner plugin.
Up to now I have succeeded in building the lib, but not in actually enabling 
the new krunner plugin.

The details are in the kde forum:
http://forum.kde.org/viewtopic.php?f=64t=93266

Do you have any hints for me on how to enable my plugin?

KDE: Plattform-Version 4.4.5 (KDE 4.4.5) release 272

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

Re: the next step on the desktop

[Markus Slopianka]

Am Dienstag 01 Februar 2011, 13:17:51 schrieb Sebastian Kügler:

 Actually, Aaron expressed my thoughts about your comments exactly.

If that's the case, you guys really should work on your self esteem. Just 
because someone 
tells his opinion he certainly does not necessarily demand his opinion to turn 
into 
reality as if you guys were his slaves.
My initial mail does not contain a single word of harsh language or a demand of 
any kind.
OTOH Aaron's mail implied lots of negative stuff about me that cannot be 
farther from the 
truth.


 It's not
 about calming down, but about having a useful discussion among Plasma
 developers. People don't just take part to advance their own agenda, we're
 having this discussion to determine direction.

I stand by my opinion that turning the focus towards Activities benefits mostly 
the kind 
of user who uses many applications simultaneously. If you agree: Fine. If not: 
The world 
doesn't collapse either.
I never have and never will bitch about defaults that may not suit my taste, 
just as I 
never bitched about my Plasma Netbook mockup from a few months ago not being 
received 
well.

Believe it or not: Whatever you will come up with, I'll stay grateful for your 
work.

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

Re: the next step on the desktop

[Markus Slopianka]

Dude, calm down a little. I was blaming no one of anything.
You need to understand that when somebody simply states what he observes (that 
programmers 
with many programs and windows open tend to like Activities more than people 
who execute 
only 3 applications) it's not an insult against anyone.
In fact I feel it's perfectly valid to scratch an itch of people who tend to 
execute many 
applications.
You asked for comments and I commented. So don't be a bitch just because my 
opinion 
differs from yours!

Am Montag 31 Januar 2011, 20:37:22 schrieb Aaron J. Seigo:
 On Sunday, January 30, 2011, Markus Slopianka wrote:
   let's try something big and new. let's make that Big Move and step away
   from ~/Desktop.
  
  Frankly, I like my dumping ground.
 
 and you can retain it. nobody is taking it away from you. even though i
 personally think you'd find far better ways of working if you forced
 yourself away from the comfortable known, i'm not selfish enough to make
 you do that :)
 
   my proposal is this:
   
   * by default, Search and Launch on the desktop
  
  What do you mean by that? Full screen SAL like on Plasma Netbook? Then
  one could just use that.
 
 go compare the netbook shell with the desktop shell and you'll find that
 they differ far, far more than just in the use of SAL. due to those
 differences, just use Plasma Netbook is absurd.
 
  As long as KDE's file search and indexing mechanism is still broken
  http://kdeatopensuse.wordpress.com/2011/01/30/opensuse-11-4-kde-testing/
  , I see more frustration than benefit. I could be wrong, though.
 
 wtf does file indexing have to do with SAL?
 
   * improve the tasks widget to have some of the nice features of widgets
   like smooth tasks with the mouse over highlights
  
  I'd be happy if I could disable the scroll wheel for starters...
 
 i've outlined numerous times what such a patch that would be accepted would
 look like. so far nobody has felt like stepping up and scratching their
 itch.
 
   * an activities widget (i'll hapilly write it) that sits next to the
   app launcher and when clicked brings up the actvities manager
   * an activities switcher as a kwin effect (!)
   * have all activities avaiable in kactivitmanagerd, even if they are
   stopped in plasma-desktop
  
  It seems to me that programmers with their fully cramped task bars (IDE,
  terminals, debuggers, SCM frontends,...) are bigger fans of activities
  than the common persons with music player and browser open alone and --
  if they are cutting edge -- even separate chat and mail clients.
 
 let me be frank with you: when someone blames us developers for catering to
 our own needs and so that's why things must obviously suck in some way or
 another, it really bugs me. you know why? because what you just wrote there
 is a pile of rubbish. we hear back fairly regularly from people in a
 multitude of differing situations that use activities and have even come
 to rely on them. but no, you don't like them and/or see the need for them
 so then, ipso facto, it must be something the developers have done just
 for ourselves with no other reason or research having been done, right?
 
 do you even know where the idea for activities came from? good old fashion
 field research with people who use their computers to do content creation.
 yes, that isn't the average web browser centric user, but they can very
 handily ignore activities altogether if they wish as they are not in their
 way at all.
 
 but of course, we should all stop what we're working on because it's so
 
 obviously unuseful and instead immediately do what you personally want:
  Personally, I'd rather have an actually good Dock implementation that
  merges launcher, task switcher, and systray in a single icon for each
  app.
 
 we added launcher support in 4.6 and we re-engineered the system tray
 protocol to make this possible. so yes, that's generally where we're
 headed. if you wish to see it all come together sooner, then you need to
 get involved and start making patches.

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

Re: the next step on the desktop

[Markus Slopianka]

Am Montag 31 Januar 2011, 02:22:41 schrieb Aaron J. Seigo:
 hi...
 
 back when we started the path towards plasma i said that we needed to
 slowly evolve the desktop beyond the desktop folder with icons littered on
 the desktop.
 
 now we have activities, kick-ass containments like search and launch and
 grouping desktop.
 
 it is time to go to that next step and move people away from the old ways.
 
 i was at a friend's house last night where a bunch of people gathered to
 hang out, chat, play games, etc. there was a desktop system there running
 plasma desktop with the search and launch containment and a gorgeous
 translucent panel couresty of kwin.
 
 i saw it and hardly recognized it: it looked new, amazing, the next thing.
 it looked amazing.
 
 so, here's my suggestion for 4.7:
 
 let's try something big and new. let's make that Big Move and step away
 from ~/Desktop.

Frankly, I like my dumping ground.

 my proposal is this:
 
 * by default, Search and Launch on the desktop

What do you mean by that? Full screen SAL like on Plasma Netbook? Then one 
could just use 
that. However, if you mean a SAL plasmoid is the corner of the screen or a new 
top bar 
with a search bar and an extender than displays the icons (or another approach 
that 
combines both metaphors), I'd be fine with that.
As long as KDE's file search and indexing mechanism is still broken 
http://kdeatopensuse.wordpress.com/2011/01/30/opensuse-11-4-kde-testing/, I 
see more 
frustration than benefit. I could be wrong, though.

 * improve the tasks widget to have some of the nice features of widgets
 like smooth tasks with the mouse over highlights

I'd be happy if I could disable the scroll wheel for starters...


 * an activities widget (i'll hapilly write it) that sits next to the app
 launcher and when clicked brings up the actvities manager
 * an activities switcher as a kwin effect (!)
 * have all activities avaiable in kactivitmanagerd, even if they are
 stopped in plasma-desktop

It seems to me that programmers with their fully cramped task bars (IDE, 
terminals, 
debuggers, SCM frontends,...) are bigger fans of activities than the common 
persons with 
music player and browser open alone and -- if they are cutting edge -- even 
separate chat 
and mail clients.
Personally, I'd rather have an actually good Dock implementation that merges 
launcher, 
task switcher, and systray in a single icon for each app. But that's possibly 
the former 
Mac user speaking inside me.

I'm willing to try alternative approaches with an open mind, though. Especially 
when I can 
try them in my 4.6 installation (I'm assuming QML plasmoids and activity 
templates can be 
used for that kind of stuff).
Maybe I can come up with a mockup for something different myself in the coming 
days.

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

Re: The state of KWin

[Markus Slopianka]

On Sunday 26 December 2010 14:19:37 Martin Gräßlin wrote:
 I
 just cannot understand that problems like slowness of Present Windows with
 NVIDIA is reported by users in the beta phase several month after the code
 hit trunk!

I would be cool if there was a separate kwin-test (or so) package that 
depends on the 
latest stable Platform/Workspace and whose KWin binary also has a different 
file name and 
whose settings are stored in different files.
I have only one PC available for personal use and as long as the 
stable/unstable choice is 
exclusive, I simply can't afford to switch to a SC version that is not at the 
very least 
in RC stage.
That would also enable me to occasionally use kwin-test on the PC at work (for 
which I 
have root rights) and leave all the others of its users with the stable KWin 
version.

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

Re: trunk open for 4.7, remember to backport :)

[Markus Slopianka]

Am Donnerstag 23 Dezember 2010, 10:30:28 schrieb Ben Cooksley:

 The git transition, due to concerns about the ability to release 4.6
 from Git, has been delayed until 4.6 is released.

So trunk could be on git right now?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Fancy Panel and pre-existing users

[Markus Slopianka]

Users who have the Fancy Tasks plasmoid installed have the Fancy Panel 
option. Users who 
don't have the plasmoid don't have it.

On Thursday 23 December 2010 23:13:53 Ben Cooksley wrote:
 Hi all,
 
 I have been made aware [1] that the options in terms of new panels
 available to users can differ if they are using a fresh profile or a
 pre-4.6 profile with their new 4.6 installation. For a new user, they
 have a Fancy Panel which those with older profiles do not have. Is
 there an explanation for why this occurs?
 
 Regards,
 Ben
 KDE Forums Administrator
 
 [1] http://forum.kde.org/viewtopic.php?f=202t=92170
 ___
 Plasma-devel mailing list
 Plasma-devel@kde.org
 https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma themes set in kdeartwork

[Markus Slopianka]

Stupid question:
Why do we need Plasma themes in kdeartwork at all?
They are not like KWin decorations and have to be compiled. Isn't GHNS enough?

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

Re: Review Request: Plasma: Folder View: Icon displays 'pressed' on non-activating clicks

[Markus Slopianka]

 On 2010-11-09 18:37:25, Aaron Seigo wrote:
 
 
 Lindsay Roberts wrote:
 If there are no objections could I request that someone check this in?

Does it change the behavior described in 
https://bugs.kde.org/show_bug.cgi?id=256465 (always using the large 256x256 
icon for the scaling effect)?
If no, I suggest to tweak the patch because ever since Nuno changed the hi-res 
icons to look completely different from the smaller ones, the scaling effect 
looks really weird.


- Markus


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


On 2010-11-09 11:50:55, Lindsay Roberts wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://svn.reviewboard.kde.org/r/5805/
 ---
 
 (Updated 2010-11-09 11:50:55)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 The folder view employs a 'pressed' effect to show when an icon is activated.
 This works as expected when global settings are set to single click: the icon
 is scaled to 90% on press, and rescales back up on activate.
 
 Under double click the icon scales on the first click, and weirdly stays 
 scaled
 until the mouse leaves the hover area.
 
 Further, the same issue applies when modifier keys are used to change
 selection.
 
 
 This addresses bug 256297.
 https://bugs.kde.org/show_bug.cgi?id=256297
 
 
 Diffs
 -
 
   /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 1193797 
 
 Diff: http://svn.reviewboard.kde.org/r/5805/diff
 
 
 Testing
 ---
 
 Tested with both single and double click settings.
 
 
 Thanks,
 
 Lindsay
 


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

Re: notification text

[Markus Slopianka]

Am Montag 25 Oktober 2010, 13:11:21 schrieb Chani:

 ...after googling the part I could read, I got my account unlocked (phew!)
 but my point still stands :)

I'd rather see clickable URLs than copyable ones...


 also, if anyone can recommend a reliable imap server, I would be willing to
 pay for an account.

I hear http://gmx.com/ is good with free IMAP an such. I'm in Germany and can't 
register, 
so I can't tell how good it is. German GMX only offers POP3 for free. IMAP is a 
premium 
service here.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: notification text

[Markus Slopianka]

Am Montag 25 Oktober 2010, 15:53:39 schrieb Marco Martin:
 here you go, in trunk text is selectable and links clickable

In case I never told you: You are my personal hero. :-)
Does it also work with Kopete which AFAIK sends HTML-formatted notifications 
for URLs?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: digiclock looks

[Markus Slopianka]

The new clock in Air looks good, in Oxygen it looks weird. I thing Todd's 
suggestion about 
a sunken look could would improve it.
The clock is also very big. Maybe the date could be displayed by default.

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

Re: digiclock looks

[Markus Slopianka]

Am Samstag 23 Oktober 2010, 01:40:52 schrieb Sebastian Kügler:
 On Friday, October 22, 2010 23:43:52 Markus Slopianka wrote:
  The clock is also very big. Maybe the date could be displayed by default.
 
 That leads to too much visual clutter. The date is available in the tooltip
 anyway, showing it by default in the panel would really be a bit too much.

This was just an idea for one approach. Don't you think the clock looks really 
big? Maybe 
some other method to decrease its size can be found
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Why rotate widgets?

[Markus Slopianka]

 on a screen laying flat or which can be tilted: to make for a more
 appropriate viewing angle.

Isn't that the responsibility of RandR?
Personally I'd rather have a global tool (KRandR or some other rotate 
Activity tool) 
that to rotate Plasmoids individually.

 from a development POV it allows us to ensure testing of rotation so we
 know it works for other shells that need it even more so but get less
 testing, particularly pre-release.

Sounds more like a hidden option.


 why do you ask?
I wondered about that option for a longer time. I never used it and I never 
found it 
useful. Today I once again stumbled over a forum post by someone who wondered 
why that 
useless option is present anyway.

Personally, I'm slightly against it but not with my full heart. What I found 
interesting 
is the idea by someone in this thread to add a context sensitive button. With 
images, 
rotation seems somewhat useful. A transparency slider might be somewhat useful 
for other 
widgets...
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Why rotate widgets?

[Markus Slopianka]

On Wednesday 08 September 2010 15:04:40 Giulio Camuffo wrote:

 I really can't understand what's the problem here. If you don't want to
 rotate your plasmoids, fine. But i really don't find why a tiny icon is
 that a problem. Does it get in the way when you want to do something? no.
 Is it broken? no. So what's the problem?

I really don't like to repeat myself:
The feature is (IMO) useless and adds clutter to the GUI and apparently I'm not 
the only 
one who thinks this way.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma version numbers

[Markus Slopianka]

Hi there.
Out of curiosity I happened to enter those commands into Konsole:

# plasma-desktop --version
Plasma Workspace: 0.3

# plasma-netbook --version
Plasma Netbook: 0.1

See the printed version numbers.
I guess those numbers are leftovers from a time both were still in pre-release.
IMO both should now match the overall KDE Platform version number (and the term 
Plasma 
Workspace changed to Plasma Desktop).

Bye.
Markus

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

Why rotate widgets?

[Markus Slopianka]

Hi.
I wonder why Plasma widgets in Plasma Desktop can be rotated. Why would anyone 
need 
individual widgets to be upside down? Isn't this one of those micro-options we 
once stated 
to get rid of?

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

Re: BoF session at the MeeGo conference

[Markus Slopianka]

On Thursday 26 August 2010 15:22:03 Bart Cerneels wrote:
 Has anyone on this list already send a BoF session proposal?
 
 I was thinking of the following:
 
 We (KDE) and others (Qt) developers have written a lot of Qt code
 already. It makes perfect sense to try and reuse this code on the
 latest and most exiting Qt platform: MeeGo.
 This BoF session will be an open, example led discussion between
 developers who want to port whole applications or use existing
 libraries and technologies on the MeeGo platform.
 
 This session is intended for anyone with existing Qt code, not just
 KDE but obviously we have a lot of experience already.
 We can also get into more specific KDE stuff during or after the session.
 
 How about it KOffice-mobile devs? Any interest?
 We've got until tomorrow.
 
 Bart

Maybe a Plasma developer is interested in presenting Qt-based Plasma Netbook 
and maybe 
even show advantages over Clutter-based MeeGo Netbook.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier

[Markus Slopianka]

On Thursday 15 July 2010 17:57:11 Aaron J. Seigo wrote:
 
 aaron's advocatei really dislike text-on-graphics from a design
 perspective. text is fine detail, and a progress bar is visually fairly
 complex. maybe it's time to think outside the box. e.g. maybe colourize
 the device icon showing what % of it is filled and provide the usage text
 where the current progress bar is. the pie chart solution as seen in
 Lancelot would likely break up the layout in visually unpleasing ways
 here, so i wouldn't consider that too much./aaron's advocate

I guess you don't have a portable MP3 player. If you had one, you wouldn't 
make such ridiculous proposals.

Colors, pie charts, etc. are OK for quick and dirty checks -- for disks that 
have hundreds of gigs available and a single MB isn't of any significance.
With common MP3 players a single MB makes the difference if I can have a song 
stored on the device or not.

Design decisions that require tooltips or additional clicks to find out basic 
information (be it space available on external drives such as MP3 players or 
Plasmoid descriptions) are counter usability and may have their space in the 
realm of GNOME.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier

[Markus Slopianka]

On Wednesday 14 July 2010 20:10:42 Jacopo De Simoi wrote:
 SVN commit 1149977 by jacopods:
 
 First attempt to get rid of the capacity bar in the device notifier: use a
 Plasma::Meter with tooltips. Screenshot:
 http://imagebin.ca/view/ccJ3dD.html

No longer displays amount of free space -- regression.
Avoidable tooltips - Usability problem.
Bug you mentioned - Qt bug (fixed in 4.7).

What are the actual improvements then?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Scrollbars in add widget ui

[Markus Slopianka]

On Tuesday 13 July 2010 22:35:50 Aaron J. Seigo wrote:
 sorry, but it's not coming back.

Oh, then offloading all useful info into tooltips is good?
Is this how you definition of elegance?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier

[Markus Slopianka]

On Wednesday 14 July 2010 23:46:41 Jacopo De Simoi wrote:

  No longer displays amount of free space -- regression.
  Avoidable tooltips - Usability problem.
 
 I agree, suggestions?

How about extending Plasma::Meter to show text/numbers in the progress bar? 
Maybe it could look like the percentage display on the battery Plasma applet.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Scrollbars in add widget ui

[Markus Slopianka]

On Thursday 15 July 2010 00:04:45 Artur Souza (MoRpHeUz) wrote:
 Yep, it's way more elegant than having an icon with an i that when
 clicked shows all the useful information.

In the old window as well as Aurelien's mockup the applet description is 
visible right away, without the need to click i, so your argument simply 
isn't valid.


 Specially that my mother
 doesn't need to figure out what the hell the i icon means (it could
 be something related to uninstall on my native language)

I take this as a proposal to remove the i from the systray. 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Scrollbars in add widget ui

[Markus Slopianka]

Oh, and btw: It's impossible to click on URLs in those Plasma tooltips, while 
it's perfectly possible in all other About windows.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Activity identicons v 1.99 :) (post-akademy)

[Markus Slopianka]

On Tuesday 13 July 2010 07:34:35 Chani wrote:
 how would you suggest that be done?

Ask Celeste to come up with something great :-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Launcher support for libtaskmanager

[Markus Slopianka]

 On 2010-07-10 19:13:13, Markus Slopianka wrote:
  GPL for library files? Sounds strange to me. I'd expect at least LGPL...
 
 Marco Martin wrote:
 this library is a big mess it already contains pieces in gpl, lgpl and bsd
 this really should be fixed

Combining LGPL and more permissive licenses (BSD, MIT) isn't such a big deal, 
but I'd avoid GPL for libraries. While it's not a violation of KDE's Licensing 
Policies (that one only demands LGPL or more permissive for kdelibs, kdepimlibs 
and kdebase-runtime), it's at least inconsistent with KDE's general LGPL for 
libraries and GPL for applications approach.
I suggest to Anton to use LGPL for both to at least make the situation not more 
messy than it already is.


- Markus


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


On 2010-07-10 18:21:39, Anton Kreuzkamp wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4585/
 ---
 
 (Updated 2010-07-10 18:21:39)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 Adds support for Windows 7 like launchers in libtaskmanager.
 (I'm on holliday from 12th July until 1st August so I will not be able to 
 reply during this time.)
 
 
 Diffs
 -
 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1148442 
   
 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp
  1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 
 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 
 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 
 
 Diff: http://reviewboard.kde.org/r/4585/diff
 
 
 Testing
 ---
 
 Tested with a small test-applett and everything works.
 
 
 Thanks,
 
 Anton
 


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

Re: Activity identicons v 1.99 :) (post-akademy)

[Markus Slopianka]

Aren't icons supposed to be meaningful? How do those random patterns represent 
activities in an iconic way?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Activity identicons v 1.99 :) (post-akademy)

[Markus Slopianka]

On Monday 12 July 2010 11:47:51 Marco Martin wrote:
 or do you have a better idea to -magically- find an image that represent
 that activity without user intervention?

Why would Activities be created without user intervention?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Activity identicons v 1.99 :) (post-akademy)

[Markus Slopianka]

On Monday 12 July 2010 11:55:50 Marco Martin wrote:
 unfortunately, i see that having something already done is often enough to
 make people not wanting to use those

Maybe it should be easily discoverable what Activities actually are.

Maybe I'm uninformed, but I see them as virtual desktops with individual 
Plasmoid setups.
Plasma in SC 4.4 had a quirky GUI for selecting activities, but at least 
showed thumbnails of them. In 4.5 thumbnails were replaced with random 
patterns and I still don't see the benefit of pattern over thumbnails.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Activity identicons v 1.99 :) (post-akademy)

[Markus Slopianka]

On Monday 12 July 2010 12:58:23 Alessandro Diaferia wrote:

 Well, I don't completely see the point of avoiding any type of
 configuration to the user. IMO, when creating a new activity, the user
 might be prompted to choose among a set of default activities. Those
 activities might already have a name and a default icon together with
 some default plasmoids already loaded. Then the user might eventually
 choose to create his custom activity and in that case he would choose a
 name and an icon in place of a default, generic one.

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

Re: Scrollbars in add widget ui

[Markus Slopianka]

On Monday 12 July 2010 13:53:10 Aurélien Gâteau wrote:

 I agree. I made a proposal for an alternative version which would
 requires no hovering to get the widget descriptions but it was rejected.

Huh? Why?
Was it like the one in 4.3? I had absolutely no problems with the 4.3 one.


 Therefore I am trying to get some less drastic changes in.

Thanks. Better than nothing.
While you're at it, fix the text input field, please. It does not have focus 
by default. :-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Scrollbars in add widget ui

[Markus Slopianka]

On Monday 12 July 2010 15:33:24 Aurélien Gâteau wrote:

 It looked like this:
 
 http://agateau.files.wordpress.com/2010/07/add-widget-e1278885892283.png
 
 It was rejected because it had the same problems as the KDE 4.3 dialog:
 taking too much screen space.

The people who rejected it obviously never saw KRunner, because your proposal 
looks exactly the same.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Activity identicons v 1.99 :) (post-akademy)

[Markus Slopianka]

On Monday 12 July 2010 23:40:42 Chani wrote:

 if you want details, go read my blog posts on activities :)
 http://chani.wordpress.com/?s=activities

Yeah, I could do that, but while I'm not afraid of reading blogs, typical 
users won't do that. It'd be really great if by SC 4.6 it was easily 
discoverable for common users (and advanced users alike) what activities are 
and how to use them. :-)

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

Re: Review Request: Launcher support for libtaskmanager

[Markus Slopianka]

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


Um, I think that was done by accident:
/kdebase/workspace/libs/taskmanager/launcheritem.h is GPL while 
/kdebase/workspace/libs/taskmanager/launcheritem.cpp is under a BSD license.

Shouldn't both be BSDL'ed?

- Markus


On 2010-07-10 17:21:34, Anton Kreuzkamp wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4585/
 ---
 
 (Updated 2010-07-10 17:21:34)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 Adds support for Windows 7 like launchers in libtaskmanager.
 (I'm on holliday from 12th July until 1st August so I will not be able to 
 reply during this time.)
 
 
 Diffs
 -
 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1148442 
   
 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp
  1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 
 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 
 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 
 
 Diff: http://reviewboard.kde.org/r/4585/diff
 
 
 Testing
 ---
 
 Tested with a small test-applett and everything works.
 
 
 Thanks,
 
 Anton
 


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

Re: Scrollbars in add widget ui

[Markus Slopianka]

On Monday 12 July 2010 00:18:03 Aurélien Gâteau wrote:
 What do you think?

I think that the scrollbars are an improvement, but I like the window from 4.3 
better: The current one requires to hover over an icon to see the description.
I have yet to see any improvement of the Add widget bar over the window, but 
I also didn't participate in the discussion before SC 4.4 over which one is 
better. So I'm not aware of the exchanged arguments. (I hope there was a 
discussion.)


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

Re: Review Request: Launcher support for libtaskmanager

[Markus Slopianka]

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


GPL for library files? Sounds strange to me. I'd expect at least LGPL...

- Markus


On 2010-07-10 18:21:39, Anton Kreuzkamp wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4585/
 ---
 
 (Updated 2010-07-10 18:21:39)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 Adds support for Windows 7 like launchers in libtaskmanager.
 (I'm on holliday from 12th July until 1st August so I will not be able to 
 reply during this time.)
 
 
 Diffs
 -
 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1148442 
   
 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp
  1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 
 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 
 1148442 
   /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 
 
 Diff: http://reviewboard.kde.org/r/4585/diff
 
 
 Testing
 ---
 
 Tested with a small test-applett and everything works.
 
 
 Thanks,
 
 Anton
 


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

Re: [Request] A lib for the system tray

[Markus]

Am Freitag 18 Juni 2010, 23:25:19 schrieb Lucien XU:
 Hello
 
 When trying to code an other dock for KDE, I wanted to unite tasks and
 systemtray, that is truly cool on macos

Funny fact: You're wrong about Mac OS X.
The OS X equivalent of a systray in in the top right within the Mac global 
menu bar.

What OS X does, however, is to allow to close all windows of an app and still 
leave the app running which is indicated by a glowing spot in the Dock (a 
triangle in the past).

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

Re: Fwd: [Bug 207902] launcher support in libtaskmanager

[Markus]

Am Dienstag 15 Juni 2010, 13:16:33 schrieb Emdek:

 I was working on new library (concept described somewhere on this ML some
 months ago) that will replace libtaskmanager in my applet (it's easier to
 write new that fits than adding workarounds to make it work correctly with
 launchers etc.) but it's suspended currently (lack of time - studies and
 work).

I think it would be a good idea to put your current library code into KDE 
Playground. That way others could work on it if they are interested...
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Fwd: [Bug 207902] launcher support in libtaskmanager

[Markus]

Hi.

Just asking:
Is anyone even looking at vote counts in Bugzilla?

Bye, Markus
---BeginMessage---
https://bugs.kde.org/show_bug.cgi?id=207902


Michał Gawroński dinth1...@gmail.com changed:

   What|Removed |Added

 CC||dinth1...@gmail.com




--- Comment #9 from Michał Gawroński dinth1906 gmail com  2010-06-14 11:39:49 
---
1800 votes, and unfortunatelly still no progress :(

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are a voter for the bug.---End Message---
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Plasma Mediacenter: Inroduce displaying and modifying of nepomuk tags

[Markus Slopianka]

 On 2010-06-07 22:45:45, Markus Slopianka wrote:
  Correct me if I missed anything, but as I skimmed through the diff, it 
  looked to me that this is only about Nepomuk tags. Correct?
  I may be splitting hairs here, but when I hear tag editing in the context 
  of media players, I think of ID3 tags and such.

Will ID3 tags later be edited with the same mechanism? (At least Artist, Title, 
Year, ans such) If yes, the wording is OK to me and not editing ID3 tags is 
just a transitional bug. However, if ID3 tags will be edited with a different 
tool/window, I suggest to change the name of Nepomuk tags to something else, 
like Label or so, to avoid confusion.


- Markus


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


On 2010-06-08 08:03:13, Christophe Olinger wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4252/
 ---
 
 (Updated 2010-06-08 08:03:13)
 
 
 Review request for Plasma and Alessandro Diaferia.
 
 
 Summary
 ---
 
 This patch introduces a new label in the bottom bar. When playing/looking at 
 a media file, it displays its nepomuk tags. When clicking on the label, the 
 user can add/edit tags to an item (comma separated). When multiple items are 
 selected, tags are applied to all of them.
 
 P.S. The videostate.cpp contains comments.
 
 
 Diffs
 -
 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.h
  1135839 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.cpp
  1135839 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.h
  1135839 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.cpp
  1135839 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.h
  1135839 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.cpp
  1135839 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.h
  1135839 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.cpp
  1135839 
   
 trunk/playground/base/plasma/MediaCenterComponents/shells/plasmediacenter/mainwindow.cpp
  1135839 
 
 Diff: http://reviewboard.kde.org/r/4252/diff
 
 
 Testing
 ---
 
 Adding, editing tags was tested extensively. No more bugs should remain (TM)
 
 
 Thanks,
 
 Christophe
 


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

Re: Review Request: Plasma Mediacenter: Inroduce displaying and modifying tags

[Markus Slopianka]

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


Correct me if I missed anything, but as I skimmed through the diff, it looked 
to me that this is only about Nepomuk tags. Correct?
I may be splitting hairs here, but when I hear tag editing in the context of 
media players, I think of ID3 tags and such.

- Markus


On 2010-06-07 21:43:23, Christophe Olinger wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4252/
 ---
 
 (Updated 2010-06-07 21:43:23)
 
 
 Review request for Plasma and Alessandro Diaferia.
 
 
 Summary
 ---
 
 This patch introduces a new label in the bottom bar. When playing/looking at 
 a media file, it displays its tags. When clicking on the label, the user can 
 add/edit tags to an item. When multiple items are selected, tags are applied 
 to all of them.
 
 P.S. The videostate.cpp contains comments.
 
 
 Diffs
 -
 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.h
  1135632 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.cpp
  1135632 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.h
  1135632 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.cpp
  1135632 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.h
  1135632 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.cpp
  1135632 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.h
  1135632 
   
 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.cpp
  1135632 
   
 trunk/playground/base/plasma/MediaCenterComponents/shells/plasmediacenter/mainwindow.cpp
  1135632 
 
 Diff: http://reviewboard.kde.org/r/4252/diff
 
 
 Testing
 ---
 
 Adding, editing tags was tested extensively. No more bugs should remain (TM)
 
 
 Thanks,
 
 Christophe
 


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

Re: [Plasma Media Center] some advice request

[Markus]

On Saturday 05 June 2010 11:21:24 Marco Martin wrote:
 A problem with this approach is that with some crappy video drivers
 (for sure intel drivers at least

And considering that HTPCs are currently most likely Atom-based (hence Intel 
GMA 500 / Poulsbo), your point is even more valid.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Plasma Media Center] some advice request

[Markus]

On Saturday 05 June 2010 16:41:15 Christopher Blauvelt wrote:
 That assumption is flawed since you can't watch Hulu on an Atom w/o
 terrible frame drops and tearing.

Doesn't Hulu use Flash? Flash's suckiness on X11 platforms and Mac OS X is 
well-known.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Plasma Media Center] some advice request

[Markus]

On Saturday 05 June 2010 18:34:51 Christopher Blauvelt wrote:
 PMC has a long way to go before we can use something like VDPAU.

Isn't that something a Phonon/QtMultimedia back-end has to take care of and 
not Plasma?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Plasma Media Center] some advice request

[Markus]

On Saturday 05 June 2010 19:50:45 Christopher Blauvelt wrote:
 On Sat, Jun 5, 2010 at 1:20 PM, Markus kamika...@web.de wrote:
  On Saturday 05 June 2010 18:34:51 Christopher Blauvelt wrote:
   PMC has a long way to go before we can use something like VDPAU.
  
  Isn't that something a Phonon/QtMultimedia back-end has to take care of
  and not Plasma?
 
 Likely, but I'm sure there will be some issues along the way even if Qt
 does implement VDPAU support

I don't understand. Why would Qt need to implement it when back-ends handle 
the decoding?
(Phonon back-end = VLC. QtMultimedia back-end = GStreamer.)


 or whatever the Intel/ATI equivalent is.

There is only one proper API and that's VA-API -- a freedesktop.org standard 
with back-ends for all common GPUs.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Plasma Media Center] some advice request

[Markus]

On Saturday 05 June 2010 21:53:37 Christopher Blauvelt wrote:

 Wow, that sounds almost religious.

So instead of answering my question, you insult me?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Optional Qt 4.7 dependency (Qt 4.7 pre-release users should read this)

[Markus]

On Donnerstag 06 Mai 2010 16:04:43 Thiago Macieira wrote:
 Em Quinta-feira 06 Maio 2010, às 14:27:25, Aurélien Gâteau escreveu:
  kdelibs does not depend on Qt 4.7 yet, but since Qt 4.7 is planned for
  release on week 23, we could make kdelibs 4.5 depends on Qt 4.7
 
 I don't think it's wise to depend on 4.7 that late in the game.

I think we don't have a choice. I just downgraded to Qt 4.6 and immediately 
encountered this bug:
https://bugs.kde.org/show_bug.cgi?id=239840
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Shared OSD Service for KDE

[Markus]

While I like the idea, I think the current implementation wastes a but much 
space (icon is over to the progress bar, not beside it) and the progress bar 
is also not the Plasma one.

PS: I added plasma-devel@kde.org as additional recipient.

Am Montag 10 Mai 2010, 09:40:01 schrieb Ozan Çağlayan:
 Hi,
 
 I've been working to create a centralised way of rendering OSD widgets upon
 request for KDE4. Finally I wrote a KDED service which uses KOSD[0] to
 render OSD widgets.
 
 KOSD is a small KDE application which draws nice, polished and
 plasma-themed OSD with progress bars. I decoupled the Widget class from it
 and rewrote it as a KDED service.
 
 Currently KMix and the brightness patch of Felix Geyer are adjusted to make
 D- Bus calls when they need to show a notification.
 
 I don't know whether to implement this sort of thing as a KDED daemon makes
 sense but at least it works and we're using it in Pardus 2009.
 
 Code is at:
   https://svn.pardus.org.tr/uludag/trunk/kde/kded_kosd/
 
 Screenshots:
   http://cekirdek.pardus.org.tr/~ozan/ivir/kosd1.png
   http://cekirdek.pardus.org.tr/~ozan/ivir/kosd2.png
 
 [0]:
   http://kde-apps.org/content/show.php/KOSD?content=81457
 
 Regards,
 
 ---
 Ozan Çağlayan
 TUBITAK/UEKAE - Pardus Linux
 http://www.pardus.org.tr/eng

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

Re: Shared OSD Service for KDE

[Markus]

Am Montag 10 Mai 2010, 14:43:29 schrieb Colin Guthrie:

 So, personally, I think the wasted space argument isn't really overly
 important in this context - use transparency and make sure it disappears
 quickly and how big it is isn't massively important. In fact you could
 say that the primary focus of an OSD is to give feedback. If it's too
 small you wont notice it :D

OK, then let me rephrase it:
The useless parts are wasting space. If anything has to be big, then the part 
of the OSD widgetthat displays the actually important part (=the progress 
bar).
But maybe this can be part of the future KCM. Plasma-Mediacenter which will 
potentially be used on a TV and seen from a sofa, obviously needs bigger 
widgets than a desktop PC.

@Ozan:
Do you already work on a KCM? I'd like to provide a few mockups, because I 
already have some ideas in mind for the Notifications KCM (some are floating 
in my mind for some time which are related to notifications in general, not 
OSDs specifically, but I can incorporate the OSD parts in my mockups).
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Shared OSD Service for KDE

[Markus]

Am Montag 10 Mai 2010, 19:09:44 schrieb Ozan Çağlayan:

 BTW should I commit and develop in trunk/playground? Does it only contain
 parts that are *likely* to be merged to KDE SC or is it really a
 completely free playground for KDE account owners?

The latter. Extragear apps start in playground as well ;)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma as a knotify backend bug?

[Markus]

Am Montag 10 Mai 2010, 22:48:51 schrieb Ivo Anjo:
 should I just
 reword this so the text gets smaller?

That likely would only help English users.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: problem with the notification plasmoid

[Markus]

Am Donnerstag 06 Mai 2010, 21:21:27 schrieb Marco Martin:

 ah, so not actually the notifications widget.
 the product to choose in bugzilla is plasma
 and the component is
 widget-devicenotifier

Just FYI: Normal users can't set the component manually. Only admins can.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Kde-pim] New application: Videocatcher

[Markus]

Why did you send your mail to kde-pim? Because of Akregator?

Personally, I think you should turn you app into a Plasma applet that 
integrates well into plasma-mediacenter and also into normal Plasma panels 
as icon (eg. by forking QuickAccess with its nice popup-based navigation).
As vodcasts are often quite big in size (esp. if they are HD) a proper vodcast 
client has to be persistent anyway.

Markus

PS: I took the liberty to add plasma-devel as recipient.


Am Sonntag 25 April 2010 15:40:19 schrieb Jonas Müller:
 Hi all
 I have recently committed a new application to playground/pim. It's called
 Videocatcher and is an Internet TV application (like a podcast client but
 for videos). It is still far from done but should be in a usable state.
 
 Currently Videocatcher makes it possible to subscribe to video RSS/ATOM
 feeds and easily download and watch the videos. It works as a podcast
 client as well, but I am only really focusing on video since Amarok has
 podcast functionality. If anyone would like to see a standalone podcast
 client feel free to tell me.
 
 The idea is to create a videocast client which is lightweight and
 integrated into KDE. Lightweight in the sense of responsive and using few
 resources, but also that it does not try to do things that other programs
 can do better. For example by using external media players.
 
 I am wondering if there is anyone here who might be interested a videocast
 client for KDE or have any ideas about the direction it should be going. Is
 it a waste of time? Should it be a podcast client as well? Should it be
 called VideoKatcher?
 
 Any ideas or feedback are greatly appreciated!
 
 Videocatcher is also available from kde-apps.org: http://kde-
 apps.org/content/show.php/Videocatcher?content=121556
 
 Regards,
 Jonas
 ___
 KDE PIM mailing list kde-...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-pim
 KDE PIM home page at http://pim.kde.org/

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

Re: Plasma Media Center progress

[Markus]

Am Mittwoch 21 April 2010 17:15:24 schrieb Marco Martin:

 a tv tuner is kinda an huge project per se (also because would almost imply
 recording, that would make almost as big as mythtv) so it has a quite low
 priority right now.
 Of course if there is someone willing to spend a lot of work just on that
 will be cool :)

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

Re: Plasma Media Center progress

[Markus]

Am Donnerstag 22 April 2010 17:08:24 schrieb todd rme:
 I think kaffeine does as well.

Recording as well? LibVLC should provide all needed features and since VLC is 
going to be Phonon's preferred back-end (at least 
http://amarok.kde.org/blog/archives/1171-Rapid-Progress-in-KDE-Multimedia.html 
sounds like that), it should be installed with KDE SC anyway...
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Reviewing Plasma themes

[Markus]

 1. Most of popular themes (I reviewed the themes bundled with Plasma
 and some highest rated/most downloaded themes from GHNS) have
 usability problems. I was surprised to see either black text on dark
 background or white text on light background in so many themes.

I think part of the problem is that many themes were written for older Plasma 
versions and don't work well with recent releases.
Maybe there should be a was to tag them as unmaintained / deprecated / 
incompatible.


 2. Plasma is still unstable. I had more than a dozen crashes of Plasma and
 KWin.

For me this seems to occur in conjunction with compositing. For some reason 
everything that accesses Plasma and/or KWin functions (plasma-desktop, 
krunner, kmix) just quits without any error message.
Try other drivers. A recent NVidia driver update seems to resolve most 
problems for me, even though I still understand why drivers make Plasma quit 
(crashes I could understand..).


 3. Widgets are clumsy. Arranging them took some time and made whish to
 punch my monitor, because widgets tend to jump back after I resized
 and/or moved them.

I think this is supposed to be a feature.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tablet Made in Germany: The wePad, completely opensource

[Markus]

 since appears to be opensource.. any info on what is based that software?
 (if there is something released yet and is not a flash demo :p)

We built a platform based on two established, well-known technologies, 
Android and Linux ( http://wepad.mobi/ )
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tablet Made in Germany: The wePad, completely opensource

[Markus]

Am Dienstag 13 April 2010 16:48:29 schrieb Aaron J. Seigo:

 is there a development community around it that we could get involved with,
 or is it a product that just happens to be running f/oss?

According to the German IT news site golem.de it's neither. They just run a 
rendered video under Windows.
It's varporware. Just forget it.


 if the latter,
 it might be interesting to try talking with the company at some point;
 meego+plasma ?

If they did that, at least it would be an actual platform.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-Netbook Mockups

[Markus]

Am Samstag 10 April 2010 02:52:48 schrieb Artur Souza (MoRpHeUz):

  Compare Apple's early PowerBooks (eg.
  http://en.wikipedia.org/wiki/File:Powerbook_duo_2300c.jpg ) to a modern
  netbook: No, not different at all (from a usability standpoint):
  9 screen for display and keyboard + touchpad for input. If sold today,
  everybody would call them netbooks.
 
 Exactly and that's the problem. Netbooks are not regular notebooks or
 desktops and that's what is most frustrating for users. Vendors put the
 same software that is supposed to run on desktops on that tiny screen and
 users have a horrible experience and then they blame the hardware, and it
 is not the problem. This is the reason most users return their netbooks to
 stores.

I'm not sure if either you misread or I wasn't clear. My point is the complete 
opposite: Apple has 25+ years of experience with GUIs on small screens .
The whole Mac GUI is designed around small screens up to a point that it works 
bad on big screens (a global menu bar isn't fun on 30 screens).


 The solution ? They started doing netbooks with bigger screens =/

That's the solution for Windows. I wasn't talking about Windows.


 From my POV it
 seems that your ideas are a little bit biased by the fact that you used
 (and liked - and there is no problem at all with it) for a long time Mac
 OS(X)

That's what I openly stated from the beginning. I could've said Look which 
great ideas I have and I had them completely on my own. but that would be 
dishonest.
And who isn't biased in any way? We're all the sum of our experiences. ;-)

I'm not a Mac fanboy. I switch operating systems and desktop environments as 
often as other people change their underwear. ;-)

Btw, of my proposals only two are based on Mac OS: The Application Menu and 
the global menu bar.
Window buttons on panel is a tweak of an idea posted by KDE's Stefan Majewsky: 
http://majewsky.wordpress.com/2010/03/24/the-kwin-button-applet/


PS: I don't know what you did, but could you please fix your mail client? 
Whenever I reply to list in your mails, the reply address is your private 
address and not plasma-devel@kde.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-Netbook Mockups

[Markus]

Thanks for your comments. I'd like to further share my reasons for the 
decisions.

Am Freitag 09 April 2010 19:59:28 schrieb Marco Martin:

 i think however the exposè effect has more informational value

As someone who used Mac OS X for years, I know Exposé inside out.
I also know that when I wanted to switch whole apps (even if it were only 
three or so) with many windows, the practical aspect shrunk.
I also remember that using it with a touchpad only was very cumbersome.

My reason for including both -- Exposé and menu -- was that the user can adapt 
his/her workflow according to the attached input devices rather than the 
capabilities of GPU and drivers.


 a crappy
 device is supposed to not have garzillions of apps open at the same time
 btw

Well, it's not our decision what the user runs, right? ;-)
Today's netbooks are more powerful than the iBook I bought 6 years ago and 
I've seen market data that indicates that not so few people buy netbooks as 
their only PCs and even Atom CPUs advance. Who knows how powerful these 
machines get 2 years from now.

That's why I thought that the user should still be able to conveniently switch 
between 10 apps that add to 50 windows -- whether we think it's a good idea or 
not.


 there was a reason for the strange layout we have now:
 the close and maximize buttons are epected to be at right,

Correct me if I'm wrong but from everything I saw of Plasma Netbook, there 
weren't any close or maximize buttons at all.


 and i think it's
 really weird if as in your screenshot those buttons are separed from the
 applet that gives the title, even if they could mae sense at opposite sides
 of the screen.

Given that it's all Plasma, I thought that all positions can be changed anyway 
if the user decides.
I also thought to mirror Mac OS 9's layout where the close button was on the 
left and a similar menu was on the right.
http://wrds.files.wordpress.com/2007/04/mac_os_9_screenshot_2.png

The main point on my mockups were not to present the ultimate applet 
positions, but instead a feature set I believe would be beneficial to have 
available in the default setup of Plasma Netbook.


 as discussed here some days ago, a menubar like that is quite challenging.
 and problem will be that probably only kde applications will be able to use
 it.

I remember a blog posting by some Chinese KDE contributor (who also wrote a 
Scim-based input method panel for Plasma) that he modified Xbar to be 
compatible with GNOME/GTK applications. That was one, two or so years ago, 
though.


 having
 controls for the current window in two opposite parts of the screen really
 looks strange to me.

It's just a thing of getting used to.
In the early 2000s I used BeOS (dual boot with Win98) at home and occasionally 
Mac OS 9 at work. Both share the concept to separate window size modification 
(Zoom and on OS9 also Window Shade) from the Close button. This was something 
I could adapt to within minutes.
And as I said: My mockups don't have the goal to hinder users to rearrange the 
Plasmoids on the bar.

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

Re: Plasma-Netbook Mockups

[Markus]

Written by MoRpHeUz — April 9, 2010 @ 19:01:
 Hi! Regarding some points:
 
 – Exposè vs List of Windows
 
 A) Most (if not all) netbooks today have a graphics card capable of doing
 composite.

Graphic cards: Yes. Drivers: Not often.
There were several announcements of ARM-based netbooks. Is any of the current 
drivers even compatible with GPUs that work in conjunction with ARM CPUs?
Does Nouveau work with Tegra for example? I tried to look it up a while ago 
and found nothing.


 And if composite is not available, it fallbacks exactly to a
 list of windows, so it seems that your idea is “quite already
 implemented”.

I on purpose made my menu switch between apps and not individual windows.



 B) From our research with users, they usually do not open that many
 applications on a netbook.

Certainly possible. Your research is likely better than my limited research 
using a handful of netbook owners and some market statistic about people who 
replace their PCs with netbooks.

One of the goals of my proposal was to enable easier switching between many 
apps without hurting the work flow for users who don't run many apps.


 However if this happens, then it would be a
 good idea to think about a good solution for “too many windows” and Exposè
 effect.
 
 – Titlebar
 
 Without closing the application, from your mockup there is no way to switch
 between activities without closing the application as the app’s menu is
 using the panel.

If by activities you mean the pages?
Well, the app doesn't need to be closed in that case, only hidden/minimized.

My rationales:
A.) Vertical space is more important than switching pages if one application 
has focus.
B.) Netbooks are probably usually used for single apps in full screen. My 
proposal was made on this assumption, even though I'd like to enable users to 
switch between 10 apps if they choose to run that many.

Just now I had another idea: Wouldn't it be possible to implement multitouch 
gestures on touchpads that support them? Eg swipe left/right to switch between 
activities/pages?


 What if I open an application that has a lot of menu
 options ? What should we do in this case ?

Same as with normal windows of Qt apps: Show an expander.


 Apple “fixes” this on OSX
 limiting the number of menu options that one can create.
 
 The window’s actions on the right are already implemented as a plasmoid and
 there is no need to show the minimize button: if you want to switch
 between applications you just do it, if you want to go to an activity you
 just use the panel for that and if you want to close, the button is there.
 In your mockup you’re duplicating the functionality: the same action can
 be triggered by the list of windows and in the right side of the panel.

No, it's not duplication. Here's why: In my proposal the menu allows to hide 
the whole application = all windows at once.
The Minimize button only hides the active window. If you're running only 
single-window apps, it does not make a difference, but if an app has multiple 
windows, it is a difference.



 – Bigger screens vs Average netbook user
 
 In our research with *average* netbook users (not geeks), they usually
 don’t connect output monitors/keyboards and specially they don’t do much
 multitasking (when they do, the applications are always maximized anyway).

I'm not arguing against your research. My proposal is not targeted against 
them, but just a collection of ideas that aims to make it easier if one user 
decides to either connect external monitors and/or do more multitasking.
Btw, I know no geek with a netbook. Are geeks even allowed to posses such 
things? :-)


 That’s why we took the path of making all applications to run maximized
 too. This came from user feedback.

In my proposal all apps are fullscreen by default as well.


 One thing that we could improve, is the ability to switch to a regular
 Plasma desktop view if there is a monitor plugged in, as this is the case
 where you have a bigger place to do your mess

A fried of mine (non-geek) uses such a setup and in fact she's the reason why 
I even started to think about Plasma Netbook. The built-in screen is 10 inches 
or so and her traditional GNOME layout totally cramps the screen. The external 
22 inch screen OTOH is almost empty.
Then I asked myself what could be done to still use the small screen 
effectively and make it easy to move windows to the big screen.

I think my proposal helps some people while OTOH hurting no one. That said, 
it's difficult to know without actually trying this out and I only have a 
15,4 notebook, so I couldn't try my own proposal even if someone implemented 
it... :-(
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-Netbook Mockups

[Markus]

Am Freitag 09 April 2010 23:10:48 schrieb Chani:
 
 while I can see this being handy for something like Qt Designer, it'd be a
 PITA for something like a web browser or okular.

Web browsers and Okular are single-window apps by design. Sure, you can show 
more than one window at the same time, but usually those do not need to be 
shown at the same time.
So with only a single document being displayed and the netbook GUI defaulting 
to fullscreen app execution anyway, in those cases the Minimize button and the 
Hide menu do the same thing: Hide the current window and showing the Newspaper 
activity.
I don't know about Qt Designer -- I was more thinking about GIMP and such.
In some cases websites spawn small popup windows, often resulting in 
interaction with the smaller windows having effects on the main window (eg. a 
web forum opens a new login window). Both in this case and GIMP-like apps, the 
smaller windows are clearly connected to.


 I don't care that all my
 .pdf files are open in something called Okular, I care about getting to
 the document about magical ponies :)
 
 and guess which sort of app Joe Sixpack is more likely to be using...

Maybe I'm spoiled by my Mac experience, but I can't remember that Mac OS (X) 
was ever regarded as geek-only platform. On the contrary: Mac OS X is usually 
highly praised for its high usability up to a point where trolls call it a 
girl and gay platform, because it's so easy and real men use Windows.
OSX too has the metaphor to minimize individual windows, hide the whole app 
and even the option to hide all non-focused apps.

While I don't claim to have infinite wisdom ;-), I've used Mac OS X for 3 or 4 
years, many versions of Windows, BeOS, and since 2 or 3 years KDE/Linux pretty 
much exclusively (and occasionally before then) and hence think that I know a 
broad spectrum of GUIs and think that I'm able to spot GUI features that are 
good. :-p ;-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-Netbook Mockups

[Markus]

Am Freitag 09 April 2010 23:08:48 schrieb Marco Martin:

 well, it's not really easy to identify what windows belong to the same app,
 that's one of the reasons the taskbar in plasma-desktop right now lists
 windows, and they are grouped by name, that is an heuristic that may or may
 not be the correct

Ugh. I thought in times of dbus such evil hacks are no longer needed. ;-)

 
  Just now I had another idea: Wouldn't it be possible to implement
  multitouch gestures on touchpads that support them? Eg swipe left/right
  to switch between activities/pages?
 
 no multitouch on X for now.

And as an idea for the future?


 right no you don't have a minimize button at all in netbook mode:
 if there is no taskbar and if the desktop can be selected as any other
 window, the minizmize button has exactly no use.

Right.


 well, dragging a window to the other screen is quite easy :)
 (interestingly enough, one could also experimen on running plasma desktop
 on the second monitor and netbook on the little one, if the computer is
 powerful enough...

Is this possible?
Surely as different X screens, but within one session?


 xephyr, virtualbox..
 way suboptimal but gives an idea

I also get a rough idea by launching plasma-netbook on my notebook. I meant a 
real-world scenario with an actual netbook and an external monitor. I don't 
think my friend lets me abuse her netbook for my experiments. :-p
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-Netbook Mockups

[Markus]

Am Samstag 10 April 2010 00:12:00 schrieb Artur Souza (MoRpHeUz):
 But they still dropped it for the iPhone and even for the iPad ;)

Both are touch-based devices and almost everybody who these days develops GUIs 
for such devices gets more than only inspiration from Apple.


 Desktops and netbooks and mobiles are different beasts and that's the whole
 point, right ?

Compare Apple's early PowerBooks (eg. 
http://en.wikipedia.org/wiki/File:Powerbook_duo_2300c.jpg ) to a modern 
netbook: No, not different at all (from a usability standpoint):
9 screen for display and keyboard + touchpad for input. If sold today, 
everybody would call them netbooks.

I'm not saying that Apple has to be copied at all costs. No. I'm merely 
suggesting that some conventions that were researched over years could be 
adapted. That's all. :-)
And if you all say Bah, your ideas suck. IT stone age's over., then I'm fine 
with it as well. :-) I just reply to almost every mail, because I simply don't 
want to be misunderstood. :-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

JavaScript API: Manipulate elements of a PlasmaSvg

[Liebe Markus (RtP2/TEF72)]

Hi there,

Is it possible to manipulate text items of a SVG image?

In the main.js of the plasmoid I did:
svg = new PlasmaSvg('foo');  // loading foo.svg

In the svg file there is a text element:
text id=textitem  ... mytext/text

Is it somehow possible to access this textitem and set/change its value using 
the Plasma Javascript API?

The only other way I can think of is to open the svg file and parse the xml, 
change the value there, save it back and load it again.
Which seems to be rather complicated.

Regards,
Markus

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

Re: [Kde-pim] Important Notice about Reviewboard

[Markus]

Maybe that's an opportunity to implement 
http://blog.fishsoup.net/2009/09/23/splinter-patch-review/ on top of Bugzilla

Am Sonntag 08 November 2009 12:11:58 schrieb David Solbach:
 Dear Reviewboard-Users,
 
 Unfortunately I had to disable the user registration because we had a lot
  of nonsense accounts created by spammers. Until we have installed a
  captcha system or similar measures, all new accounts have to be requested
  via bugs.kde.org . There is a component Reviewboard that you can choose
  to request accounts. I will react as quckly as possible!
 
 Ah, and to easily identify and delete all those spammer accounts, I need
  your help: Please (if you haven't already done so) add your First and
  Lastname to your account. If you don't want to do that just write me an
  email with your account name.
 
 Cheers,
 
 David
 
 PS: if anyone has experience in python and webdevelopment and wants to help
  to add a captcha to reviewboard, please drop me an email :)
 ___
 KDE PIM mailing list kde-...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-pim
 KDE PIM home page at http://pim.kde.org/
 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Panel autohide

[Markus Mauder]

On Thursday 08 October 2009 01:31:15 Aaron J. Seigo wrote:
 (it's really an FAQ, isn't it?)
Yeah, actually, you said a couple of very interesting things in this thread.

A couple of month ago a few of us under Chani's supervision collected a couple 
of these WayOfThePlasma [1] statements, but nothing more seems to have come of 
that.

Would there be interest in reviving this effort? Or maybe just make what is 
there more prominent?

Thanks,
- Markus

[1] http://techbase.kde.org/User:Chani/WayOfThePlasma/Categories
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel