Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » Mac OS » Porting (Mac OS X) and "reference application" idea
Re: Porting (Mac OS X) and "reference application" idea [message #33143 is a reply to message #33142] Mon, 11 July 2011 06:57 Go to previous messageGo to next message
daveremba is currently offline  daveremba
Messages: 32
Registered: June 2011
Location: Los Angeles, CA, USA
Member
screen 3

index.php?t=getfile&id=3369&private=0
Re: Porting (Mac OS X) and "reference application" idea [message #33144 is a reply to message #33142] Mon, 11 July 2011 06:59 Go to previous messageGo to next message
daveremba is currently offline  daveremba
Messages: 32
Registered: June 2011
Location: Los Angeles, CA, USA
Member
iphone widgets

index.php?t=getfile&id=3371&private=0
  • Attachment: ib_iphone.png
    (Size: 411.75KB, Downloaded 886 times)

[Updated on: Mon, 11 July 2011 07:00]

Report message to a moderator

Re: Porting (Mac OS X) and "reference application" idea [message #33147 is a reply to message #33142] Mon, 11 July 2011 09:34 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
thanks for providing some insight..

the level of porting upp would be 'native', grabbing a spot of screen or a main window, and beeing able to draw on it. this can start off with the X11 based theIDE port, but it should end with a full rainbow complaint (see uppsrc/rainbow) port of the underlying structure. everything in between is sort of implementation detail Smile

concerning the widgets: upp has its own set of wifgets, so we don't need to mess around with the macos stuff at all, this is also the beauty of crossplatform.. an almost-macosx style of the upp widgets can be obtained with the skinning mechanism in upp. you already are able to have macos style in upp apps in windows..

so the basic thing is:

* implement the SystemDraw interface, which redirects the corresponding drawing operations (like DrawRect, DrawLine) to the native drawing contexts of macos.

* implement the mouse processing to translate the received mouse handling from macos to upp and have upp process it.

* implement the keyboard processing, translate the received key actions from macos to upp and have upp process it.

* when this quite works, stuff like copy/paste, drag/drop etc. can be handled (with macos means).

i'm novice in mac stuff (actually have done nothing with it, besides some research in the web for quartz port). but i will try to help. since MACOSX port of UPP would be a MAJOR boost for upp, and our company would HIGHLY apriciate, we have audio controlling software coded in upp, customers have windows, linux, AND ofcorse macos, and need to run it in simulaters. i'm a bit into the porting stuff (not too much though), porting to linux native framebuffer and SDL. so the process is comparable. but it this case, you have main windows of macos (which should map to TopWindow), and i have a single sheer of buffer Smile which is esier..
Re: Porting (Mac OS X) and "reference application" idea [message #33149 is a reply to message #33140] Mon, 11 July 2011 14:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
daveremba wrote on Mon, 11 July 2011 00:52


What kind of port would be reasonable and useful
to the UPP community?

Probably reinventing
the entire Apple tool chain is not desirable.



I always tend to answer myself: Firefox.

Despite looks, Firefox is emulated GUI on Win32 and Linux, just like U++. I believe it is emulated GUI on MacOSX to, hint is e.g. here:

http://mxr.mozilla.org/firefox/source/widget/src/cocoa/nsNat iveThemeCocoa.h

Quote:


is there a 1:1 correspondence of widgets to UPP?
(probably not)



Well, the desired result is that any single existing example in examples and reference runs on MacOSX in native mode and feels native. We are not aiming at 100% look&feel. 97% is just enough Smile

Quote:


The UPP community would want an app that runs
on Linux and Windows to look similar, but also
conform to Apple look and feel, right?
(without much or any re-coding effort, like
Qt etc, but a better result than Qt)



Exactly. And we already know it is possible Linux vs Windows wise.

Quote:


There are several technical paths to chose from;
and picking the best one depends on what
the community expects from a porting effort
of UPP to Mac.



Actually, I do not think so. There is only one possible path and it is the same as current Linux and Windows backends... Smile

I have outlined steps in previous posts.

Just to make things clear, we will NOT be using Cocoa widgets. We will be emulating them.

So the whole xcode/nib thing is mostly irrelevant to us. We will only use as little so that MacOSX recognizes our app as native. Nothing more.

To MacOSX it will be just windows with simple view and no subwidgets...


Quote:


off-topic:
A universal mobile UI framework that claims 1 million
developers for mobile devices and that I'm working
with is Sencha, which runs in Javascript.

The libarary is called ExtJS. Here is the
link:
http://www.sencha.com/products/extjs/

Sencha currently lacks a good data-object
connection to server (Direct-EXT is incomplete).
I recommend UPP developers take a look at it,
how might it relate to the Rainbow (or future UPP)
projects?

For another project, I am considering using UPP for the
server backend (since it is so fast compared to PHP, and
a much better language (C++ & good design)
compared to PHP). I'd need JSON/REST in UPP
to get my project working however.

Any comments on this would be appreciated
(maybe in another thread).




Interesting. I see rainbow and MacOSX as our responsibility, something that simply needs to be done, but after that, I definitely want to work quite a lot on U++ as web framework. Maybe even embrace Javascript in theide in some way... Smile

That said, U++ is already being used as backend quite intensely in my work. But we are still missing "higher level" web framework...




Re: Porting (Mac OS X) and "reference application" idea [message #33150 is a reply to message #33149] Mon, 11 July 2011 15:06 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
PS.: Kohait00 gets it right on spot too Smile

[Updated on: Mon, 11 July 2011 15:07]

Report message to a moderator

Re: Porting (Mac OS X) and "reference application" idea [message #33171 is a reply to message #33150] Wed, 13 July 2011 00:15 Go to previous messageGo to next message
daveremba is currently offline  daveremba
Messages: 32
Registered: June 2011
Location: Los Angeles, CA, USA
Member
OK, your messages make it very clear & helpful.
No high level widgets.
I understand that in summary,
we're aiming for a low level port
at the System Draw level, etc.
(like from Windows to Linux).

Quote:

Actually, I do not think so. There is only one possible path and it is the same as current Linux and Windows backends...



Well within that path,
I am thinking of looking into the following
sub-paths:

1) X11 approach - develop in GCC
continue to use X11 code for drawing,
fix the observed artifacts (flat buttons and
uninitialized areas behind menus), and
add the needed code to get top windows recognized
by MacOS as true application processes
(most work appears to be done
since UPP already has X11/Linux done, but
X11 can be complex and emulator on
MacOS may not be 100% compliant)


2) OpenGL approach - develop in GCC
implement low level drawing code using OpenGL,
and use a simple library like GLUT for window
system, keybd, and mouse, events
(simple and high performance, but not sure
if GLUT behaves well with MacOS)

This is the approach used by:
http://www.openframeworks.cc/about

3) Objective-C++ approach - develop in Xcode
implement low level drawing, window, and
event code using Obj-C calls into MacOS (probably low level
Cocoa calls) hooked into SystemDraw
and other UPP libs.
(probably the most work, but maybe the
best visual result, and flexible towards
more compatbility with Apple in the future).


4) do whatever they do approach - develop in GCC
continue to look at other frameworks (wxWidgets, Firefox,
Qt, FLTK, Tcl/Tk) and see what they do;
borrow from their code libraries if possible.
wxWidgets uses approach (3) above

Here is an interesting comparison of
UI toolkits (from a wx perspective):
http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolki ts
wxWidgets has a pretty clear Cocoa library
in their source tree; unlike Firefox it
builds standalone apps rather hooked into
the Gecko framework (browser).

FLTK has an architecture that is most similar
to UPP - only a small portion of the code is
platform specific. It draws its own
widgets using low level 2D drawing primitives
in OpenGL (as in approach (2) above).
Pros: it looks the same on all platforms,
Cons: it never looks like other native apps
on any platform.
This code may be helpful to fix problems
in approach (1 & 2) above.
Source code is here:
http://www.fltk.org/software.php?VERSION=1.3.0&FILE=fltk /1.3.0/fltk-1.3.0-source.tar.gz

Firefox source is browsable here:
(to see how they do things, as you suggested Mirek)
http://mxr.mozilla.org/firefox/source/

The Firefox to Cocoa code is here:
http://mxr.mozilla.org/firefox/source/widget/src/cocoa/

I will do some tests/learning, and
report back in a few days, and
I will see how far the previous Mac
port effort got.

It seems that getting apps to work in the
X11 emulator is still worthwhile as the
easiest first step. (approach 1)

I spoke to my project client and they also do
want a working MacOS front end as well.

-Dave

[Updated on: Wed, 13 July 2011 08:01]

Report message to a moderator

Re: Porting (Mac OS X) and "reference application" idea [message #33173 is a reply to message #33171] Wed, 13 July 2011 08:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
daveremba wrote on Tue, 12 July 2011 18:15


3) Objective-C++ approach - develop in Xcode
implement low level drawing, window, and
event code using Obj-C calls into MacOS (probably low level
Cocoa calls) hooked into SystemDraw
and other UPP libs.
(probably the most work, but maybe the
best visual result, and flexible towards
more compatbility with Apple in the future).





Well, my intention actually was:

Objective-C/C++ approach - develop in TheIDE (X11).

So the steps are: Get TheIDE running in X11, investigate what is needed to be done to TheIDE build process to achieve _minimal_ cocoa application support, then use TheIDE to develop Cocoa based backend. Obiouslu, it is not important for macosx11 theide to look and feel native...

Of course, I can imagine that before we have Cocoa building X11 theide, somebody else can use xcode to start develop SystemDraw.

But I guess having theide is essential, as we need package/assembly system to do any reasonable development with U++ sources.

(That said, my immediate next plan after rainbow is "true" umake, one not requiring GUI to build apps, but that is another matter).

[Updated on: Wed, 13 July 2011 08:15]

Report message to a moderator

Re: Porting (Mac OS X) and "reference application" idea [message #33176 is a reply to message #33173] Wed, 13 July 2011 10:06 Go to previous message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
rainbow has a WinGL backend, which, as remember to have seen, also uses GLUT Smile maybe take a look in there too..
Previous Topic: possibly working theide on Mac OS X using tiny mods to UNIX dist
Next Topic: Mac OS X backend development process
Goto Forum:
  


Current Time: Thu Mar 28 21:40:12 CET 2024

Total time taken to generate the page: 0.01387 seconds