Re: [fltk.development] FrameBuffer
The only feature of a window manager I wanted is the frame and window decorations and possibly the ability to move some pop-up dialog boxes with the pointer. I've used Qt Embedded to do a GUI on Linux framebuffer (not DirectFB) and it offers the option of running your application as the window manager, that's the feature I want but in GTK incorporating window manager features are frowned upon and I haven't seen any features like that in FLTK. I would tend to concur with the GTK folk here - WM responsibilities don't really form part of the GUI toolkit, in my view. But that's just an opinion and carries no weight. FWIW, it's pretty easy to create your own window subclass that draws it's own decorations (i.e. not depending on the WM for that) and which, in it's handle:: method catches mouse clicks for window drag operations and re-positions the window frame accordingly. So, in short, you can easily simulate the behaviour of the WM in your app., if that's the way you want to go. I did this a while back, it worked OK. For the next iteration, I actually added a real WM (based on aewm) as it added almost nothing to the overall code size (it is tiny), and used fltk itself to draw most of the window decoration. An alternate is to use flwm (a WM that is written in fltk), which is also very small and lightweight. Best to try both approaches, see what works for you. It'll only cost an afternoon, and probably pay you back big-time. SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On Mon, 2008-10-06 at 09:02 +0100, MacArthur, Ian (SELEX GALILEO, UK) wrote: The only feature of a window manager I wanted is the frame and window decorations and possibly the ability to move some pop-up dialog boxes with the pointer. I've used Qt Embedded to do a GUI on Linux framebuffer (not DirectFB) and it offers the option of running your application as the window manager, that's the feature I want but in GTK incorporating window manager features are frowned upon and I haven't seen any features like that in FLTK. I would tend to concur with the GTK folk here - WM responsibilities don't really form part of the GUI toolkit, in my view. But that's just an opinion and carries no weight. I am in complete agreement, for desktop type situations where multiple apps have to cooperate. So rather than go against the flow I'd rather find or port a Window Manager that has these features. For my apps that don't require a window manager I'll do what you suggest below. FWIW, it's pretty easy to create your own window subclass that draws it's own decorations (i.e. not depending on the WM for that) and which, in it's handle:: method catches mouse clicks for window drag operations and re-positions the window frame accordingly. So, in short, you can easily simulate the behaviour of the WM in your app., if that's the way you want to go. I did this a while back, it worked OK. For the next iteration, I actually added a real WM (based on aewm) as it added almost nothing to the overall code size (it is tiny), and used fltk itself to draw most of the window decoration. An alternate is to use flwm (a WM that is written in fltk), which is also very small and lightweight. Best to try both approaches, see what works for you. It'll only cost an afternoon, and probably pay you back big-time. How much dependence on X do these window managers have? Seem like flwm would be the easiest. __ Ormund ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On Thu, 2008-10-02 at 08:57 +0100, MacArthur, Ian (SELEX GALILEO, UK) wrote: I'd hazard that that would be a lot more work than just picking up Nikita's work and moving forward. Cairo is a lot of dependency to pull in for a lightweight GUI... None of the projects I'm now doing require the advanced graphic capabilities of Cairo, I just threw Cairo out as an answer to Nikita's objections. If you have a fixed kiosk-style interface on an embedded system (I think that's what you indicate later on) then it's not entirely clear you actually need a WM at all, you can just draw your widgets in the right place... I have done this, it worked OK. FWIW, I also had a hacked up version of aewm that I used for a variant that needed more conventional windows. Either way works. The only feature of a window manager I wanted is the frame and window decorations and possibly the ability to move some pop-up dialog boxes with the pointer. I've used Qt Embedded to do a GUI on Linux framebuffer (not DirectFB) and it offers the option of running your application as the window manager, that's the feature I want but in GTK incorporating window manager features are frowned upon and I haven't seen any features like that in FLTK. To use a font you can only load it from specified file. Pango? Is that not overkill just to load a font? If your application is indeed a fixed kiosk-style interface, then your fonts and so forth are (almost) certainly set at build time, so simply loading from a known file is trivial and much easier than messing with PanGo. I agree. My fonts and graphics are loaded from files who's location are hard-coded into the program and I think that's appropriate for this sort of application. Before I comment further I need to study the code. I want to, starting with Nikita code, complete a port of FLTK to DirectFB, something that is useful to someone wanting to build a full desktop or like me that just wants a full screen dedicated app. Am I asking for too much? I have a few projects that could pay for my time in this development. Regards __ Ormund ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On Wed, 2008-10-01 at 11:38 -0700, Nikita Egorov wrote: Dont forget that DirectFB is (at the moment, of course) lowlevel library! For example : It has no methods to draw/fill arc and polygons. I thought I might use Cairo to do those things. I'd hazard that that would be a lot more work than just picking up Nikita's work and moving forward. Cairo is a lot of dependency to pull in for a lightweight GUI... Window managers have no decoration. I haven't decided on a window manager yet, I was considering hacking flwm. If you have a fixed kiosk-style interface on an embedded system (I think that's what you indicate later on) then it's not entirely clear you actually need a WM at all, you can just draw your widgets in the right place... I have done this, it worked OK. FWIW, I also had a hacked up version of aewm that I used for a variant that needed more conventional windows. Either way works. To use a font you can only load it from specified file. Pango? Is that not overkill just to load a font? If your application is indeed a fixed kiosk-style interface, then your fonts and so forth are (almost) certainly set at build time, so simply loading from a known file is trivial and much easier than messing with PanGo. It has no any functions to work with regions (regions can be only rectangular). And so on. Do you plan to do it again (after me) ?.. Hope not!! I need to study the API of DFB, FLTK and look at the code you have already written to really make a comment. My needs are user interfaces for machines so I have no interest in desktop style GUIs, a single application runs from power-up to shutdown and usually the hardware has limited resources. SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
In fact, the most FLTK's features (except GL) are working properly with DirectFB. As I wished to put only minimal changes into the sources of FLTK so I've simply rewritten most of X11's functions used in FLTK :). I don't think I understand what you are doing. It seems harder to me to make DirectFB behave like X11 than to just port FLTK to DirectBF, I'll study the code you point to. Dont forget that DirectFB is (at the moment, of course) lowlevel library! For example : It has no methods to draw/fill arc and polygons. Window managers have no decoration. To use a font you can only load it from specified file. It has no any functions to work with regions (regions can be only rectangular). And so on. Do you plan to do it again (after me) ?.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On Wed, 2008-10-01 at 11:38 -0700, Nikita Egorov wrote: Dont forget that DirectFB is (at the moment, of course) lowlevel library! For example : It has no methods to draw/fill arc and polygons. I thought I might use Cairo to do those things. Window managers have no decoration. I haven't decided on a window manager yet, I was considering hacking flwm. To use a font you can only load it from specified file. Pango? It has no any functions to work with regions (regions can be only rectangular). And so on. Do you plan to do it again (after me) ?.. Hope not!! I need to study the API of DFB, FLTK and look at the code you have already written to really make a comment. My needs are user interfaces for machines so I have no interest in desktop style GUIs, a single application runs from power-up to shutdown and usually the hardware has limited resources. Regards. __ Ormund ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
I thought I might use Cairo to do those things. Pango? I couldnt build them for my powerpc embedded device... Hope not!! I need to study the API of DFB, FLTK and look at the code you have already written to really make a comment. My needs are user interfaces for machines so I have no interest in desktop style GUIs, a single application runs from power-up to shutdown and usually the hardware has limited resources. Mine too... ;) In the moment I dont want (and have no time) to create the 1.3 with DirectFB. I'm tired of making new versions (1.1.7 was launched in Mar 2006) without any help or support. I'm quite happy with the 1.1.9. Try. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On Mon, 2008-09-29 at 02:17 -0700, alain savelli wrote: Hello, I would like to know iof the last version of FLTK support Framebuffer. About a year and a half ago Nikita Egorov took the first steps in porting FLTK to DirectFB, I would like to continue that effort and see if it will get accepted into the FLTK. My main interest is building user interfaces for machines, FLTK provides a rich set of widgets and looks like it will crosscompile without too much trouble. I don't know how long it will take me, don't have a lot of experience with graphic software, but if others are interested it might help move it along. Hi, Ormund. Do you want to create a port for clean framebuffer or via using DirectFB's functions ? In fact, the most FLTK's features (except GL) are working properly with DirectFB. As I wished to put only minimal changes into the sources of FLTK so I've simply rewritten most of X11's functions used in FLTK :). You can take the version 1.1.9 from http://git.directfb.org. Read readme.dfb. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On 29.09.2008, at 11:17, alain savelli wrote: I would like to know iof the last version of FLTK support Framebuffer. There is a version of FLTK 1.1 out there that supports framebuffers. There is no official release yet. 1.4 is a pretty good candidate for core developer supported framebuffers. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On Mon, 2008-09-29 at 02:17 -0700, alain savelli wrote: Hello, I would like to know iof the last version of FLTK support Framebuffer. About a year and a half ago Nikita Egorov took the first steps in porting FLTK to DirectFB, I would like to continue that effort and see if it will get accepted into the FLTK. My main interest is building user interfaces for machines, FLTK provides a rich set of widgets and looks like it will crosscompile without too much trouble. I don't know how long it will take me, don't have a lot of experience with graphic software, but if others are interested it might help move it along. __ Ormund ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On 29.09.2008, at 21:35, Ormund Williams wrote: On Mon, 2008-09-29 at 02:17 -0700, alain savelli wrote: Hello, I would like to know iof the last version of FLTK support Framebuffer. About a year and a half ago Nikita Egorov took the first steps in porting FLTK to DirectFB, I would like to continue that effort and see if it will get accepted into the FLTK. My main interest is building user interfaces for machines, FLTK provides a rich set of widgets and looks like it will crosscompile without too much trouble. I don't know how long it will take me, don't have a lot of experience with graphic software, but if others are interested it might help move it along. As I said earlier, we would like to have framebuffer support as part of FLTK. The recommended way of going this route would be to create a few patches for the existing FLTK 1.3 (or 2.1, if you should decide to go that path) and submit those to fltk.development. If you patches are good and code conforming, Mike will give you SVN (Subversion) access. You can then branch off your private copy, add framebuffer support, and keep it in sync with whatever is going on in the main brabch. When FB support works well enough, we can merge your code back into the main code and other coders can help you wrap the port up. It doesn't matter really how long this takes - we all are on a small budget time-wise. Its important that your code behaves nicely and plays well with the build systems. There is quite a bunch on knowledgable developers who can help you get started. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
