Re: Review Request 127253: [KUnitConversion] Add ILS (Israeli New Shekel) currency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127253/#review94450 --- Ship it! Ship It! - John Layt On April 7, 2016, 10:53 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127253/ > --- > > (Updated April 7, 2016, 10:53 p.m.) > > > Review request for KDE Frameworks, John Layt and Wolfgang Bauer. > > > Bugs: 336016 > https://bugs.kde.org/show_bug.cgi?id=336016 > > > Repository: kunitconversion > > > Description > --- > > This adds the "Isreali New Shekel" currency to KUnitConversion. > > Patch originally from Wolfgang Ludwig in the linked bug report but adjusted > to Frameworks 5. > > Added the new unit to the end of the enum for compatibility reasons. > > > Diffs > - > > src/currency.cpp 3b99644 > src/unit.h 60e849f > > Diff: https://git.reviewboard.kde.org/r/127253/diff/ > > > Testing > --- > > When I type "5 ILS" into KRunner it spits out correct results, same for "5 > sheqel" > > > Thanks, > > Kai Uwe Broulik > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 127253: [KUnitConversion] Add ILS (Israeli New Shekel) currency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127253/#review94443 --- - John Layt On April 7, 2016, 10:53 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127253/ > --- > > (Updated April 7, 2016, 10:53 p.m.) > > > Review request for KDE Frameworks, John Layt and Wolfgang Bauer. > > > Bugs: 336016 > https://bugs.kde.org/show_bug.cgi?id=336016 > > > Repository: kunitconversion > > > Description > --- > > This adds the "Isreali New Shekel" currency to KUnitConversion. > > Patch originally from Wolfgang Ludwig in the linked bug report but adjusted > to Frameworks 5. > > Added the new unit to the end of the enum for compatibility reasons. > > > Diffs > - > > src/currency.cpp 3b99644 > src/unit.h 60e849f > > Diff: https://git.reviewboard.kde.org/r/127253/diff/ > > > Testing > --- > > When I type "5 ILS" into KRunner it spits out correct results, same for "5 > sheqel" > > > Thanks, > > Kai Uwe Broulik > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 127253: [KUnitConversion] Add ILS (Israeli New Shekel) currency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127253/#review94365 --- src/unit.h (line 158) <https://git.reviewboard.kde.org/r/127253/#comment64162> Err, obviously I mean be BC, not BIC... - John Layt On March 2, 2016, 1:17 a.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127253/ > --- > > (Updated March 2, 2016, 1:17 a.m.) > > > Review request for KDE Frameworks, John Layt and Wolfgang Bauer. > > > Bugs: 336016 > https://bugs.kde.org/show_bug.cgi?id=336016 > > > Repository: kunitconversion > > > Description > --- > > This adds the "Isreali New Shekel" currency to KUnitConversion. > > Patch originally from Wolfgang Ludwig in the linked bug report but adjusted > to Frameworks 5. > > Added the new unit to the end of the enum for compatibility reasons. > > > Diffs > - > > src/currency.cpp 3b99644 > src/unit.h 9e17624 > > Diff: https://git.reviewboard.kde.org/r/127253/diff/ > > > Testing > --- > > When I type "5 ILS" into KRunner it spits out correct results, same for "5 > sheqel" > > > Thanks, > > Kai Uwe Broulik > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 127253: [KUnitConversion] Add ILS (Israeli New Shekel) currency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127253/#review94364 --- One correction to the enum. src/unit.h (line 158) <https://git.reviewboard.kde.org/r/127253/#comment64161> This can be added to the end of the Currency group and still be BIC, that's why each group is hard-coded to start at a 1000 interval. - John Layt On March 2, 2016, 1:17 a.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127253/ > --- > > (Updated March 2, 2016, 1:17 a.m.) > > > Review request for KDE Frameworks, John Layt and Wolfgang Bauer. > > > Bugs: 336016 > https://bugs.kde.org/show_bug.cgi?id=336016 > > > Repository: kunitconversion > > > Description > --- > > This adds the "Isreali New Shekel" currency to KUnitConversion. > > Patch originally from Wolfgang Ludwig in the linked bug report but adjusted > to Frameworks 5. > > Added the new unit to the end of the enum for compatibility reasons. > > > Diffs > - > > src/currency.cpp 3b99644 > src/unit.h 9e17624 > > Diff: https://git.reviewboard.kde.org/r/127253/diff/ > > > Testing > --- > > When I type "5 ILS" into KRunner it spits out correct results, same for "5 > sheqel" > > > Thanks, > > Kai Uwe Broulik > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KHolidays as Framework (redux)
Hi, It's xmas holidays, so it must be time to poke a stick at KHolidays again for inclusion as a Framework. As far as I am aware there are no outstanding porting issues with KHolidays and it is ready for review to be included as a Tier 1 Framework in the next possible release. What's the next step? Move to kdereview? There is the one issue with increasing the .so number to 6 that has been raised for all the former kdepimlibs, what was the general consensus about that? John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125343: bump so version from 5 to 6
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125343/#review85736 --- Will have a proper look when I get home tonight, what was the so number when released as part of kdepimlibs4? Was it 4 or 5? If 4 then we can stay at 5 as KHolidays has never been officially released for KF5? Or will we get this issue with every PIM library that was in the unofficial release? (And there were more abi changes than just the removal of the widget). - John Layt On Sept. 22, 2015, 9:02 a.m., Harald Sitter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125343/ > --- > > (Updated Sept. 22, 2015, 9:02 a.m.) > > > Review request for KDE Frameworks, Daniel Vrátil and John Layt. > > > Repository: kholidays > > > Description > --- > > since Applications/15.08 KHolidays::HolidayRegionSelector was removed > constituting an incompatible change. > > > Diffs > - > > CMakeLists.txt ebd4b8981a658665a42140250b6eb3d92662e607 > > Diff: https://git.reviewboard.kde.org/r/125343/diff/ > > > Testing > --- > > > Thanks, > > Harald Sitter > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Proposal to improving KDE Software Repository Organization
On 16 August 2015 at 11:14, David Faure wrote: > (*) I keep finding the "division" term a bit obscure, and I wonder if this > shouldn't be > called "product" instead. I.e. matching how we release things. Nowadays we > basically have 4 products (frameworks, plasma, applications, extragear?), > previously we had 2 (KDE SC 4, extragear). If this is what you had in mind > with divisions, then I suggest to call it product for clarity. > The reason why I think it's the same concept is that the one reason to have > different tracks is exactly because of different release schedules (e.g. > plasma > could be tested against KF5/Stable (last release) and KF5/Devel (more recent > code)) [Rambling naming bikeshed alert !] TLDR: We have a Marketing View and we have a Technical Build View and I think they are different enough to have different names and structures. How about we call 'division' something like 'build-group' or 'build-unit' instead? And while we're busy regrouping and renaming things, lets get rid of the application Modules... Longer: I like Product too, which is why I'm using it in the new TechBase KF5 Getting Started docs I started writing today [1] and especially [2], but I don't see it as being the same thing as 'division' here, and I think it exposes again a problem in our organisation and naming of Applications. My marketing-oriented view is we are organised as 3 Products: * KDE Frameworks * KDE Plasma * KDE Applications (We could add other products like 'KDE Infrastructure' and KDE Servers', but they're mostly internal). Within KDE Applications we then have a confusing mixture of Modules, Projects and standalone Applications with different porting status and release cycles: * Edu Module * Games Module * PIM Module * Playground Module * Review Module * Extragear Module * Calligra Suite * GCompris * etc... Now, some may argue that some of those are actually Products in their own right, e.g. Calligra and Extragear and GCompris, but they are Applications developed by the KDE Community within the KDE Infrastructure and adhering to the KDE Manifesto, they are all by definition KDE Applications, just with different development status or release cycles. 'division' appears slightly different to me, it is about grouping things into standalone build dependency units, so Calligra and GCompris do appear to belong at that level. OTOH, do we really want every repo in Extragear or Playground to have their own top-level 'division' just because they have different release cycles or different porting status or different version dependencies? Even the official KDE SC4 modules all have different porting status and thus build dependencies and thus conceivably different 'divisions'. That would just be too messy. I think how they get grouped into 'divisions' is always going to be different than the marketing Products and Modules. Alternative names that spring to mind are 'build-unit' or 'build-group'. Personally I think the whole Playground/Review/Applications/Extragear/Unmaintained module level split needs to go away and all Applications be considered equal, just with a different release status metadata tag based on the official lifecycle [3]. It's just reflecting the reality of the git-based split up of modules, different release cycles, death of a number of our sub-communities, and a more-focussed view on what makes up the workspace/applications split and their different release cycles. So, a proposal: we drop modules and extragear and playground and unmaintained altogether for organising our repos and paths and build process and instead just have Applications with a 'release-status' tag marking where they are in our official KDE Application Lifecycle [3]. A second 'release-cycle' tag could identify those that are to be included in the regular KDE Applications release cycle. We can still sort-of keep module, but now it's more a category tag, so all edu apps live under the path apps/edu/*. This could also remove some hassle when apps move around, their place in the namespace hierarchy and path doesn't change, just their release status tag. John. [1] https://techbase.kde.org/KF5/Getting_Started [2] https://techbase.kde.org/KF5/Getting_Started/Source_Code [3] https://techbase.kde.org/Policies/Application_Lifecycle ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Default page size now missing
On 29 July 2015 at 22:43, Jaroslaw Staniek wrote: > Hi, > While looking at possible improvements of QPageSize (with John), > another finding: > Defaults for page size for KDE SC 4 apps come from the locale based on > KLocale and specific config value. Now in QLocale we miss this > information. QPrinterInfo::defaultPrinter().defaultPageSize() is > something different, it more depends on the default printer, its > defaults and capabilities. > > For example, traditionally, USA has "Letter" as default and some other > countries have "A4". > > > The thing is that the default page size is also used for creation of > documents (ODF, PDF...). > > Any ideas on how to address that in apps that don't use > kdelibs4support? And maybe in KF5 and/or Qt. > And do we want to address that? > Even if Plasma 5 offers this config to the user, apps will ignore it > one day when they from usage of kdelibs4support. That could be > misleading. > > Personally I am copying the one-liners from kdelibs4support as a > temporary solution: if a given config value is found, it's used. > > -- > 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 The KLocale default page size was actually used in very very few places, and usually by mistake when they really wanted the default printer paper size to render a print-out to, leading to lots of issues with printers complaining about the wrong paper size. Allowing it to be set in KLocale led to a lot of user confusion on the difference between the two, there are some long and rather ugly bugzilla threads on the matter I do not wish to revisit. I'd also argue that the default page size needed for one app is not necessarily the same as for some other apps, depending on their use case. Writing a letter I probably do want A4, doing a flow-chart I usually want A3, doing a presentation I want projector screen 4:3 ratio, doing a painting in Krita it's whatever size the artwork needs. I'd rather not reintroduce all that, instead most use cases should check the default printer page size to render to, or if they do need a page size then if QLocale::measurementSystem() == QLocale::ImperialUSSystem use Letter, otherwise use A4 (this is exactly what the KLocale files are set up as, only the USA isn't A4, and PDF printing in Qt does this to choose its default page size too). In Calligra I could see the case for having the ability to set a default page size for your apps to follow as you are in the business of generating new documents with fixed page sizes, but very few other apps actually need to do so (I'm struggling to think of more than lyx), must just want it to print to. I think this belongs in Calligra settings. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On 26 August 2014 11:41, Jonathan Riddell wrote: > > I'd like to suggest taking the opportunity to remove uses of the quite ugly > term PIM in favour of the friendlier Kontact. I would say no. PIM in library names makes sense, especially as we want that others outside KDE-PIM / Kontact will use the PIM Frameworks . It's ugly, but recognised in the techie community. And just as with the other Frameworks, any gui strings need to be neutral as well. Now, KDE-PIM itself is another issue... John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
My general 2c: I'm with Kevin that we should do functional and api reviews, move code around, and generally refactor stuff *before* we split anything. It's just plain easier that way. I don't think we're anywhere near close to knowing what to do with everything to be splitting things yet. Will we also end up with deprecated code in a kdepimlibs4-support, for example? We started a page at https://community.kde.org/Frameworks/Epics/kdepimlibs to document this sort of stuff, it would be good to bring it up-to-date and work through it progressively. We also have Akademy and the sprint scheduled for November (?) at which we could sit down and methodically work through the list of everything and figure out what to do. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPlotting and KUnitConversion
On 10 August 2014 23:20, Garret Wassermann wrote: > I am also curious who is the KUnitConversion maintainer as well. > Similarly, unit conversion software would be fantastic, > however it is missing many units and features. > > I would also be glad to work on either cleaning up KUnitConversion, > or working on a replacement library. I believe I saw on the archives > someone working on KStandards? > > What is the best way to get involved in the KStandards framework > development? I will try to contact the person listed on KUC source code > too but maybe it is more appropriate to post to the mailing list for > feedback from everyone. Hi Garret, I'm the maintainer for KUnitConversion, you can find the maintainer in the metainfo.yaml file in each Framework repo [aside: perhaps we need to generate a page with this listed?]. I'm also the person looking at KStandards, or KCodes as I'm now calling it. For now KCodes will be sticking to the ISO code support and not doing any unit conversion stuff, that's a long way away if at all. At the moment I'm talking to the Wikidata people about improving their ISO code data so we can just become a consumer of their data, rather than having to maintain it on our own. I'm hoping to have that resolved soon and will push the code forward at that point. KUnitConversion does have it's limitations which is why I'm thinking about how to improve or replace it, but that won't happen any time soon so it's best to keep improving it in the meantime. The main thing I dislike is every unit regardless of category being in a single enum, which can lead to nonsense like trying to convert 1 meter in degrees Celsius. That's a version 2 fix though, and in the meantime there's other things to work on, like removing the dependency on ki18n and using Qt tr instead. You say there are units and features you need that we don't support? The obvious place to start is to implement those in the existing library so we understand them better if once we get around to designing a new api. The best place to discuss these is always here on list, so can you say what it is you are missing? Once we've discussed any new features, you can then code them and submit the patches to our ReviewBoard so I can review them. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Web Shortcuts KCM
On 14 July 2014 11:46, David Faure wrote: > On Monday 14 July 2014 12:34:44 Eike Hein wrote: >> Hi David, >> >> I'd like to port the ebrowsing KCM and move it to >> plasma-desktop or -workspace, since it has plenty >> of users outside of Konq (e.g. Konvi, Konsole and >> Okular, the first two of which have ports now). >> >> Thoughts? > > The whole split between workspace and applications seems to generate more > issues than we thought. we're going to miss a place for shared runtime > deps. > > If someone uses konvi, konsole, okular, or konqueror outside of plasma- > workspace, (e.g. in gnome, Mac or Windows), then they are not going to be able > to configure cookies, internet keywords, useragent, proxies . if these > things are part of the workspace. > > Given that the kurifilter plugins themselves are in KIO for this same reason, > maybe the ebrowsing and the kio (cookies,proxies,useragent) KCMs should go > into KIO as well? Over on the Windows list we've been discussing about KCM's for configuring common services/frameworks like this when running apps under non-Plasma desktops, including Gnome, Windows, Mac, etc. General gist is that we don't want to have systemsettings installed in non-Plasma platforms to gain access to them, so they need to be accessed through the apps config dialog or help menu instead. This implies a few things: 1) That the KCM's are located somewhere easily packaged for stand-alone app installers to include 2) That an app can figure out what KCM's it needs access to when running non-native 3) That at runtime the app can detect it is running in non-native mode and find and load the required external KCMs that it needs Preferably this would all be as automated as possible. The obvious place for the KCM's to live would be in the Framework that they configure, but we have to think how that would affect the dependency tree. Tier 1 is fine, as it can't use KConfig anyway (but how then do they handle config, if any need to?). Tier 3 is fine, as it can depend on KConfigWidgets/KCMUtils, albeit at the cost of a more complicated dependency diagram. Tier 2 could be an issue, as it cannot depend on KConfigWidgets/KCMUtils. For those we'd need separate repos (yet more repos?) or one shared repo (at the expense of more dependencies and installing extra stuff you may not need for your app), or perhaps a configure flag that enables building the KCM if you need it (a disable flag may be a good idea at Tier 3?). Thoughts? John. P.S. This and other cross-platform issues that need work are listed at https://community.kde.org/KDE_Applications/Cross_Platform_Issues ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
On 9 July 2014 06:14, Kevin Ottens wrote: > Hello, > > On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote: >> On 9 July 2014 03:30, Kevin Ottens wrote: >> > * ervin hopes to see kdepimlibs bits getting in sooner rather than later; >> >> Hmm? Sysadmin has already received a request to get the frameworks >> branch of kdepimlibs building on the CI system to allow for KMyMoney's >> frameworks branch to be built. I thought this was already underway? > > There's work underway of course. Laurent is very instrumental there. But > there's still a long way to go AFAIK. Having a branch that builds is a first > step, but then splitting the repository will be necessary, figuring out which > parts of kdepim-runtime will go with which part of kdepimlibs, organizing the > splitted repositories so that they follow the existing policies, etc. > > It's pretty much the kdelibs/kde-runtime work again, it shouldn't be > underestimated. I've had clarification from Montel, and indeed the schedule has been moved up due to there being no 4.15, so now after 4.14 in say September/October time frame. We have a PIM Sprint planned for November in Munich when I guess the Frameworks planning will be the main focus. The Frameworks branch does build, has many build fixes applied to it for KF5 and gets regular merges from master. However we're still doing new features and bug fixes in kdepimlibs as needed for improvements to the apps, hence the reluctance to split it off before necessary. I think many of the libs are already fairly standalone, but others will need considerable restructuring. A few like KHolidays could be split off and released almost immediately, others will take much longer. The really big hurdle for pimlibs will be removing KDateTime/KTimeZone/KLocale usage which is substantial work. There's some initial work towards the split at [1]. Cheers! John. [1] https://community.kde.org/Frameworks/Epics/kdepimlibs ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
On 8 July 2014 16:30, Kevin Ottens wrote: > * he'd like our documentation to improve, we're really behind alternatives in > that regard; Seconded, especially from the point-of-view of external devs. For example, someone today was asking about KArchive and whether it was fully standalone or depended on external libs that they needed to ship on non-Linux platforms, but the apidocs don't mention the dependencies anywhere. We need to document every single library from the point of view of someone completely new to KDE who just wants one single library in their Qt app. Do we have a single home page or landing point that we want all potential users to start from? Do we have general docs to point to about build chain, licences, getting help, etc? We have the community wiki but it is not meant to be for that purpose, and the apidox main page may be too static to keep up with FAQs, so we probably need to create some TechBase pages. Actually, TechBase is really going to need a big review. > * he'd like to see a donation button in KDE apps based on KF5 (developers > could opt-out); We already have a link to the donations page buried deep in the "About KDE" dialog under the "Support KDE" tab where no-one ever sees it. A Help menu item for "Donate to KDE..." that pops up a dialog explaining why would be far more visible, but easily disabled by distros who object. We could also include a "Donate to KDE" tip in every KTipDatabase and ensure it's the first tip shown by default on an apps first run. As an admin note, whenever we do add a donate link anywhere we should make it unique so that we can track how successful each channel is. > * ervin hopes to see kdepimlibs bits getting in sooner rather than later; I asked on the PIM list the other day, Montel says the plan is not to start on frameworks until after 4.15, so maybe March/April next year? I think he meant porting the PIM applications though, so I'm not sure what that means for starting on pimlibs. I'll follow up. My plans: * Write proper docs for KUnitConversion * Make KUnitConversion Tier 1 by switching to Qt translations * In advanced planning for replacements for ISO codes and flag images, even have some code, see https://community.kde.org/KDE_Core/KDE_Open_Data ** OpenCodes: repo of json files of ISO data auto-extracted from Wikidata, CC-0, can be used by anyone ** KCodes: Qt library which loads OpenCodes files ** OpenFlags: repo of SVG flag images auto-extracted from Wikidata, with icon set auto-generated from SVGs Here's a bit of bike-shedding for you: when creating completely new Frameworks in Tier 1, do we name them with a Q or with a K or with something completely neutral? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Locale Name Primer
Locale Names.
A quick primer on Locale Names, seeing as we've had a few issues in
the last couple of days. I can't claim perfect knowledge, so feel free
to point out where I am wrong :-)
TL;DR:
* Don't use QLocale::bcp47Name().
* Use QLocale::name(), but may need to modify the results.
* You usually want QLocale().name() and not QLocale::system().name()
* Don't assume language code is alpha-2, it may be alpha-3
* Always use case insensitive comparisons.
* I'll improve support in Qt 5.4.
POSIX Locale:
* What we use on Linux systems and in glibc.
* Format is "lang_REGION.encoding@variant".
* How many of those componants are included can depend on the system
or implementation. In most cases the language and region are always
included, with the encoding and variant optional.
* lang is ISO 639 alpha-2 or alpha-3 (so QLocale().name().left(2) is
not valid!) , usually in lower case
* REGION is ISO 3166 alpha-2, usually in upper case
* Many distros explicitly add .utf8 or .UTF-8 for Unicode, e.g. on
openSUSE "en_GB.utf8" uses UTF-8 but "en_GB" uses ISO-8859-1.
* The variant is usually used to change the script, but doesn't use an
ISO code for this e.g. "sr_RS" uses Cyrillic script but "sr_RS@latin"
uses Latin script
* The variant can change other options like the currency, e.g. "de_DE@euro"
* Always use case-insensitive comparison as case of codes is meaningless
* Run "locale -a" to see what your distro has installed
BCP47 Locale:
* IETF RFC, used in Unicode, W3C standards, etc.
* Used in Windows Vista and later, where it replaces the old LCID.
* Basic format is "lang-Script-REGION-variants-extensions"
* Always uses hyphen as a subtag separator
* Always uses minimum subtags required to uniquly identify locale,
e.g. "de-Latn-DE" will be reduced to "de" as Latn and DE are the
assumed defaults.
* lang is ISO 639 alpha-2 or alpha-3 code, usually in lower case
* Script is ISO 15924 alpha4 code usually in title case
* REGION is ISO 3166 alpha 2 code, usually in upper case
* variant are registered variant codes
* extensions are registered extension codes
* Always use case-insensitive comparison as case of codes is meaningless
Qt 5.3 support:
* name() always returns "lang_REGION", except where AnyCountry is set
or C, never returns encoding or variant
* bcp57Name() returns the minimal BCP47 name
* No direct may to get lang or country code, need to use
"QLocale().name().split('_').at(x)"
Needed in Qt 5.4:
* languageCode()
* countryCode()
* scriptCode()
* posixName()
* encoding?
Cheers!
John.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118564: Fix locale-aware reading in KDesktopFile
> On June 6, 2014, 12:21 p.m., John Layt wrote:
> > src/core/kconfig.cpp, line 98
> > <https://git.reviewboard.kde.org/r/118564/diff/1/?file=279088#file279088line98>
> >
> > The bcp47Name() is a complicated beast that could add lots of other
> > bits on like script to use, etc. I would stick with name() as it is
> > documented in Qt to always return language_COUNTRY, so
> > "QLocale().name().split('_').at(0)". I'll remember to add the needed
> > languageCode() api for QT 5.4.
>
> Matthew Dawson wrote:
> Not that this would block, but I was trying to understand this when I saw
> the RR. I was reading this page:
> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s04.html ,
> which would suggest that we should take the full version and search more
> specifically. Is my reading of this correct?
>
> I was actually wondering if bcp47Name() was correct, as it appears to be
> similar to Posix. It's just that KConfig doesn't search the file correctly.
> Am I correct there? Is there a better QLocale function to get something more
> Posix correct? I'm new to dealing with internationalization, so I apologize
> for stupid questions.
>
> Regardless, this won't block the patch. I rather have 90% functionality
> working then 20% that is more "correct".
I haven't had time to dig further yet, but it did occur to me that just the
"de" was wrong, from what I remember of other desktop files from KDE4 we used
the full locale code. Your link confirms the standard allows for full POSIX
locales in all their variations to work, so we may need a lot more code here
(what did the KDE4 code do?). However, that said, the POSIX standard
explicitly says locale codes should always have the country included, and if
you look at the POSIX locales installed on any modern Linux they all have the
country, so when writing we should always be using name(), so the matching read
should always be using name(). For example, anything generated within KDE's
translation system should be using name() when writing which will have the
country included.
The BCP47 name is almost always the wrong format to use, it's mostly useful on
Windows, for a start it uses "-" in some places where POSIX uses "_", and more
importantly it drops parts of the locale that it considers redundant, i.e.
returning "de" rather than "de_DE" as it assumes DE is the default country and
so not needed, whereas POSIX always requires the country to be added.
See also https://git.reviewboard.kde.org/r/118584/ where we're incorrectly
using bcp47Name() to set the system locale, which may be causing us to write
the incomplete locale to the desktop file. I think we need to check the whole
code base to confirm the bcp47Name() isn't being used anywhere else incorrectly.
Note that QLocale's name() is not fully POSIX compliant, it never adds encoding
or modifiers, but I'm working on that.
- John
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118564/#review59415
---
On June 6, 2014, 12:43 p.m., Martin Gräßlin wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118564/
> ---
>
> (Updated June 6, 2014, 12:43 p.m.)
>
>
> Review request for KDE Frameworks and John Layt.
>
>
> Repository: kconfig
>
>
> Description
> ---
>
> Fix locale-aware reading in KDesktopFile
>
> The underlying KConfig used QLocale::name() for getting the locale
> aware part. But this returns "de_DE" while the desktop files store
> "de".
>
> In addition it constructs a QLocale object instead of using the
> system locale. This has the advantage that the usage of
> QLocale::setDafault() gets honored by KConfig.
>
>
> Diffs
> -
>
> autotests/kconfigtest.cpp 2b6de0d7d63df6aee69210aa09418628f0b8110a
> autotests/kdesktopfiletest.h d57351fd6edcefd6a0efd9126e454546cfc63b55
> autotests/kdesktopfiletest.cpp 494a43c0fb5808a261b9beb56cdc4afd8580ab21
> src/core/kconfig.cpp ea9746c001e235529a1cdd5865b9e1b5c129b56a
>
> Diff: https://git.reviewboard.kde.org/r/118564/diff/
>
>
> Testing
> ---
>
> added unit test failed before. I'm not 100 % sure whether using bcp47Name is
> correct.
>
>
> Thanks,
>
> Martin Gräßlin
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118564: Fix locale-aware reading in KDesktopFile
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118564/#review59415
---
src/core/kconfig.cpp
<https://git.reviewboard.kde.org/r/118564/#comment41384>
The bcp47Name() is a complicated beast that could add lots of other bits on
like script to use, etc. I would stick with name() as it is documented in Qt
to always return language_COUNTRY, so "QLocale().name().split('_').at(0)". I'll
remember to add the needed languageCode() api for QT 5.4.
- John Layt
On June 5, 2014, 1:16 p.m., Martin Gräßlin wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118564/
> ---
>
> (Updated June 5, 2014, 1:16 p.m.)
>
>
> Review request for KDE Frameworks and John Layt.
>
>
> Repository: kconfig
>
>
> Description
> ---
>
> Fix locale-aware reading in KDesktopFile
>
> The underlying KConfig used QLocale::name() for getting the locale
> aware part. But this returns "de_DE" while the desktop files store
> "de".
>
> In addition it constructs a QLocale object instead of using the
> system locale. This has the advantage that the usage of
> QLocale::setDafault() gets honored by KConfig.
>
>
> Diffs
> -
>
> autotests/kdesktopfiletest.h d57351fd6edcefd6a0efd9126e454546cfc63b55
> autotests/kdesktopfiletest.cpp 494a43c0fb5808a261b9beb56cdc4afd8580ab21
> src/core/kconfig.cpp ea9746c001e235529a1cdd5865b9e1b5c129b56a
>
> Diff: https://git.reviewboard.kde.org/r/118564/diff/
>
>
> Testing
> ---
>
> added unit test failed before. I'm not 100 % sure whether using bcp47Name is
> correct.
>
>
> Thanks,
>
> Martin Gräßlin
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KUnitConversion apidox
Hi, I've just noticed that the KUnitConversion api dox at http://api.kde.org/frameworks-api/frameworks5-apidocs/kunitconversion/html/index.html does not have a class list available not the individual classes. Have I missed something? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117888: Move KCurrencyCode to kdelibs4support
> On April 30, 2014, 1:29 p.m., Alex Merry wrote: > > Well, it looks like nothing that has been ported is using it (and barely > > anything that hasn't been ported ever used it). > > > > However, it should be marked as deprecated, and the apidocs should > > indiciate how to port away from it. > > > > Also, I disagree that there's nothing interesting in the history. Most of > > the interesting stuff is in the kdelibs history, but that can be grafted on > > if the commit is constructed properly -- in particular, if you keep the > > initial commit from the kunitconversion repository. > > John Layt wrote: > It was used by KLocale, the Locale KCM, KUnitConversion, and the finance > apps like KMyMoney and Skrooge. Klocale still needs it. The old Locale KCM > doesn't need modifying as it already links to kdelibs4support and the > includes don't use the framework name. KUnitConversion no longer uses it > hence the move. The apps are a long way starting from a port. > > Not sure why it should be marked deprecated, isn't that the whole point > of kdelibs4support? I don't see other classes in kdelibs4support like > KLocale marked in that way? For porting there is no alternative to the class > as yet, that's coming in the new KStandards framework I'm writing, but I can > make a note of that. > > I don't know how to do the history move, I had asked on list a few times > for it to be moved but no-one has done so, so I decided it was better to at > least have it moved to the right place before it's too late (i.e. tomorrow). > > Alex Merry wrote: > I can do it for you if you like. > > The advantage of marking it deprecated is that the compiler tells you > about the deprecated usage. Of course, you can just remove KDELibs4Support > from the link targets and then fix the build, but this makes it easier to do > it piecemeal. Things in KDELibs4Support should, in general, be marked > deprecated, but not all of them are. > > Alex Merry wrote: > Merge done, and files removed from KUnitConversion. Thanks Alex! - John --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117888/#review56981 --- On May 4, 2014, 9:29 p.m., John Layt wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117888/ > --- > > (Updated May 4, 2014, 9:29 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kdelibs4support > > > Description > --- > > KCurrencyCode is not needed in KUnitConversion and imposes an unneeded > dependency on KConfigCore, so move it to kdelibs4support back with the > rest of KLocale. Note no attempt has been made to move the history as > there was nothing of significance. > > > Diffs > - > > CMakeLists.txt ff8199e8b80078d40b403800230448ad1a7c85c9 > data/CMakeLists.txt PRE-CREATION > data/currency/CMakeLists.txt PRE-CREATION > data/currency/adf.desktop PRE-CREATION > data/currency/adp.desktop PRE-CREATION > data/currency/aed.desktop PRE-CREATION > data/currency/afa.desktop PRE-CREATION > data/currency/afn.desktop PRE-CREATION > data/currency/all.desktop PRE-CREATION > data/currency/amd.desktop PRE-CREATION > data/currency/ang.desktop PRE-CREATION > data/currency/aoa.desktop PRE-CREATION > data/currency/aon.desktop PRE-CREATION > data/currency/ars.desktop PRE-CREATION > data/currency/ats.desktop PRE-CREATION > data/currency/aud.desktop PRE-CREATION > data/currency/awg.desktop PRE-CREATION > data/currency/azm.desktop PRE-CREATION > data/currency/azn.desktop PRE-CREATION > data/currency/bam.desktop PRE-CREATION > data/currency/bbd.desktop PRE-CREATION > data/currency/bdt.desktop PRE-CREATION > data/currency/bef.desktop PRE-CREATION > data/currency/bgl.desktop PRE-CREATION > data/currency/bgn.desktop PRE-CREATION > data/currency/bhd.desktop PRE-CREATION > data/currency/bif.desktop PRE-CREATION > data/currency/bmd.desktop PRE-CREATION > data/currency/bnd.desktop PRE-CREATION > data/currency/bob.desktop PRE-CREATION > data/currency/bov.desktop PRE-CREATION > data/currency/brl.desktop PRE-CREATION > data/currency/bsd.desktop PRE-CREATION > data/currency/btn.desktop PRE-CREATION > data/currency/bwp.desktop PRE-CREATION > d
Re: Review Request 117888: Move KCurrencyCode to kdelibs4support
-CREATION data/currency/lbp.desktop PRE-CREATION data/currency/lkr.desktop PRE-CREATION data/currency/lrd.desktop PRE-CREATION data/currency/lsl.desktop PRE-CREATION data/currency/ltl.desktop PRE-CREATION data/currency/luf.desktop PRE-CREATION data/currency/lvl.desktop PRE-CREATION data/currency/lyd.desktop PRE-CREATION data/currency/mad.desktop PRE-CREATION data/currency/mdl.desktop PRE-CREATION data/currency/mga.desktop PRE-CREATION data/currency/mgf.desktop PRE-CREATION data/currency/mkd.desktop PRE-CREATION data/currency/mlf.desktop PRE-CREATION data/currency/mmk.desktop PRE-CREATION data/currency/mnt.desktop PRE-CREATION data/currency/mop.desktop PRE-CREATION data/currency/mro.desktop PRE-CREATION data/currency/mtl.desktop PRE-CREATION data/currency/mur.desktop PRE-CREATION data/currency/mvr.desktop PRE-CREATION data/currency/mwk.desktop PRE-CREATION data/currency/mxn.desktop PRE-CREATION data/currency/mxv.desktop PRE-CREATION data/currency/myr.desktop PRE-CREATION data/currency/mzm.desktop PRE-CREATION data/currency/mzn.desktop PRE-CREATION data/currency/nad.desktop PRE-CREATION data/currency/ngn.desktop PRE-CREATION data/currency/nio.desktop PRE-CREATION data/currency/nlg.desktop PRE-CREATION data/currency/nok.desktop PRE-CREATION data/currency/npr.desktop PRE-CREATION data/currency/nzd.desktop PRE-CREATION data/currency/omr.desktop PRE-CREATION data/currency/pab.desktop PRE-CREATION data/currency/pen.desktop PRE-CREATION data/currency/pgk.desktop PRE-CREATION data/currency/php.desktop PRE-CREATION data/currency/pkr.desktop PRE-CREATION data/currency/pln.desktop PRE-CREATION data/currency/pte.desktop PRE-CREATION data/currency/pyg.desktop PRE-CREATION data/currency/qar.desktop PRE-CREATION data/currency/rol.desktop PRE-CREATION data/currency/ron.desktop PRE-CREATION data/currency/rsd.desktop PRE-CREATION data/currency/rub.desktop PRE-CREATION data/currency/rur.desktop PRE-CREATION data/currency/rwf.desktop PRE-CREATION data/currency/sar.desktop PRE-CREATION data/currency/sbd.desktop PRE-CREATION data/currency/scr.desktop PRE-CREATION data/currency/sdd.desktop PRE-CREATION data/currency/sdg.desktop PRE-CREATION data/currency/sek.desktop PRE-CREATION data/currency/sgd.desktop PRE-CREATION data/currency/shp.desktop PRE-CREATION data/currency/sit.desktop PRE-CREATION data/currency/skk.desktop PRE-CREATION data/currency/sll.desktop PRE-CREATION data/currency/sos.desktop PRE-CREATION data/currency/srd.desktop PRE-CREATION data/currency/srg.desktop PRE-CREATION data/currency/ssp.desktop PRE-CREATION data/currency/std.desktop PRE-CREATION data/currency/svc.desktop PRE-CREATION data/currency/syp.desktop PRE-CREATION data/currency/szl.desktop PRE-CREATION data/currency/thb.desktop PRE-CREATION data/currency/tjs.desktop PRE-CREATION data/currency/tmm.desktop PRE-CREATION data/currency/tmt.desktop PRE-CREATION data/currency/tnd.desktop PRE-CREATION data/currency/top.desktop PRE-CREATION data/currency/tpe.desktop PRE-CREATION data/currency/trl.desktop PRE-CREATION data/currency/try.desktop PRE-CREATION data/currency/ttd.desktop PRE-CREATION data/currency/twd.desktop PRE-CREATION data/currency/tzs.desktop PRE-CREATION data/currency/uah.desktop PRE-CREATION data/currency/ugx.desktop PRE-CREATION data/currency/usd.desktop PRE-CREATION data/currency/usn.desktop PRE-CREATION data/currency/uss.desktop PRE-CREATION data/currency/uyu.desktop PRE-CREATION data/currency/uzs.desktop PRE-CREATION data/currency/veb.desktop PRE-CREATION data/currency/vnd.desktop PRE-CREATION data/currency/vuv.desktop PRE-CREATION data/currency/wst.desktop PRE-CREATION data/currency/xaf.desktop PRE-CREATION data/currency/xag.desktop PRE-CREATION data/currency/xau.desktop PRE-CREATION data/currency/xcd.desktop PRE-CREATION data/currency/xof.desktop PRE-CREATION data/currency/xpd.desktop PRE-CREATION data/currency/xpf.desktop PRE-CREATION data/currency/xpt.desktop PRE-CREATION data/currency/yer.desktop PRE-CREATION data/currency/yum.desktop PRE-CREATION data/currency/zar.desktop PRE-CREATION data/currency/zmk.desktop PRE-CREATION data/currency/zwd.desktop PRE-CREATION data/currency/zwl.desktop PRE-CREATION src/CMakeLists.txt 1db2612bdc625b7267d31ce773ecfdcddc6ae045 src/kdecore/kcurrencycode.h PRE-CREATION src/kdecore/kcurrencycode.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117888/diff/ Testing --- Thanks, John Layt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117888: Move KCurrencyCode to kdelibs4support
> On April 30, 2014, 1:29 p.m., Alex Merry wrote: > > Well, it looks like nothing that has been ported is using it (and barely > > anything that hasn't been ported ever used it). > > > > However, it should be marked as deprecated, and the apidocs should > > indiciate how to port away from it. > > > > Also, I disagree that there's nothing interesting in the history. Most of > > the interesting stuff is in the kdelibs history, but that can be grafted on > > if the commit is constructed properly -- in particular, if you keep the > > initial commit from the kunitconversion repository. It was used by KLocale, the Locale KCM, KUnitConversion, and the finance apps like KMyMoney and Skrooge. Klocale still needs it. The old Locale KCM doesn't need modifying as it already links to kdelibs4support and the includes don't use the framework name. KUnitConversion no longer uses it hence the move. The apps are a long way starting from a port. Not sure why it should be marked deprecated, isn't that the whole point of kdelibs4support? I don't see other classes in kdelibs4support like KLocale marked in that way? For porting there is no alternative to the class as yet, that's coming in the new KStandards framework I'm writing, but I can make a note of that. I don't know how to do the history move, I had asked on list a few times for it to be moved but no-one has done so, so I decided it was better to at least have it moved to the right place before it's too late (i.e. tomorrow). - John --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117888/#review56981 --- On April 29, 2014, 10:24 p.m., John Layt wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117888/ > --- > > (Updated April 29, 2014, 10:24 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kdelibs4support > > > Description > --- > > KCurrencyCode is not needed in KUnitConversion and imposes an unneeded > dependency on KConfigCore, so move it to kdelibs4support back with the > rest of KLocale. Note no attempt has been made to move the history as > there was nothing of significance. > > > Diffs > - > > CMakeLists.txt ff8199e8b80078d40b403800230448ad1a7c85c9 > data/CMakeLists.txt PRE-CREATION > data/currency/CMakeLists.txt PRE-CREATION > data/currency/adf.desktop PRE-CREATION > data/currency/adp.desktop PRE-CREATION > data/currency/aed.desktop PRE-CREATION > data/currency/afa.desktop PRE-CREATION > data/currency/afn.desktop PRE-CREATION > data/currency/all.desktop PRE-CREATION > data/currency/amd.desktop PRE-CREATION > data/currency/ang.desktop PRE-CREATION > data/currency/aoa.desktop PRE-CREATION > data/currency/aon.desktop PRE-CREATION > data/currency/ars.desktop PRE-CREATION > data/currency/ats.desktop PRE-CREATION > data/currency/aud.desktop PRE-CREATION > data/currency/awg.desktop PRE-CREATION > data/currency/azm.desktop PRE-CREATION > data/currency/azn.desktop PRE-CREATION > data/currency/bam.desktop PRE-CREATION > data/currency/bbd.desktop PRE-CREATION > data/currency/bdt.desktop PRE-CREATION > data/currency/bef.desktop PRE-CREATION > data/currency/bgl.desktop PRE-CREATION > data/currency/bgn.desktop PRE-CREATION > data/currency/bhd.desktop PRE-CREATION > data/currency/bif.desktop PRE-CREATION > data/currency/bmd.desktop PRE-CREATION > data/currency/bnd.desktop PRE-CREATION > data/currency/bob.desktop PRE-CREATION > data/currency/bov.desktop PRE-CREATION > data/currency/brl.desktop PRE-CREATION > data/currency/bsd.desktop PRE-CREATION > data/currency/btn.desktop PRE-CREATION > data/currency/bwp.desktop PRE-CREATION > data/currency/byr.desktop PRE-CREATION > data/currency/bzd.desktop PRE-CREATION > data/currency/cad.desktop PRE-CREATION > data/currency/cdf.desktop PRE-CREATION > data/currency/chf.desktop PRE-CREATION > data/currency/clf.desktop PRE-CREATION > data/currency/clp.desktop PRE-CREATION > data/currency/cny.desktop PRE-CREATION > data/currency/cop.desktop PRE-CREATION > data/currency/cou.desktop PRE-CREATION > data/currency/crc.desktop PRE-CREATION > data/currency/cuc.desktop PRE-CREATION > data/currency/cup.desktop PRE-CREATION > data/currency/cve.desktop PRE-CREATION > da
Review Request 117888: Move KCurrencyCode to kdelibs4support
data/currency/lrd.desktop PRE-CREATION data/currency/lsl.desktop PRE-CREATION data/currency/ltl.desktop PRE-CREATION data/currency/luf.desktop PRE-CREATION data/currency/lvl.desktop PRE-CREATION data/currency/lyd.desktop PRE-CREATION data/currency/mad.desktop PRE-CREATION data/currency/mdl.desktop PRE-CREATION data/currency/mga.desktop PRE-CREATION data/currency/mgf.desktop PRE-CREATION data/currency/mkd.desktop PRE-CREATION data/currency/mlf.desktop PRE-CREATION data/currency/mmk.desktop PRE-CREATION data/currency/mnt.desktop PRE-CREATION data/currency/mop.desktop PRE-CREATION data/currency/mro.desktop PRE-CREATION data/currency/mtl.desktop PRE-CREATION data/currency/mur.desktop PRE-CREATION data/currency/mvr.desktop PRE-CREATION data/currency/mwk.desktop PRE-CREATION data/currency/mxn.desktop PRE-CREATION data/currency/mxv.desktop PRE-CREATION data/currency/myr.desktop PRE-CREATION data/currency/mzm.desktop PRE-CREATION data/currency/mzn.desktop PRE-CREATION data/currency/nad.desktop PRE-CREATION data/currency/ngn.desktop PRE-CREATION data/currency/nio.desktop PRE-CREATION data/currency/nlg.desktop PRE-CREATION data/currency/nok.desktop PRE-CREATION data/currency/npr.desktop PRE-CREATION data/currency/nzd.desktop PRE-CREATION data/currency/omr.desktop PRE-CREATION data/currency/pab.desktop PRE-CREATION data/currency/pen.desktop PRE-CREATION data/currency/pgk.desktop PRE-CREATION data/currency/php.desktop PRE-CREATION data/currency/pkr.desktop PRE-CREATION data/currency/pln.desktop PRE-CREATION data/currency/pte.desktop PRE-CREATION data/currency/pyg.desktop PRE-CREATION data/currency/qar.desktop PRE-CREATION data/currency/rol.desktop PRE-CREATION data/currency/ron.desktop PRE-CREATION data/currency/rsd.desktop PRE-CREATION data/currency/rub.desktop PRE-CREATION data/currency/rur.desktop PRE-CREATION data/currency/rwf.desktop PRE-CREATION data/currency/sar.desktop PRE-CREATION data/currency/sbd.desktop PRE-CREATION data/currency/scr.desktop PRE-CREATION data/currency/sdd.desktop PRE-CREATION data/currency/sdg.desktop PRE-CREATION data/currency/sek.desktop PRE-CREATION data/currency/sgd.desktop PRE-CREATION data/currency/shp.desktop PRE-CREATION data/currency/sit.desktop PRE-CREATION data/currency/skk.desktop PRE-CREATION data/currency/sll.desktop PRE-CREATION data/currency/sos.desktop PRE-CREATION data/currency/srd.desktop PRE-CREATION data/currency/srg.desktop PRE-CREATION data/currency/ssp.desktop PRE-CREATION data/currency/std.desktop PRE-CREATION data/currency/svc.desktop PRE-CREATION data/currency/syp.desktop PRE-CREATION data/currency/szl.desktop PRE-CREATION data/currency/thb.desktop PRE-CREATION data/currency/tjs.desktop PRE-CREATION data/currency/tmm.desktop PRE-CREATION data/currency/tmt.desktop PRE-CREATION data/currency/tnd.desktop PRE-CREATION data/currency/top.desktop PRE-CREATION data/currency/tpe.desktop PRE-CREATION data/currency/trl.desktop PRE-CREATION data/currency/try.desktop PRE-CREATION data/currency/ttd.desktop PRE-CREATION data/currency/twd.desktop PRE-CREATION data/currency/tzs.desktop PRE-CREATION data/currency/uah.desktop PRE-CREATION data/currency/ugx.desktop PRE-CREATION data/currency/usd.desktop PRE-CREATION data/currency/usn.desktop PRE-CREATION data/currency/uss.desktop PRE-CREATION data/currency/uyu.desktop PRE-CREATION data/currency/uzs.desktop PRE-CREATION data/currency/veb.desktop PRE-CREATION data/currency/vnd.desktop PRE-CREATION data/currency/vuv.desktop PRE-CREATION data/currency/wst.desktop PRE-CREATION data/currency/xaf.desktop PRE-CREATION data/currency/xag.desktop PRE-CREATION data/currency/xau.desktop PRE-CREATION data/currency/xcd.desktop PRE-CREATION data/currency/xof.desktop PRE-CREATION data/currency/xpd.desktop PRE-CREATION data/currency/xpf.desktop PRE-CREATION data/currency/xpt.desktop PRE-CREATION data/currency/yer.desktop PRE-CREATION data/currency/yum.desktop PRE-CREATION data/currency/zar.desktop PRE-CREATION data/currency/zmk.desktop PRE-CREATION data/currency/zwd.desktop PRE-CREATION data/currency/zwl.desktop PRE-CREATION src/CMakeLists.txt 1db2612bdc625b7267d31ce773ecfdcddc6ae045 src/kdecore/kcurrencycode.h PRE-CREATION src/kdecore/kcurrencycode.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117888/diff/ Testing --- Thanks, John Layt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117864: Move current files from /usr/share/locale/currency/ to /usr/share/locale/currency/kf5/ This allows KF5 to be co-installed with kde-runtime from kdelibs4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117864/#review56905 --- Ship it! Perfect :-) If you merge this, then I'll update my changes to move this stuff into kdelibs4support, and then we can look at doing the same for the country locale files. - John Layt On April 29, 2014, 2:42 p.m., Jonathan Riddell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117864/ > --- > > (Updated April 29, 2014, 2:42 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kunitconversion > > > Description > --- > > Move current files from /usr/share/locale/currency/ to > /usr/share/locale/currency/kf5/ This allows KF5 to be co-installed with > kde-runtime from kdelibs4 > > > Diffs > - > > src/currency/CMakeLists.txt e7ec38d > src/kcurrencycode.cpp 8d6d3ce > > Diff: https://git.reviewboard.kde.org/r/117864/diff/ > > > Testing > --- > > > Thanks, > > Jonathan Riddell > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Maintainers: Please get ready for release
On 29 April 2014 14:16, Alex Merry wrote: > > You are working on a separate branch as that wiki page suggests, right? > It wouldn't surpise me if using the --parent=master option from the > master branch gave you no changes. > I've tried both from the local master branch and a feature branch tracking origin/master, but no joy. However, posting a review from my kunitconversion repo works fine, so its something wrong in the kdelibs4support repo only. > I have my username, password and an option that sets --guess-fields in > my ~/.reviewboardrc, but otherwise just do "rbt post" (which is > equivalent to "post-review" in older version of RBTools). > Using "rbt post" has the same result, but at least has more verbose error messages: One or more fields had errors (HTTP 400, API Error 105) path: error: unable to find 1db2612bdc625b7267d31ce773ecfdcddc6ae045 fatal: git cat-file 1db2612bdc625b7267d31ce773ecfdcddc6ae045: bad file So is something messed with my kdelibs4support copy, or do others get this too? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117864: Move current files from /usr/share/locale/currency/ to /usr/share/locale/currency/kf5/ This allows KF5 to be co-installed with kde-runtime from kdelibs4
> On April 29, 2014, 1:45 p.m., Aleix Pol Gonzalez wrote: > > usually we're going more for kf5/ more than /kf5, meaning > > that those are the files in locale dedicated to currency. Note that > > share/currency is not a standard place anyway, so we are not being backward > > compatible. > > > > Aren't these files being used anywhere else? These and the locale files are transitory, for the life of kdelibs4supprt only (or will be once KCurrencyCode gets moved to kdelibs4support as previously requested/documented), and I think our use of /usr/share/locale is non-standard to start with so I'd rather not put anything there again. Is there a better place to put them, say something like /usr/share/kf5 where they won't get in anyones way and can quietly disappear from when the time comes? Also, as I mailed the lists on a couple of occasions and documented on the wiki for the runtime move, I'd rather this get a proper hierarchy like: kf5/locale/country kf5/locale/currency - John --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117864/#review56893 --- On April 29, 2014, 1:27 p.m., Jonathan Riddell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117864/ > --- > > (Updated April 29, 2014, 1:27 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kunitconversion > > > Description > --- > > Move current files from /usr/share/locale/currency/ to > /usr/share/locale/currency/kf5/ This allows KF5 to be co-installed with > kde-runtime from kdelibs4 > > > Diffs > - > > src/currency/CMakeLists.txt e7ec38d5edfb03aca5ecd41805c612d58bffa8d1 > src/kcurrencycode.cpp 8d6d3ce3229ea0bfcd4f791ad52d560097686a79 > > Diff: https://git.reviewboard.kde.org/r/117864/diff/ > > > Testing > --- > > > Thanks, > > Jonathan Riddell > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Maintainers: Please get ready for release
On 26 April 2014 23:32, Kevin Ottens wrote: > > John Layt: > - kunitconversion > The only thing left is the move of KCurrencyCode back to kdelibs4support. I've now done up patches, but I'm once again bamboozled by Reviewboard and post-review and feel like a total idiot. I should just be able to run "post-review" and it all works thanks to the .reviewboardrc file, right? It creates the review OK but then complains about an error uploading the diff, and trying to use post-review to create a diff file says there are no diffs. Can someone update http://techbase.kde.org/Development/Review_Boardwith the proper magic incantations required? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Fwd: Proposal: Location hackfest
Hi, Please see the below email from Zeeshan Ali of Gnome and GeoClue who is organising a Location hackfest in London in May/June time-frame to get Gnome, KDE, Qt, Mozilla, Jolla and others working together on improving location services on the Linux desktop. If anyone is interested in attending, in particular to work on porting Qt from GeoClue1 to GeoClue2, addressing any missing features in GeoClue2, or to work on cool new desktop features using location, then please contact him directly or add your details to the wiki. Cheers! John. -- Forwarded message -- From: Zeeshan Ali (Khattak) Date: 2 April 2014 17:00 Subject: Proposal: Location hackfest To: John Layt , Aaron McCarthy < aaron.mccar...@jollamobile.com>, Hanno Schlichting Cc: Bastien Nocera , Ekaterina Gerasimova < kittykat3...@gmail.com> Hi everyone, I'm planning a combined hackfest in the spirit of cooperation between our projects to ensure we all have a stable, well-documented and free location infrastructure for both desktops and mobile devices: https://wiki.gnome.org/Hackfests/Location2014 If you folks (or others from your projects) can participate, please add your names on the list and propose date and duration for the event. I'm hoping to organise it mid/late May or sometime in June. Once I know who can join, I can contact our board for making it official and organising the event. Aaaron, From the changelog on geoclue rpm on my Jolla phone, I gathered you are the person to contact about this in your company but if that is not the case, kindly forward this mail to the right person. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117132: Use QLocale for figuring out what languages we're translated into
> On March 28, 2014, 3:43 p.m., David Faure wrote: > > Looks wrong, QLocale looks at .ts/.qm files while we mostly use .po/.gmo > > files - different translation system. > > > > Also doubly wrong because uiLanguages() returns the user preferences (e.g. > > for me "en, fr"), which has nothing to do with "how many languages are > > actually installed" (e.g. there could be about 54). > > Aleix Pol Gonzalez wrote: > Then should we get a method to ask KLocalizedString what languages we > have available for the application. > > In any case entry.desktop files are installed at bulk by kde-runtime, so > it's actually already broken in KDE4. Actually, I get to ask to switch > language and then I get to only choose the one. Yes, QLocale::uiLanguages() returns the list of user preferences, i.e. the LANGUAGE or LC_ALL or LC_MESSAGES or LANG envar on Linux (in order of preference). The list of available KDE translations is different. KLocalizedString has a new method for 5.0 availableApplicationTranslations(), but the docs state: * Get the languages for which there exists the translation catalog file * for the set application translation domain. * * The application domain is set by \c setApplicationDomain. * If the application domain was not set, empty set is returned. * If the application domain was set, the language set will always * contain at least the source code language (en_US). I suspect as we want the languages the user can switch the application into then it should be the right method provided the application domain is set by the application. - John --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117132/#review54463 --- On March 28, 2014, 11:21 a.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117132/ > --- > > (Updated March 28, 2014, 11:21 a.m.) > > > Review request for KDE Frameworks, Albert Astals Cid and Chusslove Illich. > > > Repository: kxmlgui > > > Description > --- > > Instead of asking the file-system what languages the application is > translated into, ask QLocale what languages we have available instead. > > > Diffs > - > > src/khelpmenu.cpp 4f6ce7b > > Diff: https://git.reviewboard.kde.org/r/117132/diff/ > > > Testing > --- > > > Thanks, > > Aleix Pol Gonzalez > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Status of the KDE Runtime module splitting
On 7 April 2014 18:57, Aleix Pol wrote:
> - l10n, localization: it was decided in this mailing list it would go to
> kde4support when some development happens. Otherwise it should go to
> KUnitConversion because it's only used there. besides KDE4Support.
>
Catching up after a couple of weeks away, there were 4 issues for
localization:
* KCurrencyCode
* kde-runtime/l10n
* kde-runtime/localization/currency
* all_languages
Moving KCurrencyCode from KUnitConversion to kde4support with full git
history was supposed to have been done before the beta, as it is no longer
used in KUnitConversion, but I guess that got missed in the process. I
really would like this moved as otherwise we'd also need to carry the
config files in KUnitConversion which doesn't use them, and continue to
depend on KConfigCore.
The KLocale config files need to move from kde-runtime/l10n/* to
kde4support/localization/country/*, they should have no other use outside
kde4support. As far as I can see, the only place left using them is the
old Locale KCM which will be changed, so nothing to stop this moving now.
The KCurrencyCode config files need to move from
kde-runtime/localization/currency to kde4support/localization/currency,
assuming KCurrencyCode gets moved to kde4support, otherwise to
kunitconversion/data/currency.
A question with the kde4support/localization files is how to parallel
install with KDE4? Currently KDE4 installs its copy into
${LOCALE_INSTALL_DIR}/l10n and ${LOCALE_INSTALL_DIR}/currency (usually in
/usr/share/locale). We need to have kde4support install into
${LOCALE_INSTALL_DIR}/kf5/ instead, and modify KLocale and KCurrencyCode to
look there.
The all-languages file holds translations of all language names in the
languages KDE is translated into. This looks to have been moved to
kde4support already for KLocale to use, and is being installed to
${LOCALE_INSTALL_DIR}/kf5_all_langauges. It appears all other uses have
been ported away to use QLocale? Perhaps we should install it into
${LOCALE_INSTALL_DIR}/kf5/ as well?
In short, once KCurrencyCode is sorted there should be nothing to stop the
config file moves.
Cheers!
John.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On 26 March 2014 20:08, Kevin Ottens wrote: > Hello, > > On Tuesday 25 March 2014 16:41:12 Jos Poortvliet wrote: >> Just imagine what header would you like to see on an announcement/article: >> * Frameworks 5 To Not Include Deprecated Technologies >> * KDE Porting Aids To Have Three Releases >> * Introducing KDE Porting Aids And Changes to Frameworks 5 >> >> I'm guessing the first, but - just checking. > > The first sounds negative to me, it'd sound like we completely drop them > leaving people with no transition plan. Probably not the image we want to > give... > > I think the third one although being more descriptive is the one with the > least chances of being misrepresented. I'd say not to have this as a separate announcement on its own, it's not that significant in itself. Instead, I'd just make it a section of the next Frameworks release announcement (and future ones too) saying something like: "KF5 Porting Aids. The Frameworks team have futher refined the Framework classification model and have identified a new group called the KF5 Porting Aids. These are Frameworks containing kdelibs4 modules and api that are being deprecated in KF5 and are provided only to assist applications in porting across to KF5. As such these Frameworks will only have a limited support period, currently planned to be three release cycles. Applications are strongly encouraged to port away from these Frameworks during this support period to prevent dependency on obsolete and unsupported code. Once support is ended, some unofficial development may continue on some modules, but they will not be part of the officially supported Frameworks release. The Frameworks belonging to this group are: blah blah blah. " John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On 17 March 2014 20:14, John Layt wrote: > I like the limit on kde4support, we only have to look to Qt3Support to > know that if the aids are left in place people will avoid porting away > from them until they absolutely have to. I'm not sure we need to call > it a "product" though, perhaps just saying a special category of > Frameworks providing transitional support for a limited period of time > for apps migrating from kdelibs4 to KF5 would be enough. Hey, how > about KDE Transitional Frameworks? :-) > > The important part is to have the clear definitions of what things > mean and what our plans are. We made a horrible mistake in Qt5 of > labelling things like QWidgets as "Done" as people just didn't > understand what we meant and assumed the worst, and we all know the PR > disaster that was. Oh, which is not to say that being deprecated / transitional / being given an EoL/EoS date would prevent someone from deciding to keep them alive outside Frameworks, or even bring them back in the distant future, just that is the current status. That would need good communication too. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On 17 March 2014 18:15, Kevin Ottens wrote: > So let's pick the following cocktail: 1, 2 and 4. > > That means we immediately move khtml and kde4support out of KDE Frameworks (to > be widely advertised) and into a KDE Porting Aids product (to be advertised > only to existing KDE developers). > > Ben, I think you're going to hate me for that, but we learn as we progress... > That means we're moving ASAP khtml and kde4support repositories out of the > frameworks group of the projects tree into a new portingaids group. > > We'll also announce at beta time the second product, and that we aim for > making only three releases out of it, coordinated with KDE Frameworks releases > as to give people time to port away from it. > > Now, the last point... What else do we want to move from KDE Frameworks to KDE > Porting Aids? Aleix and Aaron proposed the following content for KDE Porting > Aids: > * kde4support (obvious); > * khtml (planned for a long time); > * kjs (because of khtml I gather); > * kjsembed (ditto); > * krunner (because of upcoming sprinter, and only one user anyway); > * kmediaplayer (unused AFAIK). > > I think that list makes sense. Is there anyone who couldn't sleep at night if > those were in KDE Porting Aids? +1 to this strategy, although some bikeshedding on the "portingaids" name might be welcome :-) Hmmm, nope, I'm drawing a blank... I like the limit on kde4support, we only have to look to Qt3Support to know that if the aids are left in place people will avoid porting away from them until they absolutely have to. I'm not sure we need to call it a "product" though, perhaps just saying a special category of Frameworks providing transitional support for a limited period of time for apps migrating from kdelibs4 to KF5 would be enough. Hey, how about KDE Transitional Frameworks? :-) The important part is to have the clear definitions of what things mean and what our plans are. We made a horrible mistake in Qt5 of labelling things like QWidgets as "Done" as people just didn't understand what we meant and assumed the worst, and we all know the PR disaster that was. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
On 17 March 2014 16:45, Alex Merry wrote: > On 17/03/14 15:25, Aurélien Gâteau wrote: >> What worries me with this approach is it feels like comparing apples and >> oranges here. To me a framework "tier" is about its dependencies, not >> about its maturity. I would suggest to instead introduce an orthogonal >> information: maturity, which could have the value: "new", "stable", >> "deprecated". + 1 > ... which I think is where the confusion about tier 4 has come from. > > This maturity information would be familiar to anyone familiar with the > Qt Project's processes, which would be a bonus. I think I've advocated in other forums that we need a "maturity" metadata flag for Apps and Frameworks that relates to our Application/Frameworks Life Cycle and is documented somewhere prominent so users know what we mean and promise, something like: Experimental / Playground / Unstable Incubator / Review / Tech Preview Stable / Released / Supported / Active Deprecated / Inactive Unsupported / Retired / Abandoned John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Plasma Next - Translations KCM - What Languages?
Hi, I'm doing some more work on the new KCM for Translations, i.e. the KCM in Plasma Next to configure the LANGUAGE env var that startkde will export for all apps running under Plasma Next to use, including Gtk as well as Qt apps. Because this is now the workspace/desktop wide setting, and not the setting for just KDE apps under all workspaces, the way the current KCM works may no longer be valid. The current Languages KCM has two columns, "Available Languages" and "Preferred Languages". The Available Languages is populated with the list of all KDE translations installed by calling KLocale::installedLanguages(), i.e. all the QStandardPaths::GenericDataLocation/locale/*/entry.desktop files installed. Now, that seems a fine idea, until you think about non-KDE apps that may have other translation languages installed which won't get listed. Are we concerned about those? Is there a common cross-distro way to find out all languages that are installed? Do we just scan all the locale/*/LC_MESSAGES/* or locale-bundle/*/LC_MESSAGES/* entries installed to get all the possible languages (and what is the difference between locale and locale-bundle)? Or do we list all languages regardless of whether they are installed or not (probably way too many)? If we stick with just KDE translations installed, do we copy the KLocale::installedLanguages() code (will we still be installing the entry.desktop files?), or use the new KLocalizedString::availableApplicationTranslations() method which requires setting an Application Domain to define which LC_MESSAGES file to look for (if so, which one)? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116615: Remove deprecated method languageForEncoding()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116615/ --- (Updated March 5, 2014, 3:05 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kcodecs Description --- Remove method KCharSets::languageForEncoding() which is marked as deprecated and to be removed for KDE4. Diffs - src/kcharsets.h 0baedd28a72248a2ef974ff2ea539409a23fe0fd src/kcharsets.cpp b140074a82384111074ee9876048718c76b98523 Diff: https://git.reviewboard.kde.org/r/116615/diff/ Testing --- Autotests pass. Thanks, John Layt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116615: Remove deprecated method languageForEncoding()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116615/ --- Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kcodecs Description --- Remove method KCharSets::languageForEncoding() which is marked as deprecated and to be removed for KDE4. Diffs - src/kcharsets.h 0baedd28a72248a2ef974ff2ea539409a23fe0fd src/kcharsets.cpp b140074a82384111074ee9876048718c76b98523 Diff: https://git.reviewboard.kde.org/r/116615/diff/ Testing --- Autotests pass. Thanks, John Layt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KGuiAddons Review
Hi, Here's my first pass through KGuiAddons, focussing on the public api. KColorCollection - Should probably become a QSharedDataPointer KWorkdWrap - "// KDE5 TODO: return a value, not a pointer, and use QSharedDataPointer." KModifierKeyInfo - Generally looks OK - Has lots of "bool isKeyPressed(Qt::Key)" style methods and keyPressed(Qt::Key, bool) style signals when perhaps a KeyState enum would be better? - Uses X11 / XKB / XCB, will need Wayland backend eventually? - Perhaps really belongs in Qt, or somewhere else? KImageCache KSharedPixmapCacheMixin KLocalImageCacheImplementation - Looks OK - KImageCache not exported, but KLocalImageCacheImplementation is, some CMake magic involved? KColorMimeData KFontUtils KIconUtils - Looks OK KColorUtils - Looks OK - Qt should probably get some of these methods? KDateValidator - Looks OK - Qt should probably have one, QTime as well? And the usual documentation improvements of course. Otherwise looks in good shape. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KIdleTime Quick Review
Hi, Nice simple one this, one public class, looks OK. Has QWidget, Windows, Mac, and X11 (XScreensaver/XSync) backends, will need Wayland or systemd support eventually? Does have one TODO, but that's an implementation detail: "widgetbasedpoller.cpp # TODO: make optional, to avoid always depending on QtWidgets? Or port to QtGui?" One small point, the idle time is an int value, perhaps a uint would be better? Also uses an int for a unique timeout identifier, perhaps a QUuid might be better? If you're looking for a maintainer, Dario Freddi wrote all the code... Just sayin ;-) John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KCodecs - Quick Review
Hi, I know nothing about text codecs, but I've had a *very* quick look at KCodecs: * Original code by Lars dated 1999! * One method marked as deprecated to be removed for KDE4 * "###FIXME KDE4: the name of the encodings should mostly be uppercase" * Code generated by script generate_string_table.pl located in kdesdk/scripts * Algorithms marked as copyright by RSA Data Security and others, but no mention what the original licence was or real link to original source * Encoding probers and lookup tables marked as copyright Mozilla 1998, X11 license * kentities.c is documented as generated by gperf from either kentities.gperf and/or khtmlentities.gperf but neither are in kcodecs, instead they are in khtml as is another copy of kentities.c. * Public API using boolean parms This suggests it could do with some attention: * Check still valid to remove deprecated code? * Check if encoding names should be made uppercase? * The generate_string_table.pl script should probably be moved into KCodecs, unless it has more general use? * The RSA and other algorithms may need checking for licensing issues, or at least improve the license documentation? * The probers may need to be checked they are still up to date with the original Mozilla code and look-up tables? * kentities.c needs investigation and I suspect moving all the files from khtml to kcodecs, with khtml then using kcodecs? Or at least docs added that this is where it comes from and should be kept in sync. I wonder how much of this functionality is now done in Qt5? Would it benefit from a functional review by someone who knows what they're doing, like Thiago or David? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On 4 March 2014 15:59, Kevin Ottens wrote: > KGuiAddons definitely. The other two are important too, but this one is even > more important. OK, I'll get onto that then. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On 4 March 2014 09:25, Kevin Ottens wrote: > On Tuesday 04 March 2014 01:04:05 John Layt wrote: >> So, now KPrintUtils and KUnitConversion are about done (bar the >> KCurrencyCode move), are there any other Frameworks needing review? > > All the unmaintained ones, some of the maintained ones too. > >> At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime >> are unclaimed? > > Is it an offer to be the maintainer for more frameworks? Be my guest. :-) It is, as I seem to have lost one along the way ;-) I was thinking by reviewing some of them I'd get a better idea of what would be suitable for me, so if there's any you think are higher priority let me know. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On 2 March 2014 19:58, Kevin Ottens wrote: > On Thursday 27 February 2014 17:15:56 John Layt wrote: >> * Try port away from ki18n to tr(). KUC makes extensive use of ki18nc() and >> ki18ncp(), but I need to check with Chusselove if all the plural >> translations can be handled with Qt or if any are scripted. >> >> * If we remove those two dependencies then KUC becomes Tier 1, but Tier 2 is >> fine either way. > > Would be nice to have it tier 1 if possible indeed. Nice move. Still to be done, but I've now removed all the uses of KLocalizedString in the api of the public classes, so it will be safe to remove the dependency at any time in the future. >> * Convert more classes to QSharedData >> >> * Some small API changes > > Please also do so before beta 1. Done, and pushed. It's a BIC and SIC change, but it appears no-one has ported to use the KF5 version as yet. All the classes are now proper shared data containers, and all the internal implementation details that had leaked into the public classes have been removed, so it's a lot cleaner. I've put the details in the porting guide. I still have a few small changes to look at, but this is the serious stuff done. I'll clean-up the apidox and add more tests later. >> Longer term, I've started work on a new Tier 1 library tentatively called >> KStandards to support the different ISO code standards, and measurement >> standards and conversions. I've already converted KCurrencyCode to a new >> KCurrency class using json files, and KCountry and KUnits should follow in >> due course to provide a future migration path for apps that need them. > > Excellent. Any effort on it should be scheduled at KF 5.1 though. Yeap, 5.1 is the plan, I want to try get some supporting stuff in Qt as well, but I'll probably roll a Tech Preview around the KF5 release. So, now KPrintUtils and KUnitConversion are about done (bar the KCurrencyCode move), are there any other Frameworks needing review? At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime are unclaimed? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On 28 February 2014 10:52, Chusslove Illich wrote: >> [: John Layt :] >> * Try port away from ki18n to tr(). KUC makes extensive use of ki18nc() >> and ki18ncp(), but I need to check with Chusselove if all the plural >> translations can be handled with Qt or if any are scripted. > > So far no language has any scripted translations here. > > There should be nothing specific about plurals in this case, i.e. they > should work with Qt so long as any plurals work (I think this is mainly upon > lconvert doing the right thing). Thanks Chusslove, I'll have a look at it over the weekend. One thing I've noticed is that it uses KLocalizedString in public api and as internal storage, is this a normal way of doing things? I would have thought once the translation has been done that a QString should be OK for storage and api use? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kprintutils - next steps
On 28 February 2014 14:14, Alex Merry wrote: > Given the alpha1 time constraints, I just pushed this. > > I'll leave dealing with the old repo to you (which I guess involves > filing a sysadmin request to remove it). > > David: kprintutils should not form part of alpha 1, since the code is > now all in KDE4Support. Fantastic, thanks Alex. It all looks good to me. Is there anything else I need to do before deleting the repo? I'd hate to delete it and break some dependency somewhere. Do we want to remove it from kde-projects.xml first and wait a little before deleting it just so things like CI have time to sync up? Perhaps I should change the kprintutils cmake to not install anything in the interim? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KUnitConversion Review
Hi, I've been reviewing KUnitConversion (KUC for short) and doing some small clean-ups, and I'm slowly coming to the conclusion I'm not a fan of the api. However it is used in a few places, so rather than try rewrite the api in the time remaining, I'll finish up the clean-ups and we can release it as is and look to replace it later on. The main clean-ups are: * Remove use of KCurrencyCode. Currently it's only used to get the currency name of the 50 currencies KUC supports and it seems overkill to keep all 207 data files and the api in KUC just for that purpose. Instead I'd move it to kde4support with the rest of KLocale (we also need to move the config files from kde-runtime). This would also remove the dependency on KConfigCore. * Try port away from ki18n to tr(). KUC makes extensive use of ki18nc() and ki18ncp(), but I need to check with Chusselove if all the plural translations can be handled with Qt or if any are scripted. * If we remove those two dependencies then KUC becomes Tier 1, but Tier 2 is fine either way. * Convert more classes to QSharedData * Some small API changes * Lots of docs clean-ups, code style, etc are needed but can be done later. I've done the first step, and I just need a volunteer to do the git magic required to: * Move kcurrencycode.h and kcurrencycode.cpp including history from "kunitconversion/src" to "kde4support/src/kdecore" * Move "kde-runtime/localization" and everything in it including history to "kde4support/src/localization" or "kde4support/runtime/localization" or wherever deemed appropriate * Move "kde-runtime/l10n" and everything in it including history into the same "localization" folder as above but folder renamed from "l10n" to "localization/country" (i.e. at same level as "currency" folder) * Make sure the data files are built and installed, but need to think about parallel installs with KDE4 data files The data file moves are part of the kde-runtime clean-up, but it makes sense to do them alongside the code moves. Longer term, I've started work on a new Tier 1 library tentatively called KStandards to support the different ISO code standards, and measurement standards and conversions. I've already converted KCurrencyCode to a new KCurrency class using json files, and KCountry and KUnits should follow in due course to provide a future migration path for apps that need them. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kprintutils - next steps
On 23 February 2014 20:02, John Layt wrote: > I believe the steps required are: > > 1) Port existing apps that are already ported to KF5 away from > KdePrint::createPrintDialog(): > - Okteta > - kfontinst > - ktexteditor > - None use KPrintPreview This has been done, all frameworks code as built by kdesrc-build has had the dependency removed. > 2) Copy code from kprintutils to kde4support > - Do we bother to keep the history? > - Where do we put it? Alex, if you have that git magic I'd appreciate your doing it, I have no clue what to do :-) I'm not sure whether we should put it back into kde4support/src/kdeui where it originally came from or kde4support/src/kprintutils? > 3) Update porting guide I've updated http://community.kde.org/Frameworks/Porting_Notes#KDEUI_Changes Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116051: Adjust kunitconversion tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116051/#review50858 --- Ship it! Ship It! - John Layt On Feb. 25, 2014, 5:22 p.m., Kevin Krammer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/116051/ > --- > > (Updated Feb. 25, 2014, 5:22 p.m.) > > > Review request for KDE Frameworks, John Layt and Petri Damstén. > > > Repository: kunitconversion > > > Description > --- > > ki18n changed from tier 2 to tier 1. > kunitconversion only depends on tier 1 now, becomes tier 2 > > > Diffs > - > > kunitconversion.yaml 78c0a75 > > Diff: https://git.reviewboard.kde.org/r/116051/diff/ > > > Testing > --- > > > Thanks, > > Kevin Krammer > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Mac OS X Frameworks Frameworks
On 23 February 2014 20:15, Harald Fernengel wrote: > Hi, > > TL;DR > > Do we want to do build KDE Frameworks as Mac OS X Frameworks? I think so, at least for the ones we want to be viewed as proper Qt Add-ons, it would enlarge our possible user-base. From experience in Qt the hard part is keeping the includes conforming, the rules would have to be well advertised and put in the coding standards. We really need a CI machine testing the build on OSX to make sure people don't keep breaking it. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Mac OS X Frameworks Frameworks
On 23 February 2014 20:15, Harald Fernengel wrote: > TL;DR > > Do we want to do build KDE Frameworks as Mac OS X Frameworks? I think so, at least for the ones we want to be viewed as proper Qt Add-ons, it would enlarge our possible user-base. From experience in Qt the hard part is keeping the includes conforming, the rules would have to be well advertised and put in the coding standards. We really need a CI machine testing the build on OSX to make sure people don't keep breaking it. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kprintutils - next steps
Hi, I've just merged my clean-ups for kprintutils to remove everything not needed due to the changes in Qt5. Basically what is now left is so minimal that I see no benefit in keeping it as a framework and propose we move it to kde4support instead. There are two parts to kprintutils: 1) The KdePrint::createPrintDialog() static methods. These used to add standard KDE add-on tabs to the dialog to implement missing CUPS features. With these features moved to Qt, this code is nothing more than syntactic sugar for an app adding its own tabs. We could keep kprintutils in case we add new features in the future, such as poster printing like KPrinter4 does, but I'd rather put the effort into finding a nice way to do that in Qt itself. 2) KPrintPreview. This uses KParts to preview the document as a pdf in the Okular part, however it lacks many features found in QPrintPreview which wasn't available when 4.0 was released. Many apps have already voted with their feet (Kate, Calligra, etc) and I'd rather put the effort into QPrintPreview if any changes are needed. I believe the steps required are: 1) Port existing apps that are already ported to KF5 away from KdePrint::createPrintDialog(): - Okteta - kfontinst - ktexteditor - None use KPrintPreview 2) Copy code from kprintutils to kde4support - Do we bother to keep the history? - Where do we put it? 3) Update porting guide 4) Update dependencies/kdesrc-build, etc? 5) Delete kprintutils repo 6) Find me something else to maintain... Thoughts? John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Figuring out kde-runtime: localization
On 23 February 2014 17:31, Albert Astals Cid wrote: > El Diumenge, 23 de febrer de 2014, a les 17:26:23, John Layt va escriure: >> >> In KF5 both KLocale and KCurrencyCode are in kde4support > > KCurrencyCode is in kunitconversion. Ah, so it is, had missed that :-) So I guess the maintainer for kunitconversion needs to move the data files there? Now, who would that be... :-) I need to see how KCurrencyCode is being used there, and decide whether to keep it public or not. So, looking at the other users of the l10n files. kio/src/core/global.cpp - Uses them to find the default BinaryUnitDialect for the current locale, but all config files have the same default, so get rid of lookup and use same default until Qt adds support. kconfigwidgets/src/klanguagebutton.cpp - loadAllLanguages() loads the list of available languages from the config files, should probably just load the list of Qt languages? Or does it really mean the list of KDE translation languages? Perhaps we need load functions for both options, depending on the use its needed for? - Will we need a K4LanguageButton that has the old behaviour? kxmlgui/src/khelpmenu.cpp - Weird one, if there are any config files installed, then enables the "Help/Switch Language" menu item, but if you trigger the item it launches KSwitchLanguageDialog which looks for the installed translation languages for the app, which is a completely different thing. - KSwitchLanguageDialogPrivate::applicationLanguageList() needs to be made a KSwitchLanguageDialog static method that KHelpMenu can call to see if more than 1 language is available, and use that in place of the existing check. Once those changes are made, then the l10n files can go to kde4support. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Building frameworks: docbook problems
On 7 February 2014 10:01, David Faure wrote: > On Monday 03 February 2014 22:08:20 Andriy Rysin wrote: >> I am trying to build frameworks using >> http://community.kde.org/Frameworks/Building on Fedora 20 and it failes >> in several modules due to some docbook problem, e.g. in kconfigwidgets: >> >> Scanning dependencies of target kstandardactiontest_automoc >> man-preparetips5.1.docbook:5: warning: failed to load external entity >> "dtd/kdex.dtd" >> ]> >> ^ >> man-preparetips5.1.docbook:7: parser error : Entity 'language' not defined >> > > Did you set XDG_DATA_DIRS to contain /share ? Just hit this myself using kdesrc-build, shouldn't it take care of it for me? Seems a little user unfriendly that it's the one envvar I have to set when kdesrc-build takes care of the rest for me? John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Figuring out kde-runtime: localization
On 21 February 2014 13:17, Aleix Pol wrote: > Hi, > Going through the information we have in kde-runtime [1] we found there are > two subdirectories related to localization (localization and l10n) that we > couldn't find a correct place to move to. > > Can anybody give us a hand and help us figure those out? > - localization: has plenty of information regarding different currencies. > - l10n: has information about different countries. > > Should these go to KI18n? Qt? > Anybody has plans for those? > > Aleix > > [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization The l10n directory holds the locale config files for each country. These files get used by KLocale. The localization directory holds the currency config files used by KLocale and KCurrencyCode, as they couldn't go into l10n/ without messing up existing code, and the long-term plan was to move l10n/ into localization/ as a country/ sub-directory. In KF5 both KLocale and KCurrencyCode are in kde4support and have mostly been replaced by using QLocale. As such both l10n and localization are only required if kde4support is installed and used. I assume the files must now be moved into kde4support? Will we also need to think about what happens with parallel installs with KDE4? As Albert points out, there looks to be a couple of other places the files are used in KF5 code that will need porting to QLocale instead, or if they are only appropriate with KLocale then moving to kde4support. I'll try have a look later today. I have a separate email about locale configuration in Plasma Next that I'll post on the Plasma list a bit later. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kguiaddons uses qpa headers?
Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.cpp:26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115715: Remove X11 dependency from kprintutils
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115715/#review49828 --- Ship it! Ship It! - John Layt On Feb. 15, 2014, 12:37 p.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115715/ > --- > > (Updated Feb. 15, 2014, 12:37 p.m.) > > > Review request for KDE Frameworks, kdewin and John Layt. > > > Repository: kprintutils > > > Description > --- > > Remove X11 dependency from kprintutils > > The availability of XLib was used to test whether Cups is available. > Cups has nothing to do with X11, thus the check is wrong. > > The code does not use any platform specific code and has a runtime > check whether cups is available. Given the comment it should also > work correct on platforms which do not have Cups (e.g. Windows). > > > Diffs > - > > CMakeLists.txt 28342d0c9149d09ab0b9e41c5ed6d41b695130ed > src/CMakeLists.txt 927b02480db47bb74ea4240e582dbb0f6f6aeac2 > src/config-kprintutils.h.cmake 89858d17de239cfc7eed1f40a8b828803de3299c > src/kcupsoptionswidget_p.cpp c88e848a41b72590b13d8b38783cd1c7b1d106d1 > src/kdeprintdialog.cpp a53e19846d0f45073f1d6827e7b2eaa2bde859a3 > > Diff: https://git.reviewboard.kde.org/r/115715/diff/ > > > Testing > --- > > > Thanks, > > Martin Gräßlin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115715: Remove X11 dependency from kprintutils
> On Feb. 14, 2014, 1:58 p.m., John Layt wrote: > > I'd prefer for now that you just replace the HAVE_X11 with "#defined > > Q_OS_UNIX && !defined Q_OS_MAC" which should produce the same effect. No > > point in compiling the CUPS code if we're never going to use it. Once Qt > > feature freeze kicks in I'll have time to review all this code properly and > > it's likely most of it will be deleted anyway. > > John Layt wrote: > Duh, make that "#if defined Q_OS_UNIX && !defined Q_OS_MAC" > > Nicolás Alvarez wrote: > Doesn't Mac use CUPS too? They do, but wrapped in their own native api and dialogs. Qt uses the native dialogs rather than the Qt dialogs, so we can't add the tabs to them. It's a long-term goal to figure out how to embed Qt widgets into the Mac and Windows dialogs :-) - John --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115715/#review49783 --- On Feb. 15, 2014, 12:37 p.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115715/ > --- > > (Updated Feb. 15, 2014, 12:37 p.m.) > > > Review request for KDE Frameworks, kdewin and John Layt. > > > Repository: kprintutils > > > Description > --- > > Remove X11 dependency from kprintutils > > The availability of XLib was used to test whether Cups is available. > Cups has nothing to do with X11, thus the check is wrong. > > The code does not use any platform specific code and has a runtime > check whether cups is available. Given the comment it should also > work correct on platforms which do not have Cups (e.g. Windows). > > > Diffs > - > > CMakeLists.txt 28342d0c9149d09ab0b9e41c5ed6d41b695130ed > src/CMakeLists.txt 927b02480db47bb74ea4240e582dbb0f6f6aeac2 > src/config-kprintutils.h.cmake 89858d17de239cfc7eed1f40a8b828803de3299c > src/kcupsoptionswidget_p.cpp c88e848a41b72590b13d8b38783cd1c7b1d106d1 > src/kdeprintdialog.cpp a53e19846d0f45073f1d6827e7b2eaa2bde859a3 > > Diff: https://git.reviewboard.kde.org/r/115715/diff/ > > > Testing > --- > > > Thanks, > > Martin Gräßlin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115715: Remove X11 dependency from kprintutils
> On Feb. 14, 2014, 1:58 p.m., John Layt wrote: > > I'd prefer for now that you just replace the HAVE_X11 with "#defined > > Q_OS_UNIX && !defined Q_OS_MAC" which should produce the same effect. No > > point in compiling the CUPS code if we're never going to use it. Once Qt > > feature freeze kicks in I'll have time to review all this code properly and > > it's likely most of it will be deleted anyway. Duh, make that "#if defined Q_OS_UNIX && !defined Q_OS_MAC" - John --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115715/#review49783 --- On Feb. 13, 2014, 7:43 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115715/ > --- > > (Updated Feb. 13, 2014, 7:43 a.m.) > > > Review request for KDE Frameworks, kdewin and John Layt. > > > Repository: kprintutils > > > Description > --- > > Remove X11 dependency from kprintutils > > The availability of XLib was used to test whether Cups is available. > Cups has nothing to do with X11, thus the check is wrong. > > The code does not use any platform specific code and has a runtime > check whether cups is available. Given the comment it should also > work correct on platforms which do not have Cups (e.g. Windows). > > > Diffs > - > > CMakeLists.txt 28342d0c9149d09ab0b9e41c5ed6d41b695130ed > src/CMakeLists.txt 927b02480db47bb74ea4240e582dbb0f6f6aeac2 > src/config-kprintutils.h.cmake 89858d17de239cfc7eed1f40a8b828803de3299c > src/kcupsoptionswidget_p.cpp c88e848a41b72590b13d8b38783cd1c7b1d106d1 > src/kdeprintdialog.cpp a53e19846d0f45073f1d6827e7b2eaa2bde859a3 > > Diff: https://git.reviewboard.kde.org/r/115715/diff/ > > > Testing > --- > > > Thanks, > > Martin Gräßlin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115715: Remove X11 dependency from kprintutils
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115715/#review49783 --- I'd prefer for now that you just replace the HAVE_X11 with "#defined Q_OS_UNIX && !defined Q_OS_MAC" which should produce the same effect. No point in compiling the CUPS code if we're never going to use it. Once Qt feature freeze kicks in I'll have time to review all this code properly and it's likely most of it will be deleted anyway. - John Layt On Feb. 13, 2014, 7:43 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115715/ > --- > > (Updated Feb. 13, 2014, 7:43 a.m.) > > > Review request for KDE Frameworks, kdewin and John Layt. > > > Repository: kprintutils > > > Description > --- > > Remove X11 dependency from kprintutils > > The availability of XLib was used to test whether Cups is available. > Cups has nothing to do with X11, thus the check is wrong. > > The code does not use any platform specific code and has a runtime > check whether cups is available. Given the comment it should also > work correct on platforms which do not have Cups (e.g. Windows). > > > Diffs > - > > CMakeLists.txt 28342d0c9149d09ab0b9e41c5ed6d41b695130ed > src/CMakeLists.txt 927b02480db47bb74ea4240e582dbb0f6f6aeac2 > src/config-kprintutils.h.cmake 89858d17de239cfc7eed1f40a8b828803de3299c > src/kcupsoptionswidget_p.cpp c88e848a41b72590b13d8b38783cd1c7b1d106d1 > src/kdeprintdialog.cpp a53e19846d0f45073f1d6827e7b2eaa2bde859a3 > > Diff: https://git.reviewboard.kde.org/r/115715/diff/ > > > Testing > --- > > > Thanks, > > Martin Gräßlin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 23:52, Alex Merry wrote: > If these additions are something that applications would need to be > aware of, I see no issue with creating a wrapper class or some such > as-and-when we find a use for one. > > If they are something that would be hidden to applications, would you > consider having platform integration hooks in QPrinter for that sort of > thing? The idea is to add things without the app needing to know or worry about, and without having to go through every app and re-code to use a new wrapper (I did that for 4.0 and 4.2, never again!). On the other hand, without knowing what those requirements might be it's a bit much to assume that the current wrapper will meet those needs. Platform hooks are possible, we have a QPA plugin for printing, but would need to be done in a cross-platform way, and until those needs arise we don't know what shape it would need to take. For color management, the idea was an extra tab would be automatically added to the dialog if color management was configured, which would then query the config for the colorspace to use and do some magic to apply it. However the proposal we discussed at the Color Management hack-fest does rely on an obscure build-time dependency and a PDF based workflow using Ghostscript that I'm really not keen on. It's also requires a decision to support Oyranos and/or colord in the core that I don't think we're ready to make yet, or indeed have the abstraction classes to do so. I think for now it's better if the Oyranos and colord camps provide their own tab widgets that apps can choose to use to configure things, and then the app takes care of deciding on color management support and workflow. I'll look again at adding the color OutputIntent to Qt's PDF support, but I'd have to do that using a QString for the ICC Profile name, when I'd rather wait until we have a proper QIccProfile class to use. Sigh, so may tasks, so little time... Anyway, far too much detail for here, I think I'm convincing myself that it's less useful to keep the empty wrapper around for now, it may be better moved to KDE4Support, along with KPrintPreview, leaving an empty repo. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 8 January 2014 07:17, Kevin Ottens wrote: > For the record, if that depends on QtPrintSupport it can't make it to > KGuiAddons (which should depend only on QtCore and QtGui). Good point :-) > I'm fine keeping it even if it's small. OK, I'll take the chainsaw to it this weekend and see what we're left with. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 23:30, Michal Humpula wrote: > If I may post a little input here. I've implemented print preview in kate > (KF5) with QPrintPreviewDialog, mainly for the reasons mentioned above. But > what I'm missing is ability to add custom configuration tabs as in > KdePrint::createPrintDialog. Though KPrintPreview doesn't seems to support > them either:-) Yeap, neither allows on-the-fly use of the custom tabs in the preview, which is a short-coming, but QPrintPreviewDialog at least gives the possibility of doing so in future with a dynamic update of the preview, KPrintPreview really doesn't support such a work flow. The other issue is anyone clicking on the print dialog button in the menu of QPrintPreviewDialog gets a dialog without any custom tabs either, which was one reason for not using it before when we added our extra stuff. It should be easy enough for me to add Qt api to allow you to set them and have the preview pass them through to the dialog, but I'm not sure how I'd show the widgets in the preview itself. Perhaps a button to pop them up? Something to think about anyway. John. P.S. Not forgetting that the app widgets are not cross-platform, they don't work on Windows or Mac, but that's on my feature plan for 5.4/5.5 time-frame. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 19:49, Kevin Ottens wrote: >> Most of the >> dialog code from there has been merged into Qt5.2, or is planned for >> Qt 5.3, so needs deleting. I'm also wondering if we still need our >> own KPrintPreview dialog, there was a reason in 4.0 but I can't >> remember why now and I'm not sure it is still valid. Alex Merry might >> remember, was it because QPrintPreview wasn't available at the time? >> We may not end up with much left here :-) > > Well, the initial plan was to not have KPrintUtils at all. It's here mainly > because of timing issues because the necessary upstream work to get everything > to disappear in KPrintUtils wasn't done in time for Qt 5.2. Running through the print dialog features, I'm don't think there is anything left to be upstreamed. There's a couple of very minor CUPS features in the dialog that I don't think anyone uses (mirror page, page border, page label) that I don't really want in Qt, but can add if anyone really makes a fuss. If we decide to replace KPrintPreview with QPrintPreviewDialog then we're just left with the convenience api to create a QPrintDialog that won't actually add anything extra. That could be still worth keeping for a couple of reasons, but it could then move to KGuiAddons. The main reason to keep it is future-proofing if we need to add common widgets or extra checks again, in particular I think it may be the only way to do color-managed printing until Qt adds proper support in QtGui. >> If the original author Petri Damstén doesn't step up, I could take on >> KUnitConversion, seeing as I'm partly familiar with the code. > > Then put your name in front with a note for Petri to kick you off if he shows > up. :-) > I don't think we've been in touch with him yet. Done :-) John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 19:55, Albert Astals Cid wrote: > El Dimarts, 7 de gener de 2014, a les 18:24:41, Alex Merry va escriure: >> On 07/01/14 17:10, John Layt wrote: >> > I've put myself down (rather obviously) for KPrintUtils. Most of the >> > dialog code from there has been merged into Qt5.2, or is planned for >> > Qt 5.3, so needs deleting. I'm also wondering if we still need our >> > own KPrintPreview dialog, there was a reason in 4.0 but I can't >> > remember why now and I'm not sure it is still valid. Alex Merry might >> > remember, was it because QPrintPreview wasn't available at the time? >> > We may not end up with much left here :-) >> >> I don't remember, but looking at email archives and Qt docs, it looks >> like that probably was the reason; I think we started KDE4 depending on >> Qt 4.3, and QPrintPreview was added in 4.4. > > And the underlying tech is totally different too, KPrintPreview prints to pdf > and then shows the preview in an okular part while QPrintPreview does a > totally different thing. I've mostly avoided looking at QPrintPreviewDialog so far (bad maintainer!), but it is basically another paint device you paint to when requested, using exactly the same painting code as you would for normal printing, or printing the preview to PDF. In theory it should be better than KPrintPreview as it only asks you to render the pages it needs as it needs them, rather than pre-rendering the whole document like KPrintPreview does, and it doesn't need the Okular KPart installed to work either. I think some apps like Calligra already prefer to use it for those reasons (that and zander being the original author). It wouldn't work for use inside Okular though, but then it always seems a little weird to do a print preview in Okular to just get an Okular window again :-) I'll do a more in-depth investigation and come back to the list to make a decision. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 6 January 2014 07:52, Kevin Ottens wrote: > I urge everyone, and in particular people volunteering to maintain a > framework, to do a pass of review of our code base and APIs to modernize them > when appropriate. It is a very big task, and in no way can be coordinated in > the way we've been working so far. Maintainers will be a crucial part of a > successful code quality review, which leads me to the governance... > The current list of modules is there: > http://community.kde.org/Frameworks/List > > As you can see there's quite some holes in the table, and quite a few entries > marked unmaintained. KDE Frameworks as a set of technologies will only be > taken seriously if we get something more complete there. I urge everyone with > an interest in KDE Frameworks to step up, look at that list and volunteer to > maintain a framework. If you volunteer, know that the following will be > expected from you: > 1) Complete in the table the information regarding your framework; > 2) Do an API review and modernization pass in your framework (possibly with > the help of others); I've put myself down (rather obviously) for KPrintUtils. Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) If the original author Petri Damstén doesn't step up, I could take on KUnitConversion, seeing as I'm partly familiar with the code. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Framework metadata
On 19 December 2013 08:47, Cornelius Schumacher wrote: > On Wednesday 18 December 2013 Aurélien Gâteau wrote: >> >> The information in the DOAP file can also be used to generate manifest >> files for Inqlude (http://inqlude.org/) > > For this to work we need at least the following data in the DOAP file: > > * machine-readable name as identifier (all lower-case, no spaces or other > special characters) > * human-readable display name > * one line short description > * longer description (preferably in markdown, so it can be properly formatted > independent of the technology used for displaying it) > * link to home page > * link to source code repository > * link to download page of release tarballs (optional) > * list of licenses > * list of authors (at least one person with a name and an email address) > * list of supported platforms I think I mentioned in the AppData thread the need for a KDE metadata file to help us manage our repos, and that all other metadata files could be generated from. This would apply to apps and workspace as well as frameworks. At the time I sketched out some metadata I thought would be useful for every KDE repo to have in a .desktop file, although more from an internal organisational and end-user viewpoint: group=[frameworks|workspaces| applications] categories=[games|education|multimedia|graphics|...] maturity=[experimental|incubator|stable|deprecated|unmaintained] release-cycle=[official|independent|unreleased] stable-release= stable-release-branch= stable-release-date= unstable-release= unstable-release-branch= unstable-release-date= dev-branch= maintainers= name= short-description= description= website= forum= user-mailing-list= dev-mailing-list= irc= bugzilla= bugzilla-product= bugzilla-component= reviewboard= reviewboard-group= Looking at DOAP, there's a lot of overlap and it looks very flexible and if it's being widely adopted then I see it as an option. The XML/RDF is a bit complex/verbose though, any other options available out there? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Framework metadata
On 19 December 2013 08:47, Cornelius Schumacher wrote: > On Wednesday 18 December 2013 Aurélien Gâteau wrote: >> >> The information in the DOAP file can also be used to generate manifest >> files for Inqlude (http://inqlude.org/) > > For this to work we need at least the following data in the DOAP file: > > * machine-readable name as identifier (all lower-case, no spaces or other > special characters) > * human-readable display name > * one line short description > * longer description (preferably in markdown, so it can be properly formatted > independent of the technology used for displaying it) > * link to home page > * link to source code repository > * link to download page of release tarballs (optional) > * list of licenses > * list of authors (at least one person with a name and an email address) > * list of supported platforms I think I mentioned in the AppData thread the need for a KDE metadata file to help us manage our repos, and that all other metadata files could be generated from. This would apply to apps and workspace as well as frameworks. At the time I sketched out some metadata I thought would be useful for every KDE repo to have in a .desktop file, although more from an internal organisational and end-user viewpoint: group=[frameworks|workspaces|applications] categories=[games|education|multimedia|graphics|...] maturity=[experimental|incubator|stable|deprecated|unmaintained] release-cycle=[official|independent|unreleased] stable-release= stable-release-branch= stable-release-date= unstable-release= unstable-release-branch= unstable-release-date= dev-branch= maintainers= name= short-description= description= website= forum= user-mailing-list= dev-mailing-list= irc= bugzilla= bugzilla-product= bugzilla-component= reviewboard= reviewboard-group= Looking at DOAP, there's a lot of overlap and it looks very flexible and if it's being widely adopted then I see it as an option. The XML/RDF is a bit complex/verbose though, any other options available out there? John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114187: KFormat - Add new KFormat class
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114187/ --- (Updated Dec. 12, 2013, 9:37 a.m.) Status -- This change has been discarded. Review request for KDE Frameworks, Albert Astals Cid, David Faure, and Kevin Ottens. Repository: kdelibs Description --- KFormat - Add new KFormat class KLocale offers a number of extra formatting options not yet available in Qt. The KFormat class adds these options to KCoreAddons: * formatByteSize() * formatDuration() * formatDecimalDuration() * formatSpelloutDuration() * formatRelativeDate() * formatRelativeDateTime() The KFormat class can be initialised with any QLocale to use in the date and number formatting, or the default locale can be easily accessed via KFormat(): QString result = KFormat().formatDuration(1000); There's a few things that need looking at here. The main one is the translation stuff because I had to convert from using ki18n to tr and it may have lost something in the process. In particular it looks like we'll actually need an en_US translation done to get the plurals right? If we can't make tr() work for these we'll have to move the class into k18n. The second is to look at the formatting options provided and decide if they are actually useful to have. The third is to confirm that the design is OK, I did think about making these simple static methods with an extra parm for QLocale, but I think this approach offers more future flexibility, and writing KFormat().formatDuration() is just as convenient as KFormat::formatDuration(). Diffs - tier1/kcoreaddons/autotests/CMakeLists.txt c8043576181e7d06663195d017be930d0bdcbde9 tier1/kcoreaddons/autotests/kformattest.h PRE-CREATION tier1/kcoreaddons/autotests/kformattest.cpp PRE-CREATION tier1/kcoreaddons/src/lib/CMakeLists.txt 638525f7b719bcd0bc1dfdf94debd51296521334 tier1/kcoreaddons/src/lib/util/kformat.h PRE-CREATION tier1/kcoreaddons/src/lib/util/kformat.cpp PRE-CREATION tier1/kcoreaddons/src/lib/util/kformatprivate.cpp PRE-CREATION tier1/kcoreaddons/src/lib/util/kformatprivate_p.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/114187/diff/ Testing --- Autotests copied from KLocale tests and improved. Thanks, John Layt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 114187: KFormat - Add new KFormat class
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114187/ --- Review request for KDE Frameworks, Albert Astals Cid, David Faure, and Kevin Ottens. Repository: kdelibs Description --- KFormat - Add new KFormat class KLocale offers a number of extra formatting options not yet available in Qt. The KFormat class adds these options to KCoreAddons: * formatByteSize() * formatDuration() * formatDecimalDuration() * formatSpelloutDuration() * formatRelativeDate() * formatRelativeDateTime() The KFormat class can be initialised with any QLocale to use in the date and number formatting, or the default locale can be easily accessed via KFormat(): QString result = KFormat().formatDuration(1000); There's a few things that need looking at here. The main one is the translation stuff because I had to convert from using ki18n to tr and it may have lost something in the process. In particular it looks like we'll actually need an en_US translation done to get the plurals right? If we can't make tr() work for these we'll have to move the class into k18n. The second is to look at the formatting options provided and decide if they are actually useful to have. The third is to confirm that the design is OK, I did think about making these simple static methods with an extra parm for QLocale, but I think this approach offers more future flexibility, and writing KFormat().formatDuration() is just as convenient as KFormat::formatDuration(). Diffs - tier1/kcoreaddons/autotests/CMakeLists.txt c8043576181e7d06663195d017be930d0bdcbde9 tier1/kcoreaddons/autotests/kformattest.h PRE-CREATION tier1/kcoreaddons/autotests/kformattest.cpp PRE-CREATION tier1/kcoreaddons/src/lib/CMakeLists.txt 638525f7b719bcd0bc1dfdf94debd51296521334 tier1/kcoreaddons/src/lib/util/kformat.h PRE-CREATION tier1/kcoreaddons/src/lib/util/kformat.cpp PRE-CREATION tier1/kcoreaddons/src/lib/util/kformatprivate.cpp PRE-CREATION tier1/kcoreaddons/src/lib/util/kformatprivate_p.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/114187/diff/ Testing --- Autotests copied from KLocale tests and improved. Thanks, John Layt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dot story on KDE contributions to Qt 5.2
On 24 November 2013 19:34, David Faure wrote: > > Is this supposed to be "added for Qt 5.2" only, or "added in Qt 5.0, 5.1 and > 5.2"? > This email says the former, but the document contains a lot of the earlier > stuff (mimetypes, qstandardpaths, ...) > > See the above doc for more, I wrote more details and updated the wiki page at > http://community.kde.org/Frameworks/Epics/Contributions_to_Qt5 to be clearer. I think we mainly want to highlight the 5.2 contributions seeing as it's to coincide with the 5.2 release, but we also want a paragraph or two mentioning previous contributions, partly as we didn't advertise those much at the time, but also to show this isn't a one-off thing but rather an ongoing and successful process. I'll try sketch out a few paragraphs tomorrow to give the story some structure. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [Kde-pim] PIM Sprint: Porting PIM to Frameworks
On 19 November 2013 22:59, Stephen Kelly wrote:
> John Layt wrote:
> Those TODO tasks are very 'vertical'. Many tasks, and most useful tasks in
> frameworks porting, are horizontal. The horizontal tasks should largely be
> done before the vertical ones. Horizontal tasks are things like:
>
> * Port existing code to modern APIs (eg port KBlog to KCalCore)
> * Remove use of to-be-deleted code (eg KCal)
> * Remove obsolete code (eg KCal)
> * Make it build
> ** Use compatibility layers (KDE4Support)
> ** Update the C++ code for changes in Qt, KDE and upstreams
> * Remove use of compatibility layers
> ** Remove buildsystem use of KDE4Support
> ** Remove C++ use of KDE4Support
> ** Both of the above can be parallelized
> * Make it cool
> ** API updates
> ** Refactoring
>
> That's the real todo list that should come before everything else you wrote
> in the wiki page. Note also that that todo list applies identically to *all*
> kde modules we're going to port. It also applied to the work already done in
> kdelibs.git.
>
> The point I want to stress is that you should focus on horizontal tasks when
> porting, not on vertical ones.
The idea of the wiki page was to set out the high level plan, document
what we currently have, and sketch out what we want the end-result to
be. Your porting steps above then pick up from there once people
actually start working on it. Call me old-fashioned waterfall model
guy, but I like to know where I'm heading first before breaking out my
code editor :-)
> Other steps already taken:
>
> * Include-what-you-use - Add includes which are 'missing' on porting.
> * Ensure that new conventions from KF5 such as C++11 language and library
> use don't conflict with existing code (see
> f237ca726d8ba66d377afaf0e3b5dce6b2d4e224 in kdepimlibs)
> * Use Q_SLOTS and Q_SIGNALS.
> * Replace kde4_add_library with add_library CMake command.
> * Ensure that KF5::KDE4Support provides maximum SC.
> ** This is what I've been doing lately. See gitk --author=steveire in kf5
>
> Note:
> * All of these are 'clean up tasks'
> * All of these should happen in master
> * These are already happening. See gitk --author=steveire in kdepimlibs
> * The above (partial) todo list is the same as should happen in all KDE
> modules we want to port. It should happen in the master branch. That makes
> the 'porting branch' small, readable, reviewable, and something others can
> learn from and replicate.
> * We can use kdepim{,libs} porting as a validation of the SC goals of KF5
> and KDE4Support. The time-to-release goal trumped that so far for plasma and
> related. It's important for all others though, so we should ensure that a
> 'clean' (see above) KDE module is easy to port.
Cool, great to know that you've been working on this already :-) Is
there a check-list and/or instructions somewhere for this stuff? Do
you need any help with these tasks, or are you happy to finish them
yourself?
>> We will drop all the old KResource
>> related code, KCal, and anything still using Qt3Support.
>
> Already done in my frameworks branch:
>
>
> http://quickgit.kde.org/?p=clones%2Fkdepimlibs%2Fskelly%2Fetmwork.git&a=shortlog&h=f97c0b8eff8cc3ab9f7b60146465271c021b7f6e
Yay! \O/ I didn't realise you were so advanced with the porting, that
certainly changes a lot of what we discussed at the sprint, and the
timeframes for finishing the work. If you had to guess at a timeframe
for how long before we can get to the point we can split, what would
it be?
>> We will have
>> a more relaxed approach than the kdelibs Frameworks and allow more
>> breaking of source compatibility like removing deprecated api and
>> renames.
>
> Good. That's something I'd certainly like to see more of in KF5 too. Time is
> the main reason that's not done there I think, because all resource and
> attention has been on 'splitting'. Much of kdelibs was written/designed in
> Qt 3 times and should be reviewed for modernness, appropriate use of more
> recent Qt APIs, resolving warnings (building KF5 shows *lots*) etc.
We also have the advantage that we have fewer clients using our
libraries, and when clients outside kdepim use them they have fairly
simple use cases. That means the main people we 'hurt' with major api
changes are ourselves, so it's really for our own benefit :-)
>> We will also consider splitting existing libraries into
>> smaller libraries if they will be more useful, especially focusing on
>> the split between KDE integration, and the underlying libraries and
>> utilities that could be used by other PIM apps.
>
> Yes, I think libakonadi is a pr
Re: [Kde-pim] PIM Sprint: Porting PIM to Frameworks
On 19 November 2013 22:59, Stephen Kelly wrote:
> John Layt wrote:
> Those TODO tasks are very 'vertical'. Many tasks, and most useful tasks in
> frameworks porting, are horizontal. The horizontal tasks should largely be
> done before the vertical ones. Horizontal tasks are things like:
>
> * Port existing code to modern APIs (eg port KBlog to KCalCore)
> * Remove use of to-be-deleted code (eg KCal)
> * Remove obsolete code (eg KCal)
> * Make it build
> ** Use compatibility layers (KDE4Support)
> ** Update the C++ code for changes in Qt, KDE and upstreams
> * Remove use of compatibility layers
> ** Remove buildsystem use of KDE4Support
> ** Remove C++ use of KDE4Support
> ** Both of the above can be parallelized
> * Make it cool
> ** API updates
> ** Refactoring
>
> That's the real todo list that should come before everything else you wrote
> in the wiki page. Note also that that todo list applies identically to *all*
> kde modules we're going to port. It also applied to the work already done in
> kdelibs.git.
>
> The point I want to stress is that you should focus on horizontal tasks when
> porting, not on vertical ones.
The idea of the wiki page was to set out the high level plan, document
what we currently have, and sketch out what we want the end-result to
be. Your porting steps above then pick up from there once people
actually start working on it. Call me old-fashioned waterfall model
guy, but I like to know where I'm heading first before breaking out my
code editor :-)
> Other steps already taken:
>
> * Include-what-you-use - Add includes which are 'missing' on porting.
> * Ensure that new conventions from KF5 such as C++11 language and library
> use don't conflict with existing code (see
> f237ca726d8ba66d377afaf0e3b5dce6b2d4e224 in kdepimlibs)
> * Use Q_SLOTS and Q_SIGNALS.
> * Replace kde4_add_library with add_library CMake command.
> * Ensure that KF5::KDE4Support provides maximum SC.
> ** This is what I've been doing lately. See gitk --author=steveire in kf5
>
> Note:
> * All of these are 'clean up tasks'
> * All of these should happen in master
> * These are already happening. See gitk --author=steveire in kdepimlibs
> * The above (partial) todo list is the same as should happen in all KDE
> modules we want to port. It should happen in the master branch. That makes
> the 'porting branch' small, readable, reviewable, and something others can
> learn from and replicate.
> * We can use kdepim{,libs} porting as a validation of the SC goals of KF5
> and KDE4Support. The time-to-release goal trumped that so far for plasma and
> related. It's important for all others though, so we should ensure that a
> 'clean' (see above) KDE module is easy to port.
Cool, great to know that you've been working on this already :-) Is
there a check-list and/or instructions somewhere for this stuff? Do
you need any help with these tasks, or are you happy to finish them
yourself?
>> We will drop all the old KResource
>> related code, KCal, and anything still using Qt3Support.
>
> Already done in my frameworks branch:
>
>
> http://quickgit.kde.org/?p=clones%2Fkdepimlibs%2Fskelly%2Fetmwork.git&a=shortlog&h=f97c0b8eff8cc3ab9f7b60146465271c021b7f6e
Yay! \O/ I didn't realise you were so advanced with the porting, that
certainly changes a lot of what we discussed at the sprint, and the
timeframes for finishing the work. If you had to guess at a timeframe
for how long before we can get to the point we can split, what would
it be?
>> We will have
>> a more relaxed approach than the kdelibs Frameworks and allow more
>> breaking of source compatibility like removing deprecated api and
>> renames.
>
> Good. That's something I'd certainly like to see more of in KF5 too. Time is
> the main reason that's not done there I think, because all resource and
> attention has been on 'splitting'. Much of kdelibs was written/designed in
> Qt 3 times and should be reviewed for modernness, appropriate use of more
> recent Qt APIs, resolving warnings (building KF5 shows *lots*) etc.
We also have the advantage that we have fewer clients using our
libraries, and when clients outside kdepim use them they have fairly
simple use cases. That means the main people we 'hurt' with major api
changes are ourselves, so it's really for our own benefit :-)
>> We will also consider splitting existing libraries into
>> smaller libraries if they will be more useful, especially focusing on
>> the split between KDE integration, and the underlying libraries and
>> utilities that could be used by other PIM apps.
>
> Yes, I think libakonadi is a pr
PIM Sprint: Porting PIM to Frameworks
Hi, At the PIM Sprint a major topic discussed was the plans for migrating to Qt5 / KF5, in particular how and when to convert from "kdepimlibs" to "PIM Frameworks". I've started a wiki page to document the process required and to co-ordinate the tasks at http://community.kde.org/Frameworks/Epics/kdepimlibs. To start with, there's already been two major steps taken: * Akonadi supports Qt5 since v1.11 * All of KDEPIM has already been ported to the CMake automoc Dan and Volker discussed a number of changes to Akonadi, how it is organised, and the removal of unsupported and deprecated code, which I'll leave to them to document. It was agreed that the ideal plan for kdepimlibs was to split all the libraries up and make them all stand-alone Frameworks, aiming for Tier 2 or even Tier 1 where possible. We will drop all the old KResource related code, KCal, and anything still using Qt3Support. We will have a more relaxed approach than the kdelibs Frameworks and allow more breaking of source compatibility like removing deprecated api and renames. We will also consider splitting existing libraries into smaller libraries if they will be more useful, especially focusing on the split between KDE integration, and the underlying libraries and utilities that could be used by other PIM apps. We are fortunate that kdepimlibs is already mostly structured as standalone libraries, so the build system splitting shouldn't be too hard. Most of the hard work will be source incompatibility related around KDateTime, KTimeZone, KLocale, and using Qt's tr() instead of KDE's i18n() for lower tier frameworks. The kdepim-runtime will need to be reviewed in the same way as kde-runtime with the aim of moving everything either into the Framework or into kdepim proper, with kdepim-runtime then being removed. The time frame is still uncertain, we're reluctant to divert developer effort from bug fixing in the 4 branch as that is what most users will care about for the next 2-3 years, but are aware that some of the libraries are dependencies for Plasma 2 and are needed sooner rather than later. The rough plan agreed is: * Wait for the KF5 split to be completed and the preview released, then fork a kdepimlibs frameworks branch * Delete all known obsolete code * Blindly port the remaining code to Qt5 / KF5 / kde4support with no api or code clean-ups * Make any internal splits, code moves, and library renaming required * Split kdepimlibs * Do api and code clean-ups, port away from kde4support, etc * Individual PIM Frameworks will be released as and when they are ready This means the initial branch should happen in 2-3 months, during which time we can plan what we want to obsolete, any other splitting we need to do, and the priority order for the libraries. One step needed before forking is to review the existing frameworks branch in kdepimlibs to see if there is actually anything useful there, if not it needs to be deleted first. We would like to ask the Frameworks community to assist us by taking the lead on the "blind port to Qt5 / KF5" step as they have the experience to quickly achieve this, i.e. changing includes, using tr(), etc. The initial port to KF5 may use kde4support for simplicity, but the released Frameworks must not use kde4support at all. This allows the initial port to be a 'blind' port by non-pim people, but the other steps will require considerable effort from the maintainers. By releasing each library as it is ready we help speed up availability for others to use them, especially for Plasma 2, but we do run the risk of releasing libraries before they have had any serious usage in our KDEPIM apps. This will be judged on a case-by-case basis depending on how much has been changed, and libraries only used by KDEPIM could be held back. Following this plan we would hope to have all the PIM Frameworks released within a year, or ready to be used in porting kdepim. EVERYONE needs to help with the following steps over the next few days: * Review the wiki page to ensure the information there is correct * Split out any other "Code Units" not currently documented * Fill in the Description field so non-PIM people can understand what a Unit does * Fill in all the Maintainer name fields so we have a name against every Unit * If there is no active Maintainer and you know enough to make decisions, you're Maintainer for this purpose MAINTAINERS need to perform the following steps before the frameworks branch is forked: * Decide what Code Units are to be deleted * Document the dependencies required for the Unit * Determine any usage of the Unit outside of kdepim * Decide what priority the Unit is * Decide on any internal splits of the Unit moving of code into other Units * Take a guess at the Frameworks Tier to aim for * Email the list with the details of decisions made for review If during this review you see any changes or clean-ups you can make before the frameworks fork then please do so, e.g. clean-up un-needed incl
Re: KF5 Update Meeting Minutes 2013-w47
On 19 November 2013 16:53, Kevin Ottens wrote: > Announcement: > * We're not yet ready for the splitting so it's postponed by a week; > * Please get open tasks done; At the PIM Sprint Alex passed the byte formatting TODO on to me which I've started coding, I'll try push a review in a couple of days: * New class KFormat will be added to KCoreAddons * Will use tr() rather than i18n(), which is proving the hard part * Will ignore any user settings, only formats as requested via api * Will have static methods for formatByteSize(), formatDecimalDuration(), formatSpelloutDuration() and formatRelativeDate() I'm still figuring out the tr() part and loading of catalogues and the rest, especially for static methods. As this doesn't involve moving any code (the old methods stay in KLocale in kde4support), and nothing else in Frameworks calls these methods, then in theory this shouldn't block the split from happening, but I'll try get it in before then. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Dot story on KDE contributions to Qt 5.2
Hi, There was a discussion on the promo list a couple of weeks back about doing a Dot story to coincide with the release of Qt 5.2 highlighting KDE's contributions. Jos started an Etherpad at https://notes.kde.org/p/Platform5DotStoryForQt52 for notes on this story. If you've made a contribution to Qt 5.2 can you please add 1-2 sentences summarising each contribution, in particular explaining how our users or the wider Qt community will benefit from what you have done. We can then later work it up into a proper story. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review43331 --- Ship it! Ship It! - John Layt On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113260/ > --- > > (Updated Oct. 22, 2013, 4:49 p.m.) > > > Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. > > > Repository: kde-runtime > > > Description > --- > > Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out > that all the stuff KTZD was doing was added in QTimeZone, that includes > reading correct system files/env variables to obtain the timezone and > returning the proper system zone (KTZD did all this by itself). It also > doesn't need to parse the timezone files itself or watch for their changes as > QTimeZone objects are not stored. > > So now it's just a thin module watching /etc/timezone (used by Debian-based > distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian > in conjunction with /etc/timezone) for changes and if it detects a change, it > checks if the new timezone is really different and if it is, it sends out a > DBus signal "timeZoneChange". I changed it from "configChanged" as I think > "timeZoneChanged" makes way more sense. > > I didn't touch the Windows part as I have no way to test, would be nice if > someone could help with that. > > EDIT: I removed the other two DBus signals which were not used and I'm unsure > KTZD is the correct place for that now anyway. The only usage in > KSystemTimeZone can be replaced by own KDirWatch instance. > > > Diffs > - > > CMakeLists.txt a5ec93d > ktimezoned/CMakeLists.txt bafc85e > ktimezoned/ktimezoned.h ff21807 > ktimezoned/ktimezoned.cpp f380c09 > ktimezoned/ktimezoned_win.h 26e21cc > ktimezoned/ktimezoned_win.cpp cadfe3a > ktimezoned/ktimezonedbase.h ca00aca > ktimezoned/org.kde.KTimeZoned.xml daaa0b7 > > Diff: http://git.reviewboard.kde.org/r/113260/diff/ > > > Testing > --- > > Tested by changing the timezone in different ways, change was detected and > signalled out. > > > Thanks, > > Martin Klapetek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
> On Nov. 4, 2013, 4:12 p.m., John Layt wrote: > > I've asked on the Qt Development list about Qt 5 Solaris support. I'm told > > it builds and works to some extent, and patches are welcome, but not > > without having been tested on a real Solaris build first, which I have no > > desire to do. I don't think much is required, Solaris uses the Olsen tz > > files, just with different patches and possibly a different zonetab layout, > > but I don't want to code blind. So we have two options, one is not worry > > about Solaris support for now, and if anyone (Ade?) complains then ask them > > to contribute upstream (with my help). The alternative is to keep the > > Solaris code in ktimezoned, including calls to return the current system > > time zone and the list of available time zones, and on other platforms just > > wrap the Qt calls. Opinions? s/patches/paths - John --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review42961 --- On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113260/ > --- > > (Updated Oct. 22, 2013, 4:49 p.m.) > > > Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. > > > Repository: kde-runtime > > > Description > --- > > Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out > that all the stuff KTZD was doing was added in QTimeZone, that includes > reading correct system files/env variables to obtain the timezone and > returning the proper system zone (KTZD did all this by itself). It also > doesn't need to parse the timezone files itself or watch for their changes as > QTimeZone objects are not stored. > > So now it's just a thin module watching /etc/timezone (used by Debian-based > distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian > in conjunction with /etc/timezone) for changes and if it detects a change, it > checks if the new timezone is really different and if it is, it sends out a > DBus signal "timeZoneChange". I changed it from "configChanged" as I think > "timeZoneChanged" makes way more sense. > > I didn't touch the Windows part as I have no way to test, would be nice if > someone could help with that. > > EDIT: I removed the other two DBus signals which were not used and I'm unsure > KTZD is the correct place for that now anyway. The only usage in > KSystemTimeZone can be replaced by own KDirWatch instance. > > > Diffs > - > > CMakeLists.txt a5ec93d > ktimezoned/CMakeLists.txt bafc85e > ktimezoned/ktimezoned.h ff21807 > ktimezoned/ktimezoned.cpp f380c09 > ktimezoned/ktimezoned_win.h 26e21cc > ktimezoned/ktimezoned_win.cpp cadfe3a > ktimezoned/ktimezonedbase.h ca00aca > ktimezoned/org.kde.KTimeZoned.xml daaa0b7 > > Diff: http://git.reviewboard.kde.org/r/113260/diff/ > > > Testing > --- > > Tested by changing the timezone in different ways, change was detected and > signalled out. > > > Thanks, > > Martin Klapetek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review42961 --- I've asked on the Qt Development list about Qt 5 Solaris support. I'm told it builds and works to some extent, and patches are welcome, but not without having been tested on a real Solaris build first, which I have no desire to do. I don't think much is required, Solaris uses the Olsen tz files, just with different patches and possibly a different zonetab layout, but I don't want to code blind. So we have two options, one is not worry about Solaris support for now, and if anyone (Ade?) complains then ask them to contribute upstream (with my help). The alternative is to keep the Solaris code in ktimezoned, including calls to return the current system time zone and the list of available time zones, and on other platforms just wrap the Qt calls. Opinions? - John Layt On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113260/ > --- > > (Updated Oct. 22, 2013, 4:49 p.m.) > > > Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. > > > Repository: kde-runtime > > > Description > --- > > Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out > that all the stuff KTZD was doing was added in QTimeZone, that includes > reading correct system files/env variables to obtain the timezone and > returning the proper system zone (KTZD did all this by itself). It also > doesn't need to parse the timezone files itself or watch for their changes as > QTimeZone objects are not stored. > > So now it's just a thin module watching /etc/timezone (used by Debian-based > distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian > in conjunction with /etc/timezone) for changes and if it detects a change, it > checks if the new timezone is really different and if it is, it sends out a > DBus signal "timeZoneChange". I changed it from "configChanged" as I think > "timeZoneChanged" makes way more sense. > > I didn't touch the Windows part as I have no way to test, would be nice if > someone could help with that. > > EDIT: I removed the other two DBus signals which were not used and I'm unsure > KTZD is the correct place for that now anyway. The only usage in > KSystemTimeZone can be replaced by own KDirWatch instance. > > > Diffs > - > > CMakeLists.txt a5ec93d > ktimezoned/CMakeLists.txt bafc85e > ktimezoned/ktimezoned.h ff21807 > ktimezoned/ktimezoned.cpp f380c09 > ktimezoned/ktimezoned_win.h 26e21cc > ktimezoned/ktimezoned_win.cpp cadfe3a > ktimezoned/ktimezonedbase.h ca00aca > ktimezoned/org.kde.KTimeZoned.xml daaa0b7 > > Diff: http://git.reviewboard.kde.org/r/113260/diff/ > > > Testing > --- > > Tested by changing the timezone in different ways, change was detected and > signalled out. > > > Thanks, > > Martin Klapetek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Flaky kcodecs test depending on qt configuration
On Thursday 24 Oct 2013 07:35:48 Kevin Ottens wrote: > Hello, > > On Wednesday 23 October 2013 21:43:59 Sune Vuorela wrote: > > Depending on the Qt configuration (built with or without ICU), the > > KCharsetsTest::testEncodingNames() test fails (in the #if) block. > > > > If Qt built with ICU, the tests succeeds and the ISO 8859-16, jis7 and > > winsami2 codecs are as expected not found. > > > > If Qt is built without ICU, those codecs are found, and the test that > > expects them to not be there fails. > > > > There doesn't seem to be api to check wether or not ICU is available for > > QTextCodec. > > > > One solution could be to just skip finding those 3 codecs in all cases. > > > > Other suggestions? > > Not on my side, but maybe John? Not a clue, text codecs are so not my thing :-) Thiago will be the best person to ask as that's very much his area of expertise. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
On 24 October 2013 07:33, Kevin Ottens wrote: > On Wednesday 23 October 2013 20:40:19 John Layt wrote: >> * The obviously place to move it is k18n, as either part of >> KLocalizedString or in a new KByteFormatter class? > > Hm, wouldn't that fit in KCoreAddons? >> * No locale file overrides the default BinaryUnitDialect, so we only >> have to worry about reading any user override from kglobals > > Or have that done by the caller (thinking about KCoreAddons there, it couldn't > use KConfig for the default). Well, that becomes the central question then, if we allow users to set a global override or not? I don't think its very useful to tell all apps that they need to read the global config themselves to see how to format the bytes, they would reasonably expect that that is what the method is there to hide from them. It would effectively become an application-level setting depending on if the app decides to read the config. On the other hand, if Qt eventually gains support it can use the setting from there. If we're happy to ignore user settings for now then KCoreAddons will be fine. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Keep the Things You Forgot
On 24 October 2013 14:54, Mario Fux KDE ML wrote: >> You probably mean dot.kde.org/2013/09/25/frameworks-5 > > And this: > http://dot.kde.org/2013/09/04/kde-release-structure-evolves Yes, that explains Frameworks and Workspaces, albeit a little fuzzy on Workspaces vs Plasma, but it kinda leaves Applications hanging, and with good reason as we really don't know what's happening there yet. Talking to a few people there does seem to be an interest in having a clean-up of the modules and apps, reducing the number of apps in the "official" release, having fewer "essential" applications of higher quality, and killing off the "SC" name once and for all. I'm also keen on breaking down the whole Modules vs Extragear distinction, they're all KDE Applications built by the same KDE Community, just with different release schedules. How that all might work is something the community as a whole needs to discuss. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Keep the Things You Forgot
On 23 October 2013 21:49, Mark wrote: > A blog post that i'd very much like from you (Aaron) is about the next > big KDE version, the naming and how the complete collection is going > to be called or if there even will be a collection release (what KDE > SC is now). Press is still getting that wrong, i tend to get it wrong > and other people talking about KDE seem to get it wrong. Usually it's > just being referred to as "KDE 5" which is wrong. (Frameworks 5, > Plasma 2, ...). So if you have the time, a blog about that would be > wonderful and very educational ^_^ H, actually I had an email I was writing about that, must finish it off... Basically just a discussion starter on the community list to discuss the future of Modules and Apps and the SC and how we need to do a big clean-up and re-brand for Gen5. I think most people here have a loose idea of where we are heading, but it would probably be a good idea to make it more explicit at some stage. Kick me at the PIM Sprint if I haven't sent it by then :-) John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
On 23 October 2013 12:56, Aleix Pol wrote: > On Tue, Oct 22, 2013 at 2:03 PM, David Faure wrote: >> >> On Thursday 17 October 2013 23:47:40 Aleix Pol wrote: >> > Well maybe I could help with this, but I'd need to know what do you >> > think >> > it would be the most appropriate solution. >> >> I'd say, split it out into a separate function for KF5, and later on, if >> you >> feel like it, contribute it to Qt for 5.3. > > I created a task for it on the kdelibs cleanups [1] so anybody can pick it > up. > > Aleix > > [1] http://community.kde.org/Frameworks/Epics/kdelibs_cleanups OK, here's a high-level suggested plan: * The obviously place to move it is k18n, as either part of KLocalizedString or in a new KByteFormatter class? * Move KLocale::BinarySizeUnits, KLocale::BinaryUnitDialect, and KLocale::formatByteSize() * Do we make it a pure static method? Or require an instance to be created? * If static-only then don't need setBinaryUnitDialect(), and binaryUnitDialect() will become a static defaultBinaryUnitDialect() * No locale file overrides the default BinaryUnitDialect, so we only have to worry about reading any user override from kglobals * Default to using QLocale() for number formatting, but need to be able to set a different locale to use. If static-only then just add an extra parameter to override the locale, otherwise will need a setLocale() * Don't forget the tests :-) The only other thing we may also want to keep from KLocale is formatDuration() / prettyFormatDuration(). It's on my todo list for Qt 5.3 and not used many places, but we may want to keep our version for now. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
> On Oct. 16, 2013, 12:15 p.m., John Layt wrote: > > Wow, there sure is a lot of code in there catering for all the possible > > corner cases :-) QTimeZone has a lot less places it checks, so I'll need > > to do an in-depth comparison, but given Qt5 will only support modern > > distros I think most of it is redundant. > > > > One thought is if we still want to have a signal that the system database > > has been updated? While Qt doesn't cache the time zone data, the apps > > probably will cache the QTimeZone instances themselves and may need to be > > told that the database has changed so they can take action. Then again, > > it's not something that will happen very often, and what will the apps do > > in response? If they refresh their cache the shared copies in QDateTime > > won't update. I guess QTimeZone will need a "reloadData()" method added > > instead. > > > > I've looked at the Windows code and it mostly looks OK, all it does is > > monitor the registry for changes. What you do need to change is the DBus > > signal from "configChanged" to your new "timeZoneChanged" signal. > > > > With regards the signal name change, does it need to go in the porting > > guide or somewhere so people know it has changed? > > > > In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and > > TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still > > need the daemon for now. > > Martin Klapetek wrote: > > Wow, there sure is a lot of code in there catering for all the possible > corner cases :-) QTimeZone has a lot less places it checks, so I'll need to > do an in-depth comparison, but given Qt5 will only support modern distros I > think most of it is redundant. > > Part of that is support for Solaris, but I see Solaris is not supported > by Qt anymore [1][2], so I just removed it altogether. > > > One thought is if we still want to have a signal that the system > database has been updated? While Qt doesn't cache the time zone data, the > apps probably will cache the QTimeZone instances themselves and may need to > be told that the database has changed so they can take action. > > I think it might be worth having it...I'll add it back, can't hurt :) > > > I've looked at the Windows code and it mostly looks OK, all it does is > monitor the registry for changes. What you do need to change is the DBus > signal from "configChanged" to your new "timeZoneChanged" signal. > > Ah yes, I forgot to add that to the patch, sorry. > > > With regards the signal name change, does it need to go in the porting > guide or somewhere so people know it has changed? > > I wanted to add it, but that's in kdelibs. Question is, should there be a > guide for runtime/workspace too? > > > In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and > TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still > need the daemon for now. > > Ok, keep us posted. (It would be cool to have cross-desktop solution for > this too...or system-wide spec at least, so we could use non-qt/-kde apps > still supporting timezone changes, but oh well). > > > [1] - http://qt-project.org/doc/qt-5.1/qtdoc/supported-platforms.html > [2] - http://qt.digia.com/Product/Supported-Platforms/ > > David Faure wrote: > There are still people around with a Solaris system. Not supported > doesn't mean we should actively remove existing support, IMHO. > > About the porting guide: the distinction between kdelibs and kde-runtime > will disappear, given the framework-ification. So treat it as a porting guide > "from kde 4 to kde-frameworks", i.e. it's fine to include "runtime" stuff in > there. > > About a solution in Qt --- that means each and every Qt app will have to > monitor the same timezone file(s), isn't that a bit too expensive? (not sure, > just wondering) > > Martin Klapetek wrote: > > There are still people around with a Solaris system. Not supported > doesn't mean we should actively remove existing support, IMHO. > > Is there any attempt to make sure KF5/PW2 is working with Solaris? > Because if the underlying components won't work on Solaris, there's no point > in keeping Solaris code in one tiny module sitting on top of the bigger > blocks. > > > it's fine to include "runtime" stuff in there. &g
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review42017 --- ktimezoned/ktimezonedbase.h <http://git.reviewboard.kde.org/r/113260/#comment30665> Not generic enough, is Unix specific. Perhaps timeZoneDatabaseUpdated() without the file path? ktimezoned/org.kde.KTimeZoned.xml <http://git.reviewboard.kde.org/r/113260/#comment30664> You need to keep this, or a variant of it. I don't think this is generic enough, it only applies to the zonetab file on Unix, and the data files could be updated without the zonetab being changed, and it doesn't apply to Windows at all. I'd suggest a generic timeZoneDatabaseUpdated() signal instead that triggers on Unix if any file in the zone path tree (/usr/share/zoneinfo or wherever) is updated, or for Windows if any of the registry database is updated (I can do that later). - John Layt On Oct. 18, 2013, 1 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113260/ > --- > > (Updated Oct. 18, 2013, 1 p.m.) > > > Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. > > > Repository: kde-runtime > > > Description > --- > > Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out > that all the stuff KTZD was doing was added in QTimeZone, that includes > reading correct system files/env variables to obtain the timezone and > returning the proper system zone (KTZD did all this by itself). It also > doesn't need to parse the timezone files itself or watch for their changes as > QTimeZone objects are not stored. > > So now it's just a thin module watching /etc/timezone (used by Debian-based > distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian > in conjunction with /etc/timezone) for changes and if it detects a change, it > checks if the new timezone is really different and if it is, it sends out a > DBus signal "timeZoneChange". I changed it from "configChanged" as I think > "timeZoneChanged" makes way more sense. > > I didn't touch the Windows part as I have no way to test, would be nice if > someone could help with that. > > EDIT: I removed the other two DBus signals which were not used and I'm unsure > KTZD is the correct place for that now anyway. The only usage in > KSystemTimeZone can be replaced by own KDirWatch instance. > > > Diffs > - > > ktimezoned/ktimezoned.cpp f380c09 > ktimezoned/ktimezoned.h ff21807 > ktimezoned/CMakeLists.txt bafc85e > ktimezoned/ktimezoned_win.h 26e21cc > ktimezoned/ktimezoned_win.cpp cadfe3a > ktimezoned/ktimezonedbase.h ca00aca > ktimezoned/org.kde.KTimeZoned.xml daaa0b7 > > Diff: http://git.reviewboard.kde.org/r/113260/diff/ > > > Testing > --- > > Tested by changing the timezone in different ways, change was detected and > signalled out. > > > Thanks, > > Martin Klapetek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
On 17 October 2013 01:51, Aleix Pol wrote: > Hi, > I was trying to port some application to Qt/KF5, then I realized that I > didn't know how to port KLocale::formatByteSize. I don't see anything in > QLocale for this, so I feel a bit stuck. Also I don't see any information in > KDE5Porting.html > > Anybody has an idea of what's the solution? Hi, Byte size formatting is not available in Qt, nor natively on any other platform or ICU/CLDR. It was the one thing in KLocale we needed to keep and I think Steve (?) at some stage was looking at breaking it out as a separate utility class. Someone recently submitted a patch to Qt for just this, but Thiago quickly rejected it do to several issues, mostly that there's no standard way of doing it across all platforms. There's a small chance it could get in to 5.3, but it's not a high priority for Qt right now.. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review41816 --- Wow, there sure is a lot of code in there catering for all the possible corner cases :-) QTimeZone has a lot less places it checks, so I'll need to do an in-depth comparison, but given Qt5 will only support modern distros I think most of it is redundant. One thought is if we still want to have a signal that the system database has been updated? While Qt doesn't cache the time zone data, the apps probably will cache the QTimeZone instances themselves and may need to be told that the database has changed so they can take action. Then again, it's not something that will happen very often, and what will the apps do in response? If they refresh their cache the shared copies in QDateTime won't update. I guess QTimeZone will need a "reloadData()" method added instead. I've looked at the Windows code and it mostly looks OK, all it does is monitor the registry for changes. What you do need to change is the DBus signal from "configChanged" to your new "timeZoneChanged" signal. With regards the signal name change, does it need to go in the porting guide or somewhere so people know it has changed? In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still need the daemon for now. - John Layt On Oct. 15, 2013, 8:09 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113260/ > --- > > (Updated Oct. 15, 2013, 8:09 p.m.) > > > Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. > > > Repository: kde-runtime > > > Description > --- > > Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out > that all the stuff KTZD was doing was added in QTimeZone, that includes > reading correct system files/env variables to obtain the timezone and > returning the proper system zone (KTZD did all this by itself). It also > doesn't need to parse the timezone files itself or watch for their changes as > QTimeZone objects are not stored. > > So now it's just a thin module watching /etc/timezone (used by Debian-based > distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian > in conjunction with /etc/timezone) for changes and if it detects a change, it > checks if the new timezone is really different and if it is, it sends out a > DBus signal "timeZoneChange". I changed it from "configChanged" as I think > "timeZoneChanged" makes way more sense. > > I didn't touch the Windows part as I have no way to test, would be nice if > someone could help with that. > > EDIT: I removed the other two DBus signals which were not used and I'm unsure > KTZD is the correct place for that now anyway. The only usage in > KSystemTimeZone can be replaced by own KDirWatch instance. > > > Diffs > - > > ktimezoned/CMakeLists.txt bafc85e > ktimezoned/ktimezoned.h ff21807 > ktimezoned/ktimezoned.cpp f380c09 > ktimezoned/ktimezoned_win.h 26e21cc > ktimezoned/ktimezoned_win.cpp cadfe3a > ktimezoned/ktimezonedbase.h ca00aca > ktimezoned/org.kde.KTimeZoned.xml daaa0b7 > > Diff: http://git.reviewboard.kde.org/r/113260/diff/ > > > Testing > --- > > Tested by changing the timezone in different ways, change was detected and > signalled out. > > > Thanks, > > Martin Klapetek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 14 October 2013 12:55, Kevin Ottens wrote: > Giving it a closer look, I'm wondering: are you sure about this course of > action? > KDateTimeEdit is basically a KDateComboBox and a KTimeComboBox layouted > together. So deprecating those two without deprecating KDateTimeEdit sounds > weird to me... In particular internally it could/should use KDateEdit (which > is forked several times and not in kdelibs ATM) which is a much more > interesting widget. > > At that point I would be tempted to move KDateTimeEdit to kde4support too as > it's not used anyway and push people toward using stock Qt widgets to their > date/time needs. > > It means the only two widgets we would save from the kde4support fate are > KDatePicker and later on KDateEdit (once all its forks are merged or we pick > one implementation from the lot). KDateEdit and KTimeEdit are forks of KDateComboBox and KTimeComboBox with extra features added, which were then copied around a lot. KDateTimeEdit was a new kdelibs widget in 4.8 designed to replace all the forks and merge all the extra features into one clean new widget, which was done in consultation with the apps involved (I think you even did the review?). Why none of the apps maintaining their own forks have changed over I don't know, I certainly told them it was available, but it may be worth asking them to find out why. KDateTimeEdit can replace all of KDateEdit, KTimeEdit, KDateComboBox, and KTimeComboBox simply by setting the mode to use, hence why I prefer for it to be the one that is kept if any are. Another plus is it is only derived from QWidget so can have its internals changed, unlike KDateWidget and KDateComboBox which are derived from QComboBox and KComboBox. Pushing people to use the Qt widgets might be preferable, but we'd need to do a feature-by-feature comparison to see if people would actually want to use them or if it would just lead to more forks. Also it would need to be an either/or thing, as the date edit widgets need a date picker pop-up, so the two go together. Ideally I'd have time to write brand new Qt widgets, but I can't guarantee that. Speaking of which, I was looking at KDatePicker vs QCalendarWidget situation, and here's my analysis. - K has optional close button - K has next/prev year and month buttons, Q only month buttons - K has year edit pop-up, Q has spin box - K has Today button - K has visible line edit for date, Q has hidden entry when type numbers - K has week selector combo - K has optional right-click context menu (unused) - K can set font size (prob obsolete?) - K has more signals - K has custom date painting, can set fg/bg colour and bg shape circle/square - Q has custom date painting using QTextCharFormat - Q can set nav bar invisible, K uses separate KDateTable class - Q can change header day name length, can format with QTextCharFormat - Q has optional week number column, can format with QTextCharFormat - Q can toggle visible grid - Q can set min/max date, but only in 100AD to 7999AD range - Q can override first day of week - Q can set editable or not editable - Q can set single date selction or no selection Basically QCalendarWidget has better guts, more flexability and themability, but KDatePicker looks better and has better usability. We may be able to extend QCalendarWidget with some of the KDE features, but that would require buy-in from the Widgets maintainers. Current Q looks ugly when used with Oxygen, it doesn't seem to pick up any themeing? Then again, KDateTable is not exactly very themed either. I'm not sure what the best option is here. If others could have a play with QCalendarWidget and give an opinion on whether it performs well enough or not? Also, how receptive have the QWidgets maintainers been to visible changes? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 14 October 2013 12:55, Kevin Ottens wrote: > Giving it a closer look, I'm wondering: are you sure about this course of > action? > KDateTimeEdit is basically a KDateComboBox and a KTimeComboBox layouted > together. So deprecating those two without deprecating KDateTimeEdit sounds > weird to me... In particular internally it could/should use KDateEdit (which > is forked several times and not in kdelibs ATM) which is a much more > interesting widget. > > At that point I would be tempted to move KDateTimeEdit to kde4support too as > it's not used anyway and push people toward using stock Qt widgets to their > date/time needs. > > It means the only two widgets we would save from the kde4support fate are > KDatePicker and later on KDateEdit (once all its forks are merged or we pick > one implementation from the lot). > > Opinion? Hi, KDateEdit and KTimeEdit are forks of KDateComboBox and KTimeComboBox with extra features added, which were then copied around a lot. KDateTimeEdit was a new kdelibs widget in 4.8 designed to replace all the forks and merge all the extra features into one clean new widget, which was done in consultation with the apps involved (I think you even did the review?). Why none of the apps maintaining their own forks have changed over I don't know, I certainly told them it was available, but it may be worth asking them to find out why. KDateTimeEdit can replace all of KDateEdit, KTimeEdit, KDateComboBox, and KTimeComboBox simply by setting the mode to use, hence why I prefer for it to be the one that is kept if any are. Another plus is it is only derived from QWidget so can have its internals changed, unlike KDateWidget and KDateComboBox which are derived from QComboBox and KComboBox. Pushing people to use the Qt widgets might be preferable, but we'd need to do a feature-by-feature comparison to see if people would actually want to use them or if it would just lead to more forks. Also it would need to be an either/or thing, as the date edit widgets need a date picker pop-up, so the two go together. Ideally I'd have time to write brand new Qt widgets, but I can't guarantee that. Speaking of which, I was looking at KDatePicker vs QCalendarWidget situation, and here's my analysis. - K has optional close button - K has next/prev year and month buttons, Q only month buttons - K has year edit pop-up, Q has spin box - K has Today button - K has visible line edit for date, Q has hidden entry when type numbers - K has week selector combo - K has optional right-click context menu (unused) - K can set font size (prob obsolete?) - K has more signals - K has custom date painting, can set fg/bg colour and bg shape circle/square - Q has custom date painting using QTextCharFormat - Q can set nav bar invisible, K uses separate KDateTable class - Q can change header day name length, can format with QTextCharFormat - Q has optional week number column, can format with QTextCharFormat - Q can toggle visible grid - Q can set min/max date, but only in 100AD to 7999AD range - Q can override first day of week - Q can set editable or not editable - Q can set single date selction or no selection Basically QCalendarWidget has better guts, more flexability and themability, but KDatePicker looks better and has better usability. We may be able to extend QCalendarWidget with some of the KDE features, but that would require buy-in from the Widgets maintainers. Current Q looks ugly when used with Oxygen, it doesn't seem to pick up any themeing? Then again, KDateTable is not exactly very themed either. I'm not sure what the best option is here. If others could have a play with QCalendarWidget and give an opinion on whether it performs well enough or not? Also, how receptive have the QWidgets maintainers been to visible changes? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 24 September 2013 19:24, Kevin Ottens wrote: > On Tuesday 24 September 2013 19:03:21 John Layt wrote: >> I'll do some analysis on the use of all the widgets and what ones are >> worth keeping, and look at the Qt widgets to see if they're worth >> switching to, if not before then at Qt Dev Days / Qt Contributors Day. > > OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We > really need to put this issue to a rest, it's been lingering for way too long. > Really looking forward to your analysis! Replying to all the list, damn gmail not knowing about mailing lists :-\ And here's my analysis :-) tl;dr: * Port KDateTimeEdit, KDatePicker, KDateTable and KTimeZoneWidget to Qt5. * Move KDateTimeWidget, KDateWidget, KDateComboBox and KTimeComboBox to kde4support General rule: Any widget that uses KDateTime, KCalendarSystem, KTimeZone, or KLocale must either go to kde4support or be ported. Porting would require removing all uses of these K classes and using QDateTime, QTimeZone and QLocale instead. KCalendarSystem would be replaced by using QLocale, as QLocale will embed the QCalendarSystem class to be used, as well as translations, formatters, etc. The widgets calendar api setCalendar(), setCalendarSystem() and calendar() would be replaced by setLocale() and locale(). No apps I checked currently use the calendar api on the widgets. Internal code accessing date/time values like day() via KGlobal::calendar() would change to directly accessing QDate or QTime for now, after Qt 5.3 they would then need changing again to use QCalendarSystem via QLocale::calendar(). Method: Checked out all of the KDE SC, plus major gui apps from extragear and calligra, then grepped for the class names. Visual guide: https://www.dropbox.com/s/qkdgo5s68pg6tp6/KDateWidgets.png KDateTimeEdit - My new widget to replace many local widgets, added in last kdelibs release - Can replace KDateComboBox, KTimeComboBox, api is almost the same - Not used anywhere!?! - API uses QDate, QTime, KDateTime, KCalendarSystem, KTimeZone - Suggest: Port to Qt5 - KDE4 era apps can start pre-porting? - Or add to Qt? KDateTimeWidget - Used 8 times - API uses QDateTime - Poor UX - Suggest: kde4support, replace with KDateTimeEdit KDateWidget - Used 6 times - API uses QDate, KCalendarSystem - Poor UX - Suggest: kde4support, replace with KDateTimeEdit KDateComboBox - Used 30 times, 29 in kdepim - API uses QDate, KCalendarSystem, KLocale::DateFormat - Forked by several apps due to lack of features, KDateTimeEdit written to replace - Suggest: kde4support, replace with KDateTimeEdit KTimeComboBox - Used 10 times, all kdepim - API uses QTime, KLocale formats - Forked by several apps due to lack of features, KDateTimeEdit written to replace - Suggest: kde4support, replace with KDateTimeEdit KDatePicker - Used about 20 times, but hard to tell due to forks and wrappers - Forked and/or wrapped by several apps due to lack of features, needs to be reviewed - Uses QDate, KCalendarSystem - Suggest: Port to Qt5 KDateTable - Used directly 2 times, but is part of KDatePicker - Forked and/or wrapped by couple apps due to lack of features, needs to be reviewed - API uses QDate, KCalendarSystem - Suggest: Port to Qt5 - Maybe make private, have flag on KDatePicker to hide chrome? - Make KPopupFrame private? - Make KDateVaidator private? KTimeZoneWidget - Used 4 times - API uses KTimeZone - Unlikely to be included in Qt, so needed in KF5 - API looks a little old fashioned, users need major rewrite anyway for QTimeZone - Suggest: Port to Qt5? Or start anew? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112935: Move KPrintDialog into KPrintUtils
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112935/#review41026 --- Ship it! Ship It! - John Layt On Sept. 25, 2013, 4:50 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112935/ > --- > > (Updated Sept. 25, 2013, 4:50 p.m.) > > > Review request for KDE Frameworks and John Layt. > > > Repository: kdelibs > > > Description > --- > > Moves KPrintDialog out of kde4attic into KPrintUtils. Patch contains some > changes like KComboBox -> QComboBox etc and also removes couple of image > icons, which are no longer needed (was part of a feature merged in qt). > > Will do separate commits. > > > Diffs > - > > staging/kde4attic/src/CMakeLists.txt 74ecc39 > staging/kde4attic/src/kcupsoptionsjobwidget_p.h > staging/kde4attic/src/kcupsoptionspageswidget.ui 0b6231b > staging/kde4attic/src/kcupsoptionspageswidget_p.h > staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 5290405 > staging/kde4attic/src/kcupsoptionssettingswidget_p.h > staging/kde4attic/src/kcupsoptionswidget_p.h > staging/kde4attic/src/kcupsoptionswidget_p.cpp 9393fbf > staging/kde4attic/src/kdeprint_nup1.png 9f13429 > staging/kde4attic/src/kdeprint_nup2.png 7289a7e > staging/kde4attic/src/kdeprint_nup4.png b03a539 > staging/kde4attic/src/kdeprint_nupother.png 5a7c385 > staging/kde4attic/src/kdeprintdialog.h 5d9cd25 > staging/kde4attic/src/kdeprintdialog.cpp 13f89a7 > staging/kprintutils/src/CMakeLists.txt a2e56c9 > staging/kprintutils/src/config-kprintutils.h.cmake PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/112935/diff/ > > > Testing > --- > > Builds > > > Thanks, > > Martin Klapetek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 27 September 2013 16:52, Kevin Ottens wrote: > On Wednesday 25 September 2013 11:28:54 John Layt wrote: >> Started to look at the number of uses, but lxr hardly shows any. Does >> lxr include .ui files, or do I need to grep? > > I don't think it does unfortunately. No, doesn't appear to, I'm busy doing a full checkout of every repo... Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 25 September 2013 17:21, Mark wrote: > >> >> I've been >> talking to the QML component guys and they will have a new calendar >> component for 5.3 that they need QCalendarSystem for as well. > > > > Hi John, > > What you said there sounds very interesting to me! Do you have any link for > me where i can read about that or where current code in that area is being > developed? > > Cheers, > Mark Sure. Just to correct myself, Mitch says its the QtQuick Controls' Calendar, not the actual QCalendarWidget. Not that I know what that means, I really need to take a QML course :-) https://codereview.qt-project.org/#change,45769 http://qt-project.org/doc/qt-5.1/qtqml/qml-qtqml2-date.html (the from* methods are missing.. see next link for those). https://codereview.qt-project.org/#patch,sidebyside,61255,1,src/qml/doc/snippets/qml/date.qml In response I pointed him at my draft QCalendarSystem class. http://qt-project.org/wiki/Qt-5-ICU#955c0120c32f7991db7d55a94df808c2. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112935: Move KPrintDialog into KPrintUtils
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112935/#review40772 --- staging/kde4attic/src/kdeprintdialog.h <http://git.reviewboard.kde.org/r/112935/#comment29986> Pedantic. Can we keep the parms all lined up with first line? Same for all below. Ta! - John Layt On Sept. 25, 2013, 3:21 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112935/ > --- > > (Updated Sept. 25, 2013, 3:21 p.m.) > > > Review request for KDE Frameworks and John Layt. > > > Description > --- > > Moves KPrintDialog out of kde4attic into KPrintUtils. Patch contains some > changes like KComboBox -> QComboBox etc and also removes couple of image > icons, which are no longer needed (was part of a feature merged in qt). > > Will do separate commits. > > > Diffs > - > > staging/kde4attic/src/kcupsoptionsjobwidget_p.h > staging/kde4attic/src/CMakeLists.txt 74ecc39 > staging/kde4attic/src/kcupsoptionspageswidget.ui 0b6231b > staging/kde4attic/src/kcupsoptionspageswidget_p.h > staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 5290405 > staging/kde4attic/src/kcupsoptionssettingswidget_p.h > staging/kde4attic/src/kcupsoptionswidget_p.h > staging/kde4attic/src/kcupsoptionswidget_p.cpp 9393fbf > staging/kde4attic/src/kdeprint_nup1.png 9f13429 > staging/kde4attic/src/kdeprint_nup2.png 7289a7e > staging/kde4attic/src/kdeprint_nup4.png b03a539 > staging/kde4attic/src/kdeprint_nupother.png 5a7c385 > staging/kde4attic/src/kdeprintdialog.h 5d9cd25 > staging/kde4attic/src/kdeprintdialog.cpp 13f89a7 > staging/kprintutils/src/CMakeLists.txt a2e56c9 > staging/kprintutils/src/config-kprintutils.h.cmake PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/112935/diff/ > > > Testing > --- > > Builds > > > Thanks, > > Martin Klapetek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 24 September 2013 19:24, Kevin Ottens wrote: > On Tuesday 24 September 2013 19:03:21 John Layt wrote: >> I'll do some analysis on the use of all the widgets and what ones are >> worth keeping, and look at the Qt widgets to see if they're worth >> switching to, if not before then at Qt Dev Days / Qt Contributors Day. > > OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We > really need to put this issue to a rest, it's been lingering for way too long. > Really looking forward to your analysis! Started to look at the number of uses, but lxr hardly shows any. Does lxr include .ui files, or do I need to grep? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 24 September 2013 12:11, Kevin Ottens wrote: >> OK, let's attempt to move KLocale, KDateTime and friends to kde4support now. >> With some luck we'll be able to completely get rid of KDE4Attic before >> release. > > Hmm, looking at that closer... indeed it looks like we can get rid of > K*TimeZone in favor of QTimeZone. But what would you advise for porting away > from KCalendarSystem and KLocalizedDate? > > Alternatives for those would be needed to move the date/time widgets currently > stuck in KDE4Attic to a more proper framework. Unfortunately QCalendarSystem was part of the QLocale changes that got postponed to 5.3 :-\ In the lower tiers this shouldn't be an issue as QDateTime or QLocale should be sufficient for their requirements. If you know of anything outside widgets that uses KCalendarSystem or KLocalizedDate then I'll have a look. For the widgets themselves, we had two main reasons for them: 1) The Qt ones were rubbish, and 2) The Qt ones didn't support our calendar systems Once Qt gets QCalendarSystem then the Qt widgets will need to support it, so I should have a good case for either fixing the existing Qt widgets or adding new ones that actually work. I've been talking to the QML component guys and they will have a new calendar component for 5.3 that they need QCalendarSystem for as well. As they stand, the KDE4 widgets are fairly tightly tied to KCalendarSystem and KLocale, and if we keep them in KF5 then they would need porting to QCalendarSystem and QLocale anyway, including a change of api for apps. We also want to drop some of our old date widgets that don't work very well. Given this all it may then make sense to move the date widgets to KDE4Support along with the other date classes, as they function as a whole. Then if we cannot get decent widgets into Qt we can create new widgets by porting our old ones to QCalendarSystem with new names. An alternative is to choose the date widgets we want to keep and remove the KCalendarSupport from them for now, and restore it when we get QCalendarSystem. I'll do some analysis on the use of all the widgets and what ones are worth keeping, and look at the Qt widgets to see if they're worth switching to, if not before then at Qt Dev Days / Qt Contributors Day. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112909: Remove KDE print stuff that has been ported to Qt5
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112909/#review40681 --- Ship it! Agree to merge this as is, it removes the stuff that would be duplicated in the Qt dialog. As for longer-term, I don't see any of those features being much used or of much use at all. If I'm wrong and people start complaining and can make a reasonable case, then I'll accept them being added into the Qt dialog. If any feature will be missed, it would be the Advanced option of directly entering CUPS options. I suspect there are some power users out there using that to get around some of Qt's short-comings, like advanced page ranges "3,7-9,15". However the usability is terrible and just shouldn't be done that way. If people make a case for it, then we can look at a better ui for it in Qt, e.g. one that has them choosing from a combo of valid values. That leaves the convenience api for server-side/client-side page selection, which for a one-line code saving is really not worth it. The only other reason I can think of for keeping the api is if we ever want to re-add a univ ersal KDE tab to the dialog, for example for Color Management. I had a cunning plan for that about a year ago, I need to go dig it up and see what actually needs doing and if I can get away with putting it into Qt instead. If we don't need it for that, then I say get rid of it entirely: we don't know what any future needs might be, so we have no guarantee that the current api will work for that, so lets not lock outselves into something until we actually need to. Oh, and I need to look at the rationale behind KPrintPreview to see if we really need it still. - John Layt On Sept. 23, 2013, 6:47 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112909/ > --- > > (Updated Sept. 23, 2013, 6:47 p.m.) > > > Review request for KDE Frameworks and John Layt. > > > Description > --- > > Most of the printing features are now part of Qt 5.2 and basically only 4 > features are left: > - Page Label > - Page Border > - Mirror Pages > - (Advanced) Job Options > - Server-side paging > > I've dropped Job Options as it was quite terrible way to edit/pass CUPS > options directly. Server-side paging is actually just a convenient feature as > with QPrintDialog, apps that can't do paging themselves need 2 lines of code > to set the printing dialog up, thanks to KDEPrintDialog only one line is > needed. The rest I've put under Page Options tab in the print dialog. To be > honest I don't think they are that useful (or used, even) but we have the > code and CUPS support already. If these options were to be dropped however, > I'd drop the whole KDE Print support then as it would become just a > convenient wrapper around QPrintDialog. > > > Diffs > - > > staging/kde4attic/src/CMakeLists.txt 4acf1b6 > staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e > staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d > staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d > staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 > staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 > staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 > staging/kde4attic/src/kdeprintdialog.cpp 4722f4c > > Diff: http://git.reviewboard.kde.org/r/112909/diff/ > > > Testing > --- > > Tested with Konsole5. > > > Thanks, > > Martin Klapetek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Qt Dev Days Stuff
On 19 September 2013 15:34, John Layt wrote: > Qt Dev Days is short on Lightning Talks, so if you have a Qt-related > topic you want to present or demo for up to 10 minutes, please submit > it at http://www.qtdeveloperdays.com/lightning-talks by tomorrow. I've submitted a talk called "KDE and Qt" which I've provisionally put my name down for. I didn't register a separate KF5 talk because I realised there was already an hour long talk scheduled :-) However I will mention KF5 and dirct people to teh talk for more info. > And yes, we still have a couple of tickets available if you want to > come and join in the fun. Ditto... Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
QTimeZone merged for 5.2
Hi, I am extremely relived to announce that QTimeZone finally got merged late late last night, thanks to the efforts of Thiago in fighting the CI system :-) Combined with other changes in QDateTime, this should mean we're free of KDateTime and KTimeZone, albeit with a few caveats. I'll be doing a lightning talk at Qt Dev Days on the topic, so I'll be documenting all the gotcha's people will need to look out for soon. Thanks also to the work from Martin and Rohan, all the necessary CUPS features have been merged into Qt 5.2, and a huge thanks to Alex for taking on QCollator and getting it in. I owe you all a beer or three next time I see you :-) I was less successful on the QLocale front, unfortunately there was too much resistance from Windows devs to using ICU everywhere, so that plan has been shelved and we've moved on to Plan C for 5.3. I'll be working through what that means for us soon, but I don't see any immediate problems for us in still switching to QLocale. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Qt Dev Days Stuff
Hi, Qt Dev Days is short on Lightning Talks, so if you have a Qt-related topic you want to present or demo for up to 10 minutes, please submit it at http://www.qtdeveloperdays.com/lightning-talks by tomorrow. I'd especially like to see a KF5 lightning talk focussed on the libraries we will be releasing and why people would want to use them. Another talk perhaps could be about KDE's contributions to Qt in both code and community, i.e. what new features we've added to Qt5, the benefits of Free Qt, etc. I could do them myself, but I already have one lightning talk planned and it might be better coming from someone more actively involved, so volunteers welcome. I want to make a marketing push for KF5 at QtDD around these two themes as well, with handouts and talking points for our booth staff, so I'll be ransacking the wiki and picking peoples brains about that over the next few days. And yes, we still have a couple of tickets available if you want to come and join in the fun. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Print Dialog - next steps
On 18 September 2013 08:18, David Faure wrote: > On Monday 09 September 2013 14:07:31 Martin Klapetek wrote: >> 5) In KF5 the KdePrintDialog stuff can either be removed entirely, or more >> conservatively modified to no longer insert the extra KDE Cups widgets and >> modifications so they don't appear twice. Discuss with Kevin and David >> which they would prefer. > > What else does KdePrintDialog bring? > > I assume nothing, and your suggestion is merely for source compatibility, > right? > > Martin: please use lxr.kde.org to see how much it's used. If less than 5 > times, kill it. If more than 50, provide it in kde4support. In between, use > your own judgement (more precisely, choose whichever option will lead to less > effort overall, trimming down KdePrintDialog vs porting all usages). All it provided was the extra CUPS features, there's no other benefit to it unless we want to add any other KDE features to the print dialog that we can't convince the print maintainer to include :-) I can't think of anything we would need to add, everything else we want needs new cross-platform api in Qt. It gets used in all KDE applications that want to print, lxr says exactly 50 actual uses, I remember spending a day to port them all for 4.0 :-) They would almost all be a 1 line change, or 2 lines if adding widgets. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
