boot to uefi action represented by check box
Hi, in System Settings -> Startup and Shutdown -> Desktop Session we have a check box labelled After next restart: [ ] Enter UEFI Setup screen (see attached screen shot) Is there a reason we do not use a button for this? How it currently works is, if I set the check box, a button appears which I then have to click. Additionally the Apply button of that page activates and I can apply the "settings change" ... which is not applied, because it resets on boot. So what is the reason behind this rather exotic work flow? Cheers, Frederik
Re: Progress is good for us but bad for documentation
Hi everyone, thank you for your input and sorry it took me a while to reply. For now I have created a list of issues on gitlab to be reminded. https://invent.kde.org/teams/documentation/sprints/-/issues Some issues I started to investigate but was struck by kapidox_generate being broken on my local machine. This is now addressed and will hopefully be fixed soon. :) Others like the KXmlGui ones I reply to here, I will play through at some point and look what I can do to fill some holes. Feel free to add issues to the issues list as you stumble over them. Cheers, Frederik On 6/14/21 2:00 PM, David Hurka wrote: Hi Frederik, here is my report about a negative experience with existing documentation: So what to report? Documentation that ... - [...] - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. When I tried to understand KXmlGui an KParts (about 15 months ago?), I felt left alone from the documentation. KXmlGui: KXmlGui explains itself as user configurable main windows (toolbars, shortcuts), which should be enough for an introduction. But KXmlGui docs didn’t give me examples how to use it. Just creating a KXmlGui main window and putting a KXmlGuiClient in it didn’t work as easy as setting the main widget of a QMainWindow. My experiment application always crashed at startup. Here I would expect some minimal working examples. It also misses an introduction about merging multiple KXmlGuiClients to one user interface. KParts: KParts didn’t tell me what the whole framework is good for. After reading the documentation, I doubted that a KPart is anything more than a KXmlGuiClient with another name or even a QWidget with a list of actions. Why not just instantiate a QWidget derived object from a library, and put that QWidget in my main window? Here I would expect an introduction why I should use KParts. Only KReadOnlyPart and KReadWritePart made some sense for me. These were able to provide reading and writing files through KIO just through the openUrl() and saveAs() methods. And Konqueror can search for a KReadOnlyPart that allows to open a specific document type, and use this part through a common API. Cheers, David
Re: Progress is good for us but bad for documentation
On 6/9/21 6:02 PM, Johannes Zarl-Zierl wrote: Hi, Am Mittwoch, 9. Juni 2021, 01:20:23 CEST schrieb Frederik Schwarzer: I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. [...] So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Is this an effort with universal scope, or is there a limit? Obviously you are at least talking about the wikis. Are you also (at the current time) talking about other websites and/or application handbooks? It is meant as an open question. All answers welcome. Of course not everything can be worked on now. But compiling a list of stuff to work on will help pushing and coordinating the work. heers, Frederik
Progress is good for us but bad for documentation
Hi, we are all making progress but the way to notice it can be painful. Looking at something you created years ago might make you cringe, but that's actually a good sign. It indicates, that you made progress. KDE is making progress as well. Here the indicator is outdated documentation. There is still quite some documentation from KDE 4 times where the technology documented already moved on to more modern times. And just as your résumé needs updating once in a while to reflect your newly acquired skills and references, documentation needs updating so it reflects the current state of KDE (as in software, places to communicate, go-to people for all the several parts of the projects, etc.). I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. So to let me know, you can send me an email (on- or off-list) and I will create a ticket for it where further discussion can take place. Of course you could theoretically open a ticket yourself but we still need to find the best place for those topics. I will keep you posted on that one. :) So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Thanks a bunch. :) Cheers, Frederik
Re: kdesrc-build expects fixed path
Hi, thanks for your replies. So it seems as if it broke recently and I was not just doing it wrong. :) In the code the bashrc snippet is just plain text. That's not going to work if there two different repo layouts. As for the fix, I guess we could either make kdesrc-build handle both layouts or make it add the path of the checkout it was run from to the bashrc. It feels intentional to use the copy from the repo layout to be more self-contained so it continues to work when the initial repo is deleted or moved around. Once the repo layout question is decided, we can check what to do here. Cheers, Frederik On 6/7/21 12:13 AM, Nate Graham wrote: I think a better change would be to return to the older, simpler, shorter "flat" folder structure. See https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/96 Nate On Sat, 05 Jun 2021 22:27:44 -0600 Ömer Fadıl USTA wrote > I think we need to change templates and other docs for its standard location as$HOME/kde/src/sdk/kdesrc-build > because it already downloads its self (as a copy) whenever we run kdesrc-buildI believe it was set up flat structure just before passing to invent structure sonow it must be looked up in sdk folder > > Ömer Fadıl Usta > PGP key : 0xfd11561976b1690b > about.me/omerusta > > > Frederik Schwarzer , 5 Haz 2021 Cmt, 20:18 tarihinde şunu yazdı: > Hi, > > when I just tried to set up kdesrc-build with --initial-setup it offered > me to update my .bashrc file. > > The changes made did not work for me because it adds > $HOME/kde/src/kdesrc-build > to the PATH while I have my checkout at another location. > > Maybe I have missed something but I think we should either > - print a warning or even an error message when >running "--initial-setup" from a "wrong" location > or > - add the location of the actual checkout to .bashrc > > Any thought or amendments? > > Cheers, > Frederik >
kdesrc-build expects fixed path
Hi, when I just tried to set up kdesrc-build with --initial-setup it offered me to update my .bashrc file. The changes made did not work for me because it adds $HOME/kde/src/kdesrc-build to the PATH while I have my checkout at another location. Maybe I have missed something but I think we should either - print a warning or even an error message when running "--initial-setup" from a "wrong" location or - add the location of the actual checkout to .bashrc Any thought or amendments? Cheers, Frederik
Re: Shall we condense the bots' commit announcements
Am 26.05.2021 03:12 schrieb Nicolás Alvarez: El mar, 25 de may. de 2021 a la(s) 21:59, Frederik Schwarzer (schwar...@kde.org) escribió: Another thought I had was that GIT_SILENT messages could be omitted. Maybe also worth considering? Seems this is already possible in the configuration, per channel. Some channels have notify_silent=False: https://invent.kde.org/sysadmin/irc-notifications/-/blob/master/gateway/notifications.cfg Thanks for the info. Cheers Frederik
Re: Shall we condense the bots' commit announcements
Hi, I would not object to this change. Maybe keep the longer versions in #kde-commits? Another thought I had was that GIT_SILENT messages could be omitted. Maybe also worth considering? Cheers Frederik On 5/25/21 11:25 PM, Nate Graham wrote: Hello all, Recently we removed the commit announcement bots from the #plasma and #kwin chatrooms because we felt their output was too noisy. However for the rooms where they are still active and announcing git commits, would people appreciate it if the announcements were shorter? For example, instead of sending 5 messages (title, first three lines, and URL) the announcement could send one message (something like title and URL combined). Would anyone object to this change? Nate
Re: Winding down Phabricator
Hi, thanks for putting so much effort in the transition. We, as the German translation team, use Phabricator for reviewing the work of casual contributors. I wonder how other teams handle this. I am not saying, Phabricator going away will break our workflow completely but it is a good way to discuss changes and keep track of the discussion. Cheers Frederik On 6/21/20 5:38 AM, Ben Cooksley wrote: Hi all, With the completion of Phase 1 of our move to Gitlab, all code review activity should now be taking place on Gitlab, with only residual reviews being cleaned out of Phabricator (which hopefully we're already well underway with - please start this if you haven't already) This leaves just Tasks left on Phabricator. As interacting with repositories isn't a core requirement for this functionality, we've now taken the step of disabling all repository functionality on Phabricator. This means that going forward, repositories will no longer be browsable on Phabricator, nor will commit information be visible on Phabricator. Additionally, actions normally taken via hooks (such as "Differential Revision" and "Fixes Txxx") will no longer work. Should anyone have any questions regarding this, please let us know. Thanks, Ben Cooksley KDE Sysadmin
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
Am 15.10.2019 18:16 schrieb Johan Ouwerkerk: On Tue, Oct 15, 2019 at 9:17 AM Frederik Schwarzer wrote: Now I will fix my latest revision and merge to master. Still: 19 commits are not compiling anymore. Or am I missing something here? How would we deal with that? Is "short-lived branches" (as you stated below) enough to reduce the risk? To answer in reverse order: Yes. On the one hand short-lived branches reduce this risk considerably: this scenario applies to breaking changes in master which fundamentally alter the way the application works. It's like a core library upgrade or, in this case, a major UX rewrite: something fairly fundamental to the application changes in master. It is unlikely that this should happen overnight without any kind of prior review. Still, this can and does happen and will happen some day to you if you contribute enough :) However this gets back at the git rebase bit. So yes, you rebase your feature on master as per normal, fix transient merge conflicts and then what? Well, then you still have to compile & test. At which point you notice breakage. How do you recover? As you would: you begin the porting effort, either changes from master to your new feature way of doing things (in case *you* are the one doing the UX rewrite/major refactoring), or vice versa you apply the new world order from master to your feature. What I like to do during this process is to avoid committing these fixes just yet. I want to get a feel for the total diff, in particular the total git diff --stat that I accumulate. Then I can identify on a file-by-file basis using something like git log -3 path/to/file or so what the likely commit is which should have been amended. Sometimes you notice the diff for a file should be spread over multiple commits according to your prior log, so what you do next is you use git add like this: git add -p path/to/file. You only select the bits for which you have identified a particular commit, you commit those added hunks and here I like to leave a note in the first line of the commit to the effect of "fixup " or "squash " or "". In this way you build up a bunch of commits which cover your fixes. Next up, you turn to git rebase again, using e.g. git rebase -i master. Now you can interactively fold the commits into the history as "it ought to be" and this is where I use my notes to help me decide how to proceed. Note you don't have to get everything just right, and note that this rebasing itself may introduce transient merge conflicts you need to fix: so if the diff stat was large it makes sense to split this up into multiple git rebase -i runs just to give yourself a break in between. Finally perhaps you rebase again to touch up a few commit messages or something, and if this whole process took considerable amount of time you want to verify that upstream master has not yet moved on by that point. So in this more complex case you can adopt a correspondingly more complex git workflow and use rebase to produce clean commits. Now, sometimes you decide this is all too much work, and too much bother. What you can do in such a scenario instead is to create a fresh new branch from master and effectively re-create commits there. In those cases git cherry-pick and git checkout -p -- path/to/file come in handy Ultimately whether or not a scrupulously clean commit log is worth the effort or whether you might decide to simplify things a little and accept a few broken commits in between mostly depends on the needs of your project and how many people work on it. Thanks for the explanation. :) Just to clarify. I am not opposing the idea of enabling fast-forward merges. It seems to be a widely-used feature after all. I just wanted to throw in my concerns. Cheers Frederik
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
Am 14.10.2019 22:51 schrieb Johan Ouwerkerk: On 14.10.2019 21:22, Frederik Schwarzer wrote: If however, master had seen commits as well, fast-forwarding is performing a rebase ... is that correct? The workflow would be: whenever master is updated, you rebase your local feature/work branch and force-push to the remote copy of the feature/work branch. This is exactly the problem I see. I create a branch. I start to use, let's say ... KDialog in my feature as KDialog has been used throughout the application and make 20 commits. Now on master, someone merges a branch that replaces all the KDialogs with overlays and removes all KDialog includes. So if I rebase on that, all my 20 commits will fail to build. Checking out an older revision to test something will not work. Now I will fix my latest revision and merge to master. Still: 19 commits are not compiling anymore. Or am I missing something here? How would we deal with that? Is "short-lived branches" (as you stated below) enough to reduce the risk? Cheers Frederik
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
Hi, just asking in case I didn't get it. I branch off of master and do a few commits in that new branch. If I now merge the branch back to master and master had not seen any commits in between, it's just relocating the master "tag" and all is fine. If however, master had seen commits as well, fast-forwarding is performing a rebase ... is that correct? Wouldn't rebasing be evil because it rewrites history? Cheers Frederik On 10/14/19 6:29 PM, Johan Ouwerkerk wrote: Yes, please, pretty please with cherry on top. :) Regards, -Johan On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid wrote: I find the merge behavior to be not what we've been doing in phabricator so given the idea is to maintain our workflows i'd appreciate if we can agree on continue doing the same. https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html Opinions? Cheers, Albert
Re: Building KDE (phonon-vlc) fails
On Monday, December 10, 2018 12:34:22 PM CET Harald Sitter wrote: > On Mon, Dec 10, 2018 at 11:26 AM Frederik Schwarzer wrote: > > After installing it, phonon-vlc built fine. > > this should be easier to diagnose in the future > https://commits.kde.org/phonon-vlc/e441972892fe61e361ee9b2c39ce0b319f6d1c9e Nice. Thanks for improving that. :) Cheers Frederik
Re: Building KDE (phonon-vlc) fails
On Monday, December 10, 2018 12:29:54 AM CET Michael Pyne wrote: > On Sun, Dec 09, 2018 at 10:18:42AM +0100, Frederik Schwarzer wrote: > > Hi, > > > > please forgive my ignorance. It has been ages since I last built KDE from > > sources. > > > > Using kdesrc-build, the phonon-vlc package fails on cmake with the > > following> > > error: > > -- Checking for module 'libvlc' > > -- Found libvlc, version 3.0.4 > > > > CMake Error at cmake/FindLIBVLC.cmake:106 (message): > > Could not find LibVLC > > > > Found, but not found? Maybe it is looking for a different version? > > > > libvlc-dev is installed on Kubuntu 18.04. > > > > Any idea on what I am missing here? > > Perhaps you need a package libvlccore-dev or similar? The FindLIBVLC in > phonon-vlc checks for both libvlc and for libvlccore but only gives the > one error message if either one is missing. Thank you for your answer. I read the FindLIBVLC file and found three checks. The one for the header file: # find / -iname vlc.h /usr/include/vlc/vlc.h The one for libvlc: # find / -iname libvlc.* /usr/lib/x86_64-linux-gnu/libvlc.so.5.6.0 /usr/lib/x86_64-linux-gnu/libvlc.so /usr/lib/x86_64-linux-gnu/libvlc.so.5 And the one for libvlccore: # find / -iname libvlccore.* /usr/lib/x86_64-linux-gnu/libvlccore.so.9 /usr/lib/x86_64-linux-gnu/libvlccore.so.9.0.0 These looked fine to my untrained eyes at first but the missing libvlccore.so (without the version number) made me think so I looked it up and indeed, the package libvlccore-dev was missing. After installing it, phonon-vlc built fine. Thanks for the pointer. :) Cheers Frederik
Building KDE (phonon-vlc) fails
Hi, please forgive my ignorance. It has been ages since I last built KDE from sources. Using kdesrc-build, the phonon-vlc package fails on cmake with the following error: -- Checking for module 'libvlc' -- Found libvlc, version 3.0.4 CMake Error at cmake/FindLIBVLC.cmake:106 (message): Could not find LibVLC Found, but not found? Maybe it is looking for a different version? libvlc-dev is installed on Kubuntu 18.04. Any idea on what I am missing here? Cheers Frederik
Re: Deploy Weblate/Pootle system for translation
On Donnerstag, 4. Mai 2017 17:59:58 CEST Guo Yunhe wrote: Hi, this discussion would be a better fit for kde-i18n-...@kde.org. > However, our SVN is stopping people from contributing. Not only techniques > but also transparency. When here are some disagreement on specific > translation, usually those who have SVN commit permission can choose the > option they prefer. Sometimes it is disappointing. Just want to point out here that disputes are not better dealt with in web translation systems. It's like saying, in SVN, if two people disagree, just give them both access and the problem will go away. Just do not solve people problems with technical solutions. As for the rest ... this topic is coming up every once in a while, so the mail archive of kde-i18n-...@kde.org is full of pro and con arguments. For me it's a matter of taste and I did not see a system yet that I like. Cheers, Frederik
Re: kde on windows
Am 31.07.2016 um 07:32 schrieb Doug: > I don't know what you think you've accomplished by limiting KDE on > Windows to just 4 files. Please take this discussion to kde-wind...@kde.org There you will get better answers than here. Also please choose your words more constructively. For most this is a leisure time project and everything is given away for free. Regards, Frederik
Re: Could we enable Travis-CI on our github mirrors?
Am 21.04.2016 07:56 schrieb Teo Mrnjavac: Hi, Can we call things as they are please? The name is "Travis CI", not "githubCI". Travis CI is open source, a separate product and service that happens to talk to GitHub. I think Albert's concern is (and I agree) that the meaning of a potential Travis-hosted CI is shifting over time from "addition" to "main one". People tend to do this. Oh, this one feature here, oh, the easier login there ... In general I think 3rd party services should be avoided to get an official status in KDE. Sourceforge suddenly started adding adware to all downloads. Github can do the same. Tomorrow, nezt week, next year. They might announce this first or they don't. The same way TravixCI could say, they now want money or put ads all over the place. We have no control over this at all. So it is better to invest some time and money to maintain our own infrastructure. It makes us independent from some management decision made by some company. Also, for an infrastructure inside KDE, we need people to work on it. If now people start to use 3rd party sevices, less people are looking at our infrastructure and it gets less attention. That's at least why I would vote against that kind of "additions" made official. If some developer wants to use something somewhere, I guess there is nothing to hold him back but KDE shoud remain as self-contained as possible. Wth all the little problems coming with this. Regards, Frederik
Re: Static code analysis - the easiest way to improve
I created an account a few weeks ago, asked to join and was able to access the KDE group fine the next day. Who is granting the access? Maybe contact that person directly. KDEGames is not there yet, though. Regards, Frederik Am Dienstag, 15. März 2016, 17:45:44 schrieb Jaroslaw Staniek: > On 15 March 2016 at 17:33, Tomas Mecir wrote: > > No change for me, unfortunately, still getting that red box (tried > > both password and github login). > > I see. All I did is asking scan-ad...@coverity.com 2 times or so. > And waiting 2+ weeks. Maybe they're fixing/enabling access > one-by-one. > > > Tomas > > > > 2016-03-15 17:28 GMT+01:00 Jaroslaw Staniek : > > > On 28 February 2016 at 16:26, Tomas Mecir wrote: > > >> Well, I'd like to, but when I log in and try to access the KDE > > >> stuff, I can see the summary, but accessing the actual defect > > >> list gives me a red box with this: > > >> > > >> It may take a few minutes before you can view your defects, > > >> when you change your email or password or sign-in with Github > > >> for the first time. > > > > > > Hi, > > > Just tried it for some projects again and the red box is > > > apparently gone. > > > > > > -- > > > regards, Jaroslaw Staniek > > > > > > KDE: > > > : A world-wide network of software engineers, artists, writers, > > > > translators > > > > > : and facilitators committed to Free Software development - > > > > http://kde.org > > > > > Calligra Suite: > > > : A graphic art and office suite - http://calligra.org > > > > > > Kexi: > > > : A visual database apps builder - http://calligra.org/kexi > > > > > > Qt Certified Specialist: > > > : http://www.linkedin.com/in/jstaniek > > > > ___ > > calligra-devel mailing list > > calligra-de...@kde.org > > https://mail.kde.org/mailman/listinfo/calligra-devel
Re: KConfig - setStandardButtons() breaks Help button?
Am Sonntag, 6. März 2016, 12:20:38 schrieb Albert Astals Cid: > El Saturday 05 March 2016, a les 08:34:27, Frederik Schwarzer va escriure: > > Hi, > > > > I am struggling with using KConfigDialog. If I use it like this: > > KConfigDialog* dialog = new KConfigDialog(this, > > > > "settings", Settings::self()); > > > > connect(dialog, &KConfigDialog::settingsChanged, > > > > this, &MainWindow::loadSettings ); > > > > dialog->show(); > > > > the Help button works. > > > > Since in my use case, some of the values in the dialog are > > calculated and (to my understanding) cannot be handled correctly > > by Kcfg, I want> > > to get rif of the "Restore Defaults" button. So I add this line: > > dialog->setStandardButtons(QDialogButtonBox::Ok | > > > > QDialogButtonBox::Cancel | QDialogButtonBox::Help); > > As a side note, there's ways in which you can make it so the > "restore default" button does execute some code for those "tricky" > settings (i.e. override updateWidgetsDefaults) Hmm, updateWidgetsDefaults() is protected. Would I not have to make my own Dialog and inherit from KConfigDialog to overwrite that? > > but then the Help button does not open the Help browser anymore. > > Is that expected? Do I use KConfigDialog incorrectly? Is this just > > broken on my system? > > > > In case someone wants to see what is happening, I created a semi- > > > > minimal buildable example to play with. See: > > https://quickgit.kde.org/?p=scratch%2Fschwarzer%2Fkconfigexamp > > le.git > As Thomas says you have to recreate the connections, so basically > > connect(buttonBox->button(QDialogButtonBox::Help), > SIGNAL(clicked()), q, SLOT(showHelp())); This was done before during the KF5 porting but it did not open the correct halp page. So I removed that part and used the StardardButtons to make the help work. ... Leading to other problems. :) Kigo is q bit complicated in this regard. Even now Applying settings with an invalid Go command is breaking the whole game until the next restart. My goal would be to get rid of the "tricky" part alltogether and just let the standard config dialog handle everything but it's a lot of fiddling to find out what can be done and what can't. Thanks, Frederik
Re: KConfig - setStandardButtons() breaks Help button?
Am Sonntag, 6. März 2016, 12:19:14 schrieb Thomas Lübking: > On Sonntag, 6. März 2016 12:10:36 CEST, Frederik Schwarzer wrote: > >> The most straight forward solution is likely to hide or delete > >> button(QDialogButtonBox::RestoreDefaults) > > > > I would like to try this but cannot find info on how to hide a > > standard button. > > The KDE 4 version did not have that button either so it's at least > > not worse than before. > > if (QPushButton *restore = > button(QDialogButtonBox::RestoreDefaults)) restore->hide(); Meh, KDevelop completed to "QDialogButtonBox::Reset" which then compiled but crashed without the if() condifion. :) Thanks. Frederik
Re: KConfig - setStandardButtons() breaks Help button?
Am Samstag, 5. März 2016, 10:53:18 schrieb Thomas Lübking: > On Samstag, 5. März 2016 08:34:27 CEST, Frederik Schwarzer wrote: Hi, > > Since in my use case, some of the values in the dialog are > > calculated and (to my understanding) cannot be handled correctly > > by Kcfg, I want> > > to get rif of the "Restore Defaults" button. So I add this line: > > dialog->setStandardButtons(QDialogButtonBox::Ok | > > > > QDialogButtonBox::Cancel | QDialogButtonBox::Help); > > > > but then the Help button does not open the Help browser anymore. > > > ::setStandardButtons simply forwards the call to the internal button > ::box which nukes all button objects (incl. their slot connections) > ::and recreates them w/ the new item list. Ok, reading it like this, the behaviour suddenly makes sense. :) > The most straight forward solution is likely to hide or delete > button(QDialogButtonBox::RestoreDefaults) I would like to try this but cannot find info on how to hide a standard button. The KDE 4 version did not have that button either so it's at least not worse than before. > Rather replace the restore defaults button, resp. re-link it to your > own calculation slot. I will add a comment that this is better and should be considered in the future. Thanks for the hints. Regards, Frederik
KConfig - setStandardButtons() breaks Help button?
Hi, I am struggling with using KConfigDialog. If I use it like this: KConfigDialog* dialog = new KConfigDialog(this, "settings", Settings::self()); connect(dialog, &KConfigDialog::settingsChanged, this, &MainWindow::loadSettings ); dialog->show(); the Help button works. Since in my use case, some of the values in the dialog are calculated and (to my understanding) cannot be handled correctly by Kcfg, I want to get rif of the "Restore Defaults" button. So I add this line: dialog->setStandardButtons(QDialogButtonBox::Ok | QDialogButtonBox::Cancel | QDialogButtonBox::Help); but then the Help button does not open the Help browser anymore. Is that expected? Do I use KConfigDialog incorrectly? Is this just broken on my system? In case someone wants to see what is happening, I created a semi- minimal buildable example to play with. See: https://quickgit.kde.org/?p=scratch%2Fschwarzer%2Fkconfigexample.git I am thankful for any hint. :) Regards, Frederik
Re: Static code analysis - the easiest way to improve
Am Sonntag, 28. Februar 2016, 20:18:22 schrieb Nick Shaforostoff: > > > Let us know in this thread if code you're interested in isn't > > > there.> > > Could we have kdegames there? > > ok, i'll include them in the next build (in a week or so) Thank you.
Re: Static code analysis - the easiest way to improve
Am Sonntag, 28. Februar 2016, 15:59:46 schrieb Jaroslaw Staniek: Hi, > Let us know in this thread if code you're interested in isn't there. Could we have kdegames there? Regards, Frederik
Re: File dialog filters
Am Dienstag, 16. Februar 2016, 18:27:23 schrieb Christian Dávid:
Hi,
> I noticed that in KMyMoney the filter strings for file dialogs are
> created "by hand", e.g. i18n("C++ sources (*.cpp *.cxx *.c++);;All
> files (*)"). So each of them must be translated. Alternatively
> something like
>
> QMimeDatabase db;
> db.mimeTypeForName("text/x-c++src").filterString()
Just a guess but many application might not succeed in finding their
MIME type in the db. They could provide an XML file for that, but this
is quite a hassle compared to just writing a few characters. Also how
can several mime types be represented? Like your example "C++
sources;;Allfiles".
>From the docs: "If the MIME type database cannot be found on the
system, as is the case on most Windows, OS X, and iOS systems, Qt will
use its own copy of it."
While this does not sound too bad, it at least gives the impression of
a not too well working process.
> could be used to create these string lowering the burden on the
> translators and resulting in consistent translations for all
> mimetypes.
Thank you for thinking about the translators. :)
I did not know about QMimeDatabase until now. On my system I have 930
MIME types in the db. Just for you to compare with yours.
To me this looks like a nice way to have unified strings for file
types and I would also like to know if there are things speaking
against using it.
Regards,
Frederik
Re: Problem with KConfigGroup
Am Montag, 15. Februar 2016, 14:20:11 schrieben Sie:
> On Monday, February 15, 2016 4:02:32 AM CET Frederik Schwarzer
wrote:
> > Hi,
> >
> > in Klickety the Configure dialog stopped working in one specific
> > area. It's a QGroupBox with radio buttons represented as an Enum
> > in the kcfg file. Two of the radio buttons have another widget
> > right next to them.
> >
> >
> >
> > | o Theme|
> > | o Color [kcolorbutton] |
> > | o Image [kurlrequester] |
> >
> >
> >
> > So, as is, the Enum always says "0" and the Apply button remains
> > grayed-out.
> > If I then remove both of those extra widgets, the correct value is
> > given (0-2) and the Apply button works as expected.
> >
> > You can find the UI file in
> > https://quickgit.kde.org/?p=klickety.git&a=blob&f=bgselector.ui&o=
> > plain and the last two widgets (KUrlRequester and KColorButton)
> > are the culprits.
> >
> > Does anone have an idea why having another widget there disturbs
> > the radio buttons?
>
> You can diff the generated files and see what happens. Also for the
> KConfigCompiler (I think that's what you are complaining about? I
> don't see any reason KConfigGroup would be the culprit here?)
Thanks for the hint. I tried that. If I remove the two widgets, the
changes in the build dir are as follows. For me this looks pretty much
as I would expect it to be.
diff -ur temp_with/ui_bgselector.h temp/ui_bgselector.h
--- temp_with/ui_bgselector.h 2016-02-15 17:37:35.855052087 +0100
+++ temp/ui_bgselector.h2016-02-15 17:36:33.449802766 +0100
@@ -36,8 +36,6 @@
QRadioButton *theme;
QRadioButton *color;
QRadioButton *image;
-KUrlRequester *kcfg_BgImage;
-KColorButton *kcfg_BgColor;
void setupUi(QWidget *BackgroundSelector)
{
@@ -70,17 +68,6 @@
gridLayout1->addWidget(image, 2, 0, 1, 1);
-kcfg_BgImage = new KUrlRequester(kcfg_BgType);
-kcfg_BgImage->setObjectName(QStringLiteral("kcfg_BgImage"));
-kcfg_BgImage->setEnabled(false);
-
-gridLayout1->addWidget(kcfg_BgImage, 2, 1, 1, 1);
-
-kcfg_BgColor = new KColorButton(kcfg_BgType);
-kcfg_BgColor->setObjectName(QStringLiteral("kcfg_BgColor"));
-
-gridLayout1->addWidget(kcfg_BgColor, 1, 1, 1, 1);
-
gridLayout->addWidget(kcfg_BgType, 3, 0, 1, 1);
But then I looked at the latest KDE 4 version and it worked quite fine
so I went through the changes since then and found that these widgets
resided within a KButtonGroup, which was changed to a QGroupBox during
porting (by me *coughs*) whereas it should have been changed to a
combination of a QGroupBox and QButtonGroup according to
http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/classKButtonGroup.html
So currenty I am fighting with QtCreator to put in a QButtonGroup
(harder than expected). Back to reading for now. :)
Thanks,
Frederik
Problem with KConfigGroup
Hi, in Klickety the Configure dialog stopped working in one specific area. It's a QGroupBox with radio buttons represented as an Enum in the kcfg file. Two of the radio buttons have another widget right next to them. | o Theme| | o Color [kcolorbutton] | | o Image [kurlrequester] | So, as is, the Enum always says "0" and the Apply button remains grayed-out. If I then remove both of those extra widgets, the correct value is given (0-2) and the Apply button works as expected. You can find the UI file in https://quickgit.kde.org/?p=klickety.git&a=blob&f=bgselector.ui&o=plain and the last two widgets (KUrlRequester and KColorButton) are the culprits. Does anone have an idea why having another widget there disturbs the radio buttons? Thanks, Frederik
Re: April: Top 15 Mailinglists with messages in moderation
On 01/04/2011, Tom Albers wrote: > Hi, > > The monthly overview of the lists with most messages in the moderation > queue: > >> 19 kde-news-de This might be a candidate for a closedown. The archive ends in 2007 and there are no plans to revive something like this. Was the admin asked for his opinion? Regards >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
