Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
It isn't IUP anymore, if you are going to follow through on all that you propose, it is something else entirely so call it something else entirely...call it PUI. Otherwise, do not tarnish the name and concept of IUP. I like IUP because it is extremely consistent between platforms (no recoding necessary, if done right). IUP is very readable, maintainable, and modular, and this new proposal would undo all that. If any programmer wants IUP, they should migrate to a platform where it's wonderful architecture is supported (Linux or Windows). You would have to make PUI compatible with Xcode, as the Windows/Linux GUIs are not even remotely compatible with the iOS API paradigm. Changing IUP APIs to be compatible with iOS APIs, as you would clearly have to do (and have already proposed) to make them compatible, would only obfuscate code instead of making it more clear. How would PUI handle when the user rotates their iOS device? You can't just simply rescale everything in your user interface, very often you have to reorganize your GUI entirely. I even have to rescale text at times. And what about iOS API quirks, like their use of nil vs null? I have programmed for iOS and Windows and I am sticking to Swift and Xcode for iOS because they are made for each other. Since Android uses the Linux kernel, you can write Linux-like apps, and I say Linux-like because the Android version of Linux is limited in functionality (http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=get&target=Mythbusters_Android.pdf). I think a limited version of IUP would not be very compelling. What is needed is an actual Windows- or actual Linux-based phone, and then IUP would be perfect. On 1/4/2017 at 3:49 PM, Eric Wing wrote: >As I said earlier, the way IUP does its startup sequence and main loop >is incompatible with Android and iOS, and potentially other backends >like Emscripten/asm.js/WebAssembly. So I have developed a new >alternative sequence that I believe will work with all platforms. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
Andrew, I want to try to address your concerns, so I will go point by point inline. On 1/4/17, Andrew Robinson wrote: > It isn't IUP anymore, if you are going to follow through on all that you > propose, it is something else entirely so call it something else > entirely...call it PUI. Otherwise, do not tarnish the name and concept of > IUP. - This specific event loop proposal actually has nothing to do with mobile vs. desktop. It has to do about trying to also support other platforms that don’t do their event loops the same way the current existing backends happen to work. The proposal retains legacy behavior so existing code on existing platforms will continue to work. And the proposal also re-unifies the platforms under the new behavior so all platforms are the same again for both old and new. This is all accomplished by introducing a new callback attribute to be a designated start point for user code. > If any programmer wants IUP, > they > should migrate to a platform where it's wonderful architecture is supported > (Linux or Windows). > - By your objections, it sounds like you are also resistant to the idea of Mac support for IUP. I don’t think this is healthy for a project that strives to be cross-platform. Its original design goals were to give a simple abstractive to native that could cover many widely different platforms, originally MS-DOS, Motif, OS/2, OpenLook/XView. IUP’s design was able to extend and endure far beyond all of those. I believe IUP’s design still holds true for these newer platforms. Its original intention/dream/potential can be further realized by actually doing this. > You would have to make PUI compatible with Xcode, - This statement doesn’t make a lot of sense to me, so I don’t understand what your concern is. Xcode is just an IDE. And I already made an Xcode project for both the Mac and iOS backends. > I like IUP because it is extremely consistent between platforms (no > recoding > necessary, if done right). IUP is very readable, maintainable, and modular, > and this new proposal would undo all that. ...(and)... > as the Windows/Linux GUIs > are not even remotely compatible with the iOS API paradigm. Changing IUP > APIs > to be compatible with iOS APIs, as you would clearly have to do (and have > already proposed) to make them compatible, would only obfuscate code > instead > of making it more clear. - Obfuscated: I think this is the most legitimate concern you raise. I think this is worth exploring and discussing. I don’t want to create a monster. However, as I pointed out (and even to the original IUP white papers), these wide platform variations are the very kind of thing that IUP was designed/intended to handle. And so far, specifically speaking about mobile, I don’t feel like there is an issue yet that is fundamentally incompatible with IUP’s design. And I have not yet proposed anything that breaks existing apps. Re-read my event loop proposal and see that it preserves legacy behavior. And re-examine the video proposal I made…I want to emphasize: I first made a standard desktop IUP app consisting of a Window and Button (Dialog and Button). I took that exact code (no changes) and made it work in a natural way on iOS and Android. The point of that demo was to show that without forcing rewrite of our app, we can adapt IUP’s existing API to behave in a natural way for those platforms. If I did the naive thing and just mapped Dialog to a mobile “Window”, the app wouldn’t function like a typical mobile app and you would be forced to write new/special code to handle those cases. But my point in showing this is that I believe IUP’s well-designed API already can handle a lot of these differences if we think about about the big picture. In this case, the big idea was to map NavigationController/Activity to Dialog instead of a “window”. That said, I’m not claiming this is going to be perfect, but my sense is that the code differences between mobile and desktop can be small (depending on the design of the app of course). (And I’ve done this commercially before with the Corona SDK so I have actual experience to back this claim up. And Appcelerator Titanium, which I was also involved with, originally supported desktop and mobile until they dropped desktop support because all the money was coming from just mobile. AppC also was building the full application stack, not just GUIs so there was a lot more effort involved.) I am proposing we will need to support a few new callbacks you can register for like for Suspend and Resume. But this really isn’t different than what goes on now. There are lots of attributes in IUP labeled “Windows only” or “GTK only”. It’s going to be no different for any new platform, regardless if it is mobile or desktop. And any developer who wishes to improve the experience on a specific platform can by opting into those extra attributes. But my goal in demonstrating the Dialog/ViewController/Activity was that we can still try to create a sensi
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
I'll take a look at this in a couple of days.
Best,
Scuri
On Wed, Jan 4, 2017 at 8:49 PM, Eric Wing wrote:
> As I said earlier, the way IUP does its startup sequence and main loop
> is incompatible with Android and iOS, and potentially other backends
> like Emscripten/asm.js/WebAssembly. So I have developed a new
> alternative sequence that I believe will work with all platforms.
>
> Android Background:
> The reason IUP’s current system doesn’t work on Android is two-fold.
> 1) All Android applications start in Java, and Android/Java completely
> control the event loop. It is not possible to access it or control it.
> 2) Android is event driven. Everything starts from a callback in Java.
> There is no C main function. We use callbacks to cross into C via JNI
> so we can run normal IUP user code. But because this is an event
> callback, the function must return. Calling IupMainLoop() is expected
> to not return which thus would block the event loop.
>
> iOS Background:
> iOS almost works, but not quite, so in the end, it is ultimately the
> same problem as Android. In iOS, to start the main event loop, we need
> to call UIApplicationMain(). I made this the implementation for
> IupMainLoop(), and this seems to fit. But the problem is that IUP APIs
> are expected to work before you call IupMainLoop(). If
> UIApplicationMain hasn’t been started yet, there are a bunch of
> implementation details in CocoaTouch I depend on to make the
> implementation work that have not created/initialized yet. These are
> things like the application delegate, and even the autorelease pool.
> So basically, UIApplicationMain is expected to be the first thing run
> in an iOS app. But once you run it, it doesn’t return and it takes
> control of the event loop. So now our problem looks the same as
> Android.
>
> Mac background:
> Mac’s startup sequence is a little different than iOS’s, so I was
> actually able to make Mac conform to the legacy startup sequence.
> However, Mac really wants to behave more like iOS/Android and what I
> did to implement this is not typical.
>
>
> Proposal:
> We introduce a new callback function, e.g. void IupEntryPoint(void)
> which gets invoked after the application gets started. This is where
> the user’s code officially begins.
>
>
> So for a typical cross-platform project, I expect something like:
>
>
> void IupEntryPoint(void);
> void IupExitCallback(void);
>
> // Remember that main is never run on Android.
> // This main function should be a template/copy-and-paste for all IUP
> projects.
> // Don't put any user code here. All user code should start in
> IupEntryPoint.
> // The main you see here is only to get the platform to eventually
> invoke IupEntryPoint() on platforms that need it.
> int main(int argc, char* argv[])
> {
> IupOpen(0, NULL);
> IupSetFunction("ENTRY_POINT", (Icallback)IupEntryPoint);
> // User can no longer assume that IupMainLoop blocks, and may
> return
> immediately.
> // You should probably not put code after this call.
> // On the pre-existing platforms, IupMainLoop will be
> implemented to lead to IupEntryPoint being invoked.
> IupMainLoop();
> return 0;
> }
>
> // This is where user code should start
> void IupEntryPoint()
> {
> // TODO: Proposed exit callback so the user can call IupClose()
> IupSetFunction("EXIT_CB", (Icallback)IupExitCallback);
>
> Ihandle* button = IupButton("Iup Button", "");
> IupSetCallback(button, "ACTION", (Icallback)OnButtonCallback);
> Ihandle* dialog = IupDialog(button);
> IupShow(dialog);
> }
>
> // TODO: Proposed exit callback which the user should setup in the
> IupEntryPoint() callback.
> void IupExitCallback()
> {
> IupClose();
> }
>
> So here are the major points:
>
> - Unchanged legacy code will continue to work as before (Windows, GTK,
> Motif).IupEntryPoint() will not exist nor IupSetFunction is never
> called for it, so it will never get invoked. IupMainLoop() will still
> behave exactly as before on those existing implementations. So nobody
> is forced to migrate until ready.
>
> - New code should adopt this new design. That way it will work on both
> the existing platforms (Windows, GTK, Motif), but also work on the new
> platforms (iOS, Android, Mac).
>
> - On Android, the main() function never gets run. But all the other
> platforms will run it. The callback entry point is where all platforms
> will start running the same code.
>
> - On Android, because main() is never run, there is no opportunity
> to
> call IupSetFunction() beforehand, IupEntryPoint() is a hardcoded
> fallback/default. Because of this, documentation/conventions should
> strongly encourage one standard function name, e.g. IupEntryPoint.
> However, I made it possible to specify a different function name in
> the AndroidManifest.xml.
>
>
> - Unix dlsym allows us to search for a symbol globally instead of a
> specific librar
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
Hi Eric, IUP is extremely healthy the way it is now, so protecting IUP's health is the more important of all things to consider. Please, IUP developers, do not let IUP go the way of Microsoft or GTK+ or Firefox. They had thee winning formula; a product that worked great and everybody loved, and then they went out and threw it all away for something "new" and "better" and "more healthy", but in reality they ruined their products. The moral of the story here is, don't let the dream anyone speaks of turn IUP into a nightmare. Let's keep it realistic, practical, readable, maintainable, and modular -- like it is now -- and drop the dream if it would affect the health of IUP in any of those regards. I am perfectly happy with IUP not being available on iOS or Android. That would never affect my choice of IUP because IUP is still the best portable user interface out there for Windows and Linux. Talking about the different specific event loops is like talking about apples and oranges. iOS and IUP work on two completely different event paradigms. It would require a rework of IUP base code to handle or convert two completely different methods of handling events, and by definition that would make it a kludge. Could you get a beginner programmer to understand any of that song and dance routine? If you take an orange and try to turn it into an orange-apple hybrid, all you are going to get is a Frankenstein monster. You cannot port a desktop app to a iOS app. They don't remotely look or act the same. Desktops have just one main screen, whereas iOS has tiny little multiple main screens you switch between. That means you would need multiple GUIs yet only use only one IupMainLoop. I smell another kludge in the making with that one. IUP has no variable constraint functions that I know of or have seen. You set the size of a control and you're done. Unlike a desktop app, your mobile app must fill the entire screen. Modifying IUP so it would *elegantly* be resizable on-the-fly just doesn't seem to be there. This isn't something that iOS does automatically for you, it sends you a notification of the screen size at start up, and it notifies you when orientation changes, it is then up to your program to accommodate those changes with your many different GUIs screen sizes. What a horrible coding mess that would be to try and do with IUP as it is now. Most iOS programmers do not understand the difference between nil and null (and certainly no one outside of iOS would understand this at all). In iOS, a string can be null terminated but it cannot be nil terminated. The variable that defines a string can be nil or a value. If you don't handle the nil case by implicitly unwrapping or binding your optionals, your app will crash or not function. Without nil, you can make unsafe pointers and get absolutely no feedback from IUP that they are unsafe. Have fun debugging that issue within IUP. Nil is an entirely new concept from Apple that IUP and the C language does not even come close to handling natively. Like I said, make this a separate project from IUP and call it something else. Best Regards, Andrew -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
Hi all, let me add my $ 0.02 here. On Jan 8 2017, Andrew Robinson wrote: >Hi Eric, > > IUP is extremely healthy the way it is now, so protecting IUP's health is > the more important of all things to consider. > > Talking about the different specific event loops is like talking about > apples and oranges. I do NOT share your hard feelings towards the proposal. Without knowing enough of the IUP internals to judge how hard it would be to actually implement it, I had the impression that the proposal was well thought out and would broaden the applicability of IUP. And at least IMHO it looks as if there is little actual damage done. I myself learned already before to work AROUND the limitation of IUP expecting to assume control of the event loop of the application. And that is for a pure C+Linux application (which assumes to mostly sit in poll(2) and revolves around invoking callbacks when data is available). I wonder how many people ran into those issues too. Furthermore I'd also welcome IUP support for iOS or Android. Though I'd agree with Andrew: if that came at the cost of becoming a non-maintainable bloatware, I'd rather choose the path of simplicity. Best /Jörg .. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
On 1/8/17, Andrew Robinson wrote: > Hi Eric, > > IUP is extremely healthy the way it is now, so protecting IUP's health is > the > more important of all things to consider. Please, IUP developers, do not > let > IUP go the way of Microsoft or GTK+ or Firefox. They had thee winning > formula; > a product that worked great and everybody loved, and then they went out and > threw it all away for something "new" and "better" and "more healthy", but > in > reality they ruined their products. The moral of the story here is, don't > let > the dream anyone speaks of turn IUP into a nightmare. Let's keep it > realistic, > practical, readable, maintainable, and modular -- like it is now -- and > drop > the dream if it would affect the health of IUP in any of those regards. I > am > perfectly happy with IUP not being available on iOS or Android. That would > never affect my choice of IUP because IUP is still the best portable user > interface out there for Windows and Linux. > There are a lot of pre-conceived beliefs (synonym=dogma) in this claim. I’m not even sure how to respond to it. But as to “healthy”, the one common thing I see everywhere is that the lack of Mac support has hurt IUP’s adoption. I’m not sure if I should bring up libui since I don’t have counterpart metrics for IUP, but for a library that just debuted this past year, it already has 200 watcher/forks and 4000 stars on GitHub. And in all the comment threads about libui, I see a mention of IUP and its unfortunate lack of Mac support. As to Microsoft, there were so many blunders there I don’t know what lessons you are trying to refer to. The big one most market analysts complain about is how they missed the mobile revolution, which actually supports what I would like to accomplish. I think the biggest complaint about GTK was they completely broke API and ABI compatibility between 2 and 3. For my IUP proposal, I’m working within the existing design to not break compatibility. I have no clue what you are getting at with Firefox. As for “practical, readable, maintainable, and modular”, that’s more dogma if you look at my prototypes. Nothing I’ve done really changes anything. The API and ABI are preserved. Each platform goes into its own backend implementation in its own subdirectory in IUP and doesn’t change the IUP core files, exactly as IUP works today. This is just as modular as IUP has always been and nothing forces you to use the platforms you don’t want. > Talking about the different specific event loops is like talking about > apples > and oranges. iOS and IUP work on two completely different event paradigms. > It > would require a rework of IUP base code to handle or convert two completely > different methods of handling events, and by definition that would make it > a > kludge. Could you get a beginner programmer to understand any of that song > and > dance routine? If you take an orange and try to turn it into an > orange-apple > hybrid, all you are going to get is a Frankenstein monster. > Every platform has a concept of an event loop. Some platforms require you to drive the event loop. Others platforms completely control the event loop. Taking mobile off the table for a second, IUP being a cross-platform library must deal with this. There are desktop platforms that also want to drive the event loop. My proposal here is intended to fix that. (It has the additional benefit of potentially allowing IUP to co-exist with other cross-platform libraries that also try to take over the event loop, such as SDL, because it begins to more formally separate out the event loop code from the main app logic.) And I think you are overstating the iOS event loop differences. I already described at the top of the proposal how each of the event loops work. iOS was the one that *almost* worked. (I initially tried something like my Mac hack, but it caused a lot of unexpected bugs and complexity. Because of this, I actually worry that my Mac implementation may be too fragile. This proposal would give me the option to do a more standard thing on Mac.) As for newbie learning, I think you overstate the difficulty here too. IUP is already event driven. Users must learn about the various callbacks, such as RESIZE_CB, CLOSE_CB, ACTION, and so forth. This proposal is simply proposing a formal callback convention for when an app is started. The logical extension of this proposal is to have callbacks for close, suspend, resume. But these are not conceptually hard, and are somewhat optional in that you only fill them in when you need them. Most platforms automatically clean up your process space so formal application exiting is not required. You might only use it if you are not saving user state during your app as the user goes, so you need to do it on quit. But if you do this AND you decide to support mobile, then you also want to implement a suspend callback. My guess is that the majority of users will call the same subroutine for quit and suspend. > You cannot por
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
>I think your understanding of NULL and nil is completely wrong here >and you are creating a straw-man. As I already explained, both are >defined as 0. There is no difference to the computer. You are wrong here, and I think that says all I need to say about the rest of your "argument". Nil is defined as an object, and null as a zero. Read all about it here: http://www.codingexplorer.com/swift-optionals-declaration-unwrapping-and-binding/ You don't unwrap or bind strings, you unwrap or bind objects. A nil object represents an object which has not been instantiated. It is not zero and never has been. Best Regards, Andrew -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
Hi, Eric. I consider you can/could/should clone IUP and procced as you say with respect to take IUP to Android or any mobile. Because you know both sides. Do it.. and Antonio and his group will see how it could be "standardized". 2017-01-12 20:53 GMT-05:00 Eric Wing: > I’m not sure if I should bring up libui since > I don’t have counterpart metrics for IUP, but for a library that just > debuted this past year, it already has 200 watcher/forks and 4000 > stars on GitHub. > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
I think any major directional changes should include a web IUP as a consideration. IMHO On Fri, 2017-01-13 at 12:41 -0500, Hernan Cano wrote: > Hi, Eric. > > I consider you can/could/should clone IUP and procced as you say with > respect to take IUP to Android or any mobile. > > Because you know both sides. > > Do it.. and Antonio and his group will see how it could be > "standardized". > > > 2017-01-12 20:53 GMT-05:00 Eric Wing: > > I’m not sure if I should bring up libui since > > I don’t have counterpart metrics for IUP, but for a library that > > just > > debuted this past year, it already has 200 watcher/forks and 4000 > > stars on GitHub. > --- > --- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > ___ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
On 1/12/17, Andrew Robinson wrote: >>I think your understanding of NULL and nil is completely wrong here >>and you are creating a straw-man. As I already explained, both are >>defined as 0. There is no difference to the computer. > > You are wrong here, and I think that says all I need to say about the rest > of > your "argument". Nil is defined as an object, and null as a zero. Read all > about it here: > http://www.codingexplorer.com/swift-optionals-declaration-unwrapping-and-binding/ > > You don't unwrap or bind strings, you unwrap or bind objects. A nil object > represents an object which has not been instantiated. It is not zero and > never > has been. > > Best Regards, > > Andrew > You are lost in the abstraction layer and are missing what’s actually going on at the machine level. Let me spell it out for you: - Cocoa/CocoaTouch is implemented in Objective-C. - I’m implementing the IUP backend in Objective-C. - Objective-C is a pure superset of C. In objc.h: nil is defined as: # define nil __DARWIN_NULL In C, NULL is generally provided by stddef.h, which goes into platform headers. This will lead you to sys/_types/_null.h #define NULL __DARWIN_NULL See? Both nil and NULL are the same. In sys/_types/_types.h, you’ll find the definition for _DARWIN_NULL #define __DARWIN_NULL 0 See? The value is 0. Thanks, Eric -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
On 1/13/17, John Spikowski wrote: > I think any major directional changes should include a web IUP as a > consideration. IMHO I think this is a really interesting idea and I would love to include this. I've done a tiny bit with Emscripten/asm.js, but I am no means an expert. I am also not a web person so I don't have the domain specific knowledge on what a backend should look like. At a very high level, I think it should work like the following: (1) You should be able to take your C based IUP application, and compile it through Emscripten. Emscripten/IUP should have some kind of implementation for all the library calls (I'm guessing implemented in JavaScript for the web browser, though maybe it is CSS/HTML?). The final output Emscripten generates is a web site (with all the C converted to JavaScript), which is your original program now working in the web browser. (2) Emscripten/IUP should be able to output just a JavaScript/web module that web application developers can import into their projects. They can write new IUP applications completely in JavaScript for the web browser and will not have to write any C. (3 bonus) Presumably, other people may want native JavaScript bindings (aka non-web, directly to JavaScriptCore, v8, SpiderMonkey, DukTape, etc.) to IUP. (If you are confused by this concept, see my JavaScript talk from the Lua Workshop 2016 https://www.youtube.com/watch?v=Xi_eMGO3g-o) The Emscripten/IUP JavaScript web API should be the same as any direct native JavaScript bindings to IUP/C. That way a developer who writes an app completely in JavaScript, can easily transplant it between the web browser and a native IUP app using the JavaScript bindings. In terms of IUP changes, I don't see it much different than what I'm doing now. I do know the existing IUP event loop will be a problem, however, I believe my event proposal should fix this one too. Since the web works on both desktop and mobile too, I suspect it will just be able to leverage what's already there. But as I said, I currently don't have the expertise in web backends or Emscipten to say more than this. So if we can find somebody to step up as the expert for this, then that would be great. Thanks, Eric -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
You have clearly never programmed for the iPhone or iPad before. nil is an object. null is a delimiter, usually used in null terminated strings or the value of a parameter. Don't waste my time. On 1/13/2017 at 2:31 PM, Eric Wing wrote: >On 1/12/17, Andrew Robinson wrote: >>>I think your understanding of NULL and nil is completely wrong here >>>and you are creating a straw-man. As I already explained, both are >>>defined as 0. There is no difference to the computer. >> >> You are wrong here, and I think that says all I need to say about the rest >> of >> your "argument". Nil is defined as an object, and null as a zero. Read all >> about it here: >> http://www.codingexplorer.com/swift-optionals-declaration-unwrapping-and-binding/ >> >> You don't unwrap or bind strings, you unwrap or bind objects. A nil object >> represents an object which has not been instantiated. It is not zero and >> never >> has been. >> >> Best Regards, >> >> Andrew >> > >You are lost in the abstraction layer and are missing what’s actually >going on at the machine level. > >Let me spell it out for you: >- Cocoa/CocoaTouch is implemented in Objective-C. >- I’m implementing the IUP backend in Objective-C. >- Objective-C is a pure superset of C. > > >In objc.h: nil is defined as: ># define nil __DARWIN_NULL > > >In C, NULL is generally provided by stddef.h, which goes into platform >headers. This will lead you to sys/_types/_null.h >#define NULL __DARWIN_NULL > >See? Both nil and NULL are the same. > > >In sys/_types/_types.h, you’ll find the definition for _DARWIN_NULL >#define __DARWIN_NULL 0 > >See? The value is 0. > > >Thanks, >Eric > >-- >Developer Access Program for Intel Xeon Phi Processors >Access to Intel Xeon Phi processor-based developer platforms. >With one year of Intel Parallel Studio XE. >Training and support from Colfax. >Order your platform today. http://sdm.link/xeonphi >___ >Iup-users mailing list >Iup-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/iup-users -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
PS -- In case you didn't notice, IUP is written for C and is meant to interface with the C language, not assembly language. The C language does not support nil, so if you tell programmers to use null instead of nil, you will screw it all up. nil is not null. It is not treated like null. nil is treated like an object that is empty. nil is not a parameter. Apple's documentation discusses this as well, I suggest you read it. On 1/13/2017 at 2:31 PM, Eric Wing wrote: >On 1/12/17, Andrew Robinson wrote: >>>I think your understanding of NULL and nil is completely wrong here >>>and you are creating a straw-man. As I already explained, both are >>>defined as 0. There is no difference to the computer. >> >> You are wrong here, and I think that says all I need to say about the rest >> of >> your "argument". Nil is defined as an object, and null as a zero. Read all >> about it here: >> http://www.codingexplorer.com/swift-optionals-declaration-unwrapping-and-binding/ >> >> You don't unwrap or bind strings, you unwrap or bind objects. A nil object >> represents an object which has not been instantiated. It is not zero and >> never >> has been. >> >> Best Regards, >> >> Andrew >> > >You are lost in the abstraction layer and are missing what’s actually >going on at the machine level. > >Let me spell it out for you: >- Cocoa/CocoaTouch is implemented in Objective-C. >- I’m implementing the IUP backend in Objective-C. >- Objective-C is a pure superset of C. > > >In objc.h: nil is defined as: ># define nil __DARWIN_NULL > > >In C, NULL is generally provided by stddef.h, which goes into platform >headers. This will lead you to sys/_types/_null.h >#define NULL __DARWIN_NULL > >See? Both nil and NULL are the same. > > >In sys/_types/_types.h, you’ll find the definition for _DARWIN_NULL >#define __DARWIN_NULL 0 > >See? The value is 0. > > >Thanks, >Eric > >-- >Developer Access Program for Intel Xeon Phi Processors >Access to Intel Xeon Phi processor-based developer platforms. >With one year of Intel Parallel Studio XE. >Training and support from Colfax. >Order your platform today. http://sdm.link/xeonphi >___ >Iup-users mailing list >Iup-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/iup-users -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
On 1/13/17, Andrew Robinson wrote: > You have clearly never programmed for the iPhone or iPad before. > > nil is an object. > null is a delimiter, usually used in null terminated strings or the value of > a > parameter. > > Don't waste my time. It's clear to me you are terribly confused on the fundamentals. You are certainly confused on the difference between the Cocoa frameworks and the Swift language. You also have shown little understanding of Objective-C. And you continue to demonstrate you don't understand how a backend works and the responsibilities a backend takes to hide implementation details and enforce public API contracts. I've been doing Cocoa for nearly 15 years. I've been a contributor to open source projects such as SDL and OpenSceneGraph to help improve the Apple platform support. I wrote the worlds first full featured Obj-C language bridge to Lua, LuaCocoa. I'm a published author for Apress for the book Beginning iPhone Games Development. I've worked with companies building Mac and iOS products. I had the privilege of working on two commercial SDKs that allowed thousands of developers to create iOS and Android apps that were used by millions of people. And I already published a runnable prototype for IUP for both Mac and iOS which doesn't flip out on these problems you've tried to invent. I suspect the others reading this thread will be able to figure out which one of us knows what they are talking about. -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
I'm only going to tell you one more time: shut up, you don't know what you are talking about. That why I give links to back up what I say, and you don't. On 1/13/2017 at 8:13 PM, Eric Wing wrote: >On 1/13/17, Andrew Robinson wrote: >> You have clearly never programmed for the iPhone or iPad before. >> >> nil is an object. >> null is a delimiter, usually used in null terminated strings or the value of >> a >> parameter. >> >> Don't waste my time. > > >It's clear to me you are terribly confused on the fundamentals. You >are certainly confused on the difference between the Cocoa frameworks >and the Swift language. You also have shown little understanding of >Objective-C. And you continue to demonstrate you don't understand how >a backend works and the responsibilities a backend takes to hide >implementation details and enforce public API contracts. > >I've been doing Cocoa for nearly 15 years. I've been a contributor to >open source projects such as SDL and OpenSceneGraph to help improve >the Apple platform support. I wrote the worlds first full featured >Obj-C language bridge to Lua, LuaCocoa. I'm a published author for >Apress for the book Beginning iPhone Games Development. I've worked >with companies building Mac and iOS products. I had the privilege of >working on two commercial SDKs that allowed thousands of developers to >create iOS and Android apps that were used by millions of people. And >I already published a runnable prototype for IUP for both Mac and iOS >which doesn't flip out on these problems you've tried to invent. > >I suspect the others reading this thread will be able to figure out >which one of us knows what they are talking about. > >-- >Developer Access Program for Intel Xeon Phi Processors >Access to Intel Xeon Phi processor-based developer platforms. >With one year of Intel Parallel Studio XE. >Training and support from Colfax. >Order your platform today. http://sdm.link/xeonphi >___ >Iup-users mailing list >Iup-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/iup-users -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
In conclusion... Working with nil from the Apple Developer site: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithObjects/WorkingwithObjects.html Best Regards, Andrew -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
I couldn't even had time to take a look at Eric considerations yet, but I would like to say a few words. First, our policy in IUP is to always maintain backward compatibility. We have applications that started their development in the 90's and they are still running using latest IUP version, with minor changes from IUP 2 to IUP 3 (and that shouldn't occur ever again). Said that, Eric is doing a great job implementing a driver for MacOS. And the idea is the same, to provide a portable abstraction that will not affect current application code that uses IUP. iOS and Android are a plus, they are still an incognita for me. We would like to dive into that world, but no doubt we will do it with caution and certainly not breaking any existing applications. So if you don't care about those systems simply ignore them. There are no plans in changing the current IUP API just for that matter. On the other hand if I could ADD some features that will help those drivers to happen then there is no problem in that and I'll be happy to do it. Next week I should release version 3.21, but before that I'l take a look at Eric's considerations and see what can be done. Best Regards, Antonio Scuri On Sat, Jan 14, 2017 at 5:28 PM, Andrew Robinson wrote: > In conclusion... > > Working with nil from the Apple Developer site: > https://developer.apple.com/library/content/documentation/ > Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithObjects/ > WorkingwithObjects.html > > Best Regards, > > Andrew > > > > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > ___ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP event loop modification proposal (due to new platforms like Android, iOS, Mac)
On 1/13/17, Eric Wing wrote:
> On 1/13/17, John Spikowski wrote:
>> I think any major directional changes should include a web IUP as a
>> consideration. IMHO
>
> I think this is a really interesting idea and I would love to include
> this. I've done a tiny bit with Emscripten/asm.js, but I am no means
> an expert. I am also not a web person so I don't have the domain
> specific knowledge on what a backend should look like.
>
> At a very high level, I think it should work like the following:
>
> (1) You should be able to take your C based IUP application, and
> compile it through Emscripten. Emscripten/IUP should have some kind of
> implementation for all the library calls (I'm guessing implemented in
> JavaScript for the web browser, though maybe it is CSS/HTML?). The
> final output Emscripten generates is a web site (with all the C
> converted to JavaScript), which is your original program now working
> in the web browser.
>
> (2) Emscripten/IUP should be able to output just a JavaScript/web
> module that web application developers can import into their projects.
> They can write new IUP applications completely in JavaScript for the
> web browser and will not have to write any C.
>
>
> (3 bonus) Presumably, other people may want native JavaScript bindings
> (aka non-web, directly to JavaScriptCore, v8, SpiderMonkey, DukTape,
> etc.) to IUP. (If you are confused by this concept, see my JavaScript
> talk from the Lua Workshop 2016
> https://www.youtube.com/watch?v=Xi_eMGO3g-o)
>
> The Emscripten/IUP JavaScript web API should be the same as any direct
> native JavaScript bindings to IUP/C. That way a developer who writes
> an app completely in JavaScript, can easily transplant it between the
> web browser and a native IUP app using the JavaScript bindings.
>
>
> In terms of IUP changes, I don't see it much different than what I'm
> doing now. I do know the existing IUP event loop will be a problem,
> however, I believe my event proposal should fix this one too. Since
> the web works on both desktop and mobile too, I suspect it will just
> be able to leverage what's already there.
>
> But as I said, I currently don't have the expertise in web backends or
> Emscipten to say more than this. So if we can find somebody to step up
> as the expert for this, then that would be great.
>
> Thanks,
> Eric
>
John,
This is an excerpt from SDL 2’s CreateWindow backend for Emscripten.
static int
Emscripten_CreateWindow(_THIS, SDL_Window * window)
{
SDL_WindowData *wdata;
double scaled_w, scaled_h;
double css_w, css_h;
/* Allocate window internal data */
wdata = (SDL_WindowData *) SDL_calloc(1, sizeof(SDL_WindowData));
if (wdata == NULL) {
return SDL_OutOfMemory();
}
if (window->flags & SDL_WINDOW_ALLOW_HIGHDPI) {
wdata->pixel_ratio = emscripten_get_device_pixel_ratio();
} else {
wdata->pixel_ratio = 1.0f;
}
scaled_w = SDL_floor(window->w * wdata->pixel_ratio);
scaled_h = SDL_floor(window->h * wdata->pixel_ratio);
emscripten_set_canvas_size(scaled_w, scaled_h);
emscripten_get_element_css_size(NULL, &css_w, &css_h);
…
So, the major thing to note is the emscripten_ prefixed functions.
Emscripten does provide an API for C to do basic web browser things.
https://kripken.github.io/emscripten-site/docs/api_reference/emscripten.h.html
I do not know if there are enough API functions exposed to implement
complete coverage for IUP's APIs. Emscripten was driven mostly for
porting games which doesn't need a lot from browser UI. For example, I
couldn’t find anything named ‘button’. But I’m not a web dev, so maybe
its called something else. If there is enough to provide full
coverage, then implementing an Enscripten/IUP backend should be pretty
straight forward. It will just writing in C and filling in the right C
APIs to call.
If there is not enough, it looks like there are two approaches to fill
in the holes:
https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#interacting-with-code-call-javascript-from-native
1) Execute JavaScript from C
Example:
emscripten_run_script("alert('hi')");
Though, they seem to recommend this macro syntax as faster/better:
EM_ASM(
alert('hello world!');
throw 'all done';
);
2) Implement your own C API functions for Emscripten in JavaScript
// In C
extern void my_js(void);
int main() {
my_js();
return 1;
}
// In JavaScript
my_js: function() {
alert('hi');
},
=
So the final piece of the puzzle is function pointers and crossing
back from JavaScript into C.
So as an example, if we create a JavaScript button, presumably, there
is a JavaScript callback function event. We want to be able to invoke
a C function from this callback.
So to make a C function callable by JavaScript:
// In C
int int_sqrt(int x) {
return sqrt(x);
}
// In JavaScript
int_sqrt = Module.cwrap('int_sqrt', 'number', ['number'])
There may be a bu
