guile-gtk-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New demos for guile-gtk-demo


From: Andy Wingo
Subject: Re: New demos for guile-gtk-demo
Date: Mon, 13 Sep 2004 22:20:13 +0200

Hey Patrick,

First off, sorry for the three-and-a-half month delay in replying. My
bad.

On Tue, 2004-06-01 at 20:02 +0200, Patrick Bernaud wrote: 
> Some new demos from gtk-demo are ready to be added to the main
> trunk, namely dialog, editable-cells, entry-completion, list-store,
> menus, panes and tree-store.

Sweet. I looked at these, they look good. I'm new at this GNU stuff, but
it seems copyrights on all files are necessary. It's a good practice; I
can't tell what the copyrights are on the original Gtk+ gtk-demo files.

So, if you could add a standard copyright block on your new files, that
would be fantastic. (I'm working on the old ones.)

Also, I'd appreciate it if you merge your changes with the current gtk--
dev--0, the ChangeLog patches will need manual help.

Now, the nit-picks :-)

It is possible to make stock images and labels with mnemonics via
`make':
 (make <gtk-image> :stock "gtk-foo")
 (make <gtk-label> :label "_foo" :use-underline #t)

In these cases, gobject-class-{get-properties,get-property-names} (the
suffixes in brackets are also generics) are useful. Although we really
need to implement Marius' Grand Help Scheme!

In appwindow.scm:
> (define register-stock-icons #f)
> (let ((registered #f))
>   (set! register-stock-icons
>       (lambda ()

Not sure what's going on here. `registered' is never used, but even if
it is, you can always do (define foo (let ((bar 42)) (lambda () ...))).
More schemey, perhaps ;)

>  (define (update-statusbar buffer . data)
>    (let* ((statusbar (car data))

Could always put statusbar in the formals.

>   (if (or (memq 'maximized new-window-state)
>           (memq 'fullscreen new-window-state))
>       #f
>       #t))))

I think you're looking for `not' ;)

> (define ui-info 
>   (string-append
>    "<ui>"
>    "  <menubar name='MenuBar'>"
>    "    <menu action='FileMenu'>"

This is kindof ugly. It would be nice to provide a ui-info->xml
procedure that would take an sexp:
(define ui-info
 `(ui
   (menu MenuBar
         (FileMenu New Open Save SaveAs | Quit)
         (PreferencesMenu
          (ColorMenu Red Green Blue)
          ...))
   (toolbar ...)))

This particular example isn't very extensible, but full SXML is verbose.
Dunno what people think about this idea.

                 (pixbuf   (if filename
                               (gdk-pixbuf-new-from-file filename)
                               #f))

Perhaps you are looking for and=>?

In dialog.scm:
    (set-transient-for dialog parent)
    (set-modal dialog #t)
    (set-destroy-with-parent dialog #t)
A lot of this can be done with properties when you make the dialog. It's
a general principle, I think.

editable-cells.scm is way too verbose. An alternate version is attached.
There's no need to duplicate your data store in lisp if it's in a tree
model. If you want it in lisp, derive your own custom tree model. (I
know, the python bindings demo has it wrong too.)

entry-completion.scm looks good, although in real life one would define
a list of completions, and for-each append them to the list store.

list-store.scm looks good I think. Should probably wrap list-store-new
so that it takes a rest arg with type classes instead of a list of
gtypes.

menus.scm looks good.

panes.scm:
         (is-child1 (if (eq? child (get-child1 paned)) #t #f))
Same as (eq? child (get-child1 paned)).

         (resize    (make <gboolean> #:value #f))
    (child-get-property paned child "resize" resize) 
Should wrap child-get-property more nicely. Mark this as a hack in the
source.

tree-store.scm:
A bit repetitive, should probably seek out some higher-level functions.
But it's OK.

ui-manager.scm:
One large quasiquote would look better for the entries. Would be nice if
the radio entries could have symbolic values, but it might not be
possible. set-flags of course needs to be wrapped. Otherwise, this looks
good I think.

</nit-picking>

> I also had to fix the GtkDialog accessors and added accessors for
> GtkColorSelectionDialog on the same model in preparation of the
> colorsel demo.

Nice work. And nice work with the actions, too.

> Since it is the first time I ever use arch, let me know if I am doing
> something wrong.

Seems OK to me. I started with arch on this project, too. It's grown on
me -- I mostly like it now.

>  - is there a reason for gobject-set-data! not being exported in
>    (gnome gobject gobject) ?

Hm, dunno. It's hacky? But I suppose there's no alternative (see
REFCOUNTING in the glib/ dir for a discussion). Sure, we can expose it.
Patch it in your tree and send me a merge request.

>  - can someone provide a working example of
>    gdk-bitmap-create-from-data? In particular I am not sure of the way
>    to format parameter two (const-guchar*).

I don't think anyone's looked too in depth at the gdk bindings. I think
however that raw byte data should be passed as uniform vectors. That's
the approach I've taken with GStreamer and DBus. It will require custom
wrappings.

Thanks for your contributions. I'll merge them in as soon as they apply
cleanly to the main branch.

Cheers,
-- 
Andy Wingo <address@hidden>
http://ambient.2y.net/wingo/

Attachment: editable-cells.scm
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]