Re: [kde-community] Usage of QNetworkAccessManager

[Richard Moore]

On 14 July 2016 at 17:38, Thiago Macieira  wrote:

> On quinta-feira, 14 de julho de 2016 18:33:37 PDT Ben Cooksley wrote:
>
> > Unfortunately, from it's first iteration in Qt 4 QNetworkAccessManager
> > w
> ​e ​
> as shipped with a severe and fundamental defect in that it does not
> > follow HTTP redirects by default. Due to Qt behavioural and other
> > compatibility promises they can never change this behaviour, not even
> > in Qt 6.
>

​This is incorrect. We can certainly change it in qt6. In fact it's an open
discussion if we can change it before - we need evidence that the change
will not break apps that handle redirects themselves. If anyone has time to
test this then pleas​e let me know the results.

​​

> >
> > Please therefore ensure your application handles redirects
> > appropriately (the form of the code will depend on the version of Qt
> > in use) if you decide to use QNAM.
>
> You do that by setting the attribute FollowRedirectsAttribute in your
> QNetworkRequests.
>
>
​​
​Yes, the code in the example dfaure has linked to does it the hard way.

Cheers

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

Re: Review Request 122909: Fix segfault with missing screens

[Richard Moore]

> On March 12, 2015, 1:40 p.m., Martin Gräßlin wrote:
> > For the record I reverted with 
> > http://commits.kde.org/plasma-workspace/c4c7e6d53f66fbdd6d58b40e5f3b443c6cf2e197:
> > 
> > The reason for revertion is that it leaks pixmaps.
> > QX11Info::display should not return a nullptr if there is no QScreen.
> > This needs fixing in Qt, not workarounds in our software. None of our
> > X11 specific code in plasma-workspace or frameworks can handle the case
> > that the Display* or xcb_connection_t* becomes null suddenly. Neither
> > can Qt internally. If it would happen Qt would abort.
> > 
> > The only application in our workspace which would be "somewhat" safe
> > is KWin because it caches the returned Display after first invokation
> > to QX11Info::display.

Now someone has told me about the problem, I can fix this trivially in Qt.


- Richard


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


On March 12, 2015, 1:24 p.m., Jan Kundrát wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122909/
> ---
> 
> (Updated March 12, 2015, 1:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Fix segfault with missing screens
> 
> This is to keep up with the Qt 5.5 changes with null QScreen. BT:
> 
>  #0  XInternAtom (dpy=0x0, name=0x7f1195725664 "_KDE_NET_WM_SHADOW", 
> onlyIfExists=0)
>  at 
> /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/IntAtom.c:174
>  #1  0x7f11956e438c in PanelShadows::Private::clearShadow 
> (this=, window=0x7f119958ff90)
>  at 
> /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/panelshadows.cpp:494
>  #2  0x7f11956e7139 in PanelShadows::removeWindow (this=0x7f119593b060 
> <(anonymous 
> namespace)::Q_QGS_privateDialogShadowsSelf::innerFunction()::holder>, 
> window=window@entry=0x7f119958ff90)
>  at 
> /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/panelshadows.cpp:142
>  #3  0x7f11956dd8f5 in PanelView::~PanelView (this=0x7f119958ff90, 
> __in_chrg=)
>  at 
> /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/panelview.cpp:124
>  #4  0x7f11956dd9af in PanelView::~PanelView (this=0x7f119958ff90, 
> __in_chrg=)
>  at 
> /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/panelview.cpp:125
>  #5  0x7f11956effa8 in ShellCorona::removeView (this=0x7f1196c19b40, 
> idx=0) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/shellcorona.cpp:710
>  #6  0x7f11956f0038 in ShellCorona::remove 
> (this=this@entry=0x7f1196c19b40, desktopView=)
>  at 
> /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/shellcorona.cpp:662
>  #7  0x7f11956f009f in ShellCorona::screenRemoved (this=0x7f1196c19b40, 
> screen=)
>  at 
> /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/shellcorona.cpp:743
> 
> 
> Diffs
> -
> 
>   shell/panelshadows.cpp c97564a2417a66e17a1a02237155f19addf2b9c7 
> 
> Diff: https://git.reviewboard.kde.org/r/122909/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jan Kundrát
> 
>

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

Re: QML style guide

[Richard Moore]

On 29 October 2012 20:42, Aaron J. Seigo  wrote:
> summary -> i've started putting together a QML style guide draft and would
> like your input and to bring it completion in a collaboration with all of you
> who are writing QML for Plasma. to that end, i've started a wiki page here:
>
> http://community.kde.org/Plasma/QMLStyle
>
> nothing is set in stone. let's make it great.

You should post this to qt-interest too since I think that's something
that will be of interest to the Qt community beyond KDE, and you're
likely to get some good feedback.

Cheers

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

Plasma UI issues on a fresh suse 11.4 (and ideas towards solving them)

[Richard Moore]

I did a fresh install of suse 11.4 yesterday, and the result was less
polished than I would have hoped. Here's what I spotted and some
suggestions for addressing them:

After a few things had launched, knetworkmanager vanished. I know in
retrospect that it was simply that the notification area got too big
and it was hidden. The arrow indicating the hidden icons is currently
too difficult to spot unless you know what it is, perhaps it could
flash when it is initially created (possibly with some animation that
things are moving there) so that people will know to look for it (i
didn't). Alternatively, perhaps simply changing the colour of the icon
would help - I think my confusion was a result of thinking the arrow
was simply another app sitting in the status area.

Once I couldn't get access to knetworkaccessmanager, I tried launching
it from the command line and got no output and no visibility. I'm
guessing it's a kuniqueapplication so it will only run once. notmart
suggested a fix here would be to make the notifier status 'notify'
when newInstance is called.

The next issue I hit was a wifi problem (the root cause was not KDE's
fault in anyway) unfortunately it wasn't handled well by the GUI
either. The first issue was poor diagnostics - I didn't get a gui
message that a firmware blob was needed, and instead had to look in
/var/log/messages. I suspect this is an underlying NetworkManager
issue. Installing the blob didn't fix things (not KDE's fault either)
but I did start to get lots of popup notifications from
KNetworkManager. Unfortunately whenever I tried to use the context
menu to access it and see what was up, another notification would
appear, and in the process cancel the menu. This was incredibly
frustrating. I'm not quite sure how we can handle this, but perhaps a
strategy similar to the one used by syslog of reverting to 'repeated X
times' might be a good idea.

One thing I must say is that I do like the new icons for the status
area, it no longer looks like it was designed by a lover of hawaiian
shirts. :-)

Cheers

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

Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]

[Richard Moore]

On Thu, Feb 10, 2011 at 4:39 AM, Ted Gould  wrote:
> 1.  Expert screenreader users will, if they can, save time by listening
>    to only the first part of an item's label before navigating
>    elsewhere. So an accessible label may put variable information
>    first (for example, "22 percent battery"), while the tooltip may be
>    better presenting the same information in key-value form (for
>    example, "Battery (22%)").

This is a great example, and suggests that we also need this
information included within the spec - ie. the distinction needs to be
made clear to developers using it. If we don't make it clear then
we'll end up with developers simply reusing the tooltip text anyway!

Cheers

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

Re: QML and Plasma -> progress()

[Richard Moore]

On Mon, Oct 4, 2010 at 7:41 PM, Marco Martin  wrote:
> Hi all,
> update on the situation: with a fair amount of hacks now we got the engine and
> the read/write main object as well, that means the js bindings can be stuffed
> in it -almost- seamlessy (i still have to try with extenders, not too
> optimistic on that), so huge win, we can show the value added on top.

One possibility might be to have a private libunbreakqml that handles
the hacks for letting you use the script engine properly.

Cheers

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

Re: PlasmaKPart moved to kdereview

[Richard Moore]

- KPartView

This is a bad name to have in an unnamespaced class. Rename to
KPartPlasmaView perhaps?

KConfigGroup config() - missing docs and should not be inline

static int mainViewId() { return 1; } broken by design it appears

No dpointers

- PlasmaKPart

Not in namespace and no K prefix. Dubious classname.

bool openFile() { return true; }; inline method and dubious

missing dpointer


Note that the dpointer issues matter since people will have to link
directly to the class to make use of the methods that are not standard
kpart ones so binary compatibility would be needed. An alternative
would be to use a KParts extension for these methods as khtml does,
but it's not the case here.

Regards

Rich.

