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
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
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.
> 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
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;
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:
for individual images
to load all images
"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(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org