… but we are still far from finish. I am talking about Echo Icon Theme. Its history is long and full of twist and contributors. It started as a personal project by former RedHat employee Diana Fong and it was targeted as a replacement for the aging bluecurve icon theme. The original draft looked like this:
The icon set quickly gained popularity among Fedora user base, but contributors were few, development slow and we missed the important part of making it default in Fedora (because it was not complete enough). This question of completeness has been haunting us ever since.
It's nostalgic to see what were my first contributions – I had practically no experience in graphics, but wanted to see the set improved. Here you can see my very first sketch:
As you can see, it is not-so-ugly icon with well distinguished shape, but with totally different style, as were pointed out by the Art members at that time (Luya and Nicu will maybe remember ;-)). I've finally ended with this:
I'd say, not bad for a first try, but this icon is no longer in Echo... I've replaced it much later with desing more consistent with our new apporach to echo.
The slight shift in design is nicely seen e.g. on these icons:
And now we're even starting something even more different – Echo Perspective. Here are some expamples of the initial progress:
Well, you might ask why starting anew when there are already great themes like tango or oxygen, what will happen to the original Echo and much more, why don't we rather join tango, … We cannot give you straight answers. It happend so that we like Echo and would like to see it being default in Fedora sometime in the future, but we also need to keep up with others – and that means perspective projection. We believe that neither Echo nor Echo Perspective is a lost case and that there are reason strong enough for us to continue working on these, but you might disagree. Well, at least, with the perspective theme, we can share a lot with tango or oxygen. Even though we have different style, the shapes can now be very similar and it should not be hard in the future to easily adapt echo-perspective icons to tango or oxygen guidelines.
And how far have I gone? In short very far. In longer – from an ocassional contributor to main contributor and practicaly the Echo Icon Theme project leader... Also as you can see from the images above, my inkscape skills have improved a lot ;-)
As you can see, on my very example, it's not actually hard to join Echo. Yep, the standars were risen a bit, but so was the infrastructure and we can call our project mature now. And we will be happy to welcome new contributors. Don't be shy and share your work/ideas with us. We will in turn help you to became a full-fledged Echo Icon Theme contributor :-) Fedora-art-list is the right place to start.
Sunday, 22 February 2009
Monday, 16 February 2009
Comments Moderation
Due to the vast amount of spam I've been recieving recently in comments to my blog posts, I've decided to enable comment moderation. This means all new comments will be reviewed by me before they are showed in the comments. Sorry for the inconvenience. I promise I'll filter only spam :)
Friday, 13 February 2009
Latest Nodoka screenshots
Ok, I wanted to test whether file uploads work with WebKit/GTK now, so I decided to use it as an opportunity to show you how nodoka currently looks on my system ;-) I think I'll have to tune the glossy scales a bit more plus maybe draw the progressbar smaller if there is no padding... Come to think of it, I think I might add an engine option for setting the scale through/fill width instead of having it hardcoded for each style. What do you think?
Thursday, 12 February 2009
Libsoup now default in WebKit/GTK
Just a short notice that libsoup backend was set to be default backend for GTK port of webkit today. I am thrilled by this partly because the libsoup backend seems to behave much more better than the cURL one, and also it seems that most new features that are somehow connected with HTTP backend are being added only for the libsoup backend.
You can read some end-user comparison of the two backends in one of my previous posts.
One another great thing is the speed with which the GTK port is advancing now. Acording to one of the webkit and epiphany developers, Gustavo Noronha, WebKit/GTK might be the default backend for Epiphany in Gnome 2.28. That's Fedora 12! Whoa! I am already restless :-) More specifically he's asking us, the end users, to
You can read some end-user comparison of the two backends in one of my previous posts.
One another great thing is the speed with which the GTK port is advancing now. Acording to one of the webkit and epiphany developers, Gustavo Noronha, WebKit/GTK might be the default backend for Epiphany in Gnome 2.28. That's Fedora 12! Whoa! I am already restless :-) More specifically he's asking us, the end users, to
"come help us (the epiphany devs) test and get a regressionless Epiphany with WebKit/GTK+ for GNOME 2.28"Well, this might be worth a feature page for F12 ;-) And even though I am using Midori to test WebKit (I use epiphany as my primary web browser and it's rather inconvenient to keep two versions of epiphany installed; and I actually find Midori very interesting and light-weight) I think I will resume testing WebKit in Epiphany as soon as Fedora 12 development starts.
Saturday, 7 February 2009
My Idea of Future Gnome Desktop
Since I read a blogpost about GTK+ 3.0 Theming API Hackfest I've been thinking about how would like the Gnome 3 desktop to be... First I've had some more general ideas like: support real transparency everywhere, desktop should serve as a place for wallpaper and widgets, not as a storage room occupied by nautilus, gnome-panel should look slicker and be more interactive, ... But yesterday I've tried cairo-dock (which I haven't figured at all how to set it to not crash and work how I would like it) and that rather short experience gave me more clear idea what I'd like it to be.
First let's see what my desktop looks like now
There are two panels and an improvised storage room on the nautilus managed part more concretely:
I find this layout particuraly useful since most things I am doing repeatedly are available on single click and the rest is two clicks ;-) Also thanks to the timetable on the desktop, figuring out which classes I have today is a matter of few seconds. And finally thanks to the network and cpu monitors I see how much I download/upload and how cpu behaves.
On the flip side this layout takes up a lot of space, the window list gets quickly filled, some of it feels rather duplicated with tray area (you know the 'minimize to tray' funcionality of nowadays's apps). Also the desktop itself feels cluttered and I cannot make the timetable bigger - the current size is as far as nautilus is able to scale.
And here's my (well let's say I rather put together various ideas from various people) solution trying to improve the usability as well as slickness (please note that the folowing image was made in inkscape, so it's not a real screenshot)
Now what has changed... Nautilus is no longer managing the desktop which in turn now serves as place for various widgets. I've put there the timetable in it's desired size (image widget - place an image you'd like on the desktop with desired size) and two monitor wigets - one for CPU and another for network. I can also imagine puting there a weather forecast, calendar, big analog clock, ...
Next thing that changed is that panel is no more. Instead there are two more widgets on the desktop - desktop switcher and dock area. There's not much to describe about the workspace switcher, just that it looks nicer and is not in any panel. More describing is due for the dock. Basically it's a reminiscent of the panel, but it's transparent, 3D-like and I've removed all differences between applets, application launchers, notification/tray area and window list.
The combination of launchers serving also for window list isn't a new idea, I've already seen it implemented in the cairo-dock, though due to frequent crashes I had not much fun with it. But as I said, I'd go even one step farther and merge also the tray icons. The idea behind is that there actually is no difference between those so why should we make one. It also saves a lot of space.
And now how it would work? Let's say I want to launch an audio player. I click on the audio player icon and it starts. The icon buttonises (shown with epiphany launcher) and starts to behave like it now behaves in task list and/or notify area. Right-click will hide (or focus if it is not focused) the window in the icon another right-click will bring it back, left-click will show a menu with the usual commands like play, previous, next, etc.
Now for pure notify icons it would behave slightly different, e.g. right-click on the signal icon (network-manager) will open a menu where you can select networks you'd like to connect to, left-click will open a menu with additional settings, just like it behaves now.
For the applications without their tray icon the launcher starts serving as a button in window list - right-click for minimize/focus, left-click for window menu.
When you'd want to open new window instead of focusing the current one, just hold shift and click the icon, or select new window from the menu that apears when you hoover over it. Windows of the same app would be grouped together and you'd select which one you'd like to choose by selecting one from the menu that appears when you hoover over the icon.
Next thing you can notice on the dock is menu and places. This would be similar to the Applications menu and Places menu, optionally the System menu as well, with the tiny difference that it would open on hoovering instead of mouse click.
This setup would mean that you'd have almost any action available for use on single click.
Final word to say about this is configurability, I think the dock should have an easy way how to manage the applets that are on it, prefereably similar to how you do it now with gnome-panel. The cairo-dock configuration window is a total no-no for me - in the basic view I wasn't able to set-up anything I wanted and in the Advanced view there was so much options that I got lost very quick.
First let's see what my desktop looks like now
There are two panels and an improvised storage room on the nautilus managed part more concretely:
- Menus
- Window list
- NetSpeed Applet
- CPU monitor
- Keyboard switcher
- Clock
- Desktop Switcher
- Application launchers
- Various session related applets - lock screen, log out, shut down
- Volume
- Trash
- Notification area
- Timetable
- Some documents, etc. on desktop
I find this layout particuraly useful since most things I am doing repeatedly are available on single click and the rest is two clicks ;-) Also thanks to the timetable on the desktop, figuring out which classes I have today is a matter of few seconds. And finally thanks to the network and cpu monitors I see how much I download/upload and how cpu behaves.
On the flip side this layout takes up a lot of space, the window list gets quickly filled, some of it feels rather duplicated with tray area (you know the 'minimize to tray' funcionality of nowadays's apps). Also the desktop itself feels cluttered and I cannot make the timetable bigger - the current size is as far as nautilus is able to scale.
And here's my (well let's say I rather put together various ideas from various people) solution trying to improve the usability as well as slickness (please note that the folowing image was made in inkscape, so it's not a real screenshot)
Now what has changed... Nautilus is no longer managing the desktop which in turn now serves as place for various widgets. I've put there the timetable in it's desired size (image widget - place an image you'd like on the desktop with desired size) and two monitor wigets - one for CPU and another for network. I can also imagine puting there a weather forecast, calendar, big analog clock, ...
Next thing that changed is that panel is no more. Instead there are two more widgets on the desktop - desktop switcher and dock area. There's not much to describe about the workspace switcher, just that it looks nicer and is not in any panel. More describing is due for the dock. Basically it's a reminiscent of the panel, but it's transparent, 3D-like and I've removed all differences between applets, application launchers, notification/tray area and window list.
The combination of launchers serving also for window list isn't a new idea, I've already seen it implemented in the cairo-dock, though due to frequent crashes I had not much fun with it. But as I said, I'd go even one step farther and merge also the tray icons. The idea behind is that there actually is no difference between those so why should we make one. It also saves a lot of space.
And now how it would work? Let's say I want to launch an audio player. I click on the audio player icon and it starts. The icon buttonises (shown with epiphany launcher) and starts to behave like it now behaves in task list and/or notify area. Right-click will hide (or focus if it is not focused) the window in the icon another right-click will bring it back, left-click will show a menu with the usual commands like play, previous, next, etc.
Now for pure notify icons it would behave slightly different, e.g. right-click on the signal icon (network-manager) will open a menu where you can select networks you'd like to connect to, left-click will open a menu with additional settings, just like it behaves now.
For the applications without their tray icon the launcher starts serving as a button in window list - right-click for minimize/focus, left-click for window menu.
When you'd want to open new window instead of focusing the current one, just hold shift and click the icon, or select new window from the menu that apears when you hoover over it. Windows of the same app would be grouped together and you'd select which one you'd like to choose by selecting one from the menu that appears when you hoover over the icon.
Next thing you can notice on the dock is menu and places. This would be similar to the Applications menu and Places menu, optionally the System menu as well, with the tiny difference that it would open on hoovering instead of mouse click.
This setup would mean that you'd have almost any action available for use on single click.
Final word to say about this is configurability, I think the dock should have an easy way how to manage the applets that are on it, prefereably similar to how you do it now with gnome-panel. The cairo-dock configuration window is a total no-no for me - in the basic view I wasn't able to set-up anything I wanted and in the Advanced view there was so much options that I got lost very quick.
Wednesday, 4 February 2009
WebKit-gtk, libsoup, cURL and midori
It seems that webkit-gtk developers would like to see libsoup as the default backend in the gtk port, whereas the current setting (which is also used in the Fedora WebKit package) is the cURL backend. And since I have finally gathered enough free space to be able to build webkit, I decided I give it a go. In the following table I've summarized the differences between the two backends (libsoup backend with r40306 selfbuilt and cURL backend with r40351, grabbed from koji) I've, as a user, noticed (click on the images to get the large version).
To me, who uses midori (with webkit-gtk backend) as a secondary browser, the option with libsoup sounds better - I can use it to authenticate to fedorahosted, also the UI is much more responsive; and the things that do not work here, I can do with epiphany (still with gecko backend).
Now, I'd share a few words about Midori. It's a pretty interesting browser developed primarilly for XFCE users that is using WebKit-gtk backend. One of its interesting features (among the almost classical basic session management and saving, configurable search engines and google search implemented in address bar) is an option to reopen closed tab. It also has pretty clean and simple UI and I find working with it to be rather pleasant. And on top of that, thanks to webkit backend, it is pretty fast and from my experience generally faster than gecko based browsers (firefox, epiphany). Finally, I like its name - midori (緑) is a japanese for green/greenery.
And to end this post I'd like to write a few features (some of which are being already in progress) I am still missing and some bugs in webkit-gtk that prevents me using it as a primary browser backend:
And to answer the obvious question you might have, nope, I have not yet filled bug reports about the things I mentioned above, but will definitelly do so sooner or later (though actually for some of the above mentioned things there already are opened bugreports in webkit bugzilla). Anyway, I wish webkit bright future and hope that the gtk port will soon get to the point where it would make sense to use it in epiphany by default.
Also, to end it on a positive note, among the things that get better since the last time I've built webkit there is improved scrolling which is now really smooth (in past it felt snatchy, especially when one tried to scroll fast) and finally working opening new windows via javascript (though midori forces it to open rather in new tabs which is IMHO really cool). Also, I can finally watch youtube videos (among other things) in webkit as well (in past swfdec just failed to load the necessary files, probably thanks to some bug or missing feature in webkit).
libsoup | cURL | |
---|---|---|
Effects on Browser UI Responsivenes | I haven't noticed any effect on UI responsiveness when loading a web page. The spinner is spinning with constant speed, I can freely switch between tabs, create new tabs, ... | I noticed significant effects on the UI responsivenes when loading pages. Especially when loading more pages at once, the UI tends to become unresponsive for a while. Also the spinner animation is not smooth and at times it even stops completely. |
Web Authentication | Authentication seems to work pretty good, still there seems to be no way how to use ssh certificate to authenticate to koji | Authentication does not work at all. |
FTP Protocol Handling | If you try to access FTP you're straight away told that the site does not exists. I'd expect either a message that it cannot handle FTP protocol or, even better, automagically opening the requested url in file browser (which should know how to handle ftp) | CRASH! Although in the previous built I've been using it was giving, after an unreasonably long wait, listing, without any links or formating, of the requested ftp directory. |
AniDB (probably perl handling) | As you can see it gives a similar output to what you get by running e.g. cat /bin/ls . I suspect that the cause is that this site is made in perl. | Works just as expected. |
To me, who uses midori (with webkit-gtk backend) as a secondary browser, the option with libsoup sounds better - I can use it to authenticate to fedorahosted, also the UI is much more responsive; and the things that do not work here, I can do with epiphany (still with gecko backend).
Now, I'd share a few words about Midori. It's a pretty interesting browser developed primarilly for XFCE users that is using WebKit-gtk backend. One of its interesting features (among the almost classical basic session management and saving, configurable search engines and google search implemented in address bar) is an option to reopen closed tab. It also has pretty clean and simple UI and I find working with it to be rather pleasant. And on top of that, thanks to webkit backend, it is pretty fast and from my experience generally faster than gecko based browsers (firefox, epiphany). Finally, I like its name - midori (緑) is a japanese for green/greenery.
And to end this post I'd like to write a few features (some of which are being already in progress) I am still missing and some bugs in webkit-gtk that prevents me using it as a primary browser backend:
- Reasonable handling of downloads. It just tells you that document cannot be displayed. Right-click, download works in midori (if you set a download manager in midori settings), but it works the same way as with copy link + wget, which means when the link is actually a html page or some script that forwards you to the real source, it fails...
- As I said earlier, lack to authenticate with ssh certificate
- Inability to upload files - the UI for it works very well, just like in firefox, but when you hit the upload button, the website complains nothing was set to be uploaded.
- Occasional crashes when closing a tab.
- It seems it is not able to keep coockies between browser sessions (i.e. I have to login to web pages every time I restart midori)
- It does not remember my user name at sites like fedoraforum, even when I check "Remember me"
- Sometimes sloppy widget focus - at times cursor is blinking in edit fields but nothing can be written until I switch focus elsewhere and back...
And to answer the obvious question you might have, nope, I have not yet filled bug reports about the things I mentioned above, but will definitelly do so sooner or later (though actually for some of the above mentioned things there already are opened bugreports in webkit bugzilla). Anyway, I wish webkit bright future and hope that the gtk port will soon get to the point where it would make sense to use it in epiphany by default.
Also, to end it on a positive note, among the things that get better since the last time I've built webkit there is improved scrolling which is now really smooth (in past it felt snatchy, especially when one tried to scroll fast) and finally working opening new windows via javascript (though midori forces it to open rather in new tabs which is IMHO really cool). Also, I can finally watch youtube videos (among other things) in webkit as well (in past swfdec just failed to load the necessary files, probably thanks to some bug or missing feature in webkit).
Monday, 2 February 2009
Echo Monthly News Issue #6
We've published today the sixth issue of our Echo Monthly News. The topics covered are
- Echo Perspective starting of Fedora Hosted
- New Echo Artist Scripts and Supporting Icon Artist Library
- Initializing New Git Repository
- Updating Your Local Copy of Git Repository
- Creating New Icon from Template
- Adding Icon to Repository
Subscribe to:
Posts (Atom)