ttuuxxx wrote:hi caieng a little history lesson

VLCGTK is frontend to vlc, around 6 yrs ago vlc had a gtk gui but was discarded for a wxgtk gui, which blewup the overall size by 200%.
Then they dropped the wxgtk gui for a qt gui which triples the size of the VLC package Due to all the library not found in a default puppy, that is why we usually go with gxine, because puppy does have the library's and plays just about all the same formats as vlc, but with a great savings in file size, also we use mplayer, which is a bit bigger than gxine, but does provide a bit more formats.
Now back to vlc, the pet I provide is a vlc package I made for 4 series and removed the very large wxgtk gui and all the wxgtk libs. reducing the package from around 9MB to 2.6MB.
Forum member sc0ttman made a nice gui to work with VLC backend at 55kb.
So that is why you need the gui and also the vlc pet to run it.
hope that helps,
also I think if you want the regular vlc with a qt gui you'll find it in the puppy package manager in 5.2
ttuuxxx
Thank you very much, ttuuxxx, for this noteworthy explanation, much appreciated.
And thanks also to you, and to sc0ttman for your terrific efforts to get VLC to run on Puppy Linux.
I don't know, or understand, the distinction between "qt gui", which you associate with "regular VLC", and the ? ??? which you and Sc0ttman use.
I will try to reinstall Wary 5.0, using your two links to install VLC.
Testing: Is your implementation identical in functionality and timing with the VLC used elsewhere, e.g. with Windows and other Linux distros? Do those other distros use QT or GTK?
Philosophy lecture:
reducing the package from around 9MB to 2.6MB
.
Are you teasing me, here, ttuuxxx?
Maybe fifty years ago, when I first began using computers, that statement would have held some significance, but when one is routinely installing Linux on PIII's with half a gigabyte of memory, the distinction between nine megabytes and three megabytes is utterly insignificant.
Even the smallest USB flash memory stick, today, is a gigabyte in size.
Is there a real world testing scenario that can measure a significant time difference between application 1a, requiring 9 megabytes, and application 1b requiring 3 megabytes? Do you suppose that when browser ABC is loaded into memory, requiring 10 seconds, and browser DEF is loaded into memory, requiring 7 seconds, that then, browser ABC will turn out to have 6 megabytes more in size than browser DEF?
When I run SeaMonkey (1.1.13) on Windows 98 it takes 2 seconds to load.
When I run SeaMonkey (2.0.11) on Linux, it takes 7 seconds to load.
Do you imagine that the explanation for the difference in time between the loading of these two Mozilla browsers has something to do with the dramatically increased SIZE of the newer Mozilla browser?
Well, maybe you are correct, and I am wrong, what do I know? nothing.
In my opinion, as one wholly ignorant, size has very little to do with this impressive delay in loading the browser under Linux. I should compare the two versions with XP. My guess is that they will both take about the same time to load. In other words, without understanding anything at all about the design of the OS, I imagine that the reason for the much faster instantiation of Sea Monkey on Win 98 compared with Linux or XP, is not because the older, obsolete Sea Monkey is so much smaller in size than more recent, more bloated, versions of the same browser, but rather because the obsolete operating system responds to the user's input far more efficiently. Compare the time needed to fly from Sydney to Perth today, versus ten years ago--the airplanes are slicker and better than ten years ago, but the delay getting through security adds an extra hour to the total travel time.
I have read, often on the internet, how much FASTER Chrome is, than Firefox. How much faster Midori is, than Konqueror.
NONSENSE.
In my testing, with this real world application, internet radio stations, the times needed for HEARING the music played, upon clicking on one of the three non-proprietary formats: mp3, ogg, or aac+,
is the same, for Chrome and FireFox, while
Konqueror, king of bloat, is measurably FASTER. "Light weight" Midori, brain dead, waits for the user to signal with a second click of the mouse, because, unlike all the other browsers, it has no facility to remember to always forward the input to VLC, and thus demands that the user instruct it, every time it is invoked.
http://www.listenlive.eu/classical.html
How often have you read that Opera is lightweight and FAST?
I encounter such assertions daily, yet, in my experience, with the internet radio station testing algorithm, Opera is consistently 20% slower than Firefox.
So, conclusion, in my opinion, SIZE is
relatively insignificant, in estimating performance. Saving a handful of megabytes, in an environment addressing gigabytes, is a bit like saving pennies by turning off the engine at a red light, but spending a fortune on fuel, because of inefficiencies in the engine design.
Thanks again for your helpful messages.
CAI ENG