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

[Chani]

On July 12, 2010 16:27:40 Markus Slopianka wrote:
> 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. :-)
> 

how would you suggest that be done?
___
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: Activity identicons v 1.99 :) (post-akademy)

[Ivan Čukić]

> separate UI? wuh?
1 - menu of icons and a 'more...' option
2 - standard icon chooser when 'more...' is clicked

> I'm starting to wonder if maybe it's not so bad to leave it to the user. After
> all, we don't try to auto-name the activity for them, new activities currently
> start at "unnamed"...

One /less-than-perfect/ solution doesn't mean we should make other
ones like that. At least, this way, the unnamed activities look
differently even with the same name.

Cheerio

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

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

[Chani]

On Monday, July 12, 2010 04:48:39 am Ivan Čukić wrote:
> > -in the activity configuration, there would be something that looks like
> > a combobox to chose icons, that shows just the set of "20 good ones" or
> > an "other..." option
> 
> Yeah, we'll need to discuss this one a bit more - whether it is good
> (usability-wise) to make a separate UI for icon choosing. Maybe we
> could add another category to the icon chooser...

separate UI? wuh?
the combobox would be in the activity config UI (which is currently wedged 
into backgrounddialog, but will need to go somewhere more sensible in 4.6).

> 
> > My only concern remains about auto-generated icons. I really don't see
> > the point of them, but, again, i might be completely wrong. Having just
> 
> It is a visual distinction - it is a bit subliminal, but after a
> while, your mind will connect a pattern to a specific activity and
> will find it easier.
> 
> I agree that setting a generic ugly icon would /force/ users to choose
> custom ones, but I'm not sure that would be such a good idea ;)
> 

I'm starting to wonder if maybe it's not so bad to leave it to the user. After 
all, we don't try to auto-name the activity for them, new activities currently 
start at "unnamed"...

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

RE: Plasma::Wallpaper does software scaling/copying when it isn't necessary

[velociraptor Genjix]

Ok, Thanks. I will definitely check that out.

peace

> From: z...@kde.org
> To: plasma-devel@kde.org
> Subject: Re: Plasma::Wallpaper does software scaling/copying when it isn't
> necessary
> Date: Mon, 12 Jul 2010 15:46:37 -0400
> 
> On Monday 12 July 2010 13:01:33 velociraptor Genjix wrote:
> > > I'm not sure what would that give you. I'm guessing you want to use
> > > something like XvPutImage which wouldn't work because you already
> > > convert the frames to RGB and basically no one accelerates Xv with RGB
> > > surfaces. Besides it would be only meaningful assuming that a) Plasma
> > > currently runs on a system with X11, b) the driver doesn't implement Xv
> > > using an overlay. While we could assume "a" and disable the plugin if
> > > it's not the case, there's no reliable way of testing b and it will
> > > obviously break the entire Plasma (your video will render on top of
> > > everything).
> > 
> > Well any pixel format is possible but we don't want to break plasma. 
> 
> This isn't about format, it's simply that backend scalers render video on top 
> of other contents (hence the name "overlays"), so on canvas such as Plasma 
> they can't be used.
>  
> > > > A video wallpaper should be as natural as an image or colour in today's
> > > > world.
> > > 
> > > That's a bit unrealistic. A static wallpaper needs to be uploaded only
> > > once, while the video will need to be uploaded ~24 times per second (and
> > > given that you're scaling in software even on an avarage laptop that's
> > > 1280*800*4*24 =~ 98MB every second).
> > 
> > But still with all the fancy 3D effects we have turned on... 
> 
> That's a /very/ different thing. The geometry and every individual pixel for 
> those is generated on the GPU. That's not the case for video, video isn't 
> generated on the GPU, it's stored on the disk and has to be uploaded. 
> 
> > > IMHO for video it'd be more interesting to start Plasma with a GL engine
> > > and after decoding the frame (to whatever is the video native YUV
> > > format, e.g. YUV420 for VP8) rendering it as a texture while doing the
> > > to rgb conversion and scale in shaders.
> > 
> > Is it currently possible? Plasma doesn't currently have a GL engine I don't
> > think?
> 
> Just start it with "-graphicsystem opengl" and go from there.
> 
> z
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
  
_
http://clk.atdmt.com/UKM/go/19780/direct/01/
Do you have a story that started on Hotmail? Tell us now___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

[Marco Martin]

On Monday 12 July 2010, Chani wrote:
> On Monday, July 12, 2010 03:04:42 am Markus Slopianka wrote:
> > 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.
> 
> nope. an Activity is what you're doing at the moment: the tools and
> documents that you need for that work. plasmoids, windows, etc... the
> activity is meant to show you what you're working on and filter out things
> that could be a distraction.
> you can sorta do this with virtual desktops, but they're not as powerful as
> activities will be, and many people use >1 desktop for the same activity.

with virtual desktop kmail can't hide some folders, for instance.
well it still doesn't do that with activities either, but it's possible to do 
that, while with virtual desktop simply is not possible

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

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

[Chani]

On Monday, July 12, 2010 04:09:44 am Marco Martin wrote:
> On Monday 12 July 2010, Alessandro Diaferia wrote:
> >   Il 12/07/2010 12:54, Marco Martin ha scritto:
> > > On Monday 12 July 2010, Markus Slopianka wrote:
> > >> 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?
> > > 
> > > not creation of activities without user intervention, but assigning a
> > > meaningful image without the user being forced to chose something
> > > 
> > > Cheers,
> > > Marco Martin
> > > ___
> > > Plasma-devel mailing list
> > > Plasma-devel@kde.org
> > > https://mail.kde.org/mailman/listinfo/plasma-devel
> > 
> > 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.
> 
> that could be an idea.
> the corresponding containment (or the first if there are more that one
> containment per activity) could be loaded from a javascript template with
> default plasmoids that have something to do with it
> 

