You can find me around as tosky.
- User Since
- Apr 18 2015, 1:18 PM (234 w, 1 d)
Sat, Oct 12
Fri, Oct 11
Thu, Oct 10
Wed, Oct 9
Tue, Oct 8
Mon, Oct 7
Sun, Oct 6
@davidedmundson time to commit? :)
Sat, Oct 5
I wonder how to untangle this dependency, because a change in Frameworks can't (shouldn't?) depend on a change in a consumer (yes, same issues as toys).
I think you need to bump the dependency on the newer KService, which means the dependency on the newest (right now unreleased) Frameworks.
If I am correct, can you please revert this and push it again when the Plasma team decides to bump the dependency?
Fri, Oct 4
@nalvarez hi! Do you have any news about this task? Can we help?
Thu, Oct 3
Can you please at least remove the steam example from the commit message, as it is not relevant (it is a downstream change) and remove the reference to the bug?
Does it also mean that kf5-toys.directory is not used anymore? (not sure whether it can't be removed anyway for compatibility?)
Wed, Oct 2
What is the difference between "LeadAcid" and "Lead Acid"?
Tue, Oct 1
Mon, Sep 30
Sun, Sep 29
Sat, Sep 28
Fri, Sep 27
Thu, Sep 26
@ngraham Let's make it configurable, but not change the default then. I disagree that changing this default on an application which support rich text by default helps making the life of everyone better.
Please ignore the last part of my last comment. My question on the way a paste happens is still relevant, so please answer it: if users use the right click, they will surely distiguish "paste" and "paste without formatting". If they use the shortcut, they can learn to use the the proper shortcut for that action (which, in applications which provides rich text support, is not ctrl-V).
Please also note that the notes applications is a rich text editor by default (like the buttons shows). So I would vote for a revert of D22774.
I don't see how using the "running in circles" argument can solve the problem. I totally understand how notes works, thanks.
The situation is how I described above: applications with just paste may have non-formatting option; applications which have both options default to pasting with formatting.
Nothing here convinces me that there is enough reasons to diverge from the common patterns. It's not a matter of being richer and with more features.
Do those applications provide the paste-with-formatting action too?
I think that the Kate use case is different, as it provides only one paste action. Whenever else there are two paste actions available, it's always "paste" (with formatting) associated to ctrl-V and "paste without formatting" to ctrl-shift-V. So maybe you are talking about pasting with the mouse? If it's through right click, both action are clearly visible. If it's through middle click, uhm, maybe we can talk about that. But the meaning of the variants of paste and their shortcuts has been very stable cross-platforms for a long while.
Wed, Sep 25
I think that this requires a bit more of discussion; "Paste" has a specific and well expected meaning.
Tue, Sep 24
Expanding a bit on the fact that the line between important and interesting may be not absolute, I think that any of items on the "Important (but not very interesting)" list become interesting if they were associated to a bug which had a relevant number of votes/reactions.
What changes is the patch needed. If we agree that Paste means "paste with formatting", then the string don't need to be changed, just the shortcut.
Out of curiosity: doesn't usually the default Paste action (ctrl-V) paste with formatting? Shouldn't the shortcut be changed instead?
Mon, Sep 23
Sat, Sep 21
Technically I think that an hard dependency on QtWebEngine is a mistake, and that both engines should be available (QTextBrowser too).
Sune thinks that this would be not wise. Oh, well. As I don't want to block this right now (but it can be changed later) even if I don't agree, if it's possible to not have regressions (apart maybe the "move to another page with space"), feel free to move forward (I won't be around in the next few days).
As I mentioned, you need to create a StaticMessages.sh file in your repository, which expose the two twin functions (export_pot_dir/import_pot_dirs if you deal with multiple pot files or export_pot_file/import_pot_files if you have just one), following the example of websites/docs-krita-org, plasma-browser-integration or other projects (kdeconnect-android, for example).
The only thing I can do on the translation side is to enable the extraction for that repository, but you need to write that script.
Fri, Sep 20
This is not off-topic, because the limit you are trying to enforce is not an absolute limit, as stated in the same code that you are quoting. It's not about "code style can just go to shit". If the QML does not allow to have this, well, either fix QML (at this point probably for Qt6), there in no much to do: an important feature like translations cannot be broken, as I pointed out on IRC, with my translator co-coordinator hat on.
Thu, Sep 19
Let's go for it (and sorry for the long waiting time).
Sorry, I totally missed it. It totally makes sense at this point.
Sorry, I missed it. I'd say that if we fail to remind translators that we need to translated Qt, we have much bigger issues than a bunch of SSL *error* messages.
No, I think that's the structure required by sphinx. Make sure that import_po_dirs returns the structure that you need.
Please note that the use case of docs-krita-org involves multiple pot files. If you just need one (but again, it depends on the size), this is a simpler case:
Take a look at what krita does:
- if releaseme can fetch translations from SVN when creating the tarballs, I don't see how to do it
- size: it depends on how big the files are going to be
- not much; something is here: https://techbase.kde.org/Localization/Concepts/Auto_Assists#Daily_jobs_done_by_Scripty - but you don't need to know it, as long as you provide a script for extracting/merging, see what docs-krita-org does.