On 1/3/17, Antonio Scuri <antonio.sc...@gmail.com> wrote: > Hi Eric, > > Excellent video. Thanks for sharing with US. Also thanks for putting so > much work on this. > > I have a few questionings. > > IUP for Cocoa is a safe ground. It can be used for Desktop applications > although we can extend to iOS. > > Desktop applications are our priority and I really would like to see this > fully working. Existing applications can really benefit from a MacOS driver > for IUP. I would suggest you to focus on this one, because the contribution > will be huge!!! We can even attract more users to IUP. > > On the other hand... do you think that mobile developers can take a > benefit from an IUP port? I see that you had to make lots for workarounds > to make it work. I don't think existing application would benefit, so maybe > we are talking just about new applications when comes to mobile. Then why > to use IUP and not another API that was originally developed for mobile? > > Also, I see a lot of work ahead maintaining the Android code. I didn't > know that was all Java based. What a mess... "Why do do something new > simpler if we can get it even more complicated..." > > Anyway just a few thoughts to get started. > > Best, > Scuri > >
So, I am based in Silicon Valley, so my vantage point of the world is probably quite different than what you see. The majority of application developers I meet today are focused on mobile development. iOS and Android are both important. iOS is important because iOS users tend to be early adopters, love great products, and are willing to pay actual money for things. Android is important just for the sheer numbers of users. And desktop app development has become mostly an afterthought or a legacy maintenance position. As you saw, Android development is so hard in general, that cross-platform iOS/Android is really hard to do. Android being based around Java complicates things because it is (ironically) so unportable. Cross-platform code bases still depend on C and C++, but new developers do not want to use these languages. The 90’s era languages from Java, JavaScript, Python, Ruby, to C# have thick runtimes and use garbage collectors which come with serious drawbacks for mobile development which is RAM constrained and battery focused. So, the industry is hurting for a really good cross-platform GUI solution for iOS and Android and future mobile devices (IoT). I think the Raspberry Pi is an interesting stand-in device for IoT because it shows a direction where devices are getting even more constrained and extremely inexpensive. Xamarin gets a lot of mention, but it is a very heavyweight solution and porting C# to new platforms is really hard. And making it run well for non-trivial apps is challenging due to the limited RAM on mobile devices. And Xamarin is actually hands-off when it comes to cross-platform GUIs and requires you to implement each platform separately (except for the new limited forms stuff they recently introduced). React and React Native have gotten a lot of buzz recently, however it is built around JavaScript. I’ve been there and done that with Appcelerator. (See my Lua Workshop 2016: A Lua embedder thrown into the JavaScript world https://www.youtube.com/watch?v=Xi_eMGO3g-o). JavaScript has a lot of its own drawbacks. One of the reasons I make a big deal about being on the main UI thread on Android is because Appcelerator originally was not when I was there which created a massive performance problem and design problem for us as we tried to build a high performance game engine for them. Eventually we convinced that this was a terrible idea and they changed it for Ti-Next. Ironically, the React people are touting being on a background thread as a good thing again. As I said, been there, done that. And Qt, on top of it being C++ (which I explain some of the harder systems pitfalls of in my JavaScript talk), it is massively bloated and complicated. 60 megs on disk for a hello world app and nearly 10 seconds to launch on my Mac, and maybe around 100 MB of RAM. 13 hours to build on a Raspberry Pi 2 and (at least at the time) couldn’t create more than one window because it was using OpenGL which was the reminder of the fact that it isn’t even a native GUI. (And if that wasn’t problem, the RAM consumption would be next.) Anyway, thanks to the next generation languages like Go, Rust, and Swift, there is a renewed interest in C libraries, because all 3 of these languages recognized how useful the C ABI is and how important leveraging existing useful libraries is. Since GUI is not solved, and there really aren’t any good solutions in C, IUP is sitting in a great position. The majority of frameworks are massive kitchen-sink solutions which come with file systems, networks, and tons of non-GUI stuff. Say with Swift, none of that is needed because Foundation (kind of the big standard library for Swift) comes with all that. On Mac, we use Foundation+AppKit. On iOS we use Foundation+UIKit. For cross-platform, Foundation+IUP could be a perfect solution. So back to the app development world as I see it, mobile is the focus, with a web app as a fallback for the desktop. This angers me as a user. A couple of examples: My banking app for mobile has a nice feature…it allows me to cash checks by taking a picture with my device’s camera. But I’d much rather do this on my desktop where I have all my bookkeeping software and a wired ethernet connection. (And every Mac has a built-in camera.) This app is simple: a couple of full screen dialogs. They already have a iOS app version. The Mac version would be very similar. Yet, they don’t provide a Mac app. Instead, I have to use their crummy web interface which lacks camera support, thus I can’t cash checks. It’s pathetic they don’t have a Mac app counterpart. I was forced to use Google Hangouts for conference calls a few years ago. They actually made a pretty decent iOS app. But this was for work related stuff, so it made more sense for me to use a laptop. But they didn’t make a native desktop app. On Mac, I was forced to install, as Administrator, a plugin for Google Hangouts, and then use it through my web browser. (I generally never grant anything on my systems to be installed as Administrator so I was angry about this.) Then the web browser plugin was so awful, it drained my fully charged laptop battery in about 30 minutes. I had to stop using it because I couldn’t make it through the meetings. Instead, I had to get an iPad and sit next to it with my laptop. If I needed to share my laptop screen, I could try pointing the iPad’s camera at it (though it usually this worked poorly so I gave up). I had a similar experience with Twitch. They had an iOS app, but no Mac app. The web interface required Flash, and I don’t install Flash. (So I don’t use Twitch.) Anyway, my point is that there are a lot of useful apps that don’t demand intricate designs that would be very similar on mobile and desktop. Companies are spending a ton of effort making mobile versions (often separate iOS and Android versions because the cross-platform solutions are terrible). Then they have yet another team that does a lousy web version as a desktop app substitute. This seems ridiculous and unnecessary because a lot of these apps could be solved simply with something like IUP if it had the necessary backends. It won’t solve all apps, but that doesn’t mean IUP for both desktop and mobile wouldn’t still be extremely useful for a lot of apps. Also, with LED, I think people could still solve the more complex apps with greater differences between platforms with relative ease. Reading the original IUP white paper (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.51.6578&rep=rep1&type=pdf), my impression is that this is what LED was intended to really help with by allowing platform specific layouts. Not to mention that IUP itself seems already well designed in that it recognized each platform could be very different. (IUP is the only API I’ve seen that doesn’t use “window” in an API name. Mapping Viewcontrollers and Activities to “Dialog” actually seemed more natural than any other API I’ve seen before.) And yes, it won’t be automatic that an app will just work between platforms without design thought. But I think for the majority of new app developers, they will start on mobile and then expand to desktop (if feasible). I think starting from a mobile design and going to desktop might be simpler than going the other way. But I think even existing legacy apps may be able to refactor without too much difficulty depending on how they were designed in the first place. So if IUP supports both, instead of having to do a complete rewrite, I think that is a huge advantage. (Then there is Microsoft’s WinRT/UWP approach that tries to unify desktop and mobile, though I don’t know anybody who actually cares about UWP. But an IUP that can handle both desktop and mobile should fit right in with UWP.) As for other desktop vs. mobile differences, so far, I actually haven’t had to “make lots for workarounds” to IUP. The focus on Dialog for Activity and NavigationController was all conceptual. It actually didn’t require changes to IUP. The biggest change I need to make for IUP right now is for the event loop, but that isn’t a mobile vs. desktop issue; that is a general platform design issue in that platforms want to control the event loop nowadays. (And I had to make a few changes to a few core IUP files because Android's C library, "Bionic", is a piece of junk. Also see my Lua Workshop/JavaScript talk about that.) There will be other things we will need to address such as suspend/resume, screen orientation, table views, but I feel all of these are compatible with IUP’s design with some thought. (I was the chief architect for the Corona SDK for several years. While initially we only allowed users to develop for iOS+Android only, our device simulator was built for Mac and Windows. While mobile has its differences, the desktop shares many similarities too. Most of the problems we faced had nothing to do with desktop vs. mobile, but usually Windows just sucking on modern features like no built-in camera API to rely on, not being able to draw native widgets on top of OpenGL. The Mac simulator was always better. Though web views sucked on all platforms except iOS. In the end, Corona eventually supported desktop apps. The public API differences were relatively minor; it was mostly a few new APIs for desktop specific things and no-ops when doing mobile specific things. IUP’s Attribute system is already designed this way.) So I agree that the lack of native Mac Cocoa support for IUP has hindered its adoption. I know that is the reason I didn’t use it at first. Instead, I’ve used many other frameworks over the years like wxWidgets, Qt, only to come out frustrated and burned by all of them. Now that I’ve finally used IUP, I see how well thought out its design is and how brilliant it is in so many respects. But the Mac limitation is still a major obstacle for me because I work in developer tools, and most developers I meet nowadays have Macs, because Mac is the only platform that lets you develop for iOS and also can do Android. Hence, this is why I started implementing the Cocoa backend. I mentioned libui before, that new C based cross-platform GUI library. It has already gotten an impressive amount of activity, I think due to its Mac support. Comments I’ve seen about it, there is usually a mention of IUP. Generally people wish there was Mac support for IUP, but without it, they are trying libui. libui incidentally is being written because the author needs something that can be called by Go. However, in terms of activity compared to mobile, I see magnitudes more stuff about iOS+Android, like with React. I have been doing some local talks about adding Cocoa support to IUP. While there has been some interest, most people I come across are more interested in mobile. To them, desktop would be nice…after mobile support. I have been invited to speak at the try! Swift conference this March in Tokyo about Swift on Android. Since they reached out to find somebody for this topic instead of me submitting an application to give a talk, I suspect there is a large audience that wants to hear about cross-platform app development solutions in Swift. Since Foundation is already cross-platform and IBM and others are already developing server-side Swift solutions, this only leaves cross-platform GUI as the remaining hole to fill. I put this prototype together partly because I would like to show a working cross-platform GUI for desktop and mobile in Swift during my talk, hoping to get people interested. As I’ve talked and shown the Mac/Cocoa IUP port and the potential for mobile, I think people will get more excited if they see a running iOS+Android prototype. I actually believe that will attract far more developers than Mac support because there are far more people doing mobile app development these days. (Mac support is necessary to keep developers from skipping past IUP, but not sufficient to attract new developers in the mobile-centric world I see.) Also, I hope speaking to 800 developers who are Cocoa & CocoaTouch experts about IUP might help recruit some help. As for Android’s difficulty, yes, it is a mess. However, because it is so hard, it is valuable. Nobody else wants to do it. Thanks, Eric ------------------------------------------------------------------------------ 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
