I suspect converters to be my second greatest idea for QetriX after Particles. In the past, QetriX used Renderers for output in desired format (HTML, JSON...). You simply handed over an object, like QList, to a Renderer of chosen kind and you got the output. It was simple as that.
But I faced the opposite situation - I have a string in some format and I need to convert it to an object. Imagine FileSystem DataStore, the data could be XML, JSON, flat file etc. I don't want to have FileSystemXml DataStore, not to mention Xml is for Soap DataStore as well. And I don't want to duplicate the code either.
I tried to create "coders", with encode and decode method. Therefore I was able to call a DataStore, the output process thru a coder.decode, then create an object and render it. Maybe it sounds complicated but in fact it was quite simple. Just few steps to make.
Well... no. It didn't work as well as I expected and I didn't like the name - coders. So back to a drawing board. I was working on a HTML coder, when the obvious came. I was dealing with conversion of a HTML code to an object and back, which in many aspects duplicates what Renderers are for. But Renderers are one-way only and I need two ways.
Even Renderers were in QetriX from the beginning, the new idea was beyond that. I renamed coders to converters (convs for short) and created few basic ones, like QForm to HTML (qform-html), Wiki to HTML (wiki-html). I was particularly happy about the second one, because before that it was as an add-on library. This way it makes much more sense.
I'm even able to make converters like PNG to JPEG, XML to QList, Image to Thumbnail or Integer to String.
To be honest, I can see the concept (or architecture, if you will) of Converters may be fundamentally wrong, because most functions are in fact converters, like "Math.add" converts two numbers into one number (sum total), and input/output types are not consistent, which is difficult to manage and impossible to unite into e.g. Interface. I may think of some boundaries in the future though.
Tuesday, April 21, 2015
Tuesday, April 14, 2015
Qarate
I like watching TV series, my list of favorites is quite long. I also like to re-watch them, from time to time, but sometimes only good episodes. I had a list of good ones on my personal wiki, but it was boring to note them each time (and when I watch multiple episodes in a row, I simply forget to note it and then I forget which one was the good one). So I discovered Trakt and was happy about it. Rating was quick and easy enough for me to actually do it.
One day Trakt creators upgraded the website and rating system was still in "to-do", so now I had nowhere to rate. I tried to google some replacement, but without any success. So, out of frustration, I added a new table "rating" to my personal wiki. It allowed me to rate not only episodes, but anything else - movies, songs, cars, vacations, etc. I was so pleased I thought this might be a nice service for others to use as well.
The biggest drawback was, that I had to enter the thing I was rating, mostly episode identification. I don't want my users to add anything. First of all, it's not quick and easy. Second of all, it will get wrong and duplicate (sorry, users...). It would require something, where all such data already is. Oh, wait!
I'm building qb for several years now and it will be the perfect marriage: a big database with "everything", plus a website, that allows you to rate anything. Sounds great.
I looked for a fitting name, which starts with "Q" and contains "rate" and in the shower (which is a common place for ideas for many people, according to one article I read) I thought of "Qarate". You can pronounce it as "Karate" (martial art) or "Carat" (unit of mass for gems and pearls). Therefore users may form dojos and level as gem rarity and belt colors (like blue diamond is more, than black sapphire).
Rating system will consist of 5 grades with matching score for that entity: +2 (excellent), +1 (good), 0 (meh), -1 (bad) and -2 (terrible). User may have limited +3 grades (the best), which can be used to mark notable things of it's kind, like one episode in a TV series season.
And I can imagine that rating of episodes may be relative to a rating of the whole series - +2 episode in +2 series is better, than +2 episode in +1 series. But user won't need to know that, it's a technicality for internal statistics and leaderboards.
One day Trakt creators upgraded the website and rating system was still in "to-do", so now I had nowhere to rate. I tried to google some replacement, but without any success. So, out of frustration, I added a new table "rating" to my personal wiki. It allowed me to rate not only episodes, but anything else - movies, songs, cars, vacations, etc. I was so pleased I thought this might be a nice service for others to use as well.
The biggest drawback was, that I had to enter the thing I was rating, mostly episode identification. I don't want my users to add anything. First of all, it's not quick and easy. Second of all, it will get wrong and duplicate (sorry, users...). It would require something, where all such data already is. Oh, wait!
I'm building qb for several years now and it will be the perfect marriage: a big database with "everything", plus a website, that allows you to rate anything. Sounds great.
I looked for a fitting name, which starts with "Q" and contains "rate" and in the shower (which is a common place for ideas for many people, according to one article I read) I thought of "Qarate". You can pronounce it as "Karate" (martial art) or "Carat" (unit of mass for gems and pearls). Therefore users may form dojos and level as gem rarity and belt colors (like blue diamond is more, than black sapphire).
Rating system will consist of 5 grades with matching score for that entity: +2 (excellent), +1 (good), 0 (meh), -1 (bad) and -2 (terrible). User may have limited +3 grades (the best), which can be used to mark notable things of it's kind, like one episode in a TV series season.
And I can imagine that rating of episodes may be relative to a rating of the whole series - +2 episode in +2 series is better, than +2 episode in +1 series. But user won't need to know that, it's a technicality for internal statistics and leaderboards.
Saturday, April 11, 2015
box-sizing: border-box;
One of the biggest pains in a web development, apart from vertical centering (except for inside a table cell), is a W3C box model, which doesn't include padding and borders into the width. You can't use "padding: 10px; width: 100%;", because the element will be 20px wider, than the parent element.
Fortunately, in CSS3 there's box-sizing property. Default value is "content-box", which behaves as the W3C model, but if you set the property to "border-box", it solves the problem with padding/border and the width. I noticed almost all major CSS frameworks adds this property to every element, like this:
* {
box-sizing: border-box;
}
In the past (in terms of internet it was more like an ancient history), comparable pain was an old Internet Explorer's own box model concept, which included border and padding into the width (so basically like "box-sizing: border-box"), whilst Netscape Navigator (ancestor of Firefox) followed W3C standards.
Side note: I don't like Microsoft doing stuff his own way, but this was actually better, than standards.
Anyway, when designing a web page you had to hack this differences, usually by using two divs instead of one. Outer div had the 100% width, inner div had the padding and border. Width of the inner div has been calculated automatically. And this wasn't the worst hack at the time, webdesign was often close to a witchcraft :-)
Microsoft added "standard mode" (now we call it "almost standard") into IE6, but kept so called "quirks mode" default and switching of those modes has been guided by DOCTYPE. This changed with IE7, where W3C mode became default (according to my test in IE11 dev tools).
Now, if you use HTML5 doctype <!DOCTYPE html>, you will get the best results - so use it always!
And about the vertical centering, you can use display property with CSS2.1 value "table-cell", so even div can behave like a table cell, with working vertical-align: middle, like this:
.verticenter {
display: table-cell;
vertical-align: middle;
}
But don't forget you should to make it a proper table! So parent div will have "display: table-row;" and it's parent div will have "display: table;". Happy styling!
Fortunately, in CSS3 there's box-sizing property. Default value is "content-box", which behaves as the W3C model, but if you set the property to "border-box", it solves the problem with padding/border and the width. I noticed almost all major CSS frameworks adds this property to every element, like this:
* {
box-sizing: border-box;
}
In the past (in terms of internet it was more like an ancient history), comparable pain was an old Internet Explorer's own box model concept, which included border and padding into the width (so basically like "box-sizing: border-box"), whilst Netscape Navigator (ancestor of Firefox) followed W3C standards.
Side note: I don't like Microsoft doing stuff his own way, but this was actually better, than standards.
Anyway, when designing a web page you had to hack this differences, usually by using two divs instead of one. Outer div had the 100% width, inner div had the padding and border. Width of the inner div has been calculated automatically. And this wasn't the worst hack at the time, webdesign was often close to a witchcraft :-)
Microsoft added "standard mode" (now we call it "almost standard") into IE6, but kept so called "quirks mode" default and switching of those modes has been guided by DOCTYPE. This changed with IE7, where W3C mode became default (according to my test in IE11 dev tools).
Now, if you use HTML5 doctype <!DOCTYPE html>, you will get the best results - so use it always!
And about the vertical centering, you can use display property with CSS2.1 value "table-cell", so even div can behave like a table cell, with working vertical-align: middle, like this:
.verticenter {
display: table-cell;
vertical-align: middle;
}
But don't forget you should to make it a proper table! So parent div will have "display: table-row;" and it's parent div will have "display: table;". Happy styling!
Tuesday, April 7, 2015
WPF styles
I knew WPF styles are powerful, but the XML code is sooo long that I've never felt the need to expand my app with tons of new lines. Until now.
Recently I moved to dark skins everywhere. In PhpStorm I switched to Dracula theme with modified Zenburn schema, Geany has Zenburn schema as well, for Thunderbird and Firefox I found magnificent DeepDark theme and earlier this year I updated Quiky editor to Monokai-like colors.
I finally decided to darker even the viewer part of Quiky. Panels were easy, it's possible to set colors as variables (e.g. <SolidColorBrush x:Key="GuiBackgroundBrushColor" Color="#666666" /> and then <Setter Property="Foreground" Value="{DynamicResource GuiForegroundBrushColor}"/>). The troubles came with a TreeView.
I spent few minutes googling how-to and I found a StackOverflow a solved question about styling TreeView items. I also wanted the whole line to be selected, not only the text background.
It took me a while to get the solution working, because honestly I didn't want to understand all that, felt like I won't need it. But I had to, so ultimately I even tweaked it a little. And because I learned what's going on (restyling is often recreating controls, all in XML), I decided to style the whole app.
My next concern were scrollbars. I wanted Apple-like and I found a solution as well. It also needed some tweaking, but it looks quite good. I added hover effect on the thumb (slider), so it fades in and out.
Finally I styled buttons, textboxes and comboboxes, but it would need a little more time (some finishing touches), so I did only some basic stuff. I want some subtle effects (animations), but I didn't like anything I made so far.
I'm satisfied, for now:
Recently I moved to dark skins everywhere. In PhpStorm I switched to Dracula theme with modified Zenburn schema, Geany has Zenburn schema as well, for Thunderbird and Firefox I found magnificent DeepDark theme and earlier this year I updated Quiky editor to Monokai-like colors.
I finally decided to darker even the viewer part of Quiky. Panels were easy, it's possible to set colors as variables (e.g. <SolidColorBrush x:Key="GuiBackgroundBrushColor" Color="#666666" /> and then <Setter Property="Foreground" Value="{DynamicResource GuiForegroundBrushColor}"/>). The troubles came with a TreeView.
I spent few minutes googling how-to and I found a StackOverflow a solved question about styling TreeView items. I also wanted the whole line to be selected, not only the text background.
It took me a while to get the solution working, because honestly I didn't want to understand all that, felt like I won't need it. But I had to, so ultimately I even tweaked it a little. And because I learned what's going on (restyling is often recreating controls, all in XML), I decided to style the whole app.
My next concern were scrollbars. I wanted Apple-like and I found a solution as well. It also needed some tweaking, but it looks quite good. I added hover effect on the thumb (slider), so it fades in and out.
Finally I styled buttons, textboxes and comboboxes, but it would need a little more time (some finishing touches), so I did only some basic stuff. I want some subtle effects (animations), but I didn't like anything I made so far.
I'm satisfied, for now:
 | |
| Before redesign |
 |
| After redesign |
Subscribe to:
Comments (Atom)