+1, javascript template support is already halfway there, and the user can 
already choose containment types (desktop, folderview, etc).

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

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

[Chani]

On Monday, July 12, 2010 03:04:42 am Markus Slopianka wrote:
> 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.

nope. an Activity is what you're doing at the moment: the tools and documents 
that you need for that work. plasmoids, windows, etc... the activity is meant 
to show you what you're working on and filter out things that could be a 
distraction.
you can sorta do this with virtual desktops, but they're not as powerful as 
activities will be, and many people use >1 desktop for the same activity.

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


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

I'd love it if someone could come up with a workable way to do thumbnails in 
the activity manager - I'm sure I said so in the BR.

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

Bug 166914: per activity task discussion

[Luca Beltrame]

Hello,

I'm posting this question mostly with my forum admin hat on, as when 4.5 will 
be released we'll likely get questions on this behavior.

Right now, if applications are moved to another activity, they remain in the 
task manager. Clicking on them will switch to the task and to the relevant 
activity. There has been discussion in the BR mentioned in the subject of 
hiding the task instead unless it's in the same activity.

Now, since we're late in the release cycle, would it be better to keep the 
existing system or move to the "hidden unless on current activity" mode? And 
would this make sense just for 4.6 instead?

Personally I prefer the latter approach (hidden) but I am not pushing for 
anything. I would just like to know an official stance so I can answer 
questions on the forums when they arise.

Thanks.



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma::Wallpaper does software scaling/copying when it isn't necessary

[Zack Rusin]

On Monday 12 July 2010 16:11:07 Giulio Camuffo wrote:
> On Monday 12 July 2010 21:46:37 Zack Rusin wrote:
> > > Is it currently possible? Plasma doesn't currently have a GL engine I
> > > don't think?
> > 
> > Just start it with "-graphicsystem opengl" and go from there.
> 
> Wouldn't be possible to do a GL wallpaper as there is a Plasma::GLApplet?

In GLApplet we read back the data from the GPU, copy it to a QImage and render 
that. It works ok for smaller Plasmoids but it's rather useless for fullscreen 
rendering.

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

Re: Plasma::Wallpaper does software scaling/copying when it isn't necessary

[Marco Martin]

On Monday 12 July 2010, Giulio Camuffo wrote:
> On Monday 12 July 2010 21:46:37 Zack Rusin wrote:
> > > Is it currently possible? Plasma doesn't currently have a GL engine I
> > > don't think?
> > 
> > Just start it with "-graphicsystem opengl" and go from there.
> 
> Wouldn't be possible to do a GL wallpaper as there is a Plasma::GLApplet?
> 
> Giulio

i guess it is, but probably as slow as glapplets

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

Re: Review Request: This patch adds the Storage class for Plasma::DataEngine caching. This current implementation caches to disk. Soon, it will be akonadi.

[Marco Martin]

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

Ship it!


I think it can go in now


/trunk/KDE/kdelibs/plasma/dataengine.cpp


this is ok for now but will need to be either of
a) retrieve become asymmetric with store and retrieve everything while 
store does for a single key value pair
b) not using a service anymore, would be directly kconfig, akonadi or 
whatever


- Marco


On 2010-07-12 20:10:03, Brian Pritchett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4548/
> ---
> 
> (Updated 2010-07-12 20:10:03)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> DataEngines can mark or unmark their sources to be cached with void 
> DataEngine::setEnableCache(const QString &source, bool cache). If the 
> DataEngine has implemented their own source by inheriting DataContainer, then 
> DataContainer::setEnableCache(bool cache) will work.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1147556 
>   /trunk/KDE/kdelibs/plasma/data/operations/storage.operations PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/datacontainer.h 1147556 
>   /trunk/KDE/kdelibs/plasma/datacontainer.cpp 1147556 
>   /trunk/KDE/kdelibs/plasma/dataengine.h 1147556 
>   /trunk/KDE/kdelibs/plasma/dataengine.cpp 1147556 
>   /trunk/KDE/kdelibs/plasma/private/datacontainer_p.h 1147556 
>   /trunk/KDE/kdelibs/plasma/private/dataengine_p.h 1147556 
>   /trunk/KDE/kdelibs/plasma/private/storage_p.h PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/4548/diff
> 
> 
> Testing
> ---
> 
> I have tested it with the microblogging dataengine/plasmoid.
> 
> 
> Thanks,
> 
> Brian
> 
>

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

Re: Plasma::Wallpaper does software scaling/copying when it isn't necessary

[Giulio Camuffo]

On Monday 12 July 2010 21:46:37 Zack Rusin wrote:
> > Is it currently possible? Plasma doesn't currently have a GL engine I
> > don't think?
> 
> Just start it with "-graphicsystem opengl" and go from there.

Wouldn't be possible to do a GL wallpaper as there is a Plasma::GLApplet?

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

Re: Review Request: This patch adds the Storage class for Plasma::DataEngine caching. This current implementation caches to disk. Soon, it will be akonadi.

[Brian Pritchett]

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

(Updated 2010-07-12 20:10:03.795472)


Review request for Plasma.


Changes
---

I updated the apidox; changed the every three minute timer to a single shot 
timer when data is updated, renamed some files and variables, and moved others 
into private to not break binary compatibility.


Summary
---

DataEngines can mark or unmark their sources to be cached with void 
DataEngine::setEnableCache(const QString &source, bool cache). If the 
DataEngine has implemented their own source by inheriting DataContainer, then 
DataContainer::setEnableCache(bool cache) will work.


