Hello all,
I have an issue with the System Notifier Daemon in kded4 blocking
right click action in systray for klipper and kmix. I have updated to the
latest git pull of dbusmenu-qt (0.5.2 I Believe) and am wondering if anyone
else has any suggestions. I am running Qt 4.7 Beta 2 and a se
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
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::index
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
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 a
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.
hi Alexis ...
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.
but there are two problems with QGraphicsWidget::geometryChanged:
0) it is
called before resizeEvent
On Tue, 2010-08-10 at 12:26 -0700, Aaron J. Seigo wrote:
> On August 10, 2010, Ted Gould wrote:
> > I think that's were we're coming at this from different positions, we
> > don't have another API for it.
>
> ah, i see. that is indeed problematic. so i'm guessing this is for Unity or
> some other
On Tuesday 10 August 2010, Aaron J. Seigo wrote:
> it would mean that there would be no need to expand the spec itself while
> allowing us to all experiment a bit more freely with it. all without
> endangering the future quality of the API and burden existing
> visualizations.
>
> and if i am pr
On August 10, 2010, Ted Gould wrote:
> I think that's were we're coming at this from different positions, we
> don't have another API for it.
ah, i see. that is indeed problematic. so i'm guessing this is for Unity or
some other not-gnome-panel-based work, meaning you have no pre-existing
applet
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4947/#review6981
---
Ship it!
some small comments below, but i think this can go in.
/tr
(I just snipped everything else, because I agree this is the heart of
the matter)
On Tue, 2010-08-10 at 11:21 -0700, Aaron J. Seigo wrote:
> On August 10, 2010, Ted Gould wrote:
> > And to overlay text is also non-ideal because making
> > the text readable
> requires basically having no icon at a
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4947/
---
(Updated 2010-08-10 18:45:50.123800)
Review request for Plasma.
Changes
--
On August 10, 2010, Ivan Čukić wrote:
> The only advantage of this proposal (as far as I'm concerned) is that
> we could choose how to handle this text providing more consistency,
> while currently we can't since it is embedded into the icon. Example -
> battery shows the text on hover, kmail and a
On August 10, 2010, Ted Gould wrote:
> On Tue, 2010-08-10 at 09:40 -0700, Aaron J. Seigo wrote:
> > i really think this is one of those places where we should draw a line
in
> > the sand and say "beyond this point, text doesn't happen, sorry."
getting
> > rid of textual data in the primary displa
On Tue, 2010-08-10 at 09:40 -0700, Aaron J. Seigo wrote:
> i really think this is one of those places where we should draw a line in
> the sand and say "beyond this point, text doesn't happen, sorry." getting
> rid of textual data in the primary display of these items is a good thing,
> not a bad t
On Tue, Aug 10, 2010 at 11:12 AM, Ivan Čukić wrote:
> > i already cringe on the keyboard layout indicator appearance applet
> because it
> > is text (and i wouldn't know how to make it different here)
>
> Well, in my case, the keybd indicator without the text is rather
> useless - the same flag f
> i already cringe on the keyboard layout indicator appearance applet because it
> is text (and i wouldn't know how to make it different here)
Well, in my case, the keybd indicator without the text is rather
useless - the same flag for two different layouts (Latin and
Cyrillic).
On the other hand
On Tuesday 10 August 2010, Aurélien Gâteau wrote:
> I would say we have much more control now with the SNI protocol. We can
> limit things to sane values. For example the host could decide on a
> maximum width and simply fade out the text if it's too wide. A useful
> recommendation in this sense w
On Tuesday 10 August 2010 18:05:30 Aurélien Gâteau wrote:
> I would say we have much more control now with the SNI protocol. We can
> limit things to sane values. For example the host could decide on a
> maximum width and simply fade out the text if it's too wide.
Please don't do that. It get's com
On August 10, 2010, Aurélien Gâteau wrote:
> > i think it's only really useful if there is a reliable way to show the
> > text. placing it next to the iconic representation is probably the only
> > way to do this reliably given that icons can be very small and it's
> > nearly impossible to tell whe
> On 2010-08-09 17:48:58, Aaron Seigo wrote:
> > another thought that occurs to me: i wonder if the "translate a package
> > name to an absolute path" doesn't belong in the Desktop Scripting .. that
> > way all wallpapers would get the benefit of it and it would be a penalty
> > paid just once
On 10/08/2010 16:46, Aaron J. Seigo wrote:
> On August 10, 2010, Aurélien Gâteau wrote:
>> I think this would give more flexibility and I can see a use for this
>> new property in a few KDE applications, KMail and Choqok for example
>> could use it to show the message count, the keyboard layout ind
On August 10, 2010, Aurélien Gâteau wrote:
> I think this would give more flexibility and I can see a use for this
> new property in a few KDE applications, KMail and Choqok for example
> could use it to show the message count, the keyboard layout indicator
> could use it as well.
>
> What do you
> On 2010-08-09 17:48:58, Aaron Seigo wrote:
> > another thought that occurs to me: i wonder if the "translate a package
> > name to an absolute path" doesn't belong in the Desktop Scripting .. that
> > way all wallpapers would get the benefit of it and it would be a penalty
> > paid just once
Hi,
As part of our use of the StatusNotifierItem (SNI) protocol in Ubuntu
GNOME, we are in need of a way to associate a label to a SNI. This would
be used for example for the keyboard layout SNI (I remember a similar
discussion around the KDE SNI on kde-core-devel) and for the battery SNI.
This i
> On 2010-08-09 17:48:58, Aaron Seigo wrote:
> > another thought that occurs to me: i wonder if the "translate a package
> > name to an absolute path" doesn't belong in the Desktop Scripting .. that
> > way all wallpapers would get the benefit of it and it would be a penalty
> > paid just once
26 matches
Mail list logo
