Re: Review Request 112208: KMix qml applet

[Diego Casella]

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

(Updated Sept. 22, 2016, 8:41 p.m.)


Status
--

This change has been discarded.


Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
Igor Poboiko.


Repository: kmix


Description
---

KMix qml applet.
As you can see from the screenshot, the applet is pretty much functional: you 
can display all the controls available, change its orientation, and decide to 
whether show all of them or just the Master Control, and refresh its status 
when new controls are added/removed/updated (such as Amarok current playing 
track). See screenshots below :)
Differences from the old kmix tray:
* no media player controls ( I never investigated how to get them, but honestly 
opening the audio applet to change/skip/pause audio track makes little sense to 
me ... if anyone wants this feature back, don't be shy and step in);
* the button used to select which Mixers are visible has been changed to open 
Phonon kcm page: since visible mixers are already configurable from KMix app, 
having a button to show KMix *and* a button to modify Mixers visibilty made 
little sense here too, so I preferred to give more visibility to Phonon kcm;

Known issues:
* there is still no way to get notified of mouse wheel events over the 
popupIcon, so it is not possible to scroll over to increase/decrease the master 
control volume;
* no scroll events over the sliders too;
* if you want to use the applet you most likely will disable KMix tray icon 
but, if you do so, KMix will show its GUI at every login and you have to close 
it manually. This requires KMix to be patched. Furthermore, if you click "KMix 
Setup" button, KMix window will not restored anymore: this needs to be pathed 
as well.
* resize doesn't work properly.


Diffs
-

  plasma/kmix-applet-qml/contents/ui/ButtonBar.qml 1467957 
  plasma/kmix-applet-qml/contents/ui/kmixapplet.qml 6c09359 

Diff: https://git.reviewboard.kde.org/r/112208/diff/


Testing
---

Tested against master and works fine.


File Attachments


Default look
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
Menu Actions
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
Applet Config Options
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
Vertical Control
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
ToolButton label and Config page after updates
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
Control Icon and Label left aligned
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
Kmix, horizontal view
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/9d6b0ca4-5a75-45cc-ab8e-61b13d4079e6__kmix_horizontal_new.png
Kmix applet, vertical view
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/7efb308a-c306-47c2-883f-64d1f32db5b5__kmix_vertical_new.png


Thanks,

Diego Casella

Re: Review Request 112208: KMix qml applet

[Diego Casella]

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

(Updated Aug. 22, 2014, 8:26 a.m.)


Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
Igor Poboiko.


Changes
---

Explicitly call DBus to show KMix user interface.


Repository: kmix


Description (updated)
---

KMix qml applet.
As you can see from the screenshot, the applet is pretty much functional: you 
can display all the controls available, change its orientation, and decide to 
whether show all of them or just the Master Control, and refresh its status 
when new controls are added/removed/updated (such as Amarok current playing 
track). See screenshots below :)
Differences from the old kmix tray:
* no media player controls ( I never investigated how to get them, but honestly 
opening the audio applet to change/skip/pause audio track makes little sense to 
me ... if anyone wants this feature back, don't be shy and step in);
* the button used to select which Mixers are visible has been changed to open 
Phonon kcm page: since visible mixers are already configurable from KMix app, 
having a button to show KMix *and* a button to modify Mixers visibilty made 
little sense here too, so I preferred to give more visibility to Phonon kcm;

Known issues:
* there is still no way to get notified of mouse wheel events over the 
popupIcon, so it is not possible to scroll over to increase/decrease the master 
control volume;
* no scroll events over the sliders too;
* if you want to use the applet you most likely will disable KMix tray icon 
but, if you do so, KMix will show its GUI at every login and you have to close 
it manually. This requires KMix to be patched. Furthermore, if you click "KMix 
Setup" button, KMix window will not restored anymore: this needs to be pathed 
as well.
* resize doesn't work properly.


Diffs (updated)
-

  plasma/kmix-applet-qml/contents/ui/ButtonBar.qml 1467957 
  plasma/kmix-applet-qml/contents/ui/kmixapplet.qml 6c09359 

Diff: https://git.reviewboard.kde.org/r/112208/diff/


Testing
---

Tested against master and works fine.


File Attachments


Default look
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
Menu Actions
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
Applet Config Options
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
Vertical Control
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
ToolButton label and Config page after updates
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
Control Icon and Label left aligned
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
Kmix, horizontal view
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/9d6b0ca4-5a75-45cc-ab8e-61b13d4079e6__kmix_horizontal_new.png
Kmix applet, vertical view
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/7efb308a-c306-47c2-883f-64d1f32db5b5__kmix_vertical_new.png


Thanks,

Diego Casella

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 12, 2014, 11:19 a.m., Christian Esken wrote:
> > For me it looks fine, with some questions:
> > 1) Is this completely decoupled from KMix? I do not see a "open mixer" to 
> > open the main application.
> > 2) Is it supposed to be integrated in KMix
> > 3) In general, the question is how to progress from here. Diego, do you 
> > want KMix integration, or a standalone app? Have any ideas or plans to get 
> > it in KDE?
> 
> Martin Klapetek wrote:
> Note that new work on QML based KMix has started, however this will be 
> Plasma5 only --> http://apachelog.wordpress.com/2014/08/11/volume/
> 
> Diego Casella wrote:
> I'll recap everything, hopefully once for all..
> This applet is meant to show the availabe mixers (with the option to show 
> all of them, or just the Master one), and modify/mute/unmute them. That's all.
> If you need to change Master channel or in general configure KMix, you 
> need to run the "old" KMix application. That's why, in the QML applet, I 
> added a button named "Mixer setup": you click it, and the "old" KMix should 
> appear (in my opinion QML applets have be minimal and simple, so everything 
> else must be done in a regular QtWidget based application).
> Anyway back on the topic: I said "should" because at the moment KMix does 
> not appear, complaining that:
> 
> "QDBusConnection: session D-Bus connection created before 
> QCoreApplication. Application may misbehave."
> 
> This is the reason why I mentioned, in the very first description of this 
> review request, that KMix needs to be patched :)
> As about "how to progess from here", I've mentioned some ideas in the 
> beginning:
> 
> * patch Plasma QML bindings to provide mouse wheel events, so I can 
> intercept scroll events in the panel and update volume levels accordingly, 
> providing the same functionality the current KMix tray icon does;
> * patch Plasma QML slider to provide mouse wheel support (don't know if 
> this has been already fixed in Plasma5);
> * patch KMix itself. It should run somewhat "daemonized" and, when QML 
> applet calls "kmix" the regular, QtWidget-based application, will pop up. 
> Since in the sourcecode I've seen references to "kmixd", which i think it 
> stands for "KMix daemon", this may be simple to implement: the daemon 
> provides the low-level connection to the hardware, and this applet and KMix 
> itself connect to the daemon (via DataEngine/DBus mechanism) to communicate 
> with it.
> 
> 
> That being said:
> * I've been trying to update this applet in the last couple of years, but
> * since KDE4/Plasma is now in maintenance mode (aka no new featured will 
> be added), those patches won't happen anymore;
> * and since someone is already on the process to "reinvent" the wheel;
> 
> I'm kinda sad/tired of how things went so far. The applet is pretty 
> functional (I use it on a daily basis), and it could work fine in Plasma5 
> too. As far as I'm concerned, at this point I don't see any reason to keep 
> this review open. If Harald wants to use any portion of this code, I'm 100% 
> OK with that.
> 
> Christian Esken wrote:
> Diego, I am not sure what went so wrong here. I am defintely also not 
> happy how things went on. What makes me most sad is, that you have a working 
> QML applet that just needs really minor integration work. All these minimal 
> issues like "scrollwheel not supported" (1) should really not stop us from 
> giving the users the option. If they must have scrollwheel or media buttons, 
> then they can use classic KMix dock. If they want a nicer integrated applet, 
> they can use your applet (2). It can be a simple option in KMix's 
> configuration dialog (Dock: Classic, Plasma, Off) instaed of (Dock: On, Off).
> 
> Sigh :-|
> 
> 
> Whatever your decision is, I can understand you Diego. If you want to 
> integrate it would make me happy (see some technical tips below). If you do 
> not want it or you cannot (essential missing plasma features that you do not 
> want to add yourselves), then it is possibly better to close this review 
> request.
> 
> --- Technical notes ---
> 
> About daemonizing KMix: That exists since forever: Simply disable "dock 
> into systray" and close window, and KMix will vanish forever. The "KMix will 
> show its GUI at every login" behavior/issue is gone since the support of 
> hotplugging. To show (I cannot remember 

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 12, 2014, 11:19 a.m., Christian Esken wrote:
> > For me it looks fine, with some questions:
> > 1) Is this completely decoupled from KMix? I do not see a "open mixer" to 
> > open the main application.
> > 2) Is it supposed to be integrated in KMix
> > 3) In general, the question is how to progress from here. Diego, do you 
> > want KMix integration, or a standalone app? Have any ideas or plans to get 
> > it in KDE?
> 
> Martin Klapetek wrote:
> Note that new work on QML based KMix has started, however this will be 
> Plasma5 only --> http://apachelog.wordpress.com/2014/08/11/volume/

I'll recap everything, hopefully once for all..
This applet is meant to show the availabe mixers (with the option to show all 
of them, or just the Master one), and modify/mute/unmute them. That's all.
If you need to change Master channel or in general configure KMix, you need to 
run the "old" KMix application. That's why, in the QML applet, I added a button 
named "Mixer setup": you click it, and the "old" KMix should appear (in my 
opinion QML applets have be minimal and simple, so everything else must be done 
in a regular QtWidget based application).
Anyway back on the topic: I said "should" because at the moment KMix does not 
appear, complaining that:

"QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave."

This is the reason why I mentioned, in the very first description of this 
review request, that KMix needs to be patched :)
As about "how to progess from here", I've mentioned some ideas in the beginning:

* patch Plasma QML bindings to provide mouse wheel events, so I can intercept 
scroll events in the panel and update volume levels accordingly, providing the 
same functionality the current KMix tray icon does;
* patch Plasma QML slider to provide mouse wheel support (don't know if this 
has been already fixed in Plasma5);
* patch KMix itself. It should run somewhat "daemonized" and, when QML applet 
calls "kmix" the regular, QtWidget-based application, will pop up. Since in the 
sourcecode I've seen references to "kmixd", which i think it stands for "KMix 
daemon", this may be simple to implement: the daemon provides the low-level 
connection to the hardware, and this applet and KMix itself connect to the 
daemon (via DataEngine/DBus mechanism) to communicate with it.


That being said:
* I've been trying to update this applet in the last couple of years, but
* since KDE4/Plasma is now in maintenance mode (aka no new featured will be 
added), those patches won't happen anymore;
* and since someone is already on the process to "reinvent" the wheel;

I'm kinda sad/tired of how things went so far. The applet is pretty functional 
(I use it on a daily basis), and it could work fine in Plasma5 too. As far as 
I'm concerned, at this point I don't see any reason to keep this review open. 
If Harald wants to use any portion of this code, I'm 100% OK with that.


- Diego


-----------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/112208/#review64369
---


On May 4, 2014, 9:46 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated May 4, 2014, 9:46 p.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Repository: kmix
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility 

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On March 22, 2014, 11:09 p.m., Mark Gaiser wrote:
> > Is there still an intention on getting this in KDE 4.xx?
> > Just wondering since it seems to be much better then the current kmix popup.
> 
> Christian Esken wrote:
> I also haven't heard about further development here. Diego as original 
> submitter or somebody else would have to push this. I added this as a topic 
> for the KDE Multimedia Sprint. It takes place in about 4 months (August 
> 2014): https://sprints.kde.org/sprint/212
> 
> Diego Casella wrote:
> My bad, sorry guys but I'm still in a busy period of my life :/
> I'll try to fix the remaining issues pointed out in this review request, 
> and then submit the changes here.
> There is still an ongoing (and BIG imho) issue anyway: we really really 
> really need a Plasma QML callback to capture mouse scroll events. AFAIK there 
> still isn't in both Plasma 4.13 and also Plasma Next. And talking about kmix 
> applet, one feature everyone is using is the ability to adjust volume level 
> with just few mouse scrolls over the applet icon.
> I think we need to fix this problem as well, what do you think?
> 
> Christian Esken wrote:
> Yes, most definitely we should have mouse scroll events. I guess 
> everybody is using it on the tray icon and in the main window, and so it 
> should also be there for the applet.
> But if users can choose the plasmoid as an optional, then this is not a 
> showstopper. It is probably better to get it started as is. We could mark it 
> "early-access", so interested people can start playing around with it and 
> using it.
> 
> Mark Gaiser wrote:
> Quote: "There is still an ongoing (and BIG imho) issue anyway: we really 
> really really need a Plasma QML callback to capture mouse scroll events"
> Seriously?
> 
> I never ever used the scrolling on the tray icon itself. I didn't even 
> know it was possible till you said it in this post.
> But please don't let such a minor issue block your progress :)
> 
> Clicking the icon or using the media keys on most keyboards is probably 
> enough possibilities for people change the volume. Scrolling on the icon is 
> imho just bonus stuff.
> 
> Martin Klapetek wrote:
> > Clicking the icon or using the media keys on most keyboards is probably 
> enough possibilities for people change the volume. Scrolling on the icon is 
> imho just bonus stuff.
> 
> I use it extensively and every new user I put on Plasma, that's one of 
> the first things I teach them. It's much more convenient because ~80% of the 
> time you're holding your mouse in your hand and ~95% of the time you have 
> your eyes on the screen. Going for keyboard button means in many cases taking 
> your eyes off the screen and looking at the exact button position, often you 
> even have to let the mouse go and move your hand to keyboard (for example 
> YouTube video/any other media being too loud).
> 
> Mark Gaiser wrote:
> But you can do it all with your mouse.
> 1. Click the icon
> 2. move your cursor to the stream (or master channel).
> 3. scroll...
> 
> Just to be sure, scrolling (as i described in the steps above) works in 
> this proposed component, right?
> All that's not working is scrolling on the tray icon, correct?
> 
> Note: I happen to have a keyboard without media keys. I always click the 
> icon and scroll on the stream where i want to change the sound level.
> 
> Martin Klapetek wrote:
> Sure you can, it's just way easier to simply scroll on an icon than 
> opening this -> http://i.imgur.com/LcyFzq6.png and identifying the channel 
> you need to change (the assumption being that you want to change only the 
> main volume, not per stream controls). That way you're doing the visual 
> identification twice - first locating the systray icon, , now locating 
> the proper handle. So doing it that way is mentally harder task than simply 
> scroll the icon, which also saves you a click ;)
> 
> Diego Casella wrote:
> @Mark Gaiser: volume change on scroll is a very, very, handy and smart 
> feature (Martin's answer sums up everything nicely): it would be a pity if we 
> lose it because of a lack in the Plasma QML bindings. By the way, an other 
> plasma applet which uses such feature is, for example, the clock applet: it 
> uses mouse scrolls to loop between timezones (if selected by the user), which 
> is handy for example to check the UTC time before an IRC meeting ;)
> Besides, you're the first person who _wasn't_ aware of that feature :P
> As last resort, if we can't come up

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On March 22, 2014, 11:09 p.m., Mark Gaiser wrote:
> > Is there still an intention on getting this in KDE 4.xx?
> > Just wondering since it seems to be much better then the current kmix popup.
> 
> Christian Esken wrote:
> I also haven't heard about further development here. Diego as original 
> submitter or somebody else would have to push this. I added this as a topic 
> for the KDE Multimedia Sprint. It takes place in about 4 months (August 
> 2014): https://sprints.kde.org/sprint/212
> 
> Diego Casella wrote:
> My bad, sorry guys but I'm still in a busy period of my life :/
> I'll try to fix the remaining issues pointed out in this review request, 
> and then submit the changes here.
> There is still an ongoing (and BIG imho) issue anyway: we really really 
> really need a Plasma QML callback to capture mouse scroll events. AFAIK there 
> still isn't in both Plasma 4.13 and also Plasma Next. And talking about kmix 
> applet, one feature everyone is using is the ability to adjust volume level 
> with just few mouse scrolls over the applet icon.
> I think we need to fix this problem as well, what do you think?
> 
> Christian Esken wrote:
> Yes, most definitely we should have mouse scroll events. I guess 
> everybody is using it on the tray icon and in the main window, and so it 
> should also be there for the applet.
> But if users can choose the plasmoid as an optional, then this is not a 
> showstopper. It is probably better to get it started as is. We could mark it 
> "early-access", so interested people can start playing around with it and 
> using it.
> 
> Mark Gaiser wrote:
> Quote: "There is still an ongoing (and BIG imho) issue anyway: we really 
> really really need a Plasma QML callback to capture mouse scroll events"
> Seriously?
> 
> I never ever used the scrolling on the tray icon itself. I didn't even 
> know it was possible till you said it in this post.
> But please don't let such a minor issue block your progress :)
> 
> Clicking the icon or using the media keys on most keyboards is probably 
> enough possibilities for people change the volume. Scrolling on the icon is 
> imho just bonus stuff.
> 
> Martin Klapetek wrote:
> > Clicking the icon or using the media keys on most keyboards is probably 
> enough possibilities for people change the volume. Scrolling on the icon is 
> imho just bonus stuff.
> 
> I use it extensively and every new user I put on Plasma, that's one of 
> the first things I teach them. It's much more convenient because ~80% of the 
> time you're holding your mouse in your hand and ~95% of the time you have 
> your eyes on the screen. Going for keyboard button means in many cases taking 
> your eyes off the screen and looking at the exact button position, often you 
> even have to let the mouse go and move your hand to keyboard (for example 
> YouTube video/any other media being too loud).
> 
> Mark Gaiser wrote:
> But you can do it all with your mouse.
> 1. Click the icon
> 2. move your cursor to the stream (or master channel).
> 3. scroll...
> 
> Just to be sure, scrolling (as i described in the steps above) works in 
> this proposed component, right?
> All that's not working is scrolling on the tray icon, correct?
> 
> Note: I happen to have a keyboard without media keys. I always click the 
> icon and scroll on the stream where i want to change the sound level.
> 
> Martin Klapetek wrote:
> Sure you can, it's just way easier to simply scroll on an icon than 
> opening this -> http://i.imgur.com/LcyFzq6.png and identifying the channel 
> you need to change (the assumption being that you want to change only the 
> main volume, not per stream controls). That way you're doing the visual 
> identification twice - first locating the systray icon, , now locating 
> the proper handle. So doing it that way is mentally harder task than simply 
> scroll the icon, which also saves you a click ;)

@Mark Gaiser: volume change on scroll is a very, very, handy and smart feature 
(Martin's answer sums up everything nicely): it would be a pity if we lose it 
because of a lack in the Plasma QML bindings. By the way, an other plasma 
applet which uses such feature is, for example, the clock applet: it uses mouse 
scrolls to loop between timezones (if selected by the user), which is handy for 
example to check the UTC time before an IRC meeting ;)
Besides, you're the first person who _wasn't_ aware of that feature :P
As last resort, if we can't come up with a proper solution to whether add 

Re: Review Request 112208: KMix qml applet

[Diego Casella]

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

(Updated May 4, 2014, 9:46 p.m.)


Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
Igor Poboiko.


Changes
---

Here you go, an other update with the following changes:
* fixed the resizing issues: now resizing the applet will also update its 
content to fit/shrink to the new applet dimensions;
* added the boolean check to avoid flickering on the slider when updating 
volume level;
* improved icon positioning and padding;
* added a background frame to better distinguish volume controls;

I've also attached two new screenshots to show you how the applet now looks 
like, hope you like it :)


Repository: kmix


Description
---

KMix qml applet.
As you can see from the screenshot, the applet is pretty much functional: you 
can display all the controls available, change its orientation, and decide to 
whether show all of them or just the Master Control, and refresh its status 
when new controls are added/removed/updated (such as Amarok current playing 
track). See screenshots below :)
Differences from the old kmix tray:
* no media player controls ( I never investigated how to get them, but honestly 
opening the audio applet to change/skip/pause audio track makes little sense to 
me ... if anyone wants this feature back, don't be shy and step in);
* the button used to select which Mixers are visible has been changed to open 
Phonon kcm page: since visible mixers are already configurable from KMix app, 
having a button to show KMix *and* a button to modify Mixers visibilty made 
little sense here too, so I preferred to give more visibility to Phonon kcm;

Known issues:
* there is still no way to get notified of mouse wheel events over the 
popupIcon, so it is not possible to scroll over to increase/decrease the master 
control volume;
* no scroll events over the sliders too;
* if you want to use the applet you most likely will disable KMix tray icon 
but, if you do so, KMix will show its GUI at every login and you have to close 
it manually. This requires KMix to be patched. Furthermore, if you click "KMix 
Setup" button, KMix window will not restored anymore: this needs to be pathed 
as well.
* resize doesn't work properly.


Diffs (updated)
-

  plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml 7e87c8e 
  plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 26f2968 
  plasma/kmix-applet-qml/contents/ui/MixersList.qml 66bda73 
  plasma/kmix-applet-qml/contents/ui/VerticalControl.qml 1702be7 
  plasma/kmix-applet-qml/contents/ui/VerticalMixerListDelegate.qml bab9ac6 
  plasma/kmix-applet-qml/contents/ui/kmixapplet.qml eecb91c 

Diff: https://git.reviewboard.kde.org/r/112208/diff/


Testing
---

Tested against master and works fine.


File Attachments (updated)


Default look
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
Menu Actions
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
Applet Config Options
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
Vertical Control
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
ToolButton label and Config page after updates
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
Control Icon and Label left aligned
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
Kmix, horizontal view
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/9d6b0ca4-5a75-45cc-ab8e-61b13d4079e6__kmix_horizontal_new.png
Kmix applet, vertical view
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/7efb308a-c306-47c2-883f-64d1f32db5b5__kmix_vertical_new.png


Thanks,

Diego Casella

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On March 22, 2014, 11:09 p.m., Mark Gaiser wrote:
> > Is there still an intention on getting this in KDE 4.xx?
> > Just wondering since it seems to be much better then the current kmix popup.
> 
> Christian Esken wrote:
> I also haven't heard about further development here. Diego as original 
> submitter or somebody else would have to push this. I added this as a topic 
> for the KDE Multimedia Sprint. It takes place in about 4 months (August 
> 2014): https://sprints.kde.org/sprint/212

My bad, sorry guys but I'm still in a busy period of my life :/
I'll try to fix the remaining issues pointed out in this review request, and 
then submit the changes here.
There is still an ongoing (and BIG imho) issue anyway: we really really really 
need a Plasma QML callback to capture mouse scroll events. AFAIK there still 
isn't in both Plasma 4.13 and also Plasma Next. And talking about kmix applet, 
one feature everyone is using is the ability to adjust volume level with just 
few mouse scrolls over the applet icon.
I think we need to fix this problem as well, what do you think?


- Diego


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/112208/#review53775
-------


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Repository: kmix
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/112208/diff/
> 
> 
> Testing
> ---
> 
> Tested against master and works fine.
> 
> 
> File Attachments
> 
> 
> Default look
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
> Menu Actions
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
> Applet Config Options
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
> Vertical Control
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
> ToolButton label and Config page after updates
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
> Control Icon and Label left aligned
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Sept. 2, 2013, 10:32 p.m., Sebastian Kügler wrote:
> > I've installed the applet, and had a look in more detail. It's coming along 
> > really nicely, and already feels a lot better than the QWidget-based kmix. 
> > :)
> > 
> > Some issues I've found:
> > - Resizing the popup dialog doesn't resize its content, this leads to 
> > unfriendly resizing on the one hand, and clipping of the list of channel 
> > items on the other
> > - The listview is draggable when it doesn't have to be, use something like 
> > interactive: height < contentsHeight in the ListView to prevent that from 
> > happening
> > - The vertical view needs definitely more spacing, if we really want to 
> > keep it
> > - Some spacing would do the listview good, this leads to better grouping of 
> > the channel items
> > - The item name isn't properly anchored and should either determine the 
> > minimum width, or be elided
> > - The percentage on the left hand side should not be bold
> > - The slider feels a bit jerky, this is probably the event round-tripping 
> > Xetuan mentions, see that part of the thread
> > - The speaker icon feels a bit weird to mute the channel, I think that's 
> > because it's used with different semantics for the applet as well: open 
> > mixer (the panel icon). Maybe it could be done with a checkbox, and 
> > possibly moved to the top-right, so that the layout
> > - The initial values in the config dialog are not set up correctly. Try 
> > switching to master channel only, OK, reopen config dialog: it's set to 
> > show all channels. Haven't checked if this is also the case for the 
> > orientation
> > - Show all mixers -> "Show all Channels" (i.e. does "mixer" make sense 
> > here, or is it really a channel, or a "Volume Control"?
> > - "Mixer slider orientation" -> "Orientation" ?
> > 
> > Overall, nice work. This is good stuff. =)
> 
> Sebastian Kügler wrote:
> Haven't heard about this in a long time, what's the status?
> 
> Diego Casella wrote:
> I'm in a quite busy period lately, but I didn't forget this. I'll be back 
> on it in a week or two :)
> 
> Christian Esken wrote:
> From the screenshots its starting to look nice. I have a question about 
> how to integrate this. Likely some people will prefer classic tray (e.g. 
> media player control) and others the QML applet (fits KDE better). I would 
> like to see a seamless integration into KMix, so the user is able to choose 
> between classic tray and QML applet, even from within KMix (1).
> Do you think this is feasible, Diego? Or does anybody else have an 
> opinion about it?
> 
> 
> (1) I am currently redoing the configuration dialog using KConfigDialog 
> and am dedicating one Tab to Systray/Sound Menu related features, where this 
> would fit nicely: 
> http://kmix5.wordpress.com/2013/11/26/secret-view-in-the-new-configuration-dialog/

I think Aaron or Marco have a way better answer than the one i could provide, 
it's in the earlier comments of this rr.


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Repository: kmix
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: sinc

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Sept. 2, 2013, 10:32 p.m., Sebastian Kügler wrote:
> > I've installed the applet, and had a look in more detail. It's coming along 
> > really nicely, and already feels a lot better than the QWidget-based kmix. 
> > :)
> > 
> > Some issues I've found:
> > - Resizing the popup dialog doesn't resize its content, this leads to 
> > unfriendly resizing on the one hand, and clipping of the list of channel 
> > items on the other
> > - The listview is draggable when it doesn't have to be, use something like 
> > interactive: height < contentsHeight in the ListView to prevent that from 
> > happening
> > - The vertical view needs definitely more spacing, if we really want to 
> > keep it
> > - Some spacing would do the listview good, this leads to better grouping of 
> > the channel items
> > - The item name isn't properly anchored and should either determine the 
> > minimum width, or be elided
> > - The percentage on the left hand side should not be bold
> > - The slider feels a bit jerky, this is probably the event round-tripping 
> > Xetuan mentions, see that part of the thread
> > - The speaker icon feels a bit weird to mute the channel, I think that's 
> > because it's used with different semantics for the applet as well: open 
> > mixer (the panel icon). Maybe it could be done with a checkbox, and 
> > possibly moved to the top-right, so that the layout
> > - The initial values in the config dialog are not set up correctly. Try 
> > switching to master channel only, OK, reopen config dialog: it's set to 
> > show all channels. Haven't checked if this is also the case for the 
> > orientation
> > - Show all mixers -> "Show all Channels" (i.e. does "mixer" make sense 
> > here, or is it really a channel, or a "Volume Control"?
> > - "Mixer slider orientation" -> "Orientation" ?
> > 
> > Overall, nice work. This is good stuff. =)
> 
> Sebastian Kügler wrote:
> Haven't heard about this in a long time, what's the status?

I'm in a quite busy period lately, but I didn't forget this. I'll be back on it 
in a week or two :)


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Repository: kmix
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 28, 2013, 9:10 p.m., Xuetian Weng wrote:
> > plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml, line 55
> > <http://git.reviewboard.kde.org/r/112208/diff/1/?file=183953#file183953line55>
> >
> > if volume is changed from kmix, not from the applet, this would issue a 
> > duplicate service call to dataengine.
> > 
> > my solution is to add a bool protector to disable this signal if the 
> > data change is not from user.
> 
> Xuetian Weng wrote:
> sorry for noise, maybe you should try onSliderMoved signal instead.
> 
> Diego Casella wrote:
> cannot bind to a non-existent property, says plasma ... are you sure this 
> method exists?
> 
> Xuetian Weng wrote:
> ah sorry... I initially thought it's Plasma/Slider in cpp but now it 
> seems it's another implementation in qml.
> the cpp version of Plasma/Slider is actually in plasma.graphicswidget but 
> since we're moving to qt5 in the future graphicswidget implementation is not 
> a preferable solution...
> 
> So you might want to use the solution in my first comment.
> 
> Diego Casella wrote:
> imho it is too hackish and the applet works good even in this state. Do 
> we really need to introduce something like that when you change the volume 
> levels for, say, a total of 5 minutes every day (overstimated)?
> 
> Xuetian Weng wrote:
> There is some possible data race when last time I looked at the 
> brightness slider in battery plasmoid. Especially when user drag the slider 
> which generates more than one onValueChanged (Click on slider is usually ok).
> 
> And the slider looks very jumpy in that case.
> 
> user drags the slider 
> onValueChanged caused by user
> call setVolume to A to backend
> user drags slider further to B
> onValueChanged caused by user
> call setVolume B to backend
> 
> backend notifies the change of A
> onValueChanged caused by backend notificatoin
> slider change back to A but user mouse is actually already on B.
> and now it will send setVolume to A again.
> and it will generate another onValueChanged.
> 
> Eventually it will have volume at B but if the difference of value A and 
> B is huge, the visual reflection would be really bad.
> And in some case it might generate really quite a lot onValueChanged 
> (since theoretically it can generate infinite ping-pong loop if all events 
> arrives just-in-time.). 
> 
> I didn't test your plasmoid but you can try to drag it aggressively from 
> on side to the other side to see if this is really a issue.

Believe me, I know exactly the issue you are talking about. I tried various 
fixes it since 2010, when I did my first (ugly) proof of concept applet[1] in 
C++. Back at that time, i simply disconnected the slider, updated it, and then 
restored the connection.
Then, moving to javascript and after that, into qml world, I tried the boolean 
solution too, but I realized that: I was adding kind of hackish code to address 
an issue which is in fact just a corner case, really. No one (mentally healthy 
enough :) would ever drag aggressively the audio slider back and forth and blow 
his/her auditive apparatus just because it's funny doing so.
I'm not saying your observation is wrong but, imho, we are adding more code to 
cover a really improper usage of the applet which is unlikely to happen.
Let's hear from other devs what they think about it, so we will better decide 
whether to deal with that issue or not :)


[1] 
http://quickgit.kde.org/?p=scratch%2Fcasella%2Fplasma-applet-kmix.git&a=blob&h=551c9eab7827c4d1d4a162bb772d9ec30091a1ad&hb=e5d4ddd21943cbf93166ff8fbd61755ad00d495e&f=mixercontrol.cpp#L61


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 28, 2013, 9:10 p.m., Xuetian Weng wrote:
> > plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml, line 55
> > <http://git.reviewboard.kde.org/r/112208/diff/1/?file=183953#file183953line55>
> >
> > if volume is changed from kmix, not from the applet, this would issue a 
> > duplicate service call to dataengine.
> > 
> > my solution is to add a bool protector to disable this signal if the 
> > data change is not from user.
> 
> Xuetian Weng wrote:
> sorry for noise, maybe you should try onSliderMoved signal instead.
> 
> Diego Casella wrote:
> cannot bind to a non-existent property, says plasma ... are you sure this 
> method exists?
> 
> Xuetian Weng wrote:
> ah sorry... I initially thought it's Plasma/Slider in cpp but now it 
> seems it's another implementation in qml.
> the cpp version of Plasma/Slider is actually in plasma.graphicswidget but 
> since we're moving to qt5 in the future graphicswidget implementation is not 
> a preferable solution...
> 
> So you might want to use the solution in my first comment.

imho it is too hackish and the applet works good even in this state. Do we 
really need to introduce something like that when you change the volume levels 
for, say, a total of 5 minutes every day (overstimated)?


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112208/diff/
> 
> 
> Testing
> ---
> 
> Tested against master and works fine.
> 
> 
> File Attachments
> 
> 
> Default look
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
> Menu Actions
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
> Applet Config Options
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
> Vertical Control
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
> ToolButton label and Config page after updates
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
> Control Icon and Label left aligned
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 22, 2013, 10:46 p.m., Aaron J. Seigo wrote:
> > File Attachment: Applet Config Options
> > <http://git.reviewboard.kde.org/r/112208/#fcomment90>
> >
> > Do we even really need horizontal/vertical orientation for the sliders 
> > as a configuration option? Other than "because we can" what is the actual 
> > end user value of that option?
> 
> Igor Poboiko wrote:
> AFAIK MacOS and Windows use vertical slider orientation, while 
> Gnome&Ubuntu use horizontal sliders. Some people may be used to one of the 
> variants and find another one inconvenient. So why not let them choose? There 
> is not that many options in that applet anyways.
> 
> Marco Martin wrote:
> i would prefer not having that as well, plasma appletswere designed to 
> make easy for the user to change a plasmoid with another if they don't like 
> it, rther than making the developer maintain many different code paths of 
> which some combination will always go untested...
> 
> one thing without a config dialog that may be tried is adjusting 
> horizontal or vertical how better suits the size of the config dialog at the 
> moment...
> 
> Sebastian Kügler wrote:
> Case in point: The use of QtHorizontal and QtVertical throughout the code 
> suggest to me that the horizontal case wasn't really tested in the submitted 
> version. Kinda supports Marco's fear of untested code pathes. ;-)
> 
> Diego Casella wrote:
> I've tried to keep compatibility with the "old" KMix interface, which 
> lets you choose whether you want horizontal or vertical sliders.
> 
> @Marco You are completely right, but we don't want to end with two 
> applets like "KMix with horizontal sliders" and "KMix with vertical sliders" 
> right? We should try to get a reliable procedure to retrieve the size of the 
> elements in the listview, which is the root of my issues with the applet 
> resize.
> 
> @Sebas Care to explain? Both the cases have been tested.
> 
> Sebastian Kügler wrote:
> sure, QtVertical and QtHorizontal do not exist, that's a syntax error. I 
> don't see how that could work, other than by complete accident.
> 
> Diego Casella wrote:
> Maybe hose enums were kept for backwards compatibilty, because they still 
> do exists. Right here:
> 
> https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/entry/plasma/scriptengines/javascript/plasmoid/appletinterface.h#L156
> 
> Since my very first draft of the kmix applet is litteraly *years* old, 
> even though I heavily refactored/modified/dropped the code, the QtVertical 
> enums is something iI never checked if they were still valid or not, since 
> they always worked fine :)
> 
> Diego Casella wrote:
> Out of curiosity: can you now confirm rev1 is working even if it isn't 
> supposed to, because somehow QtVertical/QtHorizontal are still defined in qml 
> when they shouldn't?
> 
> Do you want to keep the possibility to change the orientation of the 
> mixer controls?

@sebas ping?


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to mod

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 29, 2013, 4:05 a.m., Bhushan Shah wrote:
> > Can't we have it in branch or hosted somewhere on git?

yep, seems like it would be a good idea indeed ... casella-kmix-qml-applet is 
the branch I made.


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112208/diff/
> 
> 
> Testing
> ---
> 
> Tested against master and works fine.
> 
> 
> File Attachments
> 
> 
> Default look
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
> Menu Actions
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
> Applet Config Options
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
> Vertical Control
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
> ToolButton label and Config page after updates
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
> Control Icon and Label left aligned
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 28, 2013, 9:10 p.m., Xuetian Weng wrote:
> > plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml, line 55
> > <http://git.reviewboard.kde.org/r/112208/diff/1/?file=183953#file183953line55>
> >
> > if volume is changed from kmix, not from the applet, this would issue a 
> > duplicate service call to dataengine.
> > 
> > my solution is to add a bool protector to disable this signal if the 
> > data change is not from user.
> 
> Xuetian Weng wrote:
> sorry for noise, maybe you should try onSliderMoved signal instead.

cannot bind to a non-existent property, says plasma ... are you sure this 
method exists?


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112208/diff/
> 
> 
> Testing
> ---
> 
> Tested against master and works fine.
> 
> 
> File Attachments
> 
> 
> Default look
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
> Menu Actions
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
> Applet Config Options
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
> Vertical Control
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
> ToolButton label and Config page after updates
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
> Control Icon and Label left aligned
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 28, 2013, 9 p.m., Xuetian Weng wrote:
> > File Attachment: Control Icon and Label left aligned
> > <http://git.reviewboard.kde.org/r/112208/#fcomment89>
> >
> > It would be nice to have a line here.
> > 
> > svg: widgets/line and element horizontal-line would work here
> >

There's already a line to separate the buttons from the mixer listview. imho 
adding further separators is redundant, we already know that every slider 
refers to the mixer described by the label avobe itself.


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112208/diff/
> 
> 
> Testing
> ---
> 
> Tested against master and works fine.
> 
> 
> File Attachments
> 
> 
> Default look
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
> Menu Actions
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
> Applet Config Options
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
> Vertical Control
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
> ToolButton label and Config page after updates
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
> Control Icon and Label left aligned
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 22, 2013, 10:46 p.m., Aaron J. Seigo wrote:
> > File Attachment: Applet Config Options
> > <http://git.reviewboard.kde.org/r/112208/#fcomment87>
> >
> > Do we even really need horizontal/vertical orientation for the sliders 
> > as a configuration option? Other than "because we can" what is the actual 
> > end user value of that option?
> 
> Igor Poboiko wrote:
> AFAIK MacOS and Windows use vertical slider orientation, while 
> Gnome&Ubuntu use horizontal sliders. Some people may be used to one of the 
> variants and find another one inconvenient. So why not let them choose? There 
> is not that many options in that applet anyways.
> 
> Marco Martin wrote:
> i would prefer not having that as well, plasma appletswere designed to 
> make easy for the user to change a plasmoid with another if they don't like 
> it, rther than making the developer maintain many different code paths of 
> which some combination will always go untested...
> 
> one thing without a config dialog that may be tried is adjusting 
> horizontal or vertical how better suits the size of the config dialog at the 
> moment...
> 
> Sebastian Kügler wrote:
> Case in point: The use of QtHorizontal and QtVertical throughout the code 
> suggest to me that the horizontal case wasn't really tested in the submitted 
> version. Kinda supports Marco's fear of untested code pathes. ;-)
> 
> Diego Casella wrote:
> I've tried to keep compatibility with the "old" KMix interface, which 
> lets you choose whether you want horizontal or vertical sliders.
> 
> @Marco You are completely right, but we don't want to end with two 
> applets like "KMix with horizontal sliders" and "KMix with vertical sliders" 
> right? We should try to get a reliable procedure to retrieve the size of the 
> elements in the listview, which is the root of my issues with the applet 
> resize.
> 
> @Sebas Care to explain? Both the cases have been tested.
> 
> Sebastian Kügler wrote:
> sure, QtVertical and QtHorizontal do not exist, that's a syntax error. I 
> don't see how that could work, other than by complete accident.
> 
> Diego Casella wrote:
> Maybe hose enums were kept for backwards compatibilty, because they still 
> do exists. Right here:
> 
> https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/entry/plasma/scriptengines/javascript/plasmoid/appletinterface.h#L156
> 
> Since my very first draft of the kmix applet is litteraly *years* old, 
> even though I heavily refactored/modified/dropped the code, the QtVertical 
> enums is something iI never checked if they were still valid or not, since 
> they always worked fine :)

Out of curiosity: can you now confirm rev1 is working even if it isn't supposed 
to, because somehow QtVertical/QtHorizontal are still defined in qml when they 
shouldn't?

Do you want to keep the possibility to change the orientation of the mixer 
controls?


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibilit

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 27, 2013, 10:57 a.m., Martin Klapetek wrote:
> > File Attachment: Control Icon and Label left aligned
> > <http://git.reviewboard.kde.org/r/112208/#fcomment86>
> >
> > I wonder if we still need the speaker icons. The way I see it they 
> > represent two things - one is "how loud is this sound" (higher the volume 
> > is, more arcs the icon has). This is also represented by the slider and 
> > then by the percentage string too, so the "volume" information is there 3 
> > times. The second thing it does is saying "this is a volume control". This 
> > on the other hand is quite important I think, although if you popup kmix 
> > applet (which has the speaker icon again), I guess one expects the sliders 
> > to be volume adjusting sliders. Dunno, I think the plasmoid would be 
> > clearer without the speaker icons.
> > 
> > Either way, looks good when left aligned, good job!

That is a plain Plasma ToolButton, not a simple icon, which does the same as 
the button you can find in the "old" KMix interface does. If you click it, the 
corresponding channel will be muted. If it's already muted, it will be un-muted 
:)
imho the label gives a more concise/precise info about the actual volume level, 
which the slider cannot offer because of its nature.


- Diego


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


On Aug. 27, 2013, 8:40 a.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 27, 2013, 8:40 a.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112208/diff/
> 
> 
> Testing
> ---
> 
> Tested against master and works fine.
> 
> 
> File Attachments
> 
> 
> Default look
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
> Menu Actions
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
> Applet Config Options
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
> Vertical Control
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
> ToolButton label and Config page after updates
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
> Control Icon and Label left aligned
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

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

(Updated Aug. 27, 2013, 8:40 a.m.)


Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
Igor Poboiko.


Description
---

KMix qml applet.
As you can see from the screenshot, the applet is pretty much functional: you 
can display all the controls available, change its orientation, and decide to 
whether show all of them or just the Master Control, and refresh its status 
when new controls are added/removed/updated (such as Amarok current playing 
track). See screenshots below :)
Differences from the old kmix tray:
* no media player controls ( I never investigated how to get them, but honestly 
opening the audio applet to change/skip/pause audio track makes little sense to 
me ... if anyone wants this feature back, don't be shy and step in);
* the button used to select which Mixers are visible has been changed to open 
Phonon kcm page: since visible mixers are already configurable from KMix app, 
having a button to show KMix *and* a button to modify Mixers visibilty made 
little sense here too, so I preferred to give more visibility to Phonon kcm;

Known issues:
* there is still no way to get notified of mouse wheel events over the 
popupIcon, so it is not possible to scroll over to increase/decrease the master 
control volume;
* no scroll events over the sliders too;
* if you want to use the applet you most likely will disable KMix tray icon 
but, if you do so, KMix will show its GUI at every login and you have to close 
it manually. This requires KMix to be patched. Furthermore, if you click "KMix 
Setup" button, KMix window will not restored anymore: this needs to be pathed 
as well.
* resize doesn't work properly.


Diffs
-

  plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 

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


Testing
---

Tested against master and works fine.


File Attachments (updated)


Default look
  http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
Menu Actions
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
Applet Config Options
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
Vertical Control
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
ToolButton label and Config page after updates
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
Control Icon and Label left aligned
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png


Thanks,

Diego Casella

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

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

(Updated Aug. 27, 2013, 8:39 a.m.)


Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
Igor Poboiko.


Changes
---

Layout icon and control label on the left as david suggested


Description
---

KMix qml applet.
As you can see from the screenshot, the applet is pretty much functional: you 
can display all the controls available, change its orientation, and decide to 
whether show all of them or just the Master Control, and refresh its status 
when new controls are added/removed/updated (such as Amarok current playing 
track). See screenshots below :)
Differences from the old kmix tray:
* no media player controls ( I never investigated how to get them, but honestly 
opening the audio applet to change/skip/pause audio track makes little sense to 
me ... if anyone wants this feature back, don't be shy and step in);
* the button used to select which Mixers are visible has been changed to open 
Phonon kcm page: since visible mixers are already configurable from KMix app, 
having a button to show KMix *and* a button to modify Mixers visibilty made 
little sense here too, so I preferred to give more visibility to Phonon kcm;

Known issues:
* there is still no way to get notified of mouse wheel events over the 
popupIcon, so it is not possible to scroll over to increase/decrease the master 
control volume;
* no scroll events over the sliders too;
* if you want to use the applet you most likely will disable KMix tray icon 
but, if you do so, KMix will show its GUI at every login and you have to close 
it manually. This requires KMix to be patched. Furthermore, if you click "KMix 
Setup" button, KMix window will not restored anymore: this needs to be pathed 
as well.
* resize doesn't work properly.


Diffs (updated)
-

  plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 

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


Testing
---

Tested against master and works fine.


File Attachments


Default look
  http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
Menu Actions
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
Applet Config Options
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
Vertical Control
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
ToolButton label and Config page after updates
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png


Thanks,

Diego Casella

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 22, 2013, 2:34 p.m., Sebastian Kügler wrote:
> > File Attachment: Menu Actions
> > <http://git.reviewboard.kde.org/r/112208/#fcomment84>
> >
> > Maybe we could align this in the same way as the batter applet does?
> 
> Diego Casella wrote:
> The menu comes from a right-click from within the widget -not the applet 
> icon in the panel-, but i forgot to check the "include mouse pointer" option 
> when I took that screenshot :)
> 
> Martin Klapetek wrote:
> (the comment was about the plasmoid stuff alignment, not the menu ;)
> 
> I'd agree with aligning it the same way as battery plasmoid - put the app 
> icon on the left, make it span over two rows and discard the speaker icon. 
> Also the text should be aligned to left then instead of centered, looks a bit 
> chaotic imho.
> 
> That way we'll have consistent look in two important parts of the 
> workspace, which I believe is very important.

I see, my bad.
Pretty easy fix, will submit the update in a min ;)


- Diego


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


On Aug. 24, 2013, 3:11 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 24, 2013, 3:11 p.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/config/main.xml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/ButtonBar.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/MixersList.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/config.ui PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/kmixapplet.qml PRE-CREATION 
>   plasma/kmix-applet-qml/metadata.desktop PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112208/diff/
> 
> 
> Testing
> ---
> 
> Tested against master and works fine.
> 
> 
> File Attachments
> 
> 
> Default look
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
> Menu Actions
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
> Applet Config Options
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
> Vertical Control
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
> ToolButton label and Config page after updates
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 26, 2013, 3:38 p.m., Igor Poboiko wrote:
> > File Attachment: Vertical Control
> > <http://git.reviewboard.kde.org/r/112208/#fcomment83>
> >
> > Do we need it? 
> > 
> > (there is volume level percentage under the tooltip)
> > 
> > It isn't consistent with horizontal view where there is no such label. 
> > Also it duplicates the information from slider. And also it reacts pretty 
> > slow to the changes when user moves the slider (due to slowness of the 
> > chain plasma->dbus->kmix->backend->kmix->dbus->plasma), which is pretty 
> > frustrating.
> > 
> > A label (or a tooltip maybe?) with device name would be nice, because 
> > it is pretty hard to decide what volume am I changing when there are 
> > multiple cards (or just input and output sliders like in PulseAudio).

tooltpis are gone in rev2, see sebas comment ;)
The reason I didn't used a label with this layout is that it would take sooo 
much space but sure, this is an issue that must be addressed because the user 
must know which control he/she's going to modify ... I'll try to play with some 
wrapMode Label properties and see if I can get something usable and good 
looking.


- Diego


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


On Aug. 24, 2013, 3:11 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 24, 2013, 3:11 p.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/config/main.xml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/ButtonBar.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/MixersList.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/config.ui PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/kmixapplet.qml PRE-CREATION 
>   plasma/kmix-applet-qml/metadata.desktop PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112208/diff/
> 
> 
> Testing
> ---
> 
> Tested against master and works fine.
> 
> 
> File Attachments
> 
> 
> Default look
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
> Menu Actions
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 22, 2013, 10:46 p.m., Aaron J. Seigo wrote:
> > File Attachment: Applet Config Options
> > <http://git.reviewboard.kde.org/r/112208/#fcomment79>
> >
> > Do we even really need horizontal/vertical orientation for the sliders 
> > as a configuration option? Other than "because we can" what is the actual 
> > end user value of that option?
> 
> Igor Poboiko wrote:
> AFAIK MacOS and Windows use vertical slider orientation, while 
> Gnome&Ubuntu use horizontal sliders. Some people may be used to one of the 
> variants and find another one inconvenient. So why not let them choose? There 
> is not that many options in that applet anyways.
> 
> Marco Martin wrote:
> i would prefer not having that as well, plasma appletswere designed to 
> make easy for the user to change a plasmoid with another if they don't like 
> it, rther than making the developer maintain many different code paths of 
> which some combination will always go untested...
> 
> one thing without a config dialog that may be tried is adjusting 
> horizontal or vertical how better suits the size of the config dialog at the 
> moment...
> 
> Sebastian Kügler wrote:
> Case in point: The use of QtHorizontal and QtVertical throughout the code 
> suggest to me that the horizontal case wasn't really tested in the submitted 
> version. Kinda supports Marco's fear of untested code pathes. ;-)
> 
> Diego Casella wrote:
> I've tried to keep compatibility with the "old" KMix interface, which 
> lets you choose whether you want horizontal or vertical sliders.
> 
> @Marco You are completely right, but we don't want to end with two 
> applets like "KMix with horizontal sliders" and "KMix with vertical sliders" 
> right? We should try to get a reliable procedure to retrieve the size of the 
> elements in the listview, which is the root of my issues with the applet 
> resize.
> 
> @Sebas Care to explain? Both the cases have been tested.
> 
> Sebastian Kügler wrote:
> sure, QtVertical and QtHorizontal do not exist, that's a syntax error. I 
> don't see how that could work, other than by complete accident.

Maybe hose enums were kept for backwards compatibilty, because they still do 
exists. Right here:
https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/entry/plasma/scriptengines/javascript/plasmoid/appletinterface.h#L156

Since my very first draft of the kmix applet is litteraly *years* old, even 
though I heavily refactored/modified/dropped the code, the QtVertical enums is 
something iI never checked if they were still valid or not, since they always 
worked fine :)


