Results 1 to 10 of 11

Thread: GNOME2-Forked MATE Desktop Is Being Ported To Wayland

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,138

    Default GNOME2-Forked MATE Desktop Is Being Ported To Wayland

    Phoronix: GNOME2-Forked MATE Desktop Is Being Ported To Wayland

    MATE Desktop, the well known fork of the GNOME 2 desktop environment, is in the process of being ported to Wayland...

    http://www.phoronix.com/vr.php?view=MTYwNjQ

  2. #2
    Join Date
    Dec 2012
    Posts
    200

    Default

    Does it mean that GTK2 is also being ported to wayland?

    I wonder how they will solve in Wayland the lack of am out of process nesting system equivalent to XEmbed, that a lot of older applications use.
    Last edited by newwen; 02-17-2014 at 04:03 AM.

  3. #3
    Join Date
    Dec 2012
    Posts
    158

    Default

    Quote Originally Posted by newwen View Post
    Does it mean that GTK2 is also being ported to wayland?

    I wonder how they will solve in Wayland the lack of am out of process nesting system equivalent to XEmbed, that a lot of older applications use.
    It looks like MATE supports (or will support) GTK3:
    http://wiki.mate-desktop.org/status:gtk3

    As for XEmbed, that's the goal of the mailing post. The developer has proposed a solution, and is asking feedback about it to others devs.

  4. #4
    Join Date
    Mar 2013
    Posts
    170

    Default

    He should use the nested mini compositor approach, as suggested by Pekka:

    the conclusion was [referring to a previous discussion] to use a nested mini-compositor approach
    instead, which is demoed in weston clients as weston-nested.per weston


    We will see what will be the final solution.

  5. #5
    Join Date
    Jan 2013
    Posts
    1,028

    Default

    Quote Originally Posted by valeriodean View Post
    He should use the nested mini compositor approach, as suggested by Pekka:

    the conclusion was [referring to a previous discussion] to use a nested mini-compositor approach
    instead, which is demoed in weston clients as weston-nested.per weston


    We will see what will be the final solution.
    How does this differes from nested XWindows approach of Xorg where everything is nested window?
    Wasn't the simple planar surface per application one of the reason for Wayland development in the first place?

  6. #6
    Join Date
    May 2012
    Posts
    550

    Default

    Quote Originally Posted by brosis View Post
    How does this differes from nested XWindows approach of Xorg where everything is nested window?
    Wasn't the simple planar surface per application one of the reason for Wayland development in the first place?
    for once i have the same opinion as brosis

  7. #7
    Join Date
    Mar 2013
    Posts
    170

    Default

    Quote Originally Posted by brosis View Post
    How does this differes from nested XWindows approach of Xorg where everything is nested window?
    Wasn't the simple planar surface per application one of the reason for Wayland development in the first place?
    That is just one proposed approach.
    About the second question: no, there are many reasons.
    If you read the problem exposed in the mailing list, you will recognize why that case is not a "simple planar surface per application" problem.

  8. #8
    Join Date
    Dec 2012
    Posts
    200

    Default

    Quote Originally Posted by valeriodean View Post
    He should use the nested mini compositor approach, as suggested by Pekka:

    the conclusion was [referring to a previous discussion] to use a nested mini-compositor approach
    instead, which is demoed in weston clients as weston-nested.per weston


    We will see what will be the final solution.
    Reading through the list, I've seen the "wl_foreign_surface_manager" interface, but that protocol is missing an standarized IPC to communicate resizing requests for those exported/foreign subsurfaces, which is IMHO, essential.

  9. #9
    Join Date
    Dec 2012
    Posts
    200

    Default

    Quote Originally Posted by newwen View Post
    Reading through the list, I've seen the "wl_foreign_surface_manager" interface, but that protocol is missing an standarized IPC to communicate resizing requests for those exported/foreign subsurfaces, which is IMHO, essential.
    Well, I don't even know how wayland works as its current definition and explanation seems quite scattered around the web. I don't even know how resizing and resize requests work of regular wl_surfaces or wl_subsurfaces and how are they handled.
    Last edited by newwen; 02-17-2014 at 05:43 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •