Re: mouse buttons - my view from X11 upwards into Qt

[todd rme]

On Sun, Feb 20, 2011 at 4:57 PM, Rick Stockton <
rickstock...@reno-computerhelp.com> wrote:

>  Within Qt, the Devs have recognized that Button8 and Button9 are
> frequently implemented "backwards". Thus they assigned the more cryptic
> names "XButton1" and "XButton2".
>

Are you sure about this?  I thought xbutton1 and xbutton2 where the
"buttons" for the x-axis, that is the scroll wheel.  In other words,
xbutton1 is scroll up and xbutton 2 is scroll down (or vice versus).

-Todd

Bugzilla and identity.kde.org down this Saturday.

[Tom Albers]

Hi,

We've received a note that immanuel.kde.org will be down this Saturday. From 
7.30h CET up to 16h CET the hosting provider has planned work on the power 
supply to the hosting location.

The services affected are: bugs, identity, docs, promo, events, games, home and 
rsync.kde.org

A nasty side effect is that identity.kde.org is providing authentication 
services to several other sites, like git.reviewboard.kde.org and 
projects.kde.org. This means logged in users are lucky, but you can not log in 
if you are logged out.

Unfortunately we have not had time to setup a replication for identity.kde.org 
and it's not going to happen before this outage.

Best,
-- 
Tom Albers
KDE Sysadmin

Re: Review Request: KListWidgetSearchLine: filter items that are inserted or changed

[Stephen Kelly]

David Faure wrote:

> kdeui/itemviews/klistwidgetsearchline.cpp
> 
> 
> topLeft.parent().isValid() || bottomRight.parent().isValid()
> 
> 
> - David

Actually topLeft.parent() == bottomRight.parent(), so you only need one.

Re: Review Request: KListWidgetSearchLine: filter items that are inserted or changed

[David Faure]

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

Ship it!


Looks good -- obviously, since it provides a unit-test ;-)
I was assuming this class handled such cases already, obviously not...

Its companion KTreeWidgetSearchLine seems to handle rowsInserted already, but 
not dataChanged...


kdeui/itemviews/klistwidgetsearchline.cpp


Use .isValid() instead; faster.



kdeui/itemviews/klistwidgetsearchline.cpp


topLeft.parent().isValid() || bottomRight.parent().isValid()


- David


On Feb. 21, 2011, 7:09 p.m., Frank Reininghaus wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100709/
> ---
> 
> (Updated Feb. 21, 2011, 7:09 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Summary
> ---
> 
> Up to now, KlistWidgetSearchLine filters the list widget's items only when 
> the text in the search line is changed (or updateSearch() is called 
> directly). I propose to also update the search when items are added to the 
> list widget or when an item's data are changed.
> 
> I've moved the actual filtering code from 
> KListWidgetSearchLine::updateSearch(const QString &s) to a private method to 
> avoid code duplication (basically, the same code is needed if items are added 
> or changed).
> 
> This is needed fix bug 265709. Unit test included.
> 
> If this patch is accepted, I'll try to do something similar for 
> KTreeWidgetSearchLine.
> 
> 
> This addresses bug 265709.
> http://bugs.kde.org/show_bug.cgi?id=265709
> 
> 
> Diffs
> -
> 
>   kdeui/itemviews/klistwidgetsearchline.h a78fb9b 
>   kdeui/itemviews/klistwidgetsearchline.cpp 5b9b03d 
>   kdeui/tests/CMakeLists.txt 71c2426 
>   kdeui/tests/klistwidgetsearchlinetest.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/100709/diff
> 
> 
> Testing
> ---
> 
> The bug seems fixed, the new unit test passed. I haven't observed any 
> regressions so far.
> 
> 
> Thanks,
> 
> Frank
> 
>

Re: mouse buttons - my view from X11 upwards into Qt

[David Faure]

On Sunday 20 February 2011, Rick Stockton wrote:
> Qt::NoButton0x  The button state does not refer to any
> button  (see QMouseEvent::button
> ()).
> Qt::LeftButton  0x0001  The left button is pressed, or an event 
> refers to the left button. (The left button may be the right button on 
> left-handed mice.)
> Qt::RightButton 0x0002  The right button.
> Qt::MidButton   0x0004  The middle button.
> Qt::MiddleButtonMidButton   The middle button.
> Qt::XButton10x0008  The first X button.
> Qt::XButton20x0010  The second X button.

Let's look at the header file rather than the API docs:

enum MouseButton {
NoButton = 0x,
LeftButton   = 0x0001,
RightButton  = 0x0002,
MidButton= 0x0004, // ### Qt 5: remove me
MiddleButton = MidButton,
XButton1 = 0x0008,
XButton2 = 0x0010,
MouseButtonMask  = 0x00ff
};

"Qt::MouseButton defines all values as 32-bit hex values 
(with leading zeroes)" is true, but does this really matter to the compiler?
0x0001 is really just 1.

> I think that an enumerated item with an explicit value will NEVER be 
> compressed, even though a Compiler which wanted to squeeze an enum of 7 
> items (defined without specific values) into a SINGLE BYTE would be free 
> to do so. If my understanding is correct on all platforms, then we can 
> safely use the entire Uint32.

The standard (6.7.2.2 Enumeration specifiers) (not that I know this by heart, 
google helped) says:

Each enumerated type shall be compatible with char, a signed integer type, or 
an unsigned integer type. The choice of type is implementation-defined, but 
shall be capable of representing the values of all the members of the 
enumeration.

So this enum might very well be a single byte on some compilers, since 0xff 
fits. AFAIK gcc and msvc don't do this, though. I'll let Thiago answer about 
the more unusual compilers out there :-)

