Re: libplasma2 and QtSvg

[Alexis Ménard]

On Mon, May 16, 2011 at 11:09 PM, todd rme  wrote:
> On Mon, May 16, 2011 at 7:19 PM, Alexis Ménard  wrote:
>> On Fri, May 13, 2011 at 9:18 PM, Davide Bettio  wrote:
>>> Hi,
>>> What about performances?
>>
>> Well unless we start hacking it, we can't really tell. But in the web
>> context, SVG renders pretty fast.
>
> I think the concern is more the overhead from loading all of webkit
> just for rendering SVGs, rather than the speed of the rendering.

In many cases Plasma loads already WebKit so...

>
> -Todd
> ___
> 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: libplasma2 and QtSvg

[Alexis Ménard]

On Fri, May 13, 2011 at 9:18 PM, Davide Bettio  wrote:
> Hi,
>
> On 05/13/11 15:39, Alexis Ménard wrote:
>> To me the solution lies in WebKit, I asked if the API was stable and
>> it seems that yes it's pretty good. So if we have an interest (which I
>> believe we do a lot), then we should make the QtSvg on top of WebKit
>> API happens.
>>
>> :D.
> What about performances?

Well unless we start hacking it, we can't really tell. But in the web
context, SVG renders pretty fast.

>
> Bye,
> Davide Bettio.
>
>
>
> ___
> 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: libplasma2 and QtSvg

[Alexis Ménard]

And I'll be happy to help on that respect since I'm working on WebKit every day.

On Fri, May 13, 2011 at 10:39 AM, Alexis Ménard  wrote:
> It's Depecrated, it doesn't mean someone can't come up with a replacement.
>
> QtSvg is buggy, just ask Nuno and it will tell you how much he hates
> that module. It supports only a subset of the potential of SVG spec
> and when I was in Nokia there was no-one to work on it, and we even
> broke it badly one day.
>
> To me the solution lies in WebKit, I asked if the API was stable and
> it seems that yes it's pretty good. So if we have an interest (which I
> believe we do a lot), then we should make the QtSvg on top of WebKit
> API happens.
>
> :D.
>
> On Thu, May 12, 2011 at 5:28 PM, Aaron J. Seigo  wrote:
>> On Thursday, May 12, 2011 19:03:27 Davide Bettio wrote:
>>> As you can see here [1] QtSvg has been marked as deprecated.
>>> Do we have any plan about it?
>>
>> no, because Qt doesn't have a clear plan about it. fortunately for us, QtSvg
>> is completely hidden behind Plasma::Svg so we can swap it out once Qt figures
>> out how it will expose the SVG implementation in WebKit for general
>> consumption.
>>
>> --
>> Aaron J. Seigo
>> humru othro a kohnu se
>> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>>
>> KDE core developer sponsored by Qt Development Frameworks
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: libplasma2 and QtSvg

[Alexis Ménard]

It's Depecrated, it doesn't mean someone can't come up with a replacement.

QtSvg is buggy, just ask Nuno and it will tell you how much he hates
that module. It supports only a subset of the potential of SVG spec
and when I was in Nokia there was no-one to work on it, and we even
broke it badly one day.

To me the solution lies in WebKit, I asked if the API was stable and
it seems that yes it's pretty good. So if we have an interest (which I
believe we do a lot), then we should make the QtSvg on top of WebKit
API happens.

:D.

On Thu, May 12, 2011 at 5:28 PM, Aaron J. Seigo  wrote:
> On Thursday, May 12, 2011 19:03:27 Davide Bettio wrote:
>> As you can see here [1] QtSvg has been marked as deprecated.
>> Do we have any plan about it?
>
> no, because Qt doesn't have a clear plan about it. fortunately for us, QtSvg
> is completely hidden behind Plasma::Svg so we can swap it out once Qt figures
> out how it will expose the SVG implementation in WebKit for general
> consumption.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KWin and Qt5

[Alexis Ménard]

Hi,

There are big differences between QGPW and QWidget sitting on top of
the scene graph.

QPW we needed to :

- Convert all events from a QWidget (QGV) to QGS then back to QWidget.
- Hook up the painting code from one QPainter to the paintEvent of QWidget.

QGV was a framework sitting on top of another one (QWidget) trying to
integrate again with the one it's sitting on.

The way I see the QWidget integration with scene graph is WAY more simple :

- No event redirections/machinery (this is managed by Lighthouse already).
- All drawing calls made on QPainter goes to the scene graph.

Not sure they will redo the backing store related stuff. It will be
most probably not fast but good enough for desktop usage and as a
legacy framework.

So I believe it's WAY less cave-heats than QGP.

On Mon, May 9, 2011 at 6:41 PM, Marco Martin  wrote:
> On Monday 09 May 2011, Aaron J. Seigo wrote:
>> On Monday, May 9, 2011 19:38:28 Marco Martin wrote:
>> > On Monday 09 May 2011, Martin Gräßlin wrote:
>> > > Hi all,
>> > >
>> > > yes it's early, but there was something in Lars's blog post [1] which I
>> > > need to braindump/discuss. Let me quote the important part: "Qt will
>> > > require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the
>> > > scene graph (not the scene graph on top of QWidgets as is currently
>> > > done with Qt 4)."
>> >
>> > this sounds to me as qgraphicsproxywidgets pain all over again and i
>> > really
>>
>> the one ray of hope i have is that QGraphicsProxyWidget had to work with
>> QWidget as it was. in Qt5, there is the opportunity to break ABI and allow
>> this to be done Properly(tm) by making necessary changes in QWidget itself.
>>
>> we need to get involved early :)
>
> indeed.
> and this influences the design of plasma2 quite a bit as well
> (we could be forced to eat the cake, even if a lie ;)
>
> --
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasmoidviewer crashes

[Alexis Ménard]

run plasmoidviewer in gdb --args, it will give you a backtrace I believe.

On Thu, Apr 7, 2011 at 9:11 AM, Tsiapaliwkas Giorgos  wrote:
> hello,
>
> plasmoidviewer crashes when i change kickoff to classic menu.Since there is no
> section for plasmoidviewer at the bugzilla i consider it properly to start a
> thread here.
>
> Without plasmoidviewer i can't debug classic kickoff.
> I know that everyone is very busy,so can u suggest me an other way to debug
> kickoff?
>
> thanks in advance
> ___
> 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: mentors needed

[Alexis Ménard]

On Thu, Aug 19, 2010 at 11:51 AM, Marco Martin  wrote:

> On Thursday 19 August 2010, Lydia Pintscher wrote:
> > Heya folks :)
> >
> > I need mentors for a GSoC-like program in Canada asap so please get
> > back to me within the next two days.
> > What's needed:
> > - a mentor who can come to Toronto from October 1-3.
> > - a chunk of work that's suitable for a group of 5-10 upper-year
> > computer science students to work on for a semester. They have about
> > 10 hours a week available between September and the beginning of
> > December.
> >
> > Let me know if you're interested to mentor, have a project for them
> > and can travel to Toronto on these days. Let's get some more students
> > to write code for KDE  :)
> >
> > You can find out more about the program at http://ucosp.ca/about/
>
> help in mentoring... yes
>

Same.


> being in toronto 1st october h, a bit out of question i fear :/
>
>
>
Well, If I change my way back from brazil through toronto. I'm travelling
back the 30th of September.


> possible projects, tons, like
> - someone that helps with the activity stuff, too much to do, not enough
> people with enough time eheh ;)
> - Celeste talked to me at akademy about if it was possible to do a
> statistic
> crawling plasmoid on notifications, for an usability study (would be a
> throw
> away thing but we would have a serious study that validates, or invalidates
> our system, important anyways)
> - the usual mobile stuff
> - continuing one of the gsocs (maybe with the student that becomes a mentor
> :p)
>
> but yeah, all useless if there isn't anybody (depends on the cost/gain to
> be
> there over work and people that could derive from i guess)
>

+1


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

Re: QGraphicsWidget::geometryChanged problem in 4.7

[Alexis Ménard]

On Wed, Aug 11, 2010 at 8:22 PM, Aaron J. Seigo  wrote:
> On August 11, 2010, Alexis Ménard wrote:
>> On Wed, Aug 11, 2010 at 12:21 AM, Aaron J. Seigo  wrote:
>> > On August 10, 2010, you wrote:
>> > > > do you agree that this should get fixed in Qt?
>> > >
>> > > Obviously. Will do tomorrow ASAP and ask integration in 4.7.0
>>
>> Here is the report : http://bugreports.qt.nokia.com/browse/QTBUG-12813
>>
>> I already have the patch, I'm waiting for the review.
>
> terrific.

Pushed 3ee89bc0830f69d44f272eff5a0c886bff33c92e on its way inside the
CI. Will ask inclusion in 4.7.0.

>
>> What about moving the signal as a protected method and the
>  implementation
>> call the parent?
>
> ooh, i love it. nasty, but it works :) go-go-Gof!
>
> --
> Aaron J. Seigo
> humru
>  othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: QGraphicsWidget::geometryChanged problem in 4.7

[Alexis Ménard]

On Wed, Aug 11, 2010 at 12:21 AM, Aaron J. Seigo  wrote:

> On August 10, 2010, you wrote:
> > > do you agree that this should get fixed in Qt?
> >
> > Obviously. Will do tomorrow ASAP and ask integration in 4.7.0
>

Here is the report : http://bugreports.qt.nokia.com/browse/QTBUG-12813

I already have the patch, I'm waiting for the review.


>
> awesome :) thanks x 1000.
>
> > > and then i just need to
> > >
> > >  figure out
>  how to make it so that we don't get these errors:
> > > QMetaObject::indexOfSignal: signal geometryChanged() from
>  QGraphicsWidget
> > >
> > >  redefined in Plasma::Applet
> >
> > Well if you compile it out it should work right? With 4.7 and after the
> > signal is not defined anymore in Plasma::Applet.
>
> the code will work, but my concern is binary compatibility in libplasma. i
> don't believe the signal can be removed without harming BC. and then when
> items connect to the signal in Plasma::Applet ... i'm not sure which signal
>  they will end up connecting to. not good :/
>

What about moving the signal as a protected method and the implementation
call the parent?


>
> will have to find some sort of work around...
>
> > I'm building my KDE against
>  4.7, it's funny I've never seen this issue.
> >
> > > erf. hopefully QObject::connect is up to the task of connecting two
> > > signals of the same name from two different objects in the inheritance
> > > hierarchy. i
> > >
> > >  don't have a good feeling about that.
> >
> > Me neither.
>
> well, huzzah for that then ;)
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG
>  Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: QGraphicsWidget::geometryChanged problem in 4.7

[Alexis Ménard]

On Tue, Aug 10, 2010 at 11:49 PM, Marco Martin  wrote:

> On Tuesday 10 August 2010, Alexis Ménard wrote:
>
> > >  figure out how to make it so that we don't get these errors:
> > > QMetaObject::indexOfSignal: signal geometryChanged() from
> QGraphicsWidget
> > >
> > >  redefined in Plasma::Applet
> >
> > Well if you compile it out it should work right? With 4.7 and after the
> > signal is not defined anymore in Plasma::Applet. Am I missing something
> > here (it's 23:35 here :D).
>

That's a very GOOD point mouahahahah.


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

Re: QGraphicsWidget::geometryChanged problem in 4.7

[Alexis Ménard]

On Tue, Aug 10, 2010 at 11:24 PM, Aaron J. Seigo  wrote:

> hi Alexis ...
>

Hi,


>
> QGraphicsWidget now has a geometryChanged signal in 4.7. Plasma::Applet
> also
> has one. which means we'll need to conditionally compile it out in
>  libplasma. so far, not a huge deal.
>

mmm, I didn't see it. strange.


>
> but there are two problems with QGraphicsWidget::geometryChanged:
>
> 0) it is
> called before resizeEvent is sent, which means that subclasses have no
> chance to do any internal adjustments before the outside world is told that
>  geometry is changing
>

Well probably a good idea, easy to fix.


>
> 1) it only emits this when setGeometry is called. QGraphicsItem::setPos
> also
> affects the geometry (in fact, setGeometry calls setPos internally), but
> there is no signal emitted in this case. meaning that the "geometryChanged"
>  signal doesn't actually always get emitted when geometry changes.
>
> :/
>

That's a bug...Good catch


>
> without touching Plasma::Applet, we have the problem of the signal being
> emitted twice (once from QGraphicsView and once from Plasma::Applet), which
> we can just compile out as mentioned above ... if only it worked properly
>  :)
>

Yes...


>
> do you agree that this should get fixed in Qt?
>
>
>
Obviously. Will do tomorrow ASAP and ask integration in 4.7.0


>
> and then i just need to
>  figure out how to make it so that we don't get these errors:
>
> QMetaObject::indexOfSignal: signal geometryChanged() from QGraphicsWidget
>  redefined in Plasma::Applet
>
>
Well if you compile it out it should work right? With 4.7 and after the
signal is not defined anymore in Plasma::Applet. Am I missing something here
(it's 23:35 here :D).

I'm building my KDE against 4.7, it's funny I've never seen this issue.


> erf. hopefully QObject::connect is up to the task of connecting two signals
> of the same name from two different objects in the inheritance hierarchy. i
>  don't have a good feeling about that.


Me neither.


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

Re: plasma memory/pixmap leak ?

[Alexis Ménard]

On Wed, Jun 2, 2010 at 7:28 PM, Aaron J. Seigo  wrote:
> On June 2, 2010, todd rme wrote:
>> On Wed, Jun 2, 2010 at 12:18 PM, Aaron J. Seigo  wrote:
>> > On June 2, 2010, R.F. Pels wrote:
>> >> So, basically, the short answer is 'No'.
>> >
>> > there is no instrumentation system, no. much like most other plugin based
>> > software out there. if you'd like to develop something, that'd be great.
>> >
>> > we do have ways of finding out where problems are, though it's a bit
>> > manual and involves running individual components. at least plasma is
>> > highly componentized enough that things can be tested in relative
>> > isolation.
>>
>> Would it be possible to set up a script that would automatically run
>> plasmoidviewer for a set period of time on each plasma applet and
>> measure memory output from the process over time?
>
> yes, but what's really required is user interaction.
>
> this could be driven by a, say, javascript env that allows authoring scripts
> which push synthetic events... it's all possible, but it needs time and effort
> put into it.

I catched the pixmap leak of the systray back in time by putting a
QDebug where Qt creates a X pixmap and use a static number to count
the allocations. Then when Qt deallocate the XPixmap I decrease this
static number. When you interact with Plasma you can see if this
number is growing too fast. No the best way though but at least I
catched this leak.

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

Re: Optional Qt 4.7 dependency (Qt 4.7 pre-release users should read this)

[Alexis Ménard]

Well the beta is out now :D.

2010/5/6 Aurélien Gâteau :
> Hi,
>
> Unless someone objects, I am going to commit this small attached patch to
> kdelibs tomorrow. It brings back icons in KStatusNotifierItem menus.
>
> This patch takes advantage of QIcon::name(), which was introduced in Qt 4.7.
> It does not break build for Qt 4.6 users as the code is in a #if QT_VERSION
>>= 0x040700 block, but it will break the build for Qt 4.7 pre-release users
> because QIcon::name() is in 4.7 git branch, but is not in 4.7 TP.
>
> kdelibs does not depend on Qt 4.7 yet, but since Qt 4.7 is planned for
> release on week 23, we could make kdelibs 4.5 depends on Qt 4.7.
>
> Aurélien
>
> ___
> 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: Feedback wanted: Improvements to current Qt Widget/style mechanism

[Alexis Ménard]

On Wed, Apr 7, 2010 at 7:18 AM, Caio Marcelo de Oliveira Filho
 wrote:
> Marco Martin  writes:
>
> Hello Marco,
>
>> on one hand, i feel in order to succeed the normal qwidgets need to use this
>> (so until qt5 their api would be a mis of model and view related stuff),
>> but this brings to the question:
>> what about subclasses of qwidgets that subclassed it for functionality? (i.e.
>> kpushbutton)
>
> The current KPushButton would not be affected as there will not be a break in
> Qt's binary compatibility. See below if you were talking about migrating the
> current KPushButton to the new approach.
>
>
>>> > a) Style::populate(Widget, Model = 0) method
>>> >
>>> >    Style classes provide a "populate" method that is called by styleable
>>> >
>>> > widgets
>>> >
>>> >    upon their construction. The arguments are the widget itself, it will
>>> >    be the parent of the primitives created by the style, and the
>>> >    optional
>>> >
>>> > model (backend) used by this widget.
>>
>> uh, so would be the primitive qobjects?
>
> Yes, they have to be at least QObjects because we want to make use of
> properties and notify signals in those models. Note that this is the
> point of view of the Style, for the Style class, its really not
> important the exact type here, only that it is a QObject.
>
> The fact that it has a more specific type may or may not be important,
> if you are populating your widget with a QML component, it isn't, you
> simply will load the "Button.qml" with a property 'model' available and
> put the model there.
>
> However, if you're building a C++-based style, you can either use just
> the QObject interface, or (in the case of our "populator system") cast
> the correct type of the Model that you expect from that widget type.
>
>
>> who would decide what the binding is?
>
> The Style. That has to do with look and feel, only the Style knows which
> primitives should react to changes in the widget/model. And also which
> primitives should affect the model and widget (the MouseArea for
> instance).
>
>
>> It's a sane approach, however, my concern is how it goes together everything
>> it exists right now:
>> as i said many qwidget are subclassed for a mix of look and functionality
>> requirements, so while  wouldn't be possible to change kpushbutton and the
>> likes to the new system overnight, even if it wouldn't be necessary to do big
>> binary incompatible changes.
>> i don't have clear answers, but it should be done in the way it would provide
>> the smootherst transition path compared to what we have now
>
> Our proposal suggests that widgets are implemented in a way that the
> "logic" parts are separated. This "logic" parts of widgets can be reused
> internally by existing Qt4 QWidgets -- some of those parts even can be
> extracted from the Qt4 QWidgets themselves.
>
> Those parts, if made public, could be used internally by KWidgets as
> well. Imagine a "QButtonModel", that could be extended with more
> functionality (let's say, KAuth integration) and a KButtonModel could be
> created. This KButtonModel could be used as implementation detail of
> both KPushButton and Plasma::PushButton.
>
> We understand that this by itself already is a good thing for KDE, that
> uses the entire KPushButton to get the behaviour for
> Plasma::PushButton. Even better, if a new "environment" appear (let's
> say, Qt make a new canvas or this new Style approach in a future version
> of Qt), will be easy to just reuse the logic in KButtonModel.
>
> For the Style part, we are not so sure if today's QWidget can benefit
> from that, but we are trying to propose something that minimize (and in
> some cases even reduce to zero) the need of "redoing it all over again
> for the next Canvas".
>
> The graph scene assumption that is in the Style proposal probably will
> be still appliable in the "next Canvas", so even if the "basic types"
> change, the core of a Style (and of the widgets visual parts) can still
> be easily portable.
>
>
> Hope that it clarified a little bit the issue.

Glad to hear that is exactly the idea i had back in January...I think
I talked about it to Marius, Artur and Gabriel.

Dude seriously I need to come to Recife!

>
>
> Cheers,
>
> --
> Caio Marcelo de Oliveira Filho
> OpenBossa - INdT
>
> ___
> 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 listview

[Alexis Ménard]

On Wed, Apr 7, 2010 at 7:49 PM, Marco Martin  wrote:
> On Wednesday 07 April 2010, Reza Shah wrote:
>> Hi,
>> I created a wrapper for QListView inside QGraphicsProxyWidget, because
>> i have a plasmoid which need a listview.
>> Is it possible if my wrapper can be included in plasma library?
>>
>> Here are the source codes
>> http://websvn.kde.org/trunk/playground/base/plasma/applets/knewstuffplasmoi
>> d/src/listview.h?revision=1112072&view=markup
>> http://websvn.kde.org/trunk/playground/base/plasma/applets/knewstuffplasmo
>> id/src/listview.cpp?revision=1112072&view=markup
>>
>> PS:let me know if i didn't put proper credit to copyright
>
> I'm not sure, i am not even very happt to have put a qtreeview in here now, qt
> itemviews and qgraphicsviews really clash together, besides is possible to
> have a single level treeview to behave almost like a listview..

Plus it's inefficient to use it outside the desktop world (then if you
add it, you should say it in the doc).

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

