Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Ideas and priorities for the next development cycle
Ideas and priorities for the next development cycle [message #36984] Sat, 04 August 2012 11:13 Go to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Hi everybody,

with Skylark being finialized (just a couple of documentation topics missing now), I would like to start a debate about things to be done next (and estimates in [d]ays/[w]eeks/[m]onth).

My favorite topics:

Platforms

- "rainbowization" of Font metrics (looks like there will be more options in the future than Win32 and fontconfig)
- MacOSX support (with fudadmin excellent contribution, it should now be relatively easy) 2m
- iOS support (well, I am not much into it, but having MacOSX, it perhaps could be easy) 2m
- Android support 4m
- Create U++ rainbow version using Qt as host API (in the same matter as we are using e.g. X11). This one in fact would make U++ apps to run on many many platforms. 2m
- Create U++ rainbow version using Gtk as host API. This would have the advantage of better integration of U++ with Linux, e.g. we should be able to use Gtk standard dialog. 2m
- WinRT?

IDE

- speedup of IDE startup and operations (got quite slow recently because we have now a lot more documentation) 2w
- new set of icons 1w
- finally adding Docking capability 1m
- improving Assist++ (add some heuristic support of macros) 2m

Feel free to add more suggestions.

Also note this previous thread:

http://www.ultimatepp.org/forum/index.php?t=msg&th=6289& amp;start=0&

I guess some of topics should be brought back..

Mirek
Re: Ideas and priorities for the next development cycle [message #36986 is a reply to message #36984] Sat, 04 August 2012 21:28 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Mirek, if you need it, I'll try to contribute icons for U++ IDE. Please contact me on details if you wish to.
Re: Ideas and priorities for the next development cycle [message #36999 is a reply to message #36986] Mon, 06 August 2012 23:30 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
A great small improvement on qtf... ability to have image/objects anchored to pages and text flowing over/around them.
It's the only thing I miss on it.

Max
Re: Ideas and priorities for the next development cycle [message #37176 is a reply to message #36984] Mon, 03 September 2012 18:26 Go to previous messageGo to next message
lectus is currently offline  lectus
Messages: 329
Registered: September 2006
Location: Brazil
Senior Member
Android support is a must have.

This platform is growing too quickly to be ignored.
Re: Ideas and priorities for the next development cycle [message #37177 is a reply to message #37176] Mon, 03 September 2012 19:19 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
lectus wrote on Mon, 03 September 2012 12:26

Android support is a must have.

This platform is growing too quickly to be ignored.


I agree, unfortunately I have some capacity limits... Smile

Surely, with Rainbow, it should be easy for somebody else to develop Android support...

An alternative and perhaps promising way is to simply use Qt as rainbow backend (same way we are using e.g. Win32) and let it handle platform specific issues. Also note that this is not mutually exclusive Smile

Mirek
Re: Ideas and priorities for the next development cycle [message #37185 is a reply to message #37177] Tue, 04 September 2012 10:28 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
@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
Re: Ideas and priorities for the next development cycle [message #37190 is a reply to message #37185] Tue, 04 September 2012 13:19 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 Smile
Re: Ideas and priorities for the next development cycle [message #37193 is a reply to message #37190] Tue, 04 September 2012 15:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Recommended reading:

https://groups.google.com/forum/?fromgroups=#!topic/wx-dev/Y GcUkAjE5Es
Re: Ideas and priorities for the next development cycle [message #37197 is a reply to message #37193] Tue, 04 September 2012 21:59 Go to previous messageGo to next message
Tom1
Messages: 1212
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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 Go to previous messageGo to next message
kohait00 is currently offline  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 #37230 is a reply to message #37206] Fri, 07 September 2012 21:08 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

I think it is good idea to avoid using CtrlCore/CtrlLib as something general enough to support different GUI paradigms such as desktop vs Android.

I think we do not need compatibility between classic and new (android-like also with iOS) interfaces. So we have to create different levels of abstraction for new interfaces above Rainbow (which is simply crossplatform GUI drawing interface, if I understand right). Going that way, we may create different GUI class hierarchy which supports tablet-like interfaces which require different controls, different events, different ideology.
Re: Ideas and priorities for the next development cycle [message #37234 is a reply to message #37230] Sat, 08 September 2012 17:26 Go to previous messageGo to next message
Tom1
Messages: 1212
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
Re: Ideas and priorities for the next development cycle [message #37235 is a reply to message #37234] Sun, 09 September 2012 09:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
One more thing about Android:

I am pretty sure that Firefox for Android is a C++ application.

More importantly, I am quite sure that Chrome is also C++.

Means it should be possible after all to achieve at least that level of integration... (But perhaps somebody more familiar with Android sources should check this...)

Mirek
Re: Ideas and priorities for the next development cycle [message #37236 is a reply to message #37234] Mon, 10 September 2012 02:03 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
Tom1 wrote on Sat, 08 September 2012 08:26


I'm personally not a great fan of touch interfaces, ...



Same here! A small wireless mouse is what I prefer.

Porting between Python-Java-C++ is fairly easy once a person gets used to it.


Porting U++ to work with the Android OS shouldn't be that much of a problem if taken a step at a time.
Re: Ideas and priorities for the next development cycle [message #37237 is a reply to message #37234] Mon, 10 September 2012 08:45 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
[qoute]
I'm personally not a great fan of touch interfaces
[/quote]

they are probably not as precise enough Smile as we are with the mouse.
nonetheless, touch interfaces will be the new holy grail for the next probably 5 to ten years at least (if they ever vanish at all)..so it's good to have the upp portability and ease of use in that area too..

we really might think of a new TouchCore and derived controls, to generate a whole set of ne controls. i think many developpers would prefer them in embedded systems to the current desktop like look, for a simplicity and information focused reason.

EDIT: mozilla sources

https://wiki.mozilla.org/Mobile/Fennec/Android

[Updated on: Mon, 10 September 2012 10:18]

Report message to a moderator

Re: Ideas and priorities for the next development cycle [message #37239 is a reply to message #36984] Mon, 10 September 2012 18:40 Go to previous messageGo to next message
drjo1952 is currently offline  drjo1952
Messages: 7
Registered: December 2008
Location: Tucson, AZ
Promising Member
Mirek,

Ultimate++ is always my first 'go-to' tool in creating new tools for our lab work and for our clients. My usual approach in solving new coding chores is to try out Examples or Bazaar using code that has some possible code snippets that could be used. For example, I need to tie audio and video feedback elements in my current project; so I first tried the few media examples in bazaar. I am currently using Ubuntu 12.04 and first tried the SDL example (SDLCtrl_demo); I could only get this example to work by downloading the SDL project tarball and ./configure, make, and make install - there were missing header files otherwise. The MediaPlayer (bazaar/Media) example however does not work because of this: libavutil/colorspace.h not found. This raises a fundamental issue of testing - should we perhaps have a formal suite of examples that are automatically exercised in Ubuntu and Windows (at least) to correct configuration and missing libraries? I think Ultimate++ is a first-class tool and I don't want newbies becoming tainted by examples not working. I am not an expert in the internal ultimate++ build mechanics to pull this (automatic test suite) off by myself without some guidance but I believe we could garner significant benefits by the effort. I would like to vote for an automatic testing program as a critical next-step activity.

drjo1952
Re: Ideas and priorities for the next development cycle [message #37240 is a reply to message #37239] Mon, 10 September 2012 18:52 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
drjo1952 wrote on Mon, 10 September 2012 12:40

Mirek,

I would like to vote for an automatic testing program as a critical next-step activity.

drjo1952


Buildbot is good for both automated building and testing.


Regards,
Novo
Re: Ideas and priorities for the next development cycle [message #37241 is a reply to message #37240] Mon, 10 September 2012 19:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Mon, 10 September 2012 12:52

drjo1952 wrote on Mon, 10 September 2012 12:40

Mirek,

I would like to vote for an automatic testing program as a critical next-step activity.

drjo1952


Buildbot is good for both automated building and testing.


uppsrc/BuildAll builds all of reference and examples..

Original intention was to run it before each release Smile

I agree that some automated testing system would be nice. In fact, I guess this is where dolik's experimental website might be useful Smile
Re: Ideas and priorities for the next development cycle [message #37256 is a reply to message #37241] Wed, 12 September 2012 15:13 Go to previous messageGo to previous message
drjo1952 is currently offline  drjo1952
Messages: 7
Registered: December 2008
Location: Tucson, AZ
Promising Member
Mirek,

I have tangentially been following Dolik's universal makefile concepts - My suggestion is a simple holistic question about actually doing testing suites now with the tools at hand! I will take you suggestions of buildroot and your BuildAll as a starting point to push the effort along. Does BuildAll also build the bazaar examples as well? This raises another important question that was in the background with my original proposal? Is bazaar supposed to be a working reference point for Ultimate++; ie. should our Ultimate++ community take the responsibility for insuring that all the examples in bazaar work? If so, this implies that we are choosing which tangential applications and libraries Ultimate will integrate with; a choice that should not be taken likely. I understand that this is implying a commitment for contributors to keep bazaar examples up to date if they choose to put their code there. Perhaps we need two bazaars, one for 'supported code' and one for experimental code. The supported bazaar would then come under our test suites and we would fix or otherwise address (perhaps remove) issues found with testing.

drjo1952
Previous Topic: Fixing translations
Next Topic: File Operation
Goto Forum:
  


Current Time: Thu Mar 28 21:32:56 CET 2024

Total time taken to generate the page: 0.01133 seconds