Author Topic: a case for architectural change in oxygen?  (Read 19930 times)

0 Members and 2 Guests are viewing this topic.

JRS

  • Guest
Re: a case for architectural change in oxygen?
« Reply #30 on: July 26, 2012, 09:48:25 AM »
At least on the bright side, Microsoft will support Windows 7 until 2020.

Charles Pegge

  • Guest
Re: a case for architectural change in oxygen?
« Reply #31 on: July 26, 2012, 10:02:11 AM »
What is the GUI model in OSX, Frank? Does it use anything like the MS messaging system, with message loop and Wndproc callbacks?

Charles

efgee

  • Guest
Re: a case for architectural change in oxygen?
« Reply #32 on: July 26, 2012, 10:45:16 AM »
At least on the bright side, Microsoft will support Windows 7 until 2020.

Sweet.
Depending on Win8's reception they might have to prolong it like they did with WinXP.

efgee

  • Guest
Re: a case for architectural change in oxygen?
« Reply #33 on: July 26, 2012, 11:08:56 AM »
What is the GUI model in OSX, Frank? Does it use anything like the MS messaging system, with message loop and Wndproc callbacks?

Charles

Well, the old GUI stuff (Carbon) on OSX is phased-out.
The current API is utilizing Cocoa and it's object oriented.
(see http://en.wikipedia.org/wiki/Cocoa_(API))

Apple gives the programming tools (XCode) away for free.
(like what Microsoft does with Visual Studio Express with the exception that there is only one XCode version...)
XCode comes with a GUI builder where you drag-n-drop your GUI elements and you only have to write some glue code to make it work.
The task to create your GUI is seen as a design work not a programming one.

But if you want to do it the hard/manual way it would look like this:

Code: [Select]
int main(int argc, char *argv[]) {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    [NSApplication sharedApplication];

    int style = NSClosableWindowMask | NSResizableWindowMask | NSTexturedBackgroundWindowMask |
                     NSTitledWindowMask | NSMiniaturizableWindowMask;

    NSWindow *win = [[NSWindow alloc] initWithContentRect:NSMakeRect(50, 50, 600, 400)
                                    styleMask:style
                                    backing:NSBackingStoreBuffered
                                    defer:NO];

    [win makeKeyAndOrderFront:win];
    [NSApp run];

    [pool release];
}

I'm still contemplating to even not start with Objective-C because the brackets just look horrible to me.
But there are more language front-ends (C/C++) that can be used with XCode though - which is nice.
(or even totally different programming toolsets/languages like QT, wxWidgets and others...)


Anyhow, here:
http://www.cocoalab.com/?q=node/14

and here:
http://www.cocoatraces.com

you can find more information about Cocoa.

Take care.

Edit: typos...
« Last Edit: July 26, 2012, 11:46:11 AM by efgee »

Charles Pegge

  • Guest
Re: a case for architectural change in oxygen?
« Reply #34 on: July 26, 2012, 04:16:50 PM »

Very interesting, Frank.

I don't see any dark technologies like COM or .NET :) and the literature is significantly less opaque than MS, who want to bamboozle you with their latest APIs.

2 concepts used by Cocoa I would like to explore:

MVC Model-View-Controller

Building of classes at runtime: dynamically allocating methods to a class that uses standard interfaces.


I think we already have all the necessary components.

Charles

kryton9

  • Guest
Re: a case for architectural change in oxygen?
« Reply #35 on: July 26, 2012, 09:41:41 PM »
In studying QT today, I see some really neat stuff. As one of the videos I saw pointed out, everything major in the world is written in C or C++. It is not going away anytime soon. QT just brings c++ to the most modern ways of programming and supporting so many platforms natively not in a virtual machine.

I was jumping over many videos and saw some advanced one on QML, it is very clean and powerful and interfaces with c++.

Every widget in QT supports HTML. So a string variable supports html. Very powerful things that alone brings.

Not to bore you guys with QT talk, here is an incredible video of what can be done relatively easily in QT. Also I saw video of how one developer in one year ported QT for android development. That just shows how powerful QT is that one person could do that if you ask me.

3D Car Animation: http://www.youtube.com/watch?v=VvQ_NHKtHwE&feature=player_embedded

Android QT: Jump to 3:22 time to see an app being created and deployed. This first 3 minutes is setting up android, qt and the android emulator device.
http://www.youtube.com/watch?v=suPeZ7XC1xk&feature=player_embedded


kryton9

  • Guest
Nothing is for free
« Reply #36 on: July 27, 2012, 03:54:44 PM »
Here is the big downside to QT that I found. Just to show I am not a blind fan boy now.
This is a biggie and one of the downsides to having so much power and flexibility, file sizes soar.

QTSDK with examples, the IDE, demos, compiler, documentation... the works comes in at 7GB installed.

A simple app I wrote to test just a simple window, 2 buttons and a label:
To send for the first time the app to someone. 12.5MB uncompressed.
Compressed to 7zip 3.8MB

To be fair, you would send the required dlls just once and those are 12.4MB of the initial 12.5MB file size.

Like I said, Oxygen spoils one in being small and elegant at the same time.

One thing I need to figure out in QT that if we could bring to oxygen would be cool.
QT doesn't use garbage collection, but the way they create new instances from the heap memory they delete by themselves.
This happens with them somehow using new in the constructor. Then the destructor automatically deletes the object. This all happens without it being a singleton.
It is a mystery how this works, so I am trying to figure it out.

Charles Pegge

  • Guest
Re: a case for architectural change in oxygen?
« Reply #37 on: July 28, 2012, 03:07:55 PM »
Hi Kent

There are plenty of tricks for deleting or recycling objects efficiently. Particles, for instance can be held in one block of memory, and each tagged as being either active within a scene, or recyclable. All of them could be deleted in a single operation when no longer needed.

I love putting objects inside strings. Then the whole collection can be chopped, extended, nullfied or even dunked onto disk in one go.

kryton9

  • Guest
Re: a case for architectural change in oxygen?
« Reply #38 on: July 28, 2012, 07:07:35 PM »
If you could wrap code into a class or library to do such things it would be great. I have looked at some of your tree structure works and stuff and it got confusing really fast to me.

Charles Pegge

  • Guest
Re: a case for architectural change in oxygen?
« Reply #39 on: July 30, 2012, 12:36:35 AM »
Hi Kent,

This a set of macros that use the string/dynamic object duality to good effect

Code: OxygenBasic
  1.  
  2.  
  3. 'For flat objects
  4. '================
  5.  
  6. macro UseObjectArrayStrings
  7.  
  8.   macro ExtendObjectArray(v,n)
  9.   cast bstring @v += nuls n * sizeof v
  10.   end macro
  11.  
  12.   macro ClipObjectArray(v,n)
  13.   cast bstring @v = left(cast bstring @v,n * sizeof v)
  14.   end macro
  15.  
  16.   macro CopyObjectArray(w,v)
  17.   cast bstring @w = cast bstring @v
  18.   end macro
  19.  
  20.   macro EmptyObjectArray(v)
  21.   cast bstring @v=""
  22.   end macro
  23.  
  24.   macro PutFileObject(f,v)
  25.   putfile f,cast bstring @v
  26.   end macro
  27.  
  28.   macro GetFileObject(f,v)
  29.   getfile f,cast bstring @v
  30.   end macro
  31.  
  32.   macro ObjectArraySize(v)
  33.   len(cast bstring @v) / sizeof(v)
  34.   end macro
  35.  
  36. end macro
  37.  
  38. 'TESTS
  39. '=====
  40. #recordof UseObjectArrayStrings
  41. UseObjectArrayStrings
  42.  
  43. class vector
  44. float x,y,z
  45. '...
  46. end class
  47.  
  48. vector *v,*w
  49. ExtendObjectArray v,100
  50. v[100]<=1,2,3
  51. ExtendObjectArray v,100
  52. PutFileObject "t.bin",v
  53. GetFileObject "t.bin",v
  54. ClipObjectArray v,150
  55. CopyObjectArray w,v
  56. print w[100].z
  57.  
  58. print objectArraySize v
  59.  
  60. EmptyObjectArray v
  61.  

There's more to be discovered :)

Charles

kryton9

  • Guest
Re: a case for architectural change in oxygen?
« Reply #40 on: July 30, 2012, 10:20:43 AM »
That is nice Charles. Is cast acting like a template in other languages here?

It would be nice if you could just put to the array and let it extend and clip in the background automatically.
But come nice code to study.

I guess using macros this way is like using the inline command in c++?

Aurel

  • Guest
Re: a case for architectural change in oxygen?
« Reply #41 on: July 30, 2012, 01:13:50 PM »
I am just looking in this macro-s ...
Charles you say that macro-s can be used in my GUI stuff...how?

kryton9

  • Guest
new foundation
« Reply #42 on: August 04, 2012, 10:09:17 PM »
Charles and others,

I have been watching a series of videos about c++11 that I linked to on the coding monkeys forum. http://www.codingmonkeys.com/index.php?topic=2382.msg13545;topicseen#new

I really do think that the future is multi-platform and that c++ has to be the foundation for any new language. The changes coming with c++11 are amazing.
No more new and delete or manual memory allocation needed. There is no need for a garbage collection system either. Iterations are as I had asked for with my scan command and what I implemented in the sqlite class.  There is a major effort to bring uniformity to code and use with algorithms and containers. The next push is for the set of consistent libraries that other languages have.

Eros has committed too many lines in PowerBasic to make a change to another foundation language. I would hate to see that happen to Oxygen.
I think while Oxygen is in Alpha, a serious reanalysis has to be taken before too many lines are committed for any changes to be dauntingly difficult.

Not having the roots based on a language as powerful as c++ shows its ugly head with all the macro magic you need to do in Oxygen.
In watching those videos, macros are powerful but evil in the long run. Also using the winapi is talking to code written over 20 years ago.
It is really outdated and a waste of time building a language based on it. That really is my humble opinion.

I really think you should look at QT or GTK+, as those two seem to be the main leaders in the use of good design and what they bring.
It will allow oxygen to be on all major platforms with a language and library set that is practically all a language needs.

What oxygen could do is bring even cleaner syntax with Basic.  KBasic is now opensource, but buggy I read. It has also moved to a new version that is commercial, Basic for QT. So an opensource stable actively developed compileable cross platform BASIC is needed.

What is interesting is that c++11 is going to be cross platform, it is just a matter of time till all the compiler makers catch up.



Charles Pegge

  • Guest
Re: a case for architectural change in oxygen?
« Reply #43 on: August 05, 2012, 08:04:23 AM »

Excellent material, Kent. I've just been watching the first Bjarne Stroustrup lecture, and I totally concur with the points he makes.

We are not too far engrossed in WinApi. OxyyenBasic core depends on a tiny handful of Api calls. And Peter's graphics Windows is small and conceptually very easy to follow.

Macros deployed as typeless in-line procedures work well, in my view - but I anticipate these are discussed in later lectures. It is of course, all too easy to create evil mind-destroying code with macros, but several other constructs will do that just as well.

QT is Nokia property, I fear, but I would like to learn about GTK+

Charles

Aurel

  • Guest
Re: a case for architectural change in oxygen?
« Reply #44 on: August 05, 2012, 10:23:47 AM »
Quote
It is of course, all too easy to create evil mind-destroying code with macros

I would like to see this ' evil mind-destroying code ' - how look this anyway...?
Of course Peter's functions present great small and simple way to do graphics.
I don't get it Kent why you are so facinating with all this c++11...etc stuf.
All this will be implemented or based on already used things in win api for
which you say that is outdated.
Documentation for oxygen is on very poor level and not provide crucial things on simple way.
Hovewer if Oxygen really goes to only C++ OOP direction i will give up.
Another point Kent...
in one of your previous post you say QT build to big output exe then now you say that is great.
QT if you don't know (development ) is stoped and Nokia sold QT to Microsoft.
GTK ...heh this is for linux ...just look vindows GIMP version, never can reach quality like PAINT.net.
And at last i want only use win api nothing else on Windows.
Or if new WinRT will cover the best of old api -this would be fine for me.
« Last Edit: August 05, 2012, 10:41:10 AM by Aurel »