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 » Rainbow, first iteration  () 1 Vote
Re: Rainbow, first iteration [message #32995 is a reply to message #32994] Tue, 28 June 2011 13:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
kohait00 wrote on Tue, 28 June 2011 06:39

we actually dont need a common codes set, the backends normally provide them as well. i.e. linux input subsystem...

do you plan to detach the gui backends from CtrlCore completely?



I plan to keep Win32/X11 in CtrlCore. Most apps use just this and it would be 2 packages more in the list. In future, when MacOS and Android are available, I consider moving them there too.

Quote:


i noticed that WinAlt does not use cham. is this planned?



Unlike, WinAlt is only the first "proof of concept", nothing more.

Quote:


generally, from where do you plan to have the final GUI backend selection? from the top ackage like it is now or from the CtrlCore package? i mean where the guiplatform.h is finally situated. it could be 'overridden' in case of special specification. but all provided backends could live at some bottom level, to be selected with a compile flag like WINFB, LINUXFB, MACFB (those that are known and already exist).



I agree with compile flag and will be moving in that direction.

However, guiplatform.h placement is what it is supposed to be. I mean, first guiplatform.h in nest chain gets used. This is to allow everybody to groom his own backand withou fiddling with uppsrc code..

Quote:


this would reliev the user to specify it's own guiplatform, instead he could only take the Framebuffer package and select the backend via compileflag.



Actually, I believe we are heading right there.


BTW: i commited the state of yesterday. what is missing, are the patch0 changes.. i found a mean to convert git patches to tortoise patches. so here it comes again. [/quote]

I have found a problem there: In Image.h, GUI_X11 is not yet defined....

Report message to a moderator

Re: Rainbow, first iteration [message #32996 is a reply to message #32995] Tue, 28 June 2011 13:37 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
GUI_X11 not defined:

Quote:


patch0 has some fixes concerning PLATFORM_X11, which should be GUI_X11 or PLATFORM_POSIX now, please review it. there also arises a slight problem with Image, it still has some code PLATFORM_WIN32 and PLATFORM_X11 dependant. but due to elimination of PLATFORM_X11, which is available from Core level, GUI_X11 is available from CtrlCore level only, Image, which is included by CtrlCore does not know anything from GUI_X11. i dont have any solution for this. maybe the platform dependant stuff should be made a special class, which is implemented platform dependantly.




Smile

Report message to a moderator

Re: Rainbow, first iteration [message #32997 is a reply to message #32996] Tue, 28 June 2011 15:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
kohait00 wrote on Tue, 28 June 2011 07:37

GUI_X11 not defined:

Quote:


patch0 has some fixes concerning PLATFORM_X11, which should be GUI_X11 or PLATFORM_POSIX now, please review it. there also arises a slight problem with Image, it still has some code PLATFORM_WIN32 and PLATFORM_X11 dependant. but due to elimination of PLATFORM_X11, which is available from Core level, GUI_X11 is available from CtrlCore level only, Image, which is included by CtrlCore does not know anything from GUI_X11. i dont have any solution for this. maybe the platform dependant stuff should be made a special class, which is implemented platform dependantly.




Smile


OK, sorry. Will deal with this soon...

Report message to a moderator

Re: Rainbow, first iteration [message #32998 is a reply to message #32997] Wed, 29 June 2011 11:43 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i'm twiddleing a bit with SDL, it should be possible to treat it as Framebuffer backend, right Smile ?

here, we got a problem with GUI_APP_MAIN define in After.h of Framebuffer. in PLATFORM_WIN32 environment, Framebuffer makes FBInit(hInstance). for SDL environment under win32 i need console app stuff Smile

wouldn't it be good to just have an APP_MAIN and the rest via compile flags? as depricated means CONSOLE_APP_MAIN and GUI_APP_MAIN would redirect to APP_MAIN.. it's just an idea. it surely implies a lot more that i dont know of.

EDIT: tried to make APP_MAIN..see patch

the decision is made automatically, via flagGUI. the others redirect to APP_MAIN. i left DLL_APP_MAIN untouched.

[Updated on: Wed, 29 June 2011 14:01]

Report message to a moderator

Re: Rainbow, first iteration [message #33003 is a reply to message #32998] Wed, 29 June 2011 19:11 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 29 June 2011 05:43

i'm twiddleing a bit with SDL, it should be possible to treat it as Framebuffer backend, right Smile ?

here, we got a problem with GUI_APP_MAIN define in After.h of Framebuffer. in PLATFORM_WIN32 environment, Framebuffer makes FBInit(hInstance). for SDL environment under win32 i need console app stuff Smile

wouldn't it be good to just have an APP_MAIN and the rest via compile flags? as depricated means CONSOLE_APP_MAIN and GUI_APP_MAIN would redirect to APP_MAIN.. it's just an idea. it surely implies a lot more that i dont know of.

EDIT: tried to make APP_MAIN..see patch

the decision is made automatically, via flagGUI. the others redirect to APP_MAIN. i left DLL_APP_MAIN untouched.


Hm, I guess that perhaps we should move GUI_APP_MAIN to final backend...

Report message to a moderator

Re: Rainbow, first iteration [message #33004 is a reply to message #33003] Wed, 29 June 2011 20:47 Go to previous messageGo to next message
tojocky is currently offline  tojocky
Messages: 607
Registered: April 2008
Location: UK
Contributor

It seems that latest svn have not Framebuffer/FB.iml file
SVN version is: 3578.

Report message to a moderator

Re: Rainbow, first iteration [message #33009 is a reply to message #33004] Thu, 30 June 2011 08:33 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1427
Registered: September 2007
Ultimate Contributor
Just a quick though based on my experience with my Irrlicht back-ended GUI experimentation (without Rainbow).

What would be your recommendation on handling the lack of a windowing system? My solution is to use a "hidden" master window, which ownes everything, and the actual windows are actually fake windows, basically a slightly smarter StaticRect with frame.

Does rainbow have any support for defining an underlying windowing framework?

Report message to a moderator

Re: Rainbow, first iteration [message #33011 is a reply to message #33009] Thu, 30 June 2011 09:04 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
we recently thought about extending ownership behaviour to Ctrl itself as well, optionally. but it will bring a lot of problems, i.e. what to do if Remove() is called on an owned Ctrl. destroy it? what it program expects to keep it, but simply wants to hide.. it needs to be thought out well. a windowing framework also implies opening and closing of windows. how to do that in Upp? moving/resizing, layering is already well supported. but the other half (life cycle management) is needed to..

Report message to a moderator

Re: Rainbow, first iteration [message #33013 is a reply to message #33003] Thu, 30 June 2011 11:14 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
mirek wrote on Wed, 29 June 2011 19:11

Hm, I guess that perhaps we should move GUI_APP_MAIN to final backend...

i think so too. the APP_MAIN stuff posted above is running well, though. this would leave the user with only one place to think about GUI switching, this beeing the flag.
a project would always compile with or without GUI flag, even if it uses CtrlCore stuff in a console app (might be a case someday), since CtrlCore/CtrlLib don't depend on GUI flag.

BTW: with that, i managed to override APP_MAIN in SDLFb.
so SDL is painting Upp now, too but it's all rudimentary. when it compiles and draws, one can relax and continue. for me to commit the starting point, i'd need to know which final direction this APP_MAIN stuff goes to.

i'd vote for this too, (but this is sort of taste dependant):
to move the specification of the implemented gui's, beeing native, to guiplatform.h
and have the defaulting take effect in CtrlCore.h
thus it uses the same means as upper guiplatform.h
which can #include "../uppsrc/guiplatform.h"
for backwards compatibility Smile

CtrlCore.h:8
#ifndef GUIPLATFORM_INCLUDE

#ifdef PLATFORM_WIN32
#define flagWIN32GUI
#endif

#ifdef PLATFORM_POSIX
#define flagX11
#endif

//include again for defaults to activate
//guiplatform.h may not have ifndef/define protection
#include <guiplatform.h>
#endif


uppsrc/guiplatform.h
#ifdef flagWIN32GUI
#define GUIPLATFORM_INCLUDE <Ctrlcore/Win32Gui.h>
#endif

#ifdef flagX11
#define GUIPLATFORM_INCLUDE <Ctrlcore/X11Gui.h>
#endif

[Updated on: Thu, 30 June 2011 11:30]

Report message to a moderator

Re: Rainbow, first iteration [message #33040 is a reply to message #33013] Mon, 04 July 2011 13:51 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
Well, looks like it is getting somewhere:

index.php?t=getfile&id=3343&private=0

A lot of issues to resolve in Framebuffer remaining, but I guess that Rainbow itself is now "proven".
  • Attachment: Rainbow1.png
    (Size: 111.27KB, Downloaded 980 times)

Report message to a moderator

Re: Rainbow, first iteration [message #33041 is a reply to message #33040] Mon, 04 July 2011 14:12 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
looks niice..

the greatest issue for me currently (on SDL) is how to correctly process keys..

can you clarify a bit what K_DELTA and the others mean? K_ALT etc. are supposedly modifiers reported alongside the key codes.
when does Keyboard infrastructure expect ascii / unicode and when the +K_DELTA stuff. what is it for..

i think SDL will need to be a selfsustained (not Framebuffer dependant) thing. while it will loan most code from it.. but i hope to avoid it.. and keep it slim. it currently paints and processes mouse already.

BTW: is the APP_MAIN idea of any value? otherwise i'd drop my changes..

Report message to a moderator

Re: Rainbow, first iteration [message #33042 is a reply to message #33041] Mon, 04 July 2011 14:35 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
kohait00 wrote on Mon, 04 July 2011 08:12


BTW: is the APP_MAIN idea of any value? otherwise i'd drop my changes..





Well, for what is worth, I have moved GUI_APP_MAIN out of Framebuffer.

I do not see the reason for "nonempty" uppsrc/guiplatform.h at the moment (other than ortogonality, but I do not think it is that important here...)

Report message to a moderator

Re: Rainbow, first iteration [message #33043 is a reply to message #33042] Mon, 04 July 2011 15:03 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
no problem. was just a tweak.

do you have any K_DELTA infos Smile?

Report message to a moderator

Re: Rainbow, first iteration [message #33045 is a reply to message #33043] Mon, 04 July 2011 15:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
K_DELTA is 65536, which > that all unicode characters (well, in theory it is not, but in practice, it is).

They idea is that Key is supposed to manage ALL key events - that includes (unicode) character events and other key events. Thus first 65536 values are reserved for character events and other events, like "K_UP" or "K_A" have K_DELTA (originally, in Win32, K_DELTA is added to noncharacter keycode).

Maybe we could figure out a better synonym Smile But basically it means "this is not a character".

Mirek

Report message to a moderator

Re: Rainbow, first iteration [message #33046 is a reply to message #33045] Mon, 04 July 2011 20:58 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
did i understand you right, that key, first expects keydown/keyup events to be send, and then (after respective keyup) the corresponding char event? which windows is already doing natively, WM_KEYDOWN/UP and WM_CHAR.. (do you fake this for X11?)

Report message to a moderator

Re: Rainbow, first iteration [message #33047 is a reply to message #33046] Mon, 04 July 2011 22:57 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
kohait00 wrote on Mon, 04 July 2011 14:58

did i understand you right, that key, first expects keydown/keyup events to be send, and then (after respective keyup) the corresponding char event?



Nope, characer is issued after keydown of course. For 'a' the sequence is K_A, 'a', K_A|K_KEYUP.

Quote:


which windows is already doing natively, WM_KEYDOWN/UP and WM_CHAR.. (do you fake this for X11?)



No need to fake, X11 is quite similiar, the only difference is that it only has KeyPress/KeyRelease and you convert to chars using some functions functions...

I guess these two levels naturally have to be on any system.

Mirek

Report message to a moderator

Re: Rainbow, first iteration [message #33048 is a reply to message #33047] Mon, 04 July 2011 23:29 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
OK.

i just commited a first shot SDLFb..
as i am not too experienced in SDL actually, there will be a lot to do yet.

we should think about grouping all the real Fb backends under Framebuffer. so the user actually does not need to add each and every backend at top level. Framebuffer could add them all and enable it with the right compile flag..

the speed of the stuff is actually really suboptimal due to full memcopy each repaint, i will try to fix this soon.

didn't watch the source development too carefully: have you added a BufferPainter creatable from an existing buffer yet? (specify the fb0 memmap directly as base, to speed up things).

[Updated on: Mon, 04 July 2011 23:31]

Report message to a moderator

Re: Rainbow, first iteration [message #33049 is a reply to message #33048] Mon, 04 July 2011 23:44 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
kohait00 wrote on Mon, 04 July 2011 17:29


didn't watch the source development too carefully: have you added a BufferPainter creatable from an existing buffer yet? (specify the fb0 memmap directly as base, to speed up things).



Not yet.

Report message to a moderator

Re: Rainbow, first iteration [message #33053 is a reply to message #33049] Tue, 05 July 2011 10:42 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
during debug of sdl backend i noticed a bug:

Win32Wnd.cpp:857
should have parenthesis around (ctr ? .. : ..)
have the same line in SDLFb, and it properly quits only with paranthesis. so quite sure the compiler does not recognize the meaning properly.
	while(!EndSession() && !quit && (ctrl ? ctrl->IsOpen() && ctrl->InLoop() : GetTopCtrls().GetCount()))


BTW
CtrlCore.h:1007
+	bool    IsIgnoreMouse() const                        { return ignoremouse; }


shouldn't
X11Proc.cpp:49 read this? similar to Win32Proc.. the K_ALT_KEY was missing

dword Ctrl::KEYtoK(dword key)
{
	if(key == K_ALT_KEY || key == K_CTRL_KEY || key == K_SHIFT_KEY)
		return key;
	if(GetCtrl()) key |= K_CTRL;
	if(GetAlt()) key |= K_ALT;
	if(GetShift()) key |= K_SHIFT;
	return key;
}



patch0 suggested PLATFORM_X11 changes for TDraw/util.cpp..
do you have other plans for them? i attach the this single patch again. i know of the PLATFORM_X11 legacy define..but uppsrc should be clean from it..uppsrc is not old legacy Smile

EDIT: btw: is there a reason why the UWord doesnt work with WinGl? (asuming addint the right packeges). it crashes..
  • Attachment: x11.patch
    (Size: 2.50KB, Downloaded 369 times)

[Updated on: Tue, 05 July 2011 14:47]

Report message to a moderator

Re: Rainbow, first iteration [message #33071 is a reply to message #33053] Tue, 05 July 2011 22:39 Go to previous messageGo to previous message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
this has gone recently Smile must come back..
CtrlCore.h:1009
	bool    HasMouse() const;

Report message to a moderator

Previous Topic: Upp Server (SVN, Redmine) down?
Next Topic: Docking package fixed and moved to uppsrc
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Tue Apr 29 09:52:02 CEST 2025

Total time taken to generate the page: 0.01468 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.5.
Copyright ©2001-2013 FUDforum Bulletin Board Software