beaver-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Beaver-devel] Next release


From: Trevor L. Brown
Subject: RE: [Beaver-devel] Next release
Date: Sat, 28 Jun 2008 18:05:56 -0400

> > Hi,
> > Great we now have Beaver 0.3.0.1 online! It will be the start of the
> > big succes of Beaver. First a few things about 0.3.0.1 that can be
> > solved in the next release, then more about the next release.
> >
> > If I open the About window, I saw beaver.orig as name of the program.
> > This is the real name of the executable, Tobias made this
> > construction. But the About dialog uses APP_NAME as the name of the
> > program, which is #define'd in main.h as Beaver. Weird.
> Well sorry about that, but I first thought with symlinks the problem
> would be solved, but the pixmaps didn't get displayed so I had to make a
> script which changes into the correct directory and then start the
> original application. But it's sure strange.

I'll try to work on that one.  I'll take care of bugfixes to the 0.3.0.1
release from here out.  

> > 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.

> > 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


> 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.

> 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.

> >
> > A thing that I would really like, although not necessary for
> > development, is an artist. We need someone to redesign the Beaver logo
> > (about dialog) and make some new images for the new website. We could
> > ask someone to do this as a one-time-job. But what I actually want, is
> > an artist that is a staying part of the Beaver team. That way he/she
> > can design approximately 3 fresh images for every new release. Let's
> > say, one for the About window, one for the Prefs window and one for
> > the Plugins window. You may think: why all those images? Well, we must
> > have a distinguishing element that sets us apart from other editors:
> > Beaver is both lightweigt and looks cool. Trevor, could you put a
> > demand for an artist on Savannah?
> logos and stuff is always cool. Where do you want to but images for
> prefs- and plugins window though? The about logo surely needs some
> update (I do not like that black border around it. but the beaver looks
> really cute ^^)

We can do some votes on new graphics.  Some of what we have is lame, but (as
you point out) some of what we have is really good. 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]