Nabble - kde-core-devel

Re: Review Request: Mouse wheel interaction with breadcrumb-style address bar

2009-12-06T08:03:46Z

> On 2009-12-06 13:29:11, Peter Penz wrote:
> > Thanks Todd for the patch. I think the "iterate through directories"-feature with the mouse-wheel is very useful. I'm unsure regarding the "go-up" feature. I'd consider this as contra productive: assuming your mouse is focused above the viewport and you scroll left/right; a minor moving of the mouse upwards to the URL navigator will result in (most probably unintended) going up some directories... So IMO this part of the feature should be skipped.
> >
> > I'm not 100 % happy that currently there is quite a lot of code needed for this kind of feature (but this is not your fault). The code overlaps a lot with the "show the subdirectories as list" feature. For KDE 4.5 I've planned to do some cleanups in the KUrlNavigator & Co (the current code is still quite 1:1 to an early KDE 4.0 version that has been ported from early days of Dolphin code). One minor detail is that KUrlNavigatorButton won't have any dependency anymore to KUrlNavigator (this cyclic dependency is not nice and makes it unclear which class is responsible for what task).
> >
> > So I'd suggest that we "park" this feature until I did some internal refactoring for the KUrlNavigator classes. I'd be open to port your patch then to the refactored code. Would this be OK for you?

For the go up, it seems pretty useful to me (much easier than an "up" button), but I could change it so you have to be over a folder to do it rather than anywhere on the address bar.

It is fine for me to wait, but I should point out this is only one of several features I was planning on implementing for the breadcrumb bar. I was also planning on implementing middle click to open as tabs, changing which 100 folders are shown if there are too many directories, and optional recursive navigation. Should I go ahead and implement these so you can take them into account when doing the refactoring, or should I wait until the refactoring is done?

- Todd

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

On 2009-12-06 08:11:18, Todd wrote:

>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2330/
> -----------------------------------------------------------
>
> (Updated 2009-12-06 08:11:18)
>
>
> Review request for Dolphin and kdelibs.
>
>
> Summary
> -------
>
> This patch allows mouse wheel interaction with the breadcrumb (not editable) address bar used in programs like Dolphin. Currently this version of the address bar does not have any mouse wheel interaction, so this patch does not interfere with existing functionality.
>
> There are two different interactions supported:
>
> First, when the vertical mouse wheel (any normal mouse wheel) is used on one of the folders, it moves through the folders in the same level in alphabetical order. So say you have a folder in your Home directory named "test", with 5 sub-folders, folder1, folder2, folder3, folder4, and folder5. You are currently in folder3. If you put your mouse over the folder3 entry in the address bar and rotate your mouse wheel down by one notch, you will switch to folder4. If you rotate your mouse wheel up by one notch, you will move to folder2. Move down and up by 2 (or more, in this case) notches moves you to folder5 and folder1, respectively. While in any of these folders, using your mouse wheel on the "test" folder entry will cycle through the other subfolders in your Home directory (since those folders are at the same level as test). When you reach the first or last folder in the directory further mouse wheel activity in that direction does nothing.
>
> The second functionality is provided when doing a horizontal scroll (generally alt+wheel) anywhere on the breadcrumb-style address bar. In this case, rotating the wheel by one notch in either direction moves you up one directory. In other words, holding alt and rotating the mouse wheel by one notch is equivalent to hitting the "Up" toolbar button once.
>
> This patch does not change the mouse wheel behavior of the traditional text-based (editable) address bar.
>
> I know this won't make it in before 4.5.
>
>
> Diffs
> -----
>
> /trunk/KDE/kdelibs/kfile/kurlnavigator.h 1058639
> /trunk/KDE/kdelibs/kfile/kurlnavigator.cpp 1058639
> /trunk/KDE/kdelibs/kfile/kurlnavigatorbutton.cpp 1058639
> /trunk/KDE/kdelibs/kfile/kurlnavigatorbutton_p.h 1058639
>
> Diff: http://reviewboard.kde.org/r/2330/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Todd
>
>

Re: Catching resume from suspend?

2009-12-06T07:06:40Z

David Jarvie skrev:

> On Saturday 05 Dec 2009 20:03:39 Anders Lund wrote:
> > Chani skrev:
> > > > > now, I get the feeling that since it doesn't Just Work yet, Solid
> > > > > doesn't provide us with any such signal. this feels like the sort
> > > > > of thing that solid *should* provide, but I don't know enough about
> > > > > the low-level details to say how it should be implemented.
> > > >
> > > > This has recently been discussed on hardware-devel
> > > > http://lists.kde.org/?t=125874601600001&r=1&w=2
> > >
> > > thanks.
> > > hmm, not looking very positive right now. silly HAL. but there's got to
> > > be a way, right? :)
> >
> > Appearently, an option is to put a script in /usr/lib/pm-util that sends
> > a dbus message. That message could be caught by, say, a plasma
> > dataengine. I don't know how portable it is, but for example
> > NetworkManager is using that on my system, along with several other
> > applications.
>
> This is something that would be really useful as a generally available
> signal in KDE. I already had to make KAlarm check every minute in case of
> a resume, instead of just sleeping until a signal arrived or an alarm was
> due.
>

I will attempt to use this, for a plasma dataengine. But I guess the correct
address would be the powerdevil kded module, which could broadcast it for
general use?

--
Venlig hilsen,
Anders

Re: Review Request: some krazy (and cppcheck) cleanups

2009-12-06T06:34:57Z

On Saturday 05 December 2009 23:53:55 Andrew Coles wrote:

