(old)Puppy Linux Discussion Forum

Posted: **Wed 28 Mar 2012, 15:51**

goingnuts wrote:The 'max-length' in entry is supported in gtk1 - forgot to tell you...
Cool with the additions! Just tested some of the examples from 0.7.20: A great deal of the syntax is accepted by gtkdialog1 but might not be supported though.
How to coordinate? I have a few modifications lying around too and if we start making syntax from 0.7.20 acceptable (but maybe not responsive), we need to keep things updated...

I know that max-length is now supported. What I meant was that there are other gtk widgets, where the official gtk2 version accepts some attributes/arguments (like 'max-length' in GtkEntry), which are not supported by the official gtk1 widget.

I was having a go at the <window> tag, but I think the tag_attr stuff needs to be reworked to the new scheme to support the new window attributes (like 'center' and the new window-naming syntax), There's two new files tag_attributes.c/h and new syntax is used throughout for all widgets which use tag attributes (s.widgets, Widget_Type stuff) -it's a bit beyond me. I think the tag_attr stuff should be translated first, because there are also new attributes and signals supported by several widgets (see note in ChangeLog for 0.7.1). I'll PM you a copy of the diff with the changes as far as I got.

Also, there is the rest of the pip_malloc stuff which should be fixed - I think I can handle that -it's all in the diff from 0.59.8-to-0.7.4.

If you have any small changes that are already done, create patches of each one (or all together, if you must) and send them to me. I'll merge them with mine into a new interim working version. The sooner they get merged the easier. I think the window tag/attributes is pretty important for having later syntax work. As I said, most of the later syntax changes are not new tags, but new actions, attributes and signals which are mostly handled as part/options of existing tags.

Posted: **Thu 29 Mar 2012, 07:36**

Maybe easyer to use lexer.l and parser.y from 0.7.20 and fix what might be missing? I think 0.7.20 accepts most 0.59.8 syntax...
I revised the "gtk_image_menu_item_new_from_stock" gtk1-wrapper to show stockicons - still mis code to capitalize first letter of the label though...

Posted: **Tue 03 Apr 2012, 18:43**

20120403: New release: GtkDialog1-1.1 uploaded

Posted: **Sun 22 Apr 2012, 20:04**

A small application using gtkdialog1 - collection of system information and tools.

Posted: **Sun 22 Apr 2012, 21:34**

I put together a Wary pet (the only listed dependency is libgdk_pixbuf - which it is as long as there is a sane dependency base, but there is not - so I have a gtk-all package that works on wary)

Posted: **Tue 24 Apr 2012, 17:08**

I have an idea for gtkdialog1 dialog builder, but wanted to get some feedback to see if it would be doable or even useful or if someone could improve on my roadmap. My idea was to have a glade style panel (made with gtkdialog) and display the gtkdialog window to the side. The panel could simply fill the clipboard with template code and automatically generate placeholder buttons within the tag (for window the button would be the whole area, for hbox a full horizontal button...) that would dump the clipboard to that location between ">" and "</" - replacing the placeholder button(s) and restart the gui... to make it look nicer the placeholder buttons could eventually be styled differently etc...

Any thoughts?

Posted: **Tue 24 Apr 2012, 20:14**

technosaurus wrote:I have an idea for gtkdialog1 dialog builder, but wanted to get some feedback to see if it would be doable or even useful or if someone could improve on my roadmap. My idea was to have a glade style panel (made with gtkdialog) and display the gtkdialog window to the side. The panel could simply fill the clipboard with template code and automatically generate placeholder buttons within the tag (for window the button would be the whole area, for hbox a full horizontal button...) that would dump the clipboard to that location between ">" and "</" - replacing the placeholder button(s) and restart the gui... to make it look nicer the placeholder buttons could eventually be styled differently etc...

Any thoughts?

technosaurus,

Perhaps something like this-
http://www.murga-linux.com/puppy/viewto ... 421#415421

but much better

Regards,
s

Posted: **Sat 05 May 2012, 16:41**

