I would feel more safe if you initialized m_cursorSelectionStart and m_cursorSelectionEnd to 0 in the constructor
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jul 29 2018
Jul 27 2018
I'll push this next week if there is no additional comments
I'll push this next week if there is no additional comments
Jul 26 2018
In D14219#297396, @sdepiets wrote:In D14219#297294, @aacid wrote:Should the state of the action be remembered between runs?
I didn't plan that, the quick search project field isn't saved between runs.
Performance wise it would not change anything to launch the program with the filter on.
Jul 25 2018
In D14321#297359, @sdepiets wrote:Yes I'm working on having the craft blueprint integrated. https://phabricator.kde.org/D14322
Once it's done I'll get in touch with the binary team to have it in the CI tools.
In D14219#297294, @aacid wrote:Should the state of the action be remembered between runs?
Yes I'm working on having the craft blueprint integrated. https://phabricator.kde.org/D14322
Once it's done I'll get in touch with the binary team to have it in the CI tools.
Jul 24 2018
Should the state of the action be remembered between runs?
If it works, sure let's go for it.
Change of tooltip/menuitem text
Add tooltip and move menu item to settings
Jul 23 2018
Thanks indeed. Very useful! :)
I have done some testing, and the patch seems to work fine. Thanks for adding this very useful feature!
Add an icon for the menu entry
Jul 22 2018
Also make sure to mention bug #224179 in the revision summary, so that it will automatically be closed when you commit the revision. See https://community.kde.org/Infrastructure/Phabricator#Add_special_keywords for instructions.
The patch adds a toolbar item, but it’s missing an icon. Could you add one? I think the one named hide_table_row will work well.
Jul 21 2018
Style and invalidateFilter call fix
I think this is fine, if we let people zoom on the top area, we should let people zoom on the zoom one, but i agree with Safa this is not the actual fix for bug 375251
Jul 19 2018
Changes based on inline comments
Jul 18 2018
Adding @kossebau since he had at some point of history a patch for fixing this at the ki18n level. Friedrich can you comment on it?
Jul 17 2018
Rebasing on Applications/18.08
I agree this is suboptimal but it doesn't require the font selection (it's only the zoom).
I can find some use cases, especially with oriental languages, where you might prefer having different sizes for your English source and your local contents so it can still help.
Jul 16 2018
Thank you!
I see the problem you are solving, but this is a less optimal solution.
This way the user must change the size with every launch of the app, and this is if he knows how to :) (no to mention he should change the size of both the boxes to match, or it will be ugly looking)
A solution that is used in Linux version is much better (a font setting)
Fix tab and replace by spaces
Jul 14 2018
In T8984#151155, @ltoscano wrote:Do you mean that those markers are needed anytime there is a mixed string with a translated part (which could be LTR or RTL) and a fixed part which has always the same direction?
In T8984#151154, @safaalfulaij wrote:First, sorry for any language mistakes.
In T8984#151124, @huftis wrote:FWIW, I’m not sure I understand all the implications, but I think this sounds like a good idea. But I have two questions:
- Will these characters also be needed for LTR languages?
In some cases, yes they will be needed. Take this PR as an example, the same issue is with Dolphin:
First, sorry for any language mistakes.
Jul 13 2018
In T8984#147458, @safaalfulaij wrote:Well, I said the same way we'll do it for the formatting, so if we'll go with “all placeholders are locale-formatted”, then we'll go with “all placeholders are enclosed with isolation characters” :)
I'm with you that it's better to not let translators struggle with it, and make it the “by default” thing.
Jul 12 2018
In https://git.reviewboard.kde.org/r/127800/, @ilic wrote:
Jul 3 2018
Jun 19 2018
This is a change that would greatly benefit from an auto test, sadly we don't have to have any in lokalize.
Jun 15 2018
In D13219#278789, @ltoscano wrote:https://api.kde.org/frameworks/ki18n/html/index.html references the programmer's guide:
https://api.kde.org/frameworks/ki18n/html/prg_guide.html
In D13219#278776, @huftis wrote:I’m actually not sure how KDE’s i18n stuff is actually supposed to work now. The official(?) tutorial at https://techbase.kde.org/Development/Tutorials/Localization/i18n seems severely outdated (e.g., it talks a lot about KLocale stuff).
In D13219#271124, @aacid wrote:I'm not too thrilled about this to be honest, seems that this is something i18n should be doing by default, pinging @ilic to see what he would think about fixing/expanding ki18n to do "the right thing" by default
Jun 13 2018
In T8984#147453, @aacid wrote:I already disagreed that method is the correct solution, so no it's not "the same way"
I already disagreed that method is the correct solution, so no it's not "the same way"
In T8984#147444, @aacid wrote:You mean changing every single i18n() call that uses a placeholder? or something else?
I would like to discuss if we should enclose every placeholder used in KI18n with the two isolation characters
In D10009#265704, @aacid wrote:I'm going to add a Needs changes here to remind myself to review this, given that meskobalazs is not a kde/lokalize developer i don't think it was a good idea of him marking this as accepted.
Jun 11 2018
Closed by https://commits.kde.org/lokalize/c1fd23b55999974e50cfda299c55753796f81f31. (I don’t know why arc land didn’t close this automatically.)
Jun 9 2018
Jun 8 2018
In D13411#275934, @aacid wrote:Maybe give it a few days before pushing in case someone objects or finds a better name for Incomplete.
I'm not convinced "Incomplete" is the best name, but people will understand what it means quickly so i think this can go in.
I’ve now (hopefully) changed this to land on master
instead of stable.
Jun 7 2018
You can't add new features to a stable branch
Jun 5 2018
In D13219#273311, @aacid wrote:
Jun 3 2018
In D13219#273109, @safaalfulaij wrote:https://bugs.kde.org/show_bug.cgi?id=388642
Just saying... :)
Just saying... :)
But 2018 is not a number, it's a year ;)
May 31 2018
In D13098#270898, @huftis wrote:Thank you. lokalize --reverse works for me. I’ve now modified the behaviour so that the numeric columns are right-aligned for *both* RTL and LTR languages: https://cgit.kde.org/lokalize.git/commit/?id=83590be3996e2c2013f69ce8a850f508c4db9d53
In D13219#271124, @aacid wrote:I'm not too thrilled about this to be honest, seems that this is something i18n should be doing by default […]
May 30 2018
I'm not too thrilled about this to be honest, seems that this is something i18n should be doing by default, pinging @ilic to see what he would think about fixing/expanding ki18n to do "the right thing" by default
Note that I’ve tried making a similar change for the numeric columns in the table in the project view, but this broke sorting (and I don’t know how to fix it), so it’s not included in this patch.
In D13098#270610, @safaalfulaij wrote:In D13098#270465, @huftis wrote:I get some Arabic-looking digits in the four translation count columns, but they are left-aligned (before the patch). But they should be right-aligned?
I'm not entirely sure how this works for English base system.
Normally you would do lokalize --reverse and check the RTL layout. This should keep everything in English but simulate a RTL language being used.
In D13098#270465, @huftis wrote:Hm, I’m trying to test this, but I’m not sure how I can get a RTL layout. If I run
LC_ALL=ar_en.UTF-8 lokalizeI get some Arabic-looking digits in the four translation count columns, but they are left-aligned (before the patch). But they should be right-aligned?
May 29 2018
In D13098#270053, @safaalfulaij wrote:Sorry for reaching late.
This is a nice imporovment, it just needs one bit to work with RTL layouts as well :)
Right now, and before this patch, it's being displayed correctly (aligned to right).
Sorry for reaching late.
This is a nice imporovment, it just needs one bit to work with RTL layouts as well :)
Right now, and before this patch, it's being displayed correctly (aligned to right).
May 28 2018
May 27 2018
I’ve used @aacid’s suggestion, and now ProjectModel::data() calls ProjectModel::headerData(), to ensure that the column alignment is consistent between column headers and column data.
May 24 2018
Looks good to me, if you want to make sure header and data alignment is the same maybe you can find a way to only have one switch instead of two (i.e. make data call headerData or viceversa or make them both call a new function) that way we enforce they're the same.
Oh haha! Sounds like you're the alignment expert. UI looks good to me.
In D13098#267949, @ngraham wrote:Column data itself looks much improved!
However, this makes the headers themselves inconsistently aligned, which will lead to bug reports of another sort (see for example https://bugs.kde.org/show_bug.cgi?id=394467). Perhaps we should also center-align all the header titles, as with the fix for that bug?
Column data itself looks much improved!
May 20 2018
I'm going to add a Needs changes here to remind myself to review this, given that meskobalazs is not a kde/lokalize developer i don't think it was a good idea of him marking this as accepted.
Apr 20 2018
yeah i think that's easier to understand