new dev branch stuff

[Danny Milosavljevic]

Hi,

Am Mittwoch, den 19.01.2005, 22:54 +0100 schrieb Eduard Roccatello:
> On Wed, 2005-01-19 at 10:02 +0100, Jasper Huijsmans wrote:
> > > 1) what's our new gtk target for xfce 4.4?  gtk 2.4?
> > > 
> > 
> > If we plan for august, which was mentioned on IRC, then maybe we could aim for
> > 2.6 even?
> > 
> I agree. If august is out target i'm for gtk 2.6.
> 
> > I don't think named pipes or e.g. X messages are necessarily bad. Still a good
> > question though. For xfdesktop alone I wouldn't like to depend on d-bus, but
> > if we are going to use if for an improved configuration system, then I'm all
> > for it. Benny, what are your plans on that?
> > 
> I think dbus can be a good IPC system. i agree for its use.
> 
> > > 3) autogenerated files in CVS.  they are a pain.  i want to remove 
> > > them.  jasper already has for the panel.  jasper is smart.  jasper has a 
> > > ph.d.  therefore we should all do as jasper does.  (am i embarassing you 
> > > yet?)

I'm in favour of dropping autogenerated files :)
'Makefile.in', 'configure' and all those stuff that just gives conflict
always and gets borked from time to time by incompatible autotools
versions... that shouldnt go into cvs... its just a waste of time (list
is: autom4te.cache, compile, config.guess, config.h,config.log,
config.rpath, config.status, config.sub, configure, depcomp, install-sh,
libtool, ltcf-c.sh, ltmain.sh, Makefile, mfclean, missing,
mkinstalldirs, stamp-h1, *.spec - did I miss any?). 
And if a distro's autotools are broken, they better fix them. Not we
workaround.
(For tarballs, the issue is different. They should contain all stuff
needed to be able to just ./configure; make; make install)

Although (here comes the controversial part, and totally unrelated too
^^) I'm also in favour of dropping the generated .c/.h files from cvs in
favour of .gob files (where gob files are used, which is only my stuff I
think). [hmm did I already write that up and am repeating myself? I
wonder... déjà vu]

[If you dont want to know anything about gob, skip to the last line of
the mail ;)]

And I like to use gob2 because creating (and, more importantly,
maintaining and extending) gobjects without gob is just too convoluted
and error prone.
Although there are minor annoyances with gob, they nowhere stack up to
the ones without gob. 

I recently did a small program with a custom tree model and some
thumbnailer objects without using gob2 and it was just painful. I needed
hours to get it to display a simple folder view with thumbnails without
crashing. 

Note that is not to say that I couldnt get used to it and write a
gazillion of 'lint' scripts and remember a dozen of work formulas like
'when I change that place I have to change that and that and that place
to match'. Question is, do I want to go through that for no benefit
whatsoever (it doesnt get faster, it doesnt get leaner, it isnt even
more stylish to write code directly in C, it helps nothing at all.) or
rather do something useful like writing apps?

At least 10% of the time was just making sure I did the wiring of the
gobject's parts at the 10+ different places right. next 10% to get the
property read/write functions to *not* trash the refcounting / crash on
a NULL pointer / forget to deallocate memory / whatever annoyance of the
day .... 
And the stuff with the signal marshallers isnt bad (just glib-genmarshal
on a file with some custom format for the parameters as opposed to just
putting the darn C function prototype in there, really) but its still an
extra nail in the coffin.

Of course there is the argument "as the component's real code gets
implemented, the time spent for writing all those 'filler' code - like
the 'class' structs, the *init functions, the finalize functions,
get/set_property - will not be much as opposed to the total time. But
that is a moot point. components do *not* get big. They come into
existance, then they gain a little functionality and as soon as it would
have become too much functionality it splits and splits and splits up
into multiple components that again are small. So the time spent writing
the 'filler' code actually adds up. That is, it gets worse.

Either way,
Then I needed to change the ascendentant 'class' of one of the objects
because I added a common base class. Again modify 10+ different places
and dont forget one or else it will compile just fine and crash at
runtime. Again the create game for the new base class. Ugh.
(this coming from me, that even finds C++ classes too inflexible to use
for gui programming; so what if I am too demanding *grins*). 

This annoyances are avoided completely by the gob2 approach. Not to
mention new high level language constructs (as opposed to pure C) like
properties, signal handler methods (including property change
notification), automagic parameter sanity checking etc etc, and - that
is the new cool stuff - all that easily! :)
I'd say it fits the area for which it was developed for perfectly, that
is, creating components for gtk/c easily. </advertizement>

(There *are* 'bugs' within gob in relation to new gcc 3.4? pointer type
aliasing rules which I dont quite understand the semantics of but would
like to fix these in gob2 proper. Any pointers?)

Point being, lets get rid of all generated files that have a source
available in cvs right now :)

cheers,
   Danny

-- 
www.keyserver.net key id A334AEA6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20050120/2b7720f4/attachment.pgp>