Why is Wayland aping the APPLE interface? LINUX as an APPLE clone?

imagtek

New Member
Joined
Oct 2, 2018
Messages
21
Reaction score
6
Credits
209
Contemporary graphics libraries (Xlib, OpenGL) support application control of the cursor position on the screen.
Under the APPLE interface, this capability is disabled.
This capability is also disabled under the LINUX / Wayland replacement for Xlib. I know because it broke my application.
So what is next for LINUX? Discontinuing support for anything other than a single-button Mouse?
The ability of an application to position the cursor opens up an entire landscape of deeply interactive GUI possibilities. APPLE, with its obsession with control, has disabled this.
LINUX can be more than APPLE. The capacity is there.
But if all LINUX developers want is to look and feel like the APPLE platform, then why not just go develop there?

We do not need the APPLE graphics interface, and its obsession with stovepipe user interfaces, in LINUX.
 


Wayland isn't written by Apple. It's GNU opensource.


No Apple OS is currently using it.
But Xlib, Xorg is going away, it's slow, inefficient and lacks some functionality. It's over 30 years old.
Some distro's already use wayland as the default graphics lib.
 
The issue is not whether Xlib should be replaced to address updated Display technology and network protocols. Of course Xlib needs to be replaced, and Wayland is the replacement.

The issue is whether core Xlib functionality should be discarded in the process. It makes no sense to remove functionality that is of continuing relevance when its removal cancels an entire domain of possible GUI design and user interactivity. This is what is being done, and I do not see the need for it beyond the desire to 'look and feel' like another platform with a totally different user philosophy than LINUX. Apple stovepipes solutions into channels. Yes that gives Apple reliability and rigid control over the user experience, but it is not the only path to reliability.

Application control of the cursor across open windows in a networked environment is probably a step too far, but to be able to move the cursor under application control within the bounds of the window of current focus does not seem an insurmountable effort, since it has been in place for 30 years. And some of us use this capability and have designed around it. The argument that this capability is 'unneeded' is hugely presumptive and forces development into yet another conceptual stovepipe.

For some of us, LINUX is about total developmental freedom in an open conceptual space, not about moving everything into conceptual stovepipes. Discarding core capabilities requires deeper thought than I am seeing.
 
Did you get in touch with the developers to see whether they intend to port that functionality in their roadmap? That's what oss / free software is also about --contribution. Not just code, but ideas and suggestions too.
 
As a matter of fact I did contact the Wayland developers over this issue at gitlab.
After I made the problem understood, someone parsed the wording of my concerns and determined that I was not being sufficiently sensitive to the feelings of the developers.
I told them to fuck off with their thought policing.
They subsequently deleted all record of my concerns regarding Wayland graphics support.
This level of infantile nonsense is what passes for LINUX development now.
 
I told them to fuck off with their thought policing.
I see.

I'm curious about the functionality you were demanding. What user flow would involve the application moving the cursor around? What cursor was it, the mouse's?
 
Ask Wayland developers at gitlab.
They were provided with an exhaustive use case and active implementation.
Then they deleted it because someone sensed a deviation from Orwellian speech codes.
So this is Linux interface design.
Insane.
 
You are in a hi-res screen field of image data from a buffer that may be gigapixels.
There is no GUI. Just data and an ancillary window displaying statistics, histograms, in realtime with the moving cursor, if enabled. There is zero distractions. Every pixel on the screen is data.
You click and hold R mouse.
A tabular pop-up menu appears out of nowhere with its origin at the cursor position.
Since the software is user extensible with an internal gui builder, you slide the cursor down the menu to 'Extensions' among the other options.
A user extension menu then overlays the core menu, and the cursor position snaps to the origin of the Extensions menu.
All menus are logical trees. As you move through a menu with R mouse depressed, new menus pop up at the cursor position in a menu.
If you release R mouse at the end of a logical tree, the selected function executes. If you release R mouse anywhere else the menu simply disappears.
Any active function may create its own menu using the same gui builder and scheme. It becomes a 3-Dimensional logical network of functionality.
So you have hundreds of functions accessible with a single mouse click and moving the cursor through a logical tree, that may select other logical trees to overlay itself to arbitrary depth.
Absence of capability to warp the pointer makes all this impossible, and you are stuck with a stovepipe interface.
Stovepipes are so 20th century.
 
