Re: [fltk.development] Added: tags/release-1.3.0/
Wonderful. I did not know that it is so easy to remove a tag. On 19.12.2010, at 11:32, Albrecht Schlosser ajs856s...@go4more.de wrote: On 19.12.2010, at 10:23, Matthias Melcher wrote: No worries. Yes, I got surprised by that too on my first release attempt ;-) Just leave it there: Subversion never forgets... . But if you delete it (I did), then you can only find it if you know where (which svn release) to look for it, or if you look at the commit logs. We shouldn't have tags for releases that don't exist yet ;-) Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r7937 -branches/branch-1.3/src
Sorry, you are right. I was super tired yesterday and got it all wrong :-) On 03.12.2010, at 00:19, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: But this code is different! It will not clear the first timer if only one timer is used! The if-clause should probably go in front to the breackMacEventLoop(), or how about this: I don't follow you. When mac_timer_used is 0, the loop for (int i = 0; i mac_timer_used; ++i) doesn't run at all, so the new code is equivalent to the old one except for breakMacEventLoop() we don't want to run if no timer was ever created. This is so that fluid can be run in command mode with no access to the window manager whatsoever. Actually, I am not entirely sure that we need to break the EventLoop at all?! Yes, this is a point I don't understand in all details either. But comment out this event loop break, run the threads demo, and increase the window size with your mouse. You'll be convinced this loop break is indeed useful. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r7937 -branches/branch-1.3/src
The breakLoop is somewhat like a Fl::flush . Removing a timeout should not really need it. Maybe using the flag as in may sample is good enough On 03.12.2010, at 10:20, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: Actually, I am not entirely sure that we need to break the EventLoop at all?! Yes, this is a point I don't understand in all details either. But comment out this event loop break, run the threads demo, and increase the window size with your mouse. You'll be convinced this loop break is indeed useful. This first reply of mine is probably incorrect. Sorry for that. I have checked that the EventLoop break was not in file Fl_mac.cxx (the Carbon version). Thus, I must have added it myself, but I confess I don't remember why. I vaguely remember this was related to the threads demo. But this demo runs and resizes well without this statement. Removing this loop break would remove the interference with running fluid in command mode (the tabs demo creates an Fl_Clock whose destructor calls Fl::remove_timeout). But I don't feel safe to do that without clarifying why this statement was introduced in the first place. Any idea ? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.1 online docs [WAS: Re: [fltk.general] fl_message formatting]
Thanks. That would be great if you could do it now. I was trying to fix the VisualC issue, but I don't know how. Everything else is ready to go... . Matthias Sent from my iPhone On 29.11.2009, at 12:38, Albrecht Schlosser ajs856s...@go4more.de wrote: Matthias Melcher wrote in fltk.general: On 28.11.2009, at 12:53, Jonathan wrote: The documentation for fltk 1.1.x states that this can be done with html tags, as in: fl_message(htmlThe value of font face='symbol'q/font is 123.456/html). I did implement this feature a long time ago, but had to take it out again. Could you please tell me where exactly in the docs you found this, and which version of 1.1 we are talking about? Thanks. Matthias, I removed this already in the current svn version. However, the current 1.1[.9] web docs still include it. ... Well, I just removed it and updated the web site ;-) I'm prepared to update the 1.1 web docs to 1.1.10, but I'm hesitating because 1.1.10 is not yet officially released. Would it be okay to do it now, or should I wait ? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3: OSX runtime issues, r6905
Yes, I'll do Some more testing. There were quite a lot of changes and rearrangements... . Sent from my iPhone On 28.09.2009, at 03:09, Greg Ercolano e...@seriss.com wrote: Matt: might want to check some of your last checkins. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf8 to do list - dumb question to start
On 04.04.2009, at 10:41, Arne Magnus Bakke wrote: Duncan Gibson wrote: Now the question is, where should [does?] fltk-1.3.x draw the line? Being able to handle single unicode characters, or composed ones too? I've had the misfortune of having to implement some unicode support in applications. This is one occasion where you really want to stay with a fast and _light_ approach, if possible. Do you need normalization support? Do you need uppercase/lowercase translation? Can you use various platform specific APIs, or a (small) library? Allright, here's one suggestion: FLTK core supplies only the *very* basic functions needed to render UTF8 and read it from the keyboard. We need to be able to measure strings in pixels (cursor up/down in the editor) and find whitespaces (word fwd/bwd). If there is a simple rule to handle composed characters, fine. Let's leave normalisation and character handling etc. to an external library. Should we find an appropriate one at some point, we can integrate it as we did with png, z, and jpeg. (Sorting the strings in the browser would then always be case-sensitive by default (binary), but we can provide an API for case-insensitve (and arbitrary) searching?) With that approach, FLTK stays as fast an light as possible, but can optionally provide a more complete API. As a user I won't be happy if you separate my å into an a and a ring on the following line :) (Ironically, I'm not sure if you'll see that character in your news reader) I can see it (Mac, Mail). In return, I will send you an ä. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf-8 to do list - checking the basics ?
On 31.03.2009, at 23:27, Greg Ercolano wrote: Greg Ercolano wrote: matthiasm wrote: Oh, which reminds me, did I mention libunicode which solves basically all of this? http://cvs.gnome.org/lxr/source/libunicode/ by Tom Tromey Is this the same one? http://sourceforge.net/projects/libunicode/ I just gave the latter a look-see. Nonono, there are a bunch of libunicode around. The Tom Tromey one is discussed here: http://mail.nl.linux.org/linux-utf8/2002-06/msg00023.html and according to this merged into glib, which may be the one we should look at?! http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Moving STRs from 1.3 to 1.4 ?
On 31.03.2009, at 22:02, Duncan Gibson wrote: That leaves 9 Features and 26 Open Bugs for 1.3. Thanks! Now that is a much more bearable number! http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] can't display '' character
On 01.04.2009, at 11:24, leowang wrote: Dear All, I found that fltk can't display '' character in widget. such as Button *btn = new Button(0, 0, 100, 100, abcdefg); it will display as abcdefg. and in browser widget, nothing will be display. The is used as a special character that indicates shortcuts in menus and buttons. Simply double the character to get a single : abcdefg http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] nutty bracing
On 01.04.2009, at 21:00, Greg Ercolano wrote:
case FL_SHORTCUT: {
stuff;
stuff;
for ( stuff ) {
stuff;
}} break;
case FL_ENTER: ..
My personal favorite solution is this:
case FL_SHORTCUT:
{
stuff;
stuff;
for ( stuff ) {
stuff;
}
}
break;
case FL_ENTER:
http://robowerk.com/
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FL/names.h
On 31.03.2009, at 03:06, Greg Ercolano wrote: The globals defined in FL/names.h should probably be 'const char *' instead of 'char *', as the user can end up with a gazillion of these when they #include it: ../FL/names.h:59: warning: deprecated conversion from string constant to 'char*' ../FL/names.h:59: warning: deprecated conversion from string constant to 'char*' ../FL/names.h:59: warning: deprecated conversion from string constant to 'char*' I can make this change and test it, any reasons against it? No reason against it. Strings are implicitly const in C, so the warning is correct, and the addition of const fixes that for all compilers. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf-8 to do list - checking the basics ?
On 31.03.2009, at 17:42, Greg Ercolano wrote: Peer review! ;) Yes, and that could probably be optimized a bit too, since if both strings are 1000 chars long, but are different by the first few chars, the two strlen()'s still walk the entire length of both strings.. painful if used in a sort().. a common use of strcmp() and friends. This looks like one of those situations where the code should be replicated instead of reused, optimized so strlen()'s aren't needed. Well, it's not that simple unfortunately.Let's stick with Mr. Miller from my previous example: in Germany , his name could have been Mueller or Müller. Both is pronounced the same, means the same, and is sorted the same way. However, it is *not* the same: the first version has one more character (or glyph) wheras the second version is a byte longer than the first (because the u-umlaut expands to three unicode fragments, IIRC). And yes, the German telephonebook does look like this: Mueller, Adam Müller, Berta Mueller, Carl ... Oh, and th u-umlaut can be written in two ways in Unicode: as as single character (ü), or as a composite : (¨)+(u) where (¨) is like a key without advancing the cursor (deadkey). To further complicate things, sorting order can be different for the same language in a different country. IIRC Austrians sort U and Ü to be equivalent. This can be solved by converting strings into some kind of sortable representation before comparing them. It's a hassle though. And don't even start to think about Asian languages... . Nuts? Yeah, I think so. Oh, which reminds me, did I mention libunicode which solves basically all of this? http://cvs.gnome.org/lxr/source/libunicode/ by Tom Tromey http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Moving STRs from 1.3 to 1.4 ?
On 30.03.2009, at 14:41, Duncan Gibson wrote: I propose to post an article in fltk.general to explain to the users that in order to focus development on completing the Doxygen and UTF8 changes for 1.3.x, all other STRs will be temporarily relocate from 1.3 to 1.4. If everyone agrees, I would then go through the 1.3 STRs and move as many of the obvious non-documentation and non-UTF8 related STRs over to 1.4 as possible. I would add a note to each STR, so it might take me a couple of evenings. +1, but no need to add a note to each STR. IMHO it would be enough to just push them to 1.4. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Global scrollbar size..
On 28.03.2009, at 00:55, imacarthur wrote: Hmm, and if we do that, there's the added benefit where the old Fl_Browser_::scrollbar_width() call could still do the existing behavior of basically changing the global Fl::scrollbar_size(), and the new Fl_Browser::scrollbar_size() could have the new 'per widget' control that most folks would want/expect. In this way old programs would still work the way they did, without modification, even if they depended on the 'global' behavior of the local browser's scrollbar_width(). Would kinda kill two birds with one stone; deprecating the call and the bad behavior, while introducing new/good behavior with a new call that is more consistent naming-wise with the global. Yup. +1. And sometime in the future, 1.x.y, Fl_Browser_::scrollbar_width() will go away and everything will be consistent and lovely... +1 http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3 development/release [was: Re: Doxygen:groupingrelatedfunctions with \see]
On 25.03.2009, at 22:53, Albrecht Schlosser wrote: Greg Ercolano wrote: Albrecht Schlosser wrote: Yes, but IMHO this can also be done later. Although, if Greg would want to add his Fl_Table widget, why not? Are there issues that need more time, or is this ready-to-go ? I think their APIs need some core peer-review before becoming public. (Since I'm not the best API designer ;) I'd recommend waiting till 1.3.0 goes out, so that we don't get distracted by changes these widgets might need, and how to integrate them into the makefiles/vs projects, etc. This way we can focus on getting 1.3.0 out and stable. Then later, at our leisure, I can check the new widgets into svn in their current state, you guys can look it all over, make API comments/changes, I can then tweak into shape, doxygen them, and then they can be added to the Makefiles for public inclusion. But I really don't think we should be distracted by the new 'big' widgets for 1.3.0; Lets wait till the dust settles on the .0 release. Okay, then we will wait with the new widgets. Good. So 1.3.0 is doxygen, unicode, and ABI changes only. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6720 - in branches/branch-1.3: FL src test
On 26.03.2009, at 18:44, Greg Ercolano wrote: Albrecht Schlosser wrote: Great, Greg, thanks! But one small issue: +ALWAYS_ON = 4, /// Both scrollbars always on [..] +BOTH_ALWAYS = 7/// both scrollbars always on Hmm, good catch. Yeah, agreed the ALWAYS_ON should not imply both. Will fix. ALWAYS_ON simply means that whichever scrollbars are requested they are always visible, even if the scrolling area is smaller than the window. BOTH_ALLWAYS is simply the combination of LEFT|RIGHT|ALWAYS http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-s60 released on SourceForge.
On 25.03.2009, at 09:41, SA wrote: I humbly present: http://sourceforge.net/projects/fltk-s60 Well ... right.. probably it's not as important as Fl_Shared_Image API changes but hey ;) maybe someone could do some testing at least? ;D Well, thanks for making the source code publicly available vie SF. I looked at your project (and commented on it) when you first released information to the list, and as you know, I like it very much. I think that FLTK is the perfect library for these kind of device, however I do not own an S60 device, so testing your port is not possible for me. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3 development/release [was: Re: Doxygen: grouping relatedfunctions with \see]
On 25.03.2009, at 16:34, Fabien Costantini wrote: (1) Get utf-8 support ready. Ok, let's specifiy the _minimum_ features to realize before an RC can be released then. - First, the TODO.utf8 file is just a list a files (to be treated?), should be rename TODO_FILES.utf8 if it is still necessary? - Then a real TODO.utf8 should be updated with a full list of the features to fix/add - Then we should establish which are the priority tasks we want to fix in utf8 for 1.3. (i.e: I doubt it is a good idea to expect adding all langages supports in our next release : couldn't it be made progressively after that ?) IMHO we must bring a clearer line to the UTF8 implementation. I have only been following loosely, but the last time I checked, we were still missing a definitive set of utf8 functions that can then be used to fix Fl_Text_Display and all the other widgets that count characters. Just defining the FLTK UTF8 API would be a huge step toward cleaning up. Next step would be to remove code duplication and consistently use the utf8 functions for *all* string handling. (2) Check, which ABI issues should be solved before a FLTK 1.3 release. The point may be : what if instead of expecting to release beautiful-complete-abi-stable-proofed-the-one version, we just target smaller/ more manageable/frequent releases (like a new release every year approx.). Then I guess it won't be so terrible to wait for the next ABI change, wouldn't it ? Well, this is exactly why I wanted to limit the whole 1.3 list of improvements to Doxygen, UTF8, Fl_Tree_Browser and Fl_Table. FLTK 1.4 can then have as many new ABI changes as required. Somehow though we all just dumped our wishes into 1.3 and now have a bug list that is longer than the 2.1 bug list. This is hardly helpful. How in the world was it possible that a 99% stable 1.1.10 ended up in a 200+ bugs 1.3 just by adding Unicode support and documentation? And there is still no Tree Browser in sight. (3) Fix bugs. YES, and the fact that the team is bigger today may help better than before. (4) Improve documentation. Yes, and probably focus on correctness and completeness more than on the aspect of the documentation, which still matters though. The current documentation is great, and Erco's improvements make it beatiful and consistent. Now if we solve the PDF numbering issue and the above mentioned missing utf8 API, we are fine. Fantastic work! I can continue to fix UTF8 bugs, but I need a real TODO list to be established (see upper) and then priorities for 1.3. Yes, precisely. We need to know what exactly to goal shall be, so IMHO we must write and document the API first, then implement it using the give code and apply it throughout the source (unless someone already did and I missed it and should shut up anyways ;-) For me issue (2) seems _very_ important, because there are lots of old STR's, maybe already from 2005/06 or even earlier, that say we can't do this for 1.1, because it would break the ABI. Now we have 2009, and FLTK 1.4 won't come before 2010 or 2011, right? Unfortunately, many of these STR's are now classified as 1.4 feature requests, but we should have an eye on those, too. Again, I'd highly suggest here that we (maybe you?) establish a TODO- CHANGES.abi asap so that we can have a clear view a determine limits to it. Well, most of that stuff should have gone to 1.4. 1.3 was supposed to be purely the addition of utf8, Doxygen, Fl_Tree_Browser and Fl_Table. Any suggestions on how to get out of this problem are greatly appreciated. Sorry, I hope I am not offending anyone, especially since I have not contributed for quite a while. I would really love to get back to 1.1.10 stability. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3: Doxygen chapter numbers and appendix letters - reordering
On 21.03.2009, at 17:28, imacarthur wrote: On 21 Mar 2009, at 14:25, Albrecht Schlosser wrote: Otherwise, please give your votes. +1 from me, of course ;-) +1 from me - I fond the issues with the appendix A B thing particularly awkward, so this sounds like it will take us past that. Thanks. +1, no questions asked. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Thoughts on the GLEAM patch that was posted
On 21.03.2009, at 19:00, Ian MacArthur wrote: Did anybody look at the GLEAM patch that Colin Jones posted at http://www.fltk.org/links.php?V367 ? It looks quite nice to me (although he seems to be patching against the debian tarballs, and I am concerned about some of the details of the patch.) That said, I think it looks like a nice extra theme - worth considering for inclusion in 1.3...? It's nice. I would add a tiny bit n=mor highlighting, but other than that, it is a nice additional look. I have not looked at the implementation though... . http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygen: no varnames in the index
On 16.03.2009, at 04:59, Greg Ercolano wrote: Trying to fix up those discrepancies in Fl_Browser's docs where we have discrepancies like this in the method index: no variable names in the prototype / / void insert (int, FL_BLINE *) Insert a new line *t* before *line*. \___\ variable names in the docs Just add descriptive names. They need not be the same as in the source file (although it would be nice if they were). Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [SPAM] Re: Doxygen commenting in fltk
On 14.03.2009, at 15:54, Greg Ercolano wrote: If you want to be able to edit, just email me your google account name and I'll add you as a collaborator. Or, just tell me what you want changed and I'll add it, but it'd be more interesting to see how the collab works.. No time available. Nevertheless, I am very curious how this works, so I did sent you the EMail via Google already. Thanks for all your work on FLTK these days - at least I have time to follow the mailing list Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [SPAM] Re: Doxygen commenting in fltk
On 14.03.2009, at 16:35, Greg Ercolano wrote: matthiasm wrote: No time available. Nevertheless, I am very curious how this works, so I did sent you the EMail via Google already. Mmm, didn't get it -- I think my e...@3dsite.com is a dead address now. I'm sending you an invite instead; let's see if that works. I received the invite. It works. Thanks. I first cliked the edit link which gave me the option to request edit access automatically. The request is formwarded to you google mail account by Google. No choice here. Thanks for all your work on FLTK these days - at least I have time to follow the mailing list Yes; I'm sure we all miss your marathon bug fixes..! I decided to jump into the fray with svn access. Enjoy :-) . I always liked the marathon days and I am looking forward to the day when I get back to it. STR's are all just mean little evil brain teasers... . http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2076:Patchforfl_text_extentsmechanismin fltk-1.3.x
On 11.02.2009, at 09:39, MacArthur, Ian (SELEX GALILEO, UK) wrote: ..so that one can easily just run through all the tests quickly just by clicking the 'Next Test' button, and it just selects the next item in the browser. Or just clicking in the browser will run that particular test quickly. I guess Next Test could be an FL_ENTER button, so the enter key can be used to advance through the tests.. This seems like a good idea - although it seems to me that (once upon a time) there were going to be test routines for every function. I guess that soon there were too many functions to make that feasible. When I ported FLTK to the Mac, I started exactly that. The source code is still in test/unittest.cxx. The goal was to be able to verify rendering on every available platform. I wanted to render markers first and then overwrite them with whatever drawing function I was testing. That way, of-by-one errors, for example in fl_rect, would become obvious right away. I would *love* to have that for text rendering. For some test, a comparison to an image would be in order as well (for example: this is how FL_HELVETICA should look and this is how it is rendered on this machine). Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Votes please: Should STR updates always be mirrored to fltk.bugs or fltk.development ?
(4) My vote: +1 for always mirroring STR updates to the newsgroups for consistency. +1, traffic would be ok http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] About FLTK 1.3 (and 1.1) objectives (was Re: [Library] r6628 - branches/branch-1.1/src)
On 13.01.2009, at 14:20, Fabien Costantini wrote: Still, I feel I have something to point out clearly, for the new year : We should *definitely stop* updating modifications to 1.1.x because Agreed. Please no more fixe for 1.1 - unless: 1: there is something very wrong in 1.1 that would make it unusable - or - 2: the fix is relatively major and the fix for 1.3 is the same. Then it can be applied to both versions. But when in doubt, just assume that 1.1 is closed and final. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fullscreen problems with Gnome panels?
On 29.12.2008, at 02:54, Danny Parker wrote: I've been looking into FLTK for a project a friend of mine and I are working on and everything looks really good so far. However, I'm using using Unbuntu Hardy Heron and I have problems with the Gnome panels appearing over many fullscreen applications. This also appears to happen with the fullscreen demo in the FLTK test folder. Does anyone know of a way around this when coding a fullscreen app in FLTK? The FLTK Fullscreen option is not meant to put the screen on the very top. For X11 (Ubuntu and other Linux/Unix OSs's), lifting the window on top over all other windows is a Window Manager function. You can send a request to the window manager to make your window the top-most, but it is up to the window manager to do it (or not). So, FLTK does not provide an on top of everything window, but you may be able to get one by adding a few X calls right after Fl_Window::show(). http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Moving features to something called FLTK 1.4
Hi developers, you may have noticed that I moved a bunch of feature requests for 1.3 to something I call 1.4. Don't worry. I am not planning another code split or anything crazy. In our 1.3 vs. 2.1 vs. 3.0 discussion, we decided to create a new version of FLTK 1.1 plus utf8, Fl_Table, and Fl_Tree, and call that 1.3. Utf8 is a much too much of a change to have it as some additional feature in some sub release. However, we are all so hungry for features and found som many little bugs (some of which never bothered anyone in 1.0 and 1.1) that our bug list rapidly grew over 100. That is much too much change for a single revision and will delay 1.3.0 close to indefinitley. In order to get back to the original goal, I moved all features not mentioned above to some 1.4 release. This dosn't mean that they will never be implemented, it only means that they are not the main focus. If I get a complete path for one of those, I will certainly not reject that. FLTK 1.3 *still* has 53 bugs on the roadmap plus 6 bugs from the 1.1 branch. 18 more RFE's still make this list frustratingly long. So if there is more stuff that is not desperately needed, please move it to 1.4. Once we have a 1.3.0, we can still move those issues back to 1.3, ok? Trying to focus in the floods, Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Something I call FLTK 1.4
Dear Users, you may have noticed that FLTK 1.4 popped up on the roadmap. No worries please, I am not jumping ahead. I am merely trying to get a 1.3.0 roadmap down to a manageable size. Once we have a 1.3.0 with full utf8 support out of the door, we will move 1.4 issues back into the 1.3 roadmap. Thanks, Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] OT: Brandy
On 18.12.2008, at 09:17, Duncan Gibson wrote: Matt wrote: We have been building and opening a museum for Brandy over the last three months. The place was pretty much deserted and raw, but we got it back going and can now show the visitors the art of destilling in the biggest wine destillery of Germany. [...] and http://weinbrennerei-dujardin.de/Weinbrennerei.html OK, definitely off topic, but I have to ask: what is Melcher's Rat/ advice It is a Spanish brandy which we make and distribute that is available only in some northern regions of Germany, named after my great grandfather, Heinrich ;-) . http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: FLTK 1.3 (and 1.1) libpng upgrade from 1.2.25 to 1.2.33
On 17.12.2008, at 15:28, Albrecht Schlosser wrote: matthiasm wrote: Great! Please go ahead. I'll do. BTW: Welcome back! :-) Thanks! ;-) We have been building and opening a museum for Brandy over the last three months. The place was pretty much deserted and raw, but we got it back going and can now show the visitors the art of destilling in the biggest wine destillery of Germany. Three weeks ago was the opening event with 600 people from all over the area including the mayor of the city and some officials even from the state. I had the honor of holding the opening speech and my legs are still shaking a bit ;-) Anyway, reading the FLTK mailing list helped me a lot to stay sane in the evenings and get my thoughts away from cleaning windows, moving 2 metric tons heavy copper pots and rolling 3000 gallon wood barrels. Back to UTF8 - horray :-P Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6589 - branches/branch-1.1/src
On 17.12.2008, at 13:28, Fabien Costantini wrote: I was not sure that STR bug fix should appear or not in the CHANGES, anyway I added this one in CHANGES to both branches; as it won't hurt. Fabien I tend to put *every* fixed STR into CHANGES. When we reach the final release, we can still throw the minimal stuff out and compress fixes later (for example, all documentation changes become a single item with the list of STRs). The only exception is STRs that fix regressions, since they are not actually changes from a previous version to the current one. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Inclusion of PDF file in SVN repo
On 08.12.2008, at 20:10, imacarthur wrote: Gents, Is it intended that the fltk.pdf file be included in the svn repo? I wondered, only because it is quite large and that might be a problem for some users on slow links? No, the PDF should not be part of the svn because it is auto-generated and can also be downloaded seperately from the web page. We do not include any auto-generated fluid build results either. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Inclusion of PDF file in SVN repo
On 08.12.2008, at 20:28, Fabien Costantini wrote: Gents, Is it intended that the fltk.pdf file be included in the svn repo? I wondered, only because it is quite large and that might be a problem for some users on slow links? No, the PDF should not be part of the svn because it is auto- generated and can also be downloaded seperately from the web page. We do not include any auto-generated fluid build results either. The PDF generation requires lot of tools and tricky installs to make the doxygen generation correctly, and also ; we found not reasonable to put all the html generated files to the svn repo, but still wanted the final to get a documentation with its distrib as in fltk 1.1. This is why we decided to put it in the svn repo of fltk13. Ah, true. Well, I have a fast network connection... ;-). Not sure if a temporary pdf is interesting to someone who could not generate an improved one? Anyway, fine with me either way. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK coding standards RFC
On 06.11.2008, at 09:17, Albrecht Schlosser wrote: I agree that there should be a standard proposed in the FLTK coding standards document. However, I think that your analysis covers only the exceptions, because you searched only for set_, is_, and ed() as you described in the link above. set and clear is used for bit flags. Values don't use set. set_changed() sets the changed bit but color(0) sets the color value It can be hard for non-native speakers to figure some calls out, for exmaple: maximize() vs. maximized() (setter and getter), but set_maximized() also seems awkward to me I am glad we have not hit irregular verbs yet ;-) bend() vs. bent(), for example (setter and getter, again) I can't offer a solution, unfortunatly, but I likel to read code in a somewhat meaningful English sentence. if (window-maximized()) then ... . if (window-is_maximized()) then ... . seem both OK, or should it be window-is_maximum_size()... :-/ - I really don't know. Whihever it is though, it should be mostly consistent. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [fltk-1.3] CMake maintenance
On 22.10.2008, at 05:07, Maik Beckmann wrote: thanks for proposing to maintain the CMake files. If you wish to do that, don't need svn access, the best way to proceed is to add an STR for fltk1.3 like CMake files Maintenance for 1.3 Which means I won't be able to work incremental. So be it. Ah, no. You can certainly get SVN access. You need to contact Mike ([EMAIL PROTECTED] ). Ususally we ask contributers to send in a few patches first. If the patches are good, Mike will give you an SVN login. If cmake works for vs2003, it works for vs6 to vs9 (and later) as well. For XCode I need testers. We have a bunch of OS X users (including myself). It should be no problem at all to find a tester. We generally don't accept unfinished work, especially when the proposed solution aready exists and is working in another form (like for the vc2005,vc6 makefiles). Having one build system for everything reduces maintenance cost. We have been discussing that and would love to have a single build system - assuming that this system can generated the required files for other IDEs correctly. First of all I will clean up what's there, which might end up in writing everything from scratch. Since you seem to live good without cmake so far(it doesn't even work at the fltk-1.3 branch), I'll set the minimum requirement to cmake-2.6, which ships a much better FindX11.cmake. We have no CMake maintainer yet. 1.3 is still very much in limbo, which explains why there is no working file. I don't know much about CMake, but judging by what the possibilities seem to be, CMake seems to be a good decission. Your efforts will be very welcome. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_measure, fl_height, fl_width and fltk-1.3
On 22.10.2008, at 15:10, MacArthur, Ian (SELEX GALILEO, UK) wrote: - What do people think? Should we have an extended fl_height/ fl_measure mechanism to determine the actual size of the text glyphs to be drawn? If so, I'll generate some STR's. FLTK support for fonts is poor and inconsistent. It is limited to what the Fomrs library provided back at times when fonts were bitmapped and the height of a font was the same as the height of the bitmap, and a line break would simply continue that many pixels lower. But the porting of FLTK to OS X Quartz was a pain because no aspect of Quartz fonte rendering is limited to integers. In fact, assuming that a character width is evenly dividable will generate extremely ugly text. FLTK currently uses a somewhat secret flag that limits Quartz to integer math, but this makes fonts blow 10 points close to unreadable. So that first thing to support Cairo and Quartz correctly must be a move to floating point coordinates and measurements. Secondly, we will have to open up access to many more aspects of the selected font, some of which you mention in your post, and more. But here also lies the usual problem of staying fast and light: after reading through the Apple font rendering manuals for weeks, and trying to fully understand Unicode, I concluded that all font rendering in the world should be limited to 8x8 pixel bitmap fonts in the range of 32 to 126 ;-). Text rendering can fill books, and those books can fill a library. - Do folk think the win32 fl_width() mechanism should be brought more into line with the XFT/OSX implementation? Or should we leave it alone? Or...? Yes, font rendering should look more or less the same on all platforms and deliver at least similar values for the same arguments. fl_width should take kerning and ligatures into account, but it must do so quickly! This is not always the case (see Quartz) which is why the width calculation uses per-charcater buffering. The fault here lies within FLTK which does not buffer any text information an measures and renderes every text segment from scratch every time a redraw is needed. It will be extremely hard to remain efficient here! Anayway, I am starting to drift into a rant because I am overworked. I like your short-term additions and would welcome them to the current 1.3! Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Change to svn 1.1.10 for Fl_Group::clip_children()
On 19.10.2008, at 13:56, imacarthur wrote: I'm always a bit hazy on the whole what changes affect the ABI thing, but I notice this change has been committed against 1.1.x (1.1.10) svn: - Fl_Group::clip_children() is now public (STR #2017) Is that a safe thing? Can we do that without breaking the 1.1. ABI? I have done a little research before we decided for the change and have not found a C++ compiler that encodes public attributes in the decorated method name. This is not to say that there is not some exotic compiler that does, but at least for the current gcc and VisualC, these attributes seem to only exist in the header files (and not changing the ABI). I hope... ;-) http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6431 - in branches/branch-1.3/documentation: . src
On 15.10.2008, at 14:58, Fabien Costantini wrote: fltk-dev@easysw.com wrote: Author: fabien Date: 2008-10-14 15:12:25 -0700 (Tue, 14 Oct 2008) New Revision: 6431 This checkin destroyed the svn history of all the images and *.dox files. You should have svn moved them instead of deleting and adding them in another directory. Do we want to have the history, should this be repaired (maybe by copying from the old rev. to the new target dir.?). Albrecht Hmmm weird, because I *did* used svn move ... svn move *does* delete the old file and create a new one, so the log was OK. I am not sure if an internal history is kept in a all encompassing way in Subversion. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6435 - branches/branch-1.3/documentation
On 15.10.2008, at 17:27, Albrecht Schlosser wrote: Fabien Costantini wrote: That said, it should be easy to update the local copy otherwise we won't do it regularly. Sorry, I can't really understand this sentence. If *I* would change my local copy to remove this line, then I would maybe commit *this* modification unintentionally, because I *must* check in the whole fltk tree to be consistent. Just to be sure, you don't svn stat before committing to the trunk ? Because if you do (and you should), there is no chance you can mess with it. Of course I do. Needless to say. But your modification forces me and (IMHO) other developers to take care of this modification every time they want to commit something. Right now we are testing, and generation of the pdf file should really be done regularly to see the results after changing sources. Can we simply have two targets? Like: make pdf and make pdf-dist The second target only would execute the copy command. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LaTeX and pdf generation [Re: [Library]r6411 - ...]
On 14.10.2008, at 12:48, Albrecht Schlosser wrote: Now I can also generate the pdf file (205 pages) :-) Wh! That is so cool ;-) We can soon print a book then :-P http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3, OSX port keyboard handling broken
On 27.09.2008, at 19:23, imacarthur wrote: Has somebody modified the keyboard handling in Fl_mac.cxx ? It seems to be broken currently. Yes, I did. The implementation is not complete yet and fails below some(?) OS version. The advantage of my keyboard function will be an advanced handling on dead keys and international keyboards in general. The old version did not handle Alt-Key characters. I am very sorry that I do not have the time to take more care of the UTF8 version. Things in the job go crazy once more and we have a nasty deadline coming up :-/ Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On 29.09.2008, at 11:17, alain savelli wrote: I would like to know iof the last version of FLTK support Framebuffer. There is a version of FLTK 1.1 out there that supports framebuffers. There is no official release yet. 1.4 is a pretty good candidate for core developer supported framebuffers. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Please file STRs for both issues, preferably with patches ;-) Thanks. On 29.09.2008, at 18:28, Alvin wrote: Carlos Pita wrote: I'm not sure if I must report this as a bug, tell me so if it's the case. Most fluid windows don't play nice with tiling windows managers (wmii, awesome, dwm, xmonad, ratpoison) which depends on the class or instance of a window to be able to put it into a floating layer or layout. I have had a similar problem with FLTK apps and Compiz's animation rules. For example, from what I can tell, all windows in FLTK 1.3.x apps (incl. fluid itself) have a type of Unknown. As a result, FLTK windows do not follow the same animation rules as my other windows (KDE mostly). I have the same animation for all FLTK windows rather than different ones for dialogs, normal windows, etc. From using xprop, I believe the setting has to do with _NET_WM_WINDOW_TYPE(ATOM). http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fluid supporting Doxygen (SVN 6291)
On 23.09.2008, at 10:08, Duncan Gibson wrote:
I've just experimented with the new, improved fluid and was able to
add the doxygen comments for these static member variables, and then
to generate the html with some test text (may be changed by the
user).
One comment: on my first attempt I typed in the full doxygen comment
with delimiters (i.e. /** may be changed by the user */ and of
course
fluid enclosed this within extra /** and */. So could you change the
tooltip to add (/** and */ will be added) or strip /** and */ from
the comment text if needed?
Yes, I can see that that is a problem.
Earlier this summer I experimented with adding doxygen comments using
the normal fluid comment feature, and found that the code generation
doesn't always output the comments in the places where doxygen
expects.
This new doxygen comment feature looks much more promising and is a
lot
less awkward to use than New {Class, Function, Declaration} followed
by
New Comment, and then a lot of F2/F3 to move it in front of where it
was needed.
Thanks. The original comment implmentation had no Doxygen in mind. It
was based on the request the add a copyright message at the top and
bottom of the .fl, .H, and .cxx file.
http://robowerk.com/
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
On 24.09.2008, at 17:08, Albrecht Schlosser wrote: All fonts have the same problems, e.g. word - looks like: --- schließen - schlie?n Auflösung - Aufl?g größe: 98 - gr? 98 Well, unicode encodes characters in 32bit (currently only the lower 24 bits are used). utf8 is kind of a compression system that converts 24bit numbers into multiple 8bit numbers. To simplify life, characters 127 and below stay the same, wheter encoded in utf8 or not. Characters above 127 however describe different ways of compressing the original 24 bit character. I won't go into detail, but it is enough to know that there are illegal sequences, for example, ös in ISO genrates a byte sequence that would be illegal in utf8. Maybe MSWindwos and OS X recognize illegal sequences and assume ISO encoding. The correct way though would be to convert all source files from ISO to UTF8. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On 29.09.2008, at 21:35, Ormund Williams wrote: On Mon, 2008-09-29 at 02:17 -0700, alain savelli wrote: Hello, I would like to know iof the last version of FLTK support Framebuffer. About a year and a half ago Nikita Egorov took the first steps in porting FLTK to DirectFB, I would like to continue that effort and see if it will get accepted into the FLTK. My main interest is building user interfaces for machines, FLTK provides a rich set of widgets and looks like it will crosscompile without too much trouble. I don't know how long it will take me, don't have a lot of experience with graphic software, but if others are interested it might help move it along. As I said earlier, we would like to have framebuffer support as part of FLTK. The recommended way of going this route would be to create a few patches for the existing FLTK 1.3 (or 2.1, if you should decide to go that path) and submit those to fltk.development. If you patches are good and code conforming, Mike will give you SVN (Subversion) access. You can then branch off your private copy, add framebuffer support, and keep it in sync with whatever is going on in the main brabch. When FB support works well enough, we can merge your code back into the main code and other coders can help you wrap the port up. It doesn't matter really how long this takes - we all are on a small budget time-wise. Its important that your code behaves nicely and plays well with the build systems. There is quite a bunch on knowledgable developers who can help you get started. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
On 29.09.2008, at 21:37, Alvin wrote: * When show(argc, argv) is called (in Fl_arg.cxx) for the first window of the application, a check is made to see if xclass() has been set. If not, argv[0] is used. I have tested this and, sure enough, if I make a symlink called turnip to my program, the WM_CLASS is set to turnip,Turnip. Now, my apps have their main(int,char**) created by fluid. I'm not sure what happens when the show() is called instead of show(int,char**). If someone can tell me, it would be greatly appreciated. Ah, I was wondering about that. The first show() call in an application always should be show(int,char**) for this and other reasons. I beleive it is in the docs somewhere, but I can see how easy it is to get that wrong. * Should the xclass() of other Fl_Windows (and its derivatives) be automatically set when show() is called? Yes, I think that is acceptable. If so, what should it be set to: (1) The same as the first window? Is that valid? Yes, I beleive that this is coded that way anyways, unless xclass() is set differently in a later call. If no class is given or show() is called, the window class will be FLTK (at least in MSWindows). It would probably be better to use the filename instead, but since argv[0] is not accessable here, we would have to go another route (plus argv[0] is not always valid anyways, but IIRC Greg has a collection of functions to get the executable path on all platforms?!) (2) Or a distinct name, something like first window xclass#xid of the Fl_Window being shown. No, I don't think so. From what I understand, the xclass shoudl be the same to signal to the WM that all windows belong to the same app. Which brings me to the first mail: I am very surprised that Fluid is not behaving correctly, and here seems to be the main problem, because Fluid does correctly call Fl::args(...) and main_window-show(argc, argv). http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: FAQ / Build environments / cross compiling
+ on all of them as long as the documentation stays structured. We have README files on OS issues, but most IDE's exist only for single OS, so it probably makes sense to merge this information. There is a lot to say about the Xcode IDE support for FLTK for example... ;-) On 24.09.2008, at 09:34, Duncan Gibson wrote: a. Frequently Asked Questions: +1 b1.Build environments: +1 b2.Cross compiling: [could be a part of build environments] +1 Resizing +1, we can copy the existing articles and add better images Raw image data handling +1, but minimal. Either as art of the FAQ or as part of Drawing http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 svn not building on ubuntu 8.04
On 21.09.2008, at 15:34, imacarthur wrote: On 21 Sep 2008, at 9:44, Edmanuel Torres wrote: I think you are missing libxt-dev $ sudo apt-get install libxt-dev Oh, most probably! However, I don't think we actually need the call to X11/Intrinsic.h in the file anyway... I will take tat line out in the next iteration and see if other Unix variants will stop compiling then. If everything is fine, we can leave it out. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unix x11 flag in configure for 1.3
On 21.09.2008, at 20:00, Fabien Costantini wrote: We could feasibly have cases in future where the OS is UNIX but the display system is not X11 (e.g. some sort of framebuffer, or native Gl or some such thing) so if we build for that now... True, this is why if this add-on is ok, I would suggest to replace the parts of the code where we make the assumption that the #else case is unix X11, which is true today but may change. Also when you're willing to search for all X11 related code impl., it would be so easy to find them as not every #else deals with X11, but UNIX_X11 does. This overlaps with the Cairo question: X11 is absolutely not reserved to Unix. We had a branch for a while that would compile an X11 version on OS X so that apps can be run remotely. Also, _APPLE_QD_ vs. _APPLE_QUARTZ_ is just a crutch anyways and adding _APPLE_X11_ and _APPLE_CAIRO_ would probably be wrong. Can we somehow split this up into: FL_OS_WIN32, FL_OS_UNIX, etc. and FL_GFX_CAIRO, FL_GFX_X11, FL_GFX_WIN32, FL_GFX_VNC, FL_GFX_QUARTZ, etc. To be consistent, we would then have to mark the window manager as well, I guess: FL_WM_X11, FL_WM_CARBON, FL_WM_COCOA_, etc. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Size accepting pointers to int ?
On 18.09.2008, at 17:01, Roman Kantor wrote: OK, the other possibility would be that the negative size values would indicate a position within some size table. But this would be ugly too so I will drop the idea. Nagtive values are perfectly legal on any machine. Even if there is less that 4GB of RAM, the MMU may still position the physical RAM anywhere in the address space, including 0x8000 and above (which would be negative). A possible hack would be masking out the lowest bit, because structures and classes are word or longword aligned on pretty much every CPU. But it is still a dirty hack which may fail one day for some obscure reason. My favourite OS, MS Windows in most (all?) of its iterations actually uses your originally proposed hack for HANDLE! Quite a pitfall if the implementation is hidden and a programmer expects a pointer, but gets an index, or vice versa. Or in short: -1 http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6302 - branches/branch-1.3/fluid
On 19.09.2008, at 02:06, Albrecht Schlosser wrote: fltk-dev@easysw.com wrote: Author: matt Date: 2008-09-18 14:11:28 -0700 (Thu, 18 Sep 2008) New Revision: 6302 ... Modified: branches/branch-1.3/fluid/alignment_panel.cxx === --- branches/branch-1.3/fluid/alignment_panel.cxx2008-09-18 20:13:10 UTC (rev 6301) +++ branches/branch-1.3/fluid/alignment_panel.cxx2008-09-18 21:11:28 UTC (rev 6302) @@ -3,7 +3,7 @@ // // Setting and shell dialogs for the Fast Light Tool Kit (FLTK). // -// Copyright 1998-2008 by Bill Spitzak and others. +// Copyright 1998-2005 by Bill Spitzak and others. - I guess that this has been unintentionally set back to 2005 ? Yes, it was not fixed in the .fl file, so writing a new .cxx and .h from the outdated .fl reset the copyright Thanks. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygenating sources for 1.3 ?
On 14.09.2008, at 07:14, Bill Spitzak wrote: I don't like the * at the start of every line. It makes it impossible to cut/paste text from the output of doxygen. Yes, this suggestion has been ignored so far anyways, so I would say it is safe to assume that we will *not* put the * in fronnt of every line... . ;-) . I did do it in my code to have easily visible comments on non-syntax-highlighting editors. But pretty much ever editor is syntax-highlighting these days anyways. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygenating sources for 1.3 ?
Great job with the Doxygen comments so far! Thank you. On 14.09.2008, at 16:55, Duncan Gibson wrote: 1. the no html rule. Unfortunately doxygen's \c only sets the next word to a constant width (code) font, and text in \code and \endcode pairs ends up in its own boxed paragraph. To format multiple words inline using a constant width font either requires one \c per word. This is fugly for code such as \c FL_ALT \c | \c (FL_F \c + \c10) which can be handled much more readably within tt /tt pairs. Good news! I looked through the Doxygen manual again and fond this page which listst all the html commands that can be used in Doxygen comments and will be translated correctly into pdf, etc. . Whee! http://www.stack.nl/~dimitri/doxygen/htmlcmds.html 2. Fl_Button.H has: Fl_Button(int,int,int,int,const char* =0) Fl_Button.cxx has: Fl_Button(int X, int Y, int W, int H, const char* l) If I place the doxy-comment in Fl_Button.cxx, the .H form is shown in the generated file. Should I then re-include the elided parameter names in the .H file? I don't mind compact header file, but I found the laziness of not repeating the names of arguments in the header to be a mistake. Smart text editors find the declaration and give help while typing. Leaving out the argument names makes this feature almost useless. Now Doygen seems to backfire as well. I am afraid the Right Way to do this is to retype the arguments in the header files. 3. Fl_Button.html has a description for the ~Fl_Button() descructor, which is an implicit destructor that is not declared in .H or .cxx I intend to leave this out. C++ programmers should grok destructors. There should not be any additional information in the ~Fl_Button documentation than in ~Fl_Widget. If there is, that info should be in ~Fl_Widget. Doxygen will generate a link there form Fl_Button-all memebers. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Fl_Audio class for 1.3
On 13.09.2008, at 20:39, Alvin wrote: Interesting. In theory would it be possible to use libogg (or libvorbis) to get the samples from an OGG file[1] and pass it to Fl_Audio::add()? And/Or would there be classes like Fl_OGG_Audio, Fl_WAV_Audio, etc. Similar to how there is Fl_PNG_Image, FL_RGB_Image, etc. I could also imaging a Fl_Shared_Audio and a fl_register_audio()? Does all that sound possible in a fast and light way? I suggest that we avoid compile time dependencies and check at run time for common libraries. On WIN32 and OS X this is easily controlled. On Unix'es, we can slowly add whichever libraries seem to have a large user base. Which leads me to request an even deeper implmentation, a media player widget. This is really easily done in few lines using Quicktime and probably the same with the Windows Media Player. Or am I overschooting the goal again ;-) http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unicode, utf8, glib, and licensing
On 12.09.2008, at 13:17, MacArthur, Ian (SELEX GALILEO, UK) wrote: Sometimes I'm glad I have English as my first language... Or as an American friend recently noted: I have a hard time understanding those Brittish. I wish they would speak proper English like us. ROTFL, Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf8 preparation done!
On 11.09.2008, at 07:43, Greg Ercolano wrote: BTW, Matthias, here's a handy little program me and Ian came up with that tests japanese utf8.. gives instant results on showing non- roman characters: http://seriss.com/people/erco/fltk/japanese-test-utf8.cxx Thanks, that is helpful. What does it say? Programmers are stupid? ;-) I'll try the Mac next. Oops: got this building on the Mac OSX 10.4.11: [..] Compiling widget_panel.cxx... Linking fluid... ld: Undefined symbols: _XUtf8Tolower make[1]: *** [fluid] Error 1 make: *** [all] Error 1 ..I used the default configure. Let me know if you need configure output or something from me. On 10.5, it compiles and links fine. Did you update to the latest svn? XUtf8Tolower is implemented in src/xutf8/case.c . That file should be part of fltk.lib and is compiled and linked toward the very end of fltk.lib. Compiling fl_utf.c... Compiling xutf8/case.c... Compiling xutf8/is_right2left.c... Compiling xutf8/is_spacing.c... Compiling xutf8/keysym2Ucs.c... Compiling xutf8/utf8Input.c... Compiling xutf8/utf8Utils.c... Compiling xutf8/utf8Wrap.c... /usr/bin/ar cr ../lib/libfltk.a ... ... Compiling undo.cxx... Compiling widget_panel.cxx... Linking fluid... === making test === Compiling unittests.cxx... Linking unittests... http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf8 preparation done!
On 11.09.2008, at 09:07, Albrecht Schlosser wrote: make on cygwin: (1) I had to add -limm32 to LDLIBS and GLDLIBS in makeinclude, but this a generated file - don't know, where to do it right. This should be fixed by not requiring IMM32.DLL at compile time anymore. (2) help/mcast_rx and help/mcast_rx need -lws2_32 (windows-only), because ws2_32 is not linked in any more. I modified my local Makefile, but that should maybe be done differently. I threw those out for now because they are not in the utf8 scope. It would be nice to have those again later. Here's my Makefile patch. I used mcast_*.exe with an explicit .exe, just like sudoku.exe - that should be okay for windows-only. This patch would break OS X and Linux builds. As you see from the last commit, I try to touch Makefiles as little as possible, because every little change here triggers another problem on some platform I usually have never heard of... . http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf8 preparation done!
On 11.09.2008, at 12:24, MacArthur, Ian (SELEX GALILEO, UK) wrote: Built from configure/make on Msys/mingw/winXP. Caveats: -- Hand edited makeinculde to add -limm32 -lws2_32 to the linked libs, to get things through the build. I accept that long term this may not be the right solution! This should be fixed. See previous mail. -- Hand edited config.h to add (which I need for my code) /* #undef HAVE_PNG_GET_VALID */ /* #undef HAVE_PNG_SET_TRNS_TO_ALPHA */ #define HAVE_PNG_GET_VALID 1 #define HAVE_PNG_SET_TRNS_TO_ALPHA 1 I have never looked into PNG. This may be an autoconf/configure issue. ...except for fractals.exe which segfaults. (Note: the segfaulting fractals demo *may* have been present in earlier 1.3.x snapshots, or so rumour here has it...) That would be nice to know. I found one nasty crash already where the Forms emulation crashed because it abuses bit 9 of the font index to signal shadows. Now until now, we did not have 9 bits in the font index. Now that we do, we either get a crash for accessing font number 512 (bit 9 set), or we must clip foont indices at 255 and possibly get the wrong font in Forms. So much for abusing those upper bits that nobody will ever need, because theree will never be more than 255 fonts on a computer... . Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unicode, utf8, glib, and licensing
matthiasm wrote: ... 1: go strictly with our patch, remove duplicates, and clean up our API 2: use the already clean GLib API and hook that up with the guts from the patch 3: extract the unicode from GLib and replace code from the patch (but GLib is LGPL, FLTK is modified LGPL, so I am unsure if that is OK) 4: require GLib and link against it (my least favourite solution) Thanks for all the suggestions. I will use a combination of 1 and 2 then. I merge the code base with the patch (done), then make all the IDEs and Makefiles work that I can test (Linux, OSX, Xcode, VC6, VC7, VC8) and merge back into the trunk. The merge will allow other projects to continue (Doxygen, mainly). Now, this merged version will have some regression, so after the merge, I will start refactoring and fixing all Unicode support, hoping for support from the community (rgression testing, general testing, patches). I was very excited yesterday to see the first Japanese characters on my FLTK-for-OSX yesterday and I beleive that we are on a good path. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unicode, utf8, glib, and licensing
On 10.09.2008, at 09:45, MacArthur, Ian (SELEX GALILEO, UK) wrote: FWIW, iconv is the usual API on Linux/UNIX systems to do character set conversions, and Windows has its own multibyte functions - I'd rather use those than glib, if we are going to pull in another library... If I understand Matthias' concern correctly (and as ever I'm likely wrong...) it's not so much the character set conversion that's at issue, as the string manipulation routines for handling characters in the utf-8 strings. I think we *have* the functions we need for this - both OksiD and (I assume) Bill have written these functions for fltk-1.1.6 and fltk-2 respectively, with somewhat differing API's. I then tried to put the fltk-2 functions into the 1.1.8 codebase. So, anyway, I think what Matthias is suggesting is that we rework those existing functions to present an API similar to the equivalent functions from Glib, on the basis that their API looks better... Yes, right. I will create the remaining IDE support files and then phase out and restructure/refactor what we have. I will do the refactoring in the main trunk again, so that Doxygen commentary can start. Understanding more and more about languages, script, glyphs, fonts, and layouts, I realize that we can never produce a perfect UTF8 support. So let's keep it fast and light and allow rendering of all fonts and simple text input. The existing code base is just fine for that. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unicode, utf8, glib, and licensing
On 10.09.2008, at 14:52, MacArthur, Ian (SELEX GALILEO, UK) wrote: Editing complex scripts is *hard* Trivia: Reading through various documentation, my own language, German, has several pitfalls I was not aware of. Converting the word measurments in German from lower to upper case is a problem: Maße - MASSE . Ooops, the new string is one character longer (but 1 byte shorter in utf8, btw.)! Now, converting back to lower case is close to impossible, because even though Masse is a valid German word, only it means something entirely different (mass) than Maße. The tolower() function would have to understand the entire context in which the word is used. In conclusion: no need to look to the far east for impossible unicode string handling. It's right here. Matthias Melcher (mumbeling: fast and light, fast and light, fast and light...) http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unicode, utf8, glib, and licensing
On 10.09.2008, at 21:20, Yuri wrote: OK, so I have no problem with using glib with Pango and X11/Cairo, however glib isn't fast or light or standard outside Linux/Solaris, so I wouldn't want to make it a dependency on other platforms. In particular, glib on Windows still has a lot of issues... I try build Glib by MSVC compiler about 4 times (last about 2 years ago) and unfortunately Glib is not work or not compiled (as i know binary distribution of glib made by Mingw) But there is no Ming64 compiler now. and therefore Glib64 (I don't find them). But fltk_win64 works well. Glib (and others Gtk library gtkmm for example) is not light in size. Fltk has 2 great advantages: 1 - it is small 2 - works with 64bit MS compiler I think that fltk no need aditional dependences. Thanks for the input, Yuri. The idea is abandoned in favor of using our own, existing code. somtimes i have an idea rewrite FLTK callbacks using sigsc++ library :-) Signaling in general would be a good addition at some point. Knowing the community by now, we will probably write that ourselves, ya'know, for speed and weight ;-) Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] utf8 preparation done!
Allrighty, I decided to release the utf8 patch into the Wild (in this case, into the Trunk of the SVN). This means that the Doxygen developers can go forward now and move the documentation over. But this also means that this particular SVN version of FLTK 1.3 is very buggy! Here are a bunch of issues that I have found so far: IDEs: - Makefile support: tested on Fedora Core 5 and OS X, but heaven knows on which platforms this may fail - Xcode: tested, seems to be working (but see comments below on OS X) - VisualC (VC6): tested, test/utf8 works, but may have had some issues during merge. Some additional work needed (imm32.lib) - VisualStudio2005: tested, test/utf8 works, some addtl. work needed (imm32.lib) - VisualCNet: sorry, I have no longer access to that IDE - Borland and other compiler: sorry, I can't update those Platforms: - you will encounter problems on all platforms! - X11: many characters are missing, but that may be related to bad fonts on my machine. I also could not do any keyboard tests yet. Rendering seems to generally work ok. - Win32: US and German keyboard worked ok, but no compositing was tested. Rendering looks pretty good. - OS X: redering looks good. Keyboard is completely messed up, even in US setting (with Alt key) - all: while merging I have seen plenty of places that are not entirley utf8-safe, particularly Fl_Input, Fl_Text_Editor, and Fl_Help_View. Keycodes from the keyboard conflict with Unicode characters. Right-to-left rendered text can not be marked or edited, and probably much more. Nevertheless, this is a good time to get the Doxygen stuff over, so please go ahead. In the mean time, I will start fixing the keybords and try to find all char* handling that doesn't take utf8 into account. Please do not use this version in any public programs! Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unicode, utf8, glib, and licensing
On 09.09.2008, at 16:12, MacArthur, Ian (SELEX GALILEO, UK) wrote: Anyway, GLib contains among many other features all the Unicode handling routines we need for FLTK1. Sure, most of the stuff is already implemented in the patch (some code even twice or three times ;-), Yes - sorry about that. I had tried to move most of the functions to use the fltk-2 versions (presumably from Bill?) as an alternate to the OksiD ones from the 1.1.6 patch. I assumed that would allow the fltk-1 and flkt-2 trees some commonality. But I didn't remove the OksiD stuff, and there was some other clutter in there already, so... Hence the current mess. No reason to apologize. Important thing is that we have a nice foundation. Merging code is much easier than writing from scratch. But... It seems to me that the key thing that might make using Glib (or emulating Glib if we can't use it directly) an attractive proposition, is PanGo. Being able to render Unicode glyphs (which is all the patch does) is only the start of the problem. If we actually want to be able to handle text from non-LGC languages, we need a layout engine that knows the language rules. (I'm not writing one of those!) However, there are several options available, and PanGo is a prominent one. But it depends on Glib. But if we have (or emulate) Glib, maybe PanGo will play for us too...? I really am not sure about this at all. Ah, I see. Very interesting. This would open up new possibilities (commonly known as cans of worms ;-). W could emulate the fraction of GLib that we really need for fast and light rendering, but (eventually - no worries yet) allow linking with an original GLib as an option (when our Thailand user base increases significantly...). Thanks, Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygen 1.3 matrix work proposal initiative
On 08.09.2008, at 08:53, Fabien Costantini wrote:
Membergroups are created by putting functions in order and bracketing
them with //@{ and //@}
Matt, I think there's a private branch with doxygen content in the
repository, is it yours and if yes, is it worth (re-)starting from
it or getting some stuff out of it ?
It may well be that I checked that in, but it is possibly for 1.1.5. I
do not think that we can benefit from that anymore (except maybe as an
example, but Doxygen eveolved and so did FLTK).
I did already put some Doxygen comments and a Doxyfle into the current
1.3 svn, including some text pages in .../documentation/*.dox, and all
documentation for Fl_Widget. Not perfect, but somewhat workable.
The first issue I would like to get out of the way is the decission if
Doxygen comments go:
1: all d.comments wherever the definition lives (into the header files)
2: all d.comments into the source files (implementations that exist
only in the header must be cross-referenced)
3: all d.comments wherever the implementation lives (classes, types,
enums, and inlines into the headers, functions into the source)
Next, we must unfortunately wait until I have applied the UTF8 patch,
or patching will be hell and take forever. There is a good chance that
I will have the patch applied pretty soon and merge back. That doesn't
make the library lean and perfect yet, but we can then doxygenate and
streamline the unicode at the same time.
Creating ranges of STR worked very well last time. I suggest that we
simply use a group of STRs, describing the help files that need their
contents copied over. If marked active and done correctly, we will
not have any duplicate work.
Anyone who can make a list of files in the /documentation directory
and split them into STR's?
http://robowerk.com/
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygen 1.3 matrix work proposal initiative
PS: I would like to emphasize that it is much easier to mark the HTML files, not the H and CPP files for Doxyfigenication. Using the H files you *will* lose existing documentation that is not referenced from the source. Using CXX files, you will lose even more docs because they contain only part of the interface and none of the extra tables. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [fltk.commit] [Library] r6185 - in branches/fcwrk13: fluid src
On 02.09.2008, at 00:21, fltk-dev@easysw.com wrote:
Author: fabien
Date: 2008-09-01 15:21:14 -0700 (Mon, 01 Sep 2008)
New Revision: 6185
+class fl_process {
Hi Fabien,
Thanks for adding fl_process to fluid!
I would like to suggest to use Fl_Process as a name instead (with the
capitalisation) to match FLTK style.
Secondly - and I knw that some don't like this kind of development -
but what about an extension similar to fltkimage, called fltkthreads,
which provides widgets (see below) that deal with Fl_Process, threads,
and locks in a crossplatform and FLTK compatible way (and to be
honest, we do use threads and locks already anyways, so it is not such
a rare feature).
Also, what would you think about deriving Fl_Process from Fl_Widget?
Using a widget that can be part of the GUI is wonderful for debugging
or even for a final app. In my communication widgets (RS232 and TCP/
IP) I use Modem style round lights. They are gray if the port is
closed, green when idle, and blink read if there is traffic in either
direction. I'll be happy to send you the code.
Matthias
http://robowerk.com/
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6185 - inbranches/fcwrk13: fluid src
On 02.09.2008, at 12:43, Fabien Costantini wrote: Secondly what about an extension similar to fltkimage, called fltkthreads, it would make sense to me, but for now I think it would be wise not to do such things until we fixed a bit the makefiles, Yes, absolutely! Also, what would you think about deriving Fl_Process from Fl_Widget? I would not advise this. Fl_Process should be as light weight as possible and IMHO not initially related/independant to widget use. Deriving from Fl_Widget/Fl_Box would add very little code and only about 80 bytes at run-time. Only a draw() function needs to be implemented and the rest stays as is. It as alos not neccessary at all to make this widget visible anywhere or even add it to a hierarchy. It would then behave exactly as your original class. I am looking forward to your merge (and I already have an application that will use this feature). I can eventually branch a version with my suggestion for you try out - then we decide. But first I need to clean some of the mess I made in 1.3 :-P Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC Should CMake be responsible for ms visual targets generation
On 01.09.2008, at 01:05, Greg Ercolano wrote: Fabien Costantini wrote: On one hand, cmake would avoid this difficulty, on the other hand, it is not a good thing to force new users to get cmake for using fltk. Not being familiar with cmake, it sounds like a big thing. One option might be gmake. Another subject that I have been torturing my old brain about. I came up with an XML (or whatever) database containing unified instructions for building every library and executable in the archive. The XML then gets merged with multiple IDE description files (extracted from an original IDE or makefile) using a scripting language (lua came to mind, using the same philospies as FLTK, but anything is fine). Building the IDE support would be similar to building source code from Fluid files. Adding a new IDE/Build environment would be independent of 'cmake' developers, and adding a new source file or test program could be done by simply adding that file to the database and regenerating all build files by calling the script. Now if we get ten more full-time developers on board, we could add GUI to this, plus downloadable extensiens from the former Bazaar, plus... ... ah, never mind ;-) http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC Should CMake be responsible for msvisualtargets generation
On 01.09.2008, at 17:51, MacArthur, Ian (SELEX GALILEO, UK) wrote: As for now, we have unix makefiles, cmakefiles, watcom makefiles spreading over the whole fltk directory structure, and more important, we have cxx file lists spread as well. To be even more clear, I would not mind that much to add even more files (without functionality regression or not too much) if I was sure it would reduce the occurence of files to modify each time we add or remove a source cxx file. As much as possible, it would be great to simplify the build distrib and probably not a good idea to add more build environments at least for 1.3 ... As an idea (probably impactical) Is there some way we can generate one master list of .cxx/.c files, and one list of .o files, and having all the variant build scripts/tools include those? So then all we need to do is keep that list up to date and everything else will just work. Maybe? Well, no, unfortunatly. The VC and Xcode files AFAIK allow no include statements or any pther kind of preprocessing. Cmake would solve all this. I am not against cmake, I just never successfuly set up anything with it. But my last attempt was maybe seven years ago, so my opinion doesn't really count ;-) Maybe one crazy idea would be the use of the C preprocessor to generate the IDE files, so there would be no need to install any binaries. But it is probably not powerful enough. But whichever tool we use is only important for the core developers, since I assume that we would pre-create and distribute all common IDE files anyways, right? I do want to briefly go back to my original proposal: would it be useful to have some kind of contribution setup, so that new widget types and other patches can be integrated into the tree *and* inot all IDE's? Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC Should CMake be responsible for msvisualtargets generation
On 01.09.2008, at 19:06, Albrecht Schlosser wrote: matthiasm wrote: But whichever tool we use is only important for the core developers, since I assume that we would pre-create and distribute all common IDE files anyways, right? IMHO not only the _core_ developers, but also everybody who uses svn to access the newest version, if they would use on of the IDE versions for development. Otherwise, everybody who has svn write access and could add a new file to the svn repository, would have to create all IDE files before checkin - but how could that be achieved ? ... Just thinking loud ... You rerely need to change the IDE support files. This operation is limited to adding new source files or binary targets. Just changing or adding code in existing files should not require modifications to the build system. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
On 01.09.2008, at 22:27, Brian wrote: Btw fltk::HelpWidget really needs to have the contents clipboard copyable. It does in FLTK1. It should be possible to port that feature to FLTK2 from the FLTK1 code. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
On 27.08.2008, at 22:31, Rafal wrote: So I would vote * I would add a bit more debugging code and perhaps even leave more important one on even in release (users do not care if applications reacts to button press in 0.152234 or 0.152216 seconds) What do you mean by that? I don't have any problems adding for example assertions where they make sense. Or are you talking about coding style verification? Or structural control? Oh, and about your previous points of copying strings: I didn't mean to say it is bad to copy labels. I merely wanted to point out that an application always has three times as many widgets as one would think ;-) . It is always good to provide a library that is tollerant and helps the user. I would go even further and not only copy the label, but also pre- store wrapping information, graphical elements (@-notation), and the position of possible shortcut-underscores. It would make the HelpWidget a hudred times faster and speed up the rendering of other text considerably, and especially on small machines (embedded, PDAs, etc.) a spiffy interface is IMHO more important than RAM usage (just don't underestimate the number of widgets ;-) Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
On 27.08.2008, at 23:58, rlseal wrote: This policy is justifiable? So I should create storage for all of my labels and then pass via pointers to all of my other widgets - making me maintain this storage for the lifetime of the widget? Then I decide to delete my widget; leaving my label to live a free and happy life, unbound from that nasty widget, free to roam on its own, and possibly even escape death at the end of the program's life if I'm really not careful. I think I would rather have the widget responsible for its own stinking labels and let me place my worries elsewhere. Oh c'mon, now you are going overboard. A common way to create Widgets is to write something like: Fl_Box *b = new Fl_Box(10, 10, 20, 20, My Box); Now, My Box is part of the program memory and will be available throughout the lifetime of your application anyways. No additional work for you at all. If you do need the label copied, all you write is this: Fl_Box *b = new Fl_Box(10, 10, 20, 20); b-copy_label(translate_to_german(My Box)); and the widget will manage memory for you. There is no need to have your label monitored at all. And your label will never escape death at the end of the program simply because all memory an application allocates is freed when the app terminates (unless you are programming Amiga OS 1.3 and earlier). Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
On 25.08.2008, at 01:00, Rafal wrote: [EMAIL PROTECTED] wrote: The vast majority of widget labels tooltips are compile time constants Other than your own apps, do you have any evidence whatsoever to support this statement? I also disagree with saying that majority of labels are compile time constant, because: 1) mostly: translations 2) and also: dynamic labels (i.e. gui with more dynamic elements) I find the whole idea of labels wrong. Many widgets in a UI have no label at all, and many widgets may have pretty complex labels with embedded symbols, images, varying fonts, undelining, etc. . We are helping ouselves with the @-notation, complicated code, exceptions to the rule, images that are unpredictable in alignment and so forth. My proposal would be (and it solves the problem above as well) to stop continue what was internally done already and pull all label code out of the widget and simply allow any kind of widget as a label-child of a widget. The advantages should be obvious: create html based complex labels, simple one-text-liners, or image labels. Even the existing interface can reain the same. There are merely two additions that need to be done: 1. FL_Label (yes, that struct exists in Fl_Widget.H already) needs to be upgraded to become a widget and 2. the parent widget must use the alignment flags and its own corrdinates to position the label child correctly. Everything else is alredy in the code. This also solves the problem that started the discussion, because now the text interface converts into a value() call to the label widget, which by definition will duplicate the value anyways. Like it? Matthias Example w = new Fl_Value(10, 10, 200, 200, Hello); would internally call this: w = new Fl_Value(10, 10, 200, 200); w-label(new Fl_Label(Hello)); The label position and size is calculated and render time, just as it is done now. However the additional abilities are great. Imagine this: w = new Fl_Button(10, 10, 200, 200); w-label(new Fl_Html_Widget(You imust/i click me); or even, finally, the icon in front of some text: w = new Fl_Button(10, 10, 200, 200); w-label(new Fl_Group()); new Fl_Image(myIcon.gif); new Fl_Label(click here!); w-label()-end(); As an additional bonus, we would lose the labelsize and labelfont vs. textsize and textfont interface (and only keep it for source code compatibility). http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2 (also concerning FLTK1)
On 25.08.2008, at 14:49, [EMAIL PROTECTED] wrote: Having done this, I think there wouldn't be any remaining meaningful distinction between Widget and Group, and the latter could be eliminated altogether. That would be a Good Thing (tm), imo. I have thought about that quite a bit and I am not sure we hould do that. The functionality is quite different. A group *contains* a bunch of other widgets. The label however is strictly connected to a single widget and positioned in relation to the widget, possibly outside of the widget bounds. This is not to say that a widget should not be a group. This can be useful when deriving new combined widget types. It appears to me however that the label should be seperate. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
On 15.08.2008, at 16:51, Dejan Lekic wrote: Anton, there will never be a merge between those two. If it did not happen for last 8 years, then there will be no merge in next 8 years. - So, probably never. It is a pointless discussion, because it is clear even to blind eyes that there are two fractions - conservative one which like Fl_/fl_ and modern/liberal (i would add radical here as well ;) which is brave enough to accept new/modern ideas. Thus I follow Mikko's (who contributed large amount of FLTK2 code) advice and maintain my own FLTK2 branch in a GIT repository, and wait to see what will others decide. My FLTK2 branch is heavily modified from FLTK2 in SVN because I use STDC++ templates/classes a lot, and I am planning on using Boost as well. Soon there will be a new C++ standard released, and FLTK still uses some prefixes to avoid name collisions... I have no words for this... Yes, some people are fine with this - I AM NOT. OK, the sum of your mails finally makes me write this. I should probably have written this two years ago. FLTK2 has become a pool of unnerving, buggy, rotten code, spread all over the world. All FLTK2 developers (and who knows how many there really are) seem to have taken a private version and developed it in their own repositories. You have taken a perfectly fine library (the old FLTK2), and basically ripped it to shreds for your own purposes. But hey, it is OpenSource, so you guys can do with it whatever you like. But by opening your own branches and not using the main repository anymore, you have created something that has nothing to do anymore with what FLTK once was. Again, it's fine. Adding templates, Boost, namespaces, etc. is all valid, but making the library fat and unstable give FLTK a bad name. FL stands for Fast and Light. FLTK1 is known to be extremely stable, but all the fighting about the diverging versions and lack of maintenance scares users and potential developers away. Even Bill recommended at one point to continue with the FLTK1 core. What a shame that all the useful inventons in FLTK2 have been dilluted to a nothing. So my suggestion to the new FLTK2 developers: if your new library is neither Fast nor Light and lives in repositories outside of fltk.org, then please rename your libraries and get off of the fltk.org mailing list. Call it HUTK and secure that domain. www.hutk.org is available and I am happy to pay domain registration for the first four years for you. It has the added benefit for you of not having to read my blurbs anymore. Matthias PS: This is my personal opinion. Other developers and maintainers may or may not see this differently. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] enums vs. typedef/int
On 15.08.2008, at 22:04, Torsten Giebl wrote: Hello ! Things that i would change is to use Uint32, Uint16, Sint... everywhere, instead of unsigned short, This also should make FLTK more portable. Um, Uint32, Uint16, and Sint are *not* portable types... Not directly yes, you would need a typedef of course, but it makes the code more readable. An unsigned int maybe that size on this system and that size on another system. True. FLTK already has U8, U16 and U32 for that purpose. For this specific purpose though, I have simply used unsigned, because by definition, an unsigned int fits into a register and would also be at least as large as the original enum (4 bytes). This way I get maximum speed on all platforms (I assume). Fl_Align inside Fl_Widget is defined as an 8 bit bitset to continue to save space... . Anyway, I commited the changes to the current 1.3, hoping it will stay mostly compatible. Also added some Doxygen code to make it look good in the docs. Matthias PS: on a sideline, reading a 16 bit variable on an (older?) ARM CPU takes twice as long as reading a 32 bit variable... . http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] enums vs. typedef/int
As usual, I am torn between ideas for FLTK 1.3. I am starting to
really dislike C++. Anyway. Here is my issue:
enum sucks! Fl_Align is an enum, which would be great to keep
alignment variables type-safe. Always a good thing for the known
reasons. But Fl_Align is not *used* as an enumeration, it is used as a
set of flags, which leads to silly constructs like these:
myWidget-align( FL_ALIGN_LEFT | FL_ALIGN_INSIDE )
which would be great if it was type-safe and worked. Unfortunatly,
or'ing two enums makes them an integer, so we end up casting values:
myWidget-align( (Fl_Align)(FL_ALIGN_LEFT | FL_ALIGN_INSIDE) )
Now we managed to throw type safety over board, combined with a bad
cast, so it should actually be:
myWidget-align( reinterpret_castFl_Align(FL_ALIGN_LEFT |
FL_ALIGN_INSIDE) )
Now you may yawn and tell me that this problem is as old as C
itself. My question to you then is: is it a good idea to convert all
enums that are not used as true enumerations (pretty much all of them)
from
enum Fl_Align {
FL_ALIGN_LEFT = 4,
FL_ALIGN_INSIDE = 16, ...
to something like this:
typedef unsigned short Fl_Align;
const Fl_Align FL_ALIGN_LEFT = 4;
const Fl_Align FL_ALIGN_INSIDE = 16;
to get back to the readable, but somewhat unsafe:
myWidget-align( FL_ALIGN_LEFT | FL_ALIGN_INSIDE )
(on side note, enums are always 32 bits and FLTK is wildly casting to
uchar or whatever, causing big headaches when more than 8 bits are
needed)
Matthias
http://robowerk.com/
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] enums vs. typedef/int
myWidget-align( FL_ALIGN_LEFT | FL_ALIGN_INSIDE ) myWidget-align( (Fl_Align)(FL_ALIGN_LEFT | FL_ALIGN_INSIDE) ) I forgot to add that the first version is only possible because the prototype of align is align(uchar), so no enum is expected anyways, and no type safety is currently given. The disadvantage here is as I mentioned a possible extension from uchar to short or int which requires a scan for every place in the source that uses an alignment. A correct protoype of align(Fl_Align) would solve this big source of bugs, but bring the previously described problems. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] enums vs. typedef/int
On 13.08.2008, at 13:27, Duncan Gibson wrote:
Isn't there an idiom where you declare a class, but its constructor
is not public, and then have instances declared at class level?
A quick search of the Internet for C++ enumeration class throws up
various possibilities using templates, and also this one:
http://www.kolpackov.net/projects/c++/enum/class.xhtml
I have only given this a cursory glance, but could something like this
form the basis for what you want?
It seems neither fast nor light, and somewhat hard to debug. But I
would have to look a bit more closely.
I found another solution which may bring the best of all worlds,
assuming our compiler optimizes well:
inline Fl_Align operator|(Fl_Align lhs, Fl_Align rhs) {
return static_castFl_Align(lhs|rhs);
}
and so on for operator, operator^, =, |=, and ^=, possibly operator~
What do you guys think? Or should I just leave this matter alone? :-)
Matthias
http://robowerk.com/
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] enums vs. typedef/int
On 13.08.2008, at 15:13, Roman Kantor wrote:
matthiasm wrote:
inline Fl_Align operator|(Fl_Align lhs, Fl_Align rhs) {
return static_castFl_Align(lhs|rhs);
}
I like that, but your global operator seems to be recursive!
maybe
inline Fl_Align operator|(Fl_Align lhs, Fl_Align rhs) {
return
static_castFl_Align(static_castint(lhs)|static_castint(rhs));
}
Um, yes, what you said.
As an addition to previous arguments:
I know that type safety does not ensure that a program runs well, and
of course there is always someone who casts it away. But currently,
the function align(uchar a) needs an explanation. align(Fl_Align
a) is much clearer, and if then in the documentations, Fl_Align is
an (automatic) hot link to the enum, life *will* be easier.
Oh, and the same is true for Fl_Font, Fl_Boxtype, Fl_When, etc.,
Fl_Event being the exception.
http://robowerk.com/
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK V1.3.x-r6155 Fl_Widget.H broken
On 11.08.2008, at 17:40, John P. Pfost wrote: Updated to latest revision 6155 for FLTK V1.3. The Fl_Widget.H had a couple of problems compiling under Windows Visual Studio 2005. Find below my changes: Doh, tanks. Will submit changes in a minute. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6157 - branches/branch-1.3/FL
On 12.08.2008, at 19:22, Albrecht Schlosser wrote: I found some typos (look for ***, formatting best with fix-font). I hope that it's wnough context to find the places. Sorry, I'm not yet on 1.3 svn, therefore I can't provide a patch. Thanks Albrecht. Very helpful. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk on symbian... progress
On 05.08.2008, at 18:42, Fabio Garbin wrote: Hi Matthiasm / Szasz Pal, Do you got a port of FLTK to Symbian ? No, I don't know about a Symbian port. I'm trying to port to Windows Mobile.. There is some code out there that works on WindowsCE. One link was posted maybe anout a year ago. I also managed to get a proof of concept going in under a day. But there is no out-of-the-box version yet. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] OpenMoko
On 29.06.2008, at 13:24, SA wrote: I would just like make a success report. FLTK compiles and runs unmodified on OpenMoko :) Absolutely awesome. That s wonderful! That is with a full X Server, right? A future version of FLTK will support direct framebuffer accesss (there is actually a running prototype out there). Would that help OpenMoko? Is the FreeRunner available to the general public yet? I'd love to streamline FLTK for it. I am working on pen/touch/tablet support at the moment. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] OpenMoko
On 29.06.2008, at 16:53, SA wrote: You can see my application (Unicom) running on QEMU-Neo1973 here: http://tnij.com/HF8Z Cool. I just contacted the dealer. Should be no problem. But how am I going to explain this to my - um - iPhone? ;-P http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
On 29.06.2008, at 18:39, Roman Kantor wrote: matthiasm wrote: 2: there is much more to the new API than the new namespace. Widgets are named much more consistently (Fl_Tabs became TabGroup, Fl_Pack became PackGroup to indicate that they are groups, etc. etc.). Well, if you want to be pedantic, then the names would be TabGroupWidget, PackGroupWidget etc and to express more descendant classes you would end up with very long names, which can be sometimes very confusing (like CheckLightButton, because light button is inherited from light button). If you have good documentation (ie generated by Doxygen) and/or self-regarding editor or IDE, then it is very easy to get the info about base class or inheritance tree. This things remind me Hungarian notation which I personally hate with passion. Of course I don't want the entire inheritance in the names. A group is so essentially different from a non-grouping widget that it would make sense IMHO. I always understood and supported that FLTK has to be as stable as possible. I am quite surprised to see though that even API changes seem to be unwanted. But that's fine with me, either way. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
On 27.06.2008, at 07:40, Michael Sweet wrote: I understand all of this, but my real point is: what does this actually buy us? To be honest, I have 0 interest in compatibility with the current FLTK 2 API, and re-creating the/a FLTK 2 API with FLTK 1 wrapper headers seems like a poor reason to re-transition to the fltk namespace. 1: the advantage of using name spaces apart from naming conflicts can be less typing. For example: Fl_Box *b = new Fl_Box(1, 1, 10, 10, Hallo); b-align(FL_ALIGN_LEFT|FL_ALIGN_INSIDE|FL_ALIGN_WRAP); would be: using fltk; Box *b = new Box(1, 1, 10, 10, Hallo); b-align(ALIGN_LEFT|ALIGN_INSIDE|ALIGN_WRAP); Sure, it may also become more confusing, but that all is a matter of taste, coding sttye, and possibly coding discipline. 2: there is much more to the new API than the new namespace. Widgets are named much more consistently (Fl_Tabs became TabGroup, Fl_Pack became PackGroup to indicate that they are groups, etc. etc.). FLTK2 sticks with one single naming scheme (almost) all the way through to keep the interface easy to understand. 3: there are are few logical changes modifying inheritance. Fl_Image, Dymbols (you know, the @circle stuff), and boxtypes are now derived from the same base class, so where ever you can use a box in FLTK1 ow, you can just as well use a collection of images, and wherever you insert symbols into a label, you can now insert an image as well. That is really neat for prepending a little icon in front of a Browser entry. Is that enough of a big deal to make it worth an API change for FLTK1? I don't know if it is worth it for the old crew, but it sure makes the API look more modern and cleaned up for new users. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
On 20.06.2008, at 04:48, Anton Novikov wrote: Please look at the basic code from FLTK1 and FLTK2 (x, osx, Widget/Fl_Widget). It's inherently small, and coupled with base classes. I copied source files that seem to me containing basic code(I chose them quickly, mainly basing on filenames, so it's unprecise). it's fltk-1.1.8 [EMAIL PROTECTED] src % ls src_basic filename_absolute.cxx (...) I have to say that this is starting to look like a viable solution. Seriously, I am starting to really like this! So here is my suggestion (step by step, because I need to lay this out for myself, too): - we immediatly stop any development on 1.3 and 2.x (that's the easy part ;-) - we set up a new branch in the SVN called FLTK 3 (ah!) - then copy *both* code bases into this branch, renaming directories so they can coexist (src1, src2, test1, test2, ...) Now we start another library inside all this: FLTK3 - we need to set up a directory structure to support a modular FLTK3 - we need to merge the autotools environment and IDE project files of F1 and F2, so that *both* libraries *plus* F3 will be built, and both F1 and F2 link against F3 (which is still empty at this point) - we need to set up a system for regression testing And now comes the big trick: - we create the F3 OS support and core by *moving* and merging F1 and F2 core files (see the list above). The trick is not to *copy* those files, but to *move* them. That means that F1 and F2 will *loose* functionality in its own core, but will regain an improved functionality by linking back to F3. This trick has a many advantages: 1: no coding is done twice (we need to keep a minimal glue layer between F1 and F3, and F2 and F3 though) 2: all developers work on the same project 3: all developers can review their peer's code 4: all *users* can continue to use their favourite API with a stable understructure (and keep testing what we write) 5: we *finally* present a unified image to the outside world again We will reach a point when the core is ported and individual widgets will have to move. If everything works as I expect, we will then be left with the compatibility layer that I mentioned in an earlier mail. Nice. I am all for it. Let's do it right. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
On 20.06.2008, at 14:07, MacArthur, Ian (SELEX GALILEO, UK) wrote: When we do the merge, and we find differences between the nominally similar F1 and F2 implementations, how do we choose between them? The code should follow a similar basic structure. After all, FLTK2 *is* based on FLTK1. We should read through the code and understand why the code differs and choose the sections that seem correct, keeping in mind that F1 is extremely stable, but F2 already having UTF-8 built-in. I hope that the core does not differ too much. I know that the OS X code for one was only added two years ago and has since then seen ifferent(!) bug fixes in F1 and F2. A merger here should solve the last remaining F1 OS X opsies as well ;-) - until we move away from Carbon to Cocoa and have to rewrite half of the code anyways... . Sigh. Also, how do we decide exactly what the F2 API is, as it still seems to change...? Still, with this approach, maybe that doesn't matter so much... The F2 API is indeed much better, but there are still a few inconsistencies. For F3, I would re-read the coding standars document http://fltk.org/cmp.php#CODING_STANDARDS and change the API to match thoroughly. If we follow the process as described, we will reduce the F1 and F2 parts of the new project into a source-code level compatibility layer which will even out most differences to F3. We can always test back-compatibility by keeping the F1 and F2 test directories around until we are satisfied with F3. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
On 20.06.2008, at 21:04, Anton Novikov wrote: - we need to merge the autotools environment and IDE project files of F1 and F2, so that *both* libraries *plus* F3 will be built, and both F1 and F2 link against F3 (which is still empty at this point) that would be a bit confusing - fltk1 and fltk2 depending on fltk3 :) I like the idea of having them all bundled together, but I'm for the abstraction layers being a separate library. Ah no. fltk1 and 2 don't depend on fltk3. The f1 and f2 compatibility layer will. ven though we are starting out with the full library, we will end up with very little code in the f1 and f2 directories, sometimes just with a header file. - we need to set up a system for regression testing yep, that would be nice. everything but windowing can be tested automatically. by the way, if we go for it, that would be a good time for changes in infrastructure. for ex.: 1. Switch to a distributed revision control(git, mercurial). I myself switched from SVN to Mercurial some time ago very easily. It has its advantages(most evident - local commits). I have used GIT and SVN. SVN was always sufficient for me and has a great front end. Please explain (or give me a reference where I can read this up) how GIT will improve revision control. 2. Make a web interface to revision control system. Like: http://hg.sharesource.org/sharesource/ I never needed that because TortoiseSVN provides that much faster, but again, I am happy to learn why this is useful. 3. Improve bug trackers - add keywords, for ex. to group bugs based on the subsystem involved OK, that should not be too hard. You can do much more complex text searches than meets the eye already though. I will put this in the hand of those who know more about regression testing and version control than I do. When I studied Computer Science, version control meant using another audio tape to store your source code and keeping the old one away from the little sister ;-) . 1: no coding is done twice (we need to keep a minimal glue layer between F1 and F3, and F2 and F3 though) I think fltk2 needs no compatibility layer. the moved interface will be itself usable. Those who use fltk2 don't expect the API to be immutable, I guess ;) I do not want to predict to what extent we will change the F3 API, but a simple compat layer may coem in handy. That's up to the FLTK2 folks though. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
On 18.06.2008, at 09:39, Anton Novikov wrote: 2) (...) When fltk2 gets stable, everybody will be using quantum computers with 3D golographic displays. (...) Oh please! Granted, it took two years to go from a pretty stable 1.1.7 to a very stable 1.1.9, but that is mainly because we were limited to a handful of otherwise busy developers. What FLTK 2 needs to do is stop adding little features here and there and start fixing every known bug. I know it is painful. I have been there. Nobody likes to fix bugs when he could be implementing cool new features, especially if those bugs don't interfere with my own projects. But lets face it: every little new feature will cause at least four bug report and ten requests on how to make that feature even better. But unless all known bugs are fixed, a software will stay in beta (actually alpha, by definition). My suggestion would have been to write a (close-to-perfect) compatibility layer form FLTK1 to FLTK2, so that all F1 users can switch to F2 without losing anything. I have a prototype that supports derived classes and the full FL hierarchy with very few limitations, so even the most sophisticated FLTK1 hackers could move on with no changes to their source code. Unfortunatly, this will never ever fly unless F2 is as stable as F1. So if F2 has no feature stop and only occasional bug fixing, what are the other options? - Fix and emulate: the F2 team fixes F2, the F1 team creates a better emulation layer - F1 core, F2 API: make the FLTK1 API similar to FLTK2, but keep the F1 core and adapt F2 changes? - Megre by function: merge the libraries bottom up (basically your idea?) and hope that the combined code remains stable? - Merge by line: merge line by line in a Petri dish, creating the essence of F1 and F2, calling it F3 - Weave: merge line by line while keeping the sum of code functional - Kill one: abondon one of the two branches entirely - Kill both: or finally rename obne of the libraries and split into two independent projects I have been weighing all this back and forth, trying to think of the existing user bases first, but also how to attract new users (definatly not with a confusing versioning), and how to attract (and keep) core developers. PS I didn't mean to offend anybody. Really. No offense taken. I am still trying to find the perfect solution. PPS What about IRC? I am not the IRC kind of guy. I prefer news groups so that all communication is sorted and documented. There was an IRC channel open for a while, but I never managed to join it. I may try to listen in the next time around. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] STR #50: fluid: selecting an object in a tab does not bring tab to foreground
On 16.06.2008, at 18:50, Duncan Gibson wrote: I posted a possible patch to solve this feature request yesterday, but didn't see notification of it on my other account. See http://www.fltk.org/str.php?L50 Hope it's up to the required standard and I haven't missed anything. Oh, thanks. I will have a look at it as soon as I find the time. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK dashboards at Kitware
On 19.05.2008, at 19:17, David Cole wrote: Is there any interest in this community of keeping alive a nightly build/testing dashboard for FLTK? Read on for the motivation behind the question... (...) If anybody in this forum would like to keep it alive, please send email directly to david.cole (at) kitware.com. If nobody expresses interest in the next few days, I expect we will simply let it fade away. Hi David, I really like the idea of a nightly build, and there could be so much learned from it. Unfortunatley, the frequency of submissions to the repository is extremely low, so I am not sure just how much attention this service may get. Or in short: if you can, a nightly build for FLTK1.3 and/or 2.0 would be somewhat usefule, but if you need the resources otherwise, please give other projects the preference. Thank you, Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Changing STRs close w/o resolution
Maybe I should explain. I decided to change most closed w/o resolution issues to either active if the issue may apply to 1.3, or to close w/resolution if the issue is not in our hands anymore. Even if there is no final and true resolution to some issues, most of them are related to wrong usage with the user never verifying if the suggested solution worked. Since we will never touch this issue again, I believe we should regard it as resolved w/resolution. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk 1.1.8
On 12.04.2008, at 13:15, Yuri D'Elia wrote: Hi everybody, I was quite swamped with work lately, but I should be back now. Nice to have you back. I noticed there is one verified regression for 1.1.8 (fl_file_chooser) and one small fix in the Fl_Help_Viewer. Thank you very much for the offer. 1.1.8 is as final as needed, and since it contains a crash bug, I already started 1.1.9 with the two bug fixes as a release candidate. If there are no more bugs for a week, I will release 1.1.9. Should a 1.1.10 become neccessary, I will be happy to take you up on your offer. 1.3 hasn't started yet at all. I will be very busy until next Sunday. Starting on Monday however I will have four to six hours a day for two weeks to spend on 1.3 :-P. Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] FLTK 1.3 and UTF8, a first look
In case you have been wondering why I have not checked in the UTF-8 patch yet: I have been reading the diffs for the last few days, and I was quite surprised about the amount of code that needs to go into UTF-8 support. It took me a while to decide if I want to port pieces of the UTF-8 patch and fix them while porting, or if I should just apply the patch as a whole and then smooth out the kinks. I decided to do the latter so that all authors of the patch can help to improve what we got. I will try to submit the patch to the SVN in the next days, but I have a show comming up, so I may be slow. A few issues: 1: Thanks to the authors for this insane amount of code which must have taken a lot of work and frustration to create. I would like to keep as much as possible intact, however: 2: I saw double code and some naming convention inconsistencies which I would like to solve. Details to follow. 3: I would like to integrate the xutf top-level directory into the src directory somehow. Since all 1.3 applications will be UTF-8, there is no reason to link with another library if the code can be in the original library. 4: On OS X, the keyboard does not generate Uincode yet. I have not tested any other platforms. 5: we must update all the non-makefile IDE project files (CMake, vc2005, vcnet, visualc) 5a: are there any IDEs or compilers we can drop entirely? Watcom? Thanks for this great patch, Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
