Re: Plasma Media Center and state machines

[Shantanu Tushar Jha]

On 4/4/10, Aaron J. Seigo  wrote:
> On April 1, 2010, Shantanu Tushar Jha wrote:
>> Hi Christophe, now I'm able to understand most of what you've
>> proposed. Somehow, I don't like having just one state machine for the
>> whole MC, the main reason being that we're going to support
>> extensibility through custom plugins, so the MC can no longer assume
>> that it knows exactly how many states are present.
>
> there are two different things here:
>
> * how the states are created / registered
>
> * how the states interact with the user interface
>
> they are separate issues: regardless of how they interact with the UI, they
> can be created statically using a hard coded list of "new ThisState; new
> ThatState;" type calls, by iterating over a static set of enums or
> completely
> through plugins.
>
> the key here is that each top level mode (e.g. each item that appears on the
> home page) will be a top level state.
>
> that means that "the MC can no longer assume it knows exactly how many
> states
> are present" is completely and wholy irrelevant to the topic of "should we
> use
> a state machine".
>
> where "we want plugins" does matter is when it comes to "how do they
> interact
> with the user interface".
>
> let's try to lay down some axioms so we can discuss this fruifully:
>
> * there will be a shared home page
>
> * there will be a set of shared / common components available, such as the
> playlist, media browser and control bar
>
> * there will be some set of shared / common sub-components, such as a global
> pause button in the control bar
>
> * a state may also need to provide custom sub-components
>
> * a state may also want to provide a custom component for the main viewing
> area (e.g. a full screen plasmoid for weather, or a special browsing widget)
>
> if we can agree on those points, then we can ask: how can plugins work?
>
> well, it becomes evident that we should provide a way to define which common
> components and sub-components are useful in a given context from a state.
>
> we also need to allow states to register custom sub-components and provide a
> "main viewing area" component as well. (additional components that live on
> screen edges, augment the home page, etc. can be something we think about
> later once we have something releasable in hand today).
>

Exactly. Right now the Media Browser supports writing custom plugins.
So, if we extend that so that the whole Media Center supports plugin,
I think we can have a great system.
As you said, the plugin can specify what media to show, what player to
use, what controls it supports etc.
So, it will be like we'll have plugins and load them using Traders, right?

Right now, I'm fixing up the media player's playlist problem, will put
the patch on reviewboard when done.
Chris, regarding the Files browser existing right now, Aaron and Marco
said that to make it better visible on all devices, we can make it
show 3 columns at once (so to make the icons resizable, and later
maybe allow the user to zoom in/out), I tried but there is a small
problem somewhere, so I'd like if you can help with this. Is it fine?
If yes, I'll reply back with the patch :)

Cheers,

> a state should be able to enumerate child states as well. this will allow
> the
> home page entries to list all the things you can do, for instance, with
> "Photos" (browse, slideshow, add, whatever) if we so wish (see how the PS3,
> XBox 360 or moovida displays sub-menus on main entries)
>
> a state will need to be able to interact with the shared components as well,
> e.g. add an entry to the playlist.
>
> so this means we need to define some concrete APIs for playlist interaction,
> media browser population (both of categories and entries).
>
> note that all of the above is true regardless of whether we use a state
> machine to drive the whole thing or not.
>
> what the state machine gets us is a way to do the above in a modular fashion
> without writing all of the state machine boilerplate ourselves. if we really
> want (and if it is more undertandable for everyone involved) we could just
> as
> easily write the plugins in a more "traditional" fashion. we'll still end up
> with a state machine for all intents and purposes because the modes are
> mutually exclusive and full screen.
>
> the only exception to all of this is the playing of individual media. that
> is
> yet another topic, however. the above is all about the navigation and
> control
> UI which must work together seemlessly (visually and interation wise). how a
> mode (plugin or not) provides media playing is another matter (and
> personally
> i'm leaning towards providing a shared mechanism for that which is in PMC
> itself, so a state / plugin can just say "start playing this video" or
> "start
> playing this set of images"), just as the media browser should provide.
>
> --
> 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 

Re: Saving size of PopupApplet

[Rob Hasselbaum]

On Sat, Apr 3, 2010 at 9:52 PM, Aaron J. Seigo  wrote:
> On April 3, 2010, Rob Hasselbaum wrote:
>> Hi all. How can I coax Plasma into saving the size of a PopupApplet
>> after a user has changed it? This happens automatically when the
>> applet is placed on the desktop, but not when it's iconified on a
>> panel. Thanks!
>
> this seems to be working in trunk. can you provide a more detailed how-to-
> reproduce? thanks.

I add my widget to a panel, pop it up, resize it by dragging a corner,
hide it again, then restart Plasma (kquitapp plasma-desktop or
logout/login). When the desktop comes back up and I click on the panel
icon again for the widget, it's back to its original size. Happens in
KDE 4.3 and 4.4.2.

Must be something I'm doing in my code, but I don't know what.
When/how is the size saved?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Saving size of PopupApplet

[Aaron J. Seigo]

On April 3, 2010, Rob Hasselbaum wrote:
> Hi all. How can I coax Plasma into saving the size of a PopupApplet
> after a user has changed it? This happens automatically when the
> applet is placed on the desktop, but not when it's iconified on a
> panel. Thanks!

this seems to be working in trunk. can you provide a more detailed how-to-
reproduce? 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

Re: Review Request: [Quicklaunch] Refactoring, layout fixes and a drag & drop marker.

[Lukas Appelhans]

Am Freitag 02 April 2010 20:49:48 schrieben Sie:
> You wrote:
> > > > Why two layouts
> > > 
> > > I'm currently using the outer linear layout because I need a spacer
> > > (stretch) that pushes the icons to the top (for horizontal
> > > panel/desktop) or to the left (in vertical panels) if there is more
> > > space available than needed.
> > 
> > Uhm well I'm worried...
> 
> So am I. The current behavior relies too much on the interaction of the two
> layouts and the size hints provided by the IconWidgets and is therefor too
> hard to grasp by just looking at the code.
> 
> > The icons are not center-aligned?
> 
> They are not currently, but that would be easy to change.
> 
> Please note that we are talking about horizontal alignment in horizontal
> panels / vertical alignment in vertical panels. The icon alignment forced
> by the spacer will only have an effect when the applet is given more than
> it's preferred width (horizontal panel) or height (vertical panels /
> desktop).
> 
> For this case it felt more natural to me to have the icons left (or top)
> aligned rather than have them centered. If this behavior is not desired,
> changing it would be extremely easy.
Mmh... I don't know what the others think about this, but for me centered was 
more natural... opinions from the list? :)

And I noticed that multiple row support is gone at the moment it seems :/

All in all it looks very nice... I need to think about the icon-size-
configurations still... :/

Thanks,

Lukas
> 
> So long,
> Ingomar

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

Re: Saving size of PopupApplet

[Aaron J. Seigo]

On April 3, 2010, Rob Hasselbaum wrote:
> Hi all. How can I coax Plasma into saving the size of a PopupApplet
> after a user has changed it?

you don't; this is up to Plasma::PopupApplet. that it doesn't do this properly 
is a bug. i'll look into 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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Saving size of PopupApplet

[Rob Hasselbaum]

Hi all. How can I coax Plasma into saving the size of a PopupApplet
after a user has changed it? This happens automatically when the
applet is placed on the desktop, but not when it's iconified on a
panel. Thanks!

-Rob

FWIW- This is KDE 4.3.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Plasma::DialogManager

[Chani Armitage]

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

Ship it!



/trunk/KDE/kdelibs/plasma/applet.h


hmmm.
the screensaver could probably do with something like this... but... all it 
has are config dialogs and popupapplets (and popups look just fine except when 
they show up in the wrong position).

I can't think of a non-config dialog that would need it, apart from kio's 
evil modal popups - can we actually catch those?

most widgets are really quite good about doing everything on the scene. :)


- Chani


On 2010-04-03 19:09:42, Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3474/
> ---
> 
> (Updated 2010-04-03 19:09:42)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> this is the DialogManager class, as discussed before on irc with aaron. will 
> let plasma-netbook and plasma mobile show the config uis in a bit fancier way
> the base class happily does exactly nothing, actual implementations will be 
> only in shells.
> there are still some doubts, expressed by the various todo/fixme :)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1110066 
>   /trunk/KDE/kdelibs/plasma/abstractdialogmanager.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/abstractdialogmanager.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/applet.h 1110066 
>   /trunk/KDE/kdelibs/plasma/applet.cpp 1110066 
>   /trunk/KDE/kdelibs/plasma/corona.h 1110066 
>   /trunk/KDE/kdelibs/plasma/corona.cpp 1110066 
> 
> Diff: http://reviewboard.kde.org/r/3474/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco
> 
>

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

Re: Review Request: Plasma::DialogManager

[Marco Martin]

> On 2010-04-03 19:35:12, Aaron Seigo wrote:
> >

and then i'm still thinking in the future  qgraphicswidget ones should be 
supported, but if we use signals we can think about it only when and if it will 
be the case


- Marco


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


On 2010-04-03 19:09:42, Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3474/
> ---
> 
> (Updated 2010-04-03 19:09:42)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> this is the DialogManager class, as discussed before on irc with aaron. will 
> let plasma-netbook and plasma mobile show the config uis in a bit fancier way
> the base class happily does exactly nothing, actual implementations will be 
> only in shells.
> there are still some doubts, expressed by the various todo/fixme :)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1110066 
>   /trunk/KDE/kdelibs/plasma/abstractdialogmanager.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/abstractdialogmanager.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/applet.h 1110066 
>   /trunk/KDE/kdelibs/plasma/applet.cpp 1110066 
>   /trunk/KDE/kdelibs/plasma/corona.h 1110066 
>   /trunk/KDE/kdelibs/plasma/corona.cpp 1110066 
> 
> Diff: http://reviewboard.kde.org/r/3474/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco
> 
>

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

Re: Review Request: Plasma::DialogManager

[Marco Martin]

> On 2010-04-03 19:35:12, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/abstractdialogmanager.h, line 53
> > 
> >
> > my concern with using virtual methods for this is that we only get one 
> > release in which to add more virtuals to it. and i half-expect that this 
> > class easily gain more methods.
> > 
> > what if instead of virtual methods, they were just "normal" methods 
> > which emitted corresponding signals? then the shell would be responsible 
> > for creating, registering with Corona and connecting the signals of the 
> > DialogManager.
> > 
> > then it's future proof: we just add more public methods and more 
> > signals.
> > 
> > thoughts?

yes, seems a good idea


> On 2010-04-03 19:35:12, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/abstractdialogmanager.h, line 42
> > 
> >
> > it also makes it nice for memory management, and we may want to take a 
> > signals approach to this anyways?

yep, what i tought


> On 2010-04-03 19:35:12, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.h, line 811
> > 
> >
> > this could actually help a number of types of dialog showing, e.g. to 
> > prevent modal dialogs in plasma-desktop.
> > 
> > i wonder if instead of showConfigurationInterface(QWidget *widget) it 
> > should be showDialog(QWidget *widget, Plasma::DialogType type) where 
> > DialogType would be things like ConfigurationDialog, ... uhm. i can't 
> > actually think of another example atm.
> > 
> > perhaps that is just over-engineering it then. :)

i can kinda see we wanting things like the applet config dialog, usually pretty 
big anyways mostly full screen at least in some shells, while other dialogs 
should probably have a different look.

so i can see we maybe want at least two, can't think about good names now, but 
something like
showDialog (if we go signals showDialogRequested i think)
and
showFullScreenDialogRequested (FullScreen is bad, suffests a particular 
implementation should be something more generic)
but perhaps i'm overengineering even more, but i'm thinking, if we want to add 
a new public class, at least be worth it eheh :p


> On 2010-04-03 19:35:12, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/corona.cpp, line 271
> > 
> >
> > as this gets passed in from the outside world, i think it might be a 
> > good idea to keep a QWeakPointer to it.

yep.


- Marco


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


On 2010-04-03 19:09:42, Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3474/
> ---
> 
> (Updated 2010-04-03 19:09:42)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> this is the DialogManager class, as discussed before on irc with aaron. will 
> let plasma-netbook and plasma mobile show the config uis in a bit fancier way
> the base class happily does exactly nothing, actual implementations will be 
> only in shells.
> there are still some doubts, expressed by the various todo/fixme :)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1110066 
>   /trunk/KDE/kdelibs/plasma/abstractdialogmanager.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/abstractdialogmanager.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/applet.h 1110066 
>   /trunk/KDE/kdelibs/plasma/applet.cpp 1110066 
>   /trunk/KDE/kdelibs/plasma/corona.h 1110066 
>   /trunk/KDE/kdelibs/plasma/corona.cpp 1110066 
> 
> Diff: http://reviewboard.kde.org/r/3474/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco
> 
>

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

Re: Review Request: Plasma::DialogManager

[Aaron Seigo]

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



/trunk/KDE/kdelibs/plasma/abstractdialogmanager.h


it also makes it nice for memory management, and we may want to take a 
signals approach to this anyways?



/trunk/KDE/kdelibs/plasma/abstractdialogmanager.h


my concern with using virtual methods for this is that we only get one 
release in which to add more virtuals to it. and i half-expect that this class 
easily gain more methods.

what if instead of virtual methods, they were just "normal" methods which 
emitted corresponding signals? then the shell would be responsible for 
creating, registering with Corona and connecting the signals of the 
DialogManager.

then it's future proof: we just add more public methods and more signals.

thoughts?



/trunk/KDE/kdelibs/plasma/applet.h


this could actually help a number of types of dialog showing, e.g. to 
prevent modal dialogs in plasma-desktop.

i wonder if instead of showConfigurationInterface(QWidget *widget) it 
should be showDialog(QWidget *widget, Plasma::DialogType type) where DialogType 
would be things like ConfigurationDialog, ... uhm. i can't actually think of 
another example atm.

perhaps that is just over-engineering it then. :)



/trunk/KDE/kdelibs/plasma/corona.cpp


as this gets passed in from the outside world, i think it might be a good 
idea to keep a QWeakPointer to it.


- Aaron


On 2010-04-03 19:09:42, Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3474/
> ---
> 
> (Updated 2010-04-03 19:09:42)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> this is the DialogManager class, as discussed before on irc with aaron. will 
> let plasma-netbook and plasma mobile show the config uis in a bit fancier way
> the base class happily does exactly nothing, actual implementations will be 
> only in shells.
> there are still some doubts, expressed by the various todo/fixme :)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1110066 
>   /trunk/KDE/kdelibs/plasma/abstractdialogmanager.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/abstractdialogmanager.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/applet.h 1110066 
>   /trunk/KDE/kdelibs/plasma/applet.cpp 1110066 
>   /trunk/KDE/kdelibs/plasma/corona.h 1110066 
>   /trunk/KDE/kdelibs/plasma/corona.cpp 1110066 
> 
> Diff: http://reviewboard.kde.org/r/3474/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco
> 
>

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

Re: global menu bar for gsoc

[Marco Martin]

On Saturday 03 April 2010, Aaron J. Seigo wrote:
> On April 1, 2010, Ryan Rix wrote:
> > On Thu 1 April 2010 3:04:18 pm Marco Martin wrote:
> > > gnome has a dbus spec for
> > > that iirc
> > 
> > http://code.google.com/p/gnome2-globalmenu/wiki/GlobalMenuSpecification ?
> > afaict, that's the "official" globalmenu applet for GNOME.
> 
> i don't think that any specification that does not let the application draw
> the menu itself (the menu -bar- might be another matter) is not going to

i think it's important that the bar itself is -not- drawn by the app :)

> suffice. it has been hard enough to make the compromises necessary to make
> that happen with the much easier to tightly define system tray entries
> (KNotificationItem). i simply do not see that happening with applications.

is also true that compared to systray popup menus, menubar menus have custom 
widgets in it more rarely (can't recall seeing one but i won't be surprised 
there are quite some out there)

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

Re: Plasma Media Center and state machines

[Aaron J. Seigo]

On April 1, 2010, Shantanu Tushar Jha wrote:
> Hi Christophe, now I'm able to understand most of what you've
> proposed. Somehow, I don't like having just one state machine for the
> whole MC, the main reason being that we're going to support
> extensibility through custom plugins, so the MC can no longer assume
> that it knows exactly how many states are present.

there are two different things here:

* how the states are created / registered

* how the states interact with the user interface

they are separate issues: regardless of how they interact with the UI, they 
can be created statically using a hard coded list of "new ThisState; new 
ThatState;" type calls, by iterating over a static set of enums or completely 
through plugins.

the key here is that each top level mode (e.g. each item that appears on the 
home page) will be a top level state.

that means that "the MC can no longer assume it knows exactly how many states 
are present" is completely and wholy irrelevant to the topic of "should we use 
a state machine".

where "we want plugins" does matter is when it comes to "how do they interact 
with the user interface".

let's try to lay down some axioms so we can discuss this fruifully:

* there will be a shared home page

* there will be a set of shared / common components available, such as the 
playlist, media browser and control bar

* there will be some set of shared / common sub-components, such as a global 
pause button in the control bar

* a state may also need to provide custom sub-components

* a state may also want to provide a custom component for the main viewing 
area (e.g. a full screen plasmoid for weather, or a special browsing widget)

if we can agree on those points, then we can ask: how can plugins work?

well, it becomes evident that we should provide a way to define which common 
components and sub-components are useful in a given context from a state.

we also need to allow states to register custom sub-components and provide a 
"main viewing area" component as well. (additional components that live on 
screen edges, augment the home page, etc. can be something we think about 
later once we have something releasable in hand today).

a state should be able to enumerate child states as well. this will allow the 
home page entries to list all the things you can do, for instance, with 
"Photos" (browse, slideshow, add, whatever) if we so wish (see how the PS3, 
XBox 360 or moovida displays sub-menus on main entries)

a state will need to be able to interact with the shared components as well, 
e.g. add an entry to the playlist.

so this means we need to define some concrete APIs for playlist interaction, 
media browser population (both of categories and entries).

note that all of the above is true regardless of whether we use a state 
machine to drive the whole thing or not.

what the state machine gets us is a way to do the above in a modular fashion 
without writing all of the state machine boilerplate ourselves. if we really 
want (and if it is more undertandable for everyone involved) we could just as 
easily write the plugins in a more "traditional" fashion. we'll still end up 
with a state machine for all intents and purposes because the modes are 
mutually exclusive and full screen. 

the only exception to all of this is the playing of individual media. that is 
yet another topic, however. the above is all about the navigation and control 
UI which must work together seemlessly (visually and interation wise). how a 
mode (plugin or not) provides media playing is another matter (and personally 
i'm leaning towards providing a shared mechanism for that which is in PMC 
itself, so a state / plugin can just say "start playing this video" or "start 
playing this set of images"), just as the media browser should provide.

-- 
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: Review Request: Plasma::DialogManager

[Marco Martin]

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

(Updated 2010-04-03 19:09:42.668837)


Review request for Plasma.


Changes
---

DialogManager is now AbstractDialogManager since the base does nothing and has 
a pure virtual
showDialog() has a parameter with the owning applet pointer too, useful if the 
config dialog will be into the scene

it is now committed, but i'm leaving it there because it really needs an api 
review :D


Summary
---

this is the DialogManager class, as discussed before on irc with aaron. will 
let plasma-netbook and plasma mobile show the config uis in a bit fancier way
the base class happily does exactly nothing, actual implementations will be 
only in shells.
there are still some doubts, expressed by the various todo/fixme :)


Diffs (updated)
-

  /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1110066 
  /trunk/KDE/kdelibs/plasma/abstractdialogmanager.h PRE-CREATION 
  /trunk/KDE/kdelibs/plasma/abstractdialogmanager.cpp PRE-CREATION 
  /trunk/KDE/kdelibs/plasma/applet.h 1110066 
  /trunk/KDE/kdelibs/plasma/applet.cpp 1110066 
  /trunk/KDE/kdelibs/plasma/corona.h 1110066 
  /trunk/KDE/kdelibs/plasma/corona.cpp 1110066 

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


Testing
---


Thanks,

Marco

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

Re: GSoC : Multiscreen management

[Aaron J. Seigo]

On April 2, 2010, Detlev Casanova wrote:
> On Friday 02 April 2010 16:26:36 todd rme wrote:
> > On Thu, Apr 1, 2010 at 10:35 AM, Detlev Casanova
> > 
> >  wrote:
> > > So, my point is : there are problems.
> > > So far, what's the link with plasma you might ask. Well, I'd like the
> > > device notifier to react when a monitor is plugged in, showing the
> > > screen. 2 actions should be possible : Auto configure and manual
> > > configuration.
> > > 
> > >  -> Auto configure would try to find the best configuration depending
> > >  on
> > > 
> > > the screen capabilities (read resolutions).
> > > 
> > >  -> Manual configuration would open KRandr.
> > 
> > There is also an issue with plasma were activities that end up on a
> > monitor of the wrong size do not properly re-scale the widgets they
> > contain, which can result in widgets overlapping, having unpredictable
> > locations, extending off the screen, or having large blank areas.
> > Fixing this would probably be a worthwhile task.
> 
> Mmmh, I'm not using plasma activities but it's also to be checked, of
> course.

yes you are: it's that thing sitting on your desktop ;)

that said, i don't think it is in scope for this particular project.

-- 
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: GSoC : Multiscreen management

[Aaron J. Seigo]

On April 2, 2010, Detlev Casanova wrote:
> On Thursday 01 April 2010 20:15:40 Aaron J. Seigo wrote:
> > On April 1, 2010, Will Stephenson wrote:
> > > Aaron, do you think there's another GSoC project in completing Kephal?
> > 
> > yes, particularly on the storing / restoring of configurations and
> > integrating it with the existing UI elements (device notifier and
> > providing a more user- friendly alternative to the current kandr icon,
> > which is highly functional but also tricky to use)
> 
> Ok, Can I write a proposal for this then ?

imho: +1 on that.

> At first glance, it looks a bit light to make it as a GSoC but I can be
> wrong about that.

honestly, i think there will be enough to keep you busy for an entire GSoC. 
besides getting a plasmoid up to snuff there will be Kephal work that needs to 
be done. getting thoe workflows as elegant as possible can take as much time 
as we can throw at 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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Aaron J. Seigo]

On April 2, 2010, Will Stephenson wrote:
> Björn's description matches the xrandr model, but not the Kephal one. 
> Xrandr 1.3 has a single Screen numbered 0 but does not support additional
> Screens; xrandr Screens are distinct from the screennumber in X's
> $DISPLAY, and multiple Screen support is being discussed again for xrandr
> 1.4 according to one of our local Xorg guys.

while i have respect for the low level work that goes on in xrandr, i have no 
respect for their inability to create an API that is reliable and usable by 
application developers.

they have changed definitions and even behaviours so many times with no 
compatibility efforts or warning often enough, and the makes-sense-to-driver-
writers-but-is-incomprehensible-to-app-developers naming systems combines with 
that to lead me to concluce that there is no point or purpose in trying to 
track xrandr's terminology in our application facing API.

that, really, should be the role of Kephal: to provide a sensible naming 
scheme, an API that does not jump around every N months underneath us and 
which is easy to use. so we only should care about how xrandr (and other 
systems, should we care to :) mates up with Kephal, and to ensure that Kephal 
gets that right.
 
> Kephal has both multiple Outputs and multiple Screens in its model.  A

the definition of "Screen" is different between xrandr and Kephal. Kephal uses 
it to mean what app develpers think it means: it's a part of the whole output 
geometry that the user percieves as one screen.

everything else, for an application like plasma or kwin, is a detail.


so, where this gets tricky is when we want to build a tool which allows the 
user to configure how the xrandr outputs/screens are configured. Kephal needs 
to allow this to happen (perhaps even throught a separate "Controller" API?) 
and the tool needs to be written for mortal users not xrandr developers. the 
nice thing about making the configuration tool use Kephal is it will put the 
developer in the right mindset and not get sucked into xrandr's accurate but 
useless for creating usable interfaces model (which is what we have right 
now).

i'm not sure (have to look at it again) how much work will be needed in Kephal 
to get this going. i do know that there is already one such plasmoid out there 
that does screen configuration more elegantly than what we currently have, but 
i think it is also using xrandr directly atm?

-- 
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: global menu bar for gsoc

[Aaron J. Seigo]

On April 1, 2010, Ryan Rix wrote:
> On Thu 1 April 2010 3:04:18 pm Marco Martin wrote:
> > gnome has a dbus spec for
> > that iirc
> 
> http://code.google.com/p/gnome2-globalmenu/wiki/GlobalMenuSpecification ?
> afaict, that's the "official" globalmenu applet for GNOME.

i don't think that any specification that does not let the application draw 
the menu itself (the menu -bar- might be another matter) is not going to 
suffice. it has been hard enough to make the compromises necessary to make 
that happen with the much easier to tightly define system tray entries 
(KNotificationItem). i simply do not see that happening with applications.

-- 
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: Plasma Media Center and state machines

[Christophe Olinger]

Hey guys,

I think I am doing a stupid C++ mistake here: I get the follwing error:

mediacontainment.cpp:76: undefined reference to
'MediaCenter::MediaCenter::State::MediaCenterState(QState*)

The last line of this mail causes the error.


Here is mediacenterstate.h

#ifndef MEDIACENTERSTATE_H
#define MEDIACENTERSTATE_H

#include "libs/mediacenter/mediacenter.h"
#include "libs/mediacenter/mediacenter_export.h"

#include 
#include 

#include 

namespace MediaCenter {

enum State {
PictureMode,
MusicMode,
VideoMode,
Home
};

enum MainSubComponent {
JumpToVideoState,
JumpToMusicState,
JumpToPictureState,
JumpToHome,
ToggleControlBarAutohide,
ToggleInfoBarAutohide
};

class MEDIACENTER_EXPORT MediaCenterState : public QAbstractState
{
Q_OBJECT
public:
MediaCenterState(QState *parent = 0);
virtual ~MediaCenterState();

QGraphicsWidget *subComponent(MainSubComponent c);

protected:
void onExit(QEvent* event);
void onEntry(QEvent* event);

Plasma::IconWidget *m_jumpToHome;
};

} //namespace MediaCenter
#endif // MEDIACENTERSTATE_H

here is mediacenterstate.cpp

#include "mediacenterstate.h"

using namespace MediaCenter;

MediaCenterState::MediaCenterState (QState *parent) :
QAbstractState(parent),
m_jumpToHome(new Plasma::IconWidget())
{
}

MediaCenterState::~MediaCenterState()
{
}

void MediaCenterState::onExit(QEvent *event)
{
Q_UNUSED(event);
}

void MediaCenterState::onEntry(QEvent *event)
{
Q_UNUSED(event);
}

QGraphicsWidget
*MediaCenterState::subComponent(MediaCenter::MainSubComponent c)
{
if (c == MediaCenter::JumpToHome) {
m_jumpToHome->setIcon("User-Folder");
return m_jumpToHome;
}
}


here is mediacontainment.h

#ifndef MEDIACONTAINMENT_H
#define MEDIACONTAINMENT_H

#include "mediacenter/mediacenter.h"
#include "states/mediacenterstate.h"

#include 
#include 

class QAction;
class QPointF;
namespace MediaCenter {
class Browser;
class PlaybackControl;
class Playlist;
class Player;
class PictureState;
class VideoState;
}

class MediaLayout;

class MediaContainment : public Plasma::Containment
{
Q_OBJECT
public:
MediaContainment(QObject *parent, const QVariantList &args);
~MediaContainment();

QList contextualActions();

MediaCenter::State currentState();
void setCurrentState(MediaCenter::State);

QList currentMainComponents();
void addCurrentMainComponent(QGraphicsWidget*);

QList currentSubComponents();
void addCurrentSubComponent(QGraphicsWidget*);

protected:
void constraintsEvent(Plasma::Constraints constraints);

private slots:
void slotAppletAdded(Plasma::Applet *applet, const QPointF &pos);
void slotAppletRemoved(Plasma::Applet *applet);
void switchState(MediaCenter::State);

void switchToPictureState();
void switchToVideoState();
void switchToMusicState();

private:
MediaCenter::Browser *m_browser;
MediaCenter::PlaybackControl *m_control;
MediaCenter::Playlist *m_playlist;
MediaCenter::Player *m_player;

MediaCenter::State m_currentState;
MediaCenter::State m_previousState;

MediaCenter::MediaCenterState *m_mediaCenterState;
MediaCenter::VideoState *m_videoState;
MediaCenter::PictureState *m_pictureState;

QList m_currentMainComponents;
QList m_currentSubComponents;

bool m_musicIsPlaying;

MediaLayout *m_layout;

void addMediaApplet(Plasma::Applet *);

void initControls();
void connectControls(MediaCenter::State);

//we need these to give full control to the containment and avoid
cycling signals with the controller
//the controller's buttons are connected to these
void controlBarToPictureState();
void controlBarToVideoState();
void controlBarToMusicState();

void startStateMachine();
};


and here the relevant part of mediacontainment.cpp

#include "mediacontainment.h"
#include "medianotificationwidget.h"
#include "medialayout.h"
#include "mediatoolbox.h"

#include 
#include 
#include 
#include 

#include 
#include 

// Qt
#include 
#include 

// KDE
#include 
#include 
#include 

static const int BROWSER_WIDTH = 300;
static const int BROWSER_HEIGHT = 100;


K_EXPORT_PLASMA_APPLET(mediacontainment, MediaContainment)

MediaContainment::MediaContainment(QObject *parent, const QVariantList
&args) : Plasma::Containment(parent, args),
m_browser(0),
m_control(0),
m_playlist(0),
m_player(0),
m_pictureState(0),
m_currentState(MediaCenter::PictureMode),
m_previousState(MediaCenter::PictureMode),
m_musicIsPlaying(false),
m_layout(new MediaLayout(this))
{
setContainmentType(Plasma::Containment::CustomContainment);
setHasConfigurationInterface(true);
setAcceptHoverEvents(true);
setToolBox(new MediaToolBox(this));

connect (toolBox(), SIGNAL(toggled()), m_layout,
SLOT(toggleShowAllMediaApplets()));
}

MediaContainment::~MediaContainment()
{}

void MediaContainment::startStateMachine()
{
//Prepare StateMach

Re: Akademy talks, BOFs and workshops

[Lydia Pintscher]

On Sat, Apr 3, 2010 at 18:05, Marco Martin  wrote:
> On Saturday 03 April 2010, Lydia Pintscher wrote:
>> Hi folks :)
>>
>> we'd really love to have talk, BOF or workshop proposals from the
>> Plasma team for Akademy 2010.
>> You can find the call for papers here:
>> http://akademy.kde.org/call-for-papers.php
>> If you have questions please let us know at akademy-ta...@kde.org.
>>
>
> afaik there should be a plasma-mobile proposal

Yes. We want maar :D

> and I am plasnning to submit one with argument joint plasma-netbook+plasma-
> mediacenter (yes, /me bad, will submit the abstract asap)

Perfect.

> I am going for a 30 min one, but if someboby  working on the mediacenter can
> guarantee that he can do that part we can go for a 45 minutes one.
> (but this has to be decided N-O-W :p)

Keep in mind that 45 min talks need a paper submission as well.

> if somebody has a brilliant idea for a couple of lighting talks would be nice
> too.
> about a BOF: sounds nice, what do you guys think?


Cheers
Lydia

-- 
Lydia Pintscher
Amarok community manager
kde.org - amarok.kde.org - kubuntu.org
claimid.com/nightrose
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Akademy talks, BOFs and workshops

[Marco Martin]

On Saturday 03 April 2010, Lydia Pintscher wrote:
> Hi folks :)
> 
> we'd really love to have talk, BOF or workshop proposals from the
> Plasma team for Akademy 2010.
> You can find the call for papers here:
> http://akademy.kde.org/call-for-papers.php
> If you have questions please let us know at akademy-ta...@kde.org.
> 

afaik there should be a plasma-mobile proposal
and I am plasnning to submit one with argument joint plasma-netbook+plasma-
mediacenter (yes, /me bad, will submit the abstract asap)

I am going for a 30 min one, but if someboby  working on the mediacenter can 
guarantee that he can do that part we can go for a 45 minutes one.
(but this has to be decided N-O-W :p)

if somebody has a brilliant idea for a couple of lighting talks would be nice 
too.
about a BOF: sounds nice, what do you guys think?

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

Re: Calculator

[Matteo Agostinelli]

Yes, it is backwards compatible. The runner is executued when you put
a '=' at the beginning or at the end of the expression. The syntax for
common math operations is the same.