> Whilst you're changing loops based on iterators, it's better to cache the
> value of foo.end() in a const variable before the start of the loop:
>
> {
> std::list<int>::iterator itr = numbers.begin();
> const std::list<int>::iterator itrEnd = numbers.end();
>
> for (; itr != itrEnd; ++itr) {
> ...
> }
> }
>
> (Note the extra braces - that way the scope of the iterator variables is
> still limited to just the for loop.)
>

You can cut down a lot on braces and stuff by doing this instead:

for (std::list<int>::iterator itr=number.begin(), itrEnd=numbers.end();
itr!=itrEnd;++itr) {
...
}

Note the comma. Just a trick I learned a lot time ago.

Also note that in the "trivial" cases, BOOST_FOREACH makes it somewhat more
elegant.

Qt's foreach unfortunately, insists on copying the container (I think),
making it next-to-unusable except for the implicitly-shared containers, and
breaking a lot of other useful stuff.

--
Kind regards, Esben

Re: Review Request: Mouse wheel interaction with breadcrumb-style address bar

2009-12-06T05:29:00Z

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

Thanks Todd for the patch. I think the "iterate through directories"-feature with the mouse-wheel is very useful. I'm unsure regarding the "go-up" feature. I'd consider this as contra productive: assuming your mouse is focused above the viewport and you scroll left/right; a minor moving of the mouse upwards to the URL navigator will result in (most probably unintended) going up some directories... So IMO this part of the feature should be skipped.

I'm not 100 % happy that currently there is quite a lot of code needed for this kind of feature (but this is not your fault). The code overlaps a lot with the "show the subdirectories as list" feature. For KDE 4.5 I've planned to do some cleanups in the KUrlNavigator & Co (the current code is still quite 1:1 to an early KDE 4.0 version that has been ported from early days of Dolphin code). One minor detail is that KUrlNavigatorButton won't have any dependency anymore to KUrlNavigator (this cyclic dependency is not nice and makes it unclear which class is responsible for what task).

So I'd suggest that we "park" this feature until I did some internal refactoring for the KUrlNavigator classes. I'd be open to port your patch then to the refactored code. Would this be OK for you?

- Peter

On 2009-12-06 08:11:18, Todd wrote:

Re: Catching resume from suspend?

2009-12-06T04:46:55Z

On Saturday 05 Dec 2009 20:03:39 Anders Lund wrote:

> Chani skrev:
> > > > now, I get the feeling that since it doesn't Just Work yet, Solid
> > > > doesn't provide us with any such signal. this feels like the sort of
> > > > thing that solid *should* provide, but I don't know enough about the
> > > > low-level details to say how it should be implemented.
> > >
> > > This has recently been discussed on hardware-devel
> > > http://lists.kde.org/?t=125874601600001&r=1&w=2
> >
> > thanks.
> > hmm, not looking very positive right now. silly HAL. but there's got to be
> > a way, right? :)
> >
>
> Appearently, an option is to put a script in /usr/lib/pm-util that sends a
> dbus message. That message could be caught by, say, a plasma dataengine. I
> don't know how portable it is, but for example NetworkManager is using that on
> my system, along with several other applications.

This is something that would be really useful as a generally available signal in KDE. I already had to make KAlarm check every minute in case of a resume, instead of just sleeping until a signal arrived or an alarm was due.

--
David Jarvie.
KDE developer.
KAlarm author: http://www.astrojar.org.uk/kalarm

Re: Review Request: some krazy (and cppcheck) cleanups

2009-12-06T03:52:09Z

On Sunday 06 December 2009 11:37:50 Ingo Klöcker wrote:

> On Sunday 06 December 2009, Milian Wolff wrote:
> > On Saturday 05 December 2009 23:53:55 Andrew Coles wrote:
> > > Whilst you're changing loops based on iterators, it's better to
> > > cache the value of foo.end() in a const variable before the start
> > > of the loop:
> > >
> > > {
> > > std::list<int>::iterator itr = numbers.begin();
> > > const std::list<int>::iterator itrEnd = numbers.end();
> > >
> > > for (; itr != itrEnd; ++itr) {
> > > ...
> > > }
> > > }
> >
> > Is this really true? I always thought such optimization is not
> > required in compiled languages like Cpp because the compiler does it
> > for you (esp. for const iterators). If not, I might have to optimize
> > some loops I wrote or at least will write future loops like that.
>
> There's no guarantee that the compiler does it for you, so you should
> always do it. It's even better to use Qt's foreach, boost's foreach or
> std::for_each whenever possible because all of them do the right thing
> so that you don't have to think about it.

Uhm, in this case it should probably be worth it add a krazy check for
iterators, since there are some times where I can't help out using them
(iterating maps/hashes).

/me has to optimize a lot of loops with braces as well

>
>
> Regards,
> Ingo
>

--
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B

signature.asc (205 bytes) Download Attachment

Re: Review Request: some krazy (and cppcheck) cleanups

2009-12-06T02:37:50Z

On Sunday 06 December 2009, Milian Wolff wrote:

> On Saturday 05 December 2009 23:53:55 Andrew Coles wrote:
> > Whilst you're changing loops based on iterators, it's better to
> > cache the value of foo.end() in a const variable before the start
> > of the loop:
> >
> > {
> > std::list<int>::iterator itr = numbers.begin();
> > const std::list<int>::iterator itrEnd = numbers.end();
> >
> > for (; itr != itrEnd; ++itr) {
> > ...
> > }
> > }
>
> Is this really true? I always thought such optimization is not
> required in compiled languages like Cpp because the compiler does it
> for you (esp. for const iterators). If not, I might have to optimize
> some loops I wrote or at least will write future loops like that.

