Page 10 of 11
Posted: Fri 12 Jul 2013, 17:47
by amigo
I don't understand how phones got int here.
@GN -Using 'guish' would definitely show that you have the appropriate sense of humor for an open-source developer...
I'm kinda with techonosaurus in that one would expect guish to *be* a shell instead of a shell-driven utility -although the dialog equivalent for tcl is called 'wish'.
I was just DuckDuckGo-ing for guish and found this on first page:
http://sourceforge.net/projects/guish/
so, someone has beat you to it anyway.
I'm afraid I can't think of anything useful to suggest, right now, but be assured that I'll be thinking about it... 'dialogtk', 'gtk4shell'
Xdialog deservedly used the *dialog* part since the syntax used is compatible with (c)dialog. And, there used to be a tool called gtkdialog -long before the tool recognized here as 'gtkdialog' The original gtkdialog was more like gmessage. For reference, here's a link to the 'orginal' gtkdialog:
http://distro.ibiblio.org/amigolinux/do ... 04.tar.bz2 Get that while it is still hot, because it is no longer available anywhere else.
Posted: Fri 12 Jul 2013, 19:00
by jpeps
amigo wrote:I don't understand how phones got int here.
..expected standard for current user interface on efficient hardware (a desktop/laptop generally has more resources), which are far more advanced than even our current gtkdialog much less old versions. Why not just use dsl?
I recall RS removing gtkdialog altogether, since like you, he felt it added too much "bloat". Developers tend to like features like file filters, etc., and will most likely find some other language to write with if it isn't there.
Posted: Fri 12 Jul 2013, 19:34
by goingnuts
technosaurus: I get the point - the xml part opens up new possibilities.
01micko:Not bad at all
reminds me of an explanation of the use of strip in the old pupngo thread...
amigo:Thanks for the research. Might be that the names with build in meaning might turn up already used.
So guish is out - but we got some nice quoting possibilities.
Its more difficult than I thought...in many ways...
Posted: Mon 14 Apr 2014, 14:18
by Iguleder
Trying to get GtkDialog 1.3 to work under x86_64.
So far, I got it to work with GTK2, but with a static build with musl, tinyxlib, glib1 and GTK1 it enters a deadlock in malloc(), when called by gtk_new_window(). Both Valgrind and GDB fail to reveal why this happens, so I'm still investigating the code.
Posted: Mon 14 Apr 2014, 14:52
by amigo
Thanks for reporting. Hope you find the problem so we can include the fix in a new release.
Posted: Mon 14 Apr 2014, 15:08
by Iguleder
Here's the Valgrind log
Posted: Mon 14 Apr 2014, 15:20
by technosaurus
IIRC Rich (musl dev) mentiioned something about sbrk syscall used to implement malloc and his malloc implementation having issues with custom mallocs .... My guess is gtk1 either implements its own by default or there is an issue recognizing musl's version due to differences in how musl organizes header files (not incorrect, but different than glibc)
You could probably modify gtk1's ifdef to always. Use the system's *alloc functions.
Posted: Mon 14 Apr 2014, 18:28
by Iguleder
Nope - neither gtk or glib implement malloc() or brk().
EDIT: here's the patch required for GTK2 on x86_64. Still debugging GTK1.
EDIT 2: some good progress! When I build against GTK1, glib1 and glibc on Debian Sid, I face some issue with malloc() - I guess both glibc and musl are affected by the same bug, despite of the fact musl doesn't crash:
Code: Select all
gtkdialog1: malloc.c:2368: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
Code: Select all
#0 0x00007ffff5f6a3a9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff5f6d4c8 in __GI_abort () at abort.c:89
#2 0x00007ffff5facd0d in __malloc_assert (
assertion=assertion@entry=0x7ffff609bc40 "(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offs"..., file=file@entry=0x7ffff60976d1 "malloc.c",
line=line@entry=2368, function=function@entry=0x7ffff6097a58 <__func__.11276> "sysmalloc") at malloc.c:290
#3 0x00007ffff5faf889 in sysmalloc (av=0x7ffff62d8620 <main_arena>, nb=32) at malloc.c:2365
#4 _int_malloc (av=0x7ffff62d8620 <main_arena>, bytes=10) at malloc.c:3743
#5 0x00007ffff5fb0c80 in __GI___libc_malloc (bytes=10) at malloc.c:2858
#6 0x00007ffff73a1e77 in g_malloc (size=10) at gmem.c:177
#7 0x00007ffff73acc9e in g_strdup (str=0x7ffff7bae523 "GtkWidget") at gstrfuncs.c:87
#8 0x00007ffff7b69cf0 in gtk_type_unique (parent_type=21, type_info=0x7ffff7dd6080 <widget_info.12569>) at gtktypeutils.c:251
#9 0x00007ffff7b75ee2 in gtk_widget_get_type () at gtkwidget.c:247
#10 0x00007ffff7a7d080 in gtk_container_get_type () at gtkcontainer.c:136
#11 0x00007ffff7a44575 in gtk_bin_get_type () at gtkbin.c:71
#12 0x00007ffff7b86295 in gtk_window_get_type () at gtkwindow.c:188
#13 0x00007ffff7b86b10 in gtk_window_new (type=GTK_WINDOW_TOPLEVEL) at gtkwindow.c:390
#14 0x000000000040d803 in run_program () at automaton.c:474
#15 0x000000000040a550 in yywrap () at parser.y:399
#16 0x000000000040b6e9 in yylex () at lexer.c:2321
#17 0x0000000000409925 in yyparse () at parser.c:2043
#18 0x0000000000407bb4 in main (argc=2, argv=0x7fffffffe648) at main.c:261
Posted: Tue 15 Apr 2014, 10:49
by Iguleder
There you go.
Works with GTK1 on Debian Sid. The problem was a severe heap corruption that screwed up malloc() badly, caused by uninitialized variables in compat.c. I tried to attack this bug through 5 vectors and all of them failed because I ended up debugging glib's hash table code (which is impossible to debug, all meaningful data is hashed
).
When I built gtkdialog against glibc, I used MALLOC_CHECK_=1 and found out the upper heap blocks got bombed by gtkdialog, so I decided to build an unoptimized gtkdialog (-O0 -g) and saw new errors, this time in compat.c (OUR code, not glib's). Long story short - many pixmap-related errors showed up, so I traced uninitialized memory issues until I found these variables.
Took two days to debug, but eventually, Puppy Linux won again.
EDIT: doesn't work with my static musl/glib/gtk1 combo, I think one of Debian's GTK patches is required.
Posted: Tue 15 Apr 2014, 11:27
by goingnuts
Congratulations! And thank you for all your effort! We include your patch in future release.
Posted: Tue 15 Apr 2014, 11:48
by Iguleder
I don't know why, the patch was rejected when I built the static GTK1 gtkdialog, so the result binary did not include the fix.
Here's a re-generated patch that works.
Posted: Tue 15 Apr 2014, 12:04
by goingnuts
Adding examples:
* A simple calculator using awk & gtkdialog1
* A simple text editor
Posted: Wed 01 Apr 2015, 19:28
by goingnuts
And with some fear - on this special date - I announce the release of gtkdialog1-1.4 - view first post for download link.
Directly from the ChangeLog:
- Released as gtkdialog1-1.4.tar.gz
- configure.in bumped version to 1.4 and regenerate configure script
- finally fixed window launch and window close
- introduced sort in table by clicking headers
- introduced multiple select in table
- introduced autoset column size for columns in table
- introduced pixmap refresh
- fixed xpm images not resizing
- clean up code/functions in image handling
- gtk1 filechooser strip trailing "/" like gtk2 filechooser does
- added examples and fixed various mistakes
- patches for x86_64 kindly supplied by Iguleder applied
Attached image shows the gtk1 version running one of the included examples, xarchive2.
Posted: Thu 02 Apr 2015, 09:14
by disciple
Is there any chance of an advertising blurb in the first post or something?
How has it changed from the "original" gtkdialog1? What features are still missing compared to later gtkdialogs?
Posted: Thu 02 Apr 2015, 11:04
by goingnuts
Excellent suggestion! I will work on that. Meanwhile consider gtkdialog1 as a program which shares some of the historical code with newer versions of gtkdialog but with main focus on working for both gtk1 & gtk2 and with a limited number of widgets and functionality. Its more an advanced Xdialog (without the ncurses compatibility).
Posted: Sat 04 Apr 2015, 23:42
by technosaurus
Nice, good to see the progress. You kinda fell off the map for a bit.
Would it be worth while to build all of my diffs from the original gtkdialog and the gtkdialog1 work into a unified history on github?
I've also been meaning to ask around about setting up a small distro "team" on github.
Posted: Sun 05 Apr 2015, 16:13
by goingnuts
Would it be worth while to build all of my diffs from the original gtkdialog and the gtkdialog1 work into a unified history on github?
Yes - I think that could be helpful if someone need to view the different steps that has been taken. I tend to change the code more for my own needs than for showing the diff from version to version...
Trying to do the documentation atm. - revising doc/gtkdialog.texi file. Thought that it is of more value than a comparison between newer versions of gtkdialog. And it might pinpoint bugs that needs fixing or simple enhancements to be included.
Posted: Tue 07 Apr 2015, 18:24
by goingnuts
Manual in html formate attached in first post.
Posted: Thu 25 Jun 2015, 23:17
by technosaurus
I found out from
here that git comes with a perl script that exports a series of tarballs to a git history.
... right after I finally got rid of perl