Hosting Provided By

Re: Reworking the GTK+ cdebconf frontend

From: Attilio Fiandrotti <attilio.fiandrotti(at)gmail.com>
Date: Thu Jun 28 2007 - 04:31:29 EDT

Colin Watson wrote:
> On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote:

>> * r47575
>> - There are plans for having cdebconf replacing debconf someday, this 
>> means the gtk frontend should build against gtk/x11 too [1].
>> Including more directfb private includes files goes the oppposite way, 
>> so this change is wrong.

>
> Attilio, the includes go with the function calls. Either you have both
> private dfb_* function calls and private directfb includes, or you have
> neither. You can't have it both ways! If you want it to build against
> GTK/X11, use ifdefs around both the includes and the function calls.
>
> Current cdebconf warns:
>
> /home/cjwatson/d-i/packages/cdebconf/src/modules/frontend/gtk/gtk.c: In function â€˜gtk_goâ€™:
> /home/cjwatson/d-i/packages/cdebconf/src/modules/frontend/gtk/gtk.c:1475: warning: implicit declaration of function â€˜dfb_input_device_reload_keymapâ€™
> /home/cjwatson/d-i/packages/cdebconf/src/modules/frontend/gtk/gtk.c:1475: warning: implicit declaration of function â€˜dfb_input_device_atâ€™
>
> ... and this is unambiguously a bug, no matter how it gets fixed.

I've been thinking a lot in the past about the optimal way to implement keymap reloading in g-i.
The cleanest solution would probably be delegating keymap reloading (acually, the calling of dfb_input_device_reload_keymap() ) to an external application, called by the a debconf client only when needed, and not by the frontend.
This was stated being impossible because our directfb libraries, IIRC, are built without the multiapp support (and we neither have the fusion module packaged).
So, the keymap reloading function has to be called by the cdebconf process.

Because keymap reloading may be a common issue for other gtk/dfb based apps, i think a reasonable way to proceed is adding a

gdk_directfb_keymap_reload()

function to the directfb gdk backend (other directfb specialized functions already exist in that backend, like gdk_directfb_window_set_opacity() etc.. ) This would save us from including directfb's header files from the GTK frontend and directly calling directfb functions from within it. I could propose a patch and apply it upstream, but i'd like to hear an opinion from our gtk/dfb maintiner: Loic, what's your opinion on this issue?

regards

Attilio

Do you need help?

Still, this wouldn't allow building the gtk frontend against gtk/x11 (#402127), which is a different bug which should be fixed apart.

-- 
To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Received on Thu Jun 28 04:28:07 2007

This message: [ Message body ]
Next message: Colin Watson: "Re: r47706 - in trunk/packages/cdebconf: debian src"
Previous message: Christian Perrier: "Re: r47706 - in trunk/packages/cdebconf: debian src"
In reply to: Colin Watson: "Re: Reworking the GTK+ cdebconf frontend"
Next in thread: Loïc Minier: "Re: Reworking the GTK+ cdebconf frontend"
Reply: Loïc Minier: "Re: Reworking the GTK+ cdebconf frontend"

Contemporary messages sorted: [ By Date ] [ By Thread ] [ By Subject ] [ By Author ] [ By messages with attachments ]

This archive was generated by hypermail 2.1.8 : Thu Jun 28 2007 - 04:30:07 EDT