Diffs (updated)
-

  /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1147556 
  /trunk/KDE/kdelibs/plasma/data/operations/storage.operations PRE-CREATION 
  /trunk/KDE/kdelibs/plasma/datacontainer.h 1147556 
  /trunk/KDE/kdelibs/plasma/datacontainer.cpp 1147556 
  /trunk/KDE/kdelibs/plasma/dataengine.h 1147556 
  /trunk/KDE/kdelibs/plasma/dataengine.cpp 1147556 
  /trunk/KDE/kdelibs/plasma/private/datacontainer_p.h 1147556 
  /trunk/KDE/kdelibs/plasma/private/dataengine_p.h 1147556 
  /trunk/KDE/kdelibs/plasma/private/storage_p.h PRE-CREATION 

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


Testing
---

I have tested it with the microblogging dataengine/plasmoid.


Thanks,

Brian

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

Re: Plasma::Wallpaper does software scaling/copying when it isn't necessary

[Zack Rusin]

On Monday 12 July 2010 13:01:33 velociraptor Genjix wrote:
> > I'm not sure what would that give you. I'm guessing you want to use
> > something like XvPutImage which wouldn't work because you already
> > convert the frames to RGB and basically no one accelerates Xv with RGB
> > surfaces. Besides it would be only meaningful assuming that a) Plasma
> > currently runs on a system with X11, b) the driver doesn't implement Xv
> > using an overlay. While we could assume "a" and disable the plugin if
> > it's not the case, there's no reliable way of testing b and it will
> > obviously break the entire Plasma (your video will render on top of
> > everything).
> 
> Well any pixel format is possible but we don't want to break plasma. 

This isn't about format, it's simply that backend scalers render video on top 
of other contents (hence the name "overlays"), so on canvas such as Plasma 
they can't be used.
 
> > > A video wallpaper should be as natural as an image or colour in today's
> > > world.
> > 
> > That's a bit unrealistic. A static wallpaper needs to be uploaded only
> > once, while the video will need to be uploaded ~24 times per second (and
> > given that you're scaling in software even on an avarage laptop that's
> > 1280*800*4*24 =~ 98MB every second).
> 
> But still with all the fancy 3D effects we have turned on... 

That's a /very/ different thing. The geometry and every individual pixel for 
those is generated on the GPU. That's not the case for video, video isn't 
generated on the GPU, it's stored on the disk and has to be uploaded. 

> > IMHO for video it'd be more interesting to start Plasma with a GL engine
> > and after decoding the frame (to whatever is the video native YUV
> > format, e.g. YUV420 for VP8) rendering it as a texture while doing the
> > to rgb conversion and scale in shaders.
> 
> Is it currently possible? Plasma doesn't currently have a GL engine I don't
> think?

Just start it with "-graphicsystem opengl" and go from there.

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

Re: pixmap leak in KDE 4.5 RC2

[Marco Martin]

On Monday 12 July 2010, Andrei Nistor wrote:
> Hello everyone,
> 
> I've noticed that the X11 memory usage in plasma is rising steadily in
> plasma. A few hours after I log in, the X11 memory usage can reach 50MB.
> 
> I've tried to track this issue down with SadEagle in #kde-devel and he
> suggested to use ktracepixmap and kdumppixmap from playground.
> 
> The dump can be found at http://filebin.ca/mrjwbt/pixmaps-dump.tar.bz2

there doesn't seem to be so much weird stuff in those dumps (yeah the i icon 
seems to have too many copies that's true)
the most disconcerting thing imo are those garzillion copies of the cashew...
the black pixmaps are probably used somewhere to do transparency compositing, 
like fade in/fade out i guess


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

Re: Review Request: This patch adds the Storage class for Plasma::DataEngine caching. This current implementation caches to disk. Soon, it will be akonadi.

[Marco Martin]

> On 2010-07-10 08:35:01, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/dataengine.cpp, line 803
> > 
> >
> > this will work ok for low latency / synchronous storage fetching, which 
> > is what the current implementation is. but it really needs to be made 
> > properly async to avoid blocking.
> > 
> > which means starting the job and populating the source when it returns 
> > ... but only if the source hasn't already been populated in the meantime.

problem is, retrieve gets only a key/value pair
so a ton of retrieve have to be made, and a connection for each one wouldn't be 
so pretty as well.
Aaron, Bruno: I'm really thinking about if Job is the proper way to go? it also 
forces to carry around all those base64 encoded strings of complex data, that 
wouldn't be solved even when using akonadi..
if the service is going to be public and usable directly by external 
dataengines as well it really justifies to be a service. if will remain private 
and only private i'm not sure.


- Marco


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


On 2010-07-08 16:47:24, Brian Pritchett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4548/
> ---
> 
> (Updated 2010-07-08 16:47:24)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> DataEngines can mark or unmark their sources to be cached with void 
> DataEngine::setEnableCache(const QString &source, bool cache). If the 
> DataEngine has implemented their own source by inheriting DataContainer, then 
> DataContainer::setEnableCache(bool cache) will work.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1147556 
>   /trunk/KDE/kdelibs/plasma/data/operations/storage.operations PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/datacontainer.h 1147556 
>   /trunk/KDE/kdelibs/plasma/datacontainer.cpp 1147556 
>   /trunk/KDE/kdelibs/plasma/dataengine.h 1147556 
>   /trunk/KDE/kdelibs/plasma/dataengine.cpp 1147556 
>   /trunk/KDE/kdelibs/plasma/private/dataengine_p.h 1147556 
>   /trunk/KDE/kdelibs/plasma/private/storage.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/private/storage.cpp PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/4548/diff
> 
> 
> Testing
> ---
> 
> I have tested it with the microblogging dataengine/plasmoid.
> 
> 
> Thanks,
> 
> Brian
> 
>

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

Re: IRC meeting: point of what was done at akademy

[Ivan Čukić]

WORKSFORME as well

