Re: [Beaver-devel] Next release

[Tobias Heinzen]

> > > When I try to open the index.html and about.html pages from the Beaver
> > > website in Beaver, it can't open them and says they're not UTF-8. Both
> > > pages open fine in Geany and dloads.html also opens fine in Beaver.
> > > The --help and -? flags for Beaver don't seem to work anymore.
> > >       
> > What I also wanted to change is the way the Makefiles handle the DESTDIR
> > variable and how the application uses this. We should use something like
> > a "config.h" file which we include to the application where all
> > directories are getting defined so that they can be used later. I also
> > wanted to add a little dependencies checker into the makefile.
> >
> > I like the way we compile now. I don't want to use a big configure file
> > (like the one from autoconf, since this checks a lot but not that, that
> > you really need to check. also it's just way to complicated for our
> > needs I think)
> >     
>
> I get frustrated many times by the way that autoconf does things.  I'd
> prefer no autoconf but of course that's rarely possible.
>   
Well I don't think that a huge script is necessary. Just a small one 
should really suffice. We don't have much to check (I mean autoconf does 
check for stdio.h stdlib.h and so forth to exist but fails at checking 
the really needed stuff like dependencies on libraries. also it often 
fails because gettext is not installed, but nobody knows why ^^)
>   
> > > I will try to add a 0.3.0.1 screenshot to the site, if you guys have
> > > more, please add them.
> > >
> > > On which CVS module are we going to develop the next release? What
> > > will be the name of the next release, including GtkUiManager, XML
> > > syntax files and plugins? 0.3.2? 0.4.0? I'd say 0.4.0.
> > >       
> > i think we continue to work on the newest module (0.3.0.x). the older
> > ones are just to old (they still use gtk 1 i think and that would be
> > just too much work). Yes the name 0.4.0 would be better.
> >     
>
> 0.4.0 module exists now as beaver0.4.0   At some point I suppose it would be
> wise to have a beaver_current or something so that people don't have to know
> which is the most current version...  We'll see about that in the future...
> for now beaver0.4.0
>   
k cool thanks.
>   
> > But before we start we should think about what we want to do. We also
> > have to maintain the old branch 0.3.0.x until the new branch is
> > released.
> >     
>
> see above.  I'll take care of old code maintenance and leave you two to have
> fun with the project.
>   
I sure will *g*
>   
> > We should keep that in mind. These are the task I think should
> > go definetely into the next release:
> >
> > 1) GtkItemFactory to GtkUiManager change
> > 2) plugins
> > 3) removing of wordfile.txt and introducing language files
> > 4) cleanup work:
> >        - there are some functions and variables that are not used any
> > more. we should clear them out of the source code
> >        - also some features should be cleaned up a bit so that the code
> > is more readable.
> >        - comments. I think trevor has begun to comment some stuff. this
> > is good, really good ^^ that should be continued.
> >
> > the last part (4) is definitively necessary I think personally
> >     
>
> I completely agree.  We should refactor as the as first step.  Once that's
> done, lets convert to GtkUiManager, work on new features like plugins and
> more portable language files, and then we'll refactor again.  On future
> releases we'll be able to eliminate the first refactor step, but I believe
> in having post-feature refactoring as much as possible.
>   
I've got some victims already in mind. The things that I've seen, but 
clearly need some discussion are the following:

1) conf.h / conf.c are handling the loading/saving of the configfile. 
gtk+2.0 has a "Key-file parser" which is exactly what we need. Do we 
want to use the library functions or do we want to use the old 
implementation? The Keyfile parser is in the library we use right now, 
so no extra dependency would be created but the code would be much more 
readable. I think the same functionality could be achieved with much 
lesser code, should help to decrease the memory foot print ^^

What the old implementation could do is support "multiple config files" 
(or I think they do). This comes from the observation because the 
function get_string_conf  is called something like 
"General/Category/Key" and "General" obviously means which config file. 
I do not see the need of multiple config files. Should this feature be 
saved?

2) what about those old files that we don't really use (like 
old_editor.c) could they be removed?
3) do we still need the bl-file load feature (as far as I know that 
thing didn't really worked anyway)? Can I remove it? What other features 
don't we need?