Page 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 61

Thread: Qt 5.1 To Feature Improved Support For Wayland

  1. #51
    Join Date
    Dec 2010
    Posts
    1,177

    Default

    Quote Originally Posted by smitty3268 View Post
    Idiot.
    Likewise!

    Quote Originally Posted by smitty3268 View Post
    Wayland doesn't provide ANY ability to minimize apps yet. It's still being added.
    Doesn't change the fact that in the XDC 2012 video Kristian announced absolutely no plans to provide minimize support for hanging applications, only to kill them.

    Quote Originally Posted by smitty3268 View Post
    The point is nothing will stop it from being able to allow frozen apps from being minimized. Once the functionality to do that for running apps is present, adding it for hung apps is TRIVIAL.
    Such is adding a hypothetical libdeco or whatever but the reality is that NONE of the technologies that would remedy usability regressions to X exist at all.
    You Wayland fanboys just make that stuff up and tell everyone that everything is going to be alright without providing any proof at all.

    If everything is so trivial, why is that all not done yet? Instead Wayland supports to rotate windows almost since day one and – if you bother to watch the XDC video – the argument Kristian gives as to way CSD will be used is that when using the incredibly useless window rotation feature, a single line of pixels can be antialiased.
    Whoever the Intel manager is who orders Kristian to implement features a certain way, has absolutely no touch with typical PC use.

  2. #52
    Join Date
    Oct 2010
    Posts
    458

    Default

    I guess if I came in here and said "foo thought of bar input system which made baz work better than X11 or Wayland with CSD and async communication" you'd say "Oh, it doesn't exist yet and must be non-trivial so it'll never work," huh?

    If we gave up on everything because it's "non-trivial" or "doesn't exist yet" then we would never have come up with arrows, let alone bows and swords. :/

    edit: fyi, window rotate is a relatively trivial operation; it has been done many times in various other applications before wayland. Adopting it here would be fairly simple.
    Last edited by Nobu; 02-03-2013 at 10:43 PM.

  3. #53
    Join Date
    May 2010
    Posts
    173

    Default

    Quote Originally Posted by Awesomeness View Post
    Likewise!


    Doesn't change the fact that in the XDC 2012 video Kristian announced absolutely no plans to provide minimize support for hanging applications, only to kill them.
    You must have misunderstood Kristian or something, or I might be missing something.
    With the patches that add the minimize support, I can move and minimize a frozen app, but I have to initialize it from the panel. I tested it. It works. It's even on my live cd, so you can test it if you don't believe me

  4. #54
    Join Date
    Dec 2010
    Posts
    1,177

    Default

    Quote Originally Posted by nerdopolis View Post
    You must have misunderstood Kristian or something, or I might be missing something.
    With the patches that add the minimize support, I can move and minimize a frozen app, but I have to initialize it from the panel. I tested it. It works. It's even on my live cd, so you can test it if you don't believe me
    I was referring to usage of the titlebar buttons and Kristian only mentioned plans to specify rectangle coordinates on the titlebar for the close button and provide kill support for hanging apps.

    Aside from this, no implementation for getting consistent titlebar designs is available anywhere. All Wayland proponents can do is to claim that it will exist some day.
    You guys better produce facts before claiming otherwise. If you all are so elite Wayland experts, go and write libdeco and prove me wrong.

  5. #55
    Join Date
    Oct 2010
    Posts
    458

    Default

    Code:
    Objects:
    
    Theme	{
    	Name: Str,
    	Desc: Str,
    	i18n: File,
    	Theme_Details,
    	}
    
    Theme_Details
    	{
    	Borders:{
    		Radius: (optional) int,
    		Top: color|gradient|texture,
    		Right: (...),
    		Bottom: (...),
    		Left: (...)
    		},
    
    	Buttons:{
    		(same as Borders)
    		},
    
    	Menus:	{
    		(same as Borders)
    		},
    
    	Ticks:	{
    		(same as Borders),
    		Mark: character|texture|img
    		},
    
    	Radios:	{
    		(same as Borders),
    		Mark: character|texture|img
    		},
    
    	Input_Field:
    		{
    		(same as Borders)
    		},
    
    	Scroll_Bars:
    		{
    		(same as Borders)
    		},
    
    	Title_Bar:
    		{
    		Side: top|right|bottom|left,
    		Inside_Edge: color|gradient|texture
    		},
    
    	Colors:	{
    		Borders:	rgb|hsl|hexcolor,
    		Buttons:	(...),
    		Menus:		(...),
    		Ticks:		(...),
    		Radios:		(...),
    		Input_Field:	{bg:(...),fg:(...)},
    		Title_Bar:	{bg:(...),fb:(...)}
    		}
    	}
    Now all we need is an actual header file which defines these objects, and a library which reads a configuration file (structured similarly to this pseudo-code) and hands this information over to the toolkit. Text in parenthesis are comments, "(...)" means same as above.

    Any takers.

  6. #56
    Join Date
    Jun 2009
    Posts
    1,163

    Default

    Quote Originally Posted by Awesomeness View Post
    I was referring to usage of the titlebar buttons and Kristian only mentioned plans to specify rectangle coordinates on the titlebar for the close button and provide kill support for hanging apps.

    Aside from this, no implementation for getting consistent titlebar designs is available anywhere. All Wayland proponents can do is to claim that it will exist some day.
    You guys better produce facts before claiming otherwise. If you all are so elite Wayland experts, go and write libdeco and prove me wrong.
    wayland is not Weston, lets start here
    weston is not wayland, in case you had doubts

    Weston is a toy reference implementation, so developers can check how to interact with wayland within their own code(kwin/compiz/etc) and as other function weston works as an wayland test plataform/QA but both projects are 100% unrelated like Qt is not dependant of kwin, kwin just uses Qt.

    As i mentioned before wayland is a protocol not a server, meaning all is created client side and rendered FB side with 0 middle mans, so how to detect hang apps or minimize or render bugs bunny snapping a windows with an Acme hammer is done/decided and rendered from the wayland client(Qt/GTK/etc) in the way the respective project find it better(and not necesarilly in the way that weston do it).

    another thing is that wayland don't control what the wayland clients can do beyond handling the GPU framebuffer back and forth, again is not a server. Meaning that most likely kwin/compiz and the likes will just adapt their existing hang app detection routines to render in a wayland texture instead of an X11 object and properly inform the compositor.

    Weston require this patches just for the sake of having a minimalistic C reference compositor that can do in wayland something close enough to his big brother do using way more complete codebases(Qt/gtk/etc), if you bother in read kwin code or metacity code you won't find the hang detection code to be terrificaly tied to X11 at all(beyond the fact there is a bazillion ways to detect a hung up app without even need to bother the GPU and complicate things).

    so in resume:
    1. wayland dont control the apps
    2. wayland dont poll the apps
    3. wayland dont manage windows at user level, only at fb object level
    4. wayland dont handle decorations/buttons/widgets/pixmaps/porn/youtube/openoffice
    5. wayland is not a compositor
    6. wayland only provides low level protocol to manage efficient render in the GPU, everything else is client side
    7. wayland dont decide what an app will/can/can't/wont/ever will/etc do, its just render and process input/render events
    8. in wayland the compositor is not forced to render nor the renderer is forced to composite. aka Qt and GTK apps can render the decorations for their apps and kwin/compiz/shell just composite the scene without interfere in the render process
    9. for wayland everything is literaly a texture and input events and that open many doors previously closed in X11

    i agree with you in the fact that toolkit need to sit and agree in a serie of standard that allow them to exploit all this features but that is outside the scope control of wayland developers cuz is a 100% client side problem and so are all the questions made in this thread ... 100% client side issues and entirely outside wayland scope.

    if you are literate in C code read the wayland code and you will see what i mean and if you bother in read weston code you will inmediately realize is just a reimplementation of the oprations that any well established window manager do but a lot simplier and in plain C, thing is just fine cuz is nothing more than an example well documented. After all for an window manager developer is faster see a working example of the basics for wayland API than just read API docs

  7. #57
    Join Date
    Dec 2010
    Posts
    1,177

    Default

    Quote Originally Posted by jrch2k8 View Post
    i agree with you in the fact that toolkit need to sit and agree in a serie of standard that allow them to exploit all this features but that is outside the scope control of wayland developers cuz is a 100% client side problem and so are all the questions made in this thread ... 100% client side issues and entirely outside wayland scope.
    Don't act as if Wayland was an isolated island. Wayland is an Intel project and just as Intel ported Clutter, EFL, GTK, and Qt (= the clients) to Wayland, it's therefore also Intel’s responsibility to take care about fixing usability problems resulting from Wayland.
    Maybe Intel do not perceive those as problems because – as I already wrote – in their eyes Wayland is probably only meant for use on smartphones, tablets, and smart TVs/IVI where titlebars are simply nonexistent.

  8. #58
    Join Date
    Jun 2009
    Posts
    1,163

    Default

    Quote Originally Posted by Awesomeness View Post
    Don't act as if Wayland was an isolated island. Wayland is an Intel project and just as Intel ported Clutter, EFL, GTK, and Qt (= the clients) to Wayland, it's therefore also Intel’s responsibility to take care about fixing usability problems resulting from Wayland.
    Maybe Intel do not perceive those as problems because – as I already wrote – in their eyes Wayland is probably only meant for use on smartphones, tablets, and smart TVs/IVI where titlebars are simply nonexistent.
    well to start im pretty sure qt on wayland is part of lighthouse project from quite some time and made it to qt5 recently, as is true that some intels devs helped with the initial wayland port of qt they are hardly the majority(digia/kde/ex-nokia are), care to link?

    wayland is an isolated island, its not my fault you cant understand C code (or you are having fun trolling the thread or both) and again WESTON IS NOT FREAKING WAYLAND IS JUST A FREAKING EXAMPLE/REFERENCE COMPOSITOR, what part of your brain dont freaking understand wayland is a library and it doesnt care about your freaking titlebar because that is FREAKING CLIENT SIDE ISSUE and when the times comes KDE/E17/GNOME/Unity/etc will implement the FREAKING TITLEBAR THE FREAKING WAY IN HELL THEY FRICKING WANT, understand? or i need to make a youtube video with muppets and big big letters for you to be able to get it?

  9. #59
    Join Date
    Dec 2010
    Posts
    1,177

    Default

    I did not count how many of the commits are by Intel but Intel is definitively involved in porting all said toolkits to Wayland.

  10. #60
    Join Date
    Jun 2009
    Posts
    1,163

    Default

    Quote Originally Posted by Awesomeness View Post
    I did not count how many of the commits are by Intel but Intel is definitively involved in porting all said toolkits to Wayland.
    still i don't see your point, assuming ofc you have one to start with

    your twisted logic:
    intel contributes to mesa/kms/gallium/kernel/other mainstream projects? so on your logic intel should fix sabayon/fedora/ubuntu/etc because intel ppl push code to those important projects
    intel contribute/colaborate with nouveau and r600g drivers, so with your logic is intel's fault that r600g is slower than fglrx and nouveau have issues supporting wayland
    intel contribute A LOT in X11 too you know[hello!! keith packard works at intel ya know]? so intel is the culprit of all the X11 evilness ofc

    Reality:
    Wayland/weston is was started/is currently developed by X.org/mesa developers like christian and keith(that for mere casuality work for intel !!OMG) + many community devs completely unrelated to intel.So if you put 3 neurons togheter and understand that fact you will see you tend to see intel ppl in many other projects specially when involved with wayland/X11 is because those intel devs are dedicated to both projects and know lots of the internals from first hand[including many many communuty devs that you don't name because ....?] which is a great asset for developers outside X11/wayland scope to have close to them in case they need help[the same applies to KMS/DRM/Gallium/cairo/libVA/Mesa/etc dependant projects] BUT NOR WAYLAND/X11/KMS/DRM/CAIRO/PIXMAN/MESA/GALLIUM/LIBVA/FFMPEG/ETC ARE INTEL PRODUCTS OR OFFICIAL INTEL PROJECTS NOR QT/GTK/EFL/AND COMPANY ARE PRODUCTS FROM INTEL OR DERIVATED COMPANIES.

    so in resume many intel OSC developers along with many community rock stars like marek or luc or tom among many good others choose to contribute and/or improve derivated projects that are linked to their main work projects to help move thing a bit faster[or simply because they want, you know!! maybe keith/paul/brian/etc love Qt/efl/gtk and contribute to it after work hours]

Posting Permissions

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