On Fri, Aug 13, 2010 at 7:54 AM, Ryan Rix  wrote:
> Moin moin,
>
> I've moved PlasmaKPart, a KPart which can be used by any application who
> wishes to enable a dashboard/summary page in their application, into
> kdereview. PlasmaKPart leverages the Plasma Development Platform to do
> most of the work for any developer; the only thing really left for
> developers is the development of the widgets, which can either be done
> using Plasma or using QWidgets easily wrapped in Plasma objects.
>
> The documentation on this KPart, including the details to implement
> Plasma object injection using the Plasma::PluginLoader API (already in
> trunk) currently resides as a work in progress at
> http://techbase.kde.org/Development/Tutorials/Plasma/ApplicationShell .
> It will be completed over the next 24 hours.
>
> There are no dependencies for this code outside of kdelibs and
> kdebase/runtime (as far as I can tell).
>
> There is currently in plasmakaprt/shell a testing/example shell which
> will show the minimal amount of work necessary to deploy this kpart as
> well as the Plasma::PluginLoader API.
>
> This code is directly related to my Google Summer of Code work. The plan
> is to move this into kdebase-runtime.
>
> Best,
> Ryan Rix
>
> PS: I may be out of sync a little bit over the next two to three days as
> I move in and transition to dorm life for my first year of university.
>
> --
> Ryan Rix
> == http://hackersramblings.wordpress.com | http://rix.si/ ==
> == http://rix.si/page/contact/ if you need a word         ==
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Scripting IRC Session at 16:00 Tuesday

[Richard Moore]

I'm at infosec right now. So can't attend. Please let me know what
happens. Rich.

On 4/27/10, Jonathan Riddell  wrote:
>
> We'll have the Plasma Scripting IRC session at 16:00UTC on Tuesday
> (today) in #plasma on freenode.  All welcome.
>
> Jonathan
> ___
> Kde-packager mailing list
> kde-packa...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-packager
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Implemented Plasma::GaussianBlur effect

[Richard Moore]

On Tue, Apr 20, 2010 at 4:49 PM, Aaron Seigo  wrote:
>> On 2010-04-20 15:18:25, Richard Moore wrote:
>> > Missing d pointer
>> > When not move the function that allocates the gauss vector into the 
>> > private object?
>> >
>
> it isn't a public class (none of the animations are), so a dptr isn't 
> actually needed in this case :)

It looked to me as if the intention was to have a reusable BlurEffect
that was a public QGraphicsEffect, with the animation merely using it.
If so then that would need the effect class to be public. Obviously if
the only user is the animation then my comments don't apply.

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

Re: Review Request: Implemented Plasma::GaussianBlur effect

[Richard Moore]

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


Missing d pointer
When not move the function that allocates the gauss vector into the private 
object?


- Richard


On 2010-04-20 15:07:52, Bruno Abinader wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3672/
> ---
> 
> (Updated 2010-04-20 15:07:52)
> 
> 
> Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson 
> Cavalcanti.
> 
> 
> Summary
> ---
> 
> Implemented the Plasma::GaussianBlurEffect effect, which subclasses from Qt's 
> QGraphicsEffect and provides an alternative blur effect to the default 
> (exponential blur). This effect is also animation-friendly (i.e. by altering 
> the alpha value).
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdelibs/plasma/CMakeLists.txt 1116913 
>   trunk/KDE/kdelibs/plasma/private/effects/gaussianblur.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/plasma/private/effects/gaussianblur_p.h PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/3672/diff
> 
> 
> Testing
> ---
> 
> An implementation of the Plasma::BlurAnimation, which can make use of both 
> this class and Qt's QGraphicsBlurEffect animation is available, along with 
> the required modifications on the Animation example plasmoid, which seemed to 
> work just fine :-)
> 
> 
> Thanks,
> 
> Bruno
> 
>

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

Re: Review Request: Implemented Plasma::GaussianBlur effect

[Richard Moore]

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


Missing d pointer
When not move the function that allocates the gauss vector into the private 
object?


- Richard


On 2010-04-20 15:07:52, Bruno Abinader wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3672/
> ---
> 
> (Updated 2010-04-20 15:07:52)
> 
> 
> Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson 
> Cavalcanti.
> 
> 
> Summary
> ---
> 
> Implemented the Plasma::GaussianBlurEffect effect, which subclasses from Qt's 
> QGraphicsEffect and provides an alternative blur effect to the default 
> (exponential blur). This effect is also animation-friendly (i.e. by altering 
> the alpha value).
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdelibs/plasma/CMakeLists.txt 1116913 
>   trunk/KDE/kdelibs/plasma/private/effects/gaussianblur.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/plasma/private/effects/gaussianblur_p.h PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/3672/diff
> 
> 
> Testing
> ---
> 
> An implementation of the Plasma::BlurAnimation, which can make use of both 
> this class and Qt's QGraphicsBlurEffect animation is available, along with 
> the required modifications on the Animation example plasmoid, which seemed to 
> work just fine :-)
> 
> 
> Thanks,
> 
> Bruno
> 
>

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

Activity Feedback

[Richard Moore]

Hi Ivan,

Some feedback on what's in kde-review:

- Looks pretty good, yay!

- Some of the param names specified in the doxygen magic don't match
the argument names, eg. ID when the param is called wid. This will
lead to doc warnings etc.

- No use of Q_PROPERTY etc. This one is the only substantive issue I
see. I think we should be defining the relevent property magic in
these classes before they get moved from review.

Other than that, nothing so far, but I'll keep looking. Looking good :-)

Cheers

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

Re: Calculator

[Richard Moore]

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

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

Cheers

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

Re: Fixing krunner's threading

[Richard Moore]

On Tue, Mar 2, 2010 at 2:49 PM, Thiago Macieira  wrote:
> I'm turning on QT_FATAL_WARNINGS by default in Qt debug builds (starting with
> Qt 4.7).
>
> It's time people stopped ignoring Qt warnings, which indicate that there are
> problems in your code. I can see these warnings coming out of plasma:

Note that people can enable those now by running their applications
with the environment variable set:

QT_FATAL_WARNINGS=1 myapp

This is a very valuable (and often missed) way of finding such issues.

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

Re: Plugins in WebView

[Richard Moore]

On Thu, Feb 25, 2010 at 10:10 PM, Mathieu Ducharme
 wrote:
> I would like to propose allowing plasmoids to enable plugins (ie.
> Flash) in the WebView widget.
> I can tell that I personally expected the current Web Browser to be
> able to play flash videos when I tried it...
>
> Anyway, I'm not sure if it is currently possible in C++ (does not seem
> so), but the scripting API does not have access to WebView settings so
> I added the following functions to Plasma::WebView
>
> - bool pluginsEnabled()
> - void setPluginsEnabled(bool)
>

One thing to watch with this is whether the plugins paint correctly
when an applet is rotated. I know ariya did some work on this, but I
don't know if it works in the current Qt release.

Cheers

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

Re: Webslice applet moved to kdereview

[Richard Moore]

On Fri, Nov 13, 2009 at 12:58 PM, Marco Martin  wrote:
> it would probably add too much complexity to all webviews with no gain...
> but what about Plasma::WebView::setSlice() and making webview itself manage
> slices?

In future we might want to add more stuff to the slices, eg. changing
the way focus etc. is handled. I'm not sure we could do this cleanly
if it was integrated into Plasma::WebView without making the code
there more complex.

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

Re: Kubuntu patches to plasma in kdelibs

[Richard Moore]

On Thu, Nov 12, 2009 at 8:30 PM, Aaron J. Seigo  wrote:
> personally, i'm not a fan of "are you sure, yes, yes?" dialogs everywhere.
> that it doesn't work everywhere is a deal breaker, but even then removing
> widgets by accident doesn't seem to be a huge problem "in the wild". i'd
> prefer to see the ability save/restore specific layouts as a more interesting
> solution to these kinds of potential issues.

Having an undo facility here would seem a nicer solution.

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

Re: Calculator runner

[Richard Moore]

On Wed, Oct 7, 2009 at 8:33 AM, Matteo Agostinelli
 wrote:
> Yes, I am aware of the existence that runner, however I was not
> entirely satisfied by its functionality.  First, instead of using
> libqalculate it uses an external 'qalc' process and then reads the
> result from standard output. Second, it is not easily configurable.

Running bc in the background like this was why I rewrote the
calculator runner to use qtscript in the first place.

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

Re: Review Request: Plasma + Qt Kinetic GSoC Project - Attempt 2

[Richard Moore]

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



/trunk/KDE/kdelibs/plasma/animations/animation.h


Not really clear to me what this function does.



/trunk/KDE/kdelibs/plasma/animations/animation.h


More protected data members.



/trunk/KDE/kdelibs/plasma/animations/expand.h


Move private data members into the dpointer



/trunk/KDE/kdelibs/plasma/animations/fade.h


Shouldn't this be called something like FadeAnimation. Fade is too general.



/trunk/KDE/kdelibs/plasma/animations/grow.h


Grow -> GrowAnimation



/trunk/KDE/kdelibs/plasma/animations/slide.cpp


This looks like a setter but is named like a getter.



/trunk/KDE/kdelibs/plasma/deprecated/animator.cpp


This class shouldn't be public


- Richard


On 2009-09-02 06:30:59, makmanalp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1512/
> ---
> 
> (Updated 2009-09-02 06:30:59)
> 
> 
> Review request for Plasma, Aaron Seigo and Alexis Menard.
> 
> 
> Summary
> ---
> 
> Okay, this is the "oh cr*p Alexis is leaving Tokamak" version, which means 
> I'm missing a couple of stuff but I want to get it in in time. Sorry about 
> this, but I have school now so I can't give my attention to this as much as I 
> could. What's missing is:
> 
> - Didn't dptr the private members yet because I got stuck trying to figure 
> out how I'd override render() (which would be in AnimationPrivate) in the 
> subclasses such as Grow etc. I guess I could have a function with the same 
> name in AnimationDerivedPrivate but it wouldn't exactly be overriding?
> - Didn't add factory methods for each animation type yet.
> - Didn't map the existing enums to new stuff (eg AppearAnimation etc)
> - Didn't figure out checking animation status / stop and pause etc.
> 
> Now that that's over, here's the good news:
> 
> - Oodles of general tidying up:
> - Moved everything into animations/ so it's neater.
> - Added license headers to everything.
> - Tidied up includes.
> - Split each class into its own file.
> - Added missing getters.
> - Consted as much as I can.
> - No more unnecessary this->es.
> - BaseAnimationElement is now AbstractAnimation.
> - Moved the duration variable (m_duration) down the hierarchy into Animation 
> because setting duration for groups is meaningless.
> - setObject() is called setWidget() now and is moved up the hierarchy into 
> AbstractAnimation since it was doing the same for both Animation and 
> AnimationGroup.
> - render() is no longer what it used to be, it's now a protected pure virtual 
> function in Animation that the subclasses must override. getQtAnimation() 
> does some common checking and then calls the render() of that subclass. 
> getQtAnimation() is the exposed interface.
> - getQtAnimation() takes a parent object to pass to Animations and 
> AnimationGroups to use when generating the QPropertyAnimations and 
> QAnimationGroups. When getQtAnimation() is used on AnimationGroups, the 
> generated sub-animations are now owned by the generated group.
> - The MovementDirection enum is now called AnimationDirection and is in 
> plasma.h
> 
> This is the essence of all changes. Documentation might be lagging behind, 
> I'll try to clean it up later on and comments on what's wrong are much 
> appreciated.
> 
> Thanks a lot in advance!
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1018731 
>   /trunk/KDE/kdelibs/plasma/animations/abstractanimation.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/abstractanimation.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animation.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animation.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animationgroup.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animationgroup.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/expand.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/expand.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/fade.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/fade.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/grow.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/grow.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/slide.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/anima

Re: Review Request: Plasma + Qt Kinetic GSoC Project - Attempt 2

[Richard Moore]

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



/trunk/KDE/kdelibs/plasma/animations/abstractanimation.h


We don't have protected data members in our public classes.


- Richard


On 2009-09-02 06:30:59, makmanalp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1512/
> ---
> 
> (Updated 2009-09-02 06:30:59)
> 
> 
> Review request for Plasma, Aaron Seigo and Alexis Menard.
> 
> 
> Summary
> ---
> 
> Okay, this is the "oh cr*p Alexis is leaving Tokamak" version, which means 
> I'm missing a couple of stuff but I want to get it in in time. Sorry about 
> this, but I have school now so I can't give my attention to this as much as I 
> could. What's missing is:
> 
> - Didn't dptr the private members yet because I got stuck trying to figure 
> out how I'd override render() (which would be in AnimationPrivate) in the 
> subclasses such as Grow etc. I guess I could have a function with the same 
> name in AnimationDerivedPrivate but it wouldn't exactly be overriding?
> - Didn't add factory methods for each animation type yet.
> - Didn't map the existing enums to new stuff (eg AppearAnimation etc)
> - Didn't figure out checking animation status / stop and pause etc.
> 
> Now that that's over, here's the good news:
> 
> - Oodles of general tidying up:
> - Moved everything into animations/ so it's neater.
> - Added license headers to everything.
> - Tidied up includes.
> - Split each class into its own file.
> - Added missing getters.
> - Consted as much as I can.
> - No more unnecessary this->es.
> - BaseAnimationElement is now AbstractAnimation.
> - Moved the duration variable (m_duration) down the hierarchy into Animation 
> because setting duration for groups is meaningless.
> - setObject() is called setWidget() now and is moved up the hierarchy into 
> AbstractAnimation since it was doing the same for both Animation and 
> AnimationGroup.
> - render() is no longer what it used to be, it's now a protected pure virtual 
> function in Animation that the subclasses must override. getQtAnimation() 
> does some common checking and then calls the render() of that subclass. 
> getQtAnimation() is the exposed interface.
> - getQtAnimation() takes a parent object to pass to Animations and 
> AnimationGroups to use when generating the QPropertyAnimations and 
> QAnimationGroups. When getQtAnimation() is used on AnimationGroups, the 
> generated sub-animations are now owned by the generated group.
> - The MovementDirection enum is now called AnimationDirection and is in 
> plasma.h
> 
> This is the essence of all changes. Documentation might be lagging behind, 
> I'll try to clean it up later on and comments on what's wrong are much 
> appreciated.
> 
> Thanks a lot in advance!
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1018731 
>   /trunk/KDE/kdelibs/plasma/animations/abstractanimation.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/abstractanimation.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animation.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animation.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animationgroup.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/animationgroup.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/expand.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/expand.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/fade.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/fade.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/grow.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/grow.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/slide.h PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animations/slide.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/animator.h 1018731 
>   /trunk/KDE/kdelibs/plasma/animator.cpp 1018731 
>   /trunk/KDE/kdelibs/plasma/deprecated/animator.cpp PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/plasma.h 1018731 
> 
> Diff: http://reviewboard.kde.org/r/1512/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> makmanalp
> 
>

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

Re: 4.4 call for runners (ideas)

[Richard Moore]

On Thu, Jul 23, 2009 at 10:45 AM, Jacopo De Simoi wrote:
> I'd really like to see more runners rolling around in 4.4; we already have 
> (in no particular order):
> * Martin's proposal for a kwin runner
> * the ones in playground (which are more or less mantained)
> * wish for device (mounting / unmounting) runner [1]
> * I also remember (imagined?) Chani mentioning she wanted to add basic plasma 
> widgets management with a runner

I'd like to see the wikipedia runner sebas and I wrote included,
especially for netbooks.

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

Re: Plasmate status

[Richard Moore]

On Mon, Jul 20, 2009 at 2:59 PM, Yuen Hoe Lim wrote:
> thing to do 'qwertyQWERTY012345etcetc' so maybe we could try a regular
> KLineEdit and do some form of validation?

See QRegExpValidator, that's what I used to validate stuff in the
.desktop file editor in plasmate.

Cheers

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

Re: [patch] Integrating support for v0.10 of notification spec

[Richard Moore]

2009/7/16 Aurélien Gâteau :
> Le mercredi 15 juillet 2009 12:35:00, Aurélien Gâteau a écrit :
>> This work was mainly discussed on the fd.o mailing list and patches has
>> been approved by Olivier Goffart at GCDS.  Unless someone objects, I
>> will commit the patches tomorrow morning.
>
> It's in, enjoy shared notifications!

Erm, isn't there currently a rather long discussion onthe XDG list
regarding this? Have you taken this into account?

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

Re: window management ideas

[Richard Moore]

On Fri, Jul 10, 2009 at 9:28 PM, Chani wrote:
> today I was told that wmii is a window manager that uses tags, so I need to go
> look into that.

http://dwm.suckless.org/

Also worth a look.

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

Re: KDE/kdelibs/plasma

[Richard Moore]

On Wed, Jul 8, 2009 at 3:56 PM, Marco Martin wrote:
> +ItemStatus status();

Const!

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

Re: knotificationitem: api prettiness

[Richard Moore]

On Wed, May 27, 2009 at 12:27 PM, Aaron J. Seigo  wrote:
> On Tuesday 26 May 2009, Marco Martin wrote:
>> 1) we have two way to set icons: by name and by pixmap, right now by name
>> is setIcon()
>> by pixmap is setImage()
>> (that should reflect in dbus too)
>> that looks a bit weird, would be better maybe setIconName() and setIcon()?
>
> another proposal:
>
> setIconByName
> setIconByPixmap
>
> that way we don't end up with a setIcon(QIcon) that the compiler would use
> silently when someone ports from KSystemTray to KNotificationItem (we really
> want to discourage use of the setIcon(QIcon) method) and it says exactly what
> it's doing.

