Re: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems
On Mon, Jan 20, 2014 at 02:40:17PM -0800, Thiago Macieira wrote: > If we changed the default, it would mean ~/.xsession-errors would probably > become rather empty. Is that ok for KDE? Considering how poor discoverability ~/.xsession-errors has (it took me many years until I discovered it) I think this is a really good idea. It would also be nice to see a KDE/Qt UI frontend to journald eventually. -- Martin Sandsmark
Re: Moving Baloo forward
On Tuesday 21. January 2014 16.04.51 Vishesh Handa wrote: > Well, anything is possible. Someone would just need to implement it. We had > wanted to do something similar during the Nepomuk days as well, but it > didn't quite materialize. Point me to roughly where in the stack to implement it, and I'll look into implement support for multimedia files. :-) -- Martin Sandsmark
Re: Moving Baloo forward
On Tuesday 21. January 2014 14.54.39 Thomas Lübking wrote: > I *do* consider xattr the BY FAR more sane approach to the problem, but > currently do frankly not see this on end user desktops :-( Luckily, we develop end-user desktops and the people who develop the other parts of this system are normal human beings that we can talk to. I'd suggest using xattrs, and get distro people to start enabling it by default. Other things to do would be to gray out the metadata editing stuff when viewing files on a filesystem without xattrs, with a short explanation, and get kio to warn you when you try to copy files with xattrs to a filesystem that doesn't support xattrs. -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Fri, Jan 30, 2015 at 11:44:22PM -0200, Thiago Macieira wrote: > Many of your complaints about usability (threading, replies, etc.) are solved > or at least partially addressed in the new Gerrit UI, which versions like 2.7 > have. It might not be the default on the installation, so check the settings > and try to turn it on. Do you know of any Gerrit installations that have this enabled? We use Gerrit (2.7) at work, and the UI is still pretty horrible, unfortunately I can't play with the settings (I'm assuming they are some global settings, because I can't find anything for it in my personal settings). I also want to avoid setting up a personal Gerrit installation, it seems pretty painful to install. :-) -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Thu, Jan 29, 2015 at 06:49:28PM +0100, Eike Hein wrote: > I disagree - having the comment in a floating popup instead > of breaking up source code makes it easier to read the code > for me. I just want to back up this point. As mentioned already, we've been using Gerrit at work for quite a while now, and having the code broken up by comments (sometimes many lines in case of a discussion) makes it extremely hard to actually follow the flow of the code. Do you know if upstream would accept to change this, or how hard it would be to change? -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Sat, Jan 31, 2015 at 01:16:05PM +0100, Jan Kundrát wrote: > Your mail suggested that they apparently do not care about improving > their UI, because if they did, they would have solved everything > already. I disagree with that, and provide evidence which supports > the idea that Gerrit upstream in fact also cares about users, > including those who are not already experienced with its UI. I think the point was more that what Gerrit has fixed were simple UI glitches, not "radical" improvements that change the existing design to make it easier for less experienced or casual users (or even experienced users, but that's another discussion). :-) -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Sun, Feb 01, 2015 at 10:49:58AM -0200, Thiago Macieira wrote: > They would have if they still had major problems with the usability of the > tool. It probably just so happens that all the backers are used to the > interface, however bad it might be, and don't feel the need to sponsor such a > work. I think Ben's mail was more about the uncertainty whether this was actually the case (feel free to correct me on this, though). Do you know for a fact that noone has tried to push upstream radical UI changes to improve it, or is that just an assumption? Isn't it also possible that people that find the UI extremely bad haven't simply avoided Gerrit completely, or moved to something that's better? -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Tue, Feb 03, 2015 at 11:55:58AM +0100, Jan Kundrát wrote: > I believe that this is fixed in the new change UI: We use 2.7, which I assume has the new UI. > - The diff viewer shows comments minimized/collapsed and in a way > which consumes less space. Yes, but as I said this doesn't really solve it at all. As I said, for long discussions it still adds a lot of space and noise into the code, which makes following the flow of the code extremely hard to do (at least for me personally, and I suspect others). > - The review page shows file/line/range comments with a pointer to > what file and what part of a file this is about. Still annoying to have to manually go to the source files, and scroll down to the right line. :-) I guess it could be better if it was turned into a link? > Now, one thing which is arguably missing and can be improved is > adding a small chunk of actual file content to the comments shown on > review page. I think that upstream will be happy to accept such a > patch. This would indeed be a big improvement, especially if it has the ability to expand up and down, like in the file diff view (which could also be improved IMHO, clicking the number is not very intuitive at all...). :-) -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Tue, Feb 03, 2015 at 11:46:10AM +0100, Jan Kundrát wrote: > Yes, the one we're testing in KDE is reasonably recent. It lives at > https://gerrit.vesnicky.cesnet.cz/ , and it uses the new change > screen by default. Thanks! And now I see that the source/line from the comments is already a link. :-) IMHO it suffers a bit from information overload and seems generally confusing, but I guess that is solvable with some styling. I see however that most of the small issues with the UI are solved, though, which is very nice, I'll ask for our installation at work to be upgraded. :-) -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Tue, Feb 03, 2015 at 11:58:50AM +0100, Jan Kundrát wrote: > As they completely revamped the change screen UI in 2.8, I do not > think that this point is true, either. It doesn't really seem revamped, mostly just fixing all the glitches, not really changes in the basic assumptions about how it should work or the behaviour? Also adding much more to the already overloaded UI (IMHO). It would have been nice to try to decrease the information overload (collapse/hide stuff by default, for example). I'm not a UI designer, so I'm not exactly sure what the best way to do this is, but there seems to be a lot of information that isn't really necessary for most reviewers (commit hash, parent commit, change-id, commit dates, age, topic strategy, etc.). -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Tue, Feb 03, 2015 at 12:02:40PM +0100, Martin Sandsmark wrote: > Yes, but as I said this doesn't really solve it at all. As I said, for long > discussions it still adds a lot of space and noise into the code, which makes > following the flow of the code extremely hard to do (at least for me > personally, and I suspect others). Disregard my other points, as they were based on faulty assumptions. :-) But this point is still pretty major, IMHO, and I suspect that it is not something that upstream would change easily. But we have had bugs slipping through because of this already (at work), so it's not really something minor IMHO. -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Sat, Jan 31, 2015 at 02:01:22PM +0100, Jan Kundrát wrote: > Due to the nature of build jobs which constitute a pretty bursty > load, renting VMs sounds like a cost-effective approach for our > scale. I do not expect that it would make financial sense for us to > procure enough physical HW to cover the peak demand -- hence the > VMs. But this means that we would be even more dependent on financial donations to be able to keep a functioning infrastructure, if I understand correctly? > Renting VMs also enables corporate sponsors to offer unused capacity for > less money, or even for free. Has anyone been in contact with hosters/providers to see what kind of sponsoring we could get? And it still increases our reliance on sponsors. -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Tue, Jan 27, 2015 at 11:08:49AM +0100, Jan Kundrát wrote: > Gerrit will act as a primary repository host. This will be completely > transparent to the users. Developers who do not want to change their > workflow will witness no user-visible changes. All existing clones will > work, and developers will be able to direct push and bypass code review if > they so choose. So everyone with a KDE account will be able to push to any KDE project, bypassing Gerrit? -- Martin Sandsmark
Re: Another proposal for modernization of our infrastructure
On Tue, Feb 03, 2015 at 12:40:01PM +0100, Mirko Boehm wrote: > 14 messages in 90 minutes on a topic we are discussing for weeks now. > Please realise that that is why people do not engage on this mailing list. > It is not the choice of tools. Sorry for being late to the discussion, but I haven't had time to catch up on this until now, and I brought up issues I believe are important. I would like to spend more time contributing to KDE, and for that I feel that we should have a process that lowers the barrier for doing that (for everyone). I'm also sorry for working in burst-mode, I can slow down if you believe that is better? -- Martin Sandsmark
Re: Help solving this month's "Bug of the Month"
On Wed, Feb 04, 2015 at 04:45:26PM +0100, Christoph Feck wrote: > According to recent comments, this is bug is still reproducible for > some users, but not for others. It is unclear if the actual issue is > in KDE software, Qt libraries, xorg libraries, or the keyboard layout > definition files. >From reading the latest comments on that bug, and the linked Qt bug report, it seems pretty clear-cut to be a Qt bug that's fixed in Qt5, but not in Qt4? So maybe it should just be marked as an upstream bug? -- Martin Sandsmark
Re: Help solving this month's "Bug of the Month"
On Wed, Feb 04, 2015 at 09:51:53PM +0100, Albert Astals Cid wrote: > Even if it's an upstream bug, in my opinion the BugOfTheMonth+GardeningEffort > is showing the users that we care, and if they are affected by a severe bug > we're going to try to make as much as we can to fix it, not just toss it over > the fence and say "it's not us". I agree, with figuring out how it was fixed in Qt5, and backporting it to Qt4. :-) If you believe that keeping the bug in our tracker open will help on the impression to users / tracking it from our side, I agree we should keep it open. :-) -- Martin Sandsmark
Re: Moving akonadi from kdesupport and akonadi-search from playground
On Mon, Jul 20, 2015 at 04:17:16PM +0200, Daniel Vrátil wrote: > We only ported the code to KF5 Unless I'm misunderstanding something, isn't this a quite significant change? >From experience even seemingly simple ports can introduce pretty serious breakage in edge cases. -- Martin Sandsmark
Re: Moving akonadi from kdesupport and akonadi-search from playground
On Mon, Jul 20, 2015 at 05:08:45PM +0200, Daniel Vrátil wrote: > True, although the core code is mostly plain Qt wrapper around Xapian. > We've (me, Laurent and few people on #kontact) been using it for couple > weeks - months now without any problems. Ok, I don't really have any objections. -- Martin Sandsmark
Re: Season of KDE project on speed optimization
On Friday 29. April 2011 12:52:18 Lydia Pintscher wrote: > Aaditya applied for a Season of KDE slot. He wants to work on speed > optimization. Do we have a nice project for him? I don't have any specific projects in mind (maybe someone who has thought more about why KDE is slow than me has something), but I can mentor him. :-) -- Martin T. Sandsmark http://phonon.kde.org/
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sunday 24 July 2011 17:55:54 Giovanni Campagna wrote: > Il giorno dom, 24/07/2011 alle 22.37 +1200, Ben Cooksley ha scritto: > > Wrong, wrong and wrong. > > Phonon backend cannot be configured without System Settings. > And that's a feature, I suppose. As a GNOME user, I want GStreamer at > all times (and as a Fedora user, I can't even install xine). The Xine backend is not maintained anymore, so the choice is between the libvlc backend and gstreamer backend for most users, and many users actually prefer the libvlc backend (for many reasons, none of which are relevant here :-). I am not familiar with what additional restrictions your distro puts on you wrt. multimedia applications, so this might not be relevant to you, though. My two cent is that Gnome should rename it's configuration application to something that reflects what it is, instead of stealing the name from the KDE system configuration application. -- Martin Sandsmark
Re: QtScript considered dangerous
On Thu, May 24, 2012 at 10:59:21AM +0200, Dominik Haumann wrote: > Another question is: Maybe we'll have similar/other issues with kjs? ;) But KJS is maintained and has actual developers you can talk with (even on IRC!). Failing that, it is developed together with the rest of KDE, so you can even fix the bugs yourself instead of having to rely on third-parties. -- Martin Sandsmark
Re: QtScript considered dangerous
On Thu, May 24, 2012 at 11:28:41AM +0200, Thomas Friedrichsmeier wrote: > 1. AFAIR, there are some subtle differences between KJS and QtScript. I'd be > hard pressed to provide an example, but I know for sure that I have run into > some, personally. Some code that worked fine in QtScript did not work for me > in KJS (note: I was using kjsembed via Kross, then). If you could come up with some such examples, maybe we could fix them. :-) Also, KJS has been under active development the whole time, so there is a probability that the problems you were experiencing have already been fixed. > 1b. While, certainly, any such incompatibilities could easily be addressed > inside the Kate code base, keep in mind that a switch of engine could also > cause trouble for users' custom scripts. But this is something we can fix in KJS, both since it is actively maintained, and it is developed together with Kate. I'm not saying I can guarantee that there won't be any regressions or incompatibilities, but I think the gain (not crashing in a huge codebase out of our reach) outweighs the possible, but fixable, regressions. > 1c. Even if the above incompatibilities were a mere figment of my > imagination, > KJS does have it's own set of bugs. These may (or may not) be more benign > than > those of QtScript. They may be easier for us to get fixed, but that's because > there is no third party to point fingers at, in the first place. And because it has active developers who you can talk to. > 2. Kate is not the only user of QtScript in the KDE world. Do we want to > switch all other KDE apps to KJS, too? Will that really be the most efficient > solution? Let's start small, and dream big? :-) -- Martin Sandsmark
Re: QtScript considered dangerous
On Fri, May 25, 2012 at 12:03:43PM +0200, Dominik Haumann wrote: > Right, maybe an increase of the allowed memory would work, or similar > changes... Isn't the problem that the pointer size it uses is too small? -- Martin Sandsmark
Re: [RFC] Merging LightDM into KDE Workspaces (forwarded from plasma-devel)
On Wed, Aug 22, 2012 at 01:58:57PM +0100, David Edmundson wrote: > Features LightDM-KDE has that KDM does not: > - Guest support login What does the DM have to do with this? > - Ability to make customisations such as changing the background > without having to edit XML Isn't the kdm config file just a simple .ini file? > - An easy to use KCM I could swear that KDM has a very nice KCM? > - Suspend when lid closed Shouldn't acpid or whatever handle this before powerdevil kicks in anyways? (For example if you close the lid before the DM launches). > - Active development KDM has active development, I've fixed all bugs I found it in the last half year or so. :-P > Features KDM has that are still missing in LightDM-KDE > - ability to switch X sessions > - connect to remote XDMCP sessions > - Get hot new stuff/theme installer > - Ability to reboot into a different grub entry(not that that > actually works for me) How about automatic login and fingerprint reader support? I think those two are the only "obscure" features I'd miss. -- Martin Sandsmark
Re: [RFC] Merging LightDM into KDE Workspaces (forwarded from plasma-devel)
On Tue, Aug 28, 2012 at 01:17:03AM +0200, Thomas Lübking wrote: > To me it sounds as if the package contains a postinstall script to > "useradd guest" for a pwdless login. > I cannot say to really appreciate such "feature" :-\ Uh, that sounds kind of bad for a DM, yes. > He's talking about the xml greeter. Now I'm really confused, isn't the wallpaper just set in /etc/kde4/kdm/kdmrc? -- Martin Sandsmark
GetHotNewStuff for shortcut schemes
Hi! After seeing some talk about default shortcuts in KDevelop (people wanting Visual Studio-like shortcuts by default), I thought it would be neat if users easily could download specialized shortcut schemes. Unfortunately I can't find any way to import shortcut schemes, though there seems to be support for exporting them (though trying to use it crashes KDevelop pretty instantly). So, is this a cool idea? Should all shortcut schemes be grouped together, or should they be grouped per-app? Anything else I haven't thought about? -- Martin Sandsmark
Re: KStringHandler: stateless/reentrant/thread-safe?
On Sunday 28. October 2012 09.22.39 Thiago Macieira wrote: > That's a static const non-POD created by a non-constexpr. That means it's > initialised on the first run. > > It's thread-safe on GCC and C++11, but not on other conditions. It should be safe according to the spec (section 6.7 I think), but I guess we can't rely on all compilers to follow the spec? -- Martin Sandsmark KDE
Re: Moving Trojitá to extragear
On Wed, Nov 21, 2012 at 08:53:14PM +0100, Albert Astals Cid wrote: > [...] (and actually this one has a > missing feature because someone in Qt decided to make a method not virtual)" > [...] Has this been fixed in Qt5? -- Martin Sandsmark
KDEREVIEW: Mangonel
Dear Sirs and Madams, Mangonel has just been moved to KDE Review. Mangonel is a simple and lightweight application launcher in the vein of Katapult from ye olde KDE 3 days, kind of reminiscent of the "task oriented" UI for krunner, but dropping the slow krunner architecture in favour of a simpler and more straightforward one that aims to give immediate feedback to the user. So it doesn't do everything krunner does, but should be useful for some people as either an alternative to or complement to krunner. It was originally developed by Bart Kroon, but he is currently too busy to work on it, so I got a go-ahead from him to clean it up for a proper release with licenses and stuff (which I think it needs because it's pretty useful and should be spread far and wide). -- Martin Sandsmark KDE
Re: KDEREVIEW: Mangonel
Hi, thanks for the review!
On Tuesday 08 January 2013 23:12:01 Albert Astals Cid wrote:
> Which is its intended destination extragear-something?
Yes, sorry, I forgot to mention, it is destined for extragear/base.
> Any reason not to use bugs.kde.org?
Fixed.
> The i18n is quite broken, a simple grep gives me
> ./Config.cpp:39:this->setWindowTitle(KApplication::instance()-
> >applicationName() + QString(" - Configuration"));
> ./Config.cpp:48:QLabel* hotkeyLabel = new QLabel("Shortcut to show
> Mangonel:", this);
> ./Mangonel.cpp:74:m_actionShow = new KAction(QString("Show Mangonel"),
> this);
> ./Mangonel.cpp:92:QAction* actionConfig = new QAction(KIcon("configure"),
> "Configuration", this);
Fixed.
> ./Mangonel.cpp:480:m_descriptionLabel = new QGraphicsTextItem("(" +
> application.type + ")", this);
application.type should already be translated, is it problematic that I wrap
it in parentheses?
> Besides all those units in units.c seem untranslatable.
> Any reason for not using kunitconversion in there?
Ported it to use KUnitConversion now.
> Also the units.c copytight header looks a bit scary
Since they're not necessary anymore I just deleted units.c/units.h.
(I hope I don't need to eradicate them from the git history?)
And lastly, I also forgot to thank Bart for this great app. :-)
--
Martin Sandsmark
KDE
Re: KDEREVIEW: Mangonel
On Wednesday 09 January 2013 08:56:25 Jekyll Wu wrote: > If you plan to > use bugs.kde.org as the tracker, then you don't need to call > setBugAddress() at all. The default value just works. Fixed. > And don't forget to ask sysadmins to create a "mangonel" product on > bugs.kde.org :) Done. Thanks for the review! :D -- Martin Sandsmark KDE
Re: KDEREVIEW: Mangonel
On Tuesday 08 January 2013 19:30:45 Allen Winter wrote: > No docbook manual I guess I'll to contact the doc team for this? > Do you want apidox generated? if so you also need a Mainpage.dox No need for that (yet, at least, we might want to make it plugin-based in the future). > Bart's email address is missing from the Copyright statements in many files. On purpose, I didn't want to spread his email address unencoded all over the internet. Bart, is it OK if I add your email in the top of each file? > Don't use QT4_AUTOMOC in the CMakeLists.txt Fixed. > There are some Krazy warnings you should also fix at some point. > Hopefully the EBN will report those by tomorrow. I can email the Krazy > report if you want it now. That would be nice. > When running 'make install' I get this problem: > > -- Install configuration: "debugfull" > -- Installing: /data/kde/bin/mangonel > CMake Error at cmake_install.cmake:45 (FILE): > file RPATH_CHANGE could not write new RPATH: > > /data/kde/lib:/data/Qt/Qt-4.8/lib:/data/kde/lib > > to the file: > > /data/kde/bin/mangonel > > Error opening file for update. This I have no idea why happens, do you run SELinux or something? -- Martin Sandsmark KDE
Re: KDEREVIEW: Mangonel
On Wednesday 09 January 2013 19:49:36 Albert Astals Cid wrote:
> You should probably make it look like
> i18nc("some context of what stuff is", "(%1)", application.type)
>
> Just in case someone needs to do something different with the parenthesis.
Okay, fixed. Thanks :-)
--
Martin Sandsmark
KDE
Re: KDEREVIEW: Mangonel
On Wednesday 09 January 2013 19:45:27 Martin Gräßlin wrote: > There is one mail already on the list, so it is already spread. Okay, so the proverbial cat's out of the bag I guess, so I just added his email to the license headers. -- Martin Sandsmark KDE
Re: KDEREVIEW: Mangonel
On Wed, Jan 09, 2013 at 09:07:13PM +0200, Yuri Chornoivan wrote: > If there is no "Help" button and no desktop file, there is not much > sense in making docbooks. I agree. > I propose just add an item to UserBase launchers list [1] and some > tiny page based on README.md. I'll be sure to market it wherever I can when I finally release it. :-) -- Martin Sandsmark
New lockscreen
Hi! The new lock screen has some more or less serious regressions, and doesn't seem to be maintained by anyone in particular (one of the regression bugs filed against it is from november, and I don't really see anyone in particular commenting or fixing anything, it only got a handful of commits in december). So, who is supposed maintain this new screenlocker? In its current state it provides nothing new over the old lock screen (for users), but has about a dozen (12 filed ones, maybe more unreported ones?) regressions. A list of the current regressions are available here: https://bugs.kde.org/buglist.cgi?product=kscreensaver&component=locker-qml&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=384099 I can help fix some of them, but I know nothing about the codebase, and not really much about QML, so I would at least appreciate some help. Another alternative is to revert the replacement for KDE 4.10, and instead postpone it for KDE 4.11, though that's not nice considering how it has been marketed already. But IMHO it's better than shipping it in its current state so that people won't think that QML == regressions and brokenness. -- Martin Sandsmark KDE
Re: New lockscreen
On Thu, Jan 10, 2013 at 09:46:11PM +0100, Marco Martin wrote: > 311571 and 312427 should be fixed now Thanks! > some bugs seems easy, some i can'r reproduce them at all. Which ones can't you reproduce? I can look at them this evening. > however not all of those are valid i think (the concept is: is a > screenlocker, > not a screensaver anymore, thus makes behavior changes) Well, the old one managed to be both, so IMHO if we remove features it is a regression (though which ones are you talking about?). -- Martin Sandsmark
Re: New lockscreen
after a group of people requested it be that way; despite > attempts at reasoning it through with them they maintained that position. i'm > hoping the people involved will realize just how untenable that position is > now. where i failed with reason, i hope that experience will be an effective > teacher. > let's make this *not* the future of KDE development. Agreed. -- Martin Sandsmark Raiser of the Ruckus
Re: Re: New lockscreen
On Fri, Jan 11, 2013 at 09:49:06AM +0100, Martin Gräßlin wrote: > no, removing features is not a regression. It is the decision to remove the > feature. The use case for screen savers does no longer exist or when did you > last have a screen which needs to be saved? For background reading I > recommend > [1]. I still have CRT screens, and plasma displays (yes, ironic or something) are highly susceptible to burn-ins as well. LCD displays usually only have transient burn-ins, but it's still annoying. OLED displays seem to be more susceptible to burn-ins than plasma displays according to some sources. So no, the use case hasn't disappeared at all (it's still the same as it was 20 years ago). And I still really like to have the nice asciiquarium to show off whenever I leave my computer. But if you are going to remove screensaver support, at least do that completely, and don't leave a half-broken implementation in place (and mark the bugs as related to it as invalid). -- Martin Sandsmark Screensaver afficionado
Re: Re: Re: New lockscreen
On Fri, Jan 11, 2013 at 10:28:22AM +0100, Martin Gräßlin wrote: > and what has protecting the screen against burn-ins to do with security? > Nothing, right. Which is why the lock screen has usually been activated separately from the screensaver. > Btw. we are not the only ones who go the way of removing screen savers in > favor of lock screens. The same happened at GNOME and at Microsoft. So > somehow > the people working on such features came all independently to the same > conclusion. Windows 8 still has screensavers AFAIK? As does OS X. And Gnome is not something to be emulated in the least bit, IMHO. > Yes sure there are still CRTs around, there are Plasma screens around and > somewhen in the future OLEDs might be used which show the problem. Does that > mean that we should use a default (because that's what it's all about) which > is not optimal for the 99.9 % of our user base that actually uses LCD screens? Where on earth did you pull that statistic from? And while your arguments may be in favour of using a blank screensaver by default, I think something that is optimal for 100% of our users is better than 99.9%, and I think you agree. > and again that is orthogonal. There is nothing preventing anyone to add an > animation to the lock screen. Sure, let's just make sure it works properly. > As I wrote it's a HACK and has always been like that. Well, they have always been known as screen hacks, yes, but mostly because they are clever graphical hacks AFAIK. :-P -- Martin Sandsmark
Re: New lockscreen
On Fri, Jan 11, 2013 at 10:32:38AM +0100, Marco Martin wrote: > 311188 since i don't have a a multiscreen setup at the moment Me neither, unfortunately. :( > difference between 312427 and 311033 (but then he confirmed that he had > xscreensaver enabled as well so they're actually duplicates) Thanks for fixing it. :D > in 36 here works in the case a screensaver is enabled (ie esc shows the > screensaver again) Yes, I tested this briefly yesterday, and it seemed to work, but not always. I'll test more when I get home again. > this i can reproduce, i don't know much yet how to fix: > 310611 (accelerators) The code from Elias won't work? > the first plan (that i think would still have the better way to go, > especially > in the optic of preparing for wayland) was to remove the screensaver > altogether, it was re-added afterwards due to many requests Ah, as Martin said we could probably just have told people to use xss if they wanted it. But now you have managed to make a solution that works pretty well for everyone, thank you. :-) Thanks again. -- Martin Sandsmark
Re: New lockscreen
On Fri, Jan 11, 2013 at 10:50:53AM +0100, Aaron J. Seigo wrote: > "an animated screen saver" is not the only answer. "blank the screen" works > just as well, probably even better from a power consumption point of view. > blanking the screen is still supported :) Some people care more about aestethics than power consumption (especially on workstations), though. But this is a completely moot point as it's perfectly possible to create fancy displays hacks in QML as well (as I said, I've created a couple myself). -- Martin Sandsmark
Re: Re: Re: Re: New lockscreen
On Fri, Jan 11, 2013 at 11:37:43AM +0100, Martin Gräßlin wrote: > > Which is why the lock screen has usually been activated separately from the > > screensaver. > no, it wasn't. The lock screen had been implemented inside the screen savers. > Yes blank screen was just another kind of screensavers. Yes, it was. The lock screen had a separate timeout activation, the rest is just an implementation detail. And no, the lock screen was not running in the screensaver process. > yes in the same way as we have screensavers. As a legacy option What do you put in "legacy option"? It's fully supported and in the same place it always has been? Doesn't seem very legacy to me. > > And Gnome is not something to be emulated in the least bit, IMHO. > which is not what I wrote. You said we should drop them because Gnome dropped them. -- Martin Sandsmark
Re: New lockscreen
l jackson song. would you be fine if i did the > same > to you? or would you consider it juvenile, cheeky and disprespectful? Sorry, I was trying to lighten up the discussion a bit, but I can see how it came across as cheeky. My point was that you're making assumptions about what I intended, projecting that onto what I wrote, and putting words in my mouth. > the idea that "nobody noticed until now" means something is rather broken in > the development process. it should never have to come to the 11th hour; it > ought to be dealt with rather earlier. But people *did* notice, they just didn't manage to communicate the issues to the right people for whatever reason. -- Martin Sandsmark
Re: Re: Re: Re: Re: New lockscreen
On Fri, Jan 11, 2013 at 01:23:04PM +0100, Martin Gräßlin wrote: > > On Fri, Jan 11, 2013 at 11:37:43AM +0100, Martin Gräßlin wrote: > > > > Which is why the lock screen has usually been activated separately from > > > > the > > > > screensaver. > > And no, the lock screen was not running in the screensaver process. > Martin, please. I did most of the porting to the new architecture and I re- > read the code before replying to your mail writing that. Yes, technically the > lock is held by a different process which doesn't invalidate what I wrote. So both technically and from a user experience stand point the locking and the screensaver were separate? IMHO that invalidates what you said. > I have a huge problem if people twist my words. That is not what I have > written and not what I have meant. I quote my words: > > "Btw. we are not the only ones who go the way of removing screen savers in > favor of lock screens. The same happened at GNOME and at Microsoft. So > somehow > the people working on such features came all independently to the same > conclusion." > > there is nothing in it that would say that GNOME at any influenced any of our > decisions. You're trying to justify our decision (after the fact) by pointing at Gnome's decision? Or am I misunderstanding you? I'm not saying Gnome influenced our decision in the first place, I'm trying to say that we shouldn't need to use Gnome to justify our own decisions. That the Gnome people decide something does not validate anything, IMHO. -- Martin Sandsmark
Re: Re: Re: Re: Re: Re: New lockscreen
On Fri, Jan 11, 2013 at 02:14:37PM +0100, Martin Gräßlin wrote: > We are not talking about the same things. We have three parts here: > * locking of screen (no keyboard, no mouse) > * not exposing screen content > * unlock dialog > > to me the lock screen is "locking the screen plus not exposing the screen > content", while unlock is completely unrelated. The old implementation had > the > "not exposing screen content" as a screen saver. Ok, I see where you're coming from now. > well if they got it right, it's right, isn't it? Just that GNOME did > something > doesn't mean it's wrong. Given your remark it sounds like that which would be > very sad. Yes, but that something is right is pretty much orthogonal to Gnome doing it, which is why I balked at you dragging them in at all. But, useless thread. Everyone (including us) have screensavers now, everyone are happy. -- Martin Sandsmark
Re: KDEREVIEW: Mangonel
Distinguished Sirs and Madams, On Tue, Jan 08, 2013 at 09:08:11PM +0100, Martin Sandsmark wrote: > Mangonel has just been moved to KDE Review. The KDE Review process is set to be two weeks, and if Mangonel calculator isn't completely wrong, that period is now up. Since all the issues raised are fixed, I assume I can now move forward with moving it to extragear/base? Thanks to everyone who have reviewed, and contributed comments and fixes. -- Martin Sandsmark
KDE Review: Kor - a minimalistic desktop shell
Dear esteemed ladies and gentlemen (and everyone in between), Kor is a simple and minimalistic desktop shell with support for plasmoids, plasma wallpapers, etc., but also its own minimalistic plugins/widgets. It is an option for those with low-end hardware or who don't need a full Plasma desktop. It has no configuration UI, and relies on hand-edited configuration files. You can check it out from git, if you've set up your git config according to KDE standards just do «git clone kde:kor». Or you can view it here: http://quickgit.kde.org/?p=kor.git I intend to move it to extragear/base once this review is complete. -- Martin Sandsmark
Re: Login for bug reporting
On Wed, Feb 06, 2013 at 10:20:07PM +0100, Frank Reininghaus wrote: > considering that we get lots of duplicates for any reproducible bug, my > impression is actually not that there are to many obstacles in the bug > reporting process. Providing any kind of "contact me via email/Facebook" > channel will only make it worse. I'm already spending a lot of time marking > reports as duplicate/invalid or telling people that reporting bugs for KDE > 4.8 or earlier is not quite as useful as they think. Please do not make it > worse by lowering the bug reporting barriers. Wouldn't this be solved if backtraces weren't entered as bugs, but into a separate system as Nicolás talks about? That system would hopefully also be able to group together backtraces for the same crashes, and thereby also automatically discarding backtraces marked as "fixed" (especially if we get version information together with the backtrace). -- Martin Sandsmark
Re: Login for bug reporting
On Thu, Feb 07, 2013 at 01:58:14AM +0100, Teemu Rytilahti wrote: > What kind of reports are those useless ones? Dupes? Downstream bugs? Missing > information? In my opinion reporting bugs to b.k.o is not that easy (or I've > become lazy) as it should be and that's why I'm wondering.. All of the above, as well as obvious PEBKACs and support requests. -- Martin Sandsmark
Re: Login for bug reporting
On Thu, Feb 07, 2013 at 11:10:35AM +0100, Kevin Krammer wrote: > I met a guy from Mozilla on my flight back home from FOSDEM and his job is > doing statistic analysis on their crash reports to find those that happen > most > often and then enter those as issues for the developers to look at. > So they definitely don't add all crash reports to their bug tracker. But do they accept crashes which are not from their own builds? -- Martin Sandsmark
Re: Login for bug reporting
On Thu, Feb 07, 2013 at 11:15:48AM +0100, Kevin Krammer wrote: > The only thing I remember from the initial introduction was that they get so > many crash reports that they can't look at them individually but need to > perform statistical analysis first. Well, AFAIK they use breakpad, which means they need to store the debug symbols on their server, and people only upload the minimal stack traces with addresses. This makes it much easier to analyze (statistically and otherwise) and find duplicates, but it's not something we can do. If anything, it would have to be done at a distro level. -- Martin Sandsmark
Re: Login for bug reporting
On Sat, Feb 09, 2013 at 03:25:12PM +0100, Martin Graesslin wrote: > and a feedback channel. E.g. for that bug there was one setting to change and > it would have been great to just be able to tell the users that in an easy > way. I wish there was a way to have a "summary" on top in all bugs, editable by us. So instead of just adding a first comment, the reporter writes a summary that we can later edit. -- Martin Sandsmark
Re: Password strengh meter in KNewPasswordDialog
On Thu, Apr 04, 2013 at 01:02:21AM +0200, Luigi Toscano wrote: > Have you seen this? > https://fedorahosted.org/libpwquality/ > https://fedoraproject.org/wiki/Features/PasswordQualityChecking It doesn't contain any docs about how it calculates anything that I can find, which is a bit worrying. From looking at the code it looks very simplistic. But why not simply use cracklib? Or you could try to compress the string with qCompress/zlib to find a measure of the entropy contained? -- Martin Sandsmark
Re: [kdelibs] kded: Disable KHostnameD in KDED
On Mon, Apr 15, 2013 at 12:43:21PM +0200, Àlex Fiestas wrote: > Git commit 8d99f863724c6fe76d008da4455fa177af2ee3ee by Àlex Fiestas. > Committed on 15/04/2013 at 12:24. > Pushed by afiestas into branch 'master'. I thought kdelibs master was closed for everything except bug fixes? And why didn't this go through reviewboard? -- Martin Sandsmark
Re: Re: [kdelibs] kded: Disable KHostnameD in KDED
On Mon, Apr 15, 2013 at 01:17:19PM +0200, Martin Gräßlin wrote: > well not stupidly polling is a bug fix, isn't it? That's really trying to twist semantics, IMHO. Polling every five seconds like it is intended to is not a bug, and now it breaks even worse (by locking out everyone who change their hostname from their sessions, not just with a different X setup). > I think in this case it is fine, after all core-devel is on CC and the code > is > not yet removed The point of reviews is to catch stupid mistakes like the one Rolf pointed out (and preferrably have this discussion before-hand, instead of having to go in and revert stuff). -- Martin Sandsmark
Re: [kdelibs] kded: Disable KHostnameD in KDED
On Mon, Apr 15, 2013 at 02:04:43PM +0200, Sebastian Kügler wrote: > Polling every 5 seconds for a file that is rarely changed is a bug. What functionality does it break? I'm not saying it's not suboptimal, and it can be solved in better ways, but I would in no way consider this a bug fix. -- Martin Sandsmark
Re: Results of the freedesktop summit
On Tue, Apr 16, 2013 at 02:16:33PM -0700, Thiago Macieira wrote: > I've talked to Greg. He's explained that they started writing code 4 weeks > ago > only and that they've just got messages going from one process to another. > They are trying to get a prototype working before really inviting the > thundering herd to create a bikeshed flamewar^W^W^W^W^W^W^W^Wconstructive > criticism. Well, systemd already uses it¹, so they must have something workable now. ¹: http://lists.freedesktop.org/archives/systemd-devel/2013-April/010623.html -- Martin Sandsmark
Re: Nepomuk in 4.13 and beyond
On Wed, Dec 18, 2013 at 11:07:18PM +0100, Jos Poortvliet wrote: > Unless somebody knows a web service which can judge the value of a word > that internet users seem to attach to it or something like that :D Just because I'm a bit bored atm. I found such a site: http://i.imgur.com/OkIHqGv.png Not that it means anything. :-P -- Martin Sandsmark
Language detection in Sonnet
Dear esteemed sirs and madams, I have spent the last couple of days re-merging back in an old branch for Sonnet that enables language detection. Simple, high-level overview of what is done: Replace the filter class with a (proper) tokenizer, using our own languagebreaks class because QTextBoundaryFinder is broken beyond hope of salvation (imho), and implement language recognition. The language recognition is performed in three major stepts: 1. Looking at the script types used (QChar::script()). 2. Trigram-based model (I abandoned the "most significant words" algorithm for reasons). 3. Pure brute-force on all available spelling backends (the one with the least amount of errors is chosen) In this branch I have also removed some dead code and whatnot. So if you wouldn't mind, please take a look in the "langdet" branch of Sonnet, and come with any and all feedback. https://projects.kde.org/projects/frameworks/sonnet/repository/revisions/langdet/show/ -- Martin Sandsmark
