|
|
|
Home » Developing U++ » U++ Developers corner » Rainbow, first iteration
( ) 1 Vote
|
|
| Re: Rainbow, first iteration [message #33242 is a reply to message #33238] |
Tue, 19 July 2011 22:28   |
|
|
| kohait00 wrote on Tue, 19 July 2011 09:01 |
@unodogs: i am unable to find out what difference there is in PaintGl using WinGl and Paint using WinGl..the first compiles and runs, the latter compiles but crashes..
is there anything special about PaintGl? in theory, we should be able to enhance whichever application by more graphical backends. that's why i felt bold enough to try to use Paint with WinGl as well. any help here?
|
PaintGl was simply a test application for WinGl backend. I will remove it soon. Could you pull the latest sources and tell me if it still crashes (and where)? I cannot reproduce it..
Ok I know what is your problem. Please copy tahoma.fnt and tahoma.png files from PaintGl to Paint folder.. (later basic fonts will be automatically linked or generated on the fly)
[Updated on: Tue, 19 July 2011 22:31] Report message to a moderator |
|
|
|
| Re: Rainbow, first iteration [message #33245 is a reply to message #33236] |
Wed, 20 July 2011 06:17 |
 |
daveremba
Messages: 32
Registered: June 2011
Location: Los Angeles, CA, USA
|
Member |
|
|
Are there more font capabilities needed beyond
the choices in the layout editor?
| Quote: |
Not sure about OpenGL. I guess it should not be THAT hard to implement DrawText, DrawRect and DrawImage in Quartz2D...
Besides, the main problem is DrawText and font management - and there is no support for them in OpenGL.
|
There are some font support libraries for OpenGL:
basic support in GLUT, some newer libraries for the
gamers, and an older one for FreeType:
http://oglft.sourceforge.net/
--
I'm continuing to look also at Qt, wx, and Firefox.
They solve the problem of late-binding in Objective-C
and avoid the NIB file (static layout).
If anyone is curious, here is a link to an Apple man page explaining Cocoa
as it relates to the OS architecure.
As far as mixing Cocoa and C++ that is certainly do-able,
even from UPP theide by adding some options to gcc:
gcc main.m cocoa_test1AppDelegate.m -framework Foundation -framework Cocoa -o test
Cocoa apps also want to be wrapped in a folder called a
"bundle" with an info.plist XML file that defines it to
be an "app" to MacOSX. Xcode makes one when apps are built,
and bundle could also be built as a post-processing step in theide.
--
Lastly, what is chameleon? Theme-related? For example,
how does one change the background or default color of controls
in the layout?
Dave
[Updated on: Wed, 20 July 2011 06:33] Report message to a moderator |
|
|
|
| Re: Rainbow, first iteration [message #33246 is a reply to message #33245] |
Wed, 20 July 2011 07:13 |
 |
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
| daveremba wrote on Wed, 20 July 2011 00:17 |
Are there more font capabilities needed beyond
the choices in the layout editor?
|
Yes.
Check Font class in Draw.
We need the complete metrics of glyphs, capability of render unicode, the list of all fonts, and to identify 3 basic fonts (serif, sans-serif, monospace).
| Quote: |
I'm continuing to look also at Qt, wx, and Firefox.
They solve the problem of late-binding in Objective-C
and avoid the NIB file (static layout).
|
Excelent.
| Quote: |
gcc main.m cocoa_test1AppDelegate.m -framework Foundation -framework Cocoa -o test
|
I suspect that "-framework" is link step option, correct?
| Quote: |
Cocoa apps also want to be wrapped in a folder called a
"bundle" with an info.plist XML file that defines it to
be an "app" to MacOSX. Xcode makes one when apps are built,
and bundle could also be built as a post-processing step in theide.
|
My bet is there will be some commandline way to make the bundle. Plus we will have to get theide to generate the .xml (perhaps replacing only the name of application).
| Quote: |
Lastly, what is chameleon? Theme-related? For example,
how does one change the background or default color of controls
in the layout?
|
Yes, it is skinning system. It is not so much about skinning individial widgets, but the whole GUI.
There is simple example covering basics:
http://www.ultimatepp.org/reference$Chameleon$en-us.html
(well, in this case, individual widgets are skinned, but that is not the common use).
Mirek
|
|
|
|
|
|
| Re: Rainbow, first iteration [message #33249 is a reply to message #33248] |
Wed, 20 July 2011 10:48 |
|
|
| kohait00 wrote on Wed, 20 July 2011 04:28 |
@unodogs:
| Quote: |
copy tahoma.fnt and tahoma.png files from PaintGl to Paint
|
is it possible to move the fonts somehow in WinGl to relief the user from that?
|
First I wanted to embed fonts in WinGl package using brc files. Unfortunately brc files cannot be properly linked in 64b mode. So for now I'll just use iml file to store font's texture and String variable to store font definition. I don't like it (it hard to replace and edit) but I don't see other solution right now. Like I said in one of my previous posts I want to use qt's technique to generate font definition on the fly, but I need some time to do that.
|
|
|
|
|
|
|
|
|
|
| Re: Rainbow, first iteration [message #33261 is a reply to message #33246] |
Thu, 21 July 2011 00:37 |
|
daveremba
Messages: 32
Registered: June 2011
Location: Los Angeles, CA, USA
|
Member |
|
|
gcc main.m cocoa_test1AppDelegate.m -framework Foundation -framework Cocoa -o test
| mirek wrote on Tue, 19 July 2011 22:13 |
I suspect that "-framework" is link step option, correct
|
Yes:-framework name[,suffix]
"This option tells the linker to search for `name.framework/name' the framework search path."
...
The default framework search path is /Library/Frameworks then /System/Library/Frameworks | mirek wrote on Tue, 19 July 2011 22:13 |
My bet is there will be some commandline way to make the bundle. Plus we will have to get theide to generate the .xml (perhaps replacing only the name of application).
|
It isn't too complex and there is documentation.
I made a bundle of the X11 version of theide, it works
the same except that a terminal shell window is not
created (same as a "subsystem: windows" app).
--
| mirek wrote on Tue, 19 July 2011 22:13 |
We need the complete metrics of glyphs, capability of render unicode, the list of all fonts, and to identify 3 basic fonts (serif, sans-serif, monospace).
|
about "render unicode" ...
I didn't see UTF-16/unicode support in UPP. Is that
something planned to be added?
Dave
[Updated on: Thu, 21 July 2011 01:45] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Rainbow, first iteration [message #33271 is a reply to message #33270] |
Thu, 21 July 2011 18:48 |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
not neccessarily..
Font.cpp
InitStdFont() needs a restructuring, because, currently, win fonts are know, and can SyncStdFont, while i.e. X11 also does the
Font::SetStdFont(ScreenSans(12)); trick but later in init, which calls SyncStdFont as well. so it's kinda messy..
so best thing is to make InitStdFont or sth also backend dependant..
[Updated on: Thu, 21 July 2011 18:49] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Rainbow, first iteration [message #33282 is a reply to message #33280] |
Fri, 22 July 2011 14:17 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
@mirek:
I am experimenting with a ImageBuffer hack (including Buffer<>) to pass the fb surface directly as underlaying for Ctrl::framebuffer. the speed improvements for win/linux, fb0/SDL are considerable. especially in terms of responsiveness of the input handling.
while video handling under pc systems wont see much advantage, direct handling in embedded will really profit.
maybe we should really think about making upp directly drawable on fb surface, and making double buffering optional..
i will provide a patch to test it for your self. it is really quick.
@cbpporter: consider using WinAlt, in comparison with Skeleton, to see what exactly is needed. framebuffer is really a good choice as well, if irrlicht can offer a direct surface to draw to..fb based would not profit from optimized draw operations of irrlich though. see progress of MacOS port..it's getting exciting  imagine upp running on all the backends..this is a huge advantage.
EDIT: the attached patch is a quick hack to enable the usage of a n arbitrary memory chunk under ImageBuffer. Buffer<> is extended with a ctor and ability to hold not owned memory. ImageBuffer is extended to be constructable from a supplied Buffer<RGBA> plus Size, Ctrl::framebuffer is made public, so it's Buffer can be replaced.
while Linux/SDL somewhat does not show improvements, win/SDL are really responsive. LinuxFb heavily profits from the speed. again, my vote is for making this possible, so upp can run on at least some embeddeds (we would love to use it in our company in such way)
[Updated on: Fri, 22 July 2011 15:48] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Tue Apr 29 11:11:39 CEST 2025
Total time taken to generate the page: 0.01435 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
