Puppy In-House Development

[technosaurus]

Can I urge you all again to make these sources completely independent. All through the sources there are references to installed header files which break the build when doing it on a modern system. I started once to do this, but with several of you working independently it's too hard to keep up as I do other things. Just search for occurrences of '<X11/..> to see what I mean.

chroot
(I use aboriginal as my rootfs)

[Iguleder]

Got ROX-Filer to work, but the pinboard is horrible - you cannot drag files to create icons.

[Ibidem]

Do you have a version with a windows manager which can use the mouse and the keyboard ?

Do you mean "a window manager which takes advantage of the mouse as well as the keyboard" (ie, "not ratpoison")?

I'm using mwm from Motif, which definitely qualifies.
I don't have any window managers integrated into the build.

...
For now, I should push my xutils tree somewhere. It's got a few of the more useful standard X programs: xcalc, xmessage, xfontsel, xlsfonts, xkill, xprop, xwininfo, and fontutils (bdftopcf, bdftruncate, and ucs2any + the map files). I want to add xclock or oclock, and perhaps xmag and xclipbard. (I'm thinking of using oclock because it's the smaller clock, plus I like the transparency.)

[Ibidem]

A couple things that came to mind due to looking over tinyxserver and tinyxlib:
-The reason makefiles use "rm -f" for clean is that it does not fail when the file to be removed does not exist. As a result, you can use rm -f on targets that frequently won't be built (such as Xvesa).

-git can work with multiple servers and branches. If I were merging the CVE fixes that I mentioned into "master" from a branch that had changes I wasn't sure about, I would have done it like so:

Code: Select all

git checkout master
git checkout -b cve-merge
#pull repo branch
git pull git://github.com/idunham/tinyxlib blob
#Now review changes
git log
#See what files have changed
git diff master cve-merge |grep -e '^---' -e '^+++'
#Review the diff; to view the diffs for a directory, do:
#git diff master cve-merge libXfont/
git diff master cve-merge
#Since it matches your tree for the most part, you can either adopt it in full:
#git checkout master; git merge cve-merge
#or cherry-pick the commits.
#I prefer to avoid experiments in master, and cherry-picking sometimes calls for caution.
#So I cherry-pick like this:
git checkout master
git checkout -b cvefix
#Now, record the commit numbers of the commits of interest.
git log cve-merge -- libXfont/
#review them:
git show 453d28
git show c20a19
#and cherry-pick them:
git cherry-pick 453d28
git cherry-pick c20a19
#In this case, there aren't any conflicts. So we can continue by testing that it builds.
#If there were conflicts, git should let you know about it very loudly.
#You would check what conflicts (usually "both modified"):
#git status
#then edit each file, searching for '<<<<<<'
#which marks the HEAD side of an unmergeable area; from ====== to >>>>>> is the remote branch side.
#Once you figure out what changes to make, be sure to delete the markers and the unmerged code!
#After editing each file, do
#git add file
#At this point you can continue.
make clean; make
#Now merge it into master:
git checkout master
git merge cvefix
#and that's it.

But that's the long way. My comment that it was ready for you to merge, with your buildsystem, was saying that you could do it the short way:

Code: Select all

git checkout master; git checkout -b cve-merge
git pull git://github.com/idunham/tinyxlib blob
make clean; make
make clean
git checkout master; git merge cve-merge

[linuxcbon]

I'm using mwm from Motif,

It's too big , mwm sources are 9Mb, in comparison to jwm 0.3Mb.

[Iguleder]

Just wrote a dead-simple union file system using FUSE.

I want to use it for package mangement - it doesn't support COW, so it can only be used to add files to the OS (i.e install new packages). I think this makes the whole thing more secure keeps the distro robust.

Now, I'm going to write some super-fast init script which finds the "home partition" and mounts a Squashfs image placed inside it.

[Ibidem]

I'm using mwm from Motif,

It's too big , mwm sources are 9Mb, in comparison to jwm 0.3Mb.

I use a few pieces of Motif software, like xpdf, xmmix, Ted, nebula, xephem, xplore, and several others.

Anyhow...my main reason for not using JWM is the config file. I agree with Linus on XML (http://mail.bitmover.com/pipermail/lmbe ... 00076.html), and much prefer a plain-text config file...

[technosaurus]

Anyhow...my main reason for not using JWM is the config file. I agree with Linus on XML (http://mail.bitmover.com/pipermail/lmbe ... 00076.html), and much prefer a plain-text config file...

Normally I would agree; however, jwm's xml is not just a config file, but also a layout description (for menus, toolbars, etc...). Any meaningful layout language is going to resemble XML or JSON to some extent and jwm's XML engine is pretty light (no expat/libxml dependency)

NOTE: Hazewm does layout menus via flat files, is pretty close to jwm's style and has a permissive license. Currently it only does XPM images, but I'd like to see if stb_image could be used to add gif, png, jpeg and others.

Edit: found a light getty/login/xinit implementation here:
https://github.com/msharov/loginx

[Ibidem]

Anyhow...my main reason for not using JWM is the config file. I agree with Linus on XML (http://mail.bitmover.com/pipermail/lmbe ... 00076.html), and much prefer a plain-text config file...

Normally I would agree; however, jwm's xml is not just a config file, but also a layout description (for menus, toolbars, etc...). Any meaningful layout language is going to resemble XML or JSON to some extent and jwm's XML engine is pretty light (no expat/libxml dependency)

NOTE: Hazewm does layout menus via flat files, is pretty close to jwm's style and has a permissive license. Currently it only does XPM images, but I'd like to see if stb_image could be used to add gif, png, jpeg and others.

Edit: found a light getty/login/xinit implementation here:
https://github.com/msharov/loginx

Thanks for mentioning that. (I stumbled over mazewm in the proces, which is more interesting because it appears to have some awareness of colors.)
My own favorites are IceWM and Dtwm, the CDE window manager.
But CDE takes Motif, RPC, and a few other things besides. mwm is a bit plainer, but pleasant...
And IceWM is very nice, but it's LGPL, C++, and needs imlib/gdk-pixpuf. Not a major isue, but I do like plain MIT C/X11/Xpm.
BTW, those two have my preferred config file format.

[Iguleder]

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. Now, I have a big collection of applications that is comprehensive enough for an ultra-lightweight GTK1 Puppy remix

[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.