|
|
Home » Developing U++ » U++ Developers corner » Ideas and priorities for the next development cycle
|
|
|
|
|
|
Re: Ideas and priorities for the next development cycle [message #37190 is a reply to message #37185] |
Tue, 04 September 2012 13:19 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Tue, 04 September 2012 04:28 | @android support: we should know where we want to go with android?
a) blank canvas with upp typical look and feel (from w32 i.e.), single touch support... should be posible over the NDK
b) android typical appearance in terms of control widgets (way more complicated, implies to properly integrate moultitouch in upp Ctrl.
c) limiting usage of upp to Core stuff, using NDK bridging gap of java to c++. native widgets from android.. not a 'real' integration.. that said: is a 'real' integration possible anyway?
apreciate your ideas..
cheers
|
Well, a and (then) b are "standard approach".
Anyway, I have to say that recently I have started thinking about c) option, which basically is "wxWidget way". Interesting part then is what makes U++ compeling to me and what of that could be preserved when going "native GUI".
IMO, Core is simple and clear, esp. on android.
Anything that can be compiled without CtrlCore is preservable as well - that includes Draw. It should also be relatively easy to integrate Draw with any native GUI.
Of course, CtrlCore would have to go, CtrlLib would have to be replaced by something. The main issue at that point is how to make CtrlLib cross-platform. Another issue is what are important "U++ style" features of CtrlLib and whether they could be preserved. I believe that those factors are important:
- widgets are independent from GUI. I guess this part might be quite hard to achive, but perhaps not impossible. (Just to make this point clear, it for example means that I can take ArrayCtrl, fill in values, THEN add it to dialog, and THEN open the dialog in GUI. Or in fact, I can use ArrayCtrl and never use it in GUI, just to store and retrieve values). Related issue is that widgets are represented by object variables, not pointers to objects.
- frame system; we have no view class, but we have powerfull ScrollBar that can be added as Frame to any Ctrl. Hopefully could be preserved in some form, but most likely not for native views...
- customization using Display/Convert
- layouts, but those are not as important...
Hard to say, perhaps we might try something like that... Maybe even use something like wxWidgets, encapsulate U++ way and let THEM to deal with platform independency
|
|
|
|
Re: Ideas and priorities for the next development cycle [message #37197 is a reply to message #37193] |
Tue, 04 September 2012 21:59 |
Tom1
Messages: 1242 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
While reading the link and your thoughts on platform support, I once again started to wonder where is the world of GUI headed and how U++ is going to cover that. In order to better understand how you see the future of U++ on various platforms (existing and new) I would be very interested to see a platform by platform listing how Draw, CtrlCore and CtrlLib are going to be implemented. I mean, which APIs are going to be used on each platform.
I'm not a great fan of leaning on pre-existing libraries, since this is the highway to bloated software, difficult dependencies and bugs. In my book U++ project has a clean record in interfacing directly to platform APIs and implementing clean and efficient code for any required task. Using external dependencies between native APIs and U++ seems like a diversion from the well established path we have seen so far.
Best regards,
Tom
|
|
|
Re: Ideas and priorities for the next development cycle [message #37205 is a reply to message #37197] |
Wed, 05 September 2012 10:05 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Tue, 04 September 2012 15:59 | Hi Mirek,
While reading the link and your thoughts on platform support, I once again started to wonder where is the world of GUI headed and how U++ is going to cover that. In order to better understand how you see the future of U++ on various platforms (existing and new) I would be very interested to see a platform by platform listing how Draw, CtrlCore and CtrlLib are going to be implemented. I mean, which APIs are going to be used on each platform.
|
Status quo is "bussines as usual" - attempting to take the lovest possible level, using rainbow. Which does not preclude using e.g. gtk instead of plain X11 - in fact, using gtk as platform API would at least had advantage of better integration, e.g. we would be able to use gnome fileselector as an option.
"option c" was, at the moment, just an idea.
That said, supporting two relatively friendly platforms (Win32, Posix/X11) is costly. Supporting 5 (adding MacOSX, iOS, and unfriendly Android) might prove too much...
Mirek
|
|
|
Re: Ideas and priorities for the next development cycle [message #37206 is a reply to message #37205] |
Wed, 05 September 2012 10:49 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
i must agree with mirek.. i kinda think android is too much different to be fully supported in upp. in fact, any of such touch orientated OSs would be, because they impose their entirely new user philosophie (i.e. view stack, back buttons, very context orientated menus, etc..). to comply with this, upp would need a fairly large amount of redesign from buttom up (as far as i can grasp upp as a whole, correct me if i am wrong). and if ever done, wouldn't we criple upp too much with it? touch orientated progs are too different anyway. probably, upp would need to develop a whole new set of controls anyway.
OTOH, there is still a certain appeal in simple, unbloated, single touch orientated gui views (like with resistive touchscreens anyway), just on a very common multitouch platform, that for theese purposes simply hides it's presense (fullscreen view with rainbow)
so as a starter a) is a must anyway. from there on, we can see how far we can get.
what do you think?
|
|
|
|
Re: Ideas and priorities for the next development cycle [message #37234 is a reply to message #37230] |
Sat, 08 September 2012 17:26 |
Tom1
Messages: 1242 Registered: March 2007
|
Senior Contributor |
|
|
Hi Pavel,
I think you've got a point there. However, it would still be beneficial to have the graphics rendering interface (Draw or rather something more advanced) compatible between the classic desktop and touch environments. Anyway, the split to desktop and touch would be something like this.
Desktop:
- Windows
- X11
- OSX
- (Wayland)
Touch:
- Android
- iOS
- Windows Metro
I'm personally not a great fan of touch interfaces, at least not yet, but I guess being prepared is not a bad policy.
Best regards,
Tom
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Sep 20 23:15:36 CEST 2024
Total time taken to generate the page: 0.04019 seconds
|
|
|