On Sun, 14 Nov 2010 11:22:37 +0000 (UTC) Samuel CUELLA <samuel.cue...@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 b...@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 _______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
