Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Emmanuele Bassi]

Hi;

On 16 October 2015 at 18:15, cee1  wrote:

> The idea here is trying to make a thinner event loop.

You keep using that word, "thin". I don't think it means what you
think it means.

You have consistently failed to bring any measurement, or any metric,
that would allow you (or anybody else) to identify what's the current
state of GLib, and how would we identify a "thinner" version of GLib.

Saying that you want a "lightweight" version of GLib is pointless, if
you also don't define a system of measurement that defines what
"lightweight" even means.

> E.g. g_socket_client_connect_async calls g_task_new, which uses
> idle_source - routes to a main context and fires.

That's a pretty wrong understanding of how GTask actually works.

> The idea is from the evas - "evas is not dependent or aware of main
> loops".

Let's leave Evas out of this discussion.

> I'm wondering is it a thinner and cleaner implementation, that
> GTK+/GIO/etc provide hooks and let client or utility/glue library use
> these hooks to put GTK+/GIO/etc into their event loop.

The idea is to have a fd-based interface that lets you extract a
(pollable) descriptor from GMainContext, and additional main loops can
poll on that; see the (lengthy) discussion on:
https://bugzilla.gnome.org/show_bug.cgi?id=699132

Ciao,
 Emmanuele.

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

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-16 23:46 GMT+08:00 Florian Müllner :
> On Fri, Oct 16, 2015 at 5:38 PM, cee1  wrote:
>> If yes, we may let GObject inherit from
>> GstMiniObject to obtain the COW feature?
>
> This would break ABI, so not something you should expect any time soon.

So what about GObject2(a bit likes playbin2 in GStreamer)? Code can
change to inherit from it and recompiling...



-- 
Regards,

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

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Emmanuele Bassi]

Hi;

On 16 October 2015 at 18:20, cee1  wrote:
> 2015-10-16 23:46 GMT+08:00 Florian Müllner :
>> On Fri, Oct 16, 2015 at 5:38 PM, cee1  wrote:
>>> If yes, we may let GObject inherit from
>>> GstMiniObject to obtain the COW feature?
>>
>> This would break ABI, so not something you should expect any time soon.
>
> So what about GObject2(a bit likes playbin2 in GStreamer)? Code can
> change to inherit from it and recompiling...

What would be the point, if everything that currently depends on
GObject still has to depend on GObject?

That's the reason why we don't break GLib's ABI: not because we don't
want, but because then *everything* that depends on GLib would need to
break API/ABI. If you introduce a new type, you won't get any benefit
unless you also port everything to it — which nullifies the benefit of
introducing a new type without breaking ABI in the first place.

Ciao,
 Emmanuele.

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

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-15 23:00 GMT+08:00 Nicolas Dufresne :
> Le jeudi 15 octobre 2015 à 22:14 +0800, cee1 a écrit :
>> >> providing APIs to make GTK+(also GIO) easily integrated to other
>> >> event
>> >> loop, then we use epoll() on Linux, kqueue() onBSD or even
>> >> libdispatch[3] - client code can use simpler event loop(e.g. no
>> >> locks,
>> >> no recursive main loop support)
>> >
>> > This is all fully supported.
>> For GStreamer, yes. But not for GIO or GTK+? I guess.
>
> It's all provided by GLib. You should document yourself better. I've
> combined glib main loop into other loops many times, I know it's fully
> supported and has been for years. GStreamer is special case, as you
> don't need a main loop, though application is easier to write with one.

The idea here is trying to make a thinner event loop.

E.g. g_socket_client_connect_async calls g_task_new, which uses
idle_source - routes to a main context and fires.

Then "integrating gmainloop into other loops", does it need:
1)  Run g_main_context_iterate()? if yes, still extra locks, nested
loop(If they aren't needed in the specific scenario), still no epoll
or kqueue, etc.
2)  Retrieve fds from GSources(if attached fds), and add to external
epoll/kqueue, run prepare/check/dispatch in a proper position? This
seems a bit hard

The idea is from the evas - "evas is not dependent or aware of main
loops". I'm wondering is it a thinner and cleaner implementation, that
GTK+/GIO/etc provide hooks and let client or utility/glue library use
these hooks to put GTK+/GIO/etc into their event loop.



-- 
Regards,

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

Support for CUPS printer instances

[Michael Weghorn]

Hello,

currently, GTK+ does not support CUPS printer instances which are a way
to save different sets of options for a certain printer. More
information about CUPS printer instances can be found in the CUPS
documentation [1] in the section "Creating Saved Options".

I have worked on an implementation for them and have attached patches to
bug 148184 [2].

I would be very grateful if somebody could have a look at them.

Best regards,
Michael

[1] http://www.cups.org/documentation.php/options.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=148184
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Missing #include from glib/gwin32.c ?

[John Emmas]

I just updated glib (from git) and tried to build the glib-2-44 branch, 
using MSVC8.  I'm getting a compiler error at line 568 which looks like 
this:-


  typedef NTSTATUS fRtlGetVersion (PRTL_OSVERSIONINFOEXW);

Basically, my compiler doesn't recognise NTSTATUS.  If I substitute LONG 
instead of NTSTATUS, everything builds okay, so I'm assuming there's a 
missing #include.  I tried #including  and when that didn't 
work, I tried #include  (but that didn't work either).


Can anyone advise me what needs to get #included in order for NTSTATUS 
to get recognised?  Thanks.


John
P.S. I assume the same problem might also exist in 'master' although I 
haven't had a chance to try that yet.

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

回覆: Missing #include from glib/gwin32.c ?

[Fan, Chun-wei]

Hi John,

I think winternl.h is a good bet as well.  It is used elsewhere as well in the 
code.

With blessings.  Sorry for the noise from the earlier email.
---
Hi Victor,

Can you see whether winternl.h works for you?
---
With blessings, thank you.
 

- 原始郵件 -
寄件者: "John Emmas" 
寄件日期: ‎2015/‎10/‎16 22:59
副本: "gtk-devel-list" 
主旨: Re: Missing #include from glib/gwin32.c ?

On 16/10/2015 15:21, Victor Aurélio Santos wrote:
>
> Apparently at ntdef.h, try that I didn't tested.
>

Hi Victor and thanks for the quick reply.

I think ntdef.h might be MinGW specific (I can't find it in MSVC) but 
after a bit of experimenting I found 4 other header files which fix the 
problem (if I #include any of them).  The 2 most promising are probably:-

 #include   -  or
 #include 

and these two also work:-

 #include   -  or
 #include 

Conversely of course, it's possible that some of those might be MSVC 
specific and not applicable to MinGW!  Maybe Chun-wei Fan will be able 
to help us if he's around later.  Thanks again.

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

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-15 23:02 GMT+08:00 Christian Hergert :
> On 10/15/2015 07:19 AM, cee1 wrote:
>>> From GStreamer point of view, the main problem as it was explained to
>>> > me, is the global locks, creating contention (GStreamer is highly multi
>>> > -threaded). It's also a base type reserved for very specific use cases
>>> > (where a lot of that type need to be allocated, GstBuffer, GstEvent,
>>> > etc.). I'm not sure it make much sense generically. Specially that you
>>> > loose most of the feature of an object, properties, interface, signal,
>>> > etc.
>>
>> Such mini objects may also play a role in GTK+, I guess...
>
> Almost certainly not. Gtk uses properties and signals heavily, and is
> dominated by single threaded operations. Basically the complete opposite
> of why GstMiniObject was created.

GstMiniObject is discussed because the COW feature (aka.
gst_mini_object_make_writable). So the question is will GTK+ benefit
from the COW feature? If yes, we may let GObject inherit from
GstMiniObject to obtain the COW feature?



-- 
Regards,

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

Re: Missing #include from glib/gwin32.c ?

[John Emmas]

On 16/10/2015 15:21, Victor Aurélio Santos wrote:


Apparently at ntdef.h, try that I didn't tested.



Hi Victor and thanks for the quick reply.

I think ntdef.h might be MinGW specific (I can't find it in MSVC) but 
after a bit of experimenting I found 4 other header files which fix the 
problem (if I #include any of them).  The 2 most promising are probably:-


#include   -  or
#include 

and these two also work:-

#include   -  or
#include 

Conversely of course, it's possible that some of those might be MSVC 
specific and not applicable to MinGW!  Maybe Chun-wei Fan will be able 
to help us if he's around later.  Thanks again.


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

回覆: Missing #include from glib/gwin32.c ?

[Fan, Chun-wei]

Hi John,

Can I know what is the Windows SDK you are using?  Most probably the SDK you 
are using is too old.  If upgrading the SDK is not an option, you will have to 
define NTSTATUS as LONG (or let me know).

With blessings.

- 原始郵件 -
寄件者: "John Emmas" 
寄件日期: ‎2015/‎10/‎16 21:23
收件者: "gtk-devel-list" 
主旨: Missing #include from glib/gwin32.c ?

I just updated glib (from git) and tried to build the glib-2-44 branch, 
using MSVC8.  I'm getting a compiler error at line 568 which looks like 
this:-

   typedef NTSTATUS fRtlGetVersion (PRTL_OSVERSIONINFOEXW);

Basically, my compiler doesn't recognise NTSTATUS.  If I substitute LONG 
instead of NTSTATUS, everything builds okay, so I'm assuming there's a 
missing #include.  I tried #including  and when that didn't 
work, I tried #include  (but that didn't work either).

Can anyone advise me what needs to get #included in order for NTSTATUS 
to get recognised?  Thanks.

John
P.S. I assume the same problem might also exist in 'master' although I 
haven't had a chance to try that yet.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Missing #include from glib/gwin32.c ?

[Victor Aurélio Santos]

Apparently at ntdef.h, try that I didn't tested.
On Oct 16, 2015 10:23 AM, "John Emmas"  wrote:

> I just updated glib (from git) and tried to build the glib-2-44 branch,
> using MSVC8.  I'm getting a compiler error at line 568 which looks like
> this:-
>
>   typedef NTSTATUS fRtlGetVersion (PRTL_OSVERSIONINFOEXW);
>
> Basically, my compiler doesn't recognise NTSTATUS.  If I substitute LONG
> instead of NTSTATUS, everything builds okay, so I'm assuming there's a
> missing #include.  I tried #including  and when that didn't
> work, I tried #include  (but that didn't work either).
>
> Can anyone advise me what needs to get #included in order for NTSTATUS to
> get recognised?  Thanks.
>
> John
> P.S. I assume the same problem might also exist in 'master' although I
> haven't had a chance to try that yet.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Florian Müllner]

On Fri, Oct 16, 2015 at 5:38 PM, cee1  wrote:
> If yes, we may let GObject inherit from
> GstMiniObject to obtain the COW feature?

This would break ABI, so not something you should expect any time soon.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list