There's no guarantee that the compiler does it for you, so you should
always do it. It's even better to use Qt's foreach, boost's foreach or
std::for_each whenever possible because all of them do the right thing
so that you don't have to think about it.

Regards,
Ingo

signature.asc (204 bytes) Download Attachment

Review Request: Mouse wheel interaction with breadcrumb-style address bar

2009-12-06T00:11:19Z

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

Review request for Dolphin and kdelibs.

Summary
-------

This patch allows mouse wheel interaction with the breadcrumb (not editable) address bar used in programs like Dolphin. Currently this version of the address bar does not have any mouse wheel interaction, so this patch does not interfere with existing functionality.

There are two different interactions supported:

First, when the vertical mouse wheel (any normal mouse wheel) is used on one of the folders, it moves through the folders in the same level in alphabetical order. So say you have a folder in your Home directory named "test", with 5 sub-folders, folder1, folder2, folder3, folder4, and folder5. You are currently in folder3. If you put your mouse over the folder3 entry in the address bar and rotate your mouse wheel down by one notch, you will switch to folder4. If you rotate your mouse wheel up by one notch, you will move to folder2. Move down and up by 2 (or more, in this case) notches moves you to folder5 and folder1, respectively. While in any of these folders, using your mouse wheel on the "test" folder entry will cycle through the other subfolders in your Home directory (since those folders are at the same level as test). When you reach the first or last folder in the directory further mouse wheel activity in that direction does nothing.

The second functionality is provided when doing a horizontal scroll (generally alt+wheel) anywhere on the breadcrumb-style address bar. In this case, rotating the wheel by one notch in either direction moves you up one directory. In other words, holding alt and rotating the mouse wheel by one notch is equivalent to hitting the "Up" toolbar button once.

This patch does not change the mouse wheel behavior of the traditional text-based (editable) address bar.

I know this won't make it in before 4.5.

Diffs
-----

/trunk/KDE/kdelibs/kfile/kurlnavigator.h 1058639
/trunk/KDE/kdelibs/kfile/kurlnavigator.cpp 1058639
/trunk/KDE/kdelibs/kfile/kurlnavigatorbutton.cpp 1058639
/trunk/KDE/kdelibs/kfile/kurlnavigatorbutton_p.h 1058639

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

Testing
-------

Thanks,

Todd

Re: Freeze exemption for PA integration into Phonon

2009-12-06T00:07:08Z

Em Sábado 5. Dezembro 2009, às 21.06.00, Colin Guthrie escreveu:

> 'Twas brillig, and Kevin Krammer at 05/12/09 16:20 did gyre and gimble:
> > Phonon can't be treated like one of the other system libraries since it
> > depends on Qt itself, i.e. it can't be installed prior to building Qt.
> >
> > So it is more a matter of either not needing the symbols during build or
> > not install the interface libraries (doesn't have to build backends in
> > any case).
>
> Several packages need bootstrapping (e.g. how to compile gcc if you've
> not got gcc :p).
>
> It's not too much of a problem to:
> 1. Compile Qt sans-phonon
> 2. Compile Phonon
> 3. Recompile Qt + Phonon

1. Compile Qt the supported way (i.e., everything, no modifications)
2. Compile Phonon and overwrite the one in Qt

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

signature.asc (197 bytes) Download Attachment

Re: Review Request: some krazy (and cppcheck) cleanups

2009-12-05T17:46:37Z

On Saturday 05 December 2009 23:53:55 Andrew Coles wrote:

Is this really true? I always thought such optimization is not required in
compiled languages like Cpp because the compiler does it for you (esp. for
const iterators). If not, I might have to optimize some loops I wrote or at
least will write future loops like that.

--
Milian Wolff
mail@...
http://milianw.de

signature.asc (205 bytes) Download Attachment

Re: Review Request: some krazy (and cppcheck) cleanups

2009-12-05T16:05:54Z

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

(Updated 2009-12-06 00:05:54.595468)

Review request for kdelibs.

Changes
-------

Also caching the end element of the loops.

Summary
-------

c++ style casts
++c increments
variable initializations
variable scope
(The red spaces are already removed from my local copy).

Diffs (updated)
-----

/trunk/kdesupport/strigi/src/streamanalyzer/fieldpropertiesdb.cpp 1059175
/trunk/kdesupport/strigi/src/streams/zipinputstream.cpp 1059175
/trunk/kdesupport/strigi/src/strigicmd/strigicmd.cpp 1059175
/trunk/kdesupport/strigi/src/xmlindexer/rdfindexer.cpp 1059175
/trunk/kdesupport/strigi/src/xsd/example.cpp 1059175
/trunk/kdesupport/strigi/src/xsd/metadataproperties.cpp 1059175
/trunk/kdesupport/strigi/src/xsd/strigidaemonconfiguration.cpp 1059175

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

Testing
-------

Thanks,

Jaime

Re: Review Request: some krazy (and cppcheck) cleanups

2009-12-05T14:53:55Z

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

Whilst you're changing loops based on iterators, it's better to cache the value of foo.end() in a const variable before the start of the loop:

{
std::list<int>::iterator itr = numbers.begin();
const std::list<int>::iterator itrEnd = numbers.end();

for (; itr != itrEnd; ++itr) {
...
}
}

(Note the extra braces - that way the scope of the iterator variables is still limited to just the for loop.)

- Andrew

On 2009-12-04 22:43:19, Jaime Torres wrote:

