Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!



Phil Shapiro says 20,000 Teachers Should Unite to Spread Chromebooks (Video)

cyocum Laptops are not necessary (101 comments)

Given the fact money is unevenly distrubuted through the school systems, thanks to local property taxes, some teachers must buy basic supplies for their own students. Laptops will not fix the funding problems. We need a more stable source of revenue than local bond and property taxes. Once these schools get something more akin to a real amount of money to spend on educating their charges can we then even contemplate giving them laptops or chromebooks or whatever. Let's deal with the underlying problems first rather than throwing solution du jour at them.

about 4 months ago

Why Engineering Freshmen Should Take Humanities Courses

cyocum Re:and the other way around (564 comments)

I would love to see physicists stop writing garbage like this which is completely ignorant of the literature it purports to analyse. There are so many problems with the basic data gathering here that I don't know where to even start. They seem to think that literature research and argument on the Táin stopped somewhere in the 1960's and they seem to think that using a known modern editorial admixture is the same as the original text.

about a year ago

EFF Announces New Patent Reform Project

cyocum Gobs of Money (93 comments)

The only way to fix the patent problem is to shove GOBS OF MONEY down the throats of ever hungry politicians and their banks.

more than 2 years ago

Demoscene: 64k Intros At Revision Demoparty

cyocum Word Salad (207 comments)

I can't seem to make heads or tails of this post. It's techno-babble and word salad. I guess I should remember this feeling when I talk about programming with my non-programming friends.

more than 2 years ago

Physicists Discover Evolutionary Laws of Language

cyocum Re:See this all the time (287 comments)

Classical Sanskrit was used for nearly two thousand years. I don't know many languages (except Latin) that has that kind of length of use.

more than 2 years ago

Physicists Discover Evolutionary Laws of Language

cyocum Re:See this all the time (287 comments)

If you wanted a more diverse but still very well understood set of languages, I would have gone for English, Sanskrit, and Arabic. English and Sanskrit are distantly related but far enough away that you can make good inferences out of them and Arabic because there is plenty of it out there and it is Semetic (like Modern Hewbrew without all of the loan words form Indo-European languages).

more than 2 years ago

Physicists Discover Evolutionary Laws of Language

cyocum See this all the time (287 comments)

I see this all the time (I have a PhD in the humanities and I am a software engineer) where someone from outside the field does something and claims it is a universal law but really, they just worked on English and cannot (or will not) prove that it works for other languages. Usually, these papers also lack any kind of literature review and ignore many of the problems that this would uncover. I saw one paper by a physicist that tried to use bit fields to model language change; it was just massively reductionist and couldn't explain anything at all for all the mathematical rigour.

I go to my University's language lunch which has lots of this and scare the pants off grad students by saying "this is all very well but does this work for Japanese or Old Irish or any other language?" This usually makes their faces go white because naturally English is the ONLY language that matters and is therefore "universal".

more than 2 years ago

Is Free Software Ready For E-publishing?

cyocum Pandoc (221 comments)

The solution to your problems is Pandoc which can convert LaTeX to EPUB if you like. Now, it will probably take some fiddling on your part with the output but it very much smooths the process.

more than 2 years ago

Ubuntu 11.04 (Natty Narwhal) Makes a First Appearance

cyocum Re:Ah man... (179 comments)

I think a better name would have been "Naughty Nobgoblin".

more than 3 years ago

Schooling, Homeschooling, and Now, "Unschooling"

cyocum Re:So it's a fnacy nmae (1345 comments)

A lot of Historians might well agree with you. But I disagree on this point.

Modern history is a science. Or at least, it is more a science than an art. Historians may have hypotheses, but they must search for sources, categoring [sic] them according to primary and secondary, etc, in order to provide "evidence" for their theories. History is backed up by archaeological evidence, and archaeologists are most definitely scientific in their methods. For falsifiability fetishists, any historical theory can be disproved with the right evidence. While that may be hard to find, everything in history is in principle falsifiable.

The heart of the argument about scientific history is: is a historian specifically unbiased in his/her interpretation of the primary evidence? Is the historian unknowingly biased by the culture in which they live? I would answer this in the affirmative and thus history is not a science. This is a fundamental tenant of Historiography. I am also puzzled by what you mean by "modern history". Do you mean history within the last fifty years or do you mean historical methods since von Ranke?

As technology has improved, it has found its way more and more into historical studies. Things like X-ray scans, etc, used to find erased documents in old parchments. Things like putting the index of soldiers in the hundred years war in a database.

Merely putting data in a database is not History. It may come from historical sources but until someone places an interpretation on the data, it is just data. Even applying mathematics to the data is an interpretation of some kind.

History is a science, or at least, it is scientific in its methods. It's a worthwhile inclusion into an education.

If and only if you ignore the fact that the interpreters of primary evidence have unknown and unstated biases to their interpretations.

The subjects I was speaking of; things like art studies, poetry, philosophy, music, civics, etc, may all be worthwhile subjects, but they don't constitute an education. They constitute a pastime.

I would like to see a history of the Roman Empire without resort to their poetry, philosophy, or art for argumentation or explication. What it seems you misunderstand are the drivers of history are often those very things you dismiss as "pastime". For instance, Christianity has been a massive driver of history so attempting to write about late antique and medieval history without understanding the philosophical and theological arguments of the time (however flawed by the act of interpretation of a historian) would be unedifying.

One last comment. The primary sources are not unbiased themselves. Even archaeological evidence is biased in some manner (ie a burial is often times a statement made by the living about the dead and themselves with some meaning even if we have no idea what the meaning might possibly be). Primary evidence, especially documentary evidence, is often third hand: eye witness sees an event (first hand), eye witness writes down an account of the event (second hand and its own interpretation of history as it is describing something in past time), historian writes about the event (third hand and an interpretation on an interpretation). Even if the historian has more than one account that does not mean the historian has any better understanding of that event than the people who were there. The historian is not a third impartial eye on an event (or set of events). The historian must imagine the event and thus is already at a major philosophical problem that must be addressed before one can continue (I would refer the reader to a recent volume of the journal of History and Theory on the "presence of history").

As long as humans are the actors (with all of their irrationality, culture, and "pastimes") and future humans are the interpreters (with all the same plus the differences in language (something I deliberately missed out because translation of historical sources from one language into another is another huge source of subjective interpretations) and culture), History cannot be a science.

more than 4 years ago

Schooling, Homeschooling, and Now, "Unschooling"

cyocum Re:So it's a fnacy nmae (1345 comments)

I just could not let this go. I have a question. How do you have a child "learn the history of their own country" without Historians? The last time I checked History was considered an Arts and Humanities subject. People who are by your own statement: "Arts and Humanities [are] students who know how to appreciate everything and know how to do absolutely nothing. People who can master the art of appearing intelligent whilst remaining shockingly ignorant. People whose ideas and tastes and practices are simply imitations of something that was actually original." You will have your hypothetical child taught by these people or is History somehow exempt in your scheme?

more than 4 years ago

How Can We Convert the US to the Metric System?

cyocum Re:Only Three? (1487 comments)

It is equivalent to 14 pounds (lbs.) see Stone(weight).

more than 7 years ago



Foundations of GTK+ Development

cyocum cyocum writes  |  more than 6 years ago

cyocum writes "When a developer begins the design process for a new open source GUI application, there are only two viable choices, Trolltech's Qt and GTK+. GUI applications are complicated to write and often complicated to understand. Into this space steps, Apress' "Foundations of GTK+ Development" by Andrew Krause, the developer of OpenLDev IDE built with GTK+ 2. From the first page, the reader is impressed with the scope and depth of the topics covered. Krause takes the reader from the first Hello World program to creating custom widgets in thirteen chapters. The layout of the page is clean and the code sections are clearly typeset with good variable names and structure making the intent of the code clear.

While the main purpose of the book is to provide a reference for the experienced GTK+ developer, the layout of the chapters emphasizes teaching the beginner the basic structures of a GTK+ program all the way to advanced topics such as developing custom widgets and the Glade GUI builder application. Many of the most important details, such as various enumerations, are placed appropriately in the appendices while those that are used are clearly detailed in the text.

As Krause focuses on the foundation of GTK+ development, all the examples are in C and the reader should be prepared with a good knowledge of C. While there are many different languages which have bindings for GTK+, which allow programmers to use their programming language of choice, the advantage of learning the C foundations of GTK+ is that the reader gets a clear understanding of how the library works "under the hood". The reader will appreciate how their chosen bindings interact with the base library.

Each chapter begins with a list of what a reader will learn and ends with a summary of the major points of the chapter followed by an exercise. These exercises are designed to be broad and leave much for the reader to do and learn with in the structure given by the exercise. If the reader becomes stuck the website has the appropriate sources to help the reader understand the structure being used within the program to achieve its ends.

Chapter 1 gives the history of the GTK+ project, X11, covers the installation of the details of the libraries involved in developing GTK+ applications. The exercise at the end of Chapter 1 has the reader verify the installation of the GTK+ libraries.