On 11 July 2010 16:21, Ryan Rix  wrote:
> On Sun 11 July 2010 7:32:14 am Chani wrote:
>> On Saturday, July 10, 2010 03:41:47 am Marco Martin wrote:
>> > On Saturday 10 July 2010, Aaron J. Seigo wrote:
>> > > On July 9, 2010, Marco Martin wrote:
>> > > > oh, fsck, scrap that: i remembered that  90% i'll be away 16-17-18 :/
>> > >
>> > > 15th? gives ryan a day to recuperate and a day before you leave?
>> >
>> > if it's ok for other people would be perfect :)
>>
>> thursday the 15th? sure :)
>> your thursday morning is vancouver's wednesday night, it should be easy for
>> me to stay up late then.
>
> +1 WORKSFORME :) You people have made me worse of a night owl than I was two
> weeks ago anyways :P
>
> --
> Ryan Rix
> == http://hackersramblings.wordpress.com | http://rix.si/ ==
> == http://rix.si/page/contact/ if you need a word         ==
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



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

Re: Review Request: Folderview : label when empty folder

[Iamluc]

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

(Updated 2010-07-12 17:13:34.681342)


Review request for Plasma.


Changes
---

Third version with Fredrik changes.
Less changes, but we still need to call update() in listingCompleted() to show 
the message.

The icon has been removed. 


Summary
---

Hello,

This patch add a Plasma::Label with text "This folder is empty." in 
Folderview's Popup when the folder is empty.

The related bug number in kde bugzilla is 201542.

Luc


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


Diffs (updated)
-

  /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 1145373 

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


Testing
---

Delete/add files several times. The label disappears/appears correctly.


Screenshots
---

folderview empty folder
  http://reviewboard.kde.org/r/4519/s/444/
version 2
  http://reviewboard.kde.org/r/4519/s/455/


Thanks,

Iamluc

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

Plasma::Wallpaper does software scaling/copying when it isn't necessary

[velociraptor Genjix]

> Really? To me it looks like you're just using sws_scale which is a software 
> scale.
> 
> > but Plasma::Wallpaper requires me to still copy this array with slow
> > software acceleration. If the format is correct then just give me the target
> > X surface. 
> 
> I'm not sure what would that give you. I'm guessing you want to use something 
> like XvPutImage which wouldn't work because you already convert the frames to 
> RGB and basically no one accelerates Xv with RGB surfaces. Besides it would 
> be 
> only meaningful assuming that a) Plasma currently runs on a system with X11, 
> b) the driver doesn't implement Xv using an overlay. While we could assume 
> "a" 
> and disable the plugin if it's not the case, there's no reliable way of 
> testing b and it will obviously break the entire Plasma (your video will 
> render on top of everything).

Well any pixel format is possible but we don't want to break plasma. I didn't 
know sws_scale was software based but thanks for the info. I guess plasma is 
still the bottle neck though since I can render the video to a fullscreen 
window (using a GL quad) no problems.
> > A video wallpaper should be as natural as an image or colour in today's
> > world.
> 
> That's a bit unrealistic. A static wallpaper needs to be uploaded only once, 
> while the video will need to be uploaded ~24 times per second (and given that 
> you're scaling in software even on an avarage laptop that's 1280*800*4*24 =~ 
> 98MB every second).

But still with all the fancy 3D effects we have turned on... Video wallpaper is 
only a small concern. Sure it's not for developers, but having a video 
wallpaper makes for a very sexy desktop to show off Linux.
> IMHO for video it'd be more interesting to start Plasma with a GL engine and 
> after decoding the frame (to whatever is the video native YUV format, e.g. 
> YUV420 for VP8) rendering it as a texture while doing the to rgb conversion 
> and scale in shaders.
Is it currently possible? Plasma doesn't currently have a GL engine I don't 
think?
> z
Thanks for you comments. Appreciate it ;)
  
_
http://clk.atdmt.com/UKM/go/19780/direct/01/
Do you have a story that started on Hotmail? Tell us now___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Scrollbars in add widget ui

[Aurélien Gâteau]

On 12/07/2010 16:34, Artur Souza (MoRpHeUz) wrote:
> Hi Aurélien!
> 
> 2010/7/11 Aurélien Gâteau :
>> I have been playing a bit with the Add Widget UI on the plane back from
>> Akademy and replaced the scroll buttons with a scrollbar. Attached patch is
>> a first step at it, largely unfinished as I would like to know if you are
>> interested in getting this integrated before I finish it.
> 
> Scrollbars are good improvements. I'm just a little bit unsure that it
> may not work well with touch oriented interfaces (like the ones we
> tested plasma during Tokamak4). While scrollbars are great to give you
> an idea of "position" in the list, it doesn't work very well to
> actually scroll with the fingers.

That's a problem indeed. Are Plasma widgets affected by the application
global strut? I used to work for a company where we implemented a
touch-screen application back in the days, and increasing the global
strut made quite a few widgets bigger, thus easier to use. This might
cause some space issues if it gets too big though.

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

Re: Review Request: This patch adds the Storage class for Plasma::DataEngine caching. This current implementation caches to disk. Soon, it will be akonadi.

[Bruno Abinader]

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



/trunk/KDE/kdelibs/plasma/datacontainer.h


there's actual one issue I have in mind: the setter/getter "cache enabled" 
are not formerly named, IMO. If setEnableCache is the setter, enableCache 
should be the getter, and not cacheEnabled.



/trunk/KDE/kdelibs/plasma/datacontainer.cpp


This should be moved to the private class. But, if it belonged to this 
class, it would be more elegant if the variable is initialized before the ctor 
brackets (like the d pointer, for example).


- Bruno


