Folder View transperency

[James Richard Tyrer]

Although I do not think that I need to apologize for being human, I 
would like to take this opportunity to revise and extend my remarks.

James Richard Tyrer wrote:
> This is not going well.
> 
This should have been taken as a cautionary statement.  But, it is not 
clear.  I should have said more to express my frustration trying to do 
what I thought should have been a simple task and that the comments I 
made should be taken in that context.  My apologies.

> I edited the file:
> 
> $KDEDIR/share/apps/desktoptheme/Aya/widgets/translucentbackground.svgz
> 
> to reduce the transparency to 75%.  This is not simple since it was 
> necessary to change the value for many elements.
> 
> I would really rather use "Air" but that file in it is a $&#**^% mess. 

Probably not the best choice of words.  If I had not been having a bad 
day and was not seriously frustrated, I would have used more objective 
terms.  Still I do have to say that the file in Air has serious issues 
and could use some more work.

> Specifically, there is a lot of stuff in the file that isn't meta data, 
> isn't definitions, and isn't paths or shapes.  The file isn't a legal 
> SVG file as it doesn't open in Squiggle.  It also doesn't display 
> correctly with the KDE3 KDE Plugin.  It isn't a proper InkScape file 
> either since if you clean it or save as a plain file, it doesn't work 
> any more.
> 
Unfortunately, these facts are true -- although the issue with Squiggle 
could use some more elaboration.

<SNIP>
> 
> Part of this could be improved if there were a way to manage 
> translations and transforms in ink scape.  But, much of it appears to be 
> that some of the artists simply don't know how to use their SVG tools 
> (or just don't bother with such details).
> 

To make this clearer, I fault InkScape for much of the problem.  It is 
only at release 0.46 and it has many issues  However, this means that 
users of it need to know more and to learn workarounds.  This also 
requires more time and thought than might be the case if it was 1.0.1.

Some hints from a draftsman that knows more about how to use InkScape 
than his limited ability as an artist.  I am willing to provide 
assistance but I have to say that it does not appear to be wanted.

IMHO, before committing an SVG file, made with InkScape, for release, 
the author should make a copy and:

	File -> Vacuum Defs

to remove *some* unneeded definitions.  This is just a matter of 
remembering to do it.

Unfortunately, there may still be issues.  I have found many SVG files 
(mostly icons) that contain groups of 0 files.  These should be removed. 
  To do this, you have to scan through the groups and remove those that 
don't contain anything.  One does have to bother to to this, and it is a 
bother to do it -- it can take considerable time.  IMHO, these should be 
removed when Defs are vacuumed -- this _is_ an InkScape bug.

There is no solution for the unnecessary or unwanted transforms.  All 
that can be done is to do part of it over.

This specific file also contains 2 SVG "text" objects which I do not 
understand at all.

There is also a minor issue with the fact that InkScape doesn't 
correctly round numbers.  If you uncompress an SVGZ file and open it in 
an editor, you will find things like:

	-5.8042212e-6,14.999971

It should be obvious that this should be:

	0, 15

The only workaround for this InkScape bug is to use a text editor.  The 
first problem should be simple to fix (in InkScape): numbers with an 
absolute value less than a certain small value are replaced with "0" 
(underflow fixup).  The second one is not as simple although I note that 
the math to solve this problem has been done.  It refers to the 
preferred values when converting from binary float to decimal float.

Finally, I always converted SVGs made with InkScape to Plain compressed 
SVG files before I committed them.  This _should_ only remove InkScape 
specific meta data from the file.  When I did this with this Air file, 
the file was seriously corrupted and no longer displayed the same.  This 
could be an InkScape bug.  Still, I believe that a developer is 
responsible for their work.  IMHO, this needs to be fixed somehow.  If 
it is an InkScape bug, then the artists need to develop a workaround for it.

And, as I said, there are issues with opening the file in Squiggle that 
need some elaboration.  Since W3C has not provided a validator for SVG, 
the best test, currently, is to open the file in Squiggle:

http://xmlgraphics.apache.org/batik/tools/browser.html

The Air file in question fails this test.  However, there are two parts 
to this issue.

The first is that this is apparently not a legal SVG file and some of 
the shadow is not displayed.  Is this an InkScape bug, or a problem with 
the file.

The second issue is something that I failed to understand.  My (mostly) 
bad here except that I have to say that if I hadn't had the other 
problems that I probably would have figured it out.

> Perhaps with such SVG files, the feature which I want (adjustable 
> transparency of transparent widgets) wouldn't be possible.
> 
It appears that everything in the file in question except for the 
shadows is white.  I'm not sure that this is a good concept, but the 
results are nice.  I do have to say that if the "Opacity, &" in the 
object had also been used that it would have been more obvious.  It 
appears to me that if Opacity is going to be user adjustable that it has 
to be done this way.

In closing, I note that although I have been accused of making a 
personal attack here, this is not the case.  It is unfortunate when any 
criticism that is not personal (no matter how stated) is taken this way 
because it detracts from the task that we all need to work on which is 
the continued improvement of the product.

My only interest is the improvement of the product.  I am willing to try 
to assist anyone that shares this interest.

-- 
James Tyrer

Linux (mostly) From Scratch

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.