>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2321/
> -----------------------------------------------------------
>
> (Updated 2009-12-04 22:43:19)
>
>
> Review request for kdelibs.
>
>
> Summary
> -------
>
> c++ style casts
> ++c increments
> variable initializations
> variable scope
> (The red spaces are already removed from my local copy).
>
>
> Diffs
> -----
>
> /trunk/kdesupport/strigi/src/streamanalyzer/fieldpropertiesdb.cpp 1058674
> /trunk/kdesupport/strigi/src/streams/zipinputstream.cpp 1058674
> /trunk/kdesupport/strigi/src/strigicmd/strigicmd.cpp 1058674
> /trunk/kdesupport/strigi/src/xmlindexer/rdfindexer.cpp 1058674
> /trunk/kdesupport/strigi/src/xsd/example.cpp 1058674
> /trunk/kdesupport/strigi/src/xsd/metadataproperties.cpp 1058674
> /trunk/kdesupport/strigi/src/xsd/strigidaemonconfiguration.cpp 1058674
>
> Diff: http://reviewboard.kde.org/r/2321/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Jaime
>
>

Re: Freeze exemption for PA integration into Phonon

2009-12-05T13:13:16Z

Am Saturday 05 December 2009 schrieb Colin Guthrie:
> I don't know if you've been following but gstreamer backend has had some
> attention in kdesupport of late.
This is not so much on the phonon backend, i had the same impression with
songbird (i was only looking around ;-)

gstreamer has about 10x the cpu load of xine/mplayer and it sounds just "bad"
(not as transparent as either xine or mplayer -no, no pp- and occsionally
clicks and notches like it has timing/sync trouble - maybe related to the poor
performance? - felt like end 90ies when sound just was bad on linux)

The bad thing atm. about the mplayer backend is that it cannot proceed tracks
in amarok, so xine is the backend to go for.

I'm not religious, but as long as at least the gstreamer sound isn't better
(read: "acceptable"), it remains no option - no matter if the principle design
is good or not
...and to become a real candidate it should at least be not that imperformant
;-P

Cheers

Re: Freeze exemption for PA integration into Phonon

2009-12-05T12:08:49Z

'Twas brillig, and Thomas Lübking at 05/12/09 15:29 did gyre and gimble:
> If QtPhonon is the "right" one, phonon should be moved out of kdesupport (as
> Qt is mandantory anyway) and the backends should just compile against the Qt
> phonon. <bash>as gstreamer is no option at all</bash>

I don't know if you've been following but gstreamer backend has had some
attention in kdesupport of late.

I only use Xine backedn when testing I've not broken something but
generally use gstreamer for when I'm actually using my desktop and it
Works fine for my use cases (which are not all that extreme to be fair).

Xine isn't a realistic option going forward either, but I accept that
gstreamer hasn't had as much love as it should, which is sad as from a
purely "what it's designed for" perspective, it should be the ideal
system... such is life.

Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

Re: Freeze exemption for PA integration into Phonon

2009-12-05T12:06:00Z

'Twas brillig, and Kevin Krammer at 05/12/09 16:20 did gyre and gimble:
> Phonon can't be treated like one of the other system libraries since it
> depends on Qt itself, i.e. it can't be installed prior to building Qt.
>
> So it is more a matter of either not needing the symbols during build or not
> install the interface libraries (doesn't have to build backends in any case).

Several packages need bootstrapping (e.g. how to compile gcc if you've
not got gcc :p).

It's not too much of a problem to:
1. Compile Qt sans-phonon
2. Compile Phonon
3. Recompile Qt + Phonon

Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

Re: Catching resume from suspend?

2009-12-05T12:03:39Z

Chani skrev:

> > > now, I get the feeling that since it doesn't Just Work yet, Solid
> > > doesn't provide us with any such signal. this feels like the sort of
> > > thing that solid *should* provide, but I don't know enough about the
> > > low-level details to say how it should be implemented.
> >
> > This has recently been discussed on hardware-devel
> > http://lists.kde.org/?t=125874601600001&r=1&w=2
>
> thanks.
> hmm, not looking very positive right now. silly HAL. but there's got to be
> a way, right? :)
>

Appearently, an option is to put a script in /usr/lib/pm-util that sends a
dbus message. That message could be caught by, say, a plasma dataengine. I
don't know how portable it is, but for example NetworkManager is using that on
my system, along with several other applications.

--
Venlig hilsen,
Anders

Re: Catching resume from suspend?

2009-12-05T11:53:30Z

On Saturday 05 December 2009 20:38:02 Chani wrote:

In the near future, probably. Somebody (tm) should push the devicekit-power,
upower, whatever their bloody name is, into adding such a thing

>

--
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B

signature.asc (205 bytes) Download Attachment

Re: Catching resume from suspend?

2009-12-05T11:38:02Z

> >
> > now, I get the feeling that since it doesn't Just Work yet, Solid doesn't
> > provide us with any such signal. this feels like the sort of thing that
> > solid *should* provide, but I don't know enough about the low-level
> > details to say how it should be implemented.
>
> This has recently been discussed on hardware-devel
> http://lists.kde.org/?t=125874601600001&r=1&w=2

thanks.
hmm, not looking very positive right now. silly HAL. but there's got to be a
way, right? :)

--
This message brought to you by eevil bananas and the number 3.
www.chani3.com

signature.asc (205 bytes) Download Attachment

Re: BIC change in KStatusNotifierItem API

2009-12-05T10:24:19Z

On Saturday 05 December 2009, Ingo Klöcker wrote:

