Processing commands for [EMAIL PROTECTED]:
> tags 402126 pending
Bug#402126: GTK frontend should not reload keymap at every frontend_go() call
There were no tags set.
Tags added: pending
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system admi
tags 402126 pending
thanks
Attilio Fiandrotti wrote:
4) As suggested by Jeremy on IRC, reading d-i/keymap while keeping track
of last known value and looking for changes.
This is, IMHO, the easiest solution available ATM, and morover doesn't
require touching other parts of the installer th
On Mon, Jul 02, 2007 at 10:45:47AM +0200, Attilio Fiandrotti wrote:
> We must decide anyway how kbd-chooser and the GTK frontend should
> communicate (although it's one-way signaling, from kbd-chooser to the
> GTK frontend).
>
> Options are
>
> 1) by mean of a debconf question (debconf abuse?)
Attilio Fiandrotti wrote:
Frans Pop wrote:
On Monday 02 July 2007 09:34, Attilio Fiandrotti wrote:
A reasonable improvement over current situation could prbably be
setting TRUE a boolean "d-i/keymap_changed" question from within the
keymap-chooser everytime the console keymap is updated.
This
Frans Pop wrote:
On Monday 02 July 2007 09:34, Attilio Fiandrotti wrote:
A reasonable improvement over current situation could prbably be
setting TRUE a boolean "d-i/keymap_changed" question from within the
keymap-chooser everytime the console keymap is updated.
This could be an option, but us
Loïc Minier wrote:
On Mon, Jul 02, 2007, Attilio Fiandrotti wrote:
The core of the problem is not detecting the keymap change at the toolkit
level (which is unimportant in our case) but rather informing the windowing
system (DirectFB in our case) that the keymap has to be updated to match
the
On Mon, Jul 02, 2007, Attilio Fiandrotti wrote:
> The core of the problem is not detecting the keymap change at the toolkit
> level (which is unimportant in our case) but rather informing the windowing
> system (DirectFB in our case) that the keymap has to be updated to match
> the console one s
On Monday 02 July 2007 09:34, Attilio Fiandrotti wrote:
> A reasonable improvement over current situation could prbably be
> setting TRUE a boolean "d-i/keymap_changed" question from within the
> keymap-chooser everytime the console keymap is updated.
This could be an option, but using debconf for
Loïc Minier wrote:
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()
Would there be a X11 equivalent for this? I'm not sure I agree Gdk
needs to gain a directfb specific function conc
On Thu, Jun 28, 2007, Attilio Fiandrotti wrote:
[...]
> 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.
Hm
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 w
Colin Watson <[EMAIL PROTECTED]> writes:
> On Fri, Jun 22, 2007 at 11:52:56AM +0200, Attilio Fiandrotti wrote:
>> Apropos of the way of performing commits, after the g-i became part of
>> official builds i became very prudent about committing huge changes to
>> the sourcecode.
>>
>> If you look
On Fri, Jun 22, 2007 at 11:52:56AM +0200, Attilio Fiandrotti wrote:
> Apropos of the way of performing commits, after the g-i became part of
> official builds i became very prudent about committing huge changes to
> the sourcecode.
>
> If you look into last months d-boot archives, you'll see tha
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
Jérémy Bobbio wrote:
On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote:
I must evantually say i'm disappointed of the way the gtk frontend code
was nonchalantly modified, without any patch being posted and discussed
on d-boot previously, moreover proving to ignore many design d
Jérémy Bobbio wrote:
On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote:
I must evantually say i'm disappointed of the way the gtk frontend code
was nonchalantly modified, without any patch being posted and discussed
on d-boot previously, moreover proving to ignore many design d
Jérémy Bobbio wrote:
On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote:
I must evantually say i'm disappointed of the way the gtk frontend code
was nonchalantly modified, without any patch being posted and discussed
on d-boot previously, moreover proving to ignore many design d
On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote:
> I must evantually say i'm disappointed of the way the gtk frontend code
> was nonchalantly modified, without any patch being posted and discussed
> on d-boot previously, moreover proving to ignore many design decisions
> behin
Jérémy Bobbio wrote:
On Thu, Jun 21, 2007 at 10:39:24AM +0200, Attilio Fiandrotti wrote:
Jérémy Bobbio wrote:
The whole frontend is currently in one huge single C file. I'm
proofreading the whole thing for refactoring, memory leaks, potentiel
segfauts, etc.
I'd like to know What's the problem
On Thu, Jun 21, 2007 at 10:39:24AM +0200, Attilio Fiandrotti wrote:
> Jérémy Bobbio wrote:
> >The whole frontend is currently in one huge single C file. I'm
> >proofreading the whole thing for refactoring, memory leaks, potentiel
> >segfauts, etc.
>
> I'd like to know What's the problem in having
Jérémy Bobbio wrote:
Hi!
Just a short notice to tell everyone that I have started to work on
improving the code of the GTK+ frontend for cdebconf.
The whole frontend is currently in one huge single C file. I'm
proofreading the whole thing for refactoring, memory leaks, potentiel
segfauts, etc.
Hi!
Just a short notice to tell everyone that I have started to work on
improving the code of the GTK+ frontend for cdebconf.
The whole frontend is currently in one huge single C file. I'm
proofreading the whole thing for refactoring, memory leaks, potentiel
segfauts, etc.
This should keep me p
22 matches
Mail list logo