Chapter 2 is where the rubber hits the road as far as programming with GTK+ is concerned. The "Hello World" program gives the general structure of GTK+ development, which is maintained through out the following chapters. The widget hierarchy is discussed as well as how to cast objects properly ensuring correct pointer type to each particular function. All the signals and event handlers are discussed at a proper level of detail for a beginning chapter. If this were the only chapter, it would provide any programmer with enough detail to begin exploring the API and begin their own application.

Chapter 3 and 4 cover container widgets, which control layout and decorations, which allow different effects on widgets, and basic widgets (e.g. GtkToggleButton, GtkCheckButton, etc.). These are the basis for any good windowing toolkit and they are demonstrated ablely and with confidence by an author who is clearly comfortable with the toolkit and has no trouble articulating this to his reader.

Chapter 5 covers the different stock dialogs which come with GTK+, the About dialog, Information dialogs, and the FileChooser dialog, etc. While these are useful, building your own dialog boxes are left until later chapters but this chapter does give the reader a feel for how to use dialogs and where to place them in your program source for maximum readability.

Chapter 6 is an odd chapter as it covers GLib and is not related directly to GTK+ but it is necessary as some GTK+ functions return structures from this library. While it does give the reader a break from learning directly about GTK+, it seems oddly placed however as it needed to go somewhere and Chapter 6 is as good as any other chapter. This chapter is the longest chapter in the book and the author gives the reader a well deserved pat on the back at the end.

Chapter 7 and 8 are devoted to the most complicated but useful widgets, TextView and TreeView. The TextView widget allows many different operations for displaying text and the reader is introduced to many of the functions that would allow one to write a word processor. This chapter is helped heavily by the fact that the Krause is the developer of an application that uses this widget heavily. The use of the Pango library and the facilities for fonts are also covered in this chapter. In the next chapter, the reader is taken for a tour of the TreeView widget which mostly consists of creating different renderers for the different cells. The reader is given useful advice about which to use where and where to avoid using renderers which are called too often.

Chapter 9 describes how to build menus, toolbars, and popup menus both manually and with the XML based mark-up language which comes with GTK+. The reader is also introduced to the method for creating their own stock icons for the tool bars and menu items. This chapter basically completes the core development needs of an application programmer and if the book stopped here, it would be well worth purchasing. The reader should now be acquainted well enough with GTK+ to explore the API for needed functions and structures themselves. The XML demonstrated is a help as much of the code for this section is a tad boring and repetitive and the XML allows the reader to quickly create the required objects for the system.

Chapter 10 is another break from direct GTK+ development and the author has a few points about user interface design before showing the reader the Glade UI designer and libglade, which is necessary to use the interface builder. Much of a GTK+ application can be created from Glade but, as Krause rightly cautions the reader, there is still much development that needs to occur for the application to have the correct behavior. The XML created by Glade is similar to that used in the previous chapter but it covers much of what a developer would need in an application. While some may have wished that Glade was introduced earlier in the course of the book, Glade is an advanced topic and it is beneficial for the reader to understand how to create applications without Glade so that one could appreciate the design decisions when developing with GTK+.

Chapter 11 shows the reader how to create custom widgets within the toolkit from scratch which exposes in detail the inner workings of GTK+. Here Krause demonstrates using an IP input widget and a marquee widget. This chapter is quite long and involved and may take more than one read but it is well worth the exercise to understand more about the internals of the widgets that were introduced in earlier chapters.

Chapter 12 is a miscellaneous chapter with some interesting widgets that did not fit into the structure of the previous chapters including the helpful GtkPrintOperation. Chapter 13 gives you five applications built with the facilities of the previous chapters and the code for these can be obtained from the book's web site. The appendices follow and contain much information that is helpful when creating applications with GTK+.

For the beginner, this book is an invaluable resource for learning about GTK+. The content is substantive and concise while maintaining consistency throughout. The consistency, especially in the code sections, reinforces the information presented and code structure, which helps the beginner keep good coding style when writing for GTK+. The book remains tightly focused on presenting this sometimes daunting amount of information, which is one of the other great qualities of the book. For the expert, the table of contents, the appendices, and the index are the most important aspects of the book. These parts of the book are amply treated so that it is easy to use the book as a quick memory refresh. Overall, this book is a solid and dependable guide to a large windowing toolkit and should sit comfortably on any GUI application developer's desk."

Link to Original Source

cyocum cyocum writes  |  more than 7 years ago

cyocum writes "CNN [] is reporting through the AP [] that a Community College Computer Science lab instructor is accused of a pay-for-grades business. While this is a Community College and not a large University, how much incentive is there when after graduation, not many employers ask for you GPA and the constant fear of your job being outsourced once you have paid for the grade?"


cyocum has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>