Re: Proposal to use QIcon in APIs in KF5.
Hi, Lets center in the technical aspects... We should assume that Qt5 will have some kind of global icon cache, valid for every Qt application run in one machine, like KIcon has now. Am I Right? Then, without removing KIcon, it could be a thin layer (~1Kb) over QIcon. Why do not call QIcon::fromTheme() in KIcon constructors, and then nothing changes in the KDE land. in fact, for qt5 we defined source compatible to mean porting can be fully automated. By the way, if source compatible means porting can be fully automated (I guess like in Python 2 to 3), you (Qt and KDE frameworks) MUST provide such a porting tool. Best Regards.
Re: Proposal to use QIcon in APIs in KF5.
On Thu, Sep 8, 2011 at 9:17 AM, Jaime jtam...@gmail.com wrote: Hi, Lets center in the technical aspects... We should assume that Qt5 will have some kind of global icon cache, valid for every Qt application run in one machine, like KIcon has now. Am I Right? Then, without removing KIcon, it could be a thin layer (~1Kb) over QIcon. Why do not call QIcon::fromTheme() in KIcon constructors, and then nothing changes in the KDE land. in fact, for qt5 we defined source compatible to mean porting can be fully automated. By the way, if source compatible means porting can be fully automated (I guess like in Python 2 to 3), you (Qt and KDE frameworks) MUST provide such a porting tool. Best Regards. So it seems to me there are two sides to this: 1. We want to be as attractive as possible to as developers. Currently the monlithic nature and duplicates of some Qt functionality serve as barriers to use of KDE libraries. 2. We do not want to hurt or drive away existing developers. Major, required changes to the API will hurt and possible drive away existing developers. People saying that the QIcon/KIcon duplicate is detrimental seem to me to be making a compelling argument. However, I would say the same of people presenting real numbers regarding how massive the task of porting KIcon to QIcon would be. Several people have proposed moving to a separate module classes that are needed for existing applications but pose a problem for new developers, are no longer needed, or clutter the API. From what they are saying, this seems to ease the porting efforts since KIcon will not have to be changed to QIcon for any existing software, while freeing the rest of the frameworks from dependence on this class and making to clear to developers the QIcon should be used for any new software. This, from my reading, does NOT involve deprecating any of the classes placed in the module, they will continue to be supported. Does this proposal satisfy everyone's needs sufficiently? Will this pose a major barrier to porting? Will this pose any problems or barriers to the overall move to frameworks? -Todd
Re: Proposal to use QIcon in APIs in KF5.
On Thursday, September 08, 2011 09:17:00 Jaime wrote: We should assume that Qt5 will have some kind of global icon cache, valid for every Qt application run in one machine, like KIcon has now. Am I Right? Per application, it seems. That's probably still a bit behind KIcon's KSharedDataCache (which works across processes), but I don't really know the details here. Then, without removing KIcon, it could be a thin layer (~1Kb) over QIcon. Why do not call QIcon::fromTheme() in KIcon constructors, and then nothing changes in the KDE land. I think that's the idea of kde4support. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Cursor Theme Settings
On Wednesday, September 07, 2011 19:04:39 Steven Sroka wrote: On 7 September 2011 12:49, Steven Sroka sroka.ste...@gmail.com wrote: On 7 September 2011 11:22, Sebastian Kügler se...@kde.org wrote: On Wednesday, September 07, 2011 17:08:36 Steven Sroka wrote: Where are the cursor theme settings saved in KDE as well as the wallpaper slideshow settings? kcminputrc and plasma-desktop-appletsrc. For the slideshow settings, I only found plasma-desktoprc which doesn't contain the time settings. Could it be listed elsewhere? Wallpapers are per containment, and those settings are in plasma-desktop- appletsrc. Not sure why you don't have this file, maybe you didn't change any of its setup? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Proposal to use QIcon in APIs in KF5.
On Thursday, September 8, 2011 09:36:41 todd rme wrote: Several people have proposed moving to a separate module classes that are needed for existing applications but pose a problem for new developers, are no longer needed, or clutter the API. From what they are saying, this seems to ease the porting efforts since KIcon will not have to be changed to QIcon for any existing software, while freeing the rest of the frameworks from dependence on this class and making to clear to developers the QIcon should be used for any new software. This, from my reading, does NOT involve deprecating any of the classes placed in the module, they will continue to be supported. no, they absolutely will be deprecated. it will be like libkde3support, which will be going away in Frameworks 5 (due in large part to the Qt3 support going away in Qt5). however, the rest of what you write is correct: add another library to link to in your CMakeLists.txt file and you're done. since the move to Frameworks 5 for an app will require changing the target_link_libraries line anyways, this isn't any more work and is a simple thing to do. meanwhile, if we look at what KIcon actually does for an app, this discussion becomes a wee bit silly .. for those who haven't already, i suggest opening up kicon.cpp and taking a look :) -- 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: Proposal to use QIcon in APIs in KF5.
On Thursday 08 September 2011 09:36:41 todd rme wrote: Several people have proposed moving to a separate module classes that are needed for existing applications but pose a problem for new developers, are no longer needed, or clutter the API. From what they are saying, this seems to ease the porting efforts since KIcon will not have to be changed to QIcon for any existing software, while freeing the rest of the frameworks from dependence on this class and making to clear to developers the QIcon should be used for any new software. This, from my reading, does NOT involve deprecating any of the classes placed in the module, they will continue to be supported. Thanks for pointing that out. It's definitely the point that got missed in those threads about KIcon ATM. The plan in such a case is indeed 1) to introduce the new API replacing KIcon; 2) move KIcon in a new module (let's call it kde4support); 3) provide script to ease porting away from KIcon to the new API. So, you don't want to port existing code? Fine, just link on kde4support for the time being. It indeed ensures source compatibility. After some time you want to port to the new API? Fine as well, take your time, you won't loose any feature, it'll just go through factory methods instead of ctors. BTW, just to put things in perspective here, I'm already counting three/four people arguing for one hour on IRC on that topic, and more than 20 emails here in two threads... just for KIcon which is basically an empty class providing three convenience ctors. I'm not saying everybody should shut up and just walk in the same direction like robots, but I think there's far more valuable discussions to have than KIcon. They'll surely come at some point, and I'm looking forward to the feedback we'll get on those. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Proposal to use QIcon in APIs in KF5.
On Thu, Sep 8, 2011 at 10:59 AM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, September 8, 2011 09:36:41 todd rme wrote: Several people have proposed moving to a separate module classes that are needed for existing applications but pose a problem for new developers, are no longer needed, or clutter the API. From what they are saying, this seems to ease the porting efforts since KIcon will not have to be changed to QIcon for any existing software, while freeing the rest of the frameworks from dependence on this class and making to clear to developers the QIcon should be used for any new software. This, from my reading, does NOT involve deprecating any of the classes placed in the module, they will continue to be supported. no, they absolutely will be deprecated. it will be like libkde3support, which will be going away in Frameworks 5 (due in large part to the Qt3 support going away in Qt5). The original email explicitly said it would not be deprecated, so there appears to be some disagreement on this issue. I do not (anymore) recommend any other changes at this time, such as removing, changing or deprecating KIcon, because it seems to be (surprisingly to me I must admit) a contentious issue. -Todd
Re: Proposal to use QIcon in APIs in KF5.
On Thursday, September 8, 2011 11:08:06 todd rme wrote: The original email explicitly said it would not be deprecated, so there appears to be some disagreement on this issue. oh, the iron! :) the disagreement on the issue to deprecate came about due to a disagreement on irc that was hardly technical. iow, it's unwaranted disagreement driven by unwaranted disagreement. this is the kind of self- reinforcing cycle of negativity that we really need to work on avoiding in the name of constructiveness. and it's all in the part you quoted: I do not (anymore) recommend any other changes at this time, such as removing, changing or deprecating KIcon, because it seems to be (surprisingly to me I must admit) a contentious issue. the contentiousness of the issue is what made Steve take a step back. this is highly unfortunate as the objections were made without sound technical basis and the intensity of the push-back had nothing to do with technical issues and everything to do with (percieved or otherwise) social, community and partner issues. we can, and need, to hash out those topics. but let's do so in a place, time and way that doesn't risk the quality of our API in the process. let's keep the technical discussions focused on the technical. let's keep our objections based on facts. let's give each other the kind of feedback that will improve the suggestions that are made, and keep that friendly and constructive even in disagreement. if we do that, then the above reason to back off from deprecating KIcon and putting it in a support library, which is a good decision in this case, evaporates and we can get back to making great libraries for our applications to use. we may even avoid frustrating those doing the work so that they continue to do the work that we all rely on. does that make sense? -- 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: Proposal to use QIcon in APIs in KF5.
On Thursday 08 September 2011 10:54:02 Sebastian Kügler wrote: On Thursday, September 08, 2011 09:17:00 Jaime wrote: We should assume that Qt5 will have some kind of global icon cache, valid for every Qt application run in one machine, like KIcon has now. Am I Right? Per application, it seems. That's probably still a bit behind KIcon's KSharedDataCache (which works across processes), but I don't really know the details here. Yes, The QIcon cache is per application. (not global.) But what is really the performence gain? Anyway, this is still something that can be added into Qt 5.x I think Qt would benefit from something like KSharedDataCache, not only for the icon cache, but also for the font cache, and many other caches.
Re: Proposal to use QIcon in APIs in KF5.
On Thursday, September 8, 2011 12:00:29 Olivier Goffart wrote: Yes, The QIcon cache is per application. (not global.) But what is really the performence gain? finding icons in the theme structure we use is rather expensive. that's why there is a cache in the first place. sharing that cache between applications means keeping all applications fast instead of having each application start out slow. there's also the issue of disk usage which isn't a big issue on single (or low user count) laptops/desktops, but matters more on multiuser systems and devices. Anyway, this is still something that can be added into Qt 5.x I think Qt would benefit from something like KSharedDataCache, not only for the icon cache, but also for the font cache, and many other caches. agreed :) -- 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.
Downtime notification
Hi everyone, To allow us to perform some web server configuration changes on cano.kde.org, downtime has been scheduled for the following list of sites. This downtime will be intermittent, and will be undertaken on Saturday morning (GMT timezone). The affected sites under kde.org: dot, forum, userbase, techbase, community, blogs, rekonq, br, nepomuk, discover, akademy* Other affected domains: behindkde.org, kde.in, desktopsummit.org, wiki.desktopsummit.org Regards, Ben Cooksley KDE Sysadmin
Re: Cursor Theme Settings
On 8 September 2011 04:56, Sebastian Kügler se...@kde.org wrote: On Wednesday, September 07, 2011 19:04:39 Steven Sroka wrote: On 7 September 2011 12:49, Steven Sroka sroka.ste...@gmail.com wrote: On 7 September 2011 11:22, Sebastian Kügler se...@kde.org wrote: On Wednesday, September 07, 2011 17:08:36 Steven Sroka wrote: Where are the cursor theme settings saved in KDE as well as the wallpaper slideshow settings? kcminputrc and plasma-desktop-appletsrc. For the slideshow settings, I only found plasma-desktoprc which doesn't contain the time settings. Could it be listed elsewhere? Wallpapers are per containment, and those settings are in plasma-desktop- appletsrc. Not sure why you don't have this file, maybe you didn't change any of its setup? Before I was running openSUSE 12.1 M5 which has KDE 4.7. This time I am running Kubuntu 11.04 with KDE 4.6.5 and I find it under /usr/share/kubuntu-default-settings/kde4-profile/default/share/config It has this in the file: [AppletGlobals][plasma_applet_launcher] SwitchTabsOnHover=false askBeforeRemoval=true I have the slideshow turned on and set to transition every 1hr. Any other ideas? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: QML support in kde.org services
This is irrelevant with the need of documenting the QML but since the existence of the Qt desktop components and the QML toplevel windows and menushttp://labs.qt.nokia.com/2011/08/26/toplevel-windows-and-menus-with-qt-quick/ we have to consider the support for QML completion in our IDEs (KDevelop and Plasmate).As i am aware of there is no activity on that.Correct? thanks in advance -- Tsiapaliwkas Giorgos (terietor) KDE Developer terietor.gr
Re: QML support in kde.org services
The meego tablet QML component have extensive documentation, which I guess is later parsed with qt docs or something similar. You can find examples in meego.gitorious.org. Meego UX / meego-ux-components project. Regards, Alvaro On Thu, Sep 8, 2011 at 10:13 PM, Giorgos Tsiapaliwkas terie...@gmail.comwrote: This is irrelevant with the need of documenting the QML but since the existence of the Qt desktop components and the QML toplevel windows and menushttp://labs.qt.nokia.com/2011/08/26/toplevel-windows-and-menus-with-qt-quick/ we have to consider the support for QML completion in our IDEs (KDevelop and Plasmate).As i am aware of there is no activity on that.Correct? thanks in advance -- Tsiapaliwkas Giorgos (terietor) KDE Developer terietor.gr