- Diego


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


On Aug. 24, 2013, 3:11 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 24, 2013, 3:11 p.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
>

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 22, 2013, 2:34 p.m., Sebastian Kügler wrote:
> > File Attachment: Menu Actions
> > <http://git.reviewboard.kde.org/r/112208/#fcomment75>
> >
> > Maybe we could align this in the same way as the batter applet does?

The menu comes from a right-click from within the widget -not the applet icon 
in the panel-, but i forgot to check the "include mouse pointer" option when I 
took that screenshot :)


> On Aug. 22, 2013, 2:34 p.m., Sebastian Kügler wrote:
> > File Attachment: Vertical Control
> > <http://git.reviewboard.kde.org/r/112208/#fcomment76>
> >
> > Clipping

This falls in the "known issues -> resizing" stuff: it is kinda hard to get the 
sizes right but the applet itself is resizeable so, until we get this right, 
the user can expand it as much as needed to fix it. That operation needs to be 
done only once because then plasma keeps track of it, so it would be a 
single-time hassle.. what do you think?


> On Aug. 22, 2013, 2:34 p.m., Sebastian Kügler wrote:
> > plasma/CMakeLists.txt, line 2
> > <http://git.reviewboard.kde.org/r/112208/diff/1/?file=183950#file183950line2>
> >
> > use the installPackage macro for this and the following line

First it needs to be exported, since it lives inside 
kde-workspace/plasma/CMakeLists.txt ;)


> On Aug. 22, 2013, 2:34 p.m., Sebastian Kügler wrote:
> > plasma/kmix-applet-qml/contents/ui/ButtonBar.qml, line 77
> > <http://git.reviewboard.kde.org/r/112208/diff/1/?file=183952#file183952line77>
> >
> > Bad naming, I got confused while reading this, as it reads like "run 
> > this program".
> > 
> > Maybe rename to something more descriptive?

It does run an external program indeed. Changed the name, I hope this one is 
more descriptive.


> On Aug. 22, 2013, 2:34 p.m., Sebastian Kügler wrote:
> > plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml, line 80
> > <http://git.reviewboard.kde.org/r/112208/diff/1/?file=183953#file183953line80>
> >
> > PlasmaCore.IconItem does this for you

Hmm are you sure? PlasmaCore.Svg is a non graphical item which is used to get 
svg elements and then to forward them to the applet popup icon and tooltip, 
while PlasmaCore.IconItem creates a graphical item, which is not needed here.


> On Aug. 22, 2013, 2:34 p.m., Sebastian Kügler wrote:
> > plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml, line 105
> > <http://git.reviewboard.kde.org/r/112208/diff/1/?file=183953#file183953line105>
> >
> > I wonder if this can't be done without the roundtrip, i.e. directly use 
> > the icon name?

Tooltips removed, anyway that code is used few lines below to set the popup 
applet icon and its tooltip.
Now the interesting part: I've managed to remove the temporary QIcon() creation 
when setting the popup icon tooltip data, but I couldn't do the same with the 
popup icon because otherwise the icon wont work ... Something broken in 
libplasma perhaps?


> On Aug. 22, 2013, 2:34 p.m., Sebastian Kügler wrote:
> > plasma/kmix-applet-qml/contents/ui/VerticalControl.qml, line 79
> > <http://git.reviewboard.kde.org/r/112208/diff/1/?file=183956#file183956line79>
> >
> > use PlasmaCore.IconItem

See the comment above.


- Diego


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


On Aug. 24, 2013, 3:11 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 24, 2013, 3:11 p.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been change

Re: Review Request 112208: KMix qml applet

[Diego Casella]

> On Aug. 22, 2013, 10:46 p.m., Aaron J. Seigo wrote:
> > File Attachment: Applet Config Options
> > <http://git.reviewboard.kde.org/r/112208/#fcomment77>
> >
> > Do we even really need horizontal/vertical orientation for the sliders 
> > as a configuration option? Other than "because we can" what is the actual 
> > end user value of that option?
> 
> Igor Poboiko wrote:
> AFAIK MacOS and Windows use vertical slider orientation, while 
> Gnome&Ubuntu use horizontal sliders. Some people may be used to one of the 
> variants and find another one inconvenient. So why not let them choose? There 
> is not that many options in that applet anyways.
> 
> Marco Martin wrote:
> i would prefer not having that as well, plasma appletswere designed to 
> make easy for the user to change a plasmoid with another if they don't like 
> it, rther than making the developer maintain many different code paths of 
> which some combination will always go untested...
> 
> one thing without a config dialog that may be tried is adjusting 
> horizontal or vertical how better suits the size of the config dialog at the 
> moment...
> 
> Sebastian Kügler wrote:
> Case in point: The use of QtHorizontal and QtVertical throughout the code 
> suggest to me that the horizontal case wasn't really tested in the submitted 
> version. Kinda supports Marco's fear of untested code pathes. ;-)

I've tried to keep compatibility with the "old" KMix interface, which lets you 
choose whether you want horizontal or vertical sliders.

@Marco You are completely right, but we don't want to end with two applets like 
"KMix with horizontal sliders" and "KMix with vertical sliders" right? We 
should try to get a reliable procedure to retrieve the size of the elements in 
the listview, which is the root of my issues with the applet resize.

@Sebas Care to explain? Both the cases have been tested.


- Diego


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


On Aug. 24, 2013, 3:11 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112208/
> ---
> 
> (Updated Aug. 24, 2013, 3:11 p.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
> Igor Poboiko.
> 
> 
> Description
> ---
> 
> KMix qml applet.
> As you can see from the screenshot, the applet is pretty much functional: you 
> can display all the controls available, change its orientation, and decide to 
> whether show all of them or just the Master Control, and refresh its status 
> when new controls are added/removed/updated (such as Amarok current playing 
> track). See screenshots below :)
> Differences from the old kmix tray:
> * no media player controls ( I never investigated how to get them, but 
> honestly opening the audio applet to change/skip/pause audio track makes 
> little sense to me ... if anyone wants this feature back, don't be shy and 
> step in);
> * the button used to select which Mixers are visible has been changed to open 
> Phonon kcm page: since visible mixers are already configurable from KMix app, 
> having a button to show KMix *and* a button to modify Mixers visibilty made 
> little sense here too, so I preferred to give more visibility to Phonon kcm;
> 
> Known issues:
> * there is still no way to get notified of mouse wheel events over the 
> popupIcon, so it is not possible to scroll over to increase/decrease the 
> master control volume;
> * no scroll events over the sliders too;
> * if you want to use the applet you most likely will disable KMix tray icon 
> but, if you do so, KMix will show its GUI at every login and you have to 
> close it manually. This requires KMix to be patched. Furthermore, if you 
> click "KMix Setup" button, KMix window will not restored anymore: this needs 
> to be pathed as well.
> * resize doesn't work properly.
> 
> 
> Diffs
> -
> 
>   plasma/kmix-applet-qml/contents/config/main.xml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/ButtonBar.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
> PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/MixersList.qml PRE-CREATION 
>   plasma/kmix-applet-qml/contents/ui/VerticalControl.qml

Re: Review Request 112208: KMix qml applet

[Diego Casella]

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

(Updated Aug. 24, 2013, 3:11 p.m.)


Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
Igor Poboiko.


Changes
---

sorry, forgot to add a screenshot for the updated version.


Description
---

KMix qml applet.
As you can see from the screenshot, the applet is pretty much functional: you 
can display all the controls available, change its orientation, and decide to 
whether show all of them or just the Master Control, and refresh its status 
when new controls are added/removed/updated (such as Amarok current playing 
track). See screenshots below :)
Differences from the old kmix tray:
* no media player controls ( I never investigated how to get them, but honestly 
opening the audio applet to change/skip/pause audio track makes little sense to 
me ... if anyone wants this feature back, don't be shy and step in);
* the button used to select which Mixers are visible has been changed to open 
Phonon kcm page: since visible mixers are already configurable from KMix app, 
having a button to show KMix *and* a button to modify Mixers visibilty made 
little sense here too, so I preferred to give more visibility to Phonon kcm;

Known issues:
* there is still no way to get notified of mouse wheel events over the 
popupIcon, so it is not possible to scroll over to increase/decrease the master 
control volume;
* no scroll events over the sliders too;
* if you want to use the applet you most likely will disable KMix tray icon 
but, if you do so, KMix will show its GUI at every login and you have to close 
it manually. This requires KMix to be patched. Furthermore, if you click "KMix 
Setup" button, KMix window will not restored anymore: this needs to be pathed 
as well.
* resize doesn't work properly.


Diffs
-

  plasma/kmix-applet-qml/contents/config/main.xml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/ButtonBar.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/MixersList.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/VerticalMixerListDelegate.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/config.ui PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/kmixapplet.qml PRE-CREATION 
  plasma/kmix-applet-qml/metadata.desktop PRE-CREATION 

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


Testing
---

Tested against master and works fine.


File Attachments (updated)


Default look
  http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
Menu Actions
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
Applet Config Options
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
Vertical Control
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png
ToolButton label and Config page after updates
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png


Thanks,

Diego Casella

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

Re: Review Request 112208: KMix qml applet

[Diego Casella]

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

(Updated Aug. 24, 2013, 3:07 p.m.)


Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
Igor Poboiko.


Changes
---

Update diff according to (almost all) the observations made so far.
Moved portions of code to be plasma-qml-style compliant :)


Description
---

KMix qml applet.
As you can see from the screenshot, the applet is pretty much functional: you 
can display all the controls available, change its orientation, and decide to 
whether show all of them or just the Master Control, and refresh its status 
when new controls are added/removed/updated (such as Amarok current playing 
track). See screenshots below :)
Differences from the old kmix tray:
* no media player controls ( I never investigated how to get them, but honestly 
opening the audio applet to change/skip/pause audio track makes little sense to 
me ... if anyone wants this feature back, don't be shy and step in);
* the button used to select which Mixers are visible has been changed to open 
Phonon kcm page: since visible mixers are already configurable from KMix app, 
having a button to show KMix *and* a button to modify Mixers visibilty made 
little sense here too, so I preferred to give more visibility to Phonon kcm;

Known issues:
* there is still no way to get notified of mouse wheel events over the 
popupIcon, so it is not possible to scroll over to increase/decrease the master 
control volume;
* no scroll events over the sliders too;
* if you want to use the applet you most likely will disable KMix tray icon 
but, if you do so, KMix will show its GUI at every login and you have to close 
it manually. This requires KMix to be patched. Furthermore, if you click "KMix 
Setup" button, KMix window will not restored anymore: this needs to be pathed 
as well.
* resize doesn't work properly.


Diffs (updated)
-

  plasma/kmix-applet-qml/contents/config/main.xml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/ButtonBar.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/MixersList.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/VerticalMixerListDelegate.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/config.ui PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/kmixapplet.qml PRE-CREATION 
  plasma/kmix-applet-qml/metadata.desktop PRE-CREATION 

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


Testing
---

Tested against master and works fine.


File Attachments


Default look
  http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
Menu Actions
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
Applet Config Options
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
Vertical Control
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png


Thanks,

Diego Casella

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

Review Request 112208: KMix qml applet

[Diego Casella]

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

Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and 
Igor Poboiko.


Description
---

KMix qml applet.
As you can see from the screenshot, the applet is pretty much functional: you 
can display all the controls available, change its orientation, and decide to 
whether show all of them or just the Master Control, and refresh its status 
when new controls are added/removed/updated (such as Amarok current playing 
track). See screenshots below :)
Differences from the old kmix tray:
* no media player controls ( I never investigated how to get them, but honestly 
opening the audio applet to change/skip/pause audio track makes little sense to 
me ... if anyone wants this feature back, don't be shy and step in);
* the button used to select which Mixers are visible has been changed to open 
Phonon kcm page: since visible mixers are already configurable from KMix app, 
having a button to show KMix *and* a button to modify Mixers visibilty made 
little sense here too, so I preferred to give more visibility to Phonon kcm;

Known issues:
* there is still no way to get notified of mouse wheel events over the 
popupIcon, so it is not possible to scroll over to increase/decrease the master 
control volume;
* no scroll events over the sliders too;
* if you want to use the applet you most likely will disable KMix tray icon 
but, if you do so, KMix will show its GUI at every login and you have to close 
it manually. This requires KMix to be patched. Furthermore, if you click "KMix 
Setup" button, KMix window will not restored anymore: this needs to be pathed 
as well.
* resize doesn't work properly.


Diffs
-

  plasma/CMakeLists.txt 5e1dc90 
  plasma/kmix-applet-qml/contents/config/main.xml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/ButtonBar.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 
PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/MixersList.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/VerticalControl.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/VerticalMixerListDelegate.qml PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/config.ui PRE-CREATION 
  plasma/kmix-applet-qml/contents/ui/kmixapplet.qml PRE-CREATION 
  plasma/kmix-applet-qml/metadata.desktop PRE-CREATION 

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


Testing
---

Tested against master and works fine.


File Attachments


Default look
  http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png
Menu Actions
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png
Applet Config Options
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png
Vertical Control
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png


Thanks,

Diego Casella

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

Re: Review Request 6928: KMix Declarative Applet - First attempt

[Diego Casella]

> On July 26, 2013, 10:30 p.m., Christian Esken wrote:
> > I have not followed this request, but it looks like I have not receieved 
> > any followups on my last comment. I would like to know what to do with this 
> > review request. Diego, Igor? Diego, are you still following up on this. 
> > Care to contact Igor?
> 
> Diego Casella wrote:
> Hi Christian, after hearing that someone else was working on it, I left 
> the development of that plasmoid; I didnt' want to step over Igor's work.
> Anyway, by looking at the current kmix status, it's still missing the 
> conversion to a full kded service: otherwise there will be two entries in the 
> tray: the "old" kmix, and its plasmoid counterpart. We also need to extend 
> its dbus interface and add a method to pop-up the full kmix gui: in that way, 
> the plasmoid can show the user interface, allowing the end-user to configure 
> kmix properly.
> As soon as those changes will be peformed (if you agree with it of 
> course, and if you want to implement the new kmix as a qml plasmoid), I'd be 
> happy to continue what I did so far :)
> 
> Christian Esken wrote:
> Commenting on:
>"if you want to implement the new kmix as a qml plasmoid"
> 
> Well, I have no knowledge in QML and no desire to learn it. If you still 
> want to do so - focussing on the tray popup/plasmoid - then it should be much 
> more functional than your prototype - especially: supporting multiple 
> controls, adding Media player control like in todays KMix.
> The KMix Mainwindow will surely always stay a normal application, 
> everything else is a complete new application.

> Commenting on:
>   "if you want to implement the new kmix as a qml plasmoid"
>
> Well, I have no knowledge in QML and no desire to learn it.

Sorry, I meant to say "if you want me to implement the new kmix as a qml 
plasmoid", I though I was sufficiently clear since then I continued with "I'd 
be happy to continue[..]" :)

About multiple controls and Media player controls I agree: they are rather easy 
to implement, so I'll go for it.

> The KMix Mainwindow will surely always stay a normal application, everything 
> else is a complete new application.

Okay, I guess then it will be modified to not show the tray icon by default - 
otherwise there will be its tray icon and the plasma applet, kinda confusing 
for the user -  right? There's this annoyance then: when KMix is set to not 
show the tray icon, at every login it will display its GUI. That should not 
happen, unless the user explicitly executes KMix or my applet calls it.
What do you think?

PS: since kmix moved to git and this review request is old, once we agreed on 
what should be done I'll start a brand new one and and link to this one as 
reference :)


- Diego


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


On March 28, 2012, 6:49 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6928/
> ---
> 
> (Updated March 28, 2012, 6:49 p.m.)
> 
> 
> Review request for Plasma, Aaron Seigo, Christian Esken, and Marco Martin.
> 
> 
> Description
> ---
> 
> First attempt of making a declarative kmix applet for plasma.
> What the apple does right now:
> * modifies the volume level and the mute/unmute status of the master channel;
> * reacts to changes of the volume level/status (i.e. made with multimedia 
> keys);
> * disables the slider if the channel gets muted, and enables it back as soon 
> as the channel gets unmuted;
> * collapses gracefully in a popup icon when placed inside the panel.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdemultimedia/kmix/plasma/CMakeLists.txt 1287513 
>   
> trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/VerticalControl.qml
>  PRE-CREATION 
>   
> trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/kmixapplet.qml 
> PRE-CREATION 
>   trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/metadata.desktop 
> PRE-CREATION 
> 
> Diff: http://svn.reviewboard.kde.org/r/6928/diff/
> 
> 
> Testing
> ---
> 
> Tested against r1287510. For basic audio management it works great imho.
> 
> However, there is a lot of room for improvements, but this is gonna need some 
> extra work outside the kmix applet scope:
> * first of all, the applet need kmix executable to run in orde

Re: Review Request 6928: KMix Declarative Applet - First attempt

[Diego Casella]

> On July 26, 2013, 10:30 p.m., Christian Esken wrote:
> > I have not followed this request, but it looks like I have not receieved 
> > any followups on my last comment. I would like to know what to do with this 
> > review request. Diego, Igor? Diego, are you still following up on this. 
> > Care to contact Igor?

Hi Christian, after hearing that someone else was working on it, I left the 
development of that plasmoid; I didnt' want to step over Igor's work.
Anyway, by looking at the current kmix status, it's still missing the 
conversion to a full kded service: otherwise there will be two entries in the 
tray: the "old" kmix, and its plasmoid counterpart. We also need to extend its 
dbus interface and add a method to pop-up the full kmix gui: in that way, the 
plasmoid can show the user interface, allowing the end-user to configure kmix 
properly.
As soon as those changes will be peformed (if you agree with it of course, and 
if you want to implement the new kmix as a qml plasmoid), I'd be happy to 
continue what I did so far :)


- Diego


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


On March 28, 2012, 6:49 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6928/
> ---
> 
> (Updated March 28, 2012, 6:49 p.m.)
> 
> 
> Review request for Plasma, Aaron Seigo, Christian Esken, and Marco Martin.
> 
> 
> Description
> ---
> 
> First attempt of making a declarative kmix applet for plasma.
> What the apple does right now:
> * modifies the volume level and the mute/unmute status of the master channel;
> * reacts to changes of the volume level/status (i.e. made with multimedia 
> keys);
> * disables the slider if the channel gets muted, and enables it back as soon 
> as the channel gets unmuted;
> * collapses gracefully in a popup icon when placed inside the panel.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdemultimedia/kmix/plasma/CMakeLists.txt 1287513 
>   
> trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/VerticalControl.qml
>  PRE-CREATION 
>   
> trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/kmixapplet.qml 
> PRE-CREATION 
>   trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/metadata.desktop 
> PRE-CREATION 
> 
> Diff: http://svn.reviewboard.kde.org/r/6928/diff/
> 
> 
> Testing
> ---
> 
> Tested against r1287510. For basic audio management it works great imho.
> 
> However, there is a lot of room for improvements, but this is gonna need some 
> extra work outside the kmix applet scope:
> * first of all, the applet need kmix executable to run in order to perform 
> the dbus calls. You can of course disable KMix tray icon feature but, at 
> every login, KMix mainwindow will be shown and the user must closeby hand. 
> This is a kind of ugly behavior that should be avoided;
> * it will be great to great to add an action to allow the user to select the 
> master channel (by reusing KMix "Select Master Channel" widget), but this 
> will require tweaking KMix dbus interface;
> * as you noticed in the screenshots, the applet in the panel and in the 
> desktop have different size even if it __is__ actually the same: something is 
> going wrong when plasma shows the PopupApplet. This behavior was even worse 
> when I started implementing a "flip" action to change the layout from 
> horizontal to vertical and vice-versa, and for this reason I gave up and 
> simply stick with the vertical layout.
> 
> Could this applet be shipped in the current status, or should we wait for all 
> the aforementioned improvements?
> Comments/ideas/suggestions?
> 
> Cheers :)
> 
> 
> Screenshots
> ---
> 
> Applet look in panel and desktop
>   http://svn.reviewboard.kde.org/r/6928/s/627/
> Applet look in panel and desktop - audio muted
>   http://svn.reviewboard.kde.org/r/6928/s/628/
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request: Plasmate: on SigningDialog::validateParams() replace QRegExp with KPIMUtils::isValidSimpleAddress

[Diego Casella]

> On Nov. 26, 2012, 1:43 p.m., Diego Casella wrote:
> > plasmate/CMakeLists.txt, line 102
> > <http://git.reviewboard.kde.org/r/107470/diff/1/?file=96184#file96184line102>
> >
> > I'm wondering if we really need to add a kdepimutils dependency for a 
> > simple email validation... Thoughts about that?
> > 
> > In any case, "kpimutils" must be discarded and substituted with the 
> > more portable ${KDEPIMLIBS_KPIMUTILS_LIBS} (more info inside 
> > FindKdepimLibs.cmake file).
> 
> Giorgos Tsiapaliokas wrote:
> >I'm wondering if we really need to add a kdepimutils dependency for a 
> simple email validation... Thoughts about that?
> Plasmate already depends on qgpgme++ library which is in kdepimlibs. 
> Kdepimutils are also part of the kdepimlibs.
> So we don't introduce a new depedency for a new repository.
> 
> Also we have been advised for this change from the kdereview.
> 
> Antonis Tsiapaliokas wrote:
> As regards your 2nd statement, KPIMUtils::isValidSimpleAddress doesn't 
> have a correct api, so that was the best thing that i found. But yes, that 
> could be changed.
> 
> Now as regards the depedency, i agree, that we don't really need that 
> library. But the people on kcd, said that we should replace it.
>

This is the right answer, sorry again for the noise.

>>I'm wondering if we really need to add a kdepimutils dependency for a simple 
>>email validation... Thoughts about that?
>Plasmate already depends on qgpgme++ library which is in kdepimlibs. 
>Kdepimutils are also part of the kdepimlibs.
Actually, I made Plasmate to depend on QGpgme _only_ (that is, libqgpgme.so), 
not to kdepimlibs/kpimutils, in order to avoid unnecessary library 
inclusion/linkage dependencies. In fact, it looks for package "QGpgme" using 
FindQGpgme.cmake and links against ${QGPGME_LIBRARIES}, instead of retrieving 
it through the more general FindKdepimLibs.cmake.
So, using the method in this patch will add a new library dependency to 
Plasmate (libkpimutils.so), that's it.
I still don't like the idea to increase the number of required libs because of 
one simple line of code; anyway, since we are in democracy, and kcd guys told 
you that it's fine for them to do that, I won't object anymore about that 
point. Feel free to commit, but remember to fix the cmake file first ;)


- Diego


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


On Nov. 26, 2012, 10:36 a.m., Antonis Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107470/
> ---
> 
> (Updated Nov. 26, 2012, 10:36 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> On this patch i am replace the QRegExp on SigningDialog::validateParams() 
> with KPIMUtils::isValidSimpleAddress
> 
> 
> Diffs
> -
> 
>   plasmate/CMakeLists.txt 111c402 
>   plasmate/publisher/signingdialog.cpp 395138d 
> 
> Diff: http://git.reviewboard.kde.org/r/107470/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

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

Re: Review Request: Plasmate: on SigningDialog::validateParams() replace QRegExp with KPIMUtils::isValidSimpleAddress

[Diego Casella]

> On Nov. 26, 2012, 8:53 p.m., Diego Casella wrote:
> > plasmate/CMakeLists.txt, line 102
> > <http://git.reviewboard.kde.org/r/107470/diff/1/?file=96184#file96184line102>
> >
> > >>I'm wondering if we really need to add a kdepimutils dependency for a 
> > simple email validation... Thoughts about that?
> > >Plasmate already depends on qgpgme++ library which is in kdepimlibs. 
> > Kdepimutils are also part of the kdepimlibs.
> > Actually, I made Plasmate to depend on QGpgme _only_ , not the entire 
> > kdepimlibs, in order to avoid unnecessary library inclusion/linkage 
> > dependencies. In fact, it looks for package "QGpgme" using FindQGpgme.cmake 
> > and links against ${QGPGME_LIBRARIES}, instead of using 
> > FindKdepimLibs.cmake.
> > 
> > Real case example: on my system (Kubuntu 12.10), the dependencies for 
> > installing libqgpgme1 are:
> > $polentino: sudo apt-cache depends libqgpgme1 
> > libqgpgme1
> >   Depends: libc6
> >   Depends: libgpgme++2
> >   Depends: libqtcore4
> >   Depends: libstdc++6
> >   Breaks: kdepimlibs5
> >   Replaces: kdepimlibs5
> > 
> > 
> > while, for libkpimutils4:
> > $polentino:  sudo apt-cache depends libkpimutils4 
> > libkpimutils4
> >   Depends: libc6
> >   Depends: libkdecore5
> >   Depends: libkdeui5
> >   Depends: libkemoticons4
> >   Depends: libkmime4
> >   Depends: libqtcore4
> >   Depends: libqtgui4
> >   Depends: libstdc++6
> >   Breaks: kdepimlibs5
> >   Replaces: kdepimlibs5
> > 
> > 
> >

heck, forget that reply. Made a mistake in the browser.


- Diego


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


On Nov. 26, 2012, 10:36 a.m., Antonis Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107470/
> ---
> 
> (Updated Nov. 26, 2012, 10:36 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> On this patch i am replace the QRegExp on SigningDialog::validateParams() 
> with KPIMUtils::isValidSimpleAddress
> 
> 
> Diffs
> -
> 
>   plasmate/CMakeLists.txt 111c402 
>   plasmate/publisher/signingdialog.cpp 395138d 
> 
> Diff: http://git.reviewboard.kde.org/r/107470/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

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

Re: Review Request: Plasmate: on SigningDialog::validateParams() replace QRegExp with KPIMUtils::isValidSimpleAddress

[Diego Casella]

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



plasmate/CMakeLists.txt
<http://git.reviewboard.kde.org/r/107470/#comment17252>

>>I'm wondering if we really need to add a kdepimutils dependency for a 
simple email validation... Thoughts about that?
>Plasmate already depends on qgpgme++ library which is in kdepimlibs. 
Kdepimutils are also part of the kdepimlibs.
Actually, I made Plasmate to depend on QGpgme _only_ , not the entire 
kdepimlibs, in order to avoid unnecessary library inclusion/linkage 
dependencies. In fact, it looks for package "QGpgme" using FindQGpgme.cmake and 
links against ${QGPGME_LIBRARIES}, instead of using FindKdepimLibs.cmake.

Real case example: on my system (Kubuntu 12.10), the dependencies for 
installing libqgpgme1 are:
$polentino: sudo apt-cache depends libqgpgme1 
libqgpgme1
  Depends: libc6
  Depends: libgpgme++2
  Depends: libqtcore4
  Depends: libstdc++6
  Breaks: kdepimlibs5
  Replaces: kdepimlibs5


while, for libkpimutils4:
$polentino:  sudo apt-cache depends libkpimutils4 
libkpimutils4
  Depends: libc6
  Depends: libkdecore5
  Depends: libkdeui5
  Depends: libkemoticons4
  Depends: libkmime4
  Depends: libqtcore4
  Depends: libqtgui4
  Depends: libstdc++6
  Breaks: kdepimlibs5
  Replaces: kdepimlibs5
    




- Diego Casella


On Nov. 26, 2012, 10:36 a.m., Antonis Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107470/
> ---
> 
> (Updated Nov. 26, 2012, 10:36 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> On this patch i am replace the QRegExp on SigningDialog::validateParams() 
> with KPIMUtils::isValidSimpleAddress
> 
> 
> Diffs
> -
> 
>   plasmate/CMakeLists.txt 111c402 
>   plasmate/publisher/signingdialog.cpp 395138d 
> 
> Diff: http://git.reviewboard.kde.org/r/107470/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

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

Re: Review Request: Plasmate: on SigningDialog::validateParams() replace QRegExp with KPIMUtils::isValidSimpleAddress

[Diego Casella]

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



plasmate/CMakeLists.txt
<http://git.reviewboard.kde.org/r/107470/#comment17247>

I'm wondering if we really need to add a kdepimutils dependency for a 
simple email validation... Thoughts about that?

In any case, "kpimutils" must be discarded and substituted with the more 
portable ${KDEPIMLIBS_KPIMUTILS_LIBS} (more info inside FindKdepimLibs.cmake 
file).


- Diego Casella


On Nov. 26, 2012, 10:36 a.m., Antonis Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107470/
> ---
> 
> (Updated Nov. 26, 2012, 10:36 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> On this patch i am replace the QRegExp on SigningDialog::validateParams() 
> with KPIMUtils::isValidSimpleAddress
> 
> 
> Diffs
> -
> 
>   plasmate/CMakeLists.txt 111c402 
>   plasmate/publisher/signingdialog.cpp 395138d 
> 
> Diff: http://git.reviewboard.kde.org/r/107470/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

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

Re: Review Request: Make the Activity Manager's iconButton inside the configuration component to layout correctly in an horizontal layout.

[Diego Casella]

> On Oct. 23, 2012, 7:01 a.m., Ivan Čukić wrote:
> > You didn't have to bother with screenshots, your word would be sufficient :)

No problem ;)
Btw, should I commit into master and 4.9, or just master?


- Diego


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


On Oct. 22, 2012, 11:01 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106999/
> ---
> 
> (Updated Oct. 22, 2012, 11:01 p.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> When you open the Activity Manager, and click the "Configure" button, the 
> stacked config page displays a misplaced iconButton (see figure on the left).
> That's because, in ActivityDelegate, the implicitHeight of the component is 
> forced to 20.
> Funny observation: this weird behavior shows up only when Activity Manager is 
> displayed horizontally ... Vertically, everything is just fine.
> Anyway the "patch" is just an one-liner so it should be OK, I suppose.
> The fixed component is shown in the screenshot on the right.
> 
> 
> Diffs
> -
> 
>   
> plasma/desktop/shell/activitymanager/package/contents/ui/ActivityDelegate.qml 
> 4af21e7 
> 
> Diff: http://git.reviewboard.kde.org/r/106999/diff/
> 
> 
> Testing
> ---
> 
> Works perfectly, both with horizontal and vertical placement (see shots 
> below).
> 
> 
> Screenshots
> ---
> 
> Activity Manager, before
>   http://git.reviewboard.kde.org/r/106999/s/790/
> Activity Manager, after
>   http://git.reviewboard.kde.org/r/106999/s/791/
> Activity Manager, Androbit theme
>   http://git.reviewboard.kde.org/r/106999/s/792/
> Activity Manager, Aya theme
>   http://git.reviewboard.kde.org/r/106999/s/793/
> Activity Manager, Produkt theme
>   http://git.reviewboard.kde.org/r/106999/s/794/
> Activity Manager, Slim Glow theme
>   http://git.reviewboard.kde.org/r/106999/s/795/
> Activity Manager, Tibanna theme
>   http://git.reviewboard.kde.org/r/106999/s/796/
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request: Make the Activity Manager's iconButton inside the configuration component to layout correctly in an horizontal layout.

[Diego Casella]

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

(Updated Oct. 22, 2012, 11:01 p.m.)


Review request for Plasma and Marco Martin.


Changes
---

Updated with screenshots about the other plasma themes from kdeartwork.


Description
---

When you open the Activity Manager, and click the "Configure" button, the 
stacked config page displays a misplaced iconButton (see figure on the left).
That's because, in ActivityDelegate, the implicitHeight of the component is 
forced to 20.
Funny observation: this weird behavior shows up only when Activity Manager is 
displayed horizontally ... Vertically, everything is just fine.
Anyway the "patch" is just an one-liner so it should be OK, I suppose.
The fixed component is shown in the screenshot on the right.


Diffs
-

  plasma/desktop/shell/activitymanager/package/contents/ui/ActivityDelegate.qml 
4af21e7 

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


Testing
---

Works perfectly, both with horizontal and vertical placement (see shots below).


Screenshots (updated)
---

Activity Manager, before
  http://git.reviewboard.kde.org/r/106999/s/790/
Activity Manager, after
  http://git.reviewboard.kde.org/r/106999/s/791/
Activity Manager, Androbit theme
  http://git.reviewboard.kde.org/r/106999/s/792/
Activity Manager, Aya theme
  http://git.reviewboard.kde.org/r/106999/s/793/
Activity Manager, Produkt theme
  http://git.reviewboard.kde.org/r/106999/s/794/
Activity Manager, Slim Glow theme
  http://git.reviewboard.kde.org/r/106999/s/795/
Activity Manager, Tibanna theme
  http://git.reviewboard.kde.org/r/106999/s/796/


Thanks,

Diego Casella

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

Review Request: Make the Activity Manager's iconButton inside the configuration component to layout correctly in an horizontal layout.

[Diego Casella]

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

Review request for Plasma and Marco Martin.


Description
---

When you open the Activity Manager, and click the "Configure" button, the 
stacked config page displays a misplaced iconButton (see figure on the left).
That's because, in ActivityDelegate, the implicitHeight of the component is 
forced to 20.
Funny observation: this weird behavior shows up only when Activity Manager is 
displayed horizontally ... Vertically, everything is just fine.
Anyway the "patch" is just an one-liner so it should be OK, I suppose.
The fixed component is shown in the screenshot on the right.


Diffs
-

  plasma/desktop/shell/activitymanager/package/contents/ui/ActivityDelegate.qml 
4af21e7 

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


Testing
---

Works perfectly, both with horizontal and vertical placement (see shots below).


Screenshots
---

Activity Manager, before
  http://git.reviewboard.kde.org/r/106999/s/790/
Activity Manager, after
  http://git.reviewboard.kde.org/r/106999/s/791/


Thanks,

Diego Casella

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

Re: Review Request: KMix Declarative Applet - First attempt

[Diego Casella]

> On March 28, 2012, 6:06 p.m., Marco Martin wrote:
> > to me the blocker is mostly having to have kmix running...
> > since actual kmix would be (sill ;) needed for the actual complete ui... 
> > what about this?
> > 
> > a modification in the systray applet, that queries sycoca for offers of 
> > plasmoids that can manage a determined statusnotifier item, so it would ask 
> > for something providing KMix (better if the ksni id is renamed in 
> > org.kde.kmix) then will be the systray itself that either instantiates the 
> > kmix applet, or just doesn't show the kmix icon if the applet was 
> > explicitly created by the user.
> > 
> > idea is still a bit nebulous, did i explain myself enough? ;)

>From a quick look of the code, there's the chance to build the daemon too.. If 
>so, there's no need to do all that work :)
About the need of the complete UI, we need it only for one purpose: select 
which channel will be the Master channel. I can't list all the available 
channels inside the standard config page (the one which appears when you click 
on the wrench icon in the applet handle), because of scripted plasmoid 
limitiations. But, thanks to the awesome progress made with plasmacomponents, I 
could use your fancy Dialog item to show all the channels available, and allow 
the user to choose which one will be the Master channel :)
In this way, we could drop the KMix windowed app, keep only the daemon, and 
talk to it with one (or more) kmix applet. What do you think? 


- Diego


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


On March 28, 2012, 6:49 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6928/
> ---
> 
> (Updated March 28, 2012, 6:49 p.m.)
> 
> 
> Review request for Plasma, Aaron Seigo, Marco Martin, and Christian Esken.
> 
> 
> Description
> ---
> 
> First attempt of making a declarative kmix applet for plasma.
> What the apple does right now:
> * modifies the volume level and the mute/unmute status of the master channel;
> * reacts to changes of the volume level/status (i.e. made with multimedia 
> keys);
> * disables the slider if the channel gets muted, and enables it back as soon 
> as the channel gets unmuted;
> * collapses gracefully in a popup icon when placed inside the panel.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdemultimedia/kmix/plasma/CMakeLists.txt 1287513 
>   
> trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/VerticalControl.qml
>  PRE-CREATION 
>   
> trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/kmixapplet.qml 
> PRE-CREATION 
>   trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/metadata.desktop 
> PRE-CREATION 
> 
> Diff: http://svn.reviewboard.kde.org/r/6928/diff/
> 
> 
> Testing
> ---
> 
> Tested against r1287510. For basic audio management it works great imho.
> 
> However, there is a lot of room for improvements, but this is gonna need some 
> extra work outside the kmix applet scope:
> * first of all, the applet need kmix executable to run in order to perform 
> the dbus calls. You can of course disable KMix tray icon feature but, at 
> every login, KMix mainwindow will be shown and the user must closeby hand. 
> This is a kind of ugly behavior that should be avoided;
> * it will be great to great to add an action to allow the user to select the 
> master channel (by reusing KMix "Select Master Channel" widget), but this 
> will require tweaking KMix dbus interface;
> * as you noticed in the screenshots, the applet in the panel and in the 
> desktop have different size even if it __is__ actually the same: something is 
> going wrong when plasma shows the PopupApplet. This behavior was even worse 
> when I started implementing a "flip" action to change the layout from 
> horizontal to vertical and vice-versa, and for this reason I gave up and 
> simply stick with the vertical layout.
> 
> Could this applet be shipped in the current status, or should we wait for all 
> the aforementioned improvements?
> Comments/ideas/suggestions?
> 
> Cheers :)
> 
> 
> Screenshots
> ---
> 
> Applet look in panel and desktop
>   http://svn.reviewboard.kde.org/r/6928/s/627/
> Applet look in panel and desktop - audio muted
>   http://svn.reviewboard.kde.org/r/6928/s/628/
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request: KMix Declarative Applet - First attempt

[Diego Casella]

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

(Updated March 28, 2012, 6:49 p.m.)


Review request for Plasma, Aaron Seigo, Marco Martin, and Christian Esken.


Changes
---

whoops forgot to add Christian


Description
---

First attempt of making a declarative kmix applet for plasma.
What the apple does right now:
* modifies the volume level and the mute/unmute status of the master channel;
* reacts to changes of the volume level/status (i.e. made with multimedia keys);
* disables the slider if the channel gets muted, and enables it back as soon as 
the channel gets unmuted;
* collapses gracefully in a popup icon when placed inside the panel.


Diffs
-

  trunk/KDE/kdemultimedia/kmix/plasma/CMakeLists.txt 1287513 
  
trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/VerticalControl.qml
 PRE-CREATION 
  trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/kmixapplet.qml 
PRE-CREATION 
  trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/metadata.desktop PRE-CREATION 

Diff: http://svn.reviewboard.kde.org/r/6928/diff/


Testing
---

Tested against r1287510. For basic audio management it works great imho.

However, there is a lot of room for improvements, but this is gonna need some 
extra work outside the kmix applet scope:
* first of all, the applet need kmix executable to run in order to perform the 
dbus calls. You can of course disable KMix tray icon feature but, at every 
login, KMix mainwindow will be shown and the user must closeby hand. This is a 
kind of ugly behavior that should be avoided;
* it will be great to great to add an action to allow the user to select the 
master channel (by reusing KMix "Select Master Channel" widget), but this will 
require tweaking KMix dbus interface;
* as you noticed in the screenshots, the applet in the panel and in the desktop 
have different size even if it __is__ actually the same: something is going 
wrong when plasma shows the PopupApplet. This behavior was even worse when I 
started implementing a "flip" action to change the layout from horizontal to 
vertical and vice-versa, and for this reason I gave up and simply stick with 
the vertical layout.

Could this applet be shipped in the current status, or should we wait for all 
the aforementioned improvements?
Comments/ideas/suggestions?

Cheers :)


Screenshots
---

Applet look in panel and desktop
  http://svn.reviewboard.kde.org/r/6928/s/627/
Applet look in panel and desktop - audio muted
  http://svn.reviewboard.kde.org/r/6928/s/628/


Thanks,

Diego Casella

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

Review Request: KMix Declarative Applet - First attempt

[Diego Casella]

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

Review request for Plasma, Aaron Seigo and Marco Martin.


Description
---

First attempt of making a declarative kmix applet for plasma.
What the apple does right now:
* modifies the volume level and the mute/unmute status of the master channel;
* reacts to changes of the volume level/status (i.e. made with multimedia keys);
* disables the slider if the channel gets muted, and enables it back as soon as 
the channel gets unmuted;
* collapses gracefully in a popup icon when placed inside the panel.


Diffs
-

  trunk/KDE/kdemultimedia/kmix/plasma/CMakeLists.txt 1287513 
  
trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/VerticalControl.qml
 PRE-CREATION 
  trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/contents/code/kmixapplet.qml 
PRE-CREATION 
  trunk/KDE/kdemultimedia/kmix/plasma/kmix-applet/metadata.desktop PRE-CREATION 

Diff: http://svn.reviewboard.kde.org/r/6928/diff/


Testing
---

Tested against r1287510. For basic audio management it works great imho.

However, there is a lot of room for improvements, but this is gonna need some 
extra work outside the kmix applet scope:
* first of all, the applet need kmix executable to run in order to perform the 
dbus calls. You can of course disable KMix tray icon feature but, at every 
login, KMix mainwindow will be shown and the user must closeby hand. This is a 
kind of ugly behavior that should be avoided;
* it will be great to great to add an action to allow the user to select the 
master channel (by reusing KMix "Select Master Channel" widget), but this will 
require tweaking KMix dbus interface;
* as you noticed in the screenshots, the applet in the panel and in the desktop 
have different size even if it __is__ actually the same: something is going 
wrong when plasma shows the PopupApplet. This behavior was even worse when I 
started implementing a "flip" action to change the layout from horizontal to 
vertical and vice-versa, and for this reason I gave up and simply stick with 
the vertical layout.

Could this applet be shipped in the current status, or should we wait for all 
the aforementioned improvements?
Comments/ideas/suggestions?

Cheers :)


Screenshots
---

Applet look in panel and desktop
  http://svn.reviewboard.kde.org/r/6928/s/627/
Applet look in panel and desktop - audio muted
  http://svn.reviewboard.kde.org/r/6928/s/628/


Thanks,

Diego Casella

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

Re: Re: Re: refreshing the system tray icons

[Diego Casella ([Po]lentino)]

>
>
> -- Messaggio inoltrato --
> From: Martin Gräßlin 
> To: plasma-devel@kde.org
> Date: Thu, 01 Dec 2011 21:29:12 +0100
> Subject: Re: Re: refreshing the system tray icons
> On Thursday 01 December 2011 21:11:30 Marco Martin wrote:
> > (even tough i'm still not sure if is a good idea to give icon for the
> > applications like say, amarok)
> no it's not, but reality is that it looks very inconsistant and it does not
> look like we would get the applications out of the systray in 4.8.
>
> So from me +1 to monochrome
>
+1 for me too.
The point is we should make the tray more consistent and less cluttered
ihmo, esp. because it kinda disorient "regular users" about the "things"
the tray stores. Be them plasmoids, application's tray icons, or daemons
reminder, the user doesn't care about how they are implemented, but which
actions they provide. S yep, having all monochrome icons is a great
improvement about consistency :)

An other thing that will improve _a lot_ consistency (thus, the user
experience) is to have a default "look" when the tray icon are clicked:
just think about what you see when you click on the battery or device
notifier icons, versus the klipper or kmix ones. (by the way, please
forgive me for not having finished the kmix qml port yet; hopefully this
month i'll be less busy :)
Cheers,
Diego


> Cheers
> Martin
> >
> > --
> > Marco Martin
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Make IconTask use Plasma::Theme'd "close" button

[Diego Casella]

> On Nov. 9, 2011, 4:25 p.m., Aaron J. Seigo wrote:
> > other than the small issue with QDir, it looks good to me ... it's Craig's 
> > widget though so he has to have the last say to ship it or not.

Thank you a lot :)
I'll wait for Craig's approval, if he agrees with the changes :)


- Diego


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


On Nov. 9, 2011, 4:33 p.m., Diego Casella wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103092/
> ---
> 
> (Updated Nov. 9, 2011, 4:33 p.m.)
> 
> 
> Review request for Plasma and Craig Drummond.
> 
> 
> Description
> ---
> 
> Simple patch which makes IconTask look more consistent with Plasma Theme.
> It renders the "close" button using Plasma::Theme, and fallback to the 
> standard window-close icon if nothing better is available :)
> 
> 
> Diffs
> -
> 
>   applets/icontasks/tooltips/windowpreview.cpp 3e0c865 
> 
> Diff: http://git.reviewboard.kde.org/r/103092/diff/diff
> 
> 
> Testing
> ---
> 
> Compiles and works as expected (see pictures below).
> 
> 
> Screenshots
> ---
> 
> ToolTip with themed "close" button
>   http://git.reviewboard.kde.org/r/103092/s/329/
> ToolTip with default "close" icon
>   http://git.reviewboard.kde.org/r/103092/s/330/
> ToolTip with themed "closed" button, resized
>   http://git.reviewboard.kde.org/r/103092/s/331/
> 
> 
> Thanks,
> 
> Diego Casella
> 
>

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

Re: Review Request: Make IconTask use Plasma::Theme'd "close" button

[Diego Casella]

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

(Updated Nov. 9, 2011, 4:33 p.m.)


Review request for Plasma and Craig Drummond.


Changes
---

removed QDir::separator()


Description
---

Simple patch which makes IconTask look more consistent with Plasma Theme.
It renders the "close" button using Plasma::Theme, and fallback to the standard 
window-close icon if nothing better is available :)


Diffs (updated)
-

  applets/icontasks/tooltips/windowpreview.cpp 3e0c865 

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


Testing
---

Compiles and works as expected (see pictures below).


Screenshots
---

ToolTip with themed "close" button
  http://git.reviewboard.kde.org/r/103092/s/329/
ToolTip with default "close" icon
  http://git.reviewboard.kde.org/r/103092/s/330/
ToolTip with themed "closed" button, resized
  http://git.reviewboard.kde.org/r/103092/s/331/


Thanks,

Diego Casella

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

Re: Review Request: Make IconTask use Plasma::Theme'd "close" button

[Diego Casella]

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

(Updated Nov. 9, 2011, 3:59 p.m.)


Review request for Plasma and Craig Drummond.


Changes
---

Added a screenshot of the second version of the patch.


Description
---

Simple patch which makes IconTask look more consistent with Plasma Theme.
It renders the "close" button using Plasma::Theme, and fallback to the standard 
window-close icon if nothing better is available :)


Diffs
-

  applets/icontasks/tooltips/windowpreview.cpp 3e0c865 

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


Testing
---

Compiles and works as expected (see pictures below).


Screenshots (updated)
---

ToolTip with themed "close" button
  http://git.reviewboard.kde.org/r/103092/s/329/
ToolTip with default "close" icon
  http://git.reviewboard.kde.org/r/103092/s/330/
ToolTip with themed "closed" button, resized
  http://git.reviewboard.kde.org/r/103092/s/331/


Thanks,

Diego Casella

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

Re: Review Request: Make IconTask use Plasma::Theme'd "close" button

[Diego Casella]

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

(Updated Nov. 9, 2011, 3:56 p.m.)


Review request for Plasma and Craig Drummond.


Changes
---

According to Aaron's suggestions:
* made svgPath const;
* if() else () reordering;
* Plasma::Svg created in the stack instead of the heap;
* resized the close button.


Description
---

Simple patch which makes IconTask look more consistent with Plasma Theme.
It renders the "close" button using Plasma::Theme, and fallback to the standard 
window-close icon if nothing better is available :)


Diffs (updated)
-

  applets/icontasks/tooltips/windowpreview.cpp 3e0c865 

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


Testing
---

Compiles and works as expected (see pictures below).


Screenshots
---

ToolTip with themed "close" button
  http://git.reviewboard.kde.org/r/103092/s/329/
ToolTip with default "close" icon
  http://git.reviewboard.kde.org/r/103092/s/330/


Thanks,

Diego Casella

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

Re: Review Request: Make IconTask use Plasma::Theme'd "close" button

[Diego Casella]

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

(Updated Nov. 9, 2011, 10:22 a.m.)


Review request for Plasma, Aaron J. Seigo and Craig Drummond.


Description
---

Simple patch which makes IconTask look more consistent with Plasma Theme.
It renders the "close" button using Plasma::Theme, and fallback to the standard 
window-close icon if nothing better is available :)


Diffs
-

  applets/icontasks/tooltips/windowpreview.cpp 3e0c865 

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


Testing
---

Compiles and works as expected (see pictures below).


Screenshots (updated)
---

ToolTip with themed "close" button
  http://git.reviewboard.kde.org/r/103092/s/329/
ToolTip with default "close" icon
  http://git.reviewboard.kde.org/r/103092/s/330/


Thanks,

Diego Casella

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

Re: Review Request: Make IconTask use Plasma::Theme'd "close" button

[Diego Casella]

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

(Updated Nov. 9, 2011, 10:22 a.m.)


Review request for Plasma, Aaron J. Seigo and Craig Drummond.


Description
---

Simple patch which makes IconTask look more consistent with Plasma Theme.
It renders the "close" button using Plasma::Theme, and fallback to the standard 
window-close icon if nothing better is available :)


Diffs
-

  applets/icontasks/tooltips/windowpreview.cpp 3e0c865 

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


Testing (updated)
---

Compiles and works as expected (see pictures below).


Screenshots
---


  http://git.reviewboard.kde.org/r/103092/s/328/
ToolTip with themed "close" button
  http://git.reviewboard.kde.org/r/103092/s/329/
ToolTip with default "close" icon
  http://git.reviewboard.kde.org/r/103092/s/330/


Thanks,

Diego Casella

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

Review Request: Make IconTask use Plasma::Theme'd "close" button

[Diego Casella]

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

Review request for Plasma, Aaron J. Seigo and Craig Drummond.


Description
---

Simple patch which makes IconTask look more consistent with Plasma Theme.
It renders the "close" button using Plasma::Theme, and fallback to the standard 
window-close icon if nothing better is available :)


Diffs
-

  applets/icontasks/tooltips/windowpreview.cpp 3e0c865 

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


Testing
---

Compiles and works as expected (see picture below).


Screenshots
---


  http://git.reviewboard.kde.org/r/103092/s/328/
ToolTip with themed "close" button
  http://git.reviewboard.kde.org/r/103092/s/329/
ToolTip with default "close" icon
  http://git.reviewboard.kde.org/r/103092/s/330/


Thanks,

Diego Casella

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

Re: Re: PopupApplet with Qml/JS broken?

[Diego Casella ([Po]lentino)]

Quoting Marco Martin  So,
> It's probably indeed broken in the js bindings (I think it's different
> from the problem in QML tough)
> I hope to have half a second tomorrow to debug the bindings to see
> what's going on (again, i need a clone :p)
> are you on irc tomorrow?

yep, I'll be online from 3:00 pm until midnight :)
Thanks for your help, see you tomorrow !

> Cheers,
> Marco Martin

Cheers,
Diego

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Subject: Re: Can't collapse QML plasmoid to icon

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Thu, 14 Apr 2011 18:47:41 +0200
> Subject: Re: Can't collapse QML plasmoid to icon
> On Thursday, April 14, 2011 18:30:36 Diego Casella wrote:
> > [I didn't received any response yet, so I'm posting again since on April
> 28
> > there is the soft freeze fo 4.7, and I'd like to fill the KMix plasmoid
> > review request as soon as I can :)]
> >
> > Hello guys,
> > I'm facing an other problem during the development of the KMix plasmoid
> > replacement. As I wrote on the subject of this email, I can't set a
> > popupIcon for that plasmoid. I've modified the "Service Types" in
> > metadata.desktop to "Plasma/Applet,Plasma/PopupApplet" (I even tried just
> > "Plasma/PopupApplet") and then, inside the main Component.onCompleted
> > function:
> >
> > plasmoid.setMinimumSize(80, 150)
> > plasmoid.popupIcon("audio-volume-high")
>
> perhaps:
>
> plasmoid.popupIcon = "audio-volume-high"
>
> it's a property, not a function :)
>

Oh my bad, I was still thinking of it as its c++ setPopupIcon() equivalent
>.<
However, now now I've noticed an other weird issue: if I declare the applet
as "Plasma/PopupApplet", install the applet, and run kbuildsycoca4, the
widgetexplorer doesn't show the applet at all.
If I declare the plasmoid as "Plasma/Applet,Plasma/PopupApplet", plasmapkg
(and also plasmate) refuses to install it. If I copy it with "cp -r", the
widgets explorer now displays the new plasmoid but, still, it is not
collapsed into an icon when placed in the panel (popupIcon is a QIcon
property btw :).
Pretty weird, isn't it?

>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> --
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Can't collapse QML plasmoid to icon

[Diego Casella ([Po]lentino)]

[I didn't received any response yet, so I'm posting again since on April 28
there is the soft freeze fo 4.7, and I'd like to fill the KMix plasmoid
review request as soon as I can :)]

Hello guys,
I'm facing an other problem during the development of the KMix plasmoid
replacement. As I wrote on the subject of this email, I can't set a
popupIcon for that plasmoid. I've modified the "Service Types" in
metadata.desktop to "Plasma/Applet,Plasma/PopupApplet" (I even tried just
"Plasma/PopupApplet") and then, inside the main Component.onCompleted
function:

plasmoid.setMinimumSize(80, 150)
plasmoid.popupIcon("audio-volume-high")

but it's not working at all :(
Anyone can tell me where I'm wrong?
Furthermore (but this is not essential for my plasmoid), seems like I can't
set a custom actions too, just to let you know :)
Cheers,

Diego


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/




-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Can't collapse QML plasmoid to icon

[Diego Casella ([Po]lentino)]

Hello guys,
I'm facing an other problem during the development of the KMix plasmoid
replacement. As I wrote on the subject of this email, I can't set a
popupIcon for that plasmoid. I've modified the "Service Types" in
metadata.desktop to "Plasma/Applet,Plasma/PopupApplet" (I even tried just
"Plasma/PopupApplet") and then, inside the main Component.onCompleted
function:

plasmoid.setMinimumSize(80, 150)
plasmoid.popupIcon("audio-volume-high")

but it's not working at all :(
Anyone can tell me where I'm wrong?
Furthermore (but this is not essential for my plasmoid), seems like I can't
set a custom actions too, just to let you know :)
Cheers,

Diego


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [GSoC] PlasMate: first release proposal

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Sebastian Kügler 
> To: plasma-devel@kde.org
> Date: Sun, 03 Apr 2011 23:01:49 +0200
> Subject: Re: [GSoC] PlasMate: first release proposal
> Hey Diego,
>
> On Thursday, March 31, 2011 20:03:31 Diego Casella wrote:
> > after hearing sebas' interest about GSoC project aimed to release a
> stable
> > version of PlasMate, I've collected some ideas and wrote this very first
> > draft of the proposal [0] :)
> > As always, comments are highly appreciated!
>
> > @sebas: as you suggested, I didn't included the "code refactoring" thing,
> > but I think a little bit of modularization wouldn't hurt; what do you
> think?
>
> It depends, I'm not really against refactoring parts of the code where, the
> goal however needs to be to get a first working version. You've mentioned
> that
> in your proposel already, but I think the focus should shift slightly.


With "polish the code" I meant fix memleaks, remove i18n puzzles and so on;
now I've explained it better, btw :)


> Some hints that would make it more interesting:
>
> - State the goal more clearly, for example in terms of what will be working
> and tested by the end of your GSoC project. I'd personally like to see the
> following:
>
> * working and intuitive complete workflow for creating Plasma "apps"
>  (creating, editing, previewer and publishing)
> * basic debugging facilities for QML Plasmoids (for example a scripting
>  console where your print() output ends up, an object inspector)
>
+1. A scripting console is a great idea, added to the list.
Plus, I've extended that concept for every Plasmoid type, since it is really
useful. It will also partially address the plasmoid sizing issue you
mentioned above ;)


> * Fixing most important problems: plasmoid sizing in the previewer
> (especially
>  when the Plasmoid fails to load, the display explodes and one can't read
> the
>  error messages)
> * The publisher needs a way to export the Plasmoid to a remote device (for
>  example a "publish to device buttons", which makes testing the widget on a
>  target device way easier (can be done using Plasmoid sharing)
> * Improve documentation for writing Plasmoids, covering basic Plasma
> Widgets,
>  UI guidelines, etc.
> * Working workflow for dataengine development
>
> - I'm not entirely sure in how far runnners are really important at this
> point, and how much work is needed for that. It's probably one of the
> features
> that can go onto the afterburner, if it benefits the above goals.
>
> - If you have plans to further maintain and develop Plasmate (which I guess
> is
> your intention anyway, given your track record so far), it would be good to
> note that in your proposal since it makes it more interesting for people.
> The
> purpose of GSoC is to get people involved after GSoC.
>
Oh I thought this was implicit.
Added this too ;)

>
> - The proposal should also have more detailed milestones, I'd propose bi-
> weekly milestones, which take one or more (or one split up ;)) of the above
> points, and specify those in terms of accountable items. This eases also
> the
> mid- and end-term evaluations.
>
I suck with milestones, so please have a look and tell me what do you
think/if something is missing :)


>
> - You haven't mentioned communication in your proposal, additional to the
> usual suspects, status reports would be very much appreciatd. You can tie
> those to the above milestones,
>
> > :)
> >
> > [0]:
> >
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/diego_casella/1
>
> Thanks for the proposal :)
>
You're welcome, Cheers!

Diego


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


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[GSoC] PlasMate: first release proposal

[Diego Casella ([Po]lentino)]

Hey guys,
after hearing sebas' interest about GSoC project aimed to release a stable
version of PlasMate, I've collected some ideas and wrote this very first
draft of the proposal [0] :)
As always, comments are highly appreciated!
Cheers,
Diego

@sebas: as you suggested, I didn't included the "code refactoring" thing,
but I think a little bit of modularization wouldn't hurt; what do you think?
:)

[0]:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/diego_casella/1

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: Subject: Re: Subject: Plasmate status

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Sebastian Kügler 
> To: plasma-devel@kde.org
> Date: Fri, 18 Mar 2011 10:31:07 +0100
> Subject: Re: Subject: Re: Subject: Plasmate status
> On Thursday, March 17, 2011 22:52:42 Diego Casella ([Po]lentino) wrote:
> > The editor part, which is the most interesting probably, is already
> plugin-
> >  based (it picks the editor used based on the mimetype).
> >  Crashing the previewer should not be possible anyway, and if it is, it
> > needs fixing in libplasma. In general, scripted plasmoids (which plasmate
> > is all about) cannot crash plasma (or in that case the previewer).
> >
> >  I might be missing something here, in that case, please enlighten me. :)
> >
> > I'll try to pinpoint the problem; these days I was developing a qml
> > plasmoid, and plasmate was pretty crashy :(
>
> Can you send me backtraces of that? I can't see a single crash here, so
> can't
> really do anything about it without bt.
>

hmm ok, seems like the crash comes from the KMix  engine I've been playing
with lately.
If you want, here it is the bt: http://paste.kde.org/7808/
(I'll try to get a more detailed one btw :)
Cheers,

Diego

>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
>


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

A couple of questions about QML Plasma bindings

[Diego Casella ([Po]lentino)]

Hello guys,
as you should've seen in my latest posts in planetkde, I'm working on a
plasmoid version of the standard KMix applet.
I coded it in QML and of course I've taken advantage of the Plasma QML
bindings (they _really_ rocks!!), and now I've got some questions for you:

* I want to give a more elegant and pleasant look to KMix applet, and I need
to access the monochrome svg audio-* icons, but I have no idea about how to
do it.
  In C++ this is vry easy: a simple call
to Plasma::Theme::defaultTheme()->imagePath(svg) and, if the returned path
is not empty I can use it, otherwise I will fallback to
  the standard icon. So, is it possible to expose something similar to the
existing QML Theme component?

* I'd like to show a tooltip when the applet is collapsed into an icon in
the panel but, still, there are no QML bindings to Plasma::ToolTipContent
and ToolTipManager classes.
  Is there any chances to get it exposed to QML?

Anyways, awesome job with the QML/Plasma integration, it's impressive!
Cheers,
Diego

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Subject: Re: Subject: Plasmate status

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Sebastian Kügler 
> To: plasma-devel@kde.org
> Date: Thu, 17 Mar 2011 15:11:24 +0100
> Subject: Re: Subject: Plasmate status
> Hey,
>
> On Thursday, March 17, 2011 10:45:37 Diego Casella ([Po]lentino) wrote:
> > > The timeline feature doesn't work for me. Adding a save point doesn't
> > > seem to
> > > do anything, the timeline stays empty. I've not debugged that yet, so
> it
> > > might
> > > be an easy fix. (Not sure though in how far that part is supposed to
> work
> > > in
> > > general.)
> >
> > Probably the guy (don't rememer his nick) that ported the old Workflow
> dock
> > to the standar menu forgot to connect
> > the clicked signal of the "new savepoint" menuitem with the
> > "newSavePoint()" slot :)
>
> I'll have a look at that.
>
> > I was also thinking to write a GSoC proposal about a deep refactoring of
> > PlasMate codebase (plugin-based), since it's not easy to mantain in its
> > current state, make it not crashing if the previewer crashes, add the
> theme
> > creation support, maybe try adding Qt QML editor into plasmate, and make
> it
> > ready for its first release.
>
> I strongly disagree with a "deep refactoring" of the code. It's fairly
> small,
> and I didn't run across any structural problem. In fact, it's very easy to
> get
> hacking on it, and the code bears little to no surprises.
>

Ok, however more modularization wouldn't hurt :)


> The editor part, which is the most interesting probably, is already plugin-
> based (it picks the editor used based on the mimetype).
> Crashing the previewer should not be possible anyway, and if it is, it
> needs
> fixing in libplasma. In general, scripted plasmoids (which plasmate is all
> about) cannot crash plasma (or in that case the previewer).
>
> I might be missing something here, in that case, please enlighten me. :)
>

I'll try to pinpoint the problem; these days I was developing a qml
plasmoid, and plasmate was pretty crashy :(

>
> That said, I'd be willing to mentor a GSoC project with the goal to release
> a
> stable and complete version at the end of it. That excludes anything which
> brings Plasmate further away from a release, though. Plasmate has been
> lingering for too long, we should bring it to a release instead of
> tinkering
> on the codebase.
>
> Oh great :)
If you think it's feasible, I will put my ideas together and fill a
proposal.


> The editor part is interesting, we can go two ways here: Work with Qt
> Creators
> QML editor, or move towards kdevelop and make sure kdevelop understands it
> and
> can auto-propose object properties and their syntax. Neither of those is
> necessary for a 1.0, imo. They're certainly desirable, though.


Agreed.


> > Ok, now back to KMix QML applet =)
>
> Have fun, and thanks for the comments :)
>

You're welcome, cheers!
Diego


> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
> --
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Rework KMix DBus API and add KMix plasma dataengine

[Diego Casella]

> On March 14, 2011, 7:06 p.m., Diego Casella wrote:
> > Ok, sorry again for my late reply :(
> > Services are working great, however, I think you should refactor the way 
> > the 'mixer' DataEngine works, because it doesn't completely performs what 
> > it is supposed to.
> > Let me explain better: when you invoke the "mixer" DataEngine, you get only 
> > the audio cards names, and nothing more. You have to query() the 
> > DataEngine, passing one of those names, to receive further infos about the 
> > specific control of that audio card (this is what I, and I think other 
> > people does, expect when using this DataEngine).
> > And this is kinda bad because, since the DataEngine doesn't automatically 
> > updates when the volume changes level/state (see my previous comment), I 
> > have to call a query() every N milliseconds and then, for each control, 
> > check is something has changed and do a manual update of the plasmoid if 
> > needed.
> > Long story short: instead of returning a "Mixers" datasource, with key set 
> > to "Mixers" again, you should return a datasource with all the MIXER_ID's 
> > and, for each of them, all their detailed infos (volume and mute state 
> > included), so we can get all we need in one shot :)
> > (You could run "plasmaengineexplorer" and watch a couple of engines, such 
> > as 'org.kde.activities', 'hotplug' or 'tasks' to see what I mean)
> > 
> > Note that this will fix also the update() issue because, with the current 
> > implementation, the plasmoid won't update unless the value of one of the 
> > "Mixers" keys changes (since it contains only the audio card names, it 
> > means we will be notified of changes only if an audio card has been 
> > plugged/removed).
> > 
> > Anyways, these are my two cent: Aaron, what do you think about it?
> 
> Igor Poboiko wrote:
> I thought that the 'dataUpdated' signal is emitted every time data 
> changes (even from inside the dataengine - in our case, I update the 
> mute/volume by DBus signals from inside the dataengine, and it updates 
> automatically in plasmaengineexplorer), and there is no need to poll the 
> dataengine.
> The other problem is that actually the plasmoid needs information only 
> about few controls (one or a bit more sliders in plasmoid). So is there a 
> need to set ALL the controls (by default)?
> And again, what is the difference between adding these sources by default 
> and querying it, for example, on plasmoid start? I guess I misunderstood 
> something, but don't you anyway need to poll these sources to get all 
> changing data?
> And one more issue - there are three types of datasources: one basic 
> (called "Mixers", provides info about available Mixers/soundcards), some for 
> mixers/soundcards (which provides information about its controls) and some 
> for controls (which provides information about all its state - volume level, 
> mute, etc). Should I add all these sources? And should I add it automatically 
> add all sources for plugged devices-sources?
> 
> Huh, I asked so many questions.. The things you are talking about are 
> easy-to-fix, I maybe just don't understand correctly what you need :)
> 
> Diego Casella wrote:
> Err, I was referencing the controls with the same index of the audio card 
> ( i.e. 'ALSA::HDA_Intel:1' and thus 'Master:1', instead of 'Master:0'), my 
> bad :(
> So, forget what I said :)
> Anyways, one more observation: if we want to provide a complete 
> replacement of the old KMix applet, the plasmoid should be able to provide a 
> 'widget' to select/change which channel we are currently operating with 
> (master, pcm, speakers ..). In other words, we need a Plasma Service to 
> change the current master channel, and one more entry in the dataengine to 
> identify which channel is currently being controlled.
> 
> Igor Poboiko wrote:
> Yep, I thought about it. My idea was that the control shown in plasmoid 
> should be independent from master mixer in KMix. I mean, we just show one (or 
> more) control(s) and we don't care about KMix's master control (we have own 
> settings about visible controls, etc).
> But now I'm not sure it is good idea (since, for example, shortcuts are 
> assigned to master control) But anyway - KMix is running during the all 
> session, so I can provide information about master mixer/control in 
> dataengine and if user want to change it we can just call KMix to show its 
> window and show its settings

Re: Subject: Plasmate status

[Diego Casella ([Po]lentino)]

>
>
> -- Messaggio inoltrato --
> From: Sebastian Kügler 
> To: plasma-devel@kde.org
> Date: Wed, 16 Mar 2011 23:44:48 +0100
> Subject: Plasmate status
> Hi,
>

I've spent a few days working on various aspects of Plasmate, our little
> Add-
> On creator application. Newest screenshots:
>
> http://vizzzion.org/stuff/screenshots/plasmate-alpha3-startpage.png
> http://vizzzion.org/stuff/screenshots/plasmate-alpha3-editing.png
>

Looks pretty cool indeed :D
Thank you (and also to PovAddict) for the Git migration!

>
> Here's some updates which you might find interesting:
>
> - I've reworked the startpage to be more explanatory and inviting
> - You can now also work on a local project, without importing it (this
> seems
>  very useful for working on QML applets that are already in Git, or on the
>  harddisk
> - The editor now automatically loads the mainscript, when a project is
> opened:
>  more instant-hackability
> - I've converted plasmate to a git repo, git clone kde:plasmate
> - Licensing has been sorted, it's all GPLv2+ now
> - I've packaged Plasmate for openSUSE, installable packages are can be
> found
>  here:
>
> http://download.opensuse.org/repositories/home:/vizzzion/openSUSE_11.4/i586/plasmate-0.1alpha3-1.1.i586.rpm
>
> http://download.opensuse.org/repositories/home:/vizzzion/openSUSE_11.4/x86_64/plasmate-0.1alpha3-1.1.x86_64.rpm
>
> More details:
>
> The docs, as we all know are a bit lacking, but since Plasmate used
> techbase
> embedded pages, it gets better in Plasmate as we add it there. I've started
> adding small code examples to
>
> http://techbase.kde.org/Development/Tutorials/Plasma/QML/GettingStarted#Layouts
> ; Quite fun, actually ... writing small examples in Plasmate, with its
> previewer and then explaining what happens on techbase, including the code.
>
> Editing local projects in place is I think a valuable addition, since it
> allows to just open a plasmoid directory checked out from git. So it
> doesn't
> go through the savesystem, we can probably make the timeline work with it.
>
> The timeline feature doesn't work for me. Adding a save point doesn't seem
> to
> do anything, the timeline stays empty. I've not debugged that yet, so it
> might
> be an easy fix. (Not sure though in how far that part is supposed to work
> in
> general.)
>

Probably the guy (don't rememer his nick) that ported the old Workflow dock
to the standar menu forgot to connect
the clicked signal of the "new savepoint" menuitem with the "newSavePoint()"
slot :)

>
> The nice thing is that the basic workflow works quite well, you're started
> with a new or existing plasmoid in no-time, instant gratification ahead.
>
> I'd like to include the editor's config dialog, its default settings should
> probably be synched with the proposed QML coding style (tab width, etc).
>

That's a nice :)

I was also thinking to write a GSoC proposal about a deep refactoring of
PlasMate codebase (plugin-based), since it's not easy to mantain in its
current state, make it not crashing if the previewer crashes, add the theme
creation support, maybe try adding Qt QML editor into plasmate, and make it
ready for its first release.

Ok, now back to KMix QML applet =)

Cheers,
Diego


> That's it for now  :)
>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Rework KMix DBus API and add KMix plasma dataengine

[Diego Casella]

> On March 14, 2011, 7:06 p.m., Diego Casella wrote:
> > Ok, sorry again for my late reply :(
> > Services are working great, however, I think you should refactor the way 
> > the 'mixer' DataEngine works, because it doesn't completely performs what 
> > it is supposed to.
> > Let me explain better: when you invoke the "mixer" DataEngine, you get only 
> > the audio cards names, and nothing more. You have to query() the 
> > DataEngine, passing one of those names, to receive further infos about the 
> > specific control of that audio card (this is what I, and I think other 
> > people does, expect when using this DataEngine).
> > And this is kinda bad because, since the DataEngine doesn't automatically 
> > updates when the volume changes level/state (see my previous comment), I 
> > have to call a query() every N milliseconds and then, for each control, 
> > check is something has changed and do a manual update of the plasmoid if 
> > needed.
> > Long story short: instead of returning a "Mixers" datasource, with key set 
> > to "Mixers" again, you should return a datasource with all the MIXER_ID's 
> > and, for each of them, all their detailed infos (volume and mute state 
> > included), so we can get all we need in one shot :)
> > (You could run "plasmaengineexplorer" and watch a couple of engines, such 
> > as 'org.kde.activities', 'hotplug' or 'tasks' to see what I mean)
> > 
> > Note that this will fix also the update() issue because, with the current 
> > implementation, the plasmoid won't update unless the value of one of the 
> > "Mixers" keys changes (since it contains only the audio card names, it 
> > means we will be notified of changes only if an audio card has been 
> > plugged/removed).
> > 
> > Anyways, these are my two cent: Aaron, what do you think about it?
> 
> Igor Poboiko wrote:
> I thought that the 'dataUpdated' signal is emitted every time data 
> changes (even from inside the dataengine - in our case, I update the 
> mute/volume by DBus signals from inside the dataengine, and it updates 
> automatically in plasmaengineexplorer), and there is no need to poll the 
> dataengine.
> The other problem is that actually the plasmoid needs information only 
> about few controls (one or a bit more sliders in plasmoid). So is there a 
> need to set ALL the controls (by default)?
> And again, what is the difference between adding these sources by default 
> and querying it, for example, on plasmoid start? I guess I misunderstood 
> something, but don't you anyway need to poll these sources to get all 
> changing data?
> And one more issue - there are three types of datasources: one basic 
> (called "Mixers", provides info about available Mixers/soundcards), some for 
> mixers/soundcards (which provides information about its controls) and some 
> for controls (which provides information about all its state - volume level, 
> mute, etc). Should I add all these sources? And should I add it automatically 
> add all sources for plugged devices-sources?
> 
> Huh, I asked so many questions.. The things you are talking about are 
> easy-to-fix, I maybe just don't understand correctly what you need :)

Err, I was referencing the controls with the same index of the audio card ( 
i.e. 'ALSA::HDA_Intel:1' and thus 'Master:1', instead of 'Master:0'), my bad :(
So, forget what I said :)
Anyways, one more observation: if we want to provide a complete replacement of 
the old KMix applet, the plasmoid should be able to provide a 'widget' to 
select/change which channel we are currently operating with (master, pcm, 
speakers ..). In other words, we need a Plasma Service to change the current 
master channel, and one more entry in the dataengine to identify which channel 
is currently being controlled.


- Diego


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


On March 8, 2011, 7:01 p.m., Igor Poboiko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6587/
> ---
> 
> (Updated March 8, 2011, 7:01 p.m.)
> 
> 
> Review request for Plasma and Diego Casella.
> 
> 
> Summary
> ---
> 
> This patch reworks KMix DBus API and adds a plasma dataengine+service as a 
> fronte

Re: Review Request: Rework KMix DBus API and add KMix plasma dataengine

[Diego Casella]

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


Ok, sorry again for my late reply :(
Services are working great, however, I think you should refactor the way the 
'mixer' DataEngine works, because it doesn't completely performs what it is 
supposed to.
Let me explain better: when you invoke the "mixer" DataEngine, you get only the 
audio cards names, and nothing more. You have to query() the DataEngine, 
passing one of those names, to receive further infos about the specific control 
of that audio card (this is what I, and I think other people does, expect when 
using this DataEngine).
And this is kinda bad because, since the DataEngine doesn't automatically 
updates when the volume changes level/state (see my previous comment), I have 
to call a query() every N milliseconds and then, for each control, check is 
something has changed and do a manual update of the plasmoid if needed.
Long story short: instead of returning a "Mixers" datasource, with key set to 
"Mixers" again, you should return a datasource with all the MIXER_ID's and, for 
each of them, all their detailed infos (volume and mute state included), so we 
can get all we need in one shot :)
(You could run "plasmaengineexplorer" and watch a couple of engines, such as 
'org.kde.activities', 'hotplug' or 'tasks' to see what I mean)

Note that this will fix also the update() issue because, with the current 
implementation, the plasmoid won't update unless the value of one of the 
"Mixers" keys changes (since it contains only the audio card names, it means we 
will be notified of changes only if an audio card has been plugged/removed).

Anyways, these are my two cent: Aaron, what do you think about it?

- Diego


On March 8, 2011, 7:01 p.m., Igor Poboiko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6587/
> -------
> 
> (Updated March 8, 2011, 7:01 p.m.)
> 
> 
> Review request for Plasma and Diego Casella.
> 
> 
> Summary
> ---
> 
> This patch reworks KMix DBus API and adds a plasma dataengine+service as a 
> frontend to information provided by DBus.
> New DBus structure is:
>  - /Mixers
> used to get some global information, such as available mixers list and global 
> master mixer
>  - /Mixers/MIXER_ID
> used to get information about mixer with id=MIXER_ID. It provides such 
> information as list of available controls, name of this mixer, id, etc
>  - /Mixers/MIXER_ID/CONTROL_ID
> used to get and set information about control. Such information as volume 
> level, mute, name of control, etc.
> It also adds a DBus signals which are emitted when new mixer/control appears, 
> or volume level changes.
> It also splits all dbus-related code to separate class, 
> DBus{KMix,Mixer,Control}Wrapper.
> 
> The Plasma Dataengine:
> By default, the only available source is "KMix". It provides information 
> global information about KMix: is KMix running, and list of available mixers. 
> (its IDs)
> Source for every mixer is called by it's ID (for example, 
> "ALSA::HDA_Intel:1"). This source provides such information about current 
> Mixer as: it's readable name, is it opened, its balance and list of available 
> controls. It also adds basic sources for every control, which provides only 
> information about its readable name
> Sources for controls are called by 'MIXER_ID/CONTROL_ID' (for example, 
> "ALSA::HDA_Intel:1/Master:0"). If you request this source, it will provide 
> such information as its readable name, is it muted and its volume level 
> (which are updates automatically, using DBus signals).
> There is a service available for controls sources. It provides such methods 
> as setVolume() and setMute().
> 
> It doesn't close bug 171287, but it becomes one step closer to its solving :)
> 
> And, I'm not very familiar with CMake, but it would be great idea to make 
> plasma part optional.
> 
> 
> This addresses bug 171287.
> https://bugs.kde.org/show_bug.cgi?id=171287
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdemultimedia/kmix/CMakeLists.txt 1223808 
>   /trunk/KDE/kdemultimedia/kmix/apps/kmix.cpp 1223808 
>   /trunk/KDE/kdemultimedia/kmix/core/mixdevice.h 1223808 
>   /trunk/KDE/kdemultimedia/kmix/core/mixdevice.cpp 1223808 
>   /trunk/KDE/kdemultimedia/kmix/core/mixer.h 1223808 
>   /trunk/KDE/kdemultimedia/kmix/core/mixer.

Re:Re: Plasma services within Javascript (Aaron J. Seigo)

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Wed, 9 Mar 2011 10:02:37 +0100
> Subject: Re: Plasma services within Javascript
> On Tuesday, March 8, 2011, Diego Casella ([Po]lentino) wrote:
> > Hey guys,
> >
> > after a long time without playing with scripted plasmoid, I've noticed
> that
> > using a Service is somewhat broken.
> > I've even tried to follow the steps descibed here [0], of course changing
> > the following line from
> > service = engine.serviceForSource("notification");
> >
> > to
> > service = plasmoid.service("notifications", "notification");
> >
> > but I'm still getting a "TypeError: Result of expression
> > 'plasmoid.service'[undefined] is not a function."
> > Does anybody know where I'm wrong?
>
> palsmoid.service does not exist.
> engine.serviceForSource does.
>
> iow, trust the error messages :)
>

hhmm ok, anyways the example listed in [0] is still not working. Hints about
this?


[0]
http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/CheatSheet#Notifications


>
> > Oh, an other thing, really strange: seems like the "X-Plasma-MainScript"
> > entry is completely ignored. I've tried to start a Js
> > plasmoid , but the previewer shows nothing unless I rename the main
> script
> > from "project_name.js" to "main" ( back in the old days,
> > I set plasmate to name the mainscript as "project_name.js", thus
> > "X-Plasma-MainScript=code/project_name.js", and we had never
> > encountered a problem like this).
> > This issues happens even wihtin plasmoidviewer, so perhaps something
> > changed inside Plasma?
>
> this is working just fine here ... what version of kdelibs and kde-runtime
> are
> you using?
>
>
Oh this is kind of weird. Last night I recompiled KDE (last time I did it
was sunday night), and now it's working good.
/me is still wondering why me and Yuen Hoe had the same issue yesterday ..
Yuen Hoe, can you please verify if the problem still persists after a
rebuild of kdelibs/kdebase-runtime?
Cheers!


> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Rework KMix DBus API and add KMix plasma dataengine

[Diego Casella]

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


Sorry for the late reply Igor, I was kinda busy these days. I've tried the 
dataengine within a test plasmoid I did, and it works great :)
I can get and query all the channels, volume changes are correctly notified if 
an external application modifies the current level,
and works fine with the multimedia keys too.
I couldn't test the Plasma Services yet because I can't invoke them within 
javascript; as soon as I get I reply from plasma ml I will try everything.
Now, a little bit tricky part (Aaron, correct me if I'm wrong): if I write the 
following code

dataEngine("mixer").connectSource("Mixers", plasmoid)

instead of

dataEngine("mixer").connectSource("Mixers", plasmoid, 500)

I would expect to be notified of volume changes only when a volume change 
actually takes place, instead of requesting the dataengine's data every 500ms.
In your current implementation this is not happening, and I'd _really_ like to 
see this feature implemented.

- Diego


On March 8, 2011, 8:38 a.m., Igor Poboiko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6587/
> ---
> 
> (Updated March 8, 2011, 8:38 a.m.)
> 
> 
> Review request for Plasma and Diego Casella.
> 
> 
> Summary
> ---
> 
> This patch reworks KMix DBus API and adds a plasma dataengine+service as a 
> frontend to information provided by DBus.
> New DBus structure is:
>  - /Mixers
> used to get some global information, such as available mixers list and global 
> master mixer
>  - /Mixers/MIXER_ID
> used to get information about mixer with id=MIXER_ID. It provides such 
> information as list of available controls, name of this mixer, id, etc
>  - /Mixers/MIXER_ID/CONTROL_ID
> used to get and set information about control. Such information as volume 
> level, mute, name of control, etc.
> It also adds a DBus signals which are emitted when new mixer/control appears, 
> or volume level changes.
> It also splits all dbus-related code to separate class, 
> DBus{KMix,Mixer,Control}Wrapper.
> 
> The Plasma Dataengine:
> By default, the only available source is "KMix". It provides information 
> global information about KMix: is KMix running, and list of available mixers. 
> (its IDs)
> Source for every mixer is called by it's ID (for example, 
> "ALSA::HDA_Intel:1"). This source provides such information about current 
> Mixer as: it's readable name, is it opened, its balance and list of available 
> controls. It also adds basic sources for every control, which provides only 
> information about its readable name
> Sources for controls are called by 'MIXER_ID/CONTROL_ID' (for example, 
> "ALSA::HDA_Intel:1/Master:0"). If you request this source, it will provide 
> such information as its readable name, is it muted and its volume level 
> (which are updates automatically, using DBus signals).
> There is a service available for controls sources. It provides such methods 
> as setVolume() and setMute().
> 
> It doesn't close bug 171287, but it becomes one step closer to its solving :)
> 
> And, I'm not very familiar with CMake, but it would be great idea to make 
> plasma part optional.
> 
> 
> This addresses bug 171287.
> https://bugs.kde.org/show_bug.cgi?id=171287
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdemultimedia/kmix/CMakeLists.txt 1223808 
>   /trunk/KDE/kdemultimedia/kmix/apps/kmix.cpp 1223808 
>   /trunk/KDE/kdemultimedia/kmix/core/mixdevice.h 1223808 
>   /trunk/KDE/kdemultimedia/kmix/core/mixdevice.cpp 1223808 
>   /trunk/KDE/kdemultimedia/kmix/core/mixer.h 1223808 
>   /trunk/KDE/kdemultimedia/kmix/core/mixer.cpp 1223808 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbuscontrolwrapper.h PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbuscontrolwrapper.cpp PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixerwrapper.h PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixerwrapper.cpp PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixsetwrapper.h PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixsetwrapper.cpp PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/org.kde.kmix.control.xml PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/org.kde.kmix.mixer.xml PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/org.kde.kmix.mixset.xml PRE-CREATION 
>   /

Plasma services within Javascript

[Diego Casella ([Po]lentino)]

Hey guys,

after a long time without playing with scripted plasmoid, I've noticed that
using a Service is somewhat broken.
I've even tried to follow the steps descibed here [0], of course changing
the following line from
service = engine.serviceForSource("notification");

to
service = plasmoid.service("notifications", "notification");

but I'm still getting a "TypeError: Result of expression
'plasmoid.service'[undefined] is not a function."
Does anybody know where I'm wrong?

Oh, an other thing, really strange: seems like the "X-Plasma-MainScript"
entry is completely ignored. I've tried to start a Js
plasmoid , but the previewer shows nothing unless I rename the main script
from "project_name.js" to "main" ( back in the old days,
I set plasmate to name the mainscript as "project_name.js", thus
"X-Plasma-MainScript=code/project_name.js", and we had never
encountered a problem like this).
This issues happens even wihtin plasmoidviewer, so perhaps something changed
inside Plasma?
Cheers

Diego



[0]
http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/CheatSheet#Notifications
-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: the next step on the desktop

[Diego Casella ([Po]lentino)]

Sorry for the clutter in my previous email, I forgot to fully clean the body
of the email :(
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: the next step on the desktop

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Sun, 30 Jan 2011 17:22:41 -0800
> Subject: the next step on the desktop
>
> my proposal is this:
>  [...]
> * a new panel layout (TBD: let's work on this together!)
>

Panels, in the current implementation, are shared across different
activities: what about adding an option like "stick to current activity", in
order to achieve different panels for different activities?
That would be great imho because, in some activities I'm using, I don't
really need the default panel with the notification applet, application
launcher and clock, and I would be happy to replace it with a smaller panel
with some "common used applications" launchers, and a big side panel with
microblog and rss plasmoid.
That's just my two cents and use-case, tho :)
Cheers,

Diego


> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Sun, 30 Jan 2011 17:38:32 -0800
> Subject: Re: the next step on the desktop
> On Sunday, January 30, 2011, Aaron J. Seigo wrote:
> > my proposal is this:
>
> forgot:
>
> * a selection of pre-made activities (not running) including a trad desktop
> /
> folderview thig
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
>
> -- Messaggio inoltrato --
> From: Markus Slopianka 
> To: plasma-devel@kde.org
> Date: Mon, 31 Jan 2011 03:17:00 +0100
> Subject: Re: the next step on the desktop
> Am Montag 31 Januar 2011, 02:22:41 schrieb Aaron J. Seigo:
> > hi...
> >
> > back when we started the path towards plasma i said that we needed to
> > slowly evolve the desktop beyond the desktop folder with icons littered
> on
> > the desktop.
> >
> > now we have activities, kick-ass containments like search and launch and
> > grouping desktop.
> >
> > it is time to go to that next step and move people away from the old
> ways.
> >
> > i was at a friend's house last night where a bunch of people gathered to
> > hang out, chat, play games, etc. there was a desktop system there running
> > plasma desktop with the search and launch containment and a gorgeous
> > translucent panel couresty of kwin.
> >
> > i saw it and hardly recognized it: it looked new, amazing, the next
> thing.
> > it looked amazing.
> >
> > so, here's my suggestion for 4.7:
> >
> > let's try something big and new. let's make that Big Move and step away
> > from ~/Desktop.
>
> Frankly, I like my dumping ground.
>
> > my proposal is this:
> >
> > * by default, Search and Launch on the desktop
>
> What do you mean by that? Full screen SAL like on Plasma Netbook? Then one
> could just use
> that. However, if you mean a SAL plasmoid is the corner of the screen or a
> new top bar
> with a search bar and an extender than displays the icons (or another
> approach that
> combines both metaphors), I'd be fine with that.
> As long as KDE's file search and indexing mechanism is still broken
> ,
> I see more
> frustration than benefit. I could be wrong, though.
>
> > * improve the tasks widget to have some of the nice features of widgets
> > like "smooth tasks" with the mouse over highlights
>
> I'd be happy if I could disable the scroll wheel for starters...
>
>
> > * an "activities" widget (i'll hapilly write it) that sits next to the
> app
> > launcher and when clicked brings up the actvities manager
> > * an activities switcher as a kwin effect (!)
> > * have all activities avaiable in kactivitmanagerd, even if they are
> > "stopped" in plasma-desktop
>
> It seems to me that programmers with their fully cramped task bars (IDE,
> terminals,
> debuggers, SCM frontends,...) are bigger fans of activities than the common
> persons with
> music player and browser open alone and -- if they are cutting edge -- even
> separate chat
> and mail clients.
> Personally, I'd rather have an actually good Dock implementation that
> merges launcher,
> task switcher, and systray in a single icon for each app. But that's
> possibly the former
> Mac user speaking inside me.
>
> I'm willing to try alternative approaches with an open mind, though.
> Especially when I can
> try them in my 4.6 installation (I'm assuming QML plasmoids and activity
> templates can be
> used for that kind of stuff).
> Maybe I can come up with a mockup for something different myself in the
> coming days.
>
> Markus
>
>
>
> -- Messaggio inoltrato --
> From: todd rme 
> To: plasma-devel@kde.org
> Date: Sun, 30 Jan 2011 22:00:13 -0500
> Subject: Re: the next step on the desktop
> On Sun, Jan 30, 2011 at 8:22 PM, Aaron J. Seigo  wrote:
> > hi...
> >
> > ba

Re: Review Request: Prevent plasma tooltips to draw halos on empty lines.

[Diego Casella]

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

(Updated 2010-12-29 17:59:17.786485)


Review request for Plasma, Aaron Seigo and Marco Martin.


Changes
---

Empty spaces--


Summary
---

In a multi-line Plasma tooltip, don't draw a halo around empty lines.


Diffs (updated)
-

  /trunk/KDE/kdelibs/plasma/private/tooltip.cpp 1210128 

Diff: http://svn.reviewboard.kde.org/r/6233/diff


Testing
---

Test done with r1210128, results are shown in the screenshots below.


Screenshots
---

Calendar Tooltip
  http://svn.reviewboard.kde.org/r/6233/s/596/
Calendar Tooltip patched
  http://svn.reviewboard.kde.org/r/6233/s/597/
Clock Tooltip
  http://svn.reviewboard.kde.org/r/6233/s/598/
Clock Tooltip patched
  http://svn.reviewboard.kde.org/r/6233/s/599/


Thanks,

Diego

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

Review Request: Prevent plasma tooltips to draw halos on empty lines.

[Diego Casella]

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

Review request for Plasma, Aaron Seigo and Marco Martin.


Summary
---

In a multi-line Plasma tooltip, don't draw a halo around empty lines.


Diffs
-

  /trunk/KDE/kdelibs/plasma/private/tooltip.cpp 1210128 

Diff: http://svn.reviewboard.kde.org/r/6233/diff


Testing
---

Test done with r1210128, results are shown in the screenshots below.


Screenshots
---

Calendar Tooltip
  http://svn.reviewboard.kde.org/r/6233/s/596/
Calendar Tooltip patched
  http://svn.reviewboard.kde.org/r/6233/s/597/
Clock Tooltip
  http://svn.reviewboard.kde.org/r/6233/s/598/
Clock Tooltip patched
  http://svn.reviewboard.kde.org/r/6233/s/599/


Thanks,

Diego

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

Re: Re: Error while building

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: sujith h 
> To: plasma-devel@kde.org
> Date: Sat, 2 Oct 2010 12:13:34 +0530
> Subject: Error while building
> Hi,
>
> I had found an error while building the kdebase. The error actually
> pointed for the requirement saying it needs 0.6.0 version of dbusmenu-qt.
> I had updated the dbusmenu-qt by pulling it from the gitorious. And
> its already updated. Again am facing the same issue with the kdebase build.
> A helping hand to resolve this issue would be very much appreciated.
>
>
> Sujith H
>
> --
> സുജിത് ഹരിദാസന്
> Bangalore
> http://fci.wikia.com/wiki/Anti-DRM-Campaign
>  http://sujithh.info
>
>
Try to move dbusmenu-qt into the last available tag (git checkout 0.6.4.kde
IIRC), then rebuild dbusmenu-qt and kdebase; this did the trick for me. Once
they will fix that issue (Found version ".." sounds ), you can make your
clone to point back to master :)

Diego.

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Need advice about the Authentication framework GSoC project

[Diego Casella ([Po]lentino)]

Hi guys,
as you should know, I'm developing an authentication framework for scripted
plasmoid using the QCA framework. During these last days I was trying to
retrieve, for each key in the local keystore, the list of key IDs which
signed that given key and, consequently, split them by their level of trust
(KDE key, key signed by a KDE key, user key and so on .. ).
Surprisingly, the QCA::PGPKey class doesn't provide this kind of method and,
looking at the qca-gnupg plugin source in[0], there aren't the usual command
switches to show all the signatures for each keys (--list-sigs or
--check-sigs) :(
So now, what should I do? I've a couple of ideas on my mind:
* patch the plugin, and the PGPKey class ;
* use qprocess to call gpg --check-sigs and then parse its output  ;
* write a new qca plugin based on gpgme library, instead of using the
qca-gnupg which relies upon the gpg executable ;
* contact qca mantainer and request for a patch ;
What do you think about it ?
Thanks for your help,
cheers !!

Diego


[0]: http://websvn.kde.org/trunk/kdesupport/qca/plugins/qca-gnupg/gpgop.cpp

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

Hi all,
I've updated again the proposal about scripted plasmoid authentication to
better match the emerging needs :)
As usual, any feedback/advice is very appreciated!
Cheers,

-- Diego

Link:
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/diego_casella/t127038771188
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Subject: Re: Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Chani 
> To: plasma-devel@kde.org
> Date: Mon, 5 Apr 2010 15:52:07 -0700
> Subject: Re: Subject: Re: [GSoC] Proposal: Authentication for scripted
> plasmoid downloaded from the web
> On April 5, 2010 15:33:00 Diego Casella ([Po]lentino) wrote:
> > Hi all,
> > after reading some comments on my proposal, I've performed a couple of
> > changes on the implementation details and the timeline, so it should fit
> > better the GSoC schedule now :)
> > To be more precise, I've also included improving PlasMate in order to
> show
> > a widget to easily create and manage the private and public keys, along
> > with the possibility to export the public keys.
> > The Publish widget will be improved as well, showing a "Sign" checkbox
> that
> > will allow the developer to choose which key, from the ones previously
> > created, will be used to sign the plasmoid before the install/upload
> > process.
>
> having plasmoid signing in plasmate is a good idea :)
> "create and manage keys", though? that sounds like kgpg's job.
> I would imagine that plasmate would have something like kmail, where you
> can
> choose which key to use for signing, from your existing keys...
>
> although, you might want to add something that makes it easy for people not
> so
> familiar with gpg to get set up. so, hmm.
>
> That's exactly the reason :)
Since plasmate is designed for lowering the bar for contribution to KDE, it
means that almost certainly a tipical user won't be familiar with the
concept of creating keys using kgpg. So that's why I'd like to provide a
simplified widget for these operations. That's also the reason why I want to
keep these keys separated between all the others because, if they aren't
kept divided, the dev could delete the wrong entry by mistake, and this
could be really bad.

> --
> This message brought to you by eevil bananas and the number 3.
> www.chani3.com
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

Hi all,
after reading some comments on my proposal, I've performed a couple of
changes on the implementation details and the timeline, so it should fit
better the GSoC schedule now :)
To be more precise, I've also included improving PlasMate in order to show a
widget to easily create and manage the private and public keys, along with
the possibility to export the public keys.
The Publish widget will be improved as well, showing a "Sign" checkbox that
will allow the developer to choose which key, from the ones previously
created, will be used to sign the plasmoid before the install/upload
process.
By doing this, at the end of the GSoC schedule, plasma will have one
application to authenticate the plasmoids - the plasma widget explorer - and
an other tool to sign them, PlasMate :)
The link to the full proposal is
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/diego_casella/t127038771188
I'm looking for your thoughts and comments,
Cheers

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

Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Chani 
> To: plasma-devel@kde.org
> Date: Sun, 4 Apr 2010 10:56:42 -0700
> Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid
> downloaded from the web
> On April 4, 2010 06:39:10 Diego Casella ([Po]lentino) wrote:
> > Hi guys,
> > sorry for being late, however here it is my proposal for this summer of
> > code.
> > Since, during PlasMate development, we talked a bit about the possibility
> > to verify the plasmoids downloaded from kde-look.org or opendesktop.org,
> I
> > think about it for a while and I came whit the idea to improve
> > plasmaengineexplorer (plus plasmapkg and PlasMate, if there wil be enough
> > time) in order
>
> I assume you mean plasma *widget* explorer ;)
>

You are right, I made a lot of typos in this email >.<

>
> > to use the QCA api to provide plasmoids authentication. Here it is my
> > implementation details (see the full proposal here
> >
> http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/di
> > ego_casella/t127038771188 ):
>
> psst. only mentors have access to that page - note the "private" in the url
> :)
> I suggest you upload your proposal somewhere public as well.
>
> this one should work :)
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/diego_casella/t127038771188

-- Messaggio inoltrato --
> From: Chani 
> To: plasma-devel@kde.org
> Date: Sun, 4 Apr 2010 11:19:25 -0700
> Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid
> downloaded from the web
> On April 4, 2010 11:02:30 Marco Martin wrote:
> > On Sun, Apr 4, 2010 at 3:39 PM, Diego Casella ([Po]lentino)
> >
> >  wrote:
> > > Hi guys,
> > > sorry for being late, however here it is my proposal for this summer of
> > > code.
> > > Since, during PlasMate development, we talked a bit about the
> possibility
> > > to verify the plasmoids downloaded from kde-look.org or
> opendesktop.org,
> > > I think about it for a while and I came whit the idea to improve
> > > plasmaengineexplorer (plus plasmapkg and PlasMate, if there wil be
> > > enough time) in order
> > > to use the QCA api to provide plasmoids authentication. Here it is my
> > > implementation details (see the full proposal here
> > >
> http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/
> > > diego_casella/t127038771188):
> > >
> > > My idea is to use the QCA framework in order to verify the signature of
> > > the plasmoids downloaded from kde-look.org, opendesktop.org, or
> > > installed with plasmapkg/PlasMate. This will require patching the
> plasma
> > > widgetexplorer and plasmapkg (and also PlasMate in order to support the
> > > package signing process, if time permits that).
> >
> > This is a must have and was in the todo since day one...
> > as Chani said i'm not sure if is better at Plasma Package level or at
> > a broader thing for all ghns stuff
> >
>
> hmm.
> honestly I think we'll want it at *both* levels in the end.
> the GHNS dialog will need to ask the server about the security rating, so
> some
> sort of server-side support needs writing for that.
> but we also want to check the security of manually downloaded plasmoids
> (or,
> say, a plasmoid that a friend emailed us). so we want it in Plasma too.
>
> it probably makes sense to start it in plasma, and spread it from there. :)
>

Yep !

>
> oh, another thing: the kcm part of the proposal was kinda vague. I expect
> that
> it'll be just a simple thing, and advanced key-management stuff will be
> left to
> programs like kgpg... we don't want to scare people off. :) of course most
> will
> just leave it with the default KDE key anyways.. hrrm... what exactly is
> the
> kcm needed for? can't you just check which keys I trust in my keyring?
>

The idea of the KCM module is to provide a unique place where listing and
showing all the keys saved, with the opportunity to add/delete them, nothing
more :)
Of course if the keys are the ones shipped with KDE/linux distributor, they
will be available in read only mode (however they can be modified by
performing something like an "sudo apt-get upgrade", if updated keys are
available); otherwise, for third-party keys,you can add/delete them if you
trust its releaser.
Using the default keyring is correct, but since we can't tell how many keys
will be pre-installed, and how many others will be installed by the user, I
don't like the idea to pollute the default keyring with all of these.
By the way this is only my opinion, that's why I need your advices :)

>
> --
> This message brought to you by eevil bananas and the number 3.
> www.chani3.com
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

Hi guys,
sorry for being late, however here it is my proposal for this summer of
code.
Since, during PlasMate development, we talked a bit about the possibility to
verify the plasmoids downloaded from kde-look.org or opendesktop.org,
I think about it for a while and I came whit the idea to improve
plasmaengineexplorer (plus plasmapkg and PlasMate, if there wil be enough
time) in order
to use the QCA api to provide plasmoids authentication. Here it is my
implementation details (see the full proposal here
http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/diego_casella/t127038771188
):


My idea is to use the QCA framework in order to verify the signature of the
plasmoids downloaded from kde-look.org, opendesktop.org, or installed with
plasmapkg/PlasMate. This will require patching the plasma widgetexplorer and
plasmapkg (and also PlasMate in order to support the package signing
process, if time permits that).

Basically, when downloading a scripted plasmoid, the widget explorer will
extract a file containing the signature of the plasmoid, and check its
validity with a set of public keys shipped with KDE, or a set of custom
imported keys (manageable from a KCM module): if the validation process is
successfull against the original KDE keys, the widget explorer will show a
green flag in a corner of the corresponding plasmoid icon, meaning that the
plasmoid has been made from a KDE developer, so you can trust it. If the
validation is successful with a custom key imported by the user, a yellow
flag will be displayed instead, meaning that plasmoid is signed and you
trust the developer who released that plasmoid. If no keys are matched, or
the plasmoid is shipped without a signature file, a red flag will be shown,
meaning "use it at your own risk". Tooltips will be also patched in order to
show these informations.


Any feedback, suggestion or advice is welcome !

Cheers,

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

Subject: Re: Plasmate alpha2?

[Diego Casella ([Po]lentino)]

>
> On Mon, Mar 1, 2010 at 11:46 PM, Aaron J. Seigo  wrote:
>
>> On March 1, 2010, Yuen Hoe Lim wrote:
>> > scripted dataengines). So I was thinking it might be a good idea to take
>> > the opportunity and push out a parallel alpha release that, combined
>> with
>> > the 4.4.1 fixes, would provide a much more usable experience.
>>
>> sounds good; i'll whip out a tarball and name it alpha 2 :)
>>
>> > It might also come in handy for the folks joining the Javascript Jam :)
>>
>> agreed.
>>
>> btw, would it be worthwhile to do a plasmate irc meeting and work up some
>> "todo for the release" notes?
>>
>
> Yes, that'd be very nice :) I'd be ok with anything except this weekend.
> What about you moofang? Diego?
>

Fine for me :)

>
>> --
>> Aaron J. Seigo
>> humru othro a kohnu se
>> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>>
>> KDE core developer sponsored by Qt Development Frameworks
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

About javascript API, again :P

[Diego Casella ([Po]lentino)]

Hello guys,

I'm trying to adding a theme icon to a PushButton object, but I'm stuck with
it.
I've tried some combinations such as:

pb = new PushButton()
pb.icon = new QIcon("system-search")

or

pb.image = "system-search"

but seems it doesn't work. However, if I do

iw = new IconWidget()
iw.setIcon("system-search")
pb.icon = iw.icon

it works O.o . Any ideas/hints ?

I've also noticed that radio buttons are not mutually exclusive :)
Cheers!

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

Subject: Re: Javascript runApplication() question

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Sat, 20 Feb 2010 03:30:17 -0800
> Subject: Re: Javascript runApplication() question
> On February 20, 2010, Diego Casella ([Po]lentino) wrote:
> > Or, from an other point of view: is it planned to add a KProcess
> Javascript
> > binding for Plasma?
>
> you're looking for the exec DataEngine :)
>

Cool, thanks :)

>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Javascript runApplication() question

[Diego Casella ([Po]lentino)]

Heya folks,

I've noticed in the Javascript API there is a bool runApplication(string
exe[, array args]) [0] function that allows you to run
an executable with optional arguments. If I try running a command-line
executable instead of a GUI one ( for example
runApplication("ls", "my/favourite/directory/") ), returning a bool value is
not useful at all.
So my question is: it is possible to get the string with the result of the
command above?
Or, from an other point of view: is it planned to add a KProcess Javascript
binding for Plasma?
Cheers,

Diego.

[0]
http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API#LaunchApp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Automatic crash report generated by DrKonqi for Plasmate.

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Geoffray 
> To: plasma-devel@kde.org
> Date: Wed, 17 Feb 2010 15:13:37 +0100
> Subject: Automatic crash report generated by DrKonqi for Plasmate.
> Application: plasmate (0.1alpha1)
> KDE Platform Version: 4.4.00 (KDE 4.4.0) (Compiled from sources)
> Qt Version: 4.6.0
> Operating System: Linux 2.6.32-2-amd64 x86_64
> Distribution: Debian GNU/Linux 5.0.4 (lenny)
>
> -- Information about the crash:
> The crash occurs when right-clicking on a recent project in main window.
>
>  -- Backtrace:
> Application: Plasmate (plasmate), signal: Segmentation fault
> [KCrash Handler]
> #5  QBasicAtomicInt::ref (this=0x18136f0, other=...) at
> ../../include/QtCore/../../src/corelib/arch/qatomic_x86_64.h:121
> #6  QUrl (this=0x18136f0, other=...) at io/qurl.cpp:4106
> #7  0x7f53941350df in KUrl (this=0x18136f0, _u=...) at
> /share/src/kde/KDE/kdelibs/kdecore/io/kurl.cpp:472
> #8  0x0042a6af in GitRunner::setDirectory (this=0x181e5a0, dir=...)
> at
> /share/src/kde/playground/plasma/plasmate/savesystem/gitrunner.cpp:76
> #9  0x0042a725 in GitRunner::isValidDirectory (this=0x181e5a0) at
> /share/src/kde/playground/plasma/plasmate/savesystem/gitrunner.cpp:87
> #10 0x0042efbe in TimeLine::loadTimeLine (this=0x1818770, dir=...)
> at
> /share/src/kde/playground/plasma/plasmate/savesystem/timeline.cpp:50
> #11 0x00437807 in MainWindow::loadProject (this=0xdc6ab0, name=...,
> type=...) at /share/src/kde/playground/plasma/plasmate/mainwindow.cpp:531
> #12 0x0041c4c5 in MainWindow::qt_metacall (this=0xdc6ab0,
> _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0x7fff4cb9e3c0) at
> /share/src/build/kde/playground/plasma/plasmate/moc_mainwindow.cpp:96
> #13 0x7f5393d1c647 in QMetaObject::activate (sender=0xe6c110, m= optimized out>, local_signal_index=, argv=0x18136e0)
> at
> kernel/qobject.cpp:3294
> #14 0x0041bbbf in StartPage::projectSelected (this=0xe6c110,
> _t1=...,
> _t2=...) at
> /share/src/build/kde/playground/plasma/plasmate/moc_startpage.cpp:109
> #15 0x0043badb in StartPage::emitProjectSelected (this=0xe6c110,
> name=..., type=...) at
> /share/src/kde/playground/plasma/plasmate/startpage.cpp:427
> #16 0x0043ba8b in StartPage::emitProjectSelected (this=0xe6c110,
> index=...) at /share/src/kde/playground/plasma/plasmate/startpage.cpp:422
> #17 0x0041bab2 in StartPage::qt_metacall (this=0xe6c110,
> _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7fff4cb9e600) at
> /share/src/build/kde/playground/plasma/plasmate/moc_startpage.cpp:90
> #18 0x7f5393d1c647 in QMetaObject::activate (sender=0xf38730, m= optimized out>, local_signal_index=, argv=0x18136e0)
> at
> kernel/qobject.cpp:3294
> #19 0x7f5392ec90e5 in QAbstractItemView::clicked (this=0x18136f0,
> _t1=) at .moc/release-
> shared/moc_qabstractitemview.cpp:331
> #20 0x7f5392ed599c in QAbstractItemView::mouseReleaseEvent
> (this=0xf38730,
> event=0x7fff4cb9f540) at itemviews/qabstractitemview.cpp:1757
> #21 0x7f5392eebdae in QListView::mouseReleaseEvent (this=0x18136f0,
> e=0x18136f0) at itemviews/qlistview.cpp:796
> #22 0x7f53929ff705 in QWidget::event (this=0xf38730,
> event=0x7fff4cb9f540)
> at kernel/qwidget.cpp:7974
> #23 0x7f5392daa73b in QFrame::event (this=0xf38730, e=0x7fff4cb9f540)
> at
> widgets/qframe.cpp:557
> #24 0x7f5392ed88eb in QAbstractItemView::viewportEvent (this=0xf38730,
> event=0x7fff4cb9f540) at itemviews/qabstractitemview.cpp:1589
> #25 0x7f5393d07ff8 in
> QCoreApplicationPrivate::sendThroughObjectEventFilters (this= optimized
> out>, receiver=0xf3ca70, event=0x7fff4cb9f540) at
> kernel/qcoreapplication.cpp:819
> #26 0x7f53929a905c in QApplicationPrivate::notify_helper
> (this=0xd11e90,
> receiver=0xf3ca70, e=0x7fff4cb9f540) at kernel/qapplication.cpp:4238
> #27 0x7f53929affad in QApplication::notify (this=,
> receiver=0xf3ca70, e=0x7fff4cb9f540) at kernel/qapplication.cpp:3822
> #28 0x7f539702d11b in KApplication::notify (this=0x7fff4cba00e0,
> receiver=0xf3ca70, event=0x7fff4cb9f540) at
> /share/src/kde/KDE/kdelibs/kdeui/kernel/kapplication.cpp:302
> #29 0x7f5393d08bdc in QCoreApplication::notifyInternal
> (this=0x7fff4cba00e0, receiver=0xf3ca70, event=0x7fff4cb9f540) at
> kernel/qcoreapplication.cpp:704
> #30 0x7f53929b18eb in QCoreApplication::sendEvent (receiver=0xf3ca70,
> event=0x7fff4cb9f540, alienWidget=0xf3ca70, nativeWidget=0xf70c50,
> buttonDown=, lastMouseReceiver=...,
>spontaneous=true) at
> ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
> #31 QApplicationPrivate::sendMouseEvent (receiver=0xf3ca70,
> event=0x7fff4cb9f540, alienWidget=0xf3ca70, nativeWidget=0xf70c50,
> buttonDown=, lastMouseReceiver=...,
>spontaneous=true) at kernel/qapplication.cpp:2956
> #32 0x7f5392a305b0 in QETWidget::translateMouseEvent (this=0xf70c50,
> event=) at kernel/qapplication_x11.cpp:4368
> #33 0x7f5392a2f75c in QApplication::x11ProcessEvent
> (thi

Subject: Re: Subject: Re: [PATCH] Support for arbitrary main script names in Python plasmoids

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Richard Dale 
> To: plasma-devel@kde.org
> Date: Fri, 12 Feb 2010 23:59:06 +
> Subject: Re: Subject: Re: [PATCH] Support for arbitrary main script names
> in Python plasmoids
> On Fri, Feb 12, 2010 at 10:17 AM, Richard Dale 
> wrote:
> > On Thu, Feb 11, 2010 at 11:34 PM, Diego Casella ([Po]lentino)
> >  wrote:
> >>> -- Messaggio inoltrato --
> >>> From: Richard Dale 
> >>> To: plasma-devel@kde.org
> >>> Date: Thu, 11 Feb 2010 18:37:55 +
> >>> Subject: Re: [PATCH] Support for arbitrary main script names in Python
> >>> plasmoids
> >>> On Thu, Feb 11, 2010 at 6:02 PM, Luca Beltrame <
> ei...@heavensinferno.net>
> >>> wrote:
> >>> > Hello,
> >>> >
> >>> > currently if you use Python plasmoids the main script *must* be named
> >>> > "main.py" because it is hardcoded into pyappletscripts.py. When using
> a
> >>> > different mainscript in the .desktop file (like Plasmate does) this
> will
> >>> > ensure the plasmoid will not run (you get a NameError exception).
> >>> Well currently in Plasmate there is not way to specifiy the main
> >>> script (or main class).
> >>
> >> Actually, the main script and main class names are taken from the
> project
> >> name; if you create a
> >> RubyClock project, Plasmate will create a rubyclock.rb file, with a
> >> MainRubyClock class inside it :)
> >>>
> >>> The Ruby plasmoid implementation doesn't use the Ruby equivalent of
> >>> __dict__, but simply derives the main class name from the main script
> >>> name. So I wasn't sure is you should specifiy a main *class* name in
> >>> Plasmate like FooBar which would give a main script name of
> >>> foo_bar.rb. Or whether you should give a main script name of
> >>> foo_bar.rb the Plasmate form from which the class 'FooBar' is then
> >>> derived.
> >>>
> >>> Currently in Plasmate the name of the applet is used to derive both
> >>> the module (like a namespace), and the name of the class, which I
> >>> think is wrong. For example, if you call your applet FooBar you get:
> >>>
> >>> module FooBar
> >>>  class FooBar< PlasmaScripting::Applet
> >>> ...
> >>>
> >>> I would rather the class was called 'Main' if you don't specifiy a main
> >>> script.
> >>
> >> I'm sorry, but this is wrong: I've taken care of avoiding it since the
> >> beginning
> >> (I also reverted, a couple of days ago, a commit[1] that did exactly
> what
> >> you just
> >> described ).
> > Ah OK - I was testing what the 'The_User' had just commited, which you
> > have reverted. I think the name of the main script was wrong for
> > MainForBar - it should be code/main_foo_bar.rb, and fixing that was
> > why he made the change. Personally if a main script isn't specified I
> > would prefer a class name of 'Main' and main script of 'main.rb' for
> > Ruby.
> I've just commited some changes to the Ruby folder and main script
> name generation in Ruby so that it now works correctly. If you name
> you project FooBar it will be put in a folder called 'foo_bar' and the
> main script will be called 'main_foo_bar.rb'. If you don't follow this
> convention the correct module and class name will not be generated
> when the Ruby script engine tries to load the applet. I also enabled
> creating Ruby Data Engines, as the Ruby api works file.
>
> -- Richard
>
> That's great, thanks :)


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

Subject: Re: [PATCH] Support for arbitrary main script names in Python plasmoids

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Luca Beltrame 
> To: plasma-devel@kde.org
> Date: Thu, 11 Feb 2010 19:32:13 +0100
> Subject: Re: [PATCH] Support for arbitrary main script names in Python
> plasmoids
> In data giovedì 11 febbraio 2010 19:16:53, Aaron J. Seigo ha scritto:
>
> > i can't comment on the use of __dict__ (my python-fu is non-existent :)
> but
> > using mainScript() is obviously correct from a libplasma API usage
> > perspective and if this fixes things then yes it should be backported.
>
> Just tested this in Plasmate, which I know uses custom main scripts (after
> working around a bug there), and it works perfectly. My old scripts, which
> use
> "main.py", also work OK.
>
> That's great, thanks =)


> I'll commit to trunk and backport soon.
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: [PATCH] Support for arbitrary main script names in Python plasmoids

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Richard Dale 
> To: plasma-devel@kde.org
> Date: Thu, 11 Feb 2010 18:37:55 +
> Subject: Re: [PATCH] Support for arbitrary main script names in Python
> plasmoids
> On Thu, Feb 11, 2010 at 6:02 PM, Luca Beltrame 
> wrote:
> > Hello,
> >
> > currently if you use Python plasmoids the main script *must* be named
> > "main.py" because it is hardcoded into pyappletscripts.py. When using a
> > different mainscript in the .desktop file (like Plasmate does) this will
> > ensure the plasmoid will not run (you get a NameError exception).
> Well currently in Plasmate there is not way to specifiy the main
> script (or main class).
>

Actually, the main script and main class names are taken from the project
name; if you create a
RubyClock project, Plasmate will create a rubyclock.rb file, with a
MainRubyClock class inside it :)

>
> The Ruby plasmoid implementation doesn't use the Ruby equivalent of
> __dict__, but simply derives the main class name from the main script
> name. So I wasn't sure is you should specifiy a main *class* name in
> Plasmate like FooBar which would give a main script name of
> foo_bar.rb. Or whether you should give a main script name of
> foo_bar.rb the Plasmate form from which the class 'FooBar' is then
> derived.
>
> Currently in Plasmate the name of the applet is used to derive both
> the module (like a namespace), and the name of the class, which I
> think is wrong. For example, if you call your applet FooBar you get:
>
> module FooBar
>  class FooBar< PlasmaScripting::Applet
> ...
>

> I would rather the class was called 'Main' if you don't specifiy a main
> script.
>

I'm sorry, but this is wrong: I've taken care of avoiding it since the
beginning
(I also reverted, a couple of days ago, a commit[1] that did exactly what
you just
described ). Plasmate creates by default a

Main class for ruby and python plasmoids.

So we don't have naming collision :)

>
> For Python, what if there are several classes in the the python main
> script file - how do you tell which one is for the applet you want to
> instantiate?
>
>
> > The attached patch fixes this by retrieving the mainscript file,
> stripping it
> > to its name and then using Python introspection (__dict__) to pass the
> right
> > module name to the CreateApplet call.
> >
> > After applying, old plasmoids (using main.py) and new ones (using *any
> name*)
> > seem to work correctly.
> >
> > OK to commit? Should this also be backported?
> >
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
> >
>

[1]
http://websvn.kde.org/trunk/playground/base/plasma/plasmate/templates/mainPlasmoid.rb
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasmate alpha1 release

[Diego Casella ([Po]lentino)]

>
> From: Yuen Hoe Lim 
>
>> i wonder if a purpose-built tool just
>>> for making theme packages wouldn't be better. what do you think of
>>> dropping
>>> themes from the target use cases?
>>>
>>
>> It's all the same for me. Yuen Hoe, Shantanu, what do you think ?
>>
>
> I'm not really in position to comment knowledgeably because I don't know
> anything about theming (yet). It would probably be a little weird though if
> PlasMate ends up being a complete, one-stop tool for everything else (at
> least for Plasmoids we're close to and aiming for this) but will never be as
> such for themes, if I understood Aaron's point correctly.
>

Agreed, that's my point of view indeed.
By the way, with theme packaging enabled too, PlasMate won't be a complete
Plasma development tool because we still don't provide any Wallpaper plugin
support. And, afaik, there is only python bindings for that (apart from c++,
of course).
So, should we discard theming support, or add Wallpaper support too (for
python at least, and wait for 4.5SC to get  js and ruby bindings) and make
plasmate complete ?
Or simply, release it as it is now, refining the actual features, and listen
to users feedbacks ?

>
> That's my 2cents. I think Aaron and Diego should probably make the final
> decision on this (and Shantanu too if you know ought about theming).
>
> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
> From: "Aaron J. Seigo" 
> > > the javascript DataEngine and Runner APIs are not documented. unless
> > > someone
> > > else get to it, they won't be before 4.5 is out. which is ok, since
> those
> > > Javascript APIs have known (at least to me ;) deficiencies in 4.4.
> those
> > > are
> > > really more 4.5 targets.
> >
> > Ok, so should we disable the js ( and ruby ) radio button when selecting
> a
> > runner or dataEgine project, until we get an improved API  ?
>
> yes, probably makes sense. we should make sure that they are enabled by the
> time KDE SC 4.5 is available, though. but that's 6 months away :)
>

Nice, it's time to ping kde-bindings guys then :)

>
> > > And theme support is still unavailable, in this current state.
> > >
> > > theme support would be fairly easy to add, as far as packaging goes,
> but
> > > it will still require an external tool such as Inkscape for the
> > > forseeable future. so it will never be "perfect" for theming, it really
> > > would be just more of a packaging and previewing tool.
> >
> > Ok, then something like "create the theme directory hierarchy" -> "drag
> and
> > drop svgs and color scheme" -> "preview" -> "publish" should be fine :)
>
> yes, that's all that's needed.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasmate alpha1 release

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Tue, 2 Feb 2010 13:31:02 -0800
> Subject: Re: Subject: Re: plasmate alpha1 release
> On February 2, 2010, Diego Casella ([Po]lentino) wrote:
> > We need to add a dataEngine and runner templates in Javascript, as well a
> > runner template written in ruby but, up to now, i didn't find any example
> > in order to write good templates fot that. Hints ?
>
> the javascript DataEngine and Runner APIs are not documented. unless
> someone
> else get to it, they won't be before 4.5 is out. which is ok, since those
> Javascript APIs have known (at least to me ;) deficiencies in 4.4. those
> are
> really more 4.5 targets.
>

Ok, so should we disable the js ( and ruby ) radio button when selecting a
runner or dataEgine project, until we get an improved API  ?

>
> but i can quite easily provide templates for both, and really should be
> adding
> such things to kdeexamples anyways.
>

Good :)

>

> And theme support is still unavailable, in this current state.
>
> theme support would be fairly easy to add, as far as packaging goes, but it
> will still require an external tool such as Inkscape for the forseeable
> future. so it will never be "perfect" for theming, it really would be just
> more of a packaging and previewing tool.


Ok, then something like "create the theme directory hierarchy" -> "drag and
drop svgs and color scheme" -> "preview" -> "publish" should be fine :)

i wonder if a purpose-built tool just
> for making theme packages wouldn't be better. what do you think of dropping
> themes from the target use cases?
>

It's all the same for me. Yuen Hoe, Shantanu, what do you think ?

>
> > Furthermore, IMO, we should make PlasMate project-centric, for a couple
> of
>
> agreed
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: plasmate alpha1 release

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Wed, 3 Feb 2010 02:28:33 +0800
> Subject: Re: plasmate alpha1 release
>
> I attempted the basic use-case I assumed should work: I start with some
> code, create a save point (this succeeds), then I do new things to the code,
> and then I attempt to revert the code back to the state when I created the
> save point. I don't get any errors or whatnot, but I can't seem to
> successfully revert either.
>

It's because the editor creates a backup copy of the file you are editing
and, since that backup isn't version controlled, git refuses to checkout or
revert to a previous state. Thanks for noticing ( since i turned backup off
:) !
I'll fix it as soon as possible by creating a .gitignore file :)

>
> Hmm, Personally I think I'd feel better with once every 2 months :)
>
> +1

> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: plasmate alpha1 release

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Tue, 2 Feb 2010 18:12:03 +0800
> Subject: Re: plasmate alpha1 release
> Hi guys,
>
> would it be reasonable to try for an alpha release with:
>>
>> * tagging on the 8th
>> * release on the 10th, assuming the tagging goes well
>>
>
Good for me too, so we can start recieving feedbacks from the users :)

>
> Sounds awesome! I'm not sure what kind of quality would be expected of
> alpha software though :P
>
Some of my questons/concerns about the present state of PlasMate are as
> follows:
>
>- AFAIK we are only (more or less) good to go for Plasmoids. I think
>runners et al don't quite work. Do we "hide" those options for now? :P
>
> Hiding its not a good idea, i did it this summer and they told me to not do
that; btw i agree with your idea to do something for that :)
We need to add a dataEngine and runner templates in Javascript, as well a
runner template written in ruby but, up to now, i didn't find any example in
order to write good templates fot that. Hints ?
And theme support is still unavailable, in this current state.

>
>- Likewise we currently have some UI stubs for unimplemented features
>(eg. Publish to GHNS), "hide" those too?
>- I haven't really been testing the timeline, and now that I tried it,
>it doesn't seem to work right =( Am I not using it correctly? Or is it
>bugged? Diego could you check? :P
>
> If you would be more detailed, I'll be glad to help you :)

>
>- I can't seem to create a configuration dialog for my (Python)
>plasmoid in PlasMate. I used to override showConfigurationInterface(), but
>that doesn't seem to work while using PlasMate. As long as I set
>hasConfigurationInterface to True and have the "User Interface" folder
>empty, the plasmoid always crashes when I attempt to view the configuration
>interface (right-click > settings). IIRC you're supposed to put
>QtDesigner-generated ui files in "User Interface", if so, does it make 
> sense
>to release now when there's no QtDesigner integration? Or we just leave the
>configuration interface to "future work"?
>- Additional, non-urgent point following from the last: crashing the
>plasmoid crashes PlasMate. This doesn't seem right, but I've no idea how to
>fix it at this point.
>
> What do you all think? If we could solve/get around these then for my part
> I think we're good :)
>

Agree.
Furthermore, IMO, we should make PlasMate project-centric, for a couple of
reasons:

*regardless the type of project started/opened, plasmate now loads the last
layout saved ( moreover, the layout is not resetted when changing project in
the same plasmate session ). Therefore, if we were developing a plasmoid
with the previewer visible, and then we change to a dataengine project to
fix a bug ( or if we start plasmate and open a dataengine project, when the
last project developed was a plasmoid with the previewer on ), the user will
see the previewer even if there is no reason on showing a preview for a
dataengine;

*for each project, we could save the last modified file, and show it the
next time the project will be opened again;


>
>> we should have a release plan from that point forward as well. how about:
>>
>> * a release every month, around the 10th of the month
>> * if changes warrant it and there is the manpower for it, interim releases
>> * aim for first betas in may, this would also include a feature freeze
>> * aim to move it into extragear/sdk/ and release a 0.1 release in tandem
>> with
>> KDE SC 4.5
>>
>
> Sounds good to me, although with only 2-3 devs I'm not sure how many
> changes we'll be able to push each month.
>
> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
>
>
> ___
> 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

On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Wed, 27 Jan 2010 12:45:58 +0800
> Subject: Re: On Plasmate's recent project list
>
> Correct, the project <---> folder naming convention is suggested, not
>> required ( even though I wouldn't break that :P ).
>>
>
> Hmm, okay so this brings up the greater question of whether we want to
> force project and folder names to be identical (They don't have to be
> technically, but we can force it programmatically). I'm personally not keen,
> (I have in fact already broken that rule in the implementation) and here
> again are my list of reasons :P
>
>- Forcing the names to be the same has the benefit of neatness, but I
>don't think this is always desireable since we are allowing users to import
>existing plasmoids as well as download them from GHNS (eventually), and the
>user really has no control over the names of these external projects. It'd
>be pretty troublesome, at least if it was me, if I was blocked from
>importing just because I have a project locally with the same name (note
>that if we force project and folder names to be identical, name conflicts
>will occur even if I have a plasmoid and a runner, for example, with the
>same name, and those are clearly different).
>- I think importing existing plasmoids and stuff will be a fairly
>common use-case, and the project name == folder name rule is not widely
>enforced in existing plasmoids (my own plasmoid doesn't keep this rule..)
>- For the above reasons I'm not convinced that there is a significant
>advantage of forcing project and folder names to be identical, and yet
>forcing them to be identical will make a lot of other sticky
>conflict-resolution dialogs necessary, not just in this 'import-all'
>feature. Examples: the regular project import, import from GHNS or even the
>desktop if we implement that, and when the user changes the project name in
>the metadata editor.
>
> In short, I think forcing the names to be identical will create a lot of
> extra work without really adding any significant benefit. It still can be
> done though if you guys really think it's better. What do you guys think? :)
>
> So,if we bump into a conflict situation, we rename one of the two folder,
>> good. Now, my question is: how the user will be able to distinguish the
>> "current" and "backup" version of his/her project ?
>> I mean, in the project list we can't show the directories name because
>> they must be hidden, so an appropriate way is to pick up the project name
>> from the "Name" field metadata.desktop file, and surprisingly this will be
>> 99% times the same, since previously there was a conflict, so most likely
>> the user will fill a bug report because he/she can't distingiush between the
>> two projects, and he/she is forced to look to the sources in order to find
>> the correct one.
>> So, what about showing the "Remove,overwrite,ignore" buttons, or adding
>> more informations in the project list (for example adding the date of last
>> modification could be enough to distinguish between and old backup and the
>> current project, at least when there are few projects). Any other ideas ?
>>
>
> I maintain that the former only makes sense if we force project names to be
> == folder names (in which case we'd need to add that kind of options/dialogs
> all over the place). If we keep the current status though (project names !=
> folder names), then I agree that we need distinguishers in the list. I was
> thinking adding the author name and version, because it should be relatively
> uncommon for the same guy to create two projects with the same name, so
> showing author should eliminate the larger class of duplicate names that
> result from external imports.
>

+1 for me :)

For people who actually want to maintain two projects of the same name and
> both by me, version number I think is a sensible way for me to distinguish
> between the two (so instead of doing the somewhat uncool thing of having to
> name my projects coolplasmoid_1 and coolplasmoid_2, I could have
> coolplasmoid v1 and coolplasmoid v2. Nicer IMO). Slipups that create same
> plasmoid name and same author and same version can STILL occur, but that
> would hopefully be rare, and again the fix is trivial - the user just needs
> to load either one and check his code, then flip to the metadata editor and
> key in an appropriate version number (or change the name if that's what he
> prefers).
>
> Any other ideas? :)
>
> Yours is good and, since its not a vital component in our app, we could
change its behaviour later, referring on users feedbacks :)


> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Tue, 26 Jan 2010 22:01:00 +0800
> Subject: Re: Subject: Re: Subject: Re: On Plasmate's recent project list
>
>> Er, there will be a folder name conflict only if there is a project name
>> conflict, right? Only If I already have a project "abcd" and I import which
>> already contains "abcd", there will be a conflict. Correct me if i'm wrong.
>>
>
> No, there is no hard link between the two (project and folder names), and
> they can be different. Plasmate's current state allows you to have two
> projects with the same name, but folder names obviously must be unique.
> Allowing duplicate names and hiding folder names has actually spared me a
> slew of other potentially sticky conflict situations.
>
> Correct, the project <---> folder naming convention is suggested, not
required ( even though I wouldn't break that :P ).
So,if we bump into a conflict situation, we rename one of the two folder,
good. Now, my question is: how the user will be able to distinguish the
"current" and "backup" version of his/her project ?
I mean, in the project list we can't show the directories name because they
must be hidden, so an appropriate way is to pick up the project name from
the "Name" field metadata.desktop file, and surprisingly this will be 99%
times the same, since previously there was a conflict, so most likely the
user will fill a bug report because he/she can't distingiush between the two
projects, and he/she is forced to look to the sources in order to find the
correct one.
So, what about showing the "Remove,overwrite,ignore" buttons, or adding more
informations in the project list (for example adding the date of last
modification could be enough to distinguish between and old backup and the
current project, at least when there are few projects). Any other ideas ?


> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: Subject: Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Tue, 26 Jan 2010 13:16:50 +0800
> Subject: Re: Subject: Re: On Plasmate's recent project list
>
>> By the way, we should also add a "Remove project" button or whatever
>> because, in order to test python/ruby/js plasmoid/dataengine/runner, I
>> created a lot of  projects that are no longer needed; so we need a button to
>> do some "spring-cleaning" IMO :)
>>
>
> Yeah I was planning to add that, that's why I was asking if all we needed
> to do to kill a project + git repo is to delete the whole folder :) You
> probably already know this, but in the meantime you could just kill all the
> stuff in ~/.kde4/share/apps/plasmate/ and kill the config files in
> ~/.kde4/share/config/plasmate* to start with a clean slate again :)
>
> Yep, that's why I need something more easy to accomplish that :)

> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
> From: Shantanu Tushar Jha 
>


> And there is even more, in my opinion. When the number of projects becomes
>> relevant, the user could forget how he/she properly named each of them, thus
>> it's easy to create a new project with a name already assigned. So a
>> conflict scenario is more plausible.
>> ( I'm wondering if could be cool to implement a bacukp support over
>> gitorious, when my backend will be available :)
>>
>
> Oh yes, then we have to have a conflict resolution method anyway.
>

Of course we have :) The coolness I was talking is about having version
controlled backup system over gitorious, so you can access it from every pc
with an internet connection, without worrying about in what
folder/pendrive/external drive you put it before formatting the pc.
One click, and you backup all your projects online; an other click ( + cool
anti-conflict method ), and you'll get them back :)

>
>> Either choice could mean losing contact with a lot of the user's previous
>>> work. Also not forgetting that folder names are not exposed to the user, so
>>> folder name conflicts are not visible to the user, and he will probably be
>>> quite bewildered if we suddenly pop up and say "hey you have a conflict!"
>>> when he sees none.
>>>
>>> IMO we should avoid force-overwrite if we can at all, and if Diego is
>>> right (he probably is :P ) then it's pretty trivial to just get PlasMate to
>>> do some under-the-hood renaming and circumvent all the possible problems.
>>>
>>
> Ok, then lets design some generic method for this. When someone gets an
> outline of a method, mail to the list and we can discuss. :)
>

What about performing a sort of sha1sum for each project file, and use it to
perform a check when restoring a backup ?
So, if we find two identical packages names with different hashes, we could
prompt a dialog with the name of the package with an "overwrite" checkbox
and a "details" button to give more infos about the projects. ( That's
reptty rough I know, so what about your opinion?)

Well, I'm going to take my DC examinations, bye >.<

>
>>> 
>>> Jason "moofang" Lim Yuen Hoe
>>> http://yuenhoe.co.cc/
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
> ___
> 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

Subject: Re: Subject: Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Tue, 26 Jan 2010 00:11:17 +0800
> Subject: Re: Subject: Re: On Plasmate's recent project list
>
> IMO, the import/export tarball feature will be used only for backup and
>> restore purposes. In that case, forcing an overwrite *will* make sense, and
>> that is what I originally meant. We aren't aiming for a per-project export
>> feature. Think of it as 'Backup All Projects' and 'Restore All Projects'. I
>> hope I'm able to explain what I originally meant.
>>
>> I understood what you originally meant, but why restrict it so? I don't
> personally think it's great to force overwrite and I don't think a conflict
> scenario is all too unlikely - 'Backup All Projects' means I'm saving all
> current my work and bringing it with me.
>

And there is even more, in my opinion. When the number of projects becomes
relevant, the user could forget how he/she properly named each of them, thus
it's easy to create a new project with a name already assigned. So a
conflict scenario is more plausible.
( I'm wondering if could be cool to implement a bacukp support over
gitorious, when my backend will be available :)

There is no guarantee that I won't create some projects and import a couple
> more in my new location before I decide to bring in my old work. You can say
> that the 'correct' way to backup all and restore all is to do the restore
> first thing, but users will do what they want - and then complain when they
> have a problem. And no matter how rare a conflict scenario is, forcing
> overwrite is serious business. We're talking about forcing the user to
> choose between losing whole existing projects, and not being able to import
> groups of projects.
>

I totally agree. We have to keep in mind that our target are
beginner/intermediate developers, thus we have to ease their development
cycle without forcing them on such drastic choices.
By the way, we should also add a "Remove project" button or whatever
because, in order to test python/ruby/js plasmoid/dataengine/runner, I
created a lot of  projects that are no longer needed; so we need a button to
do some "spring-cleaning" IMO :)


> Either choice could mean losing contact with a lot of the user's previous
> work. Also not forgetting that folder names are not exposed to the user, so
> folder name conflicts are not visible to the user, and he will probably be
> quite bewildered if we suddenly pop up and say "hey you have a conflict!"
> when he sees none.
>
> IMO we should avoid force-overwrite if we can at all, and if Diego is right
> (he probably is :P ) then it's pretty trivial to just get PlasMate to do
> some under-the-hood renaming and circumvent all the possible problems.
>
> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
>
> ___
> 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: Subject: Re: On Plasmate's recent project list (Yuen Hoe Lim)

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Mon, 25 Jan 2010 14:06:53 +0800
> Subject: Re: Subject: Re: On Plasmate's recent project list
> There is also another problem and it still can get sticky :) When importing
> a 'project group' tarball, what happens when there are project folders with
> the same name in the target drive? It doesn't make sense to force an
> overwrite, so we'll need to seamlessly rename the folders underneath (the
> user isn't aware of project folder names, so we can name them whatever we
> want as long as it avoids conflict). Now, renaming the folder will have
> implications for the git repository right...? Or am I just being
> overparanoid again :)
>

Don't worry, git doesn't complain if you rename the root folder :)
That's because git doesn't save a reference to the root project directory,
but it refers to the .git/ containing folder. This sounds pretty the same,
but referring the .git/ parent dir allows you to rename it as you wish,
without worrying about the name.


> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
>
> On Sun, Jan 24, 2010 at 9:58 PM, Shantanu Tushar Jha 
> wrote:
>
>> On 1/24/10, Yuen Hoe Lim  wrote:
>> >>
>> >> Uhm I dont get your concern; if you tar all the plasmate project
>> directory
>> >> for example, and then untar it, you also tar each git project history
>> >> (because every project has its own local git repo). Thus, when
>> untar-ing,
>> >> you'll get both your projetc files and git repo for free :)
>> >>
>> >
>> > Really? That's why I said I don't know much about git. So the git local
>> > repository is wholly contained in the folders themselves? That'll make
>> > things a lot simpler. Does that also mean that if I just delete the
>> project
>> > folder the git repository goes down with it? :)
>>
>> Yep, even I was wondering why you were saying that. The whole git repo
>> info, the packs etc are there in .git. So, AFAIK, just saving the
>> contents will do.
>> I can implement this "backup-n-restore" thing once you're done with
>> the "More Projects" option :)
>>
>> >
>> >
>> >> yes sir !
>> >>
>> >
>> > xD
>> >
>> > 
>> > Jason "moofang" Lim Yuen Hoe
>> > http://yuenhoe.co.cc/
>> >
>>
>>
>> --
>> Shantanu Tushar(UTC +0530)
>> http://www.shantanutushar.com
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 19, Issue 43

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Sun, 24 Jan 2010 19:28:56 +0530
> Subject: Re: Subject: Re: On Plasmate's recent project list
> On 1/24/10, Yuen Hoe Lim  wrote:
> >>
> >> Uhm I dont get your concern; if you tar all the plasmate project
> directory
> >> for example, and then untar it, you also tar each git project history
> >> (because every project has its own local git repo). Thus, when
> untar-ing,
> >> you'll get both your projetc files and git repo for free :)
> >>
> >
> > Really? That's why I said I don't know much about git. So the git local
> > repository is wholly contained in the folders themselves? That'll make
> > things a lot simpler. Does that also mean that if I just delete the
> project
> > folder the git repository goes down with it? :)
>
> Yep, even I was wondering why you were saying that. The whole git repo
> info, the packs etc are there in .git. So, AFAIK, just saving the
> contents will do.
>

Exactly :)
The only thing we have to take care is removing that hidded directory when
the deloper wants to upload the package to kdeapps.org ( when this feature
is implemented, of course =P )


> I can implement this "backup-n-restore" thing once you're done with
> the "More Projects" option :)
>
> >
> >
> >> yes sir !
> >>
> >
> > xD
> >
> > 
> > Jason "moofang" Lim Yuen Hoe
> > http://yuenhoe.co.cc/
> >
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Sun, 24 Jan 2010 00:40:33 +0800
> Subject: Re: On Plasmate's recent project list
>
> But, there should be an option by which the user
>> can 'save' all his/her projects to a file (an archive, maybe) so that
>> it can be used after a system reinstall,
>>
>
> Agree, but I'll think about that a little later - I suspect it's not so
> simple as it is not just a matter of files but also save points (ie the Git
> local repositories) that need to be cleanly migrated.


Uhm I dont get your concern; if you tar all the plasmate project directory
for example, and then untar it, you also tar each git project history
(because every project has its own local git repo). Thus, when untar-ing,
you'll get both your projetc files and git repo for free :)

I've no idea how to do that at the moment. I'm not even sure at the moment
> how to kill a project's git repository when it is being deleted. Need to
> look into that in some time (or insidiously arrow Diego to handle it :P ).
>

yes sir !

>
> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Fri, 22 Jan 2010 22:33:33 -0800
> Subject: Re: On Plasmate's recent project list
> On January 22, 2010, Yuen Hoe Lim wrote:
> > What do you guys think, does this sound like a sensible solution?
>
> 100% yes from me :)
>

/me agrees too

>
> perhaps instead of "other projects" maybe "older projects", "older
> projects"
> or maybe even just "More projects..."? "other" sounds a bit like they
> belong
> to a different category.
>


>
> but really, that's just a very, very minor nitpick. i completely agree with
> everything else you wrote.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
>
> ___
> 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: PlasMate ~ UI and other stuff

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel 
> Date: Sun, 18 Oct 2009 23:49:52 +0800
> Subject: PlasMate ~ UI and other stuff
> Hi,
>
> Haven't heard from you (plasmate) guys for awhile, guess you guys are busy
> :) Anyway, just like some input here. As per the quick discussion the other
> day, I recently had the editor component tree widget separated out into a
> new dock widget, so it no longer gets replaced by the katepart that gets
> loaded when you click a file. I've been toying around with the layout and
> dockwidget positionings since - and I can't help thinking that, with the
> addition of this new dockwidget, the whole UI has become awfully cluttered.
> This is about the best layout I can come up with atm:
>
> http://i302.photobucket.com/albums/nn91/yuenhoe/plasmateclutter.jpg
>
> I think the main problem now is that there are too many 'vertical'
> dockwidgets - the timeline, the sidebar, and now the editor tree. Vertical
> dockwidgets only fit naturally on the left/right dockareas, but having three
> of them there, plus the mainwidget in the center, really makes the thing
> so... layered, and crowded. Not to mention virtually unusable on a small
> screen.
>
> Some possible ways around it:
>
>- Make one (or more) of the 'vertical' dockwidgets 'horizontal' so that
>we can fit it snugly on the top dockarea instead. I think the editor tree
>has to stay vertical, so it'd have to be either the sidebar actions menu or
>the timeline widget, both of which I'm loathe to touch without first
>consulting with you all :) Those two are now QListWidget derivatives, and 
> it
>doesn't look like there's an easy way to 'horizontalize' them without
>rewriting quite abit of code.
>
> Yup, I'm currently working on it in order to replace QListWidget with a
more flexible QTableModel ( and the same for the Workflow sidebar );
currently I'm busy because I'm writing a presentation for the LinxDay, so be
patient =)
As regarding the directory tree dock widget, what about setting a
QTableWidget as PlasMate central widget and inserting it as first widget?
We could also insert a new tab for each file the user wants to edit, so we
can have multiple files editing for free :)


>- The old mockups:
>
>http://skitch.com/michaelrudolph/ba3j9/plasmate-editor2
>http://skitch.com/michaelrudolph/ba3cg/plasmate-editor-timeline
>
>suggested an interesting 'overlay' effect for the timeline - and also
>that the timeline be hidden all the time until a button at the bottom is
>clicked.
>
>
Yeah, I love this concept because describes perfectly how should work:
hidden when its not needed, and displayed with a fancy graphics when we need
to provide information/perform new actions ;)

>
>- I dunno... ideas?
>
> Also, it seems like alot of stuff with PlasMate is currently 'hanging'. The
> timeline seems to work nicely, but what's gonna happen with the missing
> publish widget and documentation widget? I've been spending my free time
> hacking away at the editor and previewer and there are certainly plenty more
> work needed with those two but I was just wondering about the larger view of
> the project, since no one seems to be paying much attention to it at the
> moment :)
>
> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Fri, 11 Sep 2009 09:53:37 +0530
> Subject: Re: Re: Plasmate previewer, again =P
>
>
>>- Green flag: package signed by both KDE and the developer ( =
>>completely trusted );
>>- Blue flag: package signed by KDE, but not by the developer;
>>- Yellow flag: package signed by the developer, but not by KDE;
>>- Red flag: package is not signed ( = install it at your own risk ).
>>
>> How is it known that a package is signed by KDE? Is there some existing
> mechanism or it has to be worked on?
>

This is a new feature, so we have to work on it, sooner or later :P

>
>
>>
>> * The editor works pretty good, I tried it and works perfectly.
>>
> Nice, I see that its now opening the dialog in the project's dir, sweet :)
>

Yes, its a tiny improvement I made some time ago =)
It should also load the project name in the title bar iirc, but when opening
the editor, it disappear ... I have to investigate also on this !

>
>
>> * The previewer is awesome, but its possible to test it with a "fake"
>> package and see if it load it correctly ?
>>
> Right now previewer/test can be used to view installed applets. We are
> unable to "execute" an applet currently.
>
>
>> Ok, i think that's all, now i want your opinion/ideas =)
>> Have a nice day,
>>
>> Cheers !!!
>>
>> --
>>> Aaron J. Seigo
>>> humru othro a kohnu se
>>> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>>>
>>> KDE core developer sponsored by Qt Development Frameworks
>>>
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 15, Issue 25

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Fri, 11 Sep 2009 10:56:09 +0800
> Subject: Re: Plasmate previewer, again =P
> >> * The previewer is awesome, but its possible to test it with a "fake"
> >> package and see if it load it correctly ?
>
> > can you try it on a real package loaded in plasmate?
>
> Back awhile I tried pointing it to some of my plasmoid source code before
> and it worked, so assuming the timeline/git mechanism stores the packages in
> identical format it should just be a matter of passing in the path as
> argument :P
>

Good :)

>
> I'm a little lost with the other stuff though. Will do some ploughing
> through the current code this weekend :)
>
> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Thu, 10 Sep 2009 16:53:48 -0600
> Subject: Re: Plasmate previewer, again =P
> On September 10, 2009, Diego Casella ([Po]lentino) wrote:
> > > -- Messaggio inoltrato --
> > > From: "Aaron J. Seigo" 
> > > To: plasma-devel@kde.org
> > > Date: Thu, 10 Sep 2009 11:23:26 -0600
> > > Subject: Re: Plasmate previewer, again =P
> > >
> > > On September 10, 2009, Shantanu Tushar Jha wrote:
> > > > As we could not have the meeting on that time as Diego and Aaron were
> > >
> > > busy
> > >
> > > > at Tokamak,
> > >
> > > actually, we showed up on irc at the stated time and waited around ...
> :/
> >
> > yup ...
> >
> > > > It'll be nice to have some status update. Diego what things are
> > > > remaining to be implemented, i.e. which were planned but are not yet
> > > > implemented?
> > >
> > > we put together a really short list of "things to do next"; Diego, do
> you
> > > have
> > > that still?
> > >
> > > Of course !
> >
> > Since up to now the code structure is not as good as we want, the basic
> >  idea was to build a core class that handles our UI stuff, a
> ProjectManager
> >  class to create/load projects and keep track of its files, and other
> >  stuffs. As soon as everything works well, first we have to provide a
> >  secure way to upload the package ( the idea is to use QCA to sign the
> >  package ); second, that is, when an user download a package from our
> >  server, we have to alert the user with one of these signals ( iirc :P ):
> >
> >- Green flag: package signed by both KDE and the developer ( =
> >  completely trusted );
> >- Blue flag: package signed by KDE, but not by the developer;
> >- Yellow flag: package signed by the developer, but not by KDE;
> >- Red flag: package is not signed ( = install it at your own risk ).
> >
> > Also, some improvements on Plasma::PackageMetadata should be done ( if
> >  there are no issues with BC ):
> >
> >- Made method's name more coherent ( for example, if the entry we want
> >  to retrieve is "X-KDE-PluginInfo-Name" and the getter is called
> >  "PluginName()", why the setter is named "setName()" ? it should be
> >  "setPluginName()" ! )
>
> it is setPluginName().
>

Ops, you are right ! These days my brain is completely screwed up ...
The funny part is I used both of them in my code =P

>
> >  ; - extend the API in order to handle more entries (
> >  for example, up to now there is no API call to write the
> >  "X-Plasma-MainScript" entry, so i'm forced to use QFile to open the
> >  metadata.desktop file, and then append that string manually O_o )
>
> that probably belongs either in a subclass or via a
> PackageMetaData::setProperty(const QString &key, const QVariant &value)
> method
> since X-Plasma-MainScript is specific to plasmoid scripting and not to
> packages in general.
>
> > * At present, the TimeLine is broken again because the regexp fix made @
> > Tokamak was wrong: in fact the regexp "^commit [0-9a-ef]+$" always
> returns
> > the entire list of commits! I've adjusted it with
>
> hm. try setMinimal(true) on the QRegExp object.
>
> as for the sha1 hash, try:
>
> "^commit ([0-9a-f])+$"
>
> and then you can use QRegExp::cap(int), and use a while loop like the one
> in
> the QRegExp docu:
>
> while ((pos = rx.indexIn(str, pos)) != -1) {
> list << rx.cap(1);
> pos += rx.matchedLength();
>  }
>
> and cut up the list as you go.
>

Ok, I'll try it as soon as possible =)

>
> > * The editor works pretty good, I tried it and works perfectly.
>
> great :)
>
> > * The previewer is awesome, but its possible to test it with a "fake"
> > package and see if it load it correctly ?
>
> can you try it on a real package loaded in plasmate?
>

I'll have a look !

>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Thu, 10 Sep 2009 11:23:26 -0600
> Subject: Re: Plasmate previewer, again =P
> On September 10, 2009, Shantanu Tushar Jha wrote:
> > As we could not have the meeting on that time as Diego and Aaron were
> busy
> > at Tokamak,
>
> actually, we showed up on irc at the stated time and waited around ... :/
>
yup ...

>
> > It'll be nice to have some status update. Diego what things are
> > remaining to be implemented, i.e. which were planned but are not yet
> > implemented?
>
> we put together a really short list of "things to do next"; Diego, do you
> have
> that still?
>
> Of course !
Since up to now the code structure is not as good as we want, the basic idea
was to build a core class that handles our UI stuff, a ProjectManager class
to create/load projects and keep track of its files, and other stuffs.
As soon as everything works well, first we have to provide a secure way to
upload the package ( the idea is to use QCA to sign the package ); second,
that is, when an user download a package from our server, we have to alert
the user with one of these signals ( iirc :P ):

   - Green flag: package signed by both KDE and the developer ( = completely
   trusted );
   - Blue flag: package signed by KDE, but not by the developer;
   - Yellow flag: package signed by the developer, but not by KDE;
   - Red flag: package is not signed ( = install it at your own risk ).

Also, some improvements on Plasma::PackageMetadata should be done ( if there
are no issues with BC ):

   - Made method's name more coherent ( for example, if the entry we want to
   retrieve is "X-KDE-PluginInfo-Name" and the getter is called "PluginName()",
   why the setter is named "setName()" ? it should be "setPluginName()" ! );
   - extend the API in order to handle more entries ( for example, up to now
   there is no API call to write the "X-Plasma-MainScript" entry, so i'm forced
   to use QFile to open the metadata.desktop file, and then append that string
   manually O_o )

Actual state of PlasMate:
* At present, the TimeLine is broken again because the regexp fix made @
Tokamak was wrong: in fact the regexp "^commit [0-9a-ef]+$" always returns
the entire list of commits! I've adjusted it with "commit\\s[0-9a-f]{40}\\n"
and now works perfectly but, since splitting a string with a regexp also
removes the matched expressions, the sha1hash is not present in the
resulting list so I'm waiting to write an elegant solution before committing
:P
* The editor works pretty good, I tried it and works perfectly.
* The previewer is awesome, but its possible to test it with a "fake"
package and see if it load it correctly ?

Ok, i think that's all, now i want your opinion/ideas =)
Have a nice day,

Cheers !!!

--
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel