Announcement

Collapse
No announcement yet.

Patches So Nouveau Users Can Try Out Wayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 89c51
    replied
    I guess the key point is that anything with an X in it would either need to have an alternative implemented or would have to run on top of X.
    keith packards opinion on the topic

    Leave a comment:


  • bridgman
    replied
    Wayland would not implement the XVideo API (since that is part of the X wire protocol) but you could accomplish the same thing via OpenGL rendering. It would also be pretty straightforward to implement some Xv-like functionality as an independent rendering library over Gallium3D, either as a standalone API library or by adding support for YCbCr surfaces to a generic 2D rendering library.

    I guess the key point is that anything with an X in it would either need to have an alternative implemented or would have to run on top of X. That said, many of the things which are implemented on top of X today are implemented that way because X was the one standard thing in a Linux/Unix graphics stack, not because there is some implicit dependency on something X-ey that only X can deliver.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by CrystalCowboy View Post
    And what if one of my key applications happens to rely on some of that functionality?

    What about XVideo for example? Will Wayland be able to display XVideo? If so, will I have to modify my code any to make it work?
    Then your app will run in an X emulation layer, pretty much like X apps run on Mac OS X.

    Leave a comment:


  • CrystalCowboy
    replied
    "Much of this extra functionality in x-server is not used any longer by modern toolkits like QT or GTK+, but has to be supplied for backwards compatibility."
    And what if one of my key applications happens to rely on some of that functionality?

    What about XVideo for example? Will Wayland be able to display XVideo? If so, will I have to modify my code any to make it work?

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by smitty3268 View Post
    Firefox does use GTK, just not everywhere. XUL is a homegrown toolkit that lies on top of GTK (in linux) and other toolkits for other operating systems. Like how OpenOffice uses GTK in linux but has their own widget system on top for cross-platform code.
    Both Firefox and OpenOffice use their own toolkits for everything, and only interface with GTK or Qt for painting the widgets, so they look native.

    It's a lot like using the Qt-GTK engine for making all GTK apps look like Qt apps and vice versa. The apps are coded using one toolkit, and the final painting is done by the other one.

    I don't think that Firefox depends on GTK in any way, it's just a drawing backend.

    Leave a comment:


  • highlandsun
    replied
    Originally posted by smitty3268 View Post
    The main thing is that Wayland just drops all backwards compatibility and requires modern driver/kernel features in order to minimize the amount of code required. The result is a lighter program that integrates better into current technologies.

    As far as being usable, I'd say it's not that far away for mobile devices running Meego, for example. But I doubt it will be seen anywhere on the desktop for quite a while. Dropping backwards compatibility there is a big deal, and not something that can just be done without lots of planning and a roadmap. Just for starters, they'd probably want to wait for NVidia and AMD to release binary drivers that would be compatible with it (Meego will likely only ship with Intel chips). The Qt/GTK toolkits need more time to finish getting ported/stabilized. Apps like Firefox that use some X-server API's directly need to be ported. Someone will need to figure out how remote desktop should work (embedding an x-server? VNC? A new protocol, possibly added into Wayland?) All of those things could take a while to fully finish, and most of them haven't really even started yet except for the toolkit porting.
    Designing a windowing system in this day and age that only has networking/remote desktop support added as an afterthought sounds rather pathetic. We're in an era of connected devices - handsets, tablets, desktops all should be able to interact, drag'n'drop, whatever. Jettisoning cruft is one thing, but jettisoning network-aware design is sheer ignorance.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by some-guy View Post
    No, firefox does not use gtk at all, it has its own toolkit XUL which fakes the look of gtk.
    Firefox does use GTK, just not everywhere. XUL is a homegrown toolkit that lies on top of GTK (in linux) and other toolkits for other operating systems. Like how OpenOffice uses GTK in linux but has their own widget system on top for cross-platform code.

    The system requirements page lists GTK 2.10+ as a requirement. http://www.mozilla.com/en-US/firefox...uirements.html

    I can't remember where all Firefox is directly touching X, but I think it was in the event handling code. Also plugin handling, maybe. And scrolling? I'm not really sure, it could be all over the place or very limited.

    Leave a comment:


  • some-guy
    replied
    Originally posted by smitty3268 View Post
    No. Certain parts deal directly with X. Although I don't think it's a whole lot, so maybe it wouldn't take that long to port.
    No, firefox does not use gtk at all, it has its own toolkit XUL which fakes the look of gtk.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by 89c51 View Post
    isn't firefox a "pure" gtk application ????
    No. Certain parts deal directly with X. Although I don't think it's a whole lot, so maybe it wouldn't take that long to port.

    Leave a comment:


  • 89c51
    replied
    isn't firefox a "pure" gtk application ????

    Leave a comment:

Working...
X