> This portion of "more mouse buttons", the part within Qt, isn't big 
> enough for GSOC. Perhaps the KDE follow-ups are, and I will touch on a 
> few in separate messages. I intend to write and fully document the Qt 
> Updates myself, after I receive your comments and recommendation -- and, 
> I hope, a similar input from a Qt person working in the "input devices" 
> area. (I know that they have other, big things to think about, but I'd 
> hate to do a bunch of work and be told "this isn't the right design" 
> AFTERWARDS.) So, if you can link me up with such a Qt person, please do 
> so. This is a REAL email address and a good contact point for me.

You might want to try IRC, irc.freenode.net, channel #qt-labs.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

Re: KShutdown got to kde-runtime without review

[Albert Astals Cid]

A Dilluns, 21 de febrer de 2011, Ralf Habacker va escriure:
> Am 20.02.2011 13:56, schrieb Pino Toscano:
> > Alle giovedì 17 febbraio 2011, Pino Toscano ha scritto:
> >> Alle giovedì 17 febbraio 2011, Ralf Habacker ha scritto:
> >>> Am 17.02.2011 09:32, schrieb Pino Toscano:
>  Alle giovedì 17 febbraio 2011, Ralf Habacker ha scritto:
> > Am 17.02.2011 09:18, schrieb Ralf Habacker:
> >> Am 16.02.2011 20:40, schrieb Albert Astals Cid:
> >>> Why?
> >> 
> >> I'm currently the only reviewer for windows and I reviewed the
> >> code already :-)
> > 
> > If you insist on following the formal process I can submit a
> > review request and will do the review
>  
>  Can you please rename it to e.g. kdewin-shutdown or similar,
>  given that there's already a kshutdown application for KDE for
>  years?
> >>> 
> >>> You are refering to http://kshutdown.sourceforge.net, which is a qt
> >>> only application ?
> >> 
> >> Yes, I'm referring to that KDE application (which can optionally be
> >> Qt- only). And whatever it is, it predates your utility, which must
> >> use another name, to avoid any kind of clash (application name,
> >> configuration files and associated data, .po/.mo files, etc).
> > 
> > Ping?
> > This (the clash with kshutdown) will be a *real* issue when in 4 days
> > KDE 4.6.1 will be tagged. Please do fix this issue (renaming the
> > application) ASAP.
> 
> Yeah, I thought about the weekend if it would be a solution to merge
> this feature into the external hosted kshutdown app and it would be
> possible, but kshutdown is an external application and then it would
> have to be a part of kde-runtime, which looks not to be possible in the
> short time.
> In the platforms/win dir there is also kwinstartmenu, so I will rename
> it to kwinshutdown today.

You still have not fixed the problem of not loading the catalog.

Albert

> 
> Ralf
> 
> 
> Ralf

Review Request: KListWidgetSearchLine: filter items that are inserted or changed

[Frank Reininghaus]

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

Review request for kdelibs and David Faure.


Summary
---

Up to now, KlistWidgetSearchLine filters the list widget's items only when the 
text in the search line is changed (or updateSearch() is called directly). I 
propose to also update the search when items are added to the list widget or 
when an item's data are changed.

I've moved the actual filtering code from 
KListWidgetSearchLine::updateSearch(const QString &s) to a private method to 
avoid code duplication (basically, the same code is needed if items are added 
or changed).

This is needed fix bug 265709. Unit test included.

If this patch is accepted, I'll try to do something similar for 
KTreeWidgetSearchLine.


This addresses bug 265709.
http://bugs.kde.org/show_bug.cgi?id=265709


Diffs
-

  kdeui/itemviews/klistwidgetsearchline.h a78fb9b 
  kdeui/itemviews/klistwidgetsearchline.cpp 5b9b03d 
  kdeui/tests/CMakeLists.txt 71c2426 
  kdeui/tests/klistwidgetsearchlinetest.cpp PRE-CREATION 

Diff: http://git.reviewboard.kde.org/r/100709/diff


Testing
---

The bug seems fixed, the new unit test passed. I haven't observed any 
regressions so far.


Thanks,

Frank

Re: KShutdown got to kde-runtime without review

[Albert Astals Cid]

A Dilluns, 21 de febrer de 2011, Marco Martin va escriure:
> On Monday 21 February 2011, Albert Astals Cid wrote:
> > A Diumenge, 20 de febrer de 2011, Marco Martin va escriure:
> > > On Wednesday 16 February 2011, Albert Astals Cid wrote:
> > > > Why?
> > > > 
> > > > Albert
> > > 
> > > Speaking of which, what is the policy now?
> > > I have in a branch of kdelibs a little library that should go into
> > > experimental/ (probably staying there for 4.7)
> > > 
> > > now that there isn't anymore the kdereview svn repo, how this things
> > > get reviewed?
> > 
> > We still have https://projects.kde.org/projects/kdereview but i
> > understand that only works for separate repos.
> > 
> > > just announcing here that there is the plasma/declarative branch in
> > > kdelibs that should be merged?
> > 
> > That'd be enough for me but it is not me that sets the rules :D
> 
> well, that one in particular could in theory still be pulled in a separate
> repository, other parts (libplasma at the moment) still don't depend from
> it but i really have to make it depend soon...
> this is still quite independent, but i guess in the future there will be
> plenty of big branches that really couldn't be pulled in a separate repo
> 
> what about a wiki page that lists branches big enough that need a review?

That needs me having a regular look at that wiki. Sincerely i prefer the way 
we have now (send mail to k-c-d and appropiate mailing list) since that way 
things come to me with zero effort. OTOH if you volunteer to maintain that 
wiki as second source of information i don't see a problem.

Albert

> 
> Cheers,
> Marco Martin

Re: Review Request: Phonon KDED module: Improve finding virtual devices from ALSA

[Casian Andrei]

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

(Updated Feb. 21, 2011, 5:59 p.m.)


Review request for KDE Runtime, Phonon, Phonon Backends, Harald Sitter, and 
Trever Fischer.


Changes
---

Fixed the issues pointed out.

Moved the hw thing to Phonon-VLC. 

Tried plughw instead, but doesn't work, maybe hw -> plughw somehow. I don't 
know, but with "hw" it works, with anything else it doesn't.


Summary
---

Modifications on findVirtualDevices in PhononServer, to make it find usable 
capture devices for Phonon-VLC, at least. Phonon audio capture works with the 
provided devices. Also made a couple of mostly irelevant improvements.

The Phonon KDED module was not providing any usable capture devices. Only some 
iec958 digital devices showed up, which didn't work at all. VLC needs a default 
analog ALSA device, like hw:CARD=SB, in my case.

Solid is not returning any audio devices on my system. I do not know if it 
works properly on other systems, but I will investigate further.

This is the commit message:

Phonon KDED module: Improve finding virtual devices from ALSA

PhononServer was not finding any usable capture devices. It
was skipping almost all useful devices. Commented out the
block for skipping those.

Prevent devices with empty names when their description
is empty. This should not happen, but it's just in case.

Eliminate any front, center, rear, surround virtual devices from
capture device candidates.

Additionaly, there will be only one device with an unique id, with
one or more access descriptors.

Replace default: with hw: for capture devices, to enable capture
working with Phonon-VLC.

Because Solid doesn't give me any audio devices, I cannot test for the cases 
when it actually works. However, I believe that it doesn't work on most systems.

The other iec958 digital stuff devices show up as advanced.


Diffs (updated)
-

  phonon/kded-module/phononserver.cpp 44f857e 

Diff: http://git.reviewboard.kde.org/r/100700/diff


Testing
---

Restarted KDED and ran kcmshell4 phonon, viewed the audio devices. All looks 
ok. No bogus devices.

Tested the capture demos from Phonon (currently they have a buggy interface, 
will be fixed), and they worked fine. Audio capture works ok with the 
Phonon-VLC backend. Audio-video capture also works if you get around the demo's 
interface bugs. 

Don't know what happens when Solid actually works for audio devices, if these 
changes interfere with Phonon's functionality in that case.
Not tested on other systems to see if any bogus devices appear out of nowhere.

Amarok still works :P


Screenshots (updated)
---

Phonon config with analog capture devices
  http://git.reviewboard.kde.org/r/100700/s/80/


Thanks,

Casian

Re: Review Request: Can't switch back to laptop display when external display gets disconnected

[alter_schwede]

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

(Updated Feb. 21, 2011, 5:29 p.m.)


Review request for kdelibs and usability.


Changes
---

One more thing that came to my mind: Don't check if the output is already 
enabled if it's the only one. This will set it to the preferred resolution if 
it's already active.


Summary
---

I already posted this patch here:
https://bugs.kde.org/show_bug.cgi?id=265955

This is a patch to the kded_randrmonitor service that solves the below
mentioned problem.
If only one output is connected and the user tries to switch the display it
makes sure the connected output gets activated and deactivates all disconnected
output afterwards.

Reproducible: Always

Steps to Reproduce:
1. Connect an external display to your laptop and use your latop's hotkey (e.g.
Fn+F6) to active it and deactivate your laptop's display.
2. Disconnect the external display
3. Try to switch back to internal display with your keyboard

Actual Results:  
Nothing happens

I improved my patch.
Now it also automatically deactivates all disconnected outputs on resume from
suspend and switches to a connected monitor if needed. This should fix e.g. Bug
#257642.


This addresses bugs 257642 and 265955.
https://bugs.kde.org/show_bug.cgi?id=257642
https://bugs.kde.org/show_bug.cgi?id=265955


Diffs (updated)
-

  /branches/KDE/4.6/kdebase/workspace/kcontrol/randr/module/randrmonitor.h 
1221086 
  /branches/KDE/4.6/kdebase/workspace/kcontrol/randr/module/randrmonitor.cpp 
1221086 

Diff: http://svn.reviewboard.kde.org/r/6513/diff


Testing
---


Thanks,

alter_schwede

Re: Review Request: Phonon KDED module: Improve finding virtual devices from ALSA

[Harald Sitter]

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



phonon/kded-module/phononserver.cpp


Is this ever coming back? If not, please remove it completely, if it is 
please add a comment and ultimately a TODO or FIXME.



phonon/kded-module/phononserver.cpp


Style: left curly brace goes on the same line as the start of the statement



phonon/kded-module/phononserver.cpp


"Fix *the*" maybe?



phonon/kded-module/phononserver.cpp


Style: left curly brace goes on the same line as the start of the statement



phonon/kded-module/phononserver.cpp


Style: left curly brace goes on the same line as the start of the statement



phonon/kded-module/phononserver.cpp


The rationale of this is not really convincing, if only the VLC backend has 
problems, then the VLC backend should change the name accordingly.
Also Rémi Denis-Courmont indicated on the phonon-backends list that it 
should use plughw anyway.

Please reevaluate and if possible at all move this logic to the phonon-vlc 
backend.


- Harald


On Feb. 21, 2011, 11:23 a.m., Casian Andrei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100700/
> ---
> 
> (Updated Feb. 21, 2011, 11:23 a.m.)
> 
> 
> Review request for KDE Runtime, Phonon, Phonon Backends, Harald Sitter, and 
> Trever Fischer.
> 
> 
> Summary
> ---
> 
> Modifications on findVirtualDevices in PhononServer, to make it find usable 
> capture devices for Phonon-VLC, at least. Phonon audio capture works with the 
> provided devices. Also made a couple of mostly irelevant improvements.
> 
> The Phonon KDED module was not providing any usable capture devices. Only 
> some iec958 digital devices showed up, which didn't work at all. VLC needs a 
> default analog ALSA device, like hw:CARD=SB, in my case.
> 
> Solid is not returning any audio devices on my system. I do not know if it 
> works properly on other systems, but I will investigate further.
> 
> This is the commit message:
> 
> Phonon KDED module: Improve finding virtual devices from ALSA
> 
> PhononServer was not finding any usable capture devices. It
> was skipping almost all useful devices. Commented out the
> block for skipping those.
> 
> Prevent devices with empty names when their description
> is empty. This should not happen, but it's just in case.
> 
> Eliminate any front, center, rear, surround virtual devices from
> capture device candidates.
> 
> Additionaly, there will be only one device with an unique id, with
> one or more access descriptors.
> 
> Replace default: with hw: for capture devices, to enable capture
> working with Phonon-VLC.
> 
> Because Solid doesn't give me any audio devices, I cannot test for the cases 
> when it actually works. However, I believe that it doesn't work on most 
> systems.
> 
> The other iec958 digital stuff devices show up as advanced.
> 
> 
> Diffs
> -
> 
>   phonon/kded-module/phononserver.cpp 44f857e 
> 
> Diff: http://git.reviewboard.kde.org/r/100700/diff
> 
> 
> Testing
> ---
> 
> Restarted KDED and ran kcmshell4 phonon, viewed the audio devices. All looks 
> ok. No bogus devices.
> 
> Tested the capture demos from Phonon (currently they have a buggy interface, 
> will be fixed), and they worked fine. Audio capture works ok with the 
> Phonon-VLC backend. Audio-video capture also works if you get around the 
> demo's interface bugs. 
> 
> Don't know what happens when Solid actually works for audio devices, if these 
> changes interfere with Phonon's functionality in that case.
> Not tested on other systems to see if any bogus devices appear out of nowhere.
> 
> Amarok still works :P
> 
> 
> Screenshots
> ---
> 
> Capture devices in Phonon config
>   http://git.reviewboard.kde.org/r/100700/s/79/
> 
> 
> Thanks,
> 
> Casian
> 
>

Review Request: Add support for building libplasma with GLES2

[Jammy Zhou]

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

Review request for kdelibs.


Summary
---

After build kwin with GLES2 code path, the kwin binary still has dependency on 
libGL.so, which is introduced by libplasma.so. Then we also need to add GLES2 
support to libplasma, so that kwin/plasma only has dependency on libGLESv2.so 
in this case. 

The new option "BUILD_PLASMA_WITH_OPENGLES" added in attached patch is disabled 
by default, and distributions can turn it on when do packaging for OpenGL ES2.0 
support.


Diffs
-

  CMakeLists.txt 2dcc5ec 
  cmake/modules/FindOpenGLES.cmake PRE-CREATION 
  includes/CMakeLists.txt 9954c37 
  plasma/CMakeLists.txt 8e6b0d7 

Diff: http://git.reviewboard.kde.org/r/100705/diff


Testing
---

After turn the "BUILD_PLASMA_WITH_OPENGLES" option on, kwin-gles has no 
dependency on libGL.so now. And by default, libplasma still depends on libGL.so 
when run ldd.


Thanks,

Jammy

Review Request: Phonon KDED module: Improve finding virtual devices from ALSA

[Casian Andrei]

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

Review request for KDE Runtime, Phonon, Phonon Backends, Harald Sitter, and 
Trever Fischer.


Summary
---

Modifications on findVirtualDevices in PhononServer, to make it find usable 
capture devices for Phonon-VLC, at least. Phonon audio capture works with the 
provided devices. Also made a couple of mostly irelevant improvements.

The Phonon KDED module was not providing any usable capture devices. Only some 
iec958 digital devices showed up, which didn't work at all. VLC needs a default 
analog ALSA device, like hw:CARD=SB, in my case.

Solid is not returning any audio devices on my system. I do not know if it 
works properly on other systems, but I will investigate further.

This is the commit message:

Phonon KDED module: Improve finding virtual devices from ALSA

PhononServer was not finding any usable capture devices. It
was skipping almost all useful devices. Commented out the
block for skipping those.

Prevent devices with empty names when their description
is empty. This should not happen, but it's just in case.

Eliminate any front, center, rear, surround virtual devices from
capture device candidates.

Additionaly, there will be only one device with an unique id, with
one or more access descriptors.

Replace default: with hw: for capture devices, to enable capture
working with Phonon-VLC.

Because Solid doesn't give me any audio devices, I cannot test for the cases 
when it actually works. However, I believe that it doesn't work on most systems.

The other iec958 digital stuff devices show up as advanced.


Diffs
-

  phonon/kded-module/phononserver.cpp 44f857e 

Diff: http://git.reviewboard.kde.org/r/100700/diff


Testing
---

Restarted KDED and ran kcmshell4 phonon, viewed the audio devices. All looks 
ok. No bogus devices.

Tested the capture demos from Phonon (currently they have a buggy interface, 
will be fixed), and they worked fine. Audio capture works ok with the 
Phonon-VLC backend. Audio-video capture also works if you get around the demo's 
interface bugs. 

Don't know what happens when Solid actually works for audio devices, if these 
changes interfere with Phonon's functionality in that case.
Not tested on other systems to see if any bogus devices appear out of nowhere.

Amarok still works :P


Screenshots
---

Capture devices in Phonon config
  http://git.reviewboard.kde.org/r/100700/s/79/


Thanks,

Casian

Re: Review Request: Phonon KDED module: Improve finding virtual devices from ALSA

[Casian Andrei]

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

(Updated Feb. 21, 2011, 11:23 a.m.)


Review request for KDE Runtime, Phonon, Phonon Backends, Harald Sitter, and 
Trever Fischer.


Changes
---

Remove trailing spaces...

Seems kdevelop doesn't mark them for me anymore :(


Summary
---

Modifications on findVirtualDevices in PhononServer, to make it find usable 
capture devices for Phonon-VLC, at least. Phonon audio capture works with the 
provided devices. Also made a couple of mostly irelevant improvements.

The Phonon KDED module was not providing any usable capture devices. Only some 
iec958 digital devices showed up, which didn't work at all. VLC needs a default 
analog ALSA device, like hw:CARD=SB, in my case.

Solid is not returning any audio devices on my system. I do not know if it 
works properly on other systems, but I will investigate further.

This is the commit message:

Phonon KDED module: Improve finding virtual devices from ALSA

PhononServer was not finding any usable capture devices. It
was skipping almost all useful devices. Commented out the
block for skipping those.

Prevent devices with empty names when their description
is empty. This should not happen, but it's just in case.

Eliminate any front, center, rear, surround virtual devices from
capture device candidates.

Additionaly, there will be only one device with an unique id, with
one or more access descriptors.

Replace default: with hw: for capture devices, to enable capture
working with Phonon-VLC.

Because Solid doesn't give me any audio devices, I cannot test for the cases 
when it actually works. However, I believe that it doesn't work on most systems.

The other iec958 digital stuff devices show up as advanced.


Diffs (updated)
-

  phonon/kded-module/phononserver.cpp 44f857e 

Diff: http://git.reviewboard.kde.org/r/100700/diff


Testing
---

Restarted KDED and ran kcmshell4 phonon, viewed the audio devices. All looks 
ok. No bogus devices.

Tested the capture demos from Phonon (currently they have a buggy interface, 
will be fixed), and they worked fine. Audio capture works ok with the 
Phonon-VLC backend. Audio-video capture also works if you get around the demo's 
interface bugs. 

Don't know what happens when Solid actually works for audio devices, if these 
changes interfere with Phonon's functionality in that case.
Not tested on other systems to see if any bogus devices appear out of nowhere.

Amarok still works :P


Screenshots
---

Capture devices in Phonon config
  http://git.reviewboard.kde.org/r/100700/s/79/


Thanks,

Casian

Re: Review Request: Phonon KDED module: Improve finding virtual devices from ALSA

[Trever Fischer]

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



Screenshot: Capture devices in Phonon config

Can I have an english screenshot?

- Trever


On Feb. 21, 2011, 11:23 a.m., Casian Andrei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100700/
> ---
> 
> (Updated Feb. 21, 2011, 11:23 a.m.)
> 
> 
> Review request for KDE Runtime, Phonon, Phonon Backends, Harald Sitter, and 
> Trever Fischer.
> 
> 
> Summary
> ---
> 
> Modifications on findVirtualDevices in PhononServer, to make it find usable 
> capture devices for Phonon-VLC, at least. Phonon audio capture works with the 
> provided devices. Also made a couple of mostly irelevant improvements.
> 
> The Phonon KDED module was not providing any usable capture devices. Only 
> some iec958 digital devices showed up, which didn't work at all. VLC needs a 
> default analog ALSA device, like hw:CARD=SB, in my case.
> 
> Solid is not returning any audio devices on my system. I do not know if it 
> works properly on other systems, but I will investigate further.
> 
> This is the commit message:
> 
> Phonon KDED module: Improve finding virtual devices from ALSA
> 
> PhononServer was not finding any usable capture devices. It
> was skipping almost all useful devices. Commented out the
> block for skipping those.
> 
> Prevent devices with empty names when their description
> is empty. This should not happen, but it's just in case.
> 
> Eliminate any front, center, rear, surround virtual devices from
> capture device candidates.
> 
> Additionaly, there will be only one device with an unique id, with
> one or more access descriptors.
> 
> Replace default: with hw: for capture devices, to enable capture
> working with Phonon-VLC.
> 
> Because Solid doesn't give me any audio devices, I cannot test for the cases 
> when it actually works. However, I believe that it doesn't work on most 
> systems.
> 
> The other iec958 digital stuff devices show up as advanced.
> 
> 
> Diffs
> -
> 
>   phonon/kded-module/phononserver.cpp 44f857e 
> 
> Diff: http://git.reviewboard.kde.org/r/100700/diff
> 
> 
> Testing
> ---
> 
> Restarted KDED and ran kcmshell4 phonon, viewed the audio devices. All looks 
> ok. No bogus devices.
> 
> Tested the capture demos from Phonon (currently they have a buggy interface, 
> will be fixed), and they worked fine. Audio capture works ok with the 
> Phonon-VLC backend. Audio-video capture also works if you get around the 
> demo's interface bugs. 
> 
> Don't know what happens when Solid actually works for audio devices, if these 
> changes interfere with Phonon's functionality in that case.
> Not tested on other systems to see if any bogus devices appear out of nowhere.
> 
> Amarok still works :P
> 
> 
> Screenshots
> ---
> 
> Capture devices in Phonon config
>   http://git.reviewboard.kde.org/r/100700/s/79/
> 
> 
> Thanks,
> 
> Casian
> 
>

Re: Review Request: Patch to build only kdecore

[Gregory Schlomoff]

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

(Updated Feb. 21, 2011, 10:15 a.m.)


Review request for kdelibs and KDEPIM-Libraries.


Changes
---

Renamed the build option from KIMAP_STANDALONE to KDE4_ONLY_KDECORE, as 
suggested


Summary
---

Hello,

As some of you may know, we are using KIMAP and KMime as stand-alone libraries 
for BetterInbox, our cross-platform email client.

Since our primary targets are Windows and Mac OS X platforms, it would be quite 
costly to try to build and ship the whole kdelibs + kdepimlibs + dependencies 
in order to use just kimap and kmime. So we made a few patches to KDE's build 
scripts that enable to build only kdecore + kimap + kmime. The only third-party 
dependencies on Windows are kdewin, boost, cyrus-sasl, and zlib.

Basically, we just declare a new build option called KIMAP_STANDALONE, that 
will skip the compilation of everything that is not needed. We are sharing the 
patches to kdelibs in this review request. See 
https://git.reviewboard.kde.org/r/100698/ for the patches to kdepimlibs.

Please note that the goal here is *NOT* to ask for the inclusion of those 
patches into KDE's source code, but rather to show the community how we did it, 
and maybe to foster some discussion around the idea of modularizing kdelibs and 
kdepimlibs a bit more, so that this kind of hack wouldn't be needed.

Any ideas / comments appreciated.

Cheers,

Greg Schlomoff
Founder, BetterInbox


Diffs (updated)
-

  CMakeLists.txt 87631d1 
  cmake/modules/FindKDE4Internal.cmake d4e5780 
  kdecore/CMakeLists.txt f78c115 
  kdecore/localization/kcatalog.cpp 1f01688 
  kdecore/tests/CMakeLists.txt 9703c7d 

Diff: http://git.reviewboard.kde.org/r/100697/diff


Testing
---

Works flawlessly on Windows, Mac OS, and Ubuntu


Thanks,

Gregory

Re: Review Request: Patch to build only kmime + kimap

[Gregory Schlomoff]

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

(Updated Feb. 21, 2011, 10:50 a.m.)


Review request for kdelibs and KDEPIM-Libraries.


Changes
---

Updating the diff to use proper identation, and to avoid duplicating 
add_subdirectory.


Summary
---

Patches to kdepimlibs to build only kimap and kmime. Please see 
https://git.reviewboard.kde.org/r/100697/ for the discussion.


Diffs (updated)
-

  CMakeLists.txt a486fc1 

Diff: http://git.reviewboard.kde.org/r/100698/diff


Testing
---


Thanks,

Gregory

Re: Review Request: Patch to build only kmime + kimap

[Gregory Schlomoff]

> On Feb. 21, 2011, 10:02 a.m., Christophe Giboudeaux wrote:
> > CMakeLists.txt, line 17
> > 
> >
> > Why do you need to explicitely set this if your target is Windows and 
> > Mac ?
> >

Because otherwise I get the following CMake error:

___
D:\kde\build\kdepimlibs>cmake -G "NMake Makefiles" 
-DCMAKE_INSTALL_PREFIX="D:/kde" -DCMAKE_PREFIX_PATH="D:/kde" 
-DCMAKE_BUILD_TYPE=Debug -DSTATIC_LIBRARY=ON -DKDE4_BUILD_TESTS=OFF 
-DKIMAP_STANDALONE=ON -DCMAKE_CXX_FLAGS="-DKIMAP_STANDALONE 
-DKDEWIN_STATIC_LIBS" -DKDEPIM_NO_KRESOURCES=ON -DKDEPIM_NO_KCAL=ON 
-DCMAKE_CXX_FLAGS="-DKDELIBS_STATIC_LIBS" "D:/kde/src/kdepimlibs"

CMake Error at C:/Program Files (x86)/CMake 
2.8/share/cmake-2.8/Modules/FindKDE4.cmake:98 (MESSAGE):
  ERROR: cmake/modules/FindKDE4Internal.cmake not found in
  
c:/users/greg/appdata/roaming/.kde-debug/share/apps;d:/kde/build/kdepimlibs/share/apps
Call Stack (most recent call first):
  CMakeLists.txt:23 (find_package)

[...]

-- Configuring incomplete, errors occurred!

D:\kde\build\kdepimlibs>


Basically, without this, CMake searches for FindKDE4Internal.cmake in the build 
folder (d:/kde/build/kdepimlibs/share/apps) instead of the kde install folder 
(d:/kde/share/apps)


> On Feb. 21, 2011, 10:02 a.m., Christophe Giboudeaux wrote:
> > CMakeLists.txt, line 74
> > 
> >
> > indentation between your if/endif

Sorry, will update diff


- Gregory


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


On Feb. 21, 2011, 8:42 a.m., Gregory Schlomoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100698/
> ---
> 
> (Updated Feb. 21, 2011, 8:42 a.m.)
> 
> 
> Review request for kdelibs and KDEPIM-Libraries.
> 
> 
> Summary
> ---
> 
> Patches to kdepimlibs to build only kimap and kmime. Please see 
> https://git.reviewboard.kde.org/r/100697/ for the discussion.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt a486fc1 
> 
> Diff: http://git.reviewboard.kde.org/r/100698/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gregory
> 
>

Re: Review Request: Patch to build only kmime + kimap

[Christophe Giboudeaux]

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



CMakeLists.txt


Why do you need to explicitely set this if your target is Windows and Mac ?




CMakeLists.txt


indentation between your if/endif



CMakeLists.txt


indentation between your if/endif



CMakeLists.txt


indentation



CMakeLists.txt


Please, don't duplicate add_subdirectory.

Use something like:

if(KIMAP_STANDALONE)
  set(build_kmime TRUE)
  set(build_kimap TRUE)
endif()




CMakeLists.txt


add this to the KDEPIM_ONLY_KLEO line just below.





CMakeLists.txt


then: endif(NOT KDEPIM_ONLY_KLEO AND NOT KIMAP_STANDALONE)



- Christophe


On Feb. 21, 2011, 8:42 a.m., Gregory Schlomoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100698/
> ---
> 
> (Updated Feb. 21, 2011, 8:42 a.m.)
> 
> 
> Review request for kdelibs and KDEPIM-Libraries.
> 
> 
> Summary
> ---
> 
> Patches to kdepimlibs to build only kimap and kmime. Please see 
> https://git.reviewboard.kde.org/r/100697/ for the discussion.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt a486fc1 
> 
> Diff: http://git.reviewboard.kde.org/r/100698/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gregory
> 
>

Re: Review Request: Patch to build only kdecore

[Gregory Schlomoff]

> On Feb. 21, 2011, 9:46 a.m., Christophe Giboudeaux wrote:
> > kdecore/localization/kcatalog.cpp, line 172
> > 
> >
> > where is this ifdef'd ?
> >

This is supposed to be defined manually when you build kdelibs. (In other 
words, we invoke cmake with the -DCMAKE_CXX_FLAGS="-DKIMAP_STANDALONE" 
command-line flag).

This is needed to avoid a useless (for our purposes) dependency on lib gettext, 
but actually, I have a feeling that this code could probably be refactored to 
avoid entirely the need for us to patch it.


> On Feb. 21, 2011, 9:46 a.m., Christophe Giboudeaux wrote:
> > CMakeLists.txt, line 68
> > 
> >
> > Please find a better name for kdelibs. The module is not supposed to 
> > know what kimap is. (eg: KDE4_ONLY_KDECORE)
> > 
> >

I agree -actually, I wasn't expecting this patch to be included for real in 
kdelibs, this is why I didn't bother finding a better name.

But I'll update the diff with the name you suggest.


- Gregory


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


On Feb. 21, 2011, 8:42 a.m., Gregory Schlomoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100697/
> ---
> 
> (Updated Feb. 21, 2011, 8:42 a.m.)
> 
> 
> Review request for kdelibs and KDEPIM-Libraries.
> 
> 
> Summary
> ---
> 
> Hello,
> 
> As some of you may know, we are using KIMAP and KMime as stand-alone 
> libraries for BetterInbox, our cross-platform email client.
> 
> Since our primary targets are Windows and Mac OS X platforms, it would be 
> quite costly to try to build and ship the whole kdelibs + kdepimlibs + 
> dependencies in order to use just kimap and kmime. So we made a few patches 
> to KDE's build scripts that enable to build only kdecore + kimap + kmime. The 
> only third-party dependencies on Windows are kdewin, boost, cyrus-sasl, and 
> zlib.
> 
> Basically, we just declare a new build option called KIMAP_STANDALONE, that 
> will skip the compilation of everything that is not needed. We are sharing 
> the patches to kdelibs in this review request. See 
> https://git.reviewboard.kde.org/r/100698/ for the patches to kdepimlibs.
> 
> Please note that the goal here is *NOT* to ask for the inclusion of those 
> patches into KDE's source code, but rather to show the community how we did 
> it, and maybe to foster some discussion around the idea of modularizing 
> kdelibs and kdepimlibs a bit more, so that this kind of hack wouldn't be 
> needed.
> 
> Any ideas / comments appreciated.
> 
> Cheers,
> 
> Greg Schlomoff
> Founder, BetterInbox
> 
> 
> Diffs
> -
> 
>   kdecore/localization/kcatalog.cpp 1f01688 
>   kdecore/CMakeLists.txt f78c115 
>   cmake/modules/FindKDE4Internal.cmake d4e5780 
>   CMakeLists.txt 87631d1 
>   kdecore/tests/CMakeLists.txt 9703c7d 
> 
> Diff: http://git.reviewboard.kde.org/r/100697/diff
> 
> 
> Testing
> ---
> 
> Works flawlessly on Windows, Mac OS, and Ubuntu
> 
> 
> Thanks,
> 
> Gregory
> 
>

Re: Review Request: Patch to build only kdecore

[Christophe Giboudeaux]

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



CMakeLists.txt


Please find a better name for kdelibs. The module is not supposed to know 
what kimap is. (eg: KDE4_ONLY_KDECORE)





kdecore/localization/kcatalog.cpp


where is this ifdef'd ?



- Christophe


On Feb. 21, 2011, 8:42 a.m., Gregory Schlomoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100697/
> ---
> 
> (Updated Feb. 21, 2011, 8:42 a.m.)
> 
> 
> Review request for kdelibs and KDEPIM-Libraries.
> 
> 
> Summary
> ---
> 
> Hello,
> 
> As some of you may know, we are using KIMAP and KMime as stand-alone 
> libraries for BetterInbox, our cross-platform email client.
> 
> Since our primary targets are Windows and Mac OS X platforms, it would be 
> quite costly to try to build and ship the whole kdelibs + kdepimlibs + 
> dependencies in order to use just kimap and kmime. So we made a few patches 
> to KDE's build scripts that enable to build only kdecore + kimap + kmime. The 
> only third-party dependencies on Windows are kdewin, boost, cyrus-sasl, and 
> zlib.
> 
> Basically, we just declare a new build option called KIMAP_STANDALONE, that 
> will skip the compilation of everything that is not needed. We are sharing 
> the patches to kdelibs in this review request. See 
> https://git.reviewboard.kde.org/r/100698/ for the patches to kdepimlibs.
> 
> Please note that the goal here is *NOT* to ask for the inclusion of those 
> patches into KDE's source code, but rather to show the community how we did 
> it, and maybe to foster some discussion around the idea of modularizing 
> kdelibs and kdepimlibs a bit more, so that this kind of hack wouldn't be 
> needed.
> 
> Any ideas / comments appreciated.
> 
> Cheers,
> 
> Greg Schlomoff
> Founder, BetterInbox
> 
> 
> Diffs
> -
> 
>   kdecore/localization/kcatalog.cpp 1f01688 
>   kdecore/CMakeLists.txt f78c115 
>   cmake/modules/FindKDE4Internal.cmake d4e5780 
>   CMakeLists.txt 87631d1 
>   kdecore/tests/CMakeLists.txt 9703c7d 
> 
> Diff: http://git.reviewboard.kde.org/r/100697/diff
> 
> 
> Testing
> ---
> 
> Works flawlessly on Windows, Mac OS, and Ubuntu
> 
> 
> Thanks,
> 
> Gregory
> 
>

Re: KShutdown got to kde-runtime without review

[Marco Martin]

On Monday 21 February 2011, Albert Astals Cid wrote:
> A Diumenge, 20 de febrer de 2011, Marco Martin va escriure:
> > On Wednesday 16 February 2011, Albert Astals Cid wrote:
> > > Why?
> > > 
> > > Albert
> > 
> > Speaking of which, what is the policy now?
> > I have in a branch of kdelibs a little library that should go into
> > experimental/ (probably staying there for 4.7)
> > 
> > now that there isn't anymore the kdereview svn repo, how this things get
> > reviewed?
> 
> We still have https://projects.kde.org/projects/kdereview but i understand
> that only works for separate repos.
> 
> > just announcing here that there is the plasma/declarative branch in
> > kdelibs that should be merged?
> 
> That'd be enough for me but it is not me that sets the rules :D

well, that one in particular could in theory still be pulled in a separate 
repository, other parts (libplasma at the moment) still don't depend from it 
but i really have to make it depend soon...
this is still quite independent, but i guess in the future there will be 
plenty of big branches that really couldn't be pulled in a separate repo

what about a wiki page that lists branches big enough that need a review?

Cheers,
Marco Martin

Re: Review Request: Implement a dialog to show unhandled Bugzilla errors

[Matthias Fuchs]

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



drkonqi/reportassistantpages_bugzilla.cpp


You have to check if the pointer is still valid there.

The reason for using QPointer or QWeakPointer in the first place is that 
the dialog could be destroyed by e.g. a dbus command IIRC --> there was a blog 
entry on how to crash nearly every KDE app which commented on that.

So it could be that it is not valid once it reaches the KUrl fileUrl = ... 
line.
The only way to check if it is valid is using QWeakPointer or QPointer and 
do KUrl fileUrl (dlg ? dlg->selectedUrl() : KUrl());

Yes I suppose in the worst case it could be deleted inbetween but that 
should not happen that often. ;)


- Matthias


On Feb. 19, 2011, 12:33 p.m., Darío Andrés Rodríguez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100681/
> ---
> 
> (Updated Feb. 19, 2011, 12:33 p.m.)
> 
> 
> Review request for KDE Runtime and George Kiagiadakis.
> 
> 
> Summary
> ---
> 
> Initial patch
> 
> I created a dialog that will show the RAW Bugzilla HTML output when the 
> response can't be parsed by DrKonqi. The user is encouraged to perform the 
> action again later or save the HTML data to submit a DrKonqi bug.
> 
> This function is available for the login and the submit (new report or attach 
> to an existant one) processes.
> BugzillaLib error message signals were enhanced to hold the raw html (if it 
> makes sense to show it)
> 
> The text on the dialog could be changed.
> 
> Additional fix: disconnect signals prior to creating a new report or 
> attaching to an existing one; avoiding duplicates dialog. (may be this should 
> go as another patch)
> 
> 
> This addresses bug 266542.
> http://bugs.kde.org/show_bug.cgi?id=266542
> 
> 
> Diffs
> -
> 
>   drkonqi/CMakeLists.txt 87c3d24 
>   drkonqi/bugzillalib.h cb7da10 
>   drkonqi/bugzillalib.cpp 348fb72 
>   drkonqi/reportassistantdialog.cpp 607dd63 
>   drkonqi/reportassistantpages_bugzilla.h 8681f22 
>   drkonqi/reportassistantpages_bugzilla.cpp e896c52 
>   drkonqi/reportinterface.h a1fc78a 
>   drkonqi/reportinterface.cpp a484d11 
> 
> Diff: http://git.reviewboard.kde.org/r/100681/diff
> 
> 
> Testing
> ---
> 
> Tested by faking some errors during the login and submit (new report) 
> processes.
> The code should be reviewed as I stop coding for KDE several months ago.
> 
> 
> Screenshots
> ---
> 
> Unhandled Error Dialog
>   http://git.reviewboard.kde.org/r/100681/s/77/
> 
> 
> Thanks,
> 
> Darío Andrés
> 
>

Review Request: Patch to build only kmime + kimap

[Gregory Schlomoff]

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

Review request for kdelibs and KDEPIM-Libraries.


Summary
---

Patches to kdepimlibs to build only kimap and kmime. Please see 
https://git.reviewboard.kde.org/r/100697/ for the discussion.


Diffs
-

  CMakeLists.txt a486fc1 

Diff: http://git.reviewboard.kde.org/r/100698/diff


Testing
---


Thanks,

Gregory

Review Request: Patch to build only kdecore

[Gregory Schlomoff]

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

Review request for kdelibs and KDEPIM-Libraries.


Summary
---

Hello,

As some of you may know, we are using KIMAP and KMime as stand-alone libraries 
for BetterInbox, our cross-platform email client.

Since our primary targets are Windows and Mac OS X platforms, it would be quite 
costly to try to build and ship the whole kdelibs + kdepimlibs + dependencies 
in order to use just kimap and kmime. So we made a few patches to KDE's build 
scripts that enable to build only kdecore + kimap + kmime. The only third-party 
dependencies on Windows are kdewin, boost, cyrus-sasl, and zlib.

Basically, we just declare a new build option called KIMAP_STANDALONE, that 
will skip the compilation of everything that is not needed. We are sharing the 
patches to kdelibs in this review request. See 
https://git.reviewboard.kde.org/r/100698/ for the patches to kdepimlibs.

Please note that the goal here is *NOT* to ask for the inclusion of those 
patches into KDE's source code, but rather to show the community how we did it, 
and maybe to foster some discussion around the idea of modularizing kdelibs and 
kdepimlibs a bit more, so that this kind of hack wouldn't be needed.

Any ideas / comments appreciated.

Cheers,

Greg Schlomoff
Founder, BetterInbox


Diffs
-

  kdecore/localization/kcatalog.cpp 1f01688 
  kdecore/CMakeLists.txt f78c115 
  cmake/modules/FindKDE4Internal.cmake d4e5780 
  CMakeLists.txt 87631d1 
  kdecore/tests/CMakeLists.txt 9703c7d 

Diff: http://git.reviewboard.kde.org/r/100697/diff


Testing
---

Works flawlessly on Windows, Mac OS, and Ubuntu


Thanks,

Gregory