I know everyone will hate me now, but I've decided to break my current development of gtk-nodoka-engine-0.8.x and start working on it from scratch. I don't know what was the real push to do that, but I felt I needed to support wider configurations in the engine (with future in mind), develop more consistent, usable and pleasing look and feel and write the drawing code in a way that would be independent on the toolkit. As for the design itself as inspiration serves basically the widget design on iPhone (and OSX in general), current nodoka, the 0.8.x sketches and existing implementation, Chromium and much more.
For faster tuning of the gradients I've wrote a simple GTK application filled with sliders... And I later extended it for showcasing and testing drawing code of the widget. Forgive me for not publishing the source code, because it's total mess. The widget drawing code will eventually go to gtk-nodoka-engine, so I try to keep that part less messy, but creating the gui, writing event handlers, ... has been made in way that it just works (TM)...
I have to say that it's pretty interesting to write GTK applications using all the GObject and GtkWidget magic, and I've come to a deep understanding of why it's mostly inevitable to use tools like Glade to design more complex GUIs. The app currently looks like this:
The top left image serves for tuning the fill gradient settings, with the four sliders right of it I can control the base color and transparency, the other five sliders are for the actual gradients settings. With this I've finally came up with something I was satisfied with for button and added entry (because it often combines with button). The result is such:
Now, even though current GTK (AFAIK) does not directly support button groupings, it is possible that in the future such feature will be there, so I decided to have the drawing code prepared. Since the drawing code is independent on widget toolkit, I can simulate everything I want in my small app, which is why the bottom part of the app was added. It has an drawing area in which I draw the widgets (currently buttons only) and a button which serves as a reference for testing various states. You can notice, that I have grouped the buttons by three – that's to test all the various cases that can happen: button is first in group, button is last in group and button is in group but is neither first nor last.
Next feature not implemented AFAIK anywhere else than pango (and perhaps other text rendering libraries) is complete writing style support. That means not only the left to right, then top to bottom (used e.g. in Latin, English, ...) and right to left, then top to bottom (used e.g. in Arabic) cases covered by CSS, GTK, ... but also top to bottom, then right to left (used e.g. in East Asian scripts) and top to bottom, then left to right (used e.g. in Mongolian). At one point this was part of CSS3 specification, but for some reason it has been dropped. Anyway, because in code it means only implementing two new cases which basically means only using different transformation matrix, and thus should not affect speed of the rendering, I decided to implement it.
Thus in the preview in the app, there are actually four button groups – the top one is usual LTR, with the left button being treated as first, the one bellow is usual RTL, with the right button being treated as first, and bellow the left one is top to bottom, then left to right case, with the top button being treated as first and the remaining is top to bottom, then right to left case, again with top button being treated as first.
The lighting follows "paragraphs flow" – meaning that for horizontal text the light shines from mostly from top, and in vertical text depending on the flow either from left (Mongolian) or from right (Japanese). Now it would be even greater if I could add some text to the buttons to test how it would look with it included, but I don't know how (or rather I am too lazy to study pango from scratch and quick google search does not seem to reveal any nice pango tutorials)...
And now some video of the buttons "in work".
Download
Tuesday, 28 July 2009
Thursday, 23 July 2009
The True Meaning of "Open"
I may make jokes about Microsoft at times, but at the same time, I think the Microsoft hatred is a disease. I believe in open development, and that very much involves not just making the source open, but also not shutting other people and companies out.
There are ‘extremists’ in the free software world, but that’s one major reason why I don’t call what I do ‘free software’ any more. I don’t want to be associated with the people for whom it’s about exclusion and hatred.
— Linus Torvalds, Linux Magazine, via Open Source to Go!
I can totally identify myself with what LT said. I'd say that hatred is actually one of the worst emotions the mankind has. It blinds your rational thinking, makes you do things for which other people will dislike you, and in the end it will destroy yourself. To quote from Buddhist text:
Not by hate is hate defeated;
Hate is quenched by love.
This is the eternal law.
— Dhammapada, v.5
While I deem this to be a little far-fetched (as love is also blind) it basically grasps the core of the problem. Hate is not defeated by another hate. You won't defeat Microsoft by hating them. Well, they pose themselves in the role of the archenemy of Linux, but that might change. Our ultimate goal is not to defeat Microsoft and their Windows, the mantra of open source is about being open to others, sharing your ideas, your code. There is nothing about "fight" or animosity. It's a grave pity that with expansion of Linux, people not believing in this mantra appeared and our communication channels are being slowly infested by posts filled with hatred, animosity, personal insults and trolls.
We should all remember that the world open does not contain these emotions. By showing hatred or animosity towards others you are distancing yourself from being open, you close yourselves in your shell and that will eventually lead to your loss as to the loss of the thing you originally wanted to protect.
I believe similar ideas are in the core of many Asian martial arts. For example in 合気道 (合 – ai – joining, unifying, harmonizing, 気 – ki – spirit, life energy, 道 – dō – way, path) you have to became one with the enemy to master the techniques. The goal is not to the beat the attacker, the goal is to disarm (or dispose of if you wish) the attacker without hurting him.
Similarly by contributing to open source and not showing hatred against our "enemies" we can become stronger and in the long way win the "war". And winning here does not mean that open-source will be everywhere, it means that those who oppose us now will acknowledge us either as partners or as equal competitors. We do not need to lower ourselves to their level to "win".
Anyway, the basic premise of today's blog-post is that being open also means being tolerant and cooperative. These stands on a much higher moral level than hatred, FUD, … They are also vital for keeping the open-source community healthy. They are also one of the reasons I use and contribute to Fedora. It's four foundations contain these — freedom, friends, features, first.
Tuesday, 21 July 2009
Firefox 3.7 New Design
Well, quite an unexpected post in my blog... In Chromium's Tips and Tricks section I noticed an article entitled First Look: Firefox 3.7’s New Design. After briefly looking at the Vista Aero look I went WTF! I just cannot seem to find this semitransparency in windows nice... But well, I scrolled down and down and down until noticing the Win XP version which I deem to be the best. Well, if such UI gets implemented on linux as well, it would definitely prompt me to try using firefox again, as it's basically Chromium UI with tiny changes in ordering and separate search entry (I prefer search to be integrated in location bar though).
The UI is very effective, as I have discovered when using Chromium over these past few days, and I think it's been a high time for the redesign. For once I have to praise the guys at mozilla for doing the right thing ;-) It's would be shame, though, to not note that midori introduced this kind of UI as well with it's recent 0.1.8 release (although as an option, rather than as the only setting). It's a prove that Google's decision to introduce their own web browser will lead to benefit of users of other browsers as well.
The UI is very effective, as I have discovered when using Chromium over these past few days, and I think it's been a high time for the redesign. For once I have to praise the guys at mozilla for doing the right thing ;-) It's would be shame, though, to not note that midori introduced this kind of UI as well with it's recent 0.1.8 release (although as an option, rather than as the only setting). It's a prove that Google's decision to introduce their own web browser will lead to benefit of users of other browsers as well.
Friday, 17 July 2009
AdBlock in Midori!
I must have been lucky today... First I installed chromium and now, after trying out latest git snapshot of midori, I've discovered, it can actually block ads (via the included, by default disabled 'Advertisement blocker' extension)! Well, it's pretty lame still as I noticed it only blocks google ads (probably because of missing filters) and adding filters seems to not work (not that I have any filters anyway) and there are loads of 'FIXME' comments in the source code, but I cannot wait till it gets finished :-)
Now, if only I knew how the 'Mouse Gestures' extension is supposed to work (if it works at all), it would totally make the day even more awesome!
Now, if only I knew how the 'Mouse Gestures' extension is supposed to work (if it works at all), it would totally make the day even more awesome!
And thus the browser war hath started
Behold heathens, new web-browser hath descended upon the land of Fedora. Witness the few steps needed to deploy at FergyTech. The ultimate battle for superiority may begin. Who shall be the winner?
Well, that somehow summarizes my exitement. I wonder which browser I'll end-up with in Fedora 12 :-D For now, I am using simultaneously Midori (webkitgtk)
Epiphany (xulrunner)
and Chromium (webkit/chromium)
now ;-)
Btw. I just recently used firefox once again because of some download which worked only via firefox (I don't really know why though) and the page had an enormous amount of adds... well... to be fair... I got used again to displayed adds with midori (it's not possible yet to block adds in webkitgtk), but the experience with firefox was about five times worse... The amount of windows that popped up was just terrible... Well, I'd say that using firefox without AdBlock is in a sense equivalent to taking a stroll into underworld >_<
Maybe, I'll write a short review about those three above mentioned browses (plus epiphany 2.27 snapshot which uses webkitgtk instead of xulrunner) when I gain more experience with Chromium (so for now I'll keep the awesomeness of midori's location bar only hinted in the screenshot above ;-).
Well, that somehow summarizes my exitement. I wonder which browser I'll end-up with in Fedora 12 :-D For now, I am using simultaneously Midori (webkitgtk)
Epiphany (xulrunner)
and Chromium (webkit/chromium)
now ;-)
Btw. I just recently used firefox once again because of some download which worked only via firefox (I don't really know why though) and the page had an enormous amount of adds... well... to be fair... I got used again to displayed adds with midori (it's not possible yet to block adds in webkitgtk), but the experience with firefox was about five times worse... The amount of windows that popped up was just terrible... Well, I'd say that using firefox without AdBlock is in a sense equivalent to taking a stroll into underworld >_<
Maybe, I'll write a short review about those three above mentioned browses (plus epiphany 2.27 snapshot which uses webkitgtk instead of xulrunner) when I gain more experience with Chromium (so for now I'll keep the awesomeness of midori's location bar only hinted in the screenshot above ;-).
Monday, 13 July 2009
The mess that libass is
With 'recent' inclusion of proper ASS/SSA subtitles support into gstreamer via libass, it became a necessity to package this library separately. There seems to be one official upstream at sourceforge, but mplayer ships it's own patched version of libass, vlc as well and to make the mess even bigger, there's greg's version... As I've taken upon myself the task to provide this package for fedora, I'm trying to find the best solution to this but I don't have a single clue what the best approach would be there. Also, we seem to be on the head of separate packaging of this library separately (I've found debian, ubuntu and gentoo packages) and it would be probably good to solve this issue before other big distros start to package it and make the mess even bigger...
The gentoo package seems to be 0.9.6 unpatched, debian includes mplayer's batch patch against 0.9.6 and ubuntu is pretty much identical to debian...
Now vlc's patches seems to be taken from mplayer + one or two other fixes, however the greg's version deviates further from the official 0.9.6 version and is not API compatible with previous versions. All of those include critical, as well as non-critical, fixes and feature enhancements. Now the question is what to do about this mess? Yes, I could do the same as gentoo and just wait till 0.9.7 is released (and who knows how long will it take), or I can follow debian and just add the mplayer patch and make a note in the spec file where it originates from. That would be both an easy workarounds leading practically nowhere.
I could also review in full all the changes that the patches/greg's version carry, try to understand what does what and back-port fixes as well as submitting the (smaller) patches upstream.
I could also switch to greg's version in rawhide and hope it will not break anything... It seems almost all development is happening there, but on the other hand I'd rather not use git snapshot... Although after quick look at his changelog, it seems he might be releasing 0.9.7 soonish...
Ideally vlc and mplayer would switch to system libass, greg's version merged with upstream and do a release and everyone would be happy...
Now the basic question, are there people willing to help in any way with solving this issue?
UPDATE: The mess is beginning to clean up now. The official page now suggests Greg's git as the main version and I have been told that mplayer has plans to link dynamically against this version as well and vlc is switching over to this one as well. This means that I'll switch to greg's version in Rawhide in near future as well and if it works well, I'll use it also in stable releases.
The gentoo package seems to be 0.9.6 unpatched, debian includes mplayer's batch patch against 0.9.6 and ubuntu is pretty much identical to debian...
Now vlc's patches seems to be taken from mplayer + one or two other fixes, however the greg's version deviates further from the official 0.9.6 version and is not API compatible with previous versions. All of those include critical, as well as non-critical, fixes and feature enhancements. Now the question is what to do about this mess? Yes, I could do the same as gentoo and just wait till 0.9.7 is released (and who knows how long will it take), or I can follow debian and just add the mplayer patch and make a note in the spec file where it originates from. That would be both an easy workarounds leading practically nowhere.
I could also review in full all the changes that the patches/greg's version carry, try to understand what does what and back-port fixes as well as submitting the (smaller) patches upstream.
I could also switch to greg's version in rawhide and hope it will not break anything... It seems almost all development is happening there, but on the other hand I'd rather not use git snapshot... Although after quick look at his changelog, it seems he might be releasing 0.9.7 soonish...
Ideally vlc and mplayer would switch to system libass, greg's version merged with upstream and do a release and everyone would be happy...
Now the basic question, are there people willing to help in any way with solving this issue?
UPDATE: The mess is beginning to clean up now. The official page now suggests Greg's git as the main version and I have been told that mplayer has plans to link dynamically against this version as well and vlc is switching over to this one as well. This means that I'll switch to greg's version in Rawhide in near future as well and if it works well, I'll use it also in stable releases.
Subscribe to:
Posts (Atom)