Originally posted by computerquip
View Post
Announcement
Collapse
No announcement yet.
KWin On Mir: A Solution To Non-Existent Problem
Collapse
X
-
-
Originally posted by artivision View PostI thing that Linux users are not whining. They just want the same things from the beginning of Linux time:
1) GPL and open standards. They don't want Mir nor Wayland, nor Flash nor Net(Mono), nor Catalyst nor Nvidia_blob. They want a GPL_LLVM(GCC5 or 6), HTML5, VP9, and others.
2) Compatibility with closed things. They don't prefer a new Kernel version but a new Wine version. They need the latest Lightspark. They prefer Unified_Graphics_Drivers that understand many Compilers(like GLSL and HLSL at the same time) and they don't need translations(glsl=disabled), plus free HLSL_compilers/state_trackers. They need Qemu to have 70+% translation efficiency, so they don't have to relay on closed Instruction_Sets. They need last generation Console_Emulators and Console destruction. And many more.
Comment
-
Originally posted by schmidtbag View PostIf Canonical keeps up with Mir and if it manages to become more successful than Wayland, it does get me to wonder what devs like Martin will do or say when they realize they might have to join.
Originally posted by schmidtbag View Postit's more complete than Wayland and it'll offer Android drivers
Originally posted by schmidtbag View PostI'm sure if it existed BEFORE wayland then it would get the same positive attention as wayland, minus the few people who hate canonical just because they want to hate canonical.
In fact, Canonical does everything to mimic Oracle's handling of OpenOffice that lead to LibreOffice.
Originally posted by a user View Postif canonical wants to start their own display server project then they have al right to do it and they do not own anybody to first ask for permission or get in contact with any other startup project with the same aim.
Originally posted by a user View Postwhy i haven't read any such statements when wayland started? sure even there were a lot of complaints like "why we need that? fragmentation bla bla". and now the same people seem to defend wayland >.>
On the contrary, Wayland at least has an inviting development process which Canonical projects have not.
Originally posted by Akka View PostI'm not completely sure but I think Collabora had wayland running on android with android driver a year ago or something. Its old articles on Phoronix about it. But I'm nut sure if that project is particularly active now?
Originally posted by Sonadow View PostCanonical announces move to Qt for Unity, expects that upstream will accept patchsets that provide Mir support for Qt
Originally posted by Sonadow View PostI have a nagging feeling Mir might emerge the victor if only because Nvidia already appears to be in the process of supporting Mir with their proprietary blob.
Originally posted by Sonadow View PostNot true, at least 4 different distributions attempted to adopt Unity, although some eventually abandoned it because of the crazy amount of out-of-tree patches that had to be made to the vanilla GTK3 stack in order to get it working.
Fedora initially considered porting Unity but (predictably) rejected it because it does not meet its upstream policy, Frugalware tried to support it but eventually abandoned their efforts on maintaining it. OpenSUSE also ported Unity initially and eventually gave up with maintaining the patches although it seems that a new maintainer is now working on doing so.
And of course, ArchLinux has everything, including Unity.
Comment
-
Originally posted by BO$$ View PostWhat a sad joke is Wayland. How can you defend it even when after all these years of development they don't have basic features? Canonical got tired of waiting for these losers and said fuck it we're doing it our way. That is all that is happening.
There were more important things to adjust before to spend time about a window list for the panel and a protocol for minimize/maximize control of shell_surfaces.
Canonical got tired of waiting for these losers and said fuck it we're doing it out way?
I laughed so much on that.
*Our way* means an eye candy demo of unity on XMir, and XMir is a simple copy/paste of Xwayland. LOL
Looks like that the so called *our way* is to copy the work done be the *other way* and rename it as the *our way*.
It's better if you wait until they start to walk on their legs before to acclaim something like *losers*, *our way* and others ridiculous statements like those.
Comment
-
For those of you disagreeing with my first post (on the first page) about me saying mir is more complete than wayland, thats because its based on android's display server which is fully functional. I guess where Im wrong is Mir is more incomplete than wayland in a linux x86 perspective. While I dont know the technical details of what Mir needs to be done, it seems to me that all it needs most is drivers and toolkits. All of the functionality of Mir should already be there, with the exception on resizable windows. If you all think im really that wrong then how do you explain that canonical got that X nested mir working like 2 days after announcing their plans?
Comment
-
Originally posted by schmidtbag View PostIf you all think im really that wrong then how do you explain that canonical got that X nested mir working like 2 days after announcing their plans?
We have integrated X, leveraging the prior XWayland work, to run on top of Mir (XMir)
Comment
-
Mir is opensource. Weston is opensource.
Mir want to be next gen X without its weaknesses of X. Wayland want to be next gen X without its weaknesses.
Mir fulfill moder needs. Wayland fulfill modern needs.
All is well. Stop wishing failure to FLOSS projects....
And it do not matter who is the dady but if dady can let as date with its daughter :P (eg. if canonical govern Mir well, than what is harm from its success?)
Yeah really, WHAT IS THE F****** DIFFERENCE if Wayland or Mir success?
NONE :P
Comment
-
Originally posted by TheBlackCat View PostSo instead of just implementing the additional features they needed in an existing code-base, they instead decided to re-implement all the existing features AND planning as well? Yeah, that is going to speed things up a lot...
or are you forced to adopt something that you plain dont like (be it architecture wise, be it coding style wise, be it programming language wise) just because it exists and everyone else is putting hopes on it like a sort of messiah (not believing in tit making you a sort of heretic) ?
where's your freedom as a developer?
that said,
Wayland is a protocol (and support library-ies, with bindings) on which third parties are expected to build compositors (with weston being only the referencial/ sample (sometimes even called "toy") implementation, intended for understanding how thirdp arties compositors should work but not really intended for DE consumption - not "as is") while Mir is (set out to be) an complete "product" (compositor)
wayland to Mir to wayland is in the order of LDAP in respect to active directory
second, wayland is about protocol for two reasons: one, because (and this was particularly clear at its inception by what hoegsberg said) by design in order to streamline the window manager it would push most functionality - not only decorations (that 's the tip of the iceberg) but also window move/resize - to clients (in a desktop envised as a stack of full screen surfaces each application would manage its own window in screen space - although i get that this has been changed to some extent later *)
and two, because wayland is designed to merge the compositor/WM and the display server so that window hierarchy data is not duplicated in different processes, but says nothing about the design of the rest of the GUI (namely the panel / taskbar /task switcher)
thus a protocol or the compositor to notify application events they have to handle, and from the UI to tell the compositor what it shall do with an application's windows ("minimize this app") becomes necessary - as become necessary to keep track of open applications in two different places
otoh, if from the very start you know (or want) the wm and the shell to be one thing, and window management to happen entirely in the wm (trasparently and orthogonally to applications as seems to be in Mir's design, there's little need for a protocol like the above
and, thought there's an already existing solution, that solution may not be what you need, if its focus is on that very protocol
no criticism intendend, just to point out that the respective philosophies and goals are different enough to justify going for a new solution - or is this so hard to grasp?
Comment
Comment