Re: [fltk.development] VS failures due to parallel builds
On 2 May 2010, at 10:00, Matthias Melcher wrote: On 02.05.2010, at 10:47, imacarthur wrote: On 1 May 2010, at 22:44, Matthias Melcher wrote: --dbvisualc6 dbname targetpath : create all IDE files for an Xcode3 project I thought this was a typo in Matt's post, but it seems that it really is a typo in fluid's output - i.e. --dbvisualc6 claims to generate IDE files for Xcode... S'ok - I posted a fix. Not the most complex thing I've ever done, but about I'll I've done that's useful recently! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Coding conventions?!
OK. Thanks guys for your time and feedback! But as I was reading Configuration Management Plan I have found that Version numbering guidelines are not respected. So I was wondering why is that so? Also I was wondering, wouldn't it be easier to use tabs instead of spaces for indentation? I am asking this because at least in VIM a 4 space wide tab indent still will be a tab (you can set it for 8 and it will be 8 or anything else... 2). But with spaces it is not the same thing, it is more difficult. Why to use spaces? According to the Coding Standards, in the same plan, the coding style is KR (although there is a minor mistake, in the plan. KR recommendation: Declare function names, return types, parameter types and names all on the one line, if you can.) but it is not followed. Again, why is that so? In the end I wanted to ask if it will be OK if I will use tab indentation in FLTK 2 source code since almost nobody develops it. Further more, project Coding standards states this: If you use tabs, they must be set at every 8 character columns; which means actually no body should be against it. I don't know if Coding standards are followed in FLTK 1.3 so you may just think of this reply as food for brain (How to make others or ourselves to follow the standards? :-) ). P.S. KR coding style also recommends tabs for indentation, not spaces. :-) P.P.S. Yes, I like the damn KR style. :-) P.P.P.S. Sorry if my English is not very good but I will improve it. :-) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2362: Scrollbars fixed in HelpView
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2362 Version: 2.0-feature I was honestly expecting this to take up to a week!! This is really a very very well designed system. Both versions are. Anyway, HelpView scrollbar visibility fixed. In HelpVeiw.cxx around line 2437 following this line. set_changed(); add this line. relayout(); In the same file around line 2834 following this line set_changed(); add this line. relayout(); The temptation is to create a new set_changed for this widget but since this has caused so much of a problem debugging, it's probably best to leave it explicit, if nothing else as example code. The image in the fltk docs is still not showing properly first time around (and similar problems occur with other images). The scroll buttons on the scrollbars are also still brain-dead, either by design or due to some changes in the way groups link so they may need to be daisy-chained manually until we find out why the groups are acting so weird. We're halfway through HelpView... what challenge this has been. :-) But not nearly as bad as I was expecting. Brick Wall v. Head. I'll upload the before (don't see) and after (do see) pix as attachments so in the next couple of posts you can see what's still wrong with our images in v-2.x Link: http://www.fltk.org/str.php?L2362 Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2362: Scrollbars fixed in HelpView
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2362 Version: 2.0-feature Link: http://www.fltk.org/str.php?L2362 Version: 2.0-featureattachment: now-you-do.png___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] VS failures due to parallel builds
So Visual Studio 2008 converts, reads and compiles FLTK 1.3 just fine now. Visual Studio 2010 though fails reading the .dsp files without giving a description. Hrrrm. I guess I have to load VC6 on my machine and check if the output is compatible at all... . Any suggestions welcome. - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Coding conventions?!
Emil Cataranciuc wrote: I was reading Configuration Management Plan I have found that Version numbering guidelines are not respected. Specifics? Also I was wondering, wouldn't it be easier to use tabs instead of spaces for indentation? I am asking this because at least in VIM a 4 space wide tab indent still will be a tab (you can set it for 8 and it will be 8 or anything else... 2). But with spaces it is not the same thing, it is more difficult. Why to use spaces? According to the Coding Standards, in the same plan, the coding style is KR (although there is a minor mistake, in the plan. KR recommendation: Declare function names, return types, parameter types and names all on the one line, if you can.) but it is not followed. Again, why is that so? In the end I wanted to ask if it will be OK if I will use tab indentation in FLTK 2 source code since almost nobody develops it. Further more, project Coding standards states this: If you use tabs, they must be set at every 8 character columns; which means actually no body should be against it. I don't know if Coding standards are followed in FLTK 1.3 so you may just think of this reply as food for brain (How to make others or ourselves to follow the standards? :-) ). The CMP was adopted years after a lot of FLTK was written already, so due to legacy, there's some code not yet to standard. There's a desire to not change old code to avoid making diffs that making it hard to track regressions across commits. Also, some code comes from other sources, and in those cases, its not worth while to conform the code to the CMP to make tracking diffs from the original source readable. All new code should follow the CMP. P.S. KR coding style also recommends tabs for indentation, not spaces. :-) The FLTK coding style is not KR, and purposefully defines tabstops to not be anything other than 8. The FLTK coding style seems to have a strong desire to keep the code width and height as short as possible, hence the 2 space indent and the rigorous use of dangling open braces, including on all functions/methods/classes/structs, which makes it somewhat unique. I'm sure most of the devs don't code in FLTK's style, including me, but when you work on an established project, you follow its coding rules. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
