Turkiyenin en sevilen filmlerinin yer aldigi porno internet sitemiz olan ve sex tarzi bir site olan sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir.
Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.
We are working on improving theming support for Sencha projects, and are hoping to gain some useful insights from you. If you can, please tell us how you currently create or adjust themes for your projects. Reply to this post, or privately to email@example.com.
If you need some coaxing, here are some questions that would help us get a broad sense, but don't feel obliged to answer all of them, and feel free to add additional comments or information:
What tools and resources do you use to design themes?
What tools and resources do you use to implement themes?
How often do you adjust the themes for your projects?
How do you approach theming: the implementation should match design, or design is adapted to what is possible?
What are the issues that you encounter in this process? Can you give an example?
What could make the theming process easier or more straightforward?
I think of themes on a component level. When I have a component I need to theme differently from the rest of the project, I create theme overrides in a separate css file, and tweak as needed. It would be nice to be able to have some installed themes, say at the architect level, and allow a dropdown config for the component, to change which theme it should render with.
This might take a separate application, but the concept needs to encompass making themes/skins from a visual standpoint.
Setup a styling project and have the user choose one of the base themes to start with, using the current theme example page for understanding how all the elements work together. Here is a list of possible features:
1.) User can modify any of the theme elements or they can keep some and only modify others
2.) User will need the ability to change any and all graphics in any and all states
3.) User will be able to preview in real time or near real time in at least one of the engines, i.e. webkit
4.) User will have the ability to choose which browser to view in for preview outside of the application
5.) User will have the ability to ignore IE 6, 7 and maybe 8 to reduce CSS glut
6.) User will have the ability to define their own collection of graphics like a graphics bin
7.) User will be able to drag and drop from graphics bin to specific components
8.) User will be able "publish" from this app to SA project and refresh inside of SA to see changes
9.) User will have the ability to modify any component visually or numerically; used as get it close then fine tune it numerically kind of model
10.) User will have the ability to choose CSS3 only compatibility (which might not be practical in use yet)
This is just a beginning and could go a lot further. Maybe under the hood this is using SASS and Compass to generate/publish the output but none of that should be seen via this app. Compass of course includes the added step of needing Ruby installed, but that's only a hassle for Windows. If what compass does can be done without Ruby, then get rid of that dependency.
The main idea here is to give designers a place where they can do the visual work without the headache of all the details of code. I personally am a developer and a designer in one so I can easily drop into the code and mess with it, but when I'm designing I don't want to think about code. If the app requires less than 5% need of touching the code until it is "published", then it will be successful. There are plenty of coders out there who don't want the designers touching the code and those who are only coders shouldn't be touching the design. The way it is right now with ExtJs, the designing has to be done by coders and that's why ExtJs apps look dated and uninspiring. Occasionally hybrids like myself get through it and bridge the gap to make a hopefully more engaging experience, but right now it's more than a real hassle to get ExtJs to really look nice and/or custom.
SA has turned out to be a very good application and while the UX is not perfect, it is really, really good. It takes a pile of the hassle out of writing JS and lets us focus on logic and not the inner workings and headaches of JS and browser implementations. Now do the same thing for CSS and Sencha will have a product for making JS RIAs better than most if not all in the market.
--What tools and resources do you use to design themes?
I use Photoshop primarily to create the design and all states.
--What tools and resources do you use to implement themes?
Currently I don't try to change the theme, I just work around it and override theme CSS classes to somewhat customize the look. So far I have used the grey theme since it's the least color intrusive and change specific components to fold into the look.
--How often do you adjust the themes for your projects?
Not very often, it's a pain even with SASS and Compass. Design is a visual task, not a code task even thought it gets translated into code in the end.
--How do you approach theming: the implementation should match design, or design is adapted to what is possible?
Almost always design is adapted to what is possible. Implementation rarely matches the design and this at it's core is less about Sencha products but the state of disarray in the JS/CSS world.
--What are the issues that you encounter in this process? Can you give an example?
Good design means fretting about pixels and typography and UX. Data grids are powerful and a needed component, but good design is not one grid after another filled to the brim with data thrown at the user. I'll say it again, design is a visual art/task, not a code task. Anything that causes the design process to HAVE to mess with code, is an issue to this process.
--What could make the theming process easier or more straightforward?
See my previous post.