RSS/Atom feed Twitter
Site is read-only, email is disabled

GimpDialog API change

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

6 of 6 messages available
Toggle history

Please log in to manage your subscriptions.

GimpDialog API change Michael Natterer 04 Nov 12:28
  GimpDialog API change David Neary 04 Nov 20:43
   GimpDialog API change Michael Natterer 06 Nov 11:01
    GimpDialog API change David Neary 06 Nov 14:15
     GimpDialog API change Sven Neumann 06 Nov 15:28
  GimpDialog API change David Odin 04 Nov 23:52
Michael Natterer
2003-11-04 12:28:09 UTC (over 20 years ago)

GimpDialog API change

Hi,

As you may know, GimpDialog from libgimpwidgets badly needs an API change for GIMP 2.0.

The relevant bugzilla entry: http://bugzilla.gnome.org/show_bug.cgi?id=125143

The plan is to just remove our own action_area API and use GtkDialog's one, which involves making use of the dialog's "response" signal instead of connecting to each button's "clicked".

The old API is just way too complicated and does things nobody really needs. The new stuff boils down to one function:

/** * gimp_dialog_new:
* @title: The dialog's title which will be set with * gtk_window_set_title(). * @role: The dialog's @role which will be set with * gtk_window_set_role(). * @parent: The @parent widget of this dialog. * @flags: The @flags (see the #GtkDialog documentation). * @help_func: The function which will be called if the user presses "F1". * @help_id: The help_id which will be passed to @help_func. * @...: A %NULL-terminated @va_list destribing the * action_area buttons. *
* Creates a new @GimpDialog widget. *
* This function simply packs the action_area arguments passed in "..." * into a @va_list variable and passes everything to gimp_dialog_new_valist(). *
* For a description of the format of the @va_list describing the * action_area buttons see gtk_dialog_new_with_buttons(). *
* Returns: A #GimpDialog.
**/
GtkWidget *
gimp_dialog_new (const gchar *title, const gchar *role, GtkWidget *parent, GtkDialogFlags flags, GimpHelpFunc help_func, const gchar *help_id, ...);

Of course there will be a _valist() variant.

I'll start hacking this today but would like to get some ACKs or EEKs before I start porting the plug-ins (which have many many GimpDialogs).

ciao, --mitch

David Neary
2003-11-04 20:43:51 UTC (over 20 years ago)

GimpDialog API change

Hi Mitch,

Michael Natterer wrote:

GtkWidget *
gimp_dialog_new (const gchar *title, const gchar *role, GtkWidget *parent, GtkDialogFlags flags, GimpHelpFunc help_func, const gchar *help_id, ...);

This looks good to me.

I'll start hacking this today but would like to get some ACKs or EEKs before I start porting the plug-ins (which have many many GimpDialogs).

One question... do you think it would be worthwhile to make the API change, document what needs to be done to change from the old API to the new, and then have a number of people work on porting the plug-ins? Each plug-in in itself would probably be a small job, but the lot of them might take you a while.

Would this be worthwhile? I would certainly do a few plug-ins, are there others who would be able to help out here?

Cheers, Dave.

David Odin
2003-11-04 23:52:51 UTC (over 20 years ago)

GimpDialog API change

On Tue, Nov 04, 2003 at 12:28:09PM +0100, Michael Natterer wrote:

Hi,

As you may know, GimpDialog from libgimpwidgets badly needs an API change for GIMP 2.0.

The relevant bugzilla entry: http://bugzilla.gnome.org/show_bug.cgi?id=125143

The plan is to just remove our own action_area API and use GtkDialog's one, which involves making use of the dialog's "response" signal instead of connecting to each button's "clicked".

The old API is just way too complicated and does things nobody really needs. The new stuff boils down to one function:

/** * gimp_dialog_new:
* @title: The dialog's title which will be set with * gtk_window_set_title(). * @role: The dialog's @role which will be set with * gtk_window_set_role(). * @parent: The @parent widget of this dialog. * @flags: The @flags (see the #GtkDialog documentation). * @help_func: The function which will be called if the user presses "F1". * @help_id: The help_id which will be passed to @help_func. * @...: A %NULL-terminated @va_list destribing the * action_area buttons. *
* Creates a new @GimpDialog widget. *
* This function simply packs the action_area arguments passed in "..." * into a @va_list variable and passes everything to gimp_dialog_new_valist(). *
* For a description of the format of the @va_list describing the * action_area buttons see gtk_dialog_new_with_buttons(). *
* Returns: A #GimpDialog.
**/
GtkWidget *
gimp_dialog_new (const gchar *title, const gchar *role, GtkWidget *parent, GtkDialogFlags flags, GimpHelpFunc help_func, const gchar *help_id, ...);

Of course there will be a _valist() variant.

I'll start hacking this today but would like to get some ACKs or EEKs before I start porting the plug-ins (which have many many GimpDialogs).

You have my bless on this. As I've said I can help you converting some of the plug-ins.

DindinX

Michael Natterer
2003-11-06 11:01:39 UTC (over 20 years ago)

GimpDialog API change

David Neary writes:

One question... do you think it would be worthwhile to make the API change, document what needs to be done to change from the old API to the new, and then have a number of people work on porting the plug-ins? Each plug-in in itself would probably be a small job, but the lot of them might take you a while.

Would this be worthwhile? I would certainly do a few plug-ins, are there others who would be able to help out here?

Hi,

Thanks for offering help on this huge hack.

While there is certainly help needed (my fingers start to break when i try to type 'GTK_RESPONSE_FOO' :-), I don't really know how this could be done by several people without temporarily breaking half of the tree.

gimp_dialog_new()'s API has changed in an incompatible way so unported plug-ins break. I thought about adding a temporary new API first, port them step by step, and then do a perl hack on the tree to rename all new functions back to gimp_dialog_new(). However this will hardly result in a nicely formated source, they would al have to be edited manually again. (guess why i hesitated so long before starting this ;)

After all, I think this API change is best committed atomically, so I'll just continue hacking the plug-ins and commit everything today or tomorrow.

ciao,
--mitch

David Neary
2003-11-06 14:15:13 UTC (over 20 years ago)

GimpDialog API change

Michael Natterer wrote:

David Neary writes:

Would this be worthwhile? I would certainly do a few plug-ins, are there others who would be able to help out here?

While there is certainly help needed (my fingers start to break when i try to type 'GTK_RESPONSE_FOO' :-), I don't really know how this could be done by several people without temporarily breaking half of the tree.

We could create a branch... it would be pretty shortlived.

Or we could let the plug-ins break temporarily, letting people know that's going to happen (and at the same time pointing them to a doc about what needs doing to get a plug-in fixed).

After all, I think this API change is best committed atomically, so I'll just continue hacking the plug-ins and commit everything today or tomorrow.

If you think you'll be done that quickly, that's perhaps best.

Cheers, Dave.

Sven Neumann
2003-11-06 15:28:56 UTC (over 20 years ago)

GimpDialog API change

Hi,

David Neary writes:

After all, I think this API change is best committed atomically, so I'll just continue hacking the plug-ins and commit everything today or tomorrow.

If you think you'll be done that quickly, that's perhaps best.

From looking over Mitch's shoulder I know that he's almost done with

all plug-ins already. So what's left for you to do is to watch CVS and when the change is committed, please go through all plug-ins and give them some testing. Test all buttons found in the plug-in dialog's action area. It is not unlikely that a few plug-ins will break but it should be easy to fix them.

Sven