Razor-qt 0.4 released [LWN.net]

Razor-qt 0.4 released

Posted Dec 16, 2011 20:30 UTC (Fri) by fest3er (guest, #60379) [Link]

As I discovered yesterday, KDE *still* has no integral UI to manage SSL certs for Konqueror and kmail, for example. That's a show stopper for a lot of people.

Razor-qt 0.4 released

Posted Dec 17, 2011 21:49 UTC (Sat) by wstephenson (subscriber, #14795) [Link]

Type "SSL" in the menu search or krunner and look at "SSL Preferences".

Razor-qt 0.4 released

Posted Dec 16, 2011 20:48 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

My full name is Alex Besogonov, I'd add it to my account if I could. I really liked the old good FIDOnet where everybody used real name.

As for bugs in Krita, I don't have a will to revisit them. I did list several bugs in KDE itself. I can code just fine, but desktop environments are just outside of my area of interest.

Razor-qt 0.4 released

Posted Dec 17, 2011 5:53 UTC (Sat) by jmalcolm (guest, #8876) [Link]

I would personally prefer not to see these kinds of comments (attacks really) on LWN.

attacks

Posted Dec 17, 2011 9:00 UTC (Sat) by oldtomas (guest, #72579) [Link]

At some level I do agree with you. But then again not.

Granted, I felt some sort of unease with this (quite strong) comment, which verges on personal attack.

Still, it expresses frustration with something which is quite real, and thus has the potential to clear the air.

There is some tension at the moment between the "desktop" folks and the "lean and mean" folks (to put somewhat arbitrary labels on that; i'm firmly "in" one of those "camps" -- which one it is will be left as an exercise for the reader ;-).

I hope we can sort out things without hiding the conflicts which arise along the way. If someone manages, LWN readership will, I'm sure.

attacks

Posted Dec 17, 2011 16:59 UTC (Sat) by boudewijn (subscriber, #14185) [Link]

In http://lwn.net/Articles/466891/, Alex Besogonov said "Here are other examples of braindeadness in KDE4: http://lwn.net/Articles/466857/ And that's just in KDE desktop. I have scores more of examples in other applications (like Amarok) or Krita.".

I am the maintainer of Krita, I have spent ten years of my life working on that application. This person bad-mouths the work I did. When challenged to provide details, he then came up with exactly nothing, despite claiming to have scores more of examples ready. Heck, if this guy had come up with something interesting, I might even have acted on it. Now this Alex claims to have no interest in actually revisiting the issue. I find that extremely bad form, and yes, I take that personally.

I don't mind people criticizing my work. I don't mind people offering suggestions, reporting bugs, or even telling me Krita isn't suitable for their purpose. That's fine, Krita has a specific purpose and therefore isn't all things to all people. But I do despise people who piss on other people's work and then are too lazy or cowardly to back up their claims. I may be old-fashioned, but to me it means that everything else they say starts sounding like a lie, or trolling, to me.

attacks

Posted Dec 18, 2011 0:24 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Ok, if you insist. I do some painting for entirely personal pleasure in my non-existing free time.

I try to do almost all of my work on a small laptop, so Krita's unscrollable toolbars force Krita's window to be taller than my screen which is quite annoying. Other tools (GIMP, Inkscape) have some sort of resizeable toolbars.

Oh, also don't forget the toolbars jumping around when one selects a different tool.

I tried to use a Wacom tablet, but quickly abandoned it. I like to switch between mouse and tablet quite often however Krita doesn't seem to like it. I got hit by bugs when I could paint on a locked layer or couldn't paint on an unlocked layer, or my brush was incorrect after the switch, etc. Sometimes cursor just disappears completely.

A lot of tools are buggy. For example, an ellipse tool leaves a trace of unerased pixels if I move it too much which is very distracting on a tablet.

Then there are color selectors - Krita has like 10^100 of different color spaces and 10^14 of color selectors (Triangle, simple, palette, digital mixer, advanced), but no color selector where I can quickly adjust HSB components, there's 'specific color selector' but only for RGB. I tend to remember exact color values and tweak them a bit when necessary.

Effect layers were quite buggy when I tested them.

Etc.

attacks

Posted Dec 18, 2011 8:56 UTC (Sun) by oldtomas (guest, #72579) [Link]

Now now. Calm down, both of you.

@boudewijn: no, given the evidence, I don't see Cyberax is "badmouthing" or "pissing on" your work. His comments are full of hyperbola (10^100 color spaces? C'mon, Cberax. Do you really know how big this number is? 10^14 color selectors?) -- but he might have a point. Perhaps you could try, for a change, to seduce him to make his point in a way that'd be more useful to you and the improvement of your software?

@Cyberax: hey, you might like to express your frustration with a tad less harshness. A bit of sense of humor goes a long way here.

So It'd be cool if both of you see this as a chance to make things better.

Look. I'm (by far) not the "target demoscopics" of applications like Krita. I use them when I have to -- otherwise, I'm the "FVWM" type. I do try to avoid DBUS like the plague. And so on.

Still I do realize that my life is better thanks to the work all those people is doing. I never used Krita (and it's quite possible I never will), but I'm sincere when I say "thank you, boudewijn".

Now I've been admonishing a bit too much. Sorry. I'll shut up now.

attacks

Posted Dec 18, 2011 12:57 UTC (Sun) by boudewijn (subscriber, #14185) [Link]

Okay, now we're cooking with gas.

* small screens: Krita is meant to be a professional tool for professional painters. That means we optimize for big screens. The minimum resolution to use Krita is 1024x768, and Krita does fit in there.

* Jumping palettes: that no longer happens. Was difficult to fix because we use Qt's docking system, but at the expense of adding optional scrollbars to the tool option palette docker, we managed to get rid of the jumping.

* Wacom tablet issues: all of those have been fixed for 2.4, except for certain ghosting of the brush outline cursor -- https://bugs.kde.org/show_bug.cgi?id=289174.

* ellipse tool canvas redraw problems: you are right, I can reproduce that here, but only if OpenGL is disabled. Nobody had reported that as a bug yet, so I added https://bugs.kde.org/show_bug.cgi?id=289275

* color selectors: the current set of color selectors has been created from input by professional artists and they haven't asked for an HSB mode. Having a grayscale colorspace mode available for RGB images was much more important for David Revoy. But the artistic color selector offers HSY, HSI, HSL and HSV modes, though, and if that doesn't satisfy you, it's always possible to file a wish in bugs.kde.org -- that helps us keep track of users' requirements.

* buggy effect layers: it's possible, of course, that there are problems there. To fix any problems of which we might be unaware, we need users to report bugs. And note that I've always said in public that I'm pretty easy-going about bug reports. People can mail me with a problem, ping me on irc or enter a bug in bugzilla themselves, that's all fine with me.

attacks

Posted Dec 19, 2011 17:11 UTC (Mon) by rahvin (subscriber, #16953) [Link]

* small screens: Krita is meant to be a professional tool for professional painters. That means we optimize for big screens. The minimum resolution to use Krita is 1024x768, and Krita does fit in there.

Ouch. Admittedly that's a small resolution but have you considered that by failing to accommodate (if even possible) even smaller resolutions (all the way to 640x480) you could in fact be harming accessibility for those with disabilities? Just something to think about, I realize that's probably not a target for you given your focus but there are artists with disabilities.

There is also a work-flow model in a multi-monitor environment where smaller resolution monitors are used for palette management. I'm not sure how prevalent this is in relation to Krita but I thought I'd throw it out there. You should also consider that it's becoming more likely that we might all have 4" QVGA/VGA/SVGA touch screens attached to most input devices (such as keyboards) that would be ideal locations to put tool palettes.

It's cool that your focus is professionals (IMO it's always better to work down from the top), but you might consider accommodating amateurs and those getting started. Adding something like an HSB mode should be fairly trivial with all the other color space handling you have. Although I agree with you that It's probably not needed with the grayscale colorspace and Cyberax would be well advised to discover the grayscale colorspace and what its capable of.

I haven't played with Krita before, I'm going to have to check it out.

attacks

Posted Dec 19, 2011 17:53 UTC (Mon) by boudewijn (subscriber, #14185) [Link]

You can drag all the palettes out of the main window and onto the secondary screen -- so that's covered. I think all palettes individually will fit in 640x480, but I haven't tested. My secondary monitor is already 1280x1024, and it's actually a long time since I last had a computer with a 1024x768 screen -- my wonderful Lenovo X61t with built-in wacom digitizer.

As for accessibility, yes... We actually have huge problems there. We used to have someone on the team we knew enough to make sure that the Calligra (back then, KOffice) apps were properly accessible, but we lost that knowledge, unfortunately.

attacks

Posted Dec 19, 2011 17:12 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

>* small screens: Krita is meant to be a professional tool for professional painters. That means we optimize for big screens. The minimum resolution to use Krita is 1024x768, and Krita does fit in there.

Well, it doesn't fit on Ubuntu 11.10 by default (my notebook is 1366x768). Not a big deal, but annoying.

>But the artistic color selector offers HSY, HSI, HSL and HSV modes, though, and if that doesn't satisfy you, it's always possible to file a wish in bugs.kde.org -- that helps us keep track of users' requirements.

HSV is fine (it's just another name for HSB). But I can't find a way to quickly adjust numeric values of components.

>* buggy effect layers: it's possible, of course, that there are problems there. To fix any problems of which we might be unaware, we need users to report bugs. And note that I've always said in public that I'm pretty easy-going about bug reports. People can mail me with a problem, ping me on irc or enter a bug in bugzilla themselves, that's all fine with me.

The problem is, most users just despair and either work around bugs or just switch to another tool. Especially since a typical release cycle of most Linux software ensures that the bugfix would arrive only in 6-12 months via normal repositories.

Additionally, I personally lack energy to follow through on bugreports. Especially in KDE/GNOME software, since they often end either in flamewars or forgotten. For example, alecs1 had opened a bug about accelerators in KDE that I've mentioned: https://bugs.kde.org/show_bug.cgi?id=286375 with the expected RESOLVED:WONTFIX resolution.

attacks

Posted Dec 19, 2011 18:18 UTC (Mon) by boudewijn (subscriber, #14185) [Link]

Whether an application fits on screen of course depends on a lot of variables, like whether there's a big panel taking space, or the active theme and even the translation. I'm afraid I cannot guarantee that Krita will always fit in the minimum resolution given these variables. I know it fits for me, in English, using Oxygen and OpenSUSE...

About numerical input of HS(V,B,etc) -- fair enough. Nobody asked for that before, and apparently artists don't need that kind of precision, but it would make a good improvement on the specific color selector. I have created https://bugs.kde.org/show_bug.cgi?id=289367.

Of course, you mention how frustrating it can be to file bug reports and see them closed as "won't fix", even if there's a good reason for closing the report, as in the example you have given. I can only say that there are wildly different standards for handling bug reports between projects and even within KDE. Nobody has ever closed a Krita bug report because the discussion has become acrimonious, for example, and most bug reports receive at least a reaction within a week (most often on Saturday, because that's when I sit down and triage.) In other words, it's up to the maintainer, and since I try to be a conscientious maintainer, I would very much appreciate not to be tarred with the same brush as other maintainers who might neglect bug reports.

(This is a fun graph, made by one of our developers: http://i.imgur.com/4qLWK.png. It shows the bugs on the y-axis, and then on the x-axis a pixel for every day that the bug wasn't fixed. It would be more interesting to see when we first came back with a reaction to a bug report, but well, it's just statistics anyway. Draw your own conclusions...)

Finally, I do agree that updates don't land on people's desktops quickly enough. With Calligra we were aiming for a four month release cycle, but there's always more to do, and so the schedule slips and slips. Right now, most professional and semi-professional users actually compile Krita from git master... (Which kind of shows how eager those users are to get the latest features -- and of course, also the bug-fixes we do for them.) This situation is not ideal, but I don't see how it's "brain-dead" either.

Btw, the issue with the ellipse tool leaving traces of garbage on the canvas is fixed.

attacks

Posted Dec 19, 2011 23:19 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

>Whether an application fits on screen of course depends on a lot of variables, like whether there's a big panel taking space, or the active theme and even the translation. I'm afraid I cannot guarantee that Krita will always fit in the minimum resolution given these variables. I know it fits for me, in English, using Oxygen and OpenSUSE...

I run XFCE with a single smallish top panel and without window decorations for maximized windows - it's about as small as it gets. I'll send a screenshot later.

And I must apologize, Krita is definitely getting better. I just got unlucky to use it when it has not yet been stable enough. Thanks for all the good work!

attacks

Posted Dec 20, 2011 8:45 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

Thanks --- and if you have feedback on 2.4, don't hesitate to contact me!

attacks

Posted Dec 20, 2011 14:09 UTC (Tue) by rsidd (subscriber, #2582) [Link]

Thanks both of you (boudewijn and Cyberax) for setting an example!

As an aside -- Cyberax seems to be of Russian origin and boudewijn, I assume, is of Dutch or Flemish origin. The Dutch are among the most polite people I've met. The Russians I know are polite to me, but I've seen Russians talking to one another (in English, because others were present), and the aggression is staggering -- it seems like any moment they will come to blows. Yet there's nothing personal in it -- it's just a vigorous argument, Russian-style. I suspect a lot of personality conflicts, especially online, are merely cultural issues and could be resolved if the people involved met in real life (or, as in this case, made an extra effort to listen to each other).

Apologies if the stereotyping was incorrect in this case.

attacks

Posted Dec 20, 2011 22:37 UTC (Tue) by jospoortvliet (subscriber, #33164) [Link]

Boudewijn surely is a hugbear - I can say he and his wife Irina are two of the sweetest people I know.

Otherwise, the dutch aren't always so polite - and being one, I know.

We're notoriously arrogant, especially when on holiday. Not sure why THAT brings out the asshole in us... I tend to not have holidays so for me it's hard to say :D

attacks

Posted Dec 21, 2011 11:30 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

I tend to instinctively think of Dutch people as chiefly "very tall" and "very direct". The holiday thing doesn't exactly surprise me, since English and German people also have at least a bit of a reputation for being disagreeable holidaymakers.

attacks

Posted Jan 2, 2012 20:21 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

Direct, arrogant, what's the difference? ;-)

attacks

Posted Dec 21, 2011 4:15 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

As usual, that depends on person. In the OfflineWorld(tm), I'm a much milder in person than on the Net.

attacks

Posted Dec 21, 2011 4:01 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

http://www.flickr.com/photos/72525417@N03/6547100125/in/p... - here's a screenshot of default Krita configuration on the first start.

I'm going to try Krita more this week - I've compiled git head, but I haven't yet used it much. But it definitely feels MUCH better now.

attacks

Posted Dec 21, 2011 8:19 UTC (Wed) by boudewijn (subscriber, #14185) [Link]

Outch... Of course, that _is_ smaller than the minimum size -- at 916px × 737px, but still. I'm surprised though that by default the toolbox has only one column of icons. It should have two -- and you can drag it to have three or more columns. That should help a lot with vertical space taken up.

attacks

Posted Dec 19, 2011 22:59 UTC (Mon) by rqosa (subscriber, #24136) [Link]

> For example, alecs1 had opened a bug about accelerators in KDE that I've mentioned: https://bugs.kde.org/show_bug.cgi?id=286375 with the expected RESOLVED:WONTFIX resolution.

Was his bug report really about the same issue that you had discussed here? I don't think so. It looks to me like what he was asking for in that Bugzilla entry (which was "more of a feature request" than a bug report, according to him) was for KDE4's SystemSettings to be able to display the global shortcuts registered by non-KDE4 applications (specifically Amarok 1.4, a KDE3 application). I doubt that KDE's shortcuts configuration applet has ever been able to show shortcuts for non-KDE apps (including apps for earlier versions of KDE than the version the shortcuts applet belongs to). Whereas, the way I understand it, the bug you reported here was that KDE4's Klipper registers Ctrl+Shift+Insert as a global shortcut, but that shortcut doesn't show up in the "Settings and Gestures" module in System Settings. So, what he reported in KDE's Bugzilla was completely different than what you reported here.

For what it's worth, I can't reproduce the bug as you described it on my KDE installation. You said that pressing Ctrl+Shift+Insert would "show the clipboard ring", but nothing popped up when I press that key combination. I tried it in a GTK3 application (Audacious), in a GTK2 application (gxine), in KDE4 Konqueror with WebKit, and on the desktop (i.e. with all windows minimized); in the GTK apps, it does nothing, whereas in Konqueror/WebKit it did nothing except for when typing in a textarea, in which case it appeared to treat it identically to Shift+Insert and performed a "paste".

attacks

Posted Dec 20, 2011 17:35 UTC (Tue) by alecs1 (guest, #46699) [Link]

Yes, the two things are a bit different, the bug I reported has a broader scope. Maybe a more specific bug would be useful and easier to get some fix implemented.

My request came from the more general concept is that there should always be an utterly powerful application that consistently handles control of keyboard and mouse, which I'l explain here since this is news about a DE:

1) Ctrl+Alt+Del (or another combination) should always be intercepted by a part of the DE and instantly acted upon (because maybe you want to kill that application that has taken control of your keyboard and now is thrashing the HDD and never replying, thus blocking everything). Alt+Tab should have almost as much power. Needles to say, this doesn't happen in KDE at least.

2) Dialogues requiring passwords should uniquely capture the focus at all times. I've seen the GTK implementation of these dialogues (PolicyKit I believe is called this authorization framework) telling me that it could not get total control over the keyboard focus. The KDE counterpart just crashed in the same situation. If not for the exaggerated intrusiveness, my experience with Windows Vista would have been delightful (those always got total focus, with messages I understood and even the transition animation worked). Compare this to: https://bugs.kde.org/show_bug.cgi?id=271147, which is just as bad a joke as the "lost+found" thing in the SystemSettings.

3) The DE should know where keyboard shortcuts go. If they go through a KDE3 daemon to Amarok through whatever library, then that daemon should be listed.

In my experience Linux looses badly when compared to Windows when managing misbehaving GUI applications, or taking control over input. In Windows I have Ctrl+Alt+Del for whatever full-screen and custom resolution app. missbehaves; in Linux I pray that it doesn't misbehave because it can: leave Xorg,KWin,Plasma panels in some sorts of corrupted states, because there's no Ctrl+Alt+Del instantly respected (but Ctrl+Alt+F1 seems to generally manager to bring me to a console). Fortunately, over the years at least Xorg and video drivers got their bugs fixed (I think KMS also helps), so at least Xorg doesn't crash that easily.

Alex

attacks

Posted Dec 20, 2011 17:45 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Peter Hutterer from Red Hat is fixing a entire class of such problems.

https://fedoraproject.org/wiki/Features/Grab_override

Will be in upstream Xorg and DE's can take advantage of this.

attacks

Posted Dec 20, 2011 18:59 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

it can be really annoying for a dialog window to grab the focus and not let it go when you want to do something other than respond to that dialog window.

using your example of something that asks for a password, what if you want to access your password safe to get that password?

attacks

Posted Dec 20, 2011 19:31 UTC (Tue) by alecs1 (guest, #46699) [Link]

I stand corrected, I didn't express myself very well and I only meant the root password and own password for sudo.

I'm not insisting that all password requests should acquire total focus, but those that try to implement such a thing should be consistent and stable. I didn't do an analysis of what needs passwords and what not, but I think all system configuration triggered by GUI and which requires additional privileges should do this grab. The password safe should implement some extra security itself too.

attacks

Posted Dec 20, 2011 19:39 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

The dialog doesn't need to be system-modal. It just needs to ensure exclusive access to the keyboard as long as it has the focus so that nothing else can observe your password.

Note that you're still vulnerable to impersonation attacks, since any other program can pretend to be the system dialog and capture your password that way. A reserved, unblockable shortcut key helps, but doesn't entirely eliminate the issue. To block this sort of attack you need some form of secure channel (like a dedicated LED) with which to indicate that the system dialog has successfully reserved the keyboard focus.

attacks

Posted Dec 20, 2011 20:15 UTC (Tue) by rqosa (subscriber, #24136) [Link]

> The DE should know where keyboard shortcuts go. If they go through a KDE3 daemon to Amarok through whatever library, then that daemon should be listed.

But, even assuming it's possible for some applet to get a list of keyboard shortcuts for all currently-running X clients from the X server, then that applet wouldn't be able to change the shortcuts because it's up to each individual X client to determine its own shortcuts. The "Shortcuts and Gestures" module in System Settings is supposed to be able to (permanently) change the shortcuts, and there's no way to do that in general for all X clients, so it only deals with shortcuts belonging to KDE apps.

(Another potential problem with trying to display and/or change shortcuts for all X clients is that the client that receives the key event may not be the same as the application that acts on it — for example, (if I understand correctly) KDE 4 has a daemon called "kglobalaccel" for receiving global shortcut keypress events, because KDE 4 also supports Mac OS X and "for OSX you have to have an app running to catch events at the global level".)

attacks

Posted Dec 20, 2011 20:06 UTC (Tue) by rqosa (subscriber, #24136) [Link]

s/Settings and Gestures/Shortcuts and Gestures/