[fltk.general] Fl_Text_Display::xy_to_rowcol
Hi, (I starting to use Fl_Text_Display/Editor to do something like NEdit, so I have a lot of questions) I was wondering why xy_to_rowcol is protected ? or is there a way to have the current line displayed ? For column, there is position_to_xy and x_to_col, but found nothing for y_to_line ? Regards, David ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Text_Display::xy_to_rowcol
For my need, I have put int position_to_linecol(int pos, int* lineNum, int* column) const; public instead of protected in my local repository may something like this could be useful for someone else. Le 18/08/2012 09:24, David FLEURY a écrit : > Hi, > > (I starting to use Fl_Text_Display/Editor to do something like NEdit, so > I have a lot of questions) > > I was wondering why xy_to_rowcol is protected ? > or is there a way to have the current line displayed ? > > For column, there is position_to_xy and x_to_col, but found nothing for > y_to_line ? > > Regards, > David > > ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Callback on Fl_Menu_Item (FL_SUBMENU)
On 17.08.2012, at 22:22, David FLEURY wrote: > Hi, > > In the Fl_Menu_Bar, when adding an item which has a FL_SUBMENU flag on, > can I have a callback called (using a specific when) ? > I have try callback available on Fl_Menu_Item, but it's seems to work > only on "regular" Fl_Menu_Item. > > I am trying to recompute the submenu when the user will open the submenu > (An open previous file list ( in a Nedit way) No, AFAIK, the callback on a submenu item is never called. It could be changed in the library code though. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Text_Display::xy_to_rowcol
On 18.08.2012, at 09:24, David FLEURY wrote:
> Hi,
>
> (I starting to use Fl_Text_Display/Editor to do something like NEdit, so
> I have a lot of questions)
>
> I was wondering why xy_to_rowcol is protected ?
> or is there a way to have the current line displayed ?
>
> For column, there is position_to_xy and x_to_col, but found nothing for
> y_to_line ?
Congratulations on scraping the paint on the most complex and convoluted widget
in FLTK (besides HelpView, maybe) ;-)
TextDisplay and TextEdit are based on an old version of NEdit with permission
of the authors. Originally it was a source code editor wfor ASCII characters
and monospaced fonts. Proportional font support was added later and has
generated a lot of special cases and places where we need to measure and count
instead of just ,ultiplying the number of bytes by a character width to get
pixel positions.
A couple of years ago, I made it worse by adding UTF8 support to this widget,
generating a lot of byte counting on top of pixel counting. You are welcome ;-)
What I want to say is, that a lot of interfaces or non obvious, and a lot of
methods may take more time than it is obvious. However, I think that there is a
pretty complete set of methods for this class. You are probably looking for
this function:
/**
\brief Translate pixel coordinates into row and column.
Translate window coordinates to the nearest row and column number for
positioning the cursor. This, of course, makes no sense when the font is
proportional, since there are no absolute columns. The parameter posType
specifies how to interpret the position: CURSOR_POS means translate the
coordinates to the nearest position between characters, and CHARACTER_POS
means translate the position to the nearest character cell.
\param X, Y pixel coordinates
\param[out] row, column nearest row and column
\param posType CURSOR_POS or CHARACTER_POS
*/
void fltk3::TextDisplay::xy_to_rowcol( int X, int Y, int *row,
int *column, int posType ) const {
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Callback on Fl_Menu_Item (FL_SUBMENU)
Le 18/08/2012 12:16, Matthias Melcher a écrit : > No, AFAIK, the callback on a submenu item is never called. It could be > changed in the library code though. Ok, I will see. but I try to do the best I could to not patch the ftlk 1.3.0 on my side. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Text_Display::xy_to_rowcol
> > Congratulations on scraping the paint on the most complex and convoluted > widget in FLTK (besides HelpView, maybe) ;-) Quite complex indeed... > > TextDisplay and TextEdit are based on an old version of NEdit with permission > of the authors. Originally it was a source code editor wfor ASCII characters > and monospaced fonts. Proportional font support was added later and has > generated a lot of special cases and places where we need to measure and > count instead of just ,ultiplying the number of bytes by a character width to > get pixel positions. I was using NEdit original code, and port some of it to FLTK. So I have seen that Fl_Text_Editor was a port of testDisp/textBuf from NEdit. > A couple of years ago, I made it worse by adding UTF8 support to this widget, > generating a lot of byte counting on top of pixel counting. You are welcome > ;-) A great job. > > What I want to say is, that a lot of interfaces or non obvious, and a lot of > methods may take more time than it is obvious. However, I think that there is > a pretty complete set of methods for this class. You are probably looking for > this function: Yes, I have found these, too: int position_to_line (int pos, int *lineNum) const int position_to_linecol (int pos, int *lineNum, int *column) const but they are protected and not public...(I am using fltk 1.3.0 only at this time) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Text_Display::xy_to_rowcol
On 18 Aug 2012, at 15:13, David FLEURY wrote: > > Yes, I have found these, too: > int position_to_line (int pos, int *lineNum) const > int position_to_linecol (int pos, int *lineNum, int *column) const > > but they are protected and not public...(I am using fltk 1.3.0 only at > this time) ISTR that when I made an editor based on Fl_Text_* (now long since discarded, since others have built better editors than I have ever managed...) that I ended up having to derive my own classes from the FL ones anyway, to add various tweaks and helper functions, so then adding methods to access the protected members was trivial. That can work for your case too? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FTLK performance on Linux.
On 17 Aug 2012, at 19:35, Greg Ercolano wrote: > On 08/17/12 05:06, MacArthur, Ian (SELEX GALILEO, UK) wrote: >> Just for kicks'n'giggles I ported the code to WinXP using the >> QueryPerformanceCounter() API to get timings, and I get... >> [..] >> ian.macarthur@DESDAF599172 /d/examples/qix-win-times >> $ ./qix >> New control cost 0.02(ms) >> Show window cost 21.23(ms) >> [..] > > Here's what I get on centos 5.6 on a 1.8ghz mac mini: > > 08/17/12 11:28:22 /usr/local/src/fltk-1.3.x-svn/examples > [erco@tahoe] 127 # ./foo > New control cost 0(ms) > Show window cost 109(ms) <-- FIRST RUN > > 08/17/12 11:28:29 /usr/local/src/fltk-1.3.x-svn/examples > [erco@tahoe] 128 # ./foo > New control cost 0(ms) > Show window cost 11(ms) <-- > > 08/17/12 11:28:31 /usr/local/src/fltk-1.3.x-svn/examples > [erco@tahoe] 129 # ./foo > New control cost 0(ms) > Show window cost 10(ms) <-- > > That first run of 109ms shows the overhead of pulling the binary off > disk, > and the subsequent runs are shaving off 100ms because they're obviously > running > from the disk cache, such that it's only 10ms. Huh! That's odd - but makes sense I guess. I have mainly been testing by running " make && ./qix " so that tends to mean the binary blob is already in memory on the first run anyway, so I'm not seeing a hit from loading/caching on first run... Well, I guess that might be why. I should try to run it after the system has had a long time to forget, see if I can see a hit on the first invocation. And probably need to break out strace or etc. (as I assume Matthias did!) and see where the time is really going anyway. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Callback on Fl_Menu_Item (FL_SUBMENU)
On 08/18/12 03:16, Matthias Melcher wrote: > > On 17.08.2012, at 22:22, David FLEURY wrote: > >> Hi, >> >> In the Fl_Menu_Bar, when adding an item which has a FL_SUBMENU flag on, >> can I have a callback called (using a specific when) ? >> I have try callback available on Fl_Menu_Item, but it's seems to work >> only on "regular" Fl_Menu_Item. >> >> I am trying to recompute the submenu when the user will open the submenu >> (An open previous file list ( in a Nedit way) > > No, AFAIK, the callback on a submenu item is never called. It could be > changed in the library code though. I usually repopulate things like 'File>Recent' submenus at the time the user opens the files.. (eg. user opens a file, add it to the Recent menu..) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Callback on Fl_Menu_Item (FL_SUBMENU)
Le 18/08/2012 21:07, Greg Ercolano a écrit : > I usually repopulate things like 'File>Recent' submenus at the time > the user opens the files.. (eg. user opens a file, add it to the Recent > menu..) Yes, this is what I will do. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Text_Display::xy_to_rowcol
Le 18/08/2012 20:51, Ian MacArthur a écrit : > ISTR that when I made an editor based on Fl_Text_* (now long since discarded, > since others have built better editors than I have ever managed...) that I > ended up having to derive my own classes from the FL ones anyway, to add > various tweaks and helper functions, so then adding methods to access the > protected members was trivial. > > That can work for your case too? Yes, I will do this. The less the do, the less there are bugs in my code. I am trying to learn FLTK the hard. FLTK is quite interesting. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FTLK performance on Linux.
On 08/18/12 11:56, Ian MacArthur wrote: >> That first run of 109ms shows the overhead of pulling the binary off >> disk, >> and the subsequent runs are shaving off 100ms because they're obviously >> running >> from the disk cache, such that it's only 10ms. > > Huh! That's odd - but makes sense I guess. > > I have mainly been testing by running " make && ./qix " so that tends to mean > the > binary blob is already in memory on the first run anyway, so I'm not seeing a > hit from loading/caching on first run... > Well, I guess that might be why. Pretty sure that's due to separate read/write caches. Caching for reads/writes are usually handled separately. The 'make' does a write only, running the binary does the read. But I suppose if you had in your makefile something that read the binary after it was generated, that'd take care of getting it in the read cache. > I should try to run it after the system has had a long time to forget, see if > I can see a hit on the first invocation. I don't think it's so much how long to wait, as how much activity expires the cache. I would think loading a really large file would cause the old cache to dump in favor of the new larger activity. Or running a binary that uses a lot of free ram would dump the cache. Depends on free mem; if there's a lot of free mem (which is used as disk cache on linux IIRC), the caches of old data might stay for a long while. > And probably need to break out strace or etc. (as I assume Matthias did!) and > see where the time is really going anyway. Write/read caching is done at the kernel level, so I don't think you'll see any of that with strace(1) which just traces the user mode system call interface. Perhaps dtrace(1) has hooks in the kernel for this.. not sure. Tracing the disk cache might be tricky. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] New HTML Widget
I don't know amaya render but between tkhtml3 and dillo the tkhtml3 has a much better render than dillo. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FTLK performance on Linux.
On 18 Aug 2012, at 20:25, Greg Ercolano wrote: >> >> And probably need to break out strace or etc. (as I assume Matthias did!) >> and see where the time is really going anyway. > > Write/read caching is done at the kernel level, so I don't think you'll > see > any of that with strace(1) which just traces the user mode system call > interface. > > Perhaps dtrace(1) has hooks in the kernel for this.. not sure. > Tracing the disk cache might be tricky. Yes, I think you are right. Overall though, maybe that does not matter - probably strace can show us where the delays are, I guess, that might be enough? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FTLK performance on Linux.
On 08/18/12 13:28, Ian MacArthur wrote: > > On 18 Aug 2012, at 20:25, Greg Ercolano wrote: >>> >>> And probably need to break out strace or etc. (as I assume Matthias did!) >>> and see where the time is really going anyway. >> >> Write/read caching is done at the kernel level, so I don't think you'll >> see >> any of that with strace(1) which just traces the user mode system call >> interface. >> >> Perhaps dtrace(1) has hooks in the kernel for this.. not sure. >> Tracing the disk cache might be tricky. > > Yes, I think you are right. > > Overall though, maybe that does not matter - probably strace can show us > where the delays are, I guess, that might be enough? Oh, you mean delays in the commands FLTK is running, and not the speed caused by the binary loading.. Yes, 'strace -tt cmd [args]' might be good at showing what's taking so long. I often like to use gprof; just compile+link with -pg, and then 'gprof ./cmd [args..]' ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How to make a callback for fullscreen button ofthe main FLTK window?
On 26.07.2012 10:16, MacArthur, Ian (SELEX GALILEO, UK) wrote: >> What I want is, when i click the full-screen button of the main window, it >> calls my own written callback. Is it possible ? >> I want to resize the main window as I want. So, I have to give one >> callback to resize it. >> Currently, what I am doing is, I create a button below the fullscreen >> button to resize it. It looks odd, so can I make a callback for fullscreen >> button of the main window? > > I don't think there's a way (in fltk) to hook the buttons that are in the > window decorations (other then the window close event) as they are provided > by the platform and the WM rather than by fltk itself. Well, there's no direct way to do it with a button callback, but as usual there's something the OP can do: derive one's own window class and overwrite the resize() method. With a little educated guessing (comparing the requested window size with the screen dimensions), one could find out if the user requested the full screen size. OTOH, I didn't really understand what the OP wanted to achieve... -- Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
