Re: [fltk.general] OT: Making application run once
Am 16.02.2013 14:10, schrieb Gonzalo Garramuno: I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. For OS independence I would use: http://www.fltk.org/doc-1.3/classFl__Preferences.html together with repeat_timeout( cb ) it should be fine http://www.fltk.org/doc-1.3/classFl.html#ae5373d1d50c2b0ba38280d78bb6d2628 Application reads the lock key and if none exists, writes a new lock key containing e.g. a PID. Second instance reads the lock key, checks if the PID exists and writes a command key with instructions for the first instance and quits. The first instance polls through repeat_timeout() the command key and does what it needs. On exit the first application deletes the lock key. hope this helps Kai-Uwe ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] EDE/FLTK talks on FOSDEM
Am 10.02.2013 23:39, schrieb Sanel Zukan: [2] http://edeproject.org/slides/fosdem-2013-fltk.pdf FLTK CinePaint is still in the (stalled?) starter phase and far away from production use. It's appearance in the FLTK application list makes a qualified laughter. kind regards Kai-Uwe ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OpenGL + widgets
Am 13.01.2013 21:59, schrieb Christopher James Huff: Is there a recommended approach to drawing FLTK widgets inside or on top of an OpenGL window? or somehow draw widgets to an image which is then drawn in OpenGL (could an existing driver easily be modified to do this?). Are there other FLTK allows to draw to an offscreen buffer. glDrawPixels() or if you need shaders, then better glTexImage2d and friends can bring them into OpenGL. Search for fl_create_offscreen(), fl_begin_offscreen, fl_read_image, fl_end_offscreen. Some not so self contained code for a rough idea[1]. kind regards Kai-Uwe [1] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=src/examples/image_display/Oy_Fl_Group.h;h=0e0cfd77759f198fd8bf7f7c3fb63009870750e3;hb=HEAD#l196 ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] replace PNG shared image handler
Hello, I see images with ICC profiles [1] being badly supported inside FLTK. How can I replace the default image handlers with my own ones? A simple Fl_Shared_Image::add_handler(myImageCheck); did not help. The handler is not called for known formats, like PNG. Only unknown formats are sen by myImageCheck. thanks in advance Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://www.oyranos.org/wiki/index.php?title=Test_Images ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] replace PNG shared image handler [SOLVED]
Am 10.06.12, 14:47 +0200 schrieb Kai-Uwe Behrmann: How can I replace the default image handlers with my own ones? A simple Fl_Shared_Image::add_handler(myImageCheck); did not help. The handler is not called for known formats, like PNG. Only unknown formats are sen by myImageCheck. The following sequence helped in adding our image handler before the default FLTK on: Fl_Shared_Image::add_handler(iccImageCheck); Fl_File_Icon::load_system_icons(); kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Antipaint
Am 07.06.12, 09:26 +0200 schrieb Georg Potthast: Antipaint is a Paint program based on FLTK and mentioned with a dead link in the Wiki/Software/Graphics section on the FLTK site. Mark Roth was so kind to sent me the source code and I got Antipaint to work with FLTK 1.3.0 and posted the source code here: http://nanox-microwindows-nxlib-fltk-for-dos.googlecode.com/files/antipaint.tar.gz The attached patch helped me to build the app under Linux. kind regards Kai-Uwe___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] fl_offscreen drawing and widget offsets
Hello,
I try to create a Fl_Group derived widget, which redirects pixels
by means of a fl_offscreen buffer for manipulation.
fl_offscreen works fine, pixel manipulation is fine, but drawing is
displaced.
My_Group::draw()
{
if(init || resize)
{
off = fl_create_offscreen(w(),h());
off_buf = new unsigned char[w()*h()*4];
}
fl_begin_offscreen(off);
Fl_Group::draw();
fl_read_image(off_buf,0,0,w(),h());
fl_end_offscreen();
// do some stuff with off_buf ...
fl_draw_image(off_buf, x(),y(),w(),h());
}
If I comment out the offscreen stuff the Fl_Group::draw() draws
everything correctly. Now I think that Fl_Group draws into the
Fl_Double_Window's offscreen buffer on window coordinates.
Obviously I want FL_Group::draw() to draw into Fl_Groups local
coordinates. The My_/FL_Group widget has a x() and y() value.
The desired way to workaround that difference
between Fl_Group and my derived My_Group would be to set an
offset before the Fl_Group::draw() command above.
Is there a way to place a global drawing instruction like:
all following drawing operations must use a specified offset?
An alternative might be to use a offscreen buffer that is equal to
the window buffer. But that seems not economic, as the offscreen
buffers will overlap and most space is in them not used.
thanks in advance
Kai-Uwe
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK with XFCE
Am 29.08.11, 23:47 -0700 schrieb Greg Ercolano: On 08/29/11 19:19, Steve Underwood wrote: I've been using FLTK for years on Linux and Windows machines. For the first time I have tried using it with XFCE 4.8, and I find a problem that doesn't seem to occur anywhere else. I am using FLTK 1.10. If I run Fluid, and create a window with some coloured background areas, those background are not updated properly. The window is initially drawn OK. However, if another window then overlaps it and is moved away, the background areas in the window I am creating are not properly restored. If I finish my Fluid development work, and build the resulting application, the application behaves in the same way. If I restart the same machine running Gnome 3 instead of XFCE, both Fluid and the application behave properly. The same code also behaves OK on a Windows XP machine. Is this a known issue? Is there a workaround? That could happen, if your widgets box is empty and the background has no colour. Try to change the box type to be filled. Alternatively it would be good to show a small example code to let interessted people test under twm. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] FL_TEXT_OVER_IMAGE?
Hello, the 1.1. documentation[1] says under align() is a FL_TEXT_OVER_IMAGE enum possible to show text over images. I would have liked to use that. But unfortunedly the include files in 1.1.9 and 1.3.0rc2 do not have that. Is this flag obsolete? What else is recommeded to get a text label() over image(). thanks in advance Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://www.fltk.org/documentation.php/doc-1.1/common.html#labels ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] RFQ: FLTK 3.0 - what's the status? What are the expectations? Where should we be heading?
Am 10.07.11, 15:49 +0200 schrieb Matthias Melcher: as you may have read, I have been trying to get the FLTK 1 and FLTK 2 branch back together into a single FLTK 3 branch. This reads like many more APIs become available. How do you think to can test them all? Will there come automated testing alongside, in order to cover many of the nasty regression testing? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Irrlicht and FLTK
Hello Lucas,
drawing should happen inside the FLTK widgets virtual draw() function and
in the main thread.
You could write:
class Irrlicht_Fltk : public Fl_Window
{
public:
// some needed initialisation
...
Irrlicht_Fltk( int X, int Y, const char * title) , Fl_Window(X,Y,title)
{};
draw()
{
device-getVideoDriver()-beginScene();
device-getSceneManager()-drawAll();
device-getVideoDriver()-endScene();
};
}
Irrlicht_Fltk * win = new Irrlicht_Fltk(340,180,muh);
...
FLTK will call your Irrlicht_Fltk::draw() function to draw the window.
If that works, you need a timeout to ping FLTK to redraw.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
Am 31.03.11, 13:44 -0700 schrieb Lucas:
Hi guys,
I'm trying to combine Irrlicht and FLTK into one window.
This works well on a Windows machine, but when I try it on a Mac I have some
problems.
I can get it to work when using Irrlicht's software renderer, but when using
the OpenGL renderer it doesn't work and I get an invalid drawable error (I
also get this error with the software renderer, although it works).
I hope someone on this Forums use both libraries and can help me.
Thank you in advance,
-Lu
PS:
Here is the code that works (although using the software renderer):
[code]
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/x.H
#include irrlicht.h
int main(int argc,char** argv)
{
//Create FLTK window
Fl_Window* win = new Fl_Window(340,180,muh);
win-end();
win-show(argc, argv);
//Create Irrlicht device
irr::SIrrlichtCreationParameters params;
params.WindowId = (void*)fl_xid( win );
params.DriverType = irr::video::EDT_SOFTWARE;
params.WindowSize = irr::core::dimension2du(340,180);
irr::IrrlichtDevice* device = irr::createDeviceEx(params);
//Update FLTK and Irrlicht
while(Fl::check()) {
device-getVideoDriver()-beginScene();
device-getSceneManager()-drawAll();
device-getVideoDriver()-endScene();
}
return 0;
}
[/code]
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.bugs] [MOD] STR #2504: HAVE_CAIRO macro in installed header
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current FL/Fl.H contains a HAVE_CAIRO macro. This is a very generic name and one of my projects uses the same macro name internally. Please rename HAVE_CAIRO to something like FLTK_HAVE_CAIRO. Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.general] more issue(s) on 1.3.0rc2
Starting a new thread: * one of my projects has a local HAVE_CAIRO defined and fails with Cairo enabled FLTK. The reason is the FL/Fl.H:36 has the same generic HAVE_CAIRO inside. Request: could this macro be made specific to FLTK? e.g. FLTK_HAVE_CAIRO kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK, Cairo and where FLTK is going
Am 01.01.11, 13:57 -0800 schrieb CIB: So what does this have to do with FLTK and cairo? Well, did you ever read what cairo can do? It can write PDFs. I'm sorry to say this, but a library that can write PDFs is not suitable as a base drawing kit for a fast and light GUI library. It's simply bloat. This sentence reads as if osX is bloated just because it integrates monitor displaying and printing routines through the PDF model. I think quite the opposite it true. This integration is wanted and was a desired feature in Xorg. Just it sits now in Qt and for Gnome in Cairo. What makes the ironybloaded/irony Apple system more interessting is, they integrated even colour management with PDF, while following the standard. IMHO it is good to have these features coming in FLTK. The pressure on me to switch to Qt or Gtk for desktop use was always high. 1.3. is on a good road to relax that. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] 1.3.0rc2 installation issue
I get following error with fltk-1.3.0rc2-source.tar.gz : ... Installing documentation files in /opt/local/share/doc/fltk ... Installing fltk.pdf in /opt/local/share/doc/fltk ... /usr/bin/install: Aufruf von stat für „fltk.pdf“ nicht möglich: Datei oder Verzeichnis nicht gefunden Hope that makes sense, Kai-Uwe___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk and Fluid under Ubuntu 10.04 lts
Am 26.12.10, 20:07 -0800 schrieb Greg Ercolano: Derek Prowse wrote: I am at a loss for now. On your system it may have installed in a different place from mine, as you're on 10.04 and I'm on 8.04. On my system, 'apt-file list fluid|grep bin' shows me fluid is installed in /usr/bin/fluid: # apt-file list fluid | grep bin fluid: /usr/bin/fluid fluidsynth: /usr/bin/fluidsynth libfluidsynth-dev: /usr/include/fluidsynth/seqbind.h Similarly, determine where the fluid binary is installed on your system, and modify the Exec= command accordingly. Would it be good to open a bug report at debian or ubuntu to fix that for all users? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] integrating gstreamer into an FLTK application?
Am 30.09.10, 08:59 +0100 schrieb MacArthur, Ian (SELEX GALILEO, UK): I know of someone who is using gstreamer in a non-gtk app, with (I believe) some success so it would appear to be possible. Yes, some KDE projects do. Possibly simply as alternative media backends. The gstreamer web site has links to these projects. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2411: ICC Colour management policy
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature Better to focus on getting a single, standard colorspace working right for all applications (sRGB) and *maybe* look at alternate colorspace support in the future. Thats a good step toward a CM policy. Great. Some remaining questions: How can a user programmatically see that wide gamut support is there or not? Which widgets are going to be affected? A function like the following could answer those questions in a upward compatible way: int fl_color_space ( Fl_Widget * my_widget, void ** returned_profile_block, size_t* returned_size ); useful results: * device RGB - return no profile (Win32, X11) * sRGB - return a ICC profile blob (osX SL), that can be static * wide gamut - return in the future the actual set profile Maybe its more beautiful to have a Fl_Widget::color_space( .. ) . Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2411: ICC Colour management policy
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature Generic RGB only through the API sRGB. In ColorSync utility Generic RGB is the old gamma 1.8. Mike, can you forward this to Apple? Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2411: ICC Colour management policy
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature generic RGB from ColorSync utility is not the same as CGColorSpaceCreateDeviceRGB(). That add to the confusion to a missed CM policy. So when FLTK sets an ICC profile to the system, that would be welcome to be transparent. With a ICC profile setter for fl_draw_image(), users would be allowed to deploy as well wide gamut devices. Thats currently not possible with FLTK widgets or at last not known how to. Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2411: ICC Colour management policy
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature FLTK on osX SL uses Generic RGB, which is not sRGB at all. The situation for writers of colour managed applications is quite fuzzy [1]. As a suggestion. FLTK might add an API to expose the used colour space. On WIN32 and Linux it might return sRGB. On osX SL it can return the used colour space. Thus interested applications can query what to colour correct to. /* provide a malloced ICC profile block and its size */ int fl_color_space( void ** returned_profile_block, size_t * returned_size ); The profile can on Linux be asked from the X11 server [2]. So returning the first displays profile might be the right choice. osX has surely functions to convert a CGColorSpaceRef to a ICC profile data blob. [1] http://oyranos-cms.blogspot.com/2010/09/cross-platform-toolkits-and-cm.html [2] http://www.freedesktop.org/wiki/Specifications/icc_profiles_in_x_spec Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2411: ICC Colour management policy
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature The most accurate ICC profile from fl_color_space() would be only what is really set by FLTK. On osX it is the ICC equivalent of CGColorSpaceCreateDeviceRGB. Link: http://www.fltk.org/str.php?L2411 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] ICC Colour management policy in FLTK
Am 02.09.10, 08:17 +0100 schrieb MacArthur, Ian (SELEX GALILEO, UK): is there a explicite policy on how to handle colour management in FLTK? I don't think so - though others may have more information. Actually, it is entirely possible, from your background, that you know more about this than anyone else here! I don't really know Quartz etc. well enough to even suggest something for the OSX case. Sorry... Thanks for your reply. FLTK on osX SL uses Generic RGB, which is not sRGB at all. The situation for writers of colour managed applications is quite fuzzy [1]. As a suggestion. FLTK might add an API to expose the used colour space. On WIN32 and Linux it might return sRGB. On osX SL it can return the used colour space. Thus interessted applications can query what to colour correct to. /* provide a malloced ICC profile block and its size */ int fl_color_space( void ** returned_profile_block, size_t * returned_size ); The profile can on Linux be asked from the X11 server [2]. So returning the first displays profile might be the right choice. osX has shurely functions to convert a CGColorSpaceRef to a ICC profile data blob. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://oyranos-cms.blogspot.com/2010/09/cross-platform-toolkits-and-cm.html [2] http://www.freedesktop.org/wiki/Specifications/icc_profiles_in_x_spec ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] ICC Colour management policy in FLTK
Hello, is there a explicite policy on how to handle colour management in FLTK? Background, I want to colour manage several widgets inside a FLTK application. The areas needs to be colour corrected for display while the remaining UI shall be sRGB and automatically colour corrected by the respective OS. On osX I do not know how to access the underlying Quartz engine to tell about a custom ICC colour space. I only know that FLTK has to set some ICC colour space to be able to draw anything at all. FLTK makes havy use of CGColorSpaceCreateDeviceRGB(). But there seems no hole left to place some really meaningful, like a graphics context which could be switched to a new profile. So the only workaround would be to use OpenGL. That might be acceptable. Any further ideas on how to do colour management on osX with FLTK is much welcome. On Linux its easy to access X11 and its windows in order to talk to a colour server. So the situation seems fine. The question is, will this remain as is to avoid accidential double colour corrections? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.opengl] Problem with program generated texture
Perhaps some issue around windows ARGB?
Am 23.07.10, 10:24 -0700 schrieb Marko:
GLubyte Texture4[4][3] =
{
{ 0x00, 0x00, 0xa0 }, // Dark Blue
{ 0x00, 0x00, 0xff }, // Blue
{ 0x00, 0xff, 0x00 }, // Green
{ 0xff, 0x00, 0x00 } // Red
};
(other paremeter settings in here...)
glTexImage1D(GL_TEXTURE_1D, 0, GL_RGB, 4, 0, GL_RGB , GL_UNSIGNED_BYTE,
Texture4);
Now this partly works the dark blue, blue and the green colour bands show up
just fine, but for some reason the red it just black.
___
fltk-opengl mailing list
fltk-opengl@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.general] sprites
Am 25.05.10, 19:57 -0700 schrieb pawel: Ian wrote: There are libs that can help - FTGL is worth a look for example... Yep I'm familiar with that one (that is I looked at the api docs for a few minutes) and will likely use it... Just FTGL is not unicode aware and crashes easily with according texts. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] package integrity
I downloaded http://www.fltk.org/software.php?VERSION=1.1.9FILE=fltk/1.1.9/fltk-1.1.9-source.tar.gz and checked its md5 sum with the md5sum command. It says: md5sum fltk-1.1.9-source.tar.gz 2b6088e5a7ef7930774c9334200c851e fltk-1.1.9-source.tar.gz The website (http://www.fltk.org/software.php?VERSION=1.1.9): d3c76db1b6cebce7a009429bbd125470 Whats wrong? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] package integrity - solved
Sorry, I checked the intermediate HTML page. The real tar.gz file is correct. Am 11.03.10, 21:50 +0100 schrieb Kai-Uwe Behrmann: I downloaded http://www.fltk.org/software.php?VERSION=1.1.9FILE=fltk/1.1.9/fltk-1.1.9-source.tar.gz and checked its md5 sum with the md5sum command. It says: md5sum fltk-1.1.9-source.tar.gz 2b6088e5a7ef7930774c9334200c851e fltk-1.1.9-source.tar.gz The website (http://www.fltk.org/software.php?VERSION=1.1.9): d3c76db1b6cebce7a009429bbd125470 Whats wrong? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Cairo support on FLTK 1.3
Am 27.02.10, 14:52 +0100 schrieb Matthias Melcher: Hi guys, I would please need a quick head count: - how many of you are using the Cairo option in FLTK? Currently I use cairo with own hooks as I rely on distributed FLTK versions - namely v1.1.9. - how many are actively developing Cairo or plan to do so in the near future? I would like to be able to switch completely to Cairo for drawing code inside FLTK. Eigther by cairo's native API or even with FLTKs elder drawing API. I am trying to determine if and when we could move Cairo support into the new graphics driver system. You mean to make cairo the configurable default for drawing inside FLTK? I guess the difference, in repect to antialised lines, from FLTK to Qt or say Quartz would be much smaller on Linux, which is a good thing for broader user acceptance. - Matthias kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] XCode 3.2 external build debugging
Had someone success to debug external build FLTK applications, e.g. from FLTK's test folder, in Xcode 3.2 ? GDB reports only no symbol detected in Xcode. Details: fltk-1.3.x-r6943 ./configure --enable-debug (results in the -g and -arch i386 options) Xcode 3.2 $ file test/demo test/demo: Mach-O executable i386 $ nm test/demo ... 38fc T _main U _malloc ... Plain gdb, on the command line, does accept breakpoints but not in Xcode. So obviously the -g option created by FLTK's configure script does not suffice for Xcode. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OS Native Handles
Am 02.09.09, 18:12 -0700 schrieb Shon Pritchett: Can I control the level of AA applied somehow? I believe that's my last question and I'll stop bothering you all for a few moons. I am not shure which of the following calls does switch the line smoothing in my open source app, but here they are: glHint(GL_LINE_SMOOTH_HINT, GL_NICEST); glEnable(GL_LINE_SMOOTH); The above works after the GL context initialisation. Probably OpenGL knows other switches as well. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.development] [RFE] STR #2234: DOWN_FRAME default for fluids text widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2234 Version: 1.3-feature Fluid starts the Text_Display widget with a down frame. After changing the class to Fl_Multiline_Output, the frame remained and lead to a unuseable background. Text was drawn over text instead of first erasing the old background before drawing new text. The request is to change the default box type of the text editor and text display widgets in fluid to DOWN_BOX, instead of DOWN_FRAME. Link: http://www.fltk.org/str.php?L2234 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.general] Fl_Multiline_Output oddity
Dear list,
attached you find a small fluid example of Fl_Output's multiline mode
compared to the, should I say real(?), Fl_Multiline_Output.
The result of the examle is somewhat confusing as I had expected that
Fl_Multiline_Output works the same as in test/output.cxx . But here on a
Linux box with FLTKv1.1.9, it keeps old text where it is and draws the new
above with calling Fl_Multiline_Output-value(). So in this example the
numbers are all printed at once. A ~7kB screenshot is attached - hopefully
small enough to pass.
Any idea?
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
# data file for the Fltk User Interface Designer (fluid)
version 1.0109
header_name {.h}
code_name {.cxx}
decl {\#include stdio.h} {global
}
decl {\#include FL/Fl_Multiline_Output.H} {public global
}
Function {make_window()} {open
} {
Fl_Window {} {open
xywh {209 404 500 485} type Double visible
} {
Fl_Output multi_line_output {selected
xywh {25 30 450 165} type Multiline
}
Fl_Text_Display multi_line_output2 {
xywh {25 220 450 125} align 4
class Fl_Multiline_Output
}
Fl_Button {} {
label {Change ml_output above}
callback {static int i = 0;
static char text[64];
sprintf(text, a new number %d\\n a new line %d, i, i++ );
multi_line_output-value(text);
multi_line_output2-value(text);}
xywh {25 365 450 100}
}
}
}
Function {main()} {open C return_type int
} {
code {Fl_Window * w = make_window();
w-show();
return Fl::run();} {}
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Multiline_Output oddity
Am 06.08.09, 11:47 +0200 schrieb Kai-Uwe Behrmann: numbers are all printed at once. A ~7kB screenshot is attached - hopefully small enough to pass. The screenshot was srubbed and is placed here: http://www.behrmann.name/temp/multi_line_output_s.png ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Multiline_Output oddity
Am 06.08.09, 11:08 +0100 schrieb MacArthur, Ian (SELEX GALILEO, UK): The result of the examle is somewhat confusing as I had expected that Fl_Multiline_Output works the same as in test/output.cxx . But here on a Linux box with FLTKv1.1.9, it keeps old text where it is and draws the new above with calling Fl_Multiline_Output-value(). So in this example the numbers are all printed at once. A ~7kB screenshot is attached - hopefully small enough to pass. Any idea? You have the wrong box type set on your Fl_Multiline_Output widget - you have it set to a FRAME type rather than a BOX type, so the background is not being updated. If you set it ot a BOX type, it does work as intended. I did not set any box type myself. After checking I found, fluid starts the used Text_Display with a down frame. I changed the class to Fl_Multiline_Output but the frame remained and lead to the result. Perhaps fluid could be changed to start with a box instead of a frame for according widgets? This would be more logical. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] 16-bit PGM
FLTK is a toolkit and as almost all of these category of software not trimmed toward bit depth but for speed. For 16-bit per channel and higher processing most people use own routines, libraries like OpenEXR and the like. An option more and more deployed is OpenGL these days. FLTK provides at least good integration with OpenGL. I supect that FLTK drawing does not work on OpenGL contexts. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org Am 23.07.09, 09:05 -0700 schrieb Alvin: I am attempting to load a 16-bit PGM (max colours 65535) using Fl_PNM_Image and then access the raw 16-bit values. The image file does load and does Or is there some core need for 8-bit values...perhaps fl_draw_image()?? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] having the same colors in win/mac/linux (1.1.9)?
Am 07.05.09, 11:08 -0700 schrieb Jane: how can i make sure to have the exact same colors on all three platforms? If you mean exact, you would have to take the output device specific ICC colour profile into account. So far I do not know of a toolkit delivering this abstraction. Most are ignorant for colour management. My answere is not specific to FLTK. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [LOW] STR #2168: Fl_Help_View::topline case insensitive
Agreed, I must have overseen the otherwise obvious connection to HTML ;-) best regards Kai-Uwe Am 07.03.09, 15:32 -0800 schrieb Michael Sweet: [STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2168 Version: 1.3-current HTML anchors (targets) are defined to be case-insensitive, just like element names. Only XHTML has case-sensitive anchors... Link: http://www.fltk.org/str.php?L2168 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2168: Fl_Help_View::topline case insensitive
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2168 Version: 1.3-current Fl_Help_View::topline() should select a line according to the match to a given string. Unfortunedly the matching occurs non case sensitive and remains ambiguous for case variants. possible solution: in compare_targets() use strcmp instead of strcasecmp. The later is used in the other internal member functions. format() needs a different compare_func_t as it is working in a different scope. Link: http://www.fltk.org/str.php?L2168 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.general] fltk-1.3.x docu with comments - link dead
... as it says above. see: http://www.fltk.org/documentation.php/doc-1.3/index.html kind regards, Kai-Uwe ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] configure feature report / detection
configure gives for ./configure --enable-threads --enable-shared a Graphics: X11 while for ./configure --enable-threads --enable-xft --enable-shared --enable-gl --enable-xinerama a Graphics: X11+Xft+Xinerama Much better would be IMO a output, which shows in detail missing features like: Graphics: X11 Xft: NO Xinerama: NO The later two can be omitted on non X11 systems. The reason I bring this up is, that major distributions do not even know that antialiased font and Xinerama support exists in FLTK. This bring a od fashioned light not on the distribution but on FLTK, which is unfortune. For Linux/BSD distributions it would be fine to automaticaly check for Xft, threads, Xinerama as soon as shared libraries are requested (--enable-shared). Then this would be hopefully soon a non issue any more. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1 (or 1.3) and Cairo on OSX
Did you try the standard image surface to draw on? For X displaying its my favourite. The speed seems acceptable for non animations. A small test application can be found here: http://www.behrmann.name/index.php?option=com_weblinkstask=viewcatid=75id=149 It is not tested on osX, but should compile as a simple binary without the typical app bundle stuff. Am 15.09.08, 22:55 +0100 schrieb imacarthur: Anybody got any relevant pointers on Cairo? I've never really used Suggestions? Other than not using Cairo, since Quartz is anti-aliased anyway, and there are others ways to get PDF out of an OSX system... kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.bugs] [MOD] STR #2039: Xlib correct resize smaller patch
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2039
Version: 1.3-current
Here comes a patch to make FLTK windows aware of the correct resize,
especially a resize where no new area is covered.
Problem:
FLTK relies on a Expose event (12) from Xlib to redraw window content.
The Expose event is used to damage the to be redrawn area.
In the context of a resize with no new area covered, Xlib does not need to
send the expose event as no new area is to be redrawn. In case of FLTK
widgets this is a wrong assumption.
Solution (Xlib):
The Fl_Window::resize() funktion obtains one more exception in that a
check for is_a_enlarge is introduced and only for this case the
wait_for_expose variable is set to 1. So while passing the
Fl::flush() function the i-wait_for_expose exception does no longer
prevent a draw() in the according Fl_Window.
After applying the patch all windows behave under FVWM like expected.
Under KDE the windows work as usual. I tested with
Xorg-7.2/FVWM2/KDE3/twm.
Can you please test, that the patch has no side effects for win32 and osX?
Patch:
--- Fl_x.cxx_orig 2007-06-18 15:08:57.0 +0200
+++ Fl_x.cxx2008-09-11 16:58:15.0 +0200
@@ -1024,13 +1024,14 @@
void Fl_Window::resize(int X,int Y,int W,int H) {
int is_a_move = (X != x() || Y != y());
int is_a_resize = (W != w() || H != h());
+ int is_a_enlarge = (W w() || H h());
int resize_from_program = (this != resize_bug_fix);
if (!resize_from_program) resize_bug_fix = 0;
if (is_a_move resize_from_program) set_flag(FL_FORCE_POSITION);
else if (!is_a_resize !is_a_move) return;
if (is_a_resize) {
Fl_Group::resize(X,Y,W,H);
-if (shown()) {redraw(); i-wait_for_expose = 1;}
+if (shown()) {redraw(); if(is_a_enlarge) i-wait_for_expose = 1;}
} else {
x(X); y(Y);
}
Link: http://www.fltk.org/str.php?L2039
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.general] 1.1.7, 1.1.9 or 1.3.x can not resize windows?
I tested Greg E's scroll window. It does resize only in one direction (enlarging). Making the window smaller is not possible. Many examples in the FLTK's ./test folder dont work like help view, fluid and filebrowser. It is really confusing to read about complicated things like deriving fom Fl_Window and virtual resize() for something I had thought to be a basic feature (resize in two directions equally). And the recipes do not help in any way. A bug? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Change parent of a non-modal window? Fltk1
I tried Ian's dock_group toolbox http://www.imm.uklinux.net/dock_grp.html Simply add a second window before a call to a toolbox and the toolbox get bound to the second window instead of the first. This appears wired, but in the end may be intentional. It seems you target at something not typical supported by toolkits? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org Am 13.07.08, 15:51 -0700 schrieb Hartmut Sbosny: I have two windows, windowA and windowB, and a third one, toolWindow, which is non-modal and shall act as follows: If windowA gets the focus (by user click), toolWindow becomes non-modal in respect to windowA, if windowB gets the focus, toolWindow becomes non-modal in respect to windowB, i.e. the non-modal toolWindow shall change its parent or host. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OSX 10.5.3 and FL_Native_File_Chooser
Am 11.06.08, 17:10 +0100 schrieb MacArthur, Ian (SELEX GALILEO, UK): Next, this problem may have popped with the with 10.5.3 update. I'm just wondering if anybody has noticed any problems with FLTK and OpenGL because of this update. Hmm, I was going to ask what platform you are on, and say that I find the win32 chooser does seem to block events, but I infer that you are on OSX, so that's not going to be relevant. The file chooser is meant to be modal? So its pretty normal to stop everything else. One can see it as a feature. I had to fork the file selector to behave like a normal application window. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OS X: current working directory is always the root directory
A application started from the command line should point to the current directory, all others not. You can't start a application from the doc or a folder in Finder and expect it to work there in. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org Am 15.04.08, 20:38 +0100 schrieb F Andersen: I've written a small Mac-OS-X FLTK app that writes a file using fopen(), fwrite(), fclose(). The call to fopen is something like fopen(test.txt, w). The executable is on my desktop. When I run it, the file test.txt is written to the root directory '/' instead of my desktop. What can I do to make it write the file to the same directory as the compiled executable? I tried fopen(./test.txt, w) but the file still went to the root directory. I also tried fopen(~/Desktop/test.txt, w) but that crashed the program. I'm using fltk 1.1.7 on Mac OS X Tiger. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] 1.1.x-UTF8 hack brought up to r6041
Am 26.02.08, 05:22 -0800 schrieb Greg Ercolano: OK, I've added this to the TODO list for Fl_Native_File_Chooser: Christophe points out differences with FLTK's API: * show() works differently (Native's show() blocks) SOLUTION: Meh, not sure there is one, native choosers have to block. Probably you can add an call to switch between the native and the pure FLTK one? ... as a flag Fl_File_Chooser::FLTK ? Thus the FLTK own version would be available on osX and Windows too. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Nokia buys Trolltech/Qt
Am 11.02.08, 21:38 - schrieb imm: On 11 Feb 2008, at 19:43, Gonzalo Garramuño wrote: A more interesting comment about fltk (one of the two negative ones) is this one: Yes, I saw that too. Sadly true. fltk is on life support barely above abandonware levels. ... Currently what kills fltk as a useable toolkit is it's inability to gracefullly handle automatic relayout due to language/locale changes. I have nothing constructive to say here. I wonder what toolkit the author thought *did* handle that gracefully? I'd think Gtk does and expect Ot for this too. As long as UTF8 is not main stream, e.g. FLTK2, it is pointless to discuss this. It would be much work with small benefit. Even though it'd be desireable like the script engine. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Drag from FLTK app and Drop somewhere else
Am 19.12.07, 12:07 -0800 schrieb Alvin: Alvin wrote: But, more generically, how can I copy data from a FLTK app to some location on the computer using DnD mouse movements? I see this is fairly trivial when dealing with text, but what about raw data such as an image? Write a temporary file and paste only its file name? regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Drag from FLTK app and Drop somewhere else
Am 19.12.07, 17:50 -0800 schrieb Alvin: Kai-Uwe Behrmann wrote: Am 19.12.07, 12:07 -0800 schrieb Alvin: Alvin wrote: But, more generically, how can I copy data from a FLTK app to some location on the computer using DnD mouse movements? I see this is fairly trivial when dealing with text, but what about raw data such as an image? Write a temporary file and paste only its file name? You neigther confirmed nor denied. Hmm, lets give more details. I would work as follows: a: save the content of the Fl_Box to a image file (say png/jpeg) b: copy the images file name to the clipbord (as Konqueror would do) c: wait until the image is read by the reciver (as Firefox would read) d: delete the image file, as it is no longer needed kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] FLTK1 + UTF-8 distribution
Hello, FLTK-1.1.8 will sometimes be released I'd guess and of course welcome. Fascinatingly the utf-8 version is following close. Now that I used utf-8 in some of the applications I try to maintain, it would be of great help to have the UTF-8 version distributed. One technical point are the header files, which should not be intermixed between both FLTK1 versions. o saying that only one version should be installed seems not appropriate for two different packages o modifying the include path would be out of scope for most projects o adding a new prefix to the UTF-8 version requires some amount of work in the projects, which like to use the nice feature. Anyway this would be possible. o combine both with the headers installed from the UTF-8 version and both library versions One thing, which I am not shure whether it really helps is the fact of every project should be able to start a clean compile from scratch with FLTK1.UTF-8 . Would it make sense to not to install the backward style FLTK1 headers and just the backward libraries? Of course both version would be in need to bring into one package. The backward libraries would be named to all those old names, which make old applications happy and the utf-8 libs could pick something else, which it already does. Still I am not shure if this makes sense to a plug-in / host relation with one part being old style linked to say FLTK-1.1.7 and one to the UTF-8 enabled version. Would they fail badly or see I problems where no is to be expected? ... other options to make FLTK1-UTF8 distributeable ... thanks for the great work so far, Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] LSB and rpath
Is there a special reason to build FLTK with rpath. I saw it in the configure.in script. The reason is, I was asked to remove this option from my projects for inclusion into Fedora. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] FLTK1 + Cairo in motion
A rather monolythic Cairo example collects the features I needed for some work. As a side effect it can possibly show how to draw inside FLTK using Cairo. The red moving rectangle can even be moved around. In fact, I did not know how to close the green path curve. The included makefile compiles 3 versions (Xorg/Linux). Now the problems I found, which I hope to find help here: o image surface - works properly (speed slow?) o xlib surface - is slow o xrender surface - does not render to screen With the glitz suface I did not come that far. Any ideas about the speed improvement? Link: ftp://www.behrmann.name/pub/misc/cairo-in-motion-0.7.tar.gz kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org PS: for seeing a much more useable static SVG image in FLTK example: http://imago.functionalfuture.com ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK 1.1.7 and MacOs 10.5 (Leopard)
Am 27.10.07, 15:35 +0200 schrieb matthiasm: I have not tested a 10.5 app on 10.4 since I am lacking a 10.4 machine since my upgrade yesterday... ;-) You could put post a link to a 10.5 compiled app, possibly something from the test folder. I could check on a 10.4 ppc here. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf
Am 10.10.07, 19:41 +0100 schrieb imm: On 10 Oct 2007, at 10:51, Kai-Uwe Behrmann wrote: Am 10.10.07, 10:07 +0100 schrieb MacArthur, Ian (SELEX) (UK): The threads example does not build with --enable-threads. Not shure if it is related to the 1.1.8 build or your changes. OK - which platform is this, by the way? I've only got winXP boxes here just now, and they seem to be OK. I'll need to look into it this evening. openSUSE 10.2, IA32, gcc-4.1.2 Well, I just tested this on my FC7 box. Here's what I did. $ Created an empty directory. $ Downloaded the tarball from the web (to be sure I had the public version.) $ tar -jcf . $ autoconf $ ./configure --enable-xft --enable-threads $ make ... now I see it was a typo on my side (--enable--threads). Huuh I am pretty shure such typos will hit me again, so I wrote a patch against configure.in to summarise the final status, which is attached. I know plenty of projects using such a smaller overview at end of configure. Does this make sense to FLTK too? Kai-Uwe___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf
The threads example does not build with --enable-threads. Not shure if it is related to the 1.1.8 build or your changes. Kai-Uwe Am 07.10.07, 18:14 +0100 schrieb imm: http://www.imm.uklinux.net/fltk/fltk118-utf8-2007-10-07.tar.bz2 This tarball brings my codebase into sync with 1.1.8-r5951. ?? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf
Am 10.10.07, 10:07 +0100 schrieb MacArthur, Ian (SELEX) (UK): The threads example does not build with --enable-threads. Not shure if it is related to the 1.1.8 build or your changes. OK - which platform is this, by the way? I've only got winXP boxes here just now, and they seem to be OK. I'll need to look into it this evening. openSUSE 10.2, IA32, gcc-4.1.2 Kai-Uwe ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf - future directions
Am 29.09.07, 14:41 +0100 schrieb imm: Longer Term Objectives: really need to look at a complex text layout engine (http:// en.wikipedia.org/wiki/Complex_Text_Layout) of some sort, to cope with So - should fltk provide a CTL? Or should it simply provide the means to render the glyphs, and leave the user to provide the CTL layer? Frankly, I favour the latter approach (I see this as meaning that the people whose languages benefit from having a CTL will need to write the CTL - but they are also the people best placed to know what is needed.) Others may see this differently? I did briefly look at merging PanGo as a way to provide a well- established CTL for use with fltk. But that looked hard, so I quit. If someone else wants to take a run at that, or at something not derived from GTK (e.g. partly based on ICU http://www.icu- project.org/ or something) then that would be really good. I am very happy and thankful for your work on mixing UTF-8 into 1.1.x. Well, I'd would think a CTL could be for FLTK-utf-8 like UTF-8 was for FLTK. Unfortunedly it needs quite some work. On the other hand increases acceptance for FLTK. So is it probably the right thing for fltk2? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] static string array - dynamic gettext
Hello,
Fluid assists with gettext in UI strings. This is great.
Nethertheless it makes no difference between static and dynamic
structures. For instance it creates something like:
Fl_Menu_Item menu_[] = {
{_(File), 0, 0, 0, 64, FL_NORMAL_LABEL, 0, 14, 0},
{_(Open), 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{_(Save), 0, 0, 0, 128, FL_NORMAL_LABEL, 0, 14, 0},
{_(Quit), 0, (Fl_Callback*)cb_Quit, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0}
};
The underscore is a macro to the gettext function:
#define _(text) gettext(text)
This structure is created during start up of my applications in _init()
or likewise, much earlier before it reaches main(). main() would give me a
chance to setup gettext to run properly. Now simply having no translation
in the above structure would be not a huge problem. I can and do it later.
The problem I get is, that my different applications tend to setup static
memory different. In the end some build crash due to invalid pointers
passed to the gettext function.
Is it proper to say creating the _() entries in the above static
Fl_Menu_Item array is invalid?
Fltk-utf8-1.1.8, but seen since i18n support in Fluid.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org + www.cinepaint.org
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] static string array - dynamic gettext
Am 21.09.07, 23:38 -0700 schrieb Michael Sweet: Kai-Uwe Behrmann wrote: ... Is it proper to say creating the _() entries in the above static Fl_Menu_Item array is invalid? No, what you need to do is point _() to a function that does the setlocale() the first time around, and then returns the gettext() value. How to get the environment at this stage? At least the executeable path for a relocated initialisation would be desireable. Currently I parse from argv[0] in main(). But my major concern is, whether doing something before reaching main() is at all relyable. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] repeat_timeout and draw synchronisation
Sorry if this question was already handled on this list. Anyway: Currently I call in 1.1.7 Fl::add/repeat_timeout( t, coordinator_cb, myFl_GL_Window ); to update a GL window? The problem arises while calling myFl_GL_Window-redraw() from coordinator_cb. Sometimes the call does not reach to myFl_GL_Window-draw() on windows (vista msvc2005). It appears irregular. Sometimes it works. I have many Fl::wait()'s around in my code to update the UI. I avoid calling myFl_GL_Window-draw() directly as this was not recommended in many posts. How can I enshure the number of calls to draw() is a bit more synchron with coordinator_cb and all remaining events are flushed? Is it possible that callback timers get lost, beside omitting repeat_timeout? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf official release
Am 18.07.07, 13:22 +0100 schrieb MacArthur, Ian (SELEX) (UK): When can utf-8 enabled FLTK1 officially get released? That would be some time (hopefully shortly) after the regular 1.1.8 gets released, at a guess. In the meantime, if my patch works for you, then you can probably just go with that and hope! The question was more about distribution. Ok, it is better to wait for 1.1.8. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf official release
When can utf-8 enabled FLTK1 officially get released? I have ported the legacy CinePaint from gtk1 to gtk2 for the utf-8 support and would even more love to see the included FLTK plug-ins supporting utf-8. Other projects and translators wait for FLTK with utf-8 to appear. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org Am 14.07.07, 11:13 -0700 schrieb ian: http://www.imm.uklinux.net/fltk/fltk118-utf8-2007-07-14.tar.bz2 ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] make fails for FLPhoto [Fl_Spinner.H:131]
What gcc version is used on Slackware 12? FLPhoto 1.2 or 1.3 ... ? Am 09.07.07, 18:25 -0700 schrieb Reed: Hi, I'm trying to install FLPhoto on Slackware 12. I'm getting the following error after running make. Compiling image.cxx... image.cxx: In member function 'void flphoto::crop_update_cb(Fl_Widget*)': image.cxx:1427: error: no matching function for call to 'Fl_Spinner::maximum()' /usr/local/include/FL/Fl_Spinner.H:131: note: candidates are: void Fl_Spinner::maximum(double) image.cxx:1430: error: no matching function for call to 'Fl_Spinner::maximum()' /usr/local/include/FL/Fl_Spinner.H:131: note: candidates are: void Fl_Spinner::maximum(double) image.cxx:1432: error: no matching function for call to 'Fl_Spinner::maximum()' /usr/local/include/FL/Fl_Spinner.H:131: note: candidates are: void Fl_Spinner::maximum(double) image.cxx:1435: error: no matching function for call to 'Fl_Spinner::maximum()' /usr/local/include/FL/Fl_Spinner.H:131: note: candidates are: void Fl_Spinner::maximum(double) image.cxx:1453: error: no matching function for call to 'Fl_Spinner::maximum()' /usr/local/include/FL/Fl_Spinner.H:131: note: candidates are: void Fl_Spinner::maximum(double) image.cxx:1455: error: no matching function for call to 'Fl_Spinner::maximum()' /usr/local/include/FL/Fl_Spinner.H:131: note: candidates are: void Fl_Spinner::maximum(double) make: *** [image.o] Error 1 Has anyone dealt with this error before? I searched the site for Fl_Spinner but couldn't find a question about this issue. Thank you for your time. ~Reed ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Flmm Tabs before last tab fix
The not so last tab is hidden in case the last tab is too long.
change in flmm-1.1.x/src/Flmm_Tabs.cxx
- } else if (selected=children()-2) {
+ } else if (selected=children()-1) {
// last tab is selected: make last tab right aligned
Thanks for the widgets!
best regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org + www.cinepaint.org
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] file selection order [1.1.x]
Am 29.06.07, 13:09 +0200 schrieb Kai-Uwe Behrmann: Had someone success to preserve the user selection order in the file chooser? Switched Fl_File_Chooser::fileList-when(FL_WHEN_CHANGED) in a modified Fl_File_Chooser class and added a callback to Fl_File_Chooser::fileList to observe any changes in the selection list. The changes are sorted into an external list according to MyFl_File_Chooser-value(). That helped. regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [LOW] STR #1707: initial hidden AGL window not visible
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1707
Version: 1.1-current
Link: http://www.fltk.org/str.php?L1707
Version: 1.1-current//
// $Id: cube.cxx 5519 2006-10-11 03:12:15Z mike $
//
// Another forms test program for the Fast Light Tool Kit (FLTK).
//
// Modified to have 2 cubes to test multiple OpenGL contexts
//
// Copyright 1998-2005 by Bill Spitzak and others.
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Library General Public
// License as published by the Free Software Foundation; either
// version 2 of the License, or (at your option) any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Library General Public License for more details.
//
// You should have received a copy of the GNU Library General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
// USA.
//
// Please report all bugs and problems on the following page:
//
// http://www.fltk.org/str.php
//
#include config.h
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
#include FL/Fl_Button.H
#include FL/Fl_Radio_Light_Button.H
#include FL/Fl_Slider.H
#include stdlib.h
#if !HAVE_GL
class cube_box : public Fl_Box {
public:
double lasttime;
int wire;
int hide_me;
double size;
double speed;
cube_box(int x,int y,int w,int h,const char *l=0)
:Fl_Box(FL_DOWN_BOX,x,y,w,h,l){
label(This demo does\nnot work without GL);
}
};
#else
#include FL/Fl_Gl_Window.H
#include FL/gl.h
class cube_box : public Fl_Gl_Window {
void draw();
int handle(int);
public:
double lasttime;
int wire;
int hide_me;
double size;
double speed;
cube_box(int x,int y,int w,int h,const char *l=0)
: Fl_Gl_Window(x,y,w,h,l) {lasttime = 0.0;}
};
/* The cube definition */
float v0[3] = {0.0, 0.0, 0.0};
float v1[3] = {1.0, 0.0, 0.0};
float v2[3] = {1.0, 1.0, 0.0};
float v3[3] = {0.0, 1.0, 0.0};
float v4[3] = {0.0, 0.0, 1.0};
float v5[3] = {1.0, 0.0, 1.0};
float v6[3] = {1.0, 1.0, 1.0};
float v7[3] = {0.0, 1.0, 1.0};
#define v3f(x) glVertex3fv(x)
void drawcube(int wire) {
/* Draw a colored cube */
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(0,0,255);
v3f(v0); v3f(v1); v3f(v2); v3f(v3);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(0,255,255); v3f(v4); v3f(v5); v3f(v6); v3f(v7);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(255,0,255); v3f(v0); v3f(v1); v3f(v5); v3f(v4);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(255,255,0); v3f(v2); v3f(v3); v3f(v7); v3f(v6);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(0,255,0); v3f(v0); v3f(v4); v3f(v7); v3f(v3);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(255,0,0); v3f(v1); v3f(v2); v3f(v6); v3f(v5);
glEnd();
}
void cube_box::draw() {
lasttime = lasttime+speed;
if (!valid()) {
glLoadIdentity();
glViewport(0,0,w(),h());
glEnable(GL_DEPTH_TEST);
glFrustum(-1,1,-1,1,2,1);
glTranslatef(0,0,-10);
gl_font(FL_HELVETICA_BOLD, 16 );
}
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glPushMatrix();
glRotatef(float(lasttime*1.6),0,0,1);
glRotatef(float(lasttime*4.2),1,0,0);
glRotatef(float(lasttime*2.3),0,1,0);
glTranslatef(-1.0, 1.2f, -1.5);
glScalef(float(size),float(size),float(size));
drawcube(wire);
glPopMatrix();
gl_color(FL_GRAY);
glDisable(GL_DEPTH_TEST);
gl_draw(wire ? Cube: wire : Cube: flat, -4.5f, -4.5f );
glEnable(GL_DEPTH_TEST);
}
int cube_box::handle(int e) {
switch (e) {
case FL_ENTER: cursor(FL_CURSOR_CROSS); break;
case FL_LEAVE: cursor(FL_CURSOR_DEFAULT); break;
}
return Fl_Gl_Window::handle(e);
}
#endif
Fl_Window *form;
Fl_Slider *speed, *size;
Fl_Button *button, *wire, *flat, *hide;
cube_box *cube, *cube2;
void makeform(const char *name) {
form = new Fl_Window(510+390,390,name);
new Fl_Box(FL_DOWN_FRAME,20,20,350,350,);
new Fl_Box(FL_DOWN_FRAME,510,20,350,350,);
speed = new Fl_Slider(FL_VERT_SLIDER,390,120,40,190,Speed);
size = new Fl_Slider(FL_VERT_SLIDER,450,120,40,190,Size);
wire = new Fl_Radio_Light_Button(390,20,100,30,Wire);
flat = new Fl_Radio_Light_Button(390,50,100,30,Flat);
hide = new Fl_Light_Button(390,80,100,30,Hide);
button = new Fl_Button(390,340,100,30,Exit);
cube = new cube_box(23,23,344,344, 0);
cube2 = new cube_box(513,23,344,344, 0);
Fl_Box *b = new Fl_Box(FL_NO_BOX,cube-x(),size-y(),
cube-w(),size-h(),0);
form-resizable(b);
b-hide();
form-end();
}
int main(int argc, char **argv) {
makeform(argv[0]);
speed-bounds(4,0);
speed-value(cube-speed = cube2-speed = 1.0);
Re: [fltk.bugs] [LOW] STR #1707: initial hidden AGL window not visible
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1707 Version: 1.1-current cube_v2.cxx has a set_visible() call included around line 192. It is switchable by a macro. On linux all is fine with and without set_visible(). On osX, I need set_visible() to show the GL view again. As well the second cube view behaves not normal anymore. Possibly some context switching works not cleanly. Link: http://www.fltk.org/str.php?L1707 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.general] fltk-1.1.8-utf [osX visible flag]
On osX I find regulary that my GL views look for the wrong variable to the
Fl_Widget::visible() call. Xcode shows Fl.H:163 .. event_x() {return e_y:}
which seems odd.
I tried to find concurrent header files in the file system but could not
detect so far. Mentioned here, as it appreared since my switch to the utf8
versions.
Am 23.06.07, 10:00 -0400 schrieb ian:
http://www.imm.uklinux.net/fltk/fltk118-utf8-2007-06-23.tar.bz2
Thanks
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org + www.cinepaint.org
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf [osX visible flag]
Am 25.06.07, 09:36 +0100 schrieb MacArthur, Ian (SELEX) (UK):
On osX I find regulary that my GL views look for the wrong
variable to the
Fl_Widget::visible() call. Xcode shows Fl.H:163 .. event_x()
{return e_y:}
which seems odd.
I tried to find concurrent header files in the file system
but could not
detect so far. Mentioned here, as it appreared since my
switch to the utf8
versions.
Curious - I do not think I have changed the GL implementation... I will
try and check that out.
Do all the GL demo's from the test folder work for you? They work OK for
me - but they perhaps are not exercising all the functions that you
need...
Yes, the demos are ok. But they dont hide() and show() the FL_GL_Window's.
Thats where I get the strange osX behaviour. Possibly the whole thing is
somehow related to a STR I recently filled:
http://www.fltk.org/str.php?L1707
(Note: I have been trying to keep my 1.1.8 baseline in sync with the
main tree, but no changes have been introduced in that area recently
anyway...)
Hmm, I checked against 1.1.7. Have to compile a official 1.1.8 version
on osX. ... needs some time on a ibook.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org + www.cinepaint.org
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf [UTF-8 macro]
Ian, what would you recommend to check for utf-8 enabled FLTK. The fltk-config script does not give any hint. As well a check for utf-8 would be nice to have at runtime. One fragile possibility could be to tell Fl::version() to put out 1.010850 instead of 1.010800 But not shure if this is relyable through all the FLTK versions around. Currently I check statically for the _Xutf8_h macro after including FL/x.H. But this seems not stable, as you indicated to remove or merge some files. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8 STR 1707
Am 25.06.07, 12:54 +0100 schrieb MacArthur, Ian (SELEX) (UK):
http://www.fltk.org/str.php?L1707
Hmm, I don't think so but... I can't reproduce the behaviour you
describe in the STR either - can you post a minimal working example of
what you do, either here or in the STR, for people to take a look at?
Here is a modified cube.cxx example:
http://www.fltk.org/strfiles/1707/cube_v2.cxx
... especially around line 192.
The behaviour is the same in the official 1.1.8 line. It seems indeed not
related to your utf-8 work.
Ian, thanks for your comments.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org + www.cinepaint.org
//
// $Id: cube.cxx 5519 2006-10-11 03:12:15Z mike $
//
// Another forms test program for the Fast Light Tool Kit (FLTK).
//
// Modified to have 2 cubes to test multiple OpenGL contexts
//
// Copyright 1998-2005 by Bill Spitzak and others.
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Library General Public
// License as published by the Free Software Foundation; either
// version 2 of the License, or (at your option) any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Library General Public License for more details.
//
// You should have received a copy of the GNU Library General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
// USA.
//
// Please report all bugs and problems on the following page:
//
// http://www.fltk.org/str.php
//
#include config.h
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
#include FL/Fl_Button.H
#include FL/Fl_Radio_Light_Button.H
#include FL/Fl_Slider.H
#include stdlib.h
#if !HAVE_GL
class cube_box : public Fl_Box {
public:
double lasttime;
int wire;
int hide_me;
double size;
double speed;
cube_box(int x,int y,int w,int h,const char *l=0)
:Fl_Box(FL_DOWN_BOX,x,y,w,h,l){
label(This demo does\nnot work without GL);
}
};
#else
#include FL/Fl_Gl_Window.H
#include FL/gl.h
class cube_box : public Fl_Gl_Window {
void draw();
int handle(int);
public:
double lasttime;
int wire;
int hide_me;
double size;
double speed;
cube_box(int x,int y,int w,int h,const char *l=0)
: Fl_Gl_Window(x,y,w,h,l) {lasttime = 0.0;}
};
/* The cube definition */
float v0[3] = {0.0, 0.0, 0.0};
float v1[3] = {1.0, 0.0, 0.0};
float v2[3] = {1.0, 1.0, 0.0};
float v3[3] = {0.0, 1.0, 0.0};
float v4[3] = {0.0, 0.0, 1.0};
float v5[3] = {1.0, 0.0, 1.0};
float v6[3] = {1.0, 1.0, 1.0};
float v7[3] = {0.0, 1.0, 1.0};
#define v3f(x) glVertex3fv(x)
void drawcube(int wire) {
/* Draw a colored cube */
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(0,0,255);
v3f(v0); v3f(v1); v3f(v2); v3f(v3);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(0,255,255); v3f(v4); v3f(v5); v3f(v6); v3f(v7);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(255,0,255); v3f(v0); v3f(v1); v3f(v5); v3f(v4);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(255,255,0); v3f(v2); v3f(v3); v3f(v7); v3f(v6);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(0,255,0); v3f(v0); v3f(v4); v3f(v7); v3f(v3);
glEnd();
glBegin(wire ? GL_LINE_LOOP : GL_POLYGON);
glColor3ub(255,0,0); v3f(v1); v3f(v2); v3f(v6); v3f(v5);
glEnd();
}
void cube_box::draw() {
lasttime = lasttime+speed;
if (!valid()) {
glLoadIdentity();
glViewport(0,0,w(),h());
glEnable(GL_DEPTH_TEST);
glFrustum(-1,1,-1,1,2,1);
glTranslatef(0,0,-10);
gl_font(FL_HELVETICA_BOLD, 16 );
}
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glPushMatrix();
glRotatef(float(lasttime*1.6),0,0,1);
glRotatef(float(lasttime*4.2),1,0,0);
glRotatef(float(lasttime*2.3),0,1,0);
glTranslatef(-1.0, 1.2f, -1.5);
glScalef(float(size),float(size),float(size));
drawcube(wire);
glPopMatrix();
gl_color(FL_GRAY);
glDisable(GL_DEPTH_TEST);
gl_draw(wire ? Cube: wire : Cube: flat, -4.5f, -4.5f );
glEnable(GL_DEPTH_TEST);
}
int cube_box::handle(int e) {
switch (e) {
case FL_ENTER: cursor(FL_CURSOR_CROSS); break;
case FL_LEAVE: cursor(FL_CURSOR_DEFAULT); break;
}
return Fl_Gl_Window::handle(e);
}
#endif
Fl_Window *form;
Fl_Slider *speed, *size;
Fl_Button *button, *wire, *flat, *hide;
cube_box *cube, *cube2;
void makeform(const char *name) {
form = new Fl_Window(510+390,390,name);
new Fl_Box(FL_DOWN_FRAME,20,20,350,350,);
new Fl_Box(FL_DOWN_FRAME,510,20,350,350,);
speed = new Fl_Slider(FL_VERT_SLIDER,390,120,40,190,Speed);
size = new Fl_Slider(FL_VERT_SLIDER,450,120,40,190,Size);
wire = new Fl_Radio_Light_Button(390,20,100,30,Wire);
flat = new Fl_Radio_Light_Button
Re: [fltk.general] rectangle on button after mousepress
Am 23.06.07, 11:55 +0100 schrieb imm: We are talking about the dotted-line visible focus rectangle? Yes. Are you trying to force the rectangle to move to another button? If so I think widget-take_focus(); is what you want. Oh, fine this is it. Thanks to you and Alwin, for your help. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf
Am 21.06.07, 09:19 +0100 schrieb MacArthur, Ian (SELEX) (UK): Anyway, I then tarball the clean tree with a simple: tar -jcf clean-tree.tar.bz2 clean-tree-dir/ Ok, I made a make clean; tar czf ... and copied to osX. It works as is required for my personal use. Is that the information you needed? Thanks. Yes. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf
Am 21.06.07, 07:52 +0200 schrieb Kai-Uwe Behrmann:
as well the Fl_Help_View.cxx quotation gets fixed by the following:
@@ -2198,10 +2199,7 @@
if (qch 0)
*s++ = '';
else {
-int l;
-l = fl_ucs2utf((unsigned int) qch, s);
-if (l 1) l = 1;
-s += l;
+*s++ = qch;
ptr = strchr(ptr, ';') + 1;
}
}
I am not shure if thats enough. The belonginh int qch = quote_char(ptr);
is used at many places. Possibly there similiar changes must be done as
well + removing the __APPLE__ version of the ENC macro.
As long as I know too less about this stuff, I dont like to suggest a
solution.
Indeed I removed the __APPLE__ version of ENC in front of quote_char(),
and after that the ae oe ue glyphs are displayed correctly on osX.
Seems I'll go to publish a release candidate soon :-)
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org + www.cinepaint.org
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf :: html_view
...modified the subject line to better follow up later. Am 21.06.07, 09:10 +0100 schrieb MacArthur, Ian (SELEX) (UK): I guess that the ideal is to get the html page converted into utf8 sequences, then the conversion table will go away anyway, since the mapping from html codes to local charset will disappear. Or something... The quote_char function sits in the middle of format(). So I think with the patch suggested, and possibly repeating it at other places as well, it is pretty much what you want: Convert from html ...; descriptions to utf8 and place the later into the text. At least that solution is already choosen in the fltk2 tree. Thats where I have copied. The table in quote_char() is already a more elegant solution. I will come with a complete diff for that later this day. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf [two svn tree diversion]
Am 21.06.07, 10:59 +0200 schrieb Duncan Gibson: Ian wrote: However, what I *actually* do is have a working tree and a clean copy that has never been built. Once my working tree is all synched up with my local svn, and the build runs OK, I use meld to synch the build tree with the clean tree, then tarball the clean tree. A bit off-topic, but how do you do manage two svn trees? I have often thought that it would be useful to have a two-stage source control system where you can 'work locally' and do minor checkins as you work and refactor and once you are happy with the overall result do a major checkin that wipes the minors. It would save a lot of dated copies of files. I never thought about using two systems in parallel. Of course allways an interessting point for larger projects. I remember Robert L. Krawitz talking often about a sandbox. Seems a second tree he is working on to test things. Not shure whether it is maintained in a automatical fashion. Carl Worth seems to be happy with git from kernel.org after a extensive search for something useable to maintain several states of his development. This would be the one for me to invest, when I find the time for. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf :: html_view
Here is the patch, almost taken from fltk2:
--- fltk118-utf8-2007-06-20_orig/src/Fl_Help_View.cxx 2007-06-20
21:22:51.0 +0200
+++ fltk118-utf8-2007-06-20/src/Fl_Help_View.cxx2007-06-21
17:28:35.973870720 +0200
@@ -2199,10 +2199,7 @@
if (qch 0)
*s++ = '';
else {
-int l;
-l = fl_ucs2utf((unsigned int) qch, s);
-if (l 1) l = 1;
-s += l;
+*s++ = qch;
ptr = strchr(ptr, ';') + 1;
}
}
@@ -3195,11 +3192,9 @@
#ifdef ENC
# undef ENC
#endif
-#ifdef __APPLE__
-# define ENC(a, b) b
-#else
+
+// part b in the table seems to be mac_roman - beku
# define ENC(a, b) a
-#endif
//
// 'quote_char()' - Return the character code associated with a quoted char.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org + www.cinepaint.org
Am 21.06.07, 11:10 +0200 schrieb Kai-Uwe Behrmann:
text. At least that solution is already choosen in the fltk2 tree. Thats
where I have copied.
The table in quote_char() is already a more elegant solution. I will come
with a complete diff for that later this day.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf
Am 20.06.07, 16:45 -0400 schrieb Ian MacArthur: This has Kai-Uwe Behrmann's shared-libs fix applied, and some work to get DnD working again on win32 (DnD still broken on X though...) Did not yet test new ball. In one from yesterday DnD works on at least X11/xorg-6.8. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org + www.cinepaint.org ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk-1.1.8-utf
Hello Ian,
found a compile hanging in dnd-test.cxx to fix with:
@@ -1,8 +1,8 @@
/* Drag and Drop test demo. */
#include stdio.h
#include FL/Fl.H
-#include FL/Fl_Window.h
-#include FL/Fl_Box.h
+#include FL/Fl_Window.H
+#include FL/Fl_Box.H
class Sender : public Fl_Box {
public:
as well the Fl_Help_View.cxx quotation gets fixed by the following:
@@ -2198,10 +2199,7 @@
if (qch 0)
*s++ = '';
else {
-int l;
-l = fl_ucs2utf((unsigned int) qch, s);
-if (l 1) l = 1;
-s += l;
+*s++ = qch;
ptr = strchr(ptr, ';') + 1;
}
}
I am not shure if thats enough. The belonginh int qch = quote_char(ptr);
is used at many places. Possibly there similiar changes must be done as
well + removing the __APPLE__ version of the ENC macro.
As long as I know too less about this stuff, I dont like to suggest a
solution.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org + www.cinepaint.org
Am 20.06.07, 16:45 -0400 schrieb Ian MacArthur:
New tarball is at:
http://www.imm.uklinux.net/fltk/fltk118-utf8-2007-06-20.tar.bz2
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