On 2010-07-08 16:47:24, Brian Pritchett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4548/
> ---
> 
> (Updated 2010-07-08 16:47:24)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> DataEngines can mark or unmark their sources to be cached with void 
> DataEngine::setEnableCache(const QString &source, bool cache). If the 
> DataEngine has implemented their own source by inheriting DataContainer, then 
> DataContainer::setEnableCache(bool cache) will work.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1147556 
>   /trunk/KDE/kdelibs/plasma/data/operations/storage.operations PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/datacontainer.h 1147556 
>   /trunk/KDE/kdelibs/plasma/datacontainer.cpp 1147556 
>   /trunk/KDE/kdelibs/plasma/dataengine.h 1147556 
>   /trunk/KDE/kdelibs/plasma/dataengine.cpp 1147556 
>   /trunk/KDE/kdelibs/plasma/private/dataengine_p.h 1147556 
>   /trunk/KDE/kdelibs/plasma/private/storage.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/private/storage.cpp PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/4548/diff
> 
> 
> Testing
> ---
> 
> I have tested it with the microblogging dataengine/plasmoid.
> 
> 
> Thanks,
> 
> Brian
> 
>

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

Re: Scrollbars in add widget ui

[Aurélien Gâteau]

On 12/07/2010 16:42, Marco Martin wrote:
> On Monday 12 July 2010, Markus Slopianka wrote:
>> 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.
> 
> with the slight difference that when you are using krunner you don't need to 
> access the desktop space
> 
Well, the {fade/slide}-out on drag would have avoided that problem, but
let's not rehash that discussion, as I don't think this is going to
change the decision anyway.

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

Re: Scrollbars in add widget ui

[Marco Martin]

On Monday 12 July 2010, Artur Souza (MoRpHeUz) wrote:
> Hi Aurélien!
> 
> 2010/7/11 Aurélien Gâteau :
> > I have been playing a bit with the Add Widget UI on the plane back from
> > Akademy and replaced the scroll buttons with a scrollbar. Attached patch
> > is a first step at it, largely unfinished as I would like to know if you
> > are interested in getting this integrated before I finish it.
> 
> Scrollbars are good improvements. I'm just a little bit unsure that it
> may not work well with touch oriented interfaces (like the ones we
> tested plasma during Tokamak4). While scrollbars are great to give you
> an idea of "position" in the list, it doesn't work very well to
> actually scroll with the fingers.
> 

i would like to try the following thing (that i'm already doing in the netbook 
sal favourites):
scroll with an horizontal drag, start a drag event with a vertical drag.
the tradeoff would be that the drag event would need to begin after a way 
bigger dragged distance than now.

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

pixmap leak in KDE 4.5 RC2

[Andrei Nistor]

Hello everyone, 

I've noticed that the X11 memory usage in plasma is rising steadily in plasma. 
A few hours after I log in, the X11 memory usage can reach 50MB.

I've tried to track this issue down with SadEagle in #kde-devel and he 
suggested to use ktracepixmap and kdumppixmap from playground.

The dump can be found at http://filebin.ca/mrjwbt/pixmaps-dump.tar.bz2

The total usage when the dump was taken was around 30MB. I've noticed that the 
'1' that appears in the systray when a notification is displayed appears about 
200 times in the dump, using ~500K of memory. There are also lots of black 
squares using ~7.5M of memory. 

I'd like to see this fixed by the time 4.5 is released.

Some system information: 
OS: Fedora 13 x86_64
GPU: Nvidia GeForce 8600GT, using the proprietary driver

I was unable to reproduce this on my netbook (eeepc 1000H), but it happens 
every time on my PC.

If you need more info, please ask.

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

Re: Scrollbars in add widget ui

[Marco Martin]

On Monday 12 July 2010, Markus Slopianka wrote:
> 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.

with the slight difference that when you are using krunner you don't need to 
access the desktop space

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

Re: Scrollbars in add widget ui

[Artur Souza (MoRpHeUz)]

Hi Aurélien!

2010/7/11 Aurélien Gâteau :
> I have been playing a bit with the Add Widget UI on the plane back from
> Akademy and replaced the scroll buttons with a scrollbar. Attached patch is
> a first step at it, largely unfinished as I would like to know if you are
> interested in getting this integrated before I finish it.

Scrollbars are good improvements. I'm just a little bit unsure that it
may not work well with touch oriented interfaces (like the ones we
tested plasma during Tokamak4). While scrollbars are great to give you
an idea of "position" in the list, it doesn't work very well to
actually scroll with the fingers.

Cheers!
___
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: Scrollbars in add widget ui

[Aurélien Gâteau]

On 12/07/2010 15:07, Markus Slopianka wrote:
> 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.

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.

Aurélien
___
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: 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

[Aurélien Gâteau]

On 12/07/2010 01:00, Markus Slopianka wrote:
> 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.)

I agree. I made a proposal for an alternative version which would
requires no hovering to get the widget descriptions but it was rejected.
Therefore I am trying to get some less drastic changes in.

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

Re: Scrollbars in add widget ui

[Aurélien Gâteau]

On 12/07/2010 02:47, Chani wrote:

> +1 from me :) just being able to see where in the list I am makes me happier.
> how does it look if there aren't enough to scroll?

For now it's not very nice because the scrollbar does not hide itself.
I'll look into it.

> P.S. Reviewboard Is Your Friend ;)

Don't worry, I will use reviewboard when it's done. I didn't feel it
would be appropriate right now because I would not want the patch to go
in in its current state. I just attached it in case someone wanted to
give it a try.

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

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

[Ivan Čukić]

> -in the activity configuration, there would be something that looks like a
> combobox to chose icons, that shows just the set of "20 good ones" or an
> "other..." option

Yeah, we'll need to discuss this one a bit more - whether it is good
(usability-wise) to make a separate UI for icon choosing. Maybe we
could add another category to the icon chooser...

