gmane.comp.kde.devel.core

Re: Review Request: Do not restore previously empty location bar URL

Dawit Alemayehu — 2012-05-24T16:34:40



I do not have a problem with doing that especially since pressing ESC while in the location bar will automatically restore the URL of the current content. Do you want me to completely remove the setLocationBarURL call then ?


- Dawit


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


On May 18, 2012, 7:54 a.m., Dawit Alemayehu wrote:

Re: QtScript considered dangerous

Martin Sandsmark — 2012-05-24T10:30:00

If you could come up with some such examples, maybe we could fix them. :-)

Also, KJS has been under active development the whole time, so there is a
probability that the problems you were experiencing have already been fixed.



But this is something we can fix in KJS, both since it is actively
maintained, and it is developed together with Kate.

I'm not saying I can guarantee that there won't be any regressions or
incompatibilities, but I think the gain (not crashing in a huge codebase out
of our reach) outweighs the possible, but fixable, regressions.



And because it has active developers who you can talk to.



Let's start small, and dream big? :-)

Re: QtScript considered dangerous

Martin Sandsmark — 2012-05-24T10:19:28

But KJS is maintained and has actual developers you can talk with (even on
IRC!). Failing that, it is developed together with the rest of KDE, so you
can even fix the bugs yourself instead of having to rely on third-parties.

Re: Review Request: Apper on kdereview

Matthias Klumpp — 2012-05-24T15:07:20

Hi!
< at >Albert: Isn't this the line?
https://projects.kde.org/projects/kdereview/apper/repository/revisions/master/entry/AppSetup/main.cpp#L44
(please tell me if there's something wrong ^^)

< at >Burkhard: The files have been moved - but I think I copied the
location scheme from another project, so this issue might affect other
projects too. (but I'm not completely sure... everything I've checked
so far is sane)

So this is done :) Please tell us if there's anything left to do! ;-)
Regards,
    Matthias

2012/5/23 Burkhard Lück <lueck< at >hube-lueck.de>:

Re: QtScript considered dangerous

David Faure — 2012-05-24T10:57:14

What about the solution of updating the JSC in QtScript, and submitting that 
on codereview.qt-project.org?

I.e. actually treating Qt like an opensource project and contributing the fix 
upstream?

The fact that no Qt developer will do it himself, doesn't mean they are 
opposed to it, if someone contributes the patch, does it?

Re: Review Request: Plasma::RunnerManager: only dequeue our ThreadWeaver jobs

Aurélien Gâteau — 2012-05-24T09:50:56

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

(Updated May 24, 2012, 9:50 a.m.)


Review request for kdelibs and Plasma.


Changes
-------

Subscribing Plasma as there are probably more people working on this class there.


Description
-------

When RunnerManager::reset() is called, all ThreadWeaver jobs are dequeued, including jobs from other parts of the code. This patch changes this to only dequeue the jobs created by this instance of RunnerManager.


Diffs
-----

  plasma/runnermanager.cpp 49569a3 

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


Testing
-------

I have more than one RunnerManager working at once in a project. Without the patch, only one manager return results.


Thanks,

Aurélien Gâteau

Re: Re: QtScript considered dangerous

Martin Gräßlin — 2012-05-24T09:44:25

I want to remind that today is beta tagging for 4.9 and we are already in 
feature and dependency freeze.

No matter how we turn it: switching the scripting engine cannot count as a 
bugfix and might cause quite some regressions.

As a result the earliest point in time to make that happen is 4.10 to be 
released in January 2013. I'm not sure whether this makes the proposed 
solution to the bugs the best one.

At the time of 4.10 Qt 5 will have had a release and hopefully also KF5. To me 
it would look like a much more sane step to get Kate ported to Qt/KF 5 instead 
of going for a port away from QtScript.

Just my 2 cents

Cheers
Martin

Re: QtScript considered dangerous

Thomas Friedrichsmeier — 2012-05-24T09:28:41

Re: QtScript considered dangerous

Dominik Haumann — 2012-05-24T08:59:21

Hi Milian,

CC: kde-core-devel, as this is really a tough issue...

