Re: touch on HTML5 supported by gtk+?
On tis, 2013-01-08 at 12:21 -0800, Andy Tai wrote: > Hi, with gtk+ 3, is touch input supported with the HTML 5 backend, > such as when running a gtk+ app on HTML 5 in the browser? Not currently, but it could be implemented. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: supporting all X (not only gtk+) applications in browser
On 01/09/13 00:21, Yuhao Zhu wrote: Hi All, I am not sure if this is the right place to post this. But I saw this post (https://mail.gnome.org/archives/gtk-devel-list/2010-November/msg00103.html) in this mailing list. It is about rendering gtk+ applications in firefox. I think it is a good idea to run desktop applications in web browsers, which basically acts as a container. The caveats of the Chrome OS is that users can't use real full version of all sorts of fancy software, but have to suffer the trimmed online version. Imagine we can really have a "Browser OS" where the browser is the only software, which could do conventional browsing, as well as (remotely) run desktop applications. That patch in gtk+ sorts of does this, but as per my understanding (please correct me if wrong), it transfers pure pictures/pixels, and only deals with gtk+ applications. However, why can't we just intercept the communication between X clients and servers, and render in the browser. All we have to do is to ask X server to render the client in the browser tab (probably in a canvas) instead of as a standalone application. In this way, we don't have to transfer pictures -- we are just re-routing the X rendering to the browser. Supporting Wayland is also possible, and probably better. Imagine that we can host all sorts of fancy desktop software in central servers in the cloud, and users just have to open the browser, get access to remote server, and they can use them! In this way, all data is stored on the cloud, rather than constantly synch-ing with the server! Yuhao ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list Yes, great idea but I'd advice you to google strongly first, since you can find this in GTK+3 documentation: "Using GTK+ with HTML5 The GDK Broadway backend provides support for displaying GTK+ applications using HTML5 and Web sockets. To run your application in this way, select the Broadway backend by setting GDK_BACKEND=broadway. Then you can make your application appear in a web browser by pointing it at http://127.0.0.1:8080. Note that you need to enable web sockets in your web browser." ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gobject-introspection] How to use caller-allocates and allow-none annotations in Clutter
Hi,
In <50ead835.5070...@collabora.co.uk>
"Re: [gobject-introspection] How to use caller-allocates and allow-none
annotations in Clutter" on Mon, 07 Jan 2013 14:14:13 +,
Simon McVittie wrote:
> [I am not a g-i developer, please do not take this as authoritative.]
Thanks for your reply.
I am still waiting for a g-i developer but your reply is
very helpful for me.
I may misunderstand (out caller-allocates).
My understanding about (out) (allow-none) will be right.
Thanks!
--
kou
> On 07/01/13 13:22, Kouhei Sutou wrote:
>> ClutterActorIter iter;
>> ClutterActor *child;
>>
>> clutter_actor_iter_init (&iter, container);
>> while (clutter_actor_iter_next (&iter, &child))
>> {
>> /* do something with child */
>> }
> [...]
>>
>> The "child" parameter is a return location and the return
>> location is allocated by caller. (The returned object isn't
>> allocated by caller.)
>>
>> What annotation should be used for the case? I thought
>> "out caller-allocates". Is it right usage for the
>> annotation? Or "out" is the right annotation?
>
> To me this looks like an ordinary (out), the same case as each of the
> two "outputs" of g_hash_table_iter_next(). (out caller-allocates) is
> rare: as I understand it, you'd use it in this situation:
>
> GValue value = { 0 };
>
> this_value_argument_is_out_caller_allocates (&value);
> ...
> g_value_unset (&value);
>
> and not many others.
>
>> The "child" parameter can be NULL. What annotation should be
>> used for the case? I thought "allow-none". Is it right usage
>> for the annotation? Can I use "allow-none" for an out
>> parameter?
>
> I believe (out) (allow-none) means "it is safe to pass NULL instead of
> &child, if you just want to look at the boolean return", rather than "if
> you pass &child, that might result in child == NULL afterwards".
>
>> match_start:
>> return location for start of match, or
>> NULL. [out caller-allocates][allow-none]
>
> I believe this means you call it like this:
>
> GtkTextIter start;
>
> if (gtk_text_iter_forward_search (..., &start, ...))
> {
> printf ("match starts at %d\n",
> gtk_text_iter_get_offset (&start));
> }
>
> or perhaps like this if you need to use the heap for start for whatever
> reason (I'm not sure about this usage, some details might be wrong):
>
> GtkTextIter *start = g_new0 (GtkTextIter);
>
> if (gtk_text_iter_forward_search (..., start, ...))
> {
> printf ("match starts at %d\n",
> gtk_text_iter_get_offset (start));
> }
>
> g_free (start);
>
>> Is clutter_actor_iter_next() case the same case as
>> gtk_text_iter_forward_search()?
>
> No, I think it's the same case as g_hash_table_iter_next().
>
> S
> ___
> 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: GtkWidget::visible
On 01/08/2013 04:04 PM, Benjamin Otte wrote: > Hey, > > Today, in my quest to make things clearer in the GTK core, I'm > tackling GtkWidget::visible Some comments/questions (mostly related to the a11y stuff) below. > - developer expect those widgets to not do anything > A11y people have lots of "fun" fixing bugs when Orca pokes into > widgets nobody expects to be pokable. Yes, some time ago [5] Orca developers suggested that if the widget is not "marked as visible by the toolkit" it shouldn't be exposed, as a user can't interact with it. In the same way the current VISIBLE/SHOWING states should be merged, and just maintain one state of VISIBLE==widget is visible to the user. After some discussion, thats was the final conclusion [6]. > (2) A11y code will ignore invisible widgets > We're working on a patch that will make sure no accessibles show up > for invisible widgets.[4] Makes sense. Having said so ... as I said, the consensus was maintain the state VISIBLE as a way to expose if the widget is visible from the pov of a user. For example, to know if an object is exposed to the user (as the user can interact with it), but scrolled off screen (so not visible). But during the discussion of that bug, we also agreed that in general, knowing if a widget is really on screen can be really costly [7]. So in a ideal situation we have this: * Precondition: compute if a widget is visible on screen is feasible * Target: accessibility implementation only expose objects relevant to the user. * gtk doesn't expose widgets with GtkWidget:visible=false, as they are irrelevant to the accessibility framewok * Under previous precondition, an accessibility state VISIBLE is still relevant, because as a user could try to interact with a widget scrolled off the screen, it is exposed, and in the same way it is not visible, so it would be good to differentiate one from the other. But as I said in general that precondition is not feasible. So that would lead that all the objects exposed will have the accessibility state VISIBLE, because there is no practical way to decide if it is in fact visible or not. Under that scenario, one could wonder if any accessibility VISIBLE state is relevant at all. My opinion is that it would be better to maintain it, hoping to find situations were the visibility status can be computed. Anyway, any feedback about this accessibility state is welcome, and I also hope to be wrong about not having any situation at all were the real visibility could be refined. BR PS(offtopic): someday I would need to a) deprecate that SHOWING state on atk, and b) do the same filtering on clutter. This filtering is part of a more global filtering of objects exposed by clutter that I had in mind since a long time ago. Right now clutter accessibility implementation tends to expose *everything* something that is a bad idea. Anyway, this situation became less critical thanks to the deprecation of classes like ClutterBehaviour etc, that were exposed in the past. > 1: http://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--visible > 2: http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-show > 3: > http://git.gnome.org/browse/gtk+/commit/?id=b495ce5446a0bbf2ed63b5880537779e4b123515 > 4: https://bugzilla.gnome.org/show_bug.cgi?id=577392 [5] https://bugzilla.gnome.org/show_bug.cgi?id=648260#c0 [6] https://bugzilla.gnome.org/show_bug.cgi?id=648260#c7 [7] https://bugzilla.gnome.org/show_bug.cgi?id=648260#c6 -- Alejandro Piñeiro Iglesias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: supporting all X (not only gtk+) applications in browser
I can't clearly tell what specifically you're asking, whether the "network" or the client-server interaction for fetching the data. Please be more specific, AND: reply to the list (gtk-devel-list@gnome.org) not to me :-D since this way only "I" get your email. Send to list so that everyone can see it and grasp what I could be missing. ;-) On 01/09/13 23:34, Yuhao Zhu wrote: Thanks! I saw the following comments on that implementation: Each toplevel window is mapped to a canvas element, and the content in the windows is updated by streaming commands over a multipart/x-mixed-replace XMLHttpRequest that uses gzip Content-Encoding to compress the data. Window data is pushed as region copies (for scrolling) and image diffs. Images are sent as data: uris of uncompressed png data. Input is gathered via dom events and sent to the server using websockets. Right now this is Firefox 4 only, but it could be made to work in any browser with websockets. I am confused since on one hand, it is "steaming commands" and on the other hand it is transferring images (png data). Why do we have to go through the network to transfer data? The only reason I can think of is that it assumes that the client machine that runs firefox doesn't have X/gtk+ installed? Yuhao On Wed, Jan 9, 2013 at 3:54 AM, aix64 mailto:hossein.ai...@gmail.com>> wrote: Yes, great idea but I'd advice you to google strongly first, since you can find this in GTK+3 documentation: "Using GTK+ with HTML5 The GDK Broadway backend provides support for displaying GTK+ applications using HTML5 and Web sockets. To run your application in this way, select the Broadway backend by setting GDK_BACKEND=broadway. Then you can make your application appear in a web browser by pointing it at http://127.0.0.1:8080. Note that you need to enable web sockets in your web browser." ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
