Andrew, I want to try to address your concerns, so I will go point by point inline.
On 1/4/17, Andrew Robinson <arobinso...@cox.net> 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 sensible default experience on all platforms even if you don’t explicitly opt into the platform specific attributes. Also, there is nothing that forces you to port a desktop app to mobile. If you only care about Linux and Windows, there is nothing forcing you to compile and ship a Mac, iOS, or Android version. > 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. - For orientation change, I’m thinking we can leverage the RESIZE_CB on Dialogs. A resize on desktop also requires IUP to recompute the layout so there is no difference here. The analogy to think about is on desktop, consider a window that is 640x480 gets resized to 480x640. Layout must be recomputed by IUP for this case, already for the desktop. This is no different for mobile for this case. (There is a caveat that thanks to some thoughtless Android device manufacturers, the portrait and landscape dimensions on some devices are not the same because they drew different sized title or navigation bars in the different orientations. This turns out to be another good reason why “resize” actually works out pretty well for orientation changes. We learned about this the hard way at Corona, I think when Android first introduced tablets and some vendor rushed a product out the door, with unnecessary and stupid changes.) > I even have to rescale text > at > times. - Rescaling text: We’re talking about native GUIs here. I can’t think of any native platform GUI that automatically resizes text on a window resize. That has to be something you as an app developer are doing manually and explicitly decided to do. In which case, this will continue doing exactly the same on mobile. So if you change the text size on desktop going from 640x480 to 480x640, then the same will happen on mobile. > And what about iOS API quirks, like their use of nil vs null? - iOS (and Mac) nil vs NULL: This won’t affect IUP in any way. I’m not sure why you think it would. I’m not changing any of the IUP public APIs or turning the language into Objective-C . All the iOS and Mac implementations are behind the scenes implementation details which means all the Objective-C will never be seen by you, just like you should never see the Windows backend and if it used newer Vista APIs how it uses C++ instead of C, or WinRT/UWP and how it would require C++CX, or how Android requires Java. To you, all of this is just IUP as it is now, a simple library with a C interface. Also, nil and NULL are both defined as 0 in Objective-C and C so there is no difference. Using nil is just a convention in Obj-C to represent a semantic to programmers, like how NULL is used in C. But at the end of the day, they both are just 0. > 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). - The link you provided has nothing to do with Android application development. That talk is about if you are a device manufacturer and want to port Android to a new device (e.g. toaster, refrigerator). That’s how you get started doing so. Yes, Android uses the Linux kernel. However that means squat when it comes to building actual applications for Android. The kernel is essentially an implementation detail of Android and as an application programmer, Google considers it a hidden implementation detail. They could swap it for a BSD kernel and Android apps wouldn’t notice because Android apps must be written at such a high level. Furthermore, in terms of IUP, all its “Linux” GUI is userland above the kernel. We’re talking about Motif and GTK which technically isn’t Linux (since it runs on other platforms like FreeBSD). But the main point is that none of this stuff exists on Android. It sounds like you didn’t watch my video presentation(s) about how Android development works. I recommend watching that to understand how an Android app works. https://youtu.be/UvrEfOg3Nyk And if you want to know more about the NDK and how things like Bionic suck, also watch this other video I presented at the Lua Workshop this year. https://youtu.be/37m_PxWoAqI > 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. > - Windows-like phone. That was WinRT/WinUWP, but that’s going nowhere. Still, I’m sure Microsoft would love it if IUP had a WinRT backend. And be warned, many of my proposals also are also necessary to support WinRT. - Linux-like phone: Tizen, Ubuntu Phone. These also went nowhere. But, I think both got a special variation of Qt. So if somebody implemented a Qt backend for IUP, that might get you closer. But the rest of consumers didn’t buy these phones. > I have > programmed for iOS and Windows and I am sticking to Swift and Xcode for iOS > because they are made for each other. > - You mentioned Swift. I thought I should mention that one of my end goals is to allow people to write cross-platform IUP apps in Swift for ALL platforms (not just Apple platforms). I already have Swift working in a cross-platform way on Mac, iOS, Linux (Steam-Runtime/SteamOS), Raspberry Pi (Raspbian), and Android. I also have a very crude Windows version working. Again, this goes back to the intelligent design of IUP. Its API was designed to accommodate language bindings. So you are always free to continue writing a separate, dedicated iOS or Mac version of your app in Swift; more power to you. But I want to give people the option to write a single cross-platform app in IUP for all the platforms, in Swift (and also C, Lua, JavaScript, or any other language). "Workflow": Cross-platform Dev in Swift https://www.youtube.com/watch?v=w8ftI9mpGdY "Workflow" in Swift: The Android Addendum https://www.youtube.com/watch?v=w6FY_qSi8yY ------------------------------------------------------------------------------ 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
