Originally posted by TheSoulz
View Post
Announcement
Collapse
No announcement yet.
Canonical Joined The Khronos Group To Help Mir/Wayland Drivers
Collapse
X
-
Originally posted by BlackStar View PostAs an app and a toolkit dev, you are wrong.
GTK, Qt and SDL only offer a subset of functionality. To do some things, you must reach out to X, Wayland and Mir directly, and that means you now have 3x code to write.
Canonical wants you to believe that the porting issue will magically disappear. They are lying.
and depends on the kind of apps, its not like sundently your app its gonna be 3 times bigger.
can you give me a hard example where you would talk to the display server (x,mir,wayland) direcly?
even if there are these are todays problems since we only have 1 display server we didnt have the tools now that we have 3 we could possibly do like call somekind of API and the API figures out what display server the user is using then use the correct path to that display server so devs would target one single API, am i wrong???
new things = new problems = new solutions
just beacuse today it may be an issue does not mean tools cant be created to solve them.
Originally posted by blackout23 View PostOhh yeah toolkits are going to save the day lol. Except for all the irrelevant apps that don't use any of the above mentioned toolkits like you know Firefox (XUL) or Chromium (Aura). Pretty sure the Steam client also uses it's own Toolkit as does the Unreal Engine 4 Editor.
they (googl3) even have new tools for mir/wayland right now, what was it called? ozone?
think it helps to hardware accelerate grapichs.
The resume its simple, people are freaking out over stupid things that can be solve (if they werent already) when there are other bigger issues that require more attention.Last edited by TheSoulz; 25 August 2014, 06:11 AM.
Comment
-
Originally posted by TheSoulz View Postcan you give me a hard example where you would talk to the display server (x,mir,wayland) direcly?This weekend I read a blog post by Robert Ancell from Canonical claiming that the display server doesn’t matter . To quote the direct message: The result of this is the display server doesn&#…
Originally posted by TheSoulz View Posteven if there are these are todays problems since we only have 1 display server we didnt have the tools now that we have 3 we could possibly do like call somekind of API and the API figures out what display server the user is using then use the correct path to that display server so devs would target one single API, am i wrong???
Originally posted by TheSoulz View Postjust beacuse today it may be an issue does not mean tools cant be created to solve them.
Comment
-
Originally posted by TheSoulz View PostSo you write your app once, and it should work everywhere if the toolkit is supported.
And even if you are using a toolkit, and even if the toolkit ostensibly supports all three, there are always subtle differences in how the display servers behave that can lead to unexpected bugs. Trying to port stuff to wayland has led to the discovery of a lot of bugs in toolkits that weren't detected before because Wayland makes use of code-paths had not been used before or not been used in the same way. Mir will have the same problem, and have it even worse if Canonical has to maintain Mir in downstream patches.
But, at least with Wayland these bugs will be likely to be detected earlier because the upstream developers will be targeting it. But, except for Canonical's own projects, most upstreams will not be targeting, or probably even testing significanly, on Mir. KDE, for example, uses continuous testing of all commits. They can't test Mir, however, because their testing environment does not run on Ubuntu, and no one else supports Mir.
Comment
-
Originally posted by TheBlackCat View Posthttp://blog.martin-graesslin.com/blo...r-does-matter/
Sure, but it still means developers need to code three solutions to their problem instead of two. It is adding additional work that wouldn't have been necessary.
There will never be tools to cover every use case. And writing the tools still requires three different code paths instead of two, so it doesn't change anything, it just pushs the same problem into a different part of the software stack.
also he said "If the toolkit would just abstract away all the display server differences our applications libraries would not have crashed"
like i said the previus post this could be created
"Sure, but it still means developers need to code three solutions to their problem instead of two. It is adding additional work that wouldn't have been necessary."
that would be ludacris, you would create a library inside the toolkit or something and all apps target it.
if all apps created it inside theyr own code would be unnessary bloat.
"There will never be tools to cover every use case. And writing the tools still requires three different code paths instead of two, so it doesn't change anything, it just pushs the same problem into a different part of the software stack."
there never is, but for moust commun cases it would work farly well i belive, sometimes when you create something more fancy you already know you will have more work.Last edited by TheSoulz; 25 August 2014, 08:35 AM.
Comment
-
Sorry i couldnt edit my previus post to add this since 5 minutes had passed ( stupid rule should be at least 15m to edit :P )
im gonna move on from this since i belive its unimportante, abstracting the display manager solve moust of the issues (or should) if not other solutions will be created i have no doubt.
meanwhile theres other bigger issues like different packages and make dev's life way more harder then this.
consider that
Comment
-
Originally posted by BlackStar View PostAs an app and a toolkit dev, you are wrong.
GTK, Qt and SDL only offer a subset of functionality. To do some things, you must reach out to X, Wayland and Mir directly, and that means you now have 3x code to write.
Canonical wants you to believe that the porting issue will magically disappear. They are lying.
there is no wayland drawing api like X had it. same as there is nothing like X properties since wayland basically sandboxes your surfaces and that is it. so, please name one example where you would need to do it
p.s. if it sounds like trolling, blame it on my poor english, i'm genuinely interested in your answer
Comment
-
Originally posted by blackout23 View PostOhh yeah toolkits are going to save the day lol. Except for all the irrelevant apps that don't use any of the above mentioned toolkits like you know Firefox (XUL) or Chromium (Aura). Pretty sure the Steam client also uses it's own Toolkit as does the Unreal Engine 4 Editor.
then again, this wayland/mir will probably be evolutionary irrelevant. same as evolution is forcing MS out of their lock-in shell and adapt to service for everyone business type. by the time first mir deployment in late 16 happens, there will be way too much wayland adoption already. ubuntu might have largest share in linux desktop, but it will be of same importance as MS who holds 95% of worlds desktops.
95% might sound big number, but when they put PC/phone/tablet devices together, their market share is simply too low to be able to just continue with old strategy. and that is why MS focused on service for everyone now, it is the only way to reach larger market and at the same time if they don't they might become less and less relevant
wayland already ships on phones, cars, soon on various distros (F21 should ship with wayland support, not default though). mir? only adopted by ubuntu phone and ubuntu and yet to reach first usable state that is not tech preview
next thing is support from GPUs, NVidia and AMD will probably provide support for both, while Intel already decided to pick one. also, based that all toolkits decided on definite wayland support and unsure about mir, that will hopefully bury canonical in downstream patches and they'll just create mir as wayland compositor
Comment
-
Originally posted by justmy2cents View Postp.s. if it sounds like trolling, blame it on my poor english, i'm genuinely interested in your answer
One of the divides between acadamia and practicing software developers is that acadamia always sees the theory and how well everything should work. Developers see what happens in real life, and it's never nearly as clean as everyone hopes.
The real issue I think is less the porting process for apps, but the testing process. It's going to be very difficult to properly test things (fully and constantly) on all 3 servers (X, Wayland, and Mir) and there are going to be times when Mir breaks assumptions that they would like to keep in the code for Wayland, and no one is really going to want to have to deal with that when there isn't a good reason for it. The only reason it's even a possibility is because fundamentally Wayland and Mir are so similar - if we were talking about another change as big as the one between X and Wayland is, there would be a full-scale revolt among developers.
*Compositors, like Kwin are a different animal than regular apps, and have much much more trouble, which is why i don't expect kwin to run on Mir anytime soon. The problem is much less severe for most other apps.Last edited by smitty3268; 28 August 2014, 01:15 AM.
Comment
-
Originally posted by TheSoulz View PostI've read that very fast and may have skiped stuff but some problems he presented are not truly valid, he created If wayland and then said what if then it dosent work on mir? create a if mir ...
also he said "If the toolkit would just abstract away all the display server differences our applications libraries would not have crashed"
like i said the previus post this could be created
Originally posted by TheSoulz View Post"Sure, but it still means developers need to code three solutions to their problem instead of two. It is adding additional work that wouldn't have been necessary."
that would be ludacris, you would create a library inside the toolkit or something and all apps target it.
if all apps created it inside theyr own code would be unnessary bloat.
Originally posted by TheSoulz View Post"There will never be tools to cover every use case. And writing the tools still requires three different code paths instead of two, so it doesn't change anything, it just pushs the same problem into a different part of the software stack."
there never is, but for moust commun cases it would work farly well i belive, sometimes when you create something more fancy you already know you will have more work.
Comment
Comment