Re: Plasma Wallpapers in QML

[Aaron J. Seigo]

On Tuesday, October 2, 2012 20:28:29 Aleix Pol wrote:
> I just pushed the mouse events forwarding to the QGraphicsScene, not
> it's not only alive but it can be tickled ;).

... so who'll be the first one to find a cute picture of a baby and a funny 
giggling sound and make it into a wallpaper? ;)

cool stuff; can't wait to get this fully integrated into libplasma2 based 
shells! we'll want to make some noise about this feature in the 4.10 release 
announcements.

-- 
Aaron Seigo

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

Re: Review Request: add preview thumbnail at color wallpaper config dialog

[Aaron J. Seigo]

> On Oct. 2, 2012, 2:20 p.m., Aleix Pol Gonzalez wrote:
> > plasma/generic/wallpapers/color/itemsview.h, line 1
> > 
> >
> > Shouldn't the ItemsView be in some kind of common place?
> > 
> > I probably should be using it in Animated Wallpapers as well...
> 
> Marco Martin wrote:
> that idea struck me as well, but then the question is where.
> 
> places are libplasma, where i think is no-no (we should remove things 
> like that as much as we can for plasma2) or plasmagenericshell, but i don't 
> want wallpapers linking to it.
> 
> if those views were already qml it would be massively easier

i think it's a moot point right now. it is not optimal at all, but in future 
we'll just have QML wallpapers and then it's a non-issue: we can wrap this in a 
standard QML component and wallpapers that need further configuration can use 
it with a model.


- Aaron J.


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


On Oct. 2, 2012, 11:48 a.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106626/
> ---
> 
> (Updated Oct. 2, 2012, 11:48 a.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> This is part of my feature plan for 4.10.
> 
> Added preview thumbnail at color wallpaper configuration dialog for each 
> background mode, 
> and removed the background mode combobox. 
> 
> 
> Diffs
> -
> 
>   plasma/generic/wallpapers/color/CMakeLists.txt 71006ee 
>   plasma/generic/wallpapers/color/backgrounddelegate.h e69de29 
>   plasma/generic/wallpapers/color/backgrounddelegate.cpp e69de29 
>   plasma/generic/wallpapers/color/backgroundlistmodel.h e69de29 
>   plasma/generic/wallpapers/color/backgroundlistmodel.cpp e69de29 
>   plasma/generic/wallpapers/color/color.h a477aa9 
>   plasma/generic/wallpapers/color/color.cpp d696c2d 
>   plasma/generic/wallpapers/color/config.ui d5bf809 
>   plasma/generic/wallpapers/color/itemsview.h e69de29 
>   plasma/generic/wallpapers/color/itemsview.cpp e69de29 
> 
> Diff: http://git.reviewboard.kde.org/r/106626/diff/
> 
> 
> Testing
> ---
> 
> tested against master, worked fine.
> 
> 
> Screenshots
> ---
> 
> new config dialog
>   http://git.reviewboard.kde.org/r/106626/s/740/
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

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

Re: Display Configuration KCM design review

[Aaron J. Seigo]

On Tuesday, October 2, 2012 14:29:24 Dan Vrátil wrote:
> I'm now working on new KCM.

code
--
where is the code currently? i find it is often a lot easier to comment (and
help out) when i can build and try the code directly


duality in interaction
--
my first thought is: why are there two areas for interaction?

all the informaton is currently shown on the screens in the preview area, and
i have to interact with the preview area to move or rotate a screen ...

... but if i want to change other information i see there, then i have to go
to the bottom area (after noticing that they are connected :), find the
matching information and then change it there.

why can't i just change which is the primary monitor by pressing on the star
(or whatever it eneds up being) in the preview area?

why not be able to change the resolution and refresh by pressing on the
information in the monitor itself?

having some interaction in one area and some in another feels scattered. i find
my eyes (and mouse) going back and forth a lot. that some things are able to
be configured in both the preview and the details below demonstrates some
additional inconsistencies.

perhaps the nicest thing about having the previews where configuration happens
is that one does not need to "translate" between the representation (the
preview on screen) of the real thing (the actual screen) and a further
abstraction (the collection of widgets at the bottom). it's one layer of
mental re-direction less.

layout finesse
--

i'll echo the suggestion to put a little bit of space between the monitors.
yes, the screens are "connected" in the "real" world in that the graphics they
show are connected (though in the "real" "real" world, there is always some
separation, if only by the bezel). however, visually in the settings it
doesn't look ellegant but like someone forgot a margin somewhere :) nobody
will end up confused or balk a the lack of literal pixel truth if there is a
nice little margin between the screens. if anything, it is likely to help
people see that they are separate things more easily, useful when the screens
are otherwise identical.

i do prefer the two rotation arrows over the one rotation icon as seen in
http://i.minus.com/j0jCsZ3DaQQPO.jpg .. it's fewer clicks to get what i want
and very clear what will happen.

it would be nice to find a prettier way to show the bottom of the monitor than
dark line (which isn't obvious at all at first to me?) ... probably will
require an artist's intervention ;)

the on/off checkbox is perhaps one of the few perfect times to use the toggle
switch QML Component on the desktop as it is rather literall "on" or "off" :)


thanks for working on this :)

--
Aaron J. Seigo

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

Re: plasma2 and ToolTipManager

[Aaron J. Seigo]

On Tuesday, October 2, 2012 12:38:11 Martin Gräßlin wrote:
> should at least try to make that possible and not kill that before we
> even start with going to Wayland, can we?

yes, i agree.

my concern is that we may be tempted to answer too many questions with "put it
in the window manager" in spite of the down sides of that.

and yes, i think we can do all of these things at once: inrease security,
present an improved user experience, not substantially regress on what already
works[1], retain a well-designed system (or even: improve the design of our
systems)

[1] in the case of screenshots, wayland will require some changes no matter we
do; so on day 0, i fully expect regressions there, and likely elsewhere.
that's ok. it's intentional choices that carry unecessary / regretable
regressions that should be avoided

--
Aaron Seigo

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

Re: plasma2 and ToolTipManager

[Aaron J. Seigo]

On Monday, October 1, 2012 19:36:34 Fredrik Höglund wrote:
> Plasma can then texture directly from the pixmap if it uses OpenGL,

right.

i don't devel on win/mac and haven't for years now, but fwiu, the exact
mechanism to do this is platform specific. still, it works rather well on all
platforms so doesn't paint us into a platform-specific corner in case we care
about that.

most importantly, it means no application level IPC, no unecessary copying of
data around, and all the rendering can be kept within the processes where it
makes the most sense.

--
Aaron J. Seigo

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

Re: Getting notifications in the plasma widget

[Aaron J. Seigo]

On Tuesday, October 2, 2012 00:06:50 Robin Atwood wrote:
> OK, I think I know what the problem is. The app is for monitoring system
> services and must run as root to be able to do anything. There are two
> knotifys running, one as my user and one as root.

bingo.

> I guess there is no way to
> connect the root knotify to the user widget? 

they are on different dbus sessions, so no .. 

> But I can run the app as my
> user and do the service stops/starts with sudo. 

which is probably what you want to do anyways. running GUIs as root is scary 
and recomended against.

-- 
Aaron J. Seigo

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

maintainership of plasma-desktop

[Aaron J. Seigo]

Hello all ...

I am looking for someone(s) to take over maintainership of the assets in:

kde-workspace/plasma/desktop

that inclues the plasma-desktop binary, the relevant containments, etc. This 
also includes the libplasmagenericshell library (desktop scripting, etc).

If you are interested, please let me know.

-- 
Aaron J. Seigo

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

Re: Getting notifications in the plasma widget

[Aaron J. Seigo]

On Monday, October 1, 2012 22:35:41 Robin Atwood wrote:
> Oh yes, it´s not that old!

ok :) so that leave very few reasons for this not working.

if other applications using the same kdelibs are showing their popup
notifications in the notification plasmoid, then the knotify4 daemon sees the
dbus service and is using it. as soon as that happens, ALL popup notifications
go through the dbus service and NO KPassivePopup windows are created.

(see kde-runtime/knotify/notifybypopup.cpp)

so ... what could be going wrong?

my best gues is that your app is not be connecting to knotify4 (or to a
different knotify4 than the one running in your desktop session; that could
plausibly happen if running the application as a different user)

it may be worth killing knotify4 and starting it again from a konsole and
seeing what sort of debug output you get when the notifications from your app
trigger. or .. seeing if there is more than one knotify process running in the
first place :)

--
Aaron J. Seigo

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

Re: plasma2 and ToolTipManager

[Aaron J. Seigo]

On Monday, October 1, 2012 15:15:23 Martin Gräßlin wrote:
> Am 01.10.2012 14:46, schrieb Aaron J. Seigo:
> > the GL texture would be generated and updated by the window manager
> > but used b
> > other applications (e.g.the desktop shell). how to address such
> > textures is
> > platform specific (windows, mac, x11, etc) but it is a broadly
> > available
> > functionality and one _we_ only need to care about on a very select #
> > of
> > platforms.
>
> sharing OpenGL textures for the windows is an absolute no-go from the
> security point of view in Wayland. See also
> http://community.kde.org/KWin/Wayland_Development with some notes about
> security I did during XDC.

btw, the untenability of this "restrict all the accesses by pushing it all
into the windowmanager because of security" can perhaps be most easily seen
with this entry on that page:

"Screenshots need to be restricted to KWin. Solution: move KSnapshot to KWin,
remove D-Bus interface for Screenshots"

and gimp? and krita? and .. (IT help desks with existing software solutions
are going to love this, too)

try explaining to the owner of a laptop that they can no longer take
screenshots except through the Desktop Environment Approved and Mandated user
interface. "It's for your own good, security after all..."

to which i (as such an owner) would tell that software, as politely as
possible, to fuck off because this is my system which i own and will use as i
wish. it (and by extension its authors) does not get to mandate to me
application choice simply because i choose your window manager. it does not
get to override my choices on my hardware because it thinks it knows better
than me about my needs. it doesn't. (and conversely, i don't know better about
your needs than you do.)

the enemy of security is perfection. perfect security is the antithesis of
ease of use and so people route around it. usually by picking things that are
less secure but do what they want.

as an owner of my hardware, however, i would be very happy to confirm that a
given application may have access to a given service. i do this all the time
on my mobile devices. i do it on my desktop for access to my wallet (though
that is woefully insecure as an all-or-nothing access mechanism which the
application can actually route around if it tries; this is an implementation
defect, however, not an attribute of the concept).

instead of trying to control UI choices and make the WM the dictator of how i
can use my own property, i'd prefer to see a mechanism by which applications
may be specifically blessed to have reasonable access to such services as
"taking a snapshot".

(i'll completely ignore anything about hardware related hacks as that is not
really relevant within the scope of trying to ensure the graphics system
doesn't leak privacy, but keeping the possibility of hardware hacks in mind
relieves us of the fantasy that this security can ever be utterly
impregnable.)

--
Aaron J. Seigo

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

Re: plasma2 and ToolTipManager

[Aaron J. Seigo]

On Monday, October 1, 2012 15:15:23 Martin Gräßlin wrote:
> Am 01.10.2012 14:46, schrieb Aaron J. Seigo:
> > the GL texture would be generated and updated by the window manager
> > but used b
> > other applications (e.g.the desktop shell). how to address such
> > textures is
> > platform specific (windows, mac, x11, etc) but it is a broadly
> > available
> > functionality and one _we_ only need to care about on a very select #
> > of
> > platforms.
>
> sharing OpenGL textures for the windows is an absolute no-go from the
> security point of view in Wayland

in wayland, isn't the desktop shell also a secured (as in: controlled and
identified) process?

--
Aaron J. Seigo

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

Re: plasma2 and ToolTipManager

[Aaron J. Seigo]

On Monday, October 1, 2012 13:56:53 Marco Martin wrote:
> On Sunday 30 September 2012, Martin Gräßlin wrote:
> > On Wednesday 26 September 2012 16:16:23 Sebastian Kügler wrote:
> > > On Wednesday, September 26, 2012 15:35:26 Marco Martin wrote:
> > > > comments?
> > >
> > > Sounds straightforward to do. Do we need WM support for the placement?
> >
> > I would like to try moving the complete tooltip into the WM. I'm very
> > unhappy with what we currently have and I consider especially the window
> > thumbnails to be more like a cludge.
>
> it may make sense...
> the problems i may think about it are mostly data communication-related.

and consistency. do we do every single tooltip (of the plasma style) for every
app that uses such a thing in the window manager?

if "yes" then these applications become unusable without kwin (or a compatible
WM, which does not exist). (right now, we only lose window thumbnails, not all
tooltips.)

if "no" then we have to coordinate between tooltips shown by the WM and ones
shown by applications, which will be exceptionally non-trivial to get right.

* we know we want the pixmap generated by the WM.
* we know we don't want the pixmap transmitted over application based IPC.

& imho the UI presentation needs to stay in-application for reasons of
coordination, flexibility and simplicity. ... which leads us to "how can we get
the necessary pixmaps that the WM renders to the UI while keeping the UI in
the application?" sharing GL textures seems like a reasonable answer.

the GL texture would be generated and updated by the window manager but used b
other applications (e.g.the desktop shell). how to address such textures is
platform specific (windows, mac, x11, etc) but it is a broadly available
functionality and one _we_ only need to care about on a very select # of
platforms.

what could make it an unreasonable answer is if:

* the overhead is high
* we can not coordinate updates to the texture between the WM and the
application (leading to, e.g., thumbnails not updated in a live fashion)

just as i am hesitant to move window management issues outside the window
manager (e.g. client side window decos), i am hesitant to move application
rendering into the window manager.

--
Aaron J. Seigo

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

Re: Review Request: create only the required files during the load of the project

[Aaron J. Seigo]

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

Ship it!


i think this change is necessary and can go in. however, the model MUST then be 
fixed to at least show all non-created files described in the package as well 
otherwise things like creating new images or populating the default settings 
will be hard/impossible for the user and making that easy is plasmate's #1 
purpose in life. :)

- Aaron J. Seigo


On Oct. 1, 2012, 8:46 a.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106665/
> ---
> 
> (Updated Oct. 1, 2012, 8:46 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Until now plasmate was creating all the Package::files() on the load of the 
> project,
> with this patch it will create only the Package::requiredFiles().
> 
> Also we **have** to s/Package::files()/Package::requiredFiles(), because 
> right now
> 1. the Plasma themes are broken:
> plasmate creates all the listing files of the theme package with QFile,so 
> QSvgRenderer can't
> open them, and if the user adds one more foo.svgz file, he will end up with 2 
> foo.svg files and
> even if he deletes the corrupted one it will be recreated on the next load
> 
> 2. plasmate forces the user to have a main.xml and a default-configrc, also 
> even if the user deletes
> those files, on the reload they will be recreated.
> 
> I haven't s/Package::dirs()/Package::RequiredDirs() because we don't have any 
> ui element in order to
> inform the user that the foo dir(for examples the images or the animations 
> dir) exists, so he will have to
> figure it out and create it manually and even if he does the dirs won't 
> appear in the plasmate's package model.
> 
> 
> The only drawback of this patch is that the user won't see anymore the 
> description of the file but he will see their names.
> 
> I believe that for the moment we should add this patch and to fix the 
> PackageModel issues after the beta.
> 
> 
> P.S.: I replaced some deprecated methods.
> 
> 
> Diffs
> -
> 
>   packagemodel.cpp d9cc35e 
> 
> Diff: http://git.reviewboard.kde.org/r/106665/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

Re: Getting notifications in the plasma widget

[Aaron J. Seigo]

On Sunday, September 30, 2012 21:33:56 Robin Atwood wrote:
> On Sunday 30 Sep 2012, Aaron J. Seigo wrote:
> > On Saturday, September 29, 2012 19:49:25 Robin Atwood wrote:
> > > > I have just realised that an application I wrote years ago has its
> > > > KNotification message popups appearing on the desktop and not in the
> > > > plasma
> > > > widget in the panel. I simply call
> > > > 
> > > >   KNotification::event( eventid, title );
> > > > 
> > > > and specify "Show a message in a popup" in the configuration dialog.
> > > > What
> > 
> > that sould be enough. do other applications with notification show up in
> > the plasmoid?
> 
> Yes, all the others are OK. My application does not have its own panel
> widget though, I want to use the general one.

this app written years ago .. it is using the Qt4 / KDE Platform 4 libraries, 
correct?

-- 
Aaron J. Seigo

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

Re: KDE not usable in LTSP fat mode, too I/O traffic

[Aaron J. Seigo]

On Sunday, September 30, 2012 17:00:41 marco Mailing List @ ammdomus wrote:
> The problem I'm facing is also present in normal stand alone PC, but
> there has less impact since there is fewer I/O (something to
> investigate) and, more important, the I/O is faster.

why there is less I/O in a stand-alone would be nice to know. this includes 
which components are causing the writing.

one thing that jumps to mind is, as you noted, is the cache files. i wonder if 
those are either being re-written, or if they are being unecessary transfered 
due to internals in KSharedDataCache (KSDC), etc. if there is some interaction 
between KSDC and the mechanisms used to run the fat clients, it could be that 
the contents of the caches are being transfered unecessarily for each and 
every process that accesses them. that's a shot in the dark, though, and i'd 
be a bit surprised if that was the cause.

really i don't know what we can do without more data as to what components are 
accessing which files where on disk. strace may be able to help here.

it would also be interesting to know if stopping plasma-desktop with `kquitapp 
plasma-desktop` and then restarting it in a running session reproduces the 
problems, or if it is a one-time thing. there's also krunner, kwin, kded and a 
few other processes that may be culprits if plasma-desktop only ends up being 
part of the issue (or not really involved at all).

-- 
Aaron J. Seigo

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

Re: Review Request: Use Product instead of description for device names

[Aaron J. Seigo]

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

Ship it!


very sensible and nice improvement. as long as the product name is always sth 
sensible and there (e.g. never an empty string) then this looks good; if the 
product can be an empty string, then it should fall back to the hotplug text 
(perhaps in the DataEngine itself)

- Aaron J. Seigo


On Sept. 29, 2012, 8:21 p.m., Alex Fiestas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106637/
> ---
> 
> (Updated Sept. 29, 2012, 8:21 p.m.)
> 
> 
> Review request for Plasma and Viranch Mehta.
> 
> 
> Description
> ---
> 
> The description is useful for when the device is not hotpluggable/removeable, 
> for example to show:
> 96.3 GiB Hard Drive
> 15.1 GiB Hard Drive
> 
> instead of two identical labels.
> 
> But when it comes to removable/hotpluggable we want to show the Product to be 
> able to show:
> 
> Nokia N9
> Nexus 7
> 
> Instead of 
> Portable Media Player
> Portable Media Player
> 
> The difference can be shown also in the attached screenshots.
> 
> 
> Diffs
> -
> 
>   
> plasma/generic/applets/devicenotifier/package/contents/ui/devicenotifier.qml 
> b23df45 
> 
> Diff: http://git.reviewboard.kde.org/r/106637/diff/
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> before
>   http://git.reviewboard.kde.org/r/106637/s/743/
> after
>   http://git.reviewboard.kde.org/r/106637/s/744/
> 
> 
> Thanks,
> 
> Alex Fiestas
> 
>

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

Re: Getting notifications in the plasma widget

[Aaron J. Seigo]

On Saturday, September 29, 2012 19:49:25 Robin Atwood wrote:
> > I have just realised that an application I wrote years ago has its
> > KNotification message popups appearing on the desktop and not in the
> > plasma
> > widget in the panel. I simply call
> > 
> >   KNotification::event( eventid, title );
> > 
> > and specify "Show a message in a popup" in the configuration dialog. What

that sould be enough. do other applications with notification show up in the 
plasmoid?

-- 
Aaron J. Seigo

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

Re: Tasker in 4.10?

[Aaron J. Seigo]

On Saturday, September 29, 2012 11:11:32 Shaun Reich wrote:
> do you happen to know of an example of something that isn't? never
> figured that one out, making it non-modal. iirc you can't use
> kmessagebox or else it's automatically modal.

you can use KMessageBox::createMessageBox and then set the dialog to not be 
modal. it is a bit of a clumsy API like that. you can also probably send in a 
parent windowId of 0 and then pass WindowModal in the options flags.

-- 
Aaron J. Seigo

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

Re: Review Request: Make it possible to use QtCreator QML profiler and debugger with KDE Applications

[Aaron J. Seigo]

On Friday, September 28, 2012 15:30:05 Aurélien Gâteau wrote:
> > On Sept. 26, 2012, 9:16 a.m., Aurélien Gâteau wrote:
> > > I pushed the plasmoidviewer changed in and filed a Qt review as well:
> > > https://codereview.qt-project.org/#change,35683>
> > Aaron J. Seigo wrote:
> > this change was pushed into the KDE/4.9 branch of kdelibs, but not
> > master. not sure it should be in the 4.9 branch at all, but at least
> > it is now in master as well.
> >
> > this is one of the reasons i love having the branch name in the
> > command prompt as i'm then always aware of what branch i'm actually
> > in.
> I pushed it to KDE/4.9 on purpose, because I thought the policy was that
> kdelibs master branch was frozen and not to be used. Has this changed?

ah, right .. my bad. sorry, having been away from libs dev for ~2 months, i
ended up reseting my libs to master after doing some frameworks hacking at
randa. meh. sorry for the noise :(

--
Aaron J. Seigo

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

Re: Tasker in 4.10?

[Aaron J. Seigo]

On Friday, September 28, 2012 20:48:58 Shaun Reich wrote:
> speaking of modal dialogs; aren't there still a few in plasma still?
> last i checked there was one for pretty common cases like removing a
> panel, and since it blocks plasma, i had trouble with it when it
> wasn't in focus.

yes, the panel dialog is still modal. that should be fixed. it isn't a massive 
problem though as clicking anywhere on plasma (including a panel) will bring 
it up, but it still is non-optimal and a violation of the no-modals.

patches welcome :)

-- 
Aaron J. Seigo

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

Re: Tasker in 4.10?

[Aaron J. Seigo]

On Friday, September 28, 2012 22:11:37 Michał 'rysiek'  Woźniak wrote:
> I sent a link to a repo, here it is again:
> https://redmine.hackerspace.pl/projects/private-tasker/repository

you'll want to move this to git.kde.org ... you can get a devel account on
identity.kde.org

--
Aaron J. Seigo

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

Re: Tasker in 4.10?

[Aaron J. Seigo]

On Friday, September 28, 2012 19:59:45 Michał 'rysiek'  Woźniak wrote:
> Is it possible to get Tasker in 4.10? What is the procedure?

it has to be:

* maintained
* work in all form factors (planar/desktop, vertical, horizontal)
* follow the typical Plasma principles of resizability, no blocking UI (modal
dialogs are evil, e.g.) etc
* stable

preferably:

* usable/useful not only with a mouse but with touch too
* the UI done in QML
* bonus points for integration with other KDE technologies

btw, where is currently developed (git repo address e.g.)?

> What are the deadlines?

deadlines are described in the KDE SC release schedule.  in fact, if you
google for "KDE SC 4.10 release schedule" (you can replace the release # with
other numbers too of course :) it's the first hit that comes back.

--
Aaron Seigo

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

Re: Including Stackfolder to 4.10

[Aaron J. Seigo]

On Friday, September 28, 2012 14:08:41 Ural Mullabaev wrote:
> > On Friday, September 28, 2012 12:19:10 Ural Mullabaev wrote:
> > > Config dialog was specially removed to simplify applet.
> > > To add applet you should drag folder e.g. from Dolphin to panel and
> > > choose
> > > StackFolder item in the popup menu. Added applet will associate with
> > > dragged folder.
> > 
> > this means it does not work when added from the add widgets interface.
> > which
> > means 1 of 2 things needs to happen:
> > 
> > * it gets a config dialog that lets you set the current directory
> > * it is set to hidden so it does not show in Add Widgets
> 
> It's strange behavior. When you using "Add widgets" dialog it has to set
> home directory. 

setting to the home directory would be good enough imho. i do see that it gets 
the "Home" icon now when that happens ... but it doesn't list anything in the 
dialog that pops up. :/

-- 
Aaron J. Seigo

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

Re: Including Stackfolder to 4.10

[Aaron J. Seigo]

On Friday, September 28, 2012 12:19:10 Ural Mullabaev wrote:
> Config dialog was specially removed to simplify applet.
> To add applet you should drag folder e.g. from Dolphin to panel and choose
> StackFolder item in the popup menu. Added applet will associate with
> dragged folder.

this means it does not work when added from the add widgets interface. which 
means 1 of 2 things needs to happen:

* it gets a config dialog that lets you set the current directory
* it is set to hidden so it does not show in Add Widgets

-- 
Aaron J. Seigo

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

Re: Review Request: Make it possible to use QtCreator QML profiler and debugger with KDE Applications

[Aaron J. Seigo]

> On Sept. 26, 2012, 9:16 a.m., Aurélien Gâteau wrote:
> > I pushed the plasmoidviewer changed in and filed a Qt review as well: 
> > https://codereview.qt-project.org/#change,35683

this change was pushed into the KDE/4.9 branch of kdelibs, but not master. not 
sure it should be in the 4.9 branch at all, but at least it is now in master as 
well.

this is one of the reasons i love having the branch name in the command prompt 
as i'm then always aware of what branch i'm actually in.


- Aaron J.


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


On Sept. 21, 2012, 3:29 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106527/
> ---
> 
> (Updated Sept. 21, 2012, 3:29 p.m.)
> 
> 
> Review request for kdelibs, Plasma, Marco Martin, and David Faure.
> 
> 
> Description
> ---
> 
> QtCreator comes with a handy QML profiler and debugger, but it relies on 
> tricky command-line parsing and #define setup. This patch makes it possible 
> to use it with KDE applications. It does two things:
> 
> 1. Add the "qmljsdebugger" option to the list of qt command-line options, 
> with a hack to ensure it is passed unaltered (as in, using '=' to separate 
> argument from value, rather than ' ')
> 2. Add a static method to KDeclarative to enable the debugger when the 
> "qmljsdebugger" command-line option is defined.
> 
> I am not entirely sure about #2 as it means linking to libkdeclarative even 
> if it is not used (do we expect all KDE apps to use KDeclarative?). The 
> alternative to using it is to tell developers who want to use the QML 
> debugger to add one of the following snippets in their code.
> 
> Either:
> 
> // Add this snippet in one of your .cpp file.
> // Me sure it appears before any QDeclarative include.
> #define QT_DECLARATIVE_DEBUG
> #include 
> 
> or:
> 
> // Add this include to the file containing your main() function
> #include 
> 
> // Add this to your main() function.
> // Make sure it is called before instantiating a QDeclarativeView.
> QDeclarativeDebuggingEnabler enabler;
> 
> 
> Diffs
> -
> 
>   experimental/libkdeclarative/kdeclarative.h 5e404c7 
>   experimental/libkdeclarative/kdeclarative.cpp 34383c0 
>   kdecore/kernel/kcmdlineargs.cpp 2da636f 
> 
> Diff: http://git.reviewboard.kde.org/r/106527/diff/
> 
> 
> Testing
> ---
> 
> - Patch plasmoidviewer to call KDeclarative::setupQmlJsDebugger()
> - Run it through qmlprofiler:
> 
> qmlprofiler plasmoidviewer org.kde.example.widgetgallery
> 
> - Press r (in the terminal) while it is running to start recording
> - Press q to stop recording => application should stop and a file 
> named "plasmoidviewer_$date_$time.qtd" should be created
> - Open Qt Creator, click the "Analyze" sidebar button
> - Right click in the profiler area (bottom right) and select "Load QML Trace"
> - Select the "plasmoidviewer_$date_$time.qtd" file
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

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

Re: Including Stackfolder to 4.10

[Aaron J. Seigo]

On Friday, September 28, 2012 10:18:29 Ural Mullabaev wrote:
> What I have to do to include StackFolder in KDE 4.10? I should to post to
> the reviewbord or can you look in the repository, because it isn't small
> part of code?

Looking into the repository is fine.

Is the QML version complete? I just installed it and while it shows an icon 
(which is too small when put in a small panel; see attachment) clicking on it 
just brings up an empty dialog and there is no config dialog.

-- 
Aaron Seigo
<>

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

Re: development settings panel in Active Settings

[Aaron J. Seigo]

On Thursday, September 27, 2012 16:38:20 Aaron J. Seigo wrote:
> * allows for ordering of panels so that, e.g., the devel panel appears last.
> (actually, i haven't  pushed that yet, but will be doing so..)

ok, this is in now. modules are ordered by their categories. the category 
sorting is controlled by entries in active-settingsrc like:

[SettingsCategoryWeights]
Date and Time=10
Language=10

if a category isn't listed, those items drop to the bottom. within categories 
of equal weight, sorting is alphabetical by name.

i also found and fixed a memory leak and cleaned up some API issues (e.g. 
lacking const on getters) in the in plasma-mobile/components/settings. 

while doing so, it occured to me that it may make more sense to have that 
component in plasma-mobile/applications/settings/ .. unless the idea is that 
other applications could use that component as well? if the component is 
really only for active-settings, then this seems like a hidden location. if it 
is meant for other apps to use then it needs some generalizations, particulaly 
in the KServiceTypeTrader query. i suppose Sebas can enlighten us on this 
issue. :)

-- 
Aaron J. Seigo

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

development settings panel in Active Settings

[Aaron J. Seigo]

hi ..

i've pushed my develsettings branch into plasma-mobile. it adds a new panel 
which does three things:

* shows/hides the menu entry for the terminal application (useful so it is not 
shown by default in Launch)
* enables/disables ssh access
* makes the pointer visible / invisible

one thing it does not yet do that i would like it to is to install konsole if 
there is no terminal application on the device. this probably means some 
PackageKit hacking.

the code that does all the bits of magic is not the most amazingly gorgeous as 
it deals with ugly bits of X11 and fd.o desktop standards .. but it seems to 
work :)

testing and feedback welcome.

the branch also:

* removes the text "Active Settings" from the startup page of the application 
as that seems superfluous and more visual noise
* allows for ordering of panels so that, e.g., the devel panel appears last. 
(actually, i haven't  pushed that yet, but will be doing so..)

i'd like to merge this into master after PA3 is released (unless someone feels 
there is a really good reason to put it into PA3 and can do some more QA 
testing)

-- 
Aaron J. Seigo

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

Re: libplasma2 and Wallpaper

[Aaron J. Seigo]

On Thursday, September 27, 2012 22:02:02 Reza Shah wrote:
> And maybe some developer of certain apps like that qml wallpaper and
> want to offer that ability to their user.

while technically possible, i hope no app developers actually do this (with 
perhaps some exceptions such as, mybe, games) as it is unlikely to add to 
the user experience anything other than more things to configure and more 
things to go wrong and look inconsistent.

-- 
Aaron J. Seigo

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

Re: libplasma2 and Wallpaper

[Aaron J. Seigo]

On Thursday, September 27, 2012 20:36:39 Reza Shah wrote:
> If it's not overkill, may be the new design can be used inside other apps.
> Something like set dolphin background, set kopete chat background.

what is the benefit of having wallpapers in random application windows?

-- 
Aaron J. Seigo

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

Re: plasma2 and ToolTipManager

[Aaron J. Seigo]

On Wednesday, September 26, 2012 17:10:49 Marco Martin wrote:
> On Wed, Sep 26, 2012 at 4:16 PM, Sebastian Kügler  wrote:
> > On Wednesday, September 26, 2012 15:35:26 Marco Martin wrote:
> >> comments?
> >
> > Sounds straightforward to do. Do we need WM support for the placement?
>
> only thing it would need an access to the good old corona
> popupPosition function, so that function would probably have to be
> moved somewhere else (same thing applies for Dialog)
> to implement such function is basically needed access to screen
> coordinates and screen geometry

right, and this is shell specific as to what that even means. (remember that we
have a KPart too :)

we'll need some mechanism to get to this information, and wherever we place it
it will need to be available to things such as tooltips and dialogs ... as
long as we talk about Plasma code only, i'm not sure what better place than
the Corona related to the Containment/Applet in question there is.

but the real complication comes from the fact that we'd like to make the
tooltips available to other applications ... ones which won't have a Corona.
so this information will still need to be provided by the shell/application
itself .. we may end up with an interface which applications can reimplement
or just instantiate to get the default behaviour, which Corona itself
subclasses or aggregates so it can be customized in behaviour.

question is how to make this visible to components that need it, and that
sounds a lot like needing a singleton ... if we can get away with an
application global singleton it's simple. but the case where there may be
multiple Coronas in the same app (think about the KPart :) that might not be
true.

fun .. :)

--
Aaron J. Seigo

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

Re: Move kde-workspace/plasma/generic/tools into plasmate

[Aaron J. Seigo]

On Wednesday, September 26, 2012 14:14:16 Giorgos Tsiapaliokas wrote:
> What do you think?

sounds like a good idea :) it moves all our "SDK" type stuff into one place and 
out of the end-user oriented kde-workspace. +1 from me.

-- 
Aaron J. Seigo

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

Re: plasma: QGraphicsView-ectomy

[Aaron J. Seigo]

On Wednesday, September 26, 2012 15:57:10 Marco Martin wrote:
> * ToolTipManager: should just be a qml component (see other thread)
> * Dialog: should just be a component as well

+1 to both, though i'm a little anxious to see how cleanly ToolTipManager will 
work ...

> * PopupApplet: i don't think it should be a differerent class from
> Applet, still don't have a clear idea how to do that, but the only
> difference could be in desktop file

i actually really like the idea that all aplets are popup applets. merge the 
logic and API and forget about the difference. if you don't want the 
iconification, then you don't set a minimum size and/or don't hit that minimum 
size. thoughts?

> * View: not sure what to do with this (also, there is still come code
> commented in applet and containment that was using views) I'm open to
> ideas on what the semantics of this should be. i would like not having
> views at all in libplasma tough

i would not be surprised if we end up with at least a View interface that gets 
implemented. Wallpaper usage, for instance; that could be moved to Containment 
if we limit ourselves "forever" to 1-view-per-containment

in Applet the main use case seems to be for screenRect and mapTo/FromView. we 
should see where that is actually used and then decide how to handle that.

-- 
Aaron Seigo

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

Re: Review Request: Move plasma tools into plasmate

[Aaron J. Seigo]

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

Ship it!


as this generates large diffs, affects multiple repositories simultaneously and 
is just really moving things around, i don't think this is very well suited to 
reviewboard. it's better discussed on the mailing list and then just done. in 
any case, i'm in favour of this. but before it is pushed to master, the current 
code of plasmate needs to be moved into a sub-directory as well. this will 
result in plasmate/plasmate/, and perhaps we should think about renaming the 
repository to plasma-sdk-tools or somesuch at a future point. in any case, once 
plasmate sources are in a subdirectory as well, please push.

- Aaron J. Seigo


On Sept. 25, 2012, 11:51 p.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106580/
> ---
> 
> (Updated Sept. 25, 2012, 11:51 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch moves the kde-workspace/plasma/generic/tools into plasmate/ .
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 9ff1f27 
>   engineexplorer/CMakeLists.txt PRE-CREATION 
>   engineexplorer/Messages.sh PRE-CREATION 
>   engineexplorer/engineexplorer.h PRE-CREATION 
>   engineexplorer/engineexplorer.cpp PRE-CREATION 
>   engineexplorer/engineexplorer.ui PRE-CREATION 
>   engineexplorer/ktreeviewsearchline.h PRE-CREATION 
>   engineexplorer/ktreeviewsearchline.cpp PRE-CREATION 
>   engineexplorer/main.cpp PRE-CREATION 
>   engineexplorer/serviceviewer.h PRE-CREATION 
>   engineexplorer/serviceviewer.cpp PRE-CREATION 
>   engineexplorer/serviceviewer.ui PRE-CREATION 
>   engineexplorer/titlecombobox.h PRE-CREATION 
>   plasmoidviewer/CMakeLists.txt PRE-CREATION 
>   plasmoidviewer/Messages.sh PRE-CREATION 
>   plasmoidviewer/fullview.h PRE-CREATION 
>   plasmoidviewer/fullview.cpp PRE-CREATION 
>   plasmoidviewer/main.cpp PRE-CREATION 
>   remote-widgets-browser/CMakeLists.txt PRE-CREATION 
>   remote-widgets-browser/Messages.sh PRE-CREATION 
>   remote-widgets-browser/main.cpp PRE-CREATION 
>   remote-widgets-browser/main.qml PRE-CREATION 
>   remote-widgets-browser/plasmafiltermodel.h PRE-CREATION 
>   remote-widgets-browser/plasmafiltermodel.cpp PRE-CREATION 
>   remote-widgets-browser/resources.qrc PRE-CREATION 
>   wallpaperviewer/CMakeLists.txt PRE-CREATION 
>   wallpaperviewer/Messages.sh PRE-CREATION 
>   wallpaperviewer/main.cpp PRE-CREATION 
>   wallpaperviewer/wallpaperwidget.h PRE-CREATION 
>   wallpaperviewer/wallpaperwidget.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/106580/diff/
> 
> 
> Testing
> ---
> 
> How I made the move,
> 
> I used the git subtree command, like
> 
> cd foo/kde-workspace
> git subtree split -P plasma/generic/tools -b someBranch
> cd foo/plasmate
> git fetch foo/kde-workspace someBranch
> git checkout master 
> git merge FETCH_HEAD
> vi CMakeLists.txt(this is the conflict)
> git add CMakeLists.txt
> git commit(I haven't done it yet)
> git push origin master(I have done it yet)
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

Re: Behavior on systray icon clicking

[Aaron J. Seigo]

On Tuesday, September 25, 2012 13:33:11 Kåre Särs wrote:
> I have spacial memory

this is a basic part of human cognitive abilities. even toddlers who can only
crawl exhibit it :)

> I don't use
> grouping of windows because I can use the taskbar-items to select all my
> individual windows with just _one_ mouse click.

that's orthogonal.

regardless, having systray entries merged with their taskbar entries means you
could get to ALL the applications functions from the same place. (and yes,
still with "just one click" to the window). therefore this idea shouldn't
worry you.

i doubt we will make it optional in the default plasmoid unless someone can
demonstrate a compelling reason why the feature could be detrimental to usage.

(the tasks widget already has more than enough options as it is .. we don't
need to add more and more. eventually we would have a complete mess.)

> For those that don't have spacial memory

which is ~0% of the current human population

--
Aaron J. Seigo

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

Re: Behavior on systray icon clicking

[Aaron J. Seigo]

On Tuesday, September 25, 2012 11:42:40 Ivan Čukić wrote:
> This replicates the behaviour of tasks applet - think of click-to-minimise.

.. and why appliation tray icons really ought to be merged with the tasks
applet.

i'm hoping that we will achieve this with the QML version once it is done. it
should be a lot easier to accomplish than with the existing C++ stuff.

--
Aaron J. Seigo

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

Re: Behavior on systray icon clicking

[Aaron J. Seigo]

On Tuesday, September 25, 2012 11:35:07 Martin Klapetek wrote:
> While I agree in
> principle, pretty much none of the apps behave this way 

the reason for this is symmetry: people tend to expect that an element that 
performs an action will perform a similar action when pressed again. 
unfortunately for our beautiful designs, symmetry is often most naturally 
experienced as inversion when the action is a binary operation -> if i press 
something and it has an effect, it is reasonable to expect that if it is still 
pressable that pressing it again will produce a related effect. in a binary 
system, that translates to "pressing toggles the state". people often don't 
see it as "showing a window" (or whatever) but toggling a state. voila.

> So here's the question - should we follow the rest of the workspace and be
> consistent or should we do it "properly" - clicking plasmoid it opens,
> closing is done with close button (possibly followed by fixing other apps)?

how does the current system negatively impact people using the system?
how would changing to the proposed behaviour improve the experience?

(hopefully those questions can be rhetorical :)

-- 
Aaron J. Seigo

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

Re: libplasma2 and Wallpaper

[Aaron J. Seigo]

On Tuesday, September 25, 2012 11:31:06 Marco Martin wrote:
> On Tue, Sep 25, 2012 at 9:49 AM, Aaron J. Seigo  wrote:
> > we may even want to put support for these new plugins into the QML helper
> > for Containment so that shells don't need to do anything at all. this is
> > the design we have right now in libplasma for Wallpapers and Containments
> > and that part works rather well.
> > 
> > thoughts?
> 
> yes, wallpaper could be easily done without support from the library.
> i still don't have an exactly clear idea how the qml loading would be
> handled by the new shell, but whatever does qml loading for
> containment (probably a containment subclass? 

yes. i think that makes the most sense. that way each shell does not need to 
care about how the QML magic happens. just as Corona/Containment was used in 
the past to (mostly) hide the QGV semantics of things.

as per our group discussion in Randa, one nice result of moving Applet towards 
QObject only and pushing the QML support to a set of runtime components is 
that we get a level of presentation (QML, QGV, etc) independence we couldn't 
achieve previously. hopefully this will provide some of the future proofing 
that Sebas raised as being desirable :)

> that should be discussed
> shortly as well) should load its own qml and then the wallpaper qml
> and put it in a lower z-order.

agreed..

> as the current, the lifecycle of the qml wallpaper should depend if
> the view wants a wallpaper at all

yes ... this is something that could remain present in the Containment API 
much as we done it in libplasma1

-- 
Aaron J. Seigo

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

libplasma2 and Wallpaper

[Aaron J. Seigo]

hello ...

Plasma::Wallpaper has a number of limitations that are a result of the times 
it came from :)

namely, it directly paints using QPainter and forwards in a rather artifical 
means various mouse events. nothing else was really possible without dong the 
wallpapers in individual Containments, which obviously wasn't an option.

but now we are heading to a QML centric world. i think it would be far more 
useful to rip out the Wallpaper C++ plugin support and replace it instead with 
a solution using QML that lives outside of libplasma2.

this new approach would:

* use Plasma::Package to contain individual wallpaper engines
* have a set API made available to it by a QML component providing e.g. access 
to configuration options, a way to load configuration using QML (including a 
standardized item view that can be populated with a model provided by the QML 
wallpaper)

the benefits:

* no API in libplasma
* still available to all shells (and all QML apps, for that matter)
* full access to user interaction
* OpenGL rendering (at least in QML2)
* greater consistency by providing a way to make things like the config item 
view available to all plugins
* easier to make beautiful and interactive wallpapers (with good performance)

the drawbacks:

* all existing wallpapers will break
* any app / plasma shell that does not use QML will not benefit from this; but 
that # for plasma apps should be zero in the near future

the re-assuring:

* we can maintain configuration compatibility with the old plugins, so a 
configuration that uses the image plugin (for instance) would contnue to work 
with the same configuration as-is

to implement this, we would take some of the code in apol's recent plugin, add 
access to a small set of the existing QML bindings for config (e.g.) and 
provide a QML component in runtime to make it easy to use and write new 
wallpapers.

we may even want to put support for these new plugins into the QML helper for 
Containment so that shells don't need to do anything at all. this is the 
design we have right now in libplasma for Wallpapers and Containments and that 
part works rather well.

thoughts?

-- 
Aaron J. Seigo

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

Re: api review for DataEngineConsumer

[Aaron J. Seigo]

On Monday, September 24, 2012 21:09:57 Marco Martin wrote:
> rationale to remove remoteDataEngine

the difference between dataEngine and remoteDataEngine was passing a QUrl for 
the remote engine. it seemed natural to merge the two things. not only does 
this give us just one method in the public API, but it also makes the split 
between local/remote less evident / obvious, which is what should be worked 
towards imho.

> and finishedWithEngine?

this was not in DataEngineConsumer (DEC), as DataEngine usage is tied to the 
lifespan of a given DEC. the idea is to just delete the DEC when you are 
finished with the engines loaded using it.

-- 
Aaron J. Seigo

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

Re: Plasma Wallpapers in QML

[Aaron J. Seigo]

On Tuesday, September 25, 2012 03:21:39 Aleix Pol wrote:
> git clone kde:scratch/apol/qmlwallpapers

works very nicely; would be even nicer if mouse events were passed through, 
though, to allow some level of interaction, but given the mechanism that is 
needed to be used to make this work at the moment that may not be possible.

... and this leads me to think about what to do with Wallpaper in libplasma2 
:)

as for where to put this plugin, for now it should go into kdeplasma-addons 
with the other wallpaper plugins.

p.s. ascii animals are awesome :)

-- 
Aaron J. Seigo

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

Re: Review Request: expand the theme package in order to include *.svgz files

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On Sept. 24, 2012, 3:38 p.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106557/
> ---
> 
> (Updated Sept. 24, 2012, 3:38 p.m.)
> 
> 
> Review request for kdelibs and Plasma.
> 
> 
> Description
> ---
> 
> The theme package recognizes only files like foo.svg, with this patch it will 
> also recognize
> the foo.svgz files.
> 
> 
> Diffs
> -
> 
>   plasma/private/packages.cpp 15db229 
> 
> Diff: http://git.reviewboard.kde.org/r/106557/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

Re: Review Request: Fix wrong selection background rendering (visible e.g. with Plastique)

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On Sept. 23, 2012, 5:45 p.m., Christoph Feck wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106544/
> ---
> 
> (Updated Sept. 23, 2012, 5:45 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Fix wrong selection background rendering (visible e.g. with Plastique)
> 
> 
> This addresses bug 279663.
> http://bugs.kde.org/show_bug.cgi?id=279663
> 
> 
> Diffs
> -
> 
>   plasma/generic/wallpapers/image/backgrounddelegate.cpp 95c2719 
> 
> Diff: http://git.reviewboard.kde.org/r/106544/diff/
> 
> 
> Testing
> ---
> 
> Tested with Oxygen, Plastique, Skulpture.
> 
> 
> Thanks,
> 
> Christoph Feck
> 
>

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

api review for DataEngineConsumer

[Aaron J. Seigo]

hi...

i just pushed DataEngineConsumer as public API in libplasma2. this class is 
used extensively in libplasma1 (and wherever it was copy and pasted ;) to make 
it easy to tie usage of DataEngineManager to the lifespan of a given object 
(such as Applet, Runner, etc.)

turns out that this is how DataEngineManager was nearly *always* used, and 
when it wasn't (e.g. in individual Applets) it often caused problems. problems 
which DataEngineConsumer avoids.

so ... in these changes to libplasma2, DataEngineManager is now private API 
and DataEngineConsumer is cleaned up a bit and made public.

it is new API, however, with newly written documentation and so could use some 
review. if you can, please take a look at the new DataEngineConsumer in the 
frameworks branch and provide feedback if you have any.

-- 
Aaron J. Seigo

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

Re: Fit Grid elements in Item

[Aaron J. Seigo]

On Monday, September 24, 2012 11:45:22 David Edmundson wrote:
> the plasmoid
> should fit the size of the content, not shrinking the content to fit.

in this case, yes, as it is a popup applet which has an inherent minimum 
useful size. however, this is only acceptable when there is no other option 
and should not be the general case. 

content should always be scaled to fit the space alotted to the plasmoid. 
otherwise we get "androidis sizeitis" where putting QML app(let)s in different 
size views (or, screens) looks horrific. this may include eliminating some 
elements, simplifying them, scaling them, etc.

in the case of the calculator, it only makes sense to have all the buttons 
shown, and there is a set minimum size that also makes sense (be able to show 
all the content, still be big enough to press, etc.) .. .so there are always 
exception .. but they are exceptions. :)

-- 
Aaron J. Seigo

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

Re: commit problem

[Aaron J. Seigo]

On Monday, September 24, 2012 10:06:44 Reza Shah wrote:
> And later how to merge this to master? Does 'git cherry-pick sha' when
> i'm at master enough?

you need to `git push` again after the cherry pick. a cherry pick, like any 
git change set, is made locally only and you have to tell git to copy that 
change to a given remote (e.g. origin)

-- 
Aaron J. Seigo

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

Re: Review Request: improve wheel scrolling behaviour inside thumbnail view in virus and pattern wallpaper plugins

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On Sept. 23, 2012, 12:02 p.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106541/
> ---
> 
> (Updated Sept. 23, 2012, 12:02 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch try to improve wheel scrolling behaviour when scrolling thumbnail 
> view inside 'virus' and 'pattern' wallpaper plugins.
> To make it uniform like 'image' wallpaper plugin
> 
> 
> Diffs
> -
> 
>   wallpapers/pattern/CMakeLists.txt b6771d4 
>   wallpapers/pattern/config.ui 90fc7d1 
>   wallpapers/pattern/itemsview.h e69de29 
>   wallpapers/pattern/itemsview.cpp e69de29 
>   wallpapers/virus/CMakeLists.txt 81ff916 
>   wallpapers/virus/itemsview.h e69de29 
>   wallpapers/virus/itemsview.cpp e69de29 
>   wallpapers/virus/virusconfig.ui 78902a2 
> 
> Diff: http://git.reviewboard.kde.org/r/106541/diff/
> 
> 
> Testing
> ---
> 
> tested against KDE/4.9 branch, looked ok
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

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

Re: Review Request: reuse knewstuff's itemsview class to provide smooth scrolling in wallpaper configuration screen

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On Sept. 23, 2012, 2:19 a.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106536/
> ---
> 
> (Updated Sept. 23, 2012, 2:19 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch add smoothscrolling behaviour to listview in image wallpaper 
> screen,
> to improve the behaviour mentioned in this bug: 
> https://bugs.kde.org/show_bug.cgi?id=224198
> 
> The codes are from knewstuff itemsview class.
> 
> Can this also pushed to 4.9 branch?
> 
> PS:not sure how to include itemsview.h and itemsview.cpp in diff file, so i 
> just added as file attachments.
> 
> 
> This addresses bug 224198.
> http://bugs.kde.org/show_bug.cgi?id=224198
> 
> 
> Diffs
> -
> 
>   plasma/generic/wallpapers/image/CMakeLists.txt 2a4c2a3 
>   plasma/generic/wallpapers/image/imageconfig.ui 793f0ea 
>   plasma/generic/wallpapers/image/itemsview.h PRE-CREATION 
>   plasma/generic/wallpapers/image/itemsview.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/106536/diff/
> 
> 
> Testing
> ---
> 
> tested against master.
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

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

Re: plasmoid configuration using kconfigxt

[Aaron J. Seigo]

On Sunday, September 23, 2012 07:58:58 Reza Shah wrote:
> or only the items inside 'Appearance' group which are belong to my
> plasmoid will be deleted?

only the settings belonging to the plasmoid are removed. so in the case you 
shared, the entries in plasma-desktoprc will remain while the settings in 
plasma-deskotp-appletsrc will be removed.

simply don't use kconfigxt if the plasmoid is written in C++.

-- 
Aaron J. Seigo

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

Re: plasmoid configuration using kconfigxt

[Aaron J. Seigo]

On Saturday, September 22, 2012 09:04:23 Reza Shah wrote:
> I changed the configuration to kconfigxt, but now the settings are
> keep inside plasma-desktoprc. Is this expected behavior?

Yes, if you are doing it from a C++ plugin, this is exactly what will happen.
>From a QML/JS plugin it should do the right thing magically for you :)

--
Aaron Seigo
Make·Play·Live
http://makeplaylive.com

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

Re: Review Request: Fix panel redraw after screen resize

[Aaron J. Seigo]

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



plasma/desktop/shell/desktopcorona.cpp
<http://git.reviewboard.kde.org/r/106519/#comment15269>

instead of using a QTimer::singleShot, please add a QTimer member to 
DesktopCorona that is a singleshot. this way, if it get calls more than one in 
a row, only one timer call will be triggered.

thanks for the detailed comment explaining why this slot is needed!


- Aaron J. Seigo


On Sept. 21, 2012, 1:18 p.m., Ralf Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106519/
> ---
> 
> (Updated Sept. 21, 2012, 1:18 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch is my attempt to fix redrawing the panel when the screen is 
> resized. During my experiments, I added update() calls to all places I could 
> think of, but none of them helped - it seems that even though the panel is 
> redrawn, that content is not properly displayed. I am not sure whether this 
> might actually be a bug in KWin: For example, I also saw parts of the panel 
> content end up in the desktop background if compositing was disabled and the 
> background was set to a solid black, opposed to an actual image. I don't have 
> the knowledge to persuade that idea further though.
> I found, however, a solution (or a work-around) to fix the panel bug. Is that 
> acceptable?
> 
> 
> This addresses bug 269635.
> http://bugs.kde.org/show_bug.cgi?id=269635
> 
> 
> Diffs
> -
> 
>   plasma/desktop/shell/desktopcorona.h b65a926 
>   plasma/desktop/shell/desktopcorona.cpp ea58c2c 
> 
> Diff: http://git.reviewboard.kde.org/r/106519/diff/
> 
> 
> Testing
> ---
> 
> Re-sized the screen a few times (using xrandr) to verify that the graphical 
> glitches after a resize are gone.
> 
> 
> Thanks,
> 
> Ralf Jung
> 
>

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

Re: Review Request: Fix panel redraw after screen resize

[Aaron J. Seigo]

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



plasma/desktop/shell/panelview.cpp
<http://git.reviewboard.kde.org/r/106519/#comment15266>

problem with this approach is that whenever it resizes (which happens for 
many other reasons than screen resizes) it will cause a full panel repaint, and 
that is very expensive. performance when the panel is resized automatically due 
to contents changing, for instance, will suffer dramatically.

this needs to be tied to screen size changes ONLY (there is code in the 
shell that connects to these signals) .. and really it looks like the window 
just is not properly getting repaint calls when the window is resized in such 
cases.

i wonder if there isn't a race condition somewhere between screen resizing, 
panel window resizing and x events somewhere ...


- Aaron J. Seigo


On Sept. 21, 2012, 9:47 a.m., Ralf Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106519/
> ---
> 
> (Updated Sept. 21, 2012, 9:47 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch is my attempt to fix redrawing the panel when the screen is 
> resized. During my experiments, I added update() calls to all places I could 
> think of, but none of them helped - it seems that even though the panel is 
> redrawn, that content is not properly displayed. I am not sure whether this 
> might actually be a bug in KWin: For example, I also saw parts of the panel 
> content end up in the desktop background if compositing was disabled and the 
> background was set to a solid black, opposed to an actual image. I don't have 
> the knowledge to persuade that idea further though.
> I found, however, a solution (or a work-around) to fix the panel bug. Is that 
> acceptable?
> 
> 
> This addresses bug 269635.
> http://bugs.kde.org/show_bug.cgi?id=269635
> 
> 
> Diffs
> -
> 
>   plasma/desktop/shell/panelview.cpp 7713740 
> 
> Diff: http://git.reviewboard.kde.org/r/106519/diff/
> 
> 
> Testing
> ---
> 
> Re-sized the screen a few times (using xrandr) to verify that the graphical 
> glitches after a resize are gone.
> 
> 
> Thanks,
> 
> Ralf Jung
> 
>

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

Re: Notifications-future, a recap

[Aaron J. Seigo]

On Friday, September 21, 2012 01:40:51 Alex Fiestas wrote:
> On Thursday 20 September 2012 19:42:32 Sune Vuorela wrote:
> > On 2012-09-17, Dario Freddi  wrote:
> > > It really depends on what you want to achieve. If your goal is just
> > > cleaning up the API and implementing the existing standard it might
> > > work out, but for sure it won't just cut it for what I proposed, where
> > 
> > Why won't the existing (as in the fdo/galago spec) api cut it to ensure
> > we also play well with others (in both directions) ?
> > 
> > Really. All I read is complexity for teh sake of complexity, trying
> > to build walled gardens for the sake of building walled gardens and
> > complicating deployment for the sake of complicating deployment.
> > And I don't think that's neither modern, slick nor futureproof.
> 
> I don't see how this is incompatible with Dario's vision tbh, we just have
> to:
> 
> -Be sure we don't add overhead when deployming in windows/mac/others
> -Be sure that we are retrocompatible
> -Be sure that Qt's notification system integrates well (QPA)
> 
> As about the complexity, it all depends if we want to stay with galago
> (which imho is an insufficient standard) or we want to try to do something
> new.

"new" is not a good enough reason to create new incompatabilities. currently 
KDE notifications work seamlessly in other workspaces, and Gtk+ (and other) 
apps work seamlessly in Plasma workspaces .. this is due to supporting galago.

if the "new" can be achieved by extending or building on galago, that would 
seem to me to be a much better thing.

and no, galago is not perfect. it's not even "great", but it is passable and 
widely used and that gives it a lot of value.

if it turns out that we can not indeed achieve truly useful things without 
creating something completely new, we'll still need to support galago 
notifications in Plasma Workspaces, and we'll still want a bridge to galago so 
we don't lose integration with other workspaces (otherwise our app devs and 
users will, rightfully, complain)

so ... what are the things that can not be achieved by building on top of 
galago?

> GNOME3 notifications are quite good, implementing at least one concept long
> pursued by Notmart's vision (being able to specify which notifications
> should be kept and which notifications are irrelevant). To do this they had
> least expand galago spec.

key word: expand.

-- 
Aaron Seigo


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

Re: Review Request: fix crash in runner due to bookmarks

[Aaron J. Seigo]

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

Ship it!


just fix the if() note and push away (both to 4.9 branch and master pls)


plasma/generic/runners/bookmarks/browsers/firefox.cpp
<http://git.reviewboard.kde.org/r/106504/#comment15242>

as already noted, this if is not needed .. otherwise, i agree with Marco G. 
that this patch is fine once that is changed. so .. remove that if and commit 
pls :)


- Aaron J. Seigo


On Sept. 19, 2012, 11:21 a.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106504/
> ---
> 
> (Updated Sept. 19, 2012, 11:21 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> krunner crashes due to 
> kde-workspace/plasma/generic/runners/bookmarks/browsers/firefox.cpp 
> (Firefox::teardown()).
> 
> This patch solves the issue.
> 
> Also I fixed the indentation and a mem leak.
> 
> 
> Diffs
> -
> 
>   plasma/generic/runners/bookmarks/browsers/firefox.cpp 4dc02e3 
> 
> Diff: http://git.reviewboard.kde.org/r/106504/diff/
> 
> 
> Testing
> ---
> 
> since yesterday that I use the patch I haven't see any crashes
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

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

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On Sept. 19, 2012, 11:03 a.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106479/
> ---
> 
> (Updated Sept. 19, 2012, 11:03 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> How to reproduce the issue,
> 
> 1. open a project with plasmate
> 2. go File->close project
> 3. open the project again.
> A kmessagebox will appear with the error.
> 
> 
> Diffs
> -
> 
>   mainwindow.cpp b84da4a 
> 
> Diff: http://git.reviewboard.kde.org/r/106479/diff/
> 
> 
> Testing
> ---
> 
> I have tested the patch and I haven't seen any issues
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

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

[Aaron J. Seigo]

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



mainwindow.cpp
<http://git.reviewboard.kde.org/r/106479/#comment15199>

this looks incorrect; probably what is missing is an "|| !m_part"


- Aaron J. Seigo


On Sept. 17, 2012, 11:20 a.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106479/
> ---
> 
> (Updated Sept. 17, 2012, 11:20 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> How to reproduce the issue,
> 
> 1. open a project with plasmate
> 2. go File->close project
> 3. open the project again.
> A kmessagebox will appear with the error.
> 
> 
> Diffs
> -
> 
>   mainwindow.cpp b84da4a 
> 
> Diff: http://git.reviewboard.kde.org/r/106479/diff/
> 
> 
> Testing
> ---
> 
> I have tested the patch and I haven't seen any issues
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

Re: System tray

[Aaron J. Seigo]

On Tuesday, September 18, 2012 08:12:37 Daniel Nicoletti wrote:
> 2012/9/18 Aaron J. Seigo :
> > On Tuesday, September 18, 2012 10:58:32 Marco Martin wrote:
> >> - for the popup as just icons: not overly strong opinion, but I tend to
> >> prefer using text as well.
> > 
> > agreed. it makes it clearer what each icon is, but also gives a much
> > bigger
> > hit area and allows them to be easily scanned (a grid is difficult for
> > many to scan quickly).
> 
> Would it be hard to add an option to instead of a popup expand
> the plasmoid and show the remaining icons?

It would be easy to do, but easy is not always a measure of goodness. These 
kinds of options quickly pile up and making maintenance of the code much, 
much, much harder while simultaneously making the software vastly less 
enjoyable to use for most people (many of whom decide not to use KDE software 
as a result, I might add). This has been our general policy from the start, 
and it means we have options that tend to have more value.

So, no .. :)

> I really dislike the popup expecially because when I click on a plasmoid
> there it opens in the middle of the screen, and not close to the panel.

That would not be resolved by the option you describe. (And even if it did we 
don't pretend to fix bugs by working around them .. we fix them. :)

Where to open a popup is indeed tricky. Marco's suggestion is the best one, 
though as he notes that is not easy to achieve in the current architecture.

What makes the problem very visible is that when a popup is shown, the system 
tray popup hides. What would perhaps be better is if when an applet is clicked 
and it shows its popup that it shows the popup to the left/right and the 
system tray popup is not itself hidden. This may be able to be made to work by 
having the form factor to always be vertical for applets in the popup; some 
work on the popup position code may also be necessary to ensure there isn't 
ugly overlap between the popups.

-- 
Aaron J. Seigo

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

Re: System tray

[Aaron J. Seigo]

On Tuesday, September 18, 2012 10:58:32 Marco Martin wrote:
> - for the popup as just icons: not overly strong opinion, but I tend to
> prefer using text as well.

agreed. it makes it clearer what each icon is, but also gives a much bigger 
hit area and allows them to be easily scanned (a grid is difficult for many to 
scan quickly).

i didn't see any other issues beyond what Marco noted .. great work so far!

-- 
Aaron J. Seigo

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

Re: Notifications-future, a recap

[Aaron J. Seigo]

On Monday, September 17, 2012 20:40:33 Dario Freddi wrote:
> it's pretty much on the board :) just that 90% of this will happen in
> the background (server), whereas handlers will just take care of
> showing a model and a set of events. The aim is to make the client API
> as simple as possible and have a fatter server.

is the goal of getting rid of the notifications server as discussed at the 
Frameworks meetings in Randa off the table then?

-- 
Aaron J. Seigo

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

Re: Review Request: declarative plasmoid object, containment access

[Aaron J. Seigo]

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


exposing the containment to all plasmoids is not a good idea. one of the main 
benefits of these QML/JS plasmoids is that they are far more sandboxed from the 
rest of the system. this also invites plasmoids to think they know how the 
shell works, which they can't -> it could just as easily be plasma-netbook ad 
plasma-desktop.

let's back up and look at the problem from the starting point: the goal is to 
put an entry in a context menu that people can select which adds an icon for 
that application to the panel or "the" desktop (whatever that means given 
multiple screens, per virtual desktop views, etc.)

first question: do we really need this exact feature? is drag and drop good 
enough? are there other ways we could offer? (e.g. in the "Add widgets" UI 
could there be a way to add applications as well?)

second question: if this is really, really required can it be done without 
opening access to Containment? e.g. could it be done using a Plasma::Service 
which does the right thing for the given shell?

also, i don't think missing this feature should stand in the way of the QML 
version replacing the C++ version in master. we need to get this merged as soon 
as possible so people can start using it and we can start improving problems 
that crop up.

- Aaron J. Seigo


On Sept. 7, 2012, 9:20 a.m., Greg T wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106365/
> ---
> 
> (Updated Sept. 7, 2012, 9:20 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Heya,
> I need access to the containment in a qml plasmoid with c++ extensions. 
> Actually I'm using that to add launcher items from the new kickoff-qml to the 
> desktop/panel. Thats one of the last missing features of declarative kickoff, 
> basically it would be ready now to replace the c++ version...
> 
> Well, certainly you know what I want to achieve, so feel free to suggest 
> better alternatives :)
> 
> 
> Diffs
> -
> 
>   plasma/scriptengines/javascript/plasmoid/appletinterface.h 4f1201b 
>   plasma/scriptengines/javascript/plasmoid/appletinterface.cpp 75dc2f0 
> 
> Diff: http://git.reviewboard.kde.org/r/106365/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Greg T
> 
>

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

Re: RFC: on notifications applet

[Aaron J. Seigo]

On Thursday, September 6, 2012 17:59:03 Marco Martin wrote:
> opinions? comments?

great work to this point, and i like the plan for completion in 4.10.

+1 x2 :)

-- 
Aaron J. Seigo

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

Re: How Can I change wallpaper from CLI?

[Aaron J. Seigo]

On Thursday, September 6, 2012 14:22:28 Kevin Krammer wrote:
> Without checking the implementation details I would have guessed that
> "allowing content to be introspected" needs support for that introspection
> in every single application 

in the same way that every application that opens files stored on disk needs to 
support file open/read/write. in reality, very few of our applications make 
direct libc calls to achieve this and instead rely on (much) higher level 
libraries to keep such details at arms length.

we don't even need to patch every single application thanks to KDE's 
libraries. by patching specific classes in our libs, we are able to get the 
functionality in many of our apps instantly. example: we have written and 
maintain a rather small patch that makes kparts use ResourceInstance. this 
small change in one library makes every single kparts-using application 
instantly work as desired. KDE's dev framework is pretty awesome like that.

some applications will require some patches, however. that's already been done 
in dolphin (as one example), so we know how dificult it is: not very. these 
patches are small and very simple to write (i gave an example code snippet in 
a previous email), and only need to be done where other suitable frameworks 
(e.g. kparts) are not used.

> and that support would need to be updated when
> the introspector changes the way it introspects.

that's why we have a library like libkactivities: to provide an easy to use, 
long-lived API that hides the implementation details. the API in 
libkactivities is built around the design ("expose what is being viewed in a 
window") not the implementation ("we connect to a daemon using dbus and 
then..").

the introspection mechanism is completely encapsulated in libkactivities and 
no application need (or should) care now or in the future about the 
implementation details. in frameworks 5 libkactivities will end up being a Qt-
only library. the dbus API is also available in a well-formed dbus xml service 
definition so it can be readily reused by other applications which don't use 
Qt.

so .. no. the individual application should never need to be updated even if 
kactivitymanagerd changes, is replaced, or whatever.

-- 
Aaron J. Seigo

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

Re: How Can I change wallpaper from CLI?

[Aaron J. Seigo]

On Thursday, September 6, 2012 12:47:16 Kevin Krammer wrote:
> The problem with that (as far as I can tell) is that this would not be
> available to non-KDE apps, which (again as far as I understand) is the case
> of the thread starter.

if the issue was non-KDE apps, this would be an interesting starting point for 
discussion.

but the discussion moved to the example of a KIPI plugin for digikam. that is 
a KDE application.

once we get our own house in order, then i'd love to discuss about how we 
interface with the rest of the world.

> D-Bus interfaces have the advantage of being accessible from almost any
> program technology stack, most times even from shell scripts.

qdbus org.kde.ActivityManager /ActivityManager | grep Resource

we're smart enough to implement things in ways that aren't completely stupid. 
;)


and really this is a design question ("is associating URIs and metadata with 
windows a good / better solution? if so, how?"), not an implementation problem 
("what is used for remote procedure calls?"). 

even if the implementation is bad (though i don't believe it is), we can 
usefully improve the implementation as long as we have a good design to start 
with; the reverse is not true however -> design flaws don't get fixed by 
improving the implementation of them.

currently when it comes to things like setting wallpapers, our design sucked.

so some of us worked on improving that, and if you look at its use in Plasma 
Active you can judge for yourself whether or not it is an improvement or not.

and now we're asking the rest of our community to use that improved design 
broadly including on the desktop.

> > show me a dbus api for wallpaper setting that can do that. :)
> 
> Just curious: what kind of non-D-Bus communication mechanism is used by
> that?

it uses DBus. the differentiation is that it isn't focused on "making something 
to set a wallpaper" but focused on "allowing content to be introspected so 
that things can be done for/with that content".

making an API for "setting wallpaper" is not only fragile (see the differences 
in KDesktop 1, 2, 3 and Plasma; see the differences for windows, mac, xfce, 
gnome, etc) it is also very limited in scope and needs to be upkept in every 
single application.

the design concept of "expose the URI of the content this application window 
is showing" suffers none of those limitations. and it lets us do the trivial 
things like "set that as a wallpaper" easily: it's writing one plugin for one 
app (SLC) instead of writing one plugin for every single application out 
there.

really, it's the same thinking that went into things like kparts.

-- 
Aaron J. Seigo

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

FallbackComponent: caching, and doing something more permanent with it

[Aaron J. Seigo]

hi..

since reviewboard is not accepting my diff to plasma-mobile (either from the 
website or via the usual post-review; it seems to think there is no 
components/mobilecomponents/fallbackcomponent.cpp file... :/) i'm posting a 
patch here that implements some basic caching to avoid hitting disk more often 
than necessary. it uses QCache so as to prevent unlimited memory usage.

also, this seems to be the only thing from the plasma-mobile repository that 
SLC now uses. since it is so trivial, i'm considering just copying it into SLC 
wholesale. the only other thing that uses FallbackComponent is the 
ResourceDelegate that is used extensively in plasma-mobile, so the 
functionality of FallbackComponent is indeed needed, though i wonder if it 
needs to be its own entire componet just to access that one small bit of code. 
might be nicer if it were it were just part of ResourceDelegate .. but that's 
pure QML so probably not possible.

anyways ... patch and SLC usage -> thoughts?

-- 
Aaron J. Seigodiff --git a/components/mobilecomponents/fallbackcomponent.cpp b/components/mobilecomponents/fallbackcomponent.cpp
index 33fa820..10fb0a6 100644
--- a/components/mobilecomponents/fallbackcomponent.cpp
+++ b/components/mobilecomponents/fallbackcomponent.cpp
@@ -34,16 +34,27 @@ FallbackComponent::FallbackComponent(QObject *parent)
 
 QString FallbackComponent::resolvePath(const QString &component, const QStringList &paths)
 {
+QString resolved;
 foreach (const QString &path, paths) {
 //kDebug() << "Searching for" << path;
-//TODO: cache this, to prevent too much disk access
-const QString resolved = KStandardDirs::locate("data", "plasma/" + component + '/' + path);
+const QString key = component + '/' + path;
+if (m_paths.contains(key)) {
+resolved = *m_paths.object(key);
+if (!resolved.isEmpty()) {
+break;
+} else {
+continue;
+}
+}
+
+resolved = KStandardDirs::locate("data", "plasma/" + key);
+m_paths.insert(key, new QString(resolved));
 if (!resolved.isEmpty()) {
-return resolved;
+break;
 }
 }
 
-return QString();
+return resolved;
 }
 
 #include "fallbackcomponent.moc"
diff --git a/components/mobilecomponents/fallbackcomponent.h b/components/mobilecomponents/fallbackcomponent.h
index 4bf98b2..b5a13fa 100644
--- a/components/mobilecomponents/fallbackcomponent.h
+++ b/components/mobilecomponents/fallbackcomponent.h
@@ -22,6 +22,7 @@
 
 
 #include 
+#include 
 
 
 class FallbackComponent : public QObject
@@ -32,6 +33,9 @@ public:
 FallbackComponent(QObject *parent = 0);
 
 Q_INVOKABLE QString resolvePath(const QString &component, const QStringList &paths);
+
+private:
+QCache m_paths;
 };
 
 #endif


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

Re: How Can I change wallpaper from CLI?

[Aaron J. Seigo]

On Wednesday, September 5, 2012 20:42:55 Gilles Caulier wrote:
> There a task assigned to a student this summer to open Plasma API for
> wallpaper purpose. I mentored him to patch Plasma and write relevant
> Kipi plugin for digiKam.

honestly, it would make a lot more sense for applications that show content to 
use KActivities::ResourceInstance so that applications can see what the active 
content is.

what that would do in this case is instead of implementing (non-standard) 
means to set desktop wallpapers in N applications, N applications simply start 
advertising what content the user is focused on so that other parts of the 
system can react.

that way instead of dozens of different plugins for dozens of applications to 
do something as inane and rarely used as "set this random image i'm viewing to 
be my wallpaper" using a menu item (it's already possible with drag and drop), 
Share Like Connect could simply offer an item when a image with a supported 
mimetype is selected / viewed.

then nobody needs to worry about plasma shell internals (which can even differ 
between shells, btw, and has changed over time in some shells making 
maintaining such publicly used dbus APIs a PITA) and nobody needs to keep 
writing new plugins for this stuff.

extra bonus is that we'd then be able to do actually useful things for free 
like make it simple to post an image to one's microblog account or add the 
image (or whatever document / data / information) to an activity or 

and how hard is it?

using namespace KActivities;
m_resource = new ResourceInstance(window->wId(), this);

... some time later ...

m_resource->setUri(m_currentImage);
m_resource->setTitle(m_imageTitle);
m_resource->setMimetype(m_imageMimetype);

voila.

show me a dbus api for wallpaper setting that can do that. :)

-- 
Aaron J. Seigo

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

Re: KActivities library optimizations

[Aaron J. Seigo]

On Wednesday, September 5, 2012 21:54:33 Ivan Čukić wrote:
> > > We need data models for it
> >
> > sounds good ...
>
> Now, since the models library (in order to skip data retrieval from kamd via
> d-bus*) will need to be linked to nepomuk (linked resources) and qtsql (for
> detailed even logs), what do you think to make it a separate library -
> libkactivities-datamodels (or similar).

more libraries means harder to use (have to know the more about the design to
know which library to use and when).

i think a dep on nepomuk is just fine as long as nepomuk's depencies are
limited .. if they aren't, then it can be an issue.

i'm not clear on what the dependency on qtsql is for? (sorry .. hopefully you
can explain in more detail)

if data models are meant to be "the" way to interact with activities, which
could well be a valid approach, then having a separate lib also won't buy us
much as everything will use the models library anyways.

one reason to do it as a separate library could be to deprecate libkactivities
altogether and make everything a model (with things like Controller simply
becoming additional API added to the model subclass)

the more i think about it, the more i think it would be interesting to see a
models-only API for activities ... in which case having it as a separate, new
library makes lots of sense.

and yes, mega bonus points for suddenly not worrying about sync/async :)

--
Aaron J. Seigo

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

Re: [kactivities] src/lib: docs say it is deprecated, mark it as such

[Aaron J. Seigo]

On Wednesday, September 5, 2012 16:53:39 Ivan Čukić wrote:
> On Wednesday, 5. September 2012. 16.46.42 Aaron Seigo wrote:
> > Git commit 464f13b72949d4dc547e88144a4b089c6939f01e by Aaron Seigo.
> > Committed on 05/09/2012 at 16:46.
> > Pushed by aseigo into branch 'master'.
> >
> > docs say it is deprecated, mark it as such
> >
> > M  +1-1src/lib/info.h
> >
> > http://commits.kde.org/kactivities/464f13b72949d4dc547e88144a4b089c6939f01
> > e
> >
> > diff --git a/src/lib/info.h b/src/lib/info.h
> > index 7041d34..1afcae4 100644
> > --- a/src/lib/info.h
> > +++ b/src/lib/info.h
> >
> > @@ -107,6 +107,7 @@ public:
> >   * @returns the URI of this activity. The same URI is used by
> >   * activities KIO slave.
> >   */
> >
> > +KDE_DEPRECATED
> >
> >  KUrl uri() const;
>
> Am planning to un-deprecate it - it will return the kio url for the
> activity. That's why I removed the KDE_DEPRECATED. (will remove it when I
> redo the url() method)

ah, so the apidocs are incorrect.

--
Aaron J. Seigo

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

Re: KActivities library optimizations

[Aaron J. Seigo]

On Tuesday, September 4, 2012 16:19:52 Ivan Čukić wrote:
> > one thing i'm not a fan of with the new Consumer approach is that it is
> > impossible to know whether the code will block or not. it does a pre-fetch
> > and then cleverly blocks only if it hasn't received a reply yet. which
> > means there is no way to guarantee async behaviour when desired. as long
> > as
> > the calls to kactivitymanagerd are blazingly fast (and/or Consumer is
> > always created in sufficiently in advance of usage) this is a minor issue.
>
> Without the blocking. the hell would break loose - it wouldn't be backwards
> compatible and every kactivities client would need to be patched.

according to lxr, that is:

* plasma-desktop shell
* activities DataEngine
* activities Runner
* powerdevil
* plasma-mobile shell
* active web browser
* kwin
* tasks plasmoid
* pager plasmoid
* SLC

(see: http://lxr.kde.org/ident?i=KActivities ... though some of those are uses
of ResourceInstance which is not affected, e.g. the hits in dolphin)

most of these are pretty trivial uses; the plasma shells are probably the
biggest amount of work.

as this is the only way to guarantee no blocking anywhere, i think we should
seriously consider making this shift in v2 of the library (for Frameworks?) at
the same time we remove the deprecated calls. having looked at the code in
question, it really isn't a ton of work.

> > > or remove it since we IIRC don't use it in any important place.
> >
> > but we want to, right?
>
> Not really. The method that only gets a list and doesn't notify you on
> changes and similar is not that useful in my opinion.

i see it is marked as deprecated, even ... that at least makes one thing
easier :)

> We need data models for it

sounds good ...

--
Aaron J. Seigo

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

Re: KActivities library optimizations

[Aaron J. Seigo]

On Tuesday, September 4, 2012 11:28:22 Ivan Čukić wrote:
> I don't like the idea of having a simple requests like activity list
> or info with async api. This would be quite imitating for simple
> clients like loopless kio_activities, or file item plugin. It would be
> nicer to have something like std::async(...some method...).

for the simple requests API, one possibility is to have a class that you
instatiate and which pre-propulates (as the current class does) and signals
when it is ready for use. turning this sync is really easy (for things like
kio_activities), using the pattern seen in many other classes with exec() or
waitForFinished() methods (which can be paired with value classes that use
this explicitly as seen in QtDBus).

iow, the API can be async with a "make this sync, please" convenience method
for cases where it truly is ok to be sync.

one thing i'm not a fan of with the new Consumer approach is that it is
impossible to know whether the code will block or not. it does a pre-fetch and
then cleverly blocks only if it hasn't received a reply yet. which means there
is no way to guarantee async behaviour when desired. as long as the calls to
kactivitymanagerd are blazingly fast (and/or Consumer is always created in
sufficiently in advance of usage) this is a minor issue.

> For the slower methods (linked resources, and similar), I'd go for it,

yes, these probably really need to be async ...

> or remove it since we IIRC don't use it in any important place.

but we want to, right?

--
Aaron J. Seigo

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

Re: KActivities library optimizations

[Aaron J. Seigo]

On Monday, September 3, 2012 09:26:27 Ivan Čukić wrote:
> What do you think of the idea to go one step further, and instead of
> accessing the data via d-bus, to only use d-bus for signalling the changes,
> but to use QSharedMemory for actual data access (read-only from the
> library).

sounds a lot less maintainable and in the long run less re-usable. i also
wonder if using shared memory wouldn't simply move, rather than remove, lock
contention for data population, etc.

looking at the code in kactivities, the main problem seems to be that there
are (still) sync calls in the library. that's "ok" as long as it can be
guaranteed that the calls return quickly, which means that a) the daemon is
either running always (never crashes) or very quick to start, b) the daemon
can guarantee fast retrieval of the data, c) the daemon itself is never in a
sync call for very long.

the sync calls seem to be there due to the API of libkactivities which
attempts to provide synchronous access. perhaps it would be better to just
drop the pretense of synchronicity in the API?

--
Aaron J. Seigo

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

Re: Back to basics

[Aaron J. Seigo]

On Friday, August 17, 2012 23:52:52 David Edmundson wrote:
> but making patches is the only thing that matters.

exactly :) don't wait for someone to show up to start doing what matters...

(it's been 6 weeks since the blog entry you reference)

-- 
Aaron J. Seigo

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

Re: Review Request: Fix for Bug 165792 - Allow multirow panels

[Aaron J. Seigo]

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


this patch does not follow the coding style of the rest of the file (or the 
rest of the application)

has it been tested for all cases where updateStruts is called? does opening the 
panel editor when there are two panels on the same screen edge result in the 
panels switching order, for instance? what is the visual cue (if any) nothing 
what panel the panel controller is associated with when it is shown? why is the 
panel moved when struts are set?


plasma/desktop/shell/panelview.cpp
<http://git.reviewboard.kde.org/r/105932/#comment13804>

this does not catch CustomPanelContainment


- Aaron J. Seigo


On Aug. 8, 2012, 4:19 p.m., Tobias Franz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105932/
> ---
> 
> (Updated Aug. 8, 2012, 4:19 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> goes back to:
> https://bugs.kde.org/show_bug.cgi?id=165792
> 
> 
> This addresses bug 165792.
> http://bugs.kde.org/show_bug.cgi?id=165792
> 
> 
> Diffs
> -
> 
>   plasma/desktop/shell/panelview.cpp 50826a8 
> 
> Diff: http://git.reviewboard.kde.org/r/105932/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tobias Franz
> 
>

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

Re: Dictionary KRunner: Complete

[Aaron J. Seigo]

On Saturday, August 18, 2012 01:21:46 Jason A. Donenfeld wrote:
> It currently lives in kde-review [2], and I'd like to merge it into
> the plasma-addons git repository for 4.10, with your permission. Would
> someone look over it and let me know?

please put it in a branch in the kdeplasma-addons repository and open a review 
request for it. this is the most efficient way to get it in (seeing as it will 
need to be put into kdeplasma-addons to be a part of it, this will not be 
wasted effort)

-- 
Aaron J. Seigo

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

Re: Back to basics

[Aaron J. Seigo]

On Thursday, August 16, 2012 21:47:12 Nuno Pinheiro wrote:
> one thing lead to another and I acoured to me that the timing is perfect for
> a release were we focus on the basic desktop, and we market it just like
> that a "back to basics" release for the big 4.10, so we would do a few
> litle thing that improve the basic desktop experience the things people use
> 90% of the time, and we market that, we market that we still care about
> mouse and keyboard interaction and what works.

first, purpose drives technology. thinking first about what would be clever 
marketing and try to form fit the technolgy to it is a losing concept. either 
that or the justin bieber desktop would be the best thing ever.

just look at the thread on kde-promo ... the relevant phrase is "tail wagging 
dog".

if you ever feel it is important to CC a marketing list when thinking about 
discussing technology, delete the email (or whatever) immediately, think it 
through a bit more and send it to the relevant tech list instead with actual 
content.

so ...

there are no "basics".

never have been.

never will be.

i respect and admire the desire to make things better. that's always a good 
thing. but what thing(s) should be better?

you mention at some point the mouse/keyboard driven concept (because we've 
obviously lef that behind or something apparently) and that is perhaps a good 
start. so WHAT aspect of mouse/keyboard interaction could be improved?

-- 
Aaron J. Seigo

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

Re: [Owncloud] ownCloud Plasma client

[Aaron J. Seigo]

On Friday, July 13, 2012 01:17:14 Alex Fiestas wrote:
> so please feel welcome to participate :p

nice to see there is progress being made on this.

once small comment on the UI in the screenshot... why are there so many boxes 
in the content area? there's one around the content telling us this is the 
"testme" account, and then one around the checkboxes. do any of those boxes 
serve a purpose? less is more :)

-- 
Aaron J. Seigo

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

Re: QML plasmoid, pageStack.pop() doesn't work

[Aaron J. Seigo]

On Thursday, July 12, 2012 18:24:18 Gao Xiang wrote:
>   initialPage: [ c, b, a ]

as Darker noted, this is incorrect: it only takes a single page that is used 
to initialize the stack.

you want to use push and pop to push and pop pages on and off the stack. push 
can take an array of pages, so that you can do one push call to initialize the 
whole thing (perhaps in Component.onCompleted?)

that this is not obvious may be a sign that the API could be improved.

on a side note, the API docs here are messed up somewhat:

http://api.kde.org/4.x-api/plasma-qml-apidocs/PageStack.html

note the list of methods.

-- 
Aaron J. Seigo

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

Re: [KDE Bugtracking System] REMINDER: current Plasma regressions

[Aaron J. Seigo]

can we have this query changed so that it does not post every single day to 
the mailing list but perhaps do it just 1-2 times per week? i'd be happy with 
once per week, tbh..

thanks :)

On Monday, July 2, 2012 06:00:06 bugzilla_nore...@kde.org wrote:
> Please find below a list of the current regressions reported for Plasma
> 
>   This search was scheduled by myr...@kde.org.
> 
> 
> Plasma regressions
> --
> Bug 291676:
>   https://bugs.kde.org/show_bug.cgi?id=291676
>   Priority: NOR  Severity: normal  Platform: Gentoo Packages
>   Assignee: plasma-b...@kde.org
> Status: NEW
>Summary: Device Items resize on hover due to visibility change of the
> status text Bug 300885:
>   https://bugs.kde.org/show_bug.cgi?id=300885
>   Priority: NOR  Severity: critical  Platform: Ubuntu Packages
>   Assignee: plasma-b...@kde.org
> Status: NEW
>Summary: Weather widget does not work anymore with bbcuk or wetter.com
> provider Bug 301424:
>   https://bugs.kde.org/show_bug.cgi?id=301424
>   Priority: NOR  Severity: normal  Platform: openSUSE RPMs
>   Assignee: plasma-b...@kde.org
> Status: NEW
>Summary: Cannot open battery monitor applet if set to hidden in systray
> Bug 301459:
>   https://bugs.kde.org/show_bug.cgi?id=301459
>   Priority: NOR  Severity: normal  Platform: openSUSE RPMs
>   Assignee: plasma-b...@kde.org
> Status: UNCONFIRMED
>Summary: Categories button should reflect the category being filtered on
> Bug 301460:
>   https://bugs.kde.org/show_bug.cgi?id=301460
>   Priority: NOR  Severity: normal  Platform: Other
>   Assignee: plasma-b...@kde.org
> Status: NEW
>Summary: Switching activities became really slow
> Bug 301533:
>   https://bugs.kde.org/show_bug.cgi?id=301533
>   Priority: NOR  Severity: normal  Platform: Other
>   Assignee: plasma-b...@kde.org
> Status: NEW
>Summary: Option "Show Multiple Batteries" does nothing
> Bug 302331:
>   https://bugs.kde.org/show_bug.cgi?id=302331
>   Priority: NOR  Severity: normal  Platform: Ubuntu Packages
>   Assignee: ignat.seme...@blue-systems.com
> Status: UNCONFIRMED
>Summary: [post 4.9beta2] Folderview does not show any to activity linked
> files
-- 
Aaron J. Seigo

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

Re: Adding an image to slideshow.

[Aaron J. Seigo]

On Thursday, June 28, 2012 11:45:10 Varun Herale wrote:
> Hello,
> 
> This is regarding bug#302612 <https://bugs.kde.org/show_bug.cgi?id=302612>.
> 
> When a URL is added using setUrls(url), the path is temporarily added to
> the "m_slideshowBackgrounds" list. But when the next slide is rendered this
> member doesn't remember the path added. It goes back to only containing the
> paths of images in the slideshow folder. So it is a good thing to copy the
> image into the slideshow folder in this case ?

i think that would be a highly unexpected for the user as image files would end 
up copied seemingly randomly all over the place. no .. what needs to happen is 
that the wallpaper plugin needs to be fixed so that it remembers the added path 
correctly.

(classic example of "fix, don't work around, the bug")

-- 
Aaron J. Seigo

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

Re: How to access calendar using javascript?

[Aaron J. Seigo]

On Thursday, June 28, 2012 15:46:09 qasdfgtyuiop wrote:
> I want to let my widget add some events to the calendar.  But I can
> not find the api doc, where can I find them?

you probably want to be adding events into Akonadi. 

the calendar DataEngine has a Service defined that lets you add an event .. but 
it has not been fully implemented.

so we either need to complete that implementation or you will need to write 
directly to Akonadi. finishing the DataEngine would be preferred because then 
it immediately becomes available to QML/Javascript.

-- 
Aaron J. Seigo

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

Re: Offset from Plasma Theme?

[Aaron J. Seigo]

On Sunday, July 1, 2012 19:46:51 Michail Vourlakos wrote:
> Hello,
> 
> I would like to know if there is a way to know how much offset
> adds the Plasma theme in a plasmoid. The decorations of the
> plasma theme add some offset, for example the 0, 0 point of a plasmoid
> is in reality offsetX+0, offsetY+0 because of the plasma theme.
> 
> I need that because of some computations outside of that plasmoid.

can you explain what you are wanting to do in a bit more detail? because with 
what you described, it really sounds like you are doing something in the wrong 
way. 

these details are purposefully hidden so that developers don't try and do 
overly clever things that actually just break the user experience. if you are 
struggling against the API / design, it almost always means you should be 
doing something a little different. 

... but sometimes we actually do find new, valid use cases and need to extend / 
improve plasma in some way to meet them.

so if you can share more details, i can share a proper answer :)

-- 
Aaron J. Seigo

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

Re: Windows previews in qml plasmoid?

[Aaron J. Seigo]

On Thursday, June 28, 2012 08:56:21 Michail V. wrote:
> Is there a way to have windows previews in a qml plasmoid?

the ToolTip QML item (which isn't documented on api.kde.org with the other QML 
elements since it is written in C++ *sigh*) does not expose the requisite 
property in Plasma::ToolTipContent: windowsToPreview.

there are two ways to address this:

* add this functionality to the existing ToolTip element in kde-
runtime/plasma/declarativeimports/core/tooltip.cpp

* include a bit of C++ with the QML task manager applet which exposes this 

the two methods are essentially identical with one important difference: 
patching the tooltip.cpp in kde-runtime exposes this to *all* users of the QML 
elements ... and i don't think we want to do that as we could not take that 
API back later and this is one area that is likely to see some re-design in 
libplasma2.

so including a bit of C++ that bridges between Plasma::ToolTipContent and QML 
which does expose the windowsToPreview API would probably be best. you could 
even start by just copying over those files from kde-runtime and modifying as 
needed.

cheers.

-- 
Aaron J. Seigo

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

Re: Plasma applets inside QML applet

[Aaron J. Seigo]

On Sunday, June 24, 2012 13:11:46 David Edmundson wrote:
> What about the case of the calendar in the digital clock?

the calendar in the clock (and it's the same in all clocks, not just the 
digital clock) is not an applet. the calender applet instantiates the same 
calendar object that the clocks do.

-- 
Aaron Seigo

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

Re: Review Request: Plasma qml-Components ToolButton: change text-color on hover more fluently

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On June 28, 2012, 3:40 p.m., Johannes Tröscher wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105375/
> ---
> 
> (Updated June 28, 2012, 3:40 p.m.)
> 
> 
> Review request for Plasma and Aaron J. Seigo.
> 
> 
> Description
> ---
> 
> this is mostly visible with dark-themes only.
> as of now the text color got only changed when the "hover-element" was fully 
> visible. this looked a bit weird.
> this patch adds a ColorAnimation with the same duration as the 
> opacity-animation on the "hover-element" as Behavior for the Label.
> now the color changes fluently on hovering the ToolButton
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 1655821 
> 
> Diff: http://git.reviewboard.kde.org/r/105375/diff/
> 
> 
> Testing
> ---
> 
> tested, works
> 
> 
> Thanks,
> 
> Johannes Tröscher
> 
>

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

Re: Review Request: change default config of taskmanager

[Aaron J. Seigo]

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


Items= is no longer used. individual entries are. so this review is not correct.

the prefered items are also indeed removable. that was fixed a while back.

are you using kde-workspace from master or some older branch or...?

- Aaron J. Seigo


On June 28, 2012, 3:48 p.m., Greg T wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105374/
> ---
> 
> (Updated June 28, 2012, 3:48 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> libtaskmanager can't remove those ("browser", "preferred://browser, , , ") 
> entrys, so I moved them to the Items list. I don't know why they were 
> separated in the first place. That's why I'm opening this review request.
> 
> 
> This addresses bug 278724.
> http://bugs.kde.org/show_bug.cgi?id=278724
> 
> 
> Diffs
> -
> 
>   
> plasma/desktop/shell/data/layouts/org.kde.plasma-desktop.defaultPanel/contents/layout.js
>  afd1f2c 
> 
> Diff: http://git.reviewboard.kde.org/r/105374/diff/
> 
> 
> Testing
> ---
> 
> no regressions noted.
> 
> 
> Thanks,
> 
> Greg T
> 
>

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

Re: Review Request: make content margin of widget explorer similar to activity manager

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On June 26, 2012, 1:53 p.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105361/
> ---
> 
> (Updated June 26, 2012, 1:53 p.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> This patch changes content margins of widget explorer similar to activity 
> manager, which is has better layout in my opinion.
> I attached the screenshot for comparison between previous,after and reference.
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/widgetexplorer.cpp 06f0766 
> 
> Diff: http://git.reviewboard.kde.org/r/105361/diff/
> 
> 
> Testing
> ---
> 
> tested against master
> 
> 
> Screenshots
> ---
> 
> before-after
>   http://git.reviewboard.kde.org/r/105361/s/612/
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

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

Re: Review Request: fixed widget explorer or activity manager not closed when clicking desktop area above panel

[Aaron J. Seigo]

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


for the activity manager this can make sense since interaction with the desktop 
is not particularly important.

but this behaviour is intentional for the add widget interface since moving 
things around on the desktop while it is shown is common. so this should not 
happen when the window is showing the widget explorer.

- Aaron J. Seigo


On June 26, 2012, 12:29 p.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105340/
> ---
> 
> (Updated June 26, 2012, 12:29 p.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> There is a bug which prevent widget explorer or activity manager not closed 
> when clicking desktop area above panel.
> 
> Steps to reproduce:
> - after login and with no window appear (we can see desktop area clearly).
> - open widget explorer from panel
> - then click at desktop area somewhere above the panel.
> 
> The expected result is widget explorer or activity manager will be closed.
> 
> 
> Diffs
> -
> 
>   plasma/desktop/shell/controllerwindow.cpp 306a152 
> 
> Diff: http://git.reviewboard.kde.org/r/105340/diff/
> 
> 
> Testing
> ---
> 
> test against master branch.
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

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

Re: Review Request: ksysguard.deskstop shoud not use generic name "System Monitor" for its "Name" key

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On June 24, 2012, 7:39 a.m., Jekyll Wu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105338/
> ---
> 
> (Updated June 24, 2012, 7:39 a.m.)
> 
> 
> Review request for Plasma and John Tapsell.
> 
> 
> Description
> ---
> 
> Currently, ksysguard.desktop contains "Name=System Monitor" and 
> "GenericName=System Monitor". 
> 
> FOD specification[1] writes:
> 
> NameSpecific name of the application, for example "Mozilla".
> GenericName Generic name of the application, for example "Web Browser".
> 
> So I think using a generic name like "System Monitor" for "Name" is 
> problematic. The current situation of using the same generic name for both 
> "Name" and "GenericName" is also questionable.
> 
> The patch simply uses "KSysGuard" for the "Name" key . 
> 
> [1] 
> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys
> 
> 
> Diffs
> -
> 
>   ksysguard/gui/ksysguard.desktop 7e8ff32 
> 
> Diff: http://git.reviewboard.kde.org/r/105338/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jekyll Wu
> 
>

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

Re: Review Request: DBus-interface for changing wallpapers

[Aaron J. Seigo]

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



plasma/desktop/shell/plasmaapp.cpp
<http://git.reviewboard.kde.org/r/105319/#comment11903>

i would prefer it if the plugin name and mode were not exposed. the use 
case is "setting a wallpaper image" so let's implement that. 

the main problem with being able to set the name and mode is that not only 
are most of the plugins optional (just asking for fun breakage) but also 
require configuration.

so i would recommend a rather simpler setWallpaperImage(const QString &url).

it should probably do similar to what the drag and drop support does and if 
the url is not local then try to fetch it using KIO.



plasma/desktop/shell/plasmaapp.cpp
<http://git.reviewboard.kde.org/r/105319/#comment11905>

this will fail for per-virtual-desktop-containments. you need to also pass 
in the current desktop (KWindowSystem has a method for getting that)



plasma/desktop/shell/plasmaapp.cpp
<http://git.reviewboard.kde.org/r/105319/#comment11904>

must check that currentContainment is not null. containmentForScreen 
returns null on failure.



- Aaron J. Seigo


On June 24, 2012, 3:47 p.m., Varun Herale wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105319/
> ---
> 
> (Updated June 24, 2012, 3:47 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch is for hosting a dbus-interface that can be used to load any 
> installed wallpaper plugin onto current desktop containment. In case of 
> default "image" plugin, the path to the image can also be sent which will 
> change the wallpaper.  
> 
> 
> Diffs
> -
> 
>   plasma/desktop/shell/dbus/org.kde.plasma.App.xml eefce32 
>   plasma/desktop/shell/plasmaapp.h 6ae0c89 
>   plasma/desktop/shell/plasmaapp.cpp 7abd8fc 
> 
> Diff: http://git.reviewboard.kde.org/r/105319/diff/
> 
> 
> Testing
> ---
> 
> Tested on different activities and made sure it works for per-virtual desktop 
> containment.
> 
> Haven't tested on a system with multiple screens though, as I don't have 
> access to one. Could someone please test for that ?
> 
> 
> Thanks,
> 
> Varun Herale
> 
>

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

Re: Review Request: Use common plasma components Tooltip in battery monitor

[Aaron J. Seigo]

> On June 18, 2012, 3:37 p.m., Viranch Mehta wrote:
> > The button size and the hover appearance is different from the original 
> > one. The IconButton component was made to keep the look of the buttons 
> > consistent with the original version of the applet. Do we want to change 
> > this?
> 
> David Edmundson wrote:
> Valid argument for now, won't be valid when everything moves to 
> QML/Plasma Components.
> 
> You're maintainer, you have final say.
> If you want me to wait till 4.10 when more applets are QML based I will 
> do.
> 
> Viranch Mehta wrote:
> Well after a second thought, I think its a better idea to use plasma 
> components for consistency over plasma rather than maintaining consistency 
> with previous versions. but the original button for some reason looks 
> *really* better in visual terms to me (in fact, the button is also used in 
> some other plasmoids including the network manager). so...
> 
> to plasma components dev: can we have an option in the button of what 
> background svg is used? may be a switch between the current one and the one 
> in this plasmoid (widgets/viewitem)?
> 
> if that may take time to come up, or is not desired, we can have this 
> patch shipped right in!
> 
> Viranch Mehta wrote:
> david, please ship this patch for now. thanks!

i don't think we want to allow defining which SVG is used, but it could make 
sense to have a property that can be set to adjust the look based on where/how 
the button is used.


- Aaron J.


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


On June 17, 2012, 7:52 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105283/
> ---
> 
> (Updated June 17, 2012, 7:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Current battery monitor implements it's own Button class, this previously 
> broke styles with theme text and overloads icon sizes and such.
> 
> It's bad for applets to implement their own version of common classes as it 
> prevents consistency.
> 
> (will fix the whitespace addition before commit)
> 
> 
> Diffs
> -
> 
>   plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml d4454c6 
>   plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml a2ab72a 
> 
> Diff: http://git.reviewboard.kde.org/r/105283/diff/
> 
> 
> Testing
> ---
> 
> Checked applet looked ok.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request: Fix the minimum size of some applets

[Aaron J. Seigo]

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


patch seems broken, perhaps was not made against current master. can you 
re-send the patch?

- Aaron J. Seigo


On June 22, 2012, 6:17 a.m., Maarten De Meyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105234/
> ---
> 
> (Updated June 22, 2012, 6:17 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This fixes the minimum size of the following applets: showdashboard, 
> systemloadviewer, pastebin, weatherstation and timer.
> Some sizes were to small, so there were visual glitches and some applets had 
> no minimum value set.
> 
> I have no commit rights.
> 
> 
> Diffs
> -
> 
>   applets/pastebin/pastebin.cpp 208e6a3 
>   applets/showdashboard/showdashboard.h 695347f 
>   applets/showdashboard/showdashboard.cpp 1c2f623 
>   applets/systemloadviewer/systemloadviewer.cpp b852256 
>   applets/timer/timer.cpp ba5ee66 
>   applets/weatherstation/weatherstation.h 6d4ae24 
>   applets/weatherstation/weatherstation.cpp 8ada9c2 
> 
> Diff: http://git.reviewboard.kde.org/r/105234/diff/
> 
> 
> Testing
> ---
> 
> Run the applets with their new minimum size, and minimized.
> 
> 
> Thanks,
> 
> Maarten De Meyer
> 
>

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

Re: When should a bug be considered as a regression or a release_blocker?

[Aaron J. Seigo]

On Thursday, June 21, 2012 20:17:50 Martin Gräßlin wrote:
> if there is interest in the team, I am willing to do the administrative work
> of creating target milestones and disabling outdated ones. I'm doing that
> work for kwin anyway and doing it for Plasma would not create much work.

cool! thanks for stepping up like that ... which makes this the next topic:

> Btw. would someone be interested in a Plasma bug workflow BOF at Akademy?

me. :)

--
Aaron J. Seigo

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

Re: Plasma Containment default setting

[Aaron J. Seigo]

On Thursday, June 21, 2012 20:17:12 Varun Herale wrote:
> > * will the feature work consistently (multiple screens, per-virtual
> > desktop
> > containments, etc..) and not just work for some configurations
> 
> I have written some code <http://pastebin.com/E9NK0Cxu> for this. It hosts
> a dbus-interface from which wallpaper plugins can be loaded. From what I've
> tested it works for per-virtual desktop containments and should also work
> with multiple screens. Please do review, it'll help with my understanding
> of Plasma atleast.

please post it on http://reviewboard.kde.org .. i can't review a pastebin, 
sorry.

btw, you may want to look at Corona::containmentForScreen().

-- 
Aaron J. Seigo

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

Re: When should a bug be considered as a regression or a release_blocker?

[Aaron J. Seigo]

On Thursday, June 21, 2012 17:18:15 Martin Gräßlin wrote:
> next. That might work also for Plasma.

we have done this in past releases. it does work. i'd like to do it again. but
it takes effort, leadership and group cooperation.

--
Aaron J. Seigo

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

Re: When should a bug be considered as a regression or a release_blocker?

[Aaron J. Seigo]

On Thursday, June 21, 2012 16:13:32 Mark wrote:
> think we should make releases with random pieces cutted out, or they
> will never be complete" so we don't cut out pieces that don't work yet
> we also don't want to release pieces that don't work.

we don't WANT to, but we do. 

this is the "perfect is the enemy of good" problem. we could wait till 
everything is (close enough to) perfect .. and then never release. or release 
once every 3-4 years. which would become the same thing as never because the 
project would die.

we don't cut out pieces as there would be almost nothing left over time, bugs 
would just get hidden not addressed, etc. etc.

but we want to ship working things so we improve them on each iteration.

hope that helps ...

> To phrase it more clearly.
> How do we deal with individual components that are completely broken?

fix them.

the effort spent in this thread could likely have fixed the kget issue.

> How do we mark such issues in bugzilla?

as critical bugs.

> And how does the release team
> handle those issues if they are still completely broken once a new KDE
> SC is about to be released? (not a beta or rc, but final release)

i already answered that.

-- 
Aaron J. Seigo

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

Re: When should a bug be considered as a regression or a release_blocker?

[Aaron J. Seigo]

On Thursday, June 21, 2012 16:58:28 Mark wrote:
> Ehhh, that's a very strange reasoning :p That way you could release a
> completely broken KDE SC (like KDE 4.0 was ;p) then developers will

this is not why the 4.0 release was made at the point it was, nor is it 
comparable in scope as marco pointed out.

-- 
Aaron J. Seigo

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

Re: Plasma Containment default setting

[Aaron J. Seigo]

On Thursday, June 21, 2012 15:27:11 Martin Klapetek wrote:
> (think the environments without dragging to desktop).

this will require different code paths for each env: setting the desktop 
wallpaper is not standardized between environments. in kde3 we used dcop calls 
which were specific to kdesktop and did not work anywhere else. so unless 
someone implements methods for multiple other environments, this is unlikely 
to matter.
 
> > why? we have DnD already ...
> 
> Yes, but this discussion started exactly because there's a need (justified
> or not) for a different solution. 

a need that is not justified is not a need. :)

-- 
Aaron J. Seigo

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

Re: Plasma Containment default setting

[Aaron J. Seigo]

On Thursday, June 21, 2012 15:21:03 Kevin Ottens wrote:
> On Thursday 21 June 2012 14:37:36 Aaron J. Seigo wrote:
> > [...]
> > this for me takes precidence over the SLC steps which are:
> > 
> > * write more plugins for SLC
> > 
> > * get the patches into kdelibs
> 
> Which reminds me I wanted to ask: did those patch reach the frameworks
> branch yet?

no

> Or you prefer push them after the splitting is over?

no

the branch is ivan/kparts-activities

it would also be great see the  ivan/plasma-active-patches branch merged into 
frameworks. possibly the kio fuse branch as well, though that one may not be 
fully baked yet; ivan will know for sure.

sebas: is the web thumbnails branch still needing to be merged?

-- 
Aaron J. Seigo

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

Re: Team meeting today

[Aaron J. Seigo]

On Thursday, June 21, 2012 16:49:42 Mark wrote:
> Now this won't give the maintainer or any status but it does give an
> idea if a certain component is even maintained. 

that pretty much describes what i do when i want to check in on a given bit of 
code (not just in plasma) ...

-- 
Aaron J. Seigo

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

Re: Plasma Containment default setting

[Aaron J. Seigo]

On Thursday, June 21, 2012 14:51:51 Luca Beltrame wrote:
> In data giovedì 21 giugno 2012 14:37:36, Aaron J. Seigo ha scritto:
>
> [SLC]
>
> > * make it part of the default desktop layout
>
> Does SLC still depend on components from plasma-mobile?

it had imports for them, but no components from MobileComponents were actually
being used .. so: no :)

--
Aaron J. Seigo

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

Re: [kdeplasma-addons] applets/fileWatcher: fix the minimum size only on the desktop

[Aaron J. Seigo]

On Wednesday, June 13, 2012 15:36:39 Anne-Marie Mahfouf wrote:
> Git commit b7eff7326cbe4392bcbeb2c57371efc1b75c421a by Anne-Marie Mahfouf.
> Committed on 13/06/2012 at 15:32.
> Pushed by annma into branch 'master'.
> 
> fix the minimum size only on the desktop
> 
> CCBUG: 301676
> 
> M  +5-1applets/fileWatcher/fileWatcher.cpp
> 
> http://commits.kde.org/kdeplasma-addons/b7eff7326cbe4392bcbeb2c57371efc1b75c
> 421a
> 
> diff --git a/applets/fileWatcher/fileWatcher.cpp
> b/applets/fileWatcher/fileWatcher.cpp index 8b8aa2e..2544013 100644
> --- a/applets/fileWatcher/fileWatcher.cpp
> +++ b/applets/fileWatcher/fileWatcher.cpp
> @@ -45,7 +45,6 @@ FileWatcher::FileWatcher(QObject *parent, const
> QVariantList &args) {
>setAspectRatioMode(Plasma::IgnoreAspectRatio);
>setHasConfigurationInterface(true);
> -  setMinimumSize(200, 100);
>resize(400, 200);
>  }
> 
> @@ -112,6 +111,11 @@ void FileWatcher::constraintsEvent(Plasma::Constraints
> constraints) textItem->setPos(contentsRect().topLeft());
>  updateRows();
>  }
> +if (constraints & Plasma::FormFactorConstraint) {
> +if (formFactor() == Plasma::Planar) {
> +setMinimumSize(200, 100);
> +}
> +}
>  }

this still is not enough because the minimum size is not reset when move from 
the desktop into a panel. will fix, but keep this in mind ..

also, if an applet needs such a thing, it usually is because it can not scale 
the main interface down well, and so should then become a popup applet.

and sometimes the main interface does not scale down well, but could if there 
was some additional thought put into it :)

-- 
Aaron J. Seigo

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

Re: Team meeting today

[Aaron J. Seigo]

On Thursday, June 21, 2012 13:23:02 David Edmundson wrote:
> I made a similar form for Plasma is available here:
> http://community.kde.org/Plasma/Maintainership please fill-in as
> appropriate.

there are 51 plasmoids in kdeplasma-addons alone.

some plasmoids have clear owners (for various reasons: more complex, specific 
interest area, etc...) such as the comic plasmoid, remember the milk, kde 
observatory ...

most are communally owned, however. this allows people to work on things 
rather more freely, but also reflects the reality that people come and go a 
lot.

the bugzilla components also don't map cleanly to the code as they are often 
about functional distinctions as that is easier to help with categorizaton 
(multiscreen being perhaps the obvious example). again, some of these have 
people who care for them, and some are communally owned.

so my main concerns for such a list are:

* it will only cover certain elements but not others

* that people who are no longer active will not remove their name and it will 
very quickly grow outdated (this has been my experience with all of the wiki 
pages we've used for such things ...)

what i'm missing here is: why do we need this?

is it that people do not know how to use git well enough to see who has been 
working on it?

is the idea of community maintenance an alien idea so people want to see "the 
person who is in charge" or each item?

i can see having a list of maintainers for components that are "strongly 
maintained" by an individual, such as the comics applet (to pick something 
completely at random). but then ... using git i'd be able to figure that out 
immediately as well.

i can definitely understand wanting to have notation for who oversees which 
group of technologies: e.g. who is responsible for libplasma, for plasma in 
workspace and runtime (or which large parts of it...), for solid, for 
networking, for power management, for window management and composition .. 
etc. that would be useful for understanding how the overall product splits 
down into projects with team leadership.

is that what we're looking for rather than a module-by-module break down of 
plasma?

(i ask because this seems to have come up after i had to leave..)

-- 
Aaron J. Seigo

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