Re: [Vala] Blitzen: A Vala Application Server



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



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