> My only concern remains about auto-generated icons. I really don't see
> the point of them, but, again, i might be completely wrong. Having just

It is a visual distinction - it is a bit subliminal, but after a
while, your mind will connect a pattern to a specific activity and
will find it easier.

I agree that setting a generic ugly icon would /force/ users to choose
custom ones, but I'm not sure that would be such a good idea ;)


Ivan

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

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

[Alessandro Diaferia]

  Il 12/07/2010 13:09, Ivan Čukić ha scritto:
> 0. Not going to discuss about the reasoning behind identicons again.
>
> 1. Activities are no more only /desktop-setups-group-of-widgets/ so
> making thumbnails can be counter-productive - you can keep the desktop
> empty in all activities and still want to use other activity-related
> features. Or if you like consistency, you could make the layout for
> all activities identical (for example a few folder-views)
>
> 2. Creating a set of predefined activities just so that the icon is
> auto-assigned? Very strange reasoning. You could argue that the
> predefining would also provide a standard widgets layout, but it is
> not plausible - the layouts in different 'types' can be quite the
> same, and layouts for the same 'type' can be totally different.
The set of predefined activities was not meant as a solution for the 
auto-assigned icon stuff, I just intended that as a default set of most 
used activities. But anyway as you make me notice it's not the best way 
to go :)
> 3. Showing the configuration dialogue on creation is a possibility
> that I have nothing against. But we still need different icons if the
> user doesn't want to set them.
My only concern remains about auto-generated icons. I really don't see 
the point of them, but, again, i might be completely wrong. Having just 
one generic activity icon would force the user to choose an appropriate 
one in order to distinguish among them and I feel this is ok rather than 
unmeaningful auto-generated ones. In addition to this, wWhat would be 
really awesome is having an "icon-guess-system" based on the type of 
plasmoids the user loads in the activites. But, again, probably only 
guessing on plasmoid types is not enough.
> Cheerio
>
Regards

-- 
Alessandro Diaferia
KDE Developer
KDE e.V. member

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

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

[nuno pinheiro]

On Monday 12 July 2010 12:16:04 Ivan Čukić wrote:
> > me realy does not care much as long as we have something that looks
> > pretty and is easy to recognize by the user, i proposed to do those
> > icons because wen I saw how our Chani chose random icons to represent
> > them, i had my typical "your icons look soo ugly used like that"
> > feeling...  so I proposed
> > 
> > 
> > , what if i do a batch of consistent icons that a user can choose form
> > that don't look terribly wrong together?
> 
> Well, you already promised to do that :)

I was explaining how it went :D

> > thumbnails can work just as well its a
> 
> Thumbnails are not a real option because of technical difficulties and
> (un)usefulness.
> 1. See prev mail
> 2. Even if we add windows into thumbs (and not only plasma's look) -
> compare a thumbnail of kmail to a thumb of akregator (and a lot of
> other programs). There is no significant difference (thumbs need to be
> rather small). And, the thumbs would be constantly changing which is
> *bad*.
> 3. What when there are more screens?
yeah

-- 
oxygen guy, "I make the pretty pictures"
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

[Marco Martin]

On Monday 12 July 2010, Ivan Čukić wrote:
> 0. Not going to discuss about the reasoning behind identicons again.
> 
> 1. Activities are no more only /desktop-setups-group-of-widgets/ so
> making thumbnails can be counter-productive - you can keep the desktop
> empty in all activities and still want to use other activity-related
> features. Or if you like consistency, you could make the layout for
> all activities identical (for example a few folder-views)
> 
> 2. Creating a set of predefined activities just so that the icon is
> auto-assigned? Very strange reasoning. You could argue that the
> predefining would also provide a standard widgets layout, but it is
> not plausible - the layouts in different 'types' can be quite the
> same, and layouts for the same 'type' can be totally different.
> 
> 3. Showing the configuration dialogue on creation is a possibility
> that I have nothing against. But we still need different icons if the
> user doesn't want to set them.
> 
> Cheerio

i basically agree on all points, as probably i already said, the way i would 
like more is:
-still identicons as default, the set of round ones you posted would be a good 
improvement already
-in the activity configuration, there would be something that looks like a 
combobox to chose icons, that shows just the set of "20 good ones" or an 
"other..." option
-chosing one of the 20 would still compose it with the colored ball
-chosing other would pop up the usual icon selection dialog, the icon wouldn't 
be no longer composed in the ball since wouldn't really fit

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

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

[Ivan Čukić]

> me realy does not care much as long as we have something that looks pretty and
> is easy to recognize by the user, i proposed to do those icons because wen I
> saw how our Chani chose random icons to represent them, i had my typical "your
> icons look soo ugly used like that" feeling...  so I proposed


> , what if i do a batch of consistent icons that a user can choose form that
> don't look terribly wrong together?

Well, you already promised to do that :)

> thumbnails can work just as well its a

Thumbnails are not a real option because of technical difficulties and
(un)usefulness.
1. See prev mail
2. Even if we add windows into thumbs (and not only plasma's look) -
compare a thumbnail of kmail to a thumb of akregator (and a lot of
other programs). There is no significant difference (thumbs need to be
rather small). And, the thumbs would be constantly changing which is
*bad*.
3. What when there are more screens?



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

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

[Ivan Čukić]

0. Not going to discuss about the reasoning behind identicons again.

1. Activities are no more only /desktop-setups-group-of-widgets/ so
making thumbnails can be counter-productive - you can keep the desktop
empty in all activities and still want to use other activity-related
features. Or if you like consistency, you could make the layout for
all activities identical (for example a few folder-views)

2. Creating a set of predefined activities just so that the icon is
auto-assigned? Very strange reasoning. You could argue that the
predefining would also provide a standard widgets layout, but it is
not plausible - the layouts in different 'types' can be quite the
same, and layouts for the same 'type' can be totally different.

3. Showing the configuration dialogue on creation is a possibility
that I have nothing against. But we still need different icons if the
user doesn't want to set them.

Cheerio

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

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

[nuno pinheiro]

On Monday 12 July 2010 11:53:20 Marco Martin wrote:
> On Monday 12 July 2010, Markus Slopianka wrote:
> > 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
> 
> the zui imo was fine as a concept, unfortunately technically qgraphicsview
> couldn't really handle it very well.
> 
> we did hope performance issues could have been fixed in Qt, but this didn't
> happen, moreover there were some issues given from the fact of simply
> zooming out the scene showing how activities were actually laid out.
> 
> we can also try one of the two following things:
> 1) on new activities assign a random wallaper and use the thumbnail of the
> wallpaper as default activity icon
> 2) still try to to do a real thumbnail of the activity, this could be quite
> inefficient and in the current ui would be so scaled down it won't be
> recognizable (but i like having the list as a little unobtrusive bar)
> 
> i guess to actually see if one of those could work, we should actually try
> one of those approaches, probably the wallpaper thumbnail would be what
> takes less effort as quick throw away code
> 
> Cheers,
> Marco Martin

me realy does not care much as long as we have something that looks pretty and 
is easy to recognize by the user, i proposed to do those icons because wen I 
saw how our Chani chose random icons to represent them, i had my typical "your 
icons look soo ugly used like that" feeling...  so I proposed 
, what if i do a batch of consistent icons that a user can choose form that 
don't look terribly wrong together? thumbnails can work just as well its a 
mater of theming them a bit but we will need to prompt the user to chose a 
wallpaper and chances are that he will chose the one he likes best and that is 
probably not different from the one he is using now in other activities.
 ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


-- 
oxygen guy, "I make the pretty pictures"
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

[Marco Martin]

On Monday 12 July 2010, Alessandro Diaferia wrote:
>   Il 12/07/2010 12:54, Marco Martin ha scritto:
> > On Monday 12 July 2010, Markus Slopianka wrote:
> >> 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?
> > 
> > not creation of activities without user intervention, but assigning a
> > meaningful image without the user being forced to chose something
> > 
> > Cheers,
> > Marco Martin
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> 
> 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.

that could be an idea.
the corresponding containment (or the first if there are more that one 
containment per activity) could be loaded from a javascript template with 
default plasmoids that have something to do with it

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

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

[Alessandro Diaferia]

  Il 12/07/2010 12:54, Marco Martin ha scritto:
> On Monday 12 July 2010, Markus Slopianka wrote:
>> 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?
> not creation of activities without user intervention, but assigning a
> meaningful image without the user being forced to chose something
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
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.

Just my 2cc.

Regards.

-- 
Alessandro Diaferia
KDE Developer
KDE e.V. member

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

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

[Marco Martin]

On Monday 12 July 2010, Markus Slopianka wrote:
> 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?

not creation of activities without user intervention, but assigning a 
meaningful image without the user being forced to chose something

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

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

[Marco Martin]

On Monday 12 July 2010, Markus Slopianka wrote:
> 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

the zui imo was fine as a concept, unfortunately technically qgraphicsview 
couldn't really handle it very well.

we did hope performance issues could have been fixed in Qt, but this didn't 
happen, moreover there were some issues given from the fact of simply zooming 
out the scene showing how activities were actually laid out.

we can also try one of the two following things:
1) on new activities assign a random wallaper and use the thumbnail of the 
wallpaper as default activity icon
2) still try to to do a real thumbnail of the activity, this could be quite 
inefficient and in the current ui would be so scaled down it won't be 
recognizable (but i like having the list as a little unobtrusive bar)

i guess to actually see if one of those could work, we should actually try one 
of those approaches, probably the wallpaper thumbnail would be what takes less 
effort as quick throw away code

Cheers,
Marco Martin
___
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 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)

[Marco Martin]

On Monday 12 July 2010, nuno pinheiro wrote:
> On Monday 12 July 2010 10:35:44 Markus Slopianka wrote:
> > 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
> 
> that was the reason I proposed to make 20 for the most common activities,
> this way we can push for a coherent look on the icons and on the their
> status notification

unfortunately they would have to be always chosen by the user, unless a 
default set is pre created.
unfortunately, i see that having something already done is often enough to 
make people not wanting to use those (like the default subfolders in the home 
dir that some distros do) it triggers an "i don't want to be told what to do" 
behaviour.

some compromise could be done by doing some pattern matching with common names 
an activity could have (i.e the games icon would match with games, fun, maybe 
free time) and automatically chose the icon with the nearest name, would be 
tricky with localization tough

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

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

[nuno pinheiro]

On Monday 12 July 2010 10:35:44 Markus Slopianka wrote:
> 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
that was the reason I proposed to make 20 for the most common activities, this 
way we can push for a coherent look on the icons and on the their status 
notification 
-- 
oxygen guy, "I make the pretty pictures"
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

[Marco Martin]

On Monday 12 July 2010, Markus Slopianka wrote:
> 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

just to be able to tell them apart.
or do you have a better idea to -magically- find an image that represent that 
activity without user intervention?

Cheers,
Marco Martin
___
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: Review Request: Security updates in kdeplasma-addons for 4.5

[Ryan Rix]

> On 2010-07-11 22:04:59, Chani Armitage wrote:
> >

Commited as of 1148967 and backported to 4.5 as of 1148979. Thanks.


- Ryan


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


On 2010-07-11 21:53:30, Ryan Rix wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4602/
> ---
> 
> (Updated 2010-07-11 21:53:30)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> A whole bunch of security updates for the 4.5 timeframe, they need to go out 
> before 4.5 final is tagged, for applets which can or cannot reside on the 
> plasma-overlay screensaver. I feel like a dork for waiting until rc2 to 
> remember this patch, and I feel like more of a dork for sending it as an 
> offlist mail first, but here is the reviewboard since I suffer from 
> hate-commiting-to-code-i-didn't-write-itis :)
> 
> - add proper attributes to bookmarks' desktop file
> - add proper attributes to opendesktop's desktop file
> - add proper attributes to kdeobservatory's dekstop file
> - add proper attributes to kimpanel's desktop file
> - add proper attributes to pastebin's desktop file
> - add proper attributes to plasmaboard's desktop file
> - add proper attributes to qalculate's desktop file
> - add proper attributes to socialnews's desktop file
> - add proper attributes to spellcheck's desktop file
> - make systemloadviewer's launchapp optional (Made a KRunner DBUS call to 
> show system activity window)
> - make weatherstation's launchbrowser optional.
> 
> 
> Diffs
> -
> 
>   
> trunk/KDE/kdeplasma-addons/applets/bookmarks/plasma-applet-bookmarks.desktop 
> 1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/community/plasma-applet-opendesktop.desktop
>  1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/kdeobservatory/plasma-applet-kdeobservatory.desktop
>  1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/kimpanel/src/plasma-applet-kimpanel.desktop
>  1142195 
>   trunk/KDE/kdeplasma-addons/applets/pastebin/plasma-applet-pastebin.desktop 
> 1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/plasmaboard/plasma_applet_plasmaboard.desktop
>  1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/qalculate/plasma-applet-qalculate.desktop 
> 1142195 
>   trunk/KDE/kdeplasma-addons/applets/social-news/activitywidget.cpp 1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/social-news/plasma-applet-opendesktop-activities.desktop
>  1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/spellcheck/plasma-applet-spellcheck.desktop
>  1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/systemloadviewer/plasma-applet-systemloadviewer.desktop
>  1142195 
>   trunk/KDE/kdeplasma-addons/applets/systemloadviewer/systemloadviewer.cpp 
> 1142195 
>   
> trunk/KDE/kdeplasma-addons/applets/weatherstation/plasma-applet-weatherstation.desktop
>  1142195 
>   trunk/KDE/kdeplasma-addons/applets/weatherstation/weatherstation.cpp 
> 1142195 
> 
> Diff: http://reviewboard.kde.org/r/4602/diff
> 
> 
> Testing
> ---
> 
> it's been sitting on my system from two weeks not eating $cute_creatures
> 
> 
> Thanks,
> 
> Ryan
> 
>

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

Re: Review Request: Adds support for corner widgets in Plasma::TabBar

[Marco Martin]

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

Ship it!


i think now it's perfect(tm)

- Marco


On 2010-07-11 21:06:03, Giulio Camuffo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4537/
> ---
> 
> (Updated 2010-07-11 21:06:03)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Summary
> ---
> 
> This patch adds two methods that allow to put two QGraphicsWidget in the top 
> left and top right corner of the tab bar, like it is possible with QTabWidget.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdelibs/plasma/widgets/tabbar.h 1147219 
>   trunk/KDE/kdelibs/plasma/widgets/tabbar.cpp 1147219 
> 
> Diff: http://reviewboard.kde.org/r/4537/diff
> 
> 
> Testing
> ---
> 
> Tested, it works, but there's one thing that annoys me and I don't how to 
> solve in a clean way: when there are no tabs the NativeTabBar becomes a bit 
> smaller in height and the widgets resize accordingly.
> 
> 
> Screenshots
> ---
> 
> added two Plasma::PushButton
>   http://reviewboard.kde.org/r/4537/s/446/
> 
> 
> Thanks,
> 
> Giulio
> 
>

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

Re: Scrollbars in add widget ui

[Marco Martin]

On Monday 12 July 2010, Aurélien Gâteau wrote:
> Hi,
> 
> I have been playing a bit with the Add Widget UI on the plane back from
> Akademy and replaced the scroll buttons with a scrollbar. Attached patch
> is a first step at it, largely unfinished as I would like to know if you
> are interested in getting this integrated before I finish it.
> 
> Screenshots:
> - Horizontal: http://imagebin.ca/view/NkxkAG.html
> - Vertical: http://imagebin.ca/view/XnBxX8vt.html
> 
> What do you think?
> 
> Aurélien

i was yhinking about t just yesterday
while a scrollbar takes a bit of vertical space, it improves things a bit.
i was tinking about just showing 2 3-4 pixels high hint, that on mouse over 
becomes a full sized scrollbar, a bit like the new flash player of youtube...

on the other hand, if we do as discussed at akademy, partially sliding away 
the window when a drag is done, having a full sized scrollbar will become not 
an issue anymore

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

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

[Ivan Čukić]

> now, what if $plasmoid wants to use the icon (eg, activity bar)? what if
> $application wants to use the icon (eg. when associating something with an
> activity)? it'd be nice if I could see the icons when assigning windows to
> activities, but I dunno if that'd be possible with autogenerated ones...

Ok, this is a bit unrelated, but should be covered. The solution can
be something of the following:
1. KIdenticonGenerator becomes Plasma::IdenticonGenerator (in
libplasma - it needs Plasma::Svg so it can't go anywhere else)
2. We start saving the icons somewhere. Problem with this one is that
we need to save a couple different states...

> can users still choose any arbitrary icon they like?
Yes, this is just so that they could use the ones that look like
bubbles :) (yes, Nuno loves bubbles ;) )

> really, the sort of activities the user has is likely to depend on what the
> user does in his/her life :) me, I'll have activities for kwin, plasma,

Yes, I agree, but a set of common ones would be good IMO.

Cheerio!


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