Page 5 of 7

Posted: Tue 30 Mar 2010, 23:38
by ttuuxxx
The only 2 things I don't like about Fotoxx is that it doesn't batch resize, now that would e a feature and a half, and also when it displays transparent png backgrounds on icons, the background is 100% solid BLACK!!, it should be transparent.
ttuuxxx

bellow is a example fotoxx 9.8.1 VS gpicview , look at the background
also muggins your fotoxx 9.8.1 worked on 2.14x, but 9.9 has a glibC issue and won't run, did you compile it differently? strange that it didn't complain before and now it does.
/usr/bin/fotoxx: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/bin/fotoxx) <-- V9.9


and when I run the older one you packaged and works fine other than transparencies , I get
sh-3.00# /usr/bin/fotoxx
fotoxx v.9.8.1 2010.03.22
language: en_US
using 1 threads
exiftool sh: exiftool: command not found
xdg-open 1.0.1
sh: ufraw: command not found
sh: exiftool: command not found
exif_get failed


ttuuxxx

Posted: Wed 31 Mar 2010, 01:01
by muggins
Yes, I did compile it differently, using Technosaurus's g++ switches. Funnily though, the fotoxx-9.9.pet package was 3k bigger than if I just used Kornelix's Make. Anyway, I've recompiled using the latter, and re-uploaded...see if that works.

Regarding transparency issue...maybe contact the developer?

Posted: Wed 31 Mar 2010, 01:49
by ttuuxxx
sorry muggins it didn't work, I'll just upload it here for safe keeping for others who have a glibc version issue.
ttuuxxx

Posted: Wed 31 Mar 2010, 06:00
by technosaurus
which set of flags did you use? the bottom set was just a reference base on the standard set - the top set is better for size

Edit - the *sections flags are unnecessary now that freeimage is no longer a dependency - those just helped to eliminate unused sections when compiling against static libfreeimage (but it will make code slightly larger, so it is a gamble as to when to use and when not to)

Posted: Fri 02 Apr 2010, 03:24
by muggins
technosaurus:

yes, I used the top set.

ttuxxx:

I tried compiling on p216, which I think has same kernel as p214, but
no luck. Some of the function calls, that fotoxx-9.9 has, don't seem
to be covered by available libs on p216. Or at least AFAIK.

Posted: Fri 02 Apr 2010, 13:05
by technosaurus
now that we don't need libfreeimage, this would be better:

Code: Select all

g++ -pipe -combine -Os -momit-leaf-frame-pointer -fomit-frame-pointer -fmerge-all-constants -mpreferred-stack-boundary=2 -march=i386 -mtune=i686 -Wl,-O4,-Os,-relax,--sort-common,--as-needed,-s  -Wall `pkg-config --cflags gtk+-2.0 gthread-2.0` -o fotoxx fotoxx-9.9.cpp zfuncs.cpp -D "DATADIR=\"/usr/share/fotoxx\"" -D "DOCDIR=\"/usr/share/fotoxx\"" -D "BINDIR=\"/usr/bin\"" `pkg-config --libs gtk+-2.0 gthread-2.0` -ltiff
also you can discard my previous patch, since it has been fixed in a better way upstream

installing ufraw and exiftool should remove those errors
Perhaps petget needs a patch for "recommends"?

if the binary is still smaller with the normal method then he has some pretty clean code... still not quite clean enough to use -fwhole-program though, but I think that is because of C++ and the gcc version (when it works, it cuts about 10% off of mtpaint, jwm and the couple other C programs I have tested)

Posted: Thu 08 Apr 2010, 23:47
by muggins
Uploaded v10.0.

Yes Technosaurus, you're right, it does compile smaller with the above flags, cheers.

Posted: Fri 09 Apr 2010, 03:03
by ttuuxxx
lol here's muggins latest with a new folder icon and I removed the locals and docs, much nicer size, works on quirky :)
ttuuxxx

Posted: Fri 09 Apr 2010, 03:10
by technosaurus
it contains docs and locales, the binary is only 122kb

Posted: Fri 09 Apr 2010, 04:45
by ttuuxxx
technosaurus wrote:it contains docs and locales, the binary is only 122kb
lol daaaaa should of check before posting, lol
ttuuxxx

Posted: Tue 27 Apr 2010, 09:39
by muggins
Uploaded v10.2.

Posted: Sun 16 May 2010, 00:13
by dawnsboy
Hmmm... What to do about the nasty exiv tool warning. Tried the various methods suggested in this thread to no avail.

Posted: Sun 16 May 2010, 10:34
by muggins
dawnsboy,

which version fotoxx & which version puppy?

Posted: Sun 16 May 2010, 23:31
by dawnsboy
The latest version of fotoxx that you have posted (10.2) on Puppy 4.31.

Posted: Fri 21 May 2010, 00:05
by muggins
dawnsboy,

I mistakenly deleted the original exiftool .pet, from the first page, but I've now re-uploaded it. Running fotoxx, on the commandline in a fresh p431 install, after installing exiftool, ufraw & libgtkimageview, I get:

Code: Select all

# fotoxx
fotoxx v.10.2  2010.04.23
language: en_US 
using 1 threads 
exiftool 7.72
ufraw 0.16
EXIV2 0.16
JPEG enabled.
TIFF enabled.
FITS disabled.
ZIP enabled.
/root/.fotoxx/assigned_tags  - not found 
/root/.fotoxx/tags_index  - not found

Posted: Fri 21 May 2010, 11:04
by dawnsboy
Thanks muggins! I get the same results.

Posted: Mon 19 Jul 2010, 11:48
by abushcrafter
The has been loads of changes with the last 10 releases. Are you making new PETS? If not will the be any problems with the binarys in the DEB from the website of fotoxx?

Posted: Tue 20 Jul 2010, 22:06
by muggins
I'm aware there's newer releases, but just been moving around a bit. Will try & upload latest in day or so. Debs should work OK, although I haven't tried them. The only function that probably wouldn't work is burning images to CD, as this needs brasero. I did have this workiing with pburn, but i'm not sure it will work with latest source code.

Posted: Wed 21 Jul 2010, 09:42
by abushcrafter
Ok and thank you.

Posted: Thu 22 Jul 2010, 05:00
by muggins
Will take a bit longer as I have to work out how to get Exiv-tool to work with Lupu's perl setup. Any perlers here that know a simple way of compiling Exiv-tool so that it's compatible with perl's location with pup4, and with different location in lupu? otherwise I need to compile a different version for lupu!