Re: Review Request: Transparent QListQUrl handling in KUrl::List
On June 22, 2011, 7 p.m., David Faure wrote: OK. Sebastian Trueg wrote: Just to be clear: does this mean: push it now or push it after the release of 4.7? Hmm, true, I think things are pretty frozen right now. In theory, conversion operators is something I'm wary of, they can make code ambiguous etc. But in this particular case, QListQUrl and QListKUrl are pretty incompatible otherwise, so I can't see any risk of trouble arising from this change. So I'm not objecting to it being committed -- but you retain all responsibility in case of a breakage :-) Since this is just convenience you can work around, I guess it's safer to just push to master (4.7 is already branched). - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101702/#review4073 --- On June 20, 2011, 11:58 a.m., Sebastian Trueg wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101702/ --- (Updated June 20, 2011, 11:58 a.m.) Review request for kdelibs. Summary --- Internally in Nepomuk we use QUrl instead of KUrl since Soprano uses QUrl and we do not need the additional power of KUrl most of the time. Thus, conversion between KUrl and QUrl is important. This patch adds a constructor to KUrl::List which allows to use a QListQUrl as basis and an operator which provides automatic conversion from KUrl::List to QListQUrl. Diffs - kdecore/io/kurl.h 52af985 kdecore/io/kurl.cpp 90ececf Diff: http://git.reviewboard.kde.org/r/101702/diff Testing --- Thanks, Sebastian
Enabling the wiki on projects.kde.org ?
Hi, I'm not sure which mailing list is appropriate for this, so I try here. projects.kde.org is Redmine, and Redmine has a wiki. AFAIK the wiki is currently disabled on projects.kde.org (or can I enable it on a per-project basis and I just didn't find it ?). Can we enable the wiki please ? I created the SuperBuild project there after the Platform sprint, and having the wiki right there would IMO be a perfect place to put documentation etc. I wouldn't have to go to yet another wiki, or set up a whole website, etc. So, what's the state with the wiki on projects.kde.org ? Alex
Re: Enabling the wiki on projects.kde.org ?
- Original Message - Hi, I'm not sure which mailing list is appropriate for this, so I try here. projects.kde.org is Redmine, and Redmine has a wiki. AFAIK the wiki is currently disabled on projects.kde.org (or can I enable it on a per-project basis and I just didn't find it ?). Can we enable the wiki please ? I created the SuperBuild project there after the Platform sprint, and having the wiki right there would IMO be a perfect place to put documentation etc. I wouldn't have to go to yet another wiki, or set up a whole website, etc. So, what's the state with the wiki on projects.kde.org ? Alex We have 3 wiki's already, techbase, userbase and communitybase. Please use those... Best, Toma -- Tom Albers KDE Sysadmin
Re: Enabling the wiki on projects.kde.org ?
On Thursday 23 June 2011, Tom Albers wrote: - Original Message - ... AFAIK the wiki is currently disabled on projects.kde.org (or can I enable it on a per-project basis and I just didn't find it ?). Can we enable the wiki please ? I created the SuperBuild project there after the Platform sprint, and having the wiki right there would IMO be a perfect place to put documentation etc. I wouldn't have to go to yet another wiki, or set up a whole website, etc. So, what's the state with the wiki on projects.kde.org ? Alex We have 3 wiki's already, techbase, userbase and communitybase. Please use those... The wiki on projects.kde.org would be like a small homepage for a small project. IMO homepages for projects do not fit on the existing wikis, techbase is for development documentation, userbase is user documentation and communitybase is more for temporary stuff, as I understand it. And I'd like to avoid the effort of setting up a complete homepage for my two small projects. Alex
Re: Enabling the wiki on projects.kde.org ?
On Thursday 23 June 2011, Alexander Neundorf wrote: On Thursday 23 June 2011, Tom Albers wrote: - Original Message - ... AFAIK the wiki is currently disabled on projects.kde.org (or can I enable it on a per-project basis and I just didn't find it ?). Can we enable the wiki please ? I created the SuperBuild project there after the Platform sprint, and having the wiki right there would IMO be a perfect place to put documentation etc. I wouldn't have to go to yet another wiki, or set up a whole website, etc. So, what's the state with the wiki on projects.kde.org ? Alex We have 3 wiki's already, techbase, userbase and communitybase. Please use those... The wiki on projects.kde.org would be like a small homepage for a small project. IMO homepages for projects do not fit on the existing wikis, techbase is for development documentation, userbase is user documentation and communitybase is more for temporary stuff, as I understand it. And I'd like to avoid the effort of setting up a complete homepage for my two small projects. Basically the Overview page would be enough, but there I have the problem that due to the Members box only half of the horizontal size is available for the rest: https://projects.kde.org/projects/kde/superbuild Maybe this could be changed somehow ? Alex
Re: Enabling the wiki on projects.kde.org ?
- Original Message - communitybase is more for temporary stuff, as I understand it. No. Communitybase is for your project internals, like sprint organisation, meeting notes, todo lists, etc. Userbase is the interface for the users and techbase for developers. The information you provide is targeted at developers, so techbase is a perfect fit there (imho). Best, Toma -- Tom Albers KDE Sysadmin
Re: Qt-only Oxygen style
On 06/22/2011 09:22 PM, Luis Gustavo Spern Barreto wrote: Hi. I have seen a GTK port of Oxygen style on the KDE projects. My question is: Is there any plan to port Oxygen style to Qt-only style plugin? Not on the short term at least. Oxygen uses (and benefits from) part of the utilities of kdelibs, for - configuration handling (kconfig) - color handling (kcolorutils, kcolorscheme) Getting rid of these dependencies would mean duplicating this -otherwise perfectly working- code (either directly or stripped-down), which is not desirable. However, since kdelibs is going through some modularization effort right now, I'll try to jump in and make sure these two guys end up in lightweight independent libraries that oxygen could build against without additional dependencies, apart from Qt. Hugo Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Widget Focus
Steven Sroka, 23.06.2011: On 22 June 2011 03:29, Kevin Funk k...@gmx.de wrote: Wednesday 22 June 2011, Steven Sroka sroka.ste...@gmail.com: Is there any way to set focus to manually a widget when a window opens? I used QRadioButton::setFocus(Qt::ActiveWindowFocusReason), but it doesn't help, the first widget placed on the window always has focus. Thank you everyone. I simply added QRadioButton::setFocus() at the end of the block of code. You would know this better than me, is QTimer::singleShot/QMetaObject::invokeMethod preferable in this scenario? Uhm, as it seems to work without the eventloop, everything is fine? I don't think it is guaranteed that each line of code is run after the previous line is successfully completed, therefore I might need to ensure the program only calls QRadioButton::setFocus() after the widgets are created and placed. That is not really true. Well, sure - if you call a function that creates a thread or delegates work to the eventloop than you could argue that the previous line is *not* successfully completed. But this would be a corner case and is generally not the case. Just assume that everything is done after you called a function. Would the event loop help in this scenario? Then again it is probably overkill, but it is an interesting situation. Hey, Do you call setFocus *after* creating/layouting the widgets? Constructing other widgets afterwards will change the keyboard focus, so be sure to make this call last. Other than, it might help to use the event loop for calling the setFocus() slot on a widget, e.g.: QTimer::singleShot(0, widget, SLOT(setFocus())); This ensures that the widget(s) is/are fully constructed before receiving the focus activation. Hope this helps, Greets -- Kevin Funk Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
About KDE_NO_DEPRECATED
Hi, I've been doing some experiments with the KDE_NO_DEPRECATED define and I have some doubts. What is it exactly supposed to mean? As I understand it, when compiling with this define, all deprecated code should be ignored and the application should work as expected. So if an application builds with KDE_NO_DEPRECATED, you can be sure it's not using any deprecated code that might be removed in future versions. This is not the result I get. When I compile with this define, I get strange results that vary from weird behavior to segfaults. Am I using this define in a wrong way? Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: About KDE_NO_DEPRECATED
JonAnder Peñalba jonan.deb...@gmail.com writes: This is not the result I get. When I compile with this define, I get strange results that vary from weird behavior to segfaults. Are you sure these are related to KDE_NO_DEPRECATED? Do you have some backtraces, more details about the weird behavior you experience and steps to reproduce them? Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Storing data
Am Thursday 23 June 2011 schrieb Steven Sroka: What is the best way for a KDE program to store data? Not passwords or anything sensitive, but data a user had typed into text fields. Some sort of database. Something along the lines of KConfig or KConfig XT but for raw data not configuartion data for programs. Depends on the type of data and what you want to do with it. If you want to dump memory, you need to serialize the data. Have a look at QDataStream. KSharedDataCache helps to to access information from several processes at the same time (like eg. the icons) and save memory. Also you can write it to some xml or an kconfig/qsettings ini-a-like file with the advance of less access ;-) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Storing data
On Thursday, June 23, 2011 23:51:35 Thomas Lübking wrote: Am Thursday 23 June 2011 schrieb Steven Sroka: What is the best way for a KDE program to store data? Not passwords or anything sensitive, but data a user had typed into text fields. Some sort of database. Something along the lines of KConfig or KConfig XT but for raw data not configuartion data for programs. Depends on the type of data and what you want to do with it. KSharedDataCache helps to to access information from several processes at the same time (like eg. the icons) and save memory. I do just want to make very clear that KSharedDataCache is a *cache* and so it is not a suitable guaranteed storage mechanism, although it is useful as a speedup/memory-saver in various scenarios. QDataStream is a good idea as well for arbitrary binary data, but do not forget to set the version of the QDataStream that you expect in your code to something specific so that you can be guaranteed to be able to read it back out later with a newer Qt version! Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Storing data
On 23 June 2011 21:28, Michael Pyne mp...@kde.org wrote: On Thursday, June 23, 2011 23:51:35 Thomas Lübking wrote: Am Thursday 23 June 2011 schrieb Steven Sroka: What is the best way for a KDE program to store data? Not passwords or anything sensitive, but data a user had typed into text fields. Some sort of database. Something along the lines of KConfig or KConfig XT but for raw data not configuartion data for programs. Depends on the type of data and what you want to do with it. KSharedDataCache helps to to access information from several processes at the same time (like eg. the icons) and save memory. I do just want to make very clear that KSharedDataCache is a *cache* and so it is not a suitable guaranteed storage mechanism, although it is useful as a speedup/memory-saver in various scenarios. QDataStream is a good idea as well for arbitrary binary data, but do not forget to set the version of the QDataStream that you expect in your code to something specific so that you can be guaranteed to be able to read it back out later with a newer Qt version! QDataSream is out of the question unfortunately. KSharedDataCache will only read in the data that is already stored - I believe it does not provide data manipulation/organizing/writing, etc. How would I utilize a xml file? Just get my program to hand craft one? Regards, - Michael Pyne Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Storing data
Hi, on Friday 24 June 2011 05:28:25 Steven Sroka wrote: On 23 June 2011 21:28, Michael Pyne mp...@kde.org wrote: On Thursday, June 23, 2011 23:51:35 Thomas Lübking wrote: Am Thursday 23 June 2011 schrieb Steven Sroka: What is the best way for a KDE program to store data? Not passwords or anything sensitive, but data a user had typed into text fields. Some sort of database. Something along the lines of KConfig or KConfig XT but for raw data not configuartion data for programs. Depends on the type of data and what you want to do with it. KSharedDataCache helps to to access information from several processes at the same time (like eg. the icons) and save memory. I do just want to make very clear that KSharedDataCache is a *cache* and so it is not a suitable guaranteed storage mechanism, although it is useful as a speedup/memory-saver in various scenarios. QDataStream is a good idea as well for arbitrary binary data, but do not forget to set the version of the QDataStream that you expect in your code to something specific so that you can be guaranteed to be able to read it back out later with a newer Qt version! QDataSream is out of the question unfortunately. KSharedDataCache will only read in the data that is already stored - I believe it does not provide data manipulation/organizing/writing, etc. How would I utilize a xml file? Just get my program to hand craft one? That would be one way. Another one is to use tools like kxmlcompiler http://www.lst.de/~cs/kode/xmlcompiler.html to generate that code for you. -- Regards Thomas Baumgart GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA - Computers let you make more mistakes faster than any other invention in human history, with the possible exception of handguns and tequila. --Mitch Radcliffe - signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