This is a kind of +0.5. I can see the setters, but iconByName() and
iconByPixmap() seem a bit odd.

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

Re: knotificationitem: api prettiness

[Richard Moore]

On Tue, May 26, 2009 at 10:17 PM, Marco Martin  wrote:
> 1) we have two way to set icons: by name and by pixmap, right now by name is
> setIcon()
> by pixmap is setImage()
> (that should reflect in dbus too)
> that looks a bit weird, would be better maybe setIconName() and setIcon()?

To make it clear, the setImage() form takes a QIcon, while the
setIcon() form takes a QString. If it's called setIcon() then it
should take an icon.

>
> 2)  void showMessage(const QString &title, const QString &message, const
> QString &icon, int timeout = 1);
>
> should become
>
> void showMessage(const QString &message, const QString &title = QString(),
> const QString &icon = QString(), int timeout = 1);

The aim here is that you shouldn't need both a title and an icon just
to show a message. Those are extras, not things that should be
required.

>
> anything else important i forgot?
>
>
> aaand, can quite big changes like the icon methods still be done?
> and when? now? after 4.3?

The idea of having an experimental area in kdelibs was to handle
things like this, so - how do we do it in practice?

Cheers

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

Re: more on the systemtray

[Richard Moore]

On Sat, Mar 28, 2009 at 4:03 PM, Marco Martin  wrote:
> another way could be as fredrik suggested me today, just pass x11 pixmaps
> handles, no copy, really fast, but portability issues?

Just a note that I wrote a test case at tokomak 2 to check that
passing pixmap handles around still worked with 4.5 and it was fine.
That said however, I didn't try it with the raster rendering engine
which might break this. That would be a major problem for obvious
reasons.

Cheers

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

Re: another update on the systray and tiny api review

[Richard Moore]

On Mon, Mar 23, 2009 at 4:03 PM, Aaron J. Seigo  wrote:
>        bool hidden() const;
>        void setHidden(HideState state);

Asymmetry is evil. If set takes a HideState then get should return it.
Having another method that is a more general helper is ok though.

bool hidden() const;

void setHideState(HideState state);
HideState hideState() const;

This has the advantage of being clearer and also being possible to
make a Q_PROPERTY.

Cheers

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

Re: plasmate project: suggestion for timeline view

[Richard Moore]

On Tue, Mar 3, 2009 at 9:25 PM, Denis Kormalev  wrote:
> Hmm. Really good idea. But what should we do in large zoom (for example year)
> with big project with a lot of commits? Maybe some commits (with smaller
> number of changes) should be dropped from view?

Is a large project really within the target audience for plasmate? I
think we're more aiming at the smaller end of the scale, so a
less-is-more approach may well be more applicable.

Cheers

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

Trunk now depends on Qt 4.5

[Richard Moore]

Hi All,

Yes, it's that time again - qt-copy is now Qt 4.5rc1 and will be
tracking the Qt release candidates (plus any urgent fixes). This means
that people should no longer expect trunk to build or work against Qt
4.4, using Qt 4.5 features is both allowed and encouraged - go wild!

Upgrading trunk to use 4.5 means we all need to be extra careful when
backporting fixes to the 4.2 branch - this must remain compatible with
Qt 4.4. So remember, don't just blindly commit to the branch.

Apologies if this notification is a little late, but we can already
see that trunk relies on 4.5 from a functional perspective so we might
as well make it official.

Regards

Rich on behalf of the release team.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma and KWin Integration

[Richard Moore]

Hi All,

Here's the write up of the kwin and plasma integration discussion at Tokamak.

Cheers

Rich.

Plasma and KWin Integration
===

This is the results of the discussion on the areas we (the plasma team) feel
we need help from the kwin team to produce better integration. It's a mixture
of issues from fairly trivial ones, through complex ones, to those that come
down to issues with specifications like NETWM. The aim is to provide users
with the best possible experience running a pure-KDE desktop.

1. Ability to obtain pixmaps of windows.

There are a number of effects that would be possible within plasma and other
applications if it was possible to obtain a full pixmap of a window (even if
it is obscured). This information is available to kwin and used for
compositing, the idea would be to publish it for use by other applications.

Our idea was that maybe this could be handled in a suitably performant way by
using QPixmaps that share an XPixmap handle between both kwin and the client
application (plasma in our case).


2. Better thumbnail scaling.