Re: Dot article on activities needed, maybe more?

[Alexis Ménard]

I think for the Plasma-Mobile work we communicate quite well, total of
4 blog posts right after the event. And one more after Bossa (2 weeks
after Tokamak).

I agree that Sebas should not be alone for it. I'm really bad to write
articles (i'm a dev) but if someone need videos/picture of
Plasma-Mobile on the N900 just drop me an email.

Anyway thanks to people.

On Mon, Apr 5, 2010 at 9:52 PM, Chani  wrote:
> a funny thing... it actually wasn't until the end of tokamak 3 that I realised
> it was someone in plasma writing the dot articles for tokamak. I guess I
> assumed that magical fairies did all that writing ;)
>
> now, I can be rather oblivious to simple things like that at times... so maybe
> it's just me... but it seems like the "we need dot articles" thing could have
> been communicated more clearly, earlier. skimming back through archives, I
> don't see any threads on this mailing list mentioning the need to write
> tokamak4 dot articles around the time tokamak4 ended. and asking people who
> are already overwhelmed to do more things doesn't work very well.
>
> may I suggest that next tokamak, someone asks the mailing list for volunteers
> to write articles? I mean, it doesn't guarantee responses, but surely it can't
> hurt...
>
>
> ..
> for that matter, do we have a laundry-list of "things that have to be done for
> a sprint" anywhere? ... erg. we have a stub, and a blog link:
> http://community.kde.org/KDE_e.V./Sprints#Sprint_HOWTO
> it's about how to start a sprint, not about how to finish it... hmmm.
>
> --
> This message brought to you by eevil bananas and the number 3.
> www.chani3.com
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Akademy talks, BOFs and workshops

[Alexis Ménard]

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

Artur and me applied for a technical paper + 45 min talk.

>
>> and I am plasnning to submit one with argument joint plasma-netbook+plasma-
>> mediacenter (yes, /me bad, will submit the abstract asap)
>
> Perfect.
>
>> I am going for a 30 min one, but if someboby  working on the mediacenter can
>> guarantee that he can do that part we can go for a 45 minutes one.
>> (but this has to be decided N-O-W :p)
>
> Keep in mind that 45 min talks need a paper submission as well.
>
>> if somebody has a brilliant idea for a couple of lighting talks would be nice
>> too.
>> about a BOF: sounds nice, what do you guys think?
>
>
> Cheers
> Lydia
>
> --
> Lydia Pintscher
> Amarok community manager
> kde.org - amarok.kde.org - kubuntu.org
> claimid.com/nightrose
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PMC use case

[Alexis Ménard]

On Tue, Mar 30, 2010 at 12:42 PM, Sebastian Kügler  wrote:
> On Monday 29 March 2010 21:02:06 Aaron J. Seigo wrote:
>> thoughts?
>
> I don't agree with the "PMC should target notebooks" as primary usecase bit. 
> I really
> think that this thing should be developed to have its UI run on a TV, 
> preferably HD-
> Ready or Full-HD resolution. Those devices tend to be easily hooked up with a
> computer nowadays (as Jane knows), (ours has both HDMI and D-Sub and is also 
> a fine
> monitor). The key difference is wether to rely on a mouse pointer or not, and 
> how
> interaction looks like otherwise.
>
> Now that's of course me being selfish, because I, at some point, want to use 
> PMC on
> this kind of device as my Media Center. What I have in mind is roughly:
>
> - PMC running on a netbook or comparatively cheap hardware
> - easily controllable from a 10 foot distance, using a remote control or a 
> wiimote
> - connected to the Internet, so web video (youtube, blip, miro, ...) should 
> be first
>  class citizens
> - access to the local and networked media library (in the same way ("it 
> doesn't
>  matter where it's stored") via SMB, uPnP, HTTP
> - built-in web browser that's basically usable by a remote / wiimote(*) as 
> well
> - full-screen media player with overlaid Plasma widgets to control playback 
> and
>  playlist
> - good bookmarking support (favourites for web and local videos, easy way to
>  find/remember the current/next episode of a TV show)
> - contextual information for content (Nepomuk, IMDB, discogs, ...)
> - Remotely editable playlist (pull up your notebook / n900 and edit the 
> playlist on
>  the PMC without interrupting playback)
>
> The key is really to support commodity hardware, things people already have 
> or can
> get rather inexpensively and turn it into a media center with little effort
> (basically install PMC, and hook up the TV to it).

And why not targeting the problem at the source, integrating the
software into the TV directly.

>
> (*) I've played around with a wiimote last weekend and now have a Qt-style 
> class that
> can be used to interact with the features of a wiimote, buttons, LEDs, 
> accelerometers
> and haptic feedback at this point. I've got myself a copy of O'Reilly's 
> "designing
> gestural interfaces", and I think we can get quite far, from a functionality 
> and an
> intuitiveness point of view by using such a device as main controller. That's
> something I work on in a lost hour here and there.
>
> Some of the above are quite specific ideas, and it might be different from 
> what other
> people think about it. In any event, while developing, please keep the above 
> in mind,
> so I won't have to do it all myself when I scratch my itches. :)
>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Javascript Bindings inside QML

[Alexis Ménard]

On Wed, Mar 24, 2010 at 4:15 AM, Marco Martin  wrote:
> On Tuesday 23 March 2010, Aaron J. Seigo wrote:
>> On March 22, 2010, Alexis Ménard wrote:
>> > Hello,
>> >
>> > I just wonder which part of the Plasma bindings we want to put into QML :
>> >
>> > http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API
>> >
>> > All the UI related stuff is pretty much useless because QML provides
>> > those facilities. It would be nice to have a list so we can think
>> > about what we can do for it.
>>
>> the UI related API can be divided (roughly) into three bits:
>>
>> * the classes in kdelibs/plasma/widgets/ being loaded via the QObject
>> bridging provided by QtScript. we should have those widgets available from
>> QML.
>
> as far i seen it's pretty easy to bind any qgraphicswidget into qml..
> the bad news is that it will behave as a second class citizen not being a
> QDeclarativeItem, so can't be in a qanchorlayout ar directly be a listview
> delegate for instance, everything will have to go for a proxy object called
> GraphicsObjectContainer, i'm still a bit uneasy with this one.

This is about to change. QGraphicsObjectContainer will disappear.

>
>> * bindings for the QGraphicsLayout classes. those are unneeded in QML.
>>
>> * QPainter and related; we don't need any of that since there is no direct
>> painting in QML. the bindings for QRectF, QPoint, QColor, etc may or may
>> not be of use, but are small and would be nice to have if QML doesn't
>> already provide for nice programmatic access to things like colors.
> pretty sure QSizeF is accessible as size.width and size.height, used it and
> would be nearly impossible to do any good with qgraphicswidgets in qml
> otherwise, hope also the other stuff is present
>
>
>> all the rest of the JS bindings, which are mostly about things other than
>> GUI, ought to be in there.
> yeah, dataengine, services etc, all vital
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workaround in WebView...

[Alexis Ménard]

On Wed, Mar 24, 2010 at 3:35 AM, Aaron J. Seigo  wrote:
> On March 22, 2010, Alexis Ménard wrote:
>> There are two crashes because of this workaround.
>>
>> One in QGV is fixed and is on its way to 4.6.3
>>
>> The other is reported :
>>
>> https://bugs.kde.org/show_bug.cgi?id=227639
>
> that looks a lot like a bug in QGraphicsView as well: it's crashing in the bsp
> tree indexing.

Well the workaround trigger something that's it's hard to expect :
asking the content of the scene before the first round in the event
loop.

>
>> It would be nice if the original writer of the workaround can help the
>> guys of QtWebkit. I'm kinda busy right now.
>
> i have.
>
>> Next time when adding a workaround please open a bug report in the
>> upstream project.
>
> i did. with code showing the problem, minutes after committing the work around
> to libplasma so at least plasma-desktop wouldn't crash horribly.
>
> nor was i the only one to do so: there's a near duplicate report that's also
> been triaged. it's not quite the same crash, but has the same underlying
> reason.
>
> since we're handing out advice to each other, let's try this: in future those
> working on webkit and/or qgraphicsview might wish to test things like "let's
> open a combobox on a qwebpage that's in a qgraphicsscene" before making a
> release?

Well sorry to say that you experienced bad bugs like this one but in
the other hand QGraphicsView is the most tested framework in Qt and we
did massive refactoring without _too much_ breakage. Plasma-Mobile
wouldn't exist without those changes. At each bug reported/fixed an
autotest is added and the coverage is quite good. Concerning WebKit I
can't talk, I was not part of the implementation. But if you've
reported the bug then my bad i apologize. I was not able to find it
that's why.

>
> the number of these kinds of very basic yet critical (e.g. crash causing)
> problems that are making it into Qt releases is discouraging.
>
> this one wasn't the result of some accidental interaction between two Qt
> modules (QtWebkit and QGraphicsView), this was the result of a very poor
> implementation of QGraphicsView support inside of QtWebkit. it is/was code in
> QtWebkit that specifically uses QGraphicsView and which was full of
> assumptions that was quite plainly and obviously (just from reading the code,
> not even from testing) _wrong_.
>
> if it were simply a matter of "the plasma guys put QtWebkit and QGraphicsView
> together in a way we didn't expect" i'd be more charitable about the
> situation. but this is a crash that was introduced by Qt hackers working on
> integrating two Qt modules.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workaround in WebView...

[Alexis Ménard]

arf sorry wrong copy paste

here is the report https://bugs.webkit.org/show_bug.cgi?id=36436

On Tue, Mar 23, 2010 at 10:47 AM, Alexis Ménard  wrote:
> There are two crashes because of this workaround.
>
> One in QGV is fixed and is on its way to 4.6.3
>
> The other is reported :
>
> https://bugs.kde.org/show_bug.cgi?id=227639
>
> It would be nice if the original writer of the workaround can help the
> guys of QtWebkit. I'm kinda busy right now.
>
> Next time when adding a workaround please open a bug report in the
> upstream project.
>
> On Mon, Mar 22, 2010 at 7:56 PM, Marco Martin  wrote:
>> On Monday 22 March 2010, Marco Martin wrote:
>>> On Monday 22 March 2010, Alexis Ménard wrote:
>>> > Hello,
>>> >
>>> >
>>> > May i know where was the crash? Because i'm sure the workaround is not
>>> > needed anymore...
>>> >
>>> > QVariant WebView::itemChange(GraphicsItemChange change, const QVariant
>>> > &value) {
>>> >
>>> >     if (change == QGraphicsItem::ItemSceneHasChanged) {
>>> >
>>> >         //FIXME: QWebPage _requires_ a QWidget view to not crash in
>>> >
>>> > places such as
>>> >
>>> >         // WebCore::PopupMenu::show() due to
>>> >
>>> > hostWindow()->platformPageClient() == NULL
>>> >
>>> >         // because QWebPage::d->client is NULL
>>> >         d->webView->page()->setView(viewFor(this));
>>> >
>>> >     }
>>> >     return QGraphicsWidget::itemChange(change, value);
>>> >
>>> > }
>>> >
>>> > Thank you
>>>
>>> iirc the crash was opening a combobox in a webpage.
>>> right now this workaround causes many other crashes with a quite random
>>> behaviour, and one for which Amarok is being beaten quite a lot lately:
>>> https://bugs.kde.org/show_bug.cgi?id=227639
>>>
>>> Cheers,
>>> Marco Martin
>>
>> and by the way.. it doesn't seem to crash anymore wit the hack disabled.
>> combobox popups are slightly misplaced (about 50 pixels too high), but  they
>> work.
>> sooo, can it be removed?
>>
>> Cheers,
>> Marco Martin
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workaround in WebView...

[Alexis Ménard]

There are two crashes because of this workaround.

One in QGV is fixed and is on its way to 4.6.3

The other is reported :

https://bugs.kde.org/show_bug.cgi?id=227639

It would be nice if the original writer of the workaround can help the
guys of QtWebkit. I'm kinda busy right now.

Next time when adding a workaround please open a bug report in the
upstream project.

On Mon, Mar 22, 2010 at 7:56 PM, Marco Martin  wrote:
> On Monday 22 March 2010, Marco Martin wrote:
>> On Monday 22 March 2010, Alexis Ménard wrote:
>> > Hello,
>> >
>> >
>> > May i know where was the crash? Because i'm sure the workaround is not
>> > needed anymore...
>> >
>> > QVariant WebView::itemChange(GraphicsItemChange change, const QVariant
>> > &value) {
>> >
>> >     if (change == QGraphicsItem::ItemSceneHasChanged) {
>> >
>> >         //FIXME: QWebPage _requires_ a QWidget view to not crash in
>> >
>> > places such as
>> >
>> >         // WebCore::PopupMenu::show() due to
>> >
>> > hostWindow()->platformPageClient() == NULL
>> >
>> >         // because QWebPage::d->client is NULL
>> >         d->webView->page()->setView(viewFor(this));
>> >
>> >     }
>> >     return QGraphicsWidget::itemChange(change, value);
>> >
>> > }
>> >
>> > Thank you
>>
>> iirc the crash was opening a combobox in a webpage.
>> right now this workaround causes many other crashes with a quite random
>> behaviour, and one for which Amarok is being beaten quite a lot lately:
>> https://bugs.kde.org/show_bug.cgi?id=227639
>>
>> Cheers,
>> Marco Martin
>
> and by the way.. it doesn't seem to crash anymore wit the hack disabled.
> combobox popups are slightly misplaced (about 50 pixels too high), but  they
> work.
> sooo, can it be removed?
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Javascript Bindings inside QML

[Alexis Ménard]

Hello,

I just wonder which part of the Plasma bindings we want to put into QML :

http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API

All the UI related stuff is pretty much useless because QML provides
those facilities. It would be nice to have a list so we can think
about what we can do for it.

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

Workaround in WebView...

[Alexis Ménard]

Hello,


May i know where was the crash? Because i'm sure the workaround is not
needed anymore...

QVariant WebView::itemChange(GraphicsItemChange change, const QVariant &value)
{
if (change == QGraphicsItem::ItemSceneHasChanged) {
//FIXME: QWebPage _requires_ a QWidget view to not crash in
places such as
// WebCore::PopupMenu::show() due to
hostWindow()->platformPageClient() == NULL
// because QWebPage::d->client is NULL
d->webView->page()->setView(viewFor(this));
}
return QGraphicsWidget::itemChange(change, value);
}

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

Re: kdereview/networkmanagement/applet

[Alexis Ménard]

On Tue, Mar 2, 2010 at 11:17 PM, Marco Martin  wrote:
> On Tuesday 02 March 2010, Aaron J. Seigo wrote:
>> On March 2, 2010, Sebastian Kügler wrote:
>> > We should probably expose the setPixmap(QPixmap) method in
>> > Plasma::Label's API, as this functionality is very useful if you want to
>> > display a custom-painted pixmap we don't have the path of.
>>
>> or provide a Plasma::PixmapWidget that doesn't use a QGraphicsProxyWidget
>> at all.
>>
>> it's unfortunate that QGraphicsPixmapItem is a QGraphicsItem and not a
>> QGraphicsWidget :/
> yes, agree on Pixmapwidget since it could save some significant weight
> compared to a label

Yep 1... It's quite easy to implement...

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

Re: T4: Opening Day Presentations

[Alexis Ménard]

On Wed, Jan 27, 2010 at 1:24 PM, Artur Souza (MoRpHeUz)
 wrote:
> Hey,
>
> On Tue, Jan 26, 2010 at 3:09 PM, Alexis Ménard  wrote:
>> i'd love to give a small state of the art for plasma-mobile (at least
>> for the n900 point of view) : QML, C++, Packaging, and the main issues
>> we have to face for now. I will also come with some nice technical
>> proof and concept to consider during the sprint.
>
> maybe we can do this together ? :)
>

+1

> Cheers,
>
> --
> ---
> Artur Duque de Souza
> OpenBossa Research Labs
> INdT - Instituto Nokia de Tecnologia
> ---
> Blog: http://labs.morpheuz.eng.br/blog/
> PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
> ---
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: T4: Opening Day Presentations

[Alexis Ménard]

Yo,

i'd love to give a small state of the art for plasma-mobile (at least
for the n900 point of view) : QML, C++, Packaging, and the main issues
we have to face for now. I will also come with some nice technical
proof and concept to consider during the sprint.

/me don't want to wear too much his Qt hat this time :D

On Tue, Jan 26, 2010 at 6:56 PM, Marco Martin  wrote:
> On Tuesday 26 January 2010, Aaron J. Seigo wrote:
>> On January 26, 2010, Marco Martin wrote:
>> > i assume we're doing like last times, so giving brief presentations on
>> > the first day...
>>
>> we're going to have ~25 people there this time. so this time i think we'll
>> have to do it just a little bit differently, due to time (15 min / person
>> would be over 6 hours of presentations!).
>
> yes, agree
>
>> i'd like to see one presentation about Oxygen, one or two about KWin and
>> then a handful about Plasma related topics. each should be in the 10-20
>> minute range (20 at the absolutely maximum).
>
> i was thinking doing 2 really short (added to wiki), one on how to use the sdk
> of the intel thinghie, so can get up to speed everyone interested in hacking
> on it (perhaps with arthur and alexis we can stuff that -and- maemo in a sigle
> slot timeframe eheh :))
> and a little call on volunteers on what still sucks on the netbook ui :)
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Need a couple of volunteers (was: Re: TokamakIV update)

[Alexis Ménard]

On Wed, Jan 13, 2010 at 10:13 PM, Chani  wrote:
>
>>
>> Would really need a couple more of "yes, i'm interested" :p
>
> ohh, I wish I could say yes, but I've got enough on my plate already... I'll
> be playing with my n900 at tokamak if I ever get around to building plasma-
> moblie (erm, are there instructions anywhere? dependency list?)

In my mind mouahahahah...When arthur is coming (before i'm
busy...sorrry) we're gonna clean that properly so wiki + packages (and
the scripts)...

Some dependencies are missing, i'm gonna package them (almost done)
and upload that to extra-devel so people don't need to go to that step
:D. For example, soprano, raptor,...

>
>> also, it would make working with those things significantly easier if
>> someody has laying around things like an usb ethernet adaptor (getting
>> wifi to work on them is too random:) and usb hubs, preferably powered and
>> can share them just during the meeting ;)
>
> well, aaron has my trolltech usb-cupwarmer-hub, I'm sure he can bring that. :)
>
> --
> This message brought to you by eevil bananas and the number 3.
> www.chani3.com
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Need a couple of volunteers (was: Re: TokamakIV update)

[Alexis Ménard]

On Wed, Jan 13, 2010 at 11:15 AM, Marco Martin  wrote:
> On Tuesday 12 January 2010, Marco Martin wrote:
>> Hi all,
>> Since a couple of days i had the occasion playing aroung with a neat mobile
>> device by Intel. I think it's a good development platform to get
>> plasma-mobile started since is basicaly a pc (tough only slightly bigger
>> than an n810) so getting things to run on it is really easy.
>> Now since i had green light to ask this, (i know that's a rethorical
>> question since i know everybody here loves this stuff ;p) if i can get at
>> least two people that will be interested working on them during Tokamak i
>> think i can make them lending us two more devices, so there will be enough
>> to experiment for some people.
>> then of course they don't have to do that all the time, we just have to
>> make sure they'll be put in good use.
>>
>> who raises hand? :)
>
> Would really need a couple more of "yes, i'm interested" :p
> also, it would make working with those things significantly easier if someody
> has laying around things like an usb ethernet adaptor (getting wifi to work on
> them is too random:) and usb hubs, preferably powered and can share them just
> during the meeting ;)
>

For me i do prefer working on the N900, the config is much more
reliable and easy.
I bring extra devices for other people.

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

Re: Need a couple of volunteers (was: Re: TokamakIV update)

[Alexis Ménard]

On Tue, Jan 12, 2010 at 7:06 PM, Marco Martin  wrote:
> On Tuesday 12 January 2010, Nuno Pinheiro wrote:
>> On Tuesday, 12 de January de 2010 17:44:39 Marco Martin wrote:
>> > On Tuesday 12 January 2010, Nuno Pinheiro wrote:
>> > > On Tuesday, 12 de January de 2010 15:32:44 Marco Martin wrote:
>> > >
>> > > I have been lately playing around with alot of UI/design in touch small
>> > > screen oriented devices, so I would be interested..
>> > >
>> > > the N900 still has not made it here so Im playing with printed versions
>> > >
>> > > :D (actual paper printed versions its pretty fun)
>> >
>> > will install gwenview too on it so :D
>> > ah, and that one is 800x480 too, so no need to make two versions of the
>> > mockups ;)
>>
>> but i bet the screen is bigger that the n900, the n900 poses alot of
>> interesting issues because the dpi is huge, Touch based devices are really
>> interesting  as besides the usual "how many pixels do i have" problem other
>> problems rise up as "this clicable area must be as big as my fingertip", so
>> there we go back to the real size based design vs the pixel based design,
>> and the complete custom design for each device.
>>
>> Interesting stuff :D
>
> yeah, the thing looks like a slighty bigger n810 and has already much higher
> dpi that the usual 96 of the desktop (fonts are hge there ;))
>
>> > > > Hi all,
>> > > > Since a couple of days i had the occasion playing aroung with a neat
>> > > > mobile device by Intel. I think it's a good development platform to
>> > > > get
>> > > >
>> > > >  plasma-mobile started since is basicaly a pc (tough only slightly
>> > > >
>> > > > bigger than an n810) so getting things to run on it is really easy.
>> > > >
>> > > > Now since i had green light to ask this, (i know that's a rethorical
>> > > >
>> > > >  question since i know everybody here loves this stuff ;p) if i can
>> > > >  get at least two people that will be interested working on them
>> > > >  during Tokamak i think i can make them lending us two more devices,
>> > > >  so there will be enough to experiment for some people.
>> > > >
>> > > > then of course they don't have to do that all the time, we just have
>> > > > to
>> > > >
>> > > >  make sure they'll be put in good use.
>> > > >
>> > > > who raises hand? :)
>> > > >
>> > > > cheers,
>> > > > Marco Martin
>> > > > ___
>> > > > Plasma-devel mailing list
>> > > > Plasma-devel@kde.org
>> > > > https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
> --
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

I'm looking forward to work with you on mockup Nuno so we can
implement something there. I always lack proper graphic resources when
hacking.

/me is dreaming to be a designer.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Need a couple of volunteers (was: Re: TokamakIV update)

[Alexis Ménard]

Plus 3-4 N900s that i will bring :D

Artur is coming to Oslo end of this month, i plan to work with him on
KDE packages so the devices will be ready to work with...And at least
the process so we can generate plasma packages on the fly...

On Tue, Jan 12, 2010 at 5:54 PM, Aaron J. Seigo  wrote:
> On January 12, 2010, Alexis Ménard wrote:
>> Me but i'll bring N900s too.
>>
>> My plan for tokamak 4 is plasma-mobile only...nothing else...
>
> yes, i think we'll have one "pod" of people working on Plasma Mobile during
> the conference. i think we'll have at least 4-5 devices in total to keep
> people busy. (3 from Intel, at least one N900 and i will be bringing a low-end
> MIPS based clamshell device as well.)
>
> really exciting stuff, and i hope we all bring our Big Ideas for the user
> interface with us!
>
> of course, there will be lots of other topics for "the rest of us" to keep our
> hands busy with too! :)
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Need a couple of volunteers (was: Re: TokamakIV update)

[Alexis Ménard]

Me but i'll bring N900s too.

My plan for tokamak 4 is plasma-mobile only...nothing else...

On Tue, Jan 12, 2010 at 4:32 PM, Marco Martin  wrote:
> Hi all,
> Since a couple of days i had the occasion playing aroung with a neat mobile
> device by Intel. I think it's a good development platform to get plasma-mobile
> started since is basicaly a pc (tough only slightly bigger  than an n810) so
> getting things to run on it is really easy.
> Now since i had green light to ask this, (i know that's a rethorical question
> since i know everybody here loves this stuff ;p) if i can get at least two
> people that will be interested working on them during Tokamak i think i can
> make them lending us two more devices, so there will be enough to experiment
> for some people.
> then of course they don't have to do that all the time, we just have to make
> sure they'll be put in good use.
>
> who raises hand? :)
>
> cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: TokamakIV update

[Alexis Ménard]

My travel has been approved so you can remove me from the budget :D.

On Mon, Jan 11, 2010 at 11:15 PM, Sebastian Kügler  wrote:
> Hi,
>
> I've just sent a request for sponsoring to the KDE e.V. board. I'll let you 
> know if
> and when we got the funding approved. Please hold off booking your tickets 
> until then
> -- I don't expect it to take more than a couple of days.
>
> We'll be around 25 people, for roughly a week, Oxygen, Kwin and Plasma people
> combined. Quite impressive :)
>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: t4 wiki page

[Alexis Ménard]

I will probably be part of it...I still need to ask for approval

On Wed, Dec 30, 2009 at 8:18 AM, Aaron J. Seigo  wrote:
> On December 29, 2009, Chani wrote:
>> aaron, do we need more of those filled in or can we email the board now? :)
>
> the board should be emailed; i wasn't aware that i was coordinating this,
> however. if i am, i'll get right on it, however. sebas?
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: animation api changes

[Alexis Ménard]

On Fri, Dec 4, 2009 at 2:24 AM, Aaron J. Seigo  wrote:
>
> hi all ..
>
> so, the animation API is going through its final set of changes for 4.4.
> please take a look at it if you care to and give us feedback now before it's
> too late (as defined by "we are shipping it in 4.4 and are committed to that
> API").
>
> the basic "shape" of the API is this:
>
> * Plasma::Animator becomes a factory for Plasma::Animations
>
> * Plasma::Animation IsA QAbstractAnimation with the bare essential pure
> virtuals implemented and which takes a QGraphicsWidget that should be animated
>
> * Plasma::AnimationGroup IsA QAbstractAnimation that wraps a
> QAbstractAnimationGroup (this is the part i'm least sure about atm...) and
> makes switching from parallel to sequential easy (personally, i think Kinetic
> should have made parallel vs sequential a property, not introduced two
> different classes; it's a hassle).

The motivation behind was that the code was quite different for the two groups.
We didn't want to have :
- If else if else if else all over the place inside the code.

Other point :
QPauseAnimation *   addPause ( int msecs )
QAbstractAnimation *currentAnimation () const
QPauseAnimation *   insertPause ( int index, int msecs )

This API don't make sense for a parrallel group.

But what is the use case (concrete) where you want to switch the group
from sequential to parrallel?

>
> however, if we feel that the parallel-
> >sequential switching is not worth it, we can simply kill this class and make
> people deal with the slightly unwieldy QAnimationGroup directly. i'm kind of
> leaning in that direction, tbh, even though i dislike parts of
> QAnimationGroup's design.
>
> basically, it's a QGrahicsView-specific set of Plasma-standardized animations
> implemented in little convenience classes so that it's simpler to use Kinetic,
> particularly from scripts but also C++. they still mix-and-match nicely with
> plain Kinetic classes, so it's not an either-or-choice, these are just some
> pre-made ones for us to use extensively throughout plasma code (less code,
> more consistency)

And animations integrate well with QML :D.

>
> we still have one large outstanding bit of work left, and that is to port the
> animations away from the use of the previous API revision's "render()" method
> and make them proper QAbstractAnimations. see the Fade animation for how this
> should look if you'd like to pitch in. the ones with render calls still are:
>
>        grow.cpp
>        pause.cpp
>        pulser.cpp
>        rotation.cpp
>        rotationstacked.cpp
>
> Slide should also probably have its internal QPropertyAnimation removed so
> it's as simple/straightforward as Fade is.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Warning : qreal in Plasma...

[Alexis Ménard]

Hello dudes,

When recompiling Plasma for the N900 i found some compilations issues, don't
worry no big deal.

Just so you know on ARM qreal is not a double but a float...

so qMax(0.0, whatEverQReal) doesn't compile...You should use
qMax(qreal(0.0), whatEverQReal)...

:D.

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

Upstream bugs... (Qt)

[Alexis Ménard]

Hello,

Since Qt Development Frameworks have an open bug tracker i would like to
invite people to report bugs into it.

As you can see in this bug (https://bugs.kde.org/show_bug.cgi?id=210146),
it's marked as CLOSED UPSTREAM. But if nobody reports the bug in Qt's
bugtracker, there is no way for Qt developers to know that the bug exists (i
knew it because i'm following Plasma). Right now filtering by
closed/upstream gives Trolls nothing since there is not enough information.
I'm sure there are some other bugs that need a proper report.

So if you marked the bug CLOSED UPSTREAM please create one in the Qt
bugtracker and link it into the KDE bugtracker so people can follow it.

Don't be afraid Qt's bugtracker is friendly :D.

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

Re: About KDE/plasma on small devices

[Alexis Ménard]

On Tue, Nov 24, 2009 at 12:07 AM, Martin Gräßlin
wrote:

> Am Montag 23 November 2009 23:16:10 schrieb Alexis Ménard:
> > KWin works out of the box without anything, it just doesn't have OpenGL
> > support mainly because KWin effects are using raw OpenGL which is
> different
> > from OpenGL ES 2.0. I don't think we need for now to replace the window
> > manager. Matchbox works quite fine.
> Just as a note: I started to work on a shader based implementation for the
> rendering and to get by that KWin ported to OpenGL ES 2.0 and OpenGL 3.
>

awesome!


>
> ___
> 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: About KDE/plasma on small devices

[Alexis Ménard]

Well i've started the mobile shell, and it's not far... I just come back
from vacations so i will start again hacking on it.

For now, it's just a containment (mainly stole from plasma-desktop and
netbook).

I have implemented an applet to toggle the expose effect in the n900.

The road is long in order to have something usable on the n900. The applet
handle should be redisign, many applets are not finger enabled (though some
of them works quite nice).

And then the main problem is the lack of the documentation in the maemo
side. I had to reverse engineered the dbus server to find out which signal
trigger the expose effect.

On Mon, Nov 23, 2009 at 10:39 PM, Aaron J. Seigo  wrote:

> On November 23, 2009, you wrote:
> > > it's close, but there will be things in it that just don't fit very
> well.
> > > fortunately, plasma encourages a highly modular design and so parts
> that
> > > do make sense can be shared between plasma-netbook and plasma-mobile
> > > without much effort at all.
> > > yes; it could also be something more custom-fitted to a small screen,
> > > particularly when it comes to application transitions. see, for
> instance,
> > >  what the palm pre or even the iphone does in this area.
> >
> > So basically we would need a much more finger friendly smaller/compressed
> > plasma containment.
> > Whih shouldn't be too hard if we would "fork" the netbook maybe?
>
> perhaps; i'd suggest starting with an intended user experience design and
> work
> from there, taking what we can from other places.
>
> > > when it comes to the n900 itself, they use an expose-like effect which
> > >  would mean a different Plasma::View for each widget on the canvas.
> this
> > > is actually not uncommon (it's how popup applets work in the
> > > icon-and-dialog state, e.g. when in a panel in plasma-desktop).
>

I've actually hacked something else, a full screen app...So maemo popups
works well, like when somebody call for instance. Even the compositor do its
job.


> >
> > I would really like to keep the "footprint" as low as possible not just
>

Pointless for now, make things works fine and then you optimize.


> >  from a performance point of view but also from a position that we would
> >  have to port KWin to this special platform which could be worked around
> by
> >  adding the needed pieces upon the ready made plasma right?
>
>
KWin works out of the box without anything, it just doesn't have OpenGL
support mainly because KWin effects are using raw OpenGL which is different
from OpenGL ES 2.0. I don't think we need for now to replace the window
manager. Matchbox works quite fine.


> well, the n900 already provides this out of the box. we don't need to do
> anything there.
>
> there's the additional route of "creating a shell for any phone and do it
> from
> the ground up"; personally, i think we should target the n900 as step 1 and
> then generalize it from there. the reasons are:
>
> * we have n900s to actually run stuff on right now
> * it allows us to grow the project step by step instead of having to do
> everything at once
>
>
Having a plasma-mobile, with couple of useful applets, finger oriented.
Plasma mobile can works in full screen (in addition to the current
hildon-desktop) would be nice for a step 1. Then we can think of creating an
applet for calling and so on.


> > > >  would have the issue that you would get quite scared because most of
> > > > the mobilephone apps would have to be placed there.
> > >
> > > why would this be a problem? I'm not sure i'm seeing the issue here :)
> >
> > From what I've seen on the plasma newspaper the user would either (1)
> need
> >  to always drag the applet upon the newspaper or (2) KEEP all the
> plasmoids
> >  for these phone special stuff upon the newspaper conatinment which makes
> >  it either a hell of a mess or too much to load smooth enough for a daily
> >  workflow.
>
> it again comes back to what user experience plasma-mobile should offer.
>
> one possibility is:
>
> * there is a "home" screen that allows one to put multiple widgets on the
> screen at the same time; basically a tiny version of plasma-desktop's
> desktop
> view
>
>
That is my goal.


> * widgets can also be launched as a "full application", or full screen. in
> that case we create a separate View and show the widget in that view.
>
>
Kate for instance is already running. The problem is Oxygen and the UI, it's
not device enabled. KDE needs lot of work in that side. Plasma is probably
one of the easiest component to have on the N900 because its flexibility.


> the question is if we allow multiple applications to run or just one at a
> time. if just one at a time, then there is just one view and it can
> load/delete widgets on request. lower resource usage, but also slower
> switching between apps. this is the iPhone approach fwiu.


> if multiple, then its up to the user to not launch too many at once,
> closing
> those they don't need/want. perhaps with some automatic management added in

Re: maemo 6 ui (a new qgv-based widget toolkit)

[Alexis Ménard]

Hello,

Animated Layouts should come in 4.7...They were planned to be in 4.6 but we
didn't make it.

INDT guys had already a proto that was working quite well. It needs to be
polish, reviewed
and it can be merged into Qt master.

But it still interessting to have a look i agree.

On Fri, Oct 16, 2009 at 9:46 AM, Ian Monroe  wrote :

> Just a heads up in case you missed it with the other news coming out
> of the Maemo summit. For Maemo 6/Harmattan Nokia has developed whats
> essentially a whole gui toolkit built on QGV designed to work well
> with thumb ui's and hardware acceleration. So its unlikely you'd want
> to use it directly in plasma (and certainly not in its current tech
> preview state).
>
> But it has some interesting stuff like animated layouts. So it might
> be worth looking at it and taking code or ideas from.
>
> Looks like they're using gitorious as a glorified tar ball server.
> http://qt.gitorious.org/maemo-6-ui-framework
>
> Clone and then qmake && make doc to check it out.
>
> Ian
> ___
> 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: ginormous performance issue

[Alexis Ménard]

I like the new method and deprecate the old one if it's not anymore needed.

On Friday, July 17, 2009, Aaron J. Seigo  wrote:
> On Friday 17 July 2009, Marco Martin wrote:
>> and still, in the case of an applet with many subwidgets, independent
>> timers can do really a big signal storm, so i still kinda like more the
>> pointer approach :p
>
> yes, having a single timer for this is a nice win  the pointer thing is as
> bit of a hack (and yes, a pointer is always an int, so that's fine in that
> previous patch). the pointer bit would need to be stripped before actually
> putting it into the cache; i wonder if having a set "syntax" for it would make
> more sense, e.g. :path_details_separated_by_underscores allowing the id to
> be stripped off.
>
> then the "don't cache this yet" collection could be a map of ids to entries.
>
> really, this is just a way around adding API. i wonder if it wouldn't make
> more sense to just add a new addToCache method in Theme that takes an
> additional "id" argument for this purpose. avoids all the string parsing and
> reliance on "well formed" entries and makes it clear what's going on
> internally.
>
> i'll think more on this over the weekend (back to work on monday for me! wee!
> :)) but the more i look at the various patches the more i think that a new
> method is the cleanest approach. thoughts?
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: ginormous performance issue

[Alexis Ménard]

Crappy idea, API will be ugly and will lead to errors.

Timer is the best approach.

On Thu, Jul 16, 2009 at 9:03 PM, Alexis Ménard  wrote:

>
>
> On Thu, Jul 16, 2009 at 9:00 PM, Marco Martin  wrote:
>
>> On Thursday 16 July 2009, Aaron J. Seigo wrote:
>> > On Thursday 16 July 2009, Marco Martin wrote:
>> > > but a sick idea come to my mind: what about encoding the pointer value
>> > > (or another random number, whatever) into the key? :p
>> > > a key will have the form
>> > > 7635865:path_300_200_blahblah
>> >
>> > how will this work between sessions? (new pointer values)
>>
>> the pointer is discarded when saved into the cache (the key has the same
>> old
>> format) so it should work as before between sessions, what doesn't work i
>> think in the patch is that findInCache now doesn't remove the pointer from
>> the
>> id, so it always fail, but making it actually remove and discard the
>> pointer
>> it should work fine
>>
>> > between objects with the same svg at the same size? (should share the
>> same
>> > cache values)
>> should work, what it could happen is a double save, but an extra control
>> could
>> be added
>>
>> i know this soolution is a trrible hack (now a format in the id string is
>> required, where before it could be anything), should work, but if someone
>> has
>> better solutions i am all for it.
>> now the question is: better this approach or moving the timers in svg and
>> framesvg again?
>
>
> Why not having a way/API to discard the caching for an Applet when the
> handle start resizing (button is pressed) ? And then reactivate it when the
> mouse is released.
>
>
>
>>
>>
>> Cheers,
>> Marco Martin
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: ginormous performance issue

[Alexis Ménard]

On Thu, Jul 16, 2009 at 9:00 PM, Marco Martin  wrote:

> On Thursday 16 July 2009, Aaron J. Seigo wrote:
> > On Thursday 16 July 2009, Marco Martin wrote:
> > > but a sick idea come to my mind: what about encoding the pointer value
> > > (or another random number, whatever) into the key? :p
> > > a key will have the form
> > > 7635865:path_300_200_blahblah
> >
> > how will this work between sessions? (new pointer values)
>
> the pointer is discarded when saved into the cache (the key has the same
> old
> format) so it should work as before between sessions, what doesn't work i
> think in the patch is that findInCache now doesn't remove the pointer from
> the
> id, so it always fail, but making it actually remove and discard the
> pointer
> it should work fine
>
> > between objects with the same svg at the same size? (should share the
> same
> > cache values)
> should work, what it could happen is a double save, but an extra control
> could
> be added
>
> i know this soolution is a trrible hack (now a format in the id string is
> required, where before it could be anything), should work, but if someone
> has
> better solutions i am all for it.
> now the question is: better this approach or moving the timers in svg and
> framesvg again?


Why not having a way/API to discard the caching for an Applet when the
handle start resizing (button is pressed) ? And then reactivate it when the
mouse is released.



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

Re: What to do with the old Plasma::Animator?

[Alexis Ménard]

On Fri, Jun 12, 2009 at 5:29 PM, Aaron J. Seigo  wrote:

> On Friday 12 June 2009, Alexis Ménard wrote:
> > On Fri, Jun 12, 2009 at 3:40 PM, Akmanalp, Mehmet A
> wrote:
>
> > > 1) Move the old animator.cpp into deprecated/ and create a whole new
> > > animator.cpp with a whole new Plasma::Animator? If so, how is this
> > > "extend Plasma::Animator"?
> >
> > Yes move it just. And create a new class for now.
> >
> > > 2) Move the old animator.cpp into deprecated/ and extend it in the new
> > > animator.cpp? Then, this doesn't solve the naming issue(We still have
> > > to use a different name, not "Animator"), and it isn't "retro-fitting
> > > Animation".
> >
> > You can't remove it completly, symbols have to be here for binary
> > compatibilty reasons.
> > Grab a name (can't be Animator), the one you want, we will see later.
>
> erf.. i'm concerned we're going to confuse Mehmet with conflicting advice
> ...
> but here goes anyways ;)
>
> my thoughts are this:
>
> Animator is a great name and says what it does; i don't want two classes
> kicking around, and we can't remove Animator. s:
>
> * mark all the methods currently in Animator as KDE_DEPRECATED
>

Didn't know that...


>
> * add the new methods for the kinetic project to animator.h
>

Yep.


>
> * move the current animator.cpp into deprecate
>
> * create a new .cpp file for the new implementation:
> kdelibs/plasma/animator.cpp
>
> * move the constructor and destructor from plasma/deprecated/animator.cpp
> into
> the new plasma/animator.cpp, as it needs to join the new implementation.
>
> this means that the deprecated implementation is in
> plasma/deprecated/animator.cpp, the new stuff is in plasma/animator.cpp and
> we
> keep Animator around as a class that people use for the kinetic stuff.
>
> Alexis: does that make sense to you as well? :)


Then it makes sense.


>
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> ___
> 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: What to do with the old Plasma::Animator?

[Alexis Ménard]

On Fri, Jun 12, 2009 at 3:40 PM, Akmanalp, Mehmet A wrote:

> Regarding these:
>
> On Thu, Jun 4, 2009 at 9:39 PM, Alexis Ménard wrote:
> >
> >
> > On Thu, Jun 4, 2009 at 7:16 PM, Aaron J. Seigo  wrote:
> >> can we just extend Plasma::Animator with the new methods and deprecate
> all
> >> the
> >> old stuff?
> >>
> >> to keep the implementation from becoming mixed up with all the old
> crufty
> >> stuff, we could move the current animator.cpp somewhere else
> >> (deprecated/animator.cpp? private/animator.cpp?) and name the new, fresh
> >> and
> >> happy implementation file animator.cpp.
> >
> > Yep as soon as the old stuff is properly documented as obslelete and you
> > hide it deeply in the h file, that's how we do in Qt.
> > Having a new file can be better if the choice is possible.
> >>
> >> the other option would be AnimationFactory, but then things gets
> confusing
> >> in libplasma imho. i'd much rather just retro-fit Animation.
> >
> >
> > I really like the factory concept : give me blur animation object which i
> > can set-up and put into groups if needed...
>
> So, I've been thinking, and I'm a little confused. Do we:
>
> 1) Move the old animator.cpp into deprecated/ and create a whole new
> animator.cpp with a whole new Plasma::Animator? If so, how is this
> "extend Plasma::Animator"?


Yes move it just. And create a new class for now.


>
> 2) Move the old animator.cpp into deprecated/ and extend it in the new
> animator.cpp? Then, this doesn't solve the naming issue(We still have
> to use a different name, not "Animator"), and it isn't "retro-fitting
> Animation".


You can't remove it completly, symbols have to be here for binary
compatibilty reasons.
Grab a name (can't be Animator), the one you want, we will see later.


>
> 3) Something else that I didn't quite get?
>
> --
> ~ mali (http://constant.inople.net/)
> ___
> 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: Bypassing Qt bug in the desktop toolbox

[Alexis Ménard]

http://qt.gitorious.org/qt/qt/merge_requests/407

Is this fix resolve your problem? Can you try?

If yes, then i would prefer a qt-copy patch than a hack in the code. People
will forget it and it pollute the code base. Qt-copy patches are
updated/removed properly when new release of Qt are available.

I will check tomorrow if this commit is in 4.5.2 packages...if yes, then no
point to do this, 4.5.2 arrive very soon.

On Mon, Jun 8, 2009 at 8:16 PM, Ivan Cukic

> wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/804/
> ---
>
> (Updated 2009-06-08 11:16:37.652296)
>
>
> Review request for Plasma.
>
>
> Summary (updated)
> ---
>
> Qt has a b-u-g causing it to show a child element after calling show() even
> though the parent is hidden.
>
> (spelled b-u-g since revboard automatically makes links for bugs...)
>
>
> Diffs
> -
>
>  /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 978915
>
> Diff: http://reviewboard.kde.org/r/804/diff
>
>
> Testing
> ---
>
> Yes :)
>
>
> Thanks,
>
> Ivan
>
> ___
> 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: KDE/kdebase/workspace/plasma/applets/battery

[Alexis Ménard]

On Sat, Jun 6, 2009 at 3:18 PM, David Nolden  wrote:

> Am Samstag 06 Juni 2009 14:58:47 schrieb Artur Souza(MoRpHeUz):
> > Please guys, let's not make a storm in a cup of water: let's choose one
> > behavior and see if users opens too many bugs for it and we fix it in the
> > next versions. Don't fight with each other for a plasmoid's feature :)
> That's not how it can work. Everyone who is clever enough to file a
> bug-report
> is also clever enough to change the config-file.


Completly false. Mr Joe is not able to find a file in .kde4/... and read
through it... Most of the case they simply don't know where are those files.

Vs

Open a web browser and fill a bug/wish on a website, simple clicks, and
there is a link in the app.

My grand parents will choose the second one for sure...

KDevelop can works like this, your users are developers, we have Mr
everybody out there.


>
> It's about delivering the best we can to everyone, without configuration,
> and
> not just those who know how to help themselves.
>
> And it's also about "decision making" in a "community". I'm asking myself
> why
> we even discussed this whole issue when the result of the discussion
> doesn't
> play the slightest role.
> ___
> 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 running on S60 device

[Alexis Ménard]

On Fri, Jun 5, 2009 at 3:38 PM, Alexis Ménard  wrote:

>
>
> On Fri, Jun 5, 2009 at 3:16 PM, Artur Souza(MoRpHeUz) <
> morph...@openbossa.org> wrote:
>
>> Hi Jani,
>>
>> On Friday 05 June 2009, 07:32 Jani Hautakangas wrote:
>> >  What should I do to get this project started? Who should I contact? It
>> > would really nice if someone could walk me through to get this project
>> up.
>> > I guess that S60 port will have webpage of its own http://s60.kde.orglike
>> > other ports have their own. Eventually this project will be KDE for
>> Symbian
>> > but since Symbian Foundation is not yet properly running lets keep it
>> KDE
>> > on S60. Finally when we have KDE or parts of it up and running we can
>> start
>> > pushing this upstream. I'm sure that not every component is feasible for
>> > S60/Symbian but at least Plasma looks very promising. There is no
>> guarantee
>> > that that this will ever fly but at least we can try.
>>
>> I think that the best way to start this project is to request an svn
>> account
>> and start working on playground. In KDE's svn server there is a folder
>> named
>> "playground" where we can put all our prototypes. I think this would be a
>> good
>> place to start.
>>
>> It's important that you start sharing the code from the beginning with the
>> community so we can give you some help with that. Kevin and others can
>> help a
>> lot and there are a lot of Nokians around also that can help. But if you
>> keep
>> the code somewhere that we can't see it would be difficult to help...
>
>
>
> Yes this is open source philosophy. Then you will have people to help you
> with KDE knowledge.
>
>
>>
>>
>> >   - CMake doesn't support Symbian. We must use QMake for now.
>> >
>> >   - Qt for S60 doesn't support QtDBus. There are few alternatives
>> for this:
>> >   - Implement QtDBus for S60 (native or use LIW/AIW behind
>> the scenes)
>> >   - Use S60 LIW/AIW directly
>> >   - Use upcoming Qt Service Framework if it is feasible
>> >   - Beg QtSoftware to port QtDBus for S60
>>
>> Maybe Alexis can talk with the guys from the S60 port about QtDBus status
>> ? :)
>> Otherwise I can go and talk with them but probably it would be faster if
>> Alexis
>> just go to their office =P
>>
>
> There is no plan to support QtDBus on S60 since nobody using it before KDE.
> We have heard that somebody port it to S60 but
> if somebody make that thing up and running on S60 then Qt Software will be
> glad to take a look on the merge
> request.
>

Nobody using it on S60 before jani came with a KDE on it.


>
>
>
>>
>> > My employer Tieto http://www.tieto.com is willing to contribute/sponsor
>> > this project. Tieto is among the leading Symbian R&D service providers
>> for
>> > OEMs globally with up to 1300 persons in Mobile Devices R&D globally.
>>
>> I know your company...there were some Tieto's workers on a project that I
>> was
>> working :)
>
>
> That is nice, but this should happen on KDE repo, with KDE folks, Qt
> Software people,
> tieto guys to make this port a success.
>
>
>>
>>
>> So please: put the code somewhere on svn and come to #plasma on freenode
>> :)
>> Welcome aboard ;)
>
>
> Welcome!.
>
>
>>
>>
>> http://techbase.kde.org/Contribute/Get_a_SVN_Account
>>
>> Cheers,
>>
>> --
>> Artur Duque de Souza
>> OpenBossa Research Labs
>> INdT - Instituto Nokia de Tecnologia
>> --
>> Blog: http://labs.morpheuz.eng.br/blog/
>> GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net
>> --
>>
>> ___
>> 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 running on S60 device

[Alexis Ménard]

On Fri, Jun 5, 2009 at 3:16 PM, Artur Souza(MoRpHeUz) <
morph...@openbossa.org> wrote:

> Hi Jani,
>
> On Friday 05 June 2009, 07:32 Jani Hautakangas wrote:
> >  What should I do to get this project started? Who should I contact? It
> > would really nice if someone could walk me through to get this project
> up.
> > I guess that S60 port will have webpage of its own http://s60.kde.orglike
> > other ports have their own. Eventually this project will be KDE for
> Symbian
> > but since Symbian Foundation is not yet properly running lets keep it KDE
> > on S60. Finally when we have KDE or parts of it up and running we can
> start
> > pushing this upstream. I'm sure that not every component is feasible for
> > S60/Symbian but at least Plasma looks very promising. There is no
> guarantee
> > that that this will ever fly but at least we can try.
>
> I think that the best way to start this project is to request an svn
> account
> and start working on playground. In KDE's svn server there is a folder
> named
> "playground" where we can put all our prototypes. I think this would be a
> good
> place to start.
>
> It's important that you start sharing the code from the beginning with the
> community so we can give you some help with that. Kevin and others can help
> a
> lot and there are a lot of Nokians around also that can help. But if you
> keep
> the code somewhere that we can't see it would be difficult to help...



Yes this is open source philosophy. Then you will have people to help you
with KDE knowledge.


>
>
> >   - CMake doesn't support Symbian. We must use QMake for now.
> >
> >   - Qt for S60 doesn't support QtDBus. There are few alternatives for
> this:
> >   - Implement QtDBus for S60 (native or use LIW/AIW behind
> the scenes)
> >   - Use S60 LIW/AIW directly
> >   - Use upcoming Qt Service Framework if it is feasible
> >   - Beg QtSoftware to port QtDBus for S60
>
> Maybe Alexis can talk with the guys from the S60 port about QtDBus status ?
> :)
> Otherwise I can go and talk with them but probably it would be faster if
> Alexis
> just go to their office =P
>

There is no plan to support QtDBus on S60 since nobody using it before KDE.
We have heard that somebody port it to S60 but
if somebody make that thing up and running on S60 then Qt Software will be
glad to take a look on the merge
request.


>
> > My employer Tieto http://www.tieto.com is willing to contribute/sponsor
> > this project. Tieto is among the leading Symbian R&D service providers
> for
> > OEMs globally with up to 1300 persons in Mobile Devices R&D globally.
>
> I know your company...there were some Tieto's workers on a project that I
> was
> working :)


That is nice, but this should happen on KDE repo, with KDE folks, Qt
Software people,
tieto guys to make this port a success.


>
>
> So please: put the code somewhere on svn and come to #plasma on freenode :)
> Welcome aboard ;)


Welcome!.


>
>
> http://techbase.kde.org/Contribute/Get_a_SVN_Account
>
> Cheers,
>
> --
> Artur Duque de Souza
> OpenBossa Research Labs
> INdT - Instituto Nokia de Tecnologia
> --
> Blog: http://labs.morpheuz.eng.br/blog/
> GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net
> --
>
> ___
> 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 + QT Kinetic Preliminary Design Decisions

[Alexis Ménard]

On Thu, Jun 4, 2009 at 7:16 PM, Aaron J. Seigo  wrote:

> On Thursday 04 June 2009, Akmanalp, Mehmet A wrote:
> > Hello,
> > I wanted to distill the discussions made previously on the list + my
> > thoughts and findings into something more concrete, so I can start
> > making a prototype soon.
>
> great :) also, i find writing the prototype code sooner rather than later
> helps flush out a LOT of things we might otherwise miss. don't wait for a
> completed specification to start sketching out the API: those two things
> should go hand-in-hand.
>
> > * For grouping, our Animation object (or whatever) can just subclass
> > QAnimationGroup. QAG supplies all we need, no need to go lower to
> > QAbstractAnimation imho.
>
> .. and for parallel or sequential it would create, internally, QParallelAG
> and/or QSequentialAG objects?
>
> > This way, we can interopt with other Kinetic
> > stuff nicely. IIRC, it was also mentioned the js / ruby / python APIs
> > will not need to know about Kinetic.
>
> as long as QAG is kept to an internal detail and there's no need for users
> of
> the code to ever call methods in QAG (or QAbstractAnimation) then we'll be
> fine.
>
> > * Now that I thought of it, I'm not exactly sure what aseigo meant by
> > "auto-start-when-event-loop-enters magic". Would we make QAG start
> > automagically with the next tick of the event loop. If so, providing
>
> that's the idea.
>
> > an option to not do this would also be neat, so people using our stuff
> > in conjunction with Kinetic stuff can have more freedom. However, how
>
> correct; that was event in the code sketches in my previous emails.
>
> > would we detect that an animaton object is done being created?(Maybe
> > we're going to add more properties to it.)
>
> you'd create them all before it hits the event loop.
>
> > * Should we set the object to animated in the Animation ctor or set it
> > later with a function such as .setObject()?
>
> if the Animation object does not operate properly without such an object,
> i'd
> suggest putting it in the ctor; if the intention is to create Animations
> and
> then apply them over and over to different objects, then the setter makes
> sense. either way, the setter should be there (as it is with other
> QAbstractAnimators that work on specific kinds of items)
>
> my only concern would be that Qt doesn't then introduce a
> QGraphicsItemAnimation or whatever and obsoletes our code there ;)


There is unfortunatly already a sucky QGraphicsItemAnimation...

Actually animation is related to one target at the time...
So you will need to do extra work to apply it on several targets...

But that is a valuable feedback, i can talk with some guys here, same
animation but
multiple targets.


>
>
> > * For consistency / compatibility between all the different language
> > bindings, returning a reference instead of using something like the <<
> > operator as a grouping shortcut seems like a better idea.
>
> +1
>
> > * Example (looks a bit cleaner in monospace):
> > Animation a,b;
> > a.setParallel(1)
>
> well, a.setParallel(true) ;)
>
> >  .add(Animator.blur(0.6))
> >  .add(Animator.bounce(2))
> > b.add(a)
> >  .add(Animator.pause(1))
>
> hm... how will the implementation of this look like? since objects a and b
> will be a QAnimationGroup, when a is added to b it will need to check for
> parallel, etc. and set up the correct kinetic stuff internally, correct?
> that
> could get a bit messy in the implementation.
>

mmm looks like strange...I mean having an extra class for grouping is
probably better
AND more readable, when you read you can see that you put the blur animation
in a group,
and the API for Animation will be much more clean. As aaron said, go ahead
man, we prefer
to review h files and you will face implementation issues so go ahead.


>
> if it does get too messy, one option might be to make Animation not a
> QAnimationGroup but give it an accessor that would return a new
> QAnimationGroup based on its internal status.
>
> probably i'm getting a bit ahead of all of this speaking of implementation
> details ;)
>
> > * I'm still lacking a decent name for the class. SimpleAnimator?
> > KineticAnimator? Animator2? :P Maybe something shorter and easier to
> > type?  Dunno.
>
> can we just extend Plasma::Animator with the new methods and deprecate all
> the
> old stuff?
>
> to keep the implementation from becoming mixed up with all the old crufty
> stuff, we could move the current animator.cpp somewhere else
> (deprecated/animator.cpp? private/animator.cpp?) and name the new, fresh
> and
> happy implementation file animator.cpp.


Yep as soon as the old stuff is properly documented as obslelete and you
hide it deeply in the h file, that's how we do in Qt.

Having a new file can be better if the choice is possible.


>
> the other option would be AnimationFactory, but then things gets confusing
> in

libplasma imho. i'd much rather just retro-fit Animation.


I really like the factory concept : give me blur

Re: Plasma + QT Kinetic Preliminary Design Decisions

[Alexis Ménard]

Hi,

On Thu, Jun 4, 2009 at 3:12 PM, Gökmen GÖKSEL  wrote:

> On Thursday 04 June 2009 15:34:22 Akmanalp, Mehmet A wrote:
> > Hello,
> Hi,
>
> > I wanted to distill the discussions made previously on the list + my
> > thoughts and findings into something more concrete, so I can start
> > making a prototype soon.
> Cool
>
> > * For grouping, our Animation object (or whatever) can just subclass
> > QAnimationGroup. QAG supplies all we need, no need to go lower to
> > QAbstractAnimation imho. This way, we can interopt with other Kinetic
> > stuff nicely. IIRC, it was also mentioned the js / ruby / python APIs
> > will not need to know about Kinetic.
> "QAG supplies all we need" -> What do we need exactly ?


Running sequential animation and some of same at the same time. Let's say
bounce growing effect kind of...


>
>
> > * Now that I thought of it, I'm not exactly sure what aseigo meant by
> > "auto-start-when-event-loop-enters magic". Would we make QAG start
> > automagically with the next tick of the event loop. If so, providing
> > an option to not do this would also be neat, so people using our stuff
> > in conjunction with Kinetic stuff can have more freedom. However, how
> > would we detect that an animaton object is done being created?(Maybe
> > we're going to add more properties to it.)
> We can handle it by using some properties or something different with some
> low
> level tricks :)
>

>
> > * Should we set the object to animated in the Animation ctor or set it
> > later with a function such as .setObject()?
> Can't we make it in both way ?
>
> > * Imho the new library should not depend on Plasma::Animator, I can
> > reimplement the stuff I need.
> Looks fine
>
> > * For consistency / compatibility between all the different language
> > bindings, returning a reference instead of using something like the <<
> > operator as a grouping shortcut seems like a better idea.
> +1
>
> > * Example (looks a bit cleaner in monospace):
> > Animation a,b;
> > a.setParallel(1)
> >  .add(Animator.blur(0.6))
> >  .add(Animator.bounce(2))
> > b.add(a)
> >  .add(Animator.pause(1))
> Looks fine,
>
> > * A list of effects to be definitely implemented (since they were
> > already being used / wanted by someone):
> > - Flip
> > - Slide In / Out
> > - Fade In / Out
> > - Expand / Contract in a direction
> > - Grow / Shrink / Scale
> Animate, animate every thing :)
>
> > * I'm still lacking a decent name for the class. SimpleAnimator?
> > KineticAnimator? Animator2? :P Maybe something shorter and easier to
> > type?  Dunno.
> just Kinetic in namespace of Plasma should be fine; Plasma::Kinetic ;)


Kinetic means nothing for a dev, if you read this class name without knowing
what it's doing behind, what you expect that thing do? You don't know...
Plasma::Animator is a good name, you guess it "animate" something. It's
already taken so AnimationManager, AnimationFactory, AnimationProvider
perhaps.


>
>
> --
> Gökmen GÖKSEL
> Pardus Developer
>
> ___
> 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: Current Animations Poll for QT Kinetic + Plasma

[Alexis Ménard]

On Tue, Jun 2, 2009 at 11:31 PM, Akmanalp, Mehmet A wrote:

> Hello,
> As a result of the previous discussion [0], I set out to see what all
> the current plasma apps (in svn) were doing in regards to animation so
> I gathered some data simply by grepping for customAnimation through
> their sources [1], then checking out what they were doing.
>
> In short:
> 7 fades
> 2 slides
> 1 expand / contract
> Not many chained together!
> (Keep in mind that a sample set of 10 a)
>
> So, apparently, people don't use a large variety of animations at all,
> and don't chain them parallelly. One example of parallel animations I
> spotted was the rssnow app, where when one news item slid out and the
> other slid in. Another was the pager, where you can slide your mouse
> over several desktop icons and they will all keep fading at the same
> time, although this is more the "fire and forget" type of animation
> aseigo was talking about.
>
> Anyway, maybe the reason for scarce use and lack of variety in
> animations is that people can't / are too lazy to (not in the bad
> sense) write animations, so they simply opt not to. When this layer
> makes it upstream, more people might take notice of its existence and
> decide to use more animations.


First because before you add to create a QTimeline manage it, connect
signals and so on and not reliable with lot of animations. That was not
really easy. Second, QGraphicsItemAnimation is not a very good API. Third
(my POV), i always though that Plasma::Animator was a bit too complex to
extend, but it opened the way and when in Qt Software we did the Animation
API, we took that guy in consideration :D. Perhaps with a more easy to use
animation and state framework people will start to use it. Sub-attaq example
in master is way to combine state chart diagrams to fully create a game and
couple that to animations.


>
>
> So, obviously, it looks like we need a fade effect :) But taking into
> consideration what I just said, it might be foresighted to add a
> little more. I'll pick and play around with some plasmoids to see what
> else could be added to them.


If a set is created and easy to use, then for sure widget 3rd party hackers
will use it. Look anne-marie and the picture frame...
One more thing is that we can integrate those animations in plasma widgets
(i mean pushbutton or whatever). This can bring some cool visual effects
like a kinetic scrolling for a list view. But be carefull not to much...lol


>
>
> Thoughts? Comments? Suggestions?
> --
> ~ mali (http://constant.inople.net/)
>
> [0] http://mail.kde.org/pipermail/plasma-devel/2009-May/005927.html
> [1] http://blackwater.constant.inople.net/gsoc/usage.txt
> ___
> 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: popupApplet and window focus

[Alexis Ménard]

A popup take by definition the focus in Qt...That's how it is... Since a
virtual keyboard is a particular use case, as i comment let popup applet
neutral and set the flag you need on it in plasmaboard.

2009/5/25 Björn Ruberg 

> On Montag 25 Mai 2009, you wrote:
> > On Monday 25 May 2009, Björn Ruberg wrote:
> > > >> First issue:
> > > >> Plasmaboard uses the class PopupApplet. When clicking on the icon,
> the
> > > >> keyboard appears. This keyboard must stay unfocused! So I used the
> > > >> method setPassivePopup(true). That worked great. But when I upgraded
> > > >> my working machine from Fedora 10 to Fedora 11 Preview it stopped
> > > >> working. Since then the opening keyboard steals focus from the
> window
> > > >> and is useless. This may be a bug invented in qt-4.5 or kde-4.2.2 .
> > > >> setPasivePopup is rarely used, so it is possible that no one
> noticed.
> > > >
> > > >well, it's more like "it's totally cool for popups to have focus" ...
> > > > we'll need some work-around for this for Plasmaboard. either that or
> > > > else Plasmaboard will have to provide and manage it's own popup
> instead
> > > > of relying on PopupApplet for this 
> > >
> > > Sorry, didn't got that completly.
> > > The passive popups worked already. "Suddenly" they are not working.
> >
> > m.. define "not working"; they changed a bit in how they work, but
> that
> > was to fix other issues. passive doesn't mean "can't get focus"
>
>
> Okay. "not working" means it steals focus from the last window.
>
>
> > > Please help me at least with issue one. I think it's quite important to
> > > have a working virtual keyboard for KDE when 4.3 comes out. Cheap
> >
> > i wonder if it would be possible to track the last-focused window and
> just
> > send x events directly to it.
>
>
> Probably we would find a way within kwin. But it must work with plasma and
> other window managers, too. So my way is the bullet proof and always
> working
> one.
>
>
> > but yes, otherwise .. hm ... i think that the
> > keyboard would need to handle it's own popup window and ensure it never
> > gets focus. putting that into passive popup as a general case situation
> > will screw up other widgets that do need focus; perhaps we can fold it
> into
> > popupapplet for 4.4 if there's a general need for it.
>
>
> Well, what about a "setVeryPassivePopup"-method?
>
>
> But before I put the work into investigation how to write my own popup
> (probably I just need to subclass and set some window-flag?), the question
> remains why setPassivePopup suddenly changed its behaviour - or why its
> behaviour is different between Fedora and Ubuntu.
>
>
>
> ___
> 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: Qt Kinetic + Plasma Call For Ideas / Project Plan

[Alexis Ménard]

What about trying to achieve that with the actual grammar that is in dui,
the curly brace based language??

On Thu, May 28, 2009 at 11:14 PM, Akmanalp, Mehmet A wrote:

> On Thu, May 28, 2009 at 9:38 PM, Aaron J. Seigo  wrote:
> > Animation *a = Animator::fadeIn(item);
> > Animation *b = Animator::add(a, Animator::bounce(item, timesToBounce));
> > a = Animator::while(b, Animator::blur(item, amount));
> > Animator::add(a, Animator::fadeOut(item));
> > // auto starts when event loop is hit again, unless a->stop() is called
> >
> > Animation *a = Animator::fadeIn(item);
> > Animator::bounce(item, timeToBounce, a, Animator::Add);
> > Animator::blur(item, amount, a, Animator::While);
> > Animator::fadeOut(item, a, Animator::Add);
> Honestly, I think the add / while syntax is a little unintuitive,
> which is a minus since we're trying to make things as simple as
> possible. Also, what if  want the blur to happen  during the fadein
> and the bounce? I don't see how you'd do this with add-while without
> grouping the fadein and blur.
>
> > * means two phase learning curve (Animator's shortcut, then Kinetic) if
> you
> > need to "graduate" from Add/While in Plasa::Animator to Kinetic's groups
> Following the previous statement, I'd say we just ditch add / while.
> This way, it'd be more consistent with Kinetic *and* it'd be a little
> more intuitive (imho).
>
> Even if we don't create a whole new language as Ivan proposes, we
> could imitate it in the name of ease of use:
>
> Animator a;
> a.animate(item,
>  a.series(
>a.fadeIn(),
>a.parallel(
>  a.blur(amount, time),
>  a.series(
>a.bounce(timesToBounce),
>a.flip()
>  )
>),
>  a.fadeOut()
>  )
> );
>
> Although the a. in the beginning of all of those is a bit annoying.
> Thoughts?
> ___
> 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: Qt Kinetic + Plasma Call For Ideas / Project Plan

[Alexis Ménard]

On Thu, May 28, 2009 at 7:35 PM, Akmanalp, Mehmet A wrote:

> 2009/5/28 Ivan Čukić :
> > One effect that I would need, that would be an extension of
> grow/shrink/scale
> > is grow/shrink/scale while moving.
> > Alternatively, you could make a simple move transition which could be
> combined
> > with g/s/s to achieve the desired effect.
> On this, do you think instead of hardcoding animations together,
> should we have some sort of thing that handles series and parallel
> animations like Kinetic does? So we can tell that we want animations
> that happen simultaneously and that happen after eachother? Silly
> pseudocode example:
>
> doseries(fadein, doparallel(bounce, blur), fadeout)


That is what QSequentialAnimationGroup is doing...


>
>
> would fade in, bounce and blur at the same time, and fade out. Or do
> we not need this at this point?
>
> > The second thing is that you could have the animations for all effects -
> for
> > example gradual fade from one image to another like the taskbar buttons
> do on
> > hover...
> I'm not sure I understand exactly what you mean by "having the
> animations for all effects".
>
> Thanks,
> ~ mali (http://constant.inople.net/)
> ___
> 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

KDE/kdebase/workspace/plasma/applets/systemtray/protocols/fdo

[Alexis Ménard]

SVN commit 971259 by menard:

Mr X really really love when we free his pixmap memory.

Hop hop hop, never forget to release the data that you allocate when
you return in the middle of a method. This code was leaking like a
hell. I'll close the bug open for that.

CCBUG:183191
CCMAIL:plasma-devel@kde.org

 M  +8 -3  x11embedcontainer.cpp  


--- 
trunk/KDE/kdebase/workspace/plasma/applets/systemtray/protocols/fdo/x11embedcontainer.cpp
 #971258:971259
@@ -244,9 +244,11 @@
 else
   image = background.copy().toImage(); //With the X11 graphics engine, we 
have to create a copy first, else we get a crash
 
-if(d->oldBackgroundImage == image)
+if(d->oldBackgroundImage == image) {
+  XFreePixmap(display, bg);
+  XRenderFreePicture(display, picture);
   return;
-
+}
 d->oldBackgroundImage = image;
 
 if (background.paintEngine()->type() != QPaintEngine::X11) {
@@ -342,8 +344,11 @@
 ximage.blue_mask= 0x001f;
 }
 ximage.obdata   = 0;
-if (XInitImage(&ximage) == 0)
+if (XInitImage(&ximage) == 0) {
+XRenderFreePicture(display, picture);
+XFreePixmap(display, bg);
 return;
+}
 
 Pixmap pm = XCreatePixmap(display, clientWinId(), width(), height(), 
ximage.depth);
 GC gc = XCreateGC(display, pm, 0, 0);
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma + QT Kinetic gSoC Project, Looking for co-mentor

[Alexis Ménard]

I agree to follow that student as i said on IRC. Just need to manage that
with Google.

On Wed, May 13, 2009 at 1:30 PM, Mehmet Ali Akmanalp wrote:

> Hello,
> I'm an accepted student for gsoc at Pardus [0][1]. My project was to
> add a plugin for KDM (among other things) to support fingerprint
> authentication, but we recently found out that it was already done and
> there is no reason to reinvent the wheel. So, I've been looking around
> for projects and I came across the Plasma / Qt Kinetic integration
> project. When I checked, I found that the project wasn't taken, and I
> would like to do it. I think it's a good idea to have some sort of
> collaborative effort between me and my mentor at Pardus, the QT
> Kinetic people and the KDE plasma people. I've talked to darktears
> (Alexis Menard from Qt-Kinetic, one of the two original mentors for
> the project) on #qt-kinetic and sebas (Sebastian Kügler) on #plasma
> and both seemed positive about the idea, and so did aseigo. Any
> thoughts on this? I will send an e-mail to the google gsoc people next
> to figure out the bureaucracy (how the mentors will be assigned, how I
> can change my project and such).
>
>
> [0] http://www.pardus.org.tr/eng/index.html
> [1] http://socghop.appspot.com/org/home/google/gsoc2009/pardus
> ~ mali (http://constant.inople.net/)
> ___
> Kde-soc-mentor mailing list
> kde-soc-men...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-soc-mentor
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Unprofessional text in plasmoids for download

[Alexis Ménard]

As Aaron said in the bug report, it is provided by kde-look.

If you want something happen it should be on the website BEFORE they appear
online.

Can you propose us a solution (technical or not) for the KDE/Plasma side to
basically check if the content is ok? A spellchecker? A my
sentenceMakeSenseChecker? It's impossible for us to check that.

So obviously this is not the right place to deal with that but more with
people that take care of kde-look.

I would say please keep a category where i can do whatever i want including
bad comments just to let people trying.

As you probably noticed the applets we ship in KDE have a proper comment
because we checked same BEFORE it end up in packages, same it has to be one
BEFORE it goes online on kde-look.

On Mon, Apr 27, 2009 at 9:59 PM, Dotan Cohen  wrote:

> I reported a KDE bug regarding the summary text of kde-look plasmoids
> that are appearing in the Add Plasmoids dialogue. Here is the bug:
> https://bugs.kde.org/show_bug.cgi?id=190779
>
> The lead Plasma dev suggested that I write to this address with details
> about which plasmoids have bad grammar, immature, or other undesirable
> text.
>
> Magic Folder: A Plasmoid someone asked for
> Not only is this incorrect grammar (missing "that"), it does not
> describe what the plasmoid does.
>
> Kulo: This is my first plasmoid, written in python, using...
> There is no description of what the plasmoid does. Nor does the user
> care if this is the dev's first of five hundredth plasmoid.
>
> T-arduino: This is a simple plasmoid written in python. It read...
> Again, no description of what the plasmoid does. What does the user care
> what language it is written in?
>
> QuickUrl: This very simple plasmoid offers the possibility to a...
> No description of what the plasmoid does, but at least the name gives a
> hint. I suppose if the introductory text were longer the author would
> have gotten around to mentioning what his creation does.
>
> Tarmoid: Tarmoid
> No description of what the plasmoid does.
>
> There are many more examples, but I would like to point out that stating
> that a plasmoid is "simple" or "a plasmoid" is redundant when there is
> so little space to make use of. Please have someone proofread the
> descriptions, correct errors, and ensure that the description is concise
> enough to describe the plasmoid in the space allocated for it.
>
> Thanks.
>
> --
>
> Dotan Cohen
>
> http://what-is-what.com
> http://gibberish.co.il
>
> * Please DO NOT send me forwards or chain letters.
> * Send mail in UTF-8 text. Do not send Word documents.
> * Use BCC for sending email to multiple recipients. DO NOT use To or CC.
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasmoide "cadre photo

[Alexis Ménard]

Hello Maxime,

The appropriate mailing-list is plasma-de...@kde.org.
Please post your message in English since not all of the developers speak
french.

I translate :

"The widget picture frame is wonderful. I have two ideas to improve it :

- A possibility to increase sizes of pictures.

- Display the name of the directory when it is in random mode and the applet
pick in different directories/sub-directories.

See you, good luck and long life To KDE."

2009/4/18 richard maxime 

> salut,
>
> le plasmoide "cadre photo" est génial. J'ai deux propositions à faire:
> -> permettre d'agrandir les tailles des photos
> -> afficher le nom du dossier ou sont piochés des photos si on prend un
> diaporama de plusieurs sous-dossier.
> a+ et bon courage
> vive KDE
> petit penguoin
> OS: Kubuntu-RC-9.04
>
>
>
> ___
> 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: Contrast plasma::theme color issues

[Alexis Ménard]

I can understand the branding though, otherwise you can't differentiate a
distrib A to a distrib B. But is it really what the end user want? no, he
just want something that works, cool, new, and beautiful.

I have also many friends asking how to remove the opensuse logo and instead
use KDE one for the K Menu.

For me now, what makes a difference between distrib A and distrib B is what
it is inside. Branding and so, i simply don't care because like most of
users i remove the default wallpaper, the default theme and all the default
layout of the panel to match to my own workflow and my habits. So by "what
is inside" i mean packages quality, graphical tools for end users to set up
network, graphic card and so. Those tools has to be easy to use and then i
install this distrib to my friend or tell them that is a good choice to
start.


On Thu, Apr 9, 2009 at 9:52 PM, Marco Martin  wrote:

> On Thursday 09 April 2009, nuno pinheiro wrote:
> ...
> > In this case i know and its couse the marketing team in mandriva wants
> > gnome and kde desktop to look alike, so yeah
> > g. makes me wonder wtf do
> we work
> > for
> > fortunatly every one i know the frist thing they do with the kde desktop
> in
> > mandriva is to change to kde defoults,
> > Helio galaxy theme looks a bit old.
> interesting related story, that i think it kinda exposes the problem with
> distro theming/branding:
> a friend of mine recently installed linux, after my of course totally
> neutral
> advices chose kde (was opensuse, similar choices in theming and branding),
>
> after some days he asked me how he could remove all the branding from it
> because he said it looked exactly like the branded firmwares of the
> cellphones
> that operator sell (their logo everywhere, functions crippled etc..)
>
> if distros are getting really a bad image like the cellphone operators (and
> is
> reeeally a bad rep:) there is really something wrong, because they don't
> deserve it
> i hope they understand they are nearly committing suicide with this,
> because
> mandriva and opensuse are pretty solid distributions otherwise
>
> Cheers,
> Marco Martin
>
> >
> >
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Contrast plasma::theme color issues

[Alexis Ménard]

Completely agree on that...Same for OpenSuse 11.1 they ship Aya by default,
first thing i do (when it's not my own build), get rid of the ugly default.

Please listen users (and sometime just ask them what they want or what are
their habits)
They want NEW stuff not a KDE3-like theme.

What i still don't understand is that the default of plasma is oxygen theme,
why changing it? Why shipping oxygen windec by default so? Why not using
plastique in that case?

And i have to say that Aaron is right, the first impression you have is not
really impressive in that case.

On Thu, Apr 9, 2009 at 9:27 PM, nuno pinheiro  wrote:

> A Quinta 09 Abril 2009 18:40:46 Aaron J. Seigo você escreveu:
> > On Thursday 09 April 2009, Helio Chissini de Castro wrote:
> > > For light backgrounds with white text, there's no same issue. Happens
> > > always in the combination of dark background with light themes.
> >
> > the solution is simple: make the halo larger and perhaps don't use such a
> > small font.
> >
> > > So, for 4.4 maybe is a good idea to study this specific issue and have
> > > some solution for this, but for now, i'm out of a simple solution than
> do
> > > a ugly hack for solve our issues.
> >
> > it doesn't require an ugly hack at all. here's your patch, applies in
> > kdelibs/plasma/:
> >
> > Index: widgets/iconwidget.cpp
> > ===
> > --- widgets/iconwidget.cpp  (revision 951209)
> > +++ widgets/iconwidget.cpp  (working copy)
> > @@ -976,7 +976,7 @@
> >  shadowOffset = QPoint(0, 1);
> >  }
> >
> > -PaintUtils::shadowBlur(shadow, 2, d->shadowColor);
> > +PaintUtils::shadowBlur(shadow, 4, d->shadowColor);
> >  painter->drawImage(textBoundingRect.topLeft() + shadowOffset,
> shadow);
> >  d->drawTextItems(painter, option, labelLayout, infoLayout);
> >  }
> >
> > > So we need at least in future the possibility of set color for items
> like
> > > icon text color, desktop plasma menu text color, etc...
> >
> > not necessary.
> >
> > now the commentary part of my email:
> > > First of all, here's the screenshot of basically the default desktop:
> > > http://users.mandriva.com.br/~heliocastro/mandriva_free.jpg
> > >
> > > So, we are using Aya theme, against a dark background.
> >
> > may i ask: why Aya?
> >
> > we include Aya for boring, conservative desks. think "i'm an accountant
> and
> > always wear a yellow bow tie to work. sometimes i put sugar *and* cream
> in
> > my coffee!!!"
> >
> > i dunno .. it's like giving people the choice between a cool, hip suit
> and
> > a paper bag and they pick the paper bag to wear outside.
> >
> > i'm really disappointed in defaults distros are choosing because they
> > totally make it pointless for us to do any art when the distros prove
> over
> > and over that they have no taste and therefore will inflict their lack of
> > taste on the user.
> >
> > this sort of decision making is killing kde on the desktop. think "first
> > impressions" and guess what people will think when they look at what you
> > just sent us. ugh!
> >
> > and before you say "oh, but people like simple and plain" i say
> "bullshit,
> > go look at how everyone wants a mac".
> >
> > some day i wonder why we even bother trying to make things look good
> > upstream.
>
> In this case i know and its couse the marketing team in mandriva wants
> gnome
> and kde desktop to look alike, so yeah
> g. makes me wonder wtf do we work
> for
> fortunatly every one i know the frist thing they do with the kde desktop in
> mandriva is to change to kde defoults,
> Helio galaxy theme looks a bit old.
>
>
> ___
> 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: Support for transparent panel without composition

[Alexis Ménard]

On Mon, Mar 30, 2009 at 9:15 PM, David Nolden  wrote:

> Am Montag 30 März 2009 21:32:47 schrieb Alexis Ménard:
> > That is not completly true. With composition we let the graphics card do
> it
> > for us. We fill the background transparent that is all.
> You don't do that for plasmoids, do you?
>




> > In your case at each paintEvent on the panel you will end up to grab the
> > widget behind, create a pixmap, then blend each pixels with the panel
> > itself. Those are not free operations, especially on a device (we want
> > Plasma running on that too). So on those devices that don't have
> > compositing, we don't want by default that option. Then you have the
> > overhead in DesktopView::paintEvent() to check if you should invalidate
> and
> > call a repaint on the panel. I think it is overhead because most of the
> > paint event the check will be useless. So then solutions, cache the
> pixmap
> > which is blended and don't do the check change into paintEvent of the
> > DesktopView. But what happened there? Kickoff 2.0, when we should
> > invalidate the cache? When we should repaint? I forgot that updating
> > the whole panel like you do will end up to paint all applets in the
> panel,
> > even if there are cached they will be mark as dirty, for example the K
> Menu
> > will be repaint even if it don't need it (not transparent).
> Since the background of the panel usually only consists of the wallpaper,
> this
> should be a cheap operation, essentially not much different from what
> QGraphicsVIew does internall when it renders a plasmoid on top of the
> background.
>
> The overhead to check for intersection with panel is extremely small, not
> even
> worth noting. It's done per-event, not per-pixel.


Put a QDebug and look how many times you enter in the paint event of the
DesktopView. A lot! Lot of thing happen into the desktop even if the painter
is clipped you end up into the paintEvent anyway and do your intersection. I
agree that is not an expensive op but still it think that is overhead for a
feature that doesn't affect most of users now.


>
>
> Not the whole panel is updated, only the part of it that intersects with
> the
> changed background part, so that part of your criticism is wrong. Please
> read
> the patch more exactly.


Yep but let's say you update the rect under the K Menu, you will repaint the
K Menu (because of update(), so it include the icon too), this things will
not happen with the compositing since the icon of KMenu is opaque. As I said
it not a big deal but it is not sexy.


>
>
> > So i think i will follow aaron and i think that is not an optimal idea.
> For
> > two reasons, Linux start to have proper drivers, and it's going to be
> > better every day, Gallium3D start to be supported by the industry (for
> the
> > future). More and more distributions come with packages that have
> > composition enabled and proper drivers. The second reason as i said is
> > devices, that will not help us to make Plasma + QGV fast on those devices
> > (those that don't have compositing).
>
> Who cares how future devices will be? Who cares how future drivers will be?
> We
> are already working on KDE 4.3, something that is called "stable" for
> public
> use, right now! Why doesn't even a single plasma developer seem to care how
> current or even past devices work?


We care, we just think that it is not useful to support that. Supporting,
maintaining and adding a "workaround" for a feature that is already provided
by the compositing is not relevant i think. Let's use what we have now and
let's behind us workarounds that we had for KDE3.
In KDE3 time we didn't have that, so those kind of workarounds was the only
solution.


> Do you expect everyone to dump his computer
> just to get a nice looking Desktop? Or are you planning to position plasma
> as
> a desktop-shell only for new computers, aka. Vista for Linux?
>

Nice looking with actual technologies. It is very current that a game is not
with full details because you graphics card X doesn't provide the Y
functionnality. Same here.


>
> Sorry, but I find this attitude disappointing.


We just give our point of view.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Support for transparent panel without composition

[Alexis Ménard]

On Mon, Mar 30, 2009 at 6:13 PM, David Nolden

> wrote:

>
>
> > On 2009-03-30 08:33:22, Rob Scheepmaker wrote:
> > > Keeping this all within the desktop shell is a clear improvement over
> 'contaminating' libplasma, though I'm still not a big fan of supporting fake
> transparency. Realize, that with somewhat decent drivers, real transparency
> through compositing is most likely faster then fake transparency. It's
> designed for that sort of thing, just like moving a window in front of
> another window is also faster with compositing on, because the other window
> doesn't continuously need to repaint. Of course compositing had it's
> problem, which used to make compositing quite slower in practice, but
> nowadays, I can't really say I can notice any performance difference between
> using compositing and not, except a slight increase in memory usage, and a
> slightly warmer gfx card. So the 'snappy desktop' argument is not really
> valid imo. The only reason why you would want fake transparency is old
> hardware (not even low end, a lot of modern low end hardware handles
> compositing just fine) and/or crappy drivers. The crappy drivers part: one
> of the things I like about plasma is that it doesn't hack around problems in
> the software stack below it, it exposes those problems, and forces the stack
> below to improve, which benefits much more then just plasma. So that keeps
> people with old hardware as primary target for this patch. And really: if
> you really care about eye candy, why not spend 20 bucks on a new low end gfx
> card that handles compositing smoothly?
> > > It also doesn't really decrease the amount of work that goes inside
> creating a theme significantly, because there's still quite some stuff that
> NEEDS an opaque version, like the dialog graphics (Plasma::Dialogs usually
> appear in front of other windows, so using fake transparency would be a
> really bad idea there), and extender items (needed for creating the pixmap
> used while dragging an item around). And having a fake transparent panel
> combined with a opaque plasma dialog connected to it would look. a bit
> odd imo.
> > >
> > > So long story short I personally think the advantages are too few to be
> worth introducing this hack into plasma. But if enough people think
> otherwise, feel free to ignore my opinion...
> >
> > David Nolden wrote:
> > I have a geforce 9600GT, had a 7600GT before, am using the newest
> nvidia drivers. This is probably the best supported and close to the fastest
> hardware available for linux composition, still under high workloads(4 times
> make, 1 kdevelop parsing, 1 amarok), it feels extremely sluggish, and even
> without that workload it _always_ lags a few milliseconds. To you those
> milliseconds might not matter, but to me they do.
> >
> > Also, games are much slower just when enabling the composition in the
> xorg.conf.
> >
> > The only other hardware that right now supports composition in an
> acceptable way is probably the intel drivers, but those cards are usually
> also to slow to fire a full composited 3200x1200 Desktop. My old intel
> notebook had even too slow graphics to composite a 1024x768 Desktop in an
> even remotely acceptable way.
> >
> > I didn't even want to discuss about these issues, the key point is:
> There is _many_ reasons not to use composition, and many people who cannot
> use it. There probably always will be.
> >
> > Also, think for example about the KDE feature that shuts off
> composition when power is very low. How unbelievable ugly is it right now,
> when for example the glassified theme is used, and it shuts the composition
> off for you?
> >
> > The key point: Just because composition works for you does not mean
> it works for everyone. Also, you shouldn't tell people they need to buy new
> hardware, just so they can do something that there hardware is perfectly
> capable of(That is _that other OS_ style ;-)
>
> Btw. with that patch, the panel is rendered in exactly the same way as a
> plasmoid, so if you think the performance is problematic, then you should
> equally worry about those
>

That is not completly true. With composition we let the graphics card do it
for us. We fill the background transparent that is all.

In your case at each paintEvent on the panel you will end up to grab the
widget behind, create a pixmap, then blend each pixels with the panel
itself. Those are not free operations, especially on a device (we want
Plasma running on that too). So on those devices that don't have
compositing, we don't want by default that option. Then you have the
overhead in DesktopView::paintEvent() to check if you should invalidate and
call a repaint on the panel. I think it is overhead because most of the
paint event the check will be useless. So then solutions, cache the pixmap
which is blended and don't do the check change into paintEvent of the
DesktopView. But what happened there? Kickoff 2.0, when we should invalidate
the cache?

Re: [GSoC] Review on QtKinetic+Plasma Proposal

[Alexis Ménard]

It sounds ok for my side.

On Wed, Mar 25, 2009 at 10:51 PM, Jesus Sanchez-Palencia
wrote:

> Could you guys please review my proposal before I send it to Google ?!
> For your consideration: http://docs.google.com/Doc?id=ddq4rqn6_55fzr8skdt
>
> I'll be waiting for your comments!
>
> Thanks in advance,
> jeez
>
>
>
>
>
> ___
> 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: [GSoC] Qt Kinetic + Plasma

[Alexis Ménard]

Hello,

Me and Morpheuz working on Qt Kinetic so you will have mentors that are
inside the "thing".

You can contact us on IRC, Morpheuz and darktears, then we can talk about
that.

There is a channel qt-kinetic that you can join too on freenode.

2009/3/13 Jesus Sanchez-Palencia 

> Hello, everybody!
>
> My name is Jesus Sanchez-Palencia and I'm a Computer Engineering
> undergraduate student at CIn-UFPE (http://www.cin.ufpe.br/english/),
> Brazil. Right now, I'm on my last semester at the university.
>
> I was taking a look at your ideas to GSoC 2009 and I was particularly
> interested on this QtKinetic + Plasma integration. I have some background on
> the Kinetic project, have been playing with it since the first public git
> repository was up. Also, I've been following weekly the API changes
> regarding the Animation stuff.
>
> Hope you guys can help me out on writing the project proposal! I'll try to
> contact the possible mentors in order to talk about this project better. You
> can find me as jeez (or jeez__) at #plasma.
>
> Thanks in advance!
> jeez
>
>
>
> ___
> 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: Problems with QGraphicsLayout

[Alexis Ménard]

Oops error with keyboard

If you never set a minimum size how Qt can know it? I remember that your
widget is custom...

In QWiget we set an arbitrary size and in QGraphicsLayoutItem we set 40*40
if i remember.

On Sun, Mar 1, 2009 at 5:58 PM, Alexis Ménard  wrote:

> MM, if you never set aminimun size of Qt can know?
>
> In QWiget we set an arbitrary size and un LayoutItem we set 40*40 if i
> remember.
>
>
> On Sat, Feb 28, 2009 at 7:32 PM, Marco Martin  wrote:
>
>> On Saturday 28 February 2009, Matthias Fuchs wrote:
>> > > The Labels shall only be as large as the text is. One reason for that
>> is
>> > > that I use isUnderMouse() to detect clicks on the label and I also set
>> a
>> > > cursor for the label. And empty space should not result in a different
>> > > cursor or in visiting a website if you click on it.
>> >
>> > Ok, for people with the same problem: Setting the minimumWidth fixed it
>> so it means that setSizePolicy(Minimum, Minimum) is still broken in qt :/
>>
>> > ___
>> > 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
>>
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Problems with QGraphicsLayout

[Alexis Ménard]

MM, if you never set aminimun size of Qt can know?

In QWiget we set an arbitrary size and un LayoutItem we set 40*40 if i
remember.

On Sat, Feb 28, 2009 at 7:32 PM, Marco Martin  wrote:

> On Saturday 28 February 2009, Matthias Fuchs wrote:
> > > The Labels shall only be as large as the text is. One reason for that
> is
> > > that I use isUnderMouse() to detect clicks on the label and I also set
> a
> > > cursor for the label. And empty space should not result in a different
> > > cursor or in visiting a website if you click on it.
> >
> > Ok, for people with the same problem: Setting the minimumWidth fixed it
> so it means that setSizePolicy(Minimum, Minimum) is still broken in qt :/
>
> > ___
> > 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
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: How to adjust applet size according to its child QGraphicsWidget?

[Alexis Ménard]

Ok,

I found the problem. Nowhere you set the size of MyGraphicsWidget, so the
layout can't know about its size, and more you never set the preferredSize
so it use the default which is arbitrary small. Take a look on the doc for
setPreferredSize, setMinimumSize, setMaximumSize and the overload of
sizeHint for custom sizeHints.

Btw :

QSizeF s = parentWidget()->size()

That is not a good approach in the paint event.

2009/2/25 Petri Damstén 

> On Wednesday 25 February 2009 12:05:52 Dong Tiger wrote:
> > 2008/12/30 Alexis Ménard 
> >
> > > Unfortunately you can't it is a bug in Qt.
> > >
> > > You can take a look to the task tracker of Qt Number 231114 and 211500.
> I
> > > guess it is what you try to solve. The fix is in 4.4 branch (so
> scheduled
> > > for 4.4.4) and in 4.5.
> >
> > I still can't get this work even with latest Qt4.5. I've attached code of
> a
> > sample plasmoid which demonstrate the problem. You are welcomed to try it
> > out. Right click on the applet to modify its child widget size.
> >
> > > As a workaround you have to manage the resize of your applet by hand
> when
> > > the size of the layout change.
> >
> > The question is how can I do it? When the embedded QGraphicsWidget need
> to
> > enlarge, say from 200x200 to 400x400, how can I decide what the applet
> size
> > should be?
>
> Does this work?
>
> Petri
>
>
> ___
> 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: Sets the focus for widget in Plasma::Dialog on show

[Alexis Ménard]

I closed some bugs because people where complaining that the notifier took
the focus. The use case was :

I typing a mail and a notification pop, then the focus moved to the
notifier, i don't care, i want to continue typing my mail...

If you are chatting and then the thing pop and steal your focus, it is
annoying...

An option instead?

On Mon, Feb 23, 2009 at 1:30 PM, Ivan Cukic

> wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/161/
> ---
>
> (Updated 2009-02-23 04:30:15.258007)
>
>
> Review request for Plasma.
>
>
> Summary
> ---
>
> Sets the focus of the view and the QGWidget that is contained in this
> Plasma::Dialog on show event.
>
>
> Diffs (updated)
> -
>
>  /trunk/KDE/kdelibs/plasma/dialog.cpp 929387
>
> Diff: http://reviewboard.kde.org/r/161/diff
>
>
> Testing
> ---
>
>
> Thanks,
>
> Ivan
>
> ___
> 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-mid

[Alexis Ménard]

>From my side i will be ok to work on it but as i said to Morpheuz i will
need help because i am pretty busy.

So i need help for the artwork and for patches if they come.

Having plasma-mid, i can see two benefits,having a real alternative to the
GTK stuff on Maemo...I want to get rid of... I think plasma can perfectly
fill in that device and handle at least what's hildon do. And more Plasma
can run on other platforms/device.

At the same time it match with what we need here in Qt Software, make Qt
faster and faster on devices.

2009/2/20 Artur Souza(MoRpHeUz) 

> hi!
>
> On Friday 20 February 2009 00:53:28 Aaron J. Seigo wrote:
> > but we ought to turn some guns on plasma-mid as well, but only if we have
> > them to spare.
> >
> > realistically, i'm already maxed out and can't give it the care,
> attention
> > and love it will take to make plasma-mid all that it should be. i can be
> > here to support that effort and even contribute, but for it to become a
> > reality, someone needs to make it Their Baby.
> >
> > is there anyone on the list who'd be up for that? it would mean:
>
> Here is the deal: I really have to give some love to Plasmate but, if I can
> find a student from GSoC to work either on Plasmate or on plasma-mid, I
> would
> really love to have a baby like plasma-mid. I'm just not sure I can handle
> plasma-mid + plasmate "full time" as both deserve a lot of attention...
>
> > if you're already busy with other important plasma things (yes, i'm
> looking
> > at you marco ;) please don't shift your attention just because of this
> > email. worst case scenario is plasma-mid sits for a little longer, best
> > case is that someone with some time available each week who hasn't found
> > "their niche" yet in plasma will be excited about helping create the
> future
> > of netbooks and get obsessed with plasma-mid. :)
>
> In worst scenario we can have some people taking care of plasma-mid (even
> if
> it's not their _main_ baby). I mean, me + marco + sebas? + aaron + whoever
> is
> interested would make it happen.slower than if someone had it as a baby
> but it would work...
>
> So, I'm really looking forward someone willing to help either on Plasmate
> or
> Plasma-midin both scenarios I would love to have plasma-mid as my baby
> (for some reason I feel that this conversation taken out of context would
> look
> strange hehe =P ).
>
> Cheers!
>
> PS: maybe I can bug pinheiro + some canola's designer to help on the mockup
> of
> this thinghhmmm ;)
>
> --
> Artur Duque de Souza
> OpenBossa Research Labs
> INdT - Instituto Nokia de Tecnologia
> --
> Blog: http://labs.morpheuz.eng.br/blog/
> GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net
> --
>
>
>
> ___
> 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, ARGB and 4.5

[Alexis Ménard]

The one pixel thingy was commited 10 minutes ago, so we reach the snapshots
tomorrow :D

Nice to hear that all issues are fixed one by one :D

On Tue, Feb 17, 2009 at 11:29 AM, Marco Martin  wrote:

> On Monday 16 February 2009, Marco Martin wrote:
> > On Monday 16 February 2009, Aaron J. Seigo wrote:
> > > On Friday 13 February 2009, Marco Martin wrote:
> > > > Hi all,
> > > > right now plasma enables argb visuals with that magin X11 code pasted
> > > > in many places...
> > > > since 4.5 now can handle it
> > > > by setting Qt::WA_TranslucentBackground on the top level window we
> want
> > > > transparent we can make it in a prettier way
> > >
> > > that would be nice.
> >
> > done,
> > seems to work quite good, except for two things:
> > the tooltips seems to insist that they don't want to be transparent
> > the systemtray has garbage again with the raster graphicssystem (so i
> > didn't dream it up) i'm not sure if that's the case also with the old
> > method btw
> update: tred with the latest qt snapshot and tooltips opacity is
> automagigally
> fixed there, so we just have to be a bit patient :D
> also some other little annoyances are fixed:
> on autohide panels the cashew was disappearing
> also the weather icon was disappearing when the tab were switched from 5
> days
> view to details
>
> those 2 issues are fixed as well :D
> ___
> 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, ARGB and 4.5

[Alexis Ménard]

I you change the graphicssystem and you have already opened the application
that will be embedded, then you will have garbage...You shoud restart those
applications to reembed them...

On Mon, Feb 16, 2009 at 10:51 PM, Marco Martin  wrote:

> On Monday 16 February 2009, Aaron J. Seigo wrote:
> > On Friday 13 February 2009, Marco Martin wrote:
> > > Hi all,
> > > right now plasma enables argb visuals with that magin X11 code pasted
> in
> > > many places...
> > > since 4.5 now can handle it
> > > by setting Qt::WA_TranslucentBackground on the top level window we want
> > > transparent we can make it in a prettier way
> >
> > that would be nice.
> done,
> seems to work quite good, except for two things:
> the tooltips seems to insist that they don't want to be transparent
> the systemtray has garbage again with the raster graphicssystem (so i
> didn't
> dream it up) i'm not sure if that's the case also with the old method btw
>
> i really hope those two aren't insolvable issues, otherwise it would be
> necessary to return back..
>
>
>
> ___
> 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: bisecting the 1-pixel bug

[Alexis Ménard]

Hi,

This is fixed, i will have the review tomorrow and i will push it for 4.5.0
final.

But to be sure it works you have to clean the cache in your
.kde4/cache-*/kpc/plasma*

Otherwise it won't redraw all svgs without the 1 px bug.

On Sat, Feb 14, 2009 at 5:33 PM, Alexis Ménard  wrote:

> Ok thanks for taking time...we are still on it...Monday i will take a look
> on it and provide that to our graphics team.
>
> 2009/2/14 Marco Martin 
>
>> Hi all,
>> before i forget the details, i've done some tests about the 1 pixel bug in
>> framesvg and what i found is this:
>> it happens only when the svgrenderer paints on a qpixmap, if asked to
>> paint on
>> all of it, sometimes the last pixel gets not painted, the minimum amount
>> of
>> code to reliably cause this is the file attached, note the 1 pixel red
>> line
>> that appears sometimes.
>>
>> i've done a git bisect on the qt/all snapshot branch and probably doesn't
>> tell
>> that much (it does just reflet snapshots and not actual commits right?)
>> but what i've found, if i didn't did terrible mistakes is that:
>>
>> (if it's not a really trivial thing to fix i'm going to post this on the
>> qt
>> task tracker)
>>
>> 355c90dad265a6c3b20f7bffeeabdc420ace78ee is first bad commit
>> commit 355c90dad265a6c3b20f7bffeeabdc420ace78ee
>> Author: Snapshots 
>> Date:   Wed Dec 3 02:00:16 2008 +0100
>>
>>Update to Qt 4.5 snapshot 20081203
>>
>> :100644 100644 f053d8e7342aa99764f9f4674296d9ca9a4db372
>> 8a9943da9b00c055f7d8dd5ebaffe0698c9502b4 M .tag
>> :04 04 24d96e05510c648058db5df5b5ef2bbad15f82c9
>> 7961db773e9b5b60ec300edbddcc87998d1c068b M doc
>> :04 04 60df8b9737bcb54961c379640241c725963dee04
>> 7d3f9d1080034f16a11fc1a7caf0d581a59ed4a9 M qmake
>> :04 04 f89dd3fb8c536d65c8a0f091807c0a61030b4f59
>> ded3aa6cdf7bec61efad821e255565a07c39452b M src
>> :04 04 6edf3b7029b91891f30295e21e49f9a6c1380159
>> 20fa707790f7a3d935642e39ac7561832d9692c7 M tools
>>
>> ___
>> 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: bisecting the 1-pixel bug

[Alexis Ménard]

Ok thanks for taking time...we are still on it...Monday i will take a look
on it and provide that to our graphics team.

2009/2/14 Marco Martin 

> Hi all,
> before i forget the details, i've done some tests about the 1 pixel bug in
> framesvg and what i found is this:
> it happens only when the svgrenderer paints on a qpixmap, if asked to paint
> on
> all of it, sometimes the last pixel gets not painted, the minimum amount of
> code to reliably cause this is the file attached, note the 1 pixel red line
> that appears sometimes.
>
> i've done a git bisect on the qt/all snapshot branch and probably doesn't
> tell
> that much (it does just reflet snapshots and not actual commits right?)
> but what i've found, if i didn't did terrible mistakes is that:
>
> (if it's not a really trivial thing to fix i'm going to post this on the qt
> task tracker)
>
> 355c90dad265a6c3b20f7bffeeabdc420ace78ee is first bad commit
> commit 355c90dad265a6c3b20f7bffeeabdc420ace78ee
> Author: Snapshots 
> Date:   Wed Dec 3 02:00:16 2008 +0100
>
>Update to Qt 4.5 snapshot 20081203
>
> :100644 100644 f053d8e7342aa99764f9f4674296d9ca9a4db372
> 8a9943da9b00c055f7d8dd5ebaffe0698c9502b4 M .tag
> :04 04 24d96e05510c648058db5df5b5ef2bbad15f82c9
> 7961db773e9b5b60ec300edbddcc87998d1c068b M doc
> :04 04 60df8b9737bcb54961c379640241c725963dee04
> 7d3f9d1080034f16a11fc1a7caf0d581a59ed4a9 M qmake
> :04 04 f89dd3fb8c536d65c8a0f091807c0a61030b4f59
> ded3aa6cdf7bec61efad821e255565a07c39452b M src
> :04 04 6edf3b7029b91891f30295e21e49f9a6c1380159
> 20fa707790f7a3d935642e39ac7561832d9692c7 M tools
>
> ___
> 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: Qt 4.5 and KDE 4.2

[Alexis Ménard]

2009/2/13 Chani 

>
> >
> > Therefore, in order to provide the best possible user experience, please
> > let us know of issues you encounter, especially in Plasma combined with
> Qt
> > 4.5. The Plasma team is willing to work out the kinks that might be
> there,
> > but we'll need help testing the fixes. The good news is that the issues
> are
> > usually quite well visible, so they should be rather easy to catch, just
> > watch out for screwed up layouting, especially where widgets resize
> > dynamically. The twitter applet comes to mind here, for example.
> >
>
> since 4.5, keyboard shortcuts only work on the dashboard and screensaver,
> not
> on the desktop alone. I haven't been able to figure out why, and haven't
> ruled
> out the possibility that something changed around the same *time* as 4.5
> came
> in. I'd really appreciate it if someone could test for that in kde4.2 - now
> that I'm safey home I kinda need to go dig myself out of the backlog of
> homework and it'll take a while :)
>

Since 4.5 QGraphicsWidget support shorcuts, i guess they clash, i am
actually taking a look on it.


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

Re: Plasma/Kwin cooperation to achieve efficacy of Activites spatial metaphors

[Alexis Ménard]

On Tue, Feb 10, 2009 at 6:02 PM, Lucas Murray wrote:

> On Wed, Feb 11, 2009 at 12:27 AM, Jud Craft  wrote:
> > It is the height of audacity to come out of the woodwork and suggest
> > design ideas for a system that I do not create myself.  Nevertheless,
> > you might actually like some of these.
> >
> > I promise it will be entertaining.  Broken into two sections, A and B.
> >  Also long.  Have a great day!
> >
> >
> > A.  Effective Communication of Activities' Design
> > 
> > First, for KDE to effectively continue its embrace of Plasma, a good
> > campaign must be focused on explaining the benefits of the Activities
> > system to the casual user.  It doesn't help that until now it has
> > seemed mostly at cross-purposes with the old idea of virtual desktops.
> >  (I didn't say it was.  I said it _seemed_.  If it didn't, there
> > wouldn't be so much ill-will about it.)
> >
> > It doesn't help that the transitioning-between-Activities bears little
> > distinction from transitioning  between workspaces/virtual desktops.
> > It's sometimes hard for the user to figure out exactly what the big
> > deal is.  Personally, I rationalize it myself this way:
> >
> > --Virtual desktops are like having a really huge desk in your office.
> > There's plenty of room for stuff, but you have to reach around to get
> > to any of it.
> >
> > --Plasma Activities are like having _different_ desks in your office.
> > For example, one for essay writing, one for your reading, and one for
> > communication (memos, letters, in and out boxes).
>
> I see them the other way around but lets carry on...
>
> > The idea of "having more than one desk VS having a huge desk" is
> > immediately apparent to any office and home user; in fact, if you ever
> > create an in-KDE tutorial to explain how Activities work, and maybe
> > guide the user through creating one, I highly suggest you use that
> > metaphor pervasively.
> >
> > 1.  In fact, perhaps you should re-do the nomenclature and describe
> > them as "Desks"  (formerly activities) and "Desk size" (formerly
> > virtual desktop dimensions).  I could have a "Internet" desk that is
> > 2x2 screens wide, and a "Programming" desk that is 4x4 screens wide
> > for example.
> >
> > This resolves ambiguity between "just more space" and "space dedicated
> > to a special purpose".
> >
> > 2.  There should be a freaking-easy-as-dirt way to switch between
> > Activities (though I do like "Desks").  The Zooming-User-Interface
> > doesn't cut it, especially since it's at cross-purposes with the
> > traditional zoom-in/out on a surface metaphor of virtual desktops.
> > There is an inherent spatial conflict, don't ignore it.  The typical
> > office user doesn't care what your spatial metaphor is (or even what
> > they _are_), but he _will_ notice if it's inconsistent.
> >
> > A simple menu widget that when clicked, presents a list of Activites.
> > With two clicks, you can select any Activity.  (You'll assume the user
> > won't have 10+ Activities.  That's too enthusiastic).  Perhaps this
> > menu can pop up when the Cashew/Acorn-thing is clicked, as opposed to
> > strange terms like "Zoom Out", which does nothing to describe the
> > contextual novelty of the Activity idea.  Activities describe
> > different abstract spaces, not a web page.
> >
> > This same Activity Menu could be integrated into Kicker (a tab for a
> > list of all current activities -- you could switch with just one
> > click!) or into a panel-widget that triggers the menu.
> >
> >
> > B.  Working With Kwin to Resolve Spatial Conflicts
> > 
> > The main interaction layer with Activites, the Zooming User Interface,
> > in its current form isn't gonna cut it.  Even further development
> > isn't gonna cut it -- maybe you guys have some sort of brilliant
> > vision that pops up in ephemeral IRC logs, but I haven't seen it on
> > this list or Aaron Seigo's blog.  (No offense of course.  You might
> > not post it here, it might be at Techbase, or it might not exist).
> >
> > Suggestions.
> >
> > 1.  Team up with Kwin for Activites-transitions.  Kwin is the only
> > framework for screen-level transitions and animations that is well
> > developed enough to be used immediately in the near future, and
> > there's no need to reimplement screen transitions when Kwin has them
> > already there!
>
> Bingo.
>
> > 2.  Re-adopt the ZUI (whose name, being utterly meaningless to
> > Activities, should disappear soon except perhaps as API and developer
> > nomenclature) to use Kwin when present for switching between
> > Activities.  Be able to apply any desktop-switch-effect, perhaps, to
> > Plasma's ZUI transitions instead.  (Ex., switch between Activities
> > with the Cube and Wall).  This makes for more spatial conflicts, I
> > know.  Wait for it.
> >
> > 3.  The default method of Activity transition interaction should be
> >
> > --Switching immediately to a particular Activity (see Cashew-Menu idea
> > in A-2 above)
> >
> > And nothing else.  No

Re: KWin Dashboard effect

[Alexis Ménard]

Qt Animation can animate our Dashboard without pain...

2009/2/10 Martin Gräßlin 

> Hi plasma-devs,
>
> I had the idea to improve the appearance of the plasma dashboard by using a
> KWin effect for it. Currently I have some proof-of-concept code, but there
> are
> still some issues ;-)
>
> The effect changes the brightness and satuation of all windows on the same
> screen as the dashboard (causing some problems for multi-screen setups, but
> I
> have some ideas to solve them ;-) ). That's the same way as dim inactive or
> dim screen for administration mode works. So we can have a nice animation
> instead of "it's just there".
>
> I changed the background of dashboard to be transparent, but nevertheless
> there is some black background. I have no idea where that comes from :-(
>
> My idea for the effect does not only include the way the background is
> changed.
> I would like to have a smooth transition. I have not yet tried anything but
> I
> would like to paint the windows transparent and raise the dashboard from
> desktop to the top and when deactivating the other way around. I think that
> could be a nice animation. If someone has a better idea please provide it
> ;-)
>
> But here is the next problem: the white flash when opening the dashboard.
> As
> long as there is this white flash an animation does not make any sense. So
> we
> have to get rid of it. What about never closing the dashboard widget? It is
> created during startup and just put behind the desktop. We could also use
> the
> existing effect to always hide it. Or just have it on top of the desktop
> and
> have the plasmoids live in there. That way we could also benefit in other
> effects. We already had requests to hide the plasmoids in e.g. coverswitch.
>
> Ah and we can use the effect to block things like present windows and
> desktop
> grid. Alt+Tab is not that easy to block but it would be possible as well.
> We
> just have to try hard enough ;-)
>
> Attached you find the current patch for dashboard and kwin. The kwin code
> is
> also available in my git branch
> (http://github.com/mgraesslin/kwin/tree/dashboard). The dashboard code is
> really just proof-of-concept ;-) Please give it a try and provide some
> feedback.
>
> Regards
> Martin
>
>
>
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: tokamak 2, my phonenumber