Last edited:
In another implemented use case of XWarpPointer(), your Display hosts a reduced resolution view of a giga-pixel (or larger) image buffer and this view is used to navigate within the buffer. Your display footprint in this image buffer at full resolution may be smaller than the footprint of the cursor pointer on your display. Getting lost in huge, un-navigated image datasets is a serious issue.
While navigating in this buffer, you have full access to diverse functionality by pressing R mouse, that displays a drop-down tabular menu that is a logical tree. You traverse this menu to actuate functionality. Unfortunately, at the point of menu selection your cursor has migrated from its original position in the buffer navigation view. Upon menu release, this new cursor position may be many display footprints away from the point that the menu was activated. Upon menu release, you suddenly find yourself viewing an unfamiliar area in the data. It is therefore necessary to snap the cursor position back to its original point at which the menu was activated to prevent discontinuity in exploitation process flow.
Again, this functionality has been broken by presumptive and ill informed decisions regarding what is 'correct' user interface design.
Massive image datasets where a single image may contain the information content of a 2 hour Hollywood movie is the future of image processing. That future is in jeapordy by the discard of Xlib functionality that has nothing to do with interface design, but rather assertive personalities and personal agendas.
 
Some people (myself included) like to be able to control where their pointer is located. If my pointer goes jumping all over the screen, I'm going to get lost really quickly.

If you're so gung ho on this idea of warping pointers, why not fork Wayland, implement a warp pointer function, and submit a pull request?

Edit: This issue seems to indicate a warping functionality.
 
Thank you for the useful link. All I know is that my application is still broken by Wayland.
I think forking Wayland is a very bad idea. Forking standards-based libraries can only lead to non-portability, dilution and confusion.
Application development (100k+ SLOC and counting) keeps me pretty busy. It is hard to wear two hats.
Robust standards should provide open-ended functionality within reasonable bounds dictated by hardware / networks without forcing development into conceptual stovepipes.
Some development (my own) is primarily experimental and exploratory.
It is not for anyone to dictate what shall be deemed 'useful' or 'needed' in the future. That is like removing words from the dictionary. The system needs to be as conceptually / developmentally open as can be reasonably and stably implemented and maintained.
LINUX is special and distinct from corporate systems; or there is no reason for LINUX to exist.
Aping corporate design philosophy that seeks to establish a corporate look-and-feel at the cost of constraining what is possible, is counterproductive.
That is just my opinion and I respect other opinions that are different.
 
Last edited:
Note I suggested a pull request. This would simply add your code to the official Wayland. Then you could safely delete your fork.
 
Have you considered managing the screen with a gaming engine, instead with the libraries of a desktop metaphor implementation like the desktop managers are? I'm not joking, I think that a gaming engine will give the access you need to implement that in a feature-proof way.

I don't want to play the devil's advocate here, and I understand your use case. It's just that, at the same time, I think that allowing a library to take over the position of my mouse could even be undesired or potentially dangerous for most of the desktop applications, in the sense that a mouse is intended to always follow the users' orders in the traditional desktop metaphors.
 
It's just that, at the same time, I think that allowing a library to take over the position of my mouse could even be undesired or potentially dangerous for most of the desktop applications, in the sense that a mouse is intended to always follow the users' orders in the traditional desktop metaphors.
I agree. With a little effort, somebody could create a program that attempts to move the mouse to a "Buy pro version" button or something similar. Not what anybody wants.
 
It appears that the consensus is to dumb down LINUX by removing capabilities that have been in place for decades so that the full potential of modern computers is no longer accessible to desktop development. I never imagined I would see this level of craven intellectual retreat in the LINUX community.

The ability to move the cursor within the current window of focus does not fit a hijacking use case unless the hijacking application takes control of your window of focus, or the entire Display. In that case the position of the cursor is the least of your worries.

I suppose there is a work-around, but at this point LINUX has ceased to be what it started out as, and is just another dumbed down Apple/Microsoft wannabe.

Continuing development on LINUX is pointless if SJWs dictate the conceptual space you can work in. Might as well port to to a corporate desktop platform with 1000X the user base with the same development capabilities.

I've been developing on LINUX since the early 1990's and watched a relentless increase in capabilities. To see core O/S development reverse course into comfortable banality that removes an entire universe of potential is very sad. I guess that is what you call Progress these days.
 

Members online


Latest posts

Top