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

Re: Reworking the GTK+ cdebconf frontend



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

ps

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



Reply to: