Hi, Le 14/11/2010 15:30, pancake a écrit : > 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. >
Free Software Needs Free Tools: http://mako.cc/writing/hill-free_tools.html gitorious and launchpad are my two prefered tools. > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
