scroll bar

[Rúben Rodrigues]

Hi guys,

Someone could help with scroll bar, zoom gesture and pan gesture ?

I add this zoom callback, and i need to change the scroll bar. But i 
don't understand the paramentes of gtk_adjustment_configure().

static void
zoom_scale_changed (GtkGestureZoom *gesture,
 gdouble scale,
 GtkWidget  *widget)
{

 double lower = gtk_adjustment_get_lower(hadjustment);
 double upper = gtk_adjustment_get_upper(hadjustment);

double dif = ((upper - lower)*scale - (upper -lower) ) / 2.0 ;

if(dif > 0){
 linechart_set_xaxis_minmax(chart, dif , PAGE_SIZE - dif);
   gtk_adjustment_configure(hadjustment, dif, lower, PAGE_SIZE - 
dif, 1.0, 1.0, PAGE_SIZE);
 }else{
 linechart_set_xaxis_minmax(chart, 0.0 , PAGE_SIZE);
 gtk_adjustment_configure(hadjustment, 0.0, 0.0, PAGE_SIZE, 1.0, 
1.0, PAGE_SIZE);
 }
 gtk_widget_queue_draw (widget);
}

static void pan_pos_changed (GtkGesturePan  *gesture,
 GtkPanDirection direction,
 gdouble offset,
 GtkWidget  *widget){
 double value = gtk_adjustment_get_value(hadjustment);
 double lower = gtk_adjustment_get_lower(hadjustment);
 double upper = gtk_adjustment_get_upper(hadjustment);

 switch (direction){
 case GTK_PAN_DIRECTION_LEFT:
 linechart_set_xaxis_minmax(chart, lower - offset , upper - 
offset);
 break;
 case GTK_PAN_DIRECTION_RIGHT:
 linechart_set_xaxis_minmax(chart, lower + offset , upper + 
offset);
 break;
 }

 gtk_widget_queue_draw (widget);
}

To configure callback and gesture i use this:

 /* Zoom */
 gesture = gtk_gesture_zoom_new (canvas);
 g_signal_connect (gesture, "scale-changed",
 G_CALLBACK (zoom_scale_changed), canvas);
 gtk_event_controller_set_propagation_phase (GTK_EVENT_CONTROLLER 
(gesture),
GTK_PHASE_BUBBLE);
 g_object_weak_ref (G_OBJECT (canvas), (GWeakNotify) g_object_unref, 
gesture);

 /* Pan */
 gesture = gtk_gesture_pan_new(canvas,GTK_ORIENTATION_HORIZONTAL);
 g_signal_connect (gesture, "pan",
 G_CALLBACK (pan_pos_changed), canvas);
 gtk_event_controller_set_propagation_phase (GTK_EVENT_CONTROLLER 
(gesture),
GTK_PHASE_BUBBLE);
 g_object_weak_ref (G_OBJECT (canvas), (GWeakNotify) g_object_unref, 
gesture);

hadjustment = gtk_adjustment_new(0, 0, 0, 0, 0, 0);

g_signal_connect(G_OBJECT(hadjustment), "value-changed", 
(GCallback)value_changed, NULL);

hscrollbar = gtk_scrollbar_new(GTK_ORIENTATION_HORIZONTAL, hadjustment);

gtk_adjustment_configure(hadjustment, 0.0, 0.0, PAGE_SIZE, 1.0, 1.0, 
PAGE_SIZE);

The pan gesture don't works, never go to callback function.

Thanks



---
Este e-mail foi verificado em termos de vírus pelo software antivírus Avast.
https://www.avast.com/antivirus

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Strict aliasing, yes or no?

[Chris Vine]

On Wed, 19 Apr 2017 22:12:24 +0100
Chris Vine  wrote:
> On Wed, 19 Apr 2017 12:21:06 +0100
> That (GArray to GRealArray) does break the strict aliasing rules,
> unless done through a union (OK with unions in C99 with Technical
> Corrigendum 3 and in C11, implementation defined only in C89, but
> fine with gcc and clang).

Perhaps I should add that is also valid C89/99/11 if you cast pointer
values with memcpy(), which will be optimized out with any decent
compiler (such as gcc and clang).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Chris Vine]

On Wed, 19 Apr 2017 12:21:06 +0100
Simon McVittie  wrote:
> On Tue, 18 Apr 2017 at 23:05:04 +0100, Daniel Boles wrote:
> > Well, technically, code that relies on aliasing is
> > inherently buggy from the outset, because that violates the
> > standard.  
> 
> Not relying on aliasing forbids casting between dissimilar types,
> which rules out "normal" C tricks like casting between GArray and
> GRealArray (where GRealArray starts with the same members as GArray)
> as a way to have a partially-opaque struct, or an
> opaque-other-than-size struct on the stack; so regardless of whether
> it might be desirable to be writing Standard C, I'm not sure that
> GLib can do that without breaking its API.

That (GArray to GRealArray) does break the strict aliasing rules, unless
done through a union (OK with unions in C99 with Technical Corrigendum 3
and in C11, implementation defined only in C89, but fine with gcc and
clang).

I think most reasonable C programmers have roughly got to grips with
strict aliasing now.  Presumably this dates back to less illuminated
times.
 
> It is also not particularly clear from ISO/IEC 9899:201x draft N1570
> (which is essentially the same document as Standard C, but without the
> price tag) whether the usual C pseudo-object-orientation idiom[1]
> (which is a fairly fundamental part of GObject) is considered to be
> valid in Standard C.

That is and always has been perfectly valid C.  You can always cast a
pointer to one type to a pointer to the effective type of the pointee
and dereference it.  It so happens that the initial address of a struct
has two effective types in C, that of the struct itself and that of its
first member, which are required to have the same address.  You don't
even need to rely on the fifth bullet of §6.5/7 of C11 - it is covered
by the basic proposition in the first bullet.

Chris
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Morten Welinder]

You are making the situation sound a bit worse than it actually is.

> Not relying on aliasing forbids casting between dissimilar types, which
> rules out "normal" C tricks like casting between GArray and GRealArray
> (where GRealArray starts with the same members as GArray) as a way to have
> a partially-opaque struct, or an opaque-other-than-size struct on the stack;
> so regardless of whether it might be desirable to be writing Standard
> C, I'm not sure that GLib can do that without breaking its API.

C99 can do that, although access needs to be via a union type.
C99 section 6.5.2.2 #5.  No API break would be need to do it.


> whether the usual C pseudo-object-orientation idiom[1] (which
> is a fairly fundamental part of GObject) is considered to be valid in
> Standard C

That works fine.  C99 section 6.7.2.1 #12.

glib (etc) _is_ stomping on the standard in a hundred different ways.  Some
are for performance -- \0 filling, for example -- while others are pure laziness
and ignorance such as variables called "read" or macros name starting with "E".

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk-devel-list Digest, Vol 156, Issue 11

[Daniel Boles]

On 19 April 2017 at 13:00,  wrote:

>
> Message: 4
> Date: Wed, 19 Apr 2017 12:21:06 +0100
> From: Simon McVittie 
> To: gtk-devel-list@gnome.org
> Subject: Re: Strict aliasing, yes or no?
> Message-ID:
> <20170419112106.rfk2oxs5vfdn4...@archetype.pseudorandom.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, 18 Apr 2017 at 23:05:04 +0100, Daniel Boles wrote:
> > Well, technically, code that relies on aliasing is
> > inherently buggy from the outset, because that violates the standard.
>
> Not relying on aliasing forbids casting between dissimilar types, which
> rules out "normal" C tricks like casting between GArray and GRealArray
> (where GRealArray starts with the same members as GArray) as a way to have
> a partially-opaque struct, or an opaque-other-than-size struct on the
> stack;
> so regardless of whether it might be desirable to be writing Standard
> C, I'm not sure that GLib can do that without breaking its API.
>

Hmm, fair point, I wasn't aware of types like that yet.



> It is also not particularly clear from ISO/IEC 9899:201x draft N1570 (which
> is essentially the same document as Standard C, but without the
> price tag) whether the usual C pseudo-object-orientation idiom[1] (which
> is a fairly fundamental part of GObject) is considered to be valid in
> Standard C. In general, the aliasing rules are not well-understood,
> so it is pragmatic to disable aliasing-driven optimizations in code that
> is not CPU-bound.
>

I think this is well-defined: AFAICT, it is specifically allowed to cast
between pointers to SomeStruct and SomeOtherStruct whose first member is a
SomeStruct.

Put more simply: pointers to structs and pointers to their 1st member are
considered to be interchangeable for aliasing purposes - AFAIK.



> Most of GNOME is written in pragmatic C (whatever works in gcc and clang
> on CPUs that are used in the real world, sometimes with the additional
> constraint of also working on MSVC/Windows/x86), not in Standard C. For
> instance, standard C doesn't guarantee that 8, 16, 32 and 64-bit types
> exist (it only mandates the names like int32_t if such types already
> exist!), but GLib requires a type of each of those sizes. Standard C
> doesn't
> guarantee that a pointer with all bits zero is NULL, but GLib libraries
> (and probably GLib itself) commonly require that. There are plenty more
> examples, many of them things that a typical C programmer is likely to
> assume to be always true even though Standard C does not actually
> guarantee it.
>

Yeah, I figured there would be things like this. I just wasn't sure whether
strict aliasing was such a requirement, or whether we could get by without
out. I guess not :)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Simon McVittie]

On Tue, 18 Apr 2017 at 23:05:04 +0100, Daniel Boles wrote:
> Well, technically, code that relies on aliasing is
> inherently buggy from the outset, because that violates the standard.

Not relying on aliasing forbids casting between dissimilar types, which
rules out "normal" C tricks like casting between GArray and GRealArray
(where GRealArray starts with the same members as GArray) as a way to have
a partially-opaque struct, or an opaque-other-than-size struct on the stack;
so regardless of whether it might be desirable to be writing Standard
C, I'm not sure that GLib can do that without breaking its API.

It is also not particularly clear from ISO/IEC 9899:201x draft N1570 (which
is essentially the same document as Standard C, but without the
price tag) whether the usual C pseudo-object-orientation idiom[1] (which
is a fairly fundamental part of GObject) is considered to be valid in
Standard C. In general, the aliasing rules are not well-understood,
so it is pragmatic to disable aliasing-driven optimizations in code that
is not CPU-bound.

Most of GNOME is written in pragmatic C (whatever works in gcc and clang
on CPUs that are used in the real world, sometimes with the additional
constraint of also working on MSVC/Windows/x86), not in Standard C. For
instance, standard C doesn't guarantee that 8, 16, 32 and 64-bit types
exist (it only mandates the names like int32_t if such types already
exist!), but GLib requires a type of each of those sizes. Standard C doesn't
guarantee that a pointer with all bits zero is NULL, but GLib libraries
(and probably GLib itself) commonly require that. There are plenty more
examples, many of them things that a typical C programmer is likely to
assume to be always true even though Standard C does not actually
guarantee it.

S

[1] typedef struct { ... } GObject;
typedef struct { GObject parent; ... } MyObject;
typedef struct { MyObject parent; ... } MySubclassObject;
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Licensing

[John Emmas via gtk-devel-list]

Hi guys - whilst checking something else this morning I came across an 
anomaly in the licensing mechanism for glib / gtk+ etc.


The vast majority of the header files state that it's LGPL.  But 
occasionally there are GPL headers here and there.  For example in 
glib-2, the following 11 header files stipulate GPL:-


  gbase64.h
  gbookmarkfile.h
  gchecksum.h
  ghmac.h
  glib-private.h
  glib-unix.h
  gmain.h
  gmain-internal.h
  gmessages-private.h
  goption.h
  gpoll.h

Just thought I'd flag it up in case it's unintentional,

John

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list