>The problem is just that they're very large and complex files,
>from
>the looks of it. Lots of shapes, lots of gradients, lots of
>(unnecessary,
>IMNSHO) clipping and masking. The SVG icon files that ship with
>Trinity are mostly ten percent or less of that size, and much less
>complex. Even in Inkscape on my quad-core, the LO files take
>several seconds longer to load than, say, the old
>crsc-app-openoffice.svgz icon that ships with our Crystal theme.
>
>The optimum solution would be to clonk whoever created the files
>over the head with a blunt object and get them to redo them as
>straightforward stacks of shapes and gradients without all the
>unnecessary file-bloating crap.
With your understanding of svg file formats, do you feel
comfortable contacting the LO team and ask them to consider
releasing palatable icons?
>The code to look at in TDE is
>the stuff related to clipping, masking, and cloning in SVGs, but
>it
>may never be possible to make these files open acceptably fast on
>a slow machine. They're just not made with that in mind.
This likely is the best solution. Use more recent svg algorithms
that do not suffer the same rendering problems. What algorithms are
being used in other desktops? --- Take advantage of GPL code
sharing practices. :-)
>The only workaround that occurs to me at this time is overwriting
>the files with something simpler after LO is installed, or else
>deleting the SVGs outright and (hopefully) forcing the system to
>fall back on the raster versions of the icons.
A challenge to that idea is the LO devs name the icons with the LO
release number in the file name. Maintaining our own png icon set
would be overwhelming because with each LO release a new Trinity
icon set is needed. Not to mention all past LO icons sets as well
because they have included the release number in the file names for
a long time now.
>I can attempt to redraw the icons to produce substantially
>identical
>smaller SVGs to overwrite them with, but it would take a while,
>so I'm not going to start until and unless we decide that this is
>the way to go.
Does not sound productive at the moment. :-)
BTW, I used Trinity Gwenview to convert the 8 LO svg files to
256x256 png files. The png files all opened much faster in image
viewers. Yet again, the challenge is the LO release number is part
of the file name. Thus converting the images to png is doable as
proof-of-concept, but impractical to implement.
Darrell
>Is there a way to continue an interrupted git checkout?
Good question. I'd like to know too, especially after my recent
weekend debacle with git.
Darrell
Hi all!
Is there a way to continue an interrupted git checkout?
Nik
--
Please do not email me anything that you are not comfortable also sharing with
the NSA.
Dr. Nikolaus Klepp
Einnehmerstraße 14
A-4810 Gmunden
Tel.: +43 650 82 11 724
email: office(a)klepp.biz
All,
In bug report 1591, we noticed Trinity struggles to open the svg
files packaged with LibreOffice. Originally this was noticed when
trying to open the Office submenu, but general perusing of the svg
files reveals a slowdown.
As the svg files are XML (text) files, would one of you graphics
wizards look at the LO svg files for possible reasons why Trinity
struggles with the files?
Even on a dual core system the files need a few seconds to open
whereas other svg files open immediately.
The LO svg files get installed to
/usr/share/icons/hicolor/scalable/apps.
Thanks! :-)
Darrell
Looks like this tiny nightmare might be behind me. I don't know
what happened, but some combination of git clone, git reset --hard
HEAD, git clean -dxff, git checkout master, and manually copying
missing admin and cmake .git folders seems to have gotten the
switch_all_submodules_to_head_and_clean script to remain calm and
quiet and stop terminating.
No more fatal messages.
I updated my wrapper script to tee the output of
switch_all_submodules_to_head_and_clean script to a log.
Took 3 hours to clone tde-i18n --- something not right about that.
What a wasted day --- back to building packages and testing!
Darrell
>It is strange to me, how could git folder just lose.
>For tde-i18n would "lost" had to take some time.
Strange to me too and I've had all day to think about a root cause.
I know of only one thing I might have done to inadvertently delete
the folders. Yet the conundrum of even that possibility is every
single .git folder should have been deleted throughout the entire
tree. That is not the case. Further, stand-alone files such as
.gitmodules would have been deleted too, but those files are intact.
Other than the .git folder the remainder of the tde-i18n module
tree is intact.
>Have you tried git fsck on the modules that are okay for now?
Yes. I also tried git clean -f.
Running 'git pull' results in an 'Already up to date' message and
no errors. When I run the switch_all_submodules_to_head_and_clean
script then the proverbial hell breaks loose because some of the
modules are missing the respective .git folders.
At this point I just want my local tree updated far more than
solving the mystery of what happened.
Further frustrating is the Trinity git server is really slow with
respect to cloning. According to the progress bar, I'm downloading
at about 80-90 KiB/s. At 1.1 GB and a 3 Mbps connection, the tde-
i18n module should finish loading in about 50 minutes. I'm still
waiting 90 minutes later and the tde-i18n clone is only 64%
complete. At this rate, cloning the entire tree might take days. :-(
Darrell
>> Is there a way to download just the .git directory? Or pull the
>> .git directory from the top level of the sources?
>
>Are you possibly seeing the result of a hardware failure !
>I'd run memcheck... Then try fsck on the hdd.
No, nothing like that. I have a backup clone of the entire drive
and the same modules are missing the .git folders there too. Likely
this has been happening for several days but as I don't sit and
watch the script running I would not have noticed the fatal error
messages.
The .git folders have simply disappeared. How will remain a
mystery. Not all have disappeared, just some. Murphy's Law, one of
the affected folders has to be !#%* tde-i18n, at 1.1 GB.
I'm slowly rebuilding affected modules by running git clone in a
clean location, but this is not my idea of how to spend the day. :-(
The entire GIT tree is 5.5 GB, which with my ISP connection, would
take more than 4 hours --- at optimal connection speed. Probably 6
hours or so, because many folks on this small rural ISP network are
indoors during the cold winter night streaming movies....
I'd like to find a way to just snag the missing .git folder, but no
such fortune yet on the web.
Darrell
>> The latest fatal is tde-i18n, the biggest pig module of them
>all.
After waiting for several hours for tde-i18n to update, the
directory still won't sync when I run the
switch_all_submodules_to_head_and_clean script.
Now tdeadmin is missing the .git directory.
I have no idea what is happening here but one-by-one the module
.git directories are disappearing.
Is there a way to download just the .git directory? Or pull the
.git directory from the top level of the sources?
Darrell
>With git >= 1.7.8 are submodules cloned into .git/modules and in
>submodule folder is only .git file.
I have no idea what happened or why only now everything is
exploding. That said, looks like possibly my tree has been
corrupted for a while. I have no idea what is the catalyst to start
the recent events.
Seems right now I have a mish-mash mixture of some modules with a
.git directory and some modules with a .git file pointing to a
respective .git directory in the root of the source tree.
Some modules have no .git directory in the module or in the root
.git directory. Like right now, tde-i18n is void of any .git
directory in either location. That is 1.1GB of files I don't want
to have to download when all I need is a respective .git directory
somewhere.
Running git pull does nothing to recreate the .git directory
somewhere.
Is there a fix for this?
Or, is there a way I can update my tree to move the .git folder
that exists in each module to ../../../.git/modules/ and create an
appropriate .git file in each module that points to
../../../.git/modules/{modulename}?
Darrell