| |||||||||||||
attacksattacksPosted Dec 19, 2011 17:12 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)In reply to: attacks by boudewijn Parent article: Razor-qt 0.4 released
>* 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.
(Log in to post comments)
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/
|
|||||||||||||
