On 05.04.2010, at 09:17, Duncan Gibson wrote:
There's a lot of balls in the air right now; 1.1.x has supposedly
frozen, and 1.3.x is still in dev.. so users will want to know what
to do if e.g. 1.1.10 won't build on the latest release of linux.
Their only option it seems would be to move to
I just want to make sure 1.3 gets finished and released first.
So do I.
Though I think we are very close.
The work that Manolo et al have done has resolved the building issues on
64-bit OSX, so that was the only big platform stopper.
Maybe that's enough to make a first release and get it out
1: Greg's right. We should finish 1.3 first and release at least 1.3.0
Yes. Though I think we are maybe near enough already...
2: the porting is stupid boring manual labour ;-), basically
a huge find and replace, which must be fully automatic
Though hopefully without breaking the
According to the current poll, we have over a thousand users, and only
38 STRs and 11 RFEs for them to get involved with. Come on people!
Let's eat that elephant one STR burger at a time...
Since I posted this we're down to 34 STRs and 11 RFEs :-)
Go! FLTK-1.3.x, Go!
D.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1758
Version: 1.3-feature
I would not fix this. Any version beyond 1.3.0 should feature the FLTK 2
menu system where menus are simply children of the Menu widget. All
Matthias Melcher wrote:
Related to FLTK 3: since I have touched EVERY file of FLTK3 anyways, there is
no need to keep history of a file or do a diff at some point. That would be a
nice occasion to run some app that will re-indet the files.
Any suggestions for a tool? Preferably on OS X?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2053
Version: 1.3-feature
Any X11 takers?
Link: http://www.fltk.org/str.php?L2053
Version: 1.3-feature
___
fltk-dev mailing
#uses tab every 4 spaces
-T
This is surely wrong?
The fltk tab default is 8, not 4, AFAIK.
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales. Company no. 02426132
Link: http://www.fltk.org/str.php?L2053
Version: 1.3-feature
Any X11 takers?
I think Albrecht and Alvin had this more or less beaten down... Albrecht
could maybe say what to do?
I think we should probably take that patches, FWIW.
Link: http://www.fltk.org/str.php?L2082
Version:
Duncan Gibson wrote:
Just curious, what do you do with this obscure FLTK2 fork?
I've been thinking about making a post on it (FLPTK - Fast Light Plugin
Toolkit - for lack of a better name) for some time now - a new one,
that is; I made one during the early stages of the project about four
years
On 03.04.2010, at 00:20, Greg Ercolano wrote:
Fl_Menu_::add() supports two ways to set a shortcut; one as an integer,
the other as a string, e.g. ^C
FLTK currently uses these characters to specify the shortcut's shift states:
# - Alt (FL_ALT)
+ - Shift (FL_SHIFT)
^ - Control
So, would this need to be platform dependent? How would it
show up under
Windows in the shown menu text? Maybe as ^ because it's an alias for
FL_CTRL?
Probably.
What about FL_META? What key *is* FL_META, btw., on real keyboards?
On a Mac, it's the command key - the one with the
On 05.04.2010, at 12:47, Albrecht Schlosser wrote:
What about FL_META? What key *is* FL_META, btw., on real keyboards?
On Macs, it is the Cloverleaf (POI) key. On Windows, it's the Microsoft key.
Old X terminals actaully had a key labeled Meta, but under Linux, it usually
is the Microsoft
Just curious, what do you do with this obscure FLTK2 fork?
I've been thinking about making a post on it (FLPTK - Fast Light
Plugin Toolkit - for lack of a better name) for some time now - a
new one, that is; I made one during the early stages of the project
about four years ago: (the list of
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2082
Version: 1.3-feature
Ian, would you please test attached patch file str2082_window-type.patch to
see if this fixes the compiz menu animation issue. This is not
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2082
Version: 1.3-feature
Correction: I meant *menu* animations. I can see normal window animations
though, like flying when minimizing, wobbling windows when dragging,
Link: http://www.fltk.org/str.php?L2082
Version: 1.3-feature
Ian, would you please test attached patch file
str2082_window-type.patch to
see if this fixes the compiz menu animation issue. This is
not directly
what this STR is for, but I'd like to complete this now and leave the
#2: Then, you could shorten it quite a bit:
namespace fl = fltk3;
namespace Fl = fltk3::Fl;
Now the difference in length for global functions would
dissapear; it would be much the same as without this inner
namespace, only global functions (and perhaps also constants)
would seem,
Correction: I meant *menu* animations. I can see normal
window animations
though, like flying when minimizing, wobbling windows when
dragging, and
so on. But menus pop up and close instantly.
Yup. For both menus and tooltips, I see them sort of zoom into
existence.
Other non-fltk apps,
Just curious, what do you do with this obscure FLTK2 fork?
I've been thinking about making a post on it (FLPTK - Fast Light
Plugin Toolkit - for lack of a better name) for some time now...
...the page at http://flptk.sf.net summarizes the present state.
Forgot to say before: you should
However, what I do think important, and I've raised this before, is
that we should think about using a standard set of words so that we
can distinguish between length of an array or string in terms of the
number of bytes, characters, glyph columns, and the width of strings
in terms of bytes,
Duncan Gibson wrote:
Looks like this runs almost, but not quite, in parallel with FLTK.
FLTK has only needed to consider one thread with Fl::run() in it
because that relates to a typical limitation in GUI handling by the
common operating systems.
The basic idea, because of this limitation, is
MacArthur, Ian wrote:
This is an interesting idea - though how would it play with the fltk2
port?
E.g. the fltk3 code fltk3::Fl::run() would become Fl::run(), which is
the same as you would normally write in fltk2 - so is there now an
ambiguity between fltk3 and fltk2, or is this really OK?
On 05.04.2010, at 16:23, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Link: http://www.fltk.org/str.php?L2082
Version: 1.3-feature
Ian, would you please test attached patch file
str2082_window-type.patch to
see if this fixes the compiz menu animation issue. This is
not directly
what this
On 5 Apr 2010, at 19:31, Albrecht Schlosser wrote:
Will do, but will be later today - note that from a quick
inspection of
the patch, that looks fine.
TIA for testing ...
Well...
I've tested it on every linux box I have easy access to here at home,
and it works just fine.
But... it
Albrecht Schlosser wrote:
Feedback welcome.
From the FLTK 1.1 docs (Enumerations):
FL_META - One of the meta/Windows keys is down.
FL_COMMAND - An alias for FL_CTRL on WIN32 and X11, or FL_META on MacOS X.
So, would this need to be platform dependent?
No, the new code
On 05.04.2010, at 21:03, imacarthur wrote:
I've tested it on every linux box I have easy access to here at home,
and it works just fine.
Thanks.
But... it turns out that the only one that actually manifests the bug
is the one that's in the baby's room - so that's the only one I can't
test
Matthias Melcher wrote:
On 04.04.2010, at 23:51, Greg Ercolano wrote:
I just want to make sure 1.3 gets finished and released first.
There's a lot of balls in the air right now; 1.1.x has supposedly frozen,
and 1.3.x is still in dev.. so users will want to know what to do if e.g.
1.1.10
MacArthur, Ian (SELEX GALILEO, UK) wrote:
#uses tab every 4 spaces
This is surely wrong?
The fltk tab default is 8, not 4, AFAIK.
Right.. we don't ever want to change the definition of tabs.
We would just want to tell the indenter to indent code at 2 spaces.
Albrecht Schlosser wrote:
Question: should there also be a rule to cut trailing spaces before
each commit?
This sounds dubious, and I'm trying to think where that might
be a problem, but I /think/ I've encountered situations where
trailing spaces might actually be
Domingo Alvarez Duarte schrieb:
Matthias Melcher wrote:
That would be a nice occasion to run some app that will re-indet the
files.
yup, good idea
Any suggestions for a tool? Preferably on OS X? Maybe someone even has
the correct settings for FLTK's coding style?
It would be a great
On 05.04.2010, at 21:18, Greg Ercolano wrote:
I hated to bring it up, as you seem to have the creative inspiration
to do this amazing fltk3 convergence that may 'save' fltk2, and I don't
think we should stop you!
But the rest of us should probably get focused on
Wow! Easter yesterday, and FLTK rejuvenation today! :-)
D.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re http://www.fltk.org/newsgroups.php?gfltk.commit+v:7813
Fl_Text_Buffer / Fl_Text_Display / [Fl_Text_Editor]
Thanks Matt! I was actually contemplating that too for STR-2158
because otherwise you can't see a damn thing that's going on.
Reformatting, good. Removing \0 in strings workaround,
On 05.04.2010, at 23:07, Duncan Gibson wrote:
Let me know when you've done with these files so I can get back
to STR 2158
I hope I did not interfere with your research!
- Matthias
___
fltk-dev mailing list
fltk-dev@easysw.com
I'm not sure wich version of astyle are you testing, but the one that
comes with codeblocks is a bit outdated and don't produce the good
results that the latest astyle produce.
___
fltk-dev mailing list
fltk-dev@easysw.com
On 05.04.2010, at 22:08, none (Gombok) wrote:
Probably formatting documents could be overdone.
I would prefer only handling indentation and not tampering other
formatings like comments. (Exception may be to force spaces between
keywords and parameters like in for (;;), but thats not absolute
I look forward receiving that, because I'm not at ease for clipboard
and X11. Thanks so much.
OK - but it will probably be later rather than sooner, as I have a
few things to try and get done over the next week or two...
Ian: I have added the new class Fl_Clipboard_Writer for Mac
Albrecht Schlosser schrieb:
One reason why we're discussing this is that we _have_ different
coding styles in some files. Thus, only reformatting indentation
would probably be suboptimal.
imho formatting could be done manual and with spaces.
Maybe once with support of some tool.
So anything
Greg Ercolano wrote:
regarding FL_COMMAND and FL_CONTROL being Apple keyboard-centric naming
should probably be highlighted in the docs, as to the casual glance of
an app programmer,
one might not easily catch FL_CTRL and FL_CONTROL are two entirely
different things
#
none wrote:
So anything between
start of line and the first character could be aligned with tabs.
... with tabs and (+) spaces !
That is the point. If talking about unix the default width of
a tab is 8 characters. But thats no reason to use this width in
text editors. I guess all of them
Greg Ercolano schrieb:
The reason not to redefine tabs are that tabs are 8 in every
conceivable context except editors where they are changed.
there is no need to redefine tabs as they are not needed to replace spaces!
So no other medium will show those files correctly
On Mon, Apr 5, 2010 at 7:35 PM, none @easysw.com wrote:
Greg Ercolano schrieb:
The reason not to redefine tabs are that tabs are 8 in every
conceivable context except editors where they are changed.
there is no need to redefine tabs as they are not needed to replace spaces!
43 matches
Mail list logo
