I’ve been trying for a couple of days to figure out why a shaped window in Compiz doesn’t have a shadow. After looking through the Emerald and GTK+ decorators’ code, it seems that they only apply a shadow if the window has a titlebar decoration. This seems quite silly and limiting. Does anybody know of a way around this, or why we’re limited in such a way? Is this something that could be fixed?
Love,
Christian
I used to use the same trick Rodney Dawes describes in Subverting Subversion. Yes, it was very annoying to have to set everything from a file every time, or from stdin.
Ah, but there’s a better way, and people new to SVN seem to somehow miss this valuable command.
$ svn propedit svn:ignore
Up comes your editor, just as if you opened .cvsignore. You can now safely nuke your .cvsignore files. This is a useful command, so write it down until it’s burned into your brain.
Another year come and gone. Hopefully everybody is out having a good time or recovering from a good time. I just finished up for the night and am planning to get some reading done before bed, but thought a quick blog post summarizing the year was in order.
I’m sure I’m missing a few things. 🙂
Now, New Years Eve doubles as my mom’s birthday, which I imagine was not fun when growing up. I think the only day worse for a birthday is Christmas. It was certainly fun tonight, though. The night was spent with my mom, stepdad, brothers, sister, and Jamie. We watched Cars and played Scrabble, Bomberman Touch! for the DS (fun game!), and Cranium. We ended up spending most of the evening on Cranium, which has to be my favorite family game. We kept laughing so hard that we got ourselves sick.
Jamie brought over a bottle of champagne for us to drink. It was a late Christmas present, intended for New Years. We’re not heavy drinkers, so we only finished half the bottle, but it was very nummy. Along with that, we had a variety of snacks, including cheeses, beef sausages, vegetables, sodas, and pizza. This was, I think, my first New Years with my sister Jenna, as she had always been visiting cousins on New Years. She was pretty good most of the night, considering she had to stay up until midnight 🙂
January 1, 2007. With any luck, this year will be more exciting and eventful than last year. There are changes I hope to make, projects to abandon, projects to take up, and places to go. I think I’ll get some sleep so that I can get a head start on that.
Happy New Year!
I’ve been planning on adding tab drag-and-drop functionality to VMware Workstation 6.0. Rather than implementing this ability from scratch (which I did with Gaim, and would rather not do again), I took the sane approach and started investigating the GTK+ 2.10 API for GtkNotebook tab drag-and-drop.
This is functionality that many applications have had to implement themselves, so it’s great that support had finally gone into GTK+ 2.10. So I must wonder, with all the various applications that would benefit from this new API, how did we get it so wrong?
Now, before I continue, let me say that I applaud the effort in getting this into GTK+ in the first place. Reordering tabs looks smooth, it’s only one API call, and the basics are trivial. Where this all falls down is when you try to do anything complicated with it, and by complicated I mean anything beyond a simple text editor.
Before starting, I investigated how many projects were using this API. A quick Google Code search shows that almost nobody does, aside from maybe the tab reordering API. I did find this list of complaints, which I remember reading before. I won’t repeat everything on this list, but I will list what I’ve ran into, and how I think we can improve this API.
Global functions are very bad. (Bug 386935)
In order to allow for a tab to be dragged out and form a new window, the application must call gtk_notebook_set_window_creation_hook and pass a callback function. When a tab marked as detachable is dragged to the root window, this function will be called. It is expected that the function create a new window, position it as per the x and y coordinates of the drop (if it so desires), show it, and return the resulting notebook. GTK+ will then add the tab to that notebook.
While useful, this suffers from a major design flaw. You can’t set a window creation hook per-notebook. You get exactly one window creation hook function, which must be responsible for any and all notebooks in the program. The hook function can only distinguish between them using the notebook’s group ID.
For smaller programs, this isn’t a huge limitation. Simple text editors and the like only need one function. However, imagine if your application has multiple notebooks that each need to be dragged, and imagine if the code for those notebooks are in two separate parts of the tree. Maybe you have a nice separation of the different parts of the project. Regardless, now you have to have one common function that knows about both and handles their window creations.
The problem gets far worse for applications separated into different libraries, or those using widget utility libraries. Two separate libraries both providing a notebook with drag-and-drop with their own window creation won’t be able to set up a hook. They would require that the main application handle determining the group IDs of the notebook widgets they care about and then calling the proper functions in the libraries. While doable, it’s a horrible burden on the application, and it doesn’t always work.
Of course, the whole thing completely breaks down when you’re writing a plugin with a notebook rather than an application. The plugin won’t be able to offer its own window creation, due to possible conflicts with the main application and other plugins.
The solution, of course, is to have per-notebook window creation hooks. GTK+ could attempt to call one of these and then fall back to the global hook, if it exists. If calling the global hook, GTK+ could spit out a warning informing the user that the program should be upgraded to the new API and that the existing method is deprecated.
Rather than functions, though, a signal handler may make more sense. It could use a collector and call the handlers until it finds one that returns a GtkNotebook. I could see this being useful if a widget component library (as part of a larger project) provides a default window creation handler that the calling application wants to override for a specific case.
Numeric group IDs lead to namespace collisions. (Bug 386930)
Right now, in order to indicate which notebooks are compatible for drag-and-drop operations, each GtkNotebook gets a group ID. This is an unsigned integer with absolutely no rules on how an ID should be picked. This is very dangerous, as it could cause namespace collisions in larger applications, resulting in tabs being droppable onto incompatible notebooks. This could easily crash such applications.
There’s no reason for us to be using integers. Take a look at GtkRadioButton. They also have groups, but they work a bit differently. The first GtkRadioButton defines the group, and the rest get passed that as the group identifier. In gtkmm, you actually have a Gtk::RadioButtonGroup object that you simply instantiate and then pass to each radio button.
Now, in any well-designed program, there should be only one place creating the notebook for a certain type of window, and usually that’s the only type of notebook capable of accepting tabs from the same class of notebook. So, why not do something like what gtkmm does and have some sort of static object that represents that group, define it once, and pass it to each notebook? This is guaranteed to be unique, and solves the namespace collision issue.
Signals need to be more clear. (Bug 386943)
You can determine if a page was added to a notebook or removed from it, but there’s no clear way of determining if it was due to an API call, or a drag-and-drop operation. We worked around it in VMware Workstation, but it would have been very helpful to know precisely that a page was added due to drag-and-drop. Same with the removed signal. I know they wanted to condense the signals and figured it would work in all cases, but it doesn’t, so please, give us some more specific signals!
Drop operations should be able to be programatically rejected. (Bug 386950)
There are times when you want to allow a tab to be draggable, but want to reject it in notebooks under certain circumstances. For example, in VMware Workstation, we have the “Home” tab. I would like to be able to drag this to empty windows, but if that window has a “Home” tab already, I want to reject the drag. To my knowledge, there is no way to do this currently.
Detaching tabs into new windows requires a drag to the desktop. (Bug 360225)
In most any program with tab drag-and-drop, you can drag a tab off into any area not in the tab bar and it will detach into a new window. With the GTK+ tab dragging, you have to actually drag it to the root desktop. Even dragging off into another window isn’t good enough. This sucks. Let’s fix this properly. We’re not doing anybody any favors.
I’m missing a few annoyances I ran into, but I’ll be blogging about them separately once I remember.
So, to recap, I believe we should:
It would be great to see these things fixed so that more applications can actually use this API without major headaches. Anyone up for the task?
I plan to put up a new post soon giving a couple of tips for using the current API.
Update: Bugs have been filed for the above. They’re in the topic headers.
Hard Day in GNOME
All day long, people have been talking on IRC about the Novell lay-offs. It’s been sad to see, and as hard as it was for the people who were let go, I’m sure it was just as hard for those that had to let people go. My condolences to everyone who’s been affected by this.
I’ve talked to a few people individually about this, but it’s been recommended to me by a couple of people that perhaps using Planet GNOME would be the best way to reach everyone interested…
I’d like to offer to anyone affected by this who is looking for a job to send me your resume if you’re interested in a job at VMware. I can make sure it goes to a human being who will actually read it, rather than in some queue somewhere. We’re looking for good people, and the company is nice to work at. Although the Palo Alto offices are where all the interesting things happen for the Linux desktop development, some jobs are available at our new Cambridge office. So if you’re looking for a fun job where you can do interesting work with good people, and this interests you, even a little, we can try to get the ball rolling. To everyone else, best of luck. I don’t doubt that you will all find good jobs soon, and everyone appreciates what has been done so far by everyone in the Ximian team.
Nokia 770
My Nokia 770 came today. I haven’t had much time to play with it, but it’s quite nice so far. Cute little device, and I’m eager to hack on it. I have a couple of games I’ve written or PDAs that I hope to port. Taco would be fun to port to it, if it had cairo (which I don’t believe it does? Correct me if I’m wrong!).
Galago
A lot of work has been done in Galago SVN the past couple of weeks. A lot of the code has been cleaned up and the API is in the process of being fine-tuned. Python bindings are being written. libgalago is moving to glib. All neat stuff. I’ll post more when I get closer to being finished, but this is very cool:
for service in galago.core_get_services():
print service.get_name()
for account in service.get_accounts():
print account.get_username()
Just so easy. That’s not the final API, though. The core_get_services() part will change. Anyhow, fun stuff.
For the past few years, I’ve been using the Microsoft Office Keyboard. It was a gift from my mom, as my previous keyboard stopped working one day. Now, I’m sure a lot of people’s first thought is that this keyboard sucks because it’s from Microsoft, but so far, I’ve really enjoyed it. I have the Application Left/Right buttons mapped to switch desktops quickly and easily, and the Cut, Copy, and Paste buttons for making a window sticky, shading it, and launching a terminal. Works well enough.
Until just the other day, I had this all configured through .xmodmap and my window manager settings. However, in GNOME 2.5.x, the keyboard settings are apparently supposed to be controlled by the Keyboard control center applet, and my xmodmap settings are now ignored. My latest build of gnome-control-center CVS even shows a dialog saying that the xmodmap settings will be ignored.
So, I launched the keyboard control center applet and selected my MS Office Keyboard from the list. Perfect, I thought. That is, until I learned that my End key no longer worked, and none of the shortcut keys on the keyboard did what they were supposed to. I put it away for awhile and started manually using xmodmap and resetting the shortcuts every time I launched GNOME, until I had time to actually fix it.
The other day, I decided to fix this. The problem was actually in XFree86’s inet keyboard symbols file, in the Microsoft Office Keyboard definition. After poking around and learning how these files were constructed and what the <I#> and <E#> codes meant, I finally patched up my definition. It was an almost 100% change, so I’m assuming that either the guy who wrote this entry was on crack, or that it was for an older version of this keyboard (unless it’s a newer one, but I kind of doubt that).
I’m mostly writing this so that if any Linux users with this keyboard want it set up properly, they’ll have the information available. I have a replacement inet file available that works with my keyboard. I’d be curious to know if there are MS Office Keyboard users out there that have their xkb settings set to use this keyboard who aren’t experiencing problems.