gtkdialog1-1.4

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#46 Post by amigo »

"overview of widgets/attributes/actions" The parser is for the xml 'tags', so any time a new tag is added the parser needs to be re-generated. The best way to see how one gets added is to study the diffs between some of the original versions -the changelog will help you pinpoint when a new tag is added and show exactly where code needs to be added.

I've gotten this configuring, compiling and running using the original autoconf setup, with so far limited capabilities. You seem to have already backported some stuff from later versions of the original sources, correct?

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#47 Post by goingnuts »

amigo wrote:"overview of widgets/attributes/actions" The parser is for the xml 'tags', so any time a new tag is added the parser needs to be re-generated. The best way to see how one gets added is to study the diffs between some of the original versions -the changelog will help you pinpoint when a new tag is added and show exactly where code needs to be added.
Yes but one thing is what the parser accepts another thing is what the code actually supports. Parsing <action>removeselected:COMBOWIDGET</action> is accepted by the parser but nothing in the code supports the removal of an item in the COMBO-list.
I have tried to do more generic scripts to exercise the widgets (se below image). The code is more or less the same and its is quick to test if thing works as expected:

Code: Select all

#! /bin/sh
export MAIN_DIALOG='
 <vbox>
  <frame Combo>
   <combobox>
    <variable>COMBO</variable>
     <visible>enabled</visible>
     <item>First item</item>
     <item>Second item</item>
     <item>Third item</item>
     <action>echo You selected $COMBO</action>
   </combobox>
   <hbox>
   <button>
    <action removeselected>COMBO</action>
    <label>removeselected</label>
   </button>
   <button>
    <action clear>COMBO</action>
    <label>clear</label>
   </button>
   <button>
    <action refresh>COMBO</action>
    <label>refresh</label>
   </button>
   <button>
    <action>disable:COMBO</action>
    <label>disable</label>
   </button>
   <button>
    <action>enable:COMBO</action>
    <label>enable</label>
   </button>
   <button>
    <action>append:ENTRY,COMBO</action>
    <label>add</label>
   </button>
  </hbox>
 </frame>
 <hbox>
  <text>
   <label>Item to add: </label>
  </text>
  <entry>
   <variable>ENTRY</variable>
  </entry>
 </hbox>
 <hbox>
  <button ok></button>
  <button cancel></button>
 </hbox>
</vbox>
'
.././gtkdialog1  --program MAIN_DIALOG
Only minor things to change when another widget is to be tested.

Today I added limitation to the actions refresh, clear, removeselected and append: They did not evaluate if a widget was disabled before running which I think is wrong - so fixed that.
amigo wrote:I've gotten this configuring, compiling and running using the original autoconf setup, with so far limited capabilities. You seem to have already backported some stuff from later versions of the original sources, correct?
Thats very good! Yes I have backported code from newer versions. I also got the thing to compile with both gtk1 & 2 now and having gdk-pixbuf as an option for the gtk1 version.
Attachments
snap0008.png
(125.92 KiB) Downloaded 649 times

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#48 Post by technosaurus »

There are a couple of options for not-yet-supported tags...
Temporarily map them to existing similar supported widgets.
Ignore them silently.
Fail and exit.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#49 Post by amigo »

Of course I understand the code must support new tags and attributes. What I meant was that you'd save editing parser.c and parser.h each time. I was unable to get them to rebuild the same as yours even after down-grading bison and flex to the same versions as yours -there were still a couple of differences which would not resolve properly with your code. I am also unable to build the gtk2 version here because I have gtk-2.24.x

But, I started over several times and finally got your code transplanted into the autoconf framework so that the parser rebuilds correctly. I had already gotten the original 0.58.10 version to compile and run with very minimal changes -by simply commenting out all the gtk2 stuff which didn't work. Of course lots of stuff was not working. Notice that the 0.58.11 version introduced two new widgets, the 'tree' and 'gvim' neither of which was working. You had added a very large chunk of code as an attempt at a gtk1 tree, but since you ifdef'ed it out I figured you wouldn't mind.

So what I did was take all the tree and gvim stuff and then it was working -there were a couple of minor other changes to your code to eliminate the config.h and a couple of places where the parser.h was being included -their inclusiong early in the build was preventing the parser files from being built -they come pretty late.

I really hope you'll try to work from this new tarball -it comes 'repo clean' -there is no configure script or Makefile.in files in the tarball. This makes it easier to really see what is going on when you create a patch -only the 'meat' of the code shows up without all the changes which are made when you run configure, use another bison version, etc. I've included an autogen.sh script or you can also run 'autoreconf -if' in the raw sources. After that everything should just work.

As I said before, if you'll go over just a couple of the diffs which technosaurus posted in the 'history' archive, you'll see that it's pretty easy to add widgets. Yes, you have to provide support code, but changing the parser is achieved by adding just a couple of lines to lexer.l Note that the author was also working with raw sources -only when finalizing a release would he run the autoconf commands in the sources. So, if you are comparing diffs between release tarballs, there is a lot of the diff which can be ignored -all the Makefile.in code, all the parser.h and parser.c stuff. by lookinh just at the other *.c files and lexer.l you can see what has really been added -and it's lots simpler than trying to manually alter the parser code.

I'm attaching the first tarball I've created. Please post some more adequate text for the Authors and ChangeLog files -I've just put some place-marker items in there.

Can you create and attach the tarball of your latest changes? I'll roll them into what I've started with, if so. And I'll look at implementing a feature or two from the follwoing versions so we can see how easy it should be. You've already done most of the hard parts as far as basic functionality with images, etc. I think that many of the new tags and bugfixes from later versions will port fairly easily. I really could care less about it supporting gtk2 -as I said it won't work with my later version yet. And I have not added the autoconf stuff to let you choose which toolkit. I will work on that, though. Still, the GTK2 tags in the code serve as good place-markers when trying to backport code from later versions.

if you re-base to using this archive I'll be more able to help you out.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#50 Post by goingnuts »

Amigo...thank you! You must have thrown hours in this! I will try using your tarball and follow your guidelines - although I might not understand everything yet. Attached the present code, stripped for examples as I plan to post them separately, and with 2 Makefiles (for gtk1 and gtk2). The gtk2 builds with a few errors - some widgets do not work but haven't tested much there.

I have altered the pixmap code a bit, fixed the height of buttons without image to be same height as the ones with images, added action to combo-widget, removed some of my commented trial-codes, changed the alignment for some of the widgets so they better follow hbox and vbox logic and as told above avoided some actions running on most disabled widgets.

How do I build in you tarball? I tried to run the autogen.sh but got below output:

Code: Select all

./autogen.sh 
/usr/share/aclocal/nspr.m4:8: warning: underquoted definition of AM_PATH_NSPR
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE
aclocal:configure.in:22: warning: macro `AM_PATH_GTK' not found in library
configure.in:22: error: possibly undefined macro: AM_PATH_GTK
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
UPDATE:Got him running - had to symlink /usr/local/share/aclocal/gtk.m4 to /usr/share/aclocal/gtk.m4. Symlinked gdk-pixbuf.m4 as well. Now I only gets the warnings from autogen.sh. configure turns up and after running that make do the rest. :D

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#51 Post by amigo »

Actually I've spent several days on this, so I really hope we can coordinate.

I've looked at your latest changes -at least it's a small set. But, can we first get you going in the new sources. I'd like to get it wrapped up as a feature-freeze as of 0.58.11 (minus the tree code for now). I've seen that you had already partially backported some code from 0.59.8. That bit is implemented in the *following* version 0.59.0 upstream and more completely. 0.59.0 has some other low-hanging fruit in it like geometry support.

But, please, let's finalize this first starting point and then move forward from there shadowing the original upstream releases and fixing anything that won't support gtk1. We'll get to 7.2.0 faster that way. Let's try to keep the code looking like the original for a while -that makes backporting from each version *much* easier. When we get to a 'finished' product or are no longer relying on upstream patches, then the whole thing can be reformatted and cleaned up (the 'indent' tool can do the re-formatting for us).

Okay, the errors you are seeing are from other packages, but I'll show you how to fix them so they don't distract.
"/usr/share/aclocal/nspr.m4:8: warning: underquoted definition of AM_PATH_NSPR
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/auto ... ng-aclocal
/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE"

These come from having old versions of seamonkey and audiofile.
Open up /usr/share/aclocal/audiofile.m4 and you'll probably see this:
AC_DEFUN(AM_PATH_AUDIOFILE,
which should look like this:
AC_DEFUN([AM_PATH_AUDIOFILE],

Do the same for the nspr.m4, adding the square brackets. That should quieten those two warnings -BTW they are harmless.

The next one is a fatal error:
"aclocal:configure.in:22: warning: macro `AM_PATH_GTK' not found in library"
It comes from an incomplete installation of gtk-1.2.10. You are missing the gtk.m4 file. Here it is inlined:

Code: Select all

# Configure paths for GTK+
# Owen Taylor     97-11-3

dnl AM_PATH_GTK([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND [, MODULES]]]])
dnl Test for GTK, and define GTK_CFLAGS and GTK_LIBS
dnl
AC_DEFUN([AM_PATH_GTK],
[dnl 
dnl Get the cflags and libraries from the gtk-config script
dnl
AC_ARG_WITH(gtk-prefix,[  --with-gtk-prefix=PFX   Prefix where GTK is installed (optional)],
            gtk_config_prefix="$withval", gtk_config_prefix="")
AC_ARG_WITH(gtk-exec-prefix,[  --with-gtk-exec-prefix=PFX Exec prefix where GTK is installed (optional)],
            gtk_config_exec_prefix="$withval", gtk_config_exec_prefix="")
AC_ARG_ENABLE(gtktest, [  --disable-gtktest       Do not try to compile and run a test GTK program],
		    , enable_gtktest=yes)

  for module in . $4
  do
      case "$module" in
         gthread) 
             gtk_config_args="$gtk_config_args gthread"
         ;;
      esac
  done

  if test x$gtk_config_exec_prefix != x ; then
     gtk_config_args="$gtk_config_args --exec-prefix=$gtk_config_exec_prefix"
     if test x${GTK_CONFIG+set} != xset ; then
        GTK_CONFIG=$gtk_config_exec_prefix/bin/gtk-config
     fi
  fi
  if test x$gtk_config_prefix != x ; then
     gtk_config_args="$gtk_config_args --prefix=$gtk_config_prefix"
     if test x${GTK_CONFIG+set} != xset ; then
        GTK_CONFIG=$gtk_config_prefix/bin/gtk-config
     fi
  fi

  AC_PATH_PROG(GTK_CONFIG, gtk-config, no)
  min_gtk_version=ifelse([$1], ,0.99.7,$1)
  AC_MSG_CHECKING(for GTK - version >= $min_gtk_version)
  no_gtk=""
  if test "$GTK_CONFIG" = "no" ; then
    no_gtk=yes
  else
    GTK_CFLAGS=`$GTK_CONFIG $gtk_config_args --cflags`
    GTK_LIBS=`$GTK_CONFIG $gtk_config_args --libs`
    gtk_config_major_version=`$GTK_CONFIG $gtk_config_args --version | \
           sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/'`
    gtk_config_minor_version=`$GTK_CONFIG $gtk_config_args --version | \
           sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\2/'`
    gtk_config_micro_version=`$GTK_CONFIG $gtk_config_args --version | \
           sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\3/'`
    if test "x$enable_gtktest" = "xyes" ; then
      ac_save_CFLAGS="$CFLAGS"
      ac_save_LIBS="$LIBS"
      CFLAGS="$CFLAGS $GTK_CFLAGS"
      LIBS="$GTK_LIBS $LIBS"
dnl
dnl Now check if the installed GTK is sufficiently new. (Also sanity
dnl checks the results of gtk-config to some extent
dnl
      rm -f conf.gtktest
      AC_TRY_RUN([
#include <gtk/gtk.h>
#include <stdio.h>
#include <stdlib.h>

int 
main ()
{
  int major, minor, micro;
  char *tmp_version;

  system ("touch conf.gtktest");

  /* HP/UX 9 (%@#!) writes to sscanf strings */
  tmp_version = g_strdup("$min_gtk_version");
  if (sscanf(tmp_version, "%d.%d.%d", &major, &minor, &micro) != 3) {
     printf("%s, bad version string\n", "$min_gtk_version");
     exit(1);
   }

  if ((gtk_major_version != $gtk_config_major_version) ||
      (gtk_minor_version != $gtk_config_minor_version) ||
      (gtk_micro_version != $gtk_config_micro_version))
    {
      printf("\n*** 'gtk-config --version' returned %d.%d.%d, but GTK+ (%d.%d.%d)\n", 
             $gtk_config_major_version, $gtk_config_minor_version, $gtk_config_micro_version,
             gtk_major_version, gtk_minor_version, gtk_micro_version);
      printf ("*** was found! If gtk-config was correct, then it is best\n");
      printf ("*** to remove the old version of GTK+. You may also be able to fix the error\n");
      printf("*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing\n");
      printf("*** /etc/ld.so.conf. Make sure you have run ldconfig if that is\n");
      printf("*** required on your system.\n");
      printf("*** If gtk-config was wrong, set the environment variable GTK_CONFIG\n");
      printf("*** to point to the correct copy of gtk-config, and remove the file config.cache\n");
      printf("*** before re-running configure\n");
    } 
#if defined (GTK_MAJOR_VERSION) && defined (GTK_MINOR_VERSION) && defined (GTK_MICRO_VERSION)
  else if ((gtk_major_version != GTK_MAJOR_VERSION) ||
	   (gtk_minor_version != GTK_MINOR_VERSION) ||
           (gtk_micro_version != GTK_MICRO_VERSION))
    {
      printf("*** GTK+ header files (version %d.%d.%d) do not match\n",
	     GTK_MAJOR_VERSION, GTK_MINOR_VERSION, GTK_MICRO_VERSION);
      printf("*** library (version %d.%d.%d)\n",
	     gtk_major_version, gtk_minor_version, gtk_micro_version);
    }
#endif /* defined (GTK_MAJOR_VERSION) ... */
  else
    {
      if ((gtk_major_version > major) ||
        ((gtk_major_version == major) && (gtk_minor_version > minor)) ||
        ((gtk_major_version == major) && (gtk_minor_version == minor) && (gtk_micro_version >= micro)))
      {
        return 0;
       }
     else
      {
        printf("\n*** An old version of GTK+ (%d.%d.%d) was found.\n",
               gtk_major_version, gtk_minor_version, gtk_micro_version);
        printf("*** You need a version of GTK+ newer than %d.%d.%d. The latest version of\n",
	       major, minor, micro);
        printf("*** GTK+ is always available from ftp://ftp.gtk.org.\n");
        printf("***\n");
        printf("*** If you have already installed a sufficiently new version, this error\n");
        printf("*** probably means that the wrong copy of the gtk-config shell script is\n");
        printf("*** being found. The easiest way to fix this is to remove the old version\n");
        printf("*** of GTK+, but you can also set the GTK_CONFIG environment to point to the\n");
        printf("*** correct copy of gtk-config. (In this case, you will have to\n");
        printf("*** modify your LD_LIBRARY_PATH enviroment variable, or edit /etc/ld.so.conf\n");
        printf("*** so that the correct libraries are found at run-time))\n");
      }
    }
  return 1;
}
],, no_gtk=yes,[echo $ac_n "cross compiling; assumed OK... $ac_c"])
       CFLAGS="$ac_save_CFLAGS"
       LIBS="$ac_save_LIBS"
     fi
  fi
  if test "x$no_gtk" = x ; then
     AC_MSG_RESULT(yes)
     ifelse([$2], , :, [$2])     
  else
     AC_MSG_RESULT(no)
     if test "$GTK_CONFIG" = "no" ; then
       echo "*** The gtk-config script installed by GTK could not be found"
       echo "*** If GTK was installed in PREFIX, make sure PREFIX/bin is in"
       echo "*** your path, or set the GTK_CONFIG environment variable to the"
       echo "*** full path to gtk-config."
     else
       if test -f conf.gtktest ; then
        :
       else
          echo "*** Could not run GTK test program, checking why..."
          CFLAGS="$CFLAGS $GTK_CFLAGS"
          LIBS="$LIBS $GTK_LIBS"
          AC_TRY_LINK([
#include <gtk/gtk.h>
#include <stdio.h>
],      [ return ((gtk_major_version) || (gtk_minor_version) || (gtk_micro_version)); ],
        [ echo "*** The test program compiled, but did not run. This usually means"
          echo "*** that the run-time linker is not finding GTK or finding the wrong"
          echo "*** version of GTK. If it is not finding GTK, you'll need to set your"
          echo "*** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point"
          echo "*** to the installed location  Also, make sure you have run ldconfig if that"
          echo "*** is required on your system"
	  echo "***"
          echo "*** If you have an old version installed, it is best to remove it, although"
          echo "*** you may also be able to get things to work by modifying LD_LIBRARY_PATH"
          echo "***"
          echo "*** If you have a RedHat 5.0 system, you should remove the GTK package that"
          echo "*** came with the system with the command"
          echo "***"
          echo "***    rpm --erase --nodeps gtk gtk-devel" ],
        [ echo "*** The test program failed to compile or link. See the file config.log for the"
          echo "*** exact error that occured. This usually means GTK was incorrectly installed"
          echo "*** or that you have moved GTK since it was installed. In the latter case, you"
          echo "*** may want to edit the gtk-config script: $GTK_CONFIG" ])
          CFLAGS="$ac_save_CFLAGS"
          LIBS="$ac_save_LIBS"
       fi
     fi
     GTK_CFLAGS=""
     GTK_LIBS=""
     ifelse([$3], , :, [$3])
  fi
  AC_SUBST(GTK_CFLAGS)
  AC_SUBST(GTK_LIBS)
  rm -f conf.gtktest
])
That should get you building for gtk1, so you can see that it works. Meanwhile, I'll work on getting configuration working for gtk2 with a '--with-gtk' or '--with gtk2' option. Then we can finalize all of it as 'shadow' version 0.58.11 before moving on -okay? I just want to get what is working neatly wrapped with nice ChangeLog entries and well-checked start. Please sign the AUTHORS and ChangeLog.

Sorry, I missed seeing your UPDATE before posting, so some of the stuff above may not be needed. If you've gotten it running then *very* good. That way you can see we are on the same page.

"make do the rest" -nice, huh? We can probably wrap up this version today then, with a little cooperation.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#52 Post by goingnuts »

Amigo: Thanks for the walk-through for the autogen.sh errors. You will have to guide me a little: What do you mean by "Please sign the AUTHORS and ChangeLog"?
If I understand you correct we fix the present sourcecode now together with your buildtools as a new starting point. After that all changes to code is reported in changelog (in wording) and new builds will be made from patches applied to this fix-point? Communication has always been difficult - but most of the time we are not aware :)

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#53 Post by amigo »

Yes, you understood about the process. What I meant about signing the ChangeLog and AUTHORS, please look at the files. In the authors file it would be nice to have an email address and if you're not vehemently opposed, put your real name in there. I'll take care of the ChangeLog -just an initial entry to 'declare' the port with credits and an explanation of the starting standpoint.

I've already fixed the gtk1/gtk2 configuration. Unfortunately it just won't build for gtk2 here -I'm pretty sure it has to do with gtk2 version what version are you running?

The only change needed for gtk2 and the option is in configure.in. I'll quickly post it here so you can check if it is getting everything setup properly. Note that to support (my) gtk-2.24 we are gonna have to setup gdk-pixbuf for that as will -it has been split (back) out of gtk2 -like it is for gtk1.

configure.in:

Code: Select all

# Process this file with autoconf to produce a configure script.
AC_INIT(gtkdialog1, 0.58.10, pipas@linux.pte.hu)
#AM_CONFIG_HEADER([config.h])
AC_CONFIG_SRCDIR([src/main.c])
AM_INIT_AUTOMAKE(gtkdialog1, 0.58.10)
# Checks for programs.
AC_PROG_CC
AM_PROG_LEX
AC_PROG_YACC

# Checks for libraries.

AC_SUBST(YACC)
#YACC="yacc"
#AC_SUBST(YFLAGS)

# Checks for header files.
AC_CHECK_HEADERS([locale.h])

# A GTK dolgait ide tettem be
# Pipás


AC_ARG_WITH(gtk,
	[  --with-gtk=[version]	  which version of GTK+ to use ( 1.2 | 2.0 )],
	[ac_cv_gtkversion=$withval], [ac_cv_gtkversion="2.0"])
if test ! "$ac_cv_gtkversion" = "2.0"  -a  ! "$ac_cv_gtkversion" = "1.2"; then
	AC_MSG_ERROR([You didn't specify a correct GTK+ version. 
	  Use only "2.0" or "1.2".])
fi

if test "$ac_cv_gtkversion" = "2.0"; then
	AM_PATH_GLIB_2_0(2.0.0,,[AC_MSG_RESULT([
GLIB 2.0 was not found. I will try for GLIB 1.2 later.
])
	  ac_cv_gtkversion="1.2"])
	AM_PATH_GTK_2_0(2.0.0,,[AC_MSG_RESULT([
GTK+ 2.0 was not found. I will try for GTK+ 1.2 later.
])
	  ac_cv_gtkversion="1.2"])
fi

if test "$ac_cv_gtkversion" = "1.2"; then
	AM_PATH_GLIB(1.2.10,,
          AC_MSG_ERROR(Test for GLIB failed. See the file 'INSTALL' for help.))
	AM_PATH_GTK(1.2.10,,
          AC_MSG_ERROR(Test for GTK failed. See the file 'INSTALL' for help.))
	AM_PATH_GDK_PIXBUF(0.22.0,,
          AC_MSG_ERROR(Test for GDK_PIXBUF failed. See the file 'INSTALL' for help.))
fi


if test "$ac_cv_gtkversion" = "2.0"; then
	dnl support for gtk+2-2.24 is going to need PIXBUF setup
	dnl since it has been split from gtk sources (again)
	AC_DEFINE(USE_GTK2)
	AC_DEFINE(GTK2)
fi

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.
AC_CHECK_FUNCS([setlocale])

#AC_CONFIG_FILES([])
AC_OUTPUT(Makefile gtkdialog.spec src/Makefile doc/Makefile examples/Makefile)

If that builds for you then it's just a couple of touch-ups to make the first release.

Edit:
"patches applied to this fix-point"
A new release with new tarball would follow each round of additions. We can pass small patches back and forth during each cycle to avoid attaching full tarballs. When we shadow the upstream versions you'll see that usually the changes are pretty manageable. I'll have some more suggestions on that as we move forward.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#54 Post by goingnuts »

My gtk version is 2.12.
The new configure.in builds gtk1 version fine if I change minimum gdkpixbuf version to 0.21.0.

For the gtk2 version I needed to #ifndef USE_GTK2 the 3 imagefunctions in start of automaton.c (GdkPixbuf *scale_pixbuf, GdkPixbuf *scale_pixbuf_up and *xpm_label_box) to get it building.
It builds fine - but there are no scaling of the images so some of the test scripts spits out a really big GUI with some big buttons :)

When I build the latest source gtk2 with my own buildscript images scaled fine without need for pixbuf. But anyway this is not a big deal - maybe change the hole original image handling to rely on the new gtk1 code.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#55 Post by amigo »

"gdkpixbuf version to 0.21.0"
Easy change.

"#ifndef USE_GTK2 the 3 imagefunctions"
Okay. speaking of that, we have both:
#ifdef USE_GTK2
and:
#ifdef GTK2
Did you introduce the 'USE_GTK2' or was that already found somewhere in the code? grep doesn't find it in the original 0.58.10 We should standardize that to be consistent with upstream.

"image scaling" I'll have a look at your Makefile.gtk2 and see what you may have needed there -I may have missed something in configure.in
About "maybe change the image handling", One of the reasons I was having trouble bringing your original code into original step-by-steo was beacuse of the image-handling. Looking at what was going on, I had an idea that it might be cleaner to implement the STOCK icons support by copying the gtk2 functions which handle that into our sources(for gtk1) so that it would be more transparent in the up-front code. And, pixbuf should support handling xpm's, unless I'm wrong, so the direct-handling of xpm's could be eliminated. It might need a little modification to get it to work for gtk1 while looking like gtk2 code. I'm thinking it would be easier and cleaner to support theme-able icons that way, for both gtk1 and gtk2. But that could be left for the next round, if you like -what you have already is working.

The scaling for gtk2 should be sorted out. I had a thought about the extra scaling code you imported from rox. It might be good to keep stuff like this in another *.c file as there will probably be more of it later and it helps keep line-numbers more in sync with upstream. A file 'utils.c' and, if needed utils.h, would be easy to add to the sources.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#56 Post by goingnuts »

I introduced the #ifdef USE_GTK2 and in the latest source I also introduced #ifdef USEPIXBUF. We can change to #ifdef GTK2 - I do not find that term in my sources but I might be wrong there - but easier to write and read.

I suggest that all major additions end up in new utils.C or whatever or we could add in the bottom of existing source.

I will be off line for some hours but will pick up later to night.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#57 Post by amigo »

Hey great! With the last little addition of the extra "gdk_pixmap_colormap_create_from_xpm" code in automaton.c, this now builds for gtk2 here. There are just a couple of warnings:
conflicts: 20 shift/reduce
/usr/src/KISS-5/testing/GtkDialog1/GtkDialog1-0.58.10a/src/lexer.l:151: warning, rule cannot be matched
automaton.c: In function 'create_menuitem':
automaton.c:644:3: warning: passing argument 3 of 'gtk_signal_connect_full' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtksignal.h:119:8: note: expected 'GCallback' but argument is of type 'void (*)(struct GtkWidget *, struct AttributeSet *)'
actions.c: In function 'action_fileselection_made':
actions.c:181:5: warning: passing argument 2 of 'fill_edit_by_file' discards qualifiers from pointer target type
widgets.h:38:6: note: expected 'char *' but argument is of type 'const gchar *'
actions.c:189:5: warning: passing argument 2 of 'variables_set_value' discards qualifiers from pointer target type
variables.h:39:11: note: expected 'char *' but argument is of type 'const gchar *'
I get those by running 'make 2> errors.txt'. If you are net getting those errors it would mean they come from my later version of gtk2. Still, it did build and runs. I haven't checked out the scaling and other image functions yet, but will do so.

The choice of gtk1/gtk2 is an option to configure. The default is to build gtk2. The usage is: '--with-gtk=(1.2|2.0)'. For now I have left the AC_DEFINE(USEPIXBUF) set arbitrarily to be defined. I'll have to study the autoconf stuff a bit more to see how to set that up as a command-line option. You can check if things work without it by commenting the line out in configure.in (comment with 'dnl'). Be sure to remove the configure script and re-run autogen.sh (or simply 'autoconf') to re-generate the configure script.

If there are still scaling problems with gtk2 or any other glaring problems it would be good to get them out of the way now, but I don't mean gerneral bug-fixing throughout the code. Just make sure the added code is working properly. Once that is done, then just a small bit of editing the ChangeLog/AUTHORS and configure.in for the version number and we can release that as GtkDialog1-0.58.11
BTW, I'm using CamelCase in the name so it stands out a bit visually from the original sources -especially (for now, at least) since we are shadowing the original versions. That can be changed anytime it seems right (the CamelCase or the versioning).

Attached is a fresh tarball with your last changes and others I made. If you haven't noticed yet, I have included your examples under top dir examples/new -except I left out the puppy-specific ones -they might do something undesired if someone carelessly tries them. Also, I have edited all the examples new and old, to reflect the name-change and to add some indentation to them -I hate looking at those scripts without good indents -especially if viewing them as a shell script instead of as xml-type code.

I'm also attaching a copy of the ChangeLog which technosaurus included in the 'history' archive, except that I have re-ordered the first few entries which were backwards from the entries once 0.7.2 is reached. Makes it a little easier to follow.

P.S. I was wrong about there being 'ifdef GTK2' in the original sources.
Attachments
ChangeLog.gz
Re-arranged ChangeLog (gzipped)
(3.27 KiB) Downloaded 406 times

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#58 Post by goingnuts »

Thats great! I did some quick test on the image scaling: I was wrong - my gtk2-build also fails scaling images. Not quite sure what is going on but I will look into it.

Testing you new tarball now. After running autogen.sh, I run "./configure --with-gtk=1.2". After that make - but it seems to end in an endless loop where configure is run again and again. Same thing if I try --with-gtk=2.0. So haven't been able to build it that way...
If I copy autogen.sh and configure.in from your previous tarball and run the things again it works and I can build gtk1 and gtk2 versions. gtk1 scales images fine but the gtk2 fails to do that.

Your work on the examples look good! Better for the eyes to look at! I did try a few of them with gtk1&2 version: They run! Only I am missing dash so had to change that. Maybe we should in general use #!/bin/sh?

Please note that the build-in images in the latest source are changed - I had to change to

Code: Select all

#ifdef USEPIXBUF 
const char *error_xpm[] = {
#else
static char *error_xpm[] = {
#endif
in the top to avoid warnings - do not know if still needed... Also the cancel.xpm is unused so could be left out.

Well done amigo! Lets give it a couple of days before we finally fix the starting point - just to get the most annoying things disappear.
UPDATE: Found errors that trigs the scaling in gtk2. Also seems that the original does not scale as well. I will try to fix that and if test shows it runs ok post the patch.

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#59 Post by disciple »

Are you guys going to put this in svn or something?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#60 Post by amigo »

I have no time for managing another repo or site. I will most certainly have a place on my site where the sources are available -I'd do that anyway since it as gtk1 dream-come-true. And it's going right into my distro too in both gtk1 and gtk2 versions.

goingnuts sets the pace and can decide what he wants to do -I'm just pitching in with a little organization help -doing 'grunt' work like updating the docs and keeping autoconf happy.

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#61 Post by disciple »

Just to complete what I was thinking about when I asked: it might be worth asking Thunor if it could be added to the main gtkdialog svn repo at google code.
Personally I find it much easier to keep something in svn :)
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#62 Post by goingnuts »

I think this projects aim and target user differ from the ones of the official gtkdialog. So linking it to that might be to overdo (or even miss do) things. This backport is in the category "hobby-project" - propably with a very limited audiens now and audiens will probably be decreasing as time goes by. Using depreciated toolkits seems not to be attractive nowadays.

The strength of the backport should be speed, size, limited number of dependencies and shared syntax for the gtk1 & 2 version.

The new gtkdialog versions implement many usefull things but also get more and more complex. In the end its a balance between the usefullness of making toolkits on toolkits on toolkits, the ease of making the software "from-scratch" and your target users.

If we can carry this thing up to the level where it accepts syntax up to the 0.7.20 version (without support for every syntax/widget there) and a resonable number of usefull widgets keeping the compatability with gtk1 & 2 - I quess thats it.

I have thought of whether the project even qualify being on this forum - but as the main content here will be related to programming (depreciated) gtk - I guess it does in some sense...

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#63 Post by amigo »

I agree. I was just taking a peek into thunors repo and noticed this:
"This release adds 14 new widgets, 37 new examples, a full widget reference, and much more." Sounds a bit out-of-hand to me. Don't get me wrong I think thunor is doing a fine job -I just question the utility of many of the widgets for this type of tool. There comes a point where the complexity of writing a sane script-based GUI is cumbersome, at best, and maybe disastrous at worst. People shouldn't really be trying to code a file manager or something like that in shell anyway.

GN, I'm glad to see you pin this down:"syntax up to the 0.7.20 version"
And a agree that it would be st to leave out any widgets implemented up to that point which can't be implemented well for gtk1, like the 'tree' widget which we are currently leaving out. There are new widgets which are introduced before 0.7.20 which may be interesting. One of them is the 'notebook'. technosaurus has posted some code for that which could probably be wrangled in. The 'tree' code for gtk1 would also be interesting, if you ever figure that out. Especially interesting because if you figure it out, you may be able to do a long-sought-trick and add a tree-view to the rox filer. Lots of people have wished for that.

I think that once the feature-richness is up to an acceptable level, it would be fairly easy to review thunors code for any bug-fixes which would apply to the older sources.

Another day, another archive. Attaching latest tarball

It contains the latest fixes you sent me, and I have moced the rox pixbuf-scaling routines into a separate file misc.c

This builds and runs fine here for both gtk1 and gtk1, but I do get these warnings when compiling for gtk2:
automaton.c: In function 'xpm_label_box':
automaton.c:99:8: warning: assignment from incompatible pointer type
automaton.c:101:8: warning: assignment from incompatible pointer type
automaton.c:103:8: warning: assignment from incompatible pointer type
automaton.c:105:8: warning: assignment from incompatible pointer type
automaton.c:111:17: warning: assignment makes pointer from integer without a cast
automaton.c:127:18: warning: assignment makes pointer from integer without a cast
automaton.c:128:18: warning: assignment makes pointer from integer without a cast
automaton.c:130:18: warning: assignment makes pointer from integer without a cast
automaton.c: In function 'create_menuitem':
automaton.c:585:3: warning: passing argument 3 of 'gtk_signal_connect_full' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtksignal.h:119:8: note: expected 'GCallback' but argument is of type 'void (*)(struct GtkWidget *, struct AttributeSet *)'
actions.c: In function 'action_fileselection_made':
actions.c:181:5: warning: passing argument 2 of 'fill_edit_by_file' discards qualifiers from pointer target type
widgets.h:38:6: note: expected 'char *' but argument is of type 'const gchar *'
actions.c:189:5: warning: passing argument 2 of 'variables_set_value' discards qualifiers from pointer target type
variables.h:39:11: note: expected 'char *' but argument is of type 'const gchar *'
They are the same as before, except the 'integer without a cast' ones which result when having moved the scaling code from automaton.c to misc.c. Perhaps you can clean up my mess, if needed. Also, couldn't the USEPIXBUF simply be eliminated if we are always using it anyway?

Apart from that, this is ready to be released, I think.

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#64 Post by Aitch »

The 'tree' code for gtk1 would also be interesting, if you ever figure that out. Especially interesting because if you figure it out, you may be able to do a long-sought-trick and add a tree-view to the rox filer. Lots of people have wished for that
Oh yes! :D

Aitch :)

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#65 Post by goingnuts »

amigo: Well done - we fix this as a starting point! Found again that make goes into an endless loop but after running "touch" on all the source files everything works (you are somewhere in the future and my make seems not to like that :) ).
The "warning: assignment from incompatible pointer type" can be eliminated by changing configure.in:

Code: Select all

if test "$ac_cv_gtkversion" = "2.0"; then
	dnl support for gtk+2-2.24 is going to need PIXBUF setup
	dnl since it has been split from gtk sources (again)
	AC_DEFINE(USE_GTK2)
	AC_DEFINE(USEPIXBUF)
fi
The " warning: assignment makes pointer from integer without a cast" I will have to look into. I already spotted some bugs in action windowclose for gtk2 and the save action for both gtk1&2. I will work on those.

Next step besides testing gtk2 versus gtk1 will be to control the parser. Think it is important to verify that we can add widgets or expand the syntax..

Aitch & amigo: The tree...that is probably another project.

Post Reply