On 27.10.2011 02:30, David wrote:
>> On 27/10/11 10:10, David wrote:
>>>> Should I create a new branch and do the updates to it, try to do
>>>> incrementally, because some of the files change a few times for different
>>>> things. Do I have access to branch?
No.
>>> Looks like the way to go - but I have to wait until I have permission.
That's not likely to happen anytime soon. The FLTK team's policy is that
you need to submit some patches that are good and accepted before you
get write access. You must also show that you understand FLTK as a
system that can't be changed easily w/o breaking existing code. Solving
one's own problems is not the same as changing a toolkit with backwards
compatibility and side effects in mind...
>> I don't quite understand the question -- are you asking for SVN write
>> access, or something entirely different? You can create a 'local'
>> repository (on your own machine) and initialise it with the current fltk
>> svn version. You can then quite easily branch this and apply updates /
>> etc as you see fit, and then 'svn diff' your branch against the current
>> head (which you continually 'svn up' against 1.3)
>>
>> Ben
>>
> Yes write, to create a branch so you guys can see the incremental updates
> easily (I presume svn keeps a history that can be used to see various
> versions). If I just did diff's you'd only see the changes combined with the
> other changes.
We are not interested in "incremental" updates. We'd rather like to see
*independent* updates in their own patch sets. This way we can check one
patch, maybe modify it, test it, and eventually commit one change.
Something like the patch (bug fix) I recently committed for radio
buttons.
I suggest that you go for multiple svn checkouts ("working copies") of
the FLTK source tree. Then you can have one (or more) patch sets in one
working copy and create patches simply by using "svn diff > xyz.patch".
This patch can be posted for discussion in fltk.development, or it can
be added to an STR (bug report or RFE). Before creating a patch file,
you should always run "svn up" to synchronize your source tree to the
current svn version. If you see conflicts with the current sources, then
you need to solve them before submitting your patch.
You can have all your personal patches combined in your "private"
working copy (another checkout), so that you can use it for your own
software development. The advantage of such an approach is that you
can "svn up" this working copy at any time to sync with the newest
development version. If this would contain one or more of your patches,
then they could
(a) merge cleanly, if accepted literally
(b) merge with conflicts, if it was changed or you have other changes
In any case you'd have to check the update and solve conflicts in your
local copy.
That said, I don't recommend patching one's own FLTK version. This is
from personal experience, because I did it also when I started using
FLTK. Lack of knowledge of FLTK's features led to customizing features
in the FLTK core (one of these customizations was to change an internal
#define to enable a different behavior). It is well known that it is
difficult to update your own patches when the official sources change,
and this is (will be) a much bigger problem for the transition from
1.3 to 3.0, since the FLTK code base will change significantly. So I
decided to do my own adaptions all in my "user code", and this worked
well. At the first glance this is more work, but eventually it is
easier to manage core updates.
Many things can be done by deriving one's own widgets and changing
the handle() or other methods or adding new methods. One of these
would be to change the button behavior for Enter keys, as you
suggested somewhere else.
Anyway, if you have suggestions for improvements, it is good to submit
them to have them in the FLTK core, so that you don't need your own
adaptions (in user code) or your own patches (in the FLTK library).
But it may take a while until they are checked and accepted, and maybe
they will be postponed to a later version, so don't hold your breath...
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