[Alexis Ménard]

Me i'll take the plane LH4552 from Frankfurt to Porto, i'll arrive at 15:10
on thursday.

On Wed, Feb 4, 2009 at 12:56 AM, Frank Karlitschek wrote:

>
>
>
> On 04.02.2009, at 00:40, Chani wrote:
>
> > On February 3, 2009 14:35:20 Frank Karlitschek wrote:
> >> On 03.02.2009, at 20:29, 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 arrive at 11:10 am at Thursday. Flight 4550 from Frankfurt.
> >> Does someone else arrive around this time?
> >
> > eee! same flight! :)
> > hopefully you can find me in FRA :) I've got a 2 1/2 hour wait at
> > that airport.
> >
>
> cool.
>
> I´m sure we will find us. :-)
>
>
> Frank
>
>
>
>
>
> Frank Karlitschek
> karlitsc...@kde.org
>
>
>
> ___
> 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: QGraphicsLayout, was Re: playground/base/plasma/applets/networkmanager/applet

[Alexis Ménard]

On Wed, Jan 28, 2009 at 5:46 PM, Sebastian Kügler  wrote:

> On Tuesday 27 January 2009 23:37:07 Alexis Ménard wrote:
> > On Tue, Jan 27, 2009 at 8:26 PM, Sebastian Kügler  wrote:
> > > SVN commit 917381 by sebas:
> > >
> > > updateGeometry() works much better for layout size changes than
> > > invalidating the layout.
> >
> > invalidate just clear the cache of sizes internally, so of course after
> > that it will do nothing. Calling updateGeometry will compute all sizes
> > again according to the content and update the size. But with 4.5 it
> should
> > be less painfull to do that since a tons of bugs regarding that has been
> > fixed (updating the parent size if the layout change, update parents
> > layouts if one child grow/shrink,...). We can talk about that on tokamak,
> > hopefully 4.5 RC will be out and KDE trunk will be switch. Some of lines
> > can be removed i am confident.
>
> Ah, thanks for the explanation.
>
> I don't want to completely rely on Qt 4.5 though, since we'd like to
> release
> the networkmanager applet also for distros that rely on Qt 4.4. From what I
> can see though, I need to get the ExtenderItem to understand that its size
> has
> changed, and pass that information up to ExtenderApplet?