Cheers,
Matteo

On Sat, Apr 3, 2010 at 17:35, Richard Moore  wrote:
> On Thu, Apr 1, 2010 at 1:15 PM, Matteo Agostinelli
>  wrote:
>> I am currently working on improving the calculator runner, by adding an
>> optional dependency on libqalculate. If the library is found, the calculator
>> runner will be built against libqalculate and it will support "advanced"
>> operations (such as currency conversion, unit conversion, equation solving,
>> ...). Otherwise it will fall back to the existing code that uses QtScript. I
>> have tested the runner for some weeks now and it is stable.
>
> Is the qalculate syntax backwards compatible with the existing
> calculator runner syntax? If not then perhaps there should be two
> separate calculator runners.
>
> Cheers
>
> Rich.
> ___
> 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

Akademy talks, BOFs and workshops

[Lydia Pintscher]

Hi folks :)

we'd really love to have talk, BOF or workshop proposals from the
Plasma team for Akademy 2010.
You can find the call for papers here:
http://akademy.kde.org/call-for-papers.php
If you have questions please let us know at akademy-ta...@kde.org.


Cheers
Lydia

-- 
Lydia Pintscher
Amarok community manager
kde.org - amarok.kde.org - kubuntu.org
claimid.com/nightrose
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Calculator

[Richard Moore]

On Thu, Apr 1, 2010 at 1:15 PM, Matteo Agostinelli
 wrote:
> I am currently working on improving the calculator runner, by adding an
> optional dependency on libqalculate. If the library is found, the calculator
> runner will be built against libqalculate and it will support "advanced"
> operations (such as currency conversion, unit conversion, equation solving,
> ...). Otherwise it will fall back to the existing code that uses QtScript. I
> have tested the runner for some weeks now and it is stable.

Is the qalculate syntax backwards compatible with the existing
calculator runner syntax? If not then perhaps there should be two
separate calculator runners.

Cheers

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

Review Request: Add libqalculate support to calculator runner

[Matteo Agostinelli]

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

Review request for Plasma and Aaron Seigo.


Summary
---

Adds libqalculate to the default calculator runner. This enables advanced 
features such as unit/currency conversion, equation solving, symbolic 
manipulation and more.


Diffs
-

  /trunk/KDE/kdebase/workspace/cmake/modules/FindQalculate.cmake PRE-CREATION 
  /trunk/KDE/kdebase/workspace/plasma/generic/runners/calculator/CMakeLists.txt 
1109927 
  
/trunk/KDE/kdebase/workspace/plasma/generic/runners/calculator/calculatorrunner.h
 1109927 
  
/trunk/KDE/kdebase/workspace/plasma/generic/runners/calculator/calculatorrunner.cpp
 1109927 
  
/trunk/KDE/kdebase/workspace/plasma/generic/runners/calculator/qalculate_engine.h
 PRE-CREATION 
  
/trunk/KDE/kdebase/workspace/plasma/generic/runners/calculator/qalculate_engine.cpp
 PRE-CREATION 

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


Testing
---

Tested for several weeks without crashes


Thanks,

Matteo

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

Re: GSoC : Multiscreen management

[Aike J Sommer]

Am 02.04.2010 12:06, schrieb Will Stephenson:
> On Friday 02 April 2010 00:09:01 Björn Ruberg wrote:
>>> I have to check the difference between "Monitor", "Screen", "Display" and
>>> "Head" or are those actually the same thing ?
>>
>> "Monitor", "Display" and "Head" are probably the same - in Kephal they are
>> named as "Output". "Screen" ist actually something different. A screen can
>> have several outputs ordered left to right. If you have two monitors with
>> 1600x1200 pixels beside each other, you have a screen of 3200x1200 pixels
>> and two outputs in it. One at position 0x0 and one at 1600x0.
> 
> Aike, could you shed some light on this question?  Or Aaron, if you have the 
> overview of how Kephal works from mentoring Aike?
> 

Well.. A Screen is the logical area to which you can maximize a window
for example, or which has a panel at the bottom!
An output is the actual physical hardware / monitor...

So, for each connector that appears when calling xrandr there will be
one Output created, some enabled, some disabled... On my netbook those
are "VGA" and "LVDS", on my notebook something like "VGA", "LVDS" and
"TMDS-1" and on my HTPC "VGA" and "TV-1"!

How many Screens there are depends on your configuration:
- If you have only one enabled Output, you will have one Screen with the
same geometry
- If you have 2 or more overlapping Outputs, one Screen will be created
which spans all of those
- If you have multiple non-overlapping Outputs, one Screen will be
created per Output

One of the ideas was to be able to configure even non-overlapping
Outputs to be combined in one Screen, but that is not implemented...

Hope that helps!
:-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel