Arch GUI tools & prog. language

Question

This is a continuation from topic:
http://bbs.archlinux.org/viewtopic.php?t=2257
contrasutra wrote:What's to stop us from porting the Mandrake or Redhat System tools?
rasat wrote:I would like to have a choice to use GUI tools...
For my information, what language is easy to learn and makes nice GUI application?
farphel wrote:If your end goal is to provide gui tools for Arch, then you need to first examine what languages/toolkits are included in 'base' so that your gui tools could be included in the mini-iso.....
If your guis are post-install, and you don't care if they were to make it into base/current, then the sky's the limit.
It would be interesting to know....
1. what system tools other distros are using.
2. what tools could be useful for Arch and also if possible to modify if needed.
About programming language for Arch apps, in general, can it be said...
1. Shell Script for Arch CD installer
2. Curses and Tcl/Tk for base
3. Any language for post-install
About Python, is it possible to run a "stand alone" application without installing the python package? .... to develop apps to include the reguired python files and libs.

Answer 1

rasat wrote:1. AL's wxPython is depended on wxGTK, for what purpose? In my compiled wxPython, I didn't install wxGTK.
AFAIK, wxPython only requires GTK+ 1 and it's dependancies. wxGTK shouldn't be needed.
rasat wrote:
RdsArts wrote:Python is a byte-code language, you can't compile it into a stand-alone app yet AFAIK.
2. Would it be possible to make one "mini" Python package for running Py apps only? Why I am asking, its not "fair" to ask users to install the 7.2MB Python package just for the sake of running an Py application e.g. 100KB.
Maybe, but I doubt it. AFAIK, most of what you'd "cut" would be modules which other programs need. There are some demo programs, but I can't imagine that they take up more then 500K.
Plus, if your doing a GUI, your going to pull large dependancies anyway.
rds@hpavil
(/var/cache/pacman/pkg)
05:29 AM - $> ls -l glib-1.2.10-3.pkg.tar.gz glib2-2.2.3-1.pkg.tar.gz gtk-1.2.10
-3.pkg.tar.gz gtk2-2.2.4-1.pkg.tar.gz pygtk-2.0.0-2.pkg.tar.gz kdelibs-3.1.4-1.pkg.tar.gz qt-3.2.3-1.pkg.tar.gz
-rw-r--r-- 1 root root 181K Jan 1 21:20 glib-1.2.10-3.pkg.tar.gz
-rw-r--r-- 1 root root 883K Jan 1 21:19 glib2-2.2.3-1.pkg.tar.gz
-rw-r--r-- 1 root root 1.6M Jan 2 16:19 gtk-1.2.10-3.pkg.tar.gz
-rw-r--r-- 1 root root 4.3M Jan 1 21:19 gtk2-2.2.4-1.pkg.tar.gz
-rw-r--r-- 1 root root 15M Jan 15 03:30 kdelibs-3.1.4-1.pkg.tar.gz
-rw-r--r-- 1 root root 561K Jan 1 21:23 pygtk-2.0.0-2.pkg.tar.gz
-rw-r--r-- 1 root root 15M Jan 15 03:28 qt-3.2.3-1.pkg.tar.gz
rds@hpavil
(/var/cache/pacman/pkg)
05:29 AM - $>
Both GTK+ 2 and QT are rather "beefy" as-is. And we're not even going to talk about KDElibs. Compared to 15M for QT proper, 7M for Python isn't exactly massive.
Also, if someone's going for a GUI, they'll most likely have GTK+2 or KDE already installed, and thus it'd make Python's size small in comparison. Compare 7M for Python to XFree at ~54M, most of which IIRC is taken up in drivers and locale files which most users will never use, and it's not even close to being the largest dependancy.
Plus, with Python you gain the benefits of more stable code that can be developed in a very fast manner. It's fairly hard, IMHO, to quantify that and judge it against the relatively small size of the Python package proper.
Besides, if more people would start using Python (like they should ) installing it "for one app" would be mitigated.
*/rant*