Yes, you can invalidate the ExtenderItem cache and then call updateGeometry
on it, and call manually a resize of the parent.
You can catch the layout request on the event method. That is fix in 4.5 you
shouldn't do that but we 4.4 it should work.


>
>
> > > This fixes one part of the sizing problems, the extenderitem's size is
> > > updated when you move the extender around. Next step would be to make
> > > the extenderapplet update its geometry after the extenderitem's size
> > > changes. Is there a signal I should use, or what is the best way to do
> > > this?
> --
> sebas
>
>  http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Problem with appletRemoved signal

[Alexis Ménard]

Ok will be done tomorrow as soon as i arrive at the office :D

2009/1/27 Aaron J. Seigo 

> On Monday 26 January 2009, Alexis Ménard wrote:
> > Aie aie aie. Valgrind complain and we never know, people can use the
> > pointer to do some stuff when they get the appletRemoved signal, (we
> > already do that in our panel.cpp class).
>
> erf; yes, that pointer is not supposed to be used *sigh*
>
> > > I guess if people agreed that i should backport it to 4.2 branch.
> >
> > Is it OK?
>
> sure ...
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> ___
> 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: 4.2 on Debian Experimental Refactoring Alert :-)

[Alexis Ménard]

And yes binary compatibility has been broken so you have to recompile
applets. We never warranty the binary compatibility before 4.2 since plasma
libs wasn't in kdelibs.

2009/1/27 Aaron J. Seigo 

> On Tuesday 27 January 2009, David Baron wrote:
> > More:
> >
> > The plasma icon widget is now IconWidget and not Icon. The header file in
> > /usr/include/plasma is iconwidget.h instead of icon.h. I already
> recompiled
> > one applet that used this :-)
>
> yes, 4.2 had some API refactoring.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> ___
> 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

Problem with appletRemoved signal

[Alexis Ménard]

Hello folks,


There is a problem with appletRemoved public signal in containment. Here is
the signature :

/**
 * This signal is emitted when an applet is destroyed
 */
 void appletRemoved(Plasma::Applet *applet);

So a containment that is connected to this signal expect an Applet pointer.
But who emit this signal? Our beloved base class Containment which is
connected to the QObject destroyed signal of the applet.

Here is the slot :
void ContainmentPrivate::appletDestroyed(QObject *object);

When we arrive in the this slot applet destructor has been already called.
Since we do a static_cast just because we need the value of the pointer,
it's ok. BUT after we call :

emit q->appletRemoved(applet); with the pointer we get after the
static_cast.

Aie aie aie. Valgrind complain and we never know, people can use the pointer
to do some stuff when they get the appletRemoved signal, (we already do that
in our panel.cpp class). Luckily it doesn't crash but it can happen.

I have attach a patch that create a appletDestroyed signal that is emit just
after entering in Applet destructor. I wanted to use destroyed but we have
already a method called like this.

I guess if people agreed that i should backport it to 4.2 branch.

Is it OK?

