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 » Porting SystemDraw to Frambuffer
Porting SystemDraw to Frambuffer [message #22966] Thu, 03 September 2009 11:18 Go to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Hi there,

SystemDraw has been there for a bit of time now, but it's only implemented for the major backends, Win32 and X11 on linux.

beeing on linux embedded, one often has no X11, so bare /dev/fb0 is what we have. no problem though, one might start at that point.

so my intention is here to port the SystemDraw layer (of which i have no pretty clue for now) to the famous framebuffer.

now here is the problem, i might need to look around for quite a time in the code, finding out which are the vital parts of the SystemDraw, and where to settle to write to fb.

If you could simply give a short overview of how SystemDraw is logically set up, meaning what is layer down to device, what is facing U++ layer.. so i know where i am. not filtering unneeded function in the code wasting time.

Or is there a (even short) description of the SystemDraw class..

So far i have understood that the class is splitet itself in 2 parts, beeind the destination draw for the GUI, and using some function to update data in the destinated layer, well, thats quite logical.

any help greatly welcome, or even if anyone has started already, i might join.

saludos
kostah
icon3.gif  Re: Porting SystemDraw to Frambuffer [message #22967 is a reply to message #22966] Thu, 03 September 2009 11:26 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
an idea came along..

i'd need a bunch of drawing operations, which already are there, in the ImageDraw stuff.

so we might take a step to use an ImageDraw, somehow opening /dev/fb0 and using that one as SystemDraw, so we would have a single window application, nevermind Smile, no problem, thats a start

now any comments of those who already know more of the base part down there in U++, what might be the problems???

Re: Porting SystemDraw to Frambuffer [message #22979 is a reply to message #22967] Fri, 04 September 2009 12:06 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Thu, 03 September 2009 05:26

an idea came along..

i'd need a bunch of drawing operations, which already are there, in the ImageDraw stuff.

so we might take a step to use an ImageDraw, somehow opening /dev/fb0 and using that one as SystemDraw, so we would have a single window application, nevermind Smile, no problem, thats a start



Nope, you need Painter, more specifically BufferPainter.

fb support is one of areas I would like to investigate. I have a very stupid question:

Is it possible to somehow develop fb application in X11 environment? I mean, how do I activate fb from X11 so that I can see results?

Mirek
Re: Porting SystemDraw to Frambuffer [message #22980 is a reply to message #22979] Fri, 04 September 2009 13:55 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi mirek

the point is that we *dont* use X11, so we work on bare /dev/fb0 and drivers (/dev/input/* or dev/mouse and even tslib stuff for touchscreen) to get that working..

now the drivers integration is part of its own, but displaying only, that is sommewaht part of Draw.

so i simply open /dev/fb0 within BufferPainter and have my Draw interface to that?. i think we might need an extra buffer painter here, fb0 is somewhat more complicated

you "simply" open /dev/fb0, but you then mmap it to your userspace and can then start painting on it (some more details on that needed). to find out mode or to set it, to find out strides, color witdth and the like there is this fbinfo struct (donno the name exactly, must look it up also) and according to that, BufferPainter needs to be set up. So maybe a wrapper class?

now the question arising is, where do you really set up the global or static first Ctrl, TopWindow or the like, which is base for all what CtrlCore is doing in the gui, including showing other control? i dont speak of windowing, its part of OS, but as far as i understood (looking up Win32 implementation of CtrlCore stuff) there somewhere mus be the point where a Topwindow or a SystemDraw is instantiated and drawn to GDC and passed all the events to.

Where is that point exactly, i could find it Smile seen thing like CreateWindow and CreateWindowEx, but the rest.... thats kind of specific.. i wanted to know where the start point for Upp actually begins, where OS things switch /hand over to Upp stuff/interface.

as a startpoint we might want to take a look at the nanox project in blackfin uClinux trunk, here is the start point maybe, how to use fb0 (in a simple way, nanox is smalles X11, but we might want to have no X11 at all.
svn: blackfin.uclinux.org, svn of uClinux distro
trunk/user/microwindow/src/nanox/clientfb.c
dig for /dev/fb0

http://blackfin.uclinux.org/gf/project/uclinux-dist/scmsvn/? action=browse&path=%2Ftrunk%2Fuser%2Fmicrowin%2Fsrc%2Fna nox%2Fclientfb.c&view=markup&revision=7547

another Point: SDL

i saw that SDL is sowhat supported, how's that? it can use bare fb0 and also has its layer to the input driver stuff, including touch screen. does Upp support SDL natively?? meaning without any GTK stuff and the like? or even in windowss a native SDL?
native I mean making Upp *GUI* prjects that use no X or Win32 but SDL to display and interact.
I've seen that SDL can be compiled, but it actually only using Core stuff, so no Upp CtrlCore things, its simply compiling with the IDE and having benefit of Core, but we want more Smile

that was quite a lot. sorry
Re: Porting SystemDraw to Frambuffer [message #22986 is a reply to message #22980] Fri, 04 September 2009 14:40 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Did I understand correctly that you try to create layer that enables writing POSIX GUI apps wthout need of X11?
(excuse me interfering this topic)

[Updated on: Fri, 04 September 2009 15:35]

Report message to a moderator

Re: Porting SystemDraw to Frambuffer [message #22992 is a reply to message #22986] Fri, 04 September 2009 15:53 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Mindtraveller wrote on Fri, 04 September 2009 14:40

Did I understand correctly that you try to create layer that enables writing POSIX GUI apps wthout need of X11?
(excuse me interfering this topic)


I would say partially that's what he's trying to do, except he's probably not worried about window manager itself, he needs that part inside window, i.e. drawing widgets + receiving events.
Moving/resizing/overlapping windows is maybe out of scope for him right now.


kostah:
The current status of SDL package is add-on, so you can add it to Core application, initialize the screen, and use ordinary SDL functions to draw something, but the CtrlCore is not aware of it at all.

edit: and due to licensing of SDL I'm not sure it's possible to integrate it into base U++ libs so tightly.
I think Mirek would rather opt for custom U++ FrameBufferPaint back-end (under BSD license), but I'm not sure if it fits into his development budget, there's never enough time to do everything you would like to. Smile

[Updated on: Fri, 04 September 2009 15:57]

Report message to a moderator

Re: Porting SystemDraw to Frambuffer [message #22993 is a reply to message #22979] Fri, 04 September 2009 16:06 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 693
Registered: December 2005
Location: Budapest, Hungary
Contributor
Quote:

Is it possible to somehow develop fb application in X11 environment? I mean, how do I activate fb from X11 so that I can see results?

I think, it is not possible to you use X11 and fb symultanously on the same hw.

About 10 years ago I created an embedded Linux app with SDL. It was convenient to develop it on my local machine under KDE.
The target device had a framebuffer console without X11.

SDL is a very thin layer, I found it not very resource hungry.

I think, the best solution would be to create an SDL backend to Draw and render ctrls into the SDL surface.
SDL apps can run on fb and in an X11 window also, without change.

And this way you would be able to compile the app to Windows as well (fortunately SDL is not POSIX only).
Re: Porting SystemDraw to Frambuffer [message #22995 is a reply to message #22993] Fri, 04 September 2009 16:51 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

May be it would be interesting to consider X11 alternative like DirectFB. As far as I know it is much more lightweight than X11 but handles GTK from the other hand.
Re: Porting SystemDraw to Frambuffer [message #22996 is a reply to message #22995] Fri, 04 September 2009 18:47 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi people

to make me understand:

in embedded systems, you often have no X11 or DirectFb (although there is a small port nxlib for the Blackfin uClinux). all what we have is frambuffer and input drivers.

so the need is only to run *1* single application, without windowmanager, just as a simple control gui for things to do on an embedded system. so frambuffer / input drivers should be enough, so we could spare out all the complex layers, making an embedded system slow and using large memory chunks (in fact thats the biggest concern in ES). using other intermediate layers like DirectFB or SDL, which give you abstract access to fb0 and input drivers is fine and comfortable, but also brings in some costs (regardless of licence, this is another concern as well).

i hope you got the picture..

in any case, we need a layer for the CtrlCore that either can draw on /dev/fb0 and get its input from /dev/input/* or a layer for CtrlCore to interact with SDL or DirectFB..

The graphic stuff is far complex, and the layering especially under linux is of its own, i.e SDL itself can run on DirectFB or bare Framebuffer, DirectFB can run on X or DirectFB or others...but you know all that already.

like you already got the point, SDL is just able to be build and used under Upp, but only for Core (not CtrlCore) base Applications, means not Upp native GUI applications, simple Console applications or so..

so what would be the best / easiest / most flexible solution to drop the X11/Win32 chains ??



Application layer like that is meant to be:

Upp GUI application (single window normally, one TopWindow instance)
||
output==================input
|| ||
framebuffer inputdrivers

or like that

Upp GUI App (real CtrlCore)
||
SDL
||
output======================intput
|| ||
(frambuffer, X, GL,Dir.FB) (/dev/input or touchscreen, or X11..)


or like that

Upp GUI App (real CtrlCore)
||
DirectFB
||
output======================intput
|| ||
(frambuffer, X, GL..) (/dev/input or touchscreen, or X11..)


or like that

Upp GUI App
||(native X11 layer)
nanox (former MicroWindows)
||
output======================intput
|| ||
(frambuffer) (/dev/input or touchscreen)
Re: Porting SystemDraw to Frambuffer [message #22997 is a reply to message #22996] Fri, 04 September 2009 18:49 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Addition:

its even worth it to use Upp here in the point of not to need GTK/KDE/FLTK/wxWidgets and all that stuff Smile

it makes it obsolete as far as i know
Re: Porting SystemDraw to Frambuffer [message #22998 is a reply to message #22980] Fri, 04 September 2009 18:53 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Fri, 04 September 2009 07:55

hi mirek

the point is that we *dont* use X11, so we work on bare /dev/fb0 and drivers (/dev/input/* or dev/mouse and even tslib stuff for touchscreen) to get that working..



I am asking because of development/debugging environment...

Quote:


you "simply" open /dev/fb0, but you then mmap it to your userspace and can then start painting on it (some more details on that needed). to find out mode or to set it, to find out strides, color witdth and the like there is this fbinfo struct (donno the name exactly, must look it up also) and according to that, BufferPainter needs to be set up. So maybe a wrapper class?



I think you are going to do double-buffering anyway, so ImageBuffer is just fine for this (as you can solve the format difference later...)

Quote:


where a SystemDraw is instantiated and drawn to GDC and passed all the events to.



It is during handling of WM_PAINT (or expose).

Quote:


Where is that point exactly, i could find it Smile seen thing like CreateWindow and CreateWindowEx, but the rest.... thats kind of specific.. i wanted to know where the start point for Upp actually begins, where OS things switch /hand over to Upp stuff/interface.

as a startpoint we might want to take a look at the nanox project in blackfin uClinux trunk, here is the start point maybe, how to use fb0 (in a simple way, nanox is smalles X11, but we might want to have no X11 at all.
svn: blackfin.uclinux.org, svn of uClinux distro
trunk/user/microwindow/src/nanox/clientfb.c
dig for /dev/fb0



Well, thinking about it, I guess nice and simple solution is to provide some abstraction level...

I mean, a class that abstractly represents sort of framebuffer and mouse and keyboard input and then build the whole thing above it.

For development purposes, we can use normal single window to emulate this.

Quote:


another Point: SDL

i saw that SDL is sowhat supported, how's that?



Not realy, the only support is that it comes with mingw version.

Quote:


it can use bare fb0 and also has its layer to the input driver stuff, including touch screen. does Upp support SDL natively?? meaning without any GTK stuff and the like? or even in windowss a native SDL?



No. But I guess we can use SDL as inspiration for above abstraction layer...

Mirek
Re: Porting SystemDraw to Frambuffer [message #23997 is a reply to message #22998] Wed, 16 December 2009 11:19 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Ok, people, this framebuffer topic is about to have a revival.
since we have the Painter stuff now and the headless drawing, and even the Docking facilities in bazaar, we almost have a "window manager".. but I need help Very Happy

I have started to prepare some porting stubs for the use of framebuffer in the CtrlCore. Well, for now, ist really stubs, just moslty plain copy and paste from X11 code (which lies next), and commenting doubtable or unneeded/unneccessary parts away.

i realized that the underlying interface is quite "distributed" over a lot of sections, without explicit "tagging" what is what. it'd be esier to have the commen interface functions somehow grouped, so one could know, these functions are required. current situation is that its pretty mixed with the helper functions for the apropriate interface as well. both, in headers and code. so this is maybe to be reorganised, especially if we take in account, that this might not be the last porting we face (next important would be to port to apple graphics), and there will be even more i think. so we need to make things clearer here. (at least a short description on what so far is used by both interfaces WIN32/X11 and is required in any other port, and what are their interface specific helpers, and maybe a sentence of description to each, especially when it comes to Clipboard,DragandDrop and the like).

back to topic.

base idea:
using /dev/fb0 to display the one and only (no window manager) TopWindow instance of an application (naturally fullscreen), which is driven directly by user input extracted from /dev/input layer

class
SystemDraw : public BufferPainter

where the BufferPainter can be initialized with an ImageBuffer
which in turn should somehow represent the /dev/fb0.
-->problem: the fb0 can have really weired dimensions, bitwisths per color, strides and the like..is the ImageBuffer capable to cope with that? or do we need to have the double buffering as only solution (where the normal ImageBuffer 24bit is overlayed/calculated on tob of the weired fb0 layout)?

the control input section should be driven directly with /dev/input/, this normally does invoke a repaint in some sort

we need to provide a full implementation of own drag and drop, which can be significantly simpler i think, because we dont drag between multiple windows od Win32/X11, but simply inside the TopWindow (which is between Ctrls)

we need to provide a full replacement for Clipboard stuff, how does this work?

we need to provide a full replacement of the TimerThread (which is used heavily by Ctrls, it also needs to be reentrant (means a new occurance of timer event is handled either by interrupting a possibly currently still working timerthread procedure, or by spawning another thread to handle this, which leads either to application lock (due to repeated reentrance) or to thread explosion if handling callbacks are misdimensioned somehow.

The GUI thread (which is the main thread) would be far the simplest part i think, cause it creates, opens and runs the TopWindow and realizes all the drawing and user input.

is there any description (besides the code itself Smile) available in terms of how Clip, Drag and Drop, the timer thread and the GUI thread are set up (basic ideas should be enough)

the GUI flag, which is used currently can be abandoned maybe, because it is evaluated only in POSIX environment, in WIN32 GUI is somewhat implicit, as soon as one uses the package CtrlCore, one uses gui stuff in Win32. in Linux, one should be able to specify GUI X11 or GUI FB somehow.. but this is small peanuts. backwards compatibility can be done imlicitly by defining a standard flag.

the stubs (NOT implementations) are half way done, as soon as it compiles and links, i will post it here, maybe mirek can take a look over it and clean out what he dooms or claims not neccessary (since i have no much idea of underlying gui facility) and maybe already integrate it in the trunk, to be able to code parallely. first thing woul be, of corse, to open the /dev/fb0 and display the main window once...

ok, till then, cheers

PS: maybe we can really use this effort to restruct code to make porting in future a lot esier.

PSS: sorry for the text chunk


Re: Porting SystemDraw to Frambuffer [message #24000 is a reply to message #23997] Wed, 16 December 2009 14:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 16 December 2009 05:19


where the BufferPainter can be initialized with an ImageBuffer
which in turn should somehow represent the /dev/fb0.
-->problem: the fb0 can have really weired dimensions, bitwisths per color, strides and the like..is the ImageBuffer capable to cope with that?



No.

Quote:


or do we need to have the double buffering as only solution (where the normal ImageBuffer 24bit is overlayed/calculated on tob of the weired fb0 layout)?



Yes. BTW, ImageBuffer is 32bit RGBA.

Quote:


we need to provide a full implementation of own drag and drop, which can be significantly simpler i think, because we dont drag between multiple windows od Win32/X11, but simply inside the TopWindow (which is between Ctrls)

we need to provide a full replacement for Clipboard stuff, how does this work?



IMO, it is in fact much easier to start from the scratch than implementing Clips in X11/Win32.

There is nothing magic, you have raw binary data and string that represents the type of data. Perhaps use filesystem to store both and you are done... (with clipboard anyway, D&D will need a bit more).

Quote:


we need to provide a full replacement of the TimerThread (which is used heavily by Ctrls, it also needs to be reentrant (means a new occurance of timer event is handled either by interrupting a possibly currently still working timerthread procedure, or by spawning another thread to handle this, which leads either to application lock (due to repeated reentrance) or to thread explosion if handling callbacks are misdimensioned somehow.



There is no TimerThread in CtrlCore Smile And thing is pretty simple generally in fact. All you need to do is limit waiting for input events to some max timeout in message loop and to know current system time (one way or another). Then call TimerProc at the end of event processing or if there is timeout.

Quote:


is there any description (besides the code itself Smile) available in terms of how Clip, Drag and Drop, the timer thread and the GUI thread are set up (basic ideas should be enough)



I hope that above is helpful for starters, ask for more details as you go.

Quote:


the GUI flag, which is used currently can be abandoned maybe, because it is evaluated only in POSIX environment, in WIN32 GUI is somewhat implicit, as soon as one uses the package CtrlCore, one uses gui stuff in Win32.



GUI is because Win32 - console vs GUI apps have different linker options - that is the original problem.

Quote:


in Linux, one should be able to specify GUI X11 or GUI FB somehow.. but this is small peanuts. backwards compatibility can be done imlicitly by defining a standard flag.



Well, that is interesting problem Smile I guess GUI FB and X11 as default or something like that.

Quote:


PS: maybe we can really use this effort to restruct code to make porting in future a lot esier.



Well, it is not so messy, but it is true that over those 10 years of development, thing are getting more and more patched.

Anyway, in reality, I am not huge believer of fresh starts there. If nothing else, it would put all of my apps in jeopardy... Smile

Also, it is questionable that you can gain too much more clarity there. Some of stuff in CtrlCore is pretty nasty, but that is partly because host-platform details are pretty nasty too...

Mirek
Re: Porting SystemDraw to Frambuffer [message #24003 is a reply to message #24000] Wed, 16 December 2009 15:19 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? there is no extra thread for the TimerProc in WIN32 or X11? (WIN32 used WM_TIMER as far as i know, ahh..which is ran by he same thread in spare times, when it sleeps Smile and in X11 is maybe similar, right?
well, i'm learning.

your're right, platfomr stuff is a mess. so it's no wonder. actually i have learned a lot, how to have cleaner code because thanks to upp code. so its generally really clean, even fun to read, logical and short (most times)

thank you, i'll give it a try

Re: Porting SystemDraw to Frambuffer [message #24008 is a reply to message #22966] Wed, 16 December 2009 22:08 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi mirek, here comes the stubs for framebuffer environment. it should compile fine. is just the extract from my current svn tree (only the changed stuff left, simply replace)

flags situation:

GUI needs to be specified for FB only, if no backend follows, X11 is choosen automatically. (GUI X11). to compile frambuffer: GUI FB, WIN32 currently does not actively distinguish anything (besides what you mentioned).

i used X11 backend stuff as template, just tweaking as little as possible in first instance.

if possible, you could include this into trunk uppsrc, it comes with full .svn backend, so you can backcheck svn diff, but it mostly is things like extending #ifdef PLATFORM_X11 to #if defined(PLATFORM_X11) || defined(PLATFORM_FB) and the like.

the stubs, which were demanded during compile or linking have been prepared so far commenting code with

#ifdef UNUSED
...
#endif

next step i will try to prepare the TopWindow thing opening the /dev/fb0 and maybe painting a first picture. this could take a bit.

a branch would be good.. so i dont bother you to often, if you prefer

thanks for help
Re: Porting SystemDraw to Frambuffer [message #24009 is a reply to message #24008] Wed, 16 December 2009 22:34 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
BUG: use this one #include needs to go before NAMESPACE_UPP
  • Attachment: DrawFB.h
    (Size: 4.95KB, Downloaded 661 times)
Re: Porting SystemDraw to Frambuffer [message #24013 is a reply to message #24003] Thu, 17 December 2009 13:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 16 December 2009 09:19

did i understand you right? there is no extra thread for the TimerProc in WIN32 or X11? (WIN32 used WM_TIMER as far as i know, ahh..which is ran by he same thread in spare times, when it sleeps Smile



WM_TIMER is in fact only used to "wake up" from GetMessage.

In X11, the same thing is realized using timeout parameter in "select". What you really need is to get ProcessEvents run at most after 10ms of inactivity.

Mirek
Re: Porting SystemDraw to Frambuffer [message #27146 is a reply to message #22966] Mon, 28 June 2010 13:43 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi all,

i've been busy with another project (which isnt done yet anyway, but it beats my nerves already Smile. but now slightly i want to get back to this framebuffer issue.. over the past months a gained some amount of knowledge about upp, mirek and others are constantly providing extremely valuable infos and i start to wrap my mind on it (Painter, Draw, .. still in progress)

so here we go.. lets collect the things that will need to be adresses when porting. please complete what i forgot so the list could be used as a reference when wanting to port to other things (mac i.e.)

/////

* Drawing (open surface, check modes, alignment, color palette, implement Draw interface operations, TopWindow, DHCtrl ..)

for framebuffer this is more or less the base thing. a SystemDraw : BufferPainter which is directly doublebuffering to the /dev/fb0 with help of a converting function (which adresses strides/alignment issues). The Draw interface is completely implemented in BufferPainter.. TopWindow can only be one for framebuffer, in fullscreenmode.

* Input Interface (open input streams, /dev/input*, translate to Upp messaging, prepare for periodical invocations

* Timing (set up thread to invoke repaint each 10 ms or on demand, Timer Queue, PostCallback adaption

* Drag&Drop (this is probably the most complicated part, setup static infrastructure to mark things that are dragged??)

* Clipboard (also static infrastructure, buffers for text, images, etc..??)

* Fonts (any idea?)

* later, small "WindowManager" replacement, to be able to render / run more that one TopWindow

////

but still got some questions
what is the exact purpose / idea of:

1) TopWindow (create & startup a system dependant top window instance, linking its GDI to upp stuff as well as means to dispatch input messages. all other Ctrl's are placed as upp own children, not system own windows..)

2) DHCtrl (Ctrl with own GDI context??, seperately refreshable without affection other ctrls?? i found some in info in
http://www.ultimatepp.org/forum/index.php?t=msg&goto=267 38&
but i guess it wont be needed in frambuffer environment at first.

what more issues do we need to adress here? (maybe this could be sort of a porting guide...)

thanks

Re: Porting SystemDraw to Frambuffer [message #27217 is a reply to message #27146] Sun, 04 July 2010 11:58 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
another querstion:

where will be the problems (as expected) concerning Chameleon stuff and framebuffer? is there things to account for? how to properly initialize Chameleon stuff when you dont have OS underlayer?
Re: Porting SystemDraw to Frambuffer [message #27228 is a reply to message #27217] Tue, 06 July 2010 09:49 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Sun, 04 July 2010 05:58

another querstion:

where will be the problems (as expected) concerning Chameleon stuff and framebuffer? is there things to account for? how to properly initialize Chameleon stuff when you dont have OS underlayer?


Not much problem there. Basically, you compile as "NOGTK" and get default, non-OS dependent, look&feel.

Anyway, I may repeat myself, but the idea is that there should be something like "FB" flag and the whole framebuffer "backend" should be virtualized, so that you can easily bind U++ to any sort of device (framebuffer, SDL...).
Previous Topic: Building 32 bit apps on Ubuntu64
Next Topic: Can anyone plan to bring ultimate++ Widget toolkit to GTK-compatible, GTK# and qt-compatible?
Goto Forum:
  


Current Time: Thu Mar 28 18:42:09 CET 2024

Total time taken to generate the page: 0.01472 seconds