there are other applications like Kile that heavily use QtScript for scripting 
as well, so porting away KatePart from QtScript may solve the issue for 
KDevelop, the real problem lies (as you say) within QtScript, not Kate. The 
reason for why we use QtScript are:
- QtScript is very (!) easy to use
- QtScript is maintained (at least at that time?)
- really good documentation

There are other arguments, why we finally ended up with QtScript:
- kjs is pretty much undocumented, meaning that it's not immediately clear
  e.g. how to export custom classes and so on.
- at the time we dropped kjs, it wasn't clear whether it's going to be
  maintained and improved (the speed in QtScript was much better). At that
  time, there were even lots of people shouting "drop khtml" etc...

Initially, KatePart even used kjs and the code was a lot more complex to get 
the same thing as we have now with QtScript. That alone is a strong argument 
for using QtScript.

With regard to Kate, we are about to export our js-API so that other classes 
can use our returned QScriptValues. Once this is the case, we cannot go back 
due to BIC reasons. So this is a tough issue... We can go back to using kjs 
again, of course, but then, I still have lots of questions [1] :-)

What about other solutions: Reduce memory consumption in KDevelop?
Another question is: Maybe we'll have similar/other issues with kjs? ;)

Greetings,
Dominik

[1] http://kate-editor.org/2012/05/12/rfc-exporting-javascript-api/

On Wednesday, May 23, 2012 22:08:08 Milian Wolff wrote:

Re: Review Request: Add Configure Desktop Search button (to open Nepomuk KCM) into Nepomukcontroller Statuswidget

Kai Uwe Broulik — 2012-05-23T15:25:03

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

(Updated May 23, 2012, 3:25 p.m.)


Review request for KDE Runtime and Nepomuk.


Changes
-------

Finally came to update (well, rewrite it from scratch) my patch.
It now watches on DBus whether the KCM is already opened (randr does the same thing to determin whether it should show that "Monitor connected" dialog) and hides the Configure button in case.


Description
-------

This little patch adds a "Configure Desktop Search" button to the nepomukcontroller statuswidget (the little status dialog that appears if you left-click on the nepomuk tray icon).
I know that you can access strigi configuration via the tray icon's context menu but I often found myself opening the status dialog and then wanting to get to the config dialog from there. Can't harm, can it? :)

I also added a pause/resume icon to the suspend/resume button.


Diffs (updated)
-----

  nepomuk/kcm/statuswidget.h b7af01e 
  nepomuk/kcm/statuswidget.cpp a9ece31 
  nepomuk/kcm/statuswidget.ui ab210c8 

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


Testing
-------


Thanks,

Kai Uwe Broulik

Re: KDE mailing lists - a few questions

Sebastian Kügler — 2012-05-23T21:30:39

Might differ per person, every request for a moderation (even if it's just one 
lick) causes work, and if necessary, I'd like to avoid it. With mailinglist, 
those "small tasks" can pile up quite quickly.


With that I mean that putting a mailinglist on the list to make things more 
transparant, only for users to find out that they can't join it is worse than 
not having the mailinglist listed.

In fact, only listing mailinglists with outside relevance makes it much easier 
to find and pick the right one, as the list to sift through is much shorter 
and less ambivalent. (Yes, I've explained many people that kde-promo is just 
fine instead of kde-ev-marketing. Did it make anyone feel better? I doubt it. 
Can it be easily avoided? Absolutely.)

Have a nice evening,

Re: Review Request: Apper on kdereview

Burkhard Lück — 2012-05-23T20:26:15

Am Montag, 21. Mai 2012, 23:31:25 schrieb Daniel Nicoletti:
Apper has two man pages, the first is in /Apper, the second is in /AppSetup.

Both are not processed by the i18n tool chain aka scripty, but of course 
should be translated.

With the splitted git repos it is already hard enough for i18n + doc team to 
catch up with documentation locations, but with non predictable directories 
like in apper that would be a nightmare.

Therefore please move both man pages to a new toplevel directory doc as in all 
other git/svn repos. 

Thanks.

Re: Review Request: Apper on kdereview

Albert Astals Cid — 2012-05-23T17:01:25

El Dimecres, 23 de maig de 2012, a les 13:58:27, Matthias Klumpp va escriure:

I can't find where the apper catalog loaded in AppSetup, can you point me to 
it?

Cheers,
  Albert

escriure:

Re: KDE mailing lists - a few questions