The scaling algorithm used by kwin to create the window thumbnails seems to
produce pretty poor results, comparing the results with Qt's smooth scale for
example. Looking at the code, they appear to be using a codepath that
generically supports all the transformations used in effects. Could we get
better results by having a codepath that is specifically designed for scaling?

3. Ability to have windows on a specific set of virtual desktops.

Being able to say a window is on desktop 1 and 3 for example. This one isn't a
big deal, just a 'nice to have'.


4. Per-desktop struts.

At the moment struts apply to all desktops, which doesn't make sense if (for
example) you have different panel configurations on different desktops. It
could also be an issue if a particular desktop was a full-screen media center,
though in this latter case it can be worked around.


5. Shadows of shaped windows.

At the moment the shadows of shaped windows don't really work, could we have
something like a separate shadow mask?


6. Marco created a patch that added a shadow to the plasma panel, and whilst
kwin handled the strut correctly in some cases, it did not in others. For
example, the magnetic window borders stuck to the shadow rather than to the
edge of the panel.


7. Theming of kwin dialogs to match the rest of the desktop furniture.

Things like the window menu are part of the desktop rather than part of
applications and it would be great if they were coloured like the other pieces
of furniture rather than like the applications they manage. The same thing
applies to a number of other things drawn by kwin such as in the box switch
effect.


8. Document modal windows.

Having a way to handle document-modal windows along the lines of the Sheets in
MacOS. These would be positioned over their parent window and move with the
parent.


9. Hide the panel when zooming out to show the containments.

As discussed already by Sebas, and patch provided.


10. Alt-Tab to desktop and panel

The desktop and panel need to be able to get the keyboard focus to allow users
without keyboards to activate and use them.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: tokamak 2, my phonenumber

[Richard Moore]

On Tue, Feb 3, 2009 at 7:29 PM, Rob Scheepmaker
 wrote:
> On Monday 02 February 2009 21:19:04 Nuno Pinheiro wrote:
>> hey hee goes my phone number you might want to call wen you get to porto or
>> for any other reason
>>
>> +351 96 762 87 28
>
> Sounds useful. I'm scheduled to arrive at the airport of Oporto at 16:15 on
> Thursday. Any other people arriving around the same time?

I'll be arriving an hour before you, I don't mind hanging around if
you like. Call me +44 7968 488 568. I'll be the one who looks like
this: http://www.flickr.com/photos/richard_moore/476708071/

Cheers

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

Re: tokamakII URGENT

[Richard Moore]

Sorry to be slow (again). No need for veggie for for me.

Cheers

Rich.

On Thu, Jan 22, 2009 at 8:16 PM, Nuno Pinheiro  wrote:
> 2 questions! need ansers ASP :)
> frist one
>  vegie meals I need to sort that out with the catering so i need to know how
> many people will require vegie food.
> second
> as every one that is going to give a presentation told me what their
> presentation will be?
>
>
>
>
>
> --
> Oxygen coordinator
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak Meeting II

[Richard Moore]

I've got the following flights:

5/2/09
Manchester -> London BA2905
London -> Oporto TAP 0333 Arriving 15:15

10/2/09
Opoto -> Frankfurt, 4551 Lufthansa departing 11:55
Frankfurt -> Manchester 4856 departing 16:45

Cheers

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

Re: plasma 4.2 feature freeze meeting

[Richard Moore]

I can do 15:00 UTC Saturday.

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

Re: plasma design online

[Richard Moore]

On 9/11/08, Riccardo Iaconelli <[EMAIL PROTECTED]> wrote:
> On Thursday 11 September 2008 20:25:04 Alex Merry wrote:
> > All the files are currently empty.
>
> Sorry, I had a little bug in the update script, try now. =)

They still seem to be empty.

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

Re: KDE/kdebase/workspace/plasma/plasma

[Richard Moore]

On 8/23/08, Aaron J. Seigo <[EMAIL PROTECTED]> wrote:
> SVN commit 851124 by aseigo:

I wonder if it might be possible to make a reusable class for mouse
over activation areas like this? Obviously the number of spots where
it could be used is small, but it might be a nice-to-have.

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

Re: System tray rewrite ready for review + portability?

[Richard Moore]

On 8/18/08, Gerhard Gappmeier <[EMAIL PROTECTED]> wrote:
> independent from your changes I see a problem with the X11 includes.
> KDE4 should run on any OS including Windows and this includes break
> portability.

This is probably destined to be part of the workspace/plasma rather
than plasma libs, so there is no requirement to be portable to non-X11
platforms.

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