Dear Eade
Support for DirectFB in recent GTK+ releases is broken: IIRC GTK+ 2.12
is the latest release with a working DirectFB backend.
BTW, you may want to resort to the precompiled binaries for ARM which
can be found in the debian repositories.
Attilio
Eade, Sean (SCR US) ha scritto:
Hi A
If i understand correctly, the issue which prevents gtk+ in trunk from
building with the directfb backend should be the fact that some months
ago the gdk backends were updated to use the new
gdk_window_impl_iface_init set of pointers to functions.
At least, this is what i understod by looking a
[CC'ing also debian-boot list, since the Debian installer is one of the
major GTK-DirectFB consumers and they may be interested in this thread.]
Denis Oliver Kropp ha scritto:
Attilio Fiandrotti wrote:
Hi
The minimum DirectFB requirement to build gtk+ with the DirectFB
backend is curr
1.2.0 ?
kind regards
Attilio Fiandrotti
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Sundeep Prakash wrote:
> Hi,
>
>I have cross compiled GTK+2.10.12 and DirectFB 1.0.0 for MIPS
> BCM7401 with all the dependancy as below:
...
>
> Initially, execution failed at
>
> ret=directfb->GetInputDevice(directfb, DIDID_KEYBOARD, &keyboard) ;
>
> in gtk+-2.10.14/gdk/directfb/gdkdi
Manfred Gruber wrote:
> hi !
>
> i am very interested in these patches which speed up gtk+ with directfb.
> thanks Denis Oliver Kropp.
>
> i have now cross builded gtk-trunk for an embeddeded system. here i have some
> changes which i found on building:
>
> IMHO there is a endif missing, or do
Denis Oliver Kropp wrote:
> Attilio Fiandrotti wrote:
>> I jsut completed testng the incremental application of the patches
>
> Thanks!
>
>> provided by dok in the order he indicated (NO_EXPERIMENTS was defined).
>>
>> * Patches which are ok and i
I jsut completed testng the incremental application of the patches
provided by dok in the order he indicated (NO_EXPERIMENTS was defined).
* Patches which are ok and i think can be committed right now are
window_flip_group.patch (this is the patch which requires NO_EXPERIMENTS)
no_background_pix
Attilio Fiandrotti wrote:
> Denis Oliver Kropp wrote:
>> Attilio Fiandrotti wrote:
>>> Yesterday i noticed the very same issue Reny spotted (even without the
>>> HACK files).
>>> So my idea is committing the single gdkevens patch now and wait some
>>>
Denis Oliver Kropp wrote:
> Attilio Fiandrotti wrote:
>> Yesterday i noticed the very same issue Reny spotted (even without the
>> HACK files).
>> So my idea is committing the single gdkevens patch now and wait some
>> more before applying the last set of patch
Yesterday i noticed the very same issue Reny spotted (even without the
HACK files).
So my idea is committing the single gdkevens patch now and wait some
more before applying the last set of patches proposed by dok, os that
those issues can be adressed properly.
Attilio
RENY PAUL wrote:
> Hi Sv
I can take care of committing all the gtk patches along with the
previous patch for gdk events which i already tested and seems to be ok.
One question about the code inside
#ifndef NO_EXPERIMENTS
...
#endif
shall it be committed and activated, committed but not activated or not
committed at all
graphical debian installer).
Otherwise, if many Gtk applications are meant to be run in a
desktop-like scenario, the best option is still Gtk/X11 + Xserver or
XDFB rather than Gtk/DFB + DFB due to fact that at GTK/DFB is not yet as
mature as GTK/X11 in terms of implemented functionalities.
rega
re still unimplemented/broken.
You should file a BR [1] against the directfb component and you may have
a look at the code in the DirectFB backend [2] and try to produce a
patch for the unimplemented/broken functionalities.
regards
Attilio Fiandrotti
[1]
http://bugzilla.gnome.org/buglist.
e the patch affects not only the DFB backend but some GDK common
files as well, so i didn't dare applying it as i'm not really expert in
GDK internals.
I'm now requesting feedback in order to know if the patch shall be
applied as it is, applied with modifications or discarded
Kyle Cho wrote:
> Hi,
>
> I wonder if the memory leak described below discussion has been fixed:
>
> http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00068.html
Yes, and another major leak has been spotted and fixed recently (patch
will be applied soon).
regards
Attilio
Matthias Clasen ha scritto:
> On 3/28/07, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote:
>>
>> i believe it would be nice if someone could sync directfb backend in
>> trunk with stable release: all that's in trunk can be safely backported
>> into 2.10 (als
via the linux_input module by adding
disable-module=keyboard
disable-module=ps2mouse
to your directfbrc file
please also checkout gtk+ trunk or branch gtk-2-10: official gtk+
releases up to 2.10.12 have a directfb backend not up to date, should
be fixed in upcoming 2.10.13.
regards
Attili
ensure next stable gtk+ release (2.10.13) builds out
of box with dfb backend enabled?
One more thing: i often need to disturb mike or loic to get patches
cheched in, may i get write access to gnome's svn repo to manage the
directfb backend?
regards
Attilio Fiand
Christian Schaubschlaeger ha scritto:
> Hello!
>
> I observe the following problem on gtk+ running on directfb. It seems to
> be directfb related, since it does not occur with the x11 backend.
>
> My system:
>
> gentoo linux
> kernel 2.6.20.7
> glibc-2.5
> gcc-4.1.1
>
> directfb-1.0
> gtk+-2.10
Kalle Vahlman ha scritto:
> 2007/3/28, Attilio Fiandrotti <[EMAIL PROTECTED]>:
>> BTW, the directfb gnome bug page is also messy: a lot of bugs duplicates
>> exist, many closed bugs are still indicated as open etc..
>> i can take care of that as i take care of bugs rel
Emmanuele Bassi ha scritto:
> On Wed, 2007-03-28 at 16:24 +0200, Attilio Fiandrotti wrote:
>> Murray Cumming ha scritto:
>>> On Wed, 2007-03-28 at 12:38 +0200, Attilio Fiandrotti wrote:
>>>> Once again, i strongly suggest people interested in gtkdfb to checkout
&g
Murray Cumming ha scritto:
> On Wed, 2007-03-28 at 12:38 +0200, Attilio Fiandrotti wrote:
>> Once again, i strongly suggest people interested in gtkdfb to checkout
>> from svn, where sources are often updated with fixes not propagated in
>> regular releases.
>
> Ho
Michael Natterer ha scritto:
> On Wed, 2007-03-28 at 14:09 +0530, Prasanna Kumar K wrote:
>> Hi All,
>>
>> I want to know which was the first and oldest version of GTK that was
>> running over DirectFB without any bugs.
>
> Hi,
>
> there is no such thing as GTK+ or DirectFB without any bugs,
>
If you're talking about plain disk occupation, here is disk occupation
for gtkdfb
[EMAIL PROTECTED]:~/gtkdfb1.0/lib$ ll *.so.*.*.* | awk '{print $5"\t"$8}'
430132 libcairo.so.2.10.3
69356 libdirect-1.0.so.0.0.0
399684 libdirectfb-1.0.so.0.0.0
62680 libfusion-1.0.so.0.0.0
449972 libgdk-dire
Luis Ariel Lecca wrote:
> Hello all:
>
> I get the gtk+dfb library from debian Sarge 3.1r2:
> #apt-get install libgtk+2.0-directfb-udeb-dev
>
> I build a complex (with sockets/files/and many widgets) gtk+dfb application
> linked with dynamic libraries, using anjuta too, with no problem.
>
Hi
I've prepared a patch that takes care of fixing some bugs related to the
generation of crossing events and to cursor's shape
1) the dfb backend currently receives twice in a row a DEWT_ENTER: i
asked directfb-dev if this is something normal dfb operating (i doubt
it) or more likely a bug
Attilio Fiandrotti wrote:
> Hi
>
> i recently noticed the directfb backend delivers, in some cases,
> different gdk events from the x11 backend.
I did some tests with a single toplevel gdkwindow and this is what i got
when moving the cursor in and out of the window: the direc
Hi
i recently noticed the directfb backend delivers, in some cases,
different gdk events from the x11 backend.
The attached app exploits the issue by packing a widget inside a gtkwindow.
With gdk/x11 the toplevel gdkwindow is sent these events when the cursor
moves from the toplevel gdkwindow
Prasanna Kumar K wrote:
> /*Hi .. I have modified scribble-simple.c from gtk/examples to check the
> behaviour of foregrond/background color of this application over X and then
> over DFB. in expose_event() I have set the new foreground color, it is
> working fine over X but over DirectFB it doe
Loïc Minier wrote:
> On Mon, Dec 18, 2006, Attilio Fiandrotti wrote:
>
>>so, i guess this patch only tackles the issue but does not properly.
>
>
> Attilio, did you notice the following block near the end of
> _gdk_windowing_window_destroy which your patch tou
Kalle Vahlman wrote:
> 2006/12/18, Attilio Fiandrotti <[EMAIL PROTECTED]>:
>
>> Attilio Fiandrotti wrote:
>> > Hi
>> >
>> > I recently noticed the the size of a generic gtk/dfb application
>> > considerably grows over time while the sam
Attilio Fiandrotti wrote:
Hi
I recently noticed the the size of a generic gtk/dfb application
considerably grows over time while the same application, but compiled
for gtk/x11, does not.
The attached example aplication permanently sets up a window and an
external box and at every proram&#
Karunakaran A wrote:
> Hello,
> We are getting some depth related assertions at time of running mozilla
> over gtkDFB port.
> The assertion is coming for the following functions:
> --
> pixmap = gdk_pixmap_new(NULL,x,y, gdk_rgb_get_visual());
> gdk_drawable_set_colormap(pi
Hi
I recently noticed the the size of a generic gtk/dfb application
considerably grows over time while the same application, but compiled
for gtk/x11, does not.
The attached example aplication permanently sets up a window and an
external box and at every proram's iteration a textview is crea
; pixmap = gdk_bitmap_create_from_data(NULL, bits, 1, 1);
> cursor = gdk_cursor_new_from_pixmap(pixmap, pixmap, &color, &color, 0, 0);
>
> gtk_widget_show(widget);
>
> gdk_window_set_cursor(widget->window, cursor);
>
> gtk_main ();
>
>
> Pedro Aguilar
>
>
>&
I can make the cursor to disapper by simply adding "no-cursor" to the
directfbrc [1] file, is there a chance this may not work in some cases?
If this should not work, you could try moving the mouse to the
bottm-right corner of the screen.
cheers
Attilio
[1] http://www.directfb.org/docs/directf
GTKDFB is used by the debian-installer team for our graohical installer,
so we'll keep on supporting it.
ATM HEAD from CVS compiles fine, and debian archives in experimental
contain binaries of GTKDFB 2.10.6 (compiled against DFB 0.9.25).
cheers
Attilio
Luis Ariel Lecca wrote:
>
> Hello Raj
Sven Neumann wrote:
> Hi,
>
> On Tue, 2006-09-26 at 09:40 +0200, Attilio Fiandrotti wrote:
>
>
>>Indeed, i made daily "cvs update" and rebuilt GTK from scratch for the
>>whole past week, before 2.10.4 was released, but it seems this wasn't
>>en
Matthias Clasen wrote:
> On 9/25/06, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote:
>
>> And the DFB backend was indeed found to be broken by the gtk-gnome
>> Debian team when they tried to build a DFB flavour of GTK for use in the
>> debian-installer.
>> Is
And the DFB backend was indeed found to be broken by the gtk-gnome
Debian team when they tried to build a DFB flavour of GTK for use in the
debian-installer.
Is there a way to check if the DirctFB backend builds correctly before a
major GTK relase, like (i guess) is done for X and win32 backends
Hi
I would like to know if there is any idea about release date for GTK+
2.10.4.
Right now the DirectFB backend in CVS compiles, but 2.10.3 included a
broken DirectFB backend.
Knowing the release date for 2.10.4 would allow spotting and fixing bugs
in time bfore release, so that Debian gtk-gnom
Maybe
GdkWindow *
gdk_directfb_window_find_focus (void)
located in gdkwindow-directfb.c is what you're looking for?
cheers
Attilio
gxk wrote:
> I have GTK based DirectFB on FC5.
> Can't find in code, which function returns focused window?
> The good example is gdk_directfb_window_find_focus(),
Sven Neumann wrote:
> Hi,
>
> On Thu, 2006-08-31 at 11:35 +0200, Attilio Fiandrotti wrote:
>
>
>>With the DFB backend i recently experienced the need to force reload of
>>keymap and i did it by calling directly a DFB function from my GTK app code.
>>Mike Emme
Sven Neumann wrote:
> Hi,
>
> On Thu, 2006-08-31 at 11:35 +0200, Attilio Fiandrotti wrote:
>
>
>>With the DFB backend i recently experienced the need to force reload of
>>keymap and i did it by calling directly a DFB function from my GTK app code.
>>Mike Emme
Hi
With the DFB backend i recently experienced the need to force reload of
keymap and i did it by calling directly a DFB function from my GTK app code.
Mike Emmel suggested to add something like gdk_directfb_reload_keymap()
to the GDKDFB backend, as this seems to be a generic problem.
Any sugges
Hi
With the DFB backend i recently experienced the need to force reload of
keymap and i did it by calling directly a DFB function from my GTK app code.
Mike Emmel suggested to add something like gdk_directfb_reload_keymap()
to the GDKDFB backend, as this seems to be a generic problem.
Any suggesti
Emmanuele Bassi wrote:
> On Fri, 2006-08-11 at 13:01 +0530, Prasanna Kumar K wrote:
>
>>Hi All,
>>
>>I'm not getting the top level window when trying to run some
>>GTK-applications over GTK-DirectFB..
>>I'm getting the internal contents of the GTK-application, like
>>buttons, bars etc... but not t
Attilio Fiandrotti wrote:
>
> Attilio Fiandrotti wrote:
>
>>Carl Worth wrote:
>>
>>
>>>On Thu, 27 Jul 2006 01:06:43 +0200, Attilio Fiandrotti wrote:
>>>
>>>
>>>
>>>>I think cairodfb or gdkdfb must previously have cor
Attilio Fiandrotti wrote:
> Carl Worth wrote:
>
>>On Thu, 27 Jul 2006 01:06:43 +0200, Attilio Fiandrotti wrote:
>>
>>
>>>I think cairodfb or gdkdfb must previously have corrupted memory
>>>somewhere, but i can't detect when nor where: can anyone
Carl Worth wrote:
> On Thu, 27 Jul 2006 01:06:43 +0200, Attilio Fiandrotti wrote:
>
>>I think cairodfb or gdkdfb must previously have corrupted memory
>>somewhere, but i can't detect when nor where: can anyone reproduce this
>>or give me an hint about how to cat
Hi
While running gtk applications with the dfb backend i often (but not
always) run into a crash that is not reproducible at all with X and
hence i think it should be related to cairo-dfb or gdk-dfb.
I'm usually able to reproduce it by running the gtk-demo app, opening
the hypertext application
Jeremy Laine wrote:
> When trying to compile gtk+ 2.10.1 with the DirectFB backend, I ran
> into the following compilation error:
>
> gdkwindow-directfb.c: In function `_gdk_directfb_move_resize_child':
> gdkwindow-directfb.c:1303: error: structure has no member named `GetPosition'
>
> The prob
Matthias Clasen wrote:
> This has been discussed a bit at Guadec; and I have started looking into
> what it would take to allow compiling GTK+ with certain subsets of
> widgets.
>
> My current patch defines a small number of optional subsets:
>
> * broken: widgets covered by GTK_ENABLE_BROKEN
>
karuna karan wrote:
>>Step 1: Look up the *correct* mailing list
>
>
> This might not be *the* correct list: but definitely appeared (at the time
> of
> posting) to be a good candidate for further information.
I always considered this mailing list, togheter with directfb-dev, to be
the mo
karuna karan wrote:
> Hello All,
>
> step1: I successfully built GTK+2.9.1 with DirectFB-0.9.25.1 on FC3.
> step2 :I am trying to build firefox1.5.0.3 with GTK+2.9.1 which was
> built in step1.
i tried to do that some times ago and i ended up considering two
possible candidates to do web brow
in the source files Mike has mentioned in the mail to
> the directFB list.
>
> These indicates to me that this is not really an issue with some path
> variable as you suggested. Your inputs are awaited.
>
> Regards,
> Suman.
>
> -Original Message-
> From: A
1]: Leaving directory `/root/new/gtk+-2.9.4'
> make: *** [all] Error 2
>
> so kindly give feedback on this issue..
>
> Thanks,
> Karunakaran A.
>
>
>
>
>> From: Suman Kar <[EMAIL PROTECTED]>
>> Reply-To: Suman Kar <[EMAIL PROTECTED]>
>&
karuna karan wrote:
> Hi all,
>
> I tried to build gtk 2.9.1 with directFB backend with following
> dependencies,
DFB support in was broken: you should try 2.9.4 or follow instructions
in the wiki page to build from sratch.
If you're a debian user, you can also use precompiled i386 official
pa
I also made tests with glib 2.11.1, but i got a different error message [1]
Attilio
[1] http://bugzilla.gnome.org/show_bug.cgi?id=342093
Zhenghui Zhou wrote:
You should upgrade glib at first I think.
2006/5/17, Matthias Clasen <[EMAIL PROTECTED]>:
On 5/16/06, Attilio Fiandrotti &
Hi
I noticed the DFB backend in HEAD won't compile unless something like
gboolean
gdk_screen_is_composited (GdkScreen *screen)
{
g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL);
return FALSE;
}
is added to gdkscreen-directfb.c .
Also, while trying to compile the GTK+ 2.9.0 tarball with
Hi
this patch makes the DFB backend compile again, could someone please
commit? (Mike? :)
thanks
Attilio
Index: gdk/directfb/gdkdisplay-directfb.c
===
RCS file: /cvs/gnome/gtk+/gdk/directfb/gdkdisplay-directfb.c,v
retrieving rev
Mike Emmel wrote:
On 1/4/06, Matthias Clasen <[EMAIL PROTECTED]> wrote:
- Is it good enough to run large applications with it, e.g. the Gimp ?
No it does most of gtktest and gtkdemo.
I've not even tried Gimp.
I've just built the GIMP 2.2.10 against GTKDFB 2.8.3 with the following
configure
ments.
What do you think? is anybody interested in getting involved in
developing GDKDFB? And is there any chance GDKDFB is ever going to be
merged into GTK mainline?
ciao
Attilio Fiandrotti
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
hi everyone
we're trying to port the debian-installer gtk frontend from X to Direct
Frame Buffer: in the debian-installer gtk frontend code sequences of
instructions like this are often used
button = gtk_button_new_with_label("Hello world!");
frame = gtk_frame_new("blah blah");
gtk_container
65 matches
Mail list logo
