Re: Remarks on gtk docs
On Mon, Mar 01, 2010 at 06:17:15AM +0100, Joost wrote: I've used TK with tcl 1995-1999 writing software to handle plain TeX on Linux. And nearly every Python programmer is using it in the Tkinter form, when making the first steps in Python I've yet to see a Python programmer using Tkinter. On my planet everyone uses Python for scripting (i.e. just on command line) and then, the small fraction of them that develop something with a GUI, uses Gtk+ or Qt. The long list of issues you continue with belongs to Bugzilla. Gtk+ development is not done on this list. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Gtk+ development is not done on this list. Oh no, you let out the secret. Now the s/n ratio will drop on lists that developers actually read. --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
On Mon, Mar 01, 2010 at 11:17:25AM +0200, Tor Lillqvist wrote: Gtk+ development is not done on this list. Oh no, you let out the secret. Now the s/n ratio will drop on lists that developers actually read. Well, maybe I should say that Gtk+ development is in fact done on alt.sex.spanking Usenet group. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
That is not only your planet. There are also that folks, who run youtube, there is Zope (where Mr. van Rossum worked), there are the (unknown for me) systems, for which the reporting tools of www.reportlabs.com are made for. Or slqalchemy - also only useful in large projects. My OKamba is consisting of more than 100 files Python and i have experienced the power of that language. The planet you describe as yours, must be Mars. Kind regards, Joost Behrends ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
On Mon, Mar 01, 2010 at 02:13:05PM +0100, Joost wrote: There are also that folks, who run youtube, there is Zope (where Mr. van Rossum worked), there are the (unknown for me) systems, for which the reporting tools of www.reportlabs.com are made for. Or slqalchemy - also only useful in large projects. My OKamba is consisting of more than 100 files Python and i have experienced the power of that language. And the funny part is that none of it backs your claim [cite] nearly every Python programmer is using it in the Tkinter form, when making the first steps in Python [/cite] Not even anecdotally. Actually, I was kidding, the funny part is the `my Python project has more files than your Python project' stuff. Seriously, you claimed that Python is used in a certain manner by almost all its users. After my remark that I don't see it to be used at all in this way no evidence that what I observe is in fact an eccentric behaviour followed. So, please provide it or cease speaking for `almost all Python programmers'. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
My planet is so much worse and more aggressive, that i see no legitimation for any cease to speak of ... from you. After all that tries to exclude my from mankind. And what has to be in the buglist, what on the developer list and so on, lies not in your hands. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Hi David, On Mon, 1 Mar 2010 10:04:27 +0100 you wrote: I've yet to see a Python programmer using Tkinter. Oooh! Ooooh! Sir! Sir! http://lintrain.sourceforge.net http://www.livewires.org.uk/python And I could name others. TkInter is not dead. However, that shouldn't detract from the important Gtk points that are being discussed. If there are any ;) :P ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Gentlemen, Please, enough. This type of debate is not the purpose of this list. Consider also your cultural biases and the misunderstanding of tone and intent that they may cause. Leon Opit On 2 March 2010 03:02, Robert Pearce r...@bdt-home.demon.co.uk wrote: Hi David, On Mon, 1 Mar 2010 10:04:27 +0100 you wrote: I've yet to see a Python programmer using Tkinter. Oooh! Ooooh! Sir! Sir! http://lintrain.sourceforge.net http://www.livewires.org.uk/python And I could name others. TkInter is not dead. However, that shouldn't detract from the important Gtk points that are being discussed. If there are any ;) :P ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
On Tue, Feb 23, 2010 at 9:05 PM, 1...@depikt.net wrote: Yes - there are maintainance problems with gtk+ - serious maintainance problems. let me attempt to rephrase for you: During the development of our application, we have found that our designs seem to require features in GTK that are either missing, poorly or incorrectly implemented. We could have chosen to inspect what the wide range of existing GTK applications (some of them very large and complex) do when trying to handling situations like the ones we believe we face. However, I've decided instead to write about GTK as if it has some sort of fundamental problems, especially in comparison to another toolkit whose documentation I have definitely glanced at, but I can't tell you whether I'ved used it or not. Reasonable summary? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Hm - not fully. I've used TK with tcl 1995-1999 writing software to handle plain TeX on Linux. And nearly every Python programmer is using it in the Tkinter form, when making the first steps in Python (which by its readability is well fit to large projects - far more than a better tcl or php). I turned away from it, because it has no tabular widget and from my kind of perfectionism - in my eyes it's unbearable, that TKinter is internally starting tcl. And i have some C++ experience with XView (long ago and not with exact remembrance enough to compare). No, when you have alleged to the Qt i've mentioned, that is not, what i meant. And gtk 2.18.6 currently has the following bug on my system: Leaving entries the pointer icon is remaining the text icon and the pointer only functional after any extra click. Besides the pointer gets sometimes invisible when over the application of the left entry. With focus handling at all one can have all sorts of catastrophies, especially dysfunctional focus chains. The key-release-event with tab definitely goes to the next widget. When one wants live editing of TreeView cells from an outer entry widget (a quite normal Excel function) connected to marked cells there is the problem, that sorting by that column stays active and every new letter causes sorting without the selection moving along. Thus you write into other cells after each letter. I found no way to turn off column sorting on enter-events (and turning on on leave-events) for that entry widget - gtk has the methods for that, but the code didn't work reliably. The letters inside the table's cells must be as small as possible, as long as they stay comfortably readable, because as many lines as possibly should be on the screen. They are too small for comfortable writing then (that means especially: For setting insertion points with the pointer comfortably). This has be overlooked by the programmers, who have provided the default way of cell editing - let alone support for editing some number of cells (to the same content) simultaneously. Misdesign. The missing feature, that sorting of a column cannot regularly made with a one-way-action without changing any state of the column is so bad, that i consider that as a bug. It would have been so easy to provide this. This is no proposal, as soon as i have some 40 hours to spare, i will write my own table for depikt (without any cell renderer, drawing on an unparted surface. Framing of cells for example is easy so). The Python model is finished meanwhile. Gtk is probably better as a widget builder than as a GUI-builder. The bugs around keyboard focus are bugs with basic behavior and demonstrating, that there is no core of reliable code established. ... as if it has some sort of fundamental problems ... - yes, i write so (but not with every single problem, let alone question), but not in any as-if-pose. The entry-leaving error is not in pygtk - currently i have switched back to gtk-2.16 with the same pygtk, there it doesn't appear. Besides: That is nicely easy from the ambulance of gtk - just renaming of directories (my Python apps set the PATH themselves). It is on Windows - and that should be the platform of main interest. Because Xlib abstraction with gdk is useless on Unix - there alone it were just idling. The XProtocoll also could provide interfacing with non-C-languages, would Xlib be under the hood of gtk, not gdk. This is about tables and focus chains, about bureau software. What your beautiful DAW is using, might be from better parts of gtk. No, really no as-if-pose, but i might have misunderstood you. Thanks for reading, Joost ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
This here (the middle paragraph) had been cut by a bug anywhere - it is in the version in my Sent folder. I send it a second time from Thunderbird - perhaps i must search for another email client than Thunderbird, Sylpheed or Pegasus) And i had found it somewhere on library.gnome.org - yes it is documented. But not at the prominent place, where it has to. This must be in one of the first paragraphs on .rc files everywhere. gtk authors will have had reasons for this ideosyncratic behavior of widget. From the first look it appears as nothing as another weakness - and that is, what i want to state as the second main point here: The documentation must be more honest to be well usable. These days i begin to make the User Manual for my commercial OKamba. I will cut off any try of pseudo-objectivity there and use a lot of is (hopefully not too penetrant) using it for advertisement with the same move. But i will speak of more than one weakness of OKamba there - and prevent useless searching of the users so. The gtk docs - without any need - do so nowhere :( That is a sure way to loose the battle against QT. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
That is a sure way to loose the battle against QT. People who like Qt (not QT) use that if they have a choice, people who like GTK+ use that if they have a choice. Where is the battle? --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
That is a sure way to loose the battle against QT. People who like Qt (not QT) use it if they have a choice, people who like GTK+ use it if they have a choice. Where is the battle? --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Hello Thor, after this mishap probably caused by Pegasus (or a misconfiguration by me - but so far i never heard from problems other addressees had) i'll use my ISP's webmailer for this mailbox for a while. Battle was an adoption from wikipedia's browser war - a bit superficial of course. But there is chitchat about an uprising economy of attention - in such an economy the concurrency of Gnome versus KDE is a bit more severe than any academic pastime. Of course we already have advertisement as the main income of google for instance - but many protagonists of the advertising business are having doubts about the effectiveness of advertisement at all. And the first task in establishing such an economy were to sanction advertising lies severely. And their grips below the belt. As spam is dealt with already today (and this is a feature of such an economy). I guess moreover, that the common open source programmer is convinced of his work's quality. At least i am for my little Python tool thrases. And that she wants to be read like any author of poetry - of course read means used here. By the way: Thanks for your work with the Windows update. I didn't have those great problems John Stowers reported. But a bad bug: When leaving an entry's window from a drag for selection, the cursor remains the text insertion cursor and doesn't work no more - only an arbitrary extra click reestablishes the normal functions of the pointer. A bug 2.16.6 didn't have. Yes - there are maintainance problems with gtk+ - serious maintainance problems. Providing connect() in depikt i studied the standard method of gtk+ of course - learning, that the use of closures and marshallers is only providing hooks in comparision with g_signal_connect() and GCallback. And signatures we currently do not need. Hooks - that means side-effects. Why not have the actions of these hooks in the using code around my_object.connect() ? And - if needed multiply - write a function around g_signal_connect() ? That is always better readable, 100%. I won't probably support that with depikt, only if the simpler GCallback will be dismissed also. As the well-done simplicity of the old Tooltips, which are deprecated now (which didn't show correct colours though, as GtkTreeView::base[NORMAL] didn't too). And apparently we only got bars as containers for widgets with tooltips instead (i might have missed something here - i will still use the deprecated methods). Thanks for reading, Joost ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Remarks on gtk docs
Hello, this will be a long text. Parts of it have been circulated in my brain since many months - i must do this. Please keep in mind, that i do not want to offend anyone, my username viciousdog on sourceforge is nothing else than a warning. python/gtk/sqlite has been chosen as the (virtualized) poor man's computer by OLPC. I learned that after i had chosen this platform myself. Continuing to read this, some of you might want to respond: Then write documentation yourself !! - but i cannot. Living in a country, where a labour politician has reintroduced forced labor recently i really have no time for that. I'd really like to write 10-20 pages about rc syntax, but what will come below must be enough for the moment. I will continue to write for this platform and make improvals of it for my own use. Working on my pygtk alternative depikt i learned that the promise of easy interfacing with other languages (than C) is not empty. Then there is gdk.Pixbuf and the integration of the well-designed pango and cairo. The latter must have been a bit painful for the authors of the gimp-tk - many thanks for that ! And thanks for the introduction to widget construction. But that is all, what is really good in gtk. Beginning my work on that software, which helped me to survive as an intermediary internet dealer and beginning to use gtk i searched border-width. From the promise of high-quality-surfaces i was sure to find all what tcl's TK - designated as poor by many programmers - has too. You know, what followed. I learned that border-width means margin-width with gtk, but that was of course no reason to continue searching. The inevitable result: Hours of senseless pain. I am probaly fairly dumb (i've met really better brains in my life playing bridge for example) - on the other hand i am someone capable of learning Python's infamous C-.API and to make depikt. Yes, you can make high-quality-surfaces with gtk. You can determine every pixel of your widget, if you want. But the way thereto is nearly not documented at all. And the standard equipment is leading to surfaces as gnumeric has - reminding me at GEM on the Atari ST. During 3 years the documentation of gtk and gtk itself has never ceased to cause this kind of pain. It is my fourth GUI-builder - and what is in the tutorial is 100% useless in such a situation. No word about the style sharing, no word about the needed full path to a widget's name in rc files, (probably) no word about property-notify events, no word about what Style properties in the references mean ... These thousands of pages have caused a lot of work on your side - with about 100 good pages they were as useful as they could and should be as the result of so much work Only last week i learned that the GtkEntry::cursor-color in GtkEntry::cursor-color = DarkGrey is necessary - or is it not ? Again in a session fighting rc syntax with pain. No chance at all to get to fluid writing with this beasty material. That comes absolutely unexpected, after all we will link the style, where it is in, to an entry (and we absolutely should, when we want to produce well maintainable software) thus it looks redundant on the first view. What i had to learn in November under pains also is, that you have to write the full path to the widget down in lines like: widget OKambaDialog.outer_bd.inner_bd style st_dialog_inset OKambaDialog is necessary here - again deviating from what contemporary programmers know from CSS's id versus class. And if someone is prepared to this difference to class, he would probably expect this whole path with class, not with widget. And i had found it somewhere on library.gnome.org - yes it is documented. But not at the prominent place, where it has to. This must be in one of the first paragraphs on .rc files everywhere. gtk authors will have had reasons for this ideosyncratic behavior of widget. From the first look it appears as nothing as another weakness - and that is, what i want to state as the second main point here: The documentation must be more honest to be well usable. These days i begin to make the User Manual for my commercial OKamba. I will cut off any try of pseudo-objectivity there and use a lot of is (hopefully not too penetrant) using it for advertisement with the same move. But i will speak of more than one weakness of OKamba there - and prevent useless searching of the users so. The gtk docs - without any need - do so nowhere :( That is a sure way to loose the battle against QT. Yes, still i will continue to work with gtk. Here is what i wrote on depikt.net: With much more time i'd very like to make a simplified python-connected gtk, dismissing the outdated painting methods of gdk (since some years obsoleted by cairo inside gdk), some outdated features in imitation of X11 (as ... pixmaps), the styles sharing, properties at all, and would let it work with python classes instead of glib. But that will probably stay one of my dream
Re: Remarks on gtk docs
This here (the middle paragraph had been cut by a bug anywhere - it is in the version in my Sent folder) And i had found it somewhere on library.gnome.org - yes it is documented. But not at the prominent place, where it has to. This must be in one of the first paragraphs on .rc files everywhere. gtk authors will have had reasons for this ideosyncratic behavior of widget. From the first look it appears as nothing as another weakness - and that is, what i want to state as the second main point here: The documentation must be more honest to be well usable. These days i begin to make the User Manual for my commercial OKamba. I will cut off any try of pseudo-objectivity there and use a lot of is (hopefully not too penetrant) using it for advertisement with the same move. But i will speak of more than one weakness of OKamba there - and prevent useless searching of the users so. The gtk docs - without any need - do so nowhere :( That is a sure way to loose the battle against QT. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Joost, and others, I tried learning to use gtk, gdk, cairo, pango, etc several years ago and was frustrated by the difficulty in getting good docs, sample code, etc. Even worse was finding that constant change meant me having to rewrite code fairly often. Note that I'm an old guy who has written code for a living since I was a young guy. But this has been the most difficult venue in which I've tried to work. I feel and share your pain in producing something of quality and lasting value. I know it can be done, but I pretty much work alone, and it's not easy. I switched to writing my own set of widgets in C++ which more or less look and act somewhat like Java's AWT, but nowhere near as powerful yet. I've got simple projects like a telnet client working, but I feel like I'm mining gold with a fork. My one big question to this list is (and no disrespect is meant), is there a elist similar to this one dedicated to Xlib programming? This list does have many very talented people, some of whom I'm in awe of. But I'm veering into a different direction and just need pointer towards that direction. adTHANKSvance, Ed James On Wed, Feb 17, 2010 at 7:06 AM, Joost 1...@depikt.net wrote: ... own use. Working on my pygtk alternative depikt i learned that the promise of easy interfacing with other languages (than C) is not empty. Then there is gdk.Pixbuf and the integration of the well-designed pango and cairo. The latter must have been a bit painful for the authors of the gimp-tk - many thanks for that ! And thanks for the introduction to widget construction. ...But the way thereto is nearly not documented... ... During 3 years the documentation of gtk and gtk itself has never ceased to cause this kind of pain. It is my fourth GUI-builder - and what is in the tutorial ... ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Ed James wrote: Joost, and others, I tried learning to use gtk, gdk, cairo, pango, etc several years ago and was frustrated by the difficulty in getting good docs, sample code, etc. Even worse was finding that constant change meant me having to rewrite code fairly often. Note that I'm an old guy who has written code for a living since I was a young guy. But this has been the most difficult venue in which I've tried to work. I feel and share your pain in producing something of quality and lasting value. I know it can be done, but I pretty much work alone, and it's not easy. I switched to writing my own set of widgets in C++ which more or less look and act somewhat like Java's AWT, but nowhere near as powerful yet. I've got simple projects like a telnet client working, but I feel like I'm mining gold with a fork. My one big question to this list is (and no disrespect is meant), is there a elist similar to this one dedicated to Xlib programming? This list does have many very talented people, some of whom I'm in awe of. But I'm veering into a different direction and just need pointer towards that direction. ... xorg would be as close as any: xorg mailing list x...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
