On 1/8/17, Andrew Robinson <arobinso...@cox.net> 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 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. I worked on two commercial SDKs with users shipping their apps for both desktop and mobile, which disproves this statement. It depends on the app, but there are plenty of apps can work on both desktop and mobile. Yours may not work on mobile, but that doesn’t mean everybody else’s can’t. > That means you would need > multiple > GUIs yet only use only one IupMainLoop. I smell another kludge in the > making > with that one. > If you need or want multiple GUI layouts (and I do emphasize *if*, because it isn’t *always* the case), go back and read the original white papers on IUP: this is what LED was designed to handle. Quote: “and customization for different users and platforms” They envisioned even among the desktops, you may need or want different specialized layouts driven by the same code base. > 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. > Yes it does. That’s what all the different boxes can help you do, like hbox, vbox, and gridbox, with features like the EXPAND attribute. Even without mobile, polished desktop apps should consider users who want to resize their windows. Mobile can leverage this because thinking of it as an analogy to the desktop, this is simply having 2 different fixed sized window dimensions you need to handle. If you’ve already programmed the desktop to handle the continuous spectrum of window sizes, then mobile will just work automatically as a subset. Maybe I also need to point out, that both iOS and Android allow you to limit your app to only certain orientations, (e.g. only landscape). It isn't always the best idea. But it's just like not allowing users to resize the window on desktop: again, not always the best idea. But the option is available for the developer. So if you don't allow resizing on desktop, you can also disable it on mobile. You do remind me that there are cases on mobile where the user interface is completely replaced on orientation change, such as Cover Flow mode in the music app when going to landscape. This is an interesting question as to whether IUP existing RESIZE_CB can used to handle this. I actually don’t know the answer for that at the moment. However, this problem isn’t unique to mobile. There are some desktop apps that will completely transform their window contents at certain window sizes. I’m having trouble thinking of an app that you would know, but as an approximate example, Mac iTunes used to have various modes where it is the normal large window with a table of all your music, a tiny window mode where you just see the play buttons and the current song, and a fullscreen visualizer mode. But total UI transformation on different window sizes is an advanced case. It’s not on my immediate to-solve list. I think standard resizing is useful for the majority of apps and will work today within IUP’s current design and feature set. If you need or want multiple GUI layouts (and I do emphasize *if*, because it isn’t *always* the case), go back and read the original white papers on IUP: this is what LED was designed to handle. Quote: “customization for different users and platforms” They envisioned even among the desktops, you may need or want different specialized layouts driven by the same code base. > 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. > 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. And also I said, IUP users only talk to the public C interface as they do now. They will use C strings as they do now, which means NULL termination for strings. IUP users will never even know that Obj-C has a second define for 0 called nil because they are still using plain old C. I think you are showing a misunderstanding of how backends work too. Obj-C is just an implementation detail. You are also bringing in concepts of optionals and unwrapping, which are Swift language concepts which I’m not even using in the backend. Again, even if I was, this is totally irrelevant to IUP users because they continue writing code exactly as they do now. There is no define for nil in C. There is no optionals and unwrapping in C (or Obj-C for that matter). The IUP backend is just an implementation detail and these specific things will never be known to the IUP user. I could theoretically write the backend in Obj-C, Swift, or even pure C CoreFoundation (for strings) and none of these things you listed would make any difference to IUP users. And this isn’t just about iOS. This is also about Mac, which means you are implying that a Mac version for IUP should be rejected (which you also imply at the beginning of this message about only wanting "Windows and Linux"). For people who understand backends, and from the vast number of cross-platform libraries that support do Mac, it is pretty clear that this alleged problem doesn't actually exist. 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