Two of the attachments on page1 are corrupted -- I cannot get either GZip (on Win and Puppy) or 7zip (on Win) to open either *.gz file. (One of the TarBZ2 files opens, I didn't test the other.)

I hope that the smaller of the two *.pets posted on this page will work in pUPnGO. If not... well

Posted: **Sat 05 May 2012, 18:33**

starhawk wrote:Two of the attachments on page1 are corrupted -- I cannot get either GZip (on Win and Puppy) or 7zip (on Win) to open either *.gz file. (One of the TarBZ2 files opens, I didn't test the other.)

Well - no - they are fake .gz files. Remove the .gz extension and make them executable.

Posted: **Sat 05 May 2012, 19:33**

Oh.

*facepalm*

Posted: **Thu 24 May 2012, 18:48**

Another demo: gtkcdplayer.
Based on cdtool-2.1.8 - included in attached pet.
Update 20120527: v0.2 optimized db use (no look up if cd recognized), removed wrong text if cdplay/cdown not found, moved stopbutton and now cdtool binaries supplied as mcb-cdtool.

Posted: **Thu 24 May 2012, 23:31**

Makes a nice command-line cd tool. (i.e, cdtool)

Posted: **Fri 25 May 2012, 00:26**

another candidate for a gui would be a pdf viewer using mupdf draw
mubusy draw -o "$1-%d.png" "$1" (... though I could use jwm just as easily with my jwm image viewer hack)
... it also does pdf->text and all sorts of other stuff

the mupdf viewer itself has no controls and uses ~10Mb RAM, gtkdialog1 should be about half that and could provide some controls

btw, did anything ever come of your xembed stuff ... would be kinda neat to use xdotool/etc... on an embedded viewer (for stuff like tabbed terminal, vlc-gtk and similar mupdf-gtk)

using the $1-%d.png method would work with this:
jwm_image_view *.png
(here is the code, it should be a little less complicated with gtkdialog though)

Code: Select all

#!/bin/ash
#NOTE $HOME/.jwm/jwmrc-tmp needs to be <include>d in the jwmrc
IMAGE1=""
while ([ $1 ]) do
case ${1} in
	*.png|*.jpg|*.xpm)[ $IMAGE1 ] && IMAGES=${IMAGES}' '${1} && IMAGELAST=${1} || IMAGE1=${1};;
	height=*)eval ${1};;
	Close)rm -rf ${HOME}/.jwm/jwmrc-tmp;jwm -restart;exit;;
	*);;
esac
shift
done

PREVIOUS=${IMAGELAST}' '${IMAGE1}' '${IMAGES%*${IMAGELAST}}
NEXT=${IMAGES}' '${IMAGE1}
SMALLER='height='$((${height:-192}/2))' '${IMAGE1}' '${IMAGES}
LARGER='height='$((${height:-192}*2))' '${IMAGE1}' '${IMAGES}

MAXHEIGHT=`xwininfo -root`
MAXHEIGHT=${MAXHEIGHT##*-geometry *x};
MAXHEIGHT=$((${MAXHEIGHT%%+*}-50));
MAXIMIZE='height='${MAXHEIGHT}' '${IMAGE1}' '${IMAGES}


[ $height ] && height='height="'$height'"'
echo '<JWM><Tray  autohide="false" halign="center" y="1" border="0">
	<TrayButton popup="Previous" label="«" >exec:jwm_image_view '${height}' '${PREVIOUS}'</TrayButton>
	<TrayButton popup="Next" label="»" >exec:jwm_image_view '${height}' '${NEXT}'</TrayButton>
	<TrayButton popup="Smaller" label="-" >exec:jwm_image_view '${SMALLER}'</TrayButton>
	<TrayButton popup="Larger" label="+" >exec:jwm_image_view '${LARGER}'</TrayButton>
	<TrayButton popup="Set this image as background - not yet implemented" label="ʬ" >exec:jwm_set_background '${IMAGE1}'</TrayButton>
	<TrayButton popup="Normal size" label="_" >exec:jwm_image_view '${IMAGE1}' '${IMAGES}'</TrayButton>
	<TrayButton popup="Maximize" label="" >exec:jwm_image_view '${MAXIMIZE}'</TrayButton>
	<TrayButton popup="Close" label="X">exec:jwm_image_view Close</TrayButton>
</Tray>
<Tray  autohide="false" halign="center" y="25"  border="2" '$height' >
<TrayButton popup="'${IMAGE1}'" icon="'${IMAGE1:-mini-dog.xpm}'" >exec:jwm_image_view Close</TrayButton>
</Tray></JWM>' > ${HOME}/.jwm/jwmrc-tmp
jwm -restart

Posted: **Fri 25 May 2012, 14:05**

jpeps: Indeed it is - just realized further possibilities with the cddb, volume, shuffle and more I will try to add on the gtkcdplayer...although cdplay might be sort of and outdated technology...

technosaurus I think I got lost in the process of identifying the window to catch/swallow...I will see how far I got and post the source for the standalone swallower..
Also I will try to look deeper into the mupdf-stuff....

Posted: **Sun 27 May 2012, 14:33**

Updated gtkcdplayer
Also saved 73K by making a multicall binary of the 4 progs in the cdtool package (its now 54K uncompressed, 31K upxed - less than the former shipped cdtool alone).

Posted: **Sun 27 May 2012, 22:23**

goingnuts wrote:Also saved 73K by making a multicall binary of the 4 progs in the cdtool package

Out of interest: is that a standard option, or does it involve some trickery?

Posted: **Mon 28 May 2012, 00:19**

disciple wrote:Out of interest: is that a standard option, or does it involve some trickery?

not standard, but the principle is straightforward - change the main() for each program to program_main() and make a new main() that calls the appropriate program_main() based on the basename of agv[0] (the /path/name of the binary as executed) or argv[1] if for instance the first arg is busybox - see the latest release of mupdf for an example that I contributed to (mubusy).

Now this is also applicable to scripts, but using $0 instead of argv[0]
for example

Code: Select all

cdplayer(){
: code here
}

processinfo(){
: code here
}

multicall(){
$@
}

mycommand=`basename $0`
$mycommand $@

(this will run the function cdplayer if you run the script as ./cdplayer or multicall cdplayer, and is much more compressible than several small files)

Posted: **Mon 28 May 2012, 04:01**

Oh, so you're actually doing it to reduce the number of executables, rather than to avoid compiling multiple copies of shared code?
Do you need to post the modified source?
What license is it under?

Posted: **Mon 28 May 2012, 12:49**

Main purpose of doing mcb is to reduce total size...
I do not know about the license stuff and if source must be shipped along with the binary but as always source is available upon request. I seldom ship the modified source code as only very few seems interested in that...

Attached an other demo - gtkrdesktop - including rdesktop-1.2.0 static build.

The purpose of making the demos is to exercise gtkdialog1 and find missing features etc. The gtkrdesktop is a launcher for the remote desktop application rdesktop, used to connect to various windows desktops. I would have liked to include possibilities for saving/loading profiles but are missing some features in the gtkdialog1 like setting status of checkboxes via script/variable and the append action to comboboxes - added to the TODO list in first post.

Posted: **Mon 28 May 2012, 22:31**

goingnuts wrote:Main purpose of doing mcb is to reduce total size...

Yeah, I was really asking about how it reduces the total size.

I do not know about the license stuff and if source must be shipped along with the binary

OK, looking at http://packages.debian.org/changelogs/p ... .copyright it seems to be under the GPL, and therefore it must.

but as always source is available upon request.

Please provide it. Thanks.

I seldom ship the modified source code as only very few seems interested in that...

What if someone comes along in future who wants it, but you're not around anymore? Your effort would have been wasted, as someone else would need to redo it.
I know of a case where someone released a couple of Windows builds of a program that they were working on based on a GPL library, promising to release the source when it was "finished" (a number of people want it, mostly to build on Linux). But then they disappeared from the forum it was released on, without providing the source. There are still people finding it years later, but all we can do is use the binary with Wine

Attached an other demo - gtkrdesktop - including rdesktop-1.2.0 static build.

Cool.

(old)Puppy Linux Discussion Forum

gtkdialog1-1.4