Re: Klipper

2011-05-31 Thread Esben Mose Hansen

On 2011-05-16 18:35, todd rme wrote:


Would that make klipper a potential target for the upcoming
modularization efforts, then?


As a pseudo-sometime maintainer of Klipper, I have thought about this 
extensively. So this is my take on it.


Klipper should be modularized like this:

1. The core bit:
1.a. This bit should listen to clipboard changes, and notify interested 
clients about changes as they occur.
1.b. It should also handle at least basic clipboard retention (that is, 
plain text, html, and QT-supported image formats).


2. The history bit.
This should be a client. It should be able to store the history. It 
would be best if the selection is only recorded if it is plain text, 
with the option of being completely ignored. It could also handle the 
edit clipboard feature.


3. The action bit. This feature is surprisingly popular, but I still 
find it a bit bells-and-whistles sort of thing. For those who don't know 
what it is, it is a listener that looks at the clipboard contents and if 
it matches certain patterns (e.g., looks like an URL, matches a file on 
disk etc), pops up a passive popup with some options for handling it, 
say opening the file in okular or whatever).



Now, since we are discussing this, I can put my question to the crowd: 
Does this sound like a dataengine with two plasmoids to you? Or should 
it be a service that communicates over dbus? Or is it just a bad idea.


Note that if it is converted to a dataengine/plasmoid, the Gnome users 
we have will hate us.


--
kind regards,
Esben Mose Hansen


Re: Klipper

2011-05-31 Thread Lubos Lunak
On Tuesday 31 of May 2011, Esben Mose Hansen wrote:
 On 2011-05-16 18:35, todd rme wrote:
  Would that make klipper a potential target for the upcoming
  modularization efforts, then?

 As a pseudo-sometime maintainer of Klipper, I have thought about this
 extensively. So this is my take on it.

 Klipper should be modularized like this:

 1. The core bit:
 1.a. This bit should listen to clipboard changes, and notify interested
 clients about changes as they occur.

 Why would they need it instead of QClipboard::changed() ?

 1.b. It should also handle at least basic clipboard retention (that is,
 plain text, html, and QT-supported image formats).

 Note that it doesn't really depend on whether Qt supports the format or not, 
QClipboard::mimeData() can provide the complete clipboard contents in all 
formats, whether known or not. The problem is rather the question what 
formats to store (more than one usually means duplication of the underlying 
data and there's no generic way to tell which format is the best, 
additionally actually creating the data in any format may possibly take some 
time).

 2. The history bit.
 This should be a client. It should be able to store the history. It
 would be best if the selection is only recorded if it is plain text,
 with the option of being completely ignored.

 This could be
- a race condition (depending on how the retrieving of content for history 
saving is done)
- slow (keep in mind that people occassionally put huge data into clipboard)

 It could also handle the edit clipboard feature.

 I can see the reason why this could be outside of the core, or why the 
history showing could be, but the saving itself IMO fits much better in core.

 3. The action bit. This feature is surprisingly popular, but I still
 find it a bit bells-and-whistles sort of thing. For those who don't know
 what it is, it is a listener that looks at the clipboard contents and if
 it matches certain patterns (e.g., looks like an URL, matches a file on
 disk etc), pops up a passive popup with some options for handling it,
 say opening the file in okular or whatever).


 Now, since we are discussing this, I can put my question to the crowd:
 Does this sound like a dataengine with two plasmoids to you?

 It sounds a bit like over-engineering to me.

 Or should it be a service that communicates over dbus? Or is it just a bad
 idea. 

 Given what's said above, I myself would try to keep all the data handling to 
the core, as much as possible. The UI, if separate, could just forward 
commands to the core or ask only for contents it actually needs to show.

 That said, history has shown that having clipboard polling in an important 
process can occassionally break things in ugly ways, so trying to move the 
core to KDED (or Plasma, if somebody really thinks that's a good idea) should 
be something to think about twice. And if it already needs a separate 
process, what is the gain of the UI separation (this is not a rhetoric 
question)?

 Note that if it is converted to a dataengine/plasmoid, the Gnome users
 we have will hate us.

 The only UI from Klipper I care to see are the history and action popups, so 
if this meant I'd need to have a plasmoid somewhere just to remind me that a 
a functionality I consider core exists, then count me in.

-- 
 Lubos Lunak
 l.lu...@suse.cz


Review Request: PATCH: Honor size and coordinates when creating new Konqueror windows

2011-05-31 Thread Dawit Alemayehu

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

Review request for KDE Base Apps and David Faure.


Summary
---

Currently new window creation in KonqMainWindow::slotCreateNewWindow does not 
honor the supplied cooridnate and size information under certain circumstances. 
For example, if you click on a javascript link that opens a new window, then 
the new window will always be maximized, regardless of the size information 
supplied by the javascript window.open call, as long as the Konqueror window 
where you clicked on the link is also maximized. Even when the original window 
is not maximized, if you maximize and close the newly created window, then 
clicking on the javscript window.open link again will result in a maximized 
window.

The attached patch addresses all of the above issues by making sure the 
coordinate and size information are always honored during new window creation.


Diffs
-

  konqueror/src/konqmainwindow.cpp 56aa379 

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


Testing
---


Thanks,

Dawit



Re: Review Request: make the add search engine window right aligned to the search bar

2011-05-31 Thread Commit Hook

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


This review has been submitted with commit 
658bff15e373602425fa5bd0909e6e837fa2bffc by Burkhard Lück.

- Commit


On May 30, 2011, 8:26 p.m., Burkhard Lück wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/101475/
 ---
 
 (Updated May 30, 2011, 8:26 p.m.)
 
 
 Review request for KDE Base Apps, Dawit Alemayehu and David Faure.
 
 
 Summary
 ---
 
 Currently the add search engine window is left aligned to the left side of 
 the search bar. E. g. using locales with long translations of the window 
 title Set URI Shortcuts (or other strings in the window) like eg fr part of 
 the window to add the search engine is outside the screen, because the 
 translated string is longer than the search bar. 
 The patch makes the window right aligned at the end of the search bar, than 
 no matter how long the translated string is the whole window will be always 
 inside konquerors main window.
 
 Screenshot in locale fr before the patch showing the bug: 
 http://bugsfiles.kde.org/attachment.cgi?id=52424
 
 Screenshot in locale fr with the patch (one with / one without throbber): 
 http://bugsfiles.kde.org/attachment.cgi?id=60484
 
 
 This addresses bug 253879.
 http://bugs.kde.org/show_bug.cgi?id=253879
 
 
 Diffs
 -
 
   konq-plugins/searchbar/searchbar.cpp c7aa301 
 
 Diff: http://git.reviewboard.kde.org/r/101475/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Burkhard
 




Re: Klipper

2011-05-31 Thread Aaron J. Seigo
On Tuesday, May 31, 2011 19:38:20 Lubos Lunak wrote:
 separate process, what is the gain of the UI separation (this is not a
 rhetoric question)?

so that we can easily change the UI, have multiple UIs, combine it with other 
features in future .. all without touching the business logic code, which is 
often the parts that are the most tricky, easiest to share and need to change 
the least over time.
 
  Note that if it is converted to a dataengine/plasmoid, the Gnome users
  we have will hate us.
 
  The only UI from Klipper I care to see are the history and action popups,
 so if this meant I'd need to have a plasmoid somewhere just to remind me
 that a a functionality I consider core exists, then count me in.

as opposed to an icon in the system tray? because plasmoids can (and do) live 
there too. (battery, network, etc)

rather, if you're trying to avoid running a plasma shell (plasma-desktop, 
etc), that's not particularly the use case we're developing for. 

however, with core/UI separation, you could easily write an alternative UI 
without much effort.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.


regarding kde's plugin mechanism

2011-05-31 Thread tushar mehta
Do we have any document or reference for understanding kde's plugin
mechanism?
I need to understand how custom transferfactory and custom transfer-objects
(derived
from the transfer-class) related to each plugin works.

any sample code, text anything will be helpful for me.

thank you.


Re: regarding kde's plugin mechanism

2011-05-31 Thread Aaron J. Seigo
On Tuesday, May 31, 2011 19:31:19 tushar mehta wrote:
 Do we have any document or reference for understanding kde's plugin
 mechanism?

what aspect of the plugin system are you curious about? 

there is api documentation and i believe some tutorials on techbase. but if 
you have slightly more specific questions, we can probably offer specific 
answers on the list too :)

 I need to understand how custom transferfactory and custom transfer-objects
 (derived from the transfer-class) related to each plugin works.

where is this code?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.


Re: Review Request: Add Activity Awareness to KFilePlaces* Widget (OnlyInActivity)

2011-05-31 Thread Kevin Ottens

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


Note that I can't really comment on the activities specific parts, Ivan would 
probably be a better reviewer for that parts. Anyway I found a couple of 
smaller issues which need fixing.


kfile/kfileplacesmodel.cpp
http://git.reviewboard.kde.org/r/101348/#comment3019

Please fix the indentation of this line.

Also why not providing q as parent for the activity consumer so that the 
delete in the dtor isn't needed anymore.



kfile/kfileplacesmodel.cpp
http://git.reviewboard.kde.org/r/101348/#comment3020

Please remove the extra space after *.


- Kevin


On May 13, 2011, 2:30 a.m., Jeffery MacEachern wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/101348/
 ---
 
 (Updated May 13, 2011, 2:30 a.m.)
 
 
 Review request for kdelibs, Kevin Ottens and David Faure.
 
 
 Summary
 ---
 
 Adds an Only show in this Activity option to the KFilePlaces Widget and 
 support in the underlying model code. Currently only one activity/all 
 activities are supported as choices; I think this should be sufficient, and 
 anything more complicated would be hard to make usable.
 
 
 Diffs
 -
 
   kfile/CMakeLists.txt ceae140 
   kfile/kfileplaceeditdialog.h d5b030a 
   kfile/kfileplaceeditdialog.cpp d798b4d 
   kfile/kfileplacesmodel.h b3dd821 
   kfile/kfileplacesmodel.cpp b037084 
   kfile/kfileplacesview.cpp 6a343b3 
 
 Diff: http://git.reviewboard.kde.org/r/101348/diff
 
 
 Testing
 ---
 
 Tested on Project Neon/Kubuntu Natty. Created several activities, added Place 
 bookmarks, set them to only show in the current activity, and switched 
 activities. Everything worked as intended. EDIT: one small known issue - the 
 OnlyInActivity setting doesn't take when the bookmark is first created; you 
 have to hit Edit and re-check the box.
 
 
 Thanks,
 
 Jeffery
 




Re: Review Request: Disallows renaming to names containing '/' names being equal to . or ...

2011-05-31 Thread Commit Hook

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


This review has been submitted with commit 
d034afc892e21a0b8fd9147f1914d6b356413e10 by Matthias Fuchs.

- Commit


On May 27, 2011, 11:07 p.m., Matthias Fuchs wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/101454/
 ---
 
 (Updated May 27, 2011, 11:07 p.m.)
 
 
 Review request for KDE Base Apps and Peter Penz.
 
 
 Summary
 ---
 
 So far this works only for the RenameDialog as I could not find the method 
 that changes the name when inline renaming is enabled.
 If you could tell me where that method is I would in fact adapt the patch.
 
 
 This addresses bug 211751.
 http://bugs.kde.org/show_bug.cgi?id=211751
 
 
 Diffs
 -
 
   dolphin/src/views/renamedialog.cpp 810562a 
 
 Diff: http://git.reviewboard.kde.org/r/101454/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Matthias
 




Re: Review Request: Disallows renaming to names containing '/' names being equal to . or ...

2011-05-31 Thread Commit Hook

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


This review has been submitted with commit 
680b8f918900b2b8b99fe5046806ca1b032867e3 by Matthias Fuchs.

- Commit


On May 27, 2011, 11:07 p.m., Matthias Fuchs wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/101454/
 ---
 
 (Updated May 27, 2011, 11:07 p.m.)
 
 
 Review request for KDE Base Apps and Peter Penz.
 
 
 Summary
 ---
 
 So far this works only for the RenameDialog as I could not find the method 
 that changes the name when inline renaming is enabled.
 If you could tell me where that method is I would in fact adapt the patch.
 
 
 This addresses bug 211751.
 http://bugs.kde.org/show_bug.cgi?id=211751
 
 
 Diffs
 -
 
   dolphin/src/views/renamedialog.cpp 810562a 
 
 Diff: http://git.reviewboard.kde.org/r/101454/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Matthias
 




Re: Review Request: Disallow names of files containing '/' or being equal to . or ...

2011-05-31 Thread Commit Hook

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


This review has been submitted with commit 
def6e86db16246e12660d6ba66f607a9ea6d9a58 by Matthias Fuchs.

- Commit


On May 28, 2011, 6:26 p.m., Matthias Fuchs wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/101456/
 ---
 
 (Updated May 28, 2011, 6:26 p.m.)
 
 
 Review request for kdelibs and David Faure.
 
 
 Summary
 ---
 
 nt
 
 
 This addresses bug 211751.
 http://bugs.kde.org/show_bug.cgi?id=211751
 
 
 Diffs
 -
 
   kio/kio/kdirmodel.cpp 6bf57be 
   kio/kio/kfileitemdelegate.cpp cb3939d 
 
 Diff: http://git.reviewboard.kde.org/r/101456/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Matthias
 




Re: Review Request: Disallow names of files containing '/' or being equal to . or ...

2011-05-31 Thread Commit Hook

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


This review has been submitted with commit 
465ec0c76958657cdb75616f87d4e160f8615bcb by Matthias Fuchs.

- Commit


On May 28, 2011, 6:26 p.m., Matthias Fuchs wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/101456/
 ---
 
 (Updated May 28, 2011, 6:26 p.m.)
 
 
 Review request for kdelibs and David Faure.
 
 
 Summary
 ---
 
 nt
 
 
 This addresses bug 211751.
 http://bugs.kde.org/show_bug.cgi?id=211751
 
 
 Diffs
 -
 
   kio/kio/kdirmodel.cpp 6bf57be 
   kio/kio/kfileitemdelegate.cpp cb3939d 
 
 Diff: http://git.reviewboard.kde.org/r/101456/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Matthias
 




Re: QComboBox vs KConfigDialogManager

2011-05-31 Thread Aaron J. Seigo
On Tuesday, May 31, 2011 21:55:59 Jeremy Whiting wrote:
 1) Check if the widget has a kcfg_property is set on the widget.  If so, use
 that property's value as the property to record.
 2) Check if the widget has a User property to save (This was not set in
 QComboBox in 4.7 but is set in 4.8 to the currentIndex property)
 3) Try casting to a combobox and use the current text if the combobox is
 editable, otherwise use the currentIndex
 
 Anyone here can guess where the problem lies? 

erf!

 a) change all our .ui files KComboBox, QComboBox widgets to have
 kcfg_property set if we want to save the currentText as the value of the
 config item.

this doesn't sound like a great solution since it means not only a lot of work 
and testing in our own repos (with a high risk of missing something), but it 
will affect all third parties as well (which we can't guarantee will notice or 
provide a fix on their own). a fix, even if it is a (well documented with 
comments ;) work-around, in KConfigDialogManager would probably be more 
valuable as a result.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.