During the last weeks, I decided to make the most of some spare time I had while still in “nowhere land” (see my previous post) and so I’ve been working in frogr to see if I could release the 0.8 version before the end of the year. In my mind it looked like kind of a nice and humble Christmas present to the world and, at the same time, a interesting way to spent this time I had between my depart from my previous job and the start of the new one.
And it turns out that, at the end, I didn’t manage to have as much spare time as I initially expected to have (I was pretty busy most of the time, actually), mainly due to many unrelated things I needed also to take care of, but in the end I still managed to steal some minutes here and there and I’m now proudly announcing that the new release is finally out.
But before going on, see the mandatory screenshot, as taken in my Fedora 18 machine:
As you can already spot in the screenshot, some changes are already quite visible, but some others are not, so let’s now comment on the most important ones, one by one…
Ported to GtkApplication and GMenu
It’s no secret that one of my favourite changes in this release is the integration with GNOME 3‘s “global menu” (aka the application menu), which makes frogr more beatifully integrated with the desktop than ever. However that came with a price: I needed to port frogr to GtkApplication first and then implement both the application menu and the menu bar using GMenu, which also made me raise the required version for GTK+ up to 3.4.
Sure I could have kept adding more ifdefs to the code to keep supporting previous GTK+ versions, but I also saw this as a good opportunity to clean up the code and get rid of so many conditional compilation units that were increasingly harder to maintain, and so I did it. As a plus, the OS X specific code has been reduced enormously as well, since GTK+ 3.4 integrates very well with OS X without having to do anything special, as I needed to do when I used GTK+ 2.24 for that port.
Loading and saving ‘projects’
This has been one of the features that several people have suggested in the past in different occasions, and so one of those I hope people will enjoy the most with this new release: the possibility to save the current session into a “project file”, so you can resume your work later.
How it works it’s actually pretty simple: when you save a session to a project, frogr will just serialize your current pictures, sets, groups and local tags to a json file (using json-glib) that you can use to restore the state later. It could be more sophisticated, but I think that it works reasonably well in the tests I did considering what it was designed for. In any case, please feel free to report bugs or feature requests to improve or fix things if needed.
Support for video uploads
Believe it or not, frogr has been almost ready to upload videos since some time ago, since for Flickr a video is just a “moving picture”, and it’s treated in exactly the same way than pictures when it comes to the upload API.
The only thing that was missing to remove that almost from here was to generate thumbnails for videos so they could get loaded into the UI. Not rocket science, sure, but something which needed doing and which was not a priority at all until now. And to be honest, it is not a priority yet anyway, but I felt like doing it this time once and for all, so from now on you can upload videos too.
Other features & bug fixes
Besides those three and perhaps more noticeable features, frogr 0.8 comes with several other new things, bug fixes, small changes and refinement that I hope will make this release more stable, useful and fun to use than ever.
Some examples of those other new things are, as taken from the NEWS file:
- Handle and report errors in a better way (no more mysterious failures).
- Perform after-upload operations (add to sets/groups, set license…) in parallel.
- Avoid fetching sets/groups/tags when still not connected yet to Flickr.
- Hide title bar when main window is maximized (see screenshot above).
- Renamed the ‘Actions’ menu to ‘Edit’ and brought the ‘File’ menu back.
- Allow sorting elements in the icon view by size.
Last, I’m also quite happy to tell that the OS X port of frogr has been finally migrated to GTK+ 3 in this release (at last!), and that the whole process of building it for that platform is now easier than ever, thanks to a specific Jhbuild moduleset I created for that purpose, following the lead of GEdit (thanks Nacho for the suggestion).
Check out the README file in the osx/ directory if you feel curious about the process or if you want to build it yourself. It shouldn’t take more than 2-3 commands in the terminal to get something like this running in your OS X machine:
Also, another advantage of having that moduleset created, is that now it’s trivial to properly document (by means of a shell script) the bundle file used to distribute frogr in OS X, instead of just providing an “opaque” pre-compiled bundle, as I used to do in an “unofficial way” with previous versions. Feel free to grab the bundle I’ve just created for this release from the GNOME FTP server.
So that’s it. I hope you enjoy using frogr 0.8 as much as I did writing it, and if you eventually find it useful too, then even better! As usual, check the website of the project for additional information or just to know how to install frogr on your system.
Sorry for the following. I am sure you’re hoping for more positive feedback
* * *
On having both a (meaningful, i.e. not just “Quit”) GMenu and an application menu… I think that’s the worst possible decisions one can make with Gnome software currently, because to me as a user it is completely intransparent why some menu items aren’t any more in the application menu.
I had this problem with Totem/Videos 3.6 where I wondered if it could still open files from in-app. Of course it could, only the menu entry had now wandered into the GMenu. Which I didn’t assume was there (coming from the GMenu-free Totem 3.4). This mess led to me finding my way around the new Totem roughly three days later. Which is a lot of time, given how I watched two seasons of Futurama in between…
If there is no application menu at all and the application starts in the windowless “card” mode by default, I am more prone to check application menu for its contents, though. Which doesn’t mean the usability obstacle goes away completely, though.
No need to apologize, I’m open both to positive and negative feedback. As long as it’s constructive and/or useful criticism I’m more than happy to see what people think out there about this release.
Actually, I can understand your concerns very well because something similar happened to me with some applications when I upgraded to Fedora 18 some weeks ago, even if most of those apps (e.g. Empathy, Nautilus) didn’t have any menu in the window, just in the Shell’s top panel.
However, I’m not sure whether this is just a matter of “get used to this new thing” or whether it’s plainly wrong to have both menus available in the same app. In my mind (and it seems according to GtkApplication docs too [1]) the application menu is something that contains options that make sense for the whole application, while the menu bar contains options (and submenus) that are meaningful for the specific windows they’re place in.
And in that sense I think frogr is doing the right thing (or at least I can say I’ve tried to do it so): things as “Preferences” or “Authorize” are in the -global- application menu, while other things such as “Edit details” or “Upload all” are in the menu bar in frogr’s main window. And this also seem to make sense when you run frogr in other desktop environments such as Unity or OS X, where the application menu and menu bar are rendered together in the same place.
In any case, the main intention here was to port frogr to GMenu and start using the application menu right now, but it was never discarded at all the idea of getting rid of the menu bar completely in a future release, providing it makes sense (perhaps adding a ‘Gear’ button -like in Epiphany- would make more sense). And your comment was to me a nice reminder in this regard so thank you for bringing it up.
Thanks for the feedback!
[1] http://developer.gnome.org/gtk3/3.4/GtkApplication.html
God, I hate GMenu. If you make an app with that then when that app runs in other DE (such as Xfce), the menubar will be borked (see https://bugzilla.gnome.org/show_bug.cgi?id=678919). The “genius” solution to this devised by the GTK guys? Make two different UIs: one with GMenu and one without it. So now you’ve increased fragmentation and make it harder for developers to make apps for Linux. Not to mention the “global” menu is a stupid idea. It only works for the simplest of applications and it’s not clear for the user which actions are on the “global” menu and which are on the menubar.
Well, I think it’s quite a subjective matter in the end. As for me, I like the global menu a lot, and it’s something I’ve been waiting for since some time ago already, thus I’m quite happy now we have it in GNOME 3, which is the environment I use 99% of the time.
As for the integration outside GNOME, well… frogr is primarily designed to be a GNOME application and that’s why so focused in working well in that platform, as its main priority. After all, that’s the platform where it’s mainly developed, tested and used (at least that I know of).
That doesn’t mean, however, that I oppose to it working and integrating better with other desktops (that would be cool, indeed), and I’m open to integrate any patch that might fix that in a reasonable way, but it’s important to notice that my main focus right now is the GNOME desktop, and that’s what’s currently driving the development of frogr at the moment (hence the decision to migrate to GMenu).
Thanks for the feedback, in any case. I’ll bear it in mind.
Pingback: GNOMEs Flickr Consumer Has Assistance for Uploading Videos | Detik Smart Free Download