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: 14290
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: 1319
Registered: March 2007
|
Ultimate 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: 14290
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: 1319
Registered: March 2007
|
Ultimate 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Ideas and priorities for the next development cycle [message #38433 is a reply to message #38190] |
Sat, 15 December 2012 16:50 |
nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
|
Contributor |
|
|
The above post worked OK for basics. When a Find-Replace in addition to the Find was opened there were problems.
Instead comment these lines
C:\upp\uppsrc\CodeEditor\CodeEditor.cpp(261):
C:\upp\uppsrc\CodeEditor\FindReplace.cpp(252):
C:\upp\uppsrc\RichEdit\Cursor.cpp(94):
C:\upp\uppsrc\RichEdit\Cursor.cpp(328):
C:\upp\uppsrc\RichEdit\Cursor.cpp(347):
C:\upp\uppsrc\RichEdit\Find.cpp(113):
I have not run into any problems yet.
edit: If the find box was not always on top and didn't jump to the bottom center it would be better, at least for some.
[Updated on: Sat, 15 December 2012 17:07] Report message to a moderator |
|
|
|
| Re: Ideas and priorities for the next development cycle [message #38435 is a reply to message #38433] |
Sat, 15 December 2012 17:23 |
Didier
Messages: 740
Registered: November 2008
Location: France
|
Contributor |
|
|
Hi all,
I have a very simple request/idea about the way you can use the help in theIde.
When editing some code, you can easily jump to the library source code, but when in the lib source all you can get is the help about a certain function OR edit the help for that lib (which is not what you want most of the time).
Idea:
When clicking on the 'blue square' a popup menu should appear. It would propose 2 options:
* edit the help
* view the help topic (and thus open the help viewer on the dedicated topic )
[Updated on: Sat, 15 December 2012 17:25] Report message to a moderator |
|
|
|
|
|
| Re: Ideas and priorities for the next development cycle [message #38470 is a reply to message #36984] |
Wed, 19 December 2012 15:47 |
lectus
Messages: 329
Registered: September 2006
Location: Brazil
|
Senior Member |
|
|
Android support is a must have, because it's the fastest growing mobile platform.
I believe with NDK you can use C++.
I think Mac OS X is also good to have, because it's part of the 3 big Desktop platforms: Windows, Linux and Mac OS X.
U++ is already full-featured as it is. It needs to concentrate on running on more platforms now (Skylark was a huge step in my opinion because web apps run everywhere if a browser is available).
[Updated on: Wed, 19 December 2012 15:52] Report message to a moderator |
|
|
|
|
|
Goto Forum:
Current Time: Sun Apr 26 01:53:38 GMT+2 2026
Total time taken to generate the page: 0.01488 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