Myriam Schweingruber — 2012-05-23T15:39:52

I am a moderator for several mailing lists, some of these for the fsfe
and those have most likely an equal amount of spam traffic than KDE
lists. Worse even for the 3  mailing lists I moderate in the *ubuntu
space, it sometimes peaks at 30 spam messages a day for one of them,
but it is easily handled with listadmin and quite fast, so not
something I consider "much overhead". Part of the morning routine with
a cup of coffee :)

"A false sense of transparency" - I don't see what you mean by that,
there already are mailing lists with private archives in the listinfo
and I don't see how that would cause people to try to obscure things.
But maybe I misunderstand what you mean

Yes, that was definitely also part of the plan, thanks for the
information about the ones that can be removed.


Regards, Myriam

Re: KDE mailing lists - a few questions

Sebastian Kügler — 2012-05-23T14:52:26

I think with respect to that, much of it is probably idle conspiracy theorism, 
don't pay too much attention to it. It's usual the less useful people who find 
the time to complain about that. (Makes me wonder about their agendas, but in 
fact -- not really.)

Mailinglist which aren't meant for public consumption are not very useful in 
the list info, that only attracts spammers, adds a lot of overhead for the 
moderators, and doesn't add anything other than some false sense of 
transparency (realistically, it achieves the opposite).

I understood your email as attempt to sort out the mailinglist "mess" (is 
it?), but I'll happily shut up.

Cheers,

Re: Review Request: Fix for SSL handeshake failure in TcpSlaveBase due to server not supporting SSL compression

Dawit Alemayehu — 2012-05-23T14:01:11

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

(Updated May 23, 2012, 2:01 p.m.)


Review request for kdelibs and Thiago Macieira.


Changes
-------

Updated testing done and dependency.


Description (updated)
-------

The attached patch addresses the issue of SSL handshake failure in TcpSlaveBase due to lack of support for disabling SSL compression in Qt. As of 4.8, Qt supports this functionality so this patch implements support for activing that support in KTcpSocket and using it from KIO::TcpSlaveBase so that users will be able to browse SSL protected sites that do not support SSL compression.

Note that this review request requires https://git.reviewboard.kde.org/r/104958/. 


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


Diffs
-----

  kio/kio/tcpslavebase.h fea2c08 
  kio/kio/tcpslavebase.cpp d0f92b4 

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


Testing (updated)
-------

Visit the links below before and after the patch:

https://tim.rz.rwth-aachen.de/mail-lifecycle/
http://www.suse.com/company/careers/ and click on "Apply Now"


Thanks,

Dawit Alemayehu

Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror

Dawit Alemayehu — 2012-05-23T13:53:34



Yes, I tested it too and it worked from me as well. I did not commit the change because the option is really only useful in 4.9.0 so I was waiting until 4.8.4 is tagged and released at the end of this month.


- Dawit


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


On April 26, 2012, 3:48 a.m., Dawit Alemayehu wrote:

Re: Review Request: Plasma::RunnerManager: only dequeue our ThreadWeaver jobs

Aurélien Gâteau — 2012-05-23T13:16:38



There is no test at the moment for the RunnerManager class. Docs does not need to be updated: it's a bug fix, not a behavior change.


- Aurélien


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


On May 17, 2012, 1:18 p.m., Aurélien Gâteau wrote:

Re: Review Request: Plasma::RunnerManager: only dequeue our ThreadWeaver jobs

Albert Astals Cid — 2012-05-23T13:06:46

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


Does this have unit tests? Would make sense to add a new one forcing this behaviour? What about docs? Should any doc be fixed/improved mentioning the behaviour?

- Albert Astals Cid


On May 17, 2012, 1:18 p.m., Aurélien Gâteau wrote:

Re: Review Request: Plasma::RunnerManager: only dequeue our ThreadWeaver jobs

Aurélien Gâteau — 2012-05-23T13:01:08

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


Looks like this request does not trigger much passion. Unless someone objects, I am going to commit it tomorrow.

- Aurélien Gâteau


On May 17, 2012, 1:18 p.m., Aurélien Gâteau wrote:

Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror

David Faure — 2012-05-23T12:43:59



KHTML patch tested, it works.


- David


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


On April 26, 2012, 3:48 a.m., Dawit Alemayehu wrote: