Puppy In-House Development

[technosaurus]

Thanks for mentioning that. (I stumbled over mazewm in the proces, which is more interesting because it appears to have some awareness of colors.)

I had almost forgotten that goingnuts forked it with lots of improvements. Puppy's hazewm thread also has my hand-edited xpm tango icon sets and some config file example for mazewm.

@Iguleder - It wouldn't be difficult to add backdrop capability to Rox, but jwm is probably better since it can do solid colors (much lower resource usage), gradients or different images for each desktop which even the gtk2 version of rox cannot.

[Ibidem]

I just downloaded Slacko and replaced its applications (mtPaint, ROX-Filer, etc') with the static versions built against tinyxlib, GTK1 and musl - they work extremely well!

ROX-Filer 1.2.2 lacks the backdrop feature, so I set the desktop background using JWM. Besides this, everything seems fine - even custom icons and the pinboard (!).

Also, I got GTK See to work - I had to patch it to support libpng 1.5 and above.

Any reason for not using amigo's "ROX 1.3"?

Also, sometimes I wonder why people keep using libpng; if there's anything that caused the slow adoption of png outside FOSS software, their API and continuous breakage thereof would be it...libpnglite seemed neat, IIRC...
(it's not a minimal version of libpng, but a small library for reading and writing PNGs with a completely different API).


On a completely unrelated note, I pushed xutils to github (https://github.com/idunham/xutils).

If you're wondering why I'd bother with that: I'd rather not fetch a git tree for each of xkill, xlsfonts, xmessage, xfontsel, and so on, then have to install autoconf, run it, wait for a configure script that generally takes 2-4 times as long as the build and may not work, and so on. Most of the time, the X apps could have been built by just going "gcc -o $APP *.c", so the build infrastructure is grossly overweight. I wrote a simple POSIX Makefile that builds it all (may need -DHAVE_STRLCAT removed on uclibc/glibc systems; musl and dietlibc have strlcat.)
Additionally, I'm aiming to build an xutils-mcb, so that would need all the code I pull in to be in a single tree for optimal results...
Speaking of which, I noticed that there were 3 copies of an old "library" floating around; xlsfonts, xprop, and xwininfo all use dsimple.c/dsimple.h. So I grabbed one that worked with all three, and dropped it in.

[jamesbond]

On a completely unrelated note, I pushed xutils to github (https://github.com/idunham/xutils).

Thanks for that. I was just about to ask you for this but you're faster

If you're wondering why I'd bother with that: I'd rather not fetch a git tree for each of xkill, xlsfonts, xmessage, xfontsel, and so on, then have to install autoconf, run it, wait for a configure script that generally takes 2-4 times as long as the build

... and ./configure scripts don't have "-j6" flag . Thanks again.

[technosaurus]

@Iguleder - I hacked in a test for using literocks to manage trayapplets. To allow them to be pinboard_save()d, it eventually needs to be a included in the current_pinboard as a GList of something like:

• struct applets{
  gchar *applet; //icon file to display for applet
  gchar *lc; //app to run on left click
  gchar *rc; //app to run on right click
  gchar *tt; //tooltip text of file
  gchar *app; //optional control app
  }

btw... I also removed some more old pinboard style cruft.

Code: Select all

--- literocks-master/ROX-Filer/src/pinboard.c	2012-11-17 06:30:27.000000000 +0800
+++ literocks-applets/ROX-Filer/src/pinboard.c	2014-01-20 13:36:06.398520740 +0800
@@ -166,7 +166,6 @@ static gboolean scroll_event(GtkWidget *
 static gint icon_motion_notify(GtkWidget *widget,
 			       GdkEventMotion *event,
 			       PinIcon *pi);
-static const char *pin_from_file(gchar *line);
 static void snap_to_grid(int *x, int *y);
 static void offset_from_centre(PinIcon *pi, int *x, int *y);
 static gboolean drag_motion(GtkWidget		*widget,
@@ -333,13 +332,6 @@ void pinboard_activate(const gchar *name
 					current_pinboard->backdrop,
 					current_pinboard->backdrop_style);
 		}
-		else
-		{
-			parse_file(path, pin_from_file);
-			info_message(_("Your old pinboard file has been "
-					"converted to the new XML format."));
-			pinboard_save();
-		}
 		g_free(path);
 	}
 	else
@@ -1445,6 +1437,62 @@ static void backdrop_from_xml(xmlNode *n
 		current_pinboard->backdrop_style = BACKDROP_TILE;
 }
 
+static void leftclick(GtkStatusIcon *si, gpointer s){
+	g_spawn_command_line_async(s,NULL);
+}
+
+static void rightclick(GtkStatusIcon *si, guint b,guint a_t, gpointer s){
+	g_spawn_command_line_async(s,NULL);
+}
+
+/** refreshes the status icon image from file if it changes */
+static void refresh(GFileMonitor *monitor, GFile *file, GFile *to_file, GFileMonitorEvent event, gpointer si){
+	gtk_status_icon_set_from_file(si,g_file_get_path(file));
+}
+
+/** gets a new mouse over tooltip from file if it changes */
+static void updatetooltip(GFileMonitor *monitor, GFile *file, GFile *to_file, GFileMonitorEvent event, gpointer si){
+	gtk_status_icon_set_tooltip_markup(si, g_mapped_file_get_contents(g_mapped_file_new(g_file_get_path(file), FALSE, NULL)));
+}
+
+gchar *applets; //hack to prevent having to free/reload every pinboard reload
+static void applet_from_xml(xmlNode *node)
+{
+	gchar *applet,*tt,*lc,*rc,*app;
+	GtkStatusIcon *si;
+	
+	applet = xmlNodeGetContent(node);
+	g_return_if_fail(applet != NULL);
+	g_return_if_fail(g_strstr(applets,applet) != NULL);
+	applets = g_strconcat(applets,applet,NULL);  
+	if (g_file_test(applet, G_FILE_TEST_EXISTS)){
+			si = gtk_status_icon_new_from_file(applet);
+			g_signal_connect(g_file_monitor_file(g_file_new_for_path(applet),
+				G_FILE_MONITOR_NONE, FALSE, NULL), "changed",
+				G_CALLBACK(refresh),(gpointer) si);
+	}else return;
+	
+	
+	tt = xmlGetProp(node, "tt");
+	if (tt && g_file_test(tt, G_FILE_TEST_EXISTS)) {
+		gtk_status_icon_set_tooltip_markup(si,
+			g_mapped_file_get_contents(g_mapped_file_new(tt, FALSE, NULL)));
+		g_signal_connect(g_file_monitor_file(g_file_new_for_path(tt),
+			G_FILE_MONITOR_NONE, FALSE, NULL), "changed",
+			G_CALLBACK(updatetooltip),(gpointer) si);
+	} else if (tt) gtk_status_icon_set_tooltip_markup(si, tt);
+
+	lc = xmlGetProp(node, "lc");
+	if (lc) g_signal_connect(G_OBJECT(si), "activate", G_CALLBACK(leftclick),(gpointer) lc);
+
+	rc= xmlGetProp(node, "rc");
+	if (rc) g_signal_connect(G_OBJECT(si), "popup-menu", G_CALLBACK(rightclick), (gpointer) rc);
+
+	app = xmlGetProp(node, "app");
+	if (app) g_spawn_command_line_async(app,NULL);
+
+}
+
 /* Create one pinboard icon for each icon in the doc */
 static void pinboard_load_from_xml(xmlDocPtr doc)
 {
@@ -1464,6 +1512,11 @@ static void pinboard_load_from_xml(xmlDo
 			backdrop_from_xml(node);
 			continue;
 		}
+		if (strcmp(node->name, "applet") == 0)
+		{
+			applet_from_xml(node);
+			continue;
+		}
 		if (strcmp(node->name, "icon") != 0)
 			continue;
 
@@ -1506,43 +1559,6 @@ static void pinboard_load_from_xml(xmlDo
 	}
 }
 
-/* Called for each line in the pinboard file while loading a new board.
- * Only used for old-format files when converting to XML.
- */
-static const char *pin_from_file(gchar *line)
-{
-	gchar	*leaf = NULL;
-	int	x, y, n;
-
-	if (*line == '<')
-	{
-		gchar	*end;
-
-		end = strchr(line + 1, '>');
-		if (!end)
-			return _("Missing '>' in icon label");
-
-		leaf = g_strndup(line + 1, end - line - 1);
-
-		line = end + 1;
-
-		while (g_ascii_isspace(*line))
-			line++;
-		if (*line != ',')
-			return _("Missing ',' after icon label");
-		line++;
-	}
-
-	if (sscanf(line, " %d , %d , %n", &x, &y, &n) < 2)
-		return NULL;		/* Ignore format errors */
-
-	pinboard_pin(line + n, leaf, x, y, NULL);
-
-	g_free(leaf);
-
-	return NULL;
-}
-
 /* Write the current state of the pinboard to the current pinboard file */
 static void pinboard_save(void)
 {

This can replace all tray applets using minimal resources similar to my simple icon tray app, but using rox as the controlling process

Edit: this is the format to add to the PuppyPin file
<applet tt="/tmp/mytooltip" rc="geany" lc="abiword" app="app2updateImage" >
/usr/share/pixmaps/galculator.png</applet>

[Iguleder]

I might fork 1.2.x and do that feature stripping. I also want to change those ugly icons.

[technosaurus]

I might fork 1.2.x and do that feature stripping. I also want to change those ugly icons.

I did a lot of work on an xpm version of the tango icon set (which could be built in to gtk1 apps).
for gtk1 we could keep the panels and add a file watch boolean property to icons so that they could be used as desktop widgets or tray applets or to popup a gtkdialog1 startmenu (for wms without a tray or trays without a applet area or swallow capacity)

[NeroVance]

I am curious about how BusyBox would be facing bloat, but you never know.

I'll look into gtk1, perhaps that could be an interesting part to fork if there are any bugs that need patching, or anything that would reduce stability and security. Because I strive for an era where Puppy is renowned for Legendary Robustness

I don't even mind the look of gtk1 apps, maybe it's because I like the Motif look. Kinda strange to hear from a young fella like me, but eh, it's what Tk looks like by default, and I think that it would be good for Tcl devs like myself to have an environment where most things also look like Tcl/Tk

Hell, add some of that multiuser shtick that folks seem to just love other distros for, and you'd get a rock solid workstation or server (terminal server or such) environment. But I'd probably just do a Puplet related to that.

Anyway, I like some of these ideas, and I do like the idea of giving cheetah-fast speeds to older systems, and keeping the good times rolling.

- Nero Vance

[Iguleder]

A small progress update - I wrote a simple union file system on top of FUSE and now I'm writing a new init script which mounts a union of a SFS and a writable layer.

It's similar to a frugal installation of Puppy, but very simple and doesn't use Aufs/UnionFS. These projects prove to be problematic because development seems slower these days - I think an in-house union file system is the way to go, since overlayfs doesn't allow dynamic addition or removal of layers.

EDIT: works partially. This thing boots and reaches a shell - all applications work, but links (including /bin/sh) don't work. It's an issue with the file system - I'm investigating it.

EDIT 2: fixed the problem. Now, there's another one - fc-cache fails to write its cache files.

EDIT 3: the problem should be gone now. When the file system is mounted, the read-only layer directory tree is created under the read-write layer. Then, any mkdir() call creates the directory under the writeable layer.

[Iguleder]

Just rewrote luufs - now, directories are created dynamically, as with Aufs and UnionFS. Hard links are not supported because they're very hard to implement in user-mode, so fc-cache fails to create links under /var/cache/fontconfig. Mouting another file system there solves this problem, so it's fine.

Generally, the whole thing looks good. It's 63 MB, extremely lighweight and fast, boots like Puppy (a SFS with a layered file system), has a good selection of fonts and supports UEFI. It should be more robust than Puppy and Quirky, because luufs does not allow files to be replaced, by design (e.g a malicious package cannot override /bin/dropbear).

Also, instead of doing switch_root or pivot_root, the layered file system is used as a chroot environment. Processes like init and syslogd run in the real file system root, so they're more isolated. In fact, the user runs in a "sandbox". This makes it possible to implement cool features, like dynamic creation of a user for each application, through luufs (security to the extreme! ).

Now, I want to test package management using lpackage (my simple GTK1 package manager frontend), inside luufs.

EDIT: boots on my Eee PC 1001PX and on a Lenovo G580 laptop, with UEFI. Memory consumption is pretty low and X works. Now, I'm trying to get WiFi to work.

EDIT 2: added WiFi support and made the building process more efficient - it's 60 MB. luufs works well - now I'm working on package management.

EDIT 3: many improvements since my last update - I added Conky, bftpd (for file sharing), x11vnc and more. Overall, it looks pretty good - now I'm adding "boot codes", so the user can specify the partition changes are saved to. Then, I want to add support for a "pfix=copy" mode.

[B.K. Johnson]

What happened here? As soon as you guys have something working, you high-tail it out of here to play with your goodies all by yourself?
A disappointed kibitzer.

[Iguleder]

Don't worry, my friend. I'm working on Puppy integration - I'm trying to build a barebones GTK1-based Slacko.

EDIT: fixed two crashes in Beaver, so it works now.

[B.K. Johnson]

Happy to hear still a work in progress.
Your reputation is tops, so eagerly awaiting!

[Iguleder]

Exciting news! Following discussions in the woof-CE mailing list, yesterday I started working on a package manager written in C, with libarchive.

It has a simple package format that combines .tar.xz and INI files, for metadata. It also has a checksum and adding digital signatures won't be too hard.

So far, it's capable of installing a single package. Once I add repositories and dependencies support, I want to build a debootatrap-like script on top of it, as a versatile and portable tool which could replace woof-CE.

EDIT: added full support for dependency resolution. Now I'm doing some code cleanup, adding a configuration file and setting up a real repository for testing.

[Ibidem]

Just finished backporting the latest CVE fixes for libXfont (CVE-2014-0209 through CVE-2014-0211), realizing I'd missed a few older CVEs which I proceeded to backport (CVE-2011-2895, CVE-2007-1351, CVE-2007-1352).

I've applied them to Iguleder's tree in the branch "blob"; to get the CVE fixes and no more of my changes, do this:

Code: Select all

git checkout -b blob
git add remote ibid git://github.com/idunham/tinyxlib
git pull ibid blob

[Iguleder]

Will do

EDIT: merged. Thanks!

[technosaurus]

I found a bunch of patches for kdrive/tinyx at:
cgit.openembedded.org/openembedded/tree/recipes/xorg-xserver/xserver-kdrive

[NeroVance]

I found a bunch of patches for kdrive/tinyx at:
cgit.openembedded.org/openembedded/tree/recipes/xorg-xserver/xserver-kdrive

Now you're talking. Get that along with some decent lightweight toolkits, perhaps some of us can take Woof, and build either on top of or underneath it all, a Secure and Reliable foundation from which a new distro could be built.

These days, I've gained an interest in good old unix, kinda want to see how far I could go with making a variant of Puppy into something like such.

[amigo]

How does one clone that patch repo, or is there a tarball?

[NeroVance]

How does one clone that patch repo, or is there a tarball?

I don't use Git, but I figure as it says cgit.openembedded.org I would suggest looking up cloning from git.

Could be quite useful to have indeed.

[technosaurus]

may be able to use wget in spider mode on the plain files ... I forget the wget flags for that but the plain files are at
http://cgit.openembedded.org/openembedd ... rg-xserver