Re: Review Request: konsole --nofork crashes when started not from terminal

2011-12-23 Thread Askar Safin

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

(Updated Dec. 23, 2011, 11:58 a.m.)


Review request for kdelibs.


Summary (updated)
-

konsole --nofork crashes when started not from terminal


Description
---

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


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


Diffs
-

  kdeui/kernel/kuniqueapplication.cpp 777fc35 

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


Testing
---


Thanks,

Askar Safin



Re: Review Request: konsole --nofork crashes when started not from terminal

2011-12-23 Thread Askar Safin

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

Ship it!


Ship It!

- Askar Safin


On Dec. 23, 2011, 11:58 a.m., Askar Safin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/10/
 ---
 
 (Updated Dec. 23, 2011, 11:58 a.m.)
 
 
 Review request for kdelibs.
 
 
 Description
 ---
 
 See https://bugs.kde.org/show_bug.cgi?id=288200
 
 
 This addresses bug 288200.
 http://bugs.kde.org/show_bug.cgi?id=288200
 
 
 Diffs
 -
 
   kdeui/kernel/kuniqueapplication.cpp 777fc35 
 
 Diff: http://git.reviewboard.kde.org/r/10/diff/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Askar Safin
 




Re: More devices into the Shortcut system...

2011-12-23 Thread todd rme
On Fri, Dec 23, 2011 at 12:57 AM, Albert Astals Cid aa...@kde.org wrote:
 El Dimarts, 20 de desembre de 2011, a les 21:48:30, Rick Stockton va escriure:
 It is time for us to Fish, or Cut Byte on two alternative ways to
 introduce Mouse-Oriented Shortcuts into Qt5 and KDE-Next:

 Todd RME has been suggesting a new design- oriented around DBUS.
 Unfortunately, I don't know how to do that coding. Todd, if your design
 gets a more favorable review from THIS group, within the next few days,
 I'll try to assist you in your work (as best as I can; I'm definitely
 not the brightest person here.)

 As an alternative, I'm suggesting the idea of enhancing one or two of
 the existing classes: I'd prefer to enhance the current QShortCutEvent
 and QShortCut scheme, so that they can include Mouse Button events
 within a QKeySequence. (This will including the possibility of _only_
 one or more Mouse Buttons, with no keyboard event at all.) If that
 proves difficult, I could create new Classes to do this-- but I think I
 can use the 'hasExtendedInfo' trick which one of the smart Qt guys has
 used to handle a variety of Signatures in the  QtMouseEvent() code. I
 can work with *this* stuff on my own.

 Please give opinions soon, as we have only 3-5 weeks before the Qt5 API
 goes into soft freeze. After we have Mouse Buttons done, the same design
 could be extended to handle other input devices (joystick, multitouch,
 and so on.)

 After reading this mail i feel like i don't have all the information to give
 an opinion since i did not get any pointer to learn what is the Todd RME DBUS
 design.

 Albert

Please take a look here: https://bugs.kde.org/show_bug.cgi?id=171295
Or here: 
http://neverendingo.blogspot.com/2010/11/matter-of-control-state-of-input-device.html

The short version of the idea is to extend the existing dbus-based
keyboard shortcut system to allow developers to support other devices
besides just keyboards.  Users would be able to install plug-ins that
provide button press events from other devices besides just keyboards.

The dbus service would be very simple and generic, just providing a
way to register or unregister devices and receive button press events
from the plugins.  Things like configuring devices, deciding how to
name the button presses, making sure devices of a particular type
(like multiple keyboards) don't conflict, and other such issues would
be handled by the plugins in whatever way is appropriate for the
device.

The plugins wouldn't have to be physical devices, either.  They could
be things like voice recognition (such as simon), time-based triggers,
even online signals.  If someone wants to provide shortcut events for
something, they just need to write the appropriate plugin.  Of course
none of the plugins would actually do anything unless the user
specifically associates an event with a shortcut, and button presses
would be tied to individual plugins so no plugin could steal the
shortcuts of another plugin.

The idea would be that systems like kremotecontrol, simon, even games
looking to use joysticks buttons, could all work through the same
interface, instead of needing the half-dozen or so radically different
shortcut systems and user interfaces we have now.

Initially (i.e. for frameworks 5) this could all be behind-the-scenes
changes.  Basically just create the dbus interface and port the
keyboard handler to use it.  Once that is done, support for additional
devices and changes in the gui to support them could come later.

-Todd


Review Request: Make kfmclient honor the user configured browser settings for local resources

2011-12-23 Thread Dawit Alemayehu

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

Review request for KDE Base Apps and David Faure.


Description
---

The attached patch changes kfmclient so that it

* honors the user configured browser setting when the specified URL is a local 
page that is to be handled by a browser.
* honors the user configured browser setting when the user specified url is ftp.


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


Diffs
-

  konqueror/client/kfmclient.cpp 339ba31 

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


Testing
---

Change the browser in the default application list to firefox and make sure 
all of the following commands open the URL in firefox:

* kfmclient openURL http://www.kde.org 
* kfmclient openURL /usr/share/doc/qt/html/index.html
* kfmclient openURL ftp://ftp.kde.org


Thanks,

Dawit Alemayehu