How use gnome-calculator in my gtk+ app

[Rúben Rodrigues]

Hi guys,

I need to add to my app a calculator. It's possible to add 
gnome-calculator as child of a container in my app?

Thanks

Ruben


---
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: How use gnome-calculator in my gtk+ app

[Roth Robert]

Hi Ruben,

That depends on what do you mean by adding a calculator:
* do you only need a text-field to evaluate calculations from? (easier to
implement, spawn a process for the command-line version of calculator to
calculate the result, just like the calculator gnome shell search provider
does)
* do you need the full interface (including calculations history, buttons)
- this is harder to do, calculator is not designed to do this, as this
seems to me like a very rare usecase. Feel free to contact me for more
details on how and what.

I'm also interested in other people's ideas and suggestions (as a more
generic topic) on embedding an applications UI in another's one, e.g.
GtkSocket/GtkPlug and/or other solutions.

Regards,
Robert

On Wed, Mar 22, 2017 at 11:28 AM Rúben Rodrigues 
wrote:

> Hi guys,
>
> I need to add to my app a calculator. It's possible to add
> gnome-calculator as child of a container in my app?
>
> Thanks
>
> Ruben
>
>
> ---
> 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
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Is GtkAssistant a toplevel widget?

[songqing shan]

Hi,


I want anybody can help me as follows.


On the GTK3.0 manual, "gtk_widget_is_toplevel()" part says that "Currently only 
GtkWindow and 
GtkInvisible (and 
out-of-process 
GtkPlugs) 
are toplevel widgets." However, when I use GtkAssistant, the error occurred 
"Gtk-WARNING **: Can't set a parent on a toplevel widget." . Actually, 
GtkAssistant is a toplevel widget. Can I use GtkAssistant as a non toplevel 
widget? If yes, how to use it?


Thanks,


Song

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

Re-drawing GtkDrawingArea surface on motion-notify-event

[Marcin Kolny]

Hi everyone,
I'd like to write very simple application for drawing lines.
 1) User press button - app saves x and y coordinates
 2) User moves the mouse - app dynamically draws potential line on each
mouse move event
 3) User releases button - app "saves" the line on the canvas.

I've tried to modify slightly the GTK example drawing application [1].
 1) On button press event I paint the current state to the "base_surface"
surface.
 2) On each mouse move I paint to the "tmp_surface" surface "base_surface"
and after that the actual line, so I avoid multiple lines on mouse move.
 3) On mouse release event I paint "tmp_surface" surface to "base_surface".

This works, and full code can be found on my gist [2]. However, I don't
think it's the right approach, since I have to re-paint a whole image for
each mouse-move, and latter on, on "draw" event application is doing almost
the same, so I'm doing the re-paint twice per each mouse move. I'm afraid
that for huge surfaces it might be very inefficient.

Do you know what would be the right approach to solve this sort of problems?

Thank you for help,
Marcin

[1] https://developer.gnome.org/gtk3/stable/ch01s05.html
[2] https://gist.github.com/loganek/156b6b9ce2333fd7d389f74c093a92b4
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Best practise inheritance

[Emmanuele Bassi]

Now that I'm not on my phone, I can probably do a better job at
replying to this email.

On 21 March 2017 at 23:21, Emmanuele Bassi  wrote:
>
> On Tue, 21 Mar 2017 at 21:23, S. Jacobi  wrote:
>>
>> On Tue, 21 Mar 2017 20:53:04 +
>> Emmanuele Bassi  wrote:
>>
>> >
>> > Also, do not store a private pointer in your instance structure, and
>> > use the get_private_instance() function that the G_DEFINE_TYPE macro
>> > creates for you.
>> >
>> So you say whenever I need access to the objects private data I should
>> call G_TYPE_INSTANCE_GET_PRIVATE, despite the mentioned overhead?
>
>
> Nope. I said to use the get_instance_private() function generated for your
> type by the G_DEFINE_TYPE macro, which uses pointer arithmetic and an offset
> computed when the class is instantiated and it's constant for all instances.

Before GObject 2.38, the private data was allocated interleaved with
each instance data in the memory block; this meant that each GType has
to compute the offset for each ancestor type in the hierarchy. After
2.38, the private instance data is allocated as a single block, and
the offset for each ancestor class is constant and known once the type
is created (assuming you're using the G_DEFINE_TYPE macros and you're
not calling g_type_class_add_private() in an ancestor of your type;
for that case we still know the offset at class init time, which means
we always know the offset before you can instantiate a type). The
known offset allows us to retrieve a pointer to the private instance
data with simple, and fast, pointer arithmetic.

The G_DEFINE_TYPE_EXTENDED macro will create a
_get_instance_private() static inline function that returns
a pointer to the private instance data. If you use
G_DEFINE_TYPE_WITH_PRIVATE, or G_DEFINE_TYPE_WITH_CODE (...
G_ADD_PRIVATE), GObject will do all the heavy lifting behind the
scenes for you — and it will ensure that any changes we make to
GObject will end up in your code with a simple rebuild.

Since getting the private instance data was "expensive" in the
beginning, the best practice was to use a private pointer inside the
instance data structure, at the cost of a slightly larger instance
structure size and at the cost of having a real instance structure
instead of just renaming `struct _GObject` to your type; now that
retrieving that data is fast, having that pointer is not necessary any
more (doing a pointer offset is actually faster than a pointer
redirection, on any modern architecture).

tl;dr: Always use G_DEFINE_TYPE and G_DECLARE_* macros to
automatically use best practices, and to avoid having to deal with the
innards of GType.

>> > The GObject tutorial has a good introduction on how to define types
>> > and how to use them.
>> >
>> Indeed. It took me a while to walk through it. However, the example
>> given in [3] has the comment /* Other members, including private data.
>> */, which would contradict your opinion, or is at least a bit unclear,
>> because final and derivable types are handled a bit differently.

>> [3] https://developer.gnome.org/gobject/stable/howto-gobject-code.html

The example you're referring to is describing the "final type" case,
where the instance structure is already *private* to the source file.
This means you don't need a Private data structure at all — i.e. all
the instance data is private.

You should use private instance data structures if you're using
G_DECLARE_DERIVABLE_TYPE and you make your instance structure public,
in order to let other people subclass your type.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Is GtkAssistant a toplevel widget?

[Emmanuele Bassi]

As you can see here:

  
https://developer.gnome.org/gtk3/stable/GtkAssistant.html#GtkAssistant.object-hierarchy

GtkAssistant is-a GtkWindow, which means it's a top level widget.

The documentation of `gtk_widget_is_toplevel()` does not list all the
possible GtkWindow sub-types, because GTK+ may introduce new ones, and
we don't want to update the documentation needlessly.

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

Re: Re-drawing GtkDrawingArea surface on motion-notify-event

[Stefan Salewski]

On Sun, 2017-03-19 at 22:12 +, Marcin Kolny wrote:
> I'd like to write very simple application for drawing lines.

You can restrict all drawing operations to a rectangle enclosing your
line. For each move with button pressed, fill that rectangle with
background color and then draw the line with foreground color. Or, you
may save the old line start and end points and paint that old line with
background color before drawing the new line. I think there is not much
benefit for using an temporary surface for this use case.

For more complicated graphics it can become a bit slow indeed -- I once
tried it for my schematics editor -- there I used a bounding box for
all the graphical elements, when one element is moved, I had to draw
its background and then all other elements overlapping with that
background element. Using OpenGl may be faster and easier, because you
can fast just redraw all. I think GTK3 now has a gl-area widget. The
problem with Gl is that it is basically more for drawing triangles than
for drawing lines... 
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GDBus: Implementing multiple interfaces with a single object

[Colin Walters]

Hey,

Is there some example code out there that implements multiple
GDBus interfaces using a single GObject?   I have an existing
subclass of the $prefix_TYPE_$iface_SKELETON and I'd like it
to *also* implement a new interface.

This is for rpm-ostree, so I'll just make it concrete; I started by
doing this

```
G_DEFINE_TYPE_WITH_CODE (RpmostreedOS,
 rpmostreed_os,
 RPMOSTREE_TYPE_OS_SKELETON,
 G_IMPLEMENT_INTERFACE (RPMOSTREE_TYPE_OS,
rpmostreed_os_iface_init)
 G_IMPLEMENT_INTERFACE (RPMOSTREE_TYPE_OSEXPERIMENTAL,

rpmostreed_osexperimental_iface_init)
 );
```

But AFAICS, the _SKELETON objects can only implement one interface,
since that's what GDBusInterfaceSkeleton does, and this is a subclass?

It wouldn't be too bad in my case to simply make a new concrete
subclass, and share code via private helpers, but maybe I'm missing
some easy way to do this.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list