> On Friday 04 December 2009, Andreas Pakulat wrote:
> > On 04.12.09 21:30:49, Olivier Goffart wrote:
> > > Le Friday 04 December 2009, Andreas Pakulat a écrit :
> > > > > This was done with approval from Marco Martin. It had to be
> > > > > done now because ABI changes in KStatusNotifierItem ABI won't
> > > > > be possible after kdelibs 4.4 is out.
> > > >
> > > > Just for the future: Usually such ABI breakages should be done on
> > > > Mondays if I recall correctly.
> > >
> > > That was in the time when ABI breakages were very frequent, before
> > > KDE 4.0 Now, there is no real need to enforce this policy i think.
> >
> > Well, I've already seen people complaining about it not being
> > enforced here (not so long ago). And I also think its still useful as
> > it means safety when just svn up'ing before starting to read the
> > mails. At least a warning a day or two before changing the ABI would
> > be good IMHO.
>
> Sending warnings by mail is useless. Many developers do not read
> kde-core-devel for one reason or the other.

I still see k-c-d as the "official" development channel of KDE, so things
should be announced here. If not here, where then ?

> We should simply stick with the ABI-breakage-on-Mondays-only rule.

Yes.

> Hmm, the SVN Commit Policy on techbase doesn't say anything about the
> ABI-breakage-on-Mondays-only rule.

Maybe it should be added there.

Alex

Re: Catching resume from suspend?

2009-12-05T10:09:22Z

On Saturday, 2009-12-05, Chani wrote:

> On December 5, 2009 09:21:38 Anders Lund wrote:
> > Hi,
> >
> > Sorry for crossposting, I hope it is not too bad.
> >
> > Now my problem: I have several plasma applets that uses qtimer to
> > schedule updates. These updates are then screwed up because of system
> > suspends (I close the lid of my laptop). So I can see two possible
> > solutions:
> >
> > 1) a signal that informs about a resume from suspend/standby (I tried to
> > use the powersave plasma dataengine which have state variables, but they
> > are not updated during suspend/resume events)
> >
> > 2) using brute force by checking the system time in intervals (such as
> > every minute). In a plasma event this would mean connecting to the time
> > dataengine and compare my scheduled time with the current.
> >
> > I ask because I do not have the knowledge to decide what is the best
> > thing to do, or if 1) is possible at all - afaik it is not, since I
> > havent found any working solution for it (I know there is something
> > called KIdleTime in KDE 4.4, but I do not see how that could help in this
> > case).
>
> #2 is Bad and Wrong; imagine every widget doing that, it'd be ridiculous.
> :)
>
> #1 is the right direction, although the exact implementation may differ...
> ideally dataengines should get kicked when there's a time jump or suspend
> or whatever; all the code to handle this should be in libplasma or higher
> (solid?), and it should Just Work for any dataengine. :) and of course a
> signal should be available for non-plasma stuff.
>
> now, I get the feeling that since it doesn't Just Work yet, Solid doesn't
> provide us with any such signal. this feels like the sort of thing that
> solid *should* provide, but I don't know enough about the low-level
> details to say how it should be implemented.

This has recently been discussed on hardware-devel
http://lists.kde.org/?t=125874601600001&r=1&w=2

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

signature.asc (197 bytes) Download Attachment

Re: Catching resume from suspend?

2009-12-05T10:08:22Z

Chani skrev:

I thought so :)

> #1 is the right direction, although the exact implementation may differ...
> ideally dataengines should get kicked when there's a time jump or suspend
> or whatever; all the code to handle this should be in libplasma or higher
> (solid?), and it should Just Work for any dataengine. :) and of course a
> signal should be available for non-plasma stuff.
>
> now, I get the feeling that since it doesn't Just Work yet, Solid doesn't
> provide us with any such signal. this feels like the sort of thing that
> solid *should* provide, but I don't know enough about the low-level
> details to say how it should be implemented.
>
> I imagine that the best case would be hal (or whatever backend solid talks
> to) telling us that we've woken up from suspend; if it doesn't do that,
> then at least when *we* initiate the suspend we could make a note of it
> and find a way to signal when we wake up. but I don't know how that stuff
> actually works, so hopefully someone else can explain how and where you
> can implement it. :)
>
> the end result should be that developers can either listen for that signal
> from solid, or just use a dataengine. :)
>

Ok, I also have little knowledge about the lowlevel end, so I hope someone can
with solid knowledge can help here ;)

--
Venlig hilsen,
Anders

Re: BIC change in KStatusNotifierItem API

2009-12-05T09:46:35Z

On Friday 04 December 2009, Andreas Pakulat wrote:

> On 04.12.09 21:30:49, Olivier Goffart wrote:
> > Le Friday 04 December 2009, Andreas Pakulat a écrit :
> > > > This was done with approval from Marco Martin. It had to be
> > > > done now because ABI changes in KStatusNotifierItem ABI won't
> > > > be possible after kdelibs 4.4 is out.
> > >
> > > Just for the future: Usually such ABI breakages should be done on
> > > Mondays if I recall correctly.
> >
> > That was in the time when ABI breakages were very frequent, before
> > KDE 4.0 Now, there is no real need to enforce this policy i think.
>
> Well, I've already seen people complaining about it not being
> enforced here (not so long ago). And I also think its still useful as
> it means safety when just svn up'ing before starting to read the
> mails. At least a warning a day or two before changing the ABI would
> be good IMHO.

Sending warnings by mail is useless. Many developers do not read
kde-core-devel for one reason or the other. We should simply stick with
the ABI-breakage-on-Mondays-only rule.

Hmm, the SVN Commit Policy on techbase doesn't say anything about the
ABI-breakage-on-Mondays-only rule.

Regards,
Ingo

signature.asc (204 bytes) Download Attachment

Re: Catching resume from suspend?

2009-12-05T09:46:14Z

On December 5, 2009 09:21:38 Anders Lund wrote:

> Hi,
>
> Sorry for crossposting, I hope it is not too bad.
>
> Now my problem: I have several plasma applets that uses qtimer to schedule
> updates. These updates are then screwed up because of system suspends (I
> close the lid of my laptop). So I can see two possible solutions:
>
> 1) a signal that informs about a resume from suspend/standby (I tried to
> use the powersave plasma dataengine which have state variables, but they
> are not updated during suspend/resume events)
>
> 2) using brute force by checking the system time in intervals (such as
> every minute). In a plasma event this would mean connecting to the time
> dataengine and compare my scheduled time with the current.
>
> I ask because I do not have the knowledge to decide what is the best thing
> to do, or if 1) is possible at all - afaik it is not, since I havent found
> any working solution for it (I know there is something called KIdleTime in
> KDE 4.4, but I do not see how that could help in this case).
>

#2 is Bad and Wrong; imagine every widget doing that, it'd be ridiculous. :)

#1 is the right direction, although the exact implementation may differ...
ideally dataengines should get kicked when there's a time jump or suspend or
whatever; all the code to handle this should be in libplasma or higher
(solid?), and it should Just Work for any dataengine. :) and of course a
signal should be available for non-plasma stuff.

now, I get the feeling that since it doesn't Just Work yet, Solid doesn't
provide us with any such signal. this feels like the sort of thing that solid
*should* provide, but I don't know enough about the low-level details to say
how it should be implemented.

I imagine that the best case would be hal (or whatever backend solid talks to)
telling us that we've woken up from suspend; if it doesn't do that, then at
least when *we* initiate the suspend we could make a note of it and find a way
to signal when we wake up. but I don't know how that stuff actually works, so
hopefully someone else can explain how and where you can implement it. :)

the end result should be that developers can either listen for that signal
from solid, or just use a dataengine. :)

--
This message brought to you by eevil bananas and the number 3.
www.chani3.com

signature.asc (205 bytes) Download Attachment

Catching resume from suspend?

2009-12-05T09:21:38Z

Hi,

Sorry for crossposting, I hope it is not too bad.

Now my problem: I have several plasma applets that uses qtimer to schedule
updates. These updates are then screwed up because of system suspends (I close
the lid of my laptop). So I can see two possible solutions:

1) a signal that informs about a resume from suspend/standby (I tried to use
the powersave plasma dataengine which have state variables, but they are not
updated during suspend/resume events)

2) using brute force by checking the system time in intervals (such as every
minute). In a plasma event this would mean connecting to the time dataengine
and compare my scheduled time with the current.

I ask because I do not have the knowledge to decide what is the best thing to
do, or if 1) is possible at all - afaik it is not, since I havent found any
working solution for it (I know there is something called KIdleTime in KDE
4.4, but I do not see how that could help in this case).

--
Kind regards,
Anders

Re: Freeze exemption for PA integration into Phonon

2009-12-05T08:40:06Z

Am Saturday 05 December 2009 schrieb Kevin Krammer:
> My understanding is that Phonon is a shared lib so you don't need it at
> build time.
> The interfaces are source and binary compatible so QtWebKit can safely use
> the headers of the Qt sources during build.
Looking at WebCore.pro, it does (still) not appear as if phonon support would
be compiled /at all/ in if you don't pass -phonon

contains(DEFINES, ENABLE_VIDEO=1)

which is itself 0 due to

contains(QT_CONFIG, phonon):DEFINES += ENABLE_VIDEO=1
else:DEFINES += ENABLE_VIDEO=0

still you'd not have Qt phonon support w/o compiling Qt with phonon support,
yesno?
(or does Qt (meanwhile?) detect the system phonon and weirdly adds support if
you explicitly added -no-phonon?!?)

> The runtime linker will then
> resolve the symbols by taking the library built from kdesupport.
If i move libQtPhonon out of the way, yes.

So the suggested way is to:
- compile Qt with -phonon
- compile kdesupport including phonon
- prefix kdesupport phonon to QTDIR, having it override the Qt variant
or
- replace QtPhonon with symlinks to kdesupport phonon (BC is guaranteed in
either way)
- compile KDE

Thomas

Re: Freeze exemption for PA integration into Phonon

2009-12-05T08:20:48Z

On Saturday, 2009-12-05, Thomas Lübking wrote:

> Am Saturday 05 December 2009 schrieb Christoph Feck:
> > As I understand it, the recent changes in Phonon were just way too late
> > to be included into Qt.
>
> That's not the point - i'd still have to pick a lib.
>
> If QtPhonon is the "right" one, phonon should be moved out of kdesupport
> (as Qt is mandantory anyway) and the backends should just compile against
> the Qt phonon. <bash>as gstreamer is no option at all</bash>
>
> If kdesupport phonon is the "right" one, Qt should allow to compile against
> the system libphonon (like i can use the system zlib, png, gif, whatever)

AFAIK this is the correct one, as in the most advanced.

Phonon can't be treated like one of the other system libraries since it
depends on Qt itself, i.e. it can't be installed prior to building Qt.

So it is more a matter of either not needing the symbols during build or not
install the interface libraries (doesn't have to build backends in any case).

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

signature.asc (197 bytes) Download Attachment

Re: Freeze exemption for PA integration into Phonon

2009-12-05T08:13:01Z

On Sat, Dec 05, 2009 at 04:18:13PM +0100, Christoph Feck wrote:
> As I understand it, the recent changes in Phonon were just way too late to be
> included into Qt.

Well, they haven't updated their version of Phonon in almost a year (from our
trunk, which should be canonical. But I see they've committed some changes
locally. It's a mess).

But I'm working on a patch for KDE-Qt, so that it gets an up-to-date Phonon
(for those that want the half-assed¹ <video> and <audio>-implementation in
QtWebKit :-p).

¹: It's not done with VideoDataOutput, the way it is supposed to be done™.

--
Martin Sandsmark
:wq

Re: Freeze exemption for PA integration into Phonon

2009-12-05T08:09:49Z

On Saturday, 2009-12-05, Thomas Lübking wrote:
> Am Saturday 05 December 2009 schrieb Kevin Krammer:
> > Since Tobias wrote he builds kdesupport, I would have assumed this means
> > building Qt without Phonon.
> > But I see that indeed the --no-phonon option is missing from the
> > recommended configure command in README.kde-qt (but I haven't updated
> > this recently).
>
> nope, not recommanded (plus unfortunately not everyone reads README!s ;-)

True, but it should be part of the recommendation for kde-qt builds.
Anyone is free to ignore recommendations but at least those who care should be
made aware of them.

> > Anyway, wouldn't you still get sound in e.g. Arora since you have Phonon
> > after installing it from kdesupport? (e.g. installing into the same
> > prefix?)
>
> Through external plugins (flash...) sure ;-)
> Through QtWebkit after building Qt w/o phonon? (like <embed
> src="ding.wav"/>)
>
> Not the last time i tried. (As QtWebkit was compiled w/o phonon support,
> but I run a double phonon installation since quite some time, so in fact
> webkit might meanwhile somehow load it as plugin when detecting it at
> runtime, but i doubt this)

My understanding is that Phonon is a shared lib so you don't need it at build
time.
The interfaces are source and binary compatible so QtWebKit can safely use the
headers of the Qt sources during build. The runtime linker will then resolve
the symbols by taking the library built from kdesupport.

It is basically an implicit plugin.

Or build but not install Phonon's libraries.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

signature.asc (197 bytes) Download Attachment

Re: Freeze exemption for PA integration into Phonon

2009-12-05T07:29:41Z

Am Saturday 05 December 2009 schrieb Christoph Feck:
> As I understand it, the recent changes in Phonon were just way too late to
> be included into Qt.
That's not the point - i'd still have to pick a lib.

If QtPhonon is the "right" one, phonon should be moved out of kdesupport (as
Qt is mandantory anyway) and the backends should just compile against the Qt
phonon. <bash>as gstreamer is no option at all</bash>

If kdesupport phonon is the "right" one, Qt should allow to compile against
the system libphonon (like i can use the system zlib, png, gif, whatever)

I don't care who ships phonon, but the current situation is at least confusing
and in (this) case leading ppl. to linker errors :-(

Thomas

Re: Freeze exemption for PA integration into Phonon

2009-12-05T07:18:13Z

On Saturday 05 December 2009 16:04:49 Thomas Lübking wrote:
> (Though i don't know about personal/political/legal issues behind the
> current situation)

As I understand it, the recent changes in Phonon were just way too late to be
included into Qt.

Christoph Feck (kdepepo)

Re: Freeze exemption for PA integration into Phonon

2009-12-05T07:04:49Z

Am Saturday 05 December 2009 schrieb Kevin Krammer:
> Since Tobias wrote he builds kdesupport, I would have assumed this means
> building Qt without Phonon.
> But I see that indeed the --no-phonon option is missing from the
> recommended configure command in README.kde-qt (but I haven't updated this
> recently).
nope, not recommanded (plus unfortunately not everyone reads README!s ;-)

> Anyway, wouldn't you still get sound in e.g. Arora since you have Phonon
> after installing it from kdesupport? (e.g. installing into the same
> prefix?)

Through external plugins (flash...) sure ;-)
Through QtWebkit after building Qt w/o phonon? (like <embed src="ding.wav"/>)

Not the last time i tried. (As QtWebkit was compiled w/o phonon support, but I
run a double phonon installation since quite some time, so in fact webkit
might meanwhile somehow load it as plugin when detecting it at runtime, but i
doubt this)

Also just removing phonon (i.e. all sound) support from bare Qt is (to me) no
solution at all.

Frankly, phonon is such a nice thing to have, but the current clash destroys
this completely (at least for everyone who fails to handle the 2-lib thing)

Of course one could expect distros to handle this and self-compilers know
about their system, but it could sadly simple work for nearby free :-(

(Though i don't know about personal/political/legal issues behind the current
situation)

Cheers,
Thomas

Re: Freeze exemption for PA integration into Phonon

2009-12-05T06:40:08Z

On Saturday, 2009-12-05, Thomas Lübking wrote:

> Welcome to the wonderful world of
> "We are incapable of picking and propagating /ONE/ phonon version..."
> grrr.
>
> The problem is that your phonon plugin was compiled and linked against the
> phonon from kdesupport (4.4) whereas qt ships it's own phonon (4.3) which
> designer links in (probably when loading a Qt phonon plugin - gstreamer)
> and which simply does not provide this function.
>
> Either you:
> - compile Qt w/o phonon (great!, no sound etc. for eg. arora)

Since Tobias wrote he builds kdesupport, I would have assumed this means
building Qt without Phonon.
But I see that indeed the --no-phonon option is missing from the recommended
configure command in README.kde-qt (but I haven't updated this recently).

Anyway, wouldn't you still get sound in e.g. Arora since you have Phonon after
installing it from kdesupport? (e.g. installing into the same prefix?)

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

signature.asc (197 bytes) Download Attachment

Re: Freeze exemption for PA integration into Phonon

2009-12-05T06:17:44Z

Welcome to the wonderful world of
"We are incapable of picking and propagating /ONE/ phonon version..."
grrr.

The problem is that your phonon plugin was compiled and linked against the
phonon from kdesupport (4.4) whereas qt ships it's own phonon (4.3) which
designer links in (probably when loading a Qt phonon plugin - gstreamer) and
which simply does not provide this function.

Either you:
- compile Qt w/o phonon (great!, no sound etc. for eg. arora)
- replace the Qt phonon lib with a symlink to the kdesupport variant (very
reliable solution...)
- drop phonon from kdesupport (which is not only one version ahead, but also
brings the xine backend and gstreamer is §$%&/()= !)

- in this very case start designer like

LD_PRELOAD=/full/path/to/my/kdesupport/libphonon.so designer

to ensure the kdesupport phonon is used.

Phonon should be some "3rd" party thing out of ONE source (whoever this is - i
don't care either) so one can compile and lilnk Qt and KDE against the one and
only same library

My 2¢:
Basically this means the former trolls should allow "-system-phonon"

Cheers

Ps:
If anybody feels offended by the above rant - i don't care >-)

Am Saturday 05 December 2009 schrieb Tobias Koenig:

> On Wed, Nov 18, 2009 at 06:10:20PM +0100, Martin Sandsmark wrote:
> > Hi!
>
> Hej,
>
> I have a problem to start Qt designer with current KDE trunk because of
> the PA integration in phonon:
>
> designer: symbol lookup error:
> /mnt/archive/opt/kde-trunk/lib/kde4/plugins/phonon_backend/phonon_xine.so:
> undefined symbol: _ZN6Phonon12PulseSupport11getInstanceEv
>
> Any idea what the reason could be or how to fix it?
> I use kdesupport/phonon from trunk and qt/master branch from git
> repository.
>
> Ciao,
> Tobias
>

Re: Freeze exemption for PA integration into Phonon

2009-12-05T05:55:21Z

On Wed, Nov 18, 2009 at 06:10:20PM +0100, Martin Sandsmark wrote:
> Hi!
Hej,

I have a problem to start Qt designer with current KDE trunk because of
the PA integration in phonon:

designer: symbol lookup error: /mnt/archive/opt/kde-trunk/lib/kde4/plugins/phonon_backend/phonon_xine.so: undefined symbol: _ZN6Phonon12PulseSupport11getInstanceEv

Any idea what the reason could be or how to fix it?
I use kdesupport/phonon from trunk and qt/master branch from git repository.

Ciao,
Tobias

signature.asc (205 bytes) Download Attachment

Review Request: Patch to address job queueing and ioslave spawn limits in KIO::Scheduler...

2009-12-05T02:13:19Z

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

Review request for kdelibs.

Summary
-------

This patch is intended to address the issue of job queueing and enforcement of per host connection limits, and hence ioslaves spawned, in KIO::Scheduler. Right now KIO::Scheduler only reuses idle ioslaves and does not by default provide job queueing. It simply spawns as many ioslaves (read: connections/sockets) as there are jobs if it cannot find an idle one to reuse. This default behavior has been the cause of more than a few issues that have been amply disscused in other threads recently:

http://lists.kde.org/?t=125857293400001&r=1&w=2
http://lists.kde.org/?t=125149495900004&r=1&w=2
http://lists.kde.org/?t=124531188100002&r=1&w=2

Based on the feedback I received from the discussions in the threads listed above, I have gone ahead and made the necessary modifications hanges to address the concerns that were raised there. Specifically, this version addresses the potential deadlock conditions created with the first patch as pointed out by David. As such I would like to commit these changes into trunk so that it can receive wider testing. As a precaution, the patch leaves out the portion of code that makes it the default for all KIO job requests. Instead only jobs scheduled through implicit calls to KIO::Scheduler::scheduleJob will be affected by this change. This would mean only few components such as the newly added kdewebkit will be impacted and serve as the test bed for the much needed changes that will surely come to KIO::Scheduler in the future (read Hartmetz's response in the first thread).

Diffs
-----

/trunk/KDE/kdelibs/kdecore/sycoca/kprotocolinfo.h 1058764
/trunk/KDE/kdelibs/kdecore/sycoca/kprotocolinfo.h 1058764
/trunk/KDE/kdelibs/kdecore/sycoca/kprotocolinfo.cpp 1058764
/trunk/KDE/kdelibs/kdecore/sycoca/kprotocolinfo.cpp 1058764
/trunk/KDE/kdelibs/kdecore/sycoca/kprotocolinfo_p.h 1058764
/trunk/KDE/kdelibs/kdecore/sycoca/kprotocolinfo_p.h 1058764
/trunk/KDE/kdelibs/kdecore/sycoca/ksycoca.cpp 1058764
/trunk/KDE/kdelibs/kdecore/sycoca/ksycoca.cpp 1058764
/trunk/KDE/kdelibs/kio/kio/job.cpp 1058764
/trunk/KDE/kdelibs/kio/kio/job_p.h 1058764
/trunk/KDE/kdelibs/kio/kio/scheduler.cpp 1058764

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

Testing
-------

Been using this patch daily with the stable KDE 4.3 branch since its first creation a couple of months back.

Thanks,

adawit