discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NeXT GNU Homage Project Work


From: Maxthon Chan
Subject: Re: NeXT GNU Homage Project Work
Date: Wed, 18 Nov 2015 16:46:54 +0800

Not just that, maybe we need a new TFB mechanism that is ARC- and Swift-proof, and maybe rewrite opal and quartzcore. The reason I suggest building QC on top of EGL and Wayland is because how technology layers from OS X maps here.

2) X11 is on its way out so I think we need to put our eyes on the future-proof things.

3 & 4) Metal, SpriteKit and SceneKit are for games, preferably distributed through Steam. If we have clones of OS X game frameworks then Steam (and maybe App Store) games for OS X will become one recompile away from being released under Linux. Game Center and other OS X-specific game features can be implemented by calling into Steam platform’s similar features.
 
On Nov 18, 2015, at 16:37, Luboš Doležel <lubos@dolezel.info> wrote:

On 11/17/2015 04:34 AM, Maxthon Chan wrote:
Sorry…

If this is the case then I would suggest those AppKit and UIKit
enhances, sort of bringing GNUstep up to speed with OS X:

1) Storyboards. This is how Xcode arrange user interfaces now. 2)
QuartzCore and WIndowServer based on Wayland and EGL. This will
replace Window Maker with a higher performance interface engine, and
replace gnustep-back entirely. (“windowmaker-wayland” is a
Wayland-only compositor that have the OS X look and feel,
“gnustep-qe” implements QuartzCore API using Wayland and EGL, and
gnustep-gui rewritten to use gnustep-qe instead of gnustep-back) 3)
Metal, which can be mapped to Vulcan(“gnustep-metal-vulcan”), Mantle
(for AMD cards, “gnustep-metal-mantle”) or CUDA (for nVIDIA cards,
“gnustep-metal-cuda”) 4) SceneKit and SpriteKit, both can be
implemented on top of Metal. 5) loginwindow (which is necessary in
building a complete desktop experience)


Well, the biggest problem is the (nearly) complete lack of integration
between CoreBase & Base (NSRunLoop) and opal & quartzcore & gnustep-gui.
And even apps that don't make any CG/CA calls cause crashes, simply
because -gui was never really tested with real OS X apps.

(I will work on CFRunLoop-based NSRunLoop in near future.)

Right now, my impression is that if I spend a few months hacking on a
new CG/CA/AppKit implementation layered on top of Qt's accelerated
rendering engine, it will suck big time, but still have a better
compatibility and performance.

2) My point is not to clone OS X, so I'd leave this to X11/Qt/...

3) and 4) The question is how many apps need this.

-- 
Luboš Doležel

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]