PS : Sorry for don't using the review board but it doesn't work with git, i
don't have the svn revision.
diff --git a/plasma/applet.cpp b/plasma/applet.cpp
index 0956fdf..b4116af 100644
--- a/plasma/applet.cpp
+++ b/plasma/applet.cpp
@@ -135,6 +135,9 @@ Applet::Applet(QObject *parentObject, const QVariantList &args)
 
 Applet::~Applet()
 {
+//let people know that i will die
+emit appletDestroyed(this);
+
 if (!d->transient && d->extender) {
 //This would probably be nicer if it was located in extender. But in it's dtor, this won't
 //work since when that get's called, the applet's config() isn't accessible anymore. (same
diff --git a/plasma/applet.h b/plasma/applet.h
index 5f4ad71..9d5324d 100644
--- a/plasma/applet.h
+++ b/plasma/applet.h
@@ -611,6 +611,11 @@ class PLASMA_EXPORT Applet : public QGraphicsWidget
  */
 void activate();
 
+/**
+ * Emitted when the applet is deleted
+ */
+void appletDestroyed(Plasma::Applet *applet);
+
 public Q_SLOTS:
 /**
  * Sets the immutability type for this applet (not immutable,
diff --git a/plasma/containment.cpp b/plasma/containment.cpp
index 9cc469b..73d5a7b 100644
--- a/plasma/containment.cpp
+++ b/plasma/containment.cpp
@@ -735,7 +735,7 @@ void Containment::addApplet(Applet *applet, const QPointF &pos, bool delayInit)
 
 connect(applet, SIGNAL(configNeedsSaving()), this, SIGNAL(configNeedsSaving()));
 connect(applet, SIGNAL(releaseVisualFocus()), this, SIGNAL(releaseVisualFocus()));
-connect(applet, SIGNAL(destroyed(QObject*)), this, SLOT(appletDestroyed(QObject*)));
+connect(applet, SIGNAL(appletDestroyed(Plasma::Applet*)), this, SLOT(appletDestroyed(Plasma::Applet*)));
 connect(applet, SIGNAL(activate()), this, SIGNAL(activate()));
 
 if (pos != QPointF(-1, -1)) {
@@ -1698,16 +1698,8 @@ bool ContainmentPrivate::regionIsEmpty(const QRectF ®ion, Applet *ignoredAppl
 return true;
 }
 
-void ContainmentPrivate::appletDestroyed(QObject *object)
+void ContainmentPrivate::appletDestroyed(Plasma::Applet *applet)
 {
-// we do a static_cast here since it really isn't an Applet by this
-// point anymore since we are in the qobject dtor. we don't actually
-// try and do anything with it, we just need the value of the pointer
-// so this unsafe looking code is actually just fine.
-//
-// NOTE: DO NOT USE THE applet VARIABLE FOR ANYTHING OTHER THAN COMPARING
-//   THE ADDRESS! ACTUALLY USING THE OBJECT WILL RESULT IN A CRASH!!!
-Applet *applet = static_cast(object);
 applets.removeAll(applet);
 if (focusedApplet == applet) {
 focusedApplet = 0;
diff --git a/plasma/containment.h b/plasma/containment.h
index 354ccb7..e234341 100644
--- a/plasma/containment.h
+++ b/plasma/containment.h
@@ -507,7 +507,7 @@ class PLASMA_EXPORT Containment : public Applet
 const QGraphicsItem *toolBoxItem() const;
 
 private:
-Q_PRIVATE_SLOT(d, void appletDestroyed(QObject*))
+Q_PRIVATE_SLOT(d, void appletDestroyed(Plasma::Applet*))
 Q_PRIVATE_SLOT(d, void containmentAppletAnimationComplete(QGraphicsItem *item,
   Plasma::Animator::Animation anim))
 Q_PRIVATE_SLOT(d, void triggerShowAddWidgets())
diff --git a/plasma/private/containment_p.h b/plasma/private/containment_p.h
index 6fe21b7..0a91b98 100644
--- a/plasma/private/containment_p.h
+++ b/plasma/private/containment_p.h
@@ -75,7 +75,7 @@ public:
 void positionContainments();
 void setLockToolText();
 void handleDisappeared(AppletHandle *handle);
-void appletDestroyed(QObject*);
+void appletDestroyed(Plasma::Applet*);
 voi

Re: Tokamak Meeting II

[Alexis Ménard]

Nuno, did you plan me for a talk?

Mine will be : "Qt Software, what's going on?"

Mainly i will talk about Animation API, States and transitions and a bit of
the declarative-ui.

On Sat, Jan 17, 2009 at 3:40 PM, Nuno Pinheiro wrote:

> A Saturday 17 January 2009 14:12:12, Rob Scheepmaker escreveu:
> > On Thursday 15 January 2009 17:47:30 Nuno Pinheiro wrote:
> > > hey everybody
> > >
> > > fristly confirmation for the people coming.
> >
> > I'll be there!
> >
> > > Secondly I asked several people already to prepare a litle presentation
> > > to give on the 6.  (can be about anything as long as its plasma
> related,
> > > i think a small presentatioon of your personal adgenda for the meeting
> is
> > > prety interesting).
> > >
> > > so if you coud send me a title to the presentation and expected time it
> > > will take you it will be great.
> >
> > I suppose I can give a talk about extenders. Since there will also be non
> > plasma people, I was wondering how technical I should get though. Should
> I
> > dive into how to use them in your applet, or just show what they are,
> what
> > they can do, and what features I've planned for the next release?
>
> I think we should focus mostly on the internal people aka us. but if we can
> give a litle introductury test about what we are talking about i think it
> will
> be nice
>
>
> > > thanks in advance
> > > Nuno Pinheiro
> >
> > and thank you for arranging this meeting. :)
>
> Thank you for coming.
>
> > Regards,
> > Rob
>
> btw major update to the http://techbase.kde.org/Projects/Plasma/Tokamak2page.
>
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
>
> --
> 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: signal clicked()

[Alexis Ménard]

Overload the mousePressEvent method...And take a look to the documentation
of Qt, QGraphicsWidget/QGraphicsItem since the Applet class inherits from
them. Everything is explain about event propagation.


2009/1/17 Toussis Manolis 

> I want my plasma to react on left click on it.
> What signal/object should I connect to my slot?
> I tried MyApplet::clicked() , but there is no such signal...
>
>
>
> ___
> 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

[Alexis Ménard]

I am here, i don't know yest when i arrive but the 5th for sure.

I have a talk that i want to give about some stuff coming from Qt Software.

As soon as i have the date i will let you know.

On Fri, Jan 16, 2009 at 3:03 PM, Anne-Marie Mahfouf <
annemarie.mahf...@free.fr> wrote:

> Hi Artur, hi all,
> >
> > Hey, I'm arriving at the same day/time! Maybe we are in the same flight
> > from Lisbon to Porto ? (TP1952)
> indeed, same flight! we can meet at the boarding area around 7h30 am, we'll
> be
> arriving at 7:00 at Lisbon from Toulouse.
>
> -
> Nuno: I can talk 5 minutes if you schedule us 3 after 10h30 - 11h.
>
> Planned 5 minutes talk: "Picture Frame applet: present and future"
>
> -
>
> My objectives for the week-end:
> * picture frame applet perspectives (PoTD engine, metadata and Nepomuk
> integration, flipping animation, sharing config with Desktop settings, ...)
> * what containment for educational purposes? (started by Aaron blog)
> the Desktop itself and the plasmoids.
> * KDE community plasma integration  (uploading of data from users which I
> am
> waiting for ages in particular!)
>
>
> Anne-Marie
>
> ___
> 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: FrameSvg corruption [a bit urgent]

[Alexis Ménard]

I noticed some artifacts too in my case on the task manager. I will try
lancelot.

The problem appears quite recently since the big move with the caching big
work. I guess it was my Nvidia driver that were crap(as usually) but not
sure now. On my laptop everything works fine so...

2009/1/15 Aaron J. Seigo 

> On Thursday 15 January 2009, Ivan Čukić wrote:
> > p.s. Why don't we call the /not found/ branch when the rectangle is not
> > valid?
> >
> > Something like:
> > if (found && elementRect.isValid()) {
> > return true;
> > } else {
> > d->findAndCacheElementRect(elementId);
> > return d->renderer->elementExists(elementId);
> > }
>
> because if it is found, then we don't want to re-look it up in the svg. no?
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> ___
> 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: Welcome to 4.3.

[Alexis Ménard]

2009/1/7 Aaron J. Seigo 

> On Tuesday 06 January 2009, Aaron J. Seigo wrote:
> > of course, there are more mundane things i'll also be plonking on, like:
>
> knew i'd forget at least one:
>
> * deprecating or changing how Animator works and seeing what we can do with
> Kinetic.
>

:D

Pretty sure we can do something :D, just matter of discussions and
feedbacks.


>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> ___
> 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: How to adjust applet size according to its child QGraphicsWidget?

[Alexis Ménard]

Unfortunately you can't it is a bug in Qt.

You can take a look to the task tracker of Qt Number 231114 and 211500. I
guess it is what you try to solve. The fix is in 4.4 branch (so scheduled
for 4.4.4) and in 4.5.

As a workaround you have to manage the resize of your applet by hand when
the size of the layout change.

2008/12/30 Dong Tiger 

> Hi,
>
> A QGraphicsWidget is embeded into Plasma::Applet through
> QGraphicsLinearLayout. When this QGraphicsWidget's size changes, how to get
> the applet's size adjusted accordingly?
>
> The code snippet looks like:
>
>   child = new MyGraphicsWidget(applet);
>   layout = new QGraphicsLinearLayout(applet);
>   layout->setSpacing(0);
>   layout->addItem(child);
>   applet->setLayout(layout);
>
>
> Regards,
> --
> Tiger
>
> ___
> 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: build error from today's SVN

[Alexis Ménard]

Just clean your build dir for this applet. Then mocs will be properly
generated again.

On Tue, Dec 23, 2008 at 11:10 AM, asraniel  wrote:

> I had that error but some time ago now.
> Deleting the build folder of kickoff solved the problem for me.
>
> Am Dienstag 23 Dezember 2008 11.04:57 schrieb Oszkar Ambrus:
> > Hi,
> >
> > After updating kdebase yesterday, I'm unable to build it successfully.
> > I get an error [1] for the Plasma SimpleLauncher. Any suggestions?
> >
> > Thanks,
> > Oszkar
> >
> > [1] The error listing:
> >
> > CMakeFiles/plasma_applet_simplelauncher.dir/ui/brandingbutton.o: In
> > function `Kickoff::BrandingButton::metaObject() const':
> >
> /home/kde-devel/kde/build/KDE/kdebase/workspace/plasma/applets/kickoff/bran
> >dingbutton.moc:47: multiple definition of
> > `Kickoff::BrandingButton::metaObject() const'
> >
> CMakeFiles/plasma_applet_simplelauncher.dir/plasma_applet_simplelauncher_au
>
> >tomoc.o:/home/kde-devel/kde/build/KDE/kdebase/workspace/plasma/applets/kicko
> >ff/moc_brandingbutton.cpp:42: first defined here
> >
> CMakeFiles/plasma_applet_simplelauncher.dir/ui/brandingbutton.o:(.data.rel.
> >ro+0x0): multiple definition of
> `Kickoff::BrandingButton::staticMetaObject'
> >
> CMakeFiles/plasma_applet_simplelauncher.dir/plasma_applet_simplelauncher_au
> >tomoc.o:(.data.rel.ro+0x0): first defined here
> > CMakeFiles/plasma_applet_simplelauncher.dir/ui/brandingbutton.o: In
> > function `Kickoff::BrandingButton::qt_metacast(char const*)':
> >
> /home/kde-devel/kde/build/KDE/kdebase/workspace/plasma/applets/kickoff/bran
> >dingbutton.moc:52: multiple definition of
> > `Kickoff::BrandingButton::qt_metacast(char const*)'
> >
> CMakeFiles/plasma_applet_simplelauncher.dir/plasma_applet_simplelauncher_au
>
> >tomoc.o:/home/kde-devel/kde/build/KDE/kdebase/workspace/plasma/applets/kicko
> >ff/moc_brandingbutton.cpp:47: first defined here
> > CMakeFiles/plasma_applet_simplelauncher.dir/ui/brandingbutton.o: In
> > function `Kickoff::BrandingButton::qt_metacall(QMetaObject::Call, int,
> > void**)':
> >
> /home/kde-devel/kde/build/KDE/kdebase/workspace/plasma/applets/kickoff/bran
> >dingbutton.moc:60: multiple definition of
> > `Kickoff::BrandingButton::qt_metacall(QMetaObject::Call, int, void**)'
> >
> CMakeFiles/plasma_applet_simplelauncher.dir/plasma_applet_simplelauncher_au
>
> >tomoc.o:/home/kde-devel/kde/build/KDE/kdebase/workspace/plasma/applets/kicko
> >ff/moc_brandingbutton.cpp:55: first defined here
> > collect2: ld returned 1 exit status
> > make[2]: *** [lib/plasma_applet_simplelauncher.so] Error 1
> > make[1]: ***
> >
> [workspace/plasma/applets/kickoff/CMakeFiles/plasma_applet_simplelauncher.d
> >ir/all] Error 2
> > make: *** [all] Error 2
> > makeobj[0]: Leaving directory `/home/kde-devel/kde/build/KDE/kdebase'
> > ___
> > 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
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak II is .. on!

[Alexis Ménard]

 This time, I will be present as Qt Software engineer.

I don't ask for sponsoring/help, the company will handle costs of my trip.

On Mon, Dec 15, 2008 at 7:54 PM, Kevin Ottens  wrote:

> On Monday 15 December 2008 18:56:19 Aaron J. Seigo wrote:
> > if you were not on the list last weekend, then please let me know what
> your
> > costs will be and i'll see if we have room in the budget. thanks =)
>
> Well, I added myself to the list today, so I'm hereby asking if you've some
> room for a SFFF? (as ade puts it) :-)
>
> Regards.
> --
> Kévin 'ervin' Ottens, http://ervin.ipsquad.net
> "Ni le maître sans disciple, Ni le disciple sans maître,
> Ne font reculer l'ignorance."
> ___
> 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: Themes revision for 4.2

[Alexis Ménard]

We can't remove it, but adding new yes for sure. Users will complain and i
think it is their right. The theme you choose are different for everyone so
more is better than less, and it cost nothing to keep the old one.

2008/12/5 Aaron J. Seigo <[EMAIL PROTECTED]>

> On Friday 05 December 2008, Ivan Čukić wrote:
> > Any thoughts?
>
>
> people using silicon suddenly lose their theme? hrm.
>
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
>
>
> KDE core developer sponsored by Qt Software
>
>
>
> ___
> 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: tasks widget hacking

[Alexis Ménard]

On Tue, Dec 2, 2008 at 12:02 PM, Christian Mollekopf
<[EMAIL PROTECTED]>wrote:

> Am 02.12.2008, 11:43 Uhr, schrieb Marco Martin <[EMAIL PROTECTED]>:
>
> > On Tuesday 02 December 2008, Alexis Ménard wrote:
> >> And the layout is recreated again and again, i am sure we can find a
> >> solution for that.
> >
> > time ago i tried to remove that thing, it resulted in empty holes still
> > sized
> > as there were items in it, so then tried with a simple qt program and the
> > problem wasn't there, so it must be a problem somewhere in
> > layoutwidget.cpp,
> > but it's pretty complex, really wasn't able to track it down
>
> Since i did most of this stuff i should attend the meeting as well =)
> Good for me is between 20.00- 24.00 GMT+1, today for instance would be
> good.
>
> The layout recreation is a workaround since the QGraphicsGridLayout
> doesn't remove the items properly.
> I think Aaron and Marco agreed on this workaround an we will have to keep
> it that way until it's fixed in QT.
>

If the problem is in Qt then i will fix it, it's my job. And removing items
should work and must work...
I have already used QGraphicsGridLayout and it should work as far as i know
and the last time i used it.
Anyway if the bug exist why don't you write to the support of Qt Software
about that?
I have actually screen all QGraphicsLayout tasks and there are no such of
things. So the bug will never be fixed if it exist.

Anyway i will take a look at it...



>
> Regards,
>
> Christian
>
> >
> >> 2008/12/2 Aaron J. Seigo <[EMAIL PROTECTED]>
> >>
> >> > hi...
> >> >
> >> > i'd like to have a tasks widget hacking day.
> >> >
> >> > the reason for this i that the code is something of a mess internally
> >> and
> >> > imho
> >> > it's unmaintainable in its current state. i say this because changing
> >> > little
> >> > things in one place often create rather unexpected results; there's a
> >> > good amount of unreachable code; there's what looks to be some pretty
> >> > obvious memory leaks (e.g. Tasks::m_groupTaskItems never seems to have
> >> > items removed
> >> > from it!); Tasks does bookkeeping, but for only some things, and this
> >> > bookkeeping is controlled from Tasks, LayoutWidget *and*
> >> TaskGroupItem!
> >> >
> >> > there are bugs that sometimes results in "holes" showing up in the
> >> > layout, grouping not working reliably on start up and more.
> >> >
> >> > if we ship with it like this, we will hate ourselves later.
> >> >
> >> > unfortunately, i'm not particularly sure what all the reasons and
> >> > rationals are for some of the code decisions.
> >> >
> >> > so if you have been working on the tasks widget in the last month or
> >> two,
> >> > please respond in this thread with when would be a good time and day
> >> for
> >> > you
> >> > so we can get together on irc and sort this thing out. =)
> >> >
> >> > --
> >> > Aaron J. Seigo
> >> > humru othro a kohnu se
> >> > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
> >> >
> >> > KDE core developer sponsored by Qt Software
> >> >
> >> >
> >> > ___
> >> > 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
>
>
>
> --
> Erstellt mit Operas revolutionärem E-Mail-Modul:
> http://www.opera.com/mail/
> ___
> 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: tasks widget hacking

[Alexis Ménard]

And the layout is recreated again and again, i am sure we can find a
solution for that.

2008/12/2 Aaron J. Seigo <[EMAIL PROTECTED]>

> hi...
>
> i'd like to have a tasks widget hacking day.
>
> the reason for this i that the code is something of a mess internally and
> imho
> it's unmaintainable in its current state. i say this because changing
> little
> things in one place often create rather unexpected results; there's a good
> amount of unreachable code; there's what looks to be some pretty obvious
> memory leaks (e.g. Tasks::m_groupTaskItems never seems to have items
> removed
> from it!); Tasks does bookkeeping, but for only some things, and this
> bookkeeping is controlled from Tasks, LayoutWidget *and* TaskGroupItem!
>
> there are bugs that sometimes results in "holes" showing up in the layout,
> grouping not working reliably on start up and more.
>
> if we ship with it like this, we will hate ourselves later.
>
> unfortunately, i'm not particularly sure what all the reasons and rationals
> are for some of the code decisions.
>
> so if you have been working on the tasks widget in the last month or two,
> please respond in this thread with when would be a good time and day for
> you
> so we can get together on irc and sort this thing out. =)
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> ___
> 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: Patch to mousePressEvent in Plasma lib.

[Alexis Ménard]

stop drug alexis
stop drug alexis

forget the last mail.

On Wed, Nov 26, 2008 at 4:54 PM, Alexis Ménard <[EMAIL PROTECTED]> wrote:

> Ok so i keep the reimplentation and i remove the setFocus only, and i call
> the base class.
>
> 2008/11/26 Aaron J. Seigo <[EMAIL PROTECTED]>
>
>> On Wednesday 26 November 2008, Alexis Ménard wrote:
>> > Hello,
>> >
>> > Here is a patch that remove the focus stuff in the mousePressEvent of
>> > Applet class and remove the overload. Why? Because Qt have a focus
>> policy
>> > that manage that for you. It break the binary compatibilty but it not
>> too
>> > late no? :D.
>> > I think it will avoid some future problems regarding focus.
>> >
>> > Review please?
>>
>> you can do this without breaking BC, obviously. i'd like us to get in the
>> habit of doing so and in this case it keeps the door open for adding
>> something
>> to that method if needed later on.
>>
>> --
>> Aaron J. Seigo
>> humru othro a kohnu se
>> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>>
>> KDE core developer sponsored by Qt Software
>>
>>
>> ___
>> 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: Patch to mousePressEvent in Plasma lib.

[Alexis Ménard]

Ok so i keep the reimplentation and i remove the setFocus only, and i call
the base class.

2008/11/26 Aaron J. Seigo <[EMAIL PROTECTED]>

> On Wednesday 26 November 2008, Alexis Ménard wrote:
> > Hello,
> >
> > Here is a patch that remove the focus stuff in the mousePressEvent of
> > Applet class and remove the overload. Why? Because Qt have a focus policy
> > that manage that for you. It break the binary compatibilty but it not too
> > late no? :D.
> > I think it will avoid some future problems regarding focus.
> >
> > Review please?
>
> you can do this without breaking BC, obviously. i'd like us to get in the
> habit of doing so and in this case it keeps the door open for adding
> something
> to that method if needed later on.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> ___
> 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

Patch to mousePressEvent in Plasma lib.

[Alexis Ménard]

Hello,

Here is a patch that remove the focus stuff in the mousePressEvent of Applet
class and remove the overload. Why? Because Qt have a focus policy that
manage that for you. It break the binary compatibilty but it not too late
no? :D.
I think it will avoid some future problems regarding focus.

Review please?
Index: applet.cpp 
===
--- applet.cpp  (revision 00)  
+++ applet.cpp  (working copy) 
@@ -1301,12 +1301,6 @@ 
 } 
 } 
   
-void Applet::mousePressEvent(QGraphicsSceneMouseEvent *event) 
-{ 
-setFocus(Qt::MouseFocusReason);   
-QGraphicsWidget::mousePressEvent(event);  
-} 
-  
 void Applet::focusInEvent(QFocusEvent *event) 
 { 
 if (!isContainment() && containment()) {  
@@ -1842,6 +1836,7 @@  
 q->setCacheMode(Applet::DeviceCoordinateCache);   
 q->setAcceptsHoverEvents(true);   
 q->setFlag(QGraphicsItem::ItemIsFocusable, true); 
+q->setFocusPolicy(Qt::ClickFocus);
 // FIXME: adding here because nothing seems to be doing it in QGraphicsView,
 // but it doesn't actually work anyways =/
 q->setLayoutDirection(qApp->layoutDirection());
Index: applet.h
===
--- applet.h(revision 00)
+++ applet.h(working copy)
@@ -781,11 +781,6 @@
 void mouseMoveEvent(QGraphicsSceneMouseEvent *event);
 
 /**
- * @internal manage the mouse movement to drag the applet around
- */
-void mousePressEvent(QGraphicsSceneMouseEvent *event);
-
-/**
  * Reimplemented from QGraphicsItem
  */
 void focusInEvent(QFocusEvent *event);

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

qt-copy/patches

[Alexis Ménard]

SVN commit 883128 by menard:

Fix the focus bug found in plasma, this patch is scheduled for 4.4.4 and in 4.5.

CCMAIL:plasma-devel@kde.org



 A 0260-fix-qgraphicswidget-deletionclearFocus.diff  


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

Re: Next Tokamak

[Alexis Ménard]

i know that use case. I already tried. I see where it crash but i don't
understand why...By test case i mean something that run outside plasma,
simple program. As you noticed (you or someone else) it doesn't happen on
everydody computers everytime.

On Fri, Nov 7, 2008 at 2:44 AM, Shawn Starr <[EMAIL PROTECTED]> wrote:

> On Thursday 06 November 2008 20:35:30 Alexis Ménard wrote:
> > I know that bug, everybody talk to me about that. But the thing is : i
> will
> > be *very* interessted by a test case. Actually i tried to reproduce it
> and
> > i can't. And i don't want to patch Qt blindly without understanding why
> it
> > happen. And i would like to point the fact that we had never ever have a
> > customer that report about that (as far as i know) so it seems to happen
> > only on Plasma. But guys without a test case it is difficult to help
> you...
> >
> If you install my weather applet, drag it onto the desktop, pick a place
> then
> click OK, it will crash when the mouse focuses over the plasmoid.
>
> Shawn.
>
> ___
> 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: Next Tokamak

[Alexis Ménard]

I know that bug, everybody talk to me about that. But the thing is : i will
be *very* interessted by a test case. Actually i tried to reproduce it and i
can't. And i don't want to patch Qt blindly without understanding why it
happen. And i would like to point the fact that we had never ever have a
customer that report about that (as far as i know) so it seems to happen
only on Plasma. But guys without a test case it is difficult to help you...

On Thu, Nov 6, 2008 at 8:33 PM, Shawn Starr <[EMAIL PROTECTED]> wrote:

>
>
> ------
> *From:* Alexis Ménard <[EMAIL PROTECTED]>
> *To:* plasma-devel@kde.org
> *Sent:* Thursday, November 6, 2008 12:36:40 PM
> *Subject:* Re: Next Tokamak
>
>
>
> 2008/11/6 Aaron J. Seigo <[EMAIL PROTECTED]>
>
>> On Thursday 06 November 2008, Alexis Ménard wrote:
>> > Why? Plasma in KDE 4.3 with kinetic.
>>
>> and just as important, perhaps even more so in some ways, as getting
>> plasma
>> working with kinetic is to work on unsuckifying QGraphicsLayout.
>>
>> just ran into another issue here where deleting an item doesn't result in
>> its
>> removal from a layout leading to a crash. i was surprised that that's the
>> case. there are so many anomolies with QGL right now and nothing has been
>> fixed
>> in qt 4.5
>
>
> >Nothing? I am not sure. We have fixed some. Two bigs need our love, we are
> on it. But >that is an another discussion :D.
>
> Have you looked at the Qt focus bug? It's occurring in Qt 4.4.3 (qt-copy).
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Next Tokamak

[Alexis Ménard]

2008/11/6 Aaron J. Seigo <[EMAIL PROTECTED]>

> On Thursday 06 November 2008, Alexis Ménard wrote:
> > Why? Plasma in KDE 4.3 with kinetic.
>
> and just as important, perhaps even more so in some ways, as getting plasma
> working with kinetic is to work on unsuckifying QGraphicsLayout.
>
> just ran into another issue here where deleting an item doesn't result in
> its
> removal from a layout leading to a crash. i was surprised that that's the
> case. there are so many anomolies with QGL right now and nothing has been
> fixed
> in qt 4.5


Nothing? I am not sure. We have fixed some. Two bigs need our love, we are
on it. But that is an another discussion :D.


>
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> ___
> 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