Re: [Vala] Blitzen: A Vala Application Server

[pancake <pancake youterm com>]

On Sun, 14 Nov 2010 11:22:37 +0000 (UTC)
Samuel CUELLA <samuel cuella supinfo com> wrote:

> Hi,
>
> > Where's the source repository? I can't find any svn/git/..
> For the moment, the repository is not accessible from the internet. I'll import
> it into the sourceforge subversion service when I have time. That means I'll do
> it, but I can't tell you when. If you want to work on the source code or apply
> patches, please do it against the latest release tarball. Just send your patches
> at bugs blitzen org, or use sf tracker, as written on the 'Contributing' page of
> the website.

Why non use git or hg? svn and sourceforge are imho worst solutions for developers.
I stopped using sourceforge for security reasons (their servers are not really
secure places) and because of their license agreement and service shutdown times.

If you use svn/cvs or any other traditional control version system you end up
depending on a network link in order to work with it which results in slower
work (diffing code, checking out code, ..). and it's less optimal when you work with
more people.

I understand that this is just a personal opinion, feel free to use what you like :)

> > I tried to write a simple webapp but I faced the following issues:
> >
> >  * There's no sne-server.h installed , so i had to copy them manually with 
> Fixed
> >  * There's no pkgconfig file that setups gcc flags correctly. I had to split
> >    the build in two steps (valac+gcc)
> Fixed
> Thank you for reporting bugs ! These two of them have been fixed in the latest
> release (blitzen-0.0.8-r1) available on sourceforge. You just made me realize
> that I had a manually created 'stk.pc' on my system that was not part of the
> dist and not part of the project at all. Don't hesitate to point out any of
> these 'features'.
> >  * The webapp is loaded correctly, but segfaults when running. You may find
> >    the sourcecode here:
> >       http://lolcathost.org/b/stk.tar.gz
> As written in my first answer, this is "working on my system"(tm). I don't know
> how this got wrong, but I suspect the deployment process. Try to use the
> Makefile linked in my previous post, and look at the documentation deployment
> hints at http://blitzen.sourceforge.net/manual/ch03s03.html.
> If it still don't work, please let me know. I really want to fix it if necessary.

Uhm, i have updated to 0.8-r1 and used the makefile of the manual and now it
seems to work fine. thanks :)

> > It would be nice to have some help or flags handled by blitzen binary, to
> > specify different configuration file, show version or so.
> We(I in fact) are accepting patches ;)

Until I can fetch the development repository I prefer to report bugs instead of
sending patches because i devel src is usually not the same in the last release.

> > Vlad and me are planing to add support for Stk in GtkON
> Somebody just dragged my attention to your project some days ago. I'm really
> missing your point there. What's the purpose of GtkON ? I mean, it's generating
> Vala code out of an XML file with mixed UI definition and code. Don't take it
> personal, but I think it's a very, very bad idea, at least for real
> applications. It might be OK for rapid prototyping. But in my opinion, that's
> not the big problem. The big problem is why using this ? libglade have been
> around for years, GtkBuilder is now integrated directly in gtk and glade is able
> to generate XML for it. Why using something like GtkON when you can use glade to
> design your interface and something /built into/ Gtk to load it ? GtkBuilder is
> available for any language that has a gtk binding, including Vala, but not
> restricted to it. For me, that's making GtkON pretty useless.

The purpose of GtkON is to provide a simpler syntax for the XML parsed by GtkAML.

It generates vala code from a simpler syntax which results in a container-oriented
programming language which is much cleaner for UI development.

The reason I prefer gtkaml before gtkbuilder is because most of the UIs are just
static, and it is not necessary to perform this task every time you execute the
program, maybe the cost is not noticable in your machine, but my phone and laptop
does.

I understand that from the design point of having everything separated in a MVC
way makes the development much more clean, but gtkaml does not forces you to
mix this, it's just a way to have static UIs definitions in separated files, then
you can put the logic somewhere else.

Something that really anoyis me when using glade or xml definition for container
constructions is the fact that even the properties and signals links are defined
in separated places which makes me read up to 3 files at a time in order to
understand what does what with what and where (yeah :P).

And certainly.. using glade (or any other graphical application) to design interfaces
have been pretty frustrating for me, for various reasons:

  - huge XML file generation (not human friendly)
  - you can't script or easily to GUI refactorings easily
  - gtk is a container oriented widget kit which makes the UI design a bit complex
    because you have to understand the logic of the boxes, alignments, borders, etc..
    this makes the development pretty frustrating and slow, at least for me it's
    easier to write it down what i have in mind in a simpler text syntax, and it
    is much easier to see which variables are used, which widgets, etc.
  - many people end up placing many useless widgets in the UI to make the application
    look as they want (separators, spacers, etc..) which is not really gnome-friendly.
  - adding user-defined widgets in glade is hard (to not say impossible)

If you understand well how glade and gtk works you can do pretty good stuff, but still
have all those points for new users.

> The only feature that it have over GtkBuilder is to generate 'native' code. And
> of course more concise XML. I perfectly agree that GtkBuilder XML notation can
> be reduced. For this, just talking with the Gtk guys or writing your own XML
> parser would have been better. Parsing XML and creating GObject on the flow is
> really easy. Even setting properties is straightforward.

Yep, parsing xml is such a simple task, there'r lot of libraries to do it and the coder
can focus in code generation which is good.

Maybe im such a freak guy, but I don't see why do all this stuff at runtime when it
only changes at compilation time. For some situations it is useful, but for 90% it is not.

It's at the end a personal opinion, but i prefer smaller, less mem consuming and faster apps
than having to load more libraries in memory, parse stuff and execute code which could be
defined just once.

> If you don't want to have XML files around when distributing your application,
> you can perfectly embed the interface data into a string and have this string
> parsed by GtkBuilder. There is a function for that. If you really want to
> generate static code, it's very easy to take a GtkBuilder file and to generate
> the corresponding code. You could also do the same with your own XML parse: It's
> just a matter of outputting call code instead of executing it.

The only reason to use xml UI definition i can imagine is when you need something
really dynamic, like a remote UI application using DBus and Glade, (like an http
browser using gtk) or something similar, but usually when you change the UI you
need to touch something in the code, so having the XML files out of the program
doesnt helps too much.

A designer is not going to edit an XML file, so it's always the task of the developer
to change it. And i think that it is better to keep a single user interface that fits
all uses than allowing the users to change the UI for each app. OSX and windows do
something similar, but in those cases it is more logic because their code is closed.

Another point is that you add more complexity in the program, so finding bugs in
UI is harder than in simpler apps using gtkon.

> Really, I don't see the point of that project. However, please don't take it
> personal or whatever. I know you've invested time on it and I we all know it
> feels when people don't like your work. This is only my opinion. If the project
> is useful for you and fit your needs, it's fine for everyone.

np :) i like to receive feedback from what I do, it's also a way to learn.

Yep, I use gtkon in some projects of mine and i'm pretty impressed of the results.
I have reduced and simplified the code a lot, now i can develop faster, and 
reading the code is much more easy than before. I have used many widget kits (qt,
swing, mfc, wx, ..) and IMHO gtkon is the most productive and performance-friendly
development language for UI descriptions.


> > , so you can drop StkBuilder,
> > XML files and reduce even more lines of code in the applications.
> I'm not going to drop StkBuilder in favor of GtkOn. Not because I don't like it,
> which is true, but only because that's not what I'm trying to implement there.
> StkBuilder is not intended to generate code. Ever. StkBuilder allows people to
> separate UI definition from 'business' code. It also allow to modify UI without
> recompiling. Moreover, Blitzen applications are long-lasting. StkBuilder doesn't
> read the XML file and create views on-the-fly each time a view is created. It
> only loads the definition once and keeps it in an intermediate representation
> that is then use by the instantiation engine to build up the view. I've benched
> statical code vs StkBuilder and the "overhead" is not noticeable. In fact,
> StkBuilder is faster than manual view setup. Of course, this does not include
> the first file reading, but only creating a view from the intermediate
> representation stored:
> I've got "Elapsed time : 0.000369" for build up using StkBuilder that create
> instances using g_object_new and set properties using g_object_set_properties,
> and "Elapsed time : 0.000461" for the direct view setup using the Stk API
> functions, like stk_text_entry_new() and alike.
> Therefore, there is no speed gains there.


But this is just a personal opinion based on my experiences and use cases. I don't
want you to change or remove stkbuilder, i understand that they can be useful for
many people and situations.
 
> If you want to look at the code I've used, I can put it somewhere for your
> scrutiny. Just ask.

np

> However, If you still want to adapt GtkON to Stk and you think that might be
> useful for you or other people, please do so. I've nothing personal against it,
> and I'll try to notify you on API evolution/breaks.

Yep, vlad and me will work on this along this week, we will push some blitzen
examples written in gtkon.

Thanks

--pancake