Re: Latte : make_unique for gcc <=4.8
On 05/11/17 16:12, Michail Vourlakos wrote: > Do you know any better way to handle this? You can let cmake do the check: https://cmake.org/cmake/help/v3.0/module/CheckSymbolExists.html Not sure if this is the best option, though. Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: Dropping kdelibs4-based applications in KDE Applications 17.12
On 11/11/16 16:45, Dominik Haumann wrote: > What do you think about having a Randa meeting (or similar) with focus > on finishing ports to KF5? Would that make sense? +1 actually. There are a few applications on that list which would, in my eyes, be a real loss if they were not maintained any more; I'm especially looking at kcachegrind (I know of no comparable tool and it's really good), maybe kopete. kmag is nice too on occasion but I don't know if it will die with wayland anyways. I'd be in for a sprint (or a few days of a sprint) to port those. Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: Open Folder and select file
Hey, On 19/03/16 21:44, Dominik Haumann wrote: > I think I will just say > QDesktopServices::openUrl(doc->url().adjusted(QUrl::RemoveFilename)); > then for now. KRun::runUrl seems to work fine as well. Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
On 03/02/2016 11:56 AM, Thomas Lübking wrote: > Imo that's a more issue: IPC is I/O, ie. unreliable. You cannot provide > functionality that relies on working IPC, but hard-relying on it is bad > design (nb. that the failing kded module make _every_ Qt client using > QSystemTray unusable and trying to knock out your system) > > => fix the QPA to handle I/O (dbus etc.) more robust and everyone's happy? Yes, seems like a good approach to me. I think I fixed part of the crash a while back (b45544f3d4 in knotifications, I think there's another trigger for it somewhere though), but it seemed very hard to fall back to the default system tray icons if KSNI is unavailable :/ signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
Hey, On 03/02/2016 11:19 AM, Martin Graesslin wrote: > No, because everything in the current plugin is Plasma specific. Meh. In some kind of theoretical view you are right, I do see that. Pragmatically, that's just not true, most of the things in the plugin are not plasma specific at all, for example: colour schemes, Qt style, icons theme, single/double click, file dialogs. All this is exactly as useful in plasma as it is in any other environment, and applies to the exact same set of applications. In fact the only plasma-specifc thing I know about is KSNI. > Apparently nobody is interested in writing and maintaining > a qpt-plugin for non-plasma. There is one, qt5ct, but if you want to make that as useful as the plasma one, you need to reimplement half of systemsettings5 for no real reason. > We doing the work don't care about openbox or whatever. I find that a little surprising. I thought we were building a set of applications that aim to work well in any environment. Right now, kate looks and works _much_ better on Windows than if you start it with the default settings in openbox (you don't even have icons on openbox!). As a developer of kate and as a person doing "the work" there I find that a bit frustrating. Yes, there could be a dedicated platform theme for that, but there's only one sensible thing it can do right in almost all cases, which is "the same as the plasma one". Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
Hey, On 03/01/2016 07:37 PM, Mark Gaiser wrote: > but there is > undoubtedly going to be a point in time where the plugin only works when > some very specific plasma part is required for it to function That is already the case; try running an application with a systray icon, it will not work (or in older versions even make dbus run out of file descriptors (!)). Otherwise I agree with your reasoning. I'm just not sure what we can effectively do about it. Having the plugin in an extra repository imo doesn't help much, and I really don't mind having plasma installed. Best, Sven signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
On 02/29/2016 11:09 PM, Thiago Macieira wrote: >> So using QT_QPA_PLATFORMTHEME=kde is basically not a viable solution for >> > any non-plasma desktop out there. Instead you are stuck with a 3rd party >> > solution like qt5ct to at least set the Qt / icon theme (color scheme is >> > quite hard already), and there is basically no viable option to get e.g. >> > KDE file dialogs back (instead of the unusable Qt5 default ones). > If you're not in the Plasma desktop, you should get the dialogs from the > desktop you're in. For example, if you're in GNOME, the GTK style plugin > should get the GTK dialogs. But that assumes the desktop you're in actually provides this functionality. And I think basically all desktops but Plasma and GNOME don't do that (mine certainly doesn't, it doesn't even _have_ its own file dialog). In this case the default is quite bad (the Qt5 file dialog is, sorry to say, terrible) and the chances to change it are hard to reach or not available. I don't think that is a great situation. I guess the problem here is that some Look&Feel decisions require a specific desktop (e.g. KSNI) while others don't, but they are grouped into the same module. Probably this doesn't affect enough people to be of interest to anyone, though. Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
Hey, On 02/28/2016 03:58 PM, Luigi Toscano wrote: > This is what I use: > export QT_QPA_PLATFORMTHEME=kde > > and you need the integration plugin installed. It used to be part of > Frameworks (frameworksintegration), it will be part of Plasma (but hopefully > still usable without). It isn't, unfortunately. For example, it requires KSNI support, because for some weird reason that is part of the platform theme. So using QT_QPA_PLATFORMTHEME=kde is basically not a viable solution for any non-plasma desktop out there. Instead you are stuck with a 3rd party solution like qt5ct to at least set the Qt / icon theme (color scheme is quite hard already), and there is basically no viable option to get e.g. KDE file dialogs back (instead of the unusable Qt5 default ones). Quite a step back from KDE 4 times right now, unfortunately :/ Best, Sven signature.asc Description: OpenPGP digital signature
Re: Change to Mail Infrastructure - SPF and DKIM verification will now be enforced
On 08/12/15 10:54, Ben Cooksley wrote: >> > Correction: Wayland is also affected. I didn't check a gmail mail. So given >> > that all freedesktop.org are probably affected. >> > >> > Sorry Ben, that's just a no, it will be highly disruptive to KDE to turn us >> > off from these mailing lists. > Can't recall if I stated this previously, but i'd already decided to > delay this until the end of January. > It should not be delayed forever though. I am also quite sceptical of this. The main task of a mail system is to deliver email reliably. Anti-Spam measures are only useful if they have a very very low false-positive rate. And from my personal experience, DKIM is so shaky to date that you will end up rejecting _lots_ of mail erraneously. Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: Changes to our Git infrastructure
> N not scratch repos. I can see clones being useless as branches > in the actual repos should be used instead, but I personally consider > scratch repos a very useful thing, for example to host simple projects > that shouldn't be part of any main/big module - they are much more > easier to set up than proper repositories - mostly because they don't > require manual sysadmin actions (and fileing tickets by the developer), > it's a personal git space readily available. +1, I also think scratch repos are useful and shouldn't be removed mostly for the reasons Martin quoted.
Re: Using Gerrit for code review in KDE
> Everyone with a KDE developer account should in principle have > the right to give a +2. One should only use it when appropriate though, i.e. > when one is the maintainer of a given piece of code or when the patch is > simple enough so that one feels safe to give the other the ship-it. That's my opinion as well. It would be nice to have an explicit way to differentiate the "I think this patch is okay, but I'm not very familiar with the code you changed" (+1) and "I'm confident this patch is fine" (+2) cases, and I think everyone with a KDE dev account is capable of deciding which one to select by himself when reviewing, without a technical restriction on what one can do. Greetings!
Re: KDE Review: Move LabPlot to extragear.
Hi, On Thursday 13 February 2014 22:04:32 Alexander Semke wrote: > Huch. I cannot reproduce this. Does this error happens on your system > independent of the plot type (box plot etc.) you're trying to create? Sorry for the noise, I apparently didn't install the XMLGUI files properly. Thus the button it tried to set a name on wasn't there. Now it works fine. Greetings!
Re: KDE Review: Move LabPlot to extragear.
Hello! On Tuesday 11 February 2014 21:32:29 Alexander Semke wrote: > couple of days ago LabPlot-project [1] decided to move to KDE and to become > a part of KDE Edu and to collaborate closer with people involved in other > projects on KDE Edu [2]. After almost four years of development we had the > first stable release shortly [3] and the first bug fix release. Sounds like a cool project! A few things I noticed: - why not put the compile flags from the ./compile script in CMakeLists.txt? - I added a file data source, then a worksheet and an xy plot and it crashed [1] Greetings! Sven [1] Backtrace: http://paste.kde.org/pnhjuzsao
Re: Review Request 113175: Always use an external viewer application to view files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/113175/ --- (Updated Feb. 7, 2014, 10:13 p.m.) Status -- This change has been discarded. Review request for KDE Base Apps. Repository: ark Description --- This patch makes ark always use an external viewer application instead of using the clunky internal preview thing. The internal viewer would just embed a plain kpart into a window, but without providing any of the XMLGUI or whatever from that part. Thus, when you for example clicked a PDF, you couldn't print it. The advantages of the internal viewer are imo overall quite questionable, and are far outweighted by its disadvantages. Plus, it removes code ;) Diffs - part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb Diff: https://git.reviewboard.kde.org/r/113175/diff/ Testing --- Clicking files opens them in the default application, as it should. Thanks, Sven Brauch
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
Hi! Cool project, I really missed such a component a while back (I actually wrote my own back then, which was less nice than yours). The code looks sane too from a quick look, so I'm all for moving it to extragear (although I'm not exactly an expert for sane code). It doesn't seem to be designed for lots of data (since each point is an object, etc.), which is understandable; but eventually it would be a nice feature to add API designed towards such data in the future? On Wednesday 29 January 2014 12:41:22 Inge Wallin wrote: > Regarding 3D charts, I have no idea if this is even possible using QML > alone or if you need to do something else for that. I assume you're talking about the "usual" 3D charts, such as 3D-looking pie charts and bar graphs? For drawing those, I would not use any kind of 3D API at all. Just drawing some rectangles and ellipses clipping each other will be way easier for that purpose, which is very easy even with QtQuick 1. (Apart from that, those 3D effects are bad for a chart's readability anyways ;) Greetings, Sven
Re: kde-workspace git broken ?
On Monday 11 November 2013 14:13:22 Martin Gräßlin wrote: > Please remember: do not push a revert of a merge commit. Another tip not everyone might know: you can use git push --dry-run to see which changes would be pushed, without actually pushing them. That helps a lot with avoiding breakage. Sven
Re: Adopting AppData in KDE?
On Sunday 03 November 2013 12:49:52 henry miller wrote: > Richard Hughes wrote: > >Please don't portray me as a modern-day highwayman as I'm really just > >trying to build an awesome application installer for GNOME. It's two > >orders of magnitude harder to actually write a shared standard and ask > >other desktops to adopt it (making changes as required) rather than a > >quick hack that just works with one desktop on one distribution. > > Let me rewritte the above into a FAQ format: > Q: Why does KDE not ship appdata files > A: the maintainers of appdata have admited they have no interest in > standards, thus KDE has no formal ability to get things we need changed. > In addition while appdata claims to be distribution/gnome, it really is a > Fedora thing and few other distribution packages use it, thus violating > KDEs no patches for on distribution only. Let's not make a fight of this. I think the point that some people (including me) didn't find the strategy for creating a standard quite optimal was made, and we should drop it now and focus on discussing the adoption of the specification. Sven
Re: Adopting AppData in KDE?
On Sunday 03 November 2013 13:50:05 Richard Hughes wrote: > I don't think that's true at all. Krita and Inkscape are two of the > killer apps I'd love to feature more prominently in GNOME Software. Yes, and of course both applications would do anything it takes to get listed in the package manager. Still, if KDE would go with its own thing it would be unnecessarily painful. I just wanted to say that KDE doing its own thing is a kind of virtual option since nobody would profit from it. We're probably getting into a fight over uninteresting details here, sorry for bringing them up. I just wanted to make two points, which are - looking for this metadata file is not a good way to ensure quality - I like the spec but I do not like the way it is presented to KDE. On Sunday 03 November 2013 15:04:16 Felix Rohrbach wrote: > Personally, I think it's a good idea to have something like AppData, but > as a way to let an application present itself, not as something > applications are forced to use. Exactly. Greetings, Sven
Re: Adopting AppData in KDE?
On Sunday 03 November 2013 12:22:52 Richard Hughes wrote: > This is what we've decided to do in GNOME, KDE is free to decide any policy > it wants. We've decided that 500 high quality applications are better than > 3000 broken ones. Assuming KDE did that, then we would end up with a situation where you can't easily install Krita in distributions that ship GNOME, and you can't easily install Inkscape in distributions that ship KDE. That's a horrible situation, because a lot of people do that as of today. It would further widen the (technical) gap between the desktop environments, instead of encouraging people to select the best application for what they want to do regardless of what toolkit it uses (which I consider a somewhat idiotic criterion). There would be lots of confused users in internet forums asking for why $application is not available any more, and we'd be sitting there explaining how to jump through hoops to still install it. Thus I would claim that this is not an acceptable option. Quality control should happen at the packager level. Broken applications should not be available in the distribution's main repository. And distributions should make the choice which application is good enough for their users, not a desktop environment. Besides, as said multiple times, this spec does not provide any kind of quality control worth mentioning anyways. The level of quality control it achieves is on par with looking at the date of the last commit in the repository. For the same reasons, in my opinion, not showing packages in a package manager which don't provide screenshots because they don't look pretty is a bad choice. Of course this is your decision though. In any case, it's a very bad precondition for discussing the new specification for the reasons Albert mentioned. > I don't think _having_ an AppData > file makes an application high quality, but we can probably say the > opposite is true in about 2-3 years. I don't see the point. Either it becomes so mainstream that you effectively need to have it; then every maintainer of a crappy application will just add it (to put it bluntly). Just imagine it would be part of an IDEs template for a new application -- nobody would not have it. Or it does not become mainstream; then you will end up excluding a lot of high-quality applications for no reason (think e.g. Blender). Greetings, Sven
Re: Adopting AppData in KDE?
On Saturday 02 November 2013 20:05:11 Richard Hughes wrote: > > Who's doing the quality review? > Well, if an upstream ships a valid .desktop file and a valid AppData > file then that's a good indication it's at least alive. I don't understand that. It's a good indication it's alive right now, but that's just because the spec is new. In three years the presence of such a file will indicate exactly nothing, or will it? Greetings, Sven
Re: Adopting AppData in KDE?
On Saturday 02 November 2013 19:48:01 Richard Hughes wrote: > On 2 November 2013 19:33, Albert Astals Cid wrote: > > What's the point in having an installer that hides more than half of the > > apps in the world that don't ship a file that is not a standard and > > doesn't seem to me it was developed as a standard? How is this useful to > > the end user? > We want to showcase high quality applications with active upstream > maintainers. There's no point us showing 5000 application where half > don't work or are abandonware. Also, I'm hoping AppData does become a > standard. It's already used by over 200 projects. This is what baffled me a bit too. Selecting applications which adhere to this standard doesn't seem like a very good way to select high-quality applications to me. Assuming KDE would say "no, we don't like this standard, we want to do it differently" you would lock all KDE apps out of your software installer? That being said, I do like the idea and I also like the specification. I'd like it to be adopted. Just my two cents ;) Greetings, Sven
Re: Adopting AppData in KDE?
On Saturday 02 November 2013 14:37:02 Richard Hughes wrote: > Well, I've not done any technical review of the OCS code, but in > Fedora I've chosen to use fedora-tagger for ratings and comments. It's > not hardcoded and I'd be open to doing something else. I have worked with OCS in the past on a technical level (I have implemented part of it) and I would not recommend to use it as a basis for any new project, at least not without *significant* revision. Most of the requests have severe design flaws, especially there's usually an arbitrary number (e.g. 12 screenshots) of items allowed for which there are 12 different tags called , etc. which makes everything a pain. This pattern is in like every request. Greetings, Sven
Re: Review Request 113175: Always use an external viewer application to view files
> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote: > > I'm not totally happy with this change. Yes, the internal viewer is > > limited in functionality, but it has advantages: (1) it is fast to open > > and can be closed again with a single keystroke; (2) it remembers its size > > and can be resized without affecting the default window size of, say, > > KWrite or whichever external application is used; (3) it can be forced to > > display an archive component of any type as plain text. > > > > There's nothing wrong with having the facility to open an archive component > > in its default application (or any other application), but it should be an > > option. Either a configuration setting (Use internal viewer - Use external > > application), or a context menu with options View (in the internal viewer), > > Open (in the default application) or Open With... (any other application). > > Sven Brauch wrote: > I guessed some people would not be happy with it, but it was worth a try > ;) > > How about a context menu action? Or, since the context menu is currently > empty, just opening the external viewer on right-click? > > Jonathan Marten wrote: > Not sure that changing the function of the right-click would be approved > of (but then, I'm not the ark maintainer or authority, just an intensive user > of it). Maybe the middle button? > > There has been some discussion about adding a context menu to Ark before > now - e.g. bug #166203. > > > Sebastian Kügler wrote: > Honestly, to most people the internal viewer just looks broken, like an > incomplete stepchild of the real viewer application. > > Can we please at least make the default to open the application, not the > crippled viewer? > > Sven Brauch wrote: > I feel like Sebastian does and I have watched people use Ark before which > obviously felt the same (i.e. which were confused because the PDF viewer was > missing all the buttons). I do see the point of the viewer in some corner > cases, but in almost all cases I don't want it. > > Maybe we could do this: The side panel is currently quite useless (huge > amount of space occupied + little information in there). We could embed the > viewer there, and change the action on click to select the file and display > it there. That would serve the (I guess?) common use case, which is looking > through several images and deciding which one you want to extract even better > than the current solution. Then there could be a button below the viewer > widget to open the file in the actual application. > I'm not sure this is a good idea, what do you think? Ok, I see the problem with that approach -- it requires extracting files on selecting them, which is of course not optimal. - Sven --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113175/#review41400 --- On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113175/ > --- > > (Updated Oct. 8, 2013, 3:23 p.m.) > > > Review request for KDE Base Apps. > > > Repository: ark > > > Description > --- > > This patch makes ark always use an external viewer application instead of > using the clunky internal preview thing. The internal viewer would just embed > a plain kpart into a window, but without providing any of the XMLGUI or > whatever from that part. Thus, when you for example clicked a PDF, you > couldn't print it. The advantages of the internal viewer are imo overall > quite questionable, and are far outweighted by its disadvantages. > > Plus, it removes code ;) > > > Diffs > - > > part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb > part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 > part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 > part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb > > Diff: http://git.reviewboard.kde.org/r/113175/diff/ > > > Testing > --- > > Clicking files opens them in the default application, as it should. > > > Thanks, > > Sven Brauch > >
Re: Review Request 113175: Always use an external viewer application to view files
> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote: > > I'm not totally happy with this change. Yes, the internal viewer is > > limited in functionality, but it has advantages: (1) it is fast to open > > and can be closed again with a single keystroke; (2) it remembers its size > > and can be resized without affecting the default window size of, say, > > KWrite or whichever external application is used; (3) it can be forced to > > display an archive component of any type as plain text. > > > > There's nothing wrong with having the facility to open an archive component > > in its default application (or any other application), but it should be an > > option. Either a configuration setting (Use internal viewer - Use external > > application), or a context menu with options View (in the internal viewer), > > Open (in the default application) or Open With... (any other application). > > Sven Brauch wrote: > I guessed some people would not be happy with it, but it was worth a try > ;) > > How about a context menu action? Or, since the context menu is currently > empty, just opening the external viewer on right-click? > > Jonathan Marten wrote: > Not sure that changing the function of the right-click would be approved > of (but then, I'm not the ark maintainer or authority, just an intensive user > of it). Maybe the middle button? > > There has been some discussion about adding a context menu to Ark before > now - e.g. bug #166203. > > > Sebastian Kügler wrote: > Honestly, to most people the internal viewer just looks broken, like an > incomplete stepchild of the real viewer application. > > Can we please at least make the default to open the application, not the > crippled viewer? I feel like Sebastian does and I have watched people use Ark before which obviously felt the same (i.e. which were confused because the PDF viewer was missing all the buttons). I do see the point of the viewer in some corner cases, but in almost all cases I don't want it. Maybe we could do this: The side panel is currently quite useless (huge amount of space occupied + little information in there). We could embed the viewer there, and change the action on click to select the file and display it there. That would serve the (I guess?) common use case, which is looking through several images and deciding which one you want to extract even better than the current solution. Then there could be a button below the viewer widget to open the file in the actual application. I'm not sure this is a good idea, what do you think? - Sven --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113175/#review41400 --- On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113175/ > --- > > (Updated Oct. 8, 2013, 3:23 p.m.) > > > Review request for KDE Base Apps. > > > Repository: ark > > > Description > --- > > This patch makes ark always use an external viewer application instead of > using the clunky internal preview thing. The internal viewer would just embed > a plain kpart into a window, but without providing any of the XMLGUI or > whatever from that part. Thus, when you for example clicked a PDF, you > couldn't print it. The advantages of the internal viewer are imo overall > quite questionable, and are far outweighted by its disadvantages. > > Plus, it removes code ;) > > > Diffs > - > > part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb > part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 > part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 > part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb > > Diff: http://git.reviewboard.kde.org/r/113175/diff/ > > > Testing > --- > > Clicking files opens them in the default application, as it should. > > > Thanks, > > Sven Brauch > >
Re: Review Request 113175: Always use an external viewer application to view files
> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote: > > I'm not totally happy with this change. Yes, the internal viewer is > > limited in functionality, but it has advantages: (1) it is fast to open > > and can be closed again with a single keystroke; (2) it remembers its size > > and can be resized without affecting the default window size of, say, > > KWrite or whichever external application is used; (3) it can be forced to > > display an archive component of any type as plain text. > > > > There's nothing wrong with having the facility to open an archive component > > in its default application (or any other application), but it should be an > > option. Either a configuration setting (Use internal viewer - Use external > > application), or a context menu with options View (in the internal viewer), > > Open (in the default application) or Open With... (any other application). I guessed some people would not be happy with it, but it was worth a try ;) How about a context menu action? Or, since the context menu is currently empty, just opening the external viewer on right-click? - Sven --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113175/#review41400 ------- On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113175/ > --- > > (Updated Oct. 8, 2013, 3:23 p.m.) > > > Review request for KDE Base Apps. > > > Repository: ark > > > Description > --- > > This patch makes ark always use an external viewer application instead of > using the clunky internal preview thing. The internal viewer would just embed > a plain kpart into a window, but without providing any of the XMLGUI or > whatever from that part. Thus, when you for example clicked a PDF, you > couldn't print it. The advantages of the internal viewer are imo overall > quite questionable, and are far outweighted by its disadvantages. > > Plus, it removes code ;) > > > Diffs > - > > part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb > part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 > part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 > part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb > > Diff: http://git.reviewboard.kde.org/r/113175/diff/ > > > Testing > --- > > Clicking files opens them in the default application, as it should. > > > Thanks, > > Sven Brauch > >
Re: Review Request 113175: Always use an external viewer application to view files
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113175/ --- (Updated Oct. 8, 2013, 3:23 p.m.) Review request for KDE Base Apps. Changes --- No, in fact we should do this, of course. The class is worthless now. Repository: ark Description --- This patch makes ark always use an external viewer application instead of using the clunky internal preview thing. The internal viewer would just embed a plain kpart into a window, but without providing any of the XMLGUI or whatever from that part. Thus, when you for example clicked a PDF, you couldn't print it. The advantages of the internal viewer are imo overall quite questionable, and are far outweighted by its disadvantages. Plus, it removes code ;) Diffs (updated) - part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb Diff: http://git.reviewboard.kde.org/r/113175/diff/ Testing --- Clicking files opens them in the default application, as it should. Thanks, Sven Brauch
Re: Review Request 113175: Always use an external viewer application to view files
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113175/ --- (Updated Oct. 8, 2013, 3:17 p.m.) Review request for KDE Base Apps. Repository: ark Description --- This patch makes ark always use an external viewer application instead of using the clunky internal preview thing. The internal viewer would just embed a plain kpart into a window, but without providing any of the XMLGUI or whatever from that part. Thus, when you for example clicked a PDF, you couldn't print it. The advantages of the internal viewer are imo overall quite questionable, and are far outweighted by its disadvantages. Plus, it removes code ;) Diffs (updated) - part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 Diff: http://git.reviewboard.kde.org/r/113175/diff/ Testing --- Clicking files opens them in the default application, as it should. Thanks, Sven Brauch
Re: Review Request 113175: Always use an external viewer application to view files
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113175/ --- (Updated Oct. 8, 2013, 3:13 p.m.) Review request for KDE Base Apps. Repository: ark Description --- This patch makes ark always use an external viewer application instead of using the clunky internal preview thing. The internal viewer would just embed a plain kpart into a window, but without providing any of the XMLGUI or whatever from that part. Thus, when you for example clicked a PDF, you couldn't print it. The advantages of the internal viewer are imo overall quite questionable, and are far outweighted by its disadvantages. Plus, it removes code ;) Diffs - part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 Diff: http://git.reviewboard.kde.org/r/113175/diff/ Testing --- Clicking files opens them in the default application, as it should. Thanks, Sven Brauch
Re: Review Request 113175: Always use an external viewer application to view files
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113175/ --- (Updated Oct. 8, 2013, 3:11 p.m.) Review request for KDE Base Apps and Raphael Kubo da Costa. Repository: ark Description --- This patch makes ark always use an external viewer application instead of using the clunky internal preview thing. The internal viewer would just embed a plain kpart into a window, but without providing any of the XMLGUI or whatever from that part. Thus, when you for example clicked a PDF, you couldn't print it. The advantages of the internal viewer are imo overall quite questionable, and are far outweighted by its disadvantages. Plus, it removes code ;) Diffs - part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 Diff: http://git.reviewboard.kde.org/r/113175/diff/ Testing --- Clicking files opens them in the default application, as it should. Thanks, Sven Brauch
Review Request 113175: Always use an external viewer application to view files
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113175/ --- Review request for KDE Base Apps. Repository: ark Description --- This patch makes ark always use an external viewer application instead of using the clunky internal preview thing. The internal viewer would just embed a plain kpart into a window, but without providing any of the XMLGUI or whatever from that part. Thus, when you for example clicked a PDF, you couldn't print it. The advantages of the internal viewer are imo overall quite questionable, and are far outweighted by its disadvantages. Plus, it removes code ;) Diffs - part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 Diff: http://git.reviewboard.kde.org/r/113175/diff/ Testing --- Clicking files opens them in the default application, as it should. Thanks, Sven Brauch
Re: kio and KDirNotify for remote protocols
On Wednesday 21 August 2013 23:23:35 David Faure wrote: > You could listen to the KDirNotify signal leftDirectory(url). Awesome, thanks.
Re: kio and KDirNotify for remote protocols
Hi! On Wednesday 21 August 2013 22:37:31 David Faure wrote: > No, which is why people typically create a kded module for the purpose of > such always-running watching and notifying. Ok, then this is probably what I'm going to do, too. > I don't really follow this one. The URLs have to match as you noted. Maybe > your kioslaves can register the URLs being used, so that the kdirnotify > signals use the right URLs? Yes, when I have a kded module anyways, then this is probably the way to solve this issue. I'm just not sure how to remove an URL from the watchlist again when e.g. the file browser is no longer displaying it... Greetings, Sven
kio and KDirNotify for remote protocols
Hi! I'm writing a KIO slave for the infinote protocol [1]. The protocol features push-notifications for connected clients when a file is added or removed, and it's sort of important for the user to see when files are added. Thus, I'd like to make the application using the slave (e.g. dolphin) reload the view when such a notification arrives. In theory, I know I can do this through the KDirNotify interface, but in practice, there's two problems: (1) I have no idea how long slaves are kept alive. Can I bind them to a specific view (e.g. dolphin window) and prevent them from exiting until the user closes the window, to make sure notifications are actually being received? (2) I do not know which URL to pass to KDirNotify, since such an URL might or might not include user name, default port, ... And if the URL format passed to KDirNotify by the slave differs from the format in e.g. dolphin's URL bar, the view will not be reloaded. Can someone give me a hint on how to go about solving those issues? Greetings, Sven ___ [1] http://infinote.org/
Re: Releases in 3 months
I think Nuno's point is very interesting and worth thinking about. To stick with the firefox example, since they started releasing every ortography fix in the settings dialog as a new major version, I think attention in the media to their releases has declined a lot -- nobody cares any more that a new version of firefox was released since it happens every three days. Of course this is not the only and not the most important criterion, but I still think an eye should be kept on it. Greetings, Sven 2013/7/8 Ingo Klöcker : > On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote: >> On Monday 08 July 2013 16:26:00 laurent Montel wrote: >> > Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : >> > > Hi, >> > > >> > > 2013/7/8 Àlex Fiestas: >> > > > Now that kde-workspace and kdelibs are going to be frozen (which >> > > > in >> > > > theory >> > > > means less work for everybody) I'd like to propose a new release >> > > > schedule >> > > > to be applied starting with 4.12. >> > > > >> > > > Basically the idea is to cut testing time and compensate it by >> > > > keeping master always in a "releaseable" state, now that two >> > > > major components are >> > > > frozen it looks like it is a good time to get used to it. >> > > > >> > > > You can read all the proposal in: >> > > > http://community.kde.org/KDE_Core/ReleasesProposal >> > > > >> > > > Before sending this email I have checked with distro people, >> > > > i18n >> > > > people, >> > > > other developers and almost all of them seemed to either like or >> > > > be >> > > > neutral >> > > > about it (only one exception :p) so I hope that the proposal is >> > > > not a >> > > > complete disaster. >> > > > >> > > > As its name indicates, it is a proposal, so please be >> > > > constructive in >> > > > the >> > > > feedback, we can change as many things as we need. >> > > >> > > I like the idea (from the Dolphin development point of view). Most >> > > of >> > > the changes that went into master during the past months had >> > > already >> > > been tested rather well before they were merged, and the remaining >> > > regressions were found rather quickly by people who use the master >> > > branch a lot. Therefore, it would have been nice if some of the >> > > improvements could have been shipped to users sooner - quite a few >> > > bugs that had been fixed in master (with patches that were IMHO >> > > too >> > > intrusive for the 4.10 branch) months ago were reported again and >> > > again. >> > > >> > > @Laurent:you say that you have "a lot of features to implement", >> > > and >> > > that this would not be possible with a shorter release schedule. >> > > But >> > > wouldn't it be possible to implement some of the features for the >> > > next version and the rest for the one after that? >> > > >> > > If you think that you >> > > need more time to stabilize a feature in the master branch, then >> > > maybe developing the feature in a separate branch and merge it >> > > once it's finished might be a good idea? >> > >> > No it’s not a good idea because nobody tests branch you can see pb >> > that we had when we merge akonadi branch (last big changes). >> >> It is true that we have a problem with getting people to test >> branches. But this problem is independant from the release schedule: >> I believe developing in branches is a good way to work, no matter if >> releases are created every 3 or 6 months. >> >> Having said so, I think Akonadi is a bad example because: >> - It was a huge change, quite the equivalent of a rewrite >> - It was affecting personal data > > Akonadi was developed in a branch. Okay, this branch was called master > and the stable branch was called KDE 4.4 (IIRC), and, of course, this > wasn't nice for people who built everything from master. But we tried to > communicate very clearly that master was not to be used for anything > expect for KDE PIM development. > > And, of course, we did consider using a proper branch, but then we would > have had to maintain 3 branches: KDE 4.4, Akonadi, and master. Given > that we didn't and still don't have enough people to even maintain the > Akonadi branch (aka master) I still think that this decision was the > only sensible one. The only feasible alternative would have been the > deletion of master until the first Akonadi-based alpha release. > > But all of this is stuff from the past. When we do Akonadi 2 ;-) we'll > probably choose a different path. > > > Regards, > Ingo
Re: gdk_x_error (was: Re: [kile] [Bug 321759] Kile crashes when file is opened from menu)
>> 2. GDK installs a deadly X error handler, causing the application to >> exit, instead of "just" printing an error message. See multiple >> backtraces containing gdk_x_error[3] There have recently been similar reports for KDevelop, too.
Re: Review Request 111050: Fast mime detection speedup. Well over 10x faster.
> On June 16, 2013, 4:59 p.m., Sven Brauch wrote: > > While speedup is certainly always great, this sounds dangerous to me: > > > > > I am getting an inconsistency. Using the unpatched fast mime detection on > > > a file like: "test.tar.gz" gets detected as > > > "application-x-compressed-tar" where the patched > version detects it as > > > "application-gzip". The slow and detailed mime detection detects the same > > > file as "application-x-compressed-tar". What should it be? > > > > application-gzip or application-x-compressed-tar? > > > Note: This improved detection does expect folders to end with a "/". > > > > I have no idea how e.g. KDevelop would react to those changes. In any case > > I would vote against putting such a fundamental change in behaviour into > > the soon-to-be-released 4.11 (without a long testing period). > > > > I didn't look at the code. > > Mark Gaiser wrote: > Hi Sven, > > A "fundamental change in behaviour" .. It behaves exactly the same as it > used to be. > "file:///home/yourusername/whateverforlder/" will be detected as folder. > "file:///home/yourusername/whateverforlder" won't be detected as folder, but > as the default. > > However, even the file chooser popup dialog is now showing folders with > "application-octet-stream" so i might have to revise the folder detection to > be a bit more permissive.. Files seem to be just fine. Well, if even the file chooser dialog is affected, then you can probably imagine that it'll hit quite a few other applications as well. That's why I said "fundamental change" :) - Sven --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111050/#review34437 --- On June 16, 2013, 4:42 p.m., Mark Gaiser wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111050/ > --- > > (Updated June 16, 2013, 4:42 p.m.) > > > Review request for kdelibs, David Faure and Frank Reininghaus. > > > Description > --- > > Hi, > > I've recently seen Frank Reininghaus do his best in speeding up the rendering > in dolphin with regards to the app icons. And trying to prevent icon > flickering between "unknown" and the actual icon. > > While reading his posts on the mailing list i was beginning to wonder: "is > fast mime detection actually fast"? While it was certainly faster then "slow" > mime detection, it still didn't really seem fast to me. A small benchmark app > hat ran fast mime detection in /usr/bin took ~40ms to complete. That's for > just 2656 items. > > After quite a bit of profiling i managed to to bring the duration down from > ~40ms to ~3ms sometimes ~4ms. That's well over 10x faster. > Mime detection by extension (like "file.tar.bz") is done as follows: > > file.tar.bz > Loop - find first dot > - "tar.gz" > if that matches a mime type then it's returned if it doesn't then it proceeds > on to the next dot: > - next dot: "gz" > if that matches.. return. > Otherwise it will return the default mime type. > > I am getting an inconsistency. Using the unpatched fast mime detection on a > file like: "test.tar.gz" gets detected as "application-x-compressed-tar" > where the patched version detects it as "application-gzip". The slow and > detailed mime detection detects the same file as > "application-x-compressed-tar". What should it be? application-gzip or > application-x-compressed-tar? > > Note: This improved detection does expect folders to end with a "/". > Otherwise they will be detected as application-octet-stream (the default). > But i think this is common sense to let folders end with a "/". If any apps > that don't do that, they should fix it i suppose. > > Best thing, it's all internal and private api change. No public function is > changed. > > All feedback is welcome! If possible, i would like to put this in KDE 4.11. > > > Diffs > - > > kdecore/services/kmimetype.h bc35bcf > kdecore/services/kmimetype.cpp d748523 > kdecore/services/kmimetyperepository.cpp f56f48e > kdecore/services/kmimetyperepository_p.h e1d2389 > > Diff: http://git.reviewboard.kde.org/r/111050/diff/ > > > Testing > --- > > Tested this using just output comparison between the old version and the new > implementation. It works just fine. > > > Thanks, > > Mark Gaiser > >
Re: Review Request 111050: Fast mime detection speedup. Well over 10x faster.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111050/#review34437 --- While speedup is certainly always great, this sounds dangerous to me: > I am getting an inconsistency. Using the unpatched fast mime detection on a > file like: "test.tar.gz" gets detected as "application-x-compressed-tar" > where the patched > version detects it as "application-gzip". The slow and > detailed mime detection detects the same file as > "application-x-compressed-tar". What should it be? > application-gzip or > application-x-compressed-tar? > Note: This improved detection does expect folders to end with a "/". I have no idea how e.g. KDevelop would react to those changes. In any case I would vote against putting such a fundamental change in behaviour into the soon-to-be-released 4.11 (without a long testing period). I didn't look at the code. - Sven Brauch On June 16, 2013, 4:42 p.m., Mark Gaiser wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111050/ > --- > > (Updated June 16, 2013, 4:42 p.m.) > > > Review request for kdelibs, David Faure and Frank Reininghaus. > > > Description > --- > > Hi, > > I've recently seen Frank Reininghaus do his best in speeding up the rendering > in dolphin with regards to the app icons. And trying to prevent icon > flickering between "unknown" and the actual icon. > > While reading his posts on the mailing list i was beginning to wonder: "is > fast mime detection actually fast"? While it was certainly faster then "slow" > mime detection, it still didn't really seem fast to me. A small benchmark app > hat ran fast mime detection in /usr/bin took ~40ms to complete. That's for > just 2656 items. > > After quite a bit of profiling i managed to to bring the duration down from > ~40ms to ~3ms sometimes ~4ms. That's well over 10x faster. > Mime detection by extension (like "file.tar.bz") is done as follows: > > file.tar.bz > Loop - find first dot > - "tar.gz" > if that matches a mime type then it's returned if it doesn't then it proceeds > on to the next dot: > - next dot: "gz" > if that matches.. return. > Otherwise it will return the default mime type. > > I am getting an inconsistency. Using the unpatched fast mime detection on a > file like: "test.tar.gz" gets detected as "application-x-compressed-tar" > where the patched version detects it as "application-gzip". The slow and > detailed mime detection detects the same file as > "application-x-compressed-tar". What should it be? application-gzip or > application-x-compressed-tar? > > Note: This improved detection does expect folders to end with a "/". > Otherwise they will be detected as application-octet-stream (the default). > But i think this is common sense to let folders end with a "/". If any apps > that don't do that, they should fix it i suppose. > > Best thing, it's all internal and private api change. No public function is > changed. > > All feedback is welcome! If possible, i would like to put this in KDE 4.11. > > > Diffs > - > > kdecore/services/kmimetype.h bc35bcf > kdecore/services/kmimetype.cpp d748523 > kdecore/services/kmimetyperepository.cpp f56f48e > kdecore/services/kmimetyperepository_p.h e1d2389 > > Diff: http://git.reviewboard.kde.org/r/111050/diff/ > > > Testing > --- > > Tested this using just output comparison between the old version and the new > implementation. It works just fine. > > > Thanks, > > Mark Gaiser > >
Re: Review Request 111000: add KTextEditor::MessageInterface for KDE SC 4.11
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111000/#review34316 --- +1, I have various ideas how this might be very useful. Cool! - Sven Brauch On June 13, 2013, 5:10 p.m., Dominik Haumann wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111000/ > --- > > (Updated June 13, 2013, 5:10 p.m.) > > > Review request for Kate, kdelibs, Albert Astals Cid, and Christoph Cullmann. > > > Description > --- > > This patch adds the KTextEditor::MessageInterface to the KTextEditor > interfaces in kdelibs 4.11. > > This interface exists in Kate since KDE 4.10, and is already used internally > to show messages when needed (e.g. search & replace, or swap file recover > bar). By adding this interface to kdelibs, applications like KDevelop, Kile, > etc... can use this interface to show passive interactive notifications in a > KTextEditor::View. > > With this commit, we also want to get feedback by potential users of this > interface, so we can improve/tweak it again for KDE 5 (or whatever it will be > called :) ). > > > Diffs > - > > interfaces/ktexteditor/messageinterface.cpp PRE-CREATION > interfaces/ktexteditor/messageinterface.h PRE-CREATION > interfaces/ktexteditor/CMakeLists.txt 9813734 > includes/KTextEditor/MessageInterface PRE-CREATION > includes/KTextEditor/Message PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/111000/diff/ > > > Testing > --- > > Given the interface is in Kate since KDE 4.10, the interface is quite mature. > > > Thanks, > > Dominik Haumann > >
Re: Techbase: schedules for playground and extragear
> If there are no objections, I'd remove the two pages mentioned above > by the end of the week. What do you think? I think I found those pages recently too, and I'm all for deleting them. They will get out of date again, even if someone would update them now. Cheers!
Re: R: Re: kde review kartesio
Hi, I'm sorry, but I have to agree with Anne-Marie. Cheers! Sven 2013/5/12 Anne-Marie Mahfouf : > Hi, > > I think Kartesio is not ready to move: > - the GUI is not so good > - lack of tooltips > - I am not happy with some strings and they lack context info > - the standard C++ code is not so good either (this rm for example) > - lack of testing > > I suggest you do a release first so we can test translations and you can get > some users feedback and have time to move the code to Qt classes. > > This is my suggestion only, others may disagree > > Best regards, > > Anne-Marie > >
Re: Re: kde review kartesio
Hi Luca,
> Yes, the correct way to express a power is ^. So you should write x^2.
I figured that after it had crashed ;)
> There should be a check routine to avoid that a dangerous string like
> "**" is used, and I'm surely integrating this check in the next release.
In my opinion you should not release your application with such an
obvious crash bug. It's not only this expression, the program crashes
whenever there is anything wrong in that text field. That's not
something you can defer to the next release.
> Actually there is not: I'm working on a new window for the next releases:
> basically, there will be a button over the table, something like "Edit datas".
> This will open a new window in which it will be possible to import/export CSV,
> sort X axis values, add other rows or deleting some...
I don't know if it makes sense, but you should have a look at the
calligra sheets part (aka talk to someone who knows about it).
Eventually that can be very useful for this purpose (unfortunately I
don't know exactly how they work).
> Could this instruction be shorter and more elagant? Probably. But it works,
> and actually I think it could stay as it is.
You could replace a 2000+ character boolean logic expression which
lists all the letters in the alphabet by this:
c.isLetter() || QString("+-*/^").contains(c)
at least assuming you do the other thing I said and use QString
instead of char*.
This is a cleanup which is worth doing.
> I know it, I'll try to make the code more readable, but I do not have so much
> time so usually I prefer to dedicate my time to new features or corrections
> instead of making them prettier.
Writing correctly formatted code is mostly a matter of setting up your
editor correctly. Spend five minutes doing that ;)
Greetings,
Sven
Re: kde review kartesio
Hey!
A good thing, I think such a tool could be useful to me too (and I
know a lot of other people to whom it might be useful). Here's what I
noticed from a quick look (some has been said already I think):
* You probably shouldn't track the kdev4 file in the repository, same
goes for screenshots
* zorbaneural is a very fancy dependency, it's not even in arch's AUR.
You should put the git URL into the cmake message.
* I put x**2 into the fit box and clicked Fit, and it crashed:
http://paste.kde.org/741026/
* Did you think about laying out the UI around a splitter? On my
screen, the table takes most of the area and the plot is quite small,
and I can't change that...
* It would be useful to be able to import data in some way, e.g. from
a CSV file. I don't see a way to get data into the program except
typing every number into the cells -- or is there another way? If
there is, could it be made more obvious eventually?
* What does the code in calculations.cpp:117 do? It looks quite
curious. Isn't there a more elegant solution (it looks a bit like a
QChar::isLetter() implementation)?
* calculations.cpp:505 and 584 the same code like in 117 again? It's
weird enough to have that stuff once, but copied multiple times is bad
imho ;)
* Your code uses mixed tab- and space indent (sometimes it uses tabs,
sometimes spaces for no apparent reason). Most KDE apps use only
spaces, you might consider if you want to do that too. Sometimes, the
indent is even missing completely; you should indent one level after
each opening curly parenthesis.
* Same goes for the whole formatting of the code, it's pretty
inconsistent. For example, look at the spaces around operators or so.
* Instead of writing to /tmp/kartesiotmp.txt you should probably use
QTempFile. That will also take care of the deleting the temp file when
it gets deallocated so you don't need to exec (scary and
platform-dependent) rm commands.
* calculations.cpp:277 this makes no sense, there's a statement behind
a "return"
In general, you're mixing a lot of plain C / stdlib stuff into Qt
code. Is there a reason for that? For example, in calculations.cpp:148
you take text from a text field, convert it to a byte array, convert
it to a char* and then pass it to a function. Why not just pass the
QString? You can iterate over a QString like
foreach ( const QChar& c, myqstring ) { ... }
or also
for ( int i = 0; i < myqstring.size(); i++ ) { ... }
if you like that better, and you can also index it like a char*, as in
mystring[i+1] or so.
Also, nothing in your code is const and everything is public, although
almost everything could be const and private, but I won't get started
on that now ;)
This is not meant as a list of what you must fix, it's just my two cents.
Cheers!
Sven
2013/5/10 Tomaz Canabrava :
> Annma, I find that proposal *very* good.
>
> I'm a bit distant of KDE programming - I know - because my day job is making
> me work 12h+ creating scientific tools.
> ( actually - one of the tools that I created here was a... Solver, to fit
> curves on points... )
>
> Tomaz
>
>
> 2013/5/10 David Edmundson
>>
>> The app sounds awesome.
>>
>> From the application life cycle page you linked:
>> > When you have made one of more releases and want to continue to develop
>> > it, the term 'playground' does no longer apply to you. That is the right
>> > time to move out of here
>>
>> There are no releases on download.kde.org under unstable. Have you
>> made these releases elsewhere? If so can you provide a link.
>>
>> Thanks
>>
>> David Edmundson
>
>
Re: Review Request 110266: Cleanp Places Panel context menu
> On May 2, 2013, 10:15 a.m., Heiko Tietze wrote: > > Of course the changes do improve the menu and I believe your proposal would > > be helpful. > > > > But I would like to discuss the following points: > > > > * Adding a header to menus is not commonly used. And I'm not sure why I > > need to know where I have clicked right now. Relating to design: icons with > > varying indent make visual noise. > > * 'Hide' is applied per checkbox, i.e. the action will be executed later > > (or in respect to the "Show all" checkbox). Strange behaviour. > > * 'Edit...': Do I edit the label (usually a rename action via F2), or do I > > edit the reference/link (trash://), or do I edit the appearance of the > > item? And the dots (aka ellipsis) points to additional input that will get > > requested from the user in a dialog shown after click on the item. Strange > > again because it's easier to remove a bookmark and add it again. Managing > > bookmarks relates to sorting, grouping, naming, etc. > > * "Add entry..." Same problem with ellipsis. > > * Placing the generic items at the end is a good idea. But do novices or > > even non-experts know how where to find those important information? > > > > What we need is a styleguide that applies to all KDE applications. It > > defines not only how menus look like but as well when items are disabled or > > hidden, for instance, how to deal with standard functions, and how to label > > stuff - all in general. And we need to have specific guidelines for the > > application itself. That means which function is provided and why, who uses > > it and in which situation, how does it fit into general look and feel, and > > so on. For instance: "The panel Places provides bookmarks for fast access > > to user defined folders. Users can add bookmarks either per drag and drop > > or per menu. Items can be removed, renamed, and resorted. The list of > > bookmarks follow the visual guideline of lists with medium length." > > (incomplete example, just for illustration of the idea) > > > > Following this, either 'trash' and 'removable media' should be moved into a > > different panel unless user copy the item into the Places panel (which > > makes the actual dropdown menu very simple) or the requirements need > > overhaul. > > Kai Uwe Broulik wrote: > > * Adding a header to menus is not commonly used. > I know, but now the item name is no longer thrown at your face but you > have to actually remember where you clicked. And the menu looks like a neat > solution for that, and the menu doesn't look so tiny then, also. It's done > for toolbar items context menus as well. > > > * 'Hide' is applied per checkbox, i.e. the action will be executed > later > I dislike toggle actions, that change their name, ie. "Hide" and then it > will become "Show". A checkbox imho is a totally valid thing for this. When I > uncheck the "Show Toolbar" or "Show Menu" actions, they're also applied > immediately and say "Show" all the time. And this is a common component/part > in all of KDE > > > * 'Edit...': Do I edit the label […] or […] reference/link […] or […] > appearance of the item? > Umm … really? … They only thing I could expect is it showing the actual > target's properties (ie. the folder it is pointing to itself) but the other > things are not something I would expect. > > > * 'Add entry...' umm, the application indeed wants further input from > me, the place name, URL and icon, that is. > > > * Placing the generic items at the end is a good idea. > Nothing I've done on purpose, just happened incidentally. > > > What we need is a styleguide that applies to all KDE applications. > Yup, every major OS/UI (Win, OS X, Gnome, …) have a huge illustrated > styling guide with lots of Do's and Dont's > > > Following this, either 'trash' and 'removable media' should be moved > into a different panel > Umm … Trash is something that's hard to access otherwise because it's not > a really "physical" folder. Have you had a look at Dolphin's Places bar? > There is a clear separation between Places (directories) and Devices > (Bluetooth devices, removable media, …) How about having an extra "Add entry" button at the bottom of the list? That's what would be most intuitive for me (and the easiest to use, too). Right-clicking an existing entry to add a new one... I don't know. Not incredibly obvious from my perspective. - Sven --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110266/#review31877 --- On May 2, 2013, 8:05 a.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110266/ > -
Re: kdev-python move to extragear -- once more
Hi, kdev-python has been moved to extragear. https://projects.kde.org/projects/extragear/kdevelop/plugins/kdev-python Thank you for your support. Cheers, Sven 2013/4/3 Albert Astals Cid : > El Dimecres, 3 d'abril de 2013, a les 10:53:32, Sven Brauch va escriure: >> Hi list, >> >> kdev-python has been in kdereview for almost four months now, and >> still no decision has been reached. Since I'm the person asking for >> review, I can't decide anything. >> What's the policy for a reviewed application when there's voices for >> and against accepting it? If the application should be rejected, then >> so be it, but you'll have to state that clearly (five persons telling >> me it's good and one person telling me it's not doesn't really allow >> me to take any action). > > 5:1 and the kdevelop people saying yes, that's a yes. > > Move it there. > > Cheers, > Albert > >> >> Somebody has to tell me what to do here, or else nothing will happen. >> >> Cheers, >> Sven
Re: kdev-python move to extragear -- once more
Hi list, kdev-python has been in kdereview for almost four months now, and still no decision has been reached. Since I'm the person asking for review, I can't decide anything. What's the policy for a reviewed application when there's voices for and against accepting it? If the application should be rejected, then so be it, but you'll have to state that clearly (five persons telling me it's good and one person telling me it's not doesn't really allow me to take any action). Somebody has to tell me what to do here, or else nothing will happen. Cheers, Sven
Re: Review Request 109568: GHNS3: If the provider file lists a "register account" URL, provide a link to that in the upload dialog
> On March 22, 2013, 5:38 p.m., Laurent Montel wrote: > > For me seems good. > > Regards Sorry to annoy you again ;) just to make sure, I'd push this to kdelibs master now, ok? I hope nobody will mind the increase in the required attica version... - Sven --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/#review29732 --- On March 22, 2013, 11:31 a.m., Sven Brauch wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109568/ > --- > > (Updated March 22, 2013, 11:31 a.m.) > > > Review request for Attica, kdelibs and Jeremy Paul Whiting. > > > Description > --- > > When the provider file lists an URL to register a new account, this patch > adds a link to the login screen of the upload dialog which enables a user to > register a new account. > > This patch depends on https://git.reviewboard.kde.org/r/109567/. > > > Diffs > - > > CMakeLists.txt b116f50 > knewstuff/knewstuff3/uploaddialog.h 3f58f7d > knewstuff/knewstuff3/uploaddialog.cpp 922469e > knewstuff/knewstuff3/uploaddialog.ui aa54d2b > knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 > > Diff: http://git.reviewboard.kde.org/r/109568/diff/ > > > Testing > --- > > > Thanks, > > Sven Brauch > >
Re: Review Request 109568: GHNS3: If the provider file lists a "register account" URL, provide a link to that in the upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/ --- (Updated March 22, 2013, 11:31 a.m.) Review request for Attica, kdelibs and Jeremy Paul Whiting. Changes --- Increase required attica version to 0.4.2 see commit 7f43cb97 in attica. Description --- When the provider file lists an URL to register a new account, this patch adds a link to the login screen of the upload dialog which enables a user to register a new account. This patch depends on https://git.reviewboard.kde.org/r/109567/. Diffs (updated) - CMakeLists.txt b116f50 knewstuff/knewstuff3/uploaddialog.h 3f58f7d knewstuff/knewstuff3/uploaddialog.cpp 922469e knewstuff/knewstuff3/uploaddialog.ui aa54d2b knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 Diff: http://git.reviewboard.kde.org/r/109568/diff/ Testing --- Thanks, Sven Brauch
Re: Review Request 109568: GHNS3: If the provider file lists a "register account" URL, provide a link to that in the upload dialog
> On March 22, 2013, 6:20 a.m., Laurent Montel wrote: > > You need to increase attica version and make kdelibs depends against it. > > Otherwise it will not compile. > > We can't depends against git master version, we must have a official release > > regards. Ah, yes. So, I would increase attica's version from 0.4.1 to 0.4.2 and make kdelibs master depend on that? - Sven --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/#review29671 --- On March 18, 2013, 5:41 p.m., Sven Brauch wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109568/ > --- > > (Updated March 18, 2013, 5:41 p.m.) > > > Review request for Attica, kdelibs and Jeremy Paul Whiting. > > > Description > --- > > When the provider file lists an URL to register a new account, this patch > adds a link to the login screen of the upload dialog which enables a user to > register a new account. > > This patch depends on https://git.reviewboard.kde.org/r/109567/. > > > Diffs > - > > knewstuff/knewstuff3/uploaddialog.h 3f58f7d > knewstuff/knewstuff3/uploaddialog.cpp 922469e > knewstuff/knewstuff3/uploaddialog.ui aa54d2b > knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 > > Diff: http://git.reviewboard.kde.org/r/109568/diff/ > > > Testing > --- > > > Thanks, > > Sven Brauch > >
Re: Review Request 109568: GHNS3: If the provider file lists a "register account" URL, provide a link to that in the upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/#review29639 --- The patch to attica, which is needed by this, has been submitted now. - Sven Brauch On March 18, 2013, 5:41 p.m., Sven Brauch wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109568/ > --- > > (Updated March 18, 2013, 5:41 p.m.) > > > Review request for Attica, kdelibs and Jeremy Paul Whiting. > > > Description > --- > > When the provider file lists an URL to register a new account, this patch > adds a link to the login screen of the upload dialog which enables a user to > register a new account. > > This patch depends on https://git.reviewboard.kde.org/r/109567/. > > > Diffs > - > > knewstuff/knewstuff3/uploaddialog.h 3f58f7d > knewstuff/knewstuff3/uploaddialog.cpp 922469e > knewstuff/knewstuff3/uploaddialog.ui aa54d2b > knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 > > Diff: http://git.reviewboard.kde.org/r/109568/diff/ > > > Testing > --- > > > Thanks, > > Sven Brauch > >
Re: kdev-python move to extragear -- once more
Hi, my patch to python [1] was merged recently, so I could start working on porting kdev-python away from the python fork. [2] is a branch which is up-to-date with master and works without the fork, it just links against the system's python 3.4. It's not perfect yet, but neither was the old python 3 support branch. As soon as Python 3.4 is released, this brach will be the default. Since the patch contains (binary and source) incompatible changes, it cannot be backported to python 2. Thus, the python 2 version of the plugin will have to stay with the fork for the remainder of its lifetime. It's not going to get much better than this. If we can't move this to extragear now, then I don't see why we could do it anywhere in the near future. Also there's really nothing more I can do about it now. Please let me know what you think. Greetings, Sven __ [1] http://hg.python.org/cpython/rev/7c5c678e4164 [2] https://projects.kde.org/projects/kdereview/kdev-python/repository/show?rev=python3-nofork
Review Request 109568: GHNS3: If the provider file lists a "register account" URL, provide a link to that in the upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/ --- Review request for Attica, kdelibs and Jeremy Paul Whiting. Description --- When the provider file lists an URL to register a new account, this patch adds a link to the login screen of the upload dialog which enables a user to register a new account. This patch depends on https://git.reviewboard.kde.org/r/109567/. Diffs - knewstuff/knewstuff3/uploaddialog.h 3f58f7d knewstuff/knewstuff3/uploaddialog.cpp 922469e knewstuff/knewstuff3/uploaddialog.ui aa54d2b knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 Diff: http://git.reviewboard.kde.org/r/109568/diff/ Testing --- Thanks, Sven Brauch
Re: Review Request 109421: Support custom providers in the GHNS upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109421/ --- (Updated March 14, 2013, 3:24 p.m.) Review request for kdelibs and Jeremy Paul Whiting. Changes --- Hey Jeremy, cool, thanks. The patch I proposed doesn't do that, it just adds the provider file to the default files. I agree though that the better behavior would be only to show the new file then. Since I'm not entirely sure if I did that correctly, I'll update the patch once more -- if you don't see a problem with it, should I just push it to kdelibs master? Cheers, Sven Description --- The download dialog correctly takes a custom providers .xml file, as can be specified in the .knsrc file, into account; however the upload dialog just ignored this option until now. This patch intends to fix that behavior. Nothing should change if you don't have a custom ProvidersUrl= in your .knsrc file. Diffs (updated) - knewstuff/knewstuff3/upload/atticahelper.h 4e538d3 knewstuff/knewstuff3/upload/atticahelper.cpp 735910f knewstuff/knewstuff3/uploaddialog.cpp 70a8568 knewstuff/knewstuff3/uploaddialog_p.h 50f8dd9 Diff: http://git.reviewboard.kde.org/r/109421/diff/ Testing --- The new provider is correctly being listed in the dropdown list of the first page of the dialog. If the custom provider is selected, the program tries to establish a connection to that provider. However, I could not test it any further because I don't have a working provider server... yet. File Attachments a screenshot of the dialog showing two providers, one of them loaded from the XML file specified in .knsrc http://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png Thanks, Sven Brauch
Re: Review Request 109421: Support custom providers in the GHNS upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109421/#review29158 --- One thing which came to my mind while I further worked on this, should the custom providers be added to the list, or replace it? I.e., if I have custom providers listed, should the default ones still be displayed or not? - Sven Brauch On March 11, 2013, 11:34 p.m., Sven Brauch wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109421/ > --- > > (Updated March 11, 2013, 11:34 p.m.) > > > Review request for kdelibs and Jeremy Paul Whiting. > > > Description > --- > > The download dialog correctly takes a custom providers .xml file, > as can be specified in the .knsrc file, into account; however the > upload dialog just ignored this option until now. This patch > intends to fix that behavior. > Nothing should change if you don't have a custom ProvidersUrl= in your > .knsrc file. > > > Diffs > - > > knewstuff/knewstuff3/upload/atticahelper.h 4e538d3 > knewstuff/knewstuff3/upload/atticahelper.cpp 735910f > knewstuff/knewstuff3/uploaddialog.cpp 70a8568 > knewstuff/knewstuff3/uploaddialog_p.h 50f8dd9 > > Diff: http://git.reviewboard.kde.org/r/109421/diff/ > > > Testing > --- > > The new provider is correctly being listed in the dropdown list of the first > page of the dialog. If the custom provider is selected, the program tries to > establish a connection to that provider. However, I could not test it any > further because I don't have a working provider server... yet. > > > File Attachments > > > a screenshot of the dialog showing two providers, one of them loaded from the > XML file specified in .knsrc > > http://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png > > > Thanks, > > Sven Brauch > >
Re: kdev-python move to extragear -- once more
Hi, >> And the rest of the Python library API, like the stuff in Python/* and >> Object/*? > Those aren't being used. Only the parser is used. I'm sorry, I forgot that the AST stuff is in Python/ (it has been a while). So, the ast-related stuff from Python/ is being used too. Thus, diffing Parser/ was not correct, I apologize. Still, the point that only few of the code paths python has are actually used by the plugin remains valid, since only the "parse string to ast" step is being done, but neither "compile ast to bytecode" nor "execute bytecode" step, which account for large parts of python's complexity. > Afaik: That is semantically analized to extract information like > documentation, code completion information etc. pp. Comparable to > phpfunctions.php in the kdev-php plugin. > Sven, can you confirm that? No, they are not being analyzed, it's just difficult to rip them out of python so they're still there. > I thought the big concern here is security? Any "mundane" bugs like leaks etc. > pp. don't need to be any of your concern here, or? I mean assuming Sven > updates the checkout regularily these will be fixed eventually. I'd simply see > it as a bug in kdev-python. And comparing that to the amount of bugs you'd get > by writing your own python parser it is probably a good pick. This is the real point in my opinion, yes. Writing a custom parser will have a much larger amount of exploitable bugs for years to come than the python 2.7 parser currently has. Thus, I don't really get the "security" argument. Plus, if crtical flaws should really turn up (a situation which I still consider somewhat theoretical), I would of course take care of merging the relevant patches. > "people will package it" is not really an excuse for "allow broken > ways". But "it could potentially cause extra work for the packagers" is the only argument against the fork I heard so far which I can agree with. That's why I said that. > (And WTF does it mean «I just wished you would list reasons I could > agree with», that my reasons are valid as long as you agree with them?) No, it just means I'm somewhat unhappy with the reasons you listed since I don't agree with them. In other words, I'll have to accept them as reasons why to reject the application altough I don't share your opinion, and that's bad for me. > Bugs, leaks, and any kind of issue don't need to "affect kdev-python" to > be problematic. Why? If such an issue is in a code path which is never used by kdev-python, it doesn't matter. Which will be like, most issues, because the whole stuff that actually compiles and runs python code is not being used by kdev-python. Also, memory leaks in Python? Python is like this (when executing a non-trivial script): definitely lost: 0 bytes in 0 blocks indirectly lost: 0 bytes in 0 blocks Plus, any leak would be free'd after the parse step anyways, which takes like 0.3 seconds. About bugs, what kind of bugs are you thinking of? In the worst case, it'll just be a crash bug in kdev-python, which is entirely my problem. Additionally, crash bugs in the python *parser* is something that realistically doesn't exist, especially not to an extent I or kdevelop should care about, given the amount of crash bugs we have ourselves. I just want to emphasize this again: During the time I'm working on kdev-python, I will *never* be able to write a parser which is comparably secure and bug-free to the current solution with the fork. > Assuming you need to cherry-pick later some bugfix from python 2.7.x, > what do you do if that backporting cannot be done because the code has > changed in the meanwhile, and your code is still years behind? Sorry, I'm not sure I understand what you mean -- who would do the cherry-pick? Also, I want to repeat that I already contacted the python people, and that it's very likely that the issue causing the patch will be resolved upstream. Thus, with the release of python 3.4, the fork would disappear anyways. (backporting is not possible since the patch involves binary incompatible changes) Best regards, Sven 2013/3/12 Todd : > On Tue, Mar 12, 2013 at 10:57 AM, Pino Toscano wrote: >> >> Hi, >> >> Alle sabato 9 marzo 2013, Sven Brauch ha scritto: >> > considering kdev-python is only using the Parser part of python, this >> > is actually all that has changed in the two years between 2.7.1 and >> > 2.7.3: >> > http://paste.kde.org/691184/ >> > As far as I can see, there's not a single change which would affect >> > the behavior of kdev-python in any way. And I do not expect such >> > changes to happen in further maintenance releases -- after all, >> > they're maintenance releases for fixing bugs, and the Python 2.7 >> > *parser* code does not exactly have hundreds of bugs. And, since >> > Python 2 is dead anyways, no non-maintenance releases are going to >> > happen. >> >> And the rest of the Python library API, like the stuff in Python/* and >> Object/*? > > > Those aren't being used. Only the parser is used.
Re: Review Request 109421: Support custom providers in the GHNS upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109421/ --- (Updated March 11, 2013, 11:34 p.m.) Review request for kdelibs and Jeremy Paul Whiting. Description --- The download dialog correctly takes a custom providers .xml file, as can be specified in the .knsrc file, into account; however the upload dialog just ignored this option until now. This patch intends to fix that behavior. Nothing should change if you don't have a custom ProvidersUrl= in your .knsrc file. Diffs - knewstuff/knewstuff3/upload/atticahelper.h 4e538d3 knewstuff/knewstuff3/upload/atticahelper.cpp 735910f knewstuff/knewstuff3/uploaddialog.cpp 70a8568 knewstuff/knewstuff3/uploaddialog_p.h 50f8dd9 Diff: http://git.reviewboard.kde.org/r/109421/diff/ Testing --- The new provider is correctly being listed in the dropdown list of the first page of the dialog. If the custom provider is selected, the program tries to establish a connection to that provider. However, I could not test it any further because I don't have a working provider server... yet. File Attachments a screenshot of the dialog showing two providers, one of them loaded from the XML file specified in .knsrc http://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png Thanks, Sven Brauch
Review Request 109421: Support custom providers in the GHNS upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109421/ --- Review request for kdelibs. Description --- The download dialog correctly takes a custom providers .xml file, as can be specified in the .knsrc file, into account; however the upload dialog just ignored this option until now. This patch intends to fix that behavior. Nothing should change if you don't have a custom ProvidersUrl= in your .knsrc file. Diffs - knewstuff/knewstuff3/upload/atticahelper.h 4e538d3 knewstuff/knewstuff3/upload/atticahelper.cpp 735910f knewstuff/knewstuff3/uploaddialog.cpp 70a8568 knewstuff/knewstuff3/uploaddialog_p.h 50f8dd9 Diff: http://git.reviewboard.kde.org/r/109421/diff/ Testing --- The new provider is correctly being listed in the dropdown list of the first page of the dialog. If the custom provider is selected, the program tries to establish a connection to that provider. However, I could not test it any further because I don't have a working provider server... yet. File Attachments a screenshot of the dialog showing two providers, one of them loaded from the XML file specified in .knsrc http://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png Thanks, Sven Brauch
Re: kdev-python move to extragear -- once more
Hi Pino, considering kdev-python is only using the Parser part of python, this is actually all that has changed in the two years between 2.7.1 and 2.7.3: http://paste.kde.org/691184/ As far as I can see, there's not a single change which would affect the behavior of kdev-python in any way. And I do not expect such changes to happen in further maintenance releases -- after all, they're maintenance releases for fixing bugs, and the Python 2.7 *parser* code does not exactly have hundreds of bugs. And, since Python 2 is dead anyways, no non-maintenance releases are going to happen. If it was only about this -- I could easily keep the fork updated with the 2.7.x releases. But, as said, I don't really see a point, since it's not going to affect kdev-python anyways. I see even less reason for why anyone other than me should ever want to do such an update, since it will most likely be a) irrelevant for kdev-python or b) do some changes which would actually affect kdev-python, but would then need updates to kdev-python itself since it's very tightly integrated with the parser code. Still, altough I don't agree with the two points you raised, I see your overall problem with this, and you can rest assured that I'm very much interested in getting the fork removed as soon as possible too (see my previous emails). So, if this is your last word, I'm going to move kdev-python back to playground, wait for the Python 3.4 release, and start the whole review process once again. It's not really going to change much -- most distributions will still package kdev-python and the fork is not going to be removed any sooner. It's just a bit more annoying. I'm not angry or anything, after all this is a review and if there was no negative outcomes then it would be pretty pointless. I just wished you would list reasons I could agree with -- there's the general "a fork is a horrible solution", which I totally agree with, but which is a rather philosophical point. I'm still missing an example of a real world situation where this fork specifically would be a problem. Best regards, Sven 2013/3/9 Pino Toscano : > Hi, > > Alle sabato 16 febbraio 2013, Sven Brauch ha scritto: >> A while ago, I asked for a review of kdev-python, in order for it to >> be moved from playground to extragear. There was some (legitimate) >> objection about the fork of the python parser code the plugin >> contains, which is why the move has not taken place yet, and >> kdev-python is still residing in kdereview. >> >> I'm actively working on solving the issue -- chances that a patch can >> be applied upstream which enables me to drop the fork are good. [1] >> (This would however only apply to future releases of the python 3 >> version of the plugin, since the patch introduces binary-incompatible >> changes upstream which cannot be backported to python 2.) >> >> Thus, I would suggest to move kdev-python to extragear, even if the >> issue is not solved yet. >> If you disagree, let me know, in that case I must move kdev-python >> back to playground and propose it for review again once the fork has >> been removed from the master branch. I would however prefer not to do >> this. > > Considering the libpython fork in kdevpython is: > a) outdated (it is forked from python 2.7.1, current 2.7 is 2.7.3); >considering 2.7.1 has been released on 27/10/2010 and 2.7.3 on >9/4/2012, this means it is one years and half behind fixes and >improvements of any kind > b) modified (so it is not totally pristine sources which can be updated >from upstream sources, if needed) > > this situation still makes me put -1 on this, sorry. > > I can understand it can seem frustrating having this kind of situation, > but as both KDE developer and distro (Debian) developer I cannot find > acceptable letting yet another case of embbeded code copy [1] in a new > "extragear" software, yet more so when the software copied is something > critical as python. As said in previous emails, this would put a non- > trivial burden over packagers (and potentially also over self-compiling > users). > > [1] OTOH you are not the only one -- hello Gilles Caulier! > > -- > Pino Toscano
Re: kdev-python move to extragear -- once more
Hey, this is still not resolved. If I'm not hearing any objection soon-ish, then I'll assume you're okay with moving kdev-python to extragear, and continue working on the python fork issue from there. Python 3.4 is scheduled for early 2014, and I think the python people's idea of merging my patch is "somewhere before the feature freeze for this release", so it might take a while -- far too long to keep kdev-python stuck in kdereview. Cheers, Sven 2013/2/16 Sven Brauch : > Hello, > > A while ago, I asked for a review of kdev-python, in order for it to > be moved from playground to extragear. There was some (legitimate) > objection about the fork of the python parser code the plugin > contains, which is why the move has not taken place yet, and > kdev-python is still residing in kdereview. > > I'm actively working on solving the issue -- chances that a patch can > be applied upstream which enables me to drop the fork are good. [1] > (This would however only apply to future releases of the python 3 > version of the plugin, since the patch introduces binary-incompatible > changes upstream which cannot be backported to python 2.) > > Thus, I would suggest to move kdev-python to extragear, even if the > issue is not solved yet. > If you disagree, let me know, in that case I must move kdev-python > back to playground and propose it for review again once the fork has > been removed from the master branch. I would however prefer not to do > this. > > Thanks and best regards, > Sven Brauch > > __ > [1] http://bugs.python.org/issue16795
kdev-python move to extragear -- once more
Hello, A while ago, I asked for a review of kdev-python, in order for it to be moved from playground to extragear. There was some (legitimate) objection about the fork of the python parser code the plugin contains, which is why the move has not taken place yet, and kdev-python is still residing in kdereview. I'm actively working on solving the issue -- chances that a patch can be applied upstream which enables me to drop the fork are good. [1] (This would however only apply to future releases of the python 3 version of the plugin, since the patch introduces binary-incompatible changes upstream which cannot be backported to python 2.) Thus, I would suggest to move kdev-python to extragear, even if the issue is not solved yet. If you disagree, let me know, in that case I must move kdev-python back to playground and propose it for review again once the fork has been removed from the master branch. I would however prefer not to do this. Thanks and best regards, Sven Brauch __ [1] http://bugs.python.org/issue16795
Re: Review of kdev-python for move to extragear
I raised the issue on python-dev again, let's see what happens. In case they accept this then at least for the python 3 version the python fork could be removed after a few changes on my side (for python 2 it would have to stay, but python 2 is legacy stuff anyways, and updates to both my and the python code will happen rarely (if ever)). Here's the thread: http://mail.python.org/pipermail/python-dev/2012-December/123320.html Greetings, Sven 2012/12/26 Sven Brauch : > 2012/12/26 Ben Cooksley : >> I see in that bug report that this was supposed to be referred to a >> Python development mailing list as a result of the objections of a >> single person in that bug. What was the result of that? > > Hello! > > Nothing, it just died. Here is the thread: > http://mail.python.org/pipermail/python-dev/2010-December/107009.html > > Cheers, > Sven
Re: Review of kdev-python for move to extragear
2012/12/26 Ben Cooksley : > I see in that bug report that this was supposed to be referred to a > Python development mailing list as a result of the objections of a > single person in that bug. What was the result of that? Hello! Nothing, it just died. Here is the thread: http://mail.python.org/pipermail/python-dev/2010-December/107009.html Cheers, Sven
Re: Review of kdev-python for move to extragear
2012/12/26 Sune Vuorela : > On 2012-12-25, Sven Brauch wrote: >> Also, I'm still not sure what exactly concerns you about security and >> maintenance. Problems I see include increased build time, and >> maintenance efforts for me personally in updating the fork, but none >> really seem fatal. Can you elaborate a bit about which problems you > > One of the problems are that in a distribution like debian and/or > ubuntu has around 60-70 patches against python2.7 to ensure it builds > and works everywhere. > All these patches might also be needed the extra copy - and given the > extra copy is modified, then these patches might need to be adapted. > > Another of the problems is that if there is a security bug in libpython, > then instead of just doing a security fix to python, one also needs to > do one to kdev-python. > > The first problem is large amount of work for the distribution > packagers, and the second problem is quite annoying for distribution > security teams. > > All of this applies to every embedded library. And python is a quite big > thing. > > /Sune Hi, kdev-python does not really ship with a custom version of python which is used for various things; for example the interpreter or even standard library is not being used. Only the parser code from the libpython.so library is being called, everything else is just there as basically a build dependency for the parser stuff. Thus, the chances of it not working somewhere (due to path problems, runtime dependencies, ...) are hopefully slim. How often is there security bugs in parser code? I don't know, but I'd guess it's not something that happens every other day. For security issues anywhere else (e.g. standard library modules such as xml parser stuff or whatever), they don't really matter since they can't ever be executed. I do agree that the soluton is not very elegant at any rate, but I'm still very much at loss for a better idea. If anyone can come up with something good, I'd spend the time to change it, but writing a custom parser... phew. Greetings, Sven
Re: Review of kdev-python for move to extragear
2012/12/25 Pino Toscano : > Hi, > > (please do not top-post, thanks.) > > Alle venerdì 21 dicembre 2012, Sven Brauch ha scritto: >> the two-week review period for this project (kdev-python) has passed. >> The only complaint raised was related to the python fork in the >> repository. Was the necessarity of this sufficiently explained by my >> follow-up email, or does anyone think this issue needs further >> discussion? > > I still think the modified copy of the python sources is really a bad > idea, from both a security and a maintaineance points of view, and thus > it gets my -1. > > -- > Pino Toscano Hi, Alright, so what do you suggest? The only way I see to avoid a fork currently would be writing a custom parser. That's a huge effort with questionable effect on the resulting product which I'd rather not take. Also, I'm still not sure what exactly concerns you about security and maintenance. Problems I see include increased build time, and maintenance efforts for me personally in updating the fork, but none really seem fatal. Can you elaborate a bit about which problems you expect in particular? Maybe we can discuss whether they're really fatal or what could be done to avoid them then. Best regards, Sven
Re: Review of kdev-python for move to extragear
Hi, since there were no further questions or complaints, I will consider kdev-python to have passed the review process now. Thanks! Greetings, Sven 2012/12/21 Sven Brauch : > Hello, > > the two-week review period for this project (kdev-python) has passed. > The only complaint raised was related to the python fork in the > repository. Was the necessarity of this sufficiently explained by my > follow-up email, or does anyone think this issue needs further > discussion? > > Best regards, > Sven > > 2012/12/7 Laszlo Papp : >> On Fri, Dec 7, 2012 at 12:09 PM, Milian Wolff wrote: >>> >>> On Friday 07 December 2012 06:01:19 Laszlo Papp wrote: >>> > > Out of the curiosity: how much python3 is available? Thank you for >>> > > your >>> > > work. >>> > >>> > python3 _support_ >>> >>> please read http://scummos.blogspot.de/2012/11/kdev-python-14-stable- >>> released.html >>> >>> 1.5 will get python3 support >> >> >> Thank you. >> >> Laszlo
Re: Review of kdev-python for move to extragear
Hello, the two-week review period for this project (kdev-python) has passed. The only complaint raised was related to the python fork in the repository. Was the necessarity of this sufficiently explained by my follow-up email, or does anyone think this issue needs further discussion? Best regards, Sven 2012/12/7 Laszlo Papp : > On Fri, Dec 7, 2012 at 12:09 PM, Milian Wolff wrote: >> >> On Friday 07 December 2012 06:01:19 Laszlo Papp wrote: >> > > Out of the curiosity: how much python3 is available? Thank you for >> > > your >> > > work. >> > >> > python3 _support_ >> >> please read http://scummos.blogspot.de/2012/11/kdev-python-14-stable- >> released.html >> >> 1.5 will get python3 support > > > Thank you. > > Laszlo
Re: Review of kdev-python for move to extragear
Hi! Yeah, basic python3 support is there (syntax works) but not all the features are handled correctly, e.g. nonlocal is not implemented yet etc. As milian already said, for 1.5 there will probably be two versions, a python 2 and a python 3 one. Most of the development from now on will happen for python 3. Greetings, Sven 2012/12/7 Milian Wolff : > On Friday 07 December 2012 06:01:19 Laszlo Papp wrote: >> > Out of the curiosity: how much python3 is available? Thank you for your >> > work. >> >> python3 _support_ > > please read http://scummos.blogspot.de/2012/11/kdev-python-14-stable- > released.html > > 1.5 will get python3 support > -- > Milian Wolff > m...@milianw.de > http://milianw.de
Re: Review of kdev-python for move to extragear
Hello! Unfortunately, I don't think it's possible to use an external version of python. The official parser does not provide some of the information which is required for proper static analysis; upstream refused to accept my patches changing what would have been needed to make it work (see http://bugs.python.org/issue10769). Stripping the parser out of the python package is very difficult, since it relies on PyObject data structures. Writing (and maintaining!) a custom parser would mean far more trouble than updating this one. Security fixes to the *parser* should be extremely rare. Other fixes are not relevant, since none of the runtime stuff is actually being used by kdev-python (just the parser). Greetings, Sven 2012/12/6 Pino Toscano : > Alle giovedì 6 dicembre 2012, Sven Brauch ha scritto: >> If you find any issues, please tell me so I can fix them as quickly >> as possible. > > The embedded (and modified) copy of python 2.7.1 does not seem a good > idea... is there *really* no way to use an external (lib)python? > It seems python gets some CVE from time to time, so this would impose an > extra burden on packagers (and self-compiling users which need to patch > and upgrade on their own). > > -- > Pino Toscano
Review of kdev-python for move to extragear
Hi! For quite exactly two years I have been working on integrating the Python scripting language into KDevelop. Recently this project, called kdev-python, has seen its first stable release (called 1.4 in order to match kdevplatform version numbers). The release seems to be successful so far, no crashes or grave bugs have surfaced yet. Of course there is a lot of nice-to-have functionality missing, but especially for developing PyQt / PyKDE applications, kdev-python provides a very usable development tool already. I intend to further maintain and improve the program in the future. Thus, I would like to request moving the project from the "playground" to the "extragear" repository. This email is supposed to be the formal announcement for the required two-week review period. The source code of the plugin can be found at https://projects.kde.org/projects/kdereview/kdev-python or obtained from git by running git clone git://anongit.kde.org/kdev-python If you find any issues, please tell me so I can fix them as quickly as possible. Thanks and best regards, Sven
