- Queries
- All Stories
- Search
- Advanced Search
All Stories
Dec 10 2018
In T10176#169931, @awilcox wrote:I'd recommend alphabetising the list.
Thank you for the unit test.
It may be easier to read if you have the data() then the corresponding test() function instead of having all the data() and at the end the test() functions (when you read one test, you'll just have to scroll above to know which data is tested)
Abandoning this change in that case.
more simplifications
The current master is fontconfig only, since there is no way to leave the fontconfig specific parts out of QML.
It's not clear who wrote that about being fontconfig specific (or the IMHO incorrect suggestion that Freetype is implemented 3x).
- Modernize unit tests to data driven testing
In D17483#374857, @bshah wrote:Sorry for this, me and @mart did realize that this was pushed too early. If you prefer, we can revert Kirigami part.
ToolButton code path is broken on mobile and makes it not visible at all so that is needed.
- This needs screenshots. :)
- Don't you think it's premature to submit code before we've settled on what it is we actually want? I don't see any consensus in T7927. Personally I am not at all sold on the idea of presenting users with ten font rendering options and expecting them to be able to choose their favorite. The differences between most of them are minuscule and seem all but impossible for someone who's not a font nerd to distinguish. The idea of visual previews seems sound, but I think we would need to limit them to choices that lay people actually have a chance of understanding and distinguishing between.
Could you also extend the unit test in autotest/input/highlight.d?
It's not clear who wrote that about being fontconfig specific (or the IMHO incorrect suggestion that Freetype is implemented 3x).
okay, @sredman , will do.
In D17441#374925, @ngraham wrote:In D17441#374924, @dhaumann wrote:I guess it's ok to have this in. But please use this version at your daily work ;) I think we don't have many testers...
I always use Kate from git master. Is there anything in particular I should keep an eye out for?
In D17250#374937, @brute4s99 wrote:Since I've changed the identifier for the strings in every translation, it will not give any errors. I can post some Screenshots with other languages if you'd like!
Since I've changed the identifier for the strings in every translation, it will not give any errors. I can post some Screenshots with other languages if you'd like!
Use addItem.
EDIT: I don't agree with how jealously Plasma keep these to themselves, some KCMs certainly make sense across all platforms and I maintain Mac packaging for them. But you just don't get to justify changes because of Mac or MS Windows and at the same time claim the software in question is out of limits there ;)
kcm fonts is fontconfig specific. (It's even non-tirival to translate rendering options from fontconfig terminology to freetype, which is in fact separately implemented in libXft, Qt and pango)
Thanks!
In D17250#374909, @sredman wrote:In D17250#374887, @brute4s99 wrote:Updated the diff to reflect just the relevant changes for this commit.
Looks good from this point of view. Thanks!
@nicolasfella, do you know whether changing the names of the strings in strings.xml will mess up the translators? If so, we should probably not touch those. It will make our code a little strange but it would save a lot of hassle on their end.
- Rephrase statement
In D17441#374924, @dhaumann wrote:I guess it's ok to have this in. But please use this version at your daily work ;) I think we don't have many testers...
Why not make these separate KCMs?
I guess it's ok to have this in. But please use this version at your daily work ;) I think we don't have many testers...
IMHO it's better if you use the addItem(name, data) API, storing the name of each plugin in the combobox. Then it's easy to fetch the data of the selected item.
Also, the use of QOverload does not belong to this i18n fix, so it needs to be a separate patch.
Looks good, please commit. With these kind of changes, we soon support up to 2^64 lines in a document? ;)
Remove unused code.
In D17250#374887, @brute4s99 wrote:Updated the diff to reflect just the relevant changes for this commit.