Re: Notifications-future, a recap

2012-09-17 Thread Dario Freddi 
(putting back plasma-devel on CC, since the discussion is quite relevant)

2012/9/17 Sune Vuorela :
>> I know Sune already had some plans for the notification stack and I
>> think that's one of the best times for discussing what's going to
>
> yep. the plan is
> 1) write a small library wrapping the org.freedesktop.notification api
>wrap growl on mac

OT: you don't want to wrap growl but probably the new native
notification system.

>wrap QSystemTrayIcon on windows
> 2) do something similar for audio notifications
> 3) retrofit knotification on top of those
>
> and the more I have investigated, 1) should actually be put into Qt and
> QPA.
> That should also make it possible for e.g. webkit to use it to show web
> notifications.
> Unfortunately, I'm currently a bit busy with stuff :/
>
>> My personal idea is to have a new (tier1) framework consisting of a
>> way for building handlers, a client API and a server API (so that the
>
> Really? I_think we should get rid of a daemon and just let the workspace
> shell handle it.

It really depends on what you want to achieve. If your goal is just
cleaning up the API and implementing the existing standard it might
work out, but for sure it won't just cut it for what I proposed, where
we need a centralized logic for dispatching, grouping and more. As
Marco also said (framework wasn't CC'ed tho), the applet is already
gearing towards being a dull observer.

> I have a hard time figuring out why the above quite simple steps don't
> solve the problems you're specifying (and even ensures that you keep all
> existing applications working with their notifications)

Well :D. There is no way you can group notification, no way you can
tie them to activities, no way you can dispatch notifications to
different handlers than the workspace, and more. So I guess it's
rather safe to assume that the current design just won't cut it, and
as I already said applications will still be able to work with the
existing API, they just won't be able to expose the full experience -
and in some cases where they just shoot out a transient bubble, they
won't even notice the change.

I guess the real question is whether we want to continue with the old
paradigm we have or try to bet on something more modern. Also, what I
am proposing can still be adapted to interact with other platforms -
as I said, the client API should be as minimal as possible and not
tied to the complexity of the server.

>
>
> /Sune
>
> ___
> Kde-frameworks-devel mailing list
> kde-frameworks-de...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Randa Frameworks5 preps

2012-09-17 Thread Mario Fux 
Am Montag 17 September 2012, 17.27:34 schrieb Sebastian Kügler:
> Hey,

Morning

> [This email is mostly interesting to those of us meeting in Randa later
> this week]
> 
> Before we meet in Randa, it makes sense to have a look at your dev setup,
> so that we can get started quickly. We shortly talked about this on IRC
> today. If you'd like to spare yourself some setup time in Randa, it would
> be good to have a building frameworks5 checkout. That's probably easiest
> if you put that into a $PREFIX different from you normal kde devel
> install. That's of course highly dependent on your development setup, but
> we can get started quicker if we start roughly off of the same base.
> 
> kdelibs' frameworks5 branch builds against both, Qt4 and Qt5, but we will
> stick to Qt4 for now as the first focus is the splitting of the libplasma
> into functional, non-ui and QGraphicsView-based parts. Introducing too much
> change at the same time will make it harder to track regressions and fix up
> the whole thing in the end again.

This link could be useful:
http://community.kde.org/Frameworks/Building

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

Re: Notifications-future, a recap

2012-09-17 Thread Dario Freddi 
2012/9/17 Marco Martin :
> On Monday 17 September 2012, Dario Freddi wrote:
>> I know Sune already had some plans for the notification stack and I
>> think that's one of the best times for discussing what's going to
>> happen. I seriously doubt we can rely on the old KNotification code,
>> and probably we'll have to change some things during the way, but I am
>> rather confident we can keep a sort of source compatibility with the
>> old API (although I think it's not desirable since the way
>> applications interact with notifications is a major point in this
>> potential change).
>
> this will probably need a balance between needed capabilities and entry
> barrier for applications to use it, sending a notification could probably not
> change much (besides extra data such as what activity it belongs), but
> something new would be needed for managing the notification lifecycle after is
> sent...

exactly that

>> My personal idea is to have a new (tier1) framework consisting of a
>> way for building handlers, a client API and a server API (so that the
>> server can be put into runtime rather easily). Marco is already doing
>> some work on the applet to make it "ready" to adapt to this new
>> concept. Ideally, the applet will just receive a model of the existing
>> backlog + additional messages for transient notifications and newly
>> spawned persistent ones.
>>
>> What do you think?
>
> to repeat to everybody what i said to dario, the notifications applet i'm
> rewriting, it should be almost ready to be a quite dumb visualization of
> whatever is the backend. when/if the models of the notifications are ready, so
> data + exposed actions (delete, execute action "foo", mark as read...) are
> there, even tough not immediate should be quite easy to add this source in the
> notifications applet.
>
> to comment purely on the idea, i would like a lot a more capable notifications
> system, with stuff like
> * notifications tied to activities
> * reliable way to decide when to display the osd popup and when just in the
> history
> * when not to archive in the history
> * when an action can be executed more than once and when doesn't
> * what should be shown in the history almost forever, what should go after a
> while
>
> probably some of those things can be achieved by extending the current system,
> some don't, maybe there will be compromises to be done.. that was more or less
> my wish list to santa tough

it's pretty much on the board :) just that 90% of this will happen in
the background (server), whereas handlers will just take care of
showing a model and a set of events. The aim is to make the client API
as simple as possible and have a fatter server.

>
> Cheers,
> Marco Martin
> ___
> 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: Notifications-future, a recap

2012-09-17 Thread Dario Freddi 
2012/9/17 David Faure :
> On Monday 17 September 2012 17:49:23 Dario Freddi wrote:
>> a server API (so that the
>> server can be put into runtime rather easily)
>
> Just a note on that: the plan with KDE Frameworks, is that there will be no
> more libs/runtime separation. A framework will come with any runtime stuff it
> might need, to make things more modular.
>
> Of course if you mean 'there could be multiple "servers" which handle
> visualization' then that's different, we don't want a framework to ship all
> GUIs and therefore end up with too many dependencies. E.g. the kjob framework
> doesn't ship the plasma visualization stuff :-)
>
> But mandatory runtime requirements such as daemons and stuff, should be part 
> of
> the framework, in the future.

Definitely, sorry for the confusion - the server (handling the
grouping/dispatching logic) WILL be shipped with the framework,
whereas an API for building handlers (applications, applet) will be
provided.

TBH I don't see many benefits in allowing multiple servers at this
stage - maybe in a bright future, where this could become a standard,
it would make sense to have just a way for creating a server. For now
I'd stick to the plan of shipping the entire solution :)

>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Notifications-future, a recap

2012-09-17 Thread Marco Martin 
On Monday 17 September 2012, Dario Freddi wrote:
> I know Sune already had some plans for the notification stack and I
> think that's one of the best times for discussing what's going to
> happen. I seriously doubt we can rely on the old KNotification code,
> and probably we'll have to change some things during the way, but I am
> rather confident we can keep a sort of source compatibility with the
> old API (although I think it's not desirable since the way
> applications interact with notifications is a major point in this
> potential change).

this will probably need a balance between needed capabilities and entry 
barrier for applications to use it, sending a notification could probably not 
change much (besides extra data such as what activity it belongs), but 
something new would be needed for managing the notification lifecycle after is 
sent...

> 
> My personal idea is to have a new (tier1) framework consisting of a
> way for building handlers, a client API and a server API (so that the
> server can be put into runtime rather easily). Marco is already doing
> some work on the applet to make it "ready" to adapt to this new
> concept. Ideally, the applet will just receive a model of the existing
> backlog + additional messages for transient notifications and newly
> spawned persistent ones.
> 
> What do you think?

to repeat to everybody what i said to dario, the notifications applet i'm 
rewriting, it should be almost ready to be a quite dumb visualization of 
whatever is the backend. when/if the models of the notifications are ready, so 
data + exposed actions (delete, execute action "foo", mark as read...) are 
there, even tough not immediate should be quite easy to add this source in the 
notifications applet.

to comment purely on the idea, i would like a lot a more capable notifications 
system, with stuff like 
* notifications tied to activities
* reliable way to decide when to display the osd popup and when just in the 
history
* when not to archive in the history
* when an action can be executed more than once and when doesn't
* what should be shown in the history almost forever, what should go after a 
while

probably some of those things can be achieved by extending the current system, 
some don't, maybe there will be compromises to be done.. that was more or less 
my wish list to santa tough

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

Re: Notifications-future, a recap

2012-09-17 Thread David Faure 
On Monday 17 September 2012 17:49:23 Dario Freddi wrote:
> a server API (so that the
> server can be put into runtime rather easily)

Just a note on that: the plan with KDE Frameworks, is that there will be no 
more libs/runtime separation. A framework will come with any runtime stuff it 
might need, to make things more modular.

Of course if you mean 'there could be multiple "servers" which handle 
visualization' then that's different, we don't want a framework to ship all 
GUIs and therefore end up with too many dependencies. E.g. the kjob framework 
doesn't ship the plasma visualization stuff :-)

But mandatory runtime requirements such as daemons and stuff, should be part of 
the framework, in the future.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

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

Re: Plasma Wallpapers in QML

2012-09-17 Thread Aleix Pol 
On Mon, Sep 17, 2012 at 4:55 PM, Aleix Pol  wrote:
> On Fri, Sep 14, 2012 at 6:19 PM, Marco Martin  wrote:
>> On Thursday 13 September 2012, Aleix Pol wrote:
>>> Hi,
>>> So I was tired of KPeople for today and I've decided to play a bit
>>> with wallpapers.
>>>
>>> What I did was to create a very very simple plugin (~40 sloc) that
>>> lets you easily specify a wallpaper given a QML url. Now it's
>>> hardcoded, and we should find a way to pass it (maybe through the
>>> QVariantList args?) so that a wallpaper is just the desktop file, or
>>> maybe something completely different. :)
>>>
>>> If anybody wants to try it you can fetch it from:
>>> kde:scratch/apol/qmlwallpapers
>>>
>>> Thoughts?
>>
>> i subscribe to the "cool" first tought ;)
>>
>> it would be of course something completely unrelated with the current
>> Wallpaper plugin, since it's oriented to rendering of images, but the two are
>> complimentary (not sure if allowing both at the same time to run... maybe not
>> ;)
> Well I think there's been too much of a "the other wallpaper" syndrome
> there. It's a bit weird that Plasma::Wallpaper has some API that will
> only be ever used by the images wallpaper, while there are a bunch of
> them more as in: color, virus, weather, mandelbrot, etc.
>
> For plasma2 I guess it could make sense to make it possible to
> implement them all in terms of QML since now it's very much tied to
> QPainter and it will be a bit weird to port.
>>
>> as a simple exapmple to load a Package that is not a plasmoid, you can look 
>> at
>> plasma-mobile repo,
>> applications/common/kdeclarativeview.cpp
> I'll look into this and see what I can get.
>
>>
>> as type of package, i would try to either reuse the "wallpaper" type, or
>> adding a "qml-wallpaper" one, so it gets its own install directory prefix, 
>> and
>> optional own filesystem structure
>>
>> if it uses the wallpaper type, nothing in the existing configuration have to
>> be touched, as a bonus.
> yes, that's the plan :)
>
> We might want to make the plugin configurable, I'll see what I can do
> in this regard...
>
>>
>> Cheers,
>> Marco Martin
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel

Ok, discussing about it in #plasma was helpful :).

I've ported it to use plasma packages, it's using the Plasma/Generic
type so we might want to restrict a bit the type there, but I'm unsure
about how this works.

In any case, I'll try to get it to list wallpapers before Randa for
discussing the inclusion of it.

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

Re: Review Request: hide the konsole on the close project

2012-09-17 Thread Sebastian Kügler 

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

Ship it!


Ship It!

- Sebastian Kügler


On Sept. 17, 2012, 11:17 a.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106478/
> ---
> 
> (Updated Sept. 17, 2012, 11:17 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> How to reproduce,
> 
> 1. open a project with plasmate.
> 2. go File->close Project
> 3. look at the startpage, the konsole is still there
> 
> Also in this patch I did s/m_konsole/m_konsoleWidget. The rest of the
> widget use the naming m_fooWidget.
> 
> 
> Diffs
> -
> 
>   mainwindow.h 8005d26 
>   mainwindow.cpp b84da4a 
> 
> Diff: http://git.reviewboard.kde.org/r/106478/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

Re: Review Request: The preview action shouldn't be visible all the time

2012-09-17 Thread Sebastian Kügler 

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



mainwindow.cpp


Do we setVisible(true) it when we change package?

I don't see this in the code, but haven't tried. Something to check...


- Sebastian Kügler


On Sept. 17, 2012, 11:14 a.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106477/
> ---
> 
> (Updated Sept. 17, 2012, 11:14 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patches fixes the above bugs
> 
> 
> This addresses bugs 305866 and 305867.
> http://bugs.kde.org/show_bug.cgi?id=305866
> http://bugs.kde.org/show_bug.cgi?id=305867
> 
> 
> Diffs
> -
> 
>   mainwindow.cpp b84da4a 
> 
> Diff: http://git.reviewboard.kde.org/r/106477/diff/
> 
> 
> Testing
> ---
> 
> works
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

Notifications-future, a recap

2012-09-17 Thread Dario Freddi 
Hello everyone,

you might or might not know by now of my intention of revamping the
way we deal with notifications in KDE as I explained in my last blog
post 
http://drfav.wordpress.com/2012/09/17/the-notifications-issue-part-3-the-possible-solution/
. I have been talking about this with many of you already but I think
it's time to see what's the overall reception to the idea and what's
coming up for the actual job.

I know Sune already had some plans for the notification stack and I
think that's one of the best times for discussing what's going to
happen. I seriously doubt we can rely on the old KNotification code,
and probably we'll have to change some things during the way, but I am
rather confident we can keep a sort of source compatibility with the
old API (although I think it's not desirable since the way
applications interact with notifications is a major point in this
potential change).

My personal idea is to have a new (tier1) framework consisting of a
way for building handlers, a client API and a server API (so that the
server can be put into runtime rather easily). Marco is already doing
some work on the applet to make it "ready" to adapt to this new
concept. Ideally, the applet will just receive a model of the existing
backlog + additional messages for transient notifications and newly
spawned persistent ones.

What do you think?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Randa Frameworks5 preps

2012-09-17 Thread Sebastian Kügler 
Hey,

[This email is mostly interesting to those of us meeting in Randa later this 
week]

Before we meet in Randa, it makes sense to have a look at your dev setup, so 
that we can get started quickly. We shortly talked about this on IRC today. 
If you'd like to spare yourself some setup time in Randa, it would be good 
to have a building frameworks5 checkout. That's probably easiest if you put 
that into a $PREFIX different from you normal kde devel install. That's of 
course highly dependent on your development setup, but we can get started 
quicker if we start roughly off of the same base.

kdelibs' frameworks5 branch builds against both, Qt4 and Qt5, but we will 
stick to Qt4 for now as the first focus is the splitting of the libplasma 
into functional, non-ui and QGraphicsView-based parts. Introducing too much 
change at the same time will make it harder to track regressions and fix up 
the whole thing in the end again.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Wallpapers in QML

2012-09-17 Thread Aleix Pol 
On Fri, Sep 14, 2012 at 6:19 PM, Marco Martin  wrote:
> On Thursday 13 September 2012, Aleix Pol wrote:
>> Hi,
>> So I was tired of KPeople for today and I've decided to play a bit
>> with wallpapers.
>>
>> What I did was to create a very very simple plugin (~40 sloc) that
>> lets you easily specify a wallpaper given a QML url. Now it's
>> hardcoded, and we should find a way to pass it (maybe through the
>> QVariantList args?) so that a wallpaper is just the desktop file, or
>> maybe something completely different. :)
>>
>> If anybody wants to try it you can fetch it from:
>> kde:scratch/apol/qmlwallpapers
>>
>> Thoughts?
>
> i subscribe to the "cool" first tought ;)
>
> it would be of course something completely unrelated with the current
> Wallpaper plugin, since it's oriented to rendering of images, but the two are
> complimentary (not sure if allowing both at the same time to run... maybe not
> ;)
Well I think there's been too much of a "the other wallpaper" syndrome
there. It's a bit weird that Plasma::Wallpaper has some API that will
only be ever used by the images wallpaper, while there are a bunch of
them more as in: color, virus, weather, mandelbrot, etc.

For plasma2 I guess it could make sense to make it possible to
implement them all in terms of QML since now it's very much tied to
QPainter and it will be a bit weird to port.
>
> as a simple exapmple to load a Package that is not a plasmoid, you can look at
> plasma-mobile repo,
> applications/common/kdeclarativeview.cpp
I'll look into this and see what I can get.

>
> as type of package, i would try to either reuse the "wallpaper" type, or
> adding a "qml-wallpaper" one, so it gets its own install directory prefix, and
> optional own filesystem structure
>
> if it uses the wallpaper type, nothing in the existing configuration have to
> be touched, as a bonus.
yes, that's the plan :)

We might want to make the plugin configurable, I'll see what I can do
in this regard...

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

Review Request: make plasmate able to load a project in the second time

2012-09-17 Thread Giorgos Tsiapaliwkas 

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

Review request for Plasma.


Description
---

How to reproduce the issue,

1. open a project with plasmate
2. go File->close project
3. open the project again.
A kmessagebox will appear with the error.


Diffs
-

  mainwindow.cpp b84da4a 

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


Testing
---

I have tested the patch and I haven't seen any issues


Thanks,

Giorgos Tsiapaliwkas

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

Review Request: hide the konsole on the close project

2012-09-17 Thread Giorgos Tsiapaliwkas 

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

Review request for Plasma.


Description
---

How to reproduce,

1. open a project with plasmate.
2. go File->close Project
3. look at the startpage, the konsole is still there

Also in this patch I did s/m_konsole/m_konsoleWidget. The rest of the
widget use the naming m_fooWidget.


Diffs
-

  mainwindow.h 8005d26 
  mainwindow.cpp b84da4a 

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


Testing
---


Thanks,

Giorgos Tsiapaliwkas

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

Review Request: The preview action shouldn't be visible all the time

2012-09-17 Thread Giorgos Tsiapaliwkas 

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

Review request for Plasma.


Description
---

This patches fixes the above bugs


This addresses bugs 305866 and 305867.
http://bugs.kde.org/show_bug.cgi?id=305866
http://bugs.kde.org/show_bug.cgi?id=305867


Diffs
-

  mainwindow.cpp b84da4a 

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


Testing
---

works


Thanks,

Giorgos Tsiapaliwkas

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

Review Request: Fix repositioning the toolbox when the widgets are locked

2012-09-17 Thread Ralf Jung 

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

Review request for Plasma.


Description
---

This fixes repositioning the toolbox on screen resize with the widgets being 
locked. Formerly, the toolbox would stick to its previous position, leaving it 
totally inaccessible in case the screen shrunk, and leaving it in the wrong 
shape in case the screen was grown. See the bugreport for further details.


This addresses bug 302645.
http://bugs.kde.org/show_bug.cgi?id=302645


Diffs
-

  plasma/desktop/toolboxes/internaltoolbox.cpp 2c22b70 

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


Testing
---

The bug is not reproducible anymore.


Thanks,

Ralf Jung

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