[Xfc-dev] XFCE Foundation Classes alive ??

[Bo Lorentsen]

On 10/23/2010 09:38 AM, Kent Asplund wrote:
> I should have sent a mail I guess but I was only interested in seeing
> if there was any active development.
>    
That would have helped a lot :-) I have been trying to announce a few 
thing in the list, but got no response, and I then just dropped it, and 
kept on making my own changes, for what I needed.
> I am much for lightweight and do not like that we programmers are using
> up the advances in computer technology in a more engineers improving it.
> On the other hand I am very much for OOP and making things robust and
> easy to maintain. These two seems to be slightly in conflict.
>    
Not necessarily, C++ may be bloated but not by nature, but one have to 
be careful about how one uses things like templates and large frameworks 
(due the the implicit cost), with f.ex. several hundred virtual 
functions doing unneeded stuff :-)

I think that Google have the same ambition, when they started out 
investing time in a language like go, where we again have a compiled 
language (imperative, build in structures and functional), with the 
possibility of a small footprint, an no VM (and the crowd goes mad .... 
) :-)

And lastly, I don't believe in on language to rule them all :-) I like 
C++ for system programming (even large GUI), python for larger scripts, 
shell for system automation, javascript for my web client and even Java 
for my android. All have there rightful place, and are good at solving 
problems in there relevant domain.
> On my spare time I am making a program for keeping track of time spent
> on projects/tasks: TimeIT (https://launchpad.net/timeit). This program
> is made primarily to be easy to use and do things automatically.
>
> TimeIT is made with gtkmm and I found a few things I did not like.
>
> 1 gtkmm seems to be monolithic, you always get everything. (My program
>    needed 26Mb running, not only the fault of gtkmm of course)
>    
Is this real memory, or are large parts of the library memory mapped 
when it is running ? I really like to know what is taking up all that 
memory, it sound pretty substantial.
> 2 gtkmm is using sigc++
>    
Sorry, so do we ... no need to reinvent the wheel, and as C++ is not 
functional with closures and all, this is the way to do it.
> 3 gtkmm did not fell 100% reliable. (Destruction sometimes happened in
> wrong order when using gtkmm smart pointers).
>    
Ok, XFC tries to use GTK+ to handle references and does not enforce a 
new ref-count template thingy, and this makes it much more simple and 
GTK+ like.

We also tryes not to enforce a large amount of virtual event functions, 
in case you may need these one day :-)

But the price is that you need to know how to allocate and work with XFC 
(Gtk) objects, and you need to know what to do when making new widgets, 
as they need some more attention in order to gets events pumping.
> #3 Is something that you can live with. It is much better than Windows Forms anyway.
> #2 sigc++ is great and safe implementation the of observer pattern but it tends to draw the attention away from designing interfaces and the relation between the objects.
> #1 Memory usage: Here is something that might be done something about.
>    
That was my hope too, but XFC was designed to gain this, but I have 
newer made any measuring (sorry) :-)
> So, noticing that Xfc is still having some life maybe I should try it
> and see what end result it would be.
>    
That sound very exiting, please let me know if there is anything I can 
do to help. I am not working on any GTK related stuff at the moment, but 
that could change (f.ex. : I really like to be able to write Xfce panel 
applets in XFC).
> It would at least be nice to make some benchmarks comparing Xfc and
> gtkmm memory usage. It would be something nice for you to have on the
> homepage anyway.
I do agree, but my focus have been somewhat different ...
> Is there some other reasons to choose Xfc over gtkmm?
>    
The ambition was low overhead in both memory and execution, need we more :-)

If you like to work close at the GTK+ lib, but using C++, this is as 
close as it gets.
> I think you need a section on your homepage describing why choosing
> "your" framework instead of others.
>    
Well, sorry ... I'm am primary a developer, and marketing have newer 
been my strong side :)

/BL