Re: Some suggested changes to statistical functions in Sheets
Hi Jon! Great work, thank you. I'll look at these and commit to the repo if everything looks good. Looking forward to the next patches, too! If you could send the next patches in the diff format (simply running "git diff > somefile.patch" should do the trick), that'd be great. If not, no biggie. / Tomas 2015-11-04 0:46 GMT+01:00 Jon Cooper : > Greetings all > > My first post on here - I am 'bat' in the forum and KDE bug-tracking > thing. As promised, I have tested all of the Calligra Sheets statistical > functions and most of them seem to work well. I found that some of the > t-tests were not calculated quite right so I revised the statistical.cpp > and .xml in the calligra/sheets/functions folder. This bit of stats is > something that I know in some detail since I teach it to first year uni > students (well, 'taught' might be more correct since I am officially > retired now). I also revised some of the text in the statistics.xml and > the math.xml files to try to improve descriptions of the other > functions. I have detailed the changes that I made in the attached pdf > file. I hope some of this helps and I look forward to doing more of this > sort of thing in future since I have a bit more time now and I should do > something useful with it!! > -- > Jon Cooper > jbcoo...@fastmail.net > > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Some suggested changes to statistical functions in Sheets
Added, thanks! 2015-12-03 0:16 GMT+01:00 Jon Cooper : > Dear all > > I have been checking the description of the Trend function which is in > statistical.xml. To make it clear to the user how to use this function, may > I suggest the following changes to statistical.xml > > Replace the line: > > The TREND() function calculates a sequence of values based on a > linear regression of known value pairs. > > > with: > > The TREND() function calculates a sequence of Y-values based on a > linear regression of known X- and Y-value pairs. For the input parameters, > the user must firstly select a cell-range containing the Y-values, followed > by the cell-range of the corresponding X-values. The line of > best fit may be extrapolated to a different X-range, which is specified as > the 3rd parameter. However, the input X-range should be given again if no > extrapolation is required. The regression line can be forced > to intersect the origin (X=0, Y=0) by setting the 4th parameter, > allowOffset, to FALSE or 0. Setting this parameter to TRUE or 1 (the > default) allows the best-fit line to intersect the vertical axis at a > non-zero value of Y. Note that since the result of this > function is a row of calculated Y-values, plotting the data will be > facilitated if the X- and Y- values are also in rows, rather than > columns. > > > And (because I find this very confusing) may I suggest replacing the line: > > TREND(knownY[;knownX[;newX[;allowOffset = TRUE]]]) > > > > with: > > TREND(known Y-range; known X-range; new X-range; > allowOffset=TRUE/FALSE) > > > If you make those changes, it looks like the attached screenshot and I > think it will help the user to avoid crashing the program!! > > -- > Jon Cooper > jbcoo...@fastmail.net > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?
Hey Friedrich and others! I've hit the very same issue in Sheets earlier that you did, and ended up postponing that part of the porting (though I do have a local branch with partial results). Not really sure what the best solution would be - the problem with KLocale is that it seems to be out of sync with QLocale, so for me at least they both report different locales/languages. Weird, that. Anyway. I've looked at QLocale's code, and adding precision to the formatting routines would be trivial technically - the routine called by formatMoney supports it, so it's just a matter of adding an optional argument to formatMoney - should even be BIC, as I understand it. Not sure how easy/hard it'd be to get the change into Qt. The main problem with QLocale seems to be that it essentially is a black box - it has all the locale info we need, but we can't pull it out of it. So if functions to return the format string, precisions, etc for the current locale could be added, so that wrapper classes can be built, that'd probably be all we really need. / Tomas 2016-01-06 8:12 GMT+01:00 Friedrich W. H. Kossebau : > Hi developers of finance apps & Calligra Sheets & Calligra Plan, > > (please keep cross-posting to both ml for now) > > I (not only with my Calligra developer hat on) would like to collect > experiences and ideas for conversion of curreny values to and from > strings when using Qt5/KF5, especially when porting from kdelibs4's > KLocale. > > > PROBLEM > > QLocale is rather limited (as of Qt 5.5): > - no currency string parsing method > - string formatting method toCurrencyString() does not allow > to control precision > > KLocale and its currency related methods seem the last blocker to get > rid of kdelibs4support in Calligra in the Qt5/KF5 port. Plan uses them > for handling the costs of resources, and Sheets for the currency > formatted cells. And both limitations are a blocker. > > > APPROACHES > > Long term ideally QLocale gets support in its API for that. So we > developers of currency data handling software should organize and > draft an API. > > First and short term though, until some released & wide-spread Qt > version has the improved QLocale, I am looking for a solution > independent of QLocale. > Most obvious might be to duplicate all currency things from KLocale, > which would also include duplicating the database with all currency > formatting data. This is what I would plan to do if there is no better > idea. > Especially the database duplication is painful though, I would like to > avoid at least that if possible. > > > QUESTIONS > > How have developers of e.g. Skrooge & KMyMoney approached the issue of > conversion of currency values to/from strings? > > Do you know about any activities to improve QLocale here? > > Seems that Calligra apps Plan & Sheets are the only KDE apps using > KLocale::readMoney() ? > https://lxr.kde.org/ident?v=stable-qt4&_i=readMoney&_remember=1 > > But KLocale::formatMoney() might be used by KMyMoney, Skrooge, Kraft & > others (did not check though if not custom code): > https://lxr.kde.org/ident?v=stable-qt4&_i=formatMoney&_remember=1 > > Cheers > Friedrich > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?
2016-01-06 19:46 GMT+01:00 Friedrich W. H. Kossebau : > For BIC though this might need some overloads of the method, changing the > signature of existing methods, even if only appending an argument to the > list > of arguments, does not work, or? > Given there are already 8 overloads for the different numeric types, well, > that needs possibly more thinking still. > > Yeah, this would require overloads to stay BIC, adding an argument with a default value breaks it per techbase. Not perfect, but if we can't have anything better, and it Qt accepts it, it seems workable. Or failing that, adding functions that export the locale data (format string etc), so we can do our own formatMoney clone. Would just be simple getters, don't even need setters really. > Yes, QLocale being readonly is a third issue in the list of blockers. And > not > only for the currency related methods. So our issues are: > - no currency string parsing method > - string formatting method toCurrencyString() does not allow > to control precision > - no option to extend/overwrite/customize locale data > Well, write-only is my issue, really. We can ask it to format things for us, but we can't pull the locale data out of it. If we could, we could simply be using QLocale and write our own formatting routine on top of it. / Tomas ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: [Sheets] Python Console Docker
Python scripting support would be nice as a separate plugin if someone is interested in maintaining it, but yeah, with these security concerns I'd rather drop it from the main codebase in favour of something more sandboxable. Tomas 2016-01-22 9:26 GMT+01:00 Jaroslaw Staniek : > > > On 22 January 2016 at 04:50, David Narvaez > wrote: >> >> On Thu, Jan 21, 2016 at 3:59 AM, Jaroslaw Staniek wrote: >> > Short answer, not many commits for that, even dedicated maintainer >> > probably >> > welcome, no special interest resulting in real coding, and especially, >> > organized design. >> > >> > Longer answer require showing more context. >> > >> > I can first mention atmosphere around Python and scripting in general >> > closer >> > to the Kexi circles. >> > >> > But I believe since the intent is to have consistent scripting in the >> > future, it somehow helps to see some relation to Sheets, being in the >> > same >> > class of apps. >> > >> > As some people may know I like Python for its purposes. KDE even started >> > (in >> > Calligra) projects such as Kross to support more languages honestly. >> > This >> > support was were means for not too deep bindings, not language-specific, >> > rather calling methods of objects without much regard to integration >> > with >> > data types or language specifics. >> > >> > As a part of general 'cleanup' Kexi 3 removes Kross usage and moves >> > towards >> > a single language-solution that happens to be JavaScript, using QtQml. >> > The >> > main reason is that sandbox works there and not in Python.[1] By default >> > QtQml gives no tiny chance to access filesystem for example or run >> > unwanted >> > scripts. >> > >> > There are no declared lovers of JavaScript among us, C++ hackers I >> > think. >> > But the specifics of JavaScript is less of a problem than inherent >> > insecurity of Python's execution environment. Insecurity would manifest >> > once >> > apps that use scripts get popular. The result I'd expect is very much >> > like >> > perfect cross-platforms viruses. >> > This is possible if scripts are accessible with documents, which is >> > assumption of Kexi (files are meant to be user-defined apps) and in the >> > future, I believe, also Sheet's documents, if we want competitiveness. >> > >> > For that matter, also ruby and bash and perl, would be all better >> > rejected >> > for the same reason. >> > Sure, there were ideas of digital signing of scripts but 1. Even tech >> > people >> > do not use that (and even for emails) in general, 2. Except for Krita >> > "official" builds we're not controlling the deployment process, distros >> > do >> > that, and I imagine all sort of critical issues can sooner happen e.g. >> > because of mixes responsibility. It seems that distros are able to act >> > more >> > "reactionary", not as "owners" of the software as a product. Which does >> > not >> > surprise me and there's nothing to criticize. >> > >> > For Kexi <=2 (no matter what language is picked) scripting is marked as >> > having experimental status. I am not sure whether this is the case for >> > Sheets too but for Kexi there's because of such honest status we can >> > assume >> > there's no disservice to users. With Kexi 3 we have ability to start >> > fresh >> > and with knowledge/experience gathered in the past. Also about knowledge >> > about the user base. >> > >> > For some other contexts the choice scripting can depend on external >> > requirements. Like "industry" standards -- for Krita Python is perceived >> > as >> > some kind of standard for extending graphical features. Similar opinion >> > applies for Krita itself - generic calligra-wide scripting never have >> > been >> > too actively maintained and was Kross is too simple, see [2]. For the >> > record, Krita has a proof-of-concept implementation of scripting in a >> > separate repo. >> > >> > [1] Google for "Python sandbox" for detailed discussion from Python >> > hackers >> > on why this is not possible and dropped idea. >> > [2] https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html >> >> Ditching Python because of sandboxing issues makes sense. That being >> said, I would use Python to access the file system from my >> spreadsheets all the time. I don't really remember what made me to >> look into scripting support in Sheets but I vaguely remember something >> merging several CSVs into a single spreadsheet. > > > Yes, data integration is one of the most useful use cases. > >> >> In any case, if the current plan is to remove Python support, I guess >> I am better off working on removing that instead of fixing it, >> correct? > > > I give no definitive > > answer here stating that common organized approach in Calligra is a valuable > thing. Especially that resources are always limited and better to have one > effort than multiple. Sheets maintainer decides for Sheets and it can be > assumed that who codes largely decides too. > > Assuming that removal of unused/unmaintained code will b
Re: Coverity scan results
Yeah, getting the same problem here (using the github-integration login, maybe that's the issue). 2016-02-20 18:16 GMT+01:00 Pierre : > On Friday, February 19, 2016 02:05:04 AM Nick Shaforostoff wrote: >> > https://scan.coverity.com/projects/kde/view_defects and I then get the >> > message «Failed to view defects: It may take a few minutes before you can >> > view your defects for the first time or when you change your email.» >> >> which browser do you use? >> i use chromium and it works fine. >> if the problem persists - i suggest writing to Coverity support. > > I contacted them, it doesn't work with either firefox, chromium or konqueror, > on different IP addresses… > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Static code analysis - the easiest way to improve
Well, I'd like to, but when I log in and try to access the KDE stuff, I can see the summary, but accessing the actual defect list gives me a red box with this: It may take a few minutes before you can view your defects, when you change your email or password or sign-in with Github for the first time. Been that way for more than a week now - tried both github and password login. Someone else was reporting the same problem, I think. Any ideas? Tomas 2016-02-28 15:59 GMT+01:00 Jaroslaw Staniek : > Hi, > Just to remind. If someone has some time to fix bugs, KDE > apps/Calligra/Frameworks static analysis is the easiest way to improve > Calligra. > Code defects are well explained (like uninitialized variables or > NULL-related failures). Much easier than actually reading that bug reports, > analysing them and testing. > > So please, these are low-hanging fruits. Hundreds of them. > > Visit: > https://scan.coverity.com/projects/kde > You can request access if you don't have it yet. > > Let us know in this thread if code you're interested in isn't there. > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek > > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Static code analysis - the easiest way to improve
No change for me, unfortunately, still getting that red box (tried both password and github login). Tomas 2016-03-15 17:28 GMT+01:00 Jaroslaw Staniek : > > > On 28 February 2016 at 16:26, Tomas Mecir wrote: >> >> Well, I'd like to, but when I log in and try to access the KDE stuff, >> I can see the summary, but accessing the actual defect list gives me a >> red box with this: >> >> It may take a few minutes before you can view your defects, when you >> change your email or password or sign-in with Github for the first >> time. > > > > Hi, > Just tried it for some projects again and the red box is apparently gone. > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: state of release and release plan
No big blockers on Sheets. There's a lot of "would be nice"s and "this should work better"s, but all apps have that, I imagine. 2016-07-02 8:17 GMT+02:00 Camilla Boemann : > Hi > > I think it's time we get a release out. We are stuck with not much work going > on so inspired by Dag's return let's do a push to get ready. > > I think we should cut down on the number of applications so we have something > manageble left. It's tough but the alternative is that Calligra dies > completely. And nothing prevents us from bringing apps back later. > > So my question is: What is missing for us to have a release. I am not talking > about all the nice to have features and bug fixes. I am asking what would > create huge problems for our users if we release. > > Let's get things listed. I'll start: > > > Words: Nothing blocking > > Stage: Nothing I'm aware of > > Sheets: ??? > > Plan: the locale thing? how much would a quick fix take or should we just > exclude Plan from first release? > > Karbon: let's exclude from first release > > Flow: let's exclude from first release > > Kexi: are they even a part of the release schedule anymore > > Braindump: let's drop it completely > > > Common stuff: ??? > > please fill in > > and let's get ready for a release in a month or so ? We need to set a short > deadline to keep motivation high > > best regards > Camilla > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Plan status
Apologies about a delayed reply, just got back from a vacation myself. For Sheets, the money formatting routines are the issue where we still need to rely on kde4support - https://mail.kde.org/pipermail/calligra-devel/2016-January/015746.html has some info. 2016-07-15 14:10 GMT+02:00 Dag : > Vacation is going to hit soon, and plan is not ready... > It has been a frustrating week with too much time used on non-productive > things, but progress *has* been made and I am fairly confident I will be > able to have something mid august. > > Regarding currency, does somebody know what is needed for sheets? > Plan doesn't need a lot, but I was thinking about lifting at least some of > the code from kde4, if it isn't too much hassle. > > Well, I'm off a couple of weeks, have a nice summer everybody! > > See you, > Dag > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Plan status
2016-08-02 13:14 GMT+02:00 Dag : >> For Sheets, the money formatting routines are the issue where we still >> need to rely on kde4support - >> https://mail.kde.org/pipermail/calligra-devel/2016-January/015746.html >> has some info. > Does it mean release with kde4support and wait for QLocale, > or do you have other plans? kde4support for now, most likely, if nobody has a better idea / solution. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: state of release and release plan
2016-10-26 14:03 GMT+02:00 Dag : > I would support plan of course, but what about words and sheets? > Camila and Tomas; what are you able to commit to, are there others? Varies. Bit more busy the last few months, will be better soonish. But still interested, ya. Sheets is in a decent shape, some things to sort out still, but nothing huge. Obviously there always are a lot of things that could be added/improved. Tomas
Re: Calligra Sheets feedback mode?
Have you tried compiling sheets with debug info and enabling sheets debugs in kdebugdialog5? That might give some idea what's wrong. Tomas 2018-03-23 19:22 GMT+01:00 iIjier Iuiresd : > Hi, > I'm finishing up a new Qt5 .ods reading/writing library that will deprecate > my current one: > https://github.com/f35f22fan/QOds > and unlike LibreOffice, Calligra Sheets (v3.0.1) often doesn't display the > .ods data as expected or at all and doesn't report there's an issue with it. > > I was wondering if there's some way to query Calligra what exactly it > doesn't like about an .ods document? > > I would need this info to make it worth it for me to create .ods files that > Calligra can read properly. > >
Re: Usability Testing for Calligra as part of study project
Hi there! An usability study sounds interesting, could you elaborate a bit on what exactly you'd like to do here, and what you would require from us? And what kind of time frame are you looking at? Also, we have a lot of improvements in the development version that are not yet included in any releases, is it feasible for you to compile from sources and use that instead of the released version? The released versions should work fine too, but may focus on already resolved issues. Tomas pá 7. 4. 2023 v 17:21 odesílatel Quan Nguyen napsal: > > Hello, > > We find that some of the contributions you suggested might not align with our > scope of study. The reason we pick this our interesting in Calligra and have > practical experience in conducting usability testing with real customers and > open community with guidance and support from the course lecturer as well. > > > Our scope is to evaluate the usability of Calligra office tool suite and > conduct some pilot testing, test session with real participants to evaluate > the existing usability of the tools. We are focusing on Words, Sheets, Plan > and Stage tool . The result will provide some feedbacks on existing usability > of the tools as part of the course study and might help the Calligra improve > in future development. Let us know if the study benefit for your community > and align with your goal. > > > Thank you and best regards, > > > > Quan Nguyen > > > From: Benson Muite > Sent: Wednesday, April 5, 2023 9:38 AM > To: Calligra Suite developers and users mailing list; Dag; Quan Nguyen > Cc: Branko Glibota; Arya Yaghoubi; Fatemeh Mirzaei > Subject: Re: Usability Testing for Calligra as part of study project > > > > On 4/5/23 09:26, Dag wrote: > > On Tuesday, 4 April 2023 14:29:47 CEST, Quan Nguyen wrote: > >> Hello, > >> > >> We are a team of information processing science students currently > >> taking a course on user experience and usability evaluation that lead > >> by Mikko Rajanen. Our aim is to conduct a usability test on the > >> Calligra office suite, and we would greatly appreciate your input on > >> the desired functionality and any previous tests conducted on it. We > >> value your time and thank you in advance for your assistance. > > Hi, all. > > Afaik there hasn't been any previous studies, but I might be wrong. > > We are very few active developers atm so the amount of support may be > > limited. > > @thomas Is it something you would be interrested in? > > > > It would be interresting to hear your reasons for selecting calligra for > > this study. > > > There is related work on energy efficiency of word processing > software[1][2]. KDE also has increasing accessibility as one of its > goals[3]. > > 1) https://community.kde.org/Goals/Sustainable_Software > 2) > https://produktinfo.blauer-engel.de/uploads/criteriafile/en/DE-UZ%20215-202001-en-Criteria-V2.pdf > 3) https://community.kde.org/Goals/KDE_For_All > >
Re: 2.4 Release Plan
As a disclaimer, I'm not active in Calligra development currently, so my opinion may not be entirely relevant, but hopefully it will be useful anyway. Wouldn't it be better to (at least for the initial release) use a different development scheme with an alpha/beta version being released every month or so, with no feature freeze in place? It could be more work to manage it, but by maintaining a relatively constant stream of pre-releases that each contains actual improvements (not only bug fixes), you'd keep the general awareness of the project, while at the same time having enough time to polish the applications to be end-user ready for the first final version (2.4 or 3.0 or however you're going to call it). / Tomas 2011/1/13 Inge Wallin : > On Thursday, January 13, 2011 10:57:10 Cyrille Berger Skott wrote: >> On Thursday 13 January 2011, Inge Wallin wrote: >> > Now, if we instead prolong the initial release phase to, say, 7 months >> > and by doing that make sure that the release is in fact good enough >> > then the user gets a usable Calligra in 7 months. >> >> Really, you think one extra month will be enough ? If that is the case, >> then I agree. But I am very skeptical. But ok since we are aiming at a >> release around May - June. I suggest people to fill the feature plan [1], >> with the mention "URRF - 3 weeks" (User Readiness Required Feature) if you >> think that is a feature that needs to be finished for the application to >> be user ready, and that you would need 3 weeks to complete it, and by 3 >> weeks I mean real time, meaning that if it is a feature that require 30h >> of work, and you can work 10h per week-end on calligra, it translates to 3 >> weeks. > > I have no idea what will be required. As I wrote, I think we should go the > other way around and ask the maintainers. And when you write "we aim at a > release around May - June", I have to question it. "We" in this case is you. > > Of course, I don't question that a quick release is better than a slow one. > But I think it has to be given a lower priority than getting a usable suite. > So that should be our starting point rather than the calendar time. > > Some may read this that I want a perfect suite at the release. That's not the > case, I know very well that perfect is the enemy of good. So if we can find > the lowest common denominator that would make each application good enough, > then I'm all for it. Note though, that I think usability issues are just as > important as missing actual features here. > > Your approach sketched out above seems a good one. Can we enhance it with > using the same keyword for bugs in bugs.kde.org? > >> So fill [1] as soon as possible, I would set the deadline for February, 2nd >> (which would be equivalent to a soft-freeze, meaning that afterwards >> development, in master, should be focused on the content of the features >> plan). >> >> And then we can see if we need 3, 4, or 8 month of features development. > > Yep. > >> [1] http://community.kde.org/Calligra/Schedules/2.4/Feature_Plan > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra Maintainers - status updated - more applications about to be freezed
Hey, I can take Sheets maintainership again if the existing maintainer no longer wants it. Don't have time for anything big, sadly, but I should be able to keep it shippable, at the very least. Tomas 2014-12-15 13:04 GMT+01:00 Jaroslaw Staniek : > > Hi, > While 2.9 Beta is out (congrats!), I am sending this to confirm we're > looking for new contributors and more contributions for our nice apps. > > A term of "freeze" has been coined and now more or less applies to > various apps: https://community.kde.org/Calligra/Maintainers. > > More strictly: "Proposed for freeze in 3.0 if no contributors join" > > * Carbon and Plan is known to be in this situation already. > * Calligra Author and Braindump were the new kids labeled as > experimental and are now in this group too. > * It's sad to admit Calligra Sheets and Stage also received close to > no contributions in recent releases so also are candidates to > freezing. > This is serious thing as we're talking about core office applications. > > We at Calligra are about to spend so much energy on porting most > active apps to Qt 5 and KF 5 so new blood for the above apps is > clearly needed. You have still time to join now and we're here to help > you. Once the applications are frozen, it will become increasingly > more difficult. > > Please don't hesitate to ask in this thread or privately > (https://community.kde.org/Calligra/Contact), some apps are smaller, > some are bigger. Maintaining does not mean you have to add dozens of > new features. Applications just need to be in a shippable state for > every release. A few hours a week was sufficient for many Calligra > maintainers. > > This is a nice opportunity to join FOSS for real. > > PS: This post appeared as we want to be crystal clear when questions > such as this pop up: > https://www.calligra.org/news/calligra-2-9-beta-released/#comment-1218144 > Don't be afraid, we're largely immune to sudden and ultimate > cancellation of releases of these apps. This is FOSS. > But this also means there are no "they" -- if you read this, you're > part of the project :) > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra Maintainers - status updated - more applications about to be freezed
Only tangentially related to this topic, but as it was mentioned here -- where can I find some information about the current status of the Qt5 port? I have found some discussions from 2013 and two branches in the repo, but the last commit on those is more than a year ago, so not sure if those are abandoned. / Tomas 2014-12-15 21:47 GMT+01:00 Jaroslaw Staniek : > > Thanks so much Tomas, Friedrich, Dan, Thorsten. And everyone please > continue... > > The wiki page will be kept updated accordingly. > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: I'm back
Welcome back! / Tomas 2015-01-13 12:41 GMT+01:00 Inge Wallin : > Hi everybody, > > Some of you know already that I have been very sick but perhaps not > everybody. > However, I am much better now and recovery has gone so far that I feel > that I > can come back into the KDE and Calligra families again and be active. The > most > lasting difference between now and before is that I am ~20 kg lighter. :) > > I have actually not been totally cut off, I have followed a bit on the web > and > on mailing lists, but I have a pretty big backlog. I have started to cut > that > down but it will take some time before I'm fully done with it. > > In the mean time I have been able to do some trivial hacking and actually > have > a couple of branches on my hard drive. The question is whether it's too > late > to merge them now before the big port to Qt5 and KF5. > > So consider me back with a vengeance and I am starting to feel really well > again. And I have missed KDE and Calligra a lot! > > -Inge > > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra 2.9 Beta 2 Changelog
For Sheets: * some work to speed up drawing of complex documents * updated currency info to Euro for Lithuania * fixed a crash in the table shape when the external editor is not available * fixed up mouse interaction with the table shape * fixed a problem with non-native files not being openable * fixed sorting to properly update formulas instead of discarding them * fixed find/replace to not skip the last row * fixed a deadlock with COUPNUM 2015-01-14 21:44 GMT+01:00 Cyrille Berger : > Hi, > > We would need to have the changelog information for 2.9 beta 2. The tag is > set > on: > > > http://quickgit.kde.org/?p=calligra.git&a=commit&h=7fa3f5f9a63c4c6e813f6d5610d35fbefb1dd205 > > > -- > Cyrille Berger Skott > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra Maintainers - status updated - more applications about to be freezed
Sure. 2015-01-15 9:01 GMT+01:00 Jaroslaw Staniek : > On 15 December 2014 at 13:41, Tomas Mecir wrote: > > Hey, > > > > I can take Sheets maintainership again if the existing maintainer no > longer > > wants it. Don't have time for anything big, sadly, but I should be able > to > > keep it shippable, at the very least. > > Hi Tomas > Thanks, and late question: can I assume this can be updated for Sheets now? > https://community.kde.org/Calligra/Maintainers#Applications > > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Flake event handling changes - draft proposal
As discussed on irc earlier today, here's my initial proposal to improve event handling in flake tools. Very much a work in progress. Problem: The current method of handling flake tools feels very rigid and inflexible, which gives a rather poor impression from the usability standpoint. I've been going over the related code during my yesterday's attempts to improve the related functionality somewhat in Sheets, only to come to a realisation that doing so will require a series of improvements in flake itself. This document contains the initial draft of my proposal to do exactly that. It is obviously meant to be introduced after the 3.0 release, as a change as significant as this cannot be merged this close to the 2.9 release. Usability is the main motivation here, no actual new functionality will be added (initially, at least, as I believe the changes will allow new functionality to emerge). As I note, currently the shape tools are fairly isolated from each other, and the result feels very clumsy. For example if the user is editing a text document and wants to resize a picture, he needs to find the shape manipulation tool in the panel, resize, then reselect the former text manipulation tool. With the proposed changes, he will be able to simply move the mouse over the picture (and maybe click on it, though I am a fan of the hover effect here), resize it, then get back to text editing right away. Many more similar use cases can be devised. >From the technical standpoint, the main change is that events shall be processed by all applicable tools, rather than only the active tool. The tool manager will serve as the arbiter, deciding which tool actually receives the event based on information that the tools provide. The concept of the active tool remains, but becomes much less significant, as users will be able to use functionality offered by these tools even if they are not currently active (this mostly applies to the shape manipulation too, which I would ideally like to make entirely transparent, if possible). Technical list of changes - some of these may need alterations: - We construct a priority list of tools belonging to each shape - some tools are generic, most are specific to a single shape (this mostly already exists, though some priorities will change) - Event processing gets split into two stages - Stage 1 - preprocessing: * here we query all the tool/shape combinations that are at the affected (clicked, whatever) position, topmost shape first; for keypress events, we query the active tool (TODO - maybe more than that?) * each tool determines whether it wants to process the event, and its priority in doing so * the tool will mainly decide this based on whether it is active, most tools will just be idle while inactive - Stage 2 - actual event processing: * the tool with the highest priority receives the actual event * if the tool returns that it did not process the event after all, the next tool receives it, etc (this may not even be necessary, but it may simplify the tool logic) * upon processing the event, the tool can return one of these return codes: "not processed", "processed", "processed and make this tool the active one" * these return code options are one of the most important parts of this proposal - they will allow us to switch between tools much more fluidly than currently, and it will also allow some tools to process events without actually becoming active; for example, we could allow the manipulation tool to process shape resizing attempts, while still keeping the editing tool active - Additionally, there will be a stack of "default" tools, which will be processed if the user clicks in the area where no shape is located (this is mainly for Sheets, as its main canvas is not a shape, but other apps may benefit too) - Furthermore, some events will be partially processed by the tool manager itself - this will mainly affect mouse dragging; each tool currently processes this itself, which will no longer be feasible under the new rules. As such, the mouse movement event will also include the initial point of the drag action - this will allow us, for example, to have click events routed to one tool, while allowing 'click and drag' functionality to be processed by another (e.g. situations where clicking would be processed by the editing tool, while dragging would cause the shape to be moved). - To be determined: need to decide if we want to keep the "currently active shape" concept at the tool level (ie, each tool has its own), or move it to the shape/tool manager level; I'm thinking the latter. Overall I'd like to de-emphasise the "currently active shape" concept as much as possible, letting users e.g. fluidly work on multiple shapes at once, but this may not be feasible, mostly because of keyboard shortcuts. This is just the initial draft, so please point out anything obvious that I may be missing. I also volunteer to get all this done and working :) Thoughts? / Tomas ___
Re: Flake event handling changes - draft proposal
Hi Inge, thanks for the feedback! 2015-02-03 2:18 GMT+01:00 Inge Wallin : > The problem, as you say, right now is that the user can edit shapes but > then > has no easy way to get back to the default operation. The only way is to > go to > the toolbox and select the right tool, i.e. visual tab in the toolbox for > the > operation. This is very unituitive and we have actual bug reports that say > "I > can't get back to edit cells in Sheets after inserting a chart". > Yeah, this all is accounted for in the design, though it seems I haven't worded it well enough. 1. Single click in a shape selects that shape and activates the default > shape > tool where you can move, resize, scale and rotate the shape. > 2. Double click in a shape selects that shape and activates the shape > specific > tool. Examples would be the chart tool for chart shapes and path editing > for > path shapes. > I'm thinking that the single click would bring you right into mode 2, with mode 1 as an overlay, but that is very specific and can easily be adjusted once the basics are in. > 3. Click anywhere outside any shape when the default shape is active > unselects all shapes and returns to normal editor mode, which is specific > for > each application. > That's indeed the plan. > 4. key deactivates the shape specific tool if one is active and > activates the default shape tool. (Some special tools may have internal > states > that use ending some user interaction. If so, then the user may > have > to press twice.) > Don't have this one included, but it'd be easy to add. > The good thing about this solution, as far as I can see, is that it would > mean > very small changes to flake and none to any shape. So this should be > possible > to get in before 2.9. We shouldn't be doing this now, but the current user > interaction problems are so horrible that I think we should make an > exception. > And this is especially since 3.0 will probably be quite unstable and buggy > and > should be regarded more like a tech preview than a real release. > > > There is one thing we would lose with this solution, though: rubber band > selection of shapes. If any click outside a shape leads automatically to > deselecting all shapes and reverting to the default tool for each > application > then we can't use drag operations to select shapes. > Is this a concern? I'm not really seeing this use case being very frequent, but it can easily be done too. / Tomas ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.9 final release date
Sounds good to me. 2015-02-03 10:28 GMT+01:00 Dmitry Kazakov : > +1 as well > > On Tue, Feb 3, 2015 at 11:59 AM, Jaroslaw Staniek wrote: > >> On 3 February 2015 at 09:56, Boudewijn Rempt wrote: >> > Hi, >> > >> > While there are still about 150 open bugs for Krita, my feeling is that >> > we're getting ready for a 2.9.0. There has been some nice work on Kexi, >> > Words and Sheets as well. >> > >> > We have one last beta planned for February 12th (tagging 8th), so I >> would >> > like to propose to have release 2.9.0 pretty soon afterwards: >> > >> > tagging: February 22nd >> > release: February 26th >> > >> > After that, I propose a new 2.9 release every month. >> >> +1 here >> >> -- >> regards, Jaroslaw Staniek >> >> KDE: >> : A world-wide network of software engineers, artists, writers, >> translators >> : and facilitators committed to Free Software development - >> http://kde.org >> Calligra Suite: >> : A graphic art and office suite - http://calligra.org >> Kexi: >> : A visual database apps builder - http://calligra.org/kexi >> Qt Certified Specialist: >> : http://www.linkedin.com/in/jstaniek >> ___ >> calligra-devel mailing list >> calligra-devel@kde.org >> https://mail.kde.org/mailman/listinfo/calligra-devel >> > > > > -- > Dmitry Kazakov > > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra 2.9 Beta 3 Changelog
Sheets: * Usability: when double-clicking outside of any shape, switch to the cell tool. * Fix drag and drop of cell values/selections * When selecting a range, display its dimensions in the status bar * When saving cell values, take formatting into account when determining value type. Fixes some load/save issues 2015-02-11 11:22 GMT+01:00 Boudewijn Rempt : > For Krita: > > * New splash screen by Tyson Tan! > * Fix noisy complaints from libpng about nothing > * Hide the next/previous blending mode, snap-to-grid and reload-file > actions because they don't work > * Fix the shortcuts for setting brush opacity > * Fix inverted softness (bug 342747) > * Fix ghost pixels on group layers with no children (bug 331554) > * Fix opacity setting for pattern fill layers > * G'Mic: Add progress reporting for small previews > * G'Mic: Cancel now stops execution of slow filters > * G'Mic: Don't crash when closing the G'Mic dialog after doing nothing > * G'Mic; fix url for updates > * Fix issues with Genius Tablets (bug 342641) > * Fix painting on selection masks > * Make the palettes docker follow the general background color setting > * Add a temporary dialog to fix issues when the desktop resolution and the > wintab resolution don't match up > * Fix crash when using the color transfer filter (bug 342287) > * Fix KToolLine to handle end and cancel requests (bug 336959) > * Fix a bunch of menu options to only be active at the right moment > * Add unit of measurement to offset image dialog > * Fix initialization of the crop tool (bug 342842) > * Improve default values for the crop tool (bug 242844) > * Fix crash in shaped gradient with shaped smaller than 3px wide > (bug 342942) > * Show open/save buttons in the ruler assistant tool on Windows (bug > 342348) > * Add auto-leveling to the adjust/levels filter (Aleksander Demko's first > patch!) > * Don't push the Copy action on the undo stack (bug 343328) > * Remember the constrain proportions settings in the canvas size dialog > (bug 343282) > * Fix spacing of rotating brushes (bug 329026) > * Fix crash when selecting the texture option for the pixel brush engine > (bug 342749) > * Make the "on hover" layer thumbnail configurable (bug 342168) > * Fix an issue where you'd have to press cancel multiple times to close > Krita (bug 343070) > * Notify the user when copying an empty selection (bug 343092) > * Expand the color picker tool to be able to use a radius up to 900 pixels > (bug 337406) > * Don't crash if Krita's settings has an active preset that no longer > exists (bug 340229) > * Don't crash when closing Krita while the reference image docker is still > loading thumbnails (bug 342896) > * Switch to an appropriate tool when switching between pixel and vector > layers (bug 335092) > * Support indirect painting mode for masks (bug 318882) > * Don't crash when merging selected layers (bug 343540) > * Bring back the undo docker's preview thumbnails (bug 277884) > * Don't crash when undoing points in polyline stroke or selection (bug > 342921) > * Make shift-z undo points in all poly tools (bug 342921) > * Make the shortcut for undoing poly tool points configurable (bug 342919) > * Disable the arrow keys for panning the canvas by default (bug 342023) > * Update the minimum zoom level after scaling the image (bug 342709) > * Rearrange the settings menu to be more logical (bug 342068) > * Only lock the tools if the layer is invisible, but allow moving and > deleting of invisible layers (bug 337912) > * Fix issues when working with the color selectors in HDR mode (bug 343531) > * Don't save the crop tool's force ratio setting (bug 343287) > * Fix cyclic updates of the currently selected color (bug 343531) > * G'Mic: Don't crash when enabling the small preview in interactive > colorize (bug 343616) > * Fix a crash on loading an image (bug 340752) > * G'Mic: increase the stack size to ridiculous proportions on Windows so > the parser doesn't crash > * G'Mic: start supporting interactive colorize on Windows (still not done, > needs adding support for pthreads) > * Follow the settings for visibillity of the scrollbars (bug 342217) > * Fix shaped gradients for selections with holes (bug 343187) > * Fix floodfill for 16 bits integer/channel RGB images (bug 343365) > * Fix the zoom level of the scratchpad > * Fix a big slowdown in the layer properties dialog with big layers and > big images (bug 343685) > * Fix file layer position resetting > * Add the recent documents to the list in the new images dialog (bug > 340949) > * Fix support for Wacom Airbrush devices. Patch by Arturg. (bug 343545) > * Make the text brush load and display values from the current brush > * Fix the text brush when rotation is set to drawing angle (bug 330185) > * Fix recognizing the bamboo stylus (bug 343545) > * Don't deadlock when loading a fill layer (bug 343734) > * Don't assert when checking the texture option (bug 343837) > * Make it possible again to select an image in the color transfer filter >
Re: Qt Script possibly not the best tech for Kexi scripting
I've no idea what state it is in, but, what about KJS/KJSEmbed? http://api.kde.org/frameworks-api/frameworks5-apidocs/kjs/html/index.html http://api.kde.org/frameworks-api/frameworks5-apidocs/kjsembed/html/index.html 2015-02-16 10:19 GMT+01:00 Jaroslaw Staniek : > Hi, > As you know a semi-official conclusion is that we can afford > development of scripting for at most one scripting language, and for > some reasons like popularity and security it's JavaScript. [0] > > I am forwarding the thread from the developm...@qt-project.org list. [1] > > (CC'd to calligra-devel since potentially, scripting is something > useful for other Calligra apps in some distant future) > > It says that Qt Script is going to be deprecated in Qt 5.5, and most > likely removed them from binary packages in Qt 5.6. By the time we're > done with porting to Qt5 5.5 would be ready (May 2015). > > The concern is that Qt Script isn't wery actively developed and > possibly not a safe technology for our scripting needs in Kexi. > Its engine's code has not been actively updated, and JavaScript has > since evolved as a language. Previously QtScript status was Done, what > already meant a "no new features" policy. > > > == What's a replacement? == > > As you know KROSS isn't in KF5/Qt5, so it's not an option to re-add > it. Moreover the idea of KROSS was a general one-size-fits-all support > for multiple programming languages, without find-grained support for > specifics of given language. For example you'd like to use your > language's list structure instead a wrapped QList (just an example). > > QtQml / QJSEngine is the only proposed replacement so far, by the Qt > community. We have not yet analyzed if it's as complete tool set as > QtScript for our needs. Feel free to look closer, it would be > appreciated. > > == Problems? == > > Two particular things I raised questions for in case of the above > proposal, are: > 1. Support for encapsulating non-QObject objects (light, simple > structures) for use in javascript code > 2. Support for (visual) debugging environment for users > > The answer I got (in the same thread [1]): > Re 1. There are some lighter solution, possible related to the new > Qt's Gadget construct > Re 2. Solution would come as a result of contributions that are in > progress, obviously more projects need a debugger component. > > Extra bonus is that we can develop JSON/QML (not necessarily Qt Quick) > based "micro-formats" that are can be easily accessible/blended into > JavaScript scripting. Think of conditional formatting for data grids > or Assistant GUI APIs for end users. > > == Your turn == > > Feel free to post your analysis or concerns regarding scripting here. > > We're about to enter the porting to Qt5/KF5 stage. Aspects of > scripting are included in the plan [3]. The minimum is not to break > compatibility with the simple scripting features in Kexi 2 Reports. > We're not going to support compatibility with the experimental > scripting module of Kexi 2 however (the script Kexi objects). They are > experimental after all. We hope to reuse the Kate-based editor of > course. > > == Good thing == > > I think it's good that given the plan is pragmatic (e.g. we do not > half-develop features) we've not developed QtScript-based scripting so > far, otherwise we're be rather sad because of lost resources. > > > [0] https://community.kde.org/Kexi/Plugins/Scripts > [1] https://www.mail-archive.com/development@qt-project.org/msg18866.html > [2] http://doc.qt.io/qt-5/qjsengine.html > [3] https://community.kde.org/Kexi/Porting_to_Qt%26KF_5 > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: sheets: Can't open CSV files with 'Not implemented' error box
I'll check it out. 2015-04-06 17:34 GMT+02:00 Rex Dieter : > Can someone look at or at least comment on > https://bugs.kde.org/show_bug.cgi?id=344718 > > where calligrasheets in 2.9.0 and 2.9.1 (haven't tested 2.9.2 myself yet) > seems to not be able to open/import csv files anymore. > > I'm hesitant to push this as an update to calligra-2.8.x for fedora 21 with > this regression. > > -- Rex > > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: sheets: Can't open CSV files with 'Not implemented' error box
Okay, fix is in on the 2.9 branch, you can wait for the next bugfix release or patch it up against the latest release. 2015-04-06 17:50 GMT+02:00 Tomas Mecir : > I'll check it out. > > 2015-04-06 17:34 GMT+02:00 Rex Dieter : > >> Can someone look at or at least comment on >> https://bugs.kde.org/show_bug.cgi?id=344718 >> >> where calligrasheets in 2.9.0 and 2.9.1 (haven't tested 2.9.2 myself yet) >> seems to not be able to open/import csv files anymore. >> >> I'm hesitant to push this as an update to calligra-2.8.x for fedora 21 >> with >> this regression. >> >> -- Rex >> >> ___ >> calligra-devel mailing list >> calligra-devel@kde.org >> https://mail.kde.org/mailman/listinfo/calligra-devel >> > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.9.3 reminder
For Sheets, fixed loading of CSV files. Unless that made its way into 1.9.2, which I don't think it did. 2015-04-24 23:04 GMT+02:00 Jaroslaw Staniek : > We need changelogs, please... > > On 20 April 2015 at 12:03, Jaroslaw Staniek wrote: > > Hello, > > A friendly reminder for 2.9.3: > > - Tagging: April 25th > > - Release: April 29th > > > > https://community.kde.org/Calligra/Schedules/2.9/Release_Plan#2.9.3 > > > > -- > > 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 > > > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 123985: Port sheets' configure dialog to KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123985/#review81087 --- compiling to check, but at a glance, I don't think the plugin stuff is going to work, as function modules are loaded using KoJsonTrader in the KDE5 version, as the comments indicate (see sheets/FunctionModuleRegistry.cpp). - Tomas Mecir On jún 2, 2015, 4:08 popoludní, Peter Simonsson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123985/ > --- > > (Updated jún 2, 2015, 4:08 popoludní) > > > Review request for Calligra. > > > Repository: calligra > > > Description > --- > > Fix buttons and signals. > ?eenable the plugin selector. > > > Diffs > - > > CMakeLists.txt a4e3f24 > sheets/CMakeLists.txt c7567c4 > sheets/part/dialogs/PreferenceDialog.h 543bf45 > sheets/part/dialogs/PreferenceDialog.cpp 8b044a8 > > Diff: https://git.reviewboard.kde.org/r/123985/diff/ > > > Testing > --- > > > Thanks, > > Peter Simonsson > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 123985: Port sheets' configure dialog to KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123985/#review81091 --- After testing, yeah, the plugin stuff doesn't work, please either port that as well to the new API, or keep it commented out for now. Otherwise looks good. Thanks! - Tomas Mecir On jún 2, 2015, 4:08 popoludní, Peter Simonsson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123985/ > --- > > (Updated jún 2, 2015, 4:08 popoludní) > > > Review request for Calligra. > > > Repository: calligra > > > Description > --- > > Fix buttons and signals. > ?eenable the plugin selector. > > > Diffs > - > > CMakeLists.txt a4e3f24 > sheets/CMakeLists.txt c7567c4 > sheets/part/dialogs/PreferenceDialog.h 543bf45 > sheets/part/dialogs/PreferenceDialog.cpp 8b044a8 > > Diff: https://git.reviewboard.kde.org/r/123985/diff/ > > > Testing > --- > > > Thanks, > > Peter Simonsson > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: After 2.9.7
Heya, no strong opinions on krita split either way, but while the libs stuff is discussed, figured I'd send in the perspective of the not-particularly-active Sheets maintainer :D A problem that I have been running into with Sheets is that the shared libs seem to contain more things than may be necessary. Can't really come up with specific examples (though they would mostly involve flake/plugins), but several times I've found that while fixing this or that bug/oddity, I ended up having to crawl through quite a web of inter-dependencies between Sheets code, libs code, then back into Sheets, bonus points if one more libs detour was made. That in itself isn't a concern, but when any change to libs could break words or krita or whatever, it makes things a little bit tricky, as you can imagine. So from the application maintainer perspective, I'd like to see the libs as isolated as possible, so that I can essentially treat them as a blackbox (same as Qt / KDE frameworks). I don't know how feasible that is, as we rely on flake for embeddability, but improvements in this area would be quite appreciated, if they are possible. / Tomas 2015-08-29 10:24 GMT+02:00 Camilla Boemann : > As much as I dislike forking I must admit it makes more sense than > splitting the libraries. > > 1) there are conflicting or at list disjoint interests between krita and > office. I am not complaining - it's just a fact. Forking will allow > specialization - splitting will just produce arguing > 2) by splitting it would fall on app maintainers to cleanup - uhm so I > would have to spend hours to clean up for krita-needed-changes and vice > versa, with no obligation from opposite part to make sure suc changes makes > sense or are even possible to adapt to ? > 3) the responsibility could possibly right now fall on the committer but > let's not kid ourselves - that will change rapidly because it will mean > that committers will still have to checkout all repos, making any benefit > void. > 4) the communities are already rather disjoint - few are present in both > irc channels or help out in each other's code > > On the other hand - the time together has been good or us all but I think > the time has come to fork - I have no issue if krita wants to stay in the > Calligra suite but even there their main pr and communication have already > been split up years ago > > So I suggest: > Krita.git > Calligra.git (without author, braindump, karbon, krita and kexi - so just > words, stage, sheets and flow, libs , filters and plugins) > Kexi.git > > Kexi are free to depend on Calligra.git, but even for kexi I have my > doubts if it wouldn't be better to fork > > Now I realize this might be the death of the office apps if we have no one > left to do website maintainance, releases and general work. I will do my > part but I can't do everything. So if no one is prepared to stay and do > releases etc then it still might be better to do the spltting ( but is that > a guarantee things will be released or will krita/kexi eventually split up > or do their own releases anyway. In which case Calligra will be split and > no one to do the even larger release process. > > If enough people are still interested in the office apps so that we can > continue to release then I think forking is the best thing - if not I can > only hope splitting libs will not produce the same fate > > Best regards > Camilla Boemann > > -Original Message- > From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of > Boudewijn Rempt > Sent: 29. august 2015 09:38 > To: Calligra Suite developers and users mailing list < > calligra-devel@kde.org> > Subject: Re: After 2.9.7 > > On Sat, 29 Aug 2015, Cyrille Berger wrote: > > > On Friday 28 August 2015 15:43:12 Boudewijn Rempt wrote: > >> Well, we started the discussion with the idea that making separate > >> repos for the libraries and applications was going to be useful. That > >> rather soon turned into a discussion of the problems we have making > >> our libraries fit for purpose for all applications, and that turned > >> into "why should, e.g., words and the libraries be in a separate > >> repo, it's only a lot of hassle". > >> > >> And that's where the discussion stopped, so I wrote this mail to > >> re-engage the discussion. > > > > I think the problems raised during that discussion were more: > > > > 1) How to keep the repositories in sync? > > 2) Who will fix breakage in applications? > > > > I think Friedrich email from yesterday gives a reasonably good > > solution for 1). > > > > As for 2), the biggest problem is for unmaintained applications. But > > there, I think we have to take the hard decision of simply killing > > those applications, and keep the focus on applications that have > > people who care about them. And then, for small changes, it is up to > maintainers to adjust their applications. > > Bigger changes should be more coordinated. > > I am fine with either solution. If splitting off koofd
Re: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)
2015-08-31 11:24 GMT+02:00 Friedrich W. H. Kossebau : > Does any of the non-Krita maintainers want to do a cleanup of the coding > style? > Indifferent here. Not objecting to it, but I don't really have much need for it either. / Tomas ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: [calligra] /: Port libs from KUrl to QUrl
I'll handle Sheets over the weekend if nobody else does before then. 2015-09-10 11:41 GMT+02:00 Boudewijn Rempt : > Git commit defb836a63608335988184e5ed0590588728f8be by Boudewijn Rempt. > Committed on 10/09/2015 at 09:41. > Pushed by rempt into branch 'master'. > > Port libs from KUrl to QUrl > > This means that several applications are back to unported status: > > Sheets engine > QtQuick components > Karbon > Calligra Converter > Thumbnailer > Okular plugins > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
