Re: need to backport patch in kinit/kinit_win.cpp to 4.6
On Wednesday 09 March 2011 21:26:26 Wolfgang Rohdewald wrote: git checkout --track origin/KDE/4.6 git cherry-pick fd16288 When cherry-picking for a back port or forward port, please use the -x option so that the original commit number is included in the message. This makes it easier to track the history and simplifies merging. Don't forget to check it compiles and run any unit tests :-) git push Cheers! John.
Re: Review Request: Dolphin details view optimization
On March 10, 2011, 12:03 a.m., Thomas Lübking wrote: dolphin/src/views/dolphinfileitemdelegate.h, line 40 http://git.reviewboard.kde.org/r/100826/diff/2/?file=10878#file10878line40 You could probably avoid the QObject inheritance and just add an ordinary function and connect the calling slot in the view... item delegates or QObjects, he just added the macro to make moc aware of it. http://doc.qt.nokia.com/latest/qabstractitemdelegate.html - Milian --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100826/#review1874 --- On March 9, 2011, 11:38 p.m., Samuel Rødal wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100826/ --- (Updated March 9, 2011, 11:38 p.m.) Review request for KDE Base Apps. Summary --- Constructing a KColorScheme object is very expensive because of a number of tint computations. When scrolling a big list more than 30 % of the time was spent here. Instead, we can precompute and store the inactive text color. Diffs - dolphin/src/views/dolphinfileitemdelegate.h 5eb559a7909a50afef8a67a8706ac3106dab38bb dolphin/src/views/dolphinfileitemdelegate.cpp 9fed95bca2a8170ddbc18239a990ce8a28528bf4 Diff: http://git.reviewboard.kde.org/r/100826/diff Testing --- Thanks, Samuel
Re: Review Request: Fix for connecting to FTP sites through HTTP proxy
On Thursday 10 March 2011 08:14:04 Dawit A wrote: On Wed, Mar 9, 2011 at 6:32 PM, Andreas Hartmetz ahartm...@gmail.com wrote: On Wednesday 09 March 2011 23:43:23 Dawit A wrote: [snipped] Yes, it is, but not for those reasons. That entry was not put there simply because we had an HTTP proxy implementation, but because FTP requests can be routed through an HTTP proxy server just like HTTP and HTTPS requests. IOW, what do you do when the user specifies a HTTP proxy server as the FTP proxy. It is legal and valid to do that. What is happening in KDE now is that functionality is not supported for some unknown reason. Do you mean CONNECT? CONNECT is implemented in TcpSlaveBase via Qt sockets. Nope. I am not saying FTP over HTTP is like HTTPS. I was only saying that just like you can obviously send HTTP requests through HTTP proxies, you can do the same with FTP requests. Yes, you can send ftp requests through an HTTP Proxy server. The request line header will look some like: GET ftp://ftp.kde.org/ HTTP/1.1. The proxy server will then speak to the FTP server on the client behalf and return the response as HTML. CONNECT is entirely unlike real HTTP proxying (see below), it's very much like SOCKS - it's application-level port forwarding and IIRC not even standardized in a real Internet standard. The HTTP ioslave only handles actual HTTP proxying, where you talk HTTP to the proxy server and the proxy returns the data as if it was the originating server. First I am aware of how the proxy stuff works because largely I am responsible for its creation. ;) Second and more seriously, SOCKS v5 is an Internet standard defined through RFC 1928. Though I have not read it, I am sure it Yeah, SOCKS is standardized, but CONNECT isn't AFAIK. I'll repeat here how it works, for the three other persons reading this :) CONNECT is a pseudo-HTTP request that you send to an HTTP proxy to make it forward a port, SOCKS-like. After the CONNECT command the proxy just forwards data to (and from) the remote server until the connection is closed, it's not really HTTP anymore. I don't see how the HTTP ioslave could help the FTP ioslave somehow unless there is some scheme in which the client talks HTTP to the proxy, which talks FTP to an FTP server, while the client still says it's FTP to the user / sets up the whole thing as described if the user requests FTP and an HTTP proxy is set. See my explanation above. HTTP ioslave does not help the FTP ioslave. The ftp request is sent to and handled by the HTTP ioslave. The FTP ioslave does not come into the equation for FTP over HTTP proxy cases at all. See the documentation on FTP support in your favorite open source http proxy server, e.g. Squid. Hm? That sounds exactly like the scenario I described. Note that I didn't mention ioslaves, just the protocols. Client talks HTTP to proxy, proxy talks FTP to FTP server. If such a scheme exists a one-off hack somewhere would be appropriate. That is exactly the wrong way to go about it for several reasons: #.1 Assumption is a mother of all f??? ups, especially when it comes to core libraries like KIO. There is no way you can guarantee that FTP over HTTP proxy is the only thing that would require such functionality to make a one off exception. That is why it was implemented the way it is in the first place. If another protocol requires a similar change which would be easier to do ? Change code to add yet another one-off hack or simply add a ProxiedBy= entry into the ioslave's protocol file ? Well okay, it makes no sense to change something that already works / only needs some fixing. However I don't know of another such constellation in which an application protocol is transported over another application protocol. #2. Why change something that does not break or mess up anything in the first place ? You do understand that removing that parameter from the protocol file only takes away the optimization that was added to speed up the discovery of whether a request with one protocol (ftp) has the potential to be handled by an ioslave of different protocol (http). Its removal does not change the fact that the scheduler will still send the ftp request to the http ioslave. That decision is made by KProtocolManager::slaveProtocol. The property entry in the protocol file was meant to actually avoid calling latter slower function unless it is necessary to do so, alas the changes in KParts::BrowserRun::scanFile. #3. If a user only has access to the Internet through a HTTP proxy, how would you suggest they access and download stuff from an ftp site ? I am sure you are not advocating that we implement HTTP proxy handling in the FTP ioslave. I was thinking of using CONNECT to talk real FTP. That doesn't seem to be the canonical way to do it, though... Since there is no input for specifying SOCKS proxy in the proxy configuration dialog, then I
Re: Future of KSysguard - removing remote monitoring
On March 8, 2011, John Tapsell wrote: Hi all, For the past 13 years or so, ksysguard has been in KDE under various names. Right from the beginning it was designed to monitor remote systems as well as local ones. John, thanks a lot for taking care of ksysguard. I consider it one of the best applications of the KDE basic workspace. I push it energetically on all sys- admins I find (and usually they're easily convinced). I believe the most important feature of ksysguard is its remote capability. I must acknowledge that I know very little of the mechanics of this feature (yet I know it is developed in-house, since at the time (long ago...), Chris Schlaeger didn't really have much choice in terms of monitoring libraries). I dare to ask you consider to not remove this feature. Perhaps your observation is rather an occasion to look at some redesign (and reuse of better (?) technologies in remote monitoring). Another aspect that tingled me for some time now is how nice ksysguard widgets would fit in plasmoids. Thanks a lot for your attention and for your great work. -- Cristian Tibirna KDE developer .. tibi...@kde.org .. http://www.kde.org signature.asc Description: This is a digitally signed message part.
Re: Future of KSysguard - removing remote monitoring
On 10 March 2011 14:43, Cristian Tibirna tibi...@kde.org wrote: On March 8, 2011, John Tapsell wrote: Hi all, For the past 13 years or so, ksysguard has been in KDE under various names. Right from the beginning it was designed to monitor remote systems as well as local ones. John, thanks a lot for taking care of ksysguard. I consider it one of the best applications of the KDE basic workspace. I push it energetically on all sys- admins I find (and usually they're easily convinced). I believe the most important feature of ksysguard is its remote capability. I must acknowledge that I know very little of the mechanics of this feature (yet I know it is developed in-house, since at the time (long ago...), Chris Schlaeger didn't really have much choice in terms of monitoring libraries). I dare to ask you consider to not remove this feature. Perhaps your observation is rather an occasion to look at some redesign (and reuse of better (?) technologies in remote monitoring). Thanks - you guys have already changed my mind :-) John
Re: Future of KSysguard - removing remote monitoring
On Thu, Mar 10, 2011 at 10:18 AM, John Tapsell johnf...@gmail.com wrote: On 10 March 2011 14:43, Cristian Tibirna tibi...@kde.org wrote: On March 8, 2011, John Tapsell wrote: Hi all, For the past 13 years or so, ksysguard has been in KDE under various names. Right from the beginning it was designed to monitor remote systems as well as local ones. John, thanks a lot for taking care of ksysguard. I consider it one of the best applications of the KDE basic workspace. I push it energetically on all sys- admins I find (and usually they're easily convinced). I believe the most important feature of ksysguard is its remote capability. I must acknowledge that I know very little of the mechanics of this feature (yet I know it is developed in-house, since at the time (long ago...), Chris Schlaeger didn't really have much choice in terms of monitoring libraries). I dare to ask you consider to not remove this feature. Perhaps your observation is rather an occasion to look at some redesign (and reuse of better (?) technologies in remote monitoring). Thanks - you guys have already changed my mind :-) John It is good it is not going to be removed, but it does sound like there are problems with the protocol being used that makes the program difficult to develop. Could that situation be improved without removing the functionality? -Todd
Re: Top 15 Mailinglists with messages in moderation
On March 1, 2011, Tom Albers wrote: Hi, New month, new list: Moderation queue top list: I keep empty the moderation queue on the kde-print and kde-print-devel lists but, as I already stated on this list, those aren't active anymore. The kde- print-devel is the primary e-mail for the bugzilla products related to printing, but even those bugzilla products are useless nowadays. Yes, it is a sad state of affairs, and I'm fully responsible, but it is now time to clean this up. Thanks a lot for your attention. -- Cristian Tibirna KDE developer .. tibi...@kde.org .. http://www.kde.org
FYI: Jamaica down this Saturday
Hi, jamaica (which hosts www.kde.org and a dozen more sites, not dot.kde.org, forum.kde.org or planet) will be without power between 10:00 and 17:00 CET this Saturday. The sysadmins there say they will be replacing a UPS, another source says they will move the datacenter. In any case I guess the server won't be reachable. I will try to move www.kde.org to another box, but it is uncertain we will manage to do this in time. This could also cause an occasional longer delay in DNS resolving. Best, -- Tom Albers KDE Sysadmin
Re: Top 15 Mailinglists with messages in moderation
On Thursday 10 March 2011 16:11:15 Tom Albers wrote: - Original Message - On March 1, 2011, Tom Albers wrote: Hi, New month, new list: Moderation queue top list: I keep empty the moderation queue on the kde-print and kde-print-devel lists but, as I already stated on this list, those aren't active anymore. The kde- print-devel is the primary e-mail for the bugzilla products related to printing, but even those bugzilla products are useless nowadays. Yes, it is a sad state of affairs, and I'm fully responsible, but it is now time to clean this up. Ok, just to be clear: You want me to remove those two mailinglists and let the bugreports go to dev/null, a similar construction as several other products in bugzilla? Hi, I've offered previously to mod those lists, I'd be happy to take them on now. I think I also previously said we can get rid of the kde-print list, it's had about 5 mails in the 18 months so I don't think it will be missed. I'd rather keep the devel list going for bug triage, and I will have news about possible new development work on printing in the near future for which the list may be useful. Cheers! John.
Re: Review Request: Dolphin details view optimization
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100826/#review1874 --- dolphin/src/views/dolphinfileitemdelegate.h http://git.reviewboard.kde.org/r/100826/#comment1528 You could probably avoid the QObject inheritance and just add an ordinary function and connect the calling slot in the view... - Thomas On March 9, 2011, 11:38 p.m., Samuel Rødal wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100826/ --- (Updated March 9, 2011, 11:38 p.m.) Review request for KDE Base Apps. Summary --- Constructing a KColorScheme object is very expensive because of a number of tint computations. When scrolling a big list more than 30 % of the time was spent here. Instead, we can precompute and store the inactive text color. Diffs - dolphin/src/views/dolphinfileitemdelegate.h 5eb559a7909a50afef8a67a8706ac3106dab38bb dolphin/src/views/dolphinfileitemdelegate.cpp 9fed95bca2a8170ddbc18239a990ce8a28528bf4 Diff: http://git.reviewboard.kde.org/r/100826/diff Testing --- Thanks, Samuel
Re: Future of KSysguard - removing remote monitoring
On 9 Mar 2011, at 7:54 AM, John Tapsell wrote: Thanks for the feedback - this is why I put out such emails before I make any changes. It's good to know that people actually use this app - sometimes it's hard to know if anyone actually uses it. I'll hold off on any rash changes for now. Thanks! John Has ksysguard (at least the front-end) been ported to Mac OS X? This would save me a lot of time in having to invest time and effort in creating a web-monitoring system for a few sites I do admin stuff for If not, what is preventing it from working on that platform (if any), and would you welcome any help for getting it completed?
Re: Future of KSysguard - removing remote monitoring
On 9 March 2011 16:05, Gary Greene gree...@tolharadys.net wrote: On 9 Mar 2011, at 7:54 AM, John Tapsell wrote: Thanks for the feedback - this is why I put out such emails before I make any changes. It's good to know that people actually use this app - sometimes it's hard to know if anyone actually uses it. I'll hold off on any rash changes for now. Thanks! John Has ksysguard (at least the front-end) been ported to Mac OS X? This would save me a lot of time in having to invest time and effort in creating a web-monitoring system for a few sites I do admin stuff for If not, what is preventing it from working on that platform (if any), and would you welcome any help for getting it completed? It hasn't been ported afaik, but it works on BSD and solaris etc, so I don't think porting it would be a huge deal. You could probably just try compiling it and sending me any fixes that are needed. John
