On 2013-05-18 07:49 (GMT-0500) Rajko composed:
On Sat, 18 May 2013 02:28:53 -0400 Felix Miata wrote:
See, your use case is testing, but what you test is not a typical use case with default selection as a base, it is arbitrary downsized system and application set that may, or may not work the same way as default installation.
Not infrequently the test is for whether unexpected consequences follow from non-default settings or usage.
Your change to packaging system: solver.onlyRequires = true in /etc/zypp/zypp.conf combined with difference in opinion between you and packager what belongs to Require, this can drop out some helper libraries, or applications that are present in a default set. Your system may have
systemS, plural, and many.
different properties then the one of average users, so your problem could be all between, only yours and affects everybody.
I test various things, one of which is for broken dependencies. Without solver.onlyRequires=true they escape discovery. e.g. https://bugzilla.novell.com/show_bug.cgi?id=820571
There is no "just" DND here. I didn't like DND decades ago when it was a new thing, and I don't like it now. It's poorly repeatable,...
Again, you have a problem with something that is not present for average user. You want repeatability to the last pixel
It's not about last pixel. It either fits, or it doesn't fit. Many times the panel's 30 or so px make a difference that completely changes the context. Sometimes the panel's content constitutes noise. For me, cut & paste works far more reliably and repeatably than DND.
The need is difficult to explain, so I won't try to do it in detail. It's all about laying out objects on the desktop for full screen screenshots in which the panel is not to be included in the shot
Not having panel in a screenshot is an extra demand that will not change quality of a screenshot; it will be more like dropping out an aid to
Actually it can make a big difference. Either it's good enough, or it's not; something fits, or it doesn't; it shows what it needs to show, or it doesn't; go/no-go.
people watching your image. Panel has its standard size in default installation, so it works as some kind of reference object. (Note: "some kind", not pixel precise reference.)
"Standard" panel size is invariably too short when desktop is significantly more than 1024x768, which is one of the recurring problems I have to deal with. I use other objects for reference, such as the fonts control panel, KCalc and/or the X Server panel served by kcmshell(4). The DND-only method of customizing panel height, not a limitation of KDE3, is non-repeatable without digging into ~/.kde4 while KDE4 session is closed.
Does KDE3 automatically update display? How often it scans for updated information?
Irrelevant. I do far more session starting and stopping than average. Updates happen often enough for my purposes.
Also, you can configure that panel to show only what you want to see.
Typically a default panel shows all I need to see. This thread spur happened because I tried to deviate from typical.
Don't be surprised that developers and other users have sometimes hard time to reproduce bugs and problems you can see.
In many cases I assume they have a hard time, or cannot. What I test typically requires testing in a very wide variety of conditions, to find what varies on account of different conditions. I know most use few or only one set of conditions, one screen, or maybe two, running at the screens' preferred or native resolution. Of course they cannot precisely reproduce if equipment or other limitations prevent matching the conditions I used. This is why my screenshots are often made in sets instead of individually, and why some things need to be readily repeatable. Most recently: http://fm.no-ip.com/SS/Fnt/CSSsmall/ for individual images http://fm.no-ip.com/SS/Fnt/CSSsmall/font-small-images